From report at bugs.python.org Thu Jan 1 00:15:29 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 31 Dec 2014 23:15:29 +0000 Subject: [issue18648] FP Howto and the PEP 8 lambda guildline In-Reply-To: <1375563496.73.0.458556999556.issue18648@psf.upfronthosting.co.za> Message-ID: <1420067729.14.0.0027623292531.issue18648@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 02:25:35 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 01 Jan 2015 01:25:35 +0000 Subject: [issue1500504] Alternate RFC 3986 compliant URI parsing module Message-ID: <1420075535.18.0.438921307361.issue1500504@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 02:28:36 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 01 Jan 2015 01:28:36 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1420075716.46.0.636380672837.issue2292@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 03:43:46 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 01 Jan 2015 02:43:46 +0000 Subject: [issue20898] Missing 507 response description In-Reply-To: <1394637244.26.0.361164120424.issue20898@psf.upfronthosting.co.za> Message-ID: <1420080226.92.0.37926114965.issue20898@psf.upfronthosting.co.za> Demian Brecht added the comment: @Berker: Good point, although I think that the status code table in http.client.rst should be merged with the one in http.rst as to avoid redundancy (newly added status codes should also have links added). The table in http.client.rst should likely be replaced with a link to the newer one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 03:49:39 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 01 Jan 2015 02:49:39 +0000 Subject: [issue17994] Change necessary in platform.py to support IronPython In-Reply-To: <1368714285.1.0.952125974829.issue17994@psf.upfronthosting.co.za> Message-ID: <1420080579.47.0.0141171563532.issue17994@psf.upfronthosting.co.za> Mark Lawrence added the comment: Cpython was changed via #8964 to handle this situation. ---------- nosy: +BreamoreBoy, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 07:06:15 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 01 Jan 2015 06:06:15 +0000 Subject: [issue22680] Blacklist FunctionTestCase from test discovery In-Reply-To: <1413825261.98.0.71045668194.issue22680@psf.upfronthosting.co.za> Message-ID: <1420092375.2.0.780263373654.issue22680@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 07:44:32 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 01 Jan 2015 06:44:32 +0000 Subject: [issue22680] Blacklist FunctionTestCase from test discovery In-Reply-To: <1413825261.98.0.71045668194.issue22680@psf.upfronthosting.co.za> Message-ID: <1420094672.15.0.945720906206.issue22680@psf.upfronthosting.co.za> Martin Panter added the comment: Assuming that FunctionTestCase inherits from TestCase, a fix for Issue 14534 would be useful here. That bug is about avoiding TestCase subclasses being automatically run, which is useful for abstract base test classes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 08:58:44 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 01 Jan 2015 07:58:44 +0000 Subject: [issue23142] Integration of unittest.FunctionTestCase with automatic discovery and loading Message-ID: <1420099124.62.0.985279569808.issue23142@psf.upfronthosting.co.za> New submission from Martin Panter: It is not clear how you are meant to use unittest.FunctionTestCase with automatic test running. Unless a simple way to do this already exists, I wonder if it would be okay to automatically discover and run predefined test instances, such as the "test_module.testcase" object in my example module. Currently the ?testcase? object is ignored by the automatic test discovery. Also, attempting to manually run it results in $ python -m unittest test_module.testcase [. . .] TypeError: calling unittest.case.FunctionTestCase (testSomething) returned returned , not a test Apparently calling a TestCase instance invokes TestCase.run()! The only way I can think of making such a test discoverable is my making a subclass. But as demonstrated by my example module, this is more cumbersome than bypassing FunctionTestCase altogether. ---------- components: Library (Lib) files: test_module.py messages: 233276 nosy: vadmium priority: normal severity: normal status: open title: Integration of unittest.FunctionTestCase with automatic discovery and loading type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file37579/test_module.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 10:53:41 2015 From: report at bugs.python.org (=?utf-8?q?Mi=C8=99u_Moldovan?=) Date: Thu, 01 Jan 2015 09:53:41 +0000 Subject: [issue20981] ssl doesn't build anymore with OpenSSL 0.9.7 or older: X509_check_ca In-Reply-To: <1395247121.79.0.24713590698.issue20981@psf.upfronthosting.co.za> Message-ID: <1420106021.74.0.855068138903.issue20981@psf.upfronthosting.co.za> Mi?u Moldovan added the comment: Starting with 2.7.9, this affects the 2.7 branch as well. Please note that it's not only out-of-maintenance FreeBSD versions that are affected, but also a current version of Solaris, namely Solaris 10. The end of "Premier" support for Solaris 10 is January 2018 and the end of "Extended" support for Solaris 10 is January 2021, according to http://www.oracle.com/us/support/library/lifetime-support-hardware-301321.pdf Solaris 10 has OpenSSL 0.9.7 and all security fixes are back-ported to it, more at https://blogs.oracle.com/darren/entry/openssl_versions_in_solaris ---------- nosy: +dumol versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 11:00:51 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 01 Jan 2015 10:00:51 +0000 Subject: [issue23142] Integration of unittest.FunctionTestCase with automatic discovery and loading In-Reply-To: <1420099124.62.0.985279569808.issue23142@psf.upfronthosting.co.za> Message-ID: <1420106451.28.0.693758622977.issue23142@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +ezio.melotti, michael.foord, rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 12:12:05 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 01 Jan 2015 11:12:05 +0000 Subject: [issue13248] deprecated in 3.2/3.3, should be removed in 3.4 In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za> Message-ID: <1420110725.31.0.668217012549.issue13248@psf.upfronthosting.co.za> Mark Lawrence added the comment: Can this be closed as plenty of changesets have been pushed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 12:49:35 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 01 Jan 2015 11:49:35 +0000 Subject: [issue20981] ssl doesn't build anymore with OpenSSL 0.9.7 or older: X509_check_ca In-Reply-To: <1395247121.79.0.24713590698.issue20981@psf.upfronthosting.co.za> Message-ID: <1420112975.02.0.413860612166.issue20981@psf.upfronthosting.co.za> Antoine Pitrou added the comment: 0.9.7 is truly ancient. I'd rather not add more conditional code and let people maintain their fork of Python if they already maintain a fork of OpenSSL. ---------- nosy: +alex, dstufft, giampaolo.rodola, janssen resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 12:55:39 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 01 Jan 2015 11:55:39 +0000 Subject: [issue23143] Remove some conditional code in _ssl.c Message-ID: <1420113339.19.0.823124921107.issue23143@psf.upfronthosting.co.za> New submission from Antoine Pitrou: There's a lot of conditional code in _ssl.c, meant to address the unavailability of some features in old OpenSSL versions. I think for 3.5 we should require at least 0.9.8 (which is already old), and consequently remove some of those conditionals. ---------- components: Library (Lib) keywords: easy messages: 233280 nosy: pitrou priority: low severity: normal stage: needs patch status: open title: Remove some conditional code in _ssl.c type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 13:02:09 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 01 Jan 2015 12:02:09 +0000 Subject: [issue23140] InvalidStateError on asyncio subprocess task cancelled In-Reply-To: <1420019773.34.0.176587493323.issue23140@psf.upfronthosting.co.za> Message-ID: <1420113729.25.0.17693416224.issue23140@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The exception is not raised when loop.set_debug(False) on my linux box. So I guess this may be not reproductible on all platforms. The new attached test_cancel_2.py raises an exception while asyncio debug is false, by forcing one more iteration of the loop after the pending tasks list is empty. Also with asyncio debug false and with test_cancel_2.py and after removing the last task from the initial tasks list (i.e. asyncio.Task(asyncio.sleep(10))): * with more_iterations = 2: the exception is raised, not often * with more_iterations = 3: the exception is raised, seemingly always * with more_iterations = 0: another exception, often; Exception ignored when trying to write to the signal wakeup fd: OSError: [Errno 9] Bad file descriptor ---------- Added file: http://bugs.python.org/file37580/test_cancel_2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 13:04:43 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 01 Jan 2015 12:04:43 +0000 Subject: [issue22560] Add loop-agnostic SSL implementation to asyncio In-Reply-To: <1412548102.84.0.685230620276.issue22560@psf.upfronthosting.co.za> Message-ID: <1420113883.37.0.861106428968.issue22560@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ping :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 13:09:58 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 01 Jan 2015 12:09:58 +0000 Subject: [issue19777] Provide a home() classmethod on Path objects In-Reply-To: <1385409863.35.0.0114355564026.issue19777@psf.upfronthosting.co.za> Message-ID: <1420114198.94.0.277023960241.issue19777@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- keywords: +easy stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 13:13:35 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 01 Jan 2015 12:13:35 +0000 Subject: [issue22560] Add loop-agnostic SSL implementation to asyncio In-Reply-To: <1412548102.84.0.685230620276.issue22560@psf.upfronthosting.co.za> Message-ID: <1420114415.48.0.157230577292.issue22560@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Note this could probably help https://twitter.com/icgood/status/549915951165358080, which Victor seems to care about :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 14:28:36 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 01 Jan 2015 13:28:36 +0000 Subject: [issue23132] Faster total_ordering In-Reply-To: <1419931329.13.0.970719266671.issue23132@psf.upfronthosting.co.za> Message-ID: <20150101132832.8753.76704@psf.io> Roundup Robot added the comment: New changeset 4e85df8b3ea6 by Serhiy Storchaka in branch 'default': Issue #23132: Improve performance and introspection support of comparison https://hg.python.org/cpython/rev/4e85df8b3ea6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 16:32:05 2015 From: report at bugs.python.org (Vandana Rao) Date: Thu, 01 Jan 2015 15:32:05 +0000 Subject: [issue13077] Unclear behavior of daemon threads on main thread exit In-Reply-To: <1317396642.03.0.535538271179.issue13077@psf.upfronthosting.co.za> Message-ID: <1420126325.53.0.82359388635.issue13077@psf.upfronthosting.co.za> Vandana Rao added the comment: On Windows8.1,this is not the situation.Irrespective of the thread being daemon or non-daemon,the process continues. The program doesn't terminate when daemon thread is being used. ---------- nosy: +Vandana.Rao _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 16:56:16 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 01 Jan 2015 15:56:16 +0000 Subject: [issue13077] Unclear behavior of daemon threads on main thread exit In-Reply-To: <1317396642.03.0.535538271179.issue13077@psf.upfronthosting.co.za> Message-ID: <1420127776.08.0.0496869468274.issue13077@psf.upfronthosting.co.za> R. David Murray added the comment: etuardu: I think you rewording is indeed clearer. Vandana: Please open a new issue with a reproducer. ---------- stage: patch review -> needs patch versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 17:06:36 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 01 Jan 2015 16:06:36 +0000 Subject: [issue23142] Integration of unittest.FunctionTestCase with automatic discovery and loading In-Reply-To: <1420099124.62.0.985279569808.issue23142@psf.upfronthosting.co.za> Message-ID: <1420128396.96.0.971653839798.issue23142@psf.upfronthosting.co.za> R. David Murray added the comment: According to the docs, there's no reason to use FunctionTestCase unless you are dealing with legacy test code (eg: importing it from some existing module), so yes your "this seems easier" is certainly easier :) (I wasn't even aware FunctionTestCase existed.) I'm not sure what the issues would be with making them discoverable. We'll wee what Robert and/or Michael have to say. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 18:20:10 2015 From: report at bugs.python.org (Victor Salgado) Date: Thu, 01 Jan 2015 17:20:10 +0000 Subject: [issue19777] Provide a home() classmethod on Path objects In-Reply-To: <1385409863.35.0.0114355564026.issue19777@psf.upfronthosting.co.za> Message-ID: <1420132810.46.0.123642407161.issue19777@psf.upfronthosting.co.za> Changes by Victor Salgado : ---------- keywords: +patch Added file: http://bugs.python.org/file37581/path_home.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 18:28:23 2015 From: report at bugs.python.org (Kevin J Pallan) Date: Thu, 01 Jan 2015 17:28:23 +0000 Subject: [issue19777] Provide a home() classmethod on Path objects In-Reply-To: <1385409863.35.0.0114355564026.issue19777@psf.upfronthosting.co.za> Message-ID: <1420133303.91.0.290549062348.issue19777@psf.upfronthosting.co.za> Changes by Kevin J Pallan : ---------- nosy: +artifex93 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 18:44:32 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 01 Jan 2015 17:44:32 +0000 Subject: [issue18787] Misleading error from getspnam function of spwd module In-Reply-To: <1376971981.98.0.467831293927.issue18787@psf.upfronthosting.co.za> Message-ID: <1420134272.37.0.275571998878.issue18787@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think we should always raise OSError if errno is non-zero (and not KeyError). ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 18:47:13 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 01 Jan 2015 17:47:13 +0000 Subject: [issue10388] spwd returning different value depending on privileges In-Reply-To: <1289484192.53.0.424683719192.issue10388@psf.upfronthosting.co.za> Message-ID: <1420134433.38.0.0830509283082.issue10388@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The approach in the patch seems good to me. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 19:42:51 2015 From: report at bugs.python.org (liu chang) Date: Thu, 01 Jan 2015 18:42:51 +0000 Subject: [issue23076] list(pathlib.Path().glob("")) fails with IndexError In-Reply-To: <1418860780.4.0.558535328721.issue23076@psf.upfronthosting.co.za> Message-ID: <1420137771.22.0.602030937365.issue23076@psf.upfronthosting.co.za> liu chang added the comment: hi pitrou, should we fix it in _make_selector(pattern_parts) function? origin code as: def _make_selector(pattern_parts): pat = pattern_parts[0] child_parts = pattern_parts[1:] if pat == '**': cls = _RecursiveWildcardSelector elif '**' in pat: raise ValueError("Invalid pattern: '**' can only be an entire path component") elif _is_wildcard_pattern(pat): cls = _WildcardSelector else: cls = _PreciseSelector return cls(pat, child_parts) Is it a good fix that: check the length of pattern_parts, if its length < 2, we set pat to empty str, set child_parts to a empty list? A simple code like: def _make_selector(pattern_parts): try: pat = pattern_parts[0] child_parts = pattern_parts[1:] except IndexError: pat = "" child_parts = [] if pat == '**': cls = _RecursiveWildcardSelector elif '**' in pat: raise ValueError("Invalid pattern: '**' can only be an entire path component") elif _is_wildcard_pattern(pat): cls = _WildcardSelector else: cls = _PreciseSelector return cls(pat, child_parts) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 19:43:19 2015 From: report at bugs.python.org (Victor Salgado) Date: Thu, 01 Jan 2015 18:43:19 +0000 Subject: [issue19777] Provide a home() classmethod on Path objects In-Reply-To: <1385409863.35.0.0114355564026.issue19777@psf.upfronthosting.co.za> Message-ID: <1420137799.82.0.0704863197446.issue19777@psf.upfronthosting.co.za> Changes by Victor Salgado : Added file: http://bugs.python.org/file37582/path_home2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 19:47:08 2015 From: report at bugs.python.org (Ross) Date: Thu, 01 Jan 2015 18:47:08 +0000 Subject: [issue23144] html.parser.HTMLParser: setting 'convert_charrefs = True' leads to dropped text Message-ID: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za> New submission from Ross: If convert_charrefs is set to true the final data section is not return by feed(). It is held until the next tag is encountered. --- from html.parser import HTMLParser class MyHTMLParser(HTMLParser): def __init__(self): HTMLParser.__init__(self, convert_charrefs=True) self.fed = [] def handle_starttag(self, tag, attrs): print("Encountered a start tag:", tag) def handle_endtag(self, tag): print("Encountered an end tag :", tag) def handle_data(self, data): print("Encountered some data :", data) parser = MyHTMLParser() parser.feed("foo link bar") print("") parser.feed("spam link eggs") --- gives Encountered some data : foo Encountered a start tag: a Encountered some data : link Encountered an end tag : a Encountered some data : barspam Encountered a start tag: a Encountered some data : link Encountered an end tag : a With 'convert_charrefs = False' it works as expected. ---------- components: Library (Lib) messages: 233291 nosy: xkjq priority: normal severity: normal status: open title: html.parser.HTMLParser: setting 'convert_charrefs = True' leads to dropped text type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 19:57:09 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 01 Jan 2015 18:57:09 +0000 Subject: [issue23144] html.parser.HTMLParser: setting 'convert_charrefs = True' leads to dropped text In-Reply-To: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za> Message-ID: <1420138629.89.0.888971750179.issue23144@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +ezio.melotti, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 20:32:46 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 01 Jan 2015 19:32:46 +0000 Subject: [issue23144] html.parser.HTMLParser: setting 'convert_charrefs = True' leads to dropped text In-Reply-To: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za> Message-ID: <1420140766.7.0.311727580158.issue23144@psf.upfronthosting.co.za> Martin Panter added the comment: You ?forgot? to call close(): >>> parser.close() Encountered some data : eggs Perhaps this is a documentation bug, since there is a lot of example code given, but none of the examples call close(). ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 20:39:41 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 01 Jan 2015 19:39:41 +0000 Subject: [issue13248] deprecated in 3.2/3.3, should be removed in 3.4 In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za> Message-ID: <1420141181.43.0.0902584009078.issue13248@psf.upfronthosting.co.za> Terry J. Reedy added the comment: At most half of the items listed in the original post have been dealt with. Each remaining 'deprecated items should be removed in 3.5, undeprecated, or a decision recorded to leave it deprecated indefinitely. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 20:40:05 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 01 Jan 2015 19:40:05 +0000 Subject: [issue13248] deprecated in 3.2/3.3, should be removed in 3.5 or ??? In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za> Message-ID: <1420141205.94.0.342130971469.issue13248@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- title: deprecated in 3.2/3.3, should be removed in 3.4 -> deprecated in 3.2/3.3, should be removed in 3.5 or ??? versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 20:48:15 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Thu, 01 Jan 2015 19:48:15 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <1420141695.19.0.218327340679.issue22619@psf.upfronthosting.co.za> Dmitry Kazakov added the comment: Python Developer's Guide said to ping the issue, in case of one-month long inactivity period. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 21:36:29 2015 From: report at bugs.python.org (Ross) Date: Thu, 01 Jan 2015 20:36:29 +0000 Subject: [issue23144] html.parser.HTMLParser: setting 'convert_charrefs = True' leads to dropped text In-Reply-To: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za> Message-ID: <1420144589.41.0.959965568567.issue23144@psf.upfronthosting.co.za> Ross added the comment: That would make sense. Might also be worth mentioning the difference in behaviour with convert_charrefs = True/False as that was what led me to think this was a bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 23:11:33 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 01 Jan 2015 22:11:33 +0000 Subject: [issue13248] deprecated in 3.2/3.3, should be removed in 3.5 or ??? In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za> Message-ID: <1420150293.05.0.549740029662.issue13248@psf.upfronthosting.co.za> Martin Panter added the comment: See Issue 19167 for a patch to remove the xml.etree.XMLParser.doctype() method. I?m happy for it to be removed, since the logic for generating the DeprecationWarning is buggy. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 23:12:19 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 01 Jan 2015 22:12:19 +0000 Subject: [issue13248] deprecated in 3.2/3.3, should be removed in 3.5 or ??? In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za> Message-ID: <1420150339.2.0.63182900119.issue13248@psf.upfronthosting.co.za> Martin Panter added the comment: Make that Issue 19176 for XMLParser.doctype() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 23:38:59 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Jan 2015 22:38:59 +0000 Subject: [issue23145] regrtest: log test loader errors Message-ID: <1420151939.5.0.279924205041.issue23145@psf.upfronthosting.co.za> New submission from STINNER Victor: Currently, when regrtest fails to load a test submodule, no exception is raised, no error is logged. I propose to at least log all loader errors: see attached regrtest.patch. For an example, try to apply the attached test_asyncio_bug.patch and run: ./python -m test -m test_not_implemented test_asyncio The current output is: --- [1/1] test_asyncio 1 test OK. --- The output with regrtest.patch: --- haypo at selma$ ./python -m test -m test_not_implemented test_asyncio [1/1] test_asyncio Failed to import test module: test.test_asyncio.test_base_events Traceback (most recent call last): File "/home/haypo/prog/python/default/Lib/unittest/loader.py", line 417, in _find_test_path module = self._get_module_from_name(name) File "/home/haypo/prog/python/default/Lib/unittest/loader.py", line 358, in _get_module_from_name __import__(name) File "/home/haypo/prog/python/default/Lib/test/test_asyncio/test_base_events.py", line 29 class BaseEventLoopTests(test_utils.TestCase) ^ SyntaxError: invalid syntax 1 test OK. --- Or should we raise an exception instead? ---------- components: Tests files: regrtest.patch keywords: patch messages: 233298 nosy: haypo priority: normal severity: normal status: open title: regrtest: log test loader errors versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37583/regrtest.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 23:39:13 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Jan 2015 22:39:13 +0000 Subject: [issue23145] regrtest: log test loader errors In-Reply-To: <1420151939.5.0.279924205041.issue23145@psf.upfronthosting.co.za> Message-ID: <1420151953.31.0.460083744498.issue23145@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file37584/test_asyncio_bug.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 1 23:59:56 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 01 Jan 2015 22:59:56 +0000 Subject: [issue22560] Add loop-agnostic SSL implementation to asyncio In-Reply-To: <1412548102.84.0.685230620276.issue22560@psf.upfronthosting.co.za> Message-ID: <1420153196.79.0.576496598936.issue22560@psf.upfronthosting.co.za> Guido van Rossum added the comment: Maybe we should just accept this without review? I really don't have time to review 600+ lines of code, sorry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 02:11:52 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 Jan 2015 01:11:52 +0000 Subject: [issue22560] Add loop-agnostic SSL implementation to asyncio In-Reply-To: <1412548102.84.0.685230620276.issue22560@psf.upfronthosting.co.za> Message-ID: <1420161112.62.0.775553116082.issue22560@psf.upfronthosting.co.za> STINNER Victor added the comment: > Maybe we should just accept this without review? I really don't have time to review 600+ lines of code, sorry. SSL/TLS is very important and the patch is large, a review is required. I posted a first review with a lot of comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 02:14:46 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 Jan 2015 01:14:46 +0000 Subject: [issue22560] Add loop-agnostic SSL implementation to asyncio In-Reply-To: <1412548102.84.0.685230620276.issue22560@psf.upfronthosting.co.za> Message-ID: <1420161286.97.0.265664249118.issue22560@psf.upfronthosting.co.za> STINNER Victor added the comment: Sorry for the delay. I understood that the change targets the proactor event loop, and I was busy to fix annoying random bugs in this code (it's not done yet, see for example the issue #23095 for the most recent bug). Windows is not my favorite OS, I am less intersted to fix Windows specific bugs, but sometimes I try to fix them. I still don't understand if the change is (or should be) specific to the proactor event loop or not. Antoine, can you please elaborate the rationale of your patch? Is the "legacy" code only used on Python 3.4 and older? Is ssl.MemoryBIO always present in Python 3.5 and newer? I would like to see benchmarks of memory BIO vs current code on Linux and Windows. Even if it would make the code simpler to always use memory BIO, I care of network performances. Maybe we may only use memory BIO for the proactor event loop? Do you know if other applications use memory BIO for networking with SSL? Did you try your patch on Python 3.3? On Linux and Windows? Anyway, great job! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 02:15:36 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 Jan 2015 01:15:36 +0000 Subject: [issue22560] Add loop-agnostic SSL implementation to asyncio In-Reply-To: <1412548102.84.0.685230620276.issue22560@psf.upfronthosting.co.za> Message-ID: <1420161336.37.0.599385462036.issue22560@psf.upfronthosting.co.za> STINNER Victor added the comment: > Note this could probably help https://twitter.com/icgood/status/549915951165358080, which Victor seems to care about :-) Copy of the tweet: "@gvanrossum Will we be seeing TLS upgrade support (e.g. STARTTLS) soon in asyncio / tulip? All threads and issues on the subject seem stale." How will this patch help to support STARTTLS? Could you please elaborate Antoine? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 02:47:21 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 Jan 2015 01:47:21 +0000 Subject: [issue22560] Add loop-agnostic SSL implementation to asyncio In-Reply-To: <1412548102.84.0.685230620276.issue22560@psf.upfronthosting.co.za> Message-ID: <1420163241.59.0.326009523421.issue22560@psf.upfronthosting.co.za> STINNER Victor added the comment: FYI Twisted supports SSL with IOCP using pyOpenSSL 0.10 (released in 2009) or newer. The support is based on twisted.protocols.tls.TLSMemoryBIOFactory. It looks like the memory BIO implementation is now preferred on all platforms. See the twisted.internet._newtls module: """ This module implements memory BIO based TLS support. It is the preferred implementation and will be used whenever pyOpenSSL 0.10 or newer is installed (whenever L{twisted.protocols.tls} is importable). @since: 11.1 """ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 03:46:12 2015 From: report at bugs.python.org (koobs) Date: Fri, 02 Jan 2015 02:46:12 +0000 Subject: [issue23042] Python 2.7.9 ctypes module doesn't build on FreeBSD x86 In-Reply-To: <1418416859.8.0.212660740366.issue23042@psf.upfronthosting.co.za> Message-ID: <1420166772.94.0.211066951712.issue23042@psf.upfronthosting.co.za> koobs added the comment: @lemburg, does reverting this patch fix the regression for you? ---------- nosy: +koobs type: -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 03:50:15 2015 From: report at bugs.python.org (koobs) Date: Fri, 02 Jan 2015 02:50:15 +0000 Subject: [issue23085] update internal libffi copy to 3.2.1 In-Reply-To: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za> Message-ID: <1420167015.04.0.950077087083.issue23085@psf.upfronthosting.co.za> Changes by koobs : ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 05:19:45 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 02 Jan 2015 04:19:45 +0000 Subject: [issue23145] regrtest: log test loader errors In-Reply-To: <1420151939.5.0.279924205041.issue23145@psf.upfronthosting.co.za> Message-ID: <1420172385.98.0.152076679978.issue23145@psf.upfronthosting.co.za> R. David Murray added the comment: loader.errors only exists in 3.5. ---------- nosy: +r.david.murray versions: -Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 05:21:19 2015 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 02 Jan 2015 04:21:19 +0000 Subject: [issue22560] Add loop-agnostic SSL implementation to asyncio In-Reply-To: <1412548102.84.0.685230620276.issue22560@psf.upfronthosting.co.za> Message-ID: <1420172479.63.0.448266155082.issue22560@psf.upfronthosting.co.za> Guido van Rossum added the comment: Oh, I think I understand how this could help STARTTLS. Glyph once explained it to me. STARTTLS takes an existing non-TLS Transport and layers a TLS Transport on top of it. This requires the TLS layer to read/write from the underlying Transport using the standard Transport/Protocol interface (i.e. call transport.write() to write bytes, expect protocol.data_received() to be called when bytes are read). The existing (3.4) ssl module cannot do this because the TLS implementation needs to wrap the socket directly; but (presumably) the BIO-based TLS implementation can do this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 06:12:12 2015 From: report at bugs.python.org (koobs) Date: Fri, 02 Jan 2015 05:12:12 +0000 Subject: [issue13655] Python SSL stack doesn't have a default CA Store In-Reply-To: <1324635534.55.0.434420251569.issue13655@psf.upfronthosting.co.za> Message-ID: <1420175532.02.0.957614272835.issue13655@psf.upfronthosting.co.za> Changes by koobs : ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 06:13:44 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 02 Jan 2015 05:13:44 +0000 Subject: [issue13655] Python SSL stack doesn't have a default CA Store In-Reply-To: <1324635534.55.0.434420251569.issue13655@psf.upfronthosting.co.za> Message-ID: <1420175624.72.0.066533534879.issue13655@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I don't think we're planning to distribute our own store of certs. ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 10:40:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 02 Jan 2015 09:40:25 +0000 Subject: [issue23146] Incosistency in pathlib between / and \ Message-ID: <1420191625.18.0.999730856462.issue23146@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: >>> pathlib.PureWindowsPath('c:/a/b', '/x/y') PureWindowsPath('c:/x/y') >>> pathlib.PureWindowsPath('//?/c:/a/b', '/x/y') PureWindowsPath('/x/y') >>> pathlib.PureWindowsPath(r'\\?\c:\a\b', '/x/y') PureWindowsPath('//?/c:/x/y') I suppose this is because in parse_parts() altsep is replaced with sep before calling self.splitroot() in main loop but not in other loop (if drv or root). Line 76. ---------- components: Library (Lib) messages: 233308 nosy: pitrou, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Incosistency in pathlib between / and \ type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 11:31:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 02 Jan 2015 10:31:19 +0000 Subject: [issue23147] Possible error in _header_value_parser.py Message-ID: <1420194679.08.0.467668822135.issue23147@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: In UnstructuredTokenList._fold() at line 439 the fold() method is called with one positional argument. if part.has_fws: part.fold(folded) continue But there are no fold() methods with one positional parameter. May be it should be _fold()? ---------- components: Library (Lib), email messages: 233309 nosy: barry, r.david.murray, serhiy.storchaka priority: normal severity: normal status: open title: Possible error in _header_value_parser.py type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 11:38:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 02 Jan 2015 10:38:19 +0000 Subject: [issue23148] Missing the charset parameter in as_encoded_word() Message-ID: <1420195099.17.0.393236049779.issue23148@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: In Lib/email/_header_value_parser.py:460 the as_encoded_word() method is called without mandatory argument charset. ---------- components: Library (Lib), email messages: 233310 nosy: barry, r.david.murray, serhiy.storchaka priority: normal severity: normal status: open title: Missing the charset parameter in as_encoded_word() type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 12:35:13 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 02 Jan 2015 11:35:13 +0000 Subject: [issue22560] Add loop-agnostic SSL implementation to asyncio In-Reply-To: <1412548102.84.0.685230620276.issue22560@psf.upfronthosting.co.za> Message-ID: <1420198513.54.0.571495650162.issue22560@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Antoine, can you please elaborate the rationale of your patch? The patch adds SSL support for proactor-based event loops (any event loop supporting plain sockets, actually, so it could also work for libuv etc.). > Is the "legacy" code only used on Python 3.4 and older? Is ssl.MemoryBIO always present in Python 3.5 and newer? Yes and yes. > I would like to see benchmarks of memory BIO vs current code on Linux and Windows. Do you have such benchmarks? > Maybe we may only use memory BIO for the proactor event loop? It sounds better to exercise the same code path under all platforms. > Did you try your patch on Python 3.3? No. > How will this patch help to support STARTTLS? Guido explained this one :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 13:02:17 2015 From: report at bugs.python.org (Jonathan Sharpe) Date: Fri, 02 Jan 2015 12:02:17 +0000 Subject: [issue23149] Typo in PEP-0008 - "this PEP do not" Message-ID: <1420200137.59.0.98373116964.issue23149@psf.upfronthosting.co.za> Changes by Jonathan Sharpe : ---------- assignee: docs at python components: Documentation files: fix_pep8_typo.patch keywords: patch nosy: docs at python, jonrsharpe priority: normal severity: normal status: open title: Typo in PEP-0008 - "this PEP do not" type: enhancement Added file: http://bugs.python.org/file37585/fix_pep8_typo.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 15:13:47 2015 From: report at bugs.python.org (Julian Reschke) Date: Fri, 02 Jan 2015 14:13:47 +0000 Subject: [issue23150] urllib parse incorrect handing of params Message-ID: <1420208027.4.0.951710161178.issue23150@psf.upfronthosting.co.za> New submission from Julian Reschke: urllib.parse tries to special-case params, which have been dropped from the general URI syntax back in RFC 2396 (16 years ago). In most cases this can be worked around by reconstructing the path from both path and params; however this fails for paths that *end* in a semicolon (because it's not possible to distinguish an empty param from an absent param). ---------- components: Library (Lib) messages: 233312 nosy: julian.reschke at gmx.de priority: normal severity: normal status: open title: urllib parse incorrect handing of params type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 16:03:14 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 02 Jan 2015 15:03:14 +0000 Subject: [issue23149] Typo in PEP-0008 - "this PEP do not" Message-ID: <1420210994.46.0.116579483759.issue23149@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 17:04:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 02 Jan 2015 16:04:33 +0000 Subject: [issue23151] _loggerClass is initialized twice Message-ID: <1420214673.16.0.25178792027.issue23151@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: In Lib/logging/__init__.py at line 1089 _loggerClass is initialized to None. The code in Manager.getLogger() expects that it can be None. But at line 1549 _loggerClass is initialized to Logger. And there is no official way to set it to None. Looks as either initialization to None and the code in Manager.getLogger() are redundant or initialization to Logger is redundant. ---------- components: Library (Lib) messages: 233313 nosy: serhiy.storchaka, vinay.sajip priority: normal severity: normal status: open title: _loggerClass is initialized twice _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 17:12:43 2015 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=) Date: Fri, 02 Jan 2015 16:12:43 +0000 Subject: [issue23058] argparse silently ignores arguments In-Reply-To: <1418677327.73.0.355612765077.issue23058@psf.upfronthosting.co.za> Message-ID: <1420215163.93.0.12015128278.issue23058@psf.upfronthosting.co.za> R?mi Rampin added the comment: I might use your workaround in ReproZip (https://github.com/ViDA-NYU/reprozip/issues/89), thanks. I agree that it doesn't look pretty... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 17:46:06 2015 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 02 Jan 2015 16:46:06 +0000 Subject: [issue23151] _loggerClass is initialized twice In-Reply-To: <1420214673.16.0.25178792027.issue23151@psf.upfronthosting.co.za> Message-ID: <1420217166.6.0.633227797492.issue23151@psf.upfronthosting.co.za> Vinay Sajip added the comment: The code in Manager.getLogger() allows an overriding logger class for that manager instance only - if it's not set (which is the default), it uses the module global _loggerClass. The lines rv = (self.loggerClass or _loggerClass)(name) indicate this. The module global _loggerClass is initialized to None initially, simply so that it can be defined before being used in Manager (so really, for readability). Later, after Logger is defined, _loggerClass is set to Logger. Is this causing some actual problem? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 17:47:01 2015 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 02 Jan 2015 16:47:01 +0000 Subject: [issue23010] "unclosed file" warning when defining unused logging FileHandler in dictConfig In-Reply-To: <1418046415.01.0.116582999558.issue23010@psf.upfronthosting.co.za> Message-ID: <1420217221.42.0.946762837086.issue23010@psf.upfronthosting.co.za> Vinay Sajip added the comment: Sorry I've not had much time to look at this yet. I haven't forgotten. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 19:02:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 02 Jan 2015 18:02:49 +0000 Subject: [issue23151] _loggerClass is initialized twice In-Reply-To: <1420214673.16.0.25178792027.issue23151@psf.upfronthosting.co.za> Message-ID: <1420221769.33.0.956118203038.issue23151@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Is this causing some actual problem? No, this does not cause actual problem except that it looks confusing. So really this decreased readability to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 19:10:04 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 02 Jan 2015 18:10:04 +0000 Subject: [issue23149] Typo in PEP-0008 - "this PEP do not" Message-ID: <20150102180950.125886.93409@psf.io> New submission from Roundup Robot: New changeset 0c72bd524aed by Benjamin Peterson in branch 'default': conjugate 'do' correctly (closes #23149) https://hg.python.org/peps/rev/0c72bd524aed ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 19:49:54 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Jan 2015 18:49:54 +0000 Subject: [issue4431] Distutils MSVC doesn't create manifest file In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za> Message-ID: <1420224594.3.0.582094731222.issue4431@psf.upfronthosting.co.za> Steve Dower added the comment: It shouldn't be necessary for VS 2010 and later, and the `extra_link_args=['/MANIFEST']` workaround should be sufficient for cases where it is necessary (specific dependencies other than MSVCRT that require manifests). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 19:58:45 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Jan 2015 18:58:45 +0000 Subject: [issue4431] Distutils MSVC doesn't create manifest file In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za> Message-ID: <1420225125.1.0.861917010959.issue4431@psf.upfronthosting.co.za> Steve Dower added the comment: And I suspect Matthew Brett's issue is that link_executable() does not expect an extension ('.exe') to be provided. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 19:59:26 2015 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 02 Jan 2015 18:59:26 +0000 Subject: [issue23151] _loggerClass is initialized twice In-Reply-To: <1420214673.16.0.25178792027.issue23151@psf.upfronthosting.co.za> Message-ID: <1420225166.97.0.14518620578.issue23151@psf.upfronthosting.co.za> Vinay Sajip added the comment: Okay, I'll see if I can make it clearer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 20:15:49 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Jan 2015 19:15:49 +0000 Subject: [issue19143] Finding the Windows version getting messier (detect windows 8.1?) In-Reply-To: <1380675004.25.0.239416620624.issue19143@psf.upfronthosting.co.za> Message-ID: <1420226149.94.0.999460839745.issue19143@psf.upfronthosting.co.za> Steve Dower added the comment: Thanks for the feedback. Updated the attachment with some other tidying too. ---------- Added file: http://bugs.python.org/file37586/win32_ver.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 20:16:01 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Jan 2015 19:16:01 +0000 Subject: [issue19143] Finding the Windows version getting messier (detect windows 8.1?) In-Reply-To: <1380675004.25.0.239416620624.issue19143@psf.upfronthosting.co.za> Message-ID: <1420226161.08.0.905191028128.issue19143@psf.upfronthosting.co.za> Changes by Steve Dower : Removed file: http://bugs.python.org/file37578/win32_ver.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 20:47:53 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 02 Jan 2015 19:47:53 +0000 Subject: [issue23136] BUG in how _strptime() handles week 0 In-Reply-To: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za> Message-ID: <1420228073.5.0.902774683039.issue23136@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Note that round-trip also fails in weeks 52-53. For example, >>> datetime.strptime('2014 53 6', '%Y %W %w') datetime.datetime(2015, 1, 10, 0, 0) >>> datetime.strptime('2014 53 6', '%Y %W %w').strftime('%Y %W %w') '2015 01 6' If we decide to make "2015 0 0" invalid for format '%Y %W %w', we should probably invalidate the entire week 53 in 2014 for consistency. However, I don't think there are any C implementations that would have a problem with such dates. Overall, I am inclined to accept Jim's solution for 3.5, but I am not sure about the maintenance branches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 20:49:43 2015 From: report at bugs.python.org (eryksun) Date: Fri, 02 Jan 2015 19:49:43 +0000 Subject: [issue19143] Finding the Windows version getting messier (detect windows 8.1?) In-Reply-To: <1380675004.25.0.239416620624.issue19143@psf.upfronthosting.co.za> Message-ID: <1420228183.72.0.539142789996.issue19143@psf.upfronthosting.co.za> eryksun added the comment: > if (not version.GetFileVersionInfoW(name, None, size, ver_block) or > not ver_block): Arrays don't implement __bool__ and have fixed __len__, so ver_block is always True. You could look at ver_block[0] or ver_block.value (i.e. the C string value). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 21:08:03 2015 From: report at bugs.python.org (Stephen Hansen) Date: Fri, 02 Jan 2015 20:08:03 +0000 Subject: [issue4431] Distutils MSVC doesn't create manifest file In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za> Message-ID: <1420229283.76.0.129890829789.issue4431@psf.upfronthosting.co.za> Stephen Hansen added the comment: Just to be clear, I ran into this exact issue recently in VS2010 professional as I indicated earlier. I don't know about what should or should not be needed, but the solution in the original comment fixed it exactly for me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 21:16:39 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 02 Jan 2015 20:16:39 +0000 Subject: [issue22128] patch: steer people away from codecs.open In-Reply-To: <1407071838.74.0.684483503953.issue22128@psf.upfronthosting.co.za> Message-ID: <1420229799.56.0.7376746779.issue22128@psf.upfronthosting.co.za> Martin Panter added the comment: Just pointing out there is a patch for Issue 19548 for Python 3 which also adds a pointer to the builtin open() function and updates the codecs.open() caveats. That issue doesn?t touch Python 2 though. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 21:17:20 2015 From: report at bugs.python.org (Robert Collins) Date: Fri, 02 Jan 2015 20:17:20 +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: <1420229840.61.0.238711134592.issue12681@psf.upfronthosting.co.za> Changes by Robert Collins : ---------- nosy: +rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 21:23:52 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Jan 2015 20:23:52 +0000 Subject: [issue23152] fstat64 required on Windows Message-ID: <1420230232.09.0.10127303351.issue23152@psf.upfronthosting.co.za> New submission from Steve Dower: Currently test_largefile is failing on the Windows buildbots because an fstat() call in Modules/_io/fileio.c is failing. fstat() returns a 32-bit size, but the file being opened is larger than 2GB. This appears to be a change in the CRT where it would previously succeed with an incorrect value but now returns an error. (While we're here, there is no exception set in this case, so you get "SystemError: NULL result without error in PyObject_Call", but that's not the core issue.) I can fix this instance, but I suspect we may need to fix this in multiple places. fstat64 (or _fstat64) seems to exist on multiple platforms, and the docs I found (e.g. http://linux.die.net/man/2/fstat64) suggest that EOVERFLOW is always going to occur in this case, so is there any reason not to switch to fstat64 everywhere? Maybe enable it through pyport.h/pyconfig.h and have a #define that is set based on availability? ---------- components: IO messages: 233327 nosy: benjamin.peterson, hynek, pitrou, steve.dower, stutzbach, tim.golden, zach.ware priority: normal severity: normal status: open title: fstat64 required on Windows versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 22:50:40 2015 From: report at bugs.python.org (Jim Carroll) Date: Fri, 02 Jan 2015 21:50:40 +0000 Subject: [issue23136] BUG in how _strptime() handles week 0 In-Reply-To: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za> Message-ID: <1420235440.95.0.114935833954.issue23136@psf.upfronthosting.co.za> Jim Carroll added the comment: All the proposed patches are acceptable from my point of view, but it would be really great if we could get the fix in the 2.x line. It seems unlikely there could be any legacy code that would depend on the bug to exist (ie: to only be wrong when then date requested is exactly two days before the first date of the new year). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 22:51:44 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 02 Jan 2015 21:51:44 +0000 Subject: [issue23127] socket.setsockopt() is still broken for multicast TTL and Loop options In-Reply-To: <1419859867.69.0.91970081595.issue23127@psf.upfronthosting.co.za> Message-ID: <1420235504.89.0.180752526211.issue23127@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Application code should pass the correct length of value. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 2 23:13:42 2015 From: report at bugs.python.org (John Potelle) Date: Fri, 02 Jan 2015 22:13:42 +0000 Subject: [issue23153] Clarify Boolean Clause Results Message-ID: <1420236822.81.0.553151868836.issue23153@psf.upfronthosting.co.za> New submission from John Potelle: >From v3.4 Tutorial section 5.7 It is possible to assign the result of a comparison or other Boolean expression to a variable. For example, >>> string1, string2, string3 = '', 'Trondheim', 'Hammer Dance' >>> string1 or string2 or string3 'Trondheim' >>> bool(string1 or string2 or string3) True In most languages a Boolean clause (comparison) returns a Boolean or it's equivalent, not the last argument evaluated. Please add a reference to bool function (or some better? method) in this section for clarification. ---------- assignee: docs at python components: Documentation messages: 233330 nosy: docs at python, jpotelle priority: normal severity: normal status: open title: Clarify Boolean Clause Results type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 00:23:03 2015 From: report at bugs.python.org (Matthew Brett) Date: Fri, 02 Jan 2015 23:23:03 +0000 Subject: [issue4431] Distutils MSVC doesn't create manifest file In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za> Message-ID: <1420240983.89.0.96892117772.issue4431@psf.upfronthosting.co.za> Matthew Brett added the comment: Steve - did you try my 'setup.py' example; it's standalone, as in `python setup.py build` will reproduce the error. This is specifically VS 2010. It doesn't make any difference for me if I specify an extension or not, so I don't think that is the problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 00:23:08 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 02 Jan 2015 23:23:08 +0000 Subject: [issue22231] httplib: unicode url will cause an ascii codec error when combined with a utf-8 string header In-Reply-To: <1408502977.94.0.555848371144.issue22231@psf.upfronthosting.co.za> Message-ID: <1420240988.93.0.105941351132.issue22231@psf.upfronthosting.co.za> Demian Brecht added the comment: A few notes: 1. Unicode hosts are not automatically IDNA-encoded (which they /could/ be rather than relying on the programmer to be aware of this), but this really has no bearing on this specific issue 2. Unicode paths are not automatically IRI-encoded (see https://tools.ietf.org/html/rfc3987#section-3), which should also likely be automatically handled when unicode objects are encountered as the path 3. When a single unicode element is contained within a list, string_join will defer to PyUnicode_Join. The problem here is that your pre-joined request elements looks like this: [u'POST http://bugs.python.org/any_url HTTP/1.1', 'Host: bugs.python.org', 'Accept-Encoding: identity', 'Content-Length: 44', 'notes: \xe5\x91\xb5\xe5\x91\xb5', 'Content-type: application/x-www-form-urlencoded', 'Accept: text/plain', '', ''] Because there's a unicode object contained in the list at index 0, the entire list is converted to unicode, which results in the error when \xe5 is encountered by the ascii decoder. The proposed solution won't work as unicode characters are legal (see RFC 3987) and will fail should anything outside of the ascii character set be present. I think that the correct way to solve this issue is to automatically encode unicode paths (or IRIs) using urllib.quote, passing the reserved characters defined in RFC 3987 as the safe parameter: >>> urllib.quote(u'/foo/?/bar'.encode('utf-8'),':/?#[]@!$&\'()*+,;=') '/foo/%E5%91%B5/bar' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 01:02:33 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Sat, 03 Jan 2015 00:02:33 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <1420230232.09.0.10127303351.issue23152@psf.upfronthosting.co.za> Message-ID: <1420243353.01.0.824556147003.issue23152@psf.upfronthosting.co.za> Josh Rosenberg added the comment: I believe explicitly calling the 64 bit version of a function is usually frowned upon. At least on *NIX systems, the standard solution is to define -D_FILE_OFFSET_BITS=64 during the build process, so off_t seamlessly becomes a 64 bit value, and the 64 bit version of appropriate functions is called and linked (fstat64, mmap64, etc.). ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 01:12:33 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Sat, 03 Jan 2015 00:12:33 +0000 Subject: [issue23153] Clarify Boolean Clause Results In-Reply-To: <1420236822.81.0.553151868836.issue23153@psf.upfronthosting.co.za> Message-ID: <1420243953.55.0.0422394423509.issue23153@psf.upfronthosting.co.za> Josh Rosenberg added the comment: A few questions/comments: 1. How would the reference clarify matters? 2. "Most languages" is perhaps overstating the matter. Lower level languages and strictly typed languages tend to return a boolean value, but many high level scripting languages (among them Perl, Python and JavaScript) return the last value evaluated. 3. Referencing the bool() constructor doesn't seem like it would add much, and might encourage the wrong behaviors; idiomatic Python rarely bothers to coerce to True/False because it's unnecessary extra work when an if or while condition can simply evaluate the "truthiness" of the value being tested without coercion. I kind of like the fact that it omits use of bool(), because down that road lies madness (if bool(a or b) == False: madness). ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 01:15:33 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Sat, 03 Jan 2015 00:15:33 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <1420230232.09.0.10127303351.issue23152@psf.upfronthosting.co.za> Message-ID: <1420244133.14.0.038099504716.issue23152@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Ugh. Looking into it further, POSIX systems tend to support _FILE_OFFSET_BITS=64, but Windows isn't POSIX-y enough. So Windows might need to be special cased regardless. Blech. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 01:27:44 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 03 Jan 2015 00:27:44 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <1420230232.09.0.10127303351.issue23152@psf.upfronthosting.co.za> Message-ID: <1420244864.04.0.510816570039.issue23152@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Josh is right, we would only need to use fstat64() under Windows here. fstat() under POSIX defines st_size as a off_t, which should usually be large enough even on modern 32-bit systems. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 01:49:23 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 03 Jan 2015 00:49:23 +0000 Subject: [issue4431] Distutils MSVC doesn't create manifest file In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za> Message-ID: <1420246163.67.0.732778589756.issue4431@psf.upfronthosting.co.za> Steve Dower added the comment: Sorry, I was focused on the fact that you don't need a manifest with VS 2010 and not that distutils was forcing you to have one when building an executable. Either adding '/MANIFEST' as in paxan's patch (according to http://msdn.microsoft.com/en-us/library/fft52235.aspx, you need to specify it if you specify '/MANIFESTNAME') or removing the MANIFESTNAME specification entirely should be fine for 3.4 and later. I assume since nobody has complained about 2.7 that everything works fine there? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 02:00:53 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 03 Jan 2015 01:00:53 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <1420230232.09.0.10127303351.issue23152@psf.upfronthosting.co.za> Message-ID: <1420246853.31.0.489376928486.issue23152@psf.upfronthosting.co.za> Steve Dower added the comment: Okay, I'll try and find a way to redefine it only under Windows. Unfortunately, the CRT defines fstat() as a function, which makes it hard to redefine without eagerly including sys/stat.h. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 02:01:37 2015 From: report at bugs.python.org (Matthew Brett) Date: Sat, 03 Jan 2015 01:01:37 +0000 Subject: [issue4431] Distutils MSVC doesn't create manifest file In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za> Message-ID: <1420246897.3.0.476685936668.issue4431@psf.upfronthosting.co.za> Matthew Brett added the comment: I think the argument previously was that VS 2010 was not the default compiler for Python 2.7, and so this problem was not important, but I'm happy to be corrected. I haven't tried building extensions for Python 2.7 with VS 2010 but I guess the problem will be the same. Can you see a problem with adding the /MANIFEST flag to distutils/msvc9compiler.py as a fix for this problem? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 02:33:53 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 03 Jan 2015 01:33:53 +0000 Subject: [issue4431] Distutils MSVC doesn't create manifest file In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za> Message-ID: <1420248833.33.0.0162197700304.issue4431@psf.upfronthosting.co.za> Steve Dower added the comment: /MANIFEST is probably assumed on VC9 since the CRT required it, but that was probably changed for VC10 without updating the documentation fully. Frankly I'd rather remove the MANIFESTFILE property added by distutils, since it doesn't add anything of value (on my test machine, it only requests an execution level of asInvoker, which is the default). That way people can include useful manifests with their source if necessary and provide both the /MANIFEST and /MANIFESTFILE flags themselves, and we reduce the amount of code in the stdlib. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 02:51:29 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 03 Jan 2015 01:51:29 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <1420230232.09.0.10127303351.issue23152@psf.upfronthosting.co.za> Message-ID: <1420249889.81.0.232218210125.issue23152@psf.upfronthosting.co.za> Steve Dower added the comment: Looks like the easiest fix here is to remove the HAVE_SYS_STAT_H definition and replace it with the include directly: /* Define to 1 if you have the header file. */ /* #define HAVE_SYS_STAT_H 1 */ #ifndef MS_WINCE /* Rather than define HAVE_SYS_STAT_H, we include it now and rename two of the functions. The rename must be after the header is included. */ #include #define fstat _fstati64 #define stat _stati64 #endif Does anyone know whether this sort of thing will cause problems with the build? It seems fine to me, but someone with more experience may know better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 04:22:01 2015 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 03 Jan 2015 03:22:01 +0000 Subject: [issue23150] urllib parse incorrect handing of params In-Reply-To: <1420208027.4.0.951710161178.issue23150@psf.upfronthosting.co.za> Message-ID: <1420255321.57.0.518713927039.issue23150@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Hello Julian, Can you please provide a test case of this parsing misbehavior? It might be easier to identify with the testcase. Better yet, the patch changing the parsing logic will help identify if we are dealing with any regression. Thanks! ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 04:41:51 2015 From: report at bugs.python.org (Vincent Davis) Date: Sat, 03 Jan 2015 03:41:51 +0000 Subject: [issue15933] flaky test in test_datetime In-Reply-To: <1347466816.36.0.945599436453.issue15933@psf.upfronthosting.co.za> Message-ID: <1420256511.43.0.836049774453.issue15933@psf.upfronthosting.co.za> Vincent Davis added the comment: Rather than dealing with the time delta how about getting the time twice and checking that we are between and at least once we have the same day. i.e. ts1 = time() today = self.theclass.today() ts2 = time() todayagain1 = self.theclass.fromtimestamp(ts1) todayagain2 = self.theclass.fromtimestamp(ts2) #This would then cover all the cases could separate these cases, I dontsee the need for a loop. self.assertTrue(today == todayagain1 or today == todayagain2 or todayagain1 <= today <= todayagain1) ---------- nosy: +Vincentdavis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 04:52:24 2015 From: report at bugs.python.org (Vincent Davis) Date: Sat, 03 Jan 2015 03:52:24 +0000 Subject: [issue20544] Use specific asserts in operator tests In-Reply-To: <1391804710.79.0.27308793582.issue20544@psf.upfronthosting.co.za> Message-ID: <1420257144.8.0.18608542306.issue20544@psf.upfronthosting.co.za> Vincent Davis added the comment: Looks like this is ready to be applied and closed or just closed. ---------- nosy: +Vincentdavis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 05:07:36 2015 From: report at bugs.python.org (Ethan Furman) Date: Sat, 03 Jan 2015 04:07:36 +0000 Subject: [issue23153] Clarify Boolean Clause Results In-Reply-To: <1420236822.81.0.553151868836.issue23153@psf.upfronthosting.co.za> Message-ID: <1420258056.66.0.462246641987.issue23153@psf.upfronthosting.co.za> Ethan Furman added the comment: `or` does not return the last item evaluated -- it returns the first truthy item, or, if no truthy items, the last false item: --> 0 or {} {} --> 0 or 1 or {} 1 ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 05:16:42 2015 From: report at bugs.python.org (Vincent Davis) Date: Sat, 03 Jan 2015 04:16:42 +0000 Subject: [issue18983] Specify time unit for timeit CLI In-Reply-To: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za> Message-ID: <1420258602.96.0.629734369741.issue18983@psf.upfronthosting.co.za> Vincent Davis added the comment: Anything else need to be done on this patch? ---------- nosy: +Vincentdavis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 05:26:39 2015 From: report at bugs.python.org (Glenn Linderman) Date: Sat, 03 Jan 2015 04:26:39 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1420259199.57.0.515401374648.issue1602@psf.upfronthosting.co.za> Glenn Linderman added the comment: Just to note that another side effect of this bug is that stepping through code where the source contains non-ASCII characters results in pdb producing an error when trying to print the source lines. This makes stepping through such source code impossible. I mention it, because it hasn't been mentioned before, and debuggers are mysterious and low-level enough, that solutions that might work for normal code, may not solve working with the debugger... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 05:35:20 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 03 Jan 2015 04:35:20 +0000 Subject: [issue18983] Specify time unit for timeit CLI In-Reply-To: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za> Message-ID: <1420259720.68.0.117458666295.issue18983@psf.upfronthosting.co.za> Berker Peksag added the comment: I've added a couple of comments on Rietveld. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 05:37:50 2015 From: report at bugs.python.org (Vincent Davis) Date: Sat, 03 Jan 2015 04:37:50 +0000 Subject: [issue21360] mailbox.Maildir should ignore files named with a leading dot In-Reply-To: <1398550003.67.0.360972625113.issue21360@psf.upfronthosting.co.za> Message-ID: <1420259870.21.0.887138496473.issue21360@psf.upfronthosting.co.za> Changes by Vincent Davis : ---------- nosy: +Vincentdavis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 09:46:54 2015 From: report at bugs.python.org (Julian Reschke) Date: Sat, 03 Jan 2015 08:46:54 +0000 Subject: [issue23150] urllib parse incorrect handing of params In-Reply-To: <1420208027.4.0.951710161178.issue23150@psf.upfronthosting.co.za> Message-ID: <1420274814.25.0.540856975235.issue23150@psf.upfronthosting.co.za> Julian Reschke added the comment: An example URI for this issue is: http://example.com/; The RFC 3986 path component for this URI is "/;". After using urllib's parse function, how would you know? (I realize that changing behavior of the existing API may cause problems, but this is an information loss issue). One ugly, but workable way to fix this would be to also provide access to a "RFC3986path" component. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 11:27:07 2015 From: report at bugs.python.org (Drekin) Date: Sat, 03 Jan 2015 10:27:07 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1420280827.59.0.984207453651.issue1602@psf.upfronthosting.co.za> Drekin added the comment: I tried the following code: import pdb pdb.set_trace() print(1 + 2) print("????") When run in vanilla Python it indeed ends with UnicodeEncodeError as soon as it hits the line with non-ASCII characters. However, the solution via win_unicode_console package seems to work correctly. There is just an issue when you keep calling 'next' even after the main program ended. It ends with a RuntimeError after a few iterations. I didn't know that pdb can continue debugging after the main program has ended. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 11:51:01 2015 From: report at bugs.python.org (Donald Stufft) Date: Sat, 03 Jan 2015 10:51:01 +0000 Subject: [issue23121] pip.exe breaks if python 2.7.9 is installed under c:\Program Files\Python In-Reply-To: <1419693013.55.0.898507304072.issue23121@psf.upfronthosting.co.za> Message-ID: <1420282261.24.0.354084994832.issue23121@psf.upfronthosting.co.za> Donald Stufft added the comment: I do not know what setuptools plans on with regards to distlib sorry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 12:00:26 2015 From: report at bugs.python.org (Donald Stufft) Date: Sat, 03 Jan 2015 11:00:26 +0000 Subject: [issue22256] pyvenv should display a progress indicator while creating an environment In-Reply-To: <1408785121.12.0.569760630469.issue22256@psf.upfronthosting.co.za> Message-ID: <1420282826.26.0.530842482345.issue22256@psf.upfronthosting.co.za> Donald Stufft added the comment: I just noticed this issue. I think all that really needs done here is changing the venv module to use subprocess.check_call instead of subprocess.check_output when calling ensurepip. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 12:19:08 2015 From: report at bugs.python.org (Walter Doekes) Date: Sat, 03 Jan 2015 11:19:08 +0000 Subject: [issue23010] "unclosed file" warning when defining unused logging FileHandler in dictConfig In-Reply-To: <1418046415.01.0.116582999558.issue23010@psf.upfronthosting.co.za> Message-ID: <1420283948.31.0.951421147385.issue23010@psf.upfronthosting.co.za> Walter Doekes added the comment: No worries. I know how it is ;) Thanks for the update. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 13:18:03 2015 From: report at bugs.python.org (Carol Willing) Date: Sat, 03 Jan 2015 12:18:03 +0000 Subject: [issue23116] Python Tutorial 4.7.1: Improve ask_ok() to cover more input values In-Reply-To: <1419622934.77.0.489991713093.issue23116@psf.upfronthosting.co.za> Message-ID: <1420287483.43.0.0264400480741.issue23116@psf.upfronthosting.co.za> Carol Willing added the comment: @amylou Thank you for submitting this documentation suggestion about the Python Tutorial. This tutorial section, 4.7.1 Default Argument Values, tries to show that a function can have multiple input arguments which may be given default values. While the suggestion to use lower() does offer more robust input handling, it also adds some complexity to the example by introducing another function to a possibly new user. I do believe that the 'ask_ok' function could be improved by renaming the 'complaint' argument to something more positive, perhaps 'reminder'. I would also recommend replacing the error message 'uncooperative user' to something with a softer tone, perhaps 'invalid user response'. @amyluo If you are interested in working on documentation, section 6 of the Developer Guide is a handy resource (https://docs.python.org/devguide/docquality.html). ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, willingc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 13:28:23 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 03 Jan 2015 12:28:23 +0000 Subject: [issue23154] MSVC 2013 Express needlessly rebuilds code Message-ID: <1420288103.47.0.693564742808.issue23154@psf.upfronthosting.co.za> New submission from Mark Lawrence: I've suspected that this is the case for some time but I've confirmed it this morning. I ran synchronize and the highest revision was 94004 "Changes %s to %ls in wprintf in launcher.c for C99 compatibility." As expected MSVC rebuilt the launcher. Later I reran synchronize and the highest revision was 94009 "Update bundled pip and setuptools to 6.0.6 and 11.0.". The output from the 64 bit Release build concluded "31 succeeded, 0 failed, 5 up-to-date, 1 skipped". There also seems to be a toggle operating between the Release and Debug builds such that only one rebuilds at any one time. ---------- components: Build, Windows messages: 233355 nosy: BreamoreBoy, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: MSVC 2013 Express needlessly rebuilds code versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 14:19:57 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 03 Jan 2015 13:19:57 +0000 Subject: [issue23153] Clarify Boolean Clause Results In-Reply-To: <1420236822.81.0.553151868836.issue23153@psf.upfronthosting.co.za> Message-ID: <1420291197.67.0.537629996368.issue23153@psf.upfronthosting.co.za> R. David Murray added the comment: Indeed, the short circuit and value return behavior is described in that section just before the example. I agree with Joel. This is a tutorial, and part of the zen of Python is that all expressions have a boolean value. There are very few places in python programs where it would be considered Pythonic to "cast" a value to one of the two uniquely boolean values via the Bool operator, so it is better that it *not* be mentioned in this context. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 15:36:43 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 03 Jan 2015 14:36:43 +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: <1420295803.33.0.979646337667.issue14302@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: +steve.dower, zach.ware versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 15:40:53 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 03 Jan 2015 14:40:53 +0000 Subject: [issue17202] Add .bat line to .hgeol In-Reply-To: <1360824086.93.0.558513852083.issue17202@psf.upfronthosting.co.za> Message-ID: <1420296053.57.0.700252247595.issue17202@psf.upfronthosting.co.za> Mark Lawrence added the comment: No objections so proceeding is in order here I take it? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 15:47:09 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 03 Jan 2015 14:47:09 +0000 Subject: [issue11240] Running unit tests in a command line tool leads to infinite loop with multiprocessing on Windows In-Reply-To: <1297987020.73.0.563526251198.issue11240@psf.upfronthosting.co.za> Message-ID: <1420296429.41.0.970652823577.issue11240@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 15:50:14 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 03 Jan 2015 14:50:14 +0000 Subject: [issue20983] Python 3.4 'repair' Windows installation does not install pip & setuptools packages In-Reply-To: <1395248368.62.0.321132661018.issue20983@psf.upfronthosting.co.za> Message-ID: <1420296614.38.0.723426808674.issue20983@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: +steve.dower, tim.golden, zach.ware versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 16:05:35 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 03 Jan 2015 15:05:35 +0000 Subject: [issue23154] MSVC 2013 Express needlessly rebuilds code In-Reply-To: <1420288103.47.0.693564742808.issue23154@psf.upfronthosting.co.za> Message-ID: <1420297535.59.0.367178624343.issue23154@psf.upfronthosting.co.za> Steve Dower added the comment: This is because the hg id result has changed and we embed that into python35.dll. You'll see the same thing after an edit too (when the revision has + added). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 17:00:38 2015 From: report at bugs.python.org (John Potelle) Date: Sat, 03 Jan 2015 16:00:38 +0000 Subject: [issue23153] Clarify Boolean Clause Results In-Reply-To: <1420236822.81.0.553151868836.issue23153@psf.upfronthosting.co.za> Message-ID: <1420300838.61.0.821864153413.issue23153@psf.upfronthosting.co.za> John Potelle added the comment: I'm learning Python and informing you this is confusing - and you close the ticket without hearing any response to your questions? Re: Josh 1. To show how to return a Boolean result from a Boolean clause. If there's a better way, I'm all for it. 2. "Most" is a generalization. Perhaps "Many" is a better term? All traditional 3GLs and some other scripting languages don't; e.g. REXX and Beanshell return Boolean. But it's not important here. 3. As I said, "or some better method". I've been programming 30 years but am only now learning Python. All I asking for is better clarification in the tutorial. If this were a wiki I would add one myself. Re: Ethan; quote from the line above, same section in the Tutorial: "When used as a general value and not as a Boolean, the return value of a short-circuit operator is the last evaluated argument." If this isn't correct, please fix it. And this whole sentence is a bit weird to me - Boolean operators are *always* used in a Boolean context - unless the op is overloaded with some other functionality. Why would it return anything else? (well let's not go there...) Re: R.David Sorry I didn't see any input from "Joel". But, yes, this is a tutorial. I argue that using A = (B or C or D) construct is not good, intuitive programming style, anyway. To me this looks like A should hold a Boolean, even only from a pseduocode standpoint. Even so, one wouldn't need to "cast" a Boolean if a Boolean was returned, as old programmers like me would expect. But, OK, so don't use bool() - but what you said is basically what I'm looking for IN the tutorial - eduction about why a Boolean should NOT be expected. Or how to achieve a Boolean, since it's a valid data type since version 2.3. This is a tutorial, after all. For example, the full documentation for v3.4 section 4.1: "Operations and built-in functions that have a Boolean result always return 0 or False for false and 1 or True for true, unless otherwise stated. (Important exception: the Boolean operations or and and always return one of their operands.)". Even here the docs says this is an "exception". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 17:12:34 2015 From: report at bugs.python.org (Zachary Ware) Date: Sat, 03 Jan 2015 16:12:34 +0000 Subject: [issue23154] MSVC 2013 Express needlessly rebuilds code In-Reply-To: <1420288103.47.0.693564742808.issue23154@psf.upfronthosting.co.za> Message-ID: <1420301554.96.0.0315151030282.issue23154@psf.upfronthosting.co.za> Zachary Ware added the comment: To clarify a bit, there's very little re-compiling, but everything that references the pythoncore project (every extension) is re-linked. There's no way around that short of not including the hg revision (which I won't accept :), but the re-linking only takes a fraction of a second per project. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 17:19:09 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 03 Jan 2015 16:19:09 +0000 Subject: [issue23154] MSVC 2013 Express needlessly rebuilds code In-Reply-To: <1420288103.47.0.693564742808.issue23154@psf.upfronthosting.co.za> Message-ID: <1420301949.41.0.168426361361.issue23154@psf.upfronthosting.co.za> Mark Lawrence added the comment: Then we're not talking about the same thing. Maybe my setup is wrong, but a load of files were recompiled (from memory I think from sections 3 and 4 of the Release build) so it took minutes rather than fractions of a second. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 18:01:53 2015 From: report at bugs.python.org (Zachary Ware) Date: Sat, 03 Jan 2015 17:01:53 +0000 Subject: [issue23154] MSVC 2013 Express needlessly rebuilds code In-Reply-To: <1420301949.41.0.168426361361.issue23154@psf.upfronthosting.co.za> Message-ID: Zachary Ware added the comment: Hmmm, what are sections 3 and 4? Are you building from the VS GUI or Command Prompt? >From Command Prompt in a clean checkout, running PCbuild\build.bat -d -e (debug build) should take several minutes. The same again should be quick, and then just "PCbuild\build.bat" (release build) should take a while, and the same again should be quick. If you then do another debug build (add "-d" back), it will take a bit of time due to rebuilding (or at least re-"installing") Tcl/Tk. Otherwise, things should be pretty quick. I haven't tested any of that this morning, though; how far off is that from your experience, Mark? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 18:10:31 2015 From: report at bugs.python.org (Jeremy Kloth) Date: Sat, 03 Jan 2015 17:10:31 +0000 Subject: [issue23154] MSVC 2013 Express needlessly rebuilds code In-Reply-To: <1420288103.47.0.693564742808.issue23154@psf.upfronthosting.co.za> Message-ID: <1420305031.87.0.667578578899.issue23154@psf.upfronthosting.co.za> Changes by Jeremy Kloth : ---------- nosy: +jkloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 19:57:26 2015 From: report at bugs.python.org (Ethan Furman) Date: Sat, 03 Jan 2015 18:57:26 +0000 Subject: [issue23153] Clarify Boolean Clause Results In-Reply-To: <1420236822.81.0.553151868836.issue23153@psf.upfronthosting.co.za> Message-ID: <1420311446.08.0.903743829548.issue23153@psf.upfronthosting.co.za> Ethan Furman added the comment: Apologies, my wording was poor -- the last item evaluated is the one returned, but all items may not be evaluated. As soon as the answer is known Python stops evaluating any remaining items. So in the example: --> string1, string2, string3 = '', 'Trondheim', 'Hammer Dance' --> string1 or string2 or string3 'Trondheim' string2 is returned because it satifies the `or` conditions, and string3 is not evaluated. Re: John I appreciate you have many years of programming experience, but there are going to be differences between what is good practice in those languages and what is good practice in Python. IMO, the big three differences are: - white space indentation - everything is an object (variables, functions, classes, instances, any piece of data...) - everything has a truthy of falsey value -- e.g. --> string1, string2, string3 = '', 'Trondheim', 'Hammer Dance' --> if string2: ... print('string2 has a value! It is %s' % string2) ... 'string2 has a value! It is Trondheim' notice there is no `if bool(string2)` or `if string2 == False` (which would be False). As far as finding that bit of the tutorial confusing, there is no way to have a single document that is crystal clear to everyone who reads it. This section is correct, as is section 4.1 -- `or` is being used, so the operand is returned, not True or False. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 19:58:37 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 03 Jan 2015 18:58:37 +0000 Subject: [issue23154] MSVC 2013 Express needlessly rebuilds code In-Reply-To: <1420288103.47.0.693564742808.issue23154@psf.upfronthosting.co.za> Message-ID: <1420311517.58.0.382695185275.issue23154@psf.upfronthosting.co.za> Mark Lawrence added the comment: I build from the GUI. I've just tried the Release build, it very quickly rebuilt the first four items and said the rest were up to date. I switched to Debug and got the output in the attached file. This is what I meant earlier by the effect toggling between the two builds. I tried what you suggested from the command line. I'll attach the end of the output from the final run of the debug build in a moment as I can't see how to put it in in one pass here. ---------- Added file: http://bugs.python.org/file37587/MSVCEdebugbuildoutput.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 19:59:58 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 03 Jan 2015 18:59:58 +0000 Subject: [issue23154] MSVC 2013 Express needlessly rebuilds code In-Reply-To: <1420288103.47.0.693564742808.issue23154@psf.upfronthosting.co.za> Message-ID: <1420311598.68.0.512711257037.issue23154@psf.upfronthosting.co.za> Changes by Mark Lawrence : Added file: http://bugs.python.org/file37588/CMDdebugbuildoutput.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 20:38:03 2015 From: report at bugs.python.org (Thomas Klausner) Date: Sat, 03 Jan 2015 19:38:03 +0000 Subject: [issue23155] unittest: object has no attribute '_removed_tests' Message-ID: <1420313883.47.0.122520965169.issue23155@psf.upfronthosting.co.za> New submission from Thomas Klausner: On NetBSD with python-3.4.2 I see the following issue when running the tests for py-flake8-2.2.5: running build_ext test_get_parser (flake8.tests.test_engine.TestEngine) ... ok test_get_python_version (flake8.tests.test_engine.TestEngine) ... ok test_get_style_guide (flake8.tests.test_engine.TestEngine) ... ok test_get_style_guide_kwargs (flake8.tests.test_engine.TestEngine) ... ok test_register_extensions (flake8.tests.test_engine.TestEngine) ... ok test_stdin_disables_jobs (flake8.tests.test_engine.TestEngine) ... ok test_windows_disables_jobs (flake8.tests.test_engine.TestEngine) ... ok Traceback (most recent call last): File "setup.py", line 74, in test_suite='nose.collector', File "/usr/pkg/lib/python3.4/distutils/core.py", line 148, in setup dist.run_commands() File "/usr/pkg/lib/python3.4/distutils/dist.py", line 955, in run_commands self.run_command(cmd) File "/usr/pkg/lib/python3.4/distutils/dist.py", line 974, in run_command cmd_obj.run() File "/usr/pkg/lib/python3.4/site-packages/setuptools/command/test.py", line 142, in run self.with_project_on_sys_path(self.run_tests) File "/usr/pkg/lib/python3.4/site-packages/setuptools/command/test.py", line 122, in with_project_on_sys_path func() File "/usr/pkg/lib/python3.4/site-packages/setuptools/command/test.py", line 163, in run_tests testRunner=self._resolve_as_ep(self.test_runner), File "/usr/pkg/lib/python3.4/unittest/main.py", line 93, in __init__ self.runTests() File "/usr/pkg/lib/python3.4/unittest/main.py", line 244, in runTests self.result = testRunner.run(self.test) File "/usr/pkg/lib/python3.4/unittest/runner.py", line 168, in run test(result) File "/usr/pkg/lib/python3.4/unittest/suite.py", line 87, in __call__ return self.run(*args, **kwds) File "/usr/pkg/lib/python3.4/unittest/suite.py", line 130, in run self._removeTestAtIndex(index) File "/usr/pkg/lib/python3.4/unittest/suite.py", line 83, in _removeTestAtIndex self._removed_tests += test.countTestCases() File "/usr/pkg/lib/python3.4/unittest/suite.py", line 41, in countTestCases cases = self._removed_tests AttributeError: 'FinalizingSuiteWrapper' object has no attribute '_removed_tests' *** Error code 1 I have reported this https://gitlab.com/pycqa/flake8/issues/19#note_712215 and Ian Cordasco said this looks like a bug in the unittest module, not py-flake8. ---------- components: Extension Modules messages: 233365 nosy: wiz priority: normal severity: normal status: open title: unittest: object has no attribute '_removed_tests' type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 21:48:25 2015 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 03 Jan 2015 20:48:25 +0000 Subject: [issue23150] urllib parse incorrect handing of params In-Reply-To: <1420274814.25.0.540856975235.issue23150@psf.upfronthosting.co.za> Message-ID: Senthil Kumaran added the comment: On Saturday, January 3, 2015 at 12:46 AM, Julian Reschke wrote: > An example URI for this issue is: > > http://example.com/; > > The RFC 3986 path component for this URI is "/;". I think, a stronger argument might be desirable (something like a real world scenario wherein a web app can construct such an entity) for a path that ends in a semi-colon for breaking backwards compatibility. OTOH, making it RFC 3986 compliant itself is a good enough argument, but it should be applied in total and the whole module should be made compatible instead of pieces of it. There is a bug to track it. You can mention this instance for the desired behavior in that ticket too (and close this ticket if this desired behavior is a subset). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 22:30:51 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 03 Jan 2015 21:30:51 +0000 Subject: [issue21337] Add tests for Tix In-Reply-To: <1398286008.45.0.411979424173.issue21337@psf.upfronthosting.co.za> Message-ID: <1420320651.98.0.42693464261.issue21337@psf.upfronthosting.co.za> Terry J. Reedy added the comment: A minimal test would be that the one in the doc. from tkinter import tix root = tix.Tk() root.tk.eval('package require Tix') This passes on my 3.4.2 win7. I believe the first line should work on any system with _tkinter, whereas https://stackoverflow.com/questions/27751923/tix-widgets-installation-issue reports failure of the second line on his Mac with ... self.tk.eval('package require Tix') _tkinter.TclError: can't find package Tix ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 22:55:24 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 03 Jan 2015 21:55:24 +0000 Subject: [issue23156] Update tix install information in tkinter tix chapter of doc Message-ID: <1420322124.69.0.0233808198239.issue23156@psf.upfronthosting.co.za> New submission from Terry J. Reedy: Update tix install info in doc. "Using tix" starts with 3 lines for testing one's tix install and continues '''If this fails, you have a Tk installation problem which must be resolved before proceeding. Use the environment variable TIX_LIBRARY to point to the installed Tix library directory, and make sure you have the dynamic object library (tix8183.dll or libtix8183.so) in the same directory that contains your Tk dynamic object library (tk8183.dll or libtk8183.so). The directory with the dynamic object library should also have a file called pkgIndex.tcl (case sensitive), which contains the line: package ifneeded Tix 8.1 [list load "[file join $dir tix8183.dll]" Tix]''' Almost nothing above matches my working-with-tix 3.4.2 Win 7 install. I do have a tix library directory: python34/tcl/tix8.4.3, but the version number is much newer. Since it is in the right place, TIX_LIBRARY is not needed and there is none. python34/DLLs contains tcl86t.dll and tk86t.dll and NO tix####.dll. Is the once separate tix dll now part of tk dll? I cannot find pkgIndex.tcl; it is certainly not in the DLLs directory nor in the /tcl. The current doc seems useless to people who do not have tix working. See, for example, https://stackoverflow.com/questions/27751923/tix-widgets-installation-issue which is a semi-repeat question and which claims seeing similar reports elsewhere on the net. ---------- assignee: docs at python components: Documentation, Tkinter messages: 233368 nosy: docs at python, serhiy.storchaka, terry.reedy, zach.ware priority: normal severity: normal stage: needs patch status: open title: Update tix install information in tkinter tix chapter of doc type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 22:56:27 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 03 Jan 2015 21:56:27 +0000 Subject: [issue23156] Update tix install information in tkinter tix chapter of doc In-Reply-To: <1420322124.69.0.0233808198239.issue23156@psf.upfronthosting.co.za> Message-ID: <1420322187.89.0.626877223444.issue23156@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Added Zach for Window build info, Ned for OSX info. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 22:57:06 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 03 Jan 2015 21:57:06 +0000 Subject: [issue23143] Remove some conditional code in _ssl.c In-Reply-To: <1420113339.19.0.823124921107.issue23143@psf.upfronthosting.co.za> Message-ID: <1420322226.19.0.724445564842.issue23143@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 23:11:54 2015 From: report at bugs.python.org (Donald Stufft) Date: Sat, 03 Jan 2015 22:11:54 +0000 Subject: [issue23143] Remove some conditional code in _ssl.c In-Reply-To: <1420113339.19.0.823124921107.issue23143@psf.upfronthosting.co.za> Message-ID: <1420323114.86.0.00882282453989.issue23143@psf.upfronthosting.co.za> Donald Stufft added the comment: +1, This sounds completely reasonable to do to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 23:17:31 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 03 Jan 2015 22:17:31 +0000 Subject: [issue23143] Remove some conditional code in _ssl.c In-Reply-To: <1420113339.19.0.823124921107.issue23143@psf.upfronthosting.co.za> Message-ID: <20150103221729.72569.30634@psf.io> Roundup Robot added the comment: New changeset e9f05a4a5f16 by Antoine Pitrou in branch 'default': Issue #23143: Remove compatibility with OpenSSLs older than 0.9.8. https://hg.python.org/cpython/rev/e9f05a4a5f16 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 23:21:28 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 03 Jan 2015 22:21:28 +0000 Subject: [issue23143] Remove some conditional code in _ssl.c In-Reply-To: <1420113339.19.0.823124921107.issue23143@psf.upfronthosting.co.za> Message-ID: <20150103222126.11591.23579@psf.io> Roundup Robot added the comment: New changeset 37c6fd09f71f by Antoine Pitrou in branch 'default': Issue #23143: Remove compatibility with OpenSSLs older than 0.9.8. https://hg.python.org/cpython/rev/37c6fd09f71f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 23:22:24 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 03 Jan 2015 22:22:24 +0000 Subject: [issue23153] Clarify Boolean Clause Results In-Reply-To: <1420236822.81.0.553151868836.issue23153@psf.upfronthosting.co.za> Message-ID: <1420323744.12.0.455007651074.issue23153@psf.upfronthosting.co.za> R. David Murray added the comment: I mistyped 'josh' as 'joel', sorry. Ethan covers it pretty well, but I'll add a few things. Boolean operators are indeed not always used in a boolean context. There is a long tradition in Python of using them to return values via the short-circuit mechanism. Python is not the only language that does this. That said, there are disadvantages to that use of boolean operators, and eventually the trinary expression 'x if y else z' was introduced, and is now the preferred way to compute such values. The tutorial has not been updated to reflect that, and that is something that could be done, but probably requires a significant rewrite...someone on irc pointed out that the passage we are discussing is the first introduction of 'or' in the tutorial). However, the short-circuit-and-value-returning behavior of the boolean operators will not change, since it is a long standing part of the language. Your suggestion that this whole thing be discussed more is a valid point, but the question is, is this point in the tutorial the place to do it? Again, a more extensive rewrite is probably needed in order to make a real improvement (a project that is being discussed, whose status I don't know). Finally, the 4.1 text you quote is noting and/or as an exception is talking about the built-in functions and operators. and and or are important exceptions both because their default is different from other logical operations and because, unlike the other python operators, a type cannot override them. Thus they always return a value, whereas other *logical* operations will return a boolean *unless otherwise documented* in the documentation for the type. (I'm not sure there are any exceptions to that in the sdtlib, but there are, for example, in numpy.) Now, that all said, the tutorial section explicitly mentions the behavior of and and or, so I don't see how their being exceptional in this regard is an issue with the tutorial text. If you assigned another logical expression to a variable, you'd get True or False, but in Python's philosophy that's just a special case of the fact that all values in python have a truth value, as discussed by Ethan. So, in summary, I hear you that as an experienced programmer this tutorial section did not give you all the information you wanted. However, it is a *tutorial*, and so it *can't* (and be a readable *tutorial*) cover all the issues. Perhaps it could cover more if it were rewritten, but I don't think changing this section in any of the ways suggested so far would, as it is currently organized, be an improvement. If anyone wants to take another stab at it, though, we'll definitely evaluate it. willingc on IRC suggested adding links to other parts of the docs, for further reading, and that might be worthwhile if someone wants to take a look at making a suggestion in that regard. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 23:26:02 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 03 Jan 2015 22:26:02 +0000 Subject: [issue23143] Remove some conditional code in _ssl.c In-Reply-To: <1420113339.19.0.823124921107.issue23143@psf.upfronthosting.co.za> Message-ID: <1420323962.08.0.474539318997.issue23143@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks! Now done. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 3 23:29:08 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 03 Jan 2015 22:29:08 +0000 Subject: [issue23157] Lib/test/time_hashlib.py doesn't work Message-ID: <1420324148.28.0.0179005395687.issue23157@psf.upfronthosting.co.za> New submission from Antoine Pitrou: I suppose it was totally forgotten in the transition to 3.x, and nobody appears to have complained. Perhaps we should remove it. ---------- components: Demos and Tools, Library (Lib) messages: 233375 nosy: christian.heimes, gregory.p.smith, pitrou priority: low severity: normal status: open title: Lib/test/time_hashlib.py doesn't work type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 00:42:07 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 03 Jan 2015 23:42:07 +0000 Subject: [issue1284316] Win32: Security problem with default installation directory Message-ID: <1420328527.82.0.817425227389.issue1284316@psf.upfronthosting.co.za> Steve Dower added the comment: I'll reassign this to me, as I'm looking into making Program Files the default location for 3.5. I'd like to release at least some of the alphas with the change active by default (i.e. it's easy to select the old directory) to get broader feedback. So far I haven't encountered any trouble other than in pip (as is being discussed at https://github.com/pypa/pip/issues/1668). If things don't work well in the early releases of 3.5 we can easily revert the change, though I suspect the main feedback is going to be about the amount of typing required. In that case, I'll look into hardening the permissions on the root directory as part of installation. Unless some really bad scenarios arise, getting the legacy permissions will be opt-in. As 3.5 will be the first version with that change there shouldn't be any direct back-compat issues - we can't make a change like that in maintenance releases or even 3.4. ---------- assignee: loewis -> steve.dower versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 00:42:55 2015 From: report at bugs.python.org (Zachary Ware) Date: Sat, 03 Jan 2015 23:42:55 +0000 Subject: [issue23154] MSVC 2013 Express needlessly rebuilds code In-Reply-To: <1420288103.47.0.693564742808.issue23154@psf.upfronthosting.co.za> Message-ID: <1420328575.81.0.489250505596.issue23154@psf.upfronthosting.co.za> Zachary Ware added the comment: On testing, you are correct, Mark. Sorry for the premature close. How does this patch look to you, Steve? ---------- assignee: -> zach.ware keywords: +patch resolution: not a bug -> stage: resolved -> status: closed -> open type: -> behavior Added file: http://bugs.python.org/file37589/issue23154.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 01:17:49 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 04 Jan 2015 00:17:49 +0000 Subject: [issue20898] Missing 507 response description In-Reply-To: <1394637244.26.0.361164120424.issue20898@psf.upfronthosting.co.za> Message-ID: <1420330669.2.0.33752276203.issue20898@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 01:23:20 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 04 Jan 2015 00:23:20 +0000 Subject: [issue23154] MSVC 2013 Express needlessly rebuilds code In-Reply-To: <1420288103.47.0.693564742808.issue23154@psf.upfronthosting.co.za> Message-ID: <1420331000.32.0.540496131458.issue23154@psf.upfronthosting.co.za> Steve Dower added the comment: Ah, I forgot to put Configuration in there. That patch is fine. If it's only the OpenSSL projects doing this, that shouldn't cause 31 projects to rebuild (4 at most I'd have though), but it probably will cause more rebuilds than necessary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 02:00:44 2015 From: report at bugs.python.org (Al Sweigart) Date: Sun, 04 Jan 2015 01:00:44 +0000 Subject: [issue23158] IDLE's help.txt "corrent" typo Message-ID: <1420333244.7.0.623275484679.issue23158@psf.upfronthosting.co.za> New submission from Al Sweigart: There is a typo in IDLE's help.txt file: "into the corrent number of spaces" ---------- messages: 233379 nosy: Al.Sweigart priority: normal severity: normal status: open title: IDLE's help.txt "corrent" typo type: behavior versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 02:03:20 2015 From: report at bugs.python.org (Al Sweigart) Date: Sun, 04 Jan 2015 01:03:20 +0000 Subject: [issue23158] IDLE's help.txt "corrent" typo In-Reply-To: <1420333244.7.0.623275484679.issue23158@psf.upfronthosting.co.za> Message-ID: <1420333400.46.0.26549179116.issue23158@psf.upfronthosting.co.za> Al Sweigart added the comment: I've attached a simple typo fix for this issue. ---------- keywords: +patch Added file: http://bugs.python.org/file37590/patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 02:04:11 2015 From: report at bugs.python.org (Zachary Ware) Date: Sun, 04 Jan 2015 01:04:11 +0000 Subject: [issue23154] MSVC 2013 Express needlessly rebuilds code In-Reply-To: <1420331000.32.0.540496131458.issue23154@psf.upfronthosting.co.za> Message-ID: Zachary Ware added the comment: Our original explanation accounts for the 31 projects "rebuilding". I'll get the patch committed later tonight (hopefully). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 02:10:04 2015 From: report at bugs.python.org (John Potelle) Date: Sun, 04 Jan 2015 01:10:04 +0000 Subject: [issue23153] Clarify Boolean Clause Results In-Reply-To: <1420236822.81.0.553151868836.issue23153@psf.upfronthosting.co.za> Message-ID: <1420333804.36.0.330934551241.issue23153@psf.upfronthosting.co.za> John Potelle added the comment: Thank you for your reasoned responses. I'm beginning to see just how much Python is its own animal. This and/or thing has history; I get it. Links back to the reference documentation is a good idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 02:15:13 2015 From: report at bugs.python.org (Al Sweigart) Date: Sun, 04 Jan 2015 01:15:13 +0000 Subject: [issue23158] IDLE's help.txt "corrent" typo In-Reply-To: <1420333244.7.0.623275484679.issue23158@psf.upfronthosting.co.za> Message-ID: <1420334113.56.0.829136838926.issue23158@psf.upfronthosting.co.za> Changes by Al Sweigart : ---------- components: +IDLE _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 03:17:21 2015 From: report at bugs.python.org (Al Sweigart) Date: Sun, 04 Jan 2015 02:17:21 +0000 Subject: [issue17583] IDLE HOWTO In-Reply-To: <1364685156.29.0.769214841654.issue17583@psf.upfronthosting.co.za> Message-ID: <1420337841.15.0.0474967651197.issue17583@psf.upfronthosting.co.za> Changes by Al Sweigart : ---------- nosy: +Al.Sweigart _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 03:29:37 2015 From: report at bugs.python.org (Al Sweigart) Date: Sun, 04 Jan 2015 02:29:37 +0000 Subject: [issue14944] Setup & Usage documentation for pydoc, idle & 2to3 In-Reply-To: <1338256058.02.0.10025521772.issue14944@psf.upfronthosting.co.za> Message-ID: <1420338577.08.0.466289299472.issue14944@psf.upfronthosting.co.za> Changes by Al Sweigart : ---------- nosy: +Al.Sweigart _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 03:39:12 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 04 Jan 2015 02:39:12 +0000 Subject: [issue23132] Faster total_ordering In-Reply-To: <1419931329.13.0.970719266671.issue23132@psf.upfronthosting.co.za> Message-ID: <1420339152.83.0.524143236265.issue23132@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks Serhiy. I really like this clean-up. When there is an exception in the user's root comparison operation, the traceback is more intelligible now. If you're interested, here are two additional optimizations: _op_or_eq = ''' op_result = self.%s(other) # Since bool(NotImplemented) is true, the usual special case test isn't needed here return op_result or self == other ''' # setting NotImplemented as a local constant saves one or two global lookups per call exec('def %s(self, other, NotImplemented=NotImplemented):%s' % (opname, opfunc % root), namespace) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 03:44:14 2015 From: report at bugs.python.org (Al Sweigart) Date: Sun, 04 Jan 2015 02:44:14 +0000 Subject: [issue22628] Idle: Tree lines are spaced too close together. In-Reply-To: <1413256178.66.0.725794954703.issue22628@psf.upfronthosting.co.za> Message-ID: <1420339454.52.0.272728782035.issue22628@psf.upfronthosting.co.za> Changes by Al Sweigart : ---------- nosy: +Al.Sweigart _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 04:06:05 2015 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Sun, 04 Jan 2015 03:06:05 +0000 Subject: [issue22956] Improved support for prepared SQL statements In-Reply-To: <1417095519.92.0.197896622793.issue22956@psf.upfronthosting.co.za> Message-ID: <1420340765.9.0.198406504025.issue22956@psf.upfronthosting.co.za> Gerhard H?ring added the comment: The low-hanging fruit of executemany() reusing the prepared statement is of course taken. Also, there is a statement cache that is being used transparently. I am against exposing the statement directly via the API. ---------- assignee: -> ghaering nosy: +ghaering priority: normal -> low resolution: -> rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 04:12:20 2015 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Sun, 04 Jan 2015 03:12:20 +0000 Subject: [issue21718] sqlite3 cursor.description seems to rely on incomplete statement parsing for detection In-Reply-To: <1402492269.75.0.610341668437.issue21718@psf.upfronthosting.co.za> Message-ID: <1420341140.52.0.427744209313.issue21718@psf.upfronthosting.co.za> Gerhard H?ring added the comment: I have now committed a fix in the pysqlite project at github. https://github.com/ghaering/pysqlite/commit/f67fa9c898a4713850e16934046f0fe2cba8c44c I'll eventually merge it into the Python tree. ---------- assignee: -> ghaering nosy: +ghaering _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 04:16:01 2015 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Sun, 04 Jan 2015 03:16:01 +0000 Subject: [issue22382] sqlite3 connection built from apsw connection should raise IntegrityError, not DatabaseError In-Reply-To: <1410373815.55.0.143596528672.issue22382@psf.upfronthosting.co.za> Message-ID: <1420341361.06.0.292491976875.issue22382@psf.upfronthosting.co.za> Gerhard H?ring added the comment: Reusing the apsw connection in the sqlite3 module was deprecated a long time ago. It is simply not supported, even if there is still code left in the module that supports this somewhat. This code should then be removed. This closing as wontfix. ---------- assignee: -> ghaering resolution: third party -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 04:24:17 2015 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Sun, 04 Jan 2015 03:24:17 +0000 Subject: [issue14076] sqlite3 module ignores placeholders in CREATE TRIGGER code In-Reply-To: <1329853172.58.0.728674289337.issue14076@psf.upfronthosting.co.za> Message-ID: <1420341857.94.0.623726251441.issue14076@psf.upfronthosting.co.za> Gerhard H?ring added the comment: The sqlite3 module is not at fault here. If it does not work, then is is a restriction of SQLite3 - at which places it accepts bind parameters. This closing as "not a bug". ---------- assignee: -> ghaering resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 05:33:29 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 Jan 2015 04:33:29 +0000 Subject: [issue23154] MSVC 2013 Express needlessly rebuilds code In-Reply-To: <1420288103.47.0.693564742808.issue23154@psf.upfronthosting.co.za> Message-ID: <20150104043326.8755.42816@psf.io> Roundup Robot added the comment: New changeset d53506fe31e1 by Zachary Ware in branch 'default': Closes #23154: Fix unnecessary recompilation of OpenSSL on Windows https://hg.python.org/cpython/rev/d53506fe31e1 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 06:39:22 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 04 Jan 2015 05:39:22 +0000 Subject: [issue23132] Faster total_ordering In-Reply-To: <1419931329.13.0.970719266671.issue23132@psf.upfronthosting.co.za> Message-ID: <1420349962.55.0.779286745139.issue23132@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- Removed message: http://bugs.python.org/msg233383 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 06:49:32 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 04 Jan 2015 05:49:32 +0000 Subject: [issue23132] Faster total_ordering In-Reply-To: <1419931329.13.0.970719266671.issue23132@psf.upfronthosting.co.za> Message-ID: <1420350572.36.0.110042886835.issue23132@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Serhiy, this is a really nice idea. By removing the additional layer of indirection, the code is more intelligible, runs faster, and the tracebacks make more sense when the user's root comparison raises an exception. Since there are only twelve functions involved, I don't think the function templates give us much of a payoff. Instead, it would be better to just precompute the 12 functions rather than have 5 templates. I've attached a patch relative to Python 3.4. Ideally, I would like this backported to 3.4 to fix the regression in performance and intelligibility. One further possible change is to localize the NotImplemented global variable. This will reduce the overhead of NotImplemented checking to almost nothing and almost completely restore the performance of earlier versions. ---------- Added file: http://bugs.python.org/file37591/total_ordering.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 06:49:47 2015 From: report at bugs.python.org (Bob Chen) Date: Sun, 04 Jan 2015 05:49:47 +0000 Subject: [issue22231] httplib: unicode url will cause an ascii codec error when combined with a utf-8 string header In-Reply-To: <1408502977.94.0.555848371144.issue22231@psf.upfronthosting.co.za> Message-ID: <1420350587.63.0.273764432765.issue22231@psf.upfronthosting.co.za> Bob Chen added the comment: Is there any possibility that we encapsulate urllib.quote into httplib? Because many developers wouldn't know about this utility function. And as I mentioned above, they could have got an unicode url from anywhere inside python, like an API call, without being noticed that it is potentially wrong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 07:00:46 2015 From: report at bugs.python.org (Bob Chen) Date: Sun, 04 Jan 2015 06:00:46 +0000 Subject: [issue22231] httplib: unicode url will cause an ascii codec error when combined with a utf-8 string header In-Reply-To: <1408502977.94.0.555848371144.issue22231@psf.upfronthosting.co.za> Message-ID: <1420351246.57.0.468506516297.issue22231@psf.upfronthosting.co.za> Changes by Bob Chen <175818323 at qq.com>: Removed file: http://bugs.python.org/file36492/httplib.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 07:17:04 2015 From: report at bugs.python.org (Bob Chen) Date: Sun, 04 Jan 2015 06:17:04 +0000 Subject: [issue22231] httplib: unicode url will cause an ascii codec error when combined with a utf-8 string header In-Reply-To: <1408502977.94.0.555848371144.issue22231@psf.upfronthosting.co.za> Message-ID: <1420352224.21.0.400544833237.issue22231@psf.upfronthosting.co.za> Changes by Bob Chen <175818323 at qq.com>: Added file: http://bugs.python.org/file37592/httplib.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 07:18:26 2015 From: report at bugs.python.org (Bob Chen) Date: Sun, 04 Jan 2015 06:18:26 +0000 Subject: [issue22231] httplib: unicode url will cause an ascii codec error when combined with a utf-8 string header In-Reply-To: <1408502977.94.0.555848371144.issue22231@psf.upfronthosting.co.za> Message-ID: <1420352306.1.0.324273043124.issue22231@psf.upfronthosting.co.za> Bob Chen added the comment: How about this patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 07:20:58 2015 From: report at bugs.python.org (Markus Elfring) Date: Sun, 04 Jan 2015 06:20:58 +0000 Subject: [issue22956] Improved support for prepared SQL statements In-Reply-To: <1417095519.92.0.197896622793.issue22956@psf.upfronthosting.co.za> Message-ID: <1420352458.64.0.897921393059.issue22956@psf.upfronthosting.co.za> Markus Elfring added the comment: Are you really against benefits from reusing of existing application programming interfaces for the explicit preparation and compilation of SQL statements? It seems that other software contributors like Marc-Andre Lemburg and Tony Locke show more constructive opinions. https://mail.python.org/pipermail/db-sig/2014-December/006133.html https://www.mail-archive.com/db-sig at python.org/msg01829.html http://article.gmane.org/gmane.comp.python.db/3784 ---------- resolution: rejected -> later _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 07:46:17 2015 From: report at bugs.python.org (Demian Brecht) Date: Sun, 04 Jan 2015 06:46:17 +0000 Subject: [issue22231] httplib: unicode url will cause an ascii codec error when combined with a utf-8 string header In-Reply-To: <1408502977.94.0.555848371144.issue22231@psf.upfronthosting.co.za> Message-ID: <1420353977.24.0.884116163904.issue22231@psf.upfronthosting.co.za> Demian Brecht added the comment: utf-8 encoding is only one step in IRI encoding. Correct IRI encoding is non trivial and doesn't fall into the support policy for 2.7 (bug/security fixes). I think that the best that can be done for 2.7 is to enhance the documentation around HTTPConnection.__init__ (unicode hostnames should be IDNA-encoded with the built-in IDNA encoder) and HTTPConnection.request/putrequest noting that unicode paths should be IRI encoded, with a link to RFC 3987. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 08:07:44 2015 From: report at bugs.python.org (Eric McDonald) Date: Sun, 04 Jan 2015 07:07:44 +0000 Subject: [issue23159] argparse: Provide equivalent of optparse.OptionParser.{option_groups, option_list, get_option} Message-ID: <1420355263.97.0.969710352141.issue23159@psf.upfronthosting.co.za> New submission from Eric McDonald: There are several use cases for having the equivalent of the optparse.OptionParser 'get_option' method and the 'option_groups' and 'option_list' properties in argparse.ArgumentParser class. (1) Easy alteration of the text of the default help option. With optparse, one could write: >>> oparser.get_option( "-h" ).help 'show this help message and exit' >>> oparser.get_option( "-h" ).help = "Show this help message and exit." >>> oparser.get_option( "-h" ).help 'Show this help message and exit.' The equivalent facility does not appear to exist in argparse. (Issue #19462, http://bugs.python.org/issue19462, is about a different use case. And, while https://docs.python.org/3/library/argparse.html#add-help suggests a workaround with add_help=False and then creating a new option with the 'help' action, it is still less convenient than altering the existing help option.) (2) Inspection of all the argument declarations in an ArgumentParser object after it has been populated. This is particularly useful if you want to look for the equivalent of the available options in config files and don't want to have write explicit code which separately enumerates the available config file keys and how to handle them. With an OptionParser, one could use the 'option_groups' attribute to find all option groups (to correspond to config file sections) and the 'option_list' attribute to find all options (to correspond to config file keys); these are all part of the published interface and provide relatively simple data types to inspect. With an Argument Parser, one needs to rely upon the unpublished interface (the '_actions' attribute of a parser, etc...). ---------- components: Library (Lib) messages: 233394 nosy: emcd priority: normal severity: normal status: open title: argparse: Provide equivalent of optparse.OptionParser.{option_groups,option_list,get_option} type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 08:35:09 2015 From: report at bugs.python.org (Anselm Kruis) Date: Sun, 04 Jan 2015 07:35:09 +0000 Subject: [issue23160] Respect the environment variable SVNROOT in external-common.bat Message-ID: <1420356909.91.0.987880987929.issue23160@psf.upfronthosting.co.za> New submission from Anselm Kruis: Issue #21907 introduced the environment variable SVNROOT in PCbuild/get_externals.bat. I propose to use the same variable in Tools/buildbot/external-common.bat too. This batch contains many verbatim copies of the SVN-URL. With the provided patch, it would become much simpler to use a (local) mirror of svn.python.org. ---------- components: Build messages: 233395 nosy: anselm.kruis priority: normal severity: normal status: open title: Respect the environment variable SVNROOT in external-common.bat type: enhancement versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 08:40:09 2015 From: report at bugs.python.org (Anselm Kruis) Date: Sun, 04 Jan 2015 07:40:09 +0000 Subject: [issue23160] Respect the environment variable SVNROOT in external-common.bat In-Reply-To: <1420356909.91.0.987880987929.issue23160@psf.upfronthosting.co.za> Message-ID: <1420357209.81.0.148953262524.issue23160@psf.upfronthosting.co.za> Anselm Kruis added the comment: Patch for 3.4 ---------- keywords: +patch Added file: http://bugs.python.org/file37593/issue23160-3.4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 08:42:32 2015 From: report at bugs.python.org (Anselm Kruis) Date: Sun, 04 Jan 2015 07:42:32 +0000 Subject: [issue23160] Respect the environment variable SVNROOT in external-common.bat In-Reply-To: <1420356909.91.0.987880987929.issue23160@psf.upfronthosting.co.za> Message-ID: <1420357352.69.0.465335413981.issue23160@psf.upfronthosting.co.za> Anselm Kruis added the comment: Patch for 2.7 ---------- nosy: +zach.ware Added file: http://bugs.python.org/file37594/issue23160-2.7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 08:57:16 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Sun, 04 Jan 2015 07:57:16 +0000 Subject: [issue23161] collections.abc.MutableSet missing methods Message-ID: <1420358236.89.0.629550370238.issue23161@psf.upfronthosting.co.za> New submission from Devin Jeanpierre: >>> set(dir(set)) - set(dir(collections.abc.MutableSet)) {'copy', 'update', '__rsub__', 'union', 'issubset', 'intersection', 'issuperset', '__rxor__', 'difference', 'symmetric_difference', 'difference_update', '__rand__', 'intersection_update', 'symmetric_difference_update', '__ror__'} Most of these should be implemented on MutableSet rather than subclasses. ---------- messages: 233398 nosy: Devin Jeanpierre priority: normal severity: normal status: open title: collections.abc.MutableSet missing methods versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 08:57:47 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Sun, 04 Jan 2015 07:57:47 +0000 Subject: [issue23161] collections.abc.MutableSet missing methods In-Reply-To: <1420358236.89.0.629550370238.issue23161@psf.upfronthosting.co.za> Message-ID: <1420358267.11.0.214648769344.issue23161@psf.upfronthosting.co.za> Changes by Devin Jeanpierre : ---------- components: +Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 09:05:06 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Sun, 04 Jan 2015 08:05:06 +0000 Subject: [issue23162] collections.abc sequences don't check identity before equality Message-ID: <1420358706.85.0.46487014677.issue23162@psf.upfronthosting.co.za> New submission from Devin Jeanpierre: For sequence __contains__ and other scenarios, identity is checked before equality, which I've heard is so that "for x in y: assert x in y" doesn't ever fail with an AssertionError (even with NaN and so on). This is not the case for collections.abc-based sequences, which is a jarring inconsistency. ---------- components: Library (Lib) messages: 233399 nosy: Devin Jeanpierre priority: normal severity: normal status: open title: collections.abc sequences don't check identity before equality versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 09:06:32 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 04 Jan 2015 08:06:32 +0000 Subject: [issue22256] pyvenv should display a progress indicator while creating an environment In-Reply-To: <1408785121.12.0.569760630469.issue22256@psf.upfronthosting.co.za> Message-ID: <1420358791.99.0.216694414898.issue22256@psf.upfronthosting.co.za> Nick Coghlan added the comment: I have a vague recollection of originally using check_call, and then switching to check_output. However, that may have just been for testing related reasons, which could be better handled in the test suite, allowing users to see the pip installation output as a progress indicator. If we add the extra output, adding a -q/--quiet option at the same time would be a good idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 09:37:38 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 Jan 2015 08:37:38 +0000 Subject: [issue23157] Lib/test/time_hashlib.py doesn't work In-Reply-To: <1420324148.28.0.0179005395687.issue23157@psf.upfronthosting.co.za> Message-ID: <20150104083711.72569.2669@psf.io> Roundup Robot added the comment: New changeset badb7e319ed0 by Gregory P. Smith in branch '3.4': fix issue23157 - time_hashlib hadn't been ported to Python 3. https://hg.python.org/cpython/rev/badb7e319ed0 New changeset b96985753613 by Gregory P. Smith in branch 'default': fix issue23157 - time_hashlib hadn't been ported to Python 3. https://hg.python.org/cpython/rev/b96985753613 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 09:38:30 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 04 Jan 2015 08:38:30 +0000 Subject: [issue23157] Lib/test/time_hashlib.py doesn't work In-Reply-To: <1420324148.28.0.0179005395687.issue23157@psf.upfronthosting.co.za> Message-ID: <1420360710.18.0.208029236555.issue23157@psf.upfronthosting.co.za> Gregory P. Smith added the comment: removing it would also be fine, it's not like it gets used anymore. the fixes were trivial. done. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 09:58:33 2015 From: report at bugs.python.org (Mayank Tripathi) Date: Sun, 04 Jan 2015 08:58:33 +0000 Subject: [issue19777] Provide a home() classmethod on Path objects In-Reply-To: <1385409863.35.0.0114355564026.issue19777@psf.upfronthosting.co.za> Message-ID: <1420361913.03.0.539941581963.issue19777@psf.upfronthosting.co.za> Mayank Tripathi added the comment: Added docs to mcsalgado's patch. ---------- nosy: +oquanox Added file: http://bugs.python.org/file37595/home.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 10:20:25 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 04 Jan 2015 09:20:25 +0000 Subject: [issue23132] Faster total_ordering In-Reply-To: <1419931329.13.0.970719266671.issue23132@psf.upfronthosting.co.za> Message-ID: <1420363225.41.0.277654433241.issue23132@psf.upfronthosting.co.za> Nick Coghlan added the comment: While I like the readability of Raymond's version, I think the main pay-off we're getting from the template based version is that each decorator invocation is creating *new* function objects. That creation of new function objects is what allows Serhiy's patch to set __module__ and __qualname__ for each method implementation based on the class being defined. The two approaches could be combined by moving the explicit definitions into factory functions that always created new function objects and set their introspection attributes appropriately. For example (untested code): def _fix_introspection(module, cls_qualname): def update_metadata(f): f.__qualname__ = "%s.%s" % (cls_qualname, f.__name__) f.__module__ = module return f return update_metadata def _derive_from_lt(module, cls_qualname): _NotImplemented = NotImplemented @_fix_introspection(module, cls_qualname) def __gt__(self, other): op_result = self.__lt__(other) if op_result is _NotImplemented: return _NotImplemented return not op_result and self != other @_fix_introspection(module, cls_qualname) def __le__(self, other): op_result = self.__lt__(other) return op_result or self == other @_fix_introspection(module, cls_qualname) def __ge__(self, other): op_result = self.__lt__(other) if op_result is _NotImplemented: return _NotImplemented return not op_result return __lt__, __gt__, __ge__ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 10:29:41 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 04 Jan 2015 09:29:41 +0000 Subject: [issue23156] Update tix install information in tkinter tix chapter of doc In-Reply-To: <1420322124.69.0.0233808198239.issue23156@psf.upfronthosting.co.za> Message-ID: <1420363781.47.0.584716304868.issue23156@psf.upfronthosting.co.za> Ned Deily added the comment: I'm no expert on Tk but, as best I can tell, Tix is a very old third-party set of Tk extension widgets that has been made obsolete by the Ttk widget set integrated into standard Tk 8.5. See, for example, Kevin Walzer's comments here: http://www.thecodingforums.com/threads/state-of-the-art-tkinter-tk-8-5-tix.651741/. Unlike Ttk, Tix is not part of the core Tk distribution so whether or not Tix is available depends on the Tcl/Tk distribution in use. For the Python Windows installer, we ship our own version of Tcl/Tk and include a version of Tix. For the Python OS X installer, we currently do not ship our own version of Tcl/Tk, rather we depend on the user installing a third-party version of Tcl/Tk (we currently recommend ActiveState's ActiveTcl if the use is compatible with ActiveState's license) or falling back to an (old) Apple-supplied version of Tcl/Tk. Neither Apple nor ActiveState include Tix by default. However, ActiveTcl does include Tix in the Tcl Extension Archive (http://wiki.tcl.tk/17340) it maintains and provides a command-line program, teacup, to download, install, and manage TEA extensions, analogous to Python's pip. So it's straightforward to install Tix if you are using ActiveTcl: sudo teacup install Tix Unfortunately, A/S's OS X version of Tix currently downloadable via teacup is built as a 32-bit binary only. The vast majority of users, running on up-to-date OS X systems, will run into another failure since their Python will likely be running in 64-bit mode: >>> root = Tix.Tk() Traceback (most recent call last): File "", line 1, in File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/Tix.py", line 221, in __init__ self.tk.eval('package require Tix') _tkinter.TclError: dlopen(/Library/Tcl/teapot/package/macosx10.5-i386-x86_64/lib/Tix8.4.3/libTix8.4.3.dylib, 6): no suitable image found. Did find: /Library/Tcl/teapot/package/macosx10.5-i386-x86_64/lib/Tix8.4.3/libTix8.4.3.dylib: mach-o, but wrong architecture Depending on the Python instance in use, running a universal Python in 32-bit mode may be an option or installing a 32-bit-only Python can be done. Either way, it's an unexpected hack. I don't know whether there is a fundamental problem in building Tix for 64-bit on OS X but I think it is telling that there isn't one available from A/S. Likewise, for other platforms, how you make Tix available, if at all, varies. For example, Ubuntu and Debian distributions also do not install Tix by default but it can be installed via their standard package managers. So, all in all, trying to document Tix installation is a major can of worms; I don't think we should be trying to do so in the Python documentation. Further, it seems like we should be strongly discouraging use of Tix in favor of Ttk. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 10:39:54 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 04 Jan 2015 09:39:54 +0000 Subject: [issue23132] Faster total_ordering In-Reply-To: <1419931329.13.0.970719266671.issue23132@psf.upfronthosting.co.za> Message-ID: <1420364394.5.0.444216559198.issue23132@psf.upfronthosting.co.za> Nick Coghlan added the comment: Oops, at least one error in my example: the return tuple should be "__gt__, __le__, __ge__". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 10:41:11 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 04 Jan 2015 09:41:11 +0000 Subject: [issue23161] collections.abc.MutableSet missing methods In-Reply-To: <1420358236.89.0.629550370238.issue23161@psf.upfronthosting.co.za> Message-ID: <1420364471.59.0.563393851706.issue23161@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 11:00:42 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Sun, 04 Jan 2015 10:00:42 +0000 Subject: [issue23162] collections.abc sequences don't check identity before equality In-Reply-To: <1420358706.85.0.46487014677.issue23162@psf.upfronthosting.co.za> Message-ID: <1420365642.59.0.448595159903.issue23162@psf.upfronthosting.co.za> Devin Jeanpierre added the comment: See Raymond Hettinger's comments in http://bugs.python.org/issue4296 for details on why the usual sequence behavior is deliberate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 11:17:45 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 04 Jan 2015 10:17:45 +0000 Subject: [issue23161] collections.abc.MutableSet missing methods In-Reply-To: <1420358236.89.0.629550370238.issue23161@psf.upfronthosting.co.za> Message-ID: <1420366665.47.0.390120915155.issue23161@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The r-methods have already been implemented. Here's the difference as of Python 3.4.2: >>> set(dir(set)) - set(dir(collections.abc.MutableSet)) {'update', 'difference_update', 'symmetric_difference', 'intersection_update', 'intersection', 'issubset', 'issuperset', 'difference', 'copy', 'symmetric_difference_update', 'union'} Guido intentionally omitted the named set-to-set operations in favor of the operator versions (__ior__, __lt__, etc). It was not the intention of the ABC to implement the full API (see Guido's PEP 3119 for more of his rationale. The copy() method was also omitted on purpose. It is a bit of a can-of-worms for abstract class to know everything it needs to copy the the concrete set. This work is best left to the subclass which has the required knowledge. I'm closing this one because I'm channeling Guido and thinking he really didn't want those methods as part of the ABC. ---------- nosy: +rhettinger resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 11:21:23 2015 From: report at bugs.python.org (Karl Richter) Date: Sun, 04 Jan 2015 10:21:23 +0000 Subject: [issue23163] pdb docs need to contain a statement on threads/multithreaded debugging Message-ID: <1420366883.83.0.11703664982.issue23163@psf.upfronthosting.co.za> New submission from Karl Richter: Due to the fact that `pdb` currently simply ignores breakpoints which are set and hit in another than the main thread the docs need to contain a statement on behavior in a multithreaded environment. ---------- components: Library (Lib) messages: 233409 nosy: krichter priority: normal severity: normal status: open title: pdb docs need to contain a statement on threads/multithreaded debugging type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 11:31:16 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 04 Jan 2015 10:31:16 +0000 Subject: [issue23143] Remove some conditional code in _ssl.c In-Reply-To: <1420113339.19.0.823124921107.issue23143@psf.upfronthosting.co.za> Message-ID: <1420367476.89.0.591869889697.issue23143@psf.upfronthosting.co.za> Ned Deily added the comment: Note that this change causes _ssl.so builds to fail on at least one buildbot, the OS X Tiger one, where the system OpenSSL version is 0.9.7. I've asked the buildbot owner to consider installing a local copy of a current OpenSSL. There may be other buildbots affected. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 11:35:01 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 04 Jan 2015 10:35:01 +0000 Subject: [issue23162] collections.abc sequences don't check identity before equality In-Reply-To: <1420358706.85.0.46487014677.issue23162@psf.upfronthosting.co.za> Message-ID: <1420367701.89.0.51371234446.issue23162@psf.upfronthosting.co.za> Raymond Hettinger added the comment: While this hasn't proven to be an issue to date (non-reflexive objects don't arise much in practice), the proposed change would make it easier to use the Sequence ABC to create classes that are interoperable with other sequences and that have the clean invariant, "anything added to the sequence will be "in" the sequence". That said, I don't know if this is really needed. ---------- keywords: +patch nosy: +rhettinger priority: normal -> low type: -> behavior Added file: http://bugs.python.org/file37596/sequence_identity.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 11:56:51 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 04 Jan 2015 10:56:51 +0000 Subject: [issue23132] Faster total_ordering In-Reply-To: <1419931329.13.0.970719266671.issue23132@psf.upfronthosting.co.za> Message-ID: <1420369011.6.0.813477509788.issue23132@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I don't see "creating new functions" as an advantage. ABCs don't do this, nor does any other subclassing. It seems like an attempt to create a false illusion about where the code resides. This feels like feature creep with no real advantage that anyone cares about. In the non-templating version, the code is simple and it is clear where it came-from (i.e. a code inspector can find it). IMO, the factory functions just make it harder to grok this code. Please resist the urge invent new magic and stick with the simplest Python that gets the job done. ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 12:56:39 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Sun, 04 Jan 2015 11:56:39 +0000 Subject: [issue23161] collections.abc.MutableSet missing methods In-Reply-To: <1420358236.89.0.629550370238.issue23161@psf.upfronthosting.co.za> Message-ID: <1420372599.57.0.795552069386.issue23161@psf.upfronthosting.co.za> Devin Jeanpierre added the comment: copy() should not be implemented magically, no. I understand the argument in favor of not implementing redundant methods, but if the redundancy was this big a concern, they should not have been added to sets in the first place. The current ABCs are inconsistent and confusing. For example: MutableSequence implements += and .extend, but on MutableSet, the analogous methods |= and .update are only half there. (Moreover, it's the wrong half, in my experience.) Plus not all of the named methods have operator equivalents, so e.g. is_subset is not supported, but is_disjoint is. This also means every subclass, in order to actually implement the set API, needs to write this code itself. It is very common to call the named methods, especially ones like update, and compatibility with set is desirable -- otherwise, we wouldn't bother inheriting from the relevant ABC. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 13:04:52 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Sun, 04 Jan 2015 12:04:52 +0000 Subject: [issue23162] collections.abc sequences don't check identity before equality In-Reply-To: <1420358706.85.0.46487014677.issue23162@psf.upfronthosting.co.za> Message-ID: <1420373092.11.0.653980805271.issue23162@psf.upfronthosting.co.za> Devin Jeanpierre added the comment: Thanks for the patch! I was secretly hoping to write it though. :P Not sure how the code review tool works. The patch looks good to me, except it needs tests IMO. I can write them if you think this is not worth the effort. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 13:50:10 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 04 Jan 2015 12:50:10 +0000 Subject: [issue23161] collections.abc.MutableSet missing methods In-Reply-To: <1420358236.89.0.629550370238.issue23161@psf.upfronthosting.co.za> Message-ID: <1420375810.91.0.189172287387.issue23161@psf.upfronthosting.co.za> Martin Panter added the comment: For what it?s worth, every now and then I have to stop and remember that I can?t do this sort of thing: unsupported_keys = config_dict.keys().difference(supported_list) though it is not a big problem to rewrite it as unsupported_keys = config_dict.keys() - set(supported_list) Also it looks like one can already effectively do x.copy() using the existing immutable Set operators, so that worm can is already opened: >>> ListBasedSet("abc") & ListBasedSet("abc") <__main__.ListBasedSet object at 0x7f419951b860> On the other hand, a matching almost equivalent operator does exist for a.issubset(b): a <= b, or a.__le__(b). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 14:19:32 2015 From: report at bugs.python.org (Eric O. LEBIGOT) Date: Sun, 04 Jan 2015 13:19:32 +0000 Subject: [issue23164] "pydoc filter" documentation restrictive Message-ID: <1420377572.43.0.335658121107.issue23164@psf.upfronthosting.co.za> New submission from Eric O. LEBIGOT: The pydoc documentation for filter reads: filter(function or None, sequence) -> list, tuple, or string Return those items of sequence for which function(item) is true. If function is None, return the items that are true. If sequence is a tuple or string, return the same type, else return a list. It would be nicer to know (e.g. when offline and with no local access to the HTML documentation) that filter() can actually be used more generally with an iterable: filter(function or None, **iterable**) -> list, tuple, or string Return those items of **iterable** for which? ---------- assignee: docs at python components: Documentation messages: 233416 nosy: docs at python, lebigot priority: normal severity: normal status: open title: "pydoc filter" documentation restrictive type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 15:04:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 04 Jan 2015 14:04:48 +0000 Subject: [issue23132] Faster total_ordering In-Reply-To: <1419931329.13.0.970719266671.issue23132@psf.upfronthosting.co.za> Message-ID: <1420380288.85.0.233642788323.issue23132@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The convert mapping is redundant, function name can be calculated from root and opname. __name__ and __doc__ can be assigned at import time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 15:13:01 2015 From: report at bugs.python.org (Gareth Rees) Date: Sun, 04 Jan 2015 14:13:01 +0000 Subject: [issue20606] Operator Documentation Example doesn't work In-Reply-To: <1392201634.78.0.0474474805722.issue20606@psf.upfronthosting.co.za> Message-ID: <1420380781.79.0.382976717262.issue20606@psf.upfronthosting.co.za> Gareth Rees added the comment: This is a duplicate of #22180, which was fixed in changeset 9c250f34bfa3 by Raymond Hettinger in branch '3.4'. The fix just removes the bad example, as in my patch. So I suggest that this issue be closed as a duplicate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 15:19:08 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 04 Jan 2015 14:19:08 +0000 Subject: [issue23132] Faster total_ordering In-Reply-To: <1419931329.13.0.970719266671.issue23132@psf.upfronthosting.co.za> Message-ID: <1420381148.14.0.337777542859.issue23132@psf.upfronthosting.co.za> Nick Coghlan added the comment: The metadata adjustments in Serhiy's patch had me thinking in terms of functools.wraps, but that rationale doesn't actually apply here (since the functions are only used in one place, and have a distinctive name rather than a generic one). I'd also missed that the conversion to standalone module level functions inherently provides the same pickle compatibility benefit that Serhiy's patch did. Accordingly, I agree that my suggested factory functions would make the code more complex for no benefit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 15:28:44 2015 From: report at bugs.python.org (mike bayer) Date: Sun, 04 Jan 2015 14:28:44 +0000 Subject: [issue22956] Improved support for prepared SQL statements In-Reply-To: <1417095519.92.0.197896622793.issue22956@psf.upfronthosting.co.za> Message-ID: <1420381724.02.0.224339721734.issue22956@psf.upfronthosting.co.za> mike bayer added the comment: prepared statements are, in proportion to the typical speed issues in Python (see my comparison benchmark at https://mail.python.org/pipermail/db-sig/2014-December/006147.html) a fairly small optimization that the DBAPI already allows for in an implicit sense, via an internal statement cache - the execute() method of DBAPI (see https://www.python.org/dev/peps/pep-0249/#id14) allows for this optimization. Therefore an application that wishes to use this optimization with a participating DBAPI only need to maintain a reference to the cursor, and continue to use that same cursor for the same statement - pretty much identically to how it would be used in the explicit prepare step. An explicit prepare step should be no more intrusive than an optional flag sent along to cursor(), as MySQL-connector does, see http://dev.mysql.com/doc/connector-python/en/connector-python-api-mysqlconnection-cursor.html. The DBAPI does not use objects to represent statements. In JDBC, there is a Statement and PreparedStatement object, but because JDBC has no explicit sense of a "cursor", these are in fact just cursor objects (see https://mail.python.org/pipermail/db-sig/2014-December/006168.html for my description of this). Therefore we are really just talking about a potentially modified cursor class, and in Python we can just use a flag, there's no need for heavy-handed Java-esque concepts like new classes. If one really wishes there were a PreparedStatement class, using the flag approach one can have it with very simple code that IMO does not belong in the DBAPI: class PreparedStatement(object): def __init__(self, connection, statement): self.cursor = connection.cursor(prepared=True) self.statement = statement def execute(self, params): self.cursor.execute(self.statement, params) def fetchall(self): return self.cursor.fetchall() # ... etc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 17:13:41 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 04 Jan 2015 16:13:41 +0000 Subject: [issue23111] ftplib.FTP_TLS's default constructor does not work with TLSv1.1 or TLSv1.2 In-Reply-To: <1419457507.62.0.0499182915126.issue23111@psf.upfronthosting.co.za> Message-ID: <1420388021.86.0.670179968501.issue23111@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: I think that this fix should be applied also in 2.7 branch. ---------- nosy: +Arfrever, benjamin.peterson resolution: fixed -> stage: resolved -> status: closed -> open versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 17:18:39 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 04 Jan 2015 16:18:39 +0000 Subject: [issue20606] Operator Documentation Example doesn't work In-Reply-To: <1392201634.78.0.0474474805722.issue20606@psf.upfronthosting.co.za> Message-ID: <1420388319.82.0.948793083452.issue20606@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Closed ---------- nosy: +asvetlov resolution: -> duplicate stage: -> resolved superseder: -> operator.setitem example no longer works in Python 3 due to lazy map _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 17:20:32 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 Jan 2015 16:20:32 +0000 Subject: [issue23111] ftplib.FTP_TLS's default constructor does not work with TLSv1.1 or TLSv1.2 In-Reply-To: <1419457507.62.0.0499182915126.issue23111@psf.upfronthosting.co.za> Message-ID: <20150104162020.72581.87773@psf.io> Roundup Robot added the comment: New changeset 98ee845a139a by Benjamin Peterson in branch '2.7': make SSLv23 the default version in ftplib (closes #23111) https://hg.python.org/cpython/rev/98ee845a139a ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 17:48:33 2015 From: report at bugs.python.org (Guido Vranken) Date: Sun, 04 Jan 2015 16:48:33 +0000 Subject: [issue23165] Heap overwrite in Python/fileutils.c:_Py_char2wchar() on 32 bit systems due to malloc parameter overflow Message-ID: <1420390111.83.0.411085812385.issue23165@psf.upfronthosting.co.za> New submission from Guido Vranken: The vulnerability described here is exceedingly difficult to exploit, since there is no straight-forward way an "attacker" (someone who controls a Python script contents but not other values such as system environment variables), can control a relevant parameter to the vulnerable function (_Py_char2wchar in Python/fileutils.c). It is, however, important that it is remediated since unawareness of this vulnerability may cause an unsuspecting author to establish a link between user and the function parameter in future versions of Python. Like I said, the vulnerability is caused by code in the _Py_char2wchar function. Indirectly this function is accessed through Objects/unicodeobject.c:PyUnicode_DecodeLocaleAndSize(), PyUnicode_DecodeFSDefaultAndSize(), PyUnicode_DecodeLocale, and some other functions. As far as I know this can only be exploited on 32-bit architectures (whose overflow threshold of its registers is 2**32). The following description sets out from the latest Python 3.4 code retrieved from https://hg.python.org/cpython . The problem lies in the computation of size of the buffer that will hold the wide char version of the input string: -- Python/fileutils.c -- 296 #ifdef HAVE_BROKEN_MBSTOWCS 297 /* Some platforms have a broken implementation of 298 * mbstowcs which does not count the characters that 299 * would result from conversion. Use an upper bound. 300 */ 301 argsize = strlen(arg); 302 #else 303 argsize = mbstowcs(NULL, arg, 0); 304 #endif ... ... 306 res = (wchar_t *)PyMem_RawMalloc((argsize+1)*sizeof(wchar_t)); and: 331 argsize = strlen(arg) + 1; 332 res = (wchar_t*)PyMem_RawMalloc(argsize*sizeof(wchar_t)); Both invocations to PyMem_RawMalloc are not preceded by code that asserts no overflow will occur as a result of multiplication of the length of 'arg' by sizeof(wchar_t), which is typically 4 bytes. It follows that on a 32-bit architecture, it is possible cause an internal overflow to occur through the supplication of a string whose size is >= ((2**32)-1) / 4, which is 1 gigabyte. The supplication of a 1 GB (minus one byte) string will therefore result in a value of 0 being passed to PyMem_RawMalloc, because: argsize = 1024*1024*1024-1 malloc_argument = ((argsize+1) * 4 print malloc_argument & 0xFFFFFFFF # prints '0' Effectively this will result in an allocation of exactly 1 byte, since a parameter of 0 is automatically adjusted to 1 by the underlying _PyMem_RawMalloc(): -- Objects/obmalloc.c -- 51 static void * 52 _PyMem_RawMalloc(void *ctx, size_t size) 53 { 54 /* PyMem_Malloc(0) means malloc(1). Some systems would return NULL 55 for malloc(0), which would be treated as an error. Some platforms would 56 return a pointer with no memory behind it, which would break pymalloc. 57 To solve these problems, allocate an extra byte. */ 58 if (size == 0) 59 size = 1; 60 return malloc(size); 61 } Once the memory has been allocated, mbstowcs() is invoked: -- Python/fileutils.c -- 306 res = (wchar_t *)PyMem_RawMalloc((argsize+1)*sizeof(wchar_t)); 307 if (!res) 308 goto oom; 309 count = mbstowcs(res, arg, argsize+1); In my test setup (latest 32 bit Debian), mbstowcs returns '0', meaning no bytes were written to 'res'. Then, 'res' is iterated over and the iteration is halted as soon as a null-wchar or a wchar which is a surrogate: -- Python/fileutils.c -- 310 if (count != (size_t)-1) { 311 wchar_t *tmp; 312 /* Only use the result if it contains no 313 surrogate characters. */ 314 for (tmp = res; *tmp != 0 && 315 !Py_UNICODE_IS_SURROGATE(*tmp); tmp++) 316 ; 317 if (*tmp == 0) { 318 if (size != NULL) 319 *size = count; 320 return res; 321 } 322 } 323 PyMem_RawFree(res); Py_UNICODE_IS_SURROGATE is defined as follows: -- Include/unicodeobject.h -- 183 #define Py_UNICODE_IS_SURROGATE(ch) (0xD800 <= (ch) && (ch) <= 0xDFFF) In the iteration over 'res', control is transferred back to the invoker of _Py_char2wchar() if a null-wchar is encountered first. If, however, a wchar that does satisfies the expression in Py_UNICODE_IS_SURROGATE() is encountered first, *tmp is not null and thus the conditional code on lines 318-320 is skipped. The space that 'res' points to is unintialized. Uninitialized, however, does not not entail randomness in this case. If an attacker has sufficient freedom to manipulate the contents of the process memory prior to calling _Py_char2wchar() in order to scatter it with values that satisfy Py_UNICODE_IS_SURROGATE(), this could increase their odds of having _Py_char2wchar() encounter such a value before a null-wchar. These kinds of details are very dependant on system architecture, operating system, libc implementation and so forth. The remainder of the function will perform a byte-per-byte conversion embedded in a loop, to manually convert the entire input string. Especially relevant to this vulnerability are lines 332, 339, 356 and 365, 366: On line 332 memory is allocated, effectively only 1 byte as explained above. 'argsize', however, is 0x40000000 in our case, and the entire routine is repeated until argsize is 0. On line 339 one or more characters are converted, and stored into 'out', which is 'res'. Lines 356 and 366 do the same. -- Python/fileutils.c -- 325 /* Conversion failed. Fall back to escaping with surrogateescape. */ 326 #ifdef HAVE_MBRTOWC 327 /* Try conversion with mbrtwoc (C99), and escape non-decodable bytes. */ 328 329 /* Overallocate; as multi-byte characters are in the argument, the 330 actual output could use less memory. */ 331 argsize = strlen(arg) + 1; 332 res = (wchar_t*)PyMem_RawMalloc(argsize*sizeof(wchar_t)); 333 if (!res) 334 goto oom; 335 in = (unsigned char*)arg; 336 out = res; 337 memset(&mbs, 0, sizeof mbs); 338 while (argsize) { 339 size_t converted = mbrtowc(out, (char*)in, argsize, &mbs); 340 if (converted == 0) 341 /* Reached end of string; null char stored. */ 342 break; 343 if (converted == (size_t)-2) { 344 /* Incomplete character. This should never happen, 345 since we provide everything that we have - 346 unless there is a bug in the C library, or I 347 misunderstood how mbrtowc works. */ 348 PyMem_RawFree(res); 349 if (size != NULL) 350 *size = (size_t)-2; 351 return NULL; 352 } 353 if (converted == (size_t)-1) { 354 /* Conversion error. Escape as UTF-8b, and start over 355 in the initial shift state. */ 356 *out++ = 0xdc00 + *in++; 357 argsize--; 358 memset(&mbs, 0, sizeof mbs); 359 continue; 360 } 361 if (Py_UNICODE_IS_SURROGATE(*out)) { 362 /* Surrogate character. Escape the original 363 byte sequence with surrogateescape. */ 364 argsize -= converted; 365 while (converted--) 366 *out++ = 0xdc00 + *in++; 367 continue; 368 } 369 /* successfully converted some bytes */ 370 in += converted; 371 argsize -= converted; 372 out++; 373 } 374 if (size != NULL) 375 *size = out - res; 376 #else /* HAVE_MBRTOWC */ 377 /* Cannot use C locale for escaping; manually escape as if charset 378 is ASCII (i.e. escape all bytes > 128. This will still roundtrip 379 correctly in the locale's charset, which must be an ASCII superset. */ 380 res = decode_ascii_surrogateescape(arg, size); 381 if (res == NULL) 382 goto oom; 383 #endif /* HAVE_MBRTOWC */ Suffice it to say that this leads to writing to memory that has not been allocated, thereby making this a heap overflow vulnerability. decode_ascii_surrogateescape() seems to suffer from the same issue. Guido Vranken, Intelworks http://www.intelworks.com/ ---------- files: _py_char2wchar_patches.tar.gz messages: 233424 nosy: Guido priority: normal severity: normal status: open title: Heap overwrite in Python/fileutils.c:_Py_char2wchar() on 32 bit systems due to malloc parameter overflow type: security versions: Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file37597/_py_char2wchar_patches.tar.gz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 21:10:44 2015 From: report at bugs.python.org (Ian Cordasco) Date: Sun, 04 Jan 2015 20:10:44 +0000 Subject: [issue23155] unittest: object has no attribute '_removed_tests' In-Reply-To: <1420313883.47.0.122520965169.issue23155@psf.upfronthosting.co.za> Message-ID: <1420402244.8.0.826008194833.issue23155@psf.upfronthosting.co.za> Changes by Ian Cordasco : ---------- nosy: +icordasc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 21:11:15 2015 From: report at bugs.python.org (Ian Cordasco) Date: Sun, 04 Jan 2015 20:11:15 +0000 Subject: [issue23155] unittest: object has no attribute '_removed_tests' In-Reply-To: <1420313883.47.0.122520965169.issue23155@psf.upfronthosting.co.za> Message-ID: <1420402275.32.0.245896880956.issue23155@psf.upfronthosting.co.za> Ian Cordasco added the comment: Keep in mind, this could also be a problem with NetBSD's distribution of python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 21:44:46 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 04 Jan 2015 20:44:46 +0000 Subject: [issue23156] Update tix install information in tkinter tix chapter of doc In-Reply-To: <1420322124.69.0.0233808198239.issue23156@psf.upfronthosting.co.za> Message-ID: <1420404286.55.0.0987569240186.issue23156@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I found tix8.4.3.dll and pkgIndex.tcl inside tcl/tix8.4.3, which is not where the doc currently says to look. Christian Gollwitzer posted a response on the python-list thread "Python Tk Tix GUI documentation & builder overview and tips" (which helped inspire this issue in addition to the SO post). He basically agrees with Ned's ending comment that "we should be strongly discouraging use of Tix in favor of Ttk." "Note that Tix is LEGACY. There are much better options for its widgets available that are based on ttk. ... Not to mention that the Tix widgets are extremely ugly, while the widgets from ttk have a near-native look and feel." So I agree that the opening paragraph of the (T)tkinter.tix section https://docs.python.org/3/library/tkinter.tix.html#module-tkinter.tix should identify it as a legacy python interface to the old, optional, tcl/tk tix extension that has been mostly superceded by widgets added either directly to tk or by ttk. Cristian also listed the ttk replacements. ''' * Hierarchical Listbox use ttk::treeview, tablelist_tile or tkTreeCtrl, with increasing order of capabilities and install complexity * TList: I think tkTreeCtrl can do it, never have used this layout * CheckList: tablelist can be used with an editable field * Grid widget: use tkTable * NoteBook, PanedWindow, ComboBox, LabelFrame -> ttk::notebook, ttk::panedwindow, ttk::combobox, ttk::labelframe * Balloon: tcllib::tooltip ''' The tkinter and tkinter.ttk replacements could similarly be added to the tix widget listing in the doc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 21:50:13 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 04 Jan 2015 20:50:13 +0000 Subject: [issue23165] Heap overwrite in Python/fileutils.c:_Py_char2wchar() on 32 bit systems due to malloc parameter overflow In-Reply-To: <1420390111.83.0.411085812385.issue23165@psf.upfronthosting.co.za> Message-ID: <1420404613.93.0.859697693799.issue23165@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 22:13:57 2015 From: report at bugs.python.org (Jurijs Vorotilovs) Date: Sun, 04 Jan 2015 21:13:57 +0000 Subject: [issue23166] urllib2 ignores opener configuration under certain circumstances Message-ID: <1420406037.0.0.986455895168.issue23166@psf.upfronthosting.co.za> New submission from Jurijs Vorotilovs: Python 2.7.9 has a bug in urllib2.py:urlopen(). It creates HTTPSHandler instances by its own when it should not. One may have assigned custom openers with subclassed HTTPSHandler or HTTPSHandler instance with debug enabled or etc. ---------- components: Library (Lib) messages: 233427 nosy: crazyjurich priority: normal severity: normal status: open title: urllib2 ignores opener configuration under certain circumstances type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 22:33:02 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 04 Jan 2015 21:33:02 +0000 Subject: [issue23163] pdb docs need to contain a statement on threads/multithreaded debugging In-Reply-To: <1420366883.83.0.11703664982.issue23163@psf.upfronthosting.co.za> Message-ID: <1420407182.34.0.663619379014.issue23163@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 23:06:59 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 Jan 2015 22:06:59 +0000 Subject: [issue23165] Heap overwrite in Python/fileutils.c:_Py_char2wchar() on 32 bit systems due to malloc parameter overflow In-Reply-To: <1420390111.83.0.411085812385.issue23165@psf.upfronthosting.co.za> Message-ID: <20150104220624.22417.32403@psf.io> Roundup Robot added the comment: New changeset 1ce98e85929d by Benjamin Peterson in branch '3.2': add some overflow checks before multiplying (closes #23165) https://hg.python.org/cpython/rev/1ce98e85929d New changeset d1af6f3a8ce3 by Benjamin Peterson in branch '3.3': merge 3.2 (closes #23165) https://hg.python.org/cpython/rev/d1af6f3a8ce3 New changeset d45e16b1ed86 by Benjamin Peterson in branch '3.4': merge 3.3 (closes #23165) https://hg.python.org/cpython/rev/d45e16b1ed86 New changeset 8c4fb312e15d by Benjamin Peterson in branch 'default': merge 3.4 (#23165) https://hg.python.org/cpython/rev/8c4fb312e15d ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 23:12:26 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Sun, 04 Jan 2015 22:12:26 +0000 Subject: [issue23167] Marshal docs say format version is 3; actual format version is 4 Message-ID: <1420409546.12.0.515201542018.issue23167@psf.upfronthosting.co.za> New submission from Dmitry Kazakov: Documentation on marshal module says that format version is 3, but Py_MARSHAL_VERSION is set to 4. Search for marshal-related issues gave me an idea that this is a documentation bug. ---------- assignee: docs at python components: Documentation files: marshal_doc.diff keywords: patch messages: 233429 nosy: docs at python, vlth priority: normal severity: normal status: open title: Marshal docs say format version is 3; actual format version is 4 versions: Python 3.4 Added file: http://bugs.python.org/file37598/marshal_doc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 23:17:50 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 04 Jan 2015 22:17:50 +0000 Subject: [issue20606] Operator Documentation Example doesn't work In-Reply-To: <1392201634.78.0.0474474805722.issue20606@psf.upfronthosting.co.za> Message-ID: <1420409870.3.0.343473986745.issue20606@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 23:20:02 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 04 Jan 2015 22:20:02 +0000 Subject: [issue23165] Heap overwrite in Python/fileutils.c:_Py_char2wchar() on 32 bit systems due to malloc parameter overflow In-Reply-To: <1420390111.83.0.411085812385.issue23165@psf.upfronthosting.co.za> Message-ID: <1420410002.8.0.36856969224.issue23165@psf.upfronthosting.co.za> STINNER Victor added the comment: + size_t argsize = strlen(arg) + 1; + if (argsize > PY_SSIZE_T_MAX/sizeof(wchar_t)) + return NULL; + res = PyMem_Malloc(argsize*sizeof(wchar_t)); The code doesn't check for integer overflow on "+1". I suggest instead: + size_t arglen = strlen(arg); + if (arglen > PY_SSIZE_T_MAX / sizeof(wchar_t) - 1) + return NULL; + res = PyMem_Malloc((arglen + 1) * sizeof(wchar_t)); ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 23:22:29 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 04 Jan 2015 22:22:29 +0000 Subject: [issue23165] Heap overwrite in Python/fileutils.c:_Py_char2wchar() on 32 bit systems due to malloc parameter overflow In-Reply-To: <1420390111.83.0.411085812385.issue23165@psf.upfronthosting.co.za> Message-ID: <1420410149.13.0.088334917141.issue23165@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Presumably strlen can't return SIZE_T_MAX because the trailing '\0' has to have been allocated somewhere. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 23:30:27 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 Jan 2015 22:30:27 +0000 Subject: [issue23167] Marshal docs say format version is 3; actual format version is 4 In-Reply-To: <1420409546.12.0.515201542018.issue23167@psf.upfronthosting.co.za> Message-ID: <20150104223022.125896.11936@psf.io> Roundup Robot added the comment: New changeset 8ac23d3242b4 by Benjamin Peterson in branch '3.4': the current marshal version is 4 (closes #23167) https://hg.python.org/cpython/rev/8ac23d3242b4 New changeset 826831a9a376 by Benjamin Peterson in branch 'default': merge 3.4 (#23167) https://hg.python.org/cpython/rev/826831a9a376 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 23:50:01 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 04 Jan 2015 22:50:01 +0000 Subject: [issue23165] Heap overwrite in Python/fileutils.c:_Py_char2wchar() on 32 bit systems due to malloc parameter overflow In-Reply-To: <1420410149.13.0.088334917141.issue23165@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: PY_SSIZE_T_MAX is usually smaller than SIZE_T_MAX ;-) (strlen result is not signed.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 23:51:35 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 04 Jan 2015 22:51:35 +0000 Subject: [issue13248] deprecated in 3.2/3.3, should be removed in 3.5 or ??? In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za> Message-ID: <1420411895.86.0.378005372428.issue13248@psf.upfronthosting.co.za> Martin Panter added the comment: Another one to deal with one way or the other: html.parser.HTMLParser.unescape() It is apparently due to be removed in 3.5. It was meant to be an undocumented internal function, and there is now an public alternative. However I would be inclined to leave it around a little longer, because it seems to have been widely recommended for decoding HTML entities in the past (e.g. ), and keeping it would simplify maintaining Python 2 compatible code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 4 23:52:24 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 04 Jan 2015 22:52:24 +0000 Subject: [issue23165] Heap overwrite in Python/fileutils.c:_Py_char2wchar() on 32 bit systems due to malloc parameter overflow In-Reply-To: Message-ID: <1420411941.1291731.209490689.08198FF2@webmail.messagingengine.com> Benjamin Peterson added the comment: Right, but there's still no danger of overflow. On Sun, Jan 4, 2015, at 16:50, STINNER Victor wrote: > > STINNER Victor added the comment: > > PY_SSIZE_T_MAX is usually smaller than SIZE_T_MAX ;-) > > (strlen result is not signed.) > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 01:48:06 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 05 Jan 2015 00:48:06 +0000 Subject: [issue23162] collections.abc sequences don't check identity before equality In-Reply-To: <1420358706.85.0.46487014677.issue23162@psf.upfronthosting.co.za> Message-ID: <1420418886.76.0.345040365117.issue23162@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Devin, you're welcome to whip-up a patch for the tests for this one. I don't know if it will go forward though. I'm leaving it open for a while to see if anyone has objections. If you want to work another straight-forward ABC patch, have a look at http://bugs.python.org/issue23086 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 04:44:33 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Mon, 05 Jan 2015 03:44:33 +0000 Subject: [issue23162] collections.abc sequences don't check identity before equality In-Reply-To: <1420358706.85.0.46487014677.issue23162@psf.upfronthosting.co.za> Message-ID: <1420429473.46.0.595426265946.issue23162@psf.upfronthosting.co.za> Devin Jeanpierre added the comment: Since both patches will clobber each other (same test method), complicating the review process, I've written the patch for issue23086 first. It's currently waiting on committee review from my employer. Will upload to other issue, and once it's submitted or rejected, I'll add a test patch to this issue too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 06:37:52 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 05 Jan 2015 05:37:52 +0000 Subject: [issue23001] Accept mutable bytes-like objects In-Reply-To: <1417875906.64.0.311564166909.issue23001@psf.upfronthosting.co.za> Message-ID: <1420436272.69.0.650089183239.issue23001@psf.upfronthosting.co.za> Martin Panter added the comment: If this goes ahead, it would be nice adding notes to the documentation saying that bytearray() or whatever was previously not supported. There are APIs in Python 2.6 that had similar treatment with no documentation updates, and I keep being bitten by it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 06:52:52 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 05 Jan 2015 05:52:52 +0000 Subject: [issue23162] collections.abc sequences don't check identity before equality In-Reply-To: <1420358706.85.0.46487014677.issue23162@psf.upfronthosting.co.za> Message-ID: <1420437172.02.0.558327384027.issue23162@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Can you submit a contributor agreement as well? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 07:20:56 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Mon, 05 Jan 2015 06:20:56 +0000 Subject: [issue23162] collections.abc sequences don't check identity before equality In-Reply-To: <1420358706.85.0.46487014677.issue23162@psf.upfronthosting.co.za> Message-ID: <1420438856.26.0.361304846097.issue23162@psf.upfronthosting.co.za> Devin Jeanpierre added the comment: I think that such a thing is meaningless, as I don't own copyright to the patches, my employer (Google) does. But, it can't hurt, so, done. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 07:22:13 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 05 Jan 2015 06:22:13 +0000 Subject: [issue23132] Faster total_ordering In-Reply-To: <1419931329.13.0.970719266671.issue23132@psf.upfronthosting.co.za> Message-ID: <1420438933.63.0.857140289907.issue23132@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file37599/total_ordering2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 07:52:09 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 05 Jan 2015 06:52:09 +0000 Subject: [issue23166] urllib2 ignores opener configuration under certain circumstances In-Reply-To: <1420406037.0.0.986455895168.issue23166@psf.upfronthosting.co.za> Message-ID: <1420440729.85.0.124816882364.issue23166@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report. Could you provide an example to reproduce the issue you described? ---------- nosy: +berker.peksag, orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 08:18:22 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 05 Jan 2015 07:18:22 +0000 Subject: [issue18644] Got ResourceWarning: unclosed file when using test function from formatter module In-Reply-To: <1375537519.43.0.405840418589.issue18644@psf.upfronthosting.co.za> Message-ID: <20150105071804.125898.71858@psf.io> Roundup Robot added the comment: New changeset f859a61f5853 by Berker Peksag in branch '3.4': Issue #18644: Fix a ResourceWarning in formatter.test(). https://hg.python.org/cpython/rev/f859a61f5853 New changeset f374e4e6d04b by Berker Peksag in branch 'default': Issue #18644: Fix a ResourceWarning in formatter.test(). https://hg.python.org/cpython/rev/f374e4e6d04b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 08:20:21 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 05 Jan 2015 07:20:21 +0000 Subject: [issue18644] Got ResourceWarning: unclosed file when using test function from formatter module In-Reply-To: <1375537519.43.0.405840418589.issue18644@psf.upfronthosting.co.za> Message-ID: <1420442421.07.0.637644504443.issue18644@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Vajrasky. ---------- components: +Library (Lib) -Tests nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 08:45:54 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 05 Jan 2015 07:45:54 +0000 Subject: [issue13248] deprecated in 3.2/3.3, should be removed in 3.5 or ??? In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za> Message-ID: <1420443954.38.0.787155103284.issue13248@psf.upfronthosting.co.za> Berker Peksag added the comment: Here is a follow-up list: * formatter module (will be removed in Python 3.6) * asynchat.fifo() (will be removed in Python 3.6) * buffering argument of bz2.BZ2File() (deprecated in 2011) * tarfile.filemode() (deprecated in 2012) * SO config var (sysconfig.get_config_var()) (deprecated in 2013) * platform.popen() (deprecated in 2011) * ntpath.splitunc() (deprecated in 2009) * inspect.getmoduleinfo() (deprecated in 2012) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 09:07:12 2015 From: report at bugs.python.org (ABR) Date: Mon, 05 Jan 2015 08:07:12 +0000 Subject: [issue15795] Zipfile.extractall does not preserve file permissions In-Reply-To: <1346106964.12.0.723201722432.issue15795@psf.upfronthosting.co.za> Message-ID: <1420445232.01.0.251555409688.issue15795@psf.upfronthosting.co.za> ABR added the comment: I hope this can be finally gotten in for 3.5, even if it's not the perfect solution. I hit this issue and needed to call out to a subprocess as a work-around, but that's far less reliable. ---------- nosy: +arobert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 09:29:14 2015 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 05 Jan 2015 08:29:14 +0000 Subject: [issue18644] Got ResourceWarning: unclosed file when using test function from formatter module In-Reply-To: <1375537519.43.0.405840418589.issue18644@psf.upfronthosting.co.za> Message-ID: <1420446554.47.0.616933655714.issue18644@psf.upfronthosting.co.za> Eric V. Smith added the comment: Not that I think it's worth changing for this case, but I find code like this better written as: if some_test: fl = contextlib.closing(open(sys.argv[1])) else: fl = sys.stdin with fl as fl: do_stuff(fl) This way you don't need another test, the close isn't far away from the open, and you save some lines of boilerplate. Or, if "with fl as fl" bothers you: with sys.stdout if some_test else contextlib.closing(open(sys.argv[1])) as fl: do_stuff(fl) I don't recommend that, though. In any event, thanks for the fix! ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 09:49:20 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 05 Jan 2015 08:49:20 +0000 Subject: [issue22935] Disabling SSLv3 support In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za> Message-ID: <1420447760.74.0.920028805293.issue22935@psf.upfronthosting.co.za> Ned Deily added the comment: Setting to release blocker since this needs to be resolved for 3.4.3. FYI, the OS X x86 Tiger 3.4 buildbot has been updated to use a local copy of OpenSSL 1.0.1j with SSLv3 disabled and multiple tests now fail (2.7 and default do not fail, as expected). http://buildbot.python.org/all/builders/x86%20Tiger%203.4 ---------- nosy: +larry priority: high -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 09:51:37 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 05 Jan 2015 08:51:37 +0000 Subject: [issue22935] Disabling SSLv3 support In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za> Message-ID: <1420447897.89.0.141371342451.issue22935@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm going to commit get_server_certificate_sslv23.patch into Python 3.4, so Python 3.4 will just behave like Python 2.7 and 3.5, except if someone complains :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 09:59:47 2015 From: report at bugs.python.org (noon) Date: Mon, 05 Jan 2015 08:59:47 +0000 Subject: [issue3786] _curses, _curses_panel & _multiprocessing can't be build in 2.6b3 w/ SunStudio 12 In-Reply-To: <1220608521.1.0.66106932182.issue3786@psf.upfronthosting.co.za> Message-ID: <1420448387.18.0.646142469911.issue3786@psf.upfronthosting.co.za> Changes by noon : ---------- nosy: -noon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 10:06:09 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 05 Jan 2015 09:06:09 +0000 Subject: [issue22165] Empty response from http.server when directory listing contains invalid unicode In-Reply-To: <1407423993.73.0.218384565957.issue22165@psf.upfronthosting.co.za> Message-ID: <20150105090606.125900.20191@psf.io> Roundup Robot added the comment: New changeset 1bc41bbbe02d by Ned Deily in branch '3.4': Issue #22165: Skip test_undecodable_filename on OS X prior to 10.5. https://hg.python.org/cpython/rev/1bc41bbbe02d New changeset 85258e08b69b by Ned Deily in branch 'default': Issue #22165: merge from 3.4 https://hg.python.org/cpython/rev/85258e08b69b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 10:41:51 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Mon, 05 Jan 2015 09:41:51 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <1420450911.06.0.406520357453.issue22619@psf.upfronthosting.co.za> Dmitry Kazakov added the comment: I understand that this issue is far from being important, but this is going to be the fourth unreviewed file in this issue. I noted all your comments to me and fixed the patch accordingly, but ever since November I'm the only one who posts something here. I pinged the issue about 4 days ago (after a month of utter silence) and still didn't get any response. Could someone review the latest patch (the one I attach to this message - traceback_rev.diff) or at least say what's wrong with it (or with this issue, or with something else)? ---------- Added file: http://bugs.python.org/file37600/traceback_rev.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 10:53:58 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 05 Jan 2015 09:53:58 +0000 Subject: [issue18644] Got ResourceWarning: unclosed file when using test function from formatter module In-Reply-To: <1375537519.43.0.405840418589.issue18644@psf.upfronthosting.co.za> Message-ID: <1420451638.0.0.835408386124.issue18644@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the suggestion, Eric. contextlib.closing(open(...)) looks unnecessary to me. Here is an alternative patch. ---------- Added file: http://bugs.python.org/file37601/issue18644.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 10:57:35 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 05 Jan 2015 09:57:35 +0000 Subject: [issue18644] Got ResourceWarning: unclosed file when using test function from formatter module In-Reply-To: <1375537519.43.0.405840418589.issue18644@psf.upfronthosting.co.za> Message-ID: <1420451855.95.0.366594708447.issue18644@psf.upfronthosting.co.za> STINNER Victor added the comment: > fl = contextlib.closing(open(sys.argv[1])) I prefer the current code with the explicit close() and "is not sys.stdin", it's less magic :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 11:05:23 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 05 Jan 2015 10:05:23 +0000 Subject: [issue20487] Odd words in unittest.mock document. In-Reply-To: <1391355507.86.0.158179018907.issue20487@psf.upfronthosting.co.za> Message-ID: <1420452323.79.0.977693978732.issue20487@psf.upfronthosting.co.za> Berker Peksag added the comment: Here is a patch to address msg211296. ---------- keywords: +patch nosy: +berker.peksag stage: -> patch review type: -> enhancement versions: -Python 3.3 Added file: http://bugs.python.org/file37602/issue20487.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 11:09:07 2015 From: report at bugs.python.org (Michael Foord) Date: Mon, 05 Jan 2015 10:09:07 +0000 Subject: [issue20487] Odd words in unittest.mock document. In-Reply-To: <1391355507.86.0.158179018907.issue20487@psf.upfronthosting.co.za> Message-ID: <1420452547.42.0.861378686055.issue20487@psf.upfronthosting.co.za> Michael Foord added the comment: Patch looks good, thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 11:13:30 2015 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 05 Jan 2015 10:13:30 +0000 Subject: [issue18644] Got ResourceWarning: unclosed file when using test function from formatter module In-Reply-To: <1375537519.43.0.405840418589.issue18644@psf.upfronthosting.co.za> Message-ID: <1420452810.11.0.616193152762.issue18644@psf.upfronthosting.co.za> Eric V. Smith added the comment: Good point on contextlib.closing not being needed. I usually use this pattern on things that aren't files! On second thought, the with statement will close sys.stdin, so this isn't a valid pattern here. Sorry for the noise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 11:14:00 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 05 Jan 2015 10:14:00 +0000 Subject: [issue20284] patch to implement PEP 461 (%-interpolation for bytes) In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <1420452840.15.0.127862947354.issue20284@psf.upfronthosting.co.za> STINNER Victor added the comment: Hi. I proposed twice to Ethan to implement the PEP 461, but he replied that he wants to implement it. So, what's the status of the implementation? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 11:16:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 05 Jan 2015 10:16:52 +0000 Subject: [issue18644] Got ResourceWarning: unclosed file when using test function from formatter module In-Reply-To: <1375537519.43.0.405840418589.issue18644@psf.upfronthosting.co.za> Message-ID: <1420453012.31.0.857144419443.issue18644@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I prefer the current code (i.e. formatter_fix_resource_warning_v5.patch). In more complex case ExitStack can be used, but here it looks redundant. with contextlib.ExitStack() as stack: if some_test: fl = open(sys.argv[1]) stack.enter_context(fl) else: fl = sys.stdin do_stuff(fl) or if some_test: cm = fl = open(sys.argv[1]) else: fl = sys.stdin cm = contextlib.ExitStack() with cm: do_stuff(fl) ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 11:19:03 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 05 Jan 2015 10:19:03 +0000 Subject: [issue20284] patch to implement PEP 461 (%-interpolation for bytes) In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <1420453143.28.0.397793949286.issue20284@psf.upfronthosting.co.za> STINNER Victor added the comment: I would be nice to share as much code as possible with the Unicode implementation. My idea was to add a "_PyBytesWriter" API, very close to the "_PyUnicodeWriter", to share code. Old patch implementing the _PyBytesWriter API: issue #17742 (rejected because it was less efficient, the compiler produces less efficient machine code). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 13:18:38 2015 From: report at bugs.python.org (Dmitrijs Ledkovs) Date: Mon, 05 Jan 2015 12:18:38 +0000 Subject: [issue23168] test_file2k.py depends on sys.stdin being unseekable Message-ID: <1420460318.93.0.946671821792.issue23168@psf.upfronthosting.co.za> New submission from Dmitrijs Ledkovs: # LD_LIBRARY_PATH=`pwd` ./python Lib/test/regrtest.py test_file2k _______________________________________ From report at bugs.python.org Mon Jan 5 13:21:02 2015 From: report at bugs.python.org (Dmitrijs Ledkovs) Date: Mon, 05 Jan 2015 12:21:02 +0000 Subject: [issue23168] test_file2k.py depends on sys.stdin being unseekable In-Reply-To: <1420460318.93.0.946671821792.issue23168@psf.upfronthosting.co.za> Message-ID: <1420460462.98.0.852320962976.issue23168@psf.upfronthosting.co.za> Changes by Dmitrijs Ledkovs : ---------- components: +Installation versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 13:21:47 2015 From: report at bugs.python.org (Dmitrijs Ledkovs) Date: Mon, 05 Jan 2015 12:21:47 +0000 Subject: [issue23168] test_file2k.py depends on sys.stdin being unseekable In-Reply-To: <1420460318.93.0.946671821792.issue23168@psf.upfronthosting.co.za> Message-ID: <1420460507.82.0.601425811377.issue23168@psf.upfronthosting.co.za> Changes by Dmitrijs Ledkovs : ---------- keywords: +patch Added file: http://bugs.python.org/file37603/issue23168.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 14:01:30 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 05 Jan 2015 13:01:30 +0000 Subject: [issue23168] test_file2k.py depends on sys.stdin being unseekable In-Reply-To: <1420460318.93.0.946671821792.issue23168@psf.upfronthosting.co.za> Message-ID: <1420462890.13.0.0180113402639.issue23168@psf.upfronthosting.co.za> STINNER Victor added the comment: Removing a test when it doesn't pass is not the correct way to fix a test... I would be better to write it differently to support seekable stdin. Or if it doesn't make sense, skip the test if stdin is seeable. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 14:03:59 2015 From: report at bugs.python.org (Dimitri John Ledkov) Date: Mon, 05 Jan 2015 13:03:59 +0000 Subject: [issue23168] test_file2k.py depends on sys.stdin being unseekable In-Reply-To: <1420460318.93.0.946671821792.issue23168@psf.upfronthosting.co.za> Message-ID: <1420463039.26.0.535403839412.issue23168@psf.upfronthosting.co.za> Dimitri John Ledkov added the comment: > Removing a test when it doesn't pass is not the correct way to fix a test... Whilst I agree, this is not what was done in http://bugs.python.org/issue14853 . There it was concluded that the test itself is bogus and tests essentially nothing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 14:18:11 2015 From: report at bugs.python.org (Radek Simko) Date: Mon, 05 Jan 2015 13:18:11 +0000 Subject: [issue23169] Reflect that PreReq and BuildPreReq are deprecated in the latest RPM Message-ID: <1420463891.72.0.774842309991.issue23169@psf.upfronthosting.co.za> New submission from Radek Simko: When I try to make custom package of Python 2.7, I use the spec file attached in `/Misc/RPM`. I don't really use it to build Python as I want to define some specific options, but I do use it as a source of RPM package meta data which I can simply reuse when creating the final RPM, e.g.: rpm -q --specfile ./Misc/RPM/python-2.7.spec --queryformat '%{DESCRIPTION}' Manipulation with that specfile in RPM 4.4.2.3 (CentOS 5.6) is fine, but there are warnings in RPM 4.8.0 (CentOS 6.5): warning: line 71: buildprereq is deprecated: BuildPrereq: expat-devel warning: line 72: buildprereq is deprecated: BuildPrereq: db4-devel warning: line 73: buildprereq is deprecated: BuildPrereq: gdbm-devel warning: line 74: buildprereq is deprecated: BuildPrereq: sqlite-devel warning: line 91: prereq is deprecated: Prereq: python2.6 = %{PACKAGE_VERSION} warning: line 122: prereq is deprecated: Prereq: python2.6 = %{PACKAGE_VERSION}-1pydotorg Here's related thread: https://groups.google.com/forum/#!topic/comp.lang.python/R8ahiZ5wyhc and most importantly here's proof/explanation: http://www.rpm.org/wiki/Releases/4.8.0#Packagebuilding - PreReq and BuildPreReq are now officially deprecated, with warnings at build-time - PreReq is mapped to Requires(pre,preun) at build-time Requires(pre,preun) is backwards compatible, so it works in RPM 4.4 too, I would therefore suggest to change "[Build]Prereq" to "[Build]Requires(pre,preun)" respectively in the specfile to reflect this. I'm happy to send a patch if some maintainers will agree with proposed solution. ---------- components: Build messages: 233462 nosy: radeksimko priority: normal severity: normal status: open title: Reflect that PreReq and BuildPreReq are deprecated in the latest RPM type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 14:51:19 2015 From: report at bugs.python.org (Dima Tisnek) Date: Mon, 05 Jan 2015 13:51:19 +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: <1420465879.93.0.984378505636.issue9303@psf.upfronthosting.co.za> Dima Tisnek added the comment: Is there any hope? Surely sqlite backwards compatibility is not an issue any longer... ---------- nosy: +Dima.Tisnek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 15:03:54 2015 From: report at bugs.python.org (Swen Wenzel) Date: Mon, 05 Jan 2015 14:03:54 +0000 Subject: [issue9634] Add timeout parameter to Queue.join() In-Reply-To: <1282153581.83.0.092560551276.issue9634@psf.upfronthosting.co.za> Message-ID: <1420466634.26.0.0351319948499.issue9634@psf.upfronthosting.co.za> Swen Wenzel added the comment: I have another use case. The Docs use the producer-consumer pattern as a usage example. I'm also using this pattern but apparently the consumers are not that stable during development phase. So if one of your consumers dies during execution of its task, before it can say 'task done', then you will have a deadlock. You could of course avoid this by adding a finally block which will claim the task is done even if there was some error or exception but then you will lie to the producer! And suppose you only have one consumer and there are still tasks waiting (which is the case for my application), then you'll still have a deadlock since nobody is there to execute the remaining tasks. This could be solved by putting the exception handling within the consumer's mainloop like this: Consumer(Thread): def __init__(self, queue): self.queue = queue def run(): while True: task = self.queue.get() try: # execute task except: # handle exception (hopefully) without reraising one finally: self.queue.task_done() This way, however, the producer won't notice any issues unless the consumer's exception handler sets a flag or puts the exception into a collection that can be checked by the producer. But even that is no solution if the consumer executes a task with an endless loop or runs into a deadlock itself. I would propose to throw an exception if queue.Queue.join() returns because of a timeout since then you can investigate the cause within the exception handler and do not have to check for the consumer's status after each join(). But this is microoptimization so I would also be satisfied with the same solution as for threading.Thread.join(). ---------- nosy: +Swen.Wenzel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 15:21:02 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 05 Jan 2015 14:21:02 +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: <1420467662.25.0.00647536516543.issue9303@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 17:15:50 2015 From: report at bugs.python.org (Demian Brecht) Date: Mon, 05 Jan 2015 16:15:50 +0000 Subject: [issue20898] Missing 507 response description In-Reply-To: <1394637244.26.0.361164120424.issue20898@psf.upfronthosting.co.za> Message-ID: <1420474550.22.0.992238910458.issue20898@psf.upfronthosting.co.za> Demian Brecht added the comment: The attached patch is a rework of the http.HTTPStatus docs to include links to the RFCs. While working through this, I noticed that I may have been a little overzealous in inclusion of some of the status codes. Some non-standard codes have been deprecated or collide between vendors. As such, I've removed non-standard codes. The only ones supported are those that are IANA-registered (including experimental codes). This is to reduce the chance of future conflicts. These were only recently added for 3.5 and therefore should not cause any backwards compatibility issues. ---------- Added file: http://bugs.python.org/file37604/issue20898.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 17:31:41 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 05 Jan 2015 16:31:41 +0000 Subject: [issue15795] Zipfile.extractall does not preserve file permissions In-Reply-To: <1346106964.12.0.723201722432.issue15795@psf.upfronthosting.co.za> Message-ID: <1420475501.47.0.133372860621.issue15795@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 17:45:07 2015 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 05 Jan 2015 16:45:07 +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: <1420476307.79.0.59871726118.issue9303@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 18:00:05 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 05 Jan 2015 17:00:05 +0000 Subject: [issue20898] Missing 507 response description In-Reply-To: <1394637244.26.0.361164120424.issue20898@psf.upfronthosting.co.za> Message-ID: <1420477205.86.0.84812937206.issue20898@psf.upfronthosting.co.za> Berker Peksag added the comment: LGTM. Great patch, thanks! ---------- assignee: -> berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 18:12:35 2015 From: report at bugs.python.org (Dimitri John Ledkov) Date: Mon, 05 Jan 2015 17:12:35 +0000 Subject: [issue23170] test_uuid test_ifconfig_getnode fails with Temporary failure in name resolution Message-ID: <1420477955.33.0.233419644536.issue23170@psf.upfronthosting.co.za> New submission from Dimitri John Ledkov: Building 3.4.2, running testsuite on linux, test_uuid test_ifconfig_getnode fails as following: [365/388] test_uuid Warning -- sys.path was modified by test_site test test_uuid failed -- Traceback (most recent call last): File "/builddir/build/BUILD/Python-3.4.2/Lib/test/test_uuid.py", line 318, in test_ifconfig_getnode node = uuid._ifconfig_getnode() File "/builddir/build/BUILD/Python-3.4.2/Lib/uuid.py", line 356, in _ifconfig_getnode ip_addr = socket.gethostbyname(socket.gethostname()) socket.gaierror: [Errno -3] Temporary failure in name resolution Note that "Use of the 'network' resource not enabled" ---------- components: Installation messages: 233467 nosy: xnox priority: normal severity: normal status: open title: test_uuid test_ifconfig_getnode fails with Temporary failure in name resolution type: compile error versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 18:18:17 2015 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Mon, 05 Jan 2015 17:18:17 +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: <1420478297.25.0.362145718989.issue9303@psf.upfronthosting.co.za> Gerhard H?ring added the comment: ok, i will have to look into this ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 18:30:54 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 05 Jan 2015 17:30:54 +0000 Subject: [issue23170] test_uuid test_ifconfig_getnode fails with Temporary failure in name resolution In-Reply-To: <1420477955.33.0.233419644536.issue23170@psf.upfronthosting.co.za> Message-ID: <1420479054.97.0.671941468842.issue23170@psf.upfronthosting.co.za> R. David Murray added the comment: That traceback doesn't match the uuid.py source, nor has _ifconfig_getnode been modified for quite some time. A line like your traceback says is in _ifconfig_getnode actually appears in _arp_getnode. The arp_getnode test would presumably have the same problem, since it is also not protected by either; however, that call to socket in uuid.py, which is the only such call in the file, is protected by a try/except for OSError, so no error should be bubbling up from it. Can you investigate further, please? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 18:31:42 2015 From: report at bugs.python.org (Jon Dufresne) Date: Mon, 05 Jan 2015 17:31:42 +0000 Subject: [issue23171] csv.writer.writerow() does not accept generator (must be coerced to list) Message-ID: <1420479102.66.0.846752030326.issue23171@psf.upfronthosting.co.za> New submission from Jon Dufresne: The csv.writer.writerow() does not accept a generator as input. I find this counter-intuitive and against the spirit of similar APIs. If the generator is coerced to a list, everything works as expected. See the following test script which fails on the line "w.writerow(g)". In my opinion, this line should work identically to the line "w.writerow(list(g))". --- import csv f = open('foo.csv', 'w') w = csv.writer(f) g = (i for i in ['a', 'b', 'c']) w.writerow(list(g)) g = (i for i in ['a', 'b', 'c']) w.writerow(g) --- ---------- components: Library (Lib) messages: 233470 nosy: jdufresne priority: normal severity: normal status: open title: csv.writer.writerow() does not accept generator (must be coerced to list) type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 18:38:11 2015 From: report at bugs.python.org (Dimitri John Ledkov) Date: Mon, 05 Jan 2015 17:38:11 +0000 Subject: [issue23170] test_uuid test_ifconfig_getnode fails with Temporary failure in name resolution In-Reply-To: <1420477955.33.0.233419644536.issue23170@psf.upfronthosting.co.za> Message-ID: <1420479491.45.0.0472208070694.issue23170@psf.upfronthosting.co.za> Dimitri John Ledkov added the comment: The source code matches 3.4.2 tarball exactly. There is no arp_getnode test that I can see. 316 @unittest.skipUnless(os.name == 'posix', 'requires Posix') 317 def test_ifconfig_getnode(self): 318 node = uuid._ifconfig_getnode() 319 if node is not None: 320 self.check_node(node, 'ifconfig') 346def _ifconfig_getnode(): 347 """Get the hardware address on Unix by running ifconfig.""" 348 349 # This works on Linux ('' or '-a'), Tru64 ('-av'), but not all Unixes. 350 for args in ('', '-a', '-av'): 351 mac = _find_mac('ifconfig', args, ['hwaddr', 'ether'], lambda i: i+1) 352 if mac: 353 return mac 354 355 import socket 356 ip_addr = socket.gethostbyname(socket.gethostname()) 357 358 # Try getting the MAC addr from arp based on our IP address (Solaris). 359 mac = _find_mac('arp', '-an', [ip_addr], lambda i: -1) 360 if mac: 361 return mac 362 363 # This might work on HP-UX. 364 mac = _find_mac('lanscan', '-ai', ['lan0'], lambda i: 0) 365 if mac: 366 return mac 367 368 return None And I do not see any try/except protections around it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 18:53:08 2015 From: report at bugs.python.org (Dimitri John Ledkov) Date: Mon, 05 Jan 2015 17:53:08 +0000 Subject: [issue23170] test_uuid test_ifconfig_getnode fails with Temporary failure in name resolution In-Reply-To: <1420477955.33.0.233419644536.issue23170@psf.upfronthosting.co.za> Message-ID: <1420480388.16.0.158635268623.issue23170@psf.upfronthosting.co.za> Dimitri John Ledkov added the comment: I guess this is related to http://bugs.python.org/issue17293 however I get a test-suite fail / exception there with 3.4.2 on Linux. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 18:55:00 2015 From: report at bugs.python.org (Dimitri John Ledkov) Date: Mon, 05 Jan 2015 17:55:00 +0000 Subject: [issue17293] uuid.getnode() MAC address on AIX In-Reply-To: <1361777348.15.0.791534887595.issue17293@psf.upfronthosting.co.za> Message-ID: <1420480500.2.0.926060728828.issue17293@psf.upfronthosting.co.za> Dimitri John Ledkov added the comment: I'm getting socket.gaierror from test_ifconfig_getnode / uuid._ifconfig_getnode() on python 3.4.2 on Linux, in a no network environment. Thus i'd like to see these try:/excepts: to be ported back to 3.4 branch, if they haven't been already. I filed http://bugs.python.org/issue23170 to track my issue. Feel free to close that one as a (related) dupe of this one. ---------- nosy: +xnox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 19:24:30 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 05 Jan 2015 18:24:30 +0000 Subject: [issue23170] test_uuid test_ifconfig_getnode fails with Temporary failure in name resolution In-Reply-To: <1420477955.33.0.233419644536.issue23170@psf.upfronthosting.co.za> Message-ID: <1420482270.18.0.225188704447.issue23170@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, I see what happened. Serhiy split _ifconfig_getnode, so when I did an hg annotate it looked like _ifconfig_getnode was untouched, but in fact it had been split to create the _arp_getnode function. So, this report is out of date, this has already been fixed in 3.4. ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 19:30:54 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 05 Jan 2015 18:30:54 +0000 Subject: [issue23171] csv.writer.writerow() does not accept generator (must be coerced to list) In-Reply-To: <1420479102.66.0.846752030326.issue23171@psf.upfronthosting.co.za> Message-ID: <1420482654.98.0.617944276474.issue23171@psf.upfronthosting.co.za> R. David Murray added the comment: This seems like a sensible enhancement request to me. It is possible it could even be considered a bug, the docs aren't exactly clear on what 'row' is expected to be. ---------- keywords: +easy nosy: +r.david.murray stage: -> needs patch type: behavior -> enhancement versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 20:13:24 2015 From: report at bugs.python.org (Demian Brecht) Date: Mon, 05 Jan 2015 19:13:24 +0000 Subject: [issue14134] xmlrpc.client.ServerProxy needs timeout parameter In-Reply-To: <1330294741.21.0.00592117933576.issue14134@psf.upfronthosting.co.za> Message-ID: <1420485204.4.0.673162680839.issue14134@psf.upfronthosting.co.za> Changes by Demian Brecht : Removed file: http://bugs.python.org/file37481/issue14134.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 20:24:34 2015 From: report at bugs.python.org (Demian Brecht) Date: Mon, 05 Jan 2015 19:24:34 +0000 Subject: [issue14134] xmlrpc.client.ServerProxy needs timeout parameter In-Reply-To: <1330294741.21.0.00592117933576.issue14134@psf.upfronthosting.co.za> Message-ID: <1420485874.95.0.0973826513848.issue14134@psf.upfronthosting.co.za> Demian Brecht added the comment: I withdraw my patch as (I just discovered), it is already possible to effect changes to the underlying connection. What /should/ be done is: transport = Transport() con = transport.make_connection([host]) con.timeout = 2 proxy = ServerProxy([url], transport=transport) As the connection will not be created until an RPC method is called, the timeout value assigned to the connection will be observed on socket creation. Making such modifications to the underlying transport should be documented. That said, what is a little less than optimal is that the transport attribute of a ServerProxy object is inaccessible (without hackery) after instantiation, so socket level changes are impossible if not using a custom transport. What would be nice would be to add an accessor for ServerProxy.__transport. Likewise, Transport._connection is marked as part of the private interface. Adding public accessors would allow for something like this: proxy = ServerProxy([url]) # pre-connect timeout proxy.transport.connection.timeout = 2 proxy.system.listMethods() or proxy = ServerProxy([url]) proxy.system.listMethods() # socket is available as connection has been established proxy.transport.connection.sock.settimeout(2) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 20:35:05 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 05 Jan 2015 19:35:05 +0000 Subject: [issue23160] Respect the environment variable SVNROOT in external-common.bat In-Reply-To: <1420356909.91.0.987880987929.issue23160@psf.upfronthosting.co.za> Message-ID: <1420486505.66.0.682913547922.issue23160@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 20:35:12 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 05 Jan 2015 19:35:12 +0000 Subject: [issue23160] Respect the environment variable SVNROOT in external-common.bat In-Reply-To: <1420356909.91.0.987880987929.issue23160@psf.upfronthosting.co.za> Message-ID: <1420486512.5.0.983086248255.issue23160@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 21:10:44 2015 From: report at bugs.python.org (Jurijs Vorotilovs) Date: Mon, 05 Jan 2015 20:10:44 +0000 Subject: [issue23166] urllib2 ignores opener configuration under certain circumstances In-Reply-To: <1420406037.0.0.986455895168.issue23166@psf.upfronthosting.co.za> Message-ID: <1420488644.01.0.171134578071.issue23166@psf.upfronthosting.co.za> Jurijs Vorotilovs added the comment: Attached a script demonstrating two failing cases ---------- Added file: http://bugs.python.org/file37605/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 22:12:41 2015 From: report at bugs.python.org (Wayne Song) Date: Mon, 05 Jan 2015 21:12:41 +0000 Subject: [issue23172] Bad file descriptor error occurs if random library is imported before closing FDs Message-ID: <1420492361.28.0.389548963786.issue23172@psf.upfronthosting.co.za> New submission from Wayne Song: The following script: import os import resource import random print("1") for fd in range(resource.getrlimit(resource.RLIMIT_NOFILE)[0]): try: if fd not in range(0, 3): os.close(fd) except os.error: pass print("2") print(os.urandom(32)) print("3") Crashes with the following output: 1 2 Traceback (most recent call last): File "test.py", line 17, in print(os.urandom(32)) OSError: [Errno 9] Bad file descriptor On an Ubuntu 14.04 install (in VirtualBox). It seems to run correctly on Mac OS X. The script runs fine if I don't import random at the top. ---------- components: Library (Lib) messages: 233478 nosy: waynesong priority: normal severity: normal status: open title: Bad file descriptor error occurs if random library is imported before closing FDs type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 22:27:53 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 05 Jan 2015 21:27:53 +0000 Subject: [issue23172] Bad file descriptor error occurs if random library is imported before closing FDs In-Reply-To: <1420492361.28.0.389548963786.issue23172@psf.upfronthosting.co.za> Message-ID: <1420493273.74.0.337560815629.issue23172@psf.upfronthosting.co.za> STINNER Victor added the comment: This issue is a duplicate of the issue #21207 which was already fixed in Python 3.4.1. ---------- nosy: +haypo resolution: -> duplicate status: open -> closed superseder: -> urandom persistent fd - not re-openned after fd close _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 22:42:53 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 05 Jan 2015 21:42:53 +0000 Subject: [issue23140] InvalidStateError on asyncio subprocess task cancelled In-Reply-To: <1420019773.34.0.176587493323.issue23140@psf.upfronthosting.co.za> Message-ID: <1420494173.53.0.00163817549936.issue23140@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh no. My comment was not published, it was probably an issue with my unstable Internet connection. Here is a patch fixing the issue with an unit test. There is another call to Future.set_result() in subprocess.py not protected by an if in connection_made(). I don't know if it should be patched too or not. ---------- keywords: +patch Added file: http://bugs.python.org/file37606/asyncio_subprocess_cancel_wait.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 5 22:44:38 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 05 Jan 2015 21:44:38 +0000 Subject: [issue23046] asyncio.BaseEventLoop is documented, but only exported via asyncio.base_events In-Reply-To: <1418454792.43.0.104807870648.issue23046@psf.upfronthosting.co.za> Message-ID: <1420494278.04.0.301534353924.issue23046@psf.upfronthosting.co.za> STINNER Victor added the comment: What do you think of my first change, base_event_loop.patch, which exposes BaseEventLoop? I'm going to commit it if nobody reviews it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 00:05:38 2015 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 05 Jan 2015 23:05:38 +0000 Subject: [issue23046] asyncio.BaseEventLoop is documented, but only exported via asyncio.base_events In-Reply-To: <1418454792.43.0.104807870648.issue23046@psf.upfronthosting.co.za> Message-ID: <1420499138.62.0.855037188266.issue23046@psf.upfronthosting.co.za> Guido van Rossum added the comment: Sure. I already said LGTM on the patch (http://bugs.python.org/issue23046#msg232783). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 00:18:26 2015 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 05 Jan 2015 23:18:26 +0000 Subject: [issue23140] InvalidStateError on asyncio subprocess task cancelled In-Reply-To: <1420019773.34.0.176587493323.issue23140@psf.upfronthosting.co.za> Message-ID: <1420499906.83.0.263917366364.issue23140@psf.upfronthosting.co.za> Guido van Rossum added the comment: The patch looks good, although the test feels overly complex (but maybe I'm missing something). I'm okay with leaving the other unguarded set_result() call unchanged, but I'm also okay with putting "if not self.waiter.cancelled():" around it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 00:36:21 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 05 Jan 2015 23:36:21 +0000 Subject: [issue23166] urllib2 ignores opener configuration under certain circumstances In-Reply-To: <1420406037.0.0.986455895168.issue23166@psf.upfronthosting.co.za> Message-ID: <1420500981.08.0.45588482933.issue23166@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I guess there needs to be some generic way to pass ssl information to handlers. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 00:58:20 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Mon, 05 Jan 2015 23:58:20 +0000 Subject: [issue23086] Add start and stop parameters to the Sequence.index() ABC mixin method In-Reply-To: <1418935306.72.0.256960321979.issue23086@psf.upfronthosting.co.za> Message-ID: <1420502300.38.0.408010278201.issue23086@psf.upfronthosting.co.za> Devin Jeanpierre added the comment: A wild patch appears! Test is included, I'm unhappy with it, because it uses one test method to test all of Sequence, but that's what the test suite does for MutableSequence. ---------- keywords: +patch nosy: +Devin Jeanpierre Added file: http://bugs.python.org/file37607/issue23086.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 01:00:45 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Jan 2015 00:00:45 +0000 Subject: [issue23173] asyncio: kill the subprocess if the creation failed Message-ID: <1420502445.76.0.9797827832.issue23173@psf.upfronthosting.co.za> New submission from STINNER Victor: The creation of a subprocess in asyncio is complex, it is composed of multiple steps (callbacks scheduled by call_soon, coroutines, etc.). The creation can fail because of different reasons. I guess that the most common reason is a cancellation of a task, explicitly or because of a timeout (asyncio.wait_for). I propose to ensure that everything is cleaned up on failure, especially to kill the subprocess. This choice comes from the subprocess module, it kills the subprocess on error. Attached patch implements this change. It also fixes a bug noticed in the issue #23140: a call to waiter.set_result() in SubprocessStreamProtocol.connection_made() is not protected by a test on the future state. When I wrote the unit tests, I tried to mock subprocess.Popen to ensure that the Popen.kill() method is called, but mocking a subprocess for asyncio is complex. I chose to keep the test simple. ---------- components: asyncio files: asyncio_subprocess_kill.patch keywords: patch messages: 233486 nosy: gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio: kill the subprocess if the creation failed versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37608/asyncio_subprocess_kill.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 01:01:38 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Jan 2015 00:01:38 +0000 Subject: [issue23140] InvalidStateError on asyncio subprocess task cancelled In-Reply-To: <1420019773.34.0.176587493323.issue23140@psf.upfronthosting.co.za> Message-ID: <1420502498.02.0.105218117751.issue23140@psf.upfronthosting.co.za> STINNER Victor added the comment: > I'm okay with leaving the other unguarded set_result() call unchanged, but I'm also okay with putting "if not self.waiter.cancelled():" around it. While playing with asyncio to try to inject errors on this code path, I found even more severe issues: see the issue #23173 which proposes to fix them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 01:05:22 2015 From: report at bugs.python.org (Karl Richter) Date: Tue, 06 Jan 2015 00:05:22 +0000 Subject: [issue23174] shelve.open fails with error "anydbm.error: db type could not be determined" Message-ID: <1420502722.34.0.451688646321.issue23174@psf.upfronthosting.co.za> New submission from Karl Richter: `shelve.open(tempfile.mkstemp()[1])` fails with error "anydbm.error: db type could not be determined" which is not explainable with the docs. Traceback is Traceback (most recent call last): File "./cudaminer_param_checker.py", line 720, in plac.call(cudaminer_param_checker) File "/usr/local/lib/python2.7/dist-packages/plac_core.py", line 309, in call cmd, result = parser_from(obj).consume(arglist) File "/usr/local/lib/python2.7/dist-packages/plac_core.py", line 195, in consume return cmd, self.func(*(args + varargs + extraopts), **kwargs) File "./cudaminer_param_checker.py", line 715, in cudaminer_param_checker visualize_cudaminer_param_checker_results_wxpython_gui() File "./cudaminer_param_checker.py", line 365, in visualize_cudaminer_param_checker_results_wxpython_gui frame = CudaminerParamChecker(None, ) File "./cudaminer_param_checker.py", line 378, in __init__ self.generator = CudaminerParamCheckerGenerator() File "./cudaminer_param_checker.py", line 160, in __init__ self.result_dict= shelve.open(storage_file_path) File "/usr/lib/python2.7/shelve.py", line 239, in open return DbfilenameShelf(filename, flag, protocol, writeback) File "/usr/lib/python2.7/shelve.py", line 223, in __init__ Shelf.__init__(self, anydbm.open(filename, flag), protocol, writeback) File "/usr/lib/python2.7/anydbm.py", line 82, in open raise error, "db type could not be determined" anydbm.error: db type could not be determined ---------- assignee: docs at python components: Documentation messages: 233488 nosy: docs at python, krichter priority: normal severity: normal status: open title: shelve.open fails with error "anydbm.error: db type could not be determined" type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 01:05:52 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 06 Jan 2015 00:05:52 +0000 Subject: [issue23046] asyncio.BaseEventLoop is documented, but only exported via asyncio.base_events In-Reply-To: <1418454792.43.0.104807870648.issue23046@psf.upfronthosting.co.za> Message-ID: <20150106000540.8753.12599@psf.io> Roundup Robot added the comment: New changeset ddf6b78faed9 by Victor Stinner in branch '3.4': Issue #23046: Expose the BaseEventLoop class in the asyncio namespace https://hg.python.org/cpython/rev/ddf6b78faed9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 01:12:21 2015 From: report at bugs.python.org (Karl Richter) Date: Tue, 06 Jan 2015 00:12:21 +0000 Subject: [issue23174] shelve.open fails with error "anydbm.error: db type could not be determined" In-Reply-To: <1420502722.34.0.451688646321.issue23174@psf.upfronthosting.co.za> Message-ID: <1420503141.27.0.822737050629.issue23174@psf.upfronthosting.co.za> Karl Richter added the comment: EDIT 1: other examples, e.g. import os import shelve curdir = os.path.dirname(__file__) passwords = shelve.open(os.path.join(curdir, 'password_db')) work, so there's need for usable error messages. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 01:14:58 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 06 Jan 2015 00:14:58 +0000 Subject: [issue23140] InvalidStateError on asyncio subprocess task cancelled In-Reply-To: <1420019773.34.0.176587493323.issue23140@psf.upfronthosting.co.za> Message-ID: <20150106001452.8769.67395@psf.io> Roundup Robot added the comment: New changeset 7c9b9d2514bb by Victor Stinner in branch '3.4': Issue #23140, asyncio: Fix cancellation of Process.wait(). Check the state of https://hg.python.org/cpython/rev/7c9b9d2514bb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 01:23:57 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 06 Jan 2015 00:23:57 +0000 Subject: [issue23140] InvalidStateError on asyncio subprocess task cancelled In-Reply-To: <1420019773.34.0.176587493323.issue23140@psf.upfronthosting.co.za> Message-ID: <20150106002347.72579.14604@psf.io> Roundup Robot added the comment: New changeset 990ce80d8283 by Victor Stinner in branch '3.4': Issue #23140, asyncio: Simplify the unit test https://hg.python.org/cpython/rev/990ce80d8283 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 01:25:59 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Jan 2015 00:25:59 +0000 Subject: [issue23140] InvalidStateError on asyncio subprocess task cancelled In-Reply-To: <1420019773.34.0.176587493323.issue23140@psf.upfronthosting.co.za> Message-ID: <1420503959.62.0.638475000321.issue23140@psf.upfronthosting.co.za> STINNER Victor added the comment: Thanks Xavier for the bug report, it should now be fixed. Sorry, I don't see any workaround right now (except of using the development version of Tulip). > The patch looks good, although the test feels overly complex (but maybe I'm missing something). Oh, I commited the change before seeing that you posted a review on Rietveld. I modified the unit test to simplify it, the new code is enough to trigger the bug. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 01:34:40 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Jan 2015 00:34:40 +0000 Subject: [issue22696] Add a function to know about interpreter shutdown In-Reply-To: <1413980453.04.0.451789079104.issue22696@psf.upfronthosting.co.za> Message-ID: <1420504480.86.0.672578432927.issue22696@psf.upfronthosting.co.za> STINNER Victor added the comment: > Using the function in the stdlib can be done separately. Is there an open issue for that? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 01:36:24 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Jan 2015 00:36:24 +0000 Subject: [issue22428] asyncio: KeyboardInterrupt inside a coroutine causes AttributeError In-Reply-To: <1410939370.36.0.183370883396.issue22428@psf.upfronthosting.co.za> Message-ID: <1420504584.2.0.68055084137.issue22428@psf.upfronthosting.co.za> STINNER Victor added the comment: A lot of fixes has been commited to fix this general issue with asyncio at exit. run_until_complete() doesn't log an error anymore when a BaseException (like KeyboardInterrupted) is raised. The caller is able to decide how to handle it. The traceback module has been enhanced to try to fix the "AttributeError: 'module' object has no attribute 'open'" error (or at least reduce the risk of such error). A better solution is being developed. The initial issue was fixed, I close the issue. Thanks for the report Jack. Sorry, I forgot to update this issue since it was splitted in many smaller and more specific issues. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 01:54:53 2015 From: report at bugs.python.org (Laimis) Date: Tue, 06 Jan 2015 00:54:53 +0000 Subject: [issue23175] logging.exception doesn't accept custom exc_info Message-ID: <1420505693.63.0.867428622164.issue23175@psf.upfronthosting.co.za> New submission from Laimis: Documentation says, that "The arguments are interpreted as for debug()." But it's not true, because no matter what exc_info is passed to logging.exception(), exc_info is overwritten (kwargs['exc_info'] = 1) and later self.error is called. This is either documentation issue or behavior issue, because in the current implementation it's not possible to pass custom exc_info (e.g. full traceback) to logging.exception(), although documentation implies it should work the same as for info, warning, error, debug and others. ---------- components: Library (Lib) messages: 233496 nosy: laimis priority: normal severity: normal status: open title: logging.exception doesn't accept custom exc_info type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 01:58:51 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 06 Jan 2015 00:58:51 +0000 Subject: [issue23174] shelve.open fails with error "anydbm.error: db type could not be determined" In-Reply-To: <1420502722.34.0.451688646321.issue23174@psf.upfronthosting.co.za> Message-ID: <1420505931.13.0.768421732874.issue23174@psf.upfronthosting.co.za> R. David Murray added the comment: You are opening a just-created empty file. The db type of the file cannot, therefore, be determined. Which is what the error message says. How would you suggest the error message be improved? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 02:07:05 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 06 Jan 2015 01:07:05 +0000 Subject: [issue23174] shelve.open fails with error "anydbm.error: db type could not be determined" In-Reply-To: <1420502722.34.0.451688646321.issue23174@psf.upfronthosting.co.za> Message-ID: <1420506425.69.0.536734666429.issue23174@psf.upfronthosting.co.za> R. David Murray added the comment: Sorry, I mean "an empty file with no recognized extension". I doubt supplying a suffix is what you want, though, since you probably want shelve to pick the persistent backend on db creation in order to be portable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 02:58:55 2015 From: report at bugs.python.org (Karl Richter) Date: Tue, 06 Jan 2015 01:58:55 +0000 Subject: [issue23174] shelve.open fails with error "anydbm.error: db type could not be determined" In-Reply-To: <1420502722.34.0.451688646321.issue23174@psf.upfronthosting.co.za> Message-ID: <1420509535.46.0.30738907687.issue23174@psf.upfronthosting.co.za> Karl Richter added the comment: Then, let the error message say "You are opening a just-created empty file. The db type of the file cannot, therefore, be determined." which is much clearer than "anydbm.error: db type could not be determined" which sounds like a generic fallback error message in "an error occured"-style. It seems to be necessary that the filename passed to `shelve.open` has a suffix which is not very intuitive for Linux users. It'd be great to have validation of the suffix and raise a `ValueError` with an error message like `"filename '%s' doesn't contain a suffix" % (filename,)` when it isn't supplied. If there's another issue regarding the fact that the file is "just-created" and empty, this is independent of the issue above. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 03:58:37 2015 From: report at bugs.python.org (Sworddragon) Date: Tue, 06 Jan 2015 02:58:37 +0000 Subject: [issue23176] socket.recvfrom(0) waits for data Message-ID: <1420513117.73.0.631111386058.issue23176@psf.upfronthosting.co.za> New submission from Sworddragon: For example on sending ICMP packets and receiving the data socket.recv(1) does wait for data while socket.recv(0) doesn't. socket.recvfrom(1) does wait for data too but I'm also seeing that socket.recvfrom(0) is waiting for data which doesn't look correct (at least it seems not to be consistent with socket.recv()). ---------- components: Library (Lib) messages: 233500 nosy: Sworddragon priority: normal severity: normal status: open title: socket.recvfrom(0) waits for data type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 04:39:45 2015 From: report at bugs.python.org (Jon Dufresne) Date: Tue, 06 Jan 2015 03:39:45 +0000 Subject: [issue23171] csv.writer.writerow() does not accept generator (must be coerced to list) In-Reply-To: <1420479102.66.0.846752030326.issue23171@psf.upfronthosting.co.za> Message-ID: <1420515585.03.0.673215439962.issue23171@psf.upfronthosting.co.za> Jon Dufresne added the comment: I have created an initial patch such that writerow() now allows generators. I have also added a unit test to demonstrate the fix. The code now coerces iterators (and generators) to a list, then operates on the result. I would have preferred to simply iterate over the argument, however, there is a special case where the length of the argument is exactly 1. So coercing to a list makes checking the length simpler. All feedback welcome. ---------- keywords: +patch Added file: http://bugs.python.org/file37609/csv-gen.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 04:49:15 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 06 Jan 2015 03:49:15 +0000 Subject: [issue23176] socket.recvfrom(0) waits for data In-Reply-To: <1420513117.73.0.631111386058.issue23176@psf.upfronthosting.co.za> Message-ID: <1420516155.08.0.680098667706.issue23176@psf.upfronthosting.co.za> Benjamin Peterson added the comment: That's not surprising, since revcfrom uses select() on the socket regardless of the value its argument. I'm not sure what the use of calling revcfrom(0) is. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 05:13:22 2015 From: report at bugs.python.org (Sworddragon) Date: Tue, 06 Jan 2015 04:13:22 +0000 Subject: [issue23176] socket.recvfrom(0) waits for data In-Reply-To: <1420513117.73.0.631111386058.issue23176@psf.upfronthosting.co.za> Message-ID: <1420517602.98.0.38244665312.issue23176@psf.upfronthosting.co.za> Sworddragon added the comment: If there is no real use for socket.recvfrom(0) (and then probably socket.recv(0) too) maybe a bufsize argument of 0 should throw an exception? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 07:00:42 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 06 Jan 2015 06:00:42 +0000 Subject: [issue23132] Faster total_ordering In-Reply-To: <1419931329.13.0.970719266671.issue23132@psf.upfronthosting.co.za> Message-ID: <20150106060014.72553.11704@psf.io> Roundup Robot added the comment: New changeset 09b0da38ce8d by Raymond Hettinger in branch '3.4': Issue #23132: Mitigate regression in speed and clarity in functools.total_ordering. https://hg.python.org/cpython/rev/09b0da38ce8d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 07:06:04 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 06 Jan 2015 06:06:04 +0000 Subject: [issue19548] 'codecs' module docs improvements In-Reply-To: <1384133353.82.0.173341188397.issue19548@psf.upfronthosting.co.za> Message-ID: <1420524364.85.0.193241859199.issue19548@psf.upfronthosting.co.za> Martin Panter added the comment: Adding patch v5, for the 3.4 branch. There is at least one reference that still needs fixing in the default branch that is not applicable to the 3.4 branch. Main changes from Nick?s patch: * Removed sentence now redundant with introduction to open() and EncodedFile() * Fixed wording to allow for missing surrogateescape_errors() etc * Changed heading to clarify Codec objects are stateless * Restored relaxation for StreamWriter writing to text stream * New wording under ?Encodings and Unicode? * Update cross references to new ?Error Handlers? section ---------- Added file: http://bugs.python.org/file37610/issue19548-codecs-doc.v5.py3.4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 07:22:55 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 06 Jan 2015 06:22:55 +0000 Subject: [issue23132] Faster total_ordering In-Reply-To: <1419931329.13.0.970719266671.issue23132@psf.upfronthosting.co.za> Message-ID: <1420525375.91.0.682662752399.issue23132@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 08:01:24 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 06 Jan 2015 07:01:24 +0000 Subject: [issue23099] BytesIO and StringIO values unavailable when closed In-Reply-To: <1419248477.31.0.512702147737.issue23099@psf.upfronthosting.co.za> Message-ID: <1420527684.68.0.617630849721.issue23099@psf.upfronthosting.co.za> Martin Panter added the comment: Updated patch, to also document the BytesIO buffer is no longer available when closed. The StringIO documentation actually already says this, but I rarely use StringIO. :) ---------- Added file: http://bugs.python.org/file37611/bytesio_exported_reject_close.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 09:19:03 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 06 Jan 2015 08:19:03 +0000 Subject: [issue23175] logging.exception doesn't accept custom exc_info In-Reply-To: <1420505693.63.0.867428622164.issue23175@psf.upfronthosting.co.za> Message-ID: <1420532343.27.0.639146521043.issue23175@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 09:22:58 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 06 Jan 2015 08:22:58 +0000 Subject: [issue23174] shelve.open fails with error "anydbm.error: db type could not be determined" In-Reply-To: <1420502722.34.0.451688646321.issue23174@psf.upfronthosting.co.za> Message-ID: <1420532578.74.0.0816548372148.issue23174@psf.upfronthosting.co.za> R. David Murray added the comment: The problem is that this is not the only situation in which that error can be generated. If someone passed in an "old" (and possibly non-empty) file with no extension, the same code path would get executed. The shelve/anydbm API is database agnostic, so there is no way to know a-priori what the valid extensions are. The whichdbm module (which anydbm uses) could provide this information in theory, but it doesn't currently, and if it did that would be a new API. Your problem is that the shelve API is designed so that you either pass it the base name of an existing database, *or* you pass it the base name of a *non* existent database, which it then creates all the right files for (there may be more than one file). The fact that you are passing it a new existing file is the problem, and I'm not sure the error message can be effectively improved to handle that particular mistaken use of the API without breaking the message for the places it is more meaningful. The best I can think of is to add the filename to the error message and list all the extensions and (if there are any) the 'magic' type guesses that whichdbm tried, but as I said that would be a new feature and thus could only go into 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 09:26:10 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 06 Jan 2015 08:26:10 +0000 Subject: [issue23171] csv.writer.writerow() does not accept generator (must be coerced to list) In-Reply-To: <1420479102.66.0.846752030326.issue23171@psf.upfronthosting.co.za> Message-ID: <1420532770.26.0.451160292368.issue23171@psf.upfronthosting.co.za> R. David Murray added the comment: Hmm. That could be an issue. If someone passes a generator they will generally expect it to be consumed as a generator, not turned into a list implicitly. So it may be better to turn this into a doc bug and require the explicit "list" call :(. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 09:57:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 06 Jan 2015 08:57:56 +0000 Subject: [issue23171] csv.writer.writerow() does not accept generator (must be coerced to list) In-Reply-To: <1420479102.66.0.846752030326.issue23171@psf.upfronthosting.co.za> Message-ID: <1420534676.98.0.806713757625.issue23171@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The docs mention that "row" should be a sequence, so there is no a bug. Here is a patch which makes writerow() accept an iterable without converting it to a list. It also adds tests for few corner cases and fixes the docs. ---------- nosy: +serhiy.storchaka stage: needs patch -> patch review Added file: http://bugs.python.org/file37612/csv_writerow_iterable.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 10:05:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 06 Jan 2015 09:05:33 +0000 Subject: [issue23132] Faster total_ordering In-Reply-To: <1420525375.94.0.408412876657.issue23132@psf.upfronthosting.co.za> Message-ID: <2519359.eKDZSmUWHi@raxxla> Serhiy Storchaka added the comment: May be implement your idea about local NotImplemented? And it would be good to add explaining comments in _le_from_lt() and _ge_from_gt() as in your original suggestion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 11:22:53 2015 From: report at bugs.python.org (Karl Richter) Date: Tue, 06 Jan 2015 10:22:53 +0000 Subject: [issue23174] shelve.open fails with error "anydbm.error: db type could not be determined" In-Reply-To: <1420502722.34.0.451688646321.issue23174@psf.upfronthosting.co.za> Message-ID: <1420539773.04.0.190553571596.issue23174@psf.upfronthosting.co.za> Karl Richter added the comment: That's nice, thanks. Considering your last comment, some points * If the issue can't go into the error message, than the essence of the discussion here should go into the docs (in 0.5 to 1.5 sentences). * It'd be nice if it was clear from the error message that shelve or underlying modules check the extension in filename, i.e. do `anydbm.error: db type could not be determined by file extension '%s' in filename '%s'` rather than `anydbm.error: db type could not be determined`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 11:28:30 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 06 Jan 2015 10:28:30 +0000 Subject: [issue21741] Convert most of the test suite to using unittest.main() In-Reply-To: <1402608565.65.0.506633774065.issue21741@psf.upfronthosting.co.za> Message-ID: <1420540110.46.0.15921847274.issue21741@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 11:39:03 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Tue, 06 Jan 2015 10:39:03 +0000 Subject: [issue23140] InvalidStateError on asyncio subprocess task cancelled In-Reply-To: <1420019773.34.0.176587493323.issue23140@psf.upfronthosting.co.za> Message-ID: <1420540743.27.0.995301824631.issue23140@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > Thanks Xavier for the bug report, it should now be fixed. Works fine with me. Thanks for the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 11:41:38 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Jan 2015 10:41:38 +0000 Subject: [issue19776] Provide expanduser() on Path objects In-Reply-To: <1385409778.55.0.842571848249.issue19776@psf.upfronthosting.co.za> Message-ID: <1420540898.4.0.76884321883.issue19776@psf.upfronthosting.co.za> STINNER Victor added the comment: The test fails on the buildbot "PPC64 AIX 3.x". It looks like the home directory of the buildbot slave user is /home/shager/. http://buildbot.python.org/all/builders/PPC64%20AIX%203.x/builds/2994/steps/test/logs/stdio ====================================================================== FAIL: test_expanduser (test.test_pathlib.PosixPathTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_pathlib.py", line 2002, in test_expanduser self.assertEqual(p3.expanduser(), P(otherhome) / 'Documents') AssertionError: PosixPath('/Documents') != PosixPath('Documents') ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 11:54:16 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Jan 2015 10:54:16 +0000 Subject: [issue23177] test_ssl: failures on OpenBSD with LibreSSL Message-ID: <1420541656.17.0.750310163886.issue23177@psf.upfronthosting.co.za> New submission from STINNER Victor: (See also the issue #21356.) http://buildbot.python.org/all/builders/x86%20OpenBSD%205.5%203.x/builds/1242/steps/test/logs/stdio ====================================================================== FAIL: test_options (test.test_ssl.ContextTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_ssl.py", line 764, in test_options ctx.options) AssertionError: -2130705409 != -2097150977 ====================================================================== FAIL: test_openssl_version (test.test_ssl.BasicSocketTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_ssl.py", line 315, in test_openssl_version (s, t)) AssertionError: False is not true : ('LibreSSL 2.1', (2, 0, 0, 0, 0)) ---------- components: Tests messages: 233514 nosy: haypo, rpointel priority: normal severity: normal status: open title: test_ssl: failures on OpenBSD with LibreSSL versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 11:56:23 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 06 Jan 2015 10:56:23 +0000 Subject: [issue23151] _loggerClass is initialized twice In-Reply-To: <1420214673.16.0.25178792027.issue23151@psf.upfronthosting.co.za> Message-ID: <20150106105620.11563.47003@psf.io> Roundup Robot added the comment: New changeset 8bfe230db0bc by Vinay Sajip in branch 'default': Closes #23151: Removed unnecessary initialization. https://hg.python.org/cpython/rev/8bfe230db0bc ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 12:08:37 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 06 Jan 2015 11:08:37 +0000 Subject: [issue19776] Provide expanduser() on Path objects In-Reply-To: <1385409778.55.0.842571848249.issue19776@psf.upfronthosting.co.za> Message-ID: <1420542517.44.0.564541881077.issue19776@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't really know how to investigate that failure. Perhaps David wants to look into it? ---------- nosy: +David.Edelsohn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 12:15:13 2015 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 06 Jan 2015 11:15:13 +0000 Subject: [issue23175] logging.exception doesn't accept custom exc_info In-Reply-To: <1420505693.63.0.867428622164.issue23175@psf.upfronthosting.co.za> Message-ID: <1420542913.54.0.0141968429331.issue23175@psf.upfronthosting.co.za> Vinay Sajip added the comment: 2.7 documentation has now been updated. The behaviour has already been changed for Python 3.5 to forward any exc_info passed in (see Issue #20537). ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 12:16:51 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Jan 2015 11:16:51 +0000 Subject: [issue19776] Provide expanduser() on Path objects In-Reply-To: <1385409778.55.0.842571848249.issue19776@psf.upfronthosting.co.za> Message-ID: <1420543011.79.0.778379535462.issue19776@psf.upfronthosting.co.za> STINNER Victor added the comment: > I don't really know how to investigate that failure. I don't think that it's specific to AIX, it just depends on the list of users on your system. On my Fedora 21, I have many users which have an empty home directory: - nobody - dbus - polkitd - usbmuxd - nm-openconnect - tcpdump - qemu - radvd - systemd-journal-gateway - systemd-timesync - systemd-network - systemd-resolve - systemd-bus-proxy If the test pick one of this user instead of a user with a non-empty home directory, the test fails with the same error. I propose a simple patch: test_pathlib_empty_homedir.patch ---------- Added file: http://bugs.python.org/file37613/test_pathlib_empty_homedir.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 12:18:11 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Jan 2015 11:18:11 +0000 Subject: [issue23177] test_ssl: failures on OpenBSD with LibreSSL In-Reply-To: <1420541656.17.0.750310163886.issue23177@psf.upfronthosting.co.za> Message-ID: <1420543091.1.0.553975825742.issue23177@psf.upfronthosting.co.za> STINNER Victor added the comment: changeset: 94041:87976d72fd5c user: Victor Stinner date: Tue Jan 06 11:51:06 2015 +0100 files: Lib/test/test_ssl.py description: test_ssl: add more debug to investigate test_openssl_version() failure on OpenBSD with LibreSSL. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 12:19:58 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 06 Jan 2015 11:19:58 +0000 Subject: [issue21980] Implement `logging.LogRecord.__repr__` In-Reply-To: <1405361946.16.0.0808006509696.issue21980@psf.upfronthosting.co.za> Message-ID: <20150106111953.72581.28276@psf.io> Roundup Robot added the comment: New changeset 390ffd39631b by Vinay Sajip in branch 'default': Closes #21980: Added a __repr__ for LogRecord. https://hg.python.org/cpython/rev/390ffd39631b ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 12:24:05 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 06 Jan 2015 11:24:05 +0000 Subject: [issue20896] test_ssl.test_get_server_certificate() should use PROTOCOL_SSLv23, not PROTOCOL_SSLv3 In-Reply-To: <1394623240.06.0.245086264312.issue20896@psf.upfronthosting.co.za> Message-ID: <20150106112349.72565.80546@psf.io> Roundup Robot added the comment: New changeset a8c4925e2359 by Victor Stinner in branch '3.4': Issue #20896, #22935: The ssl.get_server_certificate() function now uses the https://hg.python.org/cpython/rev/a8c4925e2359 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 12:24:05 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 06 Jan 2015 11:24:05 +0000 Subject: [issue22935] Disabling SSLv3 support In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za> Message-ID: <20150106112349.72565.69701@psf.io> Roundup Robot added the comment: New changeset a8c4925e2359 by Victor Stinner in branch '3.4': Issue #20896, #22935: The ssl.get_server_certificate() function now uses the https://hg.python.org/cpython/rev/a8c4925e2359 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 12:24:59 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Jan 2015 11:24:59 +0000 Subject: [issue22935] Disabling SSLv3 support In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za> Message-ID: <1420543499.42.0.45269403751.issue22935@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, I commited my change to Python 3.4. I'm now waiting for the following buildbot before closing the issue: http://buildbot.python.org/all/builders/x86%20Tiger%203.4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 12:25:52 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 06 Jan 2015 11:25:52 +0000 Subject: [issue20284] patch to implement PEP 461 (%-interpolation for bytes) In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <1420543552.09.0.342462006574.issue20284@psf.upfronthosting.co.za> Nick Coghlan added the comment: With the first alpha next month, unless we hear otherwise from Ethan in the next day or two, I'd suggest going ahead with the implementation. We can always tweak it during the alpha cycle if there are specific details he'd like to see changed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 12:40:02 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 06 Jan 2015 11:40:02 +0000 Subject: [issue23168] test_file2k.py depends on sys.stdin being unseekable In-Reply-To: <1420460318.93.0.946671821792.issue23168@psf.upfronthosting.co.za> Message-ID: <20150106113957.11569.52450@psf.io> Roundup Robot added the comment: New changeset 7f30206d402f by Victor Stinner in branch '2.7': Issue #23168: skip sys.stdin.seek() test if stdin is not a TTY https://hg.python.org/cpython/rev/7f30206d402f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 12:40:31 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Jan 2015 11:40:31 +0000 Subject: [issue23168] test_file2k.py depends on sys.stdin being unseekable In-Reply-To: <1420460318.93.0.946671821792.issue23168@psf.upfronthosting.co.za> Message-ID: <1420544431.51.0.316878310775.issue23168@psf.upfronthosting.co.za> STINNER Victor added the comment: Instead of removing the test, I modified it to be skipped if stdin is not a TTY. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 12:43:33 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Jan 2015 11:43:33 +0000 Subject: [issue14853] test_file.py depends on sys.stdin being unseekable In-Reply-To: <1337367006.89.0.99847274779.issue14853@psf.upfronthosting.co.za> Message-ID: <1420544613.56.0.228659695826.issue14853@psf.upfronthosting.co.za> STINNER Victor added the comment: The same issue was reported for test_file2k: issue #23168. I modified test_file2k to skip sys.stdin.seek() test if stdin is not a TTY. I prefer to skip a test in a specific case, instead of removing it completly. I propose to add again the test in test_file, with the skip. See test_file.patch for Python 2.7 (I will addapt it to Python 3 if the patch is accepted for Python 2). ---------- nosy: +haypo resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 12:43:40 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Jan 2015 11:43:40 +0000 Subject: [issue14853] test_file.py depends on sys.stdin being unseekable In-Reply-To: <1337367006.89.0.99847274779.issue14853@psf.upfronthosting.co.za> Message-ID: <1420544620.76.0.745932323877.issue14853@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file37614/test_file.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 12:46:26 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Jan 2015 11:46:26 +0000 Subject: [issue19777] Provide a home() classmethod on Path objects In-Reply-To: <1385409863.35.0.0114355564026.issue19777@psf.upfronthosting.co.za> Message-ID: <1420544786.96.0.251848575385.issue19777@psf.upfronthosting.co.za> STINNER Victor added the comment: I agree that Path.home() is more user friendly than Path.expanduser('~'). ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 12:56:57 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Jan 2015 11:56:57 +0000 Subject: [issue1687125] cannot catch KeyboardInterrupt when using curses getkey() Message-ID: <1420545417.42.0.485191986428.issue1687125@psf.upfronthosting.co.za> STINNER Victor added the comment: I cannot reproduce it on Python 2.7.9+. I get the following output which is the expected output: --- -1 CTRL-C --- Since this bug is 8 years old. I guess that the bug was already fixed, or maybe it can only be reproduced on a specific platform. But the platform or the specific conditions to reproduce the issue were not described. I close this issue. ---------- nosy: +haypo resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 12:59:27 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Jan 2015 11:59:27 +0000 Subject: [issue3180] Interrupts are lost during readline PyOS_InputHook processing In-Reply-To: <1214238743.53.0.342771827236.issue3180@psf.upfronthosting.co.za> Message-ID: <1420545567.76.0.502586132979.issue3180@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't understand how to reproduce the issue, there is no unit test nor a description how to reproduce the issue. I'm not aware of a bug where CTRL+c is simply ignored. CTRL+c is now well handled in Python 2.7, on Linux and Windows at least. Since the bug is now 7 years old, I just close it as out of date, sorry. ---------- nosy: +haypo resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 13:01:17 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Jan 2015 12:01:17 +0000 Subject: [issue1103213] Adding the missing socket.recvall() method Message-ID: <1420545677.13.0.820073639871.issue1103213@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 13:29:41 2015 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 06 Jan 2015 12:29:41 +0000 Subject: [issue23010] "unclosed file" warning when defining unused logging FileHandler in dictConfig In-Reply-To: <1418046415.01.0.116582999558.issue23010@psf.upfronthosting.co.za> Message-ID: <1420547381.63.0.218120180719.issue23010@psf.upfronthosting.co.za> Vinay Sajip added the comment: Data point: if you print out _handlerList immediately after the dictConfig() call, it *is* there, as I would have expected. The following script saved as logtest6.py: from datetime import datetime from time import sleep import sys if __name__ == '__main__': LOGGING = { 'version': 1, 'handlers': { 'logfile': { 'level': 'DEBUG', 'class': 'logging.FileHandler', 'filename': '/tmp/debug.log', }, }, } print('%s: starting' % (datetime.now(),)) from logging.config import dictConfig dictConfig(LOGGING) from logging import _handlerList print('%s: after dictconfig' % (datetime.now(),)) sys.stdout.flush() print('_handlerList 1:', _handlerList) # using importlib on a new file triggers the warnings import importlib, shutil, os print('_handlerList 2:', _handlerList) shutil.copy(__file__, __file__ + '.new') os.unlink(__file__) os.rename(__file__ + '.new', __file__) importlib.import_module('logtest6') sys.stderr.flush() print('%s: after error' % (datetime.now(),)) sys.stdout.flush() sleep(5) print('%s: after sleep' % (datetime.now(),)) # Vinay Sajip wrote: # > The handlers are AFAIK referenced - if you peek at # logging._handlerList or logging._handlers you should see them in # there. from logging import _handlerList, _handlers print('_handlerList 3:', _handlerList) else: print('imported once') When run, yields $ python3.4 logtest6.py 2015-01-06 12:26:46.910634: starting 2015-01-06 12:26:47.290223: after dictconfig _handlerList 1: [] /home/vinay/projects/python/3.4/Lib/collections/__init__.py:373: ResourceWarning: unclosed file <_io.FileIO name='/tmp/debug.log' mode='ab'> exec(class_definition, namespace) _handlerList 2: [] imported once 2015-01-06 12:26:47.388877: after error 2015-01-06 12:26:52.394514: after sleep _handlerList 3: [] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 13:35:21 2015 From: report at bugs.python.org (Idoa) Date: Tue, 06 Jan 2015 12:35:21 +0000 Subject: [issue22391] MSILIB truncates last character in summary information stream In-Reply-To: <1410454409.06.0.0184961474822.issue22391@psf.upfronthosting.co.za> Message-ID: <1420547721.13.0.880730033162.issue22391@psf.upfronthosting.co.za> Idoa added the comment: Encountered this issue also in python 2.7.7. last character is replaced with \x00. reproduction is exactly as stated by Kevin.Phillips ---------- nosy: +Idoa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 13:41:26 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Jan 2015 12:41:26 +0000 Subject: [issue22935] Disabling SSLv3 support In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za> Message-ID: <1420548086.64.0.184340781437.issue22935@psf.upfronthosting.co.za> STINNER Victor added the comment: > I'm now waiting for the following buildbot before closing the issue: > http://buildbot.python.org/all/builders/x86%20Tiger%203.4 Before my change, test_ssl because with "NameError: name 'PROTOCOL_SSLv3' is not defined". With my change, test_ssl now pass. I close the issue. Python 2.7, 3.4 and 3.5 all now have the same behaviour. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 13:43:41 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Jan 2015 12:43:41 +0000 Subject: [issue23177] test_ssl: failures on OpenBSD with LibreSSL In-Reply-To: <1420541656.17.0.750310163886.issue23177@psf.upfronthosting.co.za> Message-ID: <1420548221.14.0.312697956648.issue23177@psf.upfronthosting.co.za> STINNER Victor added the comment: It looks like OPENSSL_VERSION_NUMBER is consistent with OPENSSL_VERSION_INFO (version 2.1). But the OPENSSL_VERSION contains a different version (2.0). It looks like an issue in LibreSSL. ====================================================================== FAIL: test_openssl_version (test.test_ssl.BasicSocketTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/python-builds/3.x.borja-openbsd-x86/build/Lib/test/test_ssl.py", line 315, in test_openssl_version (s, t, hex(n))) AssertionError: False is not true : ('LibreSSL 2.1', (2, 0, 0, 0, 0), '0x20000000') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 14:01:08 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 06 Jan 2015 13:01:08 +0000 Subject: [issue23177] test_ssl: failures on OpenBSD with LibreSSL In-Reply-To: <1420541656.17.0.750310163886.issue23177@psf.upfronthosting.co.za> Message-ID: <20150106130029.11567.29367@psf.io> Roundup Robot added the comment: New changeset 05d7550bd2d9 by Victor Stinner in branch 'default': Issue #23177: Document that ssl.RAND_egd() is not available with LibreSSL https://hg.python.org/cpython/rev/05d7550bd2d9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 14:01:08 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 06 Jan 2015 13:01:08 +0000 Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd optional In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za> Message-ID: <20150106130029.11567.14907@psf.io> Roundup Robot added the comment: New changeset eddcb6671a48 by Victor Stinner in branch '2.7': Issue #21356: Make ssl.RAND_egd() optional to support LibreSSL. The https://hg.python.org/cpython/rev/eddcb6671a48 New changeset 7f82f50fdad0 by Victor Stinner in branch '3.4': Issue #21356: Make ssl.RAND_egd() optional to support LibreSSL. The https://hg.python.org/cpython/rev/7f82f50fdad0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 14:01:52 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Jan 2015 13:01:52 +0000 Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd optional In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za> Message-ID: <1420549312.56.0.826648740345.issue21356@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, Python 2.7, 3.4 and 3.5 can now be *compiled* with LibreSSL. There are still issues with LibreSSL: see the new issue #23177. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 14:01:58 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Jan 2015 13:01:58 +0000 Subject: [issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd optional In-Reply-To: <1398522096.15.0.100207892067.issue21356@psf.upfronthosting.co.za> Message-ID: <1420549318.17.0.626448230622.issue21356@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 14:06:33 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Jan 2015 13:06:33 +0000 Subject: [issue22638] ssl module: the SSLv3 protocol is vulnerable ("POODLE" attack) In-Reply-To: <1413328275.88.0.275500633746.issue22638@psf.upfronthosting.co.za> Message-ID: <1420549593.14.0.15673809106.issue22638@psf.upfronthosting.co.za> STINNER Victor added the comment: Can we close this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 14:09:37 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 06 Jan 2015 13:09:37 +0000 Subject: [issue23145] regrtest: log test loader errors In-Reply-To: <1420151939.5.0.279924205041.issue23145@psf.upfronthosting.co.za> Message-ID: <20150106130921.72559.69146@psf.io> Roundup Robot added the comment: New changeset 1bb3df5bb83f by Victor Stinner in branch 'default': Issue #23145: regrtest now shows errors and raises an exception if https://hg.python.org/cpython/rev/1bb3df5bb83f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 14:09:59 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Jan 2015 13:09:59 +0000 Subject: [issue23145] regrtest: log test loader errors In-Reply-To: <1420151939.5.0.279924205041.issue23145@psf.upfronthosting.co.za> Message-ID: <1420549799.96.0.0540040295768.issue23145@psf.upfronthosting.co.za> STINNER Victor added the comment: I chose to show errors and then raise an exception. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 14:24:35 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Tue, 06 Jan 2015 13:24:35 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <1420550675.64.0.90452165639.issue22619@psf.upfronthosting.co.za> Dmitry Kazakov added the comment: Some of the patches (including the latest one) were missing Mercurial header. I'm uploading the properly formatted patch (traceback_rev_fixed.diff) ---------- Added file: http://bugs.python.org/file37615/traceback_rev_fixed.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 14:38:18 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 06 Jan 2015 13:38:18 +0000 Subject: [issue22638] ssl module: the SSLv3 protocol is vulnerable ("POODLE" attack) In-Reply-To: <1413328275.88.0.275500633746.issue22638@psf.upfronthosting.co.za> Message-ID: <1420551498.92.0.616969260049.issue22638@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think so, thank you. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 15:38:55 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 06 Jan 2015 14:38:55 +0000 Subject: [issue19548] 'codecs' module docs improvements In-Reply-To: <1384133353.82.0.173341188397.issue19548@psf.upfronthosting.co.za> Message-ID: <20150106143716.72575.26129@psf.io> Roundup Robot added the comment: New changeset 0646eee8296a by Nick Coghlan in branch '3.4': Issue 19548: update codecs module documentation https://hg.python.org/cpython/rev/0646eee8296a New changeset 4d00d0109147 by Nick Coghlan in branch 'default': Merge issue 19548 changes from 3.4 https://hg.python.org/cpython/rev/4d00d0109147 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 15:42:05 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 06 Jan 2015 14:42:05 +0000 Subject: [issue19548] 'codecs' module docs improvements In-Reply-To: <1384133353.82.0.173341188397.issue19548@psf.upfronthosting.co.za> Message-ID: <1420555325.1.0.552679971089.issue19548@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thanks for the work on this folks, both Jan for the feedback, Martin for the writing, and everyone else for their comments. I don't believe we addressed all of Jan's comments, but I'd like to request that any further comments be filed as separate issues, now that the larger restructure of the content is out of the way. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 16:03:50 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 06 Jan 2015 15:03:50 +0000 Subject: [issue22935] Disabling SSLv3 support In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za> Message-ID: <1420556630.36.0.0887467681116.issue22935@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 16:51:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 06 Jan 2015 15:51:13 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <1420559473.71.0.534232426372.issue22619@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 17:04:41 2015 From: report at bugs.python.org (Ethan Furman) Date: Tue, 06 Jan 2015 16:04:41 +0000 Subject: [issue20284] patch to implement PEP 461 (%-interpolation for bytes) In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <1420560281.27.0.0945494323224.issue20284@psf.upfronthosting.co.za> Ethan Furman added the comment: Here is what I have so far: - complete tests for bytes and bytearry (bytearray currently commented out at line 71) - pep461 implemented for bytes This is basically an adaptation of the 2.7 code for str, adjusted appropriately. I was planning on having bytearray convert to bytes, then call the bytes code, then integrate the results back into the existing bytearray (for %=) or create and return a new bytearray (for %). I can easily believe this is not the most efficient way to do it. ;) I should have the bytearray portion done, if not this weekend, then by the following weekend. I have no objections if Victor wants to combine and optimize with the unicode implementation (and no need to wait for me to finish the bytearray portion). ---------- Added file: http://bugs.python.org/file37616/issue20284.stoneleaf.01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 17:19:36 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Jan 2015 16:19:36 +0000 Subject: [issue20284] patch to implement PEP 461 (%-interpolation for bytes) In-Reply-To: <1420560281.27.0.0945494323224.issue20284@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Ethan, do you have a public repository? If no, you can for example fork CPython: click on "Server-side clone" at https://hg.python.org/cpython/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 17:36:41 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 06 Jan 2015 16:36:41 +0000 Subject: [issue23174] shelve.open fails with error "anydbm.error: db type could not be determined" In-Reply-To: <1420502722.34.0.451688646321.issue23174@psf.upfronthosting.co.za> Message-ID: <1420562201.84.0.864646994142.issue23174@psf.upfronthosting.co.za> R. David Murray added the comment: What is it you want the docs to say? For your second point, yes, that is what I was saying would be an enhancement (the extension is a list of possible extensions that varies per-platform and per how python is built/installed). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 19:40:32 2015 From: report at bugs.python.org (Ethan Furman) Date: Tue, 06 Jan 2015 18:40:32 +0000 Subject: [issue20284] patch to implement PEP 461 (%-interpolation for bytes) In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <1420569632.66.0.607151833718.issue20284@psf.upfronthosting.co.za> Ethan Furman added the comment: Sorry, no. And time is scarce at the moment so figuring out server-side clones will have to wait as well. I uploaded the patch of what I have so far -- hopefully that will be helpful. Also attaching patch with just the tests. ---------- Added file: http://bugs.python.org/file37617/issue20284.stoneleaf.tests_only.01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 20:05:06 2015 From: report at bugs.python.org (Jon Dufresne) Date: Tue, 06 Jan 2015 19:05:06 +0000 Subject: [issue23178] csv.reader does not handle BOM Message-ID: <1420571105.9.0.00648910593011.issue23178@psf.upfronthosting.co.za> New submission from Jon Dufresne: The following test script demonstrates that Python's csv library does not handle a BOM. I would expect the returned row to be equal to expected and to print 'True' to stdout. In the wild, it is typical for other CSV writers to add a BOM. MS Excel is especially picky about the BOM when reading a utf-8 encoded file. So many writers add a BOM for interopability with MS Excel. If a python program accepts a CSV file as input (often the case in web apps), these files will not be handled correctly without preprocessing. In my opinion, this should "just work" when reading the file. --- import codecs import csv f = open('foo.csv', 'wb') f.write(codecs.BOM_UTF8 + b'a,b,c') f.close() expected = ['a', 'b', 'c'] f = open('foo.csv') r = csv.reader(f) row = next(r) print(row) print(row == expected) --- Output --- $ ./python ~/test.py ['\ufeffa', 'b', 'c'] False --- ---------- components: Library (Lib) messages: 233549 nosy: jdufresne priority: normal severity: normal status: open title: csv.reader does not handle BOM type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 20:52:05 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 06 Jan 2015 19:52:05 +0000 Subject: [issue23178] csv.reader does not handle BOM In-Reply-To: <1420571105.9.0.00648910593011.issue23178@psf.upfronthosting.co.za> Message-ID: <1420573925.19.0.216940870875.issue23178@psf.upfronthosting.co.za> R. David Murray added the comment: This is not a problem with the csv module in particular. See issue 7651. ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Python3: guess text file charset using the BOM _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 22:07:52 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 06 Jan 2015 21:07:52 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <1420578472.55.0.698987516698.issue22619@psf.upfronthosting.co.za> Terry J. Reedy added the comment: For future reference, a better initial post would have been more self-contained and explanatory, something like the following. (If I got the proposal wrong, all the more reason to explain it clearly). --- Several functions in the traceback module take a *limit* argument to limit output to the first n 'stack trace entries'. This issue proposes that negative limits should instead limit output to the last n entries. This idea was discussed on python ideas and approved by Guido there. https://mail.python.org/pipermail/python-ideas/2014-October/029826.html. --- Do the new tests pass with n=0? If not, do the functions have a sensible behavior (print header and no entries, rather than raising) that could be tested? ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 23:02:33 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 06 Jan 2015 22:02:33 +0000 Subject: [issue19548] 'codecs' module docs improvements In-Reply-To: <1384133353.82.0.173341188397.issue19548@psf.upfronthosting.co.za> Message-ID: <1420581753.48.0.254950849305.issue19548@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks Nick. Here is a small followup patch for the default (3.5) branch to keep things consistent. ---------- Added file: http://bugs.python.org/file37618/default-branch-followup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 23:27:32 2015 From: report at bugs.python.org (Matt Mackall) Date: Tue, 06 Jan 2015 22:27:32 +0000 Subject: [issue14099] ZipFile.open() should not reopen the underlying file In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za> Message-ID: <1420583252.24.0.199690739933.issue14099@psf.upfronthosting.co.za> Matt Mackall added the comment: The committed fix breaks Mercurial. http://bz.selenic.com/show_bug.cgi?id=4492 The "underlying file-like object" in our case is a wsgirequest but anything else trying to serve a dynamically-generated zip file on the web will probably die. We wrapped wsgirequest to support tell() many years ago probably copying someone else's hack, and it's worked fine across Python 2.4-2.7, but we fundamentally can't support all the new seek()s that were added here. ---------- nosy: +Matt.Mackall _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 23:30:06 2015 From: report at bugs.python.org (Al Sweigart) Date: Tue, 06 Jan 2015 22:30:06 +0000 Subject: [issue17776] IDLE Internationalization In-Reply-To: <1366207983.79.0.104817094716.issue17776@psf.upfronthosting.co.za> Message-ID: <1420583406.26.0.752296159462.issue17776@psf.upfronthosting.co.za> Changes by Al Sweigart : ---------- nosy: +Al.Sweigart _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 6 23:30:10 2015 From: report at bugs.python.org (Al Sweigart) Date: Tue, 06 Jan 2015 22:30:10 +0000 Subject: [issue17760] No i18n of IDLE's interface in french In-Reply-To: <1366123345.09.0.872714866587.issue17760@psf.upfronthosting.co.za> Message-ID: <1420583410.9.0.0375509503064.issue17760@psf.upfronthosting.co.za> Changes by Al Sweigart : ---------- nosy: +Al.Sweigart _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 00:27:18 2015 From: report at bugs.python.org (Alessio Bogon) Date: Tue, 06 Jan 2015 23:27:18 +0000 Subject: [issue23179] New function proposal: string.from_iterable(iterable [, map_function]) Message-ID: <1420586838.31.0.418706320174.issue23179@psf.upfronthosting.co.za> New submission from Alessio Bogon: I would like to suggest a new string function/constructor: string.from_iterable(iterable [,map_function]) I think that the behaviour is intuitive: given an iterable, it construct a string using its element by apply a `map_function`, if provided, to each one of them. After that the str() constructor will be applied to each element in any way, to ensure that effectively an iterable of strings is used. Of course I do not expect that you will accept this patch, but I think this really is a missing piece of the python library. You can argue that I could just use "".join(iterable) but in my opinion there are two problems: 1) if any of the elements of `iterable` is not a `str` instance, it will fail miserably; 2) this is not very pythonic. This issue is meant to be an idea for the python maintainers, so I did not write the corresponding `Doc/libary/string.rst` documentation, but if you are interested I could do it. Thank you people for your amazing work. ---------- components: Library (Lib) files: string.from_iterable.patch keywords: patch messages: 233554 nosy: youtux priority: normal severity: normal status: open title: New function proposal: string.from_iterable(iterable [,map_function]) type: enhancement versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37619/string.from_iterable.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 00:34:50 2015 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 06 Jan 2015 23:34:50 +0000 Subject: [issue23179] New function proposal: string.from_iterable(iterable [, map_function]) In-Reply-To: <1420586838.31.0.418706320174.issue23179@psf.upfronthosting.co.za> Message-ID: <1420587290.86.0.791586643441.issue23179@psf.upfronthosting.co.za> Ezio Melotti added the comment: You should propose this to the python-ideas mailing list. FWIW, if this is accepted, I would use str as default map_function. ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 01:17:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 07 Jan 2015 00:17:18 +0000 Subject: [issue14099] ZipFile.open() should not reopen the underlying file In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za> Message-ID: <1420589838.49.0.998488688189.issue14099@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: fixed -> stage: resolved -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 03:09:31 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 07 Jan 2015 02:09:31 +0000 Subject: [issue23179] New function proposal: string.from_iterable(iterable [, map_function]) In-Reply-To: <1420586838.31.0.418706320174.issue23179@psf.upfronthosting.co.za> Message-ID: <1420596571.08.0.0758192389143.issue23179@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for wanting to contribute. However, I don't see why this function would be beneficial. As indicated by the patch, it is simply ''.join(str(map_function(x)) for x in iterable) but without the inherent flexibility of the above formulation. Which looks pretty Pythonic to my eyes :). We often say "not every one line expression deserves to be a function." But yes, python-ideas would be the appropriate forum to discuss such a thing. This issue can be reopened if you get consensus that it is a valuable addition. ---------- nosy: +r.david.murray resolution: -> later stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 03:11:09 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 07 Jan 2015 02:11:09 +0000 Subject: [issue23179] New function proposal: string.from_iterable(iterable [, map_function]) In-Reply-To: <1420586838.31.0.418706320174.issue23179@psf.upfronthosting.co.za> Message-ID: <1420596669.49.0.886907759843.issue23179@psf.upfronthosting.co.za> Josh Rosenberg added the comment: I'll note: "".join(map(str, iterable)) will solve problem #1. It's fast, uses existing built-ins, and is relatively intuitive. I know map is sometimes considered Pythonic, but "".join(str(x) for x in iterable) is an equally effective, if somewhat slower, alternative that can't be called un-Pythonic. I have no idea why you think "".join(iterable) is not Pythonic, it's *the* way to join strings into a single string. Fast, direct, simple. string.from_iterable seems like a silly way to do what "".join(map(INSERTFAVORITEFUNCTIONHERE, iterable)) does already, for no gain. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 03:11:36 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 07 Jan 2015 02:11:36 +0000 Subject: [issue23160] Respect the environment variable SVNROOT in external-common.bat In-Reply-To: <1420356909.91.0.987880987929.issue23160@psf.upfronthosting.co.za> Message-ID: <1420596696.74.0.2751064816.issue23160@psf.upfronthosting.co.za> Steve Dower added the comment: Don't have time to apply them right now, but the patches look fine. I guess it'll null-merge into default, since 3.5 is unaffected? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 03:11:51 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 07 Jan 2015 02:11:51 +0000 Subject: [issue23179] New function proposal: string.from_iterable(iterable [, map_function]) In-Reply-To: <1420586838.31.0.418706320174.issue23179@psf.upfronthosting.co.za> Message-ID: <1420596711.56.0.211728824518.issue23179@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Correction: I know map is sometimes considered *un-Pythonic ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 04:15:02 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 07 Jan 2015 03:15:02 +0000 Subject: [issue19548] 'codecs' module docs improvements In-Reply-To: <1384133353.82.0.173341188397.issue19548@psf.upfronthosting.co.za> Message-ID: <20150107031458.8753.30685@psf.io> Roundup Robot added the comment: New changeset 20a5a56ce090 by Nick Coghlan in branch 'default': Issue #19548: clean up merge issues in codecs docs https://hg.python.org/cpython/rev/20a5a56ce090 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 04:34:42 2015 From: report at bugs.python.org (Geoff Shannon) Date: Wed, 07 Jan 2015 03:34:42 +0000 Subject: [issue22865] Allow pty.spawn to ignore data to copy In-Reply-To: <1415901686.09.0.50650588621.issue22865@psf.upfronthosting.co.za> Message-ID: <1420601682.59.0.619479422482.issue22865@psf.upfronthosting.co.za> Geoff Shannon added the comment: I tweaked the patch a bit to not include the parentheses since that seems to be the style here. ---------- Added file: http://bugs.python.org/file37620/pty.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 05:59:02 2015 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 07 Jan 2015 04:59:02 +0000 Subject: [issue19548] 'codecs' module docs improvements In-Reply-To: <1384133353.82.0.173341188397.issue19548@psf.upfronthosting.co.za> Message-ID: <1420606742.49.0.344134282193.issue19548@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thanks for the follow-up patch Martin - I missed those when I did the merge forward from 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 07:21:34 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 07 Jan 2015 06:21:34 +0000 Subject: [issue13128] httplib debuglevel on CONNECT doesn't print response headers In-Reply-To: <1318050704.97.0.551622649018.issue13128@psf.upfronthosting.co.za> Message-ID: <1420611694.48.0.69488981938.issue13128@psf.upfronthosting.co.za> Demian Brecht added the comment: Just happened to come across this now. Updated patch with test. ---------- Added file: http://bugs.python.org/file37621/issue13128_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 07:40:58 2015 From: report at bugs.python.org (Al Sweigart) Date: Wed, 07 Jan 2015 06:40:58 +0000 Subject: [issue2704] IDLE: Patch to make PyShell behave more like a Terminal interface In-Reply-To: <1209319360.66.0.583090952017.issue2704@psf.upfronthosting.co.za> Message-ID: <1420612858.87.0.89543965253.issue2704@psf.upfronthosting.co.za> Changes by Al Sweigart : ---------- nosy: +Al.Sweigart _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 07:48:26 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 07 Jan 2015 06:48:26 +0000 Subject: [issue23086] Add start and stop parameters to the Sequence.index() ABC mixin method In-Reply-To: <1418935306.72.0.256960321979.issue23086@psf.upfronthosting.co.za> Message-ID: <1420613306.0.0.433179586837.issue23086@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This test looks like it may have been a typo: self.assertEqual(seq.index('a'), 0, 1) Also, it would be nice to investigate the differences with list.index() and str.index() for the corner cases. Something along these lines: # Compare Sequence.index() behavior to list.index() behavior listseq = list('abracadabra') seqseq = SequenceSubclass(listseq) for start in range(-3, len(listseq) + 3): for stop in range(-3, len(listseq) + 3): for letter in set(listseq + ['z']): try: expected = listseq.index(letter, start, stop) except ValueError: with self.assertRaises(ValueError): seqseq.index(letter, start, stop) else: actual = seqseq.index(letter, start, stop) self.assertEqual(actual, expected, (letter, start, stop)) # Compare Sequence.index() behavior to str.index() behavior strseq = 'abracadabra' seqseq = SequenceSubclass(strseq) for start in range(-3, len(strseq) + 3): for stop in range(-3, len(strseq) + 3): for letter in set(strseq + 'z'): try: expected = strseq.index(letter, start, stop) except ValueError: with self.assertRaises(ValueError): seqseq.index(letter, start, stop) else: actual = seqseq.index(letter, start, stop) self.assertEqual(actual, expected, (letter, start, stop) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 07:59:33 2015 From: report at bugs.python.org (Mike Basca) Date: Wed, 07 Jan 2015 06:59:33 +0000 Subject: [issue23156] Update tix install information in tkinter tix chapter of doc In-Reply-To: <1420322124.69.0.0233808198239.issue23156@psf.upfronthosting.co.za> Message-ID: <1420613973.33.0.213458545355.issue23156@psf.upfronthosting.co.za> Mike Basca added the comment: Hi, I'm the original poster in the stack-exchange link. Based on your responses, It seems Ttk is the way to go if you're on Mac OSX 64-bit. Thanks for your time and input. Really appreciate it! ---------- nosy: +abaskm _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 08:16:27 2015 From: report at bugs.python.org (Al Sweigart) Date: Wed, 07 Jan 2015 07:16:27 +0000 Subject: [issue23180] Rename IDLE's "Windows" menu item to "Window" Message-ID: <1420614987.43.0.350300091598.issue23180@psf.upfronthosting.co.za> New submission from Al Sweigart: Currently IDLE's top-level menu item is "Windows" on Windows & Linux but is specifically changed to "Window" on OS X to match mac's look and feel. See https://hg.python.org/cpython/rev/1b3b6b1982aa The singular "Window" is the standard menu name on all platforms, and "Windows" should never be used. Note: Photoshop, Blender, Visual Studio, IntelliJ, WinMerge, HxD, and Notepad++ on Windows use the "Window" name in their menus. I can't find any that use "Windows". ---------- components: IDLE files: patch.diff keywords: patch messages: 233566 nosy: Al.Sweigart priority: normal severity: normal status: open title: Rename IDLE's "Windows" menu item to "Window" type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file37622/patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 08:18:17 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 07 Jan 2015 07:18:17 +0000 Subject: [issue23179] New function proposal: string.from_iterable(iterable [, map_function]) In-Reply-To: <1420586838.31.0.418706320174.issue23179@psf.upfronthosting.co.za> Message-ID: <1420615097.8.0.444231112899.issue23179@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I concur with Josh and David. We already have a way to do it and there doesn't seem to be anything here that would warrant further growth of the already large number of string methods. ---------- nosy: +rhettinger resolution: later -> rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 09:43:48 2015 From: report at bugs.python.org (Al Sweigart) Date: Wed, 07 Jan 2015 08:43:48 +0000 Subject: [issue23181] Unicode "code point" should be two words in documentation Message-ID: <1420620228.26.0.565920670024.issue23181@psf.upfronthosting.co.za> New submission from Al Sweigart: According to http://unicode.org/glossary/ "codepoint" is incorrect and should be changed to "code point". ---------- assignee: docs at python components: Documentation files: code_point_patch.diff keywords: patch messages: 233568 nosy: Al.Sweigart, docs at python priority: normal severity: normal status: open title: Unicode "code point" should be two words in documentation type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37623/code_point_patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 09:49:05 2015 From: report at bugs.python.org (Ian Lee) Date: Wed, 07 Jan 2015 08:49:05 +0000 Subject: [issue23182] Update grammar tests to use new style Message-ID: <1420620545.16.0.862545867011.issue23182@psf.upfronthosting.co.za> New submission from Ian Lee: Per Guido's suggestion on the peps at python.org mailing list, I'm creating this issue to update the argument annotation tests at cpython/Lib/test/test_grammar.py to use the new style wording Guido requested on GitHub [1] that I proposed and was merged into PEP-8 [2] regarding annotated function definitions. [1] https://github.com/jcrocholl/pep8/issues/357#issuecomment-67527455 [2] https://hg.python.org/peps/rev/7eb1ddc0291c ---------- components: Library (Lib), Tests files: pep8-annotated-func-test-update.patch keywords: patch messages: 233569 nosy: IanLee1521, Rosuav, gvanrossum priority: normal severity: normal status: open title: Update grammar tests to use new style type: enhancement Added file: http://bugs.python.org/file37624/pep8-annotated-func-test-update.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 09:50:17 2015 From: report at bugs.python.org (Ian Lee) Date: Wed, 07 Jan 2015 08:50:17 +0000 Subject: [issue23182] Update grammar tests to use new style for annotated function definitions In-Reply-To: <1420620545.16.0.862545867011.issue23182@psf.upfronthosting.co.za> Message-ID: <1420620617.23.0.534753508737.issue23182@psf.upfronthosting.co.za> Changes by Ian Lee : ---------- title: Update grammar tests to use new style -> Update grammar tests to use new style for annotated function definitions _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 09:53:19 2015 From: report at bugs.python.org (Chathuranga) Date: Wed, 07 Jan 2015 08:53:19 +0000 Subject: [issue23183] timeit CLI best of 3: undocumented output format Message-ID: <1420620799.47.0.00516438922368.issue23183@psf.upfronthosting.co.za> New submission from Chathuranga: easy Following command is executed in terminal to use timeit module to measure time. python -m timeit -v -n 3 "time.sleep(1)" Output of the command: raw times: 3 3 3 3 loops, best of 3: 1 sec per loop The interpretation of this output is unclear, and no details available in the documentation. https://docs.python.org/2/library/timeit.html#command-line-interface ---------- assignee: docs at python components: Documentation messages: 233570 nosy: docs at python, hachat priority: normal severity: normal status: open title: timeit CLI best of 3: undocumented output format type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 10:57:59 2015 From: report at bugs.python.org (=?utf-8?q?J=C3=A9r=C3=A9mie_Detrey?=) Date: Wed, 07 Jan 2015 09:57:59 +0000 Subject: [issue2190] MozillaCookieJar ignore HttpOnly cookies In-Reply-To: <1203957546.34.0.123660895963.issue2190@psf.upfronthosting.co.za> Message-ID: <1420624679.63.0.168164620771.issue2190@psf.upfronthosting.co.za> J?r?mie Detrey added the comment: Dear all, In fact, this cookie.txt format is still used by curl. For instance, see https://github.com/bagder/curl/blob/curl-7_39_0/lib/cookie.c#L644 which clearly shows support for the "#HttpOnly_" prefix. Therefore, supporting this format in http.cookiejar.MozillaCookieJar seems quite relevant to me. Attached is an updated patch. Kind regards, J?r?mie. ---------- nosy: +jdetrey Added file: http://bugs.python.org/file37625/httponly.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 11:04:02 2015 From: report at bugs.python.org (=?utf-8?q?J=C3=A9r=C3=A9mie_Detrey?=) Date: Wed, 07 Jan 2015 10:04:02 +0000 Subject: [issue2190] MozillaCookieJar ignore HttpOnly cookies In-Reply-To: <1203957546.34.0.123660895963.issue2190@psf.upfronthosting.co.za> Message-ID: <1420625042.0.0.00454132801066.issue2190@psf.upfronthosting.co.za> Changes by J?r?mie Detrey : ---------- versions: +Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 11:24:35 2015 From: report at bugs.python.org (Marc Schlaich) Date: Wed, 07 Jan 2015 10:24:35 +0000 Subject: [issue5162] multiprocessing cannot spawn child from a Windows service In-Reply-To: <1233885632.9.0.0484597105973.issue5162@psf.upfronthosting.co.za> Message-ID: <1420626275.88.0.495543472208.issue5162@psf.upfronthosting.co.za> Marc Schlaich added the comment: This issue is not fully fixed, there are some occasions where you can still run into it. One example is if you want to spawn a new multiprocessing.Process as sub process in a multiprocessing.Process: pythonservice.exe - multiprocessing.Process - multiprocessing.Process (does not start!) In this case you get: WINSERVICE: False WINEXE: False _python_exe: C:\Python27\python.exe prep data: {'authkey': '...', 'sys_path': [...], 'name': 'test', 'orig_dir': '...', 'sys_argv': ['C:\\Python27\\lib\\site-packages\\win32\\PythonService.exe'], 'main_path': 'C:\\Python27\\lib\\site-packages\\win32\\PythonService.exe', 'log_to_stderr': False} ---------- nosy: +schlamar _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 11:26:51 2015 From: report at bugs.python.org (Al Sweigart) Date: Wed, 07 Jan 2015 10:26:51 +0000 Subject: [issue23184] Unused imports, variables, file in IDLE Message-ID: <1420626411.51.0.528702156456.issue23184@psf.upfronthosting.co.za> New submission from Al Sweigart: The IDLE code base has several unused imports and local variables. The testcode.py file seems to have been accidentally checked in. These changes were found through a lint program, not by hand. All idle unit tests pass after these changes. ---------- components: IDLE files: idle_unused_patch.diff keywords: patch messages: 233573 nosy: Al.Sweigart priority: normal severity: normal status: open title: Unused imports, variables, file in IDLE versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37626/idle_unused_patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 11:26:58 2015 From: report at bugs.python.org (Al Sweigart) Date: Wed, 07 Jan 2015 10:26:58 +0000 Subject: [issue23184] Unused imports, variables, file in IDLE In-Reply-To: <1420626411.51.0.528702156456.issue23184@psf.upfronthosting.co.za> Message-ID: <1420626418.92.0.539160145584.issue23184@psf.upfronthosting.co.za> Changes by Al Sweigart : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 11:33:05 2015 From: report at bugs.python.org (=?utf-8?q?J=C3=A9r=C3=A9mie_Detrey?=) Date: Wed, 07 Jan 2015 10:33:05 +0000 Subject: [issue17164] MozillaCookieJar does not handle session cookies In-Reply-To: <1360358603.06.0.441613239061.issue17164@psf.upfronthosting.co.za> Message-ID: <1420626785.52.0.43849470179.issue17164@psf.upfronthosting.co.za> J?r?mie Detrey added the comment: Dear all, Here is a small tentative patch for fixing this issue. Expiry times for session cookies are now written as "0", and both "0" and "" are parsed as valid expiry times for session cookies. Cheers, J?r?mie. ---------- keywords: +patch nosy: +jdetrey versions: +Python 3.6 Added file: http://bugs.python.org/file37627/session-cookies.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 11:57:12 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Wed, 07 Jan 2015 10:57:12 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <1420628232.23.0.464304751547.issue22619@psf.upfronthosting.co.za> Dmitry Kazakov added the comment: Thank you, Terry. You got the proposal right. I'm glad you noticed the issues with tests, I updated the patch to fix them. ---------- Added file: http://bugs.python.org/file37628/traceback_rev2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 12:26:33 2015 From: report at bugs.python.org (Bernard Spil) Date: Wed, 07 Jan 2015 11:26:33 +0000 Subject: [issue23177] test_ssl: failures on OpenBSD with LibreSSL In-Reply-To: <1420541656.17.0.750310163886.issue23177@psf.upfronthosting.co.za> Message-ID: <1420629993.73.0.865144630507.issue23177@psf.upfronthosting.co.za> Bernard Spil added the comment: Note that the FreeBSD port modifies the OPENSSL_VERSION_NUMBER and sets the version number to 1.0.1g. https://svnweb.freebsd.org/ports?view=revision&revision=361642 ---------- nosy: +spil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 12:36:08 2015 From: report at bugs.python.org (Saimadhav Heblikar) Date: Wed, 07 Jan 2015 11:36:08 +0000 Subject: [issue6171] IDLE - TreeWidget draw and double-click (Ubuntu) In-Reply-To: <1243903612.81.0.195499978214.issue6171@psf.upfronthosting.co.za> Message-ID: <1420630568.8.0.451087555823.issue6171@psf.upfronthosting.co.za> Saimadhav Heblikar added the comment: Behavior described in msg229434 is right. Tested on Ubuntu 14.04 64bit with Python version 3.5.0a, TkVersion=8.5 and TclVersion=8.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 14:54:51 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 07 Jan 2015 13:54:51 +0000 Subject: [issue23177] test_ssl: failures on OpenBSD with LibreSSL In-Reply-To: <1420541656.17.0.750310163886.issue23177@psf.upfronthosting.co.za> Message-ID: <1420638891.4.0.782266305906.issue23177@psf.upfronthosting.co.za> STINNER Victor added the comment: > Note that the FreeBSD port modifies the OPENSSL_VERSION_NUMBER and sets the version number to 1.0.1g. Maybe we should remove the test on OPENSSL_VERSION (string) for LibreSSL? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 15:11:05 2015 From: report at bugs.python.org (=?utf-8?q?J=C3=A9r=C3=A9mie_Detrey?=) Date: Wed, 07 Jan 2015 14:11:05 +0000 Subject: [issue17164] MozillaCookieJar does not handle session cookies In-Reply-To: <1360358603.06.0.441613239061.issue17164@psf.upfronthosting.co.za> Message-ID: <1420639865.47.0.970086118464.issue17164@psf.upfronthosting.co.za> J?r?mie Detrey added the comment: Hi again, Attached is a patch for adding test cases to test_cookiejar. Cheers, J?r?mie. ---------- Added file: http://bugs.python.org/file37629/session-cookies-test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 16:38:00 2015 From: report at bugs.python.org (Augie Fackler) Date: Wed, 07 Jan 2015 15:38:00 +0000 Subject: [issue14099] ZipFile.open() should not reopen the underlying file In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za> Message-ID: <1420645080.72.0.546323951556.issue14099@psf.upfronthosting.co.za> Changes by Augie Fackler : ---------- nosy: +durin42 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 17:33:44 2015 From: report at bugs.python.org (Ethan Furman) Date: Wed, 07 Jan 2015 16:33:44 +0000 Subject: [issue23185] add inf and nan to math module Message-ID: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> New submission from Ethan Furman: Proposal: math.nan = float('nan') math.inf = float('inf') Guido's approval: https://mail.python.org/pipermail/python-ideas/2015-January/030775.html Followup question: Do we add a math.neginf, or somesuch, for float('-inf')? Or just use -math.inf? ---------- keywords: easy messages: 233580 nosy: ethan.furman priority: normal severity: normal status: open title: add inf and nan to math module type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 17:42:15 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 07 Jan 2015 16:42:15 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> Message-ID: <1420648935.99.0.141526308239.issue23185@psf.upfronthosting.co.za> STINNER Victor added the comment: > Do we add a math.neginf, or somesuch, for float('-inf')? Or just use -math.inf? I would prefer to only add inf. It looks like float("-inf") and -float("inf") have exactly the same IEEE 754 representation (at least on my x86_64 CPU): >>> struct.pack("d", float("-inf")) == struct.pack("d", -float("inf")) True ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 17:55:21 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 07 Jan 2015 16:55:21 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> Message-ID: <1420649721.25.0.667313170825.issue23185@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- components: +Library (Lib) stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 17:57:53 2015 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 07 Jan 2015 16:57:53 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> Message-ID: <1420649873.07.0.691857888683.issue23185@psf.upfronthosting.co.za> Mark Dickinson added the comment: Sounds good to me. > Do we add a math.neginf IMO no: -inf should be fine. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 17:58:50 2015 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 07 Jan 2015 16:58:50 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> Message-ID: <1420649930.22.0.217663947061.issue23185@psf.upfronthosting.co.za> Mark Dickinson added the comment: > float("-inf") and -float("inf") have exactly the same IEEE 754 representation Indeed: there's only one negative infinity (and only one positive infinity) in IEEE 754 binary64 format. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 18:01:03 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 07 Jan 2015 17:01:03 +0000 Subject: [issue23186] expose the client's list of ciphers during the handshake Message-ID: <1420650062.65.0.672176536798.issue23186@psf.upfronthosting.co.za> New submission from Benjamin Peterson: This patch adds a shared_ciphers() method to SSLObject and SSLSocket, which allows servers to see the complete list of ciphers sent by the client during handshake. ---------- components: Library (Lib) files: shared-ciphers.patch keywords: patch messages: 233584 nosy: alex, benjamin.peterson, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou priority: normal severity: normal stage: patch review status: open title: expose the client's list of ciphers during the handshake type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file37630/shared-ciphers.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 18:07:00 2015 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 07 Jan 2015 17:07:00 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> Message-ID: <1420650420.28.0.45765391314.issue23185@psf.upfronthosting.co.za> Mark Dickinson added the comment: Implementation suggestion: if possible, use the _Py_dg_stdnan and _Py_dg_infinity functions from Python/dtoa.c. These are a little safer than the Py_NAN and Py_HUGE_VAL macros, and will give results consistent with the float("inf") and float("nan") constructions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 18:14:59 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 07 Jan 2015 17:14:59 +0000 Subject: [issue23186] expose the client's list of ciphers during the handshake In-Reply-To: <1420650062.65.0.672176536798.issue23186@psf.upfronthosting.co.za> Message-ID: <20150107171446.72575.21775@psf.io> Roundup Robot added the comment: New changeset bc34fcccaca3 by Benjamin Peterson in branch 'default': expose the client's cipher suites from the handshake (closes #23186) https://hg.python.org/cpython/rev/bc34fcccaca3 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 18:20:52 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 07 Jan 2015 17:20:52 +0000 Subject: [issue23186] expose the client's list of ciphers during the handshake In-Reply-To: <1420650062.65.0.672176536798.issue23186@psf.upfronthosting.co.za> Message-ID: <1420651252.04.0.424230766507.issue23186@psf.upfronthosting.co.za> STINNER Victor added the comment: I reopen the issue because you commit your change while I was reviewing the patch :-/ See my review at Rietveld. ---------- nosy: +haypo resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 18:25:57 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 07 Jan 2015 17:25:57 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> Message-ID: <1420651557.81.0.189420124018.issue23185@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, NaN can be signed? >>> struct.pack("d", float("nan")) b'\x00\x00\x00\x00\x00\x00\xf8\x7f' >>> struct.pack("d", float("-nan")) b'\x00\x00\x00\x00\x00\x00\xf8\xff' >>> struct.pack("d", -float("nan")) b'\x00\x00\x00\x00\x00\x00\xf8\xff' >>> struct.pack("d", -float("-nan")) b'\x00\x00\x00\x00\x00\x00\xf8\x7f' Why does Python return the same representation for positive and negative NaN? >>> float("nan") nan >>> float("-nan") nan ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 18:42:33 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Wed, 07 Jan 2015 17:42:33 +0000 Subject: [issue23086] Add start and stop parameters to the Sequence.index() ABC mixin method In-Reply-To: <1418935306.72.0.256960321979.issue23086@psf.upfronthosting.co.za> Message-ID: <1420652553.41.0.880615760951.issue23086@psf.upfronthosting.co.za> Devin Jeanpierre added the comment: I modified your test case somewhat. Also, your tests uncovered an issue with negative indexes -- oops, hadn't thought of those. Fixed. Let me know what you think. ---------- Added file: http://bugs.python.org/file37631/issue23086.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 18:43:13 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Wed, 07 Jan 2015 17:43:13 +0000 Subject: [issue23086] Add start and stop parameters to the Sequence.index() ABC mixin method In-Reply-To: <1418935306.72.0.256960321979.issue23086@psf.upfronthosting.co.za> Message-ID: <1420652593.21.0.571096974104.issue23086@psf.upfronthosting.co.za> Devin Jeanpierre added the comment: Why is there no "review" link next to my second patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 19:18:08 2015 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 07 Jan 2015 18:18:08 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> Message-ID: <1420654688.28.0.20149240599.issue23185@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Why does Python return the same representation for positive and negative NaN? History, perhaps? In any case, the sign of a NaN isn't useful information in the same way that the sign of an infinity is. The IEEE 754 standard explicitly refuses to attach any meaning to the sign bit of a NaN. And if we were aiming for a full and faithful representation of NaNs, we'd want to output the payload, too (which is just about as meaningless / meaningful as the sign bit). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 19:22:18 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Wed, 07 Jan 2015 18:22:18 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <1420654938.18.0.707826495783.issue22619@psf.upfronthosting.co.za> Dmitry Kazakov added the comment: Hold on, I found 2 more bugs. Will update the patch soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 19:25:27 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 07 Jan 2015 18:25:27 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> Message-ID: <1420655127.93.0.11004486624.issue23185@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There are several different NaNs. >>> x = struct.unpack('d', b'\x00\x00\x00\x00\x00\x00\xf8\x7f')[0] >>> x nan >>> x == x False >>> struct.pack('d', x) b'\x00\x00\x00\x00\x00\x00\xf8\x7f' >>> x = struct.unpack('d', b'\x00\x00\x00\x00\x00\x00\xf9\x7f')[0] >>> x nan >>> x == x False >>> struct.pack('d', x) b'\x00\x00\x00\x00\x00\x00\xf9\x7f' Interesting, but 0*inf and inf-inf return values with the same representation as float('-nan'), not float('nan'). >>> inf = float("inf") >>> struct.pack('d', 0*inf) b'\x00\x00\x00\x00\x00\x00\xf8\xff' >>> struct.pack('d', inf-inf) b'\x00\x00\x00\x00\x00\x00\xf8\xff' >>> struct.pack('d', float('nan')) b'\x00\x00\x00\x00\x00\x00\xf8\x7f' >>> struct.pack('d', float('-nan')) b'\x00\x00\x00\x00\x00\x00\xf8\xff' ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 19:27:06 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 07 Jan 2015 18:27:06 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> Message-ID: <1420655226.7.0.0555580872904.issue23185@psf.upfronthosting.co.za> Antoine Pitrou added the comment: By tweaking the grammar we can have math.-inf. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 19:27:27 2015 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 07 Jan 2015 18:27:27 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> Message-ID: <1420655247.34.0.690366688695.issue23185@psf.upfronthosting.co.za> Mark Dickinson added the comment: > but 0*inf and inf-inf return values with the same representation as float('-nan'), not float('nan') Right: that's because Intel's "default" NaN (i.e., the float it produces as a result of any invalid operation) has its sign bit set. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 19:27:45 2015 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 07 Jan 2015 18:27:45 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> Message-ID: <1420655265.86.0.8208455816.issue23185@psf.upfronthosting.co.za> Mark Dickinson added the comment: > By tweaking the grammar we can have math.-inf. AAAARRGH! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 19:37:48 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Wed, 07 Jan 2015 18:37:48 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <1420655868.86.0.680724258847.issue22619@psf.upfronthosting.co.za> Dmitry Kazakov added the comment: I improved tests for *_stack and *_tb functions, fixed a few typos and added more comments. ---------- Added file: http://bugs.python.org/file37632/traceback_rev3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 19:42:47 2015 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 07 Jan 2015 18:42:47 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> Message-ID: <1420656167.23.0.194988213969.issue23185@psf.upfronthosting.co.za> Mark Dickinson added the comment: Here's a patch. ---------- assignee: -> mark.dickinson keywords: +patch Added file: http://bugs.python.org/file37633/math_inf_nan.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 20:13:02 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 07 Jan 2015 19:13:02 +0000 Subject: [issue23186] expose the client's list of ciphers during the handshake In-Reply-To: <1420650062.65.0.672176536798.issue23186@psf.upfronthosting.co.za> Message-ID: <1420657982.52.0.0656992921503.issue23186@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 20:15:48 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 07 Jan 2015 19:15:48 +0000 Subject: [issue20487] Odd words in unittest.mock document. In-Reply-To: <1391355507.86.0.158179018907.issue20487@psf.upfronthosting.co.za> Message-ID: <20150107191544.22395.20277@psf.io> Roundup Robot added the comment: New changeset 230a1bfb0f59 by Berker Peksag in branch '3.4': Issue #20487: Clarify meaning of "side effect" in the magic mock documentation. https://hg.python.org/cpython/rev/230a1bfb0f59 New changeset 3cf91d2aeab3 by Berker Peksag in branch 'default': Issue #20487: Clarify meaning of "side effect" in the magic mock documentation. https://hg.python.org/cpython/rev/3cf91d2aeab3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 20:19:01 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 07 Jan 2015 19:19:01 +0000 Subject: [issue20487] Odd words in unittest.mock document. In-Reply-To: <1391355507.86.0.158179018907.issue20487@psf.upfronthosting.co.za> Message-ID: <1420658341.19.0.123189698446.issue20487@psf.upfronthosting.co.za> Berker Peksag added the comment: Fixed. Thank you to both Andrew and Michael. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 20:27:27 2015 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 07 Jan 2015 19:27:27 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> Message-ID: <1420658847.08.0.928990041382.issue23185@psf.upfronthosting.co.za> Mark Dickinson added the comment: Thanks for the review comments. Here's an updated patch taking the review comments into account (and fixing the spelling of PY_NAN, which should have been Py_NAN). ---------- Added file: http://bugs.python.org/file37634/math_inf_nan2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 21:02:37 2015 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 07 Jan 2015 20:02:37 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> Message-ID: <1420660957.58.0.18505831564.issue23185@psf.upfronthosting.co.za> Mark Dickinson added the comment: One more patch, fixing a misplaced period. ---------- Added file: http://bugs.python.org/file37635/math_inf_nan3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 21:29:38 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Wed, 07 Jan 2015 20:29:38 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <1420662578.89.0.956240531328.issue22619@psf.upfronthosting.co.za> Changes by Dmitry Kazakov : Removed file: http://bugs.python.org/file36919/tb_patch_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 21:30:05 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Wed, 07 Jan 2015 20:30:05 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <1420662605.22.0.272366002634.issue22619@psf.upfronthosting.co.za> Changes by Dmitry Kazakov : Removed file: http://bugs.python.org/file37181/traceback.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 21:30:12 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Wed, 07 Jan 2015 20:30:12 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <1420662612.57.0.295613194818.issue22619@psf.upfronthosting.co.za> Changes by Dmitry Kazakov : Removed file: http://bugs.python.org/file37341/traceback_patch_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 21:51:52 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 07 Jan 2015 20:51:52 +0000 Subject: [issue6171] IDLE - TreeWidget draw and double-click (Ubuntu) In-Reply-To: <1243903612.81.0.195499978214.issue6171@psf.upfronthosting.co.za> Message-ID: <1420663912.47.0.0476967110112.issue6171@psf.upfronthosting.co.za> Terry J. Reedy added the comment: It appears that this could be closed then. But I would like to look at the patch first if I can get to it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 22:24:08 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 07 Jan 2015 21:24:08 +0000 Subject: [issue23158] IDLE's help.txt "corrent" typo In-Reply-To: <1420333244.7.0.623275484679.issue23158@psf.upfronthosting.co.za> Message-ID: <1420665848.05.0.242245727409.issue23158@psf.upfronthosting.co.za> Terry J. Reedy added the comment: idlelib/help.txt has been and is being replaced by idle.html, compiled from Doc/library/idle.rst. See #16893. Idle.rst started as a marked up version of help.txt and has since been edited and will get more editing. This typo has been corrected there. Help.txt is obsolete and I am not patching it further. Typos in idle.rst will be corrected. ---------- assignee: -> terry.reedy nosy: +terry.reedy resolution: -> out of date stage: -> resolved status: open -> closed versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 22:39:22 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 07 Jan 2015 21:39:22 +0000 Subject: [issue23180] Rename IDLE's "Windows" menu item to "Window" In-Reply-To: <1420614987.43.0.350300091598.issue23180@psf.upfronthosting.co.za> Message-ID: <1420666762.82.0.152712640212.issue23180@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I guess the logic of the plural was that the submenu lists windows to select from. The logic of the singular is that the submenu lets a user select and jump to *a* window, just as the file menu allows one to select and open (if needed) *a* file. Somewhat oddly, Notepad++ Window menu has a Windows entry. Please mark Idle issues for exactly 2.7, 3.4, and 3.5. ---------- nosy: +terry.reedy stage: -> patch review versions: -Python 3.2, Python 3.3, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 23:03:06 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 07 Jan 2015 22:03:06 +0000 Subject: [issue23184] Unused imports, variables, file in IDLE In-Reply-To: <1420626411.51.0.528702156456.issue23184@psf.upfronthosting.co.za> Message-ID: <1420668186.75.0.90392154277.issue23184@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am aware of some of these from running PyChecker over idlelib, but had not gotten around to an global patch yet. The unit test coverage is still woefully incomplete, so I will want to check each deletion. I have been meaning to delete testcode.py, but in a separate commit. ---------- assignee: -> terry.reedy nosy: +terry.reedy stage: -> patch review type: behavior -> enhancement versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 23:09:05 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 07 Jan 2015 22:09:05 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> Message-ID: <1420668545.35.0.754765763598.issue23185@psf.upfronthosting.co.za> STINNER Victor added the comment: "History, perhaps? In any case, the sign of a NaN isn't useful information in the same way that the sign of an infinity is. The IEEE 754 standard explicitly refuses to attach any meaning to the sign bit of a NaN. And if we were aiming for a full and faithful representation of NaNs, we'd want to output the payload, too (which is just about as meaningless / meaningful as the sign bit)." So I understand that adding a math.neg_nan would be useless. As adding one constant per possible "NaN" value :-) If I recall correctly the IEEE 754 standard, there is not single NaN value, but a range of NaN. "Two kinds of NaN: a quiet NaN (qNaN) and a signaling NaN (sNaN). A NaN may carry a payload that is intended for diagnostic information indicating the source of the NaN. The sign of a NaN has no meaning, but it may be predictable in some circumstances." says Wikipedia. Well, the current definition of math.nan makes sense, it's the same value than float("nan"). Note: On python-ideas, I asked if math.nan and math.inf should be singleton (as it was requested for float("0.0") in issue #4024). The answer is no. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 7 23:13:42 2015 From: report at bugs.python.org (Pavel Repin) Date: Wed, 07 Jan 2015 22:13:42 +0000 Subject: [issue4431] Distutils MSVC doesn't create manifest file In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za> Message-ID: <1420668822.95.0.45381379175.issue4431@psf.upfronthosting.co.za> Changes by Pavel Repin : ---------- nosy: -paxan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 00:41:35 2015 From: report at bugs.python.org (Ivailo Karamanolev) Date: Wed, 07 Jan 2015 23:41:35 +0000 Subject: [issue23187] Segmentation fault, possibly asyncio related Message-ID: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za> New submission from Ivailo Karamanolev: I have a program that's running Tornado on top of asyncio and uses mysql-connector-python to monitor a set of HTTP servers and save the status to MySQL. Initially I ran it with the current version of Python in the Ubuntu 14.04 repos, that's 3.4.0 and started getting segmentation faults after keeping it running for a few days. I compiled and installed 3.4.2 and the same thing keeps happening, with the same stack trace (per gdb). Running it with and without gdb attached gives the same results - seg fault after 3-4 days of running. The machine is running on a Xeon with ECC memory and doesn't show signs of illness otherwise, so it's probably not a hardware problem. Also, it's happening consistently when the programs runs for 3-4 days, with or without a system reboot. Program received signal SIGSEGV, Segmentation fault. 0x0000000000471ed7 in subtype_dealloc (self=0x7ffff16a3860) at Objects/typeobject.c:1128 1128 _PyObject_GC_UNTRACK(self); Stack trace: #0 0x0000000000471ed7 in subtype_dealloc (self=0x7ffff16a3860) at Objects/typeobject.c:1128 #1 0x00000000004563f4 in dict_dealloc (mp=0x7fffe95444c8) at Objects/dictobject.c:1383 #2 0x0000000000472140 in subtype_dealloc (self=0x7fffe8e1fcf8) at Objects/typeobject.c:1157 #3 0x000000000058ad22 in frame_dealloc (f=0x1145258) at Objects/frameobject.c:429 #4 0x0000000000588fd7 in gen_send_ex (gen=gen at entry=0x7fffe8c5cea0, gen=gen at entry=0x7fffe8c5cea0, exc=0, arg=arg at entry=0x0) at Objects/genobject.c:145 #5 _PyGen_Send (gen=gen at entry=0x7fffe8c5cea0, arg=arg at entry=0x87fec0 <_Py_FalseStruct>) at Objects/genobject.c:158 #6 0x00000000004da329 in PyEval_EvalFrameEx (f=f at entry=0x11faaf8, throwflag=throwflag at entry=0) at Python/ceval.c:1906 #7 0x0000000000588e5c in gen_send_ex (gen=gen at entry=0x7fffe8c5ccf0, gen=gen at entry=0x7fffe8c5ccf0, exc=0, arg=arg at entry=0x7ffff1bb6420) at Objects/genobject.c:104 #8 _PyGen_Send (gen=gen at entry=0x7fffe8c5ccf0, arg=arg at entry=0x87fec0 <_Py_FalseStruct>) at Objects/genobject.c:158 #9 0x00000000004da329 in PyEval_EvalFrameEx (f=f at entry=0x10daa48, throwflag=throwflag at entry=0) at Python/ceval.c:1906 #10 0x0000000000588e5c in gen_send_ex (gen=gen at entry=0x7fffe8c5cc18, gen=gen at entry=0x7fffe8c5cc18, exc=0, arg=arg at entry=0x102aac8) at Objects/genobject.c:104 #11 _PyGen_Send (gen=gen at entry=0x7fffe8c5cc18, arg=arg at entry=0x87fec0 <_Py_FalseStruct>) at Objects/genobject.c:158 #12 0x00000000004da329 in PyEval_EvalFrameEx (f=f at entry=0x10da7f8, throwflag=throwflag at entry=0) at Python/ceval.c:1906 #13 0x0000000000588e5c in gen_send_ex (gen=0x7ffff16b65a0, gen=0x7ffff16b65a0, exc=0, arg=) at Objects/genobject.c:104 #14 _PyGen_Send (gen=0x7ffff16b65a0, arg=) at Objects/genobject.c:158 #15 0x00000000004d9d0b in call_function (oparg=, pp_stack=0x7fffffffd290) at Python/ceval.c:4221 #16 PyEval_EvalFrameEx (f=f at entry=0x10da568, throwflag=throwflag at entry=0) at Python/ceval.c:2836 #17 0x00000000004d28d4 in PyEval_EvalCodeEx (_co=0x7ffff1e0c030, globals=, locals=, args=, argcount=3, kws=0x12e38b8, kwcount=0, defs=0x7ffff1e0a8e0, defcount=2, kwdefs=0x0, closure=0x7ffff1e10588) at Python/ceval.c:3585 #18 0x00000000004d8e75 in fast_function (nk=, na=3, n=3, pp_stack=0x7fffffffd490, func=0x7ffff1e122f0) at Python/ceval.c:4341 #19 call_function (oparg=, pp_stack=0x7fffffffd490) at Python/ceval.c:4259 #20 PyEval_EvalFrameEx (f=f at entry=0x12e3708, throwflag=throwflag at entry=0) at Python/ceval.c:2836 #21 0x00000000004d28d4 in PyEval_EvalCodeEx (_co=0x7ffff1e0c0c0, globals=, locals=locals at entry=0x0, args=args at entry=0x7fffeae8a720, argcount=2, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3585 #22 0x000000000058c67c in function_call (func=0x7ffff1e12378, arg=0x7fffeae8a708, kw=0x0) at Objects/funcobject.c:632 #23 0x000000000042686a in PyObject_Call (func=func at entry=0x7ffff1e12378, arg=arg at entry=0x7fffeae8a708, kw=kw at entry=0x0) at Objects/abstract.c:2067 #24 0x00000000004d48a4 in ext_do_call (nk=, na=1, flags=, pp_stack=0x7fffffffd760, func=0x7ffff1e12378) at Python/ceval.c:4558 #25 PyEval_EvalFrameEx (f=f at entry=0x145ac48, throwflag=throwflag at entry=0) at Python/ceval.c:2876 #26 0x00000000004d9e82 in fast_function (nk=, na=1, n=1, pp_stack=0x7fffffffd8a0, func=0x7ffff1e2d488) at Python/ceval.c:4331 #27 call_function (oparg=, pp_stack=0x7fffffffd8a0) at Python/ceval.c:4259 #28 PyEval_EvalFrameEx (f=f at entry=0x11aee28, throwflag=throwflag at entry=0) at Python/ceval.c:2836 #29 0x00000000004d9e82 in fast_function (nk=, na=1, n=1, pp_stack=0x7fffffffd9f0, func=0x7ffff1bc1400) at Python/ceval.c:4331 #30 call_function (oparg=, pp_stack=0x7fffffffd9f0) at Python/ceval.c:4259 #31 PyEval_EvalFrameEx (f=f at entry=0x10d9c68, throwflag=throwflag at entry=0) at Python/ceval.c:2836 #32 0x00000000004d9e82 in fast_function (nk=, na=1, n=1, pp_stack=0x7fffffffdb40, func=0x7ffff1bc0268) at Python/ceval.c:4331 #33 call_function (oparg=, pp_stack=0x7fffffffdb40) at Python/ceval.c:4259 #34 PyEval_EvalFrameEx (f=f at entry=0xf9ed08, throwflag=throwflag at entry=0) at Python/ceval.c:2836 #35 0x00000000004d9e82 in fast_function (nk=, na=0, n=0, pp_stack=0x7fffffffdc90, func=0x7ffff16a4d08) at Python/ceval.c:4331 #36 call_function (oparg=, pp_stack=0x7fffffffdc90) at Python/ceval.c:4259 #37 PyEval_EvalFrameEx (f=f at entry=0x7ffff7f4b438, throwflag=throwflag at entry=0) at Python/ceval.c:2836 #38 0x00000000004dae2a in PyEval_EvalCodeEx (closure=0x0, kwdefs=0x0, defcount=0, defs=0x0, kwcount=0, kws=0x0, argcount=0, args=0x0, locals=locals at entry=0x7ffff7f95d50, globals=globals at entry=0x100000000, _co=0x7ffff7ee0150, _co at entry=0x8ac460) at Python/ceval.c:3585 #39 PyEval_EvalCode (co=co at entry=0x7ffff7ee0150, globals=globals at entry=0x7ffff7f48408, locals=locals at entry=0x7ffff7f48408) at Python/ceval.c:773 #40 0x000000000050a8f8 in run_mod (arena=0x95d9a0, flags=0x7fffffffdee0, locals=0x7ffff7f48408, globals=0x7ffff7f48408, filename=0x7ffff7e3f540, mod=0x8fb1e0) at Python/pythonrun.c:2180 #41 PyRun_FileExFlags (fp=0x8fa9c0, filename_str=, start=, globals=0x7ffff7f48408, locals=0x7ffff7f48408, closeit=1, flags=0x7fffffffdee0) at Python/pythonrun.c:2133 #42 0x000000000050c8f5 in PyRun_SimpleFileExFlags (fp=0x8fa9c0, filename=, closeit=1, flags=0x7fffffffdee0) at Python/pythonrun.c:1606 #43 0x000000000041edc4 in run_file (p_cf=0x7fffffffdee0, filename=0x8ac2a0 L"./torrent_manager.py", fp=0x8fa9c0) at Modules/main.c:319 #44 Py_Main (argc=argc at entry=2, argv=argv at entry=0x8ab010) at Modules/main.c:751 #45 0x000000000041b227 in main (argc=2, argv=) at ./Modules/python.c:69 ---------- components: Interpreter Core, asyncio messages: 233608 nosy: gvanrossum, haypo, karamanolev, yselivanov priority: normal severity: normal status: open title: Segmentation fault, possibly asyncio related type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 00:48:14 2015 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 07 Jan 2015 23:48:14 +0000 Subject: [issue23187] Segmentation fault, possibly asyncio related In-Reply-To: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za> Message-ID: <1420674494.67.0.530093558757.issue23187@psf.upfronthosting.co.za> Guido van Rossum added the comment: That's going to be really hard to debug. Is it always the same stack trace? Could it be slowly running out of memory? (The consistent time until it happens points to this.) A segfault in dealloc might point to a refcounting bug. The rarity of the even might mean that it only happens in some rare case (maybe the refcount bug is in an error path that is only triggered by running out of memory somewhere?). Is mysql totally unsuspected? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 01:03:58 2015 From: report at bugs.python.org (Ivailo Karamanolev) Date: Thu, 08 Jan 2015 00:03:58 +0000 Subject: [issue23187] Segmentation fault, possibly asyncio related In-Reply-To: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za> Message-ID: <1420675438.63.0.84136084655.issue23187@psf.upfronthosting.co.za> Ivailo Karamanolev added the comment: Running out of memory is unlikely. There are many other processes running on the machine and none of them show signs of memory issues. In addition, the munin memory usage reporting doesn't show signs of steady growing or drops when the process crashes (munin screenshot attached). 3.4.0 and 3.4.2 on all runs showed exactly the same stack trace. AFAIK mysql-connector-python is pure Python, so even if the problem was there, I think it's still Python core. I'm not 100% on this though. ---------- Added file: http://bugs.python.org/file37636/Screenshot 2015-01-07 15.57.01.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 01:08:38 2015 From: report at bugs.python.org (Ivailo Karamanolev) Date: Thu, 08 Jan 2015 00:08:38 +0000 Subject: [issue23187] Segmentation fault, possibly asyncio related In-Reply-To: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za> Message-ID: <1420675718.7.0.765043825775.issue23187@psf.upfronthosting.co.za> Ivailo Karamanolev added the comment: What I forgot to mention is that I'm using aiohttp for making lots of HTTP requests. http://bugs.python.org/issue21435 mentions asyncio and aiohttp and is somewhat memory management related so I thought I'm hitting a different manifestation of it and upgrading to 3.4.2 would fix it, but it didn't. I don't know enough about cpython to know if they are related. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 01:10:43 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 08 Jan 2015 00:10:43 +0000 Subject: [issue23187] Segmentation fault, possibly asyncio related In-Reply-To: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za> Message-ID: <1420675843.57.0.345653495556.issue23187@psf.upfronthosting.co.za> STINNER Victor added the comment: > that's 3.4.0 I suggest you to upgrade to Python 3.4.2. Your issue may already be fixed. For example, there was the issue #21435 in the garbage collector. The issue was found with an asyncio code. Your crash occurs at "_PyObject_GC_UNTRACK(self);" which is also related to the garbage collector. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 01:13:08 2015 From: report at bugs.python.org (Ivailo Karamanolev) Date: Thu, 08 Jan 2015 00:13:08 +0000 Subject: [issue23187] Segmentation fault, possibly asyncio related In-Reply-To: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za> Message-ID: <1420675988.89.0.671206811962.issue23187@psf.upfronthosting.co.za> Ivailo Karamanolev added the comment: @haypo Maybe I didn't put it prominently enough, but I upgraded to 3.4.2 by downloading the source and installing it. The same crash with the same stack trace happens. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 01:18:45 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 08 Jan 2015 00:18:45 +0000 Subject: [issue23187] Segmentation fault, possibly asyncio related In-Reply-To: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za> Message-ID: <1420676325.55.0.869823166671.issue23187@psf.upfronthosting.co.za> STINNER Victor added the comment: > upgrading to 3.4.2 would fix it, but it didn't Oh sorry, I missed the part where you wrote that you already tested Python 3.4.2. By the way, if you already compile your own Python: try to configure Python with ./configure --with-pydebug. It adds much more debug checks to check internal consistency. > Is mysql totally unsuspected? It looks like mysql-connector-python is written in pure Python. Are you using other external modules which are implemented in C? -- Would it be possible to share your source code to try to reproduce the issue? You might send it to me privately if you prefer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 01:29:21 2015 From: report at bugs.python.org (Ivailo Karamanolev) Date: Thu, 08 Jan 2015 00:29:21 +0000 Subject: [issue23187] Segmentation fault, possibly asyncio related In-Reply-To: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za> Message-ID: <1420676961.81.0.218349910736.issue23187@psf.upfronthosting.co.za> Ivailo Karamanolev added the comment: > try to configure Python with ./configure --with-pydebug I'm installing 3.4.2 with this option right now and I'll reboot and run the script with gdb attached. I might be a few days before I have a result. > Are you using other external modules which are implemented in C The only module that I'm using that's implemented in C is ujson https://pypi.python.org/pypi/ujson . If you think this is relevant, I can easily try changing it to use the built-in json. > Would it be possible to share your source code I can share it privately, yes, but running it on your machine might be too complicated. Sharing the source code will probably be only useful for you to look at what libraries I am using and how I'm using asyncio. What I can do is try running it on another machine with another setup. While it is currently running on a physical machine that I set up, I can run it in parallel on a OpenVZ VPS that is installed by the VPS provider, so it should give a completely independent environment. Would that help? If yes, should I also install 3.4.2 from source with --with-pydebug? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 01:49:13 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 08 Jan 2015 00:49:13 +0000 Subject: [issue23187] Segmentation fault, possibly asyncio related In-Reply-To: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za> Message-ID: <1420678153.51.0.523760769976.issue23187@psf.upfronthosting.co.za> STINNER Victor added the comment: > The only module that I'm using that's implemented in C is ujson https://pypi.python.org/pypi/ujson . If you think this is relevant, I can easily try changing it to use the built-in json. To investigate an issue, we have to reduce the scope. If your program works with json, please use it instead yes. If the program still crash with the builtin json, it means that usjon is not the problem. If the program doesn't crash anymore, your issue may come from ujson and the investigate would be completly different... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 01:51:26 2015 From: report at bugs.python.org (Jon Dufresne) Date: Thu, 08 Jan 2015 00:51:26 +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: <1420678286.76.0.103456369816.issue7651@psf.upfronthosting.co.za> Changes by Jon Dufresne : ---------- nosy: +jdufresne _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 02:39:23 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 08 Jan 2015 01:39:23 +0000 Subject: [issue22560] Add loop-agnostic SSL implementation to asyncio In-Reply-To: <1412548102.84.0.685230620276.issue22560@psf.upfronthosting.co.za> Message-ID: <1420681163.56.0.331679701668.issue22560@psf.upfronthosting.co.za> STINNER Victor added the comment: I updated sslproto3.patch with my remarks: sslproto-4.patch Main differences with sslproto3.patch (unsorted): * write_eof raises NotImplementedError * fix write_buffer_size: use data, not offset * use tuples in the write backlog * data_received exits the loop when it gets an empty string (ignore following data, but an empty string must be at the end of the list according to Antoine) * SSLPipe._write_backlog is now a deque (should be more efficient since we remove the head of the list in _process_write_backlog) * always store and pass the server hostname, even if SNI is not supported * deny calling shutdown() twice * Remove ConnectionAbortedError special case: I would like to reproduce to understand it, and document it * Set the default read parameter to 256 KB instead of 64 KB: reuse constant from selector_events.py * SSLPipe: use a different attribute to store the shutdown callback Remarks: * sslproto looks to be based on gruvi/ssl.py of the gruvi project written by Geert Jansen. We should mention the author in the commit. * _process_write_backlog(): I don't understand why offset is set to 1 for handshake and shutdown ---------- Added file: http://bugs.python.org/file37637/sslproto-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 02:44:42 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 08 Jan 2015 01:44:42 +0000 Subject: [issue22560] Add loop-agnostic SSL implementation to asyncio In-Reply-To: <1412548102.84.0.685230620276.issue22560@psf.upfronthosting.co.za> Message-ID: <1420681482.36.0.327566858946.issue22560@psf.upfronthosting.co.za> STINNER Victor added the comment: I prefer to use the same code on all platforms. I don't like the idea of SSL bugs specific to Windows. With this change, it becomes possible to support "STARTTLS". IMO supporting this feature is more important than performance, even if I only expect a low overflow of the new _SSLPipe layer, so the benchmark is not needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 04:17:21 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 08 Jan 2015 03:17:21 +0000 Subject: [issue23188] Convert _PyErr_ChainExceptions to a public API Message-ID: <1420687041.12.0.12728944273.issue23188@psf.upfronthosting.co.za> New submission from Nick Coghlan: There's currently an internal helper API for chaining exceptions from C code, _PyErr_ChainExceptions. It would be good to have a public API that offered equivalent functionality for use in third party C extensions. ---------- messages: 233619 nosy: ncoghlan priority: normal severity: normal stage: needs patch status: open title: Convert _PyErr_ChainExceptions to a public API type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 04:33:19 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 08 Jan 2015 03:33:19 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1420687999.86.0.987047485408.issue22906@psf.upfronthosting.co.za> Nick Coghlan added the comment: As Stefan noted, the leading underscore on "_PyErr_ChainExceptions" is just a warning to third party users that we don't yet offer any API stability guarantees for it. Using it in CPython itself is entirely appropriate - that's the whole reason for exposing it to the linker at all. It would be good to have a public API for that functionality though, so I filed issue 23188 to suggest making it public. The main thing missing from the patch at this point is the __future__ import. To learn what's involved in that, one of the useful tricks is to look at the annotated __future__ module: https://hg.python.org/cpython/annotate/bbf16fd024df/Lib/__future__.py The commits adding new flags there highlight the various places that tend to be affected when a new __future__ import is added. For this particular case, the closest comparison is likely with the "absolute import" feature. One interesting aspect of this particular flag though is that it doesn't really affect compilation at all, aside from setting the flag on the code objects to indicate the future statement was in effect. The main impact will be at runtime, where it will make the exception replacement in Chris's PoC patch conditional on the presence of the flag on the code object. Chris, will you have time in the near future to rework the patch to add the __future__ support? It would be good to get this into 3.5a1 to give it the longest possible settling in period. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 04:34:35 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 08 Jan 2015 03:34:35 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1420688075.65.0.978654499597.issue22906@psf.upfronthosting.co.za> Nick Coghlan added the comment: Heh, I guess that should have been "The main thing missing other than docs and tests is ..." :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 04:46:58 2015 From: report at bugs.python.org (Chris Angelico) Date: Thu, 08 Jan 2015 03:46:58 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1420688818.86.0.786182626286.issue22906@psf.upfronthosting.co.za> Chris Angelico added the comment: I can have a poke at the __future__ import tonight, but my main concern is memory management - I'm not sufficiently familiar with the exception handling calls to be sure that I'm neither leaking nor over-freeing anything. There's also a secondary concern that the tracebacks aren't quite right at the moment, possibly caused by a muck-up in the exception chaining. >>> def f(): raise StopIteration >>> def g(): yield f() >>> next(g()) StopIteration During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 1, in RuntimeError: generator raised StopIteration There's no indication of which function/line caused the exception, which would be _extremely_ helpful. If someone else can look into that at some point, I'd appreciate the assistance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 05:49:38 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 08 Jan 2015 04:49:38 +0000 Subject: [issue23184] Unused imports, variables, file in IDLE In-Reply-To: <1420626411.51.0.528702156456.issue23184@psf.upfronthosting.co.za> Message-ID: <20150108044933.11589.63172@psf.io> Roundup Robot added the comment: New changeset 1c3f8d044589 by Terry Jan Reedy in branch '2.7': Issue #23184: delete unused idlelib file. https://hg.python.org/cpython/rev/1c3f8d044589 New changeset 364e44a49a31 by Terry Jan Reedy in branch '3.4': Issue #23184: delete unused idlelib file. https://hg.python.org/cpython/rev/364e44a49a31 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 07:14:06 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 08 Jan 2015 06:14:06 +0000 Subject: [issue23184] Unused imports, variables, file in IDLE In-Reply-To: <1420626411.51.0.528702156456.issue23184@psf.upfronthosting.co.za> Message-ID: <1420697646.03.0.0171364298739.issue23184@psf.upfronthosting.co.za> Terry J. Reedy added the comment: There were errors in the patch. FileList.py: EditorWindow is used later. RemoteDebugger.py: frame is used twice, as visible in the diff. My copy of hg is not working right at the moment, or I would have applied the rest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 09:18:39 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 08 Jan 2015 08:18:39 +0000 Subject: [issue23188] Exception chaining should trigger for non-normalised exceptions In-Reply-To: <1420687041.12.0.12728944273.issue23188@psf.upfronthosting.co.za> Message-ID: <1420705119.75.0.567862927059.issue23188@psf.upfronthosting.co.za> Nick Coghlan added the comment: After looking into this further, PyErr_SetObject (and other APIs like PyErr_SetString which call that internally) aim to handle the chaining automatically, but they don't handle exceptions which haven't been normalized yet. PyErr_SetObject should probably normalise the exception at the start of the call f ithe exception type is set on the thread state, but not the exception value. ---------- title: Convert _PyErr_ChainExceptions to a public API -> Exception chaining should trigger for non-normalised exceptions type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 09:29:56 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 08 Jan 2015 08:29:56 +0000 Subject: [issue23188] Exception chaining should trigger for non-normalised exceptions In-Reply-To: <1420687041.12.0.12728944273.issue23188@psf.upfronthosting.co.za> Message-ID: <1420705796.72.0.573001210436.issue23188@psf.upfronthosting.co.za> Nick Coghlan added the comment: The documentation of PyErr_SetObject, PyErr_SetString et al should also be updated to mention exception chaining. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 09:37:40 2015 From: report at bugs.python.org (Vjacheslav Fyodorov) Date: Thu, 08 Jan 2015 08:37:40 +0000 Subject: [issue13307] bdist_rpm: INSTALLED_FILES does not use __pycache__ In-Reply-To: <1320100717.66.0.765161985418.issue13307@psf.upfronthosting.co.za> Message-ID: <1420706260.24.0.764271609367.issue13307@psf.upfronthosting.co.za> Vjacheslav Fyodorov added the comment: Now in 3.4 Fedora 21 ---------- nosy: +Vjacheslav.Fyodorov versions: +Python 3.4 -3rd party, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 09:40:54 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 08 Jan 2015 08:40:54 +0000 Subject: [issue23188] Exception chaining should trigger for non-normalised exceptions In-Reply-To: <1420687041.12.0.12728944273.issue23188@psf.upfronthosting.co.za> Message-ID: <1420706454.96.0.838683458266.issue23188@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thinking about it a bit further, I suspect implicit normalisation of chained exceptions could cause problems when we only want to set __cause__ without setting __context__ (e.g. codec exception chaining). I'm going to ponder this one for a while, but happy to hear anyone else's feedback. At the very least, I think the C API docs could use a bit more clarity on the intricacies of C level exception chaining. ---------- assignee: -> ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 09:47:20 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 08 Jan 2015 08:47:20 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1420706840.38.0.0765067033815.issue22906@psf.upfronthosting.co.za> Nick Coghlan added the comment: Looking more closely at the patch: * for the missing tracebacks, you're probably hitting the note in https://docs.python.org/3/c-api/exceptions.html#c.PyErr_NormalizeException and need an explicit call to PyErr_SetTraceback (My recollection is that I made this same mistake when working on the codec chaining patch, so we may want to revisit the comment before PyErr_NormalizeException that suggests making setting the traceback attribute on the normalized value implicit) * to trigger the implicit chaining in PyErr_String, try calling PyErr_Restore on the normalized exception before calling PyErr_SetString, rather than just dropping the references. That should let you drop the subsequent explicit PyErr_SetContext call. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 09:58:49 2015 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 08 Jan 2015 08:58:49 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> Message-ID: <1420707529.48.0.194406905509.issue23185@psf.upfronthosting.co.za> Mark Dickinson added the comment: I have an updated patch taking into account the most recent review comments (for which thanks!), but it's at home; I'll upload it this evening (UTC+00:00). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 10:28:29 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 08 Jan 2015 09:28:29 +0000 Subject: [issue22560] Add loop-agnostic SSL implementation to asyncio In-Reply-To: <1412548102.84.0.685230620276.issue22560@psf.upfronthosting.co.za> Message-ID: <1420709309.78.0.473995551875.issue22560@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, I wrote the patch for Tulip. Patch regenerated to use Python paths. ---------- Added file: http://bugs.python.org/file37638/sslproto-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 10:28:38 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 08 Jan 2015 09:28:38 +0000 Subject: [issue22560] Add loop-agnostic SSL implementation to asyncio In-Reply-To: <1412548102.84.0.685230620276.issue22560@psf.upfronthosting.co.za> Message-ID: <1420709318.11.0.0976942173429.issue22560@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file37637/sslproto-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 10:31:06 2015 From: report at bugs.python.org (Bernard Spil) Date: Thu, 08 Jan 2015 09:31:06 +0000 Subject: [issue23177] test_ssl: failures on OpenBSD with LibreSSL In-Reply-To: <1420541656.17.0.750310163886.issue23177@psf.upfronthosting.co.za> Message-ID: <1420709466.58.0.982513383896.issue23177@psf.upfronthosting.co.za> Bernard Spil added the comment: LibreSSL defines in opensslv.h #define LIBRESSL_VERSION_NUMBER 0x20000000L #define OPENSSL_VERSION_NUMBER 0x20000000L And FreeBSD replaces #define OPENSSL_VERSION_NUMBER 0x1000107fL Proper way would be to check for LIBRESSL_VERSION_NUMBER string, FreeBSD modifies the OpenSSL version number to indicate its compatibility level (as stated in commit log) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 10:32:40 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 08 Jan 2015 09:32:40 +0000 Subject: [issue23177] test_ssl: failures on OpenBSD with LibreSSL In-Reply-To: <1420541656.17.0.750310163886.issue23177@psf.upfronthosting.co.za> Message-ID: <1420709560.02.0.510972316952.issue23177@psf.upfronthosting.co.za> STINNER Victor added the comment: > Proper way would be to check for LIBRESSL_VERSION_NUMBER string, FreeBSD modifies the OpenSSL version number to indicate its compatibility level (as stated in commit log) Please see the unit test: it checks that the version number and version string are consistent. It's not the case on OpenBSD with LibreSSL (2.0 vs 2.1) nor on FreeBSD (1.0 vs 2.1). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 10:41:45 2015 From: report at bugs.python.org (=?utf-8?q?Jarle_Selv=C3=A5g?=) Date: Thu, 08 Jan 2015 09:41:45 +0000 Subject: [issue23189] Set docstrings to empty string when optimizing with -OO. Message-ID: <1420710105.42.0.0455822244895.issue23189@psf.upfronthosting.co.za> New submission from Jarle Selv?g: Python code byte-compiled with -OO has doc-strings stripped out. This creates problems when compiling different packages which changes the doc-strings by doing something like this: __doc__ += "additional text" (when the docstring is 'None', this will fail). The packages "lmfit 0.8.1" and "Patsy 0.3.0" have this problem, and must be patched before compilation. See related discussion on Stackoverflow: http://stackoverflow.com/questions/22299532/unsupported-operand-types-for-nonetype-and-str-winappdbg-error-after-c Proposal: Set the doc-strings to empty string ("") instead of removing them completely during optimization with -OO. The memory footprint would anyway be the same. ---------- components: Interpreter Core messages: 233634 nosy: jvs priority: normal severity: normal status: open title: Set docstrings to empty string when optimizing with -OO. type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 10:46:16 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 08 Jan 2015 09:46:16 +0000 Subject: [issue23086] Add start and stop parameters to the Sequence.index() ABC mixin method In-Reply-To: <1418935306.72.0.256960321979.issue23086@psf.upfronthosting.co.za> Message-ID: <1420710376.6.0.253864482575.issue23086@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Try something like this: if start < 0: start += len(self) if stop is None: stop = len(self) elif stop < 0: stop += len(self) for i in range(max(start, 0), min(stop, len(self))): if self[i] == value: return i raise ValueError ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 10:57:50 2015 From: report at bugs.python.org (=?utf-8?q?Jarle_Selv=C3=A5g?=) Date: Thu, 08 Jan 2015 09:57:50 +0000 Subject: [issue23189] Set docstrings to empty string when optimizing with -OO. In-Reply-To: <1420710105.42.0.0455822244895.issue23189@psf.upfronthosting.co.za> Message-ID: <1420711070.19.0.571233887594.issue23189@psf.upfronthosting.co.za> Jarle Selv?g added the comment: This issue is only relevant for classes that have this construct: class MyClass(object): __doc__ += '''Some more text''' .... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 11:26:53 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 08 Jan 2015 10:26:53 +0000 Subject: [issue22919] Update PCBuild for VS 2015 In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za> Message-ID: <1420712813.43.0.63780356629.issue22919@psf.upfronthosting.co.za> STINNER Victor added the comment: Hi, I'm no more able to compile Python 3.5 on Windows. I have Visual Studio 2008 Express, Visual Studio 2010 Express. VS 2010 is unable to open PCbuild/pcbuild.sln: it says that the file was created on a more recent Visual Studio version and it is unable to open it. I tried to install Visual Studio 2013 community but it told me that my Windows Seven is too old: it looks like Windows 8.1 or newer is required :-( I found a Visual Studio 2015 Ultime preview, but I don't want to install an heavy "Ultime" IDE, I just want a simple C compiler... > Though the title says VS 2015, builds will work fine with VS 2010 and VS 2013 (and probably VS 2012, but I didn't try it). Even so, I've copied the old project files into PC/VS10.0, though I'd be happy to just forget them. There is no PC/VS10.0 file or directory in the Python source code. I only found two .sln files: PCbuild/pcbuild.sln and PC/example_nt/example.sln. The devguide looks outdated: it only mentions Visual Studio 2010 (and 2008 for Python 2.7). Can you please update it? https://docs.python.org/devguide/setup.html#compiling I am no more able to develop on Windows, the issue becomes very annoying for me. I hate having to install a huge IDE to compile Python. ---------- nosy: +haypo resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 11:31:02 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 08 Jan 2015 10:31:02 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <1420230232.09.0.10127303351.issue23152@psf.upfronthosting.co.za> Message-ID: <1420713062.84.0.0550240741825.issue23152@psf.upfronthosting.co.za> STINNER Victor added the comment: Here is a patch adding a new _Py_fstat() function which uses signed 64-bit integer to store the file size and so is not limited to 2 GB files. I just moved the code from posixmodule.c to fileutils.c. The patch replaces calls to fstat() with _Py_stat() (and also change the stat structure to _Py_stat_struct). I didn't modified _Py_stat() which calls _wstat() on Windows and so also have this issue (limited to 2 GB files on Windows). _Py_stat() is called in zipimport.c, so zipped packages are limited to 2 GB on Windows. I don't know if it's a severe issue or not. os.stat() implementation is more complex than os.fstat() on Windows. I'm unable to test my patch on Windows because Visual Studio 2010 is unable to open the new PCbuild/pcbuild.sln: see my comment on the issue #22919. ---------- keywords: +patch nosy: +haypo Added file: http://bugs.python.org/file37639/py_fstat.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 11:34:16 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 08 Jan 2015 10:34:16 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <1420230232.09.0.10127303351.issue23152@psf.upfronthosting.co.za> Message-ID: <1420713256.98.0.309029839742.issue23152@psf.upfronthosting.co.za> STINNER Victor added the comment: > #define fstat _fstati64 This change (alone) is not safe because _fstati64() doesn't use "struct stat" but "struct __stat64". I don't like such global define, I may have unexpected side effect. I prefer to modify directly calls to fstat() in .c files (like the change implemented in my patch). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 11:38:54 2015 From: report at bugs.python.org (Chris Angelico) Date: Thu, 08 Jan 2015 10:38:54 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1420713534.42.0.857206694544.issue22906@psf.upfronthosting.co.za> Chris Angelico added the comment: PyErr_Restore doesn't seem to trigger exception chaining. But thanks for the tip about explicitly setting the traceback; not sure how I missed that, but now the StopIteration traceback is visible. Minor point: The previous patch was setting the __context__ of the RuntimeError, whereas it ought to have been setting __cause__. Have corrected that. So here, before I move further forward, is a new POC patch; I've removed the patches that rhettinger applied already, and fixed up tracebacks. So now it's a better-behaved POC, at least. ---------- Added file: http://bugs.python.org/file37640/pep0479.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 11:41:15 2015 From: report at bugs.python.org (Chris Angelico) Date: Thu, 08 Jan 2015 10:41:15 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1420713675.84.0.862475722147.issue22906@psf.upfronthosting.co.za> Changes by Chris Angelico : Added file: http://bugs.python.org/file37641/stopiter.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 11:43:34 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 08 Jan 2015 10:43:34 +0000 Subject: [issue22919] Update PCBuild for VS 2015 In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za> Message-ID: <1420713814.06.0.798459511089.issue22919@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh by the way, 2 Windows buildbot slaves are no more able to compile Python. I don't know if it's related to this issue or not. Builder "AMD64 Windows7 SP1 3.x", owned by Jeremy Kloth: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x 2>LINK : fatal error LNK1104: cannot open file 'C:\buildbot.python.org\3.x.kloth-win64\build\PCBuild\amd64\python35_d.dll' [C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\pythoncore.vcxproj] Builder "x86 Windows Server 2003 [SB] 3.x" managed by Snakebite.org (trent): http://buildbot.python.org/all/builders/x86%20Windows%20Server%202003%20%5BSB%5D%203.x E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\Tools\buildbot\..\..\build\TEEB4C~1 - The process cannot access the file because it is being used by another process. (...) 2>E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\PCbuild\pythoncore.vcxproj(415,5): warning : Toolset v100 is not used for official builds. Your build may have errors or incompatibilities. (...) C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(147,5): error MSB6006: "CL.exe" exited with code 128. [E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\PCbuild\pythoncore.vcxproj] Both slaves are part of the group of "3.x stable" buildbots :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 12:04:32 2015 From: report at bugs.python.org (Al Sweigart) Date: Thu, 08 Jan 2015 11:04:32 +0000 Subject: [issue19102] Add tests for CLI of the tabnanny module In-Reply-To: <1380282068.15.0.580247887303.issue19102@psf.upfronthosting.co.za> Message-ID: <1420715072.17.0.623703899753.issue19102@psf.upfronthosting.co.za> Al Sweigart added the comment: Since tabnanny is also a module in the standard library (it is imported by the idle code), wouldn't moving it to lib/test/test_tools make it un-importable? This would be a good case for leaving it where it is. ---------- nosy: +Al.Sweigart _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 12:15:20 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 08 Jan 2015 11:15:20 +0000 Subject: [issue22919] Update PCBuild for VS 2015 In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za> Message-ID: <1420715720.19.0.212367999591.issue22919@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Visual Studio 2013 Professional works fine under Windows 7 SP1 here. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 12:17:50 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 08 Jan 2015 11:17:50 +0000 Subject: [issue22919] Update PCBuild for VS 2015 In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za> Message-ID: <1420715870.84.0.554165379606.issue22919@psf.upfronthosting.co.za> STINNER Victor added the comment: > Visual Studio 2013 Professional works fine under Windows 7 SP1 here. Ok, good to know. But is it correct that the free version of VS 2013 (community) requires Windows 8.1 or newer? It's not cool to require to upgrade Windows to being able to freely compile Python. My MSDN account is probably outdated, I don't think that I have access to the Professional version. Would it be possible to build Python with the light Windows SDK which basically only includes the C compiler and the CRT? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 12:19:23 2015 From: report at bugs.python.org (Chris Angelico) Date: Thu, 08 Jan 2015 11:19:23 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1420715963.72.0.975579048703.issue22906@psf.upfronthosting.co.za> Chris Angelico added the comment: Nick, any particular reason for pointing to https://hg.python.org/cpython/annotate/bbf16fd024df/Lib/__future__.py rather than https://hg.python.org/cpython/annotate/tip/Lib/__future__.py ? I'm looking at both, anyhow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 12:20:38 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 08 Jan 2015 11:20:38 +0000 Subject: [issue23190] OpenSSL fails building with build.bat Message-ID: <1420716038.45.0.141553844503.issue23190@psf.upfronthosting.co.za> New submission from Antoine Pitrou: With "PCbuild\build.bat -d -e", OpenSSL fails building: nasm: fatal: unable to open input file `Z:\cpython\default\externals\openssl- 1.0.1j\tmp32\aes-586.asm' Detailed build log is: "Z:\cpython\default\PCbuild\libeay.vcxproj" (default target) (32:3) -> (BuildNasmFiles target) -> Z:\cpython\default\PCbuild\openssl.props(61,5): error MSB3073: The command "setlocal [Z:\cpython\default\PCbuild\libeay.vcxproj] Z:\cpython\default\PCbuild\openssl.props(61,5): error MSB3073: set PATH=%PATH%;Z:\cpython\default\externals\\nasm-2.11.06\ [Z:\cpython\default\PCbuild\libeay.vcxproj] Z:\cpython\default\PCbuild\openssl.props(61,5): error MSB3073: nasm.exe -f win32 -o "Z:\cpython\default\externals\openssl-1.0.1j\tmp32\libeay\aes-586.obj" "Z:\cpython\default\externals\openssl-1.0.1j\tmp32\aes-586.asm"" exited with code 1. [Z:\cpython\default\PCbuild\libeay.vcxproj] "Z:\cpython\default\PCbuild\pcbuild.proj" (Rebuild target) (1) -> "Z:\cpython\default\PCbuild\_ssl.vcxproj" (Build target) (31:2) -> "Z:\cpython\default\PCbuild\ssleay.vcxproj" (default target) (33:3) -> (ClCompile target) -> c1 : fatal error C1083: Cannot open source file: 'Z:\cpython\default\externals\openssl-1.0.1j\ssl\d1_both.c': No such file or directory [Z:\cpython\default\PCbuild\ssleay.vcxproj] [etc.] It seems there are problems with how the file paths are computed? Also, I have no file "aes-586.asm", how is it supposed to be generated? ---------- components: Build, Windows messages: 233646 nosy: pitrou, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: OpenSSL fails building with build.bat type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 12:22:19 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 08 Jan 2015 11:22:19 +0000 Subject: [issue23190] OpenSSL fails building with build.bat In-Reply-To: <1420716038.45.0.141553844503.issue23190@psf.upfronthosting.co.za> Message-ID: <1420716139.79.0.0500049401482.issue23190@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Z:\cpython\default>dir Z:\cpython\default\externals\openssl-1.0.1j\ Volume in drive Z is antoine Volume Serial Number is 2FA8-F31C Directory of Z:\cpython\default\externals\openssl-1.0.1j 01/08/2015 11:59 AM . 01/08/2015 12:10 PM .. 01/08/2015 11:59 AM tmp32 0 File(s) 0 bytes 3 Dir(s) 49,764,913,152 bytes free Z:\cpython\default>dir Z:\cpython\default\externals\openssl-1.0.1j\tmp32 Volume in drive Z is antoine Volume Serial Number is 2FA8-F31C Directory of Z:\cpython\default\externals\openssl-1.0.1j\tmp32 01/08/2015 11:59 AM . 01/08/2015 11:59 AM .. 01/08/2015 11:59 AM ssleay 01/08/2015 12:17 PM libeay 0 File(s) 0 bytes 4 Dir(s) 49,764,913,152 bytes free ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 12:27:51 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 08 Jan 2015 11:27:51 +0000 Subject: [issue22919] Update PCBuild for VS 2015 In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za> Message-ID: <1420716471.69.0.30943032185.issue22919@psf.upfronthosting.co.za> Mark Lawrence added the comment: @Victor I don't know what version you need for Windows 7 or earlier but I can tell you that VS 2013 Community edition is *NOT* free, I fell into that trap myself, you need the Express edition. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 12:34:54 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 08 Jan 2015 11:34:54 +0000 Subject: [issue23190] OpenSSL fails building with build.bat In-Reply-To: <1420716038.45.0.141553844503.issue23190@psf.upfronthosting.co.za> Message-ID: <1420716894.12.0.821199331048.issue23190@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hmm, probably the svn export had failed for some reason. I deleted the OpenSSL directory, re-ran get_externals.bat and then everything went fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 12:35:24 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 08 Jan 2015 11:35:24 +0000 Subject: [issue23190] OpenSSL fails building with build.bat In-Reply-To: <1420716038.45.0.141553844503.issue23190@psf.upfronthosting.co.za> Message-ID: <1420716924.25.0.860454593241.issue23190@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 13:15:06 2015 From: report at bugs.python.org (Al Sweigart) Date: Thu, 08 Jan 2015 12:15:06 +0000 Subject: [issue7676] IDLE shell shouldn't use TABs In-Reply-To: <1263213381.47.0.181451927584.issue7676@psf.upfronthosting.co.za> Message-ID: <1420719306.24.0.651957995109.issue7676@psf.upfronthosting.co.za> Changes by Al Sweigart : ---------- nosy: +Al.Sweigart _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 14:02:17 2015 From: report at bugs.python.org (M. Schmitzer) Date: Thu, 08 Jan 2015 13:02:17 +0000 Subject: [issue23191] fnmatch regex cache use is not threadsafe Message-ID: <1420722137.58.0.63717437035.issue23191@psf.upfronthosting.co.za> New submission from M. Schmitzer: The way the fnmatch module uses its regex cache is not threadsafe. When multiple threads use the module in parallel, a race condition between retrieving a - presumed present - item from the cache and clearing the cache (because the maximum size has been reached) can lead to KeyError being raised. The attached script demonstrates the problem. Running it will (eventually) yield errors like the following. Exception in thread Thread-10: Traceback (most recent call last): File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner self.run() File "/usr/lib/python2.7/threading.py", line 763, in run self.__target(*self.__args, **self.__kwargs) File "fnmatch_thread.py", line 12, in run fnmatch.fnmatchcase(name, pat) File "/home/marc/.venv/modern/lib/python2.7/fnmatch.py", line 79, in fnmatchcase return _cache[pat].match(name) is not None KeyError: 'lYwrOCJtLU' ---------- components: Library (Lib) files: fnmatch_thread.py messages: 233650 nosy: mschmitzer priority: normal severity: normal status: open title: fnmatch regex cache use is not threadsafe type: crash versions: Python 2.7 Added file: http://bugs.python.org/file37642/fnmatch_thread.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 14:03:15 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 08 Jan 2015 13:03:15 +0000 Subject: [issue23191] fnmatch regex cache use is not threadsafe In-Reply-To: <1420722137.58.0.63717437035.issue23191@psf.upfronthosting.co.za> Message-ID: <1420722195.06.0.0130836541525.issue23191@psf.upfronthosting.co.za> STINNER Victor added the comment: I guess that a lot of stdlib modules are not thread safe :-/ A workaround is to protect calls to fnmatch with your own lock. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 14:15:58 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 08 Jan 2015 13:15:58 +0000 Subject: [issue22919] Update PCBuild for VS 2015 In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za> Message-ID: <1420722958.34.0.551981994697.issue22919@psf.upfronthosting.co.za> Steve Dower added the comment: You will need Windows 7 *SP1*, as I don't think VS will run without the updates. There is also a service pack for VS 2010 that may enable opening the newer solution - it certainly worked for me. We decided not to keep the old project files as they weren't being maintained. Community edition is free, but you need a Microsoft account (also free) to register it. I don't know why this is necessary, but that's the way they set it up. I'll check out that buildbot when I get a chance (Trent's one is known to be busted). The stable buildbots and the one with VS 2015 were doing fine last time I looked. I haven't tried with the SDK compilers, but it should be possible to build with them now. VS is no longer required to build from the command line. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 14:22:26 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 08 Jan 2015 13:22:26 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <1420230232.09.0.10127303351.issue23152@psf.upfronthosting.co.za> Message-ID: <1420723346.18.0.112557029327.issue23152@psf.upfronthosting.co.za> Steve Dower added the comment: I prefer your patch too. (I've posted on the other thread about the build problems, and I'll test this when I get a chance.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 14:22:37 2015 From: report at bugs.python.org (M. Schmitzer) Date: Thu, 08 Jan 2015 13:22:37 +0000 Subject: [issue23191] fnmatch regex cache use is not threadsafe In-Reply-To: <1420722137.58.0.63717437035.issue23191@psf.upfronthosting.co.za> Message-ID: <1420723357.71.0.00190123832324.issue23191@psf.upfronthosting.co.za> M. Schmitzer added the comment: Ok, if that is the attitude in such cases, feel free to close this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 14:25:21 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 08 Jan 2015 13:25:21 +0000 Subject: [issue23191] fnmatch regex cache use is not threadsafe In-Reply-To: <1420722137.58.0.63717437035.issue23191@psf.upfronthosting.co.za> Message-ID: <1420723521.91.0.797765974716.issue23191@psf.upfronthosting.co.za> STINNER Victor added the comment: It would be nice to fix the issue, but I don't know how it is handled in other stdlib modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 14:49:17 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 08 Jan 2015 13:49:17 +0000 Subject: [issue23191] fnmatch regex cache use is not threadsafe In-Reply-To: <1420722137.58.0.63717437035.issue23191@psf.upfronthosting.co.za> Message-ID: <1420724957.47.0.630876402735.issue23191@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It is easy to make fnmatch caching thread safe without locks. Here is a patch. The problem with fnmatch is that the caching is implicit and a user don't know that any lock are needed. So either the need of the lock should be explicitly documented, or fnmatch should be made thread safe. The second option looks more preferable to me. In 3.x fnmatch is thread safe because thread safe lru_cache is used. ---------- keywords: +patch nosy: +serhiy.storchaka stage: -> patch review Added file: http://bugs.python.org/file37643/fnmatch_threadsafe.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 14:55:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 08 Jan 2015 13:55:23 +0000 Subject: [issue23188] Exception chaining should trigger for non-normalised exceptions In-Reply-To: <1420687041.12.0.12728944273.issue23188@psf.upfronthosting.co.za> Message-ID: <1420725323.77.0.177284655019.issue23188@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: _PyErr_ChainExceptions() was added because exceptions raised in C code are not implicitly chained. The code for explicit chaining is error prone, so it was extracted in separate function. Even with _PyErr_ChainExceptions() chaining exceptions look complex. May be implicit chaining all exceptions would be better. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 15:01:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 08 Jan 2015 14:01:08 +0000 Subject: [issue23119] Remove unicode specialization from set objects In-Reply-To: <1419677411.19.0.303130627071.issue23119@psf.upfronthosting.co.za> Message-ID: <1420725668.86.0.516388317096.issue23119@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: +1 for removing unicode specialization. Dictionaries with string keys is a part of the language, but sets of strings are not special. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 15:06:38 2015 From: report at bugs.python.org (M. Schmitzer) Date: Thu, 08 Jan 2015 14:06:38 +0000 Subject: [issue23191] fnmatch regex cache use is not threadsafe In-Reply-To: <1420722137.58.0.63717437035.issue23191@psf.upfronthosting.co.za> Message-ID: <1420725998.66.0.0433018622647.issue23191@psf.upfronthosting.co.za> M. Schmitzer added the comment: @serhiy.storchaka: My thoughts exactly, especially regarding the caching being implicit. From the outside, fnmatch really doesn't look like it could have threading issues. The patch also looks exactly like what I had in mind. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 15:35:43 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 08 Jan 2015 14:35:43 +0000 Subject: [issue23119] Remove unicode specialization from set objects In-Reply-To: <1419677411.19.0.303130627071.issue23119@psf.upfronthosting.co.za> Message-ID: <1420727743.62.0.13523177346.issue23119@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: I'm not sure I follow: Sets of strings are very common when trying to create a unique set of strings or optimizing "name in set_of_names" lookups. Regarding your benchmark numbers: I have a hard time following how they work. A simply "word in set_of_one_word" certainly doesn't make a good benchmark for these sort of tests :-) You should at least test with sets of various sizes and include the non-matching checks as well. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 15:38:37 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 08 Jan 2015 14:38:37 +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: <1420727917.23.0.932195199195.issue15955@psf.upfronthosting.co.za> Martin Panter added the comment: It turns out that GzipFile.read() etc is also susceptible to decompression bombing. Here is a patch to test and fix that, making use of the existing ?max_length? parameter in the ?zlib? module. ---------- Added file: http://bugs.python.org/file37644/gzip-bomb.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 15:42:05 2015 From: report at bugs.python.org (Chris Angelico) Date: Thu, 08 Jan 2015 14:42:05 +0000 Subject: [issue23192] Generator return value ignored in lambda function Message-ID: <1420728125.93.0.910147391239.issue23192@psf.upfronthosting.co.za> New submission from Chris Angelico: As yield is an expression, it's legal in a lambda function, which then means you have a generator function. But it's not quite the same as the equivalent function made with def: $ python3 Python 3.5.0a0 (default:1c51f1650c42+, Dec 29 2014, 02:29:06) [GCC 4.7.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> f=lambda: (yield 5) >>> x=f() >>> next(x) 5 >>> x.send(123) Traceback (most recent call last): File "", line 1, in StopIteration >>> def f(): return (yield 5) ... >>> x=f() >>> next(x) 5 >>> x.send(123) Traceback (most recent call last): File "", line 1, in StopIteration: 123 >>> x = (lambda: print((yield 1)) or 2)() >>> next(x) 1 >>> x.send(3) 3 Traceback (most recent call last): File "", line 1, in StopIteration The last example demonstrates that send() is working, but the return value is not getting propagated. Disassembly shows this: >>> dis.dis(lambda: (yield 5)) 1 0 LOAD_CONST 1 (5) 3 YIELD_VALUE 4 POP_TOP 5 LOAD_CONST 0 (None) 8 RETURN_VALUE >>> def f(): return (yield 5) ... >>> dis.dis(f) 1 0 LOAD_CONST 1 (5) 3 YIELD_VALUE 4 RETURN_VALUE I'm sure this is a bug that will affect very approximately zero people, but it's still a peculiar inconsistency! Verified with 3.5 and 3.4. ---------- components: Interpreter Core messages: 233662 nosy: Rosuav priority: normal severity: normal status: open title: Generator return value ignored in lambda function versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 15:42:18 2015 From: report at bugs.python.org (Chris Angelico) Date: Thu, 08 Jan 2015 14:42:18 +0000 Subject: [issue23192] Generator return value ignored in lambda function In-Reply-To: <1420728125.93.0.910147391239.issue23192@psf.upfronthosting.co.za> Message-ID: <1420728138.61.0.876379436286.issue23192@psf.upfronthosting.co.za> Changes by Chris Angelico : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 15:42:24 2015 From: report at bugs.python.org (Michael Vogt) Date: Thu, 08 Jan 2015 14:42:24 +0000 Subject: [issue23193] Please support "numeric_owner" in tarfile Message-ID: <1420728144.57.0.872420723687.issue23193@psf.upfronthosting.co.za> New submission from Michael Vogt: Please consider adding a option to extract a tarfile with the uid/gid instead of the lookup for uname/gname in the tarheader (i.e. what tar --numeric-owner provides). One use-case is if you unpack a chroot tarfile that contains a /etc/{passwd,group} file with different uid/gid for user/groups like zope that may be present in both host and chroot but have different numbers. With the current approach files owned by this user will get the host uid/gid instead of the uid/gid of the chroot. Attached is a patch to outline what I have in mind - if there is a chance that this patch goes in I'm happy to write the required test (mocking os.chown()) for this to go in. Thanks for your consideration, Michael ---------- components: Library (Lib) files: tarfile-numeric-owner.diff keywords: patch messages: 233663 nosy: mvo priority: normal severity: normal status: open title: Please support "numeric_owner" in tarfile type: enhancement Added file: http://bugs.python.org/file37645/tarfile-numeric-owner.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 15:46:29 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 08 Jan 2015 14:46:29 +0000 Subject: [issue23119] Remove unicode specialization from set objects In-Reply-To: <1419677411.19.0.303130627071.issue23119@psf.upfronthosting.co.za> Message-ID: <1420728389.84.0.466369876641.issue23119@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Sets of strings are very common when trying to create a unique set of strings or optimizing "name in set_of_names" lookups. This is not nearly so common as attributes or globals access, or passing keyword arguments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 15:49:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 08 Jan 2015 14:49:23 +0000 Subject: [issue23193] Please support "numeric_owner" in tarfile In-Reply-To: <1420728144.57.0.872420723687.issue23193@psf.upfronthosting.co.za> Message-ID: <1420728563.52.0.155721486617.issue23193@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +lars.gustaebel, serhiy.storchaka stage: -> patch review versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 15:50:28 2015 From: report at bugs.python.org (Chris Angelico) Date: Thu, 08 Jan 2015 14:50:28 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1420728628.95.0.189423310967.issue22906@psf.upfronthosting.co.za> Chris Angelico added the comment: Okay! I think I have something here. DEFINITELY needs more eyeballs, but all tests pass, including a new one that tests StopIteration leakage both with and without the __future__ directive. Some docs changes have been made (I grepped for 'stopiteration' and 'generator' case insensitively, and changed anything that caught my eye). It'd be nice if the entire test suite and standard library could be guaranteed to work in a post-3.7 world, but I don't know of an easy way to do that, short of peppering the code with unnecessary __future__ directives. ---------- Added file: http://bugs.python.org/file37646/pep0479.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 15:52:37 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 08 Jan 2015 14:52:37 +0000 Subject: [issue23192] Generator return value ignored in lambda function In-Reply-To: <1420728125.93.0.910147391239.issue23192@psf.upfronthosting.co.za> Message-ID: <1420728757.52.0.41344465583.issue23192@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +benjamin.peterson, gvanrossum, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 16:01:22 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 08 Jan 2015 15:01:22 +0000 Subject: [issue23189] Set docstrings to empty string when optimizing with -OO. In-Reply-To: <1420710105.42.0.0455822244895.issue23189@psf.upfronthosting.co.za> Message-ID: <1420729282.98.0.0564502603496.issue23189@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: That's a backward compatibility break since existing code may be expecting None. At least it needs to be carefully considered, and should have no possibility of be applied to anything before Python 3.5. ---------- nosy: +barry versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From mal at egenix.com Thu Jan 8 16:02:01 2015 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 08 Jan 2015 16:02:01 +0100 Subject: [issue23119] Remove unicode specialization from set objects In-Reply-To: <1420728389.84.0.466369876641.issue23119@psf.upfronthosting.co.za> References: <1420728389.84.0.466369876641.issue23119@psf.upfronthosting.co.za> Message-ID: <54AE9BE9.9080406@egenix.com> On 08.01.2015 15:46, Serhiy Storchaka wrote: > >> Sets of strings are very common when trying to create a unique set of strings or optimizing "name in set_of_names" lookups. > > This is not nearly so common as attributes or globals access, or passing keyword arguments. Not at the interpreter level, but unlike dicts, sets are not used much to implement interpreter logic. Their use cases are more based in application code where you basically find two major use cases: 1. check for flag in set of numeric codes 2. check for string in unique set of strings (and their associated set operations, i.e. checking for subsets, superset, etc.) This is why I don't follow Raymond's reasoning. Of course, if he comes up with a patch that makes both cases faster, I'd be +1 ;-) -- Marc-Andre Lemburg eGenix.com From report at bugs.python.org Thu Jan 8 16:02:07 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 08 Jan 2015 15:02:07 +0000 Subject: [issue23119] Remove unicode specialization from set objects In-Reply-To: <1420728389.84.0.466369876641.issue23119@psf.upfronthosting.co.za> Message-ID: <54AE9BE9.9080406@egenix.com> Marc-Andre Lemburg added the comment: On 08.01.2015 15:46, Serhiy Storchaka wrote: > >> Sets of strings are very common when trying to create a unique set of strings or optimizing "name in set_of_names" lookups. > > This is not nearly so common as attributes or globals access, or passing keyword arguments. Not at the interpreter level, but unlike dicts, sets are not used much to implement interpreter logic. Their use cases are more based in application code where you basically find two major use cases: 1. check for flag in set of numeric codes 2. check for string in unique set of strings (and their associated set operations, i.e. checking for subsets, superset, etc.) This is why I don't follow Raymond's reasoning. Of course, if he comes up with a patch that makes both cases faster, I'd be +1 ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 16:10:35 2015 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 08 Jan 2015 15:10:35 +0000 Subject: [issue23119] Remove unicode specialization from set objects In-Reply-To: <1419677411.19.0.303130627071.issue23119@psf.upfronthosting.co.za> Message-ID: <1420729835.97.0.00779451734819.issue23119@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 16:56:52 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 08 Jan 2015 15:56:52 +0000 Subject: [issue23192] Generator return value ignored in lambda function In-Reply-To: <1420728125.93.0.910147391239.issue23192@psf.upfronthosting.co.za> Message-ID: <1420732612.74.0.36499583177.issue23192@psf.upfronthosting.co.za> Guido van Rossum added the comment: Hm, looks like nobody bothered to update the lambda code generation to use the value from yield. I almost feel like there is some unnecessary check "if we are in a lambda" in the code generation for yield. Have you looked through the code generation yet? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 17:02:25 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 08 Jan 2015 16:02:25 +0000 Subject: [issue23192] Generator return value ignored in lambda function In-Reply-To: <1420728125.93.0.910147391239.issue23192@psf.upfronthosting.co.za> Message-ID: <1420732945.84.0.527144890875.issue23192@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 17:03:27 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 08 Jan 2015 16:03:27 +0000 Subject: [issue23119] Remove unicode specialization from set objects In-Reply-To: <1419677411.19.0.303130627071.issue23119@psf.upfronthosting.co.za> Message-ID: <1420733007.15.0.364187985893.issue23119@psf.upfronthosting.co.za> STINNER Victor added the comment: @Raymond: Please disable git format for patches, because Rietveld doesn't support such patch and so we don't get the "review" button. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 17:13:37 2015 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 08 Jan 2015 16:13:37 +0000 Subject: [issue23119] Remove unicode specialization from set objects In-Reply-To: <1419677411.19.0.303130627071.issue23119@psf.upfronthosting.co.za> Message-ID: <1420733617.17.0.210529880718.issue23119@psf.upfronthosting.co.za> Ezio Melotti added the comment: Without changesets information (not included in the git format) rietveld will try to apply the patch on default and if it applies clearly it will work, so creating the patch against an up to date py3 clone should work even with the git format. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 17:35:14 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 08 Jan 2015 16:35:14 +0000 Subject: [issue22919] Update PCBuild for VS 2015 In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za> Message-ID: <1420734914.33.0.0744970781752.issue22919@psf.upfronthosting.co.za> Steve Dower added the comment: Just emailed Jeremy about the buildbot. It looks like the last time tests were run something didn't clean up properly and left the build output locked. There's nothing wrong with the project files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 17:56:48 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 08 Jan 2015 16:56:48 +0000 Subject: [issue23193] Please support "numeric_owner" in tarfile In-Reply-To: <1420728144.57.0.872420723687.issue23193@psf.upfronthosting.co.za> Message-ID: <1420736208.39.0.184517303357.issue23193@psf.upfronthosting.co.za> STINNER Victor added the comment: "(...) if there is a chance that this patch goes in I'm happy to write the required test (mocking os.chown()) for this to go in." We don't accept changes without test. So you must write a test. Implementing the feature in Python makes sense. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 18:27:16 2015 From: report at bugs.python.org (Chris Angelico) Date: Thu, 08 Jan 2015 17:27:16 +0000 Subject: [issue23192] Generator return value ignored in lambda function In-Reply-To: <1420728125.93.0.910147391239.issue23192@psf.upfronthosting.co.za> Message-ID: <1420738036.41.0.262713777832.issue23192@psf.upfronthosting.co.za> Chris Angelico added the comment: I'm not sure what to look for in the code generation. In compile.c lines 3456 and following, there's a LOAD_CONST None coming through, in the else branch of "if (e->v.Yield.value)", but nothing talking about lambda functions. There are constants COMPILER_SCOPE_LAMBDA and COMPILER_SCOPE_FUNCTION, but the only place where they're used is compiler_set_qualname() and I can't see anything obvious there. Hopefully someone more familiar with the code internals will be able to figure this out! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 18:40:20 2015 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 08 Jan 2015 17:40:20 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> Message-ID: <1420738820.04.0.906288580147.issue23185@psf.upfronthosting.co.za> Mark Dickinson added the comment: New patch, addressing review comments. ---------- Added file: http://bugs.python.org/file37647/math_inf_nan4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 19:10:27 2015 From: report at bugs.python.org (Rickard Englund) Date: Thu, 08 Jan 2015 18:10:27 +0000 Subject: [issue23187] Segmentation fault, possibly asyncio related In-Reply-To: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za> Message-ID: <1420740627.22.0.00281073251662.issue23187@psf.upfronthosting.co.za> Changes by Rickard Englund : ---------- nosy: +r-englund _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 19:19:41 2015 From: report at bugs.python.org (Rickard Englund) Date: Thu, 08 Jan 2015 18:19:41 +0000 Subject: [issue22411] Embedding Python on Windows In-Reply-To: <1410717424.69.0.586099783725.issue22411@psf.upfronthosting.co.za> Message-ID: <1420741181.98.0.480309853106.issue22411@psf.upfronthosting.co.za> Rickard Englund added the comment: I have also had this problem. The way I solved it was to undef _DEBUG before including python and then redefine it again: #undef _DEBUG //Prevent linking debug build of python #include #define _DEBUG 1 This is just a hack though and it would be interesting to know if there is a correct way to do it. ---------- nosy: +r-englund _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 19:21:17 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 08 Jan 2015 18:21:17 +0000 Subject: [issue22411] Embedding Python on Windows In-Reply-To: <1410717424.69.0.586099783725.issue22411@psf.upfronthosting.co.za> Message-ID: <1420741277.6.0.36057631969.issue22411@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 19:52:03 2015 From: report at bugs.python.org (Jim Kubicek) Date: Thu, 08 Jan 2015 18:52:03 +0000 Subject: [issue23194] Antigravity prints osascript errors in OS X Yosemite Message-ID: <1420743123.77.0.0822630306948.issue23194@psf.upfronthosting.co.za> New submission from Jim Kubicek: Python 3.4.2 (default, Dec 29 2014, 14:03:16) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import antigravity 2015-01-08 10:45:03.771 osascript[47250:12135049] Error loading /Library/ScriptingAdditions/Adobe Unit Types.osax/Contents/MacOS/Adobe Unit Types: dlopen(/Library/ScriptingAdditions/Adobe Unit Types.osax/Contents/MacOS/Adobe Unit Types, 262): no suitable image found. Did find: /Library/ScriptingAdditions/Adobe Unit Types.osax/Contents/MacOS/Adobe Unit Types: no matching architecture in universal wrapper osascript: OpenScripting.framework - scripting addition "/Library/ScriptingAdditions/Adobe Unit Types.osax" declares no loadable handlers. The import command appears to work correctly (the proper XKCD opens), so I think this issue is just cosmetic. ---------- components: Extension Modules messages: 233676 nosy: jkubicek priority: normal severity: normal status: open title: Antigravity prints osascript errors in OS X Yosemite type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 19:54:13 2015 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 08 Jan 2015 18:54:13 +0000 Subject: [issue23194] Antigravity prints osascript errors in OS X Yosemite In-Reply-To: <1420743123.77.0.0822630306948.issue23194@psf.upfronthosting.co.za> Message-ID: <1420743253.85.0.34347190322.issue23194@psf.upfronthosting.co.za> Ezio Melotti added the comment: Do you see the same messages if you use the webbrowser module directly? ---------- components: +Library (Lib) -Extension Modules nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 19:57:23 2015 From: report at bugs.python.org (Jim Kubicek) Date: Thu, 08 Jan 2015 18:57:23 +0000 Subject: [issue23194] Antigravity prints osascript errors in OS X Yosemite In-Reply-To: <1420743123.77.0.0822630306948.issue23194@psf.upfronthosting.co.za> Message-ID: <1420743443.33.0.433502903075.issue23194@psf.upfronthosting.co.za> Jim Kubicek added the comment: I do. I was just coming back here to post that very thing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 20:00:55 2015 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 08 Jan 2015 19:00:55 +0000 Subject: [issue23194] Antigravity prints osascript errors in OS X Yosemite In-Reply-To: <1420743123.77.0.0822630306948.issue23194@psf.upfronthosting.co.za> Message-ID: <1420743655.08.0.773541732458.issue23194@psf.upfronthosting.co.za> Ezio Melotti added the comment: Does anything change if you use open/open_new/open_new_tab, and/or use different urls (http and https)? ---------- nosy: +hynek, ned.deily, ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 20:02:26 2015 From: report at bugs.python.org (Jim Kubicek) Date: Thu, 08 Jan 2015 19:02:26 +0000 Subject: [issue23194] Antigravity prints osascript errors in OS X Yosemite In-Reply-To: <1420743123.77.0.0822630306948.issue23194@psf.upfronthosting.co.za> Message-ID: <1420743746.42.0.498704198411.issue23194@psf.upfronthosting.co.za> Jim Kubicek added the comment: No, the behavior is the same in all cases ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 20:03:51 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 08 Jan 2015 19:03:51 +0000 Subject: [issue23194] Antigravity prints osascript errors in OS X Yosemite In-Reply-To: <1420743123.77.0.0822630306948.issue23194@psf.upfronthosting.co.za> Message-ID: <1420743831.86.0.409562421874.issue23194@psf.upfronthosting.co.za> Ned Deily added the comment: My guess is that you have an older 32-bit-only Scripting Addition from Adobe installed. This has nothing to do with Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 20:05:42 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 08 Jan 2015 19:05:42 +0000 Subject: [issue23194] Antigravity prints osascript errors in OS X Yosemite In-Reply-To: <1420743123.77.0.0822630306948.issue23194@psf.upfronthosting.co.za> Message-ID: <1420743942.13.0.223257185393.issue23194@psf.upfronthosting.co.za> Ned Deily added the comment: The solution is to either remove or update /Library/ScriptingAdditions/Adobe Unit Types.osax/Contents/MacOS/Adobe Unit. ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 20:10:58 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 08 Jan 2015 19:10:58 +0000 Subject: [issue23194] Antigravity prints osascript errors in OS X Yosemite In-Reply-To: <1420743123.77.0.0822630306948.issue23194@psf.upfronthosting.co.za> Message-ID: <1420744258.07.0.432017819758.issue23194@psf.upfronthosting.co.za> Ned Deily added the comment: P.S. See https://discussions.apple.com/thread/4355847?start=0&tstart=0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 20:22:21 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Thu, 08 Jan 2015 19:22:21 +0000 Subject: [issue23086] Add start and stop parameters to the Sequence.index() ABC mixin method In-Reply-To: <1418935306.72.0.256960321979.issue23086@psf.upfronthosting.co.za> Message-ID: <1420744941.63.0.898754734787.issue23086@psf.upfronthosting.co.za> Devin Jeanpierre added the comment: Are you sure? I noticed that __iter__ went out of its way to avoid calling len(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 21:30:56 2015 From: report at bugs.python.org (Pierre Nugues) Date: Thu, 08 Jan 2015 20:30:56 +0000 Subject: [issue23195] Sorting with locale does not work properly with Python3 on Macos Message-ID: <1420749056.81.0.378421650447.issue23195@psf.upfronthosting.co.za> New submission from Pierre Nugues: The sorted() function does not work properly with macosx. Here is a script to reproduce the issue: import locale locale.setlocale(locale.LC_ALL, "fr_FR.UTF-8") a = ["A", "E", "Z", "a", "e", "?", "z"] sorted(a) sorted(a, key=locale.strxfrm) The execution on MacOsX produces: pierre:Flaubert pierre$ sw_vers -productVersion 10.10.1 pierre:Flaubert pierre$ python3 Python 3.4.2 (v3.4.2:ab2c023a9432, Oct 5 2014, 20:42:22) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. import locale locale.setlocale(locale.LC_ALL, "fr_FR.UTF-8") 'fr_FR.UTF-8' a = ["A", "E", "Z", "a", "e", "?", "z"] sorted(a) ['A', 'E', 'Z', 'a', 'e', 'z', '?'] sorted(a, key=locale.strxfrm) ['A', 'E', 'Z', 'a', 'e', 'z', '?'] while it produces this on your interactive shell (python.org): In [10]: import locale In [11]: locale.setlocale(locale.LC_ALL, "fr_FR.UTF-8") Out[11]: 'fr_FR.UTF-8' In [12]: a = ["A", "E", "Z", "a", "e", "?", "z"] In [13]: sorted(a) Out[13]: ['A', 'E', 'Z', 'a', 'e', 'z', '?'] In [14]: sorted(a, key=locale.strxfrm) Out[14]: ['a', 'A', 'e', 'E', '?', 'z', 'Z'] which is correct. ---------- components: Unicode messages: 233685 nosy: ezio.melotti, haypo, pnugues priority: normal severity: normal status: open title: Sorting with locale does not work properly with Python3 on Macos type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 21:33:56 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 08 Jan 2015 20:33:56 +0000 Subject: [issue23195] Sorting with locale does not work properly with Python3 on Macos In-Reply-To: <1420749056.81.0.378421650447.issue23195@psf.upfronthosting.co.za> Message-ID: <1420749236.02.0.736794269292.issue23195@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 21:54:42 2015 From: report at bugs.python.org (Pierre Nugues) Date: Thu, 08 Jan 2015 20:54:42 +0000 Subject: [issue23196] Greek letters not sorted properly Message-ID: <1420750482.34.0.750338196942.issue23196@psf.upfronthosting.co.za> New submission from Pierre Nugues: Greek letters are not properly sorted when a locale is set. I tested a French and a Greek locales. Here is an output obtained from the Python interactive shell available from the python.org home page: In [22]: a Out[22]: ('?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?') In [26]: sorted(a, key=locale.strxfrm) Out[26]: ['?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?'] The letter '?' is wrongly sorted. You can try to sort the same character list with the ICU demonstration to see the correct ordering here: http://demo.icu-project.org/icu-bin/locexp?_=el&d_=fr&x=col ---------- components: Unicode messages: 233686 nosy: ezio.melotti, haypo, pnugues priority: normal severity: normal status: open title: Greek letters not sorted properly type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 22:27:27 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 08 Jan 2015 21:27:27 +0000 Subject: [issue23195] Sorting with locale does not work properly with Python3 on Macos In-Reply-To: <1420749056.81.0.378421650447.issue23195@psf.upfronthosting.co.za> Message-ID: <1420752447.09.0.767155121802.issue23195@psf.upfronthosting.co.za> STINNER Victor added the comment: locale.strxfrm() have a different implementation in Python 2 and in Python 3: - Python 2 uses strxfrm(), so works on bytes strings - Python 3 uses wcsxfrm(), so works on multibyte strings ("unicode" strings) It looks like Python 2 and 3 have the same behaviour on Mac OS X: the list is not sorted as expected. Test on Mac OS X 10.9.2. Imac-Photo:~ haypo$ cat collate2.py #coding:utf8 import locale, random locale.setlocale(locale.LC_ALL, "fr_FR.UTF-8") print("LC_COLLATE = %s" % locale.setlocale(locale.LC_COLLATE, None)) a = ["A", "E", "Z", "\xc9", "a", "e", "\xe9", "z"] random.shuffle(a) print(sorted(a)) print(sorted(a, key=locale.strxfrm)) Imac-Photo:~ haypo$ cat collate3.py #coding:utf8 import locale, random locale.setlocale(locale.LC_ALL, "fr_FR.UTF-8") print("LC_COLLATE = %s" % locale.setlocale(locale.LC_COLLATE, None)) a = ["A", "E", "Z", "\xc9", "a", "e", "\xe9", "z"] random.shuffle(a) print(ascii(sorted(a))) print(ascii(sorted(a, key=locale.strxfrm))) Imac-Photo:~ haypo$ LC_ALL=fr_FR.utf8 python collate2.py LC_COLLATE = fr_FR.UTF-8 ['A', 'E', 'Z', 'a', 'e', 'z', '\xc9', '\xe9'] ['A', 'E', 'Z', 'a', 'e', 'z', '\xc9', '\xe9'] Imac-Photo:~ haypo$ LC_ALL=fr_FR.utf8 ~/prog/python/default/python.exe ~/collate3.py LC_COLLATE = fr_FR.UTF-8 ['A', 'E', 'Z', 'a', 'e', 'z', '\xc9', '\xe9'] ['A', 'E', 'Z', 'a', 'e', 'z', '\xc9', '\xe9'] On Linux, I get the expected order with Python 3: LC_COLLATE = fr_FR.UTF-8 ['A', 'E', 'Z', 'a', 'e', 'z', '\xc9', '\xe9'] ['a', 'A', 'e', 'E', '\xe9', '\xc9', 'z', 'Z'] On Linux, Python 2 gives me a strange order. It's maybe an issue in my program: haypo at selma$ python x.py LC_COLLATE = fr_FR.UTF-8 ['A', 'E', 'Z', 'a', 'e', 'z', '\xc9', '\xe9'] ['\xe9', '\xc9', 'a', 'A', 'e', 'E', 'z', 'Z'] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 22:46:17 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 08 Jan 2015 21:46:17 +0000 Subject: [issue23195] Sorting with locale (strxfrm) does not work properly with Python3 on Macos In-Reply-To: <1420749056.81.0.378421650447.issue23195@psf.upfronthosting.co.za> Message-ID: <1420753577.69.0.0408024609171.issue23195@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- title: Sorting with locale does not work properly with Python3 on Macos -> Sorting with locale (strxfrm) does not work properly with Python3 on Macos _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 22:48:04 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 08 Jan 2015 21:48:04 +0000 Subject: [issue23196] Greek letters not sorted properly In-Reply-To: <1420750482.34.0.750338196942.issue23196@psf.upfronthosting.co.za> Message-ID: <1420753684.3.0.806280359915.issue23196@psf.upfronthosting.co.za> R. David Murray added the comment: This appears to be a duplicate of issue 23196 (the strxfrm issue). ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Greek letters not sorted properly _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 22:48:27 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 08 Jan 2015 21:48:27 +0000 Subject: [issue23196] Greek letters not sorted properly In-Reply-To: <1420750482.34.0.750338196942.issue23196@psf.upfronthosting.co.za> Message-ID: <1420753707.36.0.178520461927.issue23196@psf.upfronthosting.co.za> R. David Murray added the comment: Oops, I meant issue 23195. ---------- superseder: Greek letters not sorted properly -> Sorting with locale (strxfrm) does not work properly with Python3 on Macos _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 22:48:54 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 08 Jan 2015 21:48:54 +0000 Subject: [issue23195] Sorting with locale (strxfrm) does not work properly with Python3 on Macos In-Reply-To: <1420749056.81.0.378421650447.issue23195@psf.upfronthosting.co.za> Message-ID: <1420753734.92.0.357397763341.issue23195@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 23:26:41 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 08 Jan 2015 22:26:41 +0000 Subject: [issue23195] Sorting with locale (strxfrm) does not work properly with Python3 on Macos In-Reply-To: <1420749056.81.0.378421650447.issue23195@psf.upfronthosting.co.za> Message-ID: <1420756001.27.0.339681117434.issue23195@psf.upfronthosting.co.za> Ned Deily added the comment: The initial difference appears to be a long-standing BSD (including OS X) versus GNU/Linux platform difference. See, for example: http://www.postgresql.org/message-id/18C8A481-33A6-4483-8C24-B8CE70DB7F27 at eggerapps.at Why there is no difference between en and fr UTF-8 is obvious when you look under the covers at the system locale definitions. This is on FreeBSD 10, OS X 10.10 is the same: $ cd /usr/share/locale/fr_FR.UTF-8/ $ ls -l total 8 lrwxr-xr-x 1 root wheel 28 Jan 16 2014 LC_COLLATE -> ../la_LN.US-ASCII/LC_COLLATE lrwxr-xr-x 1 root wheel 17 Jan 16 2014 LC_CTYPE -> ../UTF-8/LC_CTYPE lrwxr-xr-x 1 root wheel 30 Jan 16 2014 LC_MESSAGES -> ../fr_FR.ISO8859-1/LC_MESSAGES -r--r--r-- 1 root wheel 36 Jan 16 2014 LC_MONETARY lrwxr-xr-x 1 root wheel 29 Jan 16 2014 LC_NUMERIC -> ../fr_FR.ISO8859-1/LC_NUMERIC -r--r--r-- 1 root wheel 364 Jan 16 2014 LC_TIME For some reason US-ASCII is used for UTF-8 collation; this is also true for en_US.UTF-8 and de_DE.UTF-8, the only other ones I checked. The postresq discussion and some earlier Python issues suggest using ICU to properly implement Unicode functions like collation across all platforms. But that has never been implemented in Python. Nosing Marc-Andre. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 23:27:21 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 08 Jan 2015 22:27:21 +0000 Subject: [issue23195] Sorting with locale (strxfrm) does not work properly with Python3 on BSD or OS X In-Reply-To: <1420749056.81.0.378421650447.issue23195@psf.upfronthosting.co.za> Message-ID: <1420756041.42.0.861692081362.issue23195@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- title: Sorting with locale (strxfrm) does not work properly with Python3 on Macos -> Sorting with locale (strxfrm) does not work properly with Python3 on BSD or OS X _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 23:37:48 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 08 Jan 2015 22:37:48 +0000 Subject: [issue23195] Sorting with locale (strxfrm) does not work properly with Python3 on BSD or OS X In-Reply-To: <1420749056.81.0.378421650447.issue23195@psf.upfronthosting.co.za> Message-ID: <1420756668.71.0.728045804199.issue23195@psf.upfronthosting.co.za> STINNER Victor added the comment: > The postresq discussion and some earlier Python issues suggest using ICU to properly implement Unicode functions like collation across all platforms. In my experience, the locale module is error-prone and not reliable, especially if you want portability. It just uses functions provided by the OS. And the locales (LC_CTYPE, LC_MESSAGE, etc.) are process-wide which become a major issue if you want to serve different clients using different locales... Windows supports a different locale per thread if I remember correctly. It would be more reliable to use a good library like ICU. You may try: https://pypi.python.org/pypi/PyICU Link showing how to use PyICU to sort a Python sequence: https://stackoverflow.com/questions/11121636/sorting-list-of-string-with-specific-locale-in-python => strings.sort(key=lambda x: collator[loc].getCollationKey(x).getByteArray()) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 23:41:09 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 08 Jan 2015 22:41:09 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> Message-ID: <1420756869.52.0.901499955498.issue23185@psf.upfronthosting.co.za> STINNER Victor added the comment: Except of my small suggestion on the doc (see the review), math_inf_nan4.patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 23:44:10 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 08 Jan 2015 22:44:10 +0000 Subject: [issue23086] Add start and stop parameters to the Sequence.index() ABC mixin method In-Reply-To: <1418935306.72.0.256960321979.issue23086@psf.upfronthosting.co.za> Message-ID: <1420757050.69.0.76274419584.issue23086@psf.upfronthosting.co.za> Josh Rosenberg added the comment: I think it avoids len because the length might change during iteration due to side-effects of other code. Since a shrinking sequence would raise an IndexError anyway when you overran the end, it may as well not assume the length is static and just keep indexing forward until it hits an IndexError. It's less of an issue (though not a non-issue) with index, because index actually performs all the indexing without returning to user code; __iter__ pauses to allow user code to execute between each yield, so the odds of a length mutation are much higher. You might be able to use len (and just say that if a side-effect of an equality comparison causes the sequence to change length, or another thread messes with it, that's your own fault), but you'd probably want to catch and convert IndexError to ValueError to consistently respond to "we didn't find it" with the same exception. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 23:46:09 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 08 Jan 2015 22:46:09 +0000 Subject: [issue22970] Cancelling wait() after notification leaves Condition in an inconsistent state In-Reply-To: <1417404582.01.0.276361050449.issue22970@psf.upfronthosting.co.za> Message-ID: <1420757169.31.0.249930831234.issue22970@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't like the idea of ignoring exceptions (CancelledError). An option may be to store the latest exception and reraise it when the condition is acquired. I'm not sure that it's safe or correct to "retry" to acquire the condition. I don't know what I should think about this issue. I don't see any obvious and simple fix, but I agree that inconsistencies in lock primitives is a severe issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 23:49:41 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 08 Jan 2015 22:49:41 +0000 Subject: [issue23086] Add start and stop parameters to the Sequence.index() ABC mixin method In-Reply-To: <1418935306.72.0.256960321979.issue23086@psf.upfronthosting.co.za> Message-ID: <1420757381.63.0.826889174686.issue23086@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Note: index returns without the caller having a chance to execute code that would change the sequence length directly. But other threads could change it, as could a custom __eq__ on an object stored in the sequence (or a poorly implemented __getitem__ or __len__ on the sequence itself, but that's getting even more pathological). Thread consistency is the code's responsibility though (we just need to make sure we behave the best we can, and hope they use locks correctly), and the odds of equality of __getitem__ altering the sequence are much lower than the odds of someone iterating the sequence and changing it as they go (which is what __iter__'s implementation allows, responding with potentially incomplete results since items might be skipped due to the mutation), but keeping the sequence in a consistent state. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 8 23:54:38 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 08 Jan 2015 22:54:38 +0000 Subject: [issue22970] Cancelling wait() after notification leaves Condition in an inconsistent state In-Reply-To: <1417404582.01.0.276361050449.issue22970@psf.upfronthosting.co.za> Message-ID: <1420757677.99.0.352743384449.issue22970@psf.upfronthosting.co.za> STINNER Victor added the comment: threading.Condition.wait() implementation is very similar to asyncio.Condition.wait(), and the threading code only call acquire() once, it doesn't loop or ignore exceptions. Does it mean that threading.Condition.wait() has the same issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 00:23:45 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 08 Jan 2015 23:23:45 +0000 Subject: [issue22560] Add loop-agnostic SSL implementation to asyncio In-Reply-To: <1412548102.84.0.685230620276.issue22560@psf.upfronthosting.co.za> Message-ID: <1420759425.46.0.208632074209.issue22560@psf.upfronthosting.co.za> STINNER Victor added the comment: For STARTTLS, see also this issue: https://code.google.com/p/tulip/issues/detail?id=79 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 00:41:10 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Thu, 08 Jan 2015 23:41:10 +0000 Subject: [issue23086] Add start and stop parameters to the Sequence.index() ABC mixin method In-Reply-To: <1418935306.72.0.256960321979.issue23086@psf.upfronthosting.co.za> Message-ID: <1420760470.0.0.805562259675.issue23086@psf.upfronthosting.co.za> Devin Jeanpierre added the comment: I'm going to add a test case that changes the sequence length during .index(), and just do whatever list does in that case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 01:11:52 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 09 Jan 2015 00:11:52 +0000 Subject: [issue23197] asyncio: check if a future is cancelled before calling set_result/set_exception Message-ID: <1420762312.46.0.962527500609.issue23197@psf.upfronthosting.co.za> New submission from STINNER Victor: set_result/set_exception methods of an asyncio.Future raise an exception if the future is cancelled. Attached patch adds the check in 3 remaining places. ---------- components: asyncio files: asyncio.patch keywords: patch messages: 233699 nosy: gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio: check if a future is cancelled before calling set_result/set_exception versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37648/asyncio.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 01:41:19 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 09 Jan 2015 00:41:19 +0000 Subject: [issue23198] asyncio: refactor StreamReader Message-ID: <1420764079.77.0.670547785997.issue23198@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patch refactors the asyncio.StreamReader class: - use the value None instead of True or False to wake up the waiter - add a new _wakeup_waiter() method - replace _create_waiter() method with a _wait_for_data() coroutine function The change adds a subgenerator (_wait_for_data), is it an issue in term of performances? (I don't think so.) ---------- components: asyncio files: refactor_streamreader.patch keywords: patch messages: 233700 nosy: gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio: refactor StreamReader versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37649/refactor_streamreader.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 01:43:58 2015 From: report at bugs.python.org (Al Sweigart) Date: Fri, 09 Jan 2015 00:43:58 +0000 Subject: [issue7676] IDLE shell shouldn't use TABs In-Reply-To: <1263213381.47.0.181451927584.issue7676@psf.upfronthosting.co.za> Message-ID: <1420764238.74.0.45600820568.issue7676@psf.upfronthosting.co.za> Al Sweigart added the comment: There are three pieces of user-specified configuration: (1) the number of spaces for a tab set in IDLE's config, (2) the sys.ps1 value, and (3) the sys.ps2 value. Currently IDLE's shell is ignoring (1) while the editor is not. IDLE's shell is ignoring (3) while the python shell isn't. I think the obvious solution is to make IDLE's shell follow the same behavior as IDLE's editor and the python shell. The draw back comes from variable-pitch fonts, but I think using variable-pitch fonts is a minority use case and will create spacing issues regardless (compared pasting 8 spaces and pasting 1 tab into the editor with Lucida Sans Unicode). Special cases aren't special enough to break the rules. This issue is concerned with mixed tabs and spaces in the IDLE shell, which has a simple fix. Putting the >>> and ... prompts in a separate space so that they are not copied can be done in a separate issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 01:45:37 2015 From: report at bugs.python.org (Zach Welch) Date: Fri, 09 Jan 2015 00:45:37 +0000 Subject: [issue23199] libpython27.a in amd64 release is 32-bit Message-ID: <1420764337.42.0.255694319213.issue23199@psf.upfronthosting.co.za> New submission from Zach Welch: I tried to link a program against the libpython27.a provided by the latest 2.7.9 amd64 installer, only to discover that the provided library is a 32-bit version. I had to go through the gendef/dlltool dance in order to produce a useable 64-bit library from the DLL. ---------- components: Library (Lib), Windows messages: 233702 nosy: steve.dower, tim.golden, zach.ware, zwelch priority: normal severity: normal status: open title: libpython27.a in amd64 release is 32-bit type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 01:52:56 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 09 Jan 2015 00:52:56 +0000 Subject: [issue23197] asyncio: check if a future is cancelled before calling set_result/set_exception In-Reply-To: <1420762312.46.0.962527500609.issue23197@psf.upfronthosting.co.za> Message-ID: <1420764776.16.0.284451864195.issue23197@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, I forgot that the change in subprocess.py (check if waiter is cancelled before setting its result) is already part of the issue #23197 which comes with an unit test. The changes on the SSL handshake are still needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 02:01:00 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Fri, 09 Jan 2015 01:01:00 +0000 Subject: [issue22986] Improved handling of __class__ assignment In-Reply-To: <1417563561.24.0.575634102448.issue22986@psf.upfronthosting.co.za> Message-ID: <1420765260.08.0.448059875041.issue22986@psf.upfronthosting.co.za> Nathaniel Smith added the comment: I hereby invoke the one month ping rule! Patch, be pinged! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 02:02:31 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 09 Jan 2015 01:02:31 +0000 Subject: [issue7676] IDLE shell shouldn't use TABs In-Reply-To: <1263213381.47.0.181451927584.issue7676@psf.upfronthosting.co.za> Message-ID: <1420765351.18.0.18570076112.issue7676@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I believe I explained above the logical and technical factors that make the Idle shell inherently different from the console shell in this regard. As the title says, this issue is about not using tabs and not about mixing tabs and spaces. As I already said, my intended fix is to put the prompt in a sidebar (adapting the proposed editor line number code), which will allow use of space indents in the entry area, as in the editor. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 02:14:32 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 09 Jan 2015 01:14:32 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <20150109011411.11589.37150@psf.io> Roundup Robot added the comment: New changeset fbe87fb071a6 by Victor Stinner in branch 'default': Issue #22038: pyatomic.h now uses stdatomic.h or GCC built-in functions for https://hg.python.org/cpython/rev/fbe87fb071a6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 02:16:08 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 09 Jan 2015 01:16:08 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1420766168.56.0.976584915786.issue22038@psf.upfronthosting.co.za> STINNER Victor added the comment: atomicv3.patch is wrong for GCC builtin atomic operations: the parenthesis is not closed. I fixed this typo in the commit. Vitor & Gustavo: Thanks for the patch, it's now applied to Python 3.5. I tested it on Fedora 21 (x86_64). I disabled manually HAVE_STD_ATOMIC in pyconfig.h to test the two new options (stdatomic header & GCC builtins). ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 02:20:44 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 09 Jan 2015 01:20:44 +0000 Subject: [issue23025] ssl.RAND_bytes docs should mention os.urandom In-Reply-To: <1418235366.16.0.20927959194.issue23025@psf.upfronthosting.co.za> Message-ID: <1420766444.04.0.986649089753.issue23025@psf.upfronthosting.co.za> STINNER Victor added the comment: To be clear: rand.diff looks good to me, go ahead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 02:26:21 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 09 Jan 2015 01:26:21 +0000 Subject: [issue23200] Clarify max_length and flush() for zlib decompression Message-ID: <1420766781.53.0.179588350228.issue23200@psf.upfronthosting.co.za> New submission from Martin Panter: This simple patch documents that max_length has to be non-zero. The implementation actually uses zero as a special value to indicate max_length was not specified. Also, I wonder what the point of the Decompressor.flush() method is. Reading the module code and zlib manual, it looks like it would return the same data as decompressor.decompress(decompressor.unconsumed_tail), except that it uses the Z_FINISH flag instead of Z_SYNC_FLUSH, so that zlib can optimize by assuming no more data is to be processed. Since unconsumed_tail is read-only and only relevant when using max_length, and flush does not support max_length, I wonder if the flush() method should be deprecated. To further test this theory, I modified the test_zlib.py file so that all appropriate flush() calls are equivalent to this: self.assertFalse(dco.flush()) and the tests all still pass. BTW, it looks to me like zlib_Decompress_flush_impl() is setting avail_out too high (blessing unallocated memory) when the total length is more than half of UNIT_MAX, but I am not in a position to test this. ---------- assignee: docs at python components: Documentation files: max_length.patch keywords: patch messages: 233709 nosy: docs at python, vadmium priority: normal severity: normal status: open title: Clarify max_length and flush() for zlib decompression versions: Python 3.4 Added file: http://bugs.python.org/file37650/max_length.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 03:08:57 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 09 Jan 2015 02:08:57 +0000 Subject: [issue23200] Clarify max_length and flush() for zlib decompression In-Reply-To: <1420766781.53.0.179588350228.issue23200@psf.upfronthosting.co.za> Message-ID: <1420769337.91.0.0894631942911.issue23200@psf.upfronthosting.co.za> Martin Panter added the comment: The processing of unconsumed_tail in flush() was introduced via Issue 16411. Before that I suspect flush() was assumed to only be called when max_length was not used. The decompress() method changed from Z_NO_FLUSH to Z_SYNC_FLUSH in Feb 2001; see revision 01c2470eeb2e. I guess previously flush() was necessary to get all your data. The max_length parameter was added later in October that year; see Issue 403753 and revision 60e12f83d2d2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 04:13:06 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Fri, 09 Jan 2015 03:13:06 +0000 Subject: [issue23201] Decimal(0)**0 is an error, 0**0 is 1, but Decimal(0) == 0 Message-ID: <1420773186.22.0.229704657455.issue23201@psf.upfronthosting.co.za> New submission from Devin Jeanpierre: >>> import decimal >>> x = 0 >>> y = float(x) >>> z = decimal.Decimal(x) >>> x == y == z == x True >>> x ** x 1 >>> y**y 1.0 >>> z**z Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/decimal.py", line 2216, in __pow__ return context._raise_error(InvalidOperation, '0 ** 0') File "/usr/lib/python2.7/decimal.py", line 3872, in _raise_error raise error(explanation) decimal.InvalidOperation: 0 ** 0 This is PHP-like and confusing, and maybe not justified just by standards compliance. If it is justified by standards compliance, this deserves to be spelled out in big red letters in the documentation for the decimal module, along with any other inconsistencies. ---------- components: Library (Lib) messages: 233711 nosy: Devin Jeanpierre priority: normal severity: normal status: open title: Decimal(0)**0 is an error, 0**0 is 1, but Decimal(0) == 0 versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 04:13:11 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Fri, 09 Jan 2015 03:13:11 +0000 Subject: [issue23201] Decimal(0)**0 is an error, 0**0 is 1, but Decimal(0) == 0 In-Reply-To: <1420773186.22.0.229704657455.issue23201@psf.upfronthosting.co.za> Message-ID: <1420773191.1.0.040338602311.issue23201@psf.upfronthosting.co.za> Changes by Devin Jeanpierre : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 04:27:14 2015 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 09 Jan 2015 03:27:14 +0000 Subject: [issue23201] Decimal(0)**0 is an error, 0**0 is 1, but Decimal(0) == 0 In-Reply-To: <1420773186.22.0.229704657455.issue23201@psf.upfronthosting.co.za> Message-ID: <1420774034.88.0.380920652807.issue23201@psf.upfronthosting.co.za> Ezio Melotti added the comment: In the code there is this comment: # 0**0 = NaN (!), x**0 = 1 for nonzero x (including +/-Infinity) and raising the error for this specific case seems intentional. ---------- nosy: +ezio.melotti, facundobatista, mark.dickinson, rhettinger, skrah versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 04:33:29 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 09 Jan 2015 03:33:29 +0000 Subject: [issue23201] Decimal(0)**0 is an error, 0**0 is 1, but Decimal(0) == 0 In-Reply-To: <1420773186.22.0.229704657455.issue23201@psf.upfronthosting.co.za> Message-ID: <1420774409.05.0.156766258662.issue23201@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Intentional, but really hard to justify from a consistency perspective. There appear to be several reasonable arguments to treat it as 1 regardless of the mathematical impurity ( https://www.math.hmc.edu/funfacts/ffiles/10005.3-5.shtml ), and since we clearly accept that for int and float, it seems reasonable to extend it to Decimal. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 04:37:43 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Fri, 09 Jan 2015 03:37:43 +0000 Subject: [issue23201] Decimal(0)**0 is an error, 0**0 is 1, but Decimal(0) == 0 In-Reply-To: <1420773186.22.0.229704657455.issue23201@psf.upfronthosting.co.za> Message-ID: <1420774663.86.0.460868959368.issue23201@psf.upfronthosting.co.za> Devin Jeanpierre added the comment: Yes, also, it is documented: https://docs.python.org/3/library/decimal.html#decimal.InvalidOperation Still, the status quo is bad. At the very least there should be clear documentation on how Decimal differs in behavior from floats and ints. (Other than the obvious, like 1/5 taking on a different value -- although explicitly mentioning that in the list might be a good idea.) BTW, 0**0=1 is not mathematically impure. It at one point was fairly well accepted as the right answer, since it's the one that tends to come out naturally . e.g. http://arxiv.org/abs/math/9205211 page 6 ("ripples") . This might explain why ints and floats so casually evaluate 0**0 to 1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 04:57:15 2015 From: report at bugs.python.org (Chris Rebert) Date: Fri, 09 Jan 2015 03:57:15 +0000 Subject: [issue23201] Decimal(0)**0 is an error, 0**0 is 1, but Decimal(0) == 0 In-Reply-To: <1420773186.22.0.229704657455.issue23201@psf.upfronthosting.co.za> Message-ID: <1420775835.84.0.0760325911988.issue23201@psf.upfronthosting.co.za> Chris Rebert added the comment: This behavior seems to be required by the General Decimal Arithmetic Specification (http://speleotrove.com/decimal/daexcep.html ): > The following exceptional conditions can occur: > [...] > Invalid operation > This occurs and signals "invalid-operation" if: > [...] > * both operands of the "power" operation are zero "signals invalid-operation" apparently being mapped by default in Python to "raise the InvalidOperation exception". ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 05:01:18 2015 From: report at bugs.python.org (Brian Thorne) Date: Fri, 09 Jan 2015 04:01:18 +0000 Subject: [issue16192] ctypes - documentation example In-Reply-To: <1349923369.86.0.516068156992.issue16192@psf.upfronthosting.co.za> Message-ID: <1420776078.92.0.452075909876.issue16192@psf.upfronthosting.co.za> Changes by Brian Thorne : ---------- nosy: -Thorney, chris.jerdonek, eric.araujo, ezio.melotti, georg.brandl status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 06:45:41 2015 From: report at bugs.python.org (Al Sweigart) Date: Fri, 09 Jan 2015 05:45:41 +0000 Subject: [issue23184] Unused imports, variables, file in IDLE In-Reply-To: <1420626411.51.0.528702156456.issue23184@psf.upfronthosting.co.za> Message-ID: <1420782341.4.0.282234730488.issue23184@psf.upfronthosting.co.za> Al Sweigart added the comment: I've updated the patch. I've removed the EditorWindow deletion. Importing that and using it as a class variable instead of using an assignment statement wasn't picked up. (Is there a more opaque way to do this import?) I've left the RemoteDebugger.py change in. The frame variable name is (confusingly) reused: frame = frametable[fid] # ...cut for brevity... stack, i = self.idb.get_stack(frame, tb) stack = [(wrap_frame(frame), k) for frame, k in stack] Changed to: # ...cut for brevity... stack, i = self.idb.get_stack(frametable[fid], tb) stack = [(wrap_frame(frame), k) for frame, k in stack] The first use of frame is eliminated by simply using frametable[fid] instead. The second use is as the temporary variable inside the list comprehension, which means the "frame" name is reused. With this change, the only time the frame local variable is used is in the list comprehension. This gets rid of the name reuse and makes it a bit simpler. ---------- Added file: http://bugs.python.org/file37651/idle_unused_patch2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 06:46:02 2015 From: report at bugs.python.org (Al Sweigart) Date: Fri, 09 Jan 2015 05:46:02 +0000 Subject: [issue23184] Unused imports, variables, file in IDLE In-Reply-To: <1420626411.51.0.528702156456.issue23184@psf.upfronthosting.co.za> Message-ID: <1420782362.76.0.0576108821038.issue23184@psf.upfronthosting.co.za> Al Sweigart added the comment: *more transparent, that is. Not opaque. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 07:02:04 2015 From: report at bugs.python.org (Florian Bruhin) Date: Fri, 09 Jan 2015 06:02:04 +0000 Subject: [issue23202] pyvenv does not fail like documented when a venv already exists Message-ID: <1420783324.13.0.763537521613.issue23202@psf.upfronthosting.co.za> New submission from Florian Bruhin: https://docs.python.org/3/library/venv.html says: > If the target directory already exists an error will be raised, unless the --clear or --upgrade option was provided. However, that doesn't seem to be the case: [florian at ginny ~]$ python --version Python 3.4.2 [florian at ginny ~]$ pyvenv foobar [florian at ginny ~]$ ls foobar bin include lib lib64 pyvenv.cfg [florian at ginny ~]$ pyvenv foobar [florian at ginny ~]$ ---------- components: Library (Lib) messages: 233718 nosy: The Compiler, vinay.sajip priority: normal severity: normal status: open title: pyvenv does not fail like documented when a venv already exists type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 07:44:42 2015 From: report at bugs.python.org (Franck Michea) Date: Fri, 09 Jan 2015 06:44:42 +0000 Subject: [issue23203] Aliasing import of sub-{module, package} from the package raises AttributeError on import. Message-ID: <1420785882.78.0.914141516682.issue23203@psf.upfronthosting.co.za> New submission from Franck Michea: Hi, for those of you that prefer to read an example, you can read that commented demonstration of the bug[1]. Today I discovered what I think is a bug in the import system. Here is the basic setup: We have three nested packages: foo -> bar -> baz. The bar package imports foo.bar.baz. We try to import foo.bar. This works well unless we try to alias the foo.bar.baz import in foo.bar with the "import ... as ..." syntax. In that case the file will be read and executed but when we get out of the import statement, then python throws: Traceback (most recent call last): File "", line 1, in File "foo_alias_mod/bar/__init__.py", line 1, in import foo_alias_mod.bar.baz as name_does_not_matter AttributeError: 'module' object has no attribute 'bar' This works whether baz is a package or a module actually. It does not matter if it's from the interpreter, or in a file, ... I've seen it trigger with 2.7.5, 2.7.9, 3.4.5, tip, so I guess this has been here for some time. Please read the link below for a complete demo, and you can always download the tarball[2] to test yourself. [1]: Commented demonstration: http://98810f8c06.net/wtf_python.html [2]: Tarball for test: http://98810f8c06.net/wtf_python-demo.tar.bz2 ---------- components: Interpreter Core messages: 233719 nosy: franck priority: normal severity: normal status: open title: Aliasing import of sub-{module,package} from the package raises AttributeError on import. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 08:16:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 09 Jan 2015 07:16:11 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> Message-ID: <1420787771.77.0.763764412098.issue23185@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: May be make math.inf and math.nan special objects so that for all x (except inf and nan): x < math.inf x > -math.inf not (x < math.nan) not (x > math.nan) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 08:25:48 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Fri, 09 Jan 2015 07:25:48 +0000 Subject: [issue23204] list.index and rest of list methods disagree if a value is in the list if it's mutated during the call Message-ID: <1420788348.75.0.1692375665.issue23204@psf.upfronthosting.co.za> New submission from Devin Jeanpierre: >>> class AppendOnUnequal(object): ... def __init__(self, append_to): ... self.append_to = append_to ... def __eq__(self, other): ... if self is other: ... return True ... self.append_to.append(self) ... return False ... >>> L = [1]; AppendOnUnequal(L) in L True >>> L = [1]; L.count(AppendOnUnequal(L)) 1 >>> L = [1]; L.remove(AppendOnUnequal(L)) >>> L = [1]; L.index(AppendOnUnequal(L)) Traceback (most recent call last): File "", line 1, in ValueError: <__main__.AppendOnUnequal object at 0x7f2562d071d0> is not in list .index() is the only odd one out here. Looks like a bug to me. ---------- components: Interpreter Core messages: 233721 nosy: Devin Jeanpierre priority: normal severity: normal status: open title: list.index and rest of list methods disagree if a value is in the list if it's mutated during the call type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 08:26:25 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Fri, 09 Jan 2015 07:26:25 +0000 Subject: [issue23086] Add start and stop parameters to the Sequence.index() ABC mixin method In-Reply-To: <1418935306.72.0.256960321979.issue23086@psf.upfronthosting.co.za> Message-ID: <1420788385.66.0.774416217069.issue23086@psf.upfronthosting.co.za> Devin Jeanpierre added the comment: I take it back, I don't want to copy what the list type does, because it's wrong: http://bugs.python.org/issue23204 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 08:45:01 2015 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 09 Jan 2015 07:45:01 +0000 Subject: [issue23203] Aliasing import of sub-{module, package} from the package raises AttributeError on import. In-Reply-To: <1420785882.78.0.914141516682.issue23203@psf.upfronthosting.co.za> Message-ID: <1420789501.32.0.335418336287.issue23203@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +brett.cannon, eric.snow, ezio.melotti, ncoghlan type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 08:59:28 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 09 Jan 2015 07:59:28 +0000 Subject: [issue23204] list.index and rest of list methods disagree if a value is in the list if it's mutated during the call In-Reply-To: <1420788348.75.0.1692375665.issue23204@psf.upfronthosting.co.za> Message-ID: <1420790368.07.0.389331870854.issue23204@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This is a non-guaranteed behavior. It is allowed to be different from other list methods. The behavior is also very old, stable, and has not been a problem in practice. No good would come from changing it. ---------- nosy: +rhettinger resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 09:01:21 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 09 Jan 2015 08:01:21 +0000 Subject: [issue23086] Add start and stop parameters to the Sequence.index() ABC mixin method In-Reply-To: <1418935306.72.0.256960321979.issue23086@psf.upfronthosting.co.za> Message-ID: <1420790481.65.0.340758230371.issue23086@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I'm afraid you're getting lost in details that don't matter. We're trying to make the index() method more useful so that searches and be restarted where they left off. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 09:07:29 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 09 Jan 2015 08:07:29 +0000 Subject: [issue23204] list.index and rest of list methods disagree if a value is in the list if it's mutated during the call In-Reply-To: <1420788348.75.0.1692375665.issue23204@psf.upfronthosting.co.za> Message-ID: <1420790849.07.0.797207972556.issue23204@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is because list.index() has start and stop parameters, and L.index(x) is equivalent to L.index(x, 0, len(L)). In list.count() and list.remove() the limit is dynamic during iteration, but in list.index() it is specified by arguments before iterating. It is possible to make the limit static in list.count() and list.remove() or to make it floating if stop is absent or negative in list.index(), but this will complicate and slow down the code without good reason. I suggest to close this issue as "wont fix". ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 09:09:22 2015 From: report at bugs.python.org (Pierre Nugues) Date: Fri, 09 Jan 2015 08:09:22 +0000 Subject: [issue23196] Greek letters not sorted properly In-Reply-To: <1420753707.36.0.178520461927.issue23196@psf.upfronthosting.co.za> Message-ID: <71187BB0-6A68-4D82-8078-1FE3245444D5@cs.lth.se> Pierre Nugues added the comment: Hello David, This is not the same issue as 23195. I tested the Greek letters on your interactive console available at Python.org and this is not related to OS X. The Greek sorting works for all the characters I tested except the ??? character, which is in the extended Greek block. This probably explains why it is not properly collated. ICU sorts the letters properly, including ???. I think you should restore my original issue post. Kindest regards, Pierre -- Pierre Nugues, Lunds Tekniska H?gskola, Institutionen f?r datavetenskap, Box 118, S-221 00 Lund, Su?de. T?l. (0046) 46 222 96 40, http://cs.lth.se/pierre_nugues Visiteurs: Lunds Tekniska H?gskola, E-huset, rum 4134A, Ole R?mers v?g 3, S-223 63 Lund. Mon livre/My book: http://ilppp.cs.lth.se (2nd edition, 2014) > Le 8 janv. 2015 ? 22:48, R. David Murray a ?crit : > > > R. David Murray added the comment: > > Oops, I meant issue 23195. > > ---------- > superseder: Greek letters not sorted properly -> Sorting with locale (strxfrm) does not work properly with Python3 on Macos > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 09:16:00 2015 From: report at bugs.python.org (Al Sweigart) Date: Fri, 09 Jan 2015 08:16:00 +0000 Subject: [issue23205] Unit test needed for IDLE's GrepDialog.py's findfiles() Message-ID: <1420791360.73.0.110066531981.issue23205@psf.upfronthosting.co.za> New submission from Al Sweigart: GrepDialog.py's findfiles() method lacks a unit test. The comments in the unit test stub in test_grep.py correctly notes that since findfiles() method does not rely on the GrepDialog class, it can be made into a function. The attached patch does the following: - Moves findfiles() to be a function in the GrepDialog.py module. - Adds a unit test for findfiles() - Adds sensible default arguments - As suggested by the previous stub comments, findfiles() returns a generator instead of a full list - Changes 'list' and 'dir' names since those are built-ins - Uses os.walk() instead of reinventing it. There were so many changes to make that I eventually just rewrote the entire findfiles function. I've checked that the new version returns the same strings as the old version. ---------- components: IDLE files: idle_grep_findfiles_test.diff keywords: patch messages: 233727 nosy: Al.Sweigart priority: normal severity: normal status: open title: Unit test needed for IDLE's GrepDialog.py's findfiles() versions: Python 3.5 Added file: http://bugs.python.org/file37652/idle_grep_findfiles_test.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 09:18:35 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 09 Jan 2015 08:18:35 +0000 Subject: [issue23201] Decimal(0)**0 is an error, 0**0 is 1, but Decimal(0) == 0 In-Reply-To: <1420773186.22.0.229704657455.issue23201@psf.upfronthosting.co.za> Message-ID: <1420791515.34.0.68369891879.issue23201@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > this deserves to be spelled out in big red letters in > the documentation for the decimal module, along with > any other inconsistencies. I think you lost all sense of proportion here. The decimal module is obliged to follow the decimal spec (that is its reason for existence). The decimal module docs are already create a heavy mental load and their usability would not be improved shifting focus to corner case inconsistencies between types that haven't proven to be an issue in practice. If you were to go write a blog post about 0**0 versus Decimal(0)**0, I think you would find that no one cares. ---------- assignee: -> rhettinger priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 09:18:45 2015 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 09 Jan 2015 08:18:45 +0000 Subject: [issue23201] Decimal(0)**0 is an error, 0**0 is 1, but Decimal(0) == 0 In-Reply-To: <1420773186.22.0.229704657455.issue23201@psf.upfronthosting.co.za> Message-ID: <1420791525.38.0.648435711552.issue23201@psf.upfronthosting.co.za> Mark Dickinson added the comment: > This behavior seems to be required by the General Decimal Arithmetic Specification (http://speleotrove.com/decimal/daexcep.html ) Yes, exactly. The decimal module strictly follows that specification. I don't like the 0**0 -> NaN result much either (especially when we also have inf**0 -> 1), but it's what's specified. I've talked to Mike Cowlishaw (the author of the specification) about this particular issue, and the spec is not likely to change on this point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 09:33:20 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 09 Jan 2015 08:33:20 +0000 Subject: [issue23119] Remove unicode specialization from set objects In-Reply-To: <1419677411.19.0.303130627071.issue23119@psf.upfronthosting.co.za> Message-ID: <1420792400.49.0.0632173196168.issue23119@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I'm withdrawing this one. After more work trying many timings on multiple compilers and various sizes and kinds of datasets, it appears that the unicode specialization is still worth it. The cost of the lookup indirection appears to be completely insignificant (i.e. doesn't harm the non-unicode case) while the benefits of the unicode specialized lookup does have measurable benefits in the use case of deduping an iterable of strings. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 09:36:27 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 09 Jan 2015 08:36:27 +0000 Subject: [issue23189] Set docstrings to empty string when optimizing with -OO. In-Reply-To: <1420710105.42.0.0455822244895.issue23189@psf.upfronthosting.co.za> Message-ID: <1420792587.31.0.977126309293.issue23189@psf.upfronthosting.co.za> Raymond Hettinger added the comment: It seems to me that the problem here lies with the packages that use __doc__+="sometext" rather than with -OO which is doing exactly what it is supposed to. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 09:39:42 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 09 Jan 2015 08:39:42 +0000 Subject: [issue23201] Decimal(0)**0 is an error, 0**0 is 1, but Decimal(0) == 0 In-Reply-To: <1420773186.22.0.229704657455.issue23201@psf.upfronthosting.co.za> Message-ID: <1420792782.63.0.253267251228.issue23201@psf.upfronthosting.co.za> STINNER Victor added the comment: > the spec is not likely to change on this point. In this case, we should just document the behaviour with a reference to the General Decimal Arithmetic Specification. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 09:42:58 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 09 Jan 2015 08:42:58 +0000 Subject: [issue23188] Exception chaining should trigger for non-normalised exceptions In-Reply-To: <1420687041.12.0.12728944273.issue23188@psf.upfronthosting.co.za> Message-ID: <1420792978.62.0.948685815389.issue23188@psf.upfronthosting.co.za> Nick Coghlan added the comment: The interesting discovery I made while reviewing the patch for issue 22906 is that there apparently *is* implicit chaining support in PyErr_SetObject: https://hg.python.org/cpython/file/default/Python/errors.c#l70 Chris indicates that it doesn't seem to be triggering for his patch, though (even after normalising and then restoring the exception state), and I haven't fully dug into why yet. Preliminary explorations show that the last two functional modifications were a fix for a crash bug in issue 3611, and Antoine's original implementation of exception chaining in issue 3108. I've added Antoine to the nosy list, as my main takeaway at the moment is that I *don't* currently understand what's going on with the exception chaining, and I'd like to before we merge the PEP 479 patch. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 09:43:56 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 09 Jan 2015 08:43:56 +0000 Subject: [issue23196] Greek letters not sorted properly In-Reply-To: <1420750482.34.0.750338196942.issue23196@psf.upfronthosting.co.za> Message-ID: <1420793036.01.0.66576315019.issue23196@psf.upfronthosting.co.za> STINNER Victor added the comment: Which order do you expect? What is your OS? Result on Linux (Fedora 21) with the french UTF-8 locale. >>> locale.setlocale(locale.LC_ALL, '') 'fr_FR.utf8' >>> locale.getlocale(locale.LC_COLLATE) ('fr_FR', 'UTF-8') >>> sorted(x) ['?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?'] >>> sorted(x, key=locale.strxfrm) ['?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?'] I don't speak greek, I don't know which order is expected. Anyway, as explained in the issue #23195, Python doesn't implement locale.strxfrm(): it just exposes the system functions. On Linux, locales are implemented in the GNU C library ("libc") for example. So I don't see what should be done to "fix" this issue. We are not going to implement locales in Python, use an external library like ICU if you want "better" locales and have a better control on locales. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 09:45:49 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 09 Jan 2015 08:45:49 +0000 Subject: [issue23201] Decimal(0)**0 is an error, 0**0 is 1, but Decimal(0) == 0 In-Reply-To: <1420773186.22.0.229704657455.issue23201@psf.upfronthosting.co.za> Message-ID: <1420793149.98.0.168226358507.issue23201@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The docs already reference the spec. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 09:46:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 09 Jan 2015 08:46:28 +0000 Subject: [issue23086] Add start and stop parameters to the Sequence.index() ABC mixin method In-Reply-To: <1418935306.72.0.256960321979.issue23086@psf.upfronthosting.co.za> Message-ID: <1420793188.48.0.616129015592.issue23086@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I afraid that the patch can change computational complexity. The iteration usually has linear complexity, but indexing can has non-constant complexity. E.g. for linked list it will cause quadratic complexity of index(). May be we should have special case for start=0 and stop=None. And document this. ---------- nosy: +serhiy.storchaka stage: -> patch review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 09:57:16 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 09 Jan 2015 08:57:16 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> Message-ID: <1420793836.41.0.0549154776279.issue23185@psf.upfronthosting.co.za> STINNER Victor added the comment: 2015-01-09 8:16 GMT+01:00 Serhiy Storchaka : > May be make math.inf and math.nan special objects so that for all x (except inf and nan): What do you mean? Implement a subtype of float and override some methods? > x < math.inf > x > -math.inf It's already the case for int, float and decimal.Decimal. > not (x < math.nan) > not (x > math.nan) Comparison to nan always return False. I would be better to raise an error when nan is compared to other numbers (I mean operations like a>b, not a==b), but Python was not designed like that (nor the IEEE 754?). >>> sorted((nan, 1, nan, 2)) [nan, 1, nan, 2] Sorting with NaN is a common issue :-/ See for example: https://stackoverflow.com/questions/4240050/python-sort-function-breaks-in-the-presence-of-nan Anyway, changing NaN behaviour is out of the scope of this issue! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 09:58:55 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 09 Jan 2015 08:58:55 +0000 Subject: [issue22560] New SSL implementation based on ssl.MemoryBIO In-Reply-To: <1412548102.84.0.685230620276.issue22560@psf.upfronthosting.co.za> Message-ID: <1420793935.52.0.839255329153.issue22560@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Add loop-agnostic SSL implementation to asyncio -> New SSL implementation based on ssl.MemoryBIO _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 10:02:50 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 09 Jan 2015 09:02:50 +0000 Subject: [issue23198] asyncio: refactor StreamReader In-Reply-To: <1420764079.77.0.670547785997.issue23198@psf.upfronthosting.co.za> Message-ID: <1420794170.63.0.00521129564251.issue23198@psf.upfronthosting.co.za> STINNER Victor added the comment: See also this feature request: "StreamReader needs a timeout" https://code.google.com/p/tulip/issues/detail?id=96 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 10:04:45 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 09 Jan 2015 09:04:45 +0000 Subject: [issue23119] Remove unicode specialization from set objects In-Reply-To: <1420792400.49.0.0632173196168.issue23119@psf.upfronthosting.co.za> Message-ID: <54AF99A6.20803@egenix.com> Marc-Andre Lemburg added the comment: On 09.01.2015 09:33, Raymond Hettinger wrote: > > I'm withdrawing this one. After more work trying many timings on multiple compilers and various sizes and kinds of datasets, it appears that the unicode specialization is still worth it. > > The cost of the lookup indirection appears to be completely insignificant (i.e. doesn't harm the non-unicode case) while the benefits of the unicode specialized lookup does have measurable benefits in the use case of deduping an iterable of strings. Thanks, Raymond, for the additional testing :-) I did a grep over the Python C source code and it seems that sets are only used by Python/symtable.c for anything mildly performance relevant (which IIRC is used by the byte code compiler) - and those sets have Unicode strings as members. The stdlib uses sets with both Unicode strings and integers as members. From looking at the grep hits, it seems that Unicode strings are more commonly used than integers in the stdlib as set members, e.g. for method names, module names and character sets. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 10:23:22 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Fri, 09 Jan 2015 09:23:22 +0000 Subject: [issue23201] Decimal(0)**0 is an error, 0**0 is 1, but Decimal(0) == 0 In-Reply-To: <1420773186.22.0.229704657455.issue23201@psf.upfronthosting.co.za> Message-ID: <1420795402.81.0.70696640342.issue23201@psf.upfronthosting.co.za> Devin Jeanpierre added the comment: Does the spec have a handy list of differences to floats anywhere, or do you have to internalize the whole thing? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 11:04:04 2015 From: report at bugs.python.org (Pierre Nugues) Date: Fri, 09 Jan 2015 10:04:04 +0000 Subject: [issue23196] Greek letters not sorted properly In-Reply-To: <1420793036.01.0.66576315019.issue23196@psf.upfronthosting.co.za> Message-ID: Pierre Nugues added the comment: Hello Victor, Thank you for your prompt answer. > Which order do you expect? What is your OS? Result on Linux (Fedora 21) with the french UTF-8 locale. You can try this ICU demo http://demo.icu-project.org/icu-bin/locexp?_=el&d_=fr&x=col and paste the list: ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? You will get the same ordering as with Fedora, except the ?. It is a variant of i (corresponding to the letter i in Latin character). It should be sorted as an i and not just after ? (the uppercase form of alpha) and before ? (alpha). > >>>> locale.setlocale(locale.LC_ALL, '') > 'fr_FR.utf8' >>>> locale.getlocale(locale.LC_COLLATE) > ('fr_FR', 'UTF-8') >>>> sorted(x) > ['?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?'] >>>> sorted(x, key=locale.strxfrm) > ['?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?', '?'] > > I don't speak greek, I don't know which order is expected. > > Anyway, as explained in the issue #23195, Python doesn't implement locale.strxfrm(): it just exposes the system functions. On Linux, locales are implemented in the GNU C library ("libc") for example. > > So I don't see what should be done to "fix" this issue. We are not going to implement locales in Python, use an external library like ICU if you want "better" locales and have a better control on locales. May be this would be a good idea? Kindest regards, Pierre -- Pierre Nugues, Lunds Tekniska H?gskola, Institutionen f?r datavetenskap, Box 118, S-221 00 Lund, Su?de. T?l. (0046) 46 222 96 40, http://cs.lth.se/pierre_nugues Visiteurs: Lunds Tekniska H?gskola, E-huset, rum 4134A, Ole R?mers v?g 3, S-223 63 Lund. Mon livre/My book: http://ilppp.cs.lth.se (2nd edition, 2014) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 11:09:58 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 09 Jan 2015 10:09:58 +0000 Subject: [issue23203] Aliasing import of sub-{module, package} from the package raises AttributeError on import. In-Reply-To: <1420785882.78.0.914141516682.issue23203@psf.upfronthosting.co.za> Message-ID: <1420798198.28.0.905238501981.issue23203@psf.upfronthosting.co.za> Nick Coghlan added the comment: You can see the difference between the two cases in the bytecode: >>> dis.dis("import x.y.z") 1 0 LOAD_CONST 0 (0) 3 LOAD_CONST 1 (None) 6 IMPORT_NAME 0 (x.y.z) 9 STORE_NAME 1 (x) 12 LOAD_CONST 1 (None) 15 RETURN_VALUE >>> dis.dis("import x.y.z as bar") 1 0 LOAD_CONST 0 (0) 3 LOAD_CONST 1 (None) 6 IMPORT_NAME 0 (x.y.z) 9 LOAD_ATTR 1 (y) 12 LOAD_ATTR 2 (z) 15 STORE_NAME 3 (bar) 18 LOAD_CONST 1 (None) 21 RETURN_VALUE The aliased version needs to bind the innermost object immediately, so it fails, since "foo.bar" doesn't get set until *after* the import is finished. The version without the alias succeeeds, as it doesn't attempt to eagerly access the attribute before it gets set by the interpreter. To better handle a similar situation with eager attribute lookups during import, issue 17636 changed IMPORT_FROM to fall back to looking at sys.modules when a module attribute it is looking for is missing. Brett, Eric, perhaps it would be worth changing the bytecode emitted in the "import x.y.z as name" case to match that for "from x.y import x as name"? >>> dis.dis("from x.y import z as bar") 1 0 LOAD_CONST 0 (0) 3 LOAD_CONST 1 (('z',)) 6 IMPORT_NAME 0 (x.y) 9 IMPORT_FROM 1 (z) 12 STORE_NAME 2 (bar) 15 POP_TOP 16 LOAD_CONST 2 (None) 19 RETURN_VALUE ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 12:44:11 2015 From: report at bugs.python.org (Gustavo Temple) Date: Fri, 09 Jan 2015 11:44:11 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1420803851.1.0.677858754957.issue22038@psf.upfronthosting.co.za> Gustavo Temple added the comment: Thank you, Victor! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 12:57:23 2015 From: report at bugs.python.org (Robert Kuska) Date: Fri, 09 Jan 2015 11:57:23 +0000 Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs) In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za> Message-ID: <1420804643.56.0.925538133456.issue20160@psf.upfronthosting.co.za> Robert Kuska added the comment: This commit (probably) breaks aarch64 python build. See https://bugzilla.redhat.com/show_bug.cgi?id=1174037 Build was done with libffi 3.1.6, I have also tried with latest upstream libffi version with same result. (gdb) b ReturnRect Function "ReturnRect" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (ReturnRect) pending. (gdb) run test_win32.py Starting program: /usr/bin/python test_win32.py Missing separate debuginfos, use: debuginfo-install glibc-2.20.90-12.fc22.aarch64 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, ReturnRect (i=0, ar=..., br=0x59b750, cp=..., dr=..., er=0x59b750, fp=..., gr=) at /usr/src/debug/Python-2.7.9/Modules/_ctypes/_ctypes_test.c:552 552 if (ar.left + br->left + dr.left + er->left + gr.left != left * 5) (gdb) p fp $1 = {x = 4396722194992, y = 5879632} (gdb) p cp $2 = {x = 15, y = 25} (gdb) ---------- nosy: +rkuska _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 13:22:56 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 09 Jan 2015 12:22:56 +0000 Subject: [issue19051] Unify buffered readers In-Reply-To: <1379600529.46.0.258828532264.issue19051@psf.upfronthosting.co.za> Message-ID: <1420806176.11.0.957684109278.issue19051@psf.upfronthosting.co.za> Martin Panter added the comment: For what it?s worth, it would be better if compressed streams did limit the amount of data they decompressed, so that they are not susceptible to decompression bombs; see Issue 15955. But having a flexible-sized buffer could be useful in other cases. I haven?t looked closely at the code, but I wonder if there is much difference from the existing BufferedReader. Perhaps just that the underlying raw stream in this case can deliver data in arbitrary-sized chunks, but BufferedReader expects its raw stream to deliver data in limited-sized chunks? If you exposed the buffer it could be useful to do many things more efficiently: * readline() with custom newline or end-of-record codes, solving Issue 1152248, Issue 17083 * scan the buffer using string operations or regular expressions etc, e.g. to skip whitespace, read a run of unescaped symbols * tentatively read data to see if a keyword is present, but roll back if the data doesn?t match the keyword ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 13:41:07 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 09 Jan 2015 12:41:07 +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: <1420807267.1.0.71821169783.issue17003@psf.upfronthosting.co.za> Martin Panter added the comment: Is there anything left for this bug or could it be closed? I can confirm my v3.4.2 docs say ?size? instead of ?n? :) ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 13:53:29 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 09 Jan 2015 12:53:29 +0000 Subject: [issue23201] Decimal(0)**0 is an error, 0**0 is 1, but Decimal(0) == 0 In-Reply-To: <1420773186.22.0.229704657455.issue23201@psf.upfronthosting.co.za> Message-ID: <1420808009.42.0.866804452849.issue23201@psf.upfronthosting.co.za> Stefan Krah added the comment: The behavior is already documented (power function): "at least one of x or y must be nonzero" The decimal docs are already so large that it is probably a bad idea to add a warning. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 13:59:20 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 09 Jan 2015 12:59:20 +0000 Subject: [issue5811] io.BufferedReader.peek(): Documentation differs from Implementation In-Reply-To: <1240380953.7.0.732520909261.issue5811@psf.upfronthosting.co.za> Message-ID: <1420808360.88.0.328105758204.issue5811@psf.upfronthosting.co.za> Martin Panter added the comment: Is the current documentation as accurate as it can be? ?The number of bytes returned may be less or more than requested? To me this has always made this method practically useless. A valid implementation could just always return b"". I noticed the BZ2File.peek() documentation (BZ2File is apparently trying to imitate BufferedReader) is slightly more useful: ?At least one byte of data will be returned (unless at EOF)? That could be used for (say) peeking for a LF following a CR. But still the ?size? parameter does not seem very useful. In fact, LZMAFile.peek() says the size is ignored. ---------- nosy: +vadmium versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 14:08:32 2015 From: report at bugs.python.org (eryksun) Date: Fri, 09 Jan 2015 13:08:32 +0000 Subject: [issue16192] ctypes - documentation example In-Reply-To: <1349923369.86.0.516068156992.issue16192@psf.upfronthosting.co.za> Message-ID: <1420808912.53.0.743310679529.issue16192@psf.upfronthosting.co.za> eryksun added the comment: It's not correct that "[The c_int] type is an alias for the c_long type on 32-bit systems". Actually it's an alias if int and long are the same size. Here's the relevant snippet from __init__: if _calcsize("i") == _calcsize("l"): # if int and long have the same size, make c_int an alias for c_long c_int = c_long c_uint = c_ulong else: class c_int(_SimpleCData): _type_ = "i" _check_size(c_int) class c_uint(_SimpleCData): _type_ = "I" _check_size(c_uint) Notably, int and long are the same size on 64-bit Windows: >>> sizeof(c_void_p) # 64-bit 8 >>> c_int >>> sizeof(c_long) 4 ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 14:17:25 2015 From: report at bugs.python.org (INADA Naoki) Date: Fri, 09 Jan 2015 13:17:25 +0000 Subject: [issue23206] json.dumps(ensure_ascii=False) is ~10x slower than json.dumps() Message-ID: <1420809445.24.0.133647496806.issue23206@psf.upfronthosting.co.za> New submission from INADA Naoki: I prefer ensure_ascii=False because it's efficient. But I notice it is very slower. On Python 3.4.2: In [3]: %timeit json.dumps([{'hello': 'world'}]*100) 10000 loops, best of 3: 74.8 ?s per loop In [4]: %timeit json.dumps([{'hello': 'world'}]*100, ensure_ascii=False) 1000 loops, best of 3: 259 ?s per loop On Python HEAD with attached patch: In [2]: %timeit json.dumps([{'hello': 'world'}]*100) 10000 loops, best of 3: 80.8 ?s per loop In [3]: %timeit json.dumps([{'hello': 'world'}]*100, ensure_ascii=False) 10000 loops, best of 3: 80.4 ?s per loop ---------- components: Library (Lib) files: json-fast-unicode-encode.patch keywords: patch messages: 233752 nosy: naoki priority: normal severity: normal status: open title: json.dumps(ensure_ascii=False) is ~10x slower than json.dumps() versions: Python 3.5 Added file: http://bugs.python.org/file37653/json-fast-unicode-encode.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 14:34:21 2015 From: report at bugs.python.org (INADA Naoki) Date: Fri, 09 Jan 2015 13:34:21 +0000 Subject: [issue23206] json.dumps(ensure_ascii=False) is ~10x slower than json.dumps() In-Reply-To: <1420809445.24.0.133647496806.issue23206@psf.upfronthosting.co.za> Message-ID: <1420810461.95.0.381491059622.issue23206@psf.upfronthosting.co.za> INADA Naoki added the comment: I've copied test_encode_basestring_ascii.py and modify it for this patch. ---------- Added file: http://bugs.python.org/file37654/test_encode_basestring.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 15:06:38 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 09 Jan 2015 14:06:38 +0000 Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs) In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za> Message-ID: <1420812398.83.0.432920699237.issue20160@psf.upfronthosting.co.za> Steve Dower added the comment: This change only has an effect of you're building with Visual Studio and our fork of libffi. You seem to have an unrelated issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 15:20:22 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 09 Jan 2015 14:20:22 +0000 Subject: [issue23193] Please support "numeric_owner" in tarfile In-Reply-To: <1420728144.57.0.872420723687.issue23193@psf.upfronthosting.co.za> Message-ID: <1420813222.6.0.108599473947.issue23193@psf.upfronthosting.co.za> Berker Peksag added the comment: The patch also needs documentation update for TarFile.extract(): https://docs.python.org/3/library/tarfile.html#tarfile.TarFile.extract The tarfile documentation is located at Doc/library/tarfile.rst. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 15:20:39 2015 From: report at bugs.python.org (Florian Bruhin) Date: Fri, 09 Jan 2015 14:20:39 +0000 Subject: [issue23207] logging.basicConfig does not validate keyword arguments Message-ID: <1420813239.75.0.476507944816.issue23207@psf.upfronthosting.co.za> New submission from Florian Bruhin: logging.basicConfig uses **kwargs and does not validate them. This caused me to shoot myself in the foot multiple times by passing logLevel instead of level accidentally, and then trying to figure out why my messages don't get logged. ---------- messages: 233756 nosy: The Compiler, vinay.sajip priority: normal severity: normal status: open title: logging.basicConfig does not validate keyword arguments type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 16:02:06 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 09 Jan 2015 15:02:06 +0000 Subject: [issue23046] asyncio.BaseEventLoop is documented, but only exported via asyncio.base_events In-Reply-To: <1418454792.43.0.104807870648.issue23046@psf.upfronthosting.co.za> Message-ID: <1420815726.09.0.58494264261.issue23046@psf.upfronthosting.co.za> STINNER Victor added the comment: See also the "Documentation: document AbstractServer, Server.sockets is specific to asyncio event loops" issue: https://code.google.com/p/tulip/issues/detail?id=188 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 16:03:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 09 Jan 2015 15:03:32 +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: <1420815812.33.0.676476315361.issue17003@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: readlines() parameter name is not unified still (it can be "hint", "size", "sizehint"). There is no obvious winner. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 16:04:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 09 Jan 2015 15:04:18 +0000 Subject: [issue23206] json.dumps(ensure_ascii=False) is ~10x slower than json.dumps() In-Reply-To: <1420809445.24.0.133647496806.issue23206@psf.upfronthosting.co.za> Message-ID: <1420815858.24.0.604761094821.issue23206@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +ezio.melotti, pitrou, rhettinger, serhiy.storchaka stage: -> patch review type: -> performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 16:34:56 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 09 Jan 2015 15:34:56 +0000 Subject: [issue23208] asyncio: add BaseEventLoop._current_handle Message-ID: <1420817695.78.0.447471935777.issue23208@psf.upfronthosting.co.za> New submission from STINNER Victor: One pain point of asynchronous programming is to understand bugs and rebuild the chain of callbacks / coroutines / tasks. I added the source traceback to Handle, Future (Task) and CoroWrapper to help debugging. Here is a new enhancement to provide more context in debug mode: add BaseEventLoop._current_handle which is the handle currently executed. The first usage is the call_exception_handler() which logs the source traceback of the current handle in debug mode. Example: --- import asyncio def bug(): loop.call_exception_handler({'message': 'bug!'}) def schedule_bug(): bug() loop = asyncio.get_event_loop() loop.call_soon(schedule_bug) loop.call_later(1, loop.stop) loop.run_forever() loop.close() --- Output in debug mode, without the patch: --- bug! --- Output in debug mode, with the patch: --- bug! handle_traceback: Handle created at (most recent call last): File "x.py", line 10, in loop.call_soon(schedule_bug) --- Later, I plan to use the source traceback of the current handle in more places. For example, use it to log messages. I would like to know "who" logged the "SSL handshake failed". At the beginning, I wanted to add a source traceback to all transports, but it looks simpler to get the source traceback of the current handler. Moreover, this traceback is more useful than the source traceback of the transport. Previous try to add the source traceback to transports: https://code.google.com/p/tulip/issues/detail?id=212 ---------- components: asyncio files: current_handle.patch keywords: patch messages: 233759 nosy: gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio: add BaseEventLoop._current_handle versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37655/current_handle.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 16:41:00 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 09 Jan 2015 15:41:00 +0000 Subject: [issue23208] asyncio: add BaseEventLoop._current_handle In-Reply-To: <1420817695.78.0.447471935777.issue23208@psf.upfronthosting.co.za> Message-ID: <1420818060.36.0.207099929733.issue23208@psf.upfronthosting.co.za> STINNER Victor added the comment: Yury Selivanov proposed something different in the past: add a "context" (or a context identifier) to tasks to be able to (indirectly) attach local variables to tasks. "Add notion of context_id to event loop" https://code.google.com/p/tulip/issues/detail?id=165 I don't know if BaseEventLoop._current_handle is too specific or might be implemented with a task context. The task context looks to be specific to tasks, whereas handles are very generic in asyncio: almost all functions in asyncio are called in the context of a handle. Previous discussion related to task context: "local context in event loop" https://groups.google.com/forum/#!topic/python-tulip/zix5HQxtElg "ThreadLocal analogue" https://groups.google.com/forum/#!topic/python-tulip/j0cSjUGx8qk See also the tasklocals project: https://github.com/vkryachko/tasklocals ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 16:58:12 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 09 Jan 2015 15:58:12 +0000 Subject: [issue23086] Add start and stop parameters to the Sequence.index() ABC mixin method In-Reply-To: <1418935306.72.0.256960321979.issue23086@psf.upfronthosting.co.za> Message-ID: <1420819092.54.0.22214818917.issue23086@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > The iteration usually has linear complexity The iteration abstract method depends on indexing as well: def __iter__(self): i = 0 try: while True: v = self[i] yield v i += 1 except IndexError: return ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 17:01:32 2015 From: report at bugs.python.org (INADA Naoki) Date: Fri, 09 Jan 2015 16:01:32 +0000 Subject: [issue23206] json.dumps(ensure_ascii=False) is ~10x slower than json.dumps() In-Reply-To: <1420809445.24.0.133647496806.issue23206@psf.upfronthosting.co.za> Message-ID: <1420819292.51.0.782014020084.issue23206@psf.upfronthosting.co.za> INADA Naoki added the comment: Patch update. Now C version does escaping same way to Python version. ---------- Added file: http://bugs.python.org/file37656/json-fast-unicode-encode.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 17:09:03 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 09 Jan 2015 16:09:03 +0000 Subject: [issue22986] Improved handling of __class__ assignment In-Reply-To: <1417563561.24.0.575634102448.issue22986@psf.upfronthosting.co.za> Message-ID: <1420819743.19.0.255130182465.issue22986@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +benjamin.peterson stage: -> patch review type: -> enhancement versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 17:15:50 2015 From: report at bugs.python.org (Joakim Karlsson) Date: Fri, 09 Jan 2015 16:15:50 +0000 Subject: [issue22411] Embedding Python on Windows In-Reply-To: <1410717424.69.0.586099783725.issue22411@psf.upfronthosting.co.za> Message-ID: <1420820150.51.0.252929765935.issue22411@psf.upfronthosting.co.za> Joakim Karlsson added the comment: You shouldn't mix headers with and without the _DEBUG symbol defined. At least on some versions of MSVC this can lead to errors as some standard headers start referencing functions that are not available in both debug and release versions of the MSV C runtime. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 17:40:15 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 09 Jan 2015 16:40:15 +0000 Subject: [issue23014] Don't have importlib.abc.Loader.create_module() be optional In-Reply-To: <1418055538.78.0.471721917483.issue23014@psf.upfronthosting.co.za> Message-ID: <1420821615.9.0.236867369656.issue23014@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 17:40:27 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 09 Jan 2015 16:40:27 +0000 Subject: [issue23014] Don't have importlib.abc.Loader.create_module() be optional In-Reply-To: <1418055538.78.0.471721917483.issue23014@psf.upfronthosting.co.za> Message-ID: <20150109163930.8751.84187@psf.io> Roundup Robot added the comment: New changeset ab72f30bcd9f by Brett Cannon in branch 'default': Issue #23014: Make importlib.abc.Loader.create_module() required when https://hg.python.org/cpython/rev/ab72f30bcd9f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 17:42:49 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 09 Jan 2015 16:42:49 +0000 Subject: [issue16192] ctypes - documentation example In-Reply-To: <1349923369.86.0.516068156992.issue16192@psf.upfronthosting.co.za> Message-ID: <1420821769.48.0.794875073587.issue16192@psf.upfronthosting.co.za> Berker Peksag added the comment: > It's not correct that "[The c_int] type is an alias for the c_long type on 32-bit systems". Actually it's an alias if int and long are the same size. It's already documented at https://docs.python.org/dev/library/ctypes.html#ctypes.c_int "On platforms where sizeof(int) == sizeof(long) it is an alias to c_long." Do you want to write a patch to update the original note? ---------- nosy: +berker.peksag stage: -> needs patch status: closed -> open versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 17:46:59 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 09 Jan 2015 16:46:59 +0000 Subject: [issue22992] Adding a git developer's guide to Mercurial to devguide In-Reply-To: <1417651753.19.0.905189748743.issue22992@psf.upfronthosting.co.za> Message-ID: <1420822019.45.0.415125570133.issue22992@psf.upfronthosting.co.za> Brett Cannon added the comment: If Antoine or Ezio don't make any more comments or commit this themselves then I will take the patch as-is and commit it next Friday. Sorry for the delay, Demian, but December is always a slow month due to holidays. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 17:47:18 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 09 Jan 2015 16:47:18 +0000 Subject: [issue22411] Embedding Python on Windows In-Reply-To: <1410717424.69.0.586099783725.issue22411@psf.upfronthosting.co.za> Message-ID: <1420822038.58.0.917776667277.issue22411@psf.upfronthosting.co.za> Steve Dower added the comment: Yeah, unfortunately the only correct way to do this is to use a debug build of Python. It isn't that difficult to build, but it is extra work and may not be an option at all depending on context (for example, some businesses won't let employees access source code to open-source projects). If you link against python3.dll rather than python34.dll (there's a pre-processor variable to set, but I don't remember it off the top of my head) then you should avoid most of the debug/non-debug issues. I think you'll still need the #undef _DEBUG code though, and you'll lose access to some functionality, so it may not be an appropriate solution for you. I don't think there's any good fix for this for 3.4, short of someone building and releasing a debug build from the same changeset as the actual release. For 3.5 I may be able to add an installer option to install debug binaries alongside the release ones. I'll put some thought into it and try some things out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 17:51:26 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 09 Jan 2015 16:51:26 +0000 Subject: [issue23203] Aliasing import of sub-{module, package} from the package raises AttributeError on import. In-Reply-To: <1420785882.78.0.914141516682.issue23203@psf.upfronthosting.co.za> Message-ID: <1420822286.32.0.545327145423.issue23203@psf.upfronthosting.co.za> Brett Cannon added the comment: I think I would need to see exactly how you want the bytecode to change and then think over any backwards-compatibility issues since this is doesn't come up very often. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 18:02:23 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 09 Jan 2015 17:02:23 +0000 Subject: [issue22992] Adding a git developer's guide to Mercurial to devguide In-Reply-To: <1417651753.19.0.905189748743.issue22992@psf.upfronthosting.co.za> Message-ID: <1420822943.92.0.390758060127.issue22992@psf.upfronthosting.co.za> Demian Brecht added the comment: Thanks for the response Brett and no worries, the delay is totally understandable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 18:16:15 2015 From: report at bugs.python.org (Martin Richard) Date: Fri, 09 Jan 2015 17:16:15 +0000 Subject: [issue23209] asyncio: break some cycles Message-ID: <1420823775.21.0.0191485458241.issue23209@psf.upfronthosting.co.za> New submission from Martin Richard: Hi, I would like to submit 3 trivial modifications which break a cycle each. It is not much, but those three cycles caused a lot of objects to be garbage collected. They can now be freed using the reference counting mechanism, and therefore, reduce the latency that may be involved by the work of the garbage collector in a long living process. In asyncio/base_subprocess.py: WriteSubprocessPipeProto.proc is a reference to a BaseSubprocessTransport object, which holds a reference to the WriteSubprocessPipeProto in self._protocol. I break the cycle in the protocol at the end of connection_lost(). In asyncio/futures.py: wrap_future() defines a lambda which uses a variable defined in the function, therefore creating a closure, referencing the wrap_future() function and creating a cycle. In the (really trivial) patch, the lambda uses the argument "future" instead of the "fut" variable defined in a closure. The closure is not needed anymore. This single cycle is very common, because caused when one uses getaddrinfo(). In asyncio/selectors.py: _BaseSelectorImpl._map keeps a reference to the _SelectorMapping object, which also references the selector with _SelectorMapping._selector. The reference to the map in the selector is cleared once the selector is closed. ---------- files: break-some-cycles.diff keywords: patch messages: 233770 nosy: martius priority: normal severity: normal status: open title: asyncio: break some cycles Added file: http://bugs.python.org/file37657/break-some-cycles.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 18:16:34 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 09 Jan 2015 17:16:34 +0000 Subject: [issue23166] urllib2 ignores opener configuration under certain circumstances In-Reply-To: <1420406037.0.0.986455895168.issue23166@psf.upfronthosting.co.za> Message-ID: <1420823794.12.0.670759380389.issue23166@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 18:16:47 2015 From: report at bugs.python.org (Martin Richard) Date: Fri, 09 Jan 2015 17:16:47 +0000 Subject: [issue23209] asyncio: break some cycles In-Reply-To: <1420823775.21.0.0191485458241.issue23209@psf.upfronthosting.co.za> Message-ID: <1420823807.83.0.440150934935.issue23209@psf.upfronthosting.co.za> Changes by Martin Richard : ---------- components: +asyncio nosy: +gvanrossum, haypo, yselivanov type: -> performance versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 18:32:38 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 09 Jan 2015 17:32:38 +0000 Subject: [issue23210] clarify "virtual sequence" and range docs Message-ID: <1420824758.29.0.716744408314.issue23210@psf.upfronthosting.co.za> New submission from Ethan Furman: The help() function explains range as being a "virtual sequence", but that phrase cannot be found anywhere in the docs. Suggestion is to insert a phrase below: >> The advantage of the range type over a regular list or tuple is >> that a range object is a virtual sequence and so >> will always take the same (small) amount of memory [...] Bonus points for adding a glossary entry. :) ---------- assignee: docs at python components: Documentation messages: 233771 nosy: docs at python, ethan.furman priority: low severity: normal stage: needs patch status: open title: clarify "virtual sequence" and range docs versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 18:34:38 2015 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 09 Jan 2015 17:34:38 +0000 Subject: [issue23209] asyncio: break some cycles In-Reply-To: <1420823775.21.0.0191485458241.issue23209@psf.upfronthosting.co.za> Message-ID: <1420824878.17.0.0635261765215.issue23209@psf.upfronthosting.co.za> Guido van Rossum added the comment: All three changes look good to me. The selectors.py fix should be applied to CPython first; the others to Tulip first. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 18:37:23 2015 From: report at bugs.python.org (Joakim Karlsson) Date: Fri, 09 Jan 2015 17:37:23 +0000 Subject: [issue22411] Embedding Python on Windows In-Reply-To: <1410717424.69.0.586099783725.issue22411@psf.upfronthosting.co.za> Message-ID: <1420825043.73.0.828477981843.issue22411@psf.upfronthosting.co.za> Joakim Karlsson added the comment: A complicating factor is that the debug and release versions of the dll:s seem to behave differently, which makes it hard to replace one with the other. For instance, in dynload_win.c, the suffix of files looked for are "_d.pyd" in debug mode and ".pyd" in release mode. This causes python not to find any .pyd files if I link to the debug version. This might be a separate issue, but it is tighly connected to this as the _DEBUG setting of the embedding app changes how the Python interpreter works. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 18:46:59 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 09 Jan 2015 17:46:59 +0000 Subject: [issue22411] Embedding Python on Windows In-Reply-To: <1410717424.69.0.586099783725.issue22411@psf.upfronthosting.co.za> Message-ID: <1420825619.14.0.938861308691.issue22411@psf.upfronthosting.co.za> Steve Dower added the comment: Right, so when using python34_d.dll you need the _d.pyd versions (and if you're building your own .pyd you need to add the _d suffix too). There's nothing wrong with this difference, since the debug and release builds are subtly incompatible with each other, so the alternative is that you'd get random crashes when mixing them. Better off getting blatant errors that files can't be found. Any option to install a debug build in 3.5 would obviously install a complete debug build - not just the one DLL. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 18:51:21 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 09 Jan 2015 17:51:21 +0000 Subject: [issue23210] clarify "virtual sequence" and range docs In-Reply-To: <1420824758.29.0.716744408314.issue23210@psf.upfronthosting.co.za> Message-ID: <1420825881.1.0.261398198914.issue23210@psf.upfronthosting.co.za> Ethan Furman added the comment: Update: per Guido, we need to drop the word "virtual" from the help() for range. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 18:58:51 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 09 Jan 2015 17:58:51 +0000 Subject: [issue23210] clarify "virtual sequence" and range docs In-Reply-To: <1420824758.29.0.716744408314.issue23210@psf.upfronthosting.co.za> Message-ID: <1420826331.69.0.510603297576.issue23210@psf.upfronthosting.co.za> Ethan Furman added the comment: On 01/09/2015 09:39 AM, Guido van Rossum wrote: > Please don't add this to the glossary and don't start using "virtual" (it is > my favorite example of terminology gone wrong in C++ as well as in colloquial > language). The terminology "virtual sequence" is only used once, and probably > a holdover from the Python 2 times when the idea was to describe the difference > between xrange and range. Just drop the word "virtual" please! I think the word has an important implication (low memory usage) and keeping it (and adding it to the range docs) would be useful to somebody who was searching for such a thing and unfamiliar with how range was constructed... on the other hand, generators are very similar (although not full Sequences) and we don't use the word virtual with them... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 19:39:58 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 09 Jan 2015 18:39:58 +0000 Subject: [issue23210] clarify "virtual sequence" and range docs In-Reply-To: <1420824758.29.0.716744408314.issue23210@psf.upfronthosting.co.za> Message-ID: <1420828798.96.0.94484061602.issue23210@psf.upfronthosting.co.za> R. David Murray added the comment: I agree with Guido. Virtual is an abused word and I can't imagine anyone searching on it unless they saw it used somewhere in the first place. Range is a sequence, and the help docs are just a reminder. The Range docs clearly explain the advantages of the range type. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 20:07:16 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 09 Jan 2015 19:07:16 +0000 Subject: [issue23210] remove the word "virtual" from help(range) In-Reply-To: <1420824758.29.0.716744408314.issue23210@psf.upfronthosting.co.za> Message-ID: <1420830436.85.0.601266392337.issue23210@psf.upfronthosting.co.za> Ethan Furman added the comment: Others have chimed in for removal of the word "virtual", with the Best In Class comment going to Guido for: > To me it is a poisonous buzzword that we're better without. > It has virtually no semantics left. :-) ---------- assignee: docs at python -> components: +Interpreter Core -Documentation nosy: +pitrou title: clarify "virtual sequence" and range docs -> remove the word "virtual" from help(range) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 20:43:52 2015 From: report at bugs.python.org (Geoffrey Spear) Date: Fri, 09 Jan 2015 19:43:52 +0000 Subject: [issue23211] test.test_logging.SMTPHandlerTest failing on Snow Leopard Message-ID: <1420832632.4.0.00679469135671.issue23211@psf.upfronthosting.co.za> New submission from Geoffrey Spear: This seems to be related to issue20605 where _socket.getaddrinfo() mysteriously fails on some Snow Leopard systems but not others; I don't think the cause of that one was ever explained but this appears to be the same error: ====================================================================== ERROR: test_basic (test.test_logging.SMTPHandlerTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/geoff/Documents/programming/cpython/Lib/test/test_logging.py", line 930, in test_basic sockmap) File "/Users/geoff/Documents/programming/cpython/Lib/test/test_logging.py", line 687, in __init__ decode_data=True) File "/Users/geoff/Documents/programming/cpython/Lib/smtpd.py", line 654, in __init__ type=socket.SOCK_STREAM) File "/Users/geoff/Documents/programming/cpython/Lib/socket.py", line 730, in getaddrinfo for res in _socket.getaddrinfo(host, port, family, type, proto, flags): socket.gaierror: [Errno 8] nodename nor servname provided, or not known ---------- components: Macintosh, Tests messages: 233779 nosy: geoffreyspear, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: test.test_logging.SMTPHandlerTest failing on Snow Leopard type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 21:05:10 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 09 Jan 2015 20:05:10 +0000 Subject: [issue23212] Update Windows and OS X installer copies of OpenSSL to 1.0.1k Message-ID: <1420833910.43.0.203396056169.issue23212@psf.upfronthosting.co.za> New submission from Ned Deily: https://www.openssl.org/news/secadv_20150108.txt ---------- components: Build, Macintosh, Windows messages: 233780 nosy: ned.deily, ronaldoussoren, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: needs patch status: open title: Update Windows and OS X installer copies of OpenSSL to 1.0.1k versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 21:36:51 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 09 Jan 2015 20:36:51 +0000 Subject: [issue23209] asyncio: break some cycles In-Reply-To: <1420823775.21.0.0191485458241.issue23209@psf.upfronthosting.co.za> Message-ID: <20150109203625.11573.79423@psf.io> Roundup Robot added the comment: New changeset 376c5398f28d by Victor Stinner in branch '3.4': Issue #23209: Break some reference cycles in asyncio. Patch written by Martin https://hg.python.org/cpython/rev/376c5398f28d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 21:37:20 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 09 Jan 2015 20:37:20 +0000 Subject: [issue23209] asyncio: break some cycles In-Reply-To: <1420823775.21.0.0191485458241.issue23209@psf.upfronthosting.co.za> Message-ID: <1420835840.93.0.988054876512.issue23209@psf.upfronthosting.co.za> STINNER Victor added the comment: Hi Martin, thanks for the patch. It looks good to me. I applied it to Tulip, Python 3.4 and Python 3.5. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 21:58:08 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 09 Jan 2015 20:58:08 +0000 Subject: [issue23209] asyncio: break some cycles In-Reply-To: <1420823775.21.0.0191485458241.issue23209@psf.upfronthosting.co.za> Message-ID: <20150109205800.72573.62841@psf.io> Roundup Robot added the comment: New changeset 7438f2e30908 by Victor Stinner in branch '3.4': Issue #23209: Revert change on selectors, test_selectors failed. https://hg.python.org/cpython/rev/7438f2e30908 New changeset 27cbc877447b by Victor Stinner in branch 'default': (Merge 3.4) Issue #23209: Revert change on selectors, test_selectors failed. https://hg.python.org/cpython/rev/27cbc877447b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 22:05:27 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 09 Jan 2015 21:05:27 +0000 Subject: [issue23209] asyncio: break some cycles In-Reply-To: <1420823775.21.0.0191485458241.issue23209@psf.upfronthosting.co.za> Message-ID: <1420837527.97.0.830450159352.issue23209@psf.upfronthosting.co.za> STINNER Victor added the comment: Ooops, test_selectors fails because get_key() raises "TypeError: 'NoneType' object is not subscriptable" when the selector is closed. A different fix should be written. I'm now using tox to run the Tulip test suite, I'm surprised that I didn't notice the failure. It looks like test_selectors is not executed. runtests.py searchs for test classes with a name ending with "Tests". I will fix that. ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 22:34:53 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 09 Jan 2015 21:34:53 +0000 Subject: [issue23212] Update Windows and OS X installer copies of OpenSSL to 1.0.1k In-Reply-To: <1420833910.43.0.203396056169.issue23212@psf.upfronthosting.co.za> Message-ID: <20150109213419.72559.39792@psf.io> Roundup Robot added the comment: New changeset a216f349771b by Ned Deily in branch '2.7': Issue #23212: Update OS X installer build OpenSSL to 1.0.1k. https://hg.python.org/cpython/rev/a216f349771b New changeset 849ec86651b4 by Ned Deily in branch '2.7': Issue #23212: 2.7-specific OS X installer updates https://hg.python.org/cpython/rev/849ec86651b4 New changeset ce3028357f8b by Ned Deily in branch '3.4': Issue #23212: Update OS X installer build OpenSSL to 1.0.1k. https://hg.python.org/cpython/rev/ce3028357f8b New changeset 726d67a7ebf2 by Ned Deily in branch '3.4': Issue #23212: 3.4-specific OS X installer updates https://hg.python.org/cpython/rev/726d67a7ebf2 New changeset 6d518aa5e1a2 by Ned Deily in branch 'default': Issue #23212: merge from 3.4 https://hg.python.org/cpython/rev/6d518aa5e1a2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 9 23:40:47 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 09 Jan 2015 22:40:47 +0000 Subject: [issue23210] remove the word "virtual" from help(range) In-Reply-To: <1420824758.29.0.716744408314.issue23210@psf.upfronthosting.co.za> Message-ID: <20150109224044.8753.28213@psf.io> Roundup Robot added the comment: New changeset 79f33147949b by Benjamin Peterson in branch '3.4': remove buzzword (closes #23210) https://hg.python.org/cpython/rev/79f33147949b New changeset 154ae3af0317 by Benjamin Peterson in branch 'default': merge 3.4 (#23210) https://hg.python.org/cpython/rev/154ae3af0317 ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 00:40:18 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 09 Jan 2015 23:40:18 +0000 Subject: [issue23206] json.dumps(ensure_ascii=False) is ~10x slower than json.dumps() In-Reply-To: <1420809445.24.0.133647496806.issue23206@psf.upfronthosting.co.za> Message-ID: <1420846818.26.0.128165748894.issue23206@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thank you for the patch! I posted a review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 01:02:11 2015 From: report at bugs.python.org (Thomas D.) Date: Sat, 10 Jan 2015 00:02:11 +0000 Subject: [issue23213] subprocess communicate() hangs when stderr isn't closed Message-ID: <1420848131.85.0.905282247977.issue23213@psf.upfronthosting.co.za> New submission from Thomas D.: Hi, to demonstrate the problem you need >=systemd-217: # python3.4 Python 3.4.2 (default, Oct 12 2014, 20:09:43) [GCC 4.8.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import subprocess >>> sp = subprocess.Popen(["/sbin/udevd", "--daemon"], stdout=subprocess.PIPE, stderr=subprocess.PIPE) >>> out, err = sp.communicate() [hangs] "ps" will show root 9619 0.0 0.1 23340 5404 pts/5 Ss Jan09 0:00 \_ -bash root 13291 0.0 0.2 45352 9784 pts/5 S+ 00:34 0:00 \_ python3.4 root 13311 0.0 0.0 0 0 pts/5 Z+ 00:34 0:00 \_ [udevd] Calling "/sbin/udevd --daemon" from the shell works fine. >>> errorlog = open("/tmp/stderr.log", "wb") >>> sp = subprocess.Popen(["/sbin/udevd", "--daemon"], stdout=subprocess.PIPE, stderr=errorlog) works, too. The problem first appeared in systemd-217. I bisected systemd's source code and the commit since when Python's subprocess module is unable to start udevd is https://github.com/systemd/systemd/commit/5c67cf2774a8b964f4d7cd92a4c447da81ac6087 This is not a systemd/udev only problem. The problem was first seen with the php-fpm daemon from PHP (but only when using "error_log = syslog"). Please see the original bug report at https://github.com/saltstack/salt/issues/14957 for more details. Because Salt is still at Python 2.7, the problem can be reproduced with Python 2.7, too. Is it a bug in subprocess? In systemd/PHP? Are we (salt) using subprocess the wrong way? Thanks! PS: On your system, "/sbin/udevd" will be probably "/lib/systemd/systemd-udevd" Not sure if this is related to http://bugs.python.org/issue12786 in some ways. ---------- components: Library (Lib) messages: 233788 nosy: whissi priority: normal severity: normal status: open title: subprocess communicate() hangs when stderr isn't closed type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 01:07:34 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 10 Jan 2015 00:07:34 +0000 Subject: [issue23188] Exception chaining should trigger for non-normalised exceptions In-Reply-To: <1420687041.12.0.12728944273.issue23188@psf.upfronthosting.co.za> Message-ID: <1420848454.08.0.909579778924.issue23188@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > The interesting discovery I made while reviewing the patch for issue > 22906 is that there apparently *is* implicit chaining support in > PyErr_SetObject Indeed, there is, and it should work properly (AFAIR there was quite a bit of debugging to make this work). Also, note that normalizing is already handled. I'm not sure what you're witnessing that doesn't work as expected. I suspect that you may be confusing "an exception has been caught" (and is ready to be chained from) with "an exception has been raised" (i.e. PyErr_Occurred() is true). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 01:08:29 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 10 Jan 2015 00:08:29 +0000 Subject: [issue19776] Provide expanduser() on Path objects In-Reply-To: <1385409778.55.0.842571848249.issue19776@psf.upfronthosting.co.za> Message-ID: <1420848509.07.0.960776992029.issue19776@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Victor, your patch sounds ok to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 01:53:47 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Sat, 10 Jan 2015 00:53:47 +0000 Subject: [issue23086] Add start and stop parameters to the Sequence.index() ABC mixin method In-Reply-To: <1418935306.72.0.256960321979.issue23086@psf.upfronthosting.co.za> Message-ID: <1420851227.27.0.733863023747.issue23086@psf.upfronthosting.co.za> Devin Jeanpierre added the comment: I inferred from Serhiy's comment that if you override __iter__ to be efficient and not use __getitem__, this overridden behavior used to pass on to index(), but wouldn't after this patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 02:19:39 2015 From: report at bugs.python.org (Tommy Carstensen) Date: Sat, 10 Jan 2015 01:19:39 +0000 Subject: [issue13742] Add a key parameter (like sorted) to heapq.merge In-Reply-To: <1326105342.42.0.0197399269422.issue13742@psf.upfronthosting.co.za> Message-ID: <1420852779.2.0.180821027317.issue13742@psf.upfronthosting.co.za> Tommy Carstensen added the comment: I noticed 3.5 alpha1 is not released until February 1st. Is there any way I can get my hands on this new functionality? ---------- nosy: +Tommy.Carstensen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 02:24:07 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 10 Jan 2015 01:24:07 +0000 Subject: [issue13742] Add a key parameter (like sorted) to heapq.merge In-Reply-To: <1326105342.42.0.0197399269422.issue13742@psf.upfronthosting.co.za> Message-ID: <1420853047.21.0.415740352481.issue13742@psf.upfronthosting.co.za> Berker Peksag added the comment: Hi Tommy, the patch is already committed to Python 3.5. See https://docs.python.org/3.5/library/heapq.html#heapq.merge ---------- nosy: +berker.peksag stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 02:46:22 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 10 Jan 2015 01:46:22 +0000 Subject: [issue23214] BufferedReader.read1(size) signature incompatible with BufferedIOBase.read1(size=-1) Message-ID: <1420854382.8.0.44417983014.issue23214@psf.upfronthosting.co.za> New submission from Martin Panter: I am trying to make LZMAFile (which implements BufferedIOBase) use a BufferedReader in read mode. However this broke test_lzma.FileTestCase.test_read1_multistream(), which calls read1() with the default size argument. This is because BufferedReader.read1() does not accept size=-1: >>> stdin = open(0, "rb", closefd=False) >>> stdin <_io.BufferedReader name=0> >>> stdin.read1() # Parameter is mandatory Traceback (most recent call last): File "", line 1, in TypeError: read1() takes exactly 1 argument (0 given) >>> stdin.read1(-1) # Does not accept the BufferedIOBase default Traceback (most recent call last): File "", line 1, in ValueError: read length must be positive >>> stdin.read1(0) # Technically not positive b'' Also, the BufferedIOBase documentation does not say what the size=-1 value means, only that it reads and returns up to -1 bytes. ---------- components: IO messages: 233794 nosy: vadmium priority: normal severity: normal status: open title: BufferedReader.read1(size) signature incompatible with BufferedIOBase.read1(size=-1) versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 02:55:18 2015 From: report at bugs.python.org (Tommy Carstensen) Date: Sat, 10 Jan 2015 01:55:18 +0000 Subject: [issue13742] Add a key parameter (like sorted) to heapq.merge In-Reply-To: <1326105342.42.0.0197399269422.issue13742@psf.upfronthosting.co.za> Message-ID: <1420854918.1.0.550525312336.issue13742@psf.upfronthosting.co.za> Tommy Carstensen added the comment: Yes, but 3.5 has not been pre-released yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 03:46:30 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 10 Jan 2015 02:46:30 +0000 Subject: [issue23201] Decimal(0)**0 is an error, 0**0 is 1, but Decimal(0) == 0 In-Reply-To: <1420773186.22.0.229704657455.issue23201@psf.upfronthosting.co.za> Message-ID: <1420857990.3.0.363909329123.issue23201@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Mark Dickson wrote: > I've talked to Mike Cowlishaw (the author of the specification) > about this particular issue, and the spec is not likely to > change on this point. I'm curious about the rationale for the decision. As I'm sure you're aware, in general 0**0 is treated as 1 by both a majority (I think) of mathematicians and programming languages. As Knuth puts it, the binomial theorem is too important to do otherwise. IEEE 754 treats it as 1, although the 2008 revision adds a second power function powr() which returns NAN if both arguments are 0. So I wonder why the decimal spec choose to do otherwise? (Not saying they're wrong to do so.) ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 04:05:50 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 10 Jan 2015 03:05:50 +0000 Subject: [issue23213] subprocess communicate() hangs when stderr isn't closed In-Reply-To: <1420848131.85.0.905282247977.issue23213@psf.upfronthosting.co.za> Message-ID: <1420859150.55.0.202133243814.issue23213@psf.upfronthosting.co.za> Martin Panter added the comment: I suspect this is not a bug but a misunderstanding of how communiate(), pipes, daemon processes, etc, work. If communicate() didn?t wait for stderr to be closed, then how would it know it had read all the data that was written into the pipe? I don?t have that version of ?systemd?, but I guess your daemon leaves its output pipes open and continues to run in the background, so communicate() is waiting in case the daemon writes anything to the pipes. This would demonstrate the same situation using a Python subprocess: import subprocess import sys script = """import os, time if not os.fork(): # Child process time.sleep(30) print("Finally!") """ args = (sys.executable, "-c", script) proc = subprocess.Popen(args, stdout=subprocess.PIPE, stderr=subprocess.PIPE) proc.communicate() # Hangs for 30 s and then returns (b'Finally!\n', b'') If you want communicate() to return as soon as a daemon forks into the background, don?t read from the daemon?s output pipes. If you want to read data that the foreground process writes and ignore any data that the background process might write to the same pipes, that?s asking for race conditions. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 04:08:17 2015 From: report at bugs.python.org (Tim Peters) Date: Sat, 10 Jan 2015 03:08:17 +0000 Subject: [issue23201] Decimal(0)**0 is an error, 0**0 is 1, but Decimal(0) == 0 In-Reply-To: <1420773186.22.0.229704657455.issue23201@psf.upfronthosting.co.za> Message-ID: <1420859297.53.0.428154241776.issue23201@psf.upfronthosting.co.za> Tim Peters added the comment: This is easy: Cowlishaw is wrong on this one, but nothing can be done about it ;-) Confusion arises because most people think of 0**0 as a value (where it certainly must be 1) while others seem to view it as some kind of shorthand for expressing a limit (as the base and/or exponent _approach_ 0, in which case there is no correct answer - it's an "indeterminate form"). It's in the "spirit of 754" to take inputs at face value, viewing them as infinitely precise. So viewing 0**0 as anything other than 1 in this context is perverse. Centuries of history distilled to a few paragraphs here: http://en.wikipedia.org/wiki/Exponentiation#Zero_to_the_power_of_zero ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 04:32:01 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 10 Jan 2015 03:32:01 +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: <1420860721.56.0.742961345632.issue15955@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch for the higher-level LZMAFile implementation to use Nikolaus?s ?max_length? parameter. It depends on Nikolaus?s patch also being applied. I split out a _RawReader class that does the actual decompress() calls, and then wrapped that in a BufferedReader. This avoids needing any special code to implement buffering, readline(), etc. The only significant changes in the API that I can see are: * LZMAFile now inherits the useless specification of BufferedReader.peek(), losing the guarantee of returning at least a single byte. I questioned the BufferedReader specification at . * read() now accepts size=None, because BufferedReader does. I had to change a test case for this. ---------- Added file: http://bugs.python.org/file37658/LZMAFile.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 04:33:03 2015 From: report at bugs.python.org (Aleksi Torhamo) Date: Sat, 10 Jan 2015 03:33:03 +0000 Subject: [issue23215] MemoryError with custom error handlers and multibyte codecs Message-ID: <1420860783.67.0.50434618074.issue23215@psf.upfronthosting.co.za> New submission from Aleksi Torhamo: Using a multibyte codec and a custom error handler that ignores errors to encode a string that contains characters not representable in said encoding causes exponential growth of the output buffer, raising MemoryError. The problem is in multibytecodec_encerror() and REQUIRE_ENCODEBUFFER() in Modules/cjkcodecs/multibytecodec.c. multibytecodec_encerror() always uses REQUIRE_ENCODEBUFFER() to ensure there's enough space for the replacement string, and if more space is needed, REQUIRE_ENCODEBUFFER() calls expand_encodebuffer(), which in turn always grows the buffer by at least 50%. However, if size < 1, REQUIRE_ENCODEBUFFER() doesn't check if more space is actually needed. (It's used with negative values in other places) I have no idea why the condition was originally size < 1 instead of size < 0, but changing it seems to fix this. The replacement string case is also the only use of the macro that may use 0 as the argument. In the patch, I've instead wrapped the REQUIRE_ENCODEBUFFER() (and memcpy) in a if(size > 0), since that's what the corresponding part in multibytecodec_decerror() did in the past: https://hg.python.org/cpython/file/1c3f8d044589/Modules/cjkcodecs/multibytecodec.c#l438 Not sure which one makes more sense. As for the tests, I'm not sure if 1) all of the affected encodings should be tested or only one (or even all encodings, affected or not?) and 2) whether it should be a new test or if I should just add it to test_longstrings in Lib/test/test_codeccallbacks.py. (Structurally it's a perfect fit, but it really isn't a "long string" test as it can happen with <50 characters) At the moment, the patch is testing affected encodings in a separate test. Is the test philosophy "as thorough as possible" or "as fast as possible"? ---------- components: Interpreter Core files: python_codec_crasher.py messages: 233800 nosy: alexer priority: normal severity: normal status: open title: MemoryError with custom error handlers and multibyte codecs type: resource usage versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37659/python_codec_crasher.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 04:39:12 2015 From: report at bugs.python.org (Aleksi Torhamo) Date: Sat, 10 Jan 2015 03:39:12 +0000 Subject: [issue23215] MemoryError with custom error handlers and multibyte codecs In-Reply-To: <1420860783.67.0.50434618074.issue23215@psf.upfronthosting.co.za> Message-ID: <1420861152.03.0.172808266857.issue23215@psf.upfronthosting.co.za> Changes by Aleksi Torhamo : ---------- keywords: +patch Added file: http://bugs.python.org/file37660/python_codec_crash_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 05:26:53 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 10 Jan 2015 04:26:53 +0000 Subject: [issue5811] io.BufferedReader.peek(): Documentation differs from Implementation In-Reply-To: <1240380953.7.0.732520909261.issue5811@psf.upfronthosting.co.za> Message-ID: <1420864013.61.0.577338103181.issue5811@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a simple documentation patch to guarantee that at least one byte is normally returned. This would make the method much more useful, and compatible with the BZ2File and LZMAFile interfaces, allowing them to use BufferedReader, as I propose to do in Issue 15955. Even if nobody is interested in Torsten?s patch to limit the return length, I suggest my patch be considered :) ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python Added file: http://bugs.python.org/file37661/peek-one-byte.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 07:23:42 2015 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 10 Jan 2015 06:23:42 +0000 Subject: [issue23144] html.parser.HTMLParser: setting 'convert_charrefs = True' leads to dropped text In-Reply-To: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za> Message-ID: <1420871022.43.0.919365964965.issue23144@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: docs at python -> ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 08:15:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 10 Jan 2015 07:15:21 +0000 Subject: [issue23215] MemoryError with custom error handlers and multibyte codecs In-Reply-To: <1420860783.67.0.50434618074.issue23215@psf.upfronthosting.co.za> Message-ID: <1420874121.34.0.280930156057.issue23215@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +haypo, lemburg, loewis, serhiy.storchaka stage: -> patch review versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 08:44:25 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 10 Jan 2015 07:44:25 +0000 Subject: [issue20699] Behavior of ZipFile with file-like object and BufferedWriter. In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za> Message-ID: <1420875865.43.0.821968770474.issue20699@psf.upfronthosting.co.za> Martin Panter added the comment: I think the simplest thing to do here would be to update the documentation to match the usage. This patch does so, saying that all write() methods, as well as the BytesIO() constructor, have to accept bytes-like objects. It also expands some tests to verify this, and fixes a resulting bug in _pyio. ---------- assignee: -> docs at python components: +Documentation keywords: +patch nosy: +docs at python Added file: http://bugs.python.org/file37662/bytes-like-param.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 09:00:32 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 10 Jan 2015 08:00:32 +0000 Subject: [issue19776] Provide expanduser() on Path objects In-Reply-To: <1385409778.55.0.842571848249.issue19776@psf.upfronthosting.co.za> Message-ID: <20150110080029.11571.2737@psf.io> Roundup Robot added the comment: New changeset 63dac5212552 by Victor Stinner in branch 'default': Issue #19776: Fix test_pathlib.test_expanduser() https://hg.python.org/cpython/rev/63dac5212552 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 09:47:48 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 10 Jan 2015 08:47:48 +0000 Subject: [issue13742] Add a key parameter (like sorted) to heapq.merge In-Reply-To: <1326105342.42.0.0197399269422.issue13742@psf.upfronthosting.co.za> Message-ID: <1420879667.99.0.615418450594.issue13742@psf.upfronthosting.co.za> Terry J. Reedy added the comment: You can set up mecurial on your machine, make a read-only clone of the cpython repository, and compile it just as do other people, whether core-developers or otherwise. See docs.python.org/devguide for details. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 09:53:47 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 10 Jan 2015 08:53:47 +0000 Subject: [issue19776] Provide expanduser() on Path objects In-Reply-To: <1385409778.55.0.842571848249.issue19776@psf.upfronthosting.co.za> Message-ID: <1420880027.87.0.138458678155.issue19776@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, test_pathlib now pass on the buildbot "PPC64 AIX 3.x". I close the issue. Nice enhancement of the Path object. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 09:57:31 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 10 Jan 2015 08:57:31 +0000 Subject: [issue19051] Unify buffered readers In-Reply-To: <1379600529.46.0.258828532264.issue19051@psf.upfronthosting.co.za> Message-ID: <1420880251.13.0.0622477274546.issue19051@psf.upfronthosting.co.za> Martin Panter added the comment: Parts of the patch here actually do the same thing as my LZMAFile patch for Issue 15955. I wish I had looked at the patch earlier! The difference is I used a proposed max_length parameter for the decompressor rather than unlimited decompression, and I used the existing BufferedReader class rather than implementing a new custom one. The changes for the ?gzip? module could probably be merged with my GzipFile patch at Issue 15955 and made to use BufferedReader. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 10:15:06 2015 From: report at bugs.python.org (Al Sweigart) Date: Sat, 10 Jan 2015 09:15:06 +0000 Subject: [issue23216] IDLE grep/find/replace source code needs docstrings Message-ID: <1420881306.22.0.52075806524.issue23216@psf.upfronthosting.co.za> New submission from Al Sweigart: The following IDLE files need docstrings for their methods: GrepDialog.py SearchEngine.py SearchDialogBase.py SearchDialog.py ReplaceDialog.py ---------- components: IDLE files: idle_docstrings.diff keywords: patch messages: 233807 nosy: Al.Sweigart priority: normal severity: normal status: open title: IDLE grep/find/replace source code needs docstrings type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file37663/idle_docstrings.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 10:16:44 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 10 Jan 2015 09:16:44 +0000 Subject: [issue23201] Decimal(0)**0 is an error, 0**0 is 1, but Decimal(0) == 0 In-Reply-To: <1420773186.22.0.229704657455.issue23201@psf.upfronthosting.co.za> Message-ID: <1420881404.54.0.23949463232.issue23201@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Thank you Tim. A possibility would be to add "(disallowed by the Decimal standard)" to the exception message. ---------- nosy: +terry.reedy versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 10:27:56 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 10 Jan 2015 09:27:56 +0000 Subject: [issue23201] Decimal(0)**0 is an error, 0**0 is 1, but Decimal(0) == 0 In-Reply-To: <1420773186.22.0.229704657455.issue23201@psf.upfronthosting.co.za> Message-ID: <1420882076.11.0.515349467469.issue23201@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > A possibility would be to add "(disallowed by the > Decimal standard)" to the exception message. That is what InvalidOperation means ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 10:29:49 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 10 Jan 2015 09:29:49 +0000 Subject: [issue23205] Unit test needed for IDLE's GrepDialog.py's findfiles() In-Reply-To: <1420791360.73.0.110066531981.issue23205@psf.upfronthosting.co.za> Message-ID: <1420882189.35.0.173240027393.issue23205@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I have been putting off re-writing findfiles because it partly duplicates os.listdir, which should perhaps be used instead, except that a new, improved, os.scandir is in the works: PEP 471 and #22524. I believe filefiles currently searches depth first, whereas I would generally prefer breadth first. For instance, I would like all hits in /lib together and then hits in /lib/idlelib, /lib/test, /lib/tinter, etc. What do you think? ---------- nosy: +terry.reedy stage: -> patch review type: -> enhancement versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 10:33:16 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 10 Jan 2015 09:33:16 +0000 Subject: [issue23217] help() function incorrectly captures comment preceding a nested function Message-ID: <1420882396.37.0.573730184021.issue23217@psf.upfronthosting.co.za> New submission from Raymond Hettinger: The help() function mysteriously captures a comment on the line preceding an inner function definition in a nested scope. Given this code: ---------------- def outer(func): #comment def inner(): return return inner @outer def f(): return Calling help(f) produces: ------------------------- Help on function inner in module __main__: inner() #comment ---------- components: Library (Lib) messages: 233811 nosy: rhettinger priority: normal severity: normal status: open title: help() function incorrectly captures comment preceding a nested function type: behavior versions: Python 3.2, Python 3.3, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 10:34:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 10 Jan 2015 09:34:53 +0000 Subject: [issue20699] Behavior of ZipFile with file-like object and BufferedWriter. In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za> Message-ID: <1420882493.21.0.897650933188.issue20699@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka stage: -> patch review versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 11:00:51 2015 From: report at bugs.python.org (Al Sweigart) Date: Sat, 10 Jan 2015 10:00:51 +0000 Subject: [issue23218] Modernize the IDLE Find/Replace/Find in Files dialogs Message-ID: <1420884051.8.0.416866319984.issue23218@psf.upfronthosting.co.za> New submission from Al Sweigart: Various changes to modernize the user interface of the Find, Replace, and Find in Files dialogs: - Got rid of the "close" button, since it is redundant. - Moved the buttons below the text fields, to make better use of screen real estate. - Shorten the titles by getting rid of the "Dialog" part. - Renamed "Search" title to "Find" to match the menu item. - Renamed "Regular expression" label to the shorter "Regex" - Added slightly more padding. - Removed the "Replace+Find" and made "Replace" have this functionality. (all modern editors use Replace to mean "Replace and Find") The attached png shows the before/after differences in the design of these dialogs. ---------- components: IDLE files: idle_grep_compare.png messages: 233812 nosy: Al.Sweigart priority: normal severity: normal status: open title: Modernize the IDLE Find/Replace/Find in Files dialogs type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file37664/idle_grep_compare.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 11:02:13 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 10 Jan 2015 10:02:13 +0000 Subject: [issue23219] asyncio: cancelling wait_for(task, timeout) must also cancel the task Message-ID: <1420884133.75.0.926989519431.issue23219@psf.upfronthosting.co.za> New submission from STINNER Victor: Cancelling wait_for(task, timeout) must also cancel the waited task. Attached patch fixes this issue. Original issue: https://code.google.com/p/tulip/issues/detail?id=211 ---------- components: asyncio files: cancel_wait_for.patch keywords: patch messages: 233813 nosy: gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio: cancelling wait_for(task, timeout) must also cancel the task versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37665/cancel_wait_for.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 11:02:37 2015 From: report at bugs.python.org (Al Sweigart) Date: Sat, 10 Jan 2015 10:02:37 +0000 Subject: [issue23218] Modernize the IDLE Find/Replace/Find in Files dialogs In-Reply-To: <1420884051.8.0.416866319984.issue23218@psf.upfronthosting.co.za> Message-ID: <1420884157.77.0.339996579706.issue23218@psf.upfronthosting.co.za> Changes by Al Sweigart : ---------- keywords: +patch Added file: http://bugs.python.org/file37666/idle_find_ui_redesign.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 11:03:49 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 10 Jan 2015 10:03:49 +0000 Subject: [issue23219] asyncio: cancelling wait_for(task, timeout) must also cancel the task In-Reply-To: <1420884133.75.0.926989519431.issue23219@psf.upfronthosting.co.za> Message-ID: <1420884229.11.0.640061104394.issue23219@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file37665/cancel_wait_for.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 11:08:38 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 10 Jan 2015 10:08:38 +0000 Subject: [issue23219] asyncio: cancelling wait_for(task, timeout) must also cancel the task In-Reply-To: <1420884133.75.0.926989519431.issue23219@psf.upfronthosting.co.za> Message-ID: <1420884518.69.0.871662022797.issue23219@psf.upfronthosting.co.za> STINNER Victor added the comment: Oops, I forgot to call remove_done_callback(). New patch attached. My patch is based on Gustavo Carneiro's patch from Tulip issue #211. ---------- Added file: http://bugs.python.org/file37667/cancel_wait_for-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 11:25:56 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 10 Jan 2015 10:25:56 +0000 Subject: [issue21408] delegation of `!=` to the right-hand side argument is not always done In-Reply-To: <1398954687.6.0.574462939929.issue21408@psf.upfronthosting.co.za> Message-ID: <1420885556.52.0.329024631552.issue21408@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 12:06:23 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 10 Jan 2015 11:06:23 +0000 Subject: [issue23203] Aliasing import of sub-{module, package} from the package raises AttributeError on import. In-Reply-To: <1420785882.78.0.914141516682.issue23203@psf.upfronthosting.co.za> Message-ID: <1420887983.7.0.14192013661.issue23203@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'm suggesting we change this part of the bytecode emitted for "import x.y.z as bar": 6 IMPORT_NAME 0 (x.y.z) 9 LOAD_ATTR 1 (y) 12 LOAD_ATTR 2 (z) 15 STORE_NAME 3 (bar) to instead emit: 6 IMPORT_NAME 0 (x.y) 9 IMPORT_FROM 1 (z) 12 STORE_NAME 2 (bar) 15 POP_TOP The degenerate case of "import x as y" would be unchanged, only cases which currently emit LOAD_ATTR instructions would be modified. I haven't looked at the practical details yet, but the key would be to use IMPORT_FROM to do the name resolution, rather than LOAD_ATTR, thus enabling the fallback to sys.modules for the eager lookup. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 12:10:50 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 10 Jan 2015 11:10:50 +0000 Subject: [issue23163] pdb docs need to contain a statement on threads/multithreaded debugging In-Reply-To: <1420366883.83.0.11703664982.issue23163@psf.upfronthosting.co.za> Message-ID: <1420888250.81.0.528940461107.issue23163@psf.upfronthosting.co.za> Xavier de Gaye added the comment: pdb does not ignore breakpoints which are set and hit in a non-main thread. For example with the attached script: $ python pdb_thread.py > pdb_thread.py(5)foo() -> lineno = 5 (Pdb) break 6 Breakpoint 1 at pdb_thread.py:6 (Pdb) continue > pdb_thread.py(6)foo() -> lineno = 6 (Pdb) threading.current_thread().name 'fooThread' (Pdb) ---------- nosy: +xdegaye Added file: http://bugs.python.org/file37668/pdb_thread.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 12:13:07 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 10 Jan 2015 11:13:07 +0000 Subject: [issue23188] Exception chaining should trigger for non-normalised exceptions In-Reply-To: <1420687041.12.0.12728944273.issue23188@psf.upfronthosting.co.za> Message-ID: <1420888387.77.0.865807210042.issue23188@psf.upfronthosting.co.za> Nick Coghlan added the comment: Ah, confusion between "exception has been raised" and "we're in an active exception handler" is almost certainly what is happening. In both issue 22906 and my previous codec exception wrapping work, we're still in the C code that raised the exception, *before* we make it back to the eval loop and any Python level exception handling. So I think that's the distinction we need to ensure is documented, and potentially a new public helper function provided - if you're in a Python level exception handler, then exception context chaining will be handled automatically for you in PyErr_SetObject, but if you're still in C code and haven't made it back to the eval loop after raising an exception, then you're going to have to do any exception chaining explicitly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 12:14:36 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 10 Jan 2015 11:14:36 +0000 Subject: [issue23188] Provide a C helper function to chain raised (but not yet caught) exceptions In-Reply-To: <1420687041.12.0.12728944273.issue23188@psf.upfronthosting.co.za> Message-ID: <1420888476.09.0.370773444657.issue23188@psf.upfronthosting.co.za> Nick Coghlan added the comment: Updated the issue title and type again based on Antoine's explanation. ---------- title: Exception chaining should trigger for non-normalised exceptions -> Provide a C helper function to chain raised (but not yet caught) exceptions type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 12:19:53 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 10 Jan 2015 11:19:53 +0000 Subject: [issue23163] pdb docs need to contain a statement on threads/multithreaded debugging In-Reply-To: <1420366883.83.0.11703664982.issue23163@psf.upfronthosting.co.za> Message-ID: <1420888793.89.0.971868714138.issue23163@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The pdb documentation could make an explicit reference to the documentation of sys.settrace() where it is explained that the function is thread specific. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 13:28:46 2015 From: report at bugs.python.org (Stefan Krah) Date: Sat, 10 Jan 2015 12:28:46 +0000 Subject: [issue23201] Decimal(0)**0 is an error, 0**0 is 1, but Decimal(0) == 0 In-Reply-To: <1420773186.22.0.229704657455.issue23201@psf.upfronthosting.co.za> Message-ID: <1420892926.24.0.123721660101.issue23201@psf.upfronthosting.co.za> Stefan Krah added the comment: For the differences between the standard and IEEE 754-2008 we could link to: http://speleotrove.com/decimal/dascope.html In the long run, perhaps we should move to IEEE, because we're almost there (but that's a separate issue). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 16:26:11 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 10 Jan 2015 15:26:11 +0000 Subject: [issue23217] help() function incorrectly captures comment preceding a nested function In-Reply-To: <1420882396.37.0.573730184021.issue23217@psf.upfronthosting.co.za> Message-ID: <1420903571.12.0.887161921084.issue23217@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 18:41:47 2015 From: report at bugs.python.org (Joakim Karlsson) Date: Sat, 10 Jan 2015 17:41:47 +0000 Subject: [issue22411] Embedding Python on Windows In-Reply-To: <1410717424.69.0.586099783725.issue22411@psf.upfronthosting.co.za> Message-ID: <1420911707.1.0.856849034131.issue22411@psf.upfronthosting.co.za> Joakim Karlsson added the comment: Sounds reasonable. It would also require that all third party packages supply a "*_d.pyd" version of any extensions. Does setuptools and pip have any support for automatically creating debug versions of extensions with the correct naming scheme when creating wheels or compiling during installation? A (really shallow) search didn't find any info on this. Anyway, thanks for stepping up and taking charge of the windows installers! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 19:29:52 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 10 Jan 2015 18:29:52 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <1417530925.56.0.55888060474.issue22980@psf.upfronthosting.co.za> Message-ID: <1420914592.3.0.0643997714008.issue22980@psf.upfronthosting.co.za> Steve Dower added the comment: > Could you explain what replacing the _d suffix with a "d" ABI flag > would break ? It breaks consistency with python_d.exe and python35_d.dll, mainly, and those are not going to change (specifically, python.exe and python35.dll are not going to change, and so there's no point changing the debug versions any more than with _d). It would also break consistency with untagged PYDs, which are still supported but still need to distinguish between debug and release builds. Currently the accepted suffixes are "_d.cp35-{plat}.pyd" and "_d.pyd". While we could start requiring at least "cp3d" as the API tag, that would break a lot of development environments for no gain. So basically, I see compelling reasons for allowing the platform in the name, good enough reasons for the version, but not good enough reasons for changing the existing debug tag (and no reason for the m flag at all). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 21:45:27 2015 From: report at bugs.python.org (Brett Cannon) Date: Sat, 10 Jan 2015 20:45:27 +0000 Subject: [issue23203] Aliasing import of sub-{module, package} from the package raises AttributeError on import. In-Reply-To: <1420785882.78.0.914141516682.issue23203@psf.upfronthosting.co.za> Message-ID: <1420922727.59.0.33801577042.issue23203@psf.upfronthosting.co.za> Brett Cannon added the comment: That seems reasonable. I guess first step is a patch and then seeing if it passes the test suite. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 21:48:14 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 10 Jan 2015 20:48:14 +0000 Subject: [issue22411] Embedding Python on Windows In-Reply-To: <1410717424.69.0.586099783725.issue22411@psf.upfronthosting.co.za> Message-ID: <1420922894.51.0.700894838637.issue22411@psf.upfronthosting.co.za> Steve Dower added the comment: distutils will (now, after some changes in 3.5) build debug versions of packages on installation when running with python_d.exe. I haven't tested exactly how pip behaves here, but it should work fine if you run with a command line like this: python_d.exe -m pip install --no-use-wheel --no-clean --build I don't think pip will create a pip_d.exe, and it's likely that if a wheel is available it will grab that and you really need to build it locally. Using --no-clean and --build to specify where to build it will ensure that the symbols for the package aren't deleted, which may help with debugging, but if you don't care about that you can omit those two parameters. I've also been experimenting with adding an option to download and install debug binaries as part of the installer, and it looks like it'll work fine. So that at least will make things simpler for developers. Another change for 3.5 that will also help is #22980 (though that one isn't quite settled yet and may change again). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 22:03:30 2015 From: report at bugs.python.org (INADA Naoki) Date: Sat, 10 Jan 2015 21:03:30 +0000 Subject: [issue23206] json.dumps(ensure_ascii=False) is ~10x slower than json.dumps() In-Reply-To: <1420809445.24.0.133647496806.issue23206@psf.upfronthosting.co.za> Message-ID: <1420923810.32.0.532467802925.issue23206@psf.upfronthosting.co.za> INADA Naoki added the comment: I've updated patch to use PyUnicode_MAX_CHAR_VALUE(). ---------- Added file: http://bugs.python.org/file37669/json-fast-unicode-encode.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 10 22:07:31 2015 From: report at bugs.python.org (INADA Naoki) Date: Sat, 10 Jan 2015 21:07:31 +0000 Subject: [issue23206] json.dumps(ensure_ascii=False) is ~10x slower than json.dumps() In-Reply-To: <1420809445.24.0.133647496806.issue23206@psf.upfronthosting.co.za> Message-ID: <1420924051.78.0.752576272073.issue23206@psf.upfronthosting.co.za> INADA Naoki added the comment: test_encode_basestring_ascii.py has duplicated test cases. ---------- Added file: http://bugs.python.org/file37670/json-fast-unicode-encode.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 01:05:27 2015 From: report at bugs.python.org (Ethan Furman) Date: Sun, 11 Jan 2015 00:05:27 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> Message-ID: <1420934727.63.0.247677225201.issue23185@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +eric.smith, lemburg, rhettinger, stutzbach _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 01:29:01 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 11 Jan 2015 00:29:01 +0000 Subject: [issue21408] delegation of `!=` to the right-hand side argument is not always done In-Reply-To: <1398954687.6.0.574462939929.issue21408@psf.upfronthosting.co.za> Message-ID: <1420936141.12.0.339051333798.issue21408@psf.upfronthosting.co.za> Martin Panter added the comment: There is a bit of analysis of the object.__ne__() implementation in Issue 4395. If my understanding is correct, I think it is a bug that object.__ne__(self, other) evaluates ?not self == other?. It should evaluate ?not self.__eq__(other)? instead, so that NotImplemented can be caught, allowing the reflected other.__ne__(self) method to be tried. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 01:47:07 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 11 Jan 2015 00:47:07 +0000 Subject: [issue23165] Heap overwrite in Python/fileutils.c:_Py_char2wchar() on 32 bit systems due to malloc parameter overflow In-Reply-To: <1420390111.83.0.411085812385.issue23165@psf.upfronthosting.co.za> Message-ID: <1420937227.24.0.922356488982.issue23165@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 01:48:36 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 11 Jan 2015 00:48:36 +0000 Subject: [issue23166] urllib2 ignores opener configuration under certain circumstances In-Reply-To: <1420406037.0.0.986455895168.issue23166@psf.upfronthosting.co.za> Message-ID: <1420937316.53.0.746231881208.issue23166@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 01:54:47 2015 From: report at bugs.python.org (Al Sweigart) Date: Sun, 11 Jan 2015 00:54:47 +0000 Subject: [issue23220] IDLE does not display \b backspace correctly. Message-ID: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za> New submission from Al Sweigart: IDLE cannot display the \b backspace character correctly. From IDLE's interactive shell: >>> print('hello\b\b\b\b\bHELLO') hello?????HELLO Whereas from cmd: >>> print('hello\b\b\b\b\bHELLO') HELLO ---------- messages: 233828 nosy: Al.Sweigart priority: normal severity: normal status: open title: IDLE does not display \b backspace correctly. versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 02:39:20 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 11 Jan 2015 01:39:20 +0000 Subject: [issue23221] "a(n) the", "the a(n)" typos Message-ID: <1420940360.26.0.834732182943.issue23221@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis: In default branch: $ grep -Er '(^|[[:space:]])an? the($|[[:space:]])' * Doc/c-api/structures.rst::c:type:`PyObject\*`, it is common that the method implementation uses a the Include/dynamic_annotations.h: is about to be reused, or when a the locking discipline for a variable Include/unicodeobject.h:/* Initializes the canonical string representation from a the deprecated Lib/lib2to3/fixes/fix_exitfunc.py: # First, find a the sys import. We'll just hope it's global scope. Lib/socket.py: Create a socket object from a the bytes object returned by Lib/http/cookiejar.py: """Return string representation of Cookie in an the LWP cookie file format. Modules/_ctypes/_ctypes.c: A Pointer instance must keep a the value it points to alive. So, a $ grep -Er '(^|[[:space:]])the an?($|[[:space:]])' * Doc/library/unittest.mock.rst:being looked up on the a module and so we have to patch ``a.SomeClass`` instead:: Doc/c-api/init.rst: Return the a pointer to the first :c:type:`PyThreadState` object in the list of Doc/c-api/exceptions.rst: case of a class exception, or it may the a subclass of the expected exception.) Doc/distutils/apiref.rst: *base_dir* is just the a name of a directory which doesn't necessarily exist Lib/test/test_argparse.py: """Tests the an optional action that is required""" Lib/ssl.py: """Return the a list of ciphers shared by the client during the Lib/distutils/dir_util.py: 'base_dir' is just the a name of a directory which doesn't necessarily 'the a module' in Doc/library/unittest.mock.rst probably should be 'the ``a`` module'. 'may the a' in Doc/c-api/exceptions.rst should be 'may be a'. ---------- keywords: easy messages: 233829 nosy: Arfrever priority: normal severity: normal status: open title: "a(n) the", "the a(n)" typos versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 02:56:01 2015 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Sun, 11 Jan 2015 01:56:01 +0000 Subject: [issue10740] sqlite3 module breaks transactions and potentially corrupts data In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za> Message-ID: <1420941361.74.0.516959731994.issue10740@psf.upfronthosting.co.za> Changes by Gerhard H?ring : ---------- assignee: -> ghaering _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 02:58:33 2015 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Sun, 11 Jan 2015 01:58:33 +0000 Subject: [issue13299] namedtuple row factory for sqlite3 In-Reply-To: <1320021145.59.0.53370875256.issue13299@psf.upfronthosting.co.za> Message-ID: <1420941513.08.0.0669432738486.issue13299@psf.upfronthosting.co.za> Changes by Gerhard H?ring : ---------- assignee: -> ghaering _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 02:59:19 2015 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Sun, 11 Jan 2015 01:59:19 +0000 Subject: [issue20587] sqlite3 converter not being called In-Reply-To: <1392069177.84.0.794324739968.issue20587@psf.upfronthosting.co.za> Message-ID: <1420941559.48.0.228578751724.issue20587@psf.upfronthosting.co.za> Changes by Gerhard H?ring : ---------- assignee: -> ghaering nosy: +ghaering _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 02:59:45 2015 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Sun, 11 Jan 2015 01:59:45 +0000 Subject: [issue20562] sqlite3 returns result set with doubled first entry In-Reply-To: <1391863388.33.0.362303830227.issue20562@psf.upfronthosting.co.za> Message-ID: <1420941585.54.0.612808759065.issue20562@psf.upfronthosting.co.za> Changes by Gerhard H?ring : ---------- assignee: -> ghaering nosy: +ghaering _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 03:00:14 2015 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Sun, 11 Jan 2015 02:00:14 +0000 Subject: [issue21836] Fix sqlite3 in unicodeless build In-Reply-To: <1403593660.62.0.0164715886324.issue21836@psf.upfronthosting.co.za> Message-ID: <1420941614.07.0.071220725967.issue21836@psf.upfronthosting.co.za> Changes by Gerhard H?ring : ---------- assignee: -> ghaering _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 03:00:30 2015 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Sun, 11 Jan 2015 02:00:30 +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: <1420941630.0.0.400353237389.issue16958@psf.upfronthosting.co.za> Changes by Gerhard H?ring : ---------- assignee: -> ghaering _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 03:00:40 2015 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Sun, 11 Jan 2015 02:00:40 +0000 Subject: [issue21465] sqlite3 Row can return duplicate keys when using adapters In-Reply-To: <1399672256.68.0.166250570949.issue21465@psf.upfronthosting.co.za> Message-ID: <1420941640.66.0.306742108142.issue21465@psf.upfronthosting.co.za> Changes by Gerhard H?ring : ---------- assignee: -> ghaering _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 03:01:02 2015 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Sun, 11 Jan 2015 02:01:02 +0000 Subject: [issue13583] sqlite3.Row doesn't support slice indexes In-Reply-To: <1323639948.36.0.717803065724.issue13583@psf.upfronthosting.co.za> Message-ID: <1420941662.76.0.184872164065.issue13583@psf.upfronthosting.co.za> Changes by Gerhard H?ring : ---------- assignee: -> ghaering _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 03:01:17 2015 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Sun, 11 Jan 2015 02:01:17 +0000 Subject: [issue20463] sqlite dumpiter dumps invalid script when virtual tables are used In-Reply-To: <1391198256.46.0.541752876278.issue20463@psf.upfronthosting.co.za> Message-ID: <1420941677.45.0.348440732428.issue20463@psf.upfronthosting.co.za> Changes by Gerhard H?ring : ---------- assignee: -> ghaering _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 03:01:27 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 11 Jan 2015 02:01:27 +0000 Subject: [issue21408] delegation of `!=` to the right-hand side argument is not always done In-Reply-To: <1398954687.6.0.574462939929.issue21408@psf.upfronthosting.co.za> Message-ID: <1420941687.51.0.704500821944.issue21408@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 03:03:26 2015 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Sun, 11 Jan 2015 02:03:26 +0000 Subject: [issue20274] sqlite module has bad argument parsing code, including undefined behavior in C In-Reply-To: <1389817483.8.0.407525727046.issue20274@psf.upfronthosting.co.za> Message-ID: <1420941806.71.0.676323340417.issue20274@psf.upfronthosting.co.za> Changes by Gerhard H?ring : ---------- assignee: -> ghaering nosy: +ghaering _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 03:03:56 2015 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Sun, 11 Jan 2015 02:03:56 +0000 Subject: [issue9924] sqlite3 SELECT does not BEGIN a transaction, but should according to spec In-Reply-To: <1285214166.49.0.269440190097.issue9924@psf.upfronthosting.co.za> Message-ID: <1420941836.84.0.458260276913.issue9924@psf.upfronthosting.co.za> Changes by Gerhard H?ring : ---------- assignee: -> ghaering _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 03:04:30 2015 From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=) Date: Sun, 11 Jan 2015 02:04:30 +0000 Subject: [issue11691] sqlite3 Cursor.description doesn't set type_code In-Reply-To: <1301199375.2.0.455501522423.issue11691@psf.upfronthosting.co.za> Message-ID: <1420941870.75.0.262374281048.issue11691@psf.upfronthosting.co.za> Changes by Gerhard H?ring : ---------- assignee: docs at python -> ghaering _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 03:05:06 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 11 Jan 2015 02:05:06 +0000 Subject: [issue23203] Aliasing import of sub-{module, package} from the package raises AttributeError on import. In-Reply-To: <1420785882.78.0.914141516682.issue23203@psf.upfronthosting.co.za> Message-ID: <1420941906.23.0.865664041712.issue23203@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 03:05:52 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 11 Jan 2015 02:05:52 +0000 Subject: [issue23206] json.dumps(ensure_ascii=False) is ~10x slower than json.dumps() In-Reply-To: <1420809445.24.0.133647496806.issue23206@psf.upfronthosting.co.za> Message-ID: <1420941952.5.0.594395232135.issue23206@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 03:31:10 2015 From: report at bugs.python.org (Carol Willing) Date: Sun, 11 Jan 2015 02:31:10 +0000 Subject: [issue23220] IDLE does not display \b backspace correctly. In-Reply-To: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za> Message-ID: <1420943470.53.0.620654540749.issue23220@psf.upfronthosting.co.za> Carol Willing added the comment: FWIW: On Mac OS X 10.9.5 using Python 3.4.2, IDLE's interactive shell (started from the IDLE.app icon): >>>print('hello\b\b\b\b\bHELLO') helloHELLO >From the command line using python3 interactive shell: >>>print('hello\b\b\b\b\bHELLO') HELLO Both return a for type('hello\b\b\b\b\bHELLO') Interestingly, both behave the same when executing: >>>'hello\b\b\b\b\bHELLO' 'hello\x08\x08\x08\x08\x08HELLO' I'm not sure that IDLE is used much on OS X since the Terminal is easily available. Since K12 education may use it, it would be nice to have consistency across the OSes. ---------- nosy: +willingc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 03:50:55 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 11 Jan 2015 02:50:55 +0000 Subject: [issue23220] IDLE does not display \b backspace correctly. In-Reply-To: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za> Message-ID: <1420944655.7.0.772104409702.issue23220@psf.upfronthosting.co.za> Martin Panter added the comment: As far as I understand, Idle doesn?t interpret any terminal control codes apart from a plain \n for a new line. I know it doesn?t do a carriage return for \r either. ---------- components: +IDLE nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 05:06:50 2015 From: report at bugs.python.org (Al Sweigart) Date: Sun, 11 Jan 2015 04:06:50 +0000 Subject: [issue23216] IDLE grep/find/replace source code needs docstrings In-Reply-To: <1420881306.22.0.52075806524.issue23216@psf.upfronthosting.co.za> Message-ID: <1420949210.62.0.769146398759.issue23216@psf.upfronthosting.co.za> Changes by Al Sweigart : ---------- versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 05:06:58 2015 From: report at bugs.python.org (Al Sweigart) Date: Sun, 11 Jan 2015 04:06:58 +0000 Subject: [issue23218] Modernize the IDLE Find/Replace/Find in Files dialogs In-Reply-To: <1420884051.8.0.416866319984.issue23218@psf.upfronthosting.co.za> Message-ID: <1420949218.37.0.874546579177.issue23218@psf.upfronthosting.co.za> Changes by Al Sweigart : ---------- versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 05:07:15 2015 From: report at bugs.python.org (Al Sweigart) Date: Sun, 11 Jan 2015 04:07:15 +0000 Subject: [issue23220] IDLE does not display \b backspace correctly. In-Reply-To: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za> Message-ID: <1420949235.18.0.9090086627.issue23220@psf.upfronthosting.co.za> Changes by Al Sweigart : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 05:09:37 2015 From: report at bugs.python.org (Al Sweigart) Date: Sun, 11 Jan 2015 04:09:37 +0000 Subject: [issue23220] IDLE does not display \b backspace correctly. In-Reply-To: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za> Message-ID: <1420949377.15.0.636272179288.issue23220@psf.upfronthosting.co.za> Al Sweigart added the comment: For clarification, this happens on Windows 7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 05:21:58 2015 From: report at bugs.python.org (Al Sweigart) Date: Sun, 11 Jan 2015 04:21:58 +0000 Subject: [issue23180] Rename IDLE's "Windows" menu item to "Window" In-Reply-To: <1420614987.43.0.350300091598.issue23180@psf.upfronthosting.co.za> Message-ID: <1420950118.34.0.198594915282.issue23180@psf.upfronthosting.co.za> Al Sweigart added the comment: Will do, re marking IDLE issues for 2.7, 3.4, and 3.5 only. Thanks for the heads up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 05:31:10 2015 From: report at bugs.python.org (Al Sweigart) Date: Sun, 11 Jan 2015 04:31:10 +0000 Subject: [issue23205] Unit test needed for IDLE's GrepDialog.py's findfiles() In-Reply-To: <1420791360.73.0.110066531981.issue23205@psf.upfronthosting.co.za> Message-ID: <1420950670.11.0.867285912786.issue23205@psf.upfronthosting.co.za> Al Sweigart added the comment: I checked with a couple grep programs and they use depth first. Which makes sense, since you'd want the return order to be something like: /a/spam.txt /a/aa/spam.txt /a/bb/spam.txt /x/spam.txt /y/spam.txt /z/spam.txt ...instead of the bread-first: /a/spam.txt /x/spam.txt /y/spam.txt /z/spam.txt /a/aa/spam.txt /a/bb/spam.txt However, it turns out this is moot since the first thing GrepDialog.py does with the returned results is sort them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 07:27:32 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 11 Jan 2015 06:27:32 +0000 Subject: [issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__ In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za> Message-ID: <1420957652.66.0.660027306406.issue4395@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch that documents the default object.__ne__() implementation. It also documents the subclass priority rules for the reflected comparison methods, which is raised in Issue 22052. I have made some more tests to verify the relationships exists from __ne__ to __eq__, but no other relationships exist for the other methods. I will include it in my patch in Issue 21408 to avoid the patches conflicting with each other. ---------- keywords: +patch nosy: +vadmium Added file: http://bugs.python.org/file37671/default-ne-reflected-priority.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 07:36:23 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 11 Jan 2015 06:36:23 +0000 Subject: [issue22052] Comparison operators called in reverse order for subclasses with no override. In-Reply-To: <1406149410.09.0.756154064568.issue22052@psf.upfronthosting.co.za> Message-ID: <1420958183.31.0.086406781778.issue22052@psf.upfronthosting.co.za> Martin Panter added the comment: I have included some rules about the priority for calling reflected operator methods in my patch to Issue 4395 ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 07:39:37 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 11 Jan 2015 06:39:37 +0000 Subject: [issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__ In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za> Message-ID: <1420958377.85.0.0406146647833.issue4395@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 07:39:42 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 11 Jan 2015 06:39:42 +0000 Subject: [issue21408] delegation of `!=` to the right-hand side argument is not always done In-Reply-To: <1398954687.6.0.574462939929.issue21408@psf.upfronthosting.co.za> Message-ID: <1420958382.56.0.161562052267.issue21408@psf.upfronthosting.co.za> Martin Panter added the comment: This patch should fix the problem I think. Before the __ne__() implementation was calling the ?==? operator; now it calls the __eq__() method instead. Also includes extra test for Issue 4395 to avoid having conficting patches. ---------- keywords: +patch Added file: http://bugs.python.org/file37672/method-not-operator.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 07:39:54 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 11 Jan 2015 06:39:54 +0000 Subject: [issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__ In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za> Message-ID: <1420958394.68.0.328146678874.issue4395@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 08:05:15 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 11 Jan 2015 07:05:15 +0000 Subject: [issue23221] "a(n) the", "the a(n)" typos In-Reply-To: <1420940360.26.0.834732182943.issue23221@psf.upfronthosting.co.za> Message-ID: <1420959915.98.0.608662656913.issue23221@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, r.david.murray stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 08:22:51 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 11 Jan 2015 07:22:51 +0000 Subject: [issue23220] IDLE does not display \b backspace correctly. In-Reply-To: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za> Message-ID: <1420960971.55.0.292839661098.issue23220@psf.upfronthosting.co.za> Ned Deily added the comment: It's helpful to keep in mind that IDLE is a Tk application written in Python and, as such, depends on Tk to do nearly everything associated with writing to displays and reading from keyboards and pointing devices. If you try outputting the same string using the Tk shell, wish, you'll see exactly the same behavior as you do in IDLE: $ wish % .text insert 1.0 "hello\b\b\b\b\bHELLO" % pack .text And you'll see the same Tk platform differences. With the native OS X Tk's, the backspace characters aren't displayed; with a Linux or OS X X11 Tk, empty box characters are displayed. That may also depend on which font is in use. In any case, the Tk text widget does not behave the same way in this regard as most terminal emulator windows do would do with backspace characters. So it's up to any Tk app to figure out how it wants to deal with them. This issue has come up before for Tkinter in general: back in 2001, effbot suggested some code to search for and edit backspace runs in Tk text. Presumably something similar could be added to IDLE if there was general agreement that this was desirable (after verifying that it works on all of the Tk platforms that IDLE supports). See https://mail.python.org/pipermail/python-list/2001-December/085908.html ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 09:05:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 11 Jan 2015 08:05:11 +0000 Subject: [issue13299] namedtuple row factory for sqlite3 In-Reply-To: <1320021145.59.0.53370875256.issue13299@psf.upfronthosting.co.za> Message-ID: <1420963511.16.0.935128546205.issue13299@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is faster implementation. $ ./python -m timeit -s "import sqlite3; con = sqlite3.connect(':memory:'); con.row_factory = sqlite3.NamedTupleRow; con.execute('create table t (a, b)')" -s "for i in range(100): con.execute('insert into t values (1, 2)')" -- "con.execute('select * from t').fetchall()" 100 loops, best of 3: 2.74 msec per loop But it is still 3 times slower than sqlite3.Row. ---------- Added file: http://bugs.python.org/file37673/sqlite_namedtuplerow.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 09:12:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 11 Jan 2015 08:12:51 +0000 Subject: [issue13583] sqlite3.Row doesn't support slice indexes In-Reply-To: <1323639948.36.0.717803065724.issue13583@psf.upfronthosting.co.za> Message-ID: <1420963971.83.0.438451584343.issue13583@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: May be just use PyObject_GetItem(self->data, idx)? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 12:13:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 11 Jan 2015 11:13:08 +0000 Subject: [issue23136] BUG in how _strptime() handles week 0 In-Reply-To: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za> Message-ID: <1420974788.55.0.917626407959.issue23136@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file37674/strptime_julian_none_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 12:39:53 2015 From: report at bugs.python.org (Dmitry Shachnev) Date: Sun, 11 Jan 2015 11:39:53 +0000 Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone constant In-Reply-To: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za> Message-ID: <1420976393.07.0.839791489934.issue22932@psf.upfronthosting.co.za> Dmitry Shachnev added the comment: This patch adds a test case for formatdate() function. Before applying issue22932_v3.patch it fails, after applying that patch it succeeds. Sorry for the delay caused by holidays. ---------- Added file: http://bugs.python.org/file37675/issue22932_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 12:55:40 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 11 Jan 2015 11:55:40 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> Message-ID: <20150111115537.8743.50325@psf.io> Roundup Robot added the comment: New changeset cf4bf577749c by Mark Dickinson in branch 'default': Issue #23185: add math.inf and math.nan constants. https://hg.python.org/cpython/rev/cf4bf577749c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 12:56:31 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 11 Jan 2015 11:56:31 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> Message-ID: <1420977391.35.0.0104358223471.issue23185@psf.upfronthosting.co.za> Mark Dickinson added the comment: Committed. Thanks for all the helpful review comments! ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 13:03:34 2015 From: report at bugs.python.org (Ievgen Aleinikov) Date: Sun, 11 Jan 2015 12:03:34 +0000 Subject: [issue23222] open doesn't provide traceback for int argument Message-ID: <1420977814.07.0.566784617319.issue23222@psf.upfronthosting.co.za> New submission from Ievgen Aleinikov: HI, I was able to gat such behaviour on python version 3.4.2 and 3.2.3 >>> for i in range(10): ... f = open(i, "w") ... f.close() ... This will close interactive session without any output. On python 2 (2.7.9) it's not happening: >>> for i in range(10): ... f = open(i, "w") ... f.close() ... Traceback (most recent call last): File "", line 2, in TypeError: coercing to Unicode: need string or buffer, int found >>> And interpreter is not closed. If run attached 1.py we'll see following: python2.7 1.py Traceback (most recent call last): File "1.py", line 2, in f = open(i, "w") TypeError: coercing to Unicode: need string or buffer, int found python3.4 1.py -> nothing happens (echo $? -> 1) Kind regards, Ievgen. ---------- components: IO files: 1.py messages: 233844 nosy: slivabox priority: normal severity: normal status: open title: open doesn't provide traceback for int argument versions: Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file37676/1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 13:35:09 2015 From: report at bugs.python.org (SilentGhost) Date: Sun, 11 Jan 2015 12:35:09 +0000 Subject: [issue23222] open doesn't provide traceback for int argument In-Reply-To: <1420977814.07.0.566784617319.issue23222@psf.upfronthosting.co.za> Message-ID: <1420979709.37.0.348614515019.issue23222@psf.upfronthosting.co.za> SilentGhost added the comment: As explained in the docs[1] integer is a valid argument for the open function in the python3. It is also noted that the file descriptor is going to be closed, unless closefd argument to the open function was False, when f.close() is called. This is the behaviour you're seeing. Zero or other small integers tend to point to vital files opened by interpreter or the interpreter itself, so closing them shuts the interpreter down. This is a layman explanation, so someone should be able to provide a more technical description. In either case this is not a bug and passing random arguments to the open function is probably not what should be done in any production code. I'm closing this issue. [1] https://docs.python.org/3/library/functions.html#open ---------- components: +Interpreter Core -IO nosy: +SilentGhost resolution: -> not a bug stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 14:03:59 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 11 Jan 2015 13:03:59 +0000 Subject: [issue21902] Docstring of math.acosh, asinh, and atanh In-Reply-To: <1404275479.79.0.0199370909465.issue21902@psf.upfronthosting.co.za> Message-ID: <20150111130343.22407.47497@psf.io> Roundup Robot added the comment: New changeset d81cabb39de3 by Mark Dickinson in branch '2.7': Issue #21902: Replace incorrect 'hyperbolic arc sine' (etc.) with 'inverse hyperbolic sine' (etc.). Remove meaningless reference to radians. https://hg.python.org/cpython/rev/d81cabb39de3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 14:23:42 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 11 Jan 2015 13:23:42 +0000 Subject: [issue21902] Docstring of math.acosh, asinh, and atanh In-Reply-To: <1404275479.79.0.0199370909465.issue21902@psf.upfronthosting.co.za> Message-ID: <20150111132335.22397.11355@psf.io> Roundup Robot added the comment: New changeset 5edfc6c929f9 by Mark Dickinson in branch '3.4': Issue #21902: Replace incorrect 'hyperbolic arc sine' (etc.) with 'inverse hyperbolic sine' (etc.). Remove meaningless reference to radians. https://hg.python.org/cpython/rev/5edfc6c929f9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 14:23:42 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 11 Jan 2015 13:23:42 +0000 Subject: [issue21092] json serializer implicitly stringifies non-string keys In-Reply-To: <1396058532.4.0.747084200104.issue21092@psf.upfronthosting.co.za> Message-ID: <20150111132335.22397.70343@psf.io> Roundup Robot added the comment: New changeset 36099a05d76a by Mark Dickinson in branch 'default': Issue #21092: Merge from 3.4. https://hg.python.org/cpython/rev/36099a05d76a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 14:28:15 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 11 Jan 2015 13:28:15 +0000 Subject: [issue21092] json serializer implicitly stringifies non-string keys In-Reply-To: <1396058532.4.0.747084200104.issue21092@psf.upfronthosting.co.za> Message-ID: <1420982895.49.0.683421031184.issue21092@psf.upfronthosting.co.za> Mark Dickinson added the comment: Sorry; that last commit message should have been for #21902. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 14:28:52 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 11 Jan 2015 13:28:52 +0000 Subject: [issue21902] Docstring of math.acosh, asinh, and atanh In-Reply-To: <1404275479.79.0.0199370909465.issue21902@psf.upfronthosting.co.za> Message-ID: <1420982932.59.0.670720136543.issue21902@psf.upfronthosting.co.za> Mark Dickinson added the comment: Roundup message copied from #21902 (bad issue number): New changeset 36099a05d76a by Mark Dickinson in branch 'default': Issue #21092: Merge from 3.4. https://hg.python.org/cpython/rev/36099a05d76a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 14:29:16 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 11 Jan 2015 13:29:16 +0000 Subject: [issue21902] Docstring of math.acosh, asinh, and atanh In-Reply-To: <1404275479.79.0.0199370909465.issue21902@psf.upfronthosting.co.za> Message-ID: <1420982956.51.0.375162187222.issue21902@psf.upfronthosting.co.za> Mark Dickinson added the comment: Closing as fixed. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 15:07:10 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 11 Jan 2015 14:07:10 +0000 Subject: [issue22952] multiprocessing doc introduction not in affirmative tone In-Reply-To: <1417037709.37.0.435561396576.issue22952@psf.upfronthosting.co.za> Message-ID: <20150111140706.8767.17813@psf.io> Roundup Robot added the comment: New changeset a9a9c71f8e15 by Antoine Pitrou in branch '3.4': Issue #22952: improve multiprocessing doc introduction and defer notes until appropriate. https://hg.python.org/cpython/rev/a9a9c71f8e15 New changeset a65c23ea5f9e by Antoine Pitrou in branch 'default': Issue #22952: improve multiprocessing doc introduction and defer notes until appropriate. https://hg.python.org/cpython/rev/a65c23ea5f9e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 15:09:38 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 11 Jan 2015 14:09:38 +0000 Subject: [issue22952] multiprocessing doc introduction not in affirmative tone In-Reply-To: <1417037709.37.0.435561396576.issue22952@psf.upfronthosting.co.za> Message-ID: <20150111140935.125884.69122@psf.io> Roundup Robot added the comment: New changeset e7d03a33e675 by Antoine Pitrou in branch '2.7': Issue #22952: improve multiprocessing doc introduction and defer notes until appropriate. https://hg.python.org/cpython/rev/e7d03a33e675 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 15:10:16 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 Jan 2015 14:10:16 +0000 Subject: [issue22952] multiprocessing doc introduction not in affirmative tone In-Reply-To: <1417037709.37.0.435561396576.issue22952@psf.upfronthosting.co.za> Message-ID: <1420985416.96.0.314051714378.issue22952@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I've committed your patches, Davin. Thank you for contributing! ---------- nosy: +pitrou resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 15:11:09 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 Jan 2015 14:11:09 +0000 Subject: [issue23100] multiprocessing doc organization impedes understanding In-Reply-To: <1419292691.51.0.0335324108877.issue23100@psf.upfronthosting.co.za> Message-ID: <1420985469.44.0.279632375791.issue23100@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I am happy to provide proposed patches but first can someone please clarify for me whether I should have those patches depend upon the patches from Issue 22952? This question is now moot :) ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 15:22:14 2015 From: report at bugs.python.org (Akira Li) Date: Sun, 11 Jan 2015 14:22:14 +0000 Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone constant In-Reply-To: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za> Message-ID: <1420986134.19.0.840658090937.issue22932@psf.upfronthosting.co.za> Akira Li added the comment: @mitya57: Please, combine the code changes, tests, docs into a single rietveld-compatible patch (hg diff); read devguide and http://bugs.python.org/issue13963 Make sure "review" link appears on the right near the patch. Example: http://bugs.python.org/issue22798 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 15:58:55 2015 From: report at bugs.python.org (gajdig) Date: Sun, 11 Jan 2015 14:58:55 +0000 Subject: [issue23223] subprocess32 unable to be installed via pip Message-ID: <1420988335.84.0.852324840032.issue23223@psf.upfronthosting.co.za> New submission from gajdig: The latest subprocess32, 3.2.6, is unable to be installed in Windows 7 via pip. The error messages: _posixsubprocess.c(10) : fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory error: command 'C:\\Users\\user1\\AppData\\Local\\Programs\\Common\\Microsoft\\Visual C++ for Python\\9.0\\VC\\Bin\\cl.exe' failed with exit status 2 Read that unistd.h is not a Windows file. ---------- components: Installation, Windows messages: 233857 nosy: gajdig, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: subprocess32 unable to be installed via pip type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 16:04:35 2015 From: report at bugs.python.org (SilentGhost) Date: Sun, 11 Jan 2015 15:04:35 +0000 Subject: [issue23223] subprocess32 unable to be installed via pip In-Reply-To: <1420988335.84.0.852324840032.issue23223@psf.upfronthosting.co.za> Message-ID: <1420988675.22.0.432751064451.issue23223@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Library (Lib) -Installation nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 16:34:05 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 Jan 2015 15:34:05 +0000 Subject: [issue23206] json.dumps(ensure_ascii=False) is ~10x slower than json.dumps() In-Reply-To: <1420809445.24.0.133647496806.issue23206@psf.upfronthosting.co.za> Message-ID: <1420990445.59.0.169232916122.issue23206@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I get the following compile error: In file included from ./Include/Python.h:48:0, from /home/antoine/cpython/default/Modules/_json.c:1: /home/antoine/cpython/default/Modules/_json.c: In function ?escape_unicode?: /home/antoine/cpython/default/Modules/_json.c:301:24: error: ?PyUnicode_4BYTE_DATA? undeclared (first use in this function) assert(kind == PyUnicode_4BYTE_DATA); ^ Fixing it is trivial, I can do it when committing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 16:44:17 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 Jan 2015 15:44:17 +0000 Subject: [issue23206] json.dumps(ensure_ascii=False) is ~10x slower than json.dumps() In-Reply-To: <1420809445.24.0.133647496806.issue23206@psf.upfronthosting.co.za> Message-ID: <1420991057.81.0.237116381235.issue23206@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The patch was committed in b312b256931e. Thank you! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 17:04:16 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 11 Jan 2015 16:04:16 +0000 Subject: [issue23216] IDLE grep/find/replace source code needs docstrings In-Reply-To: <1420881306.22.0.52075806524.issue23216@psf.upfronthosting.co.za> Message-ID: <1420992256.0.0.168283278328.issue23216@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +terry.reedy stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 17:12:19 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 11 Jan 2015 16:12:19 +0000 Subject: [issue23218] Modernize the IDLE Find/Replace/Find in Files dialogs In-Reply-To: <1420884051.8.0.416866319984.issue23218@psf.upfronthosting.co.za> Message-ID: <1420992739.95.0.116124623798.issue23218@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +terry.reedy stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 17:17:03 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 11 Jan 2015 16:17:03 +0000 Subject: [issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__ In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za> Message-ID: <1420993023.61.0.993793764793.issue4395@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 17:48:16 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 11 Jan 2015 16:48:16 +0000 Subject: [issue21902] Docstring of math.acosh, asinh, and atanh In-Reply-To: <1404275479.79.0.0199370909465.issue21902@psf.upfronthosting.co.za> Message-ID: <1420994896.44.0.581012837977.issue21902@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 19:01:33 2015 From: report at bugs.python.org (Karl Richter) Date: Sun, 11 Jan 2015 18:01:33 +0000 Subject: [issue23163] pdb docs need to contain a statement on threads/multithreaded debugging In-Reply-To: <1420366883.83.0.11703664982.issue23163@psf.upfronthosting.co.za> Message-ID: <1420999293.91.0.359624506231.issue23163@psf.upfronthosting.co.za> Karl Richter added the comment: My initial description was imprecise. Clearification: The fact that in #!/usr/bin/python import threading def debugging(): def __a_thread__(): print("2") a_thread = threading.Thread(target=__a_thread__) print("1") if __name__ == "__main__": debugging() when invoked with `python -m pdb` the breakpoint at line 7 is ignored, like in $ python -m pdb multithreaded_debugging.py > /mnt/DATA/richter/examples/python/multithreaded_debugging/multithreaded_debugging.py(3)() -> import threading (Pdb) break 7 Breakpoint 1 at /mnt/DATA/richter/examples/python/multithreaded_debugging/multithreaded_debugging.py:7 (Pdb) c 1 The program finished and will be restarted > /mnt/DATA/richter/examples/python/multithreaded_debugging/multithreaded_debugging.py(3)() -> import threading (Pdb) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 19:04:47 2015 From: report at bugs.python.org (Karl Richter) Date: Sun, 11 Jan 2015 18:04:47 +0000 Subject: [issue23163] pdb docs need to contain a statement on threads/multithreaded debugging In-Reply-To: <1420366883.83.0.11703664982.issue23163@psf.upfronthosting.co.za> Message-ID: <1420999487.67.0.0221717495737.issue23163@psf.upfronthosting.co.za> Karl Richter added the comment: Sorry, I mean #!/usr/bin/python import threading def debugging(): def __a_thread__(): print("2") a_thread = threading.Thread(target=__a_thread__) a_thread.start() a_thread.join() print("1") if __name__ == "__main__": debugging() It's very uncommon to set the current debugging thread in the source. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 21:19:22 2015 From: report at bugs.python.org (Carol Willing) Date: Sun, 11 Jan 2015 20:19:22 +0000 Subject: [issue23220] IDLE does not display \b backspace correctly. In-Reply-To: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za> Message-ID: <1421007562.04.0.307475427547.issue23220@psf.upfronthosting.co.za> Carol Willing added the comment: Ned, Thanks for the detailed example and confirming my gut instinct that Tk was the root cause of the differences seen between the IDLE's Python interactive shell (https://docs.python.org/3.4/library/idle.html) and the interactive interpreter invoked from the command line (https://docs.python.org/3.4/tutorial/interpreter.html#tut-invoking). As an end user learning Python (such as the elementary education market), the current Standard Library documentation on IDLE guides me to the incorrect conclusion that the "Python shell window (aka interactive interpreter)" in IDLE would behave the same as invoking the interactive interpreter from the command line. It seems reasonable to explicitly state in the Standard Library doc that: "In rare cases, such as text handling with certain special characters (i.e. '\b' in a string), the IDLE's interactive Python shell may return a different response than the Python interactive interpreter invoked from the command line. This is due to IDLE's low level dependence on Tk (Tk itself is not part of Python; it is maintained at ActiveState. reference: first paragraph of https://docs.python.org/3.4/library/tkinter.html#module-tkinter)." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 11 21:57:00 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 11 Jan 2015 20:57:00 +0000 Subject: [issue23180] Rename IDLE's "Windows" menu item to "Window" In-Reply-To: <1420614987.43.0.350300091598.issue23180@psf.upfronthosting.co.za> Message-ID: <1421009820.78.0.380900403619.issue23180@psf.upfronthosting.co.za> Ned Deily added the comment: Also, the IDLE help text file (Lib/idlelib/help.txt) and the IDLE documentation in the Standard Library Reference (Doc/library/idle.rst) refer to the "Windows" menu and would need to be updated. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 00:23:00 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 11 Jan 2015 23:23:00 +0000 Subject: [issue23214] BufferedReader.read1(size) signature incompatible with BufferedIOBase.read1(size=-1) In-Reply-To: <1420854382.8.0.44417983014.issue23214@psf.upfronthosting.co.za> Message-ID: <1421018580.2.0.302475678575.issue23214@psf.upfronthosting.co.za> Martin Panter added the comment: Looking at the test suite: * read1() of LZMAFile and GzipFile (both implementing BufferedIOBase) are asserted to return a non-zero result until EOF * LZMAFile.read1(0) is asserted to return an empty string * BufferedReader.read1(-1) is asserted to raise ValueError * There are also tests of read1() methods on HTTPResponse and ZipFile.open() objects, but those methods are undocumented It seems the most consistent way forward would be to: * Define BufferedIOBase.read1(-1) to read and return an arbitrary number of bytes, more than zero unless none are available due to EOF or non-blocking mode. Maybe suggest that it would return the current buffered data or try to read a full buffer of data (with one call) and return it if applicable. * Change the signature to BufferedReader.read1(size=-1) and implement the size=-1 behaviour ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 00:24:02 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 11 Jan 2015 23:24:02 +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: <1421018642.2.0.410036403647.issue15955@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 00:57:38 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 11 Jan 2015 23:57:38 +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: <1421020658.17.0.0728806258562.issue15955@psf.upfronthosting.co.za> Martin Panter added the comment: We still need a patch for max_length in BZ2Decompressor, and to use it in BZ2File. Also, I think my GzipFile patch should be considered as a bug fix (rather than enhancement), e.g. the fix for Issue 16043 assumes GzipFile.read() is limited. I?m adding v4 of Nikolaus?s low-level LZMA patch. I merged v3 with the recent default branch and fixed the conflicts, since I couldn?t tell what revision it was originally based on. I also made some fixes based on my review comments. ---------- Added file: http://bugs.python.org/file37677/issue15955_lzma_r4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 01:11:24 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 12 Jan 2015 00:11:24 +0000 Subject: [issue17239] XML vulnerabilities in Python In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za> Message-ID: <1421021484.31.0.729825369245.issue17239@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 01:58:28 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 12 Jan 2015 00:58:28 +0000 Subject: [issue23224] LZMADecompressor object is only initialized in __init__ Message-ID: <1421024308.33.0.868171678499.issue23224@psf.upfronthosting.co.za> New submission from Martin Panter: Noticed in a patch review around LZMModules/_lzmamodule.c:1055 that the C-level LZMADecompressor object is being initialized in an __init__() method. It crashes if you create the object with __new__() and never call __init__(): >>> from lzma import LZMADecompressor >>> LZMADecompressor.__new__(LZMADecompressor).decompress(bytes()) Segmentation fault (core dumped) [Exit 139] ---------- components: Extension Modules messages: 233866 nosy: vadmium priority: normal severity: normal status: open title: LZMADecompressor object is only initialized in __init__ type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 02:12:35 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 12 Jan 2015 01:12:35 +0000 Subject: [issue21896] Unexpected ConnectionResetError in urllib.request against a valid website In-Reply-To: <1404217105.77.0.742047143649.issue21896@psf.upfronthosting.co.za> Message-ID: <1421025155.62.0.277270044873.issue21896@psf.upfronthosting.co.za> Martin Panter added the comment: Not a Python bug. The web site seems to be doing this based on the user agent; if you change it, it works: urlopen(Request("http://www.thomsonlocal.com/", headers={"User-Agent": "https://bugs.python.org/issue21896"})) ---------- nosy: +vadmium type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 02:22:08 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 12 Jan 2015 01:22:08 +0000 Subject: [issue23018] Add version info to python[w].exe In-Reply-To: <1418102862.79.0.624047396863.issue23018@psf.upfronthosting.co.za> Message-ID: <1421025728.63.0.413499748874.issue23018@psf.upfronthosting.co.za> Steve Dower added the comment: Anyone have any opinions on this? My only hesitation is adding the Windows 10 UUID, which will fix GetVersion but may cause other API problems, and we're certainly not testing against Windows 10 yet. (On the other hand, it's easy enough to remove that single UUID later if there's an issue we can't fix.) I'm keen to put it in and forget about it, so if not, I'll just do it :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 02:22:36 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 12 Jan 2015 01:22:36 +0000 Subject: [issue21896] Unexpected ConnectionResetError in urllib.request against a valid website In-Reply-To: <1404217105.77.0.742047143649.issue21896@psf.upfronthosting.co.za> Message-ID: <1421025756.28.0.837263135127.issue21896@psf.upfronthosting.co.za> Ned Deily added the comment: So it does. Thanks, Martin. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 02:35:50 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 12 Jan 2015 01:35:50 +0000 Subject: [issue18003] lzma module very slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1421026550.85.0.520097548916.issue18003@psf.upfronthosting.co.za> Martin Panter added the comment: I haven?t done any tests, but my LZMAFile patch to Issue 15955 uses BufferedReader, so it might satisfy this issue ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 02:43:53 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 12 Jan 2015 01:43:53 +0000 Subject: [issue22495] merge large parts of test_binop.py and test_fractions.py In-Reply-To: <1411648064.39.0.863179207441.issue22495@psf.upfronthosting.co.za> Message-ID: <1421027033.81.0.605193603936.issue22495@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 02:48:54 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 12 Jan 2015 01:48:54 +0000 Subject: [issue22495] merge large parts of test_binop.py and test_fractions.py In-Reply-To: <1411648064.39.0.863179207441.issue22495@psf.upfronthosting.co.za> Message-ID: <1421027334.64.0.342715227336.issue22495@psf.upfronthosting.co.za> Martin Panter added the comment: Yeah it would be good to put related tests in the one place. I was trying to find a good place to test how the comparison operators invoke the __eq__(), __gt__() etc methods, and the existing tests seem to be spread over test_compare.py and test_binop.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 03:00:56 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 12 Jan 2015 02:00:56 +0000 Subject: [issue23182] Update grammar tests to use new style for annotated function definitions In-Reply-To: <1420620545.16.0.862545867011.issue23182@psf.upfronthosting.co.za> Message-ID: <1421028056.46.0.130373325594.issue23182@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> patch review versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 03:02:26 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 12 Jan 2015 02:02:26 +0000 Subject: [issue20285] Improve object.__doc__ and help(object) output In-Reply-To: <1389920351.63.0.12805701843.issue20285@psf.upfronthosting.co.za> Message-ID: <1421028146.08.0.440752520448.issue20285@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 03:09:01 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 12 Jan 2015 02:09:01 +0000 Subject: [issue22662] subprocess.Popen.communicate causing local tty terminal settings to change inconsistently In-Reply-To: <1413578673.84.0.0347750412267.issue22662@psf.upfronthosting.co.za> Message-ID: <1421028541.65.0.492596768971.issue22662@psf.upfronthosting.co.za> Martin Panter added the comment: I tried in Python 2.7.9 on Linux, with env = "TERM=xterm", cmd = "date", and couldn?t get any of those seven terminal settings to be turned off ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 04:48:02 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 12 Jan 2015 03:48:02 +0000 Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?= =?utf-8?q?=E2=80=9D_exception_message_on_Wine?= In-Reply-To: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za> Message-ID: <1421034482.9.0.199984791239.issue22977@psf.upfronthosting.co.za> Martin Panter added the comment: Here?s a simple patch which should fix it, although I have not verified this because I don?t have a Windows compiler (and MINGW cross compiling sounds too tricky) ---------- keywords: +patch Added file: http://bugs.python.org/file37678/win-error-format.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 05:18:18 2015 From: report at bugs.python.org (Al Sweigart) Date: Mon, 12 Jan 2015 04:18:18 +0000 Subject: [issue23180] Rename IDLE's "Windows" menu item to "Window" In-Reply-To: <1420614987.43.0.350300091598.issue23180@psf.upfronthosting.co.za> Message-ID: <1421036298.89.0.380167275518.issue23180@psf.upfronthosting.co.za> Al Sweigart added the comment: Added another patch for the documentation changes for the menu renaming. ---------- Added file: http://bugs.python.org/file37679/idle_window_doc_rename.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 07:43:14 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 12 Jan 2015 06:43:14 +0000 Subject: [issue23224] LZMADecompressor object is only initialized in __init__ In-Reply-To: <1421024308.33.0.868171678499.issue23224@psf.upfronthosting.co.za> Message-ID: <1421044994.74.0.142772999427.issue23224@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +nadeem.vawda, serhiy.storchaka stage: -> needs patch versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 09:39:26 2015 From: report at bugs.python.org (Ethan Furman) Date: Mon, 12 Jan 2015 08:39:26 +0000 Subject: [issue20284] patch to implement PEP 461 (%-interpolation for bytes) In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <1421051966.06.0.619239799379.issue20284@psf.upfronthosting.co.za> Ethan Furman added the comment: I've been digging into this over the last week and come to the realization that I won't be able to finish this patch. My apologies. Victor, can you take over? I would appreciate it. The tests I have written are only for the Python side. The patch I was working on (inherited from Niel and the Python 2 code base) also added a couple C ABI functions -- do we want/need these? How do we write tests for them? ---------- stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 10:07:03 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 Jan 2015 09:07:03 +0000 Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?= =?utf-8?q?=E2=80=9D_exception_message_on_Wine?= In-Reply-To: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za> Message-ID: <1421053623.38.0.711051227133.issue22977@psf.upfronthosting.co.za> STINNER Victor added the comment: The attached patch lacks an unit test. When I will be able to build CPython again, I will try the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 10:42:07 2015 From: report at bugs.python.org (Anselm Kruis) Date: Mon, 12 Jan 2015 09:42:07 +0000 Subject: [issue23160] Respect the environment variable SVNROOT in external-common.bat In-Reply-To: <1420356909.91.0.987880987929.issue23160@psf.upfronthosting.co.za> Message-ID: <1421055727.91.0.875360764892.issue23160@psf.upfronthosting.co.za> Anselm Kruis added the comment: Your guess is correct, it will be a null merge into default. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 10:54:38 2015 From: report at bugs.python.org (Karan Goel) Date: Mon, 12 Jan 2015 09:54:38 +0000 Subject: [issue23221] "a(n) the", "the a(n)" typos In-Reply-To: <1420940360.26.0.834732182943.issue23221@psf.upfronthosting.co.za> Message-ID: <1421056478.84.0.900209768363.issue23221@psf.upfronthosting.co.za> Karan Goel added the comment: Hey I'll be working on this and submitting a patch. ---------- nosy: +karan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 11:10:52 2015 From: report at bugs.python.org (Karan Goel) Date: Mon, 12 Jan 2015 10:10:52 +0000 Subject: [issue23221] "a(n) the", "the a(n)" typos In-Reply-To: <1420940360.26.0.834732182943.issue23221@psf.upfronthosting.co.za> Message-ID: <1421057452.58.0.637690042366.issue23221@psf.upfronthosting.co.za> Karan Goel added the comment: There we go. I fixed all the reported typos using the best of my knowledge. ---------- keywords: +patch Added file: http://bugs.python.org/file37680/issue23221.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 11:16:49 2015 From: report at bugs.python.org (Martin Richard) Date: Mon, 12 Jan 2015 10:16:49 +0000 Subject: [issue23209] asyncio: break some cycles In-Reply-To: <1420823775.21.0.0191485458241.issue23209@psf.upfronthosting.co.za> Message-ID: <1421057809.69.0.506205037647.issue23209@psf.upfronthosting.co.za> Martin Richard added the comment: I updated the selector patch so BaseSelector.get_key() raises KeyError if the mapping is None. All the (non skipped) tests in test_selectors.py passed. Anyway, if there is an other problem with freeing the mapping object (I don't know, maybe "reopening" a loop may be considered?) this patch can probably be dropped. Since this cycle is broken when the loop is closed, the objects will likely be collected once the program terminates. ---------- Added file: http://bugs.python.org/file37681/break-selector-map-cycle.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 12:06:01 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 Jan 2015 11:06:01 +0000 Subject: [issue23225] selectors: raise an exception if the selector is closed Message-ID: <1421060761.71.0.41386603707.issue23225@psf.upfronthosting.co.za> New submission from STINNER Victor: I propose to raise a RuntimeError exception on operations of a selector when the selector is closed. I'm not sure that RuntimeError is the most common exception: - io and gzip raise ValueError - asyncio raises RuntimeError (and selectors is "linked" to asyncio) - multiprocessing raises OSError - dbm.dumb raises dbm.dumb.error This issue is related to the issue #23209 which propopses to set the _map attribute to None when in the close() method. ---------- components: asyncio files: close_selector.patch keywords: patch messages: 233881 nosy: gvanrossum, haypo, martius, neologix, yselivanov priority: normal severity: normal status: open title: selectors: raise an exception if the selector is closed versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37682/close_selector.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 12:06:32 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 Jan 2015 11:06:32 +0000 Subject: [issue23209] asyncio: break some cycles In-Reply-To: <1420823775.21.0.0191485458241.issue23209@psf.upfronthosting.co.za> Message-ID: <1421060792.52.0.245196455143.issue23209@psf.upfronthosting.co.za> STINNER Victor added the comment: I opened the issue #23225 "selectors: raise an exception if the selector is closed" which is a different approach (but it should also fix the reference cycle, I kept the "self._map = None" change). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 12:57:21 2015 From: report at bugs.python.org (Dmitry Shachnev) Date: Mon, 12 Jan 2015 11:57:21 +0000 Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone constant In-Reply-To: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za> Message-ID: <1421063841.45.0.330498501446.issue22932@psf.upfronthosting.co.za> Changes by Dmitry Shachnev : Added file: http://bugs.python.org/file37683/issue22932_combined.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 14:24:42 2015 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 12 Jan 2015 13:24:42 +0000 Subject: [issue23193] Please support "numeric_owner" in tarfile In-Reply-To: <1420728144.57.0.872420723687.issue23193@psf.upfronthosting.co.za> Message-ID: <1421069082.6.0.680171472172.issue23193@psf.upfronthosting.co.za> Eric V. Smith added the comment: I think Michael is asking if the proposed change would ever be accepted. If the answer is "no, not even if you write the tests and update the documentation", then there's no sense putting the work into this. That seems like a reasonable question to me. I think the proposed change is reasonable, but I'm no tarfile expert. But since this functionality is available in the tar command as --numeric-owner, I think the feature request itself is a good idea. ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 15:30:12 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 12 Jan 2015 14:30:12 +0000 Subject: [issue23193] Please support "numeric_owner" in tarfile In-Reply-To: <1420728144.57.0.872420723687.issue23193@psf.upfronthosting.co.za> Message-ID: <1421073012.22.0.232534905049.issue23193@psf.upfronthosting.co.za> R. David Murray added the comment: I concur that this is a reasonable feature request, and it is not one that can be satisfied without modifying the tarfile module (that is, you can't write a simple wrapper to tarfile to get the functionality desired without cutting and pasting the entire chown method). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 16:17:46 2015 From: report at bugs.python.org (=?utf-8?q?Jarle_Selv=C3=A5g?=) Date: Mon, 12 Jan 2015 15:17:46 +0000 Subject: [issue23189] Set docstrings to empty string when optimizing with -OO. In-Reply-To: <1420710105.42.0.0455822244895.issue23189@psf.upfronthosting.co.za> Message-ID: <1421075866.75.0.0324327151196.issue23189@psf.upfronthosting.co.za> Jarle Selv?g added the comment: I agree that -OO does what (people have agreed) it's supposed to do. Many packages manipulates the docstring without checking for 'None' (see list below). For many package developers, it seems hard to remember that the docstrings may disappear after optimization. This behavior is not intuitive. At least in cases where the docstring is set to a string value, the expected behavior in my opinion would be to set its value to an empty string during optimization with -OO. Here are some of the packages that run into trouble when the docstrings are set to 'None' by the -OO optimization: algopy astropy lmfit pyamg pyvisa mpl_toolkits sympy statsmodels patsy sklearn ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 17:36:32 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 12 Jan 2015 16:36:32 +0000 Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?= =?utf-8?q?=E2=80=9D_exception_message_on_Wine?= In-Reply-To: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za> Message-ID: <1421080592.07.0.144291117793.issue22977@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> patch review versions: +Python 3.4, Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 18:20:03 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 12 Jan 2015 17:20:03 +0000 Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone constant In-Reply-To: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za> Message-ID: <1421083203.66.0.980163183269.issue22932@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 18:27:39 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 12 Jan 2015 17:27:39 +0000 Subject: [issue23199] libpython27.a in amd64 release is 32-bit In-Reply-To: <1420764337.42.0.255694319213.issue23199@psf.upfronthosting.co.za> Message-ID: <1421083659.8.0.623413447247.issue23199@psf.upfronthosting.co.za> Steve Dower added the comment: Thanks for the notice. I'll try and get that fixed up for the next 2.7 release. ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 18:55:16 2015 From: report at bugs.python.org (Demian Brecht) Date: Mon, 12 Jan 2015 17:55:16 +0000 Subject: [issue8450] httplib: false BadStatusLine() raised In-Reply-To: <1271630731.08.0.327097174192.issue8450@psf.upfronthosting.co.za> Message-ID: <1421085316.07.0.368265462692.issue8450@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 21:55:06 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 Jan 2015 20:55:06 +0000 Subject: [issue19777] Provide a home() classmethod on Path objects In-Reply-To: <1385409863.35.0.0114355564026.issue19777@psf.upfronthosting.co.za> Message-ID: <1421096106.26.0.566181670118.issue19777@psf.upfronthosting.co.za> STINNER Victor added the comment: + def _test_home(self, p): + q = self.cls(os.path.expanduser('~')) + self.assertEqual(p, q) + self.assertEqual(str(p), str(q)) + self.assertIs(type(p), type(q)) + self.assertTrue(p.is_absolute()) + + def test_home(self): + p = self.cls.home() + self._test_home(p) Why are you using a submethod _test_home()? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 22:24:23 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 12 Jan 2015 21:24:23 +0000 Subject: [issue19777] Provide a home() classmethod on Path objects In-Reply-To: <1385409863.35.0.0114355564026.issue19777@psf.upfronthosting.co.za> Message-ID: <20150112204537.22417.7603@psf.io> Roundup Robot added the comment: New changeset 4a55b98314cd by Antoine Pitrou in branch 'default': Issue #19777: Provide a home() classmethod on Path objects. https://hg.python.org/cpython/rev/4a55b98314cd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 22:49:28 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 12 Jan 2015 21:49:28 +0000 Subject: [issue23199] libpython27.a in amd64 release is 32-bit In-Reply-To: <1420764337.42.0.255694319213.issue23199@psf.upfronthosting.co.za> Message-ID: <1421099368.87.0.365251760181.issue23199@psf.upfronthosting.co.za> Steve Dower added the comment: Is the libpython27.a file actually a 32-bit version or is it just corrupted? It seems to be considerably smaller than the version in the 32-bit installer, but it is certainly not being generated from the 32-bit version. I didn't write this code originally, and I don't use MinGW, so I'm not entirely familiar with how it should work. Do I need separate 64-bit tools to build the library for the 64-bit DLL or will the 32-bit tools suffice? Are the interfaces stable enough within 64-bit versions of MinGW that shipping the library makes sense, or are people likely to always need to regenerate it anyway? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 22:52:38 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 12 Jan 2015 21:52:38 +0000 Subject: [issue23225] selectors: raise an exception if the selector is closed In-Reply-To: <1421060761.71.0.41386603707.issue23225@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: RuntimeError sounds better to me (raising ValueError when no value is provided, e.g. in select() sounds definitely strange). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 22:57:59 2015 From: report at bugs.python.org (Erik O'Shaughnessy) Date: Mon, 12 Jan 2015 21:57:59 +0000 Subject: [issue1250] Building external modules using Sun Studio 12 In-Reply-To: <1191964251.86.0.558465608726.issue1250@psf.upfronthosting.co.za> Message-ID: <1421099879.75.0.48921373639.issue1250@psf.upfronthosting.co.za> Erik O'Shaughnessy added the comment: Still seeing this issue on Solaris 11 with Solaris Studio compilers when building pandas 0.15.2 and matplotlib 1.4.2. ---------- nosy: +Erik.O'Shaughnessy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 23:25:44 2015 From: report at bugs.python.org (Zach Welch) Date: Mon, 12 Jan 2015 22:25:44 +0000 Subject: [issue23199] libpython27.a in amd64 release is 32-bit In-Reply-To: <1420764337.42.0.255694319213.issue23199@psf.upfronthosting.co.za> Message-ID: <1421101544.62.0.0503914606587.issue23199@psf.upfronthosting.co.za> Zach Welch added the comment: The libpython27.a is an actual 32-bit version, as confirmed by running objdump -t on it. It reports the sections' file format as pe-i386 instead of pe-x86-64. I am only using it for building for the 64-bit target, so I cannot confirm its viability for 32-bit builds. To build 64-bit Windows binaries, you need a MinGW-w64 toolchain (which is a completely separate project from the original MinGW project). The target triplet is x86_64-w64-mingw32. I cannot speak to the stability of the MinGW-w64 library interface, but I would expect it to be stable. To wit, I would be shocked if future changes required regeneration of third-party .a files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 23:40:48 2015 From: report at bugs.python.org (Andrew Barnert) Date: Mon, 12 Jan 2015 22:40:48 +0000 Subject: [issue23226] Add float linspace recipe to docs Message-ID: <1421102448.57.0.289351503451.issue23226@psf.upfronthosting.co.za> New submission from Andrew Barnert: In a recent thread on python-ideas (https://mail.python.org/pipermail/python-ideas/2015-January/030817.html), it was concluded that Python should not have a range-like type for floats in the stdlib, but there should be some simple discussion of the alternatives in the docs. The attached diff describes the issues, demonstrates the simplest reasonable algorithm, and links to a recipe on ActiveState (which builds the same algorithm into a lazy sequence, and links to other recipes with different alternatives). ---------- assignee: docs at python components: Documentation files: stdtypes.rst.diff keywords: patch messages: 233893 nosy: abarnert, docs at python priority: normal severity: normal status: open title: Add float linspace recipe to docs type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file37684/stdtypes.rst.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 23:41:31 2015 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 12 Jan 2015 22:41:31 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> Message-ID: <1421102491.06.0.980164721067.issue23185@psf.upfronthosting.co.za> Guido van Rossum added the comment: Should inf and nan be added to cmath too? It has e and pi and isnan() and isinf()... Also complex(0, math.nan) a value that is printed as "nanj" and complex("nanj") parses and returns such a value, so the point could be made that there should be a constant named complex.nanj. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 23:53:15 2015 From: report at bugs.python.org (Robert Collins) Date: Mon, 12 Jan 2015 22:53:15 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1421103195.13.0.61617127293.issue17911@psf.upfronthosting.co.za> Robert Collins added the comment: w.r.t. a new linecache interface, it looks like we need two attributes from f_globals: __name__ and __loader__, so that we can eventually call __loader__.get_source(__name__). One small change (to let me focus on traceback) would be to add another kw argument to the existing calls that take module_globals, called e.g. get_source, which would be a simple callable (source = get_source()). For the deferred linecache situation, we'd then create partial(f_globals.__loader__.get_source, f_globals.__name__) and keep that around until we need the source. We could even abstract that out into a function in linecache to keep the knowledge in one place. Another way to tackle this would be to add a new function to linecache that lazily seeds the cache: it would stash the get_source method and the name against the filename, and when getline[s] is called actually invoke it. I think the second way is a bit nicer myself. What do folk think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 12 23:58:49 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 12 Jan 2015 22:58:49 +0000 Subject: [issue22729] `wait` and `as_completed` depend on private api In-Reply-To: <1414269700.02.0.917285833698.issue22729@psf.upfronthosting.co.za> Message-ID: <1421103528.99.0.222756510806.issue22729@psf.upfronthosting.co.za> Andrew Svetlov added the comment: -1. Sorry, I don't see the reason for making custom `Future` class. Can you elaborate? ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 00:03:41 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 12 Jan 2015 23:03:41 +0000 Subject: [issue22286] Allow backslashreplace error handler to be used on input In-Reply-To: <1409136620.65.0.397738586583.issue22286@psf.upfronthosting.co.za> Message-ID: <1421103821.82.0.748533547961.issue22286@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 00:22:33 2015 From: report at bugs.python.org (Andrew Barnert) Date: Mon, 12 Jan 2015 23:22:33 +0000 Subject: [issue23226] Add float linspace recipe to docs In-Reply-To: <1421102448.57.0.289351503451.issue23226@psf.upfronthosting.co.za> Message-ID: <1421104953.94.0.322199711758.issue23226@psf.upfronthosting.co.za> Andrew Barnert added the comment: As suggested by the review: removing unnecessary parenthetical, changing "ulp" to "digit", and fixing the recipe link. ---------- Added file: http://bugs.python.org/file37685/stdtypes.rst.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 01:29:11 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 13 Jan 2015 00:29:11 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <1421108951.81.0.268326834419.issue15836@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 01:38:20 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 13 Jan 2015 00:38:20 +0000 Subject: [issue9587] unittest.assertRaises() return the raised exception In-Reply-To: <1281711464.19.0.685530938413.issue9587@psf.upfronthosting.co.za> Message-ID: <1421109500.64.0.710048926825.issue9587@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 01:48:28 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 13 Jan 2015 00:48:28 +0000 Subject: [issue19777] Provide a home() classmethod on Path objects In-Reply-To: <1385409863.35.0.0114355564026.issue19777@psf.upfronthosting.co.za> Message-ID: <1421110108.43.0.556282495564.issue19777@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I've committed the patch, thank you! ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 02:17:00 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 13 Jan 2015 01:17:00 +0000 Subject: [issue15836] unittest assertRaises should verify excClass is actually a BaseException class In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za> Message-ID: <1421111820.81.0.985960086938.issue15836@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: patch review -> commit review versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 02:42:39 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 13 Jan 2015 01:42:39 +0000 Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?= =?utf-8?q?=E2=80=9D_exception_message_on_Wine?= In-Reply-To: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za> Message-ID: <1421113359.02.0.975574786107.issue22977@psf.upfronthosting.co.za> Martin Panter added the comment: This patch includes a test case, based on Eryksun?s exception code ---------- Added file: http://bugs.python.org/file37686/win-error-format-v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 02:43:25 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 13 Jan 2015 01:43:25 +0000 Subject: [issue23224] LZMADecompressor object is only initialized in __init__ In-Reply-To: <1421024308.33.0.868171678499.issue23224@psf.upfronthosting.co.za> Message-ID: <1421113405.24.0.322296645377.issue23224@psf.upfronthosting.co.za> Martin Panter added the comment: A patch for this might conflict with the LZMA patch for Issue 15955, so it would be simplest to wait for that issue to be resolved first ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 02:51:04 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 13 Jan 2015 01:51:04 +0000 Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone constant In-Reply-To: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za> Message-ID: <1421113864.18.0.643605975622.issue22932@psf.upfronthosting.co.za> R. David Murray added the comment: The tests fail for me the same way both before and after the code patch: ====================================================================== FAIL: test_formatdate (test.test_email.test_utils.FormatDateTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/rdmurray/python/p34/Lib/test/support/__init__.py", line 1525, in inner return func(*args, **kwds) File "/home/rdmurray/python/p34/Lib/test/test_email/test_utils.py", line 145, in test_formatdate self.assertEqual(string, 'Mon, 01 Dec 2014 15:00:00 -0000') AssertionError: 'Mon, 01 Dec 2014 14:00:00 -0000' != 'Mon, 01 Dec 2014 15:00:00 -0000' - Mon, 01 Dec 2014 14:00:00 -0000 ? ^ + Mon, 01 Dec 2014 15:00:00 -0000 ? ^ ====================================================================== FAIL: test_formatdate_with_localtime (test.test_email.test_utils.FormatDateTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/rdmurray/python/p34/Lib/test/support/__init__.py", line 1525, in inner return func(*args, **kwds) File "/home/rdmurray/python/p34/Lib/test/test_email/test_utils.py", line 157, in test_formatdate_with_localtime self.assertEqual(string, 'Mon, 01 Dec 2014 18:00:00 +0300') AssertionError: 'Mon, 01 Dec 2014 18:00:00 +0400' != 'Mon, 01 Dec 2014 18:00:00 +0300' - Mon, 01 Dec 2014 18:00:00 +0400 ? ^ + Mon, 01 Dec 2014 18:00:00 +0300 ? ^ ---------- components: +email _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 06:57:30 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 13 Jan 2015 05:57:30 +0000 Subject: [issue10552] Tools/unicode/gencodec.py error In-Reply-To: <1290889753.14.0.0688566147025.issue10552@psf.upfronthosting.co.za> Message-ID: <1421128650.82.0.569803095028.issue10552@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a new version of Kuchling?s patch. I restored some mapping files which do not give any errors (including the mac_turkish codec, which is actually documented), and removed both readme files. ---------- components: +Unicode nosy: +haypo, vadmium versions: +Python 3.4 Added file: http://bugs.python.org/file37687/10552-remove-apple-files-v2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 08:35:46 2015 From: report at bugs.python.org (Stephen Drake) Date: Tue, 13 Jan 2015 07:35:46 +0000 Subject: [issue23227] Generator's finally block not run if close() called before first iteration Message-ID: <1421134546.13.0.154248882029.issue23227@psf.upfronthosting.co.za> New submission from Stephen Drake: If a generator has its close() method called before any items are requested from it, a finally block in the generator function will not be executed. I encountered this when wrapping an open file to alter the result of iterating over it. Using a generator function with a try/finally block seemed like a simple way of acheiving this. Here's an example that logs each line as it's read: def logged_lines(f): try: for line in f: logging.warning(line.strip()) yield line finally: logging.warning('closing') f.close() If the generator is created and closed immediately, the underlying file-like object is left open: >>> f = urlopen('https://docs.python.org/') >>> lines = logged_lines(f) >>> lines.close() >>> f.closed False But once the first item is requested from the generator, close() will trigger cleanup: >>> lines = logged_lines(f) >>> next(lines) WARNING:root:>> lines.close() WARNING:root:closing >>> f.closed True Having read the documentation for yield expressions, I don't believe this behaviour to be non-conformant - but it still seems like a bit of a gotcha to me. Should this usage be warned against? ---------- assignee: docs at python components: Documentation, Interpreter Core messages: 233903 nosy: docs at python, sjdrake priority: normal severity: normal status: open title: Generator's finally block not run if close() called before first iteration type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 09:18:38 2015 From: report at bugs.python.org (Tim Golden) Date: Tue, 13 Jan 2015 08:18:38 +0000 Subject: [issue22028] Python 3.4.1 Installer ended prematurely (Windows msi) In-Reply-To: <1405994666.12.0.143457311308.issue22028@psf.upfronthosting.co.za> Message-ID: <1421137118.49.0.0500067466265.issue22028@psf.upfronthosting.co.za> Changes by Tim Golden : ---------- assignee: -> tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 09:20:37 2015 From: report at bugs.python.org (Tim Golden) Date: Tue, 13 Jan 2015 08:20:37 +0000 Subject: [issue22028] Python 3.4.1 Installer ended prematurely (Windows msi) In-Reply-To: <1405994666.12.0.143457311308.issue22028@psf.upfronthosting.co.za> Message-ID: <1421137237.32.0.0166725332439.issue22028@psf.upfronthosting.co.za> Tim Golden added the comment: This has just come up again over on python-list: https://mail.python.org/pipermail/python-list/2015-January/696660.html I'm the nearest thing we have to a mimetypes maintainer at least for Windows so I'll try to pick Steve's patch up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 09:24:01 2015 From: report at bugs.python.org (Dmitry Shachnev) Date: Tue, 13 Jan 2015 08:24:01 +0000 Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone constant In-Reply-To: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za> Message-ID: <1421137441.28.0.556363111854.issue22932@psf.upfronthosting.co.za> Dmitry Shachnev added the comment: Can it be that you have outdated tzdata? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 09:28:03 2015 From: report at bugs.python.org (Tim Golden) Date: Tue, 13 Jan 2015 08:28:03 +0000 Subject: [issue23018] Add version info to python[w].exe In-Reply-To: <1418102862.79.0.624047396863.issue23018@psf.upfronthosting.co.za> Message-ID: <1421137683.76.0.588092753691.issue23018@psf.upfronthosting.co.za> Tim Golden added the comment: Steve, could you outline the need / impact for this, please? (ie can you inform my ignorance?). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 09:55:02 2015 From: report at bugs.python.org (Michael Vogt) Date: Tue, 13 Jan 2015 08:55:02 +0000 Subject: [issue23228] Crashes when tarfile contains a symlink and unpack directory contain it too Message-ID: <1421139302.16.0.710158118765.issue23228@psf.upfronthosting.co.za> New submission from Michael Vogt: The tarfile.makelink() code crashes with a maximum recursion error when it unpacks a tarfile that contains a symlink into a directory that already contains this symlink. Attached is a standalone testcase (that probably better explains whats going on :) and a possible fix. ---------- components: Library (Lib) files: tarfile-extract-crash.py messages: 233907 nosy: mvo priority: normal severity: normal status: open title: Crashes when tarfile contains a symlink and unpack directory contain it too type: crash Added file: http://bugs.python.org/file37688/tarfile-extract-crash.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 10:01:51 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 13 Jan 2015 09:01:51 +0000 Subject: [issue23209] asyncio: break some cycles In-Reply-To: <1420823775.21.0.0191485458241.issue23209@psf.upfronthosting.co.za> Message-ID: <20150113090147.125896.33759@psf.io> Roundup Robot added the comment: New changeset 1544bdc409be by Victor Stinner in branch '3.4': Issue #23209, #23225: selectors.BaseSelector.close() now clears its internal https://hg.python.org/cpython/rev/1544bdc409be New changeset 6e7403bc906f by Victor Stinner in branch 'default': Issue #23209, #23225: selectors.BaseSelector.get_key() now raises a https://hg.python.org/cpython/rev/6e7403bc906f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 10:01:51 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 13 Jan 2015 09:01:51 +0000 Subject: [issue23225] selectors: raise an exception if the selector is closed In-Reply-To: <1421060761.71.0.41386603707.issue23225@psf.upfronthosting.co.za> Message-ID: <20150113090147.125896.98433@psf.io> Roundup Robot added the comment: New changeset 1544bdc409be by Victor Stinner in branch '3.4': Issue #23209, #23225: selectors.BaseSelector.close() now clears its internal https://hg.python.org/cpython/rev/1544bdc409be New changeset 6e7403bc906f by Victor Stinner in branch 'default': Issue #23209, #23225: selectors.BaseSelector.get_key() now raises a https://hg.python.org/cpython/rev/6e7403bc906f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 10:03:16 2015 From: report at bugs.python.org (Michael Vogt) Date: Tue, 13 Jan 2015 09:03:16 +0000 Subject: [issue23228] Crashes when tarfile contains a symlink and unpack directory contain it too In-Reply-To: <1421139302.16.0.710158118765.issue23228@psf.upfronthosting.co.za> Message-ID: <1421139796.25.0.115542233212.issue23228@psf.upfronthosting.co.za> Michael Vogt added the comment: A possible fix that works with the previous testcase for this bug. It does not break a tarfile tests. ---------- keywords: +patch Added file: http://bugs.python.org/file37689/possible-fix-37688.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 10:07:03 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Jan 2015 09:07:03 +0000 Subject: [issue23225] selectors: raise an exception if the selector is closed In-Reply-To: <1421060761.71.0.41386603707.issue23225@psf.upfronthosting.co.za> Message-ID: <1421140023.73.0.77973243776.issue23225@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, I forgot Python 3.4. Changing the behaviour of get_key() in a minor Python version (3.4.x) would break the compatibility. I used Martin Richard's patch for Python 3.4: raise a KeyError if the selector is closed. I commit my change to Python 3.5 and Tulip. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 10:07:09 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Jan 2015 09:07:09 +0000 Subject: [issue23225] selectors: raise an exception if the selector is closed In-Reply-To: <1421060761.71.0.41386603707.issue23225@psf.upfronthosting.co.za> Message-ID: <1421140029.55.0.795451697496.issue23225@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 10:07:12 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Jan 2015 09:07:12 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1421102491.06.0.980164721067.issue23185@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Guido van Rossum added the comment: > Should inf and nan be added to cmath too? It has e and pi and isnan() and isinf()... > > Also complex(0, math.nan) a value that is printed as "nanj" and complex("nanj") parses and returns such a value, so the point could be made that there should be a constant named complex.nanj. Since it's a different module and we are talking about more and different constants, I suggest to open a new issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 10:07:44 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Jan 2015 09:07:44 +0000 Subject: [issue23209] asyncio: break some cycles In-Reply-To: <1420823775.21.0.0191485458241.issue23209@psf.upfronthosting.co.za> Message-ID: <1421140064.15.0.487884029791.issue23209@psf.upfronthosting.co.za> STINNER Victor added the comment: I closed the issue #23225, so I'm also closing this issue. Thanks again Martin. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 10:10:57 2015 From: report at bugs.python.org (Michael Vogt) Date: Tue, 13 Jan 2015 09:10:57 +0000 Subject: [issue23228] Crashes when tarfile contains a symlink and unpack directory contain it too In-Reply-To: <1421139302.16.0.710158118765.issue23228@psf.upfronthosting.co.za> Message-ID: <1421140257.65.0.630965665398.issue23228@psf.upfronthosting.co.za> Michael Vogt added the comment: This patch contains a regression test as well. ---------- Added file: http://bugs.python.org/file37690/possible-fix-23228-with-test.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 10:11:55 2015 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Tue, 13 Jan 2015 09:11:55 +0000 Subject: [issue23193] Please support "numeric_owner" in tarfile In-Reply-To: <1420728144.57.0.872420723687.issue23193@psf.upfronthosting.co.za> Message-ID: <1421140315.27.0.98204965225.issue23193@psf.upfronthosting.co.za> Lars Gust?bel added the comment: I would argue that a serious alternative to this patch is to simply override the TarFile.chown() method in a subclass. However, I'm not sure if this expects too much of the user. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 10:25:15 2015 From: report at bugs.python.org (Dainis Jonitis) Date: Tue, 13 Jan 2015 09:25:15 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1421141115.32.0.200866683942.issue1602@psf.upfronthosting.co.za> Dainis Jonitis added the comment: Drekins module at https://github.com/Drekin/win-unicode-console is great, but there is small issue with it when running within debugger in Visual Studio (Python Tools for Visual Studio 2.1 installed). Debugger already wraps stdout and stderr inside the visualstudio_py_debugger._DebuggerOutput wrapper and it does not have the fileno() method which win-unicode-console stream.py check_stream() expects. I've created potential fix for it at https://github.com/Drekin/win-unicode-console/pull/4/commits that checks whether object has old_out and uses it to get to fileno. There might be much more robust ways to check for wrappers. I just wanted to make you aware, if this code will be used as basis for Python 3.5. ---------- nosy: +Jonitis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 10:35:45 2015 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 13 Jan 2015 09:35:45 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> Message-ID: <1421141745.31.0.312764152931.issue23185@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Should inf and nan be added to cmath too? Hmm; probably, yes. I'll open an issue. > so the point could be made that there should be a constant named complex.nanj Yes, I suppose it could (along with infj, of course). I don't like it much, and I suspect it would get almost no uses. complex(0, inf) and complex(0, nan) seem like good enough spellings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 10:36:36 2015 From: report at bugs.python.org (SilentGhost) Date: Tue, 13 Jan 2015 09:36:36 +0000 Subject: [issue23228] Crashes when tarfile contains a symlink and unpack directory contain it too In-Reply-To: <1421139302.16.0.710158118765.issue23228@psf.upfronthosting.co.za> Message-ID: <1421141796.06.0.986274921856.issue23228@psf.upfronthosting.co.za> SilentGhost added the comment: Perhaps I'm missing something here, but it doesn't seem to be a problem with valid links. Only invalid symlinks are causing this issue. ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 10:37:07 2015 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 13 Jan 2015 09:37:07 +0000 Subject: [issue23229] add inf and nan to cmath module Message-ID: <1421141827.81.0.668754742456.issue23229@psf.upfronthosting.co.za> New submission from Mark Dickinson: As pointed out by Guido in issue 23185, the constants `inf` and `nan` should be added to the cmath module, too. ---------- assignee: mark.dickinson components: Extension Modules messages: 233919 nosy: mark.dickinson priority: normal severity: normal status: open title: add inf and nan to cmath module type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 10:37:33 2015 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 13 Jan 2015 09:37:33 +0000 Subject: [issue23185] add inf and nan to math module In-Reply-To: <1420648424.37.0.39763409052.issue23185@psf.upfronthosting.co.za> Message-ID: <1421141853.83.0.759496620312.issue23185@psf.upfronthosting.co.za> Mark Dickinson added the comment: Opened issue #23229. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 10:37:43 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Jan 2015 09:37:43 +0000 Subject: [issue23229] add inf and nan to cmath module In-Reply-To: <1421141827.81.0.668754742456.issue23229@psf.upfronthosting.co.za> Message-ID: <1421141863.55.0.762933183473.issue23229@psf.upfronthosting.co.za> STINNER Victor added the comment: What about cmath.nanj? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 10:38:14 2015 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 13 Jan 2015 09:38:14 +0000 Subject: [issue23229] add inf and nan to cmath module In-Reply-To: <1421141827.81.0.668754742456.issue23229@psf.upfronthosting.co.za> Message-ID: <1421141894.78.0.698359588388.issue23229@psf.upfronthosting.co.za> Mark Dickinson added the comment: Guido also says: """ Also complex(0, math.nan) a value that is printed as "nanj" and complex("nanj") parses and returns such a value, so the point could be made that there should be a constant named complex.nanj. """ ... and the same comments would apply to "infj". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 10:38:47 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Jan 2015 09:38:47 +0000 Subject: [issue23229] add inf and nan to cmath module In-Reply-To: <1421141827.81.0.668754742456.issue23229@psf.upfronthosting.co.za> Message-ID: <1421141927.9.0.283093674708.issue23229@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, there is also infj: >>> complex(0, float("inf")) infj >>> complex("infj") infj >>> complex(0, float("nan")) nanj >>> complex("nanj") nanj ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 10:39:03 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Jan 2015 09:39:03 +0000 Subject: [issue23229] add inf, nan, infj, nanj to cmath module In-Reply-To: <1421141827.81.0.668754742456.issue23229@psf.upfronthosting.co.za> Message-ID: <1421141943.75.0.116449364503.issue23229@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: add inf and nan to cmath module -> add inf, nan, infj, nanj to cmath module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 10:39:41 2015 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 13 Jan 2015 09:39:41 +0000 Subject: [issue23229] add inf, nan, infj, nanj to cmath module In-Reply-To: <1421141827.81.0.668754742456.issue23229@psf.upfronthosting.co.za> Message-ID: <1421141981.23.0.529393305279.issue23229@psf.upfronthosting.co.za> Mark Dickinson added the comment: @haypo: I'm not keen on either of infj or nanj, on a YAGNI basis. I expect they'd be used almost never, and for the few times that they're really needed, complex(0, inf) and complex(0, nan) seem like good enough spellings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 10:40:37 2015 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 13 Jan 2015 09:40:37 +0000 Subject: [issue23229] add inf, nan, infj, nanj to cmath module In-Reply-To: <1421141827.81.0.668754742456.issue23229@psf.upfronthosting.co.za> Message-ID: <1421142037.94.0.646496705033.issue23229@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 10:56:11 2015 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 13 Jan 2015 09:56:11 +0000 Subject: [issue23229] add inf, nan, infj, nanj to cmath module In-Reply-To: <1421141827.81.0.668754742456.issue23229@psf.upfronthosting.co.za> Message-ID: <1421142971.42.0.439987776722.issue23229@psf.upfronthosting.co.za> Mark Dickinson added the comment: Note: following the precedent of cmath.e and cmath.pi, cmath.nan and cmath.inf should have type *float*. Let's not get into the business of deciding *which* complex infinities and nans to represent. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 10:59:20 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 13 Jan 2015 09:59:20 +0000 Subject: [issue23229] add inf, nan, infj, nanj to cmath module In-Reply-To: <1421141827.81.0.668754742456.issue23229@psf.upfronthosting.co.za> Message-ID: <1421143160.19.0.639281892576.issue23229@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There are other names which exist only in math, but not in cmath. >>> sorted(set(dir(math)) - set(dir(cmath))) ['atan2', 'ceil', 'copysign', 'degrees', 'erf', 'erfc', 'expm1', 'fabs', 'factorial', 'floor', 'fmod', 'frexp', 'fsum', 'gamma', 'hypot', 'inf', 'ldexp', 'lgamma', 'log1p', 'log2', 'modf', 'nan', 'pow', 'radians', 'trunc'] May be complex equivalents of all functions should be added for the same reasons? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 11:04:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 13 Jan 2015 10:04:57 +0000 Subject: [issue23228] Crashes when tarfile contains a symlink and unpack directory contain it too In-Reply-To: <1421139302.16.0.710158118765.issue23228@psf.upfronthosting.co.za> Message-ID: <1421143497.25.0.962304275552.issue23228@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +lars.gustaebel, serhiy.storchaka stage: -> patch review versions: +Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 11:21:03 2015 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 13 Jan 2015 10:21:03 +0000 Subject: [issue23229] add inf, nan, infj, nanj to cmath module In-Reply-To: <1421141827.81.0.668754742456.issue23229@psf.upfronthosting.co.za> Message-ID: <1421144463.42.0.659138213207.issue23229@psf.upfronthosting.co.za> Mark Dickinson added the comment: > May be complex equivalents of all functions should be added for the same reasons? (1) This is off-topic for this issue; please open a separate one. (2) Many of those functions simply don't make sense for complex numbers (for example floor, degrees, etc.), or it's not obvious how to extend them. For those that do make sense (erf, for example), implementing and testing a library-quality version would take a lot of time and effort, and no-one would be interested in the result. It's not worth it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 13:18:29 2015 From: report at bugs.python.org (Luis G.F) Date: Tue, 13 Jan 2015 12:18:29 +0000 Subject: [issue23230] Bug parsing integers with zero padding Message-ID: <1421151509.05.0.199234609043.issue23230@psf.upfronthosting.co.za> New submission from Luis G.F: Python 3.4 interpreter fail to parse a integer that has zero padding, whereas python 2.7 works properly. Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> int(001) 1 >>> Python 3.4.0 (default, Apr 11 2014, 13:05:11) [GCC 4.8.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> int(001) File "", line 1 int(001) ^ SyntaxError: invalid token >>> ---------- components: Interpreter Core messages: 233928 nosy: luisgf priority: normal severity: normal status: open title: Bug parsing integers with zero padding versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 13:22:18 2015 From: report at bugs.python.org (Geoffrey Spear) Date: Tue, 13 Jan 2015 12:22:18 +0000 Subject: [issue23230] Bug parsing integers with zero padding In-Reply-To: <1421151509.05.0.199234609043.issue23230@psf.upfronthosting.co.za> Message-ID: <1421151738.58.0.68214836769.issue23230@psf.upfronthosting.co.za> Geoffrey Spear added the comment: This is not a bug, it's a deliberate change. Python 2.x doesn't "work correctly"; what you have there is an octal literal, not a 0-padded base-10 integer. Try 008 or 011 and be surprised that python 2 is "broken" and you'll see why this syntax was removed. ---------- nosy: +geoffreyspear _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 13:31:16 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 13 Jan 2015 12:31:16 +0000 Subject: [issue20739] PEP 463 (except expression) implementation In-Reply-To: <1393113417.21.0.308711390279.issue20739@psf.upfronthosting.co.za> Message-ID: <1421152276.51.0.932783301377.issue20739@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 13:45:18 2015 From: report at bugs.python.org (Luis G.F) Date: Tue, 13 Jan 2015 12:45:18 +0000 Subject: [issue23230] Bug parsing integers with zero padding In-Reply-To: <1421151509.05.0.199234609043.issue23230@psf.upfronthosting.co.za> Message-ID: <1421153118.33.0.563505907232.issue23230@psf.upfronthosting.co.za> Luis G.F added the comment: Thanks for the response, but in my case, 001 is not an octal literal, is a base-10 zero padded comming from the parsing of a ip string like 111.000.222.333 , where numbers are all integers in base-10. The solution for parsing that seams to cast 000 as string and then using int('000', base=10). ---------- resolution: -> not a bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 13:47:31 2015 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 13 Jan 2015 12:47:31 +0000 Subject: [issue22028] Python 3.4.1 Installer ended prematurely (Windows msi) In-Reply-To: <1405994666.12.0.143457311308.issue22028@psf.upfronthosting.co.za> Message-ID: <1421153251.49.0.41291726522.issue22028@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I don't think the installer needs fixing beyond fixing mimetypes. If ensurepip fails, the whole installation ought to fail (IMO); that's the way MSI is supposed to work. It's the same if some other component could not be installed for some reason (permissions, out of disk space, etc): the entire installation gets rolled back. So I disagree with Steve that it would be desirable to let pip installation fail silently. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 13:48:20 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 13 Jan 2015 12:48:20 +0000 Subject: [issue23231] Fix codecs.iterencode/decode() by allowing data parameter to be omitted Message-ID: <1421153299.35.0.701583632763.issue23231@psf.upfronthosting.co.za> New submission from Martin Panter: As mentioned in Issue 20132, iterencode() and iterdecode() only work on text-to-byte codecs, because they assume particular data types when finalizing the incremental codecs. This patch changes the signature of the IncrementalEncoder and IncrementalDecoder methods from IncrementalEncoder.encode(object[, final]) IncrementalEncoder.decode(object[, final]) to IncrementalEncoder.encode([object,] [final]) IncrementalEncoder.decode([object,] [final]) so that iteren/decode(), and perhaps in the future, StreamWriter/Reader, can operate the incremental codec without knowing what kind of data should be processed. ---------- components: Library (Lib), Unicode files: final-no-object.patch keywords: patch messages: 233932 nosy: ezio.melotti, haypo, vadmium priority: normal severity: normal status: open title: Fix codecs.iterencode/decode() by allowing data parameter to be omitted type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file37691/final-no-object.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 13:50:06 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 13 Jan 2015 12:50:06 +0000 Subject: [issue23231] Fix codecs.iterencode/decode() by allowing data parameter to be omitted In-Reply-To: <1421153299.35.0.701583632763.issue23231@psf.upfronthosting.co.za> Message-ID: <1421153406.43.0.438397187281.issue23231@psf.upfronthosting.co.za> Martin Panter added the comment: Original patch has lots of whitespace changes, probably due to generated codec code not being regenerated for a long time. This diff ignores the space changes, so should be easier to review. ---------- Added file: http://bugs.python.org/file37692/final-no-object.ignore-space.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 14:08:25 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 13 Jan 2015 13:08:25 +0000 Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone constant In-Reply-To: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za> Message-ID: <1421154505.79.0.810292473012.issue22932@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, that's possible. I will check. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 14:10:38 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 13 Jan 2015 13:10:38 +0000 Subject: [issue23193] Please support "numeric_owner" in tarfile In-Reply-To: <1420728144.57.0.872420723687.issue23193@psf.upfronthosting.co.za> Message-ID: <1421154638.04.0.363213649275.issue23193@psf.upfronthosting.co.za> R. David Murray added the comment: If it weren't for the fact that this feature is something that the tar command provides, I'd agree (the chown method is relatively short). However, since tar *does* provide this feature, it seems reasonable for us to support it as well. Call me +0.5 :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 14:12:06 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 13 Jan 2015 13:12:06 +0000 Subject: [issue23227] Generator's finally block not run if close() called before first iteration In-Reply-To: <1421134546.13.0.154248882029.issue23227@psf.upfronthosting.co.za> Message-ID: <1421154726.39.0.350630045027.issue23227@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 14:13:37 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 13 Jan 2015 13:13:37 +0000 Subject: [issue23230] Bug parsing integers with zero padding In-Reply-To: <1421151509.05.0.199234609043.issue23230@psf.upfronthosting.co.za> Message-ID: <1421154817.74.0.1892739666.issue23230@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 14:36:00 2015 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 13 Jan 2015 13:36:00 +0000 Subject: [issue23193] Please support "numeric_owner" in tarfile In-Reply-To: <1420728144.57.0.872420723687.issue23193@psf.upfronthosting.co.za> Message-ID: <1421156160.66.0.800352391981.issue23193@psf.upfronthosting.co.za> Eric V. Smith added the comment: I don't think we want to encourage the type of coupling that arises from subclassing, especially when when overriding an undocumented method. I'm +1 on the change. I'll review the patch. Michael: can you write the tests, and hopefully docs? ---------- stage: patch review -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 15:06:06 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 13 Jan 2015 14:06:06 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1421157966.69.0.488749335617.issue1602@psf.upfronthosting.co.za> Steve Dower added the comment: It sounds like the script should handle the case where someone has already changed stdout better. We wrap the streams in PTVS so we can forward the output into the IDE where Unicode will display properly anyway. Our wrapper missing fileno is a bug in our side, but finding the original one will break output forwarding. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 15:20:46 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 13 Jan 2015 14:20:46 +0000 Subject: [issue23221] "a(n) the", "the a(n)" typos In-Reply-To: <1420940360.26.0.834732182943.issue23221@psf.upfronthosting.co.za> Message-ID: <20150113142038.125908.2355@psf.io> Roundup Robot added the comment: New changeset b168c41f2e3f by Benjamin Peterson in branch '3.4': fix instances of consecutive articles (closes #23221) https://hg.python.org/cpython/rev/b168c41f2e3f New changeset 6a19e37ce94d by Benjamin Peterson in branch '2.7': fix instances of consecutive articles (closes #23221) https://hg.python.org/cpython/rev/6a19e37ce94d New changeset c16b76c7c8ba by Benjamin Peterson in branch 'default': merge 3.4 (#23221) https://hg.python.org/cpython/rev/c16b76c7c8ba ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 15:26:06 2015 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 13 Jan 2015 14:26:06 +0000 Subject: [issue23193] Please support "numeric_owner" in tarfile In-Reply-To: <1420728144.57.0.872420723687.issue23193@psf.upfronthosting.co.za> Message-ID: <1421159166.34.0.406364390754.issue23193@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- assignee: -> eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 15:52:15 2015 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 13 Jan 2015 14:52:15 +0000 Subject: [issue23193] Please support "numeric_owner" in tarfile In-Reply-To: <1420728144.57.0.872420723687.issue23193@psf.upfronthosting.co.za> Message-ID: <1421160735.74.0.100480479923.issue23193@psf.upfronthosting.co.za> Eric V. Smith added the comment: Ignore my review comment on pwd and grp being None. I see that there is a test for it (at least grp), and they're not available on Windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 16:04:27 2015 From: report at bugs.python.org (Jan Kaliszewski) Date: Tue, 13 Jan 2015 15:04:27 +0000 Subject: [issue23232] 'codecs' module functionality + its docs -- concerning custom codecs, especially non-string ones Message-ID: <1421161467.08.0.0207328104239.issue23232@psf.upfronthosting.co.za> New submission from Jan Kaliszewski: To some extent, this issue is a follow-up of Issue 20132. It concerns some parts of functionality + documentation of the 'codecs' module related to registering custom codecs, especially non-string ones (i.e., codecs that encode/decode between arbitrary types, not necessarily the str and bytes types). A few fragments of documented behaviour and/or documentation itself bother me: 0. Ad "7.2.1. Codec Base Classes" "Each codec has to define four interfaces to make it usable as codec in Python: stateless encoder, stateless decoder, stream reader and stream writer. The stream reader and writers typically reuse the stateless encoder/decoder to implement the file protocols. Codec authors also need to define how the codec will handle encoding and decoding errors." IMHO it is still unclear: a) what is the relation between codecs in this meaning and CodecInfo objects? (especially: CodecInfo contains information about six interfaces, not four) b) How codec authors define "how the codec will handle encoding and decoding errors"? What is relation between this and error handling schemes (defined as generic, not per-codec ones) documented below? 1. Ad "7.2.1.1. Error Handlers" and "codecs.strict_errors(exception)" "'strict' Raise UnicodeError (or a subclass); this is the default. Implemented in strict_errors()." "codecs.strict_errors(exception) Implements the 'strict' error handling: each encoding or decoding error raises a UnicodeError." Is it true that always it is a UnicodeError or its subclass and not just ValueError or its subclass? (as it is described in other fragments of the module documentation). Please note, that 'strict' is documented as a universal (and not e.g. text-encoding-only) error handling scheme. So, what about non-string codecs? 2. Ad "codecs.register_error(name, error_handler)" "For encoding, error_handler will be called with a UnicodeEncodeError instance..." "Decoding and translating works similarly, except UnicodeDecodeError or UnicodeTranslateError will be passed..." Again: what about non-string codecs? UnicodeError subclasses do not seem to be appropriate for them. 3. It would be nice to address the Zoinkity's concerns from the Issue 20132 (partially related to the above points): """ One glaring omission is any information about multibyte codecs--the class, its methods, and how to even define one. Also, the primary use for codecs.register would be to append a single codec to the lookup registry. Simple usage of the method only provides lookup for the provided codecs and will not include regularly-accessible ones such as "utf-8". It would be enormously helpful to provide an example of proper, safe usage. """ ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 233940 nosy: docs at python, zuo priority: normal severity: normal status: open title: 'codecs' module functionality + its docs -- concerning custom codecs, especially non-string ones versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 16:07:44 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 13 Jan 2015 15:07:44 +0000 Subject: [issue23228] Crashes when tarfile contains a symlink and unpack directory contain it too In-Reply-To: <1421139302.16.0.710158118765.issue23228@psf.upfronthosting.co.za> Message-ID: <1421161664.11.0.389034191947.issue23228@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 16:08:39 2015 From: report at bugs.python.org (Jan Kaliszewski) Date: Tue, 13 Jan 2015 15:08:39 +0000 Subject: [issue23232] 'codecs' module functionality + its docs -- concerning custom codecs, especially non-string ones In-Reply-To: <1421161467.08.0.0207328104239.issue23232@psf.upfronthosting.co.za> Message-ID: <1421161719.84.0.346276052277.issue23232@psf.upfronthosting.co.za> Jan Kaliszewski added the comment: Sorry, s/Issue 20132/Issue 19548/g Issue 20132 is also related somehow, but here I ment that this is a follow-up of Issue 19548; and Zoinkity's concerns I cited are also from Issue 19548, and not from 20132. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 16:19:51 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Jan 2015 15:19:51 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1421162391.98.0.819395372224.issue22038@psf.upfronthosting.co.za> STINNER Victor added the comment: I reopen the issue because Python cannot be compiled anymore on the Builder AMD64 FreeBSD 10.0 3.x: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x/builds/2947/steps/configure/logs/stdio checking for stdatomic.h... yes checking for GCC >= 4.7 __atomic builtins... yes http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x/builds/2947/steps/compile/logs/stdio --- Parser/tokenizer_pgen.o --- In file included from Parser/tokenizer_pgen.c:2: In file included from Parser/tokenizer.c:4: In file included from Include/Python.h:53: Include/pyatomic.h:37:5: error: _Atomic cannot be applied to incomplete type 'void' _Atomic void *_value; ^ ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 16:26:28 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 13 Jan 2015 15:26:28 +0000 Subject: [issue22922] asyncio: call_soon() should raise an exception if the event loop is closed In-Reply-To: <1416735123.89.0.671272792173.issue22922@psf.upfronthosting.co.za> Message-ID: <20150113151506.11565.24558@psf.io> Roundup Robot added the comment: New changeset 6c473f82309d by Victor Stinner in branch '3.4': Issue #22922: Fix ProactorEventLoop.close() https://hg.python.org/cpython/rev/6c473f82309d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 16:27:48 2015 From: report at bugs.python.org (Gustavo Temple) Date: Tue, 13 Jan 2015 15:27:48 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1421162868.56.0.0908741381584.issue22038@psf.upfronthosting.co.za> Gustavo Temple added the comment: @haypo, OK, I will investigate the problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 17:12:45 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Jan 2015 16:12:45 +0000 Subject: [issue22919] Update PCBuild for VS 2015 In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za> Message-ID: <1421165565.74.0.849486276333.issue22919@psf.upfronthosting.co.za> STINNER Victor added the comment: > You will need Windows 7 *SP1* I do have Windows 7 SP1. > There is also a service pack for VS 2010 that may enable opening the newer solution - it certainly worked for me. Oh, I also worked for me. I have VS 2010 *Express* and I'm now able to open the project after installing the Service Pack 1 of VS 2010. Note: The binary (in debug mode) moved from PCbuild\python_d.exe to PCbuild\win32\python_d.exe ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 17:17:03 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 13 Jan 2015 16:17:03 +0000 Subject: [issue22919] Update PCBuild for VS 2015 In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za> Message-ID: <1421165823.78.0.464412552408.issue22919@psf.upfronthosting.co.za> Steve Dower added the comment: > I do have Windows 7 SP1. I expected so, but didn't want to assume. > I have VS 2010 *Express* and I'm now able to open the project after installing the Service Pack 1 of VS 2010. Glad to hear it. You made me a little nervous there :) (I don't feel like requiring VS 2010 SP1 is unreasonable, but I could be wrong... not sure there's any sensible way to support VS 2010 RTM though.) > Note: The binary (in debug mode) moved from PCbuild\python_d.exe to PCbuild\win32\python_d.exe Yes, that was always a pet peeve of mine, but I got big thanks from the other Windows nosy list for making that move. At this point, everything should be okay with the new location, but if there are any more issues just let me know and I'll check them out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 17:19:51 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 13 Jan 2015 16:19:51 +0000 Subject: [issue23018] Add version info to python[w].exe In-Reply-To: <1418102862.79.0.624047396863.issue23018@psf.upfronthosting.co.za> Message-ID: <1421165991.79.0.493044754898.issue23018@psf.upfronthosting.co.za> Steve Dower added the comment: Sure :) If you view Properties in Windows for Python 3.4's python[w].exe and look at the Details tab, it's very blank (for me it shows 'Application', the size and the modification date). However, if you look at python34.dll or py.exe it has a description, version, copyright message, etc. The first part of the patch adds this information to python[w].exe as well. The second part is dealing with #19143, which is where GetVersion() lies about the Windows version if you haven't explicitly declared that you know about that version. Currently on Windows 8.1 (and 10), sys.getwindowsversion() will tell you that it's Windows 8 (6.2.9200). The patch here adds the declarations to a manifest file such that Python 3.5 is "aware" of Windows 8.1 and so it doesn't need the compatibility shims/version lies that are otherwise applied. (The patch on #19143 is for the platform module so that it will always read the correct version, but this is intended for logging/system info rather than making decisions about API availability and behaviour.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 17:30:52 2015 From: report at bugs.python.org (Nikolaus Rath) Date: Tue, 13 Jan 2015 16:30:52 +0000 Subject: [issue15955] gzip, bz2, lzma: add option to limit output size In-Reply-To: <1421020658.17.0.0728806258562.issue15955@psf.upfronthosting.co.za> (Martin Panter's message of "Sun, 11 Jan 2015 23:57:38 +0000") Message-ID: <87d26i8wy1.fsf@kosh.rath.org> Nikolaus Rath added the comment: Martin Panter writes: > We still need a patch for max_length in BZ2Decompressor, and to use it > in BZ2File. I'm still quite interested to do this. The only reason I haven't done it yet is that I'm waiting for the LZMA patch to be reviewed and committed first (no need to make any mistakes twice). Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F ?Time flies like an arrow, fruit flies like a Banana.? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 17:46:12 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 13 Jan 2015 16:46:12 +0000 Subject: [issue23229] add inf, nan, infj, nanj to cmath module In-Reply-To: <1421142971.42.0.439987776722.issue23229@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > Note: following the precedent of cmath.e and cmath.pi, cmath.nan and cmath.inf should have type *float*. Let's not get into the business of deciding *which* complex infinities and nans to represent. Agreed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 17:53:20 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 13 Jan 2015 16:53:20 +0000 Subject: [issue23229] add inf, nan, infj, nanj to cmath module In-Reply-To: Message-ID: Guido van Rossum added the comment: Note, the reason I proposed nanj (and infj) is that these are produced by repr() of complex numbers. Having them in the cmath module provides a place to document them which will then be searchable. On Tue, Jan 13, 2015 at 8:46 AM, Guido van Rossum wrote: > > Guido van Rossum added the comment: > > > Note: following the precedent of cmath.e and cmath.pi, cmath.nan and > cmath.inf should have type *float*. Let's not get into the business of > deciding *which* complex infinities and nans to represent. > > Agreed. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 18:17:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 13 Jan 2015 17:17:59 +0000 Subject: [issue23229] add inf, nan, infj, nanj to cmath module In-Reply-To: <1421141827.81.0.668754742456.issue23229@psf.upfronthosting.co.za> Message-ID: <1421169479.83.0.200647704839.issue23229@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Note, the reason I proposed nanj (and infj) is that these are produced by > repr() of complex numbers. Having them in the cmath module provides a place > to document them which will then be searchable. Another solution would be to change repr() of complex if imaginary component is not finite number to the form complex(x, y). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 18:27:32 2015 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 13 Jan 2015 17:27:32 +0000 Subject: [issue23229] add inf, nan, infj, nanj to cmath module In-Reply-To: <1421141827.81.0.668754742456.issue23229@psf.upfronthosting.co.za> Message-ID: <1421170052.47.0.603843069146.issue23229@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Having them in the cmath module provides a place to document them which will then be searchable. Okay, makes sense. One of the reasons I'm a bit unhappy with the idea of adding infj and nanj is that it seems like an encouragement to expect "eval(repr(z))" to work (i.e., recover the original value of z), and because Python doesn't have strict imaginary numbers (i.e., numbers with no real part at all), that fails: >>> from math import inf, nan >>> infj = complex(0.0, inf) >>> nanj = complex(0.0, nan) >>> z = complex(0.0, -inf) >>> w = eval(repr(z)) >>> z -infj >>> w # real part has the "wrong" sign (-0-infj) But that's a pretty hollow objection, because this really has nothing to do with inf and nan; it's a problem with finite values, too: >>> z = complex(0.0, -3.4) >>> w = eval(repr(z)) >>> z -3.4j >>> w (-0-3.4j) So I'll add infj and nanj if the consensus is that they're useful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 18:31:36 2015 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 13 Jan 2015 17:31:36 +0000 Subject: [issue23229] add inf, nan, infj, nanj to cmath module In-Reply-To: <1421141827.81.0.668754742456.issue23229@psf.upfronthosting.co.za> Message-ID: <1421170296.96.0.0433106714257.issue23229@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Another solution would be to change repr() of complex if imaginary > component is not finite number to the form complex(x, y). That wouldn't help with the str(), though, unless you're proposing to change that, too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 19:08:37 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 13 Jan 2015 18:08:37 +0000 Subject: [issue23229] add inf, nan, infj, nanj to cmath module In-Reply-To: <1421170052.47.0.603843069146.issue23229@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I don't understand why w ends up having -0 as the real part. For floats, at least, we've done a lot of work to make eval(repr()) roundtrip correctly in all cases. Is the issue with complex superficial (we should fix eval or repr) or deep (if we fixed it something else would be broken)? On Tue, Jan 13, 2015 at 9:27 AM, Mark Dickinson wrote: > > Mark Dickinson added the comment: > > > Having them in the cmath module provides a place > to document them which will then be searchable. > > Okay, makes sense. > > One of the reasons I'm a bit unhappy with the idea of adding infj and nanj > is that it seems like an encouragement to expect "eval(repr(z))" to work > (i.e., recover the original value of z), and because Python doesn't have > strict imaginary numbers (i.e., numbers with no real part at all), that > fails: > > >>> from math import inf, nan > >>> infj = complex(0.0, inf) > >>> nanj = complex(0.0, nan) > >>> z = complex(0.0, -inf) > >>> w = eval(repr(z)) > >>> z > -infj > >>> w # real part has the "wrong" sign > (-0-infj) > > But that's a pretty hollow objection, because this really has nothing to > do with inf and nan; it's a problem with finite values, too: > > >>> z = complex(0.0, -3.4) > >>> w = eval(repr(z)) > >>> z > -3.4j > >>> w > (-0-3.4j) > > So I'll add infj and nanj if the consensus is that they're useful. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 19:33:52 2015 From: report at bugs.python.org (Gustavo Temple) Date: Tue, 13 Jan 2015 18:33:52 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1421174032.12.0.114123543059.issue22038@psf.upfronthosting.co.za> Changes by Gustavo Temple : Added file: http://bugs.python.org/file37693/atomicv4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 19:37:25 2015 From: report at bugs.python.org (Gustavo Temple) Date: Tue, 13 Jan 2015 18:37:25 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1421174245.21.0.0648350058815.issue22038@psf.upfronthosting.co.za> Changes by Gustavo Temple : Removed file: http://bugs.python.org/file37693/atomicv4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 19:51:09 2015 From: report at bugs.python.org (Gustavo Temple) Date: Tue, 13 Jan 2015 18:51:09 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1421175069.24.0.729464926669.issue22038@psf.upfronthosting.co.za> Changes by Gustavo Temple : Added file: http://bugs.python.org/file37694/atomicv4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 19:53:21 2015 From: report at bugs.python.org (Gustavo Temple) Date: Tue, 13 Jan 2015 18:53:21 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1421175201.45.0.867847834255.issue22038@psf.upfronthosting.co.za> Gustavo Temple added the comment: @haypo, done: atomicv4.patch ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 19:56:47 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 13 Jan 2015 18:56:47 +0000 Subject: [issue23229] add inf, nan, infj, nanj to cmath module In-Reply-To: <1421141827.81.0.668754742456.issue23229@psf.upfronthosting.co.za> Message-ID: <1421175407.31.0.341031325484.issue23229@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I don't understand why w ends up having -0 as the real part. Because "-3.4j" is interpreted as "-complex(0, 3.4)". ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 20:24:20 2015 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 13 Jan 2015 19:24:20 +0000 Subject: [issue23229] add inf, nan, infj, nanj to cmath module In-Reply-To: <1421141827.81.0.668754742456.issue23229@psf.upfronthosting.co.za> Message-ID: <1421177060.71.0.443537061029.issue23229@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Is the issue with complex superficial Unfortunately not: something like this is fairly inescapable. The problem is that when you do (for example) 5 - 6j you're in effect subtracting complex(0.0, 6.0) from complex(5.0, 0.0): you've invented a real part of 0.0 for the second term and an imaginary part of 0.0 for the first term. And since 0.0 is *not* an identity for addition (-0.0 + 0.0 is 0.0, not -0.0, under the usual rounding modes), signs of zeros tend to get lost. So the safe way to construct a complex number is to avoid any actual arithmetic by using complex(real_part, imag_part) rather than real_part + imag_part*1j. I rather like Serhiy's idea of making the complex repr have this form, except that the change would probably break existing code. (And the str should really stay in the current expected human-readable format, so the problems with infj and nanj don't go away.) Another possible "fix" is to introduce a new 'imaginary' type, such that the type of an imaginary literal is now 'imaginary' rather than 'complex', and arithmetic operations like addition can special-case the addition of a float to an 'imaginary' instance to produce a complex number with exactly the right bits. The C standardisation folks already tried this: C99 introduces optional "imaginary" types and a new _Imaginary keyword, but last time I looked almost none of the popular compilers supported those types. (I think Intel's icc might be an exception.) While this works as a technical solution, IMO the cure is worse than the disease; I don't want to think about the user-confusion that would result from having separate "complex" and "imaginary" types. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 20:27:42 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Jan 2015 19:27:42 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1421175201.45.0.867847834255.issue22038@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Can you please generate a patch for the default branch of Python? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 20:28:00 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 13 Jan 2015 19:28:00 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1421177280.91.0.854341676557.issue22038@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: Gustavo Temple: A patch against newest revision of default branch would be more useful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 20:30:53 2015 From: report at bugs.python.org (Gustavo Temple) Date: Tue, 13 Jan 2015 19:30:53 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1421177453.99.0.27021806588.issue22038@psf.upfronthosting.co.za> Gustavo Temple added the comment: OK, I will do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 20:33:04 2015 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 13 Jan 2015 19:33:04 +0000 Subject: [issue23230] Bug parsing integers with zero padding In-Reply-To: <1421151509.05.0.199234609043.issue23230@psf.upfronthosting.co.za> Message-ID: <1421177584.35.0.60889859111.issue23230@psf.upfronthosting.co.za> Mark Dickinson added the comment: > is a base-10 zero padded comming from the parsing of a ip string If you're parsing an ip string, how do you end up with a 000 *literal*? The SyntaxError only applies to literals in Python code; it doesn't affect conversion from strings to integers. So you don't need the "base=10" keyword: the following works in both Python 2 and Python 3. >>> int("000") 0 >>> int("0019") 19 ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 20:38:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 13 Jan 2015 19:38:00 +0000 Subject: [issue23229] add inf, nan, infj, nanj to cmath module In-Reply-To: <1421141827.81.0.668754742456.issue23229@psf.upfronthosting.co.za> Message-ID: <1421177880.98.0.273107629303.issue23229@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Another possible "fix" is to introduce a new 'imaginary' type, such that the type of an imaginary literal is now 'imaginary' rather than 'complex', and arithmetic operations like addition can special-case the addition of a float to an 'imaginary' instance to produce a complex number with exactly the right bits. The C standardisation folks already tried this: C99 introduces optional "imaginary" types and a new _Imaginary keyword, but last time I looked almost none of the popular compilers supported those types. (I think Intel's icc might be an exception.) While this works as a technical solution, IMO the cure is worse than the disease; I don't want to think about the user-confusion that would result from having separate "complex" and "imaginary" types. This type should exist only at compile time. Peephole optimizer should replace it with complex after folding constants. Or may be repr() (and str()) should keep zero real part if imaginary part is negative and output period if real part is zero. For now: >>> z = complex(0.0, 3.4); z; eval(repr(z)) 3.4j 3.4j >>> z = complex(0.0, -3.4); z; eval(repr(z)) -3.4j (-0-3.4j) >>> z = complex(-0.0, 3.4); z; eval(repr(z)) (-0+3.4j) 3.4j >>> z = complex(-0.0, -3.4); z; eval(repr(z)) (-0-3.4j) -3.4j But all this perhaps is offtopic here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 20:42:57 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 13 Jan 2015 19:42:57 +0000 Subject: [issue23229] add inf, nan, infj, nanj to cmath module In-Reply-To: <1421177880.98.0.273107629303.issue23229@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: OK, let's not try to resolve that issue, we can just note it in the docs. BTW I don't want repr() of a complex number to use the complex(..., ...) notation -- it's too verbose. On Tue, Jan 13, 2015 at 11:38 AM, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > > Another possible "fix" is to introduce a new 'imaginary' type, such that > the type of an imaginary literal is now 'imaginary' rather than 'complex', > and arithmetic operations like addition can special-case the addition of a > float to an 'imaginary' instance to produce a complex number with exactly > the right bits. The C standardisation folks already tried this: C99 > introduces optional "imaginary" types and a new _Imaginary keyword, but > last time I looked almost none of the popular compilers supported those > types. (I think Intel's icc might be an exception.) While this works as a > technical solution, IMO the cure is worse than the disease; I don't want to > think about the user-confusion that would result from having separate > "complex" and "imaginary" types. > > This type should exist only at compile time. Peephole optimizer should > replace it with complex after folding constants. > > Or may be repr() (and str()) should keep zero real part if imaginary part > is negative and output period if real part is zero. For now: > > >>> z = complex(0.0, 3.4); z; eval(repr(z)) > 3.4j > 3.4j > >>> z = complex(0.0, -3.4); z; eval(repr(z)) > -3.4j > (-0-3.4j) > >>> z = complex(-0.0, 3.4); z; eval(repr(z)) > (-0+3.4j) > 3.4j > >>> z = complex(-0.0, -3.4); z; eval(repr(z)) > (-0-3.4j) > -3.4j > > But all this perhaps is offtopic here. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 20:52:03 2015 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 13 Jan 2015 19:52:03 +0000 Subject: [issue23229] add inf, nan, infj, nanj to cmath module In-Reply-To: <1421141827.81.0.668754742456.issue23229@psf.upfronthosting.co.za> Message-ID: <1421178723.09.0.764552307197.issue23229@psf.upfronthosting.co.za> Mark Dickinson added the comment: > This type should exist only at compile time. But then after doing "x = 5j", "-0.0 + 5j" and "-0.0 + x" would have different values. Yuck! > repr() (and str()) should keep zero real part if imaginary part is negative and output period if real part is zero Sorry, I don't see how this helps. What do you want the repr of (for example) "complex(-0.0, 5.0)" to be, and why? What about the cases with 0 in the imaginary part? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 20:53:29 2015 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 13 Jan 2015 19:53:29 +0000 Subject: [issue23229] add inf, nan, infj, nanj to cmath module In-Reply-To: <1421141827.81.0.668754742456.issue23229@psf.upfronthosting.co.za> Message-ID: <1421178809.63.0.261915100881.issue23229@psf.upfronthosting.co.za> Mark Dickinson added the comment: > BTW I don't want repr() of a complex number to use the complex(..., ...) notation -- it's too verbose. Okay, fair enough. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 21:18:15 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 13 Jan 2015 20:18:15 +0000 Subject: [issue23233] TypeError in ./setup.py Message-ID: <1421180295.13.0.16794585619.issue23233@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: After updating outdated workspace to current sources I got following error: $ make Traceback (most recent call last): File "./setup.py", line 26, in sysconfig.get_config_vars()['CFLAGS'] = cflags + ' ' + py_cflags_nodist TypeError: Can't convert 'NoneType' object to str implicitly make: *** [sharedmods] Error 1 `make distclean` doesn't help. Here is a patch which fixes symptoms but may be right solution should change something other. ---------- components: Build files: setup_py_cflags_nodist.diff keywords: patch messages: 233966 nosy: serhiy.storchaka priority: normal severity: normal status: open title: TypeError in ./setup.py type: compile error versions: Python 3.5 Added file: http://bugs.python.org/file37695/setup_py_cflags_nodist.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 21:28:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 13 Jan 2015 20:28:23 +0000 Subject: [issue23229] add inf, nan, infj, nanj to cmath module In-Reply-To: <1421141827.81.0.668754742456.issue23229@psf.upfronthosting.co.za> Message-ID: <1421180903.05.0.230235054058.issue23229@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Sorry, I don't see how this helps. What do you want the repr of (for example) "complex(-0.0, 5.0)" to be, and why? What about the cases with 0 in the imaginary part? Ah, it doesn't help in this case. It helps only when the imaginary part is negative. >>> eval('(-0.0-5j)') (-0-5j) >>> eval('(-0-5j)') -5j ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 21:52:12 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 13 Jan 2015 20:52:12 +0000 Subject: [issue23229] add inf, nan, infj, nanj to cmath module In-Reply-To: <1421141827.81.0.668754742456.issue23229@psf.upfronthosting.co.za> Message-ID: <1421182332.33.0.276203294227.issue23229@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 21:54:38 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 13 Jan 2015 20:54:38 +0000 Subject: [issue23232] 'codecs' module functionality + its docs -- concerning custom codecs, especially non-string ones In-Reply-To: <1421161467.08.0.0207328104239.issue23232@psf.upfronthosting.co.za> Message-ID: <1421182478.81.0.463185678778.issue23232@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 22:02:35 2015 From: report at bugs.python.org (Tom Tanner) Date: Tue, 13 Jan 2015 21:02:35 +0000 Subject: [issue21114] wsgiref.simple_server doesn't handle multi-line headers correctly In-Reply-To: <1396285351.75.0.166007035179.issue21114@psf.upfronthosting.co.za> Message-ID: <1421182955.36.0.916327876218.issue21114@psf.upfronthosting.co.za> Tom Tanner added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 22:35:39 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 13 Jan 2015 21:35:39 +0000 Subject: [issue23232] 'codecs' module functionality + its docs -- concerning custom codecs, especially non-string ones In-Reply-To: <1421161467.08.0.0207328104239.issue23232@psf.upfronthosting.co.za> Message-ID: <1421184939.09.0.54963432409.issue23232@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 22:50:03 2015 From: report at bugs.python.org (Zachary Ware) Date: Tue, 13 Jan 2015 21:50:03 +0000 Subject: [issue22919] Update PCBuild for VS 2015 In-Reply-To: <1421165565.74.0.849486276333.issue22919@psf.upfronthosting.co.za> Message-ID: Zachary Ware added the comment: STINNER Victor added the comment: > Note: The binary (in debug mode) moved from PCbuild\python_d.exe to PCbuild\win32\python_d.exe There ought to be a 'python.bat' in the root of the source tree that will always point to the last-built python[_d].exe, which may ease things for you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 13 23:10:19 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 13 Jan 2015 22:10:19 +0000 Subject: [issue23233] TypeError in ./setup.py In-Reply-To: <1421180295.13.0.16794585619.issue23233@psf.upfronthosting.co.za> Message-ID: <1421187019.35.0.0428490321437.issue23233@psf.upfronthosting.co.za> Ned Deily added the comment: The patch LGTM (it doesn't hurt) but I'm not sure under what circumstances anyone would run into this problem. The only scenario I can think of is where somehow ./configure, Makefile, and setup.py are out-of-sync (not all at the same rev) and the Makefile should minimize the chances of that happening (for example, by automatically re-running configure). Do you know of a way to reproduce it? ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 00:19:00 2015 From: report at bugs.python.org (Jason R. Coombs) Date: Tue, 13 Jan 2015 23:19:00 +0000 Subject: [issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine In-Reply-To: <1378731781.77.0.0136191125302.issue18987@psf.upfronthosting.co.za> Message-ID: <1421191140.3.0.569226938806.issue18987@psf.upfronthosting.co.za> Changes by Jason R. Coombs : ---------- nosy: +jason.coombs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 00:21:46 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 13 Jan 2015 23:21:46 +0000 Subject: [issue22560] New SSL implementation based on ssl.MemoryBIO In-Reply-To: <1412548102.84.0.685230620276.issue22560@psf.upfronthosting.co.za> Message-ID: <20150113232142.11563.16367@psf.io> Roundup Robot added the comment: New changeset 432b817611f2 by Victor Stinner in branch '3.4': Issue #22560: New SSL implementation based on ssl.MemoryBIO https://hg.python.org/cpython/rev/432b817611f2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 00:25:10 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Jan 2015 23:25:10 +0000 Subject: [issue22560] New SSL implementation based on ssl.MemoryBIO In-Reply-To: <1412548102.84.0.685230620276.issue22560@psf.upfronthosting.co.za> Message-ID: <1421191510.69.0.584441086524.issue22560@psf.upfronthosting.co.za> STINNER Victor added the comment: I commited sslproto-4.patch to Python 3.4, Python 3.5 and Tulip with minor changes: - remove write_eof(), as suggested by Yury - define SSLProtocol after its transport in sslproto.py - add a docstring to SSLProtocol - test sslcontext with "is not None" - _make_ssl_transport: waiter parameter is now optional Thanks Antoine for this great contribution! Thanks also to Geert Jansen since sslproto.py looks to be based on his work. Even if I ran the test suite on Python 3.3, 3.4 and 3.5 on Linux, and on Python 3.5 on Windows, I prefer to wait one or two days to see how buildbots appreciate this enhancement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 00:32:04 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 13 Jan 2015 23:32:04 +0000 Subject: [issue22560] New SSL implementation based on ssl.MemoryBIO In-Reply-To: <1412548102.84.0.685230620276.issue22560@psf.upfronthosting.co.za> Message-ID: <20150113233028.72567.3125@psf.io> Roundup Robot added the comment: New changeset b9fbbe7103e7 by Victor Stinner in branch 'default': Issue #22560, asyncio doc: ProactorEventLoop now supports SSL! https://hg.python.org/cpython/rev/b9fbbe7103e7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 00:37:12 2015 From: report at bugs.python.org (Al Sweigart) Date: Tue, 13 Jan 2015 23:37:12 +0000 Subject: [issue23181] Unicode "code point" should be two words in documentation In-Reply-To: <1420620228.26.0.565920670024.issue23181@psf.upfronthosting.co.za> Message-ID: <1421192232.74.0.14310092823.issue23181@psf.upfronthosting.co.za> Changes by Al Sweigart : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 00:41:01 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Jan 2015 23:41:01 +0000 Subject: [issue23234] refactor subprocess: use new OSError exceptions, factorize stdin.write() code Message-ID: <1421192461.64.0.911516234193.issue23234@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patch refactors subprocess code: - use new OSError exceptions - factorize stdin.write() code ---------- components: Extension Modules files: subprocess.patch keywords: patch messages: 233974 nosy: haypo, serhiy.storchaka priority: normal severity: normal status: open title: refactor subprocess: use new OSError exceptions, factorize stdin.write() code type: enhancement versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37696/subprocess.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 00:54:50 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 13 Jan 2015 23:54:50 +0000 Subject: [issue23198] asyncio: refactor StreamReader In-Reply-To: <1420764079.77.0.670547785997.issue23198@psf.upfronthosting.co.za> Message-ID: <20150113235436.8765.8721@psf.io> Roundup Robot added the comment: New changeset 94a6f9a3580e by Victor Stinner in branch '3.4': Issue #23198: Reactor asyncio.StreamReader https://hg.python.org/cpython/rev/94a6f9a3580e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 01:04:35 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 14 Jan 2015 00:04:35 +0000 Subject: [issue23235] run_tests.py doesn't set test.support.verbose correctly Message-ID: <1421193875.73.0.411637461646.issue23235@psf.upfronthosting.co.za> New submission from Berker Peksag: "make buildbottest" uses Tools/scripts/run_tests.py and it doesn't set test.support.verbose to 0. Example output from a buildbot: [ 60/389] test_codecmaps_hk fetching http://www.pythontest.net/unicode/BIG5HKSCS-2004.TXT ... http://buildbot.python.org/all/builders/System%20Z%20Linux%203.4/builds/683/steps/test/logs/stdio It works as expected if you use regrtest directly with empty Lib/test/data/ directory: $ ./python -m test test_codecmaps_hk [1/1] test_codecmaps_hk 1 test OK. ---------- components: Demos and Tools messages: 233976 nosy: berker.peksag priority: normal severity: normal stage: needs patch status: open title: run_tests.py doesn't set test.support.verbose correctly type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 01:38:17 2015 From: report at bugs.python.org (Michiel de Hoon) Date: Wed, 14 Jan 2015 00:38:17 +0000 Subject: [issue3180] Interrupts are lost during readline PyOS_InputHook processing In-Reply-To: <1214238743.53.0.342771827236.issue3180@psf.upfronthosting.co.za> Message-ID: <1421195897.53.0.632064417033.issue3180@psf.upfronthosting.co.za> Michiel de Hoon added the comment: As it happens, we just ran into the same bug. To reproduce this issue, run >>> from Tkinter import * >>> Tk() Then Ctrl-C will not generate a KeyboardInterrupt. At first glance, the solution suggested by the original poster seems good. Can this issue by reopened? I'd be happy to take over this issue report and check the patch in more detail. ---------- nosy: +Michiel.de.Hoon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 01:48:28 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Jan 2015 00:48:28 +0000 Subject: [issue23236] asyncio: add timeout to StreamReader read methods Message-ID: <1421196508.1.0.44699876054.issue23236@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patch adds an optional timeout parameter to the read(), read_exactly() and readline() methods of StreamReader. If a single read takes longer than timeout seconds, a asyncio.TimeoutError is raised. The timeout is reset each time new data is received. Read data is pushed back to the StreamReader buffer if the wait raises an exception (timeout, cancelled, etc.), so it's possible to retry the read later. ---------- components: asyncio files: streamreader_timeout.patch keywords: patch messages: 233978 nosy: gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio: add timeout to StreamReader read methods versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37697/streamreader_timeout.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 01:49:35 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Jan 2015 00:49:35 +0000 Subject: [issue23236] asyncio: add timeout to StreamReader read methods In-Reply-To: <1421196508.1.0.44699876054.issue23236@psf.upfronthosting.co.za> Message-ID: <1421196575.55.0.521144393269.issue23236@psf.upfronthosting.co.za> STINNER Victor added the comment: Copy of the feature requets by Guido van Rossum: https://code.google.com/p/tulip/issues/detail?id=96 Often you want to stop servicing (or using) a connection when there is no activity in a given time. You can do this by wrapping all your read calls in wait_for(), but a single readline() or readexactly() call may do multiple I/O operations and typically you want to reset the timeout whenever you receive some more bytes. So it makes more sense to either add the timeout to the various read*() calls, or even to (optionally) set it in the constructor, so that the class can implement a more subtle timeout algorithm. I could imagine an overall timeout too, and possibly even something that gives up if the bandwidth goes below a threshold, to avoid waiting forever on a huge download. (For StreamWriter I think it's sufficient to call wait_for(w.drain()), so I think this only applies to StreamReader.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 01:52:53 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Jan 2015 00:52:53 +0000 Subject: [issue23198] asyncio: refactor StreamReader In-Reply-To: <1420764079.77.0.670547785997.issue23198@psf.upfronthosting.co.za> Message-ID: <1421196773.07.0.797109011434.issue23198@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 01:53:04 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 14 Jan 2015 00:53:04 +0000 Subject: [issue12160] codecs doc: what is StreamCodec? In-Reply-To: <1306166137.72.0.066960808058.issue12160@psf.upfronthosting.co.za> Message-ID: <1421196784.64.0.792416594198.issue12160@psf.upfronthosting.co.za> Martin Panter added the comment: This patch looks simple and uncontroversial. I think it could be merged. ---------- nosy: +vadmium versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 01:53:58 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Jan 2015 00:53:58 +0000 Subject: [issue3180] Interrupts are lost during readline PyOS_InputHook processing In-Reply-To: <1421195897.53.0.632064417033.issue3180@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: This issue is now closed. Please open a new issue. You should mention your OS and the Python version at least. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 02:03:58 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 14 Jan 2015 01:03:58 +0000 Subject: [issue23235] run_tests.py doesn't set test.support.verbose correctly In-Reply-To: <1421193875.73.0.411637461646.issue23235@psf.upfronthosting.co.za> Message-ID: <1421197438.37.0.334069910605.issue23235@psf.upfronthosting.co.za> Berker Peksag added the comment: Here is a possible fix. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file37698/issue23235.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 02:06:21 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 14 Jan 2015 01:06:21 +0000 Subject: [issue13881] Stream encoder for zlib_codec doesn't use the incremental encoder In-Reply-To: <1327606849.1.0.885842099772.issue13881@psf.upfronthosting.co.za> Message-ID: <1421197581.94.0.723586258583.issue13881@psf.upfronthosting.co.za> Martin Panter added the comment: See Issue 23231 for a proposal which should make the incremental codec API compatible with a generic StreamReader/Writer class. I discovered that many of the codec files are generated by gencodec.py, not hand-written. However when I tried regenerating them, I found a handful had diverged from the generated code, but others were more or less true to the generated code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 02:10:29 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 14 Jan 2015 01:10:29 +0000 Subject: [issue23235] run_tests.py doesn't set test.support.verbose correctly In-Reply-To: <1421193875.73.0.411637461646.issue23235@psf.upfronthosting.co.za> Message-ID: <1421197829.34.0.459790056624.issue23235@psf.upfronthosting.co.za> Changes by Berker Peksag : Added file: http://bugs.python.org/file37699/issue23235.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 02:10:42 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 14 Jan 2015 01:10:42 +0000 Subject: [issue23235] run_tests.py doesn't set test.support.verbose correctly In-Reply-To: <1421193875.73.0.411637461646.issue23235@psf.upfronthosting.co.za> Message-ID: <1421197842.98.0.897193774915.issue23235@psf.upfronthosting.co.za> Changes by Berker Peksag : Removed file: http://bugs.python.org/file37698/issue23235.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 02:15:01 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 14 Jan 2015 01:15:01 +0000 Subject: [issue23173] asyncio: kill the subprocess if the creation failed In-Reply-To: <1420502445.76.0.9797827832.issue23173@psf.upfronthosting.co.za> Message-ID: <20150114011446.125904.86336@psf.io> Roundup Robot added the comment: New changeset 1eae3b6fbec6 by Victor Stinner in branch '3.4': Python issue #23173: sync with Tulip https://hg.python.org/cpython/rev/1eae3b6fbec6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 02:15:17 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Jan 2015 01:15:17 +0000 Subject: [issue23173] asyncio: kill the subprocess if the creation failed In-Reply-To: <1420502445.76.0.9797827832.issue23173@psf.upfronthosting.co.za> Message-ID: <1421198117.08.0.665070603065.issue23173@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 02:17:25 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Jan 2015 01:17:25 +0000 Subject: [issue23197] asyncio: check if a future is cancelled before calling set_result/set_exception In-Reply-To: <1420762312.46.0.962527500609.issue23197@psf.upfronthosting.co.za> Message-ID: <1421198245.09.0.590081772239.issue23197@psf.upfronthosting.co.za> STINNER Victor added the comment: > Oh, I forgot that the change in subprocess.py (check if waiter is cancelled before setting its result) is already part of the issue #23197 which comes with an unit test. Wrong, it's the issue #23173. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 02:19:51 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Jan 2015 01:19:51 +0000 Subject: [issue23197] asyncio: check if a future is cancelled before calling set_result/set_exception In-Reply-To: <1420762312.46.0.962527500609.issue23197@psf.upfronthosting.co.za> Message-ID: <1421198391.07.0.192880819259.issue23197@psf.upfronthosting.co.za> STINNER Victor added the comment: The sslproto.py which just has been merged has a similar issue: if isinstance(exc, Exception): if self._waiter is not None: self._waiter.set_exception(exc) in _on_handshake_complete(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 02:20:55 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Jan 2015 01:20:55 +0000 Subject: [issue23187] Segmentation fault, possibly asyncio related In-Reply-To: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za> Message-ID: <1421198455.97.0.818972483048.issue23187@psf.upfronthosting.co.za> STINNER Victor added the comment: @Ivailo: Any progress on your investigation? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 02:21:18 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 14 Jan 2015 01:21:18 +0000 Subject: [issue14014] codecs.StreamWriter.reset contract not fulfilled In-Reply-To: <1329242513.77.0.581823861095.issue14014@psf.upfronthosting.co.za> Message-ID: <1421198478.4.0.622374085396.issue14014@psf.upfronthosting.co.za> Martin Panter added the comment: I don?t think this is appropriate. If you want to flush the underlying stream, then call its flush() method after calling reset(). The docstring only says it flushes the _codec?s_ buffers, not any buffers of the underlying stream, and it should not be the codec?s business to worry about lower level buffers. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 02:25:16 2015 From: report at bugs.python.org (Ivailo Karamanolev) Date: Wed, 14 Jan 2015 01:25:16 +0000 Subject: [issue23187] Segmentation fault, possibly asyncio related In-Reply-To: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za> Message-ID: <1421198716.78.0.00448328168507.issue23187@psf.upfronthosting.co.za> Ivailo Karamanolev added the comment: @Victor It has been running for 5 days now on 3.4.2 using json instead of ujson. I want to give at least 10 days to crash and if it's still up, I plan to switch to simplejson to see how that will go, since json is quite slow. I'll keep playing with using different modules and when/if I have something significant that I can reproduce - I'll post here. If the problems are resolved, I'll close the ticket. If that doesn't sound reasonable, please let me know. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 02:26:19 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Jan 2015 01:26:19 +0000 Subject: [issue23223] subprocess32 unable to be installed via pip In-Reply-To: <1420988335.84.0.852324840032.issue23223@psf.upfronthosting.co.za> Message-ID: <1421198779.87.0.530944348518.issue23223@psf.upfronthosting.co.za> STINNER Victor added the comment: subprocess32 is not part of Python, it's a third party mode. Report the issue to his author. ---------- nosy: +haypo resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 02:29:45 2015 From: report at bugs.python.org (koobs) Date: Wed, 14 Jan 2015 01:29:45 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1421198985.26.0.0095323313001.issue22038@psf.upfronthosting.co.za> koobs added the comment: FreeBSD buildbots broken since fbe87fb071a67cb5e638b3496362b5aedc0fc9a7 ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 02:30:10 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 14 Jan 2015 01:30:10 +0000 Subject: [issue20739] PEP 463 (except expression) implementation In-Reply-To: <1393113417.21.0.308711390279.issue20739@psf.upfronthosting.co.za> Message-ID: <1421199010.71.0.334660132913.issue20739@psf.upfronthosting.co.za> Berker Peksag added the comment: Guido's comment about the PEP is at https://mail.python.org/pipermail/python-dev/2014-March/133118.html Can we close this and mark PEP 463 as rejected now? ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 02:30:44 2015 From: report at bugs.python.org (koobs) Date: Wed, 14 Jan 2015 01:30:44 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1421199044.41.0.645287119882.issue22038@psf.upfronthosting.co.za> koobs added the comment: Oops, incomplete comment, apologies. Just noticed haypo has reported the issue here already ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 02:34:26 2015 From: report at bugs.python.org (Jeffrey Yasskin) Date: Wed, 14 Jan 2015 01:34:26 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1421199266.61.0.034151514721.issue22038@psf.upfronthosting.co.za> Changes by Jeffrey Yasskin : ---------- nosy: -jyasskin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 02:37:23 2015 From: report at bugs.python.org (Jim Jewett) Date: Wed, 14 Jan 2015 01:37:23 +0000 Subject: [issue14014] codecs.StreamWriter.reset contract not fulfilled In-Reply-To: <1421198478.4.0.622374085396.issue14014@psf.upfronthosting.co.za> Message-ID: Jim Jewett added the comment: That sounds like a bug magnet to me; my mental model is that the codec is my output; flushing it will push things out, and resetting it will erase anything pending. I don't care if some implementation detail means that some other object technically owns the buffer. An alternative (inferior, but better than nothing) would be to add an explicit note warning users that reset won't really finish the job, and they have to also get the codec's underlying stream and flush that. (Of course, if the stream is really an abstraction over the real stream ... at what point does the delegation start to work on its own?) On Tue, Jan 13, 2015 at 8:21 PM, Martin Panter wrote: > > Martin Panter added the comment: > > I don?t think this is appropriate. If you want to flush the underlying stream, then call its flush() method after calling reset(). The docstring only says it flushes the _codec?s_ buffers, not any buffers of the underlying stream, and it should not be the codec?s business to worry about lower level buffers. > > ---------- > nosy: +vadmium > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 02:37:32 2015 From: report at bugs.python.org (Robert Collins) Date: Wed, 14 Jan 2015 01:37:32 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1421199452.7.0.991091407597.issue17911@psf.upfronthosting.co.za> Robert Collins added the comment: Ok, here's a draft patch for linecache. Next up, poking around the new TB API. ---------- Added file: http://bugs.python.org/file37700/linecache_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 03:01:43 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 14 Jan 2015 02:01:43 +0000 Subject: [issue23234] refactor subprocess: use new OSError exceptions, factorize stdin.write() code In-Reply-To: <1421192461.64.0.911516234193.issue23234@psf.upfronthosting.co.za> Message-ID: <1421200903.28.0.428575815163.issue23234@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 03:09:08 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 14 Jan 2015 02:09:08 +0000 Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone constant In-Reply-To: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za> Message-ID: <1421201348.07.0.208618572163.issue22932@psf.upfronthosting.co.za> R. David Murray added the comment: Upgrading the timezone data results in passed tests. Without the fix, only one of the tests fails. Is this intentional? This, however, brings up the issue that the tests may fail on the buildbots, which may also not have up to date timezone data :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 03:13:03 2015 From: report at bugs.python.org (Michiel de Hoon) Date: Wed, 14 Jan 2015 02:13:03 +0000 Subject: [issue23237] Interrupts are lost during readline PyOS_InputHook processing (reopening) Message-ID: <1421201583.23.0.507661432161.issue23237@psf.upfronthosting.co.za> New submission from Michiel de Hoon: This bug was previously reported in http://bugs.python.org/issue3180 but was closed after seven years for being out of date. Still, the bug remains: Interrupts are lost during readline PyOS_InputHook processing. To reproduce the bug, try >>> from Tkinter import * >>> Tk() You will notice that Ctrl-C now does not generate a KeybordInterrupt. This bug appears in all Python versions I tested (Python 2.7, 3.3, 3.4) and, judging from the source code, is still present in the current Python source code in Mercurial. The bug appears both on Mac and on Linux; I do not have access to Windows. The suggested patch at http://bugs.python.org/issue3180 makes multiple changes to the behavior of PyOS_InputHook. In particular, it allows for waiting for a file descriptor other than stdin. I think that this is unrelated to the current bug, so it should not be included in the patch, in particular since that would change the API. ---------- components: Extension Modules messages: 233997 nosy: Michiel.de.Hoon priority: normal severity: normal status: open title: Interrupts are lost during readline PyOS_InputHook processing (reopening) type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 03:13:56 2015 From: report at bugs.python.org (Michiel de Hoon) Date: Wed, 14 Jan 2015 02:13:56 +0000 Subject: [issue3180] Interrupts are lost during readline PyOS_InputHook processing In-Reply-To: <1214238743.53.0.342771827236.issue3180@psf.upfronthosting.co.za> Message-ID: <1421201636.75.0.173079222912.issue3180@psf.upfronthosting.co.za> Michiel de Hoon added the comment: I have opened a new issue 23237 for this bug; please see http://bugs.python.org/issue23237 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 03:26:56 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 14 Jan 2015 02:26:56 +0000 Subject: [issue14014] codecs.StreamWriter.reset contract not fulfilled In-Reply-To: <1329242513.77.0.581823861095.issue14014@psf.upfronthosting.co.za> Message-ID: <1421202416.19.0.604109154371.issue14014@psf.upfronthosting.co.za> Martin Panter added the comment: Maybe it would be better to redefine the docstring to say it flushes the codec as well as calling flush() on the underlying stream. But if you really want to finish the job you should probably be closing the underlying stream, which would flush if necessary. See Issue 460474, for adding a close() method which invokes reset(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 03:54:51 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 14 Jan 2015 02:54:51 +0000 Subject: [issue23237] Interrupts are lost during readline PyOS_InputHook processing (reopening) In-Reply-To: <1421201583.23.0.507661432161.issue23237@psf.upfronthosting.co.za> Message-ID: <1421204091.82.0.000696615146905.issue23237@psf.upfronthosting.co.za> R. David Murray added the comment: Updating versions to reflect where it might get fixed (which is what we use the versions field for). ---------- nosy: +r.david.murray versions: -Python 3.2, Python 3.3, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 04:17:28 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 14 Jan 2015 03:17:28 +0000 Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone constant In-Reply-To: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za> Message-ID: <1421205448.71.0.995607481949.issue22932@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Maybe Dmitry can come up with the "skipif" logic that will test for up-to date tzinfo and skip the test if it is not. Otherwise we can try to come up with a test case which is sufficiently far in the past. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 04:23:07 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 14 Jan 2015 03:23:07 +0000 Subject: [issue23223] subprocess32 unable to be installed via pip In-Reply-To: <1420988335.84.0.852324840032.issue23223@psf.upfronthosting.co.za> Message-ID: <1421205787.39.0.946360341776.issue23223@psf.upfronthosting.co.za> Berker Peksag added the comment: Quoting from https://code.google.com/p/python-subprocess32/: "Think you've found an issue? Please try to reproduce it using Python 3.4 and file it using http://bugs.python.org/. Work will be done upstream and backported to this project." ---------- nosy: +berker.peksag resolution: not a bug -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 04:28:33 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 14 Jan 2015 03:28:33 +0000 Subject: [issue23223] subprocess32 unable to be installed via pip In-Reply-To: <1420988335.84.0.852324840032.issue23223@psf.upfronthosting.co.za> Message-ID: <1421206113.83.0.781452903509.issue23223@psf.upfronthosting.co.za> Berker Peksag added the comment: Here is a patch. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file37701/issue23223.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 04:35:59 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 14 Jan 2015 03:35:59 +0000 Subject: [issue23234] refactor subprocess: use new OSError exceptions, factorize stdin.write() code In-Reply-To: <1421192461.64.0.911516234193.issue23234@psf.upfronthosting.co.za> Message-ID: <1421206559.69.0.863706324912.issue23234@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- components: +Library (Lib) -Extension Modules nosy: +gregory.p.smith stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 04:39:28 2015 From: report at bugs.python.org (Zachary Ware) Date: Wed, 14 Jan 2015 03:39:28 +0000 Subject: [issue23223] subprocess32 unable to be installed via pip In-Reply-To: <1421206113.83.0.781452903509.issue23223@psf.upfronthosting.co.za> Message-ID: Zachary Ware added the comment: _posixsubprocess should not be compiled on Windows, as it will not work and has the potential to completely screw up subprocess on Windows. This appears to be a bug in subprocess32's setup.py, and thus does not apply to Python itself at all. I agree with Victor that this bug doesn't belong here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 04:46:57 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 14 Jan 2015 03:46:57 +0000 Subject: [issue23223] subprocess32 unable to be installed via pip In-Reply-To: <1420988335.84.0.852324840032.issue23223@psf.upfronthosting.co.za> Message-ID: <1421207217.23.0.521443791617.issue23223@psf.upfronthosting.co.za> Berker Peksag added the comment: Oh, good point! I missed that, thanks. ---------- resolution: -> not a bug stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 06:48:10 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 14 Jan 2015 05:48:10 +0000 Subject: [issue23226] Add float linspace recipe to docs In-Reply-To: <1421102448.57.0.289351503451.issue23226@psf.upfronthosting.co.za> Message-ID: <1421214490.39.0.744525725272.issue23226@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This is too much. Try for a brief reference. This section of the docs is primarily about how range() works. Linspace() is at best a tangential discussion and shouldn't interfere with the usability of range() docs (a tool we actually have and that is in common use). ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 06:58:23 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 14 Jan 2015 05:58:23 +0000 Subject: [issue23189] Set docstrings to empty string when optimizing with -OO. In-Reply-To: <1420710105.42.0.0455822244895.issue23189@psf.upfronthosting.co.za> Message-ID: <1421215103.89.0.635907436214.issue23189@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Here are some of the packages that run into trouble > when the docstrings are set to 'None' by the -OO optimization I think you should file bug reports for those packages. We've agreed here that the current behavior is correct and that the proposed change in backward incompatible, so I'm gone to close this one as "not a bug". Perhaps, some not in the docs for "packaging and distributing python would be appropriate" and perhaps some PEP-8 guidance for avoiding "__doc__+='moredocs'" without first checking whether __doc__ is None. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 07:14:08 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 14 Jan 2015 06:14:08 +0000 Subject: [issue13881] Stream encoder for zlib_codec doesn't use the incremental encoder In-Reply-To: <1327606849.1.0.885842099772.issue13881@psf.upfronthosting.co.za> Message-ID: <1421216048.97.0.893300286895.issue13881@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch to implement the zlib-codec and bz2-codec StreamWriter classes based on their IncrementalEncoder classes. It depends on my patch for Issue 23231, though I guess it could be tweaked to work around that if desired. ---------- keywords: +patch versions: +Python 3.5 Added file: http://bugs.python.org/file37702/zlib-bz2-writer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 07:45:55 2015 From: report at bugs.python.org (Andrew Barnert) Date: Wed, 14 Jan 2015 06:45:55 +0000 Subject: [issue23226] Add float linspace recipe to docs In-Reply-To: <1421102448.57.0.289351503451.issue23226@psf.upfronthosting.co.za> Message-ID: <1421217955.66.0.420502294095.issue23226@psf.upfronthosting.co.za> Andrew Barnert added the comment: So something like the first version below? Or should even the example be inline, as in the second version below? (Apologies if the formatting gets screwed up pasting from docs to bugs.) --- Range objects are inappropriate for non-integral types, especially inexact types such as :class:`float`. In most cases, for such types, it is better to specify a count of numbers or intervals instead of a step size. For example: >>> start, stop, num = 0, 10, 11 >>> step = (stop-start)/(num-1) >>> [start + i*step for i in range(num)] [0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0, 10.0] .. seealso:: * `linspace recipe `_ for an example lazy sequence built on this algorithm, and links to alternatives. --- Range objects are inappropriate for non-integral types, especially inexact types such as :class:`float`. In most cases, it is better to specify a count of numbers or intervals instead of a step size, as in `[start + i*(stop-start)/(num-1) for i in range(num)]`. .. seealso:: * `linspace recipe `_ for an example lazy sequence built on this algorithm, and links to alternatives. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 08:07:25 2015 From: report at bugs.python.org (Lin Wei) Date: Wed, 14 Jan 2015 07:07:25 +0000 Subject: [issue20140] UnicodeDecodeError in ntpath.py when home dir contains non-ascii signs In-Reply-To: <1389005031.99.0.692658963376.issue20140@psf.upfronthosting.co.za> Message-ID: <1421219245.74.0.160424805115.issue20140@psf.upfronthosting.co.za> Lin Wei added the comment: The patch (http://bugs.python.org/issue9291#msg206938) for #9291 actually helps with this issue, at least for me. By the way, @Serhiy do you mean that the problem is merely documentation, while the implementation is alright? ---------- nosy: +Lin.Wei _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 08:26:44 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 14 Jan 2015 07:26:44 +0000 Subject: [issue23181] Unicode "code point" should be two words in documentation In-Reply-To: <1420620228.26.0.565920670024.issue23181@psf.upfronthosting.co.za> Message-ID: <20150114072635.11565.99010@psf.io> Roundup Robot added the comment: New changeset c917ba25c007 by Georg Brandl in branch 'default': Closes #23181: codepoint -> code point https://hg.python.org/cpython/rev/c917ba25c007 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 08:28:53 2015 From: report at bugs.python.org (Ethan Furman) Date: Wed, 14 Jan 2015 07:28:53 +0000 Subject: [issue20284] patch to implement PEP 461 (%-interpolation for bytes) In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <1421220533.05.0.816346431255.issue20284@psf.upfronthosting.co.za> Ethan Furman added the comment: Removed the new ABI functions, all new functions are static. Duplicated bytes code in bytearray. in-place interpolation returns new bytearray at this point. I'll work on getting in-place working, but otherwise I'll commit this in a week so we have something in for the first alpha. ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file37703/issue20284.stoneleaf.02.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 08:41:57 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 14 Jan 2015 07:41:57 +0000 Subject: [issue23181] Unicode "code point" should be two words in documentation In-Reply-To: <1420620228.26.0.565920670024.issue23181@psf.upfronthosting.co.za> Message-ID: <20150114074117.8759.24204@psf.io> Roundup Robot added the comment: New changeset e280a04625cc by Georg Brandl in branch '2.7': Closes #23181: codepoint -> code point https://hg.python.org/cpython/rev/e280a04625cc ---------- _______________________________________ Python tracker _______________________________________ From mal at egenix.com Wed Jan 14 09:34:40 2015 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 14 Jan 2015 09:34:40 +0100 Subject: [issue14014] codecs.StreamWriter.reset contract not fulfilled In-Reply-To: <1421198478.4.0.622374085396.issue14014@psf.upfronthosting.co.za> References: <1421198478.4.0.622374085396.issue14014@psf.upfronthosting.co.za> Message-ID: <54B62A20.9050704@egenix.com> On 14.01.2015 02:21, Martin Panter wrote: > > Martin Panter added the comment: > > I don?t think this is appropriate. If you want to flush the underlying stream, then call its flush() method after calling reset(). The docstring only says it flushes the _codec?s_ buffers, not any buffers of the underlying stream, and it should not be the codec?s business to worry about lower level buffers. Correct. That's the reason why the method is called .reset() and not .flush(). -- Marc-Andre Lemburg eGenix.com From report at bugs.python.org Wed Jan 14 09:34:47 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 14 Jan 2015 08:34:47 +0000 Subject: [issue14014] codecs.StreamWriter.reset contract not fulfilled In-Reply-To: <1421198478.4.0.622374085396.issue14014@psf.upfronthosting.co.za> Message-ID: <54B62A20.9050704@egenix.com> Marc-Andre Lemburg added the comment: On 14.01.2015 02:21, Martin Panter wrote: > > Martin Panter added the comment: > > I don?t think this is appropriate. If you want to flush the underlying stream, then call its flush() method after calling reset(). The docstring only says it flushes the _codec?s_ buffers, not any buffers of the underlying stream, and it should not be the codec?s business to worry about lower level buffers. Correct. That's the reason why the method is called .reset() and not .flush(). ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From mal at egenix.com Wed Jan 14 09:41:04 2015 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 14 Jan 2015 09:41:04 +0100 Subject: [issue14014] codecs.StreamWriter.reset contract not fulfilled In-Reply-To: References: Message-ID: <54B62BA0.5020700@egenix.com> Adding a note to the documentation is fine. The .reset() method doesn't have anything to do with the underlying stream. It's only meant to work at the codec level and needed for codecs that keep internal state. -- Marc-Andre Lemburg eGenix.com From report at bugs.python.org Wed Jan 14 09:41:11 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 14 Jan 2015 08:41:11 +0000 Subject: [issue14014] codecs.StreamWriter.reset contract not fulfilled In-Reply-To: Message-ID: <54B62BA0.5020700@egenix.com> Marc-Andre Lemburg added the comment: Adding a note to the documentation is fine. The .reset() method doesn't have anything to do with the underlying stream. It's only meant to work at the codec level and needed for codecs that keep internal state. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 09:59:16 2015 From: report at bugs.python.org (memkmemk) Date: Wed, 14 Jan 2015 08:59:16 +0000 Subject: [issue23238] http.server failed to decode '+' to ' ' when calling cgi script/executable in window Message-ID: <1421225956.24.0.0678998380513.issue23238@psf.upfronthosting.co.za> New submission from memkmemk: The actual commandline generated from http request does not decode '+' back to ' ' ---------- messages: 234016 nosy: memkmemk priority: normal severity: normal status: open title: http.server failed to decode '+' to ' ' when calling cgi script/executable in window versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 10:00:36 2015 From: report at bugs.python.org (memkmemk) Date: Wed, 14 Jan 2015 09:00:36 +0000 Subject: [issue23238] http.server failed to decode '+' to ' ' when calling cgi script/executable in window In-Reply-To: <1421225956.24.0.0678998380513.issue23238@psf.upfronthosting.co.za> Message-ID: <1421226036.04.0.900064384241.issue23238@psf.upfronthosting.co.za> Changes by memkmemk : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 10:04:52 2015 From: report at bugs.python.org (=?utf-8?b?w4Fkw6FtIFpzaWdtb25k?=) Date: Wed, 14 Jan 2015 09:04:52 +0000 Subject: [issue23239] SSL match_hostname does not accept IP Address Message-ID: <1421226292.77.0.451398063166.issue23239@psf.upfronthosting.co.za> New submission from ?d?m Zsigmond: ssl.match_hostname does not accept the ca certificate if the hostname matches the ip address. I am trying to connect to a servert with a cacert by IP address but I get an error message like: '42.42.42.42' hostname does not match '' The IP Address is in the ca certificate, so it should be accepted. ---------- components: Extension Modules messages: 234017 nosy: ?d?m.Zsigmond priority: normal severity: normal status: open title: SSL match_hostname does not accept IP Address type: security versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 10:05:33 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Jan 2015 09:05:33 +0000 Subject: [issue23239] SSL match_hostname does not accept IP Address In-Reply-To: <1421226292.77.0.451398063166.issue23239@psf.upfronthosting.co.za> Message-ID: <1421226333.92.0.531568780652.issue23239@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +alex, pitrou versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 10:59:01 2015 From: report at bugs.python.org (Tim Golden) Date: Wed, 14 Jan 2015 09:59:01 +0000 Subject: [issue23018] Add version info to python In-Reply-To: <1421165991.79.0.493044754898.issue23018@psf.upfronthosting.co.za> Message-ID: <54B63DE2.4030000@timgolden.me.uk> Tim Golden added the comment: +1 from me, then. ---------- title: Add version info to python[w].exe -> Add version info to python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 12:08:13 2015 From: report at bugs.python.org (Drekin) Date: Wed, 14 Jan 2015 11:08:13 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1421233693.29.0.0855588939118.issue1602@psf.upfronthosting.co.za> Drekin added the comment: Note that win-unicode-console replaces the stdio streams rather than wraps them. So the desired state would be Unicode stream objects wrapped by PTVS. There would be no problem if win-unicode-console stream replacement occured before PTVS wraps them, which should be the case when Unicode streams for Windows are hadled by Python 3.5 itself. Is there any way to run custom Python code (like sitecustomize) before PTVS wraps the stdio streams? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 12:27:01 2015 From: report at bugs.python.org (Gustavo Temple) Date: Wed, 14 Jan 2015 11:27:01 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1421234821.01.0.304735120442.issue22038@psf.upfronthosting.co.za> Changes by Gustavo Temple : Added file: http://bugs.python.org/file37704/atomicv5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 12:47:01 2015 From: report at bugs.python.org (Dainis Jonitis) Date: Wed, 14 Jan 2015 11:47:01 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1421236021.13.0.429817671114.issue1602@psf.upfronthosting.co.za> Dainis Jonitis added the comment: Presumably Unicode streams would also fix file redirects. Currently, if you want to redirect stdout output to file it throws. For example PowerShell: C:\Python34\python.exe .\test.py | out-file -Encoding utf8 -FilePath 'test.txt' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 13:04:03 2015 From: report at bugs.python.org (arnaud gaboury) Date: Wed, 14 Jan 2015 12:04:03 +0000 Subject: [issue23240] pip 6.0.6- pip install command is broken Message-ID: <1421237043.78.0.734461978939.issue23240@psf.upfronthosting.co.za> New submission from arnaud gaboury: gabx at hortensia ?? ~ % pip3.4 install websocket-client Exception: Traceback (most recent call last): File "/usr/lib/python3.4/site-packages/pip/basecommand.py", line 232, in main status = self.run(options, args) File "/usr/lib/python3.4/site-packages/pip/commands/install.py", line 339, in run requirement_set.prepare_files(finder) File "/usr/lib/python3.4/site-packages/pip/req/req_set.py", line 229, in prepare_files req_to_install.check_if_exists() File "/usr/lib/python3.4/site-packages/pip/req/req_install.py", line 928, in check_if_exists self.satisfied_by = pkg_resources.get_distribution(self.req) File "/usr/lib/python3.4/site-packages/pip/_vendor/pkg_resources/__init__.py", line 461, in get_distribution dist = get_provider(dist) File "/usr/lib/python3.4/site-packages/pip/_vendor/pkg_resources/__init__.py", line 341, in get_provider return working_set.find(moduleOrReq) or require(str(moduleOrReq))[0] File "/usr/lib/python3.4/site-packages/pip/_vendor/pkg_resources/__init__.py", line 870, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/lib/python3.4/site-packages/pip/_vendor/pkg_resources/__init__.py", line 740, in resolve env = Environment(self.entries) File "/usr/lib/python3.4/site-packages/pip/_vendor/pkg_resources/__init__.py", line 927, in __init__ self.scan(search_path) File "/usr/lib/python3.4/site-packages/pip/_vendor/pkg_resources/__init__.py", line 957, in scan self.add(dist) File "/usr/lib/python3.4/site-packages/pip/_vendor/pkg_resources/__init__.py", line 977, in add dists.sort(key=operator.attrgetter('hashcmp'), reverse=True) TypeError: unorderable types: NoneType() < str() --------------------------------------------------------- gabx at hortensia ?? ~ % pip list aiohttp (0.9.1) apparmor (2.9.1) appdirs (1.3.0) ................. -------------------------------------------------- gabx at hortensia ?? ~ % pip show six --- Name: six Version: 1.9.0 Location: /usr/lib/python3.4/site-packages Requires: ------------------------------------------ gabx at hortensia ?? ~ % pip install ranger Requirement already satisfied (use --upgrade to upgrade): ranger in /usr/lib/python3.4/site-packages ------------------------------------------ pip install seems broken when installing a new package. ---------- components: Distutils messages: 234021 nosy: dstufft, eric.araujo, gabx priority: normal severity: normal status: open title: pip 6.0.6- pip install command is broken type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 13:20:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 14 Jan 2015 12:20:22 +0000 Subject: [issue23181] Unicode "code point" should be two words in documentation In-Reply-To: <1420620228.26.0.565920670024.issue23181@psf.upfronthosting.co.za> Message-ID: <1421238022.45.0.129227166267.issue23181@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: "codepoint" is still used in error messages, docstrings and comments. Doc/library/json.rst:517::class:`str`) codepoints for such sequences. Lib/email/message.py:276: # containing only ASCII codepoints in the unicode input). Lib/html/entities.py:6:# maps the HTML entity name to the Unicode codepoint Lib/html/entities.py:2498:# maps the Unicode codepoint to the HTML entity name Lib/codecs.py:127: 'surrogateescape' - replace with private codepoints U+DCnn. Lib/test/test_multibytecodec.py:83: # jisx0213 encoder is stateful for a few codepoints. eg) Lib/test/test_html.py:51: # check invalid codepoints Lib/test/test_html.py:54: # check more invalid codepoints Lib/test/multibytecodec_support.py:24: unmappedunicode = '\udeee' # a unicode codepoint that is not mapped. Lib/test/test_unicode.py:1473: # start bytes of a 2-byte sequence equivalent to codepoints < 0x7F Lib/test/test_unicode.py:1475: # start bytes of a 4-byte sequence equivalent to codepoints > 0x10FFFF Lib/test/test_stringprep.py:2:# Since we don't have them, this test checks only a few codepoints. Tools/unicode/gencodec.py:37:# Placeholder for a missing codepoint Modules/cjkcodecs/_codecs_hk.c:174: NEXT_IN(2); /* all decoded codepoints are pairs, above. */ Modules/cjkcodecs/cjkcodecs.h:15:/* a unicode "undefined" codepoint */ Modules/cjkcodecs/cjkcodecs.h:18:/* internal-use DBCS codepoints which aren't used by any charsets */ Modules/cjkcodecs/_codecs_cn.c:18:/* GBK and GB2312 map differently in few codepoints that are listed below: Modules/cjkcodecs/_codecs_kr.c:72: /* All codepoints in CP949 extension are in unicode Modules/unicodedata.c:979:/* macros used to determine if the given codepoint is in the PUA range that Modules/unicodedata.c:989: /* Find the name associated with the given codepoint. Modules/unicodedata.c:1000: /* XXX should we just skip all the codepoints in the PUAs here? */ Modules/unicodedata.c:1128: /* if the codepoint is in the PUA range that we use for aliases, Modules/unicodedata.c:1129: * convert it to obtain the right codepoint */ Modules/unicodedata.c:1141: /* Return the codepoint associated with the given name. Modules/unicodedata.c:1143: * 3.2.0)). If with_named_seq is 1, returns the PUA codepoint that we are Objects/unicodeobject.c:5016: errmsg = "codepoint in surrogate code point range(0xd800, 0xe000)"; Objects/unicodeobject.c:5035: errmsg = "codepoint not in range(0x110000)"; Python/sysmodule.c:1382:maxunicode -- the value of the largest Unicode codepoint\n\ ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 13:28:53 2015 From: report at bugs.python.org (Gustavo Temple) Date: Wed, 14 Jan 2015 12:28:53 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1421238533.83.0.710219417747.issue22038@psf.upfronthosting.co.za> Gustavo Temple added the comment: @haypo, @Arfrever, done: atomicv5.patch ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 13:33:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 14 Jan 2015 12:33:19 +0000 Subject: [issue23181] Unicode "code point" should be two words in documentation In-Reply-To: <1420620228.26.0.565920670024.issue23181@psf.upfronthosting.co.za> Message-ID: <1421238799.51.0.657135869607.issue23181@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which fixes remnants. ---------- Added file: http://bugs.python.org/file37705/code_point_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 14:02:56 2015 From: report at bugs.python.org (Michael Kesper) Date: Wed, 14 Jan 2015 13:02:56 +0000 Subject: [issue23241] shutil should accept pathlib types Message-ID: <1421240576.75.0.719151648499.issue23241@psf.upfronthosting.co.za> New submission from Michael Kesper: source_path = Path('../data') destination_path = Path('//file_server/work/whatever') for file_name in source_path.glob('xyz-*'): shutil.copyfile(source_path / file_name, destination_path / file_name) leads to: Traceback (most recent call last): File "copy_shares_2_work.py", line 9, in shutil.copyfile(source_path / file_name, destination_path / file_name) File "C:\Python34\lib\shutil.py", line 90, in copyfile if _samefile(src, dst): File "C:\Python34\lib\shutil.py", line 75, in _samefile return os.path.samefile(src, dst) File "C:\Python34\lib\genericpath.py", line 90, in samefile s1 = os.stat(f1) TypeError: argument should be string, bytes or integer, not WindowsPath Converting to str() works but is unexpected. ---------- messages: 234025 nosy: mkesper priority: normal severity: normal status: open title: shutil should accept pathlib types type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 14:35:54 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 14 Jan 2015 13:35:54 +0000 Subject: [issue23238] http.server failed to decode '+' to ' ' when calling cgi script/executable in window In-Reply-To: <1421225956.24.0.0678998380513.issue23238@psf.upfronthosting.co.za> Message-ID: <1421242554.69.0.0150221765954.issue23238@psf.upfronthosting.co.za> R. David Murray added the comment: There is insufficient information here to reproduce your issue. Can you provide an example? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 14:37:05 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 14 Jan 2015 13:37:05 +0000 Subject: [issue23239] SSL match_hostname does not accept IP Address In-Reply-To: <1421226292.77.0.451398063166.issue23239@psf.upfronthosting.co.za> Message-ID: <1421242625.55.0.179761071724.issue23239@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 14:42:19 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 14 Jan 2015 13:42:19 +0000 Subject: [issue23241] shutil should accept pathlib types In-Reply-To: <1421240576.75.0.719151648499.issue23241@psf.upfronthosting.co.za> Message-ID: <1421242939.35.0.215214532509.issue23241@psf.upfronthosting.co.za> R. David Murray added the comment: This is a specific example of a global discussion about handling of paths in the stdlib. So far we have elected not to provide special handling. The correct thing to do is call str. I'm not sure if shutil is special enough to be a special case, but it would need to be discussed in the context of the larger issue in some forum other than the bug tracker (probably python-dev). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 15:01:40 2015 From: report at bugs.python.org (Donald Stufft) Date: Wed, 14 Jan 2015 14:01:40 +0000 Subject: [issue23240] pip 6.0.6- pip install command is broken In-Reply-To: <1421237043.78.0.734461978939.issue23240@psf.upfronthosting.co.za> Message-ID: <1421244100.01.0.67902743935.issue23240@psf.upfronthosting.co.za> Donald Stufft added the comment: This is a pip problem and should be filed against the pip issue tracker at https://github.com/pypa/pip/issues. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 15:58:06 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 14 Jan 2015 14:58:06 +0000 Subject: [issue23240] pip 6.0.6- pip install command is broken In-Reply-To: <1421237043.78.0.734461978939.issue23240@psf.upfronthosting.co.za> Message-ID: <1421247486.78.0.608833094106.issue23240@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> third party status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 16:00:43 2015 From: report at bugs.python.org (Augie Fackler) Date: Wed, 14 Jan 2015 15:00:43 +0000 Subject: [issue21590] Systemtap and DTrace support In-Reply-To: <1401195995.8.0.935339035852.issue21590@psf.upfronthosting.co.za> Message-ID: <1421247643.24.0.565203953075.issue21590@psf.upfronthosting.co.za> Changes by Augie Fackler : ---------- nosy: +durin42 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 16:03:15 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 14 Jan 2015 15:03:15 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <20150114150245.8753.54704@psf.io> Roundup Robot added the comment: New changeset dacc944641b1 by Victor Stinner in branch 'default': Issue #22038, configure: HAVE_STD_ATOMIC now also check that "atomic_int" and https://hg.python.org/cpython/rev/dacc944641b1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 16:06:22 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Jan 2015 15:06:22 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1421247982.26.0.357122886149.issue22038@psf.upfronthosting.co.za> STINNER Victor added the comment: I commited atomicv5.patch because it's simple, but I'm not sure that we are using stdatomic.h "correctly". The current code looks to be written for GCC, Clang fails to compile it (FreeBSD 10 now uses Clang instead of GCC). Maybe the "_Atomic void*" type is wrong, and we should use the "atomic_uintptr_t" type instead and cast to the expected type? Attached atomic_pointer.patch implements this idea. It works on FreeBSD 10 with Clang and on Fedora 21 with GCC 4.9, both have stdatomic.h. ---------- Added file: http://bugs.python.org/file37706/atomic_pointer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 16:14:48 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Jan 2015 15:14:48 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1421248488.16.0.172568358958.issue22038@psf.upfronthosting.co.za> STINNER Victor added the comment: At least, the latest change repaired FreeBSD 10 compilation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 16:38:32 2015 From: report at bugs.python.org (Augie Fackler) Date: Wed, 14 Jan 2015 15:38:32 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1421249912.04.0.166109712996.issue13405@psf.upfronthosting.co.za> Changes by Augie Fackler : ---------- nosy: +durin42 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 17:09:35 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Jan 2015 16:09:35 +0000 Subject: [issue23234] refactor subprocess: use new OSError exceptions, factorize stdin.write() code In-Reply-To: <1421192461.64.0.911516234193.issue23234@psf.upfronthosting.co.za> Message-ID: <1421251775.05.0.934643313696.issue23234@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 17:10:10 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Jan 2015 16:10:10 +0000 Subject: [issue23234] refactor subprocess: use new OSError exceptions, factorize stdin.write() code In-Reply-To: <1421192461.64.0.911516234193.issue23234@psf.upfronthosting.co.za> Message-ID: <1421251810.81.0.168230454868.issue23234@psf.upfronthosting.co.za> STINNER Victor added the comment: I commited my change to Python 3.5. Thanks for the review Serhiy & vadmium. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 17:11:52 2015 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 14 Jan 2015 16:11:52 +0000 Subject: [issue23226] Add float linspace recipe to docs In-Reply-To: <1421102448.57.0.289351503451.issue23226@psf.upfronthosting.co.za> Message-ID: <1421251912.69.0.272329651164.issue23226@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 17:15:19 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 14 Jan 2015 16:15:19 +0000 Subject: [issue23234] refactor subprocess: use new OSError exceptions, factorize stdin.write() code In-Reply-To: <1421192461.64.0.911516234193.issue23234@psf.upfronthosting.co.za> Message-ID: <20150114160850.22409.38527@psf.io> Roundup Robot added the comment: New changeset 0c5ae257966f by Victor Stinner in branch 'default': Closes #23234: Refactor subprocess https://hg.python.org/cpython/rev/0c5ae257966f ---------- nosy: +python-dev stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 17:15:29 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 14 Jan 2015 16:15:29 +0000 Subject: [issue23197] asyncio: check if a future is cancelled before calling set_result/set_exception In-Reply-To: <1420762312.46.0.962527500609.issue23197@psf.upfronthosting.co.za> Message-ID: <20150114161446.72561.47015@psf.io> Roundup Robot added the comment: New changeset 42f4dfc6c6a9 by Victor Stinner in branch '3.4': Issue #23197: On SSL handshake failure on matching hostname, check if the https://hg.python.org/cpython/rev/42f4dfc6c6a9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 17:15:31 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 14 Jan 2015 16:15:31 +0000 Subject: [issue23197] asyncio: check if a future is cancelled before calling set_result/set_exception In-Reply-To: <1420762312.46.0.962527500609.issue23197@psf.upfronthosting.co.za> Message-ID: <20150114160120.11579.52820@psf.io> Roundup Robot added the comment: New changeset c9ad45b15919 by Victor Stinner in branch '3.4': Issue #23197, asyncio: On SSL handshake failure, check if the waiter is https://hg.python.org/cpython/rev/c9ad45b15919 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 17:16:41 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Jan 2015 16:16:41 +0000 Subject: [issue23197] asyncio: check if a future is cancelled before calling set_result/set_exception In-Reply-To: <1420762312.46.0.962527500609.issue23197@psf.upfronthosting.co.za> Message-ID: <1421252201.24.0.852391666981.issue23197@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, I commited my changes to Python 3.4, Python 3.5 and Tulip. All calls to set_result/set_exception should now be protected by a check on the future state. There is now a new class of bugs, but it's a different issue: https://code.google.com/p/tulip/issues/detail?id=218 I close this issue. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 17:43:46 2015 From: report at bugs.python.org (Gustavo Temple) Date: Wed, 14 Jan 2015 16:43:46 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1421253826.42.0.834146535973.issue22038@psf.upfronthosting.co.za> Gustavo Temple added the comment: @haypo, I checked and your idea and implementation are very good, thank you very much. Yes, there is a Clang-specific implementation of the stdatomic.h header [1]. The Musl libc for example created a stdatomic.h header with full compatibility [2]. [1] http://llvm.org/viewvc/llvm-project?view=revision&revision=218957 [2] http://www.openwall.com/lists/musl/2014/11/09/2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 18:23:28 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 14 Jan 2015 17:23:28 +0000 Subject: [issue23239] SSL match_hostname does not accept IP Address In-Reply-To: <1421226292.77.0.451398063166.issue23239@psf.upfronthosting.co.za> Message-ID: <1421256208.65.0.919650893983.issue23239@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> needs patch type: security -> enhancement versions: -Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 18:24:27 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 14 Jan 2015 17:24:27 +0000 Subject: [issue23239] SSL match_hostname does not accept IP Address In-Reply-To: <1421226292.77.0.451398063166.issue23239@psf.upfronthosting.co.za> Message-ID: <1421256267.65.0.505952149272.issue23239@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This is a feature request. Not supporting IP addresses is a documented limitation of the current implementation. ---------- nosy: +christian.heimes, dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 18:57:47 2015 From: report at bugs.python.org (William Scullin) Date: Wed, 14 Jan 2015 17:57:47 +0000 Subject: [issue18835] Add aligned memory variants to the suite of PyMem functions/macros In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za> Message-ID: <1421258267.5.0.50882014524.issue18835@psf.upfronthosting.co.za> Changes by William Scullin : ---------- nosy: +wscullin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 21:22:21 2015 From: report at bugs.python.org (Davin Potts) Date: Wed, 14 Jan 2015 20:22:21 +0000 Subject: [issue23051] multiprocessing.pool methods imap()[_unordered()] deadlock In-Reply-To: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za> Message-ID: <1421266941.01.0.624693580286.issue23051@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 23:22:06 2015 From: report at bugs.python.org (Davin Potts) Date: Wed, 14 Jan 2015 22:22:06 +0000 Subject: [issue23051] multiprocessing.pool methods imap()[_unordered()] deadlock In-Reply-To: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za> Message-ID: <1421274126.58.0.344791903071.issue23051@psf.upfronthosting.co.za> Davin Potts added the comment: Successfully reproduced the behavior playing through variations with the supplied examples (very helpful) on OS X v10.9.5 both in 2.7.9 and the default branch -- adding version 3.5 to issue. Also successfully verified that the supplied patches do just as advertised on same: OS X v10.9.5, both 2.7.9 and default branch. The patches' addition of a try around that for block looks like a sensible choice. At the moment, I do not yet fully understand what the patches' exception block is doing with the 'cache[job]._set' call the way it is, but I would like to spend more time to digest it better -- I hope to do so later this week. ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 23:27:13 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 14 Jan 2015 22:27:13 +0000 Subject: [issue5804] Add an 'offset' argument to zlib.decompress In-Reply-To: <1240307503.01.0.128578916914.issue5804@psf.upfronthosting.co.za> Message-ID: <1421274433.79.0.526811757381.issue5804@psf.upfronthosting.co.za> Martin Panter added the comment: A different test case for ?unused_data? attribute was added in 2012 for Issue 16350, so that part is no longer needed. If this feature goes ahead, it might be nice to also update the bzip and LZMA modules for consistency. In Python 3, the equivalent of the buffer() option would look like this, assuming the memory view is in byte format: zlib.decompress(memoryview(source)[unused_offset:]) Another option would be to copy some paint from the struct.unpack_from() bikeshed: [data, offset] = zlib.decompress_from(buffer, offset) ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 14 23:35:20 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Jan 2015 22:35:20 +0000 Subject: [issue22560] New SSL implementation based on ssl.MemoryBIO In-Reply-To: <1412548102.84.0.685230620276.issue22560@psf.upfronthosting.co.za> Message-ID: <1421274920.58.0.362888250388.issue22560@psf.upfronthosting.co.za> STINNER Victor added the comment: While I tried to write an unit test to reproduce a bug (cancelled waiter), I noticed that the handshake callback of the protocol can be called indirectly from _process_write_backlog(). So _process_write_backlog() may be called indirectly from _process_write_backlog(), whereas this function doesn't support reentrant call. A fix is to modify the handshake callback to schedule a call to _process_write_backlog(), instead of calling it immediatly. Note: The shutdown callback doesn't have this issue, it only calls transport.close(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 00:11:18 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Jan 2015 23:11:18 +0000 Subject: [issue23242] asyncio: Process must close the transport when the process exit Message-ID: <1421277078.82.0.431621848437.issue23242@psf.upfronthosting.co.za> New submission from STINNER Victor: The asyncio.subprocess.Process class never closes the subprocess transport, whereas this transport is private. I propose to close the transport as soon as possible: when transport.get_returncode() is called and its result is not None. I'm not sure that it's the most efficient way to close the transport. It may be better to close the transport in the connection_lost() method of the protocol. The patch also checks in Process.communicate() that the process is alive, and is clears the reference to the transport. ---------- components: asyncio files: subprocess_close.patch keywords: patch messages: 234042 nosy: gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio: Process must close the transport when the process exit versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37707/subprocess_close.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 00:18:04 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Jan 2015 23:18:04 +0000 Subject: [issue23243] asyncio: emit ResourceWarning warnings if transports/event loops are not explicitly closed Message-ID: <1421277484.12.0.751563251482.issue23243@psf.upfronthosting.co.za> New submission from STINNER Victor: I propose to add destructors to transports and event loops which emit a ResourceWarning if they are not closed. The change should help to detect resource leaks and bugs. Attached patch implements this issue. It only adds destructors on Python 3.4 and later, because older Python versions don't implement the PEP 442 (Safe object finalization) and so objects part of reference cycle would never be deleted. The patch adds a new _closed attribute to BaseSubprocessTransport and _SSLProtocolTransport classes, to track if the transport was closed or not. The patch should help to find bugs like this one: https://code.google.com/p/tulip/issues/detail?id=218 ---------- components: asyncio files: resource_warnings.patch keywords: patch messages: 234043 nosy: gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio: emit ResourceWarning warnings if transports/event loops are not explicitly closed versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37708/resource_warnings.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 00:48:36 2015 From: report at bugs.python.org (Jakub Wilk) Date: Wed, 14 Jan 2015 23:48:36 +0000 Subject: [issue8450] httplib: false BadStatusLine() raised In-Reply-To: <1271630731.08.0.327097174192.issue8450@psf.upfronthosting.co.za> Message-ID: <1421279316.51.0.625301126374.issue8450@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 00:49:33 2015 From: report at bugs.python.org (Jakub Wilk) Date: Wed, 14 Jan 2015 23:49:33 +0000 Subject: [issue17239] XML vulnerabilities in Python In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za> Message-ID: <1421279373.34.0.703171264525.issue17239@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 03:16:20 2015 From: report at bugs.python.org (David Coles) Date: Thu, 15 Jan 2015 02:16:20 +0000 Subject: [issue22970] Cancelling wait() after notification leaves Condition in an inconsistent state In-Reply-To: <1417404582.01.0.276361050449.issue22970@psf.upfronthosting.co.za> Message-ID: <1421288180.98.0.524650298649.issue22970@psf.upfronthosting.co.za> David Coles added the comment: Hi Victor, (Sorry for the delay, I think GMail ate the notification) The main issue is that Condition.wait MUST reacquire the associated lock released on entry to wait() before returning or else the caller's assumption that it holds a lock (such as `with lock:`) will be incorrect. With the threading module, it's typically not possible to interrupt or cancel lock acquisition (no Thread.interrupt for example). Even on Python 3.2 where lock acquisition can be interrupted by POSIX signals, Condition.wait's implementation uses the non-interruptable lock._acquire_restore (calls rlock_acquire_restore ? PyThread_acquire_lock ? PyThread_acquire_lock ? PyThread_acquire_lock_timed with intr=0 [Python/thread_pthread.h] which does the uninterruptable retry loop). So, not a problem for threading.Condition.wait(). As for re-raising the CancelledError after the lock is reacquired, I'm not sure it serves any useful purpose to the caller since by this point we're either in the process of waking up after a notify() or already raising an exception (such as a CancelledError if someone called task.cancel() _before_ the condition was notified). Making the caller also handle re-acquisition failure would be quite messy. For example, one idea would be to have the caller check cond.locked() after a CancelledError and have the caller reacquire, but it turns in asyncio you can't tell whom owns the lock (could have been grabbed by another task). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 03:38:22 2015 From: report at bugs.python.org (memkmemk) Date: Thu, 15 Jan 2015 02:38:22 +0000 Subject: [issue23238] http.server failed to decode '+' to ' ' when calling cgi script/executable in window In-Reply-To: <1421225956.24.0.0678998380513.issue23238@psf.upfronthosting.co.za> Message-ID: <1421289502.68.0.241081783968.issue23238@psf.upfronthosting.co.za> memkmemk added the comment: OK. Here is the exact things I did. All the txt is in the attached codes.zip I was playing around with python -m http.server --cgi and decided to make a java cgi. So 1. I created one and compile it. (hellojava.java) 2. Test run it in console. (c1.txt) 3. as java class file cannot be directly executed, so I create a little batch file to run it. (runjava.bat) 4. and tested it in console (c3.txt) 5. start up the http.server --cgi (c2.txt) 6. then I fire up my firefox 35.0 and go to URL http://127.0.0.1:8000/cgi-bin/runjava.bat?hellojava 7. and got the expected result (r1.txt) 8. and the console of the http.server show expected result (cr1.txt) 9. then I try to pass parameter into the java cgi itself, so I go to URL http://127.0.0.1:8000/cgi-bin/runjava.bat?hellojava+test 10. results in an blank page, actual response is also blank. 11. console shows error message (cr2.txt) 12. so I run the generated command in actual console and get the same error (cr3.txt, I am using Chinese locale so I put the actual error and English on line 3) 13. and if I replace the '+' with ' ' in the command it will work as expected. (cr4.txt) ---------- Added file: http://bugs.python.org/file37709/codes.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 03:44:45 2015 From: report at bugs.python.org (David Coles) Date: Thu, 15 Jan 2015 02:44:45 +0000 Subject: [issue22970] Cancelling wait() after notification leaves Condition in an inconsistent state In-Reply-To: <1417404582.01.0.276361050449.issue22970@psf.upfronthosting.co.za> Message-ID: <1421289885.76.0.916540179371.issue22970@psf.upfronthosting.co.za> David Coles added the comment: Just for context, the reason for using a custom wait function (cond_wait_timeout) rather than the more idiomatic asyncio.wait_for(cond.wait(), timeout) is that the combination introduces another subtle, but nasty locking inconsistency (see https://groups.google.com/forum/#!topic/python-tulip/eSm7rZAe9LM ). Should probably open a ticket for that issue too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 05:40:01 2015 From: report at bugs.python.org (N0v1ce Llve) Date: Thu, 15 Jan 2015 04:40:01 +0000 Subject: [issue23244] doc typo in 'Glossary': 'generator' Message-ID: <1421296801.34.0.273749037351.issue23244@psf.upfronthosting.co.za> New submission from N0v1ce Llve: 'a series a values' in the description of 'generator' in 'Glossary' should be 'a series of values'. Take the online documentation for example, the whole sentence is - > It looks like a normal function except that it contains yield statements for producing **a series a values** usable in a for-loop or that can be retrieved one at a time with the next() function. :) ---------- assignee: docs at python components: Documentation messages: 234047 nosy: docs at python, n0vicelive priority: normal severity: normal status: open title: doc typo in 'Glossary': 'generator' 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 15 05:43:12 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 15 Jan 2015 04:43:12 +0000 Subject: [issue13881] Stream encoder for zlib_codec doesn't use the incremental encoder In-Reply-To: <1327606849.1.0.885842099772.issue13881@psf.upfronthosting.co.za> Message-ID: <1421296992.32.0.202312696753.issue13881@psf.upfronthosting.co.za> Martin Panter added the comment: New patch that also fixes StreamWriter.writelines() in general for the byte codecs ---------- Added file: http://bugs.python.org/file37710/zlib-bz2-writer.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 05:44:02 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 15 Jan 2015 04:44:02 +0000 Subject: [issue17546] Document the circumstances where the locals() dict get updated In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za> Message-ID: <1421297042.26.0.323658198265.issue17546@psf.upfronthosting.co.za> Ethan Furman added the comment: Combined the second and last lines, discarded duplication. ---------- nosy: +ethan.furman versions: +Python 3.5 Added file: http://bugs.python.org/file37711/issue17546.stoneleaf.01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 05:56:50 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 15 Jan 2015 04:56:50 +0000 Subject: [issue18986] Add a case-insensitive case-preserving dict In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za> Message-ID: <1421297810.1.0.684352207598.issue18986@psf.upfronthosting.co.za> Ethan Furman added the comment: 3.5 is almost here; Raymond, care to make a ruling? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 06:00:39 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 15 Jan 2015 05:00:39 +0000 Subject: [issue23063] `python setup.py check --restructuredtext --strict --metadata` fails with: `warning: check: Could not finish the parsing.` if the RST document uses code or code-block directives. In-Reply-To: <1418716685.25.0.847417973192.issue23063@psf.upfronthosting.co.za> Message-ID: <20150115050025.125884.7224@psf.io> Roundup Robot added the comment: New changeset db09d760b965 by Benjamin Peterson in branch '3.4': fix parsing reST with code or code-block directives (closes #23063) https://hg.python.org/cpython/rev/db09d760b965 New changeset 38826e21f0db by Benjamin Peterson in branch '2.7': fix parsing reST with code or code-block directives (closes #23063) https://hg.python.org/cpython/rev/38826e21f0db New changeset 731a36c13629 by Benjamin Peterson in branch 'default': merge 3.4 (#23063) https://hg.python.org/cpython/rev/731a36c13629 ---------- nosy: +python-dev resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 06:02:36 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 15 Jan 2015 05:02:36 +0000 Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or operator.index() docos lie) In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za> Message-ID: <1421298156.32.0.367259149902.issue17576@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- assignee: -> ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 06:07:28 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 15 Jan 2015 05:07:28 +0000 Subject: [issue20680] Pickle socket enums by names In-Reply-To: <1392758039.35.0.851373733794.issue20680@psf.upfronthosting.co.za> Message-ID: <1421298448.71.0.464865032694.issue20680@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- assignee: -> ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 06:07:58 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 15 Jan 2015 05:07:58 +0000 Subject: [issue20773] Improve docs for DynamicClassAttribute In-Reply-To: <1393362749.08.0.709900927194.issue20773@psf.upfronthosting.co.za> Message-ID: <1421298478.65.0.816952551838.issue20773@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- assignee: -> ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 06:20:52 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 15 Jan 2015 05:20:52 +0000 Subject: [issue17422] language reference should specify restrictions on class namespace In-Reply-To: <1363293215.19.0.289288553848.issue17422@psf.upfronthosting.co.za> Message-ID: <1421299252.77.0.434838925217.issue17422@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- keywords: +patch stage: needs patch -> patch review versions: +Python 3.5 Added file: http://bugs.python.org/file37712/issue17422.stoneleaf.01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 06:27:38 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 15 Jan 2015 05:27:38 +0000 Subject: [issue22986] Improved handling of __class__ assignment In-Reply-To: <1417563561.24.0.575634102448.issue22986@psf.upfronthosting.co.za> Message-ID: <1421299658.17.0.332322409839.issue22986@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Why do you have all these special cases of ref-counting based on Py_TPFLAGS_HEAPTYPE? "static" types are generally ref-counted, too. (They just hopefully don't reach 0 often. :)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 06:31:37 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 15 Jan 2015 05:31:37 +0000 Subject: [issue22986] Improved handling of __class__ assignment In-Reply-To: <1417563561.24.0.575634102448.issue22986@psf.upfronthosting.co.za> Message-ID: <1421299897.68.0.582528150573.issue22986@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Oh, I forgot references to non-heaptypes in the header don't count... objects now being able to transmute between heap and heap-type really makes for a nice can of worms. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 06:58:30 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 15 Jan 2015 05:58:30 +0000 Subject: [issue20467] Confusing wording about __init__ In-Reply-To: <1391208094.95.0.178232051767.issue20467@psf.upfronthosting.co.za> Message-ID: <20150115055754.8765.1796@psf.io> Roundup Robot added the comment: New changeset 94696e457461 by Ethan Furman in branch '3.3': Issue20467: clarify __init__'s role https://hg.python.org/cpython/rev/94696e457461 New changeset 46c9b34f31b8 by Ethan Furman in branch '3.4': Issue20467: clarify __init__'s role https://hg.python.org/cpython/rev/46c9b34f31b8 New changeset d0421de8ee11 by Ethan Furman in branch 'default': Issue20467: clarify __init__'s role https://hg.python.org/cpython/rev/d0421de8ee11 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 07:01:34 2015 From: report at bugs.python.org (Douman) Date: Thu, 15 Jan 2015 06:01:34 +0000 Subject: [issue23245] urllib2: urlopen() gets exception(kwargs bug?) Message-ID: <1421301694.48.0.880647525512.issue23245@psf.upfronthosting.co.za> New submission from Douman: I get strange callstack from urllib2 It seems that python thinks that HTTPSConnection doesn't have context argument. Which is entirely incorrect. I have suspicions that this is related to the way how context argument is passed(kwargs) This happens starting from python 2.7.9 ---------- components: Extension Modules files: callstack_urllib2 messages: 234055 nosy: Douman priority: normal severity: normal status: open title: urllib2: urlopen() gets exception(kwargs bug?) type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file37713/callstack_urllib2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 07:02:56 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 15 Jan 2015 06:02:56 +0000 Subject: [issue20467] Confusing wording about __init__ In-Reply-To: <1391208094.95.0.178232051767.issue20467@psf.upfronthosting.co.za> Message-ID: <20150115060235.11581.92540@psf.io> Roundup Robot added the comment: New changeset 7972b18b6e42 by Ethan Furman in branch '2.7': Issue20467: clarify __init__'s role https://hg.python.org/cpython/rev/7972b18b6e42 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 07:05:55 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 15 Jan 2015 06:05:55 +0000 Subject: [issue20467] Confusing wording about __init__ In-Reply-To: <1391208094.95.0.178232051767.issue20467@psf.upfronthosting.co.za> Message-ID: <1421301955.78.0.627446076241.issue20467@psf.upfronthosting.co.za> Ethan Furman added the comment: Changed 'no value may be returned' to 'no non-None value may be returned'. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 07:26:35 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 15 Jan 2015 06:26:35 +0000 Subject: [issue22988] No error when yielding from `finally` In-Reply-To: <1417629074.29.0.62488033247.issue22988@psf.upfronthosting.co.za> Message-ID: <20150115062629.3960.61719@psf.io> Roundup Robot added the comment: New changeset 0e48b0908651 by Ethan Furman in branch '3.4': Issue22988: clarify yield and exception blocks https://hg.python.org/cpython/rev/0e48b0908651 New changeset 55ba19d084fb by Ethan Furman in branch 'default': Issue22988: clarify yield and exception blocks https://hg.python.org/cpython/rev/55ba19d084fb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 07:27:19 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 15 Jan 2015 06:27:19 +0000 Subject: [issue22988] No error when yielding from `finally` In-Reply-To: <1417629074.29.0.62488033247.issue22988@psf.upfronthosting.co.za> Message-ID: <1421303239.69.0.945246670445.issue22988@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 07:32:56 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 15 Jan 2015 06:32:56 +0000 Subject: [issue22988] No error when yielding from `finally` In-Reply-To: <1417629074.29.0.62488033247.issue22988@psf.upfronthosting.co.za> Message-ID: <1421303576.85.0.867694800791.issue22988@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 07:32:58 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 15 Jan 2015 06:32:58 +0000 Subject: [issue22997] Minor improvements to "Functional API" section of Enum documentation In-Reply-To: <1417713019.92.0.36560038902.issue22997@psf.upfronthosting.co.za> Message-ID: <20150115063253.72575.74957@psf.io> Roundup Robot added the comment: New changeset 522d13d8e76e by Ethan Furman in branch '3.4': Issue22997: minor doc update; thanks to Simoen Visser https://hg.python.org/cpython/rev/522d13d8e76e New changeset 31ae2dcaaed8 by Ethan Furman in branch 'default': Issue22997: minor doc update; thanks to Simoen Visser https://hg.python.org/cpython/rev/31ae2dcaaed8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 07:33:35 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 15 Jan 2015 06:33:35 +0000 Subject: [issue22997] Minor improvements to "Functional API" section of Enum documentation In-Reply-To: <1417713019.92.0.36560038902.issue22997@psf.upfronthosting.co.za> Message-ID: <1421303615.03.0.284228076104.issue22997@psf.upfronthosting.co.za> Ethan Furman added the comment: Thank you, Simeon! ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 07:36:45 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 15 Jan 2015 06:36:45 +0000 Subject: [issue22997] Minor improvements to "Functional API" section of Enum documentation In-Reply-To: <1417713019.92.0.36560038902.issue22997@psf.upfronthosting.co.za> Message-ID: <1421303805.96.0.992691253081.issue22997@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 08:13:50 2015 From: report at bugs.python.org (Mayank Tripathi) Date: Thu, 15 Jan 2015 07:13:50 +0000 Subject: [issue23244] doc typo in 'Glossary': 'generator' In-Reply-To: <1421296801.34.0.273749037351.issue23244@psf.upfronthosting.co.za> Message-ID: <1421306030.73.0.581309890903.issue23244@psf.upfronthosting.co.za> Changes by Mayank Tripathi : ---------- keywords: +patch Added file: http://bugs.python.org/file37714/generator_typo.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 08:16:44 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 15 Jan 2015 07:16:44 +0000 Subject: [issue23244] doc typo in 'Glossary': 'generator' In-Reply-To: <1421296801.34.0.273749037351.issue23244@psf.upfronthosting.co.za> Message-ID: <20150115071633.125910.76691@psf.io> Roundup Robot added the comment: New changeset 25a1ce2a6f9b by Georg Brandl in branch '2.7': Closes #23244: fix typo. Thanks Mayank Tripathi for the patch. https://hg.python.org/cpython/rev/25a1ce2a6f9b New changeset 3e4d4c4968bb by Georg Brandl in branch '3.4': Closes #23244: fix typo. Thanks Mayank Tripathi for the patch. https://hg.python.org/cpython/rev/3e4d4c4968bb ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 08:28:37 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 15 Jan 2015 07:28:37 +0000 Subject: [issue18986] Add a case-insensitive case-preserving dict In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za> Message-ID: <1421306917.47.0.080895724567.issue18986@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Yes. I intend to button this one up before long. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 09:16:03 2015 From: report at bugs.python.org (Piotr Dobrogost) Date: Thu, 15 Jan 2015 08:16:03 +0000 Subject: [issue22028] Python 3.4.1 Installer ended prematurely (Windows msi) In-Reply-To: <1405994666.12.0.143457311308.issue22028@psf.upfronthosting.co.za> Message-ID: <1421309763.67.0.372270709557.issue22028@psf.upfronthosting.co.za> Changes by Piotr Dobrogost : ---------- nosy: +piotr.dobrogost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 09:24:41 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 15 Jan 2015 08:24:41 +0000 Subject: [issue23209] asyncio: break some cycles In-Reply-To: <1420823775.21.0.0191485458241.issue23209@psf.upfronthosting.co.za> Message-ID: <1421310281.39.0.414543354451.issue23209@psf.upfronthosting.co.za> STINNER Victor added the comment: I noticed that _ProactorBasePipeTransport doesn't clear its reference to the socket when it is closed. I changed this in the following commit (now merged in Python 3.4 & 3.5): https://code.google.com/p/tulip/source/detail?r=61ce7def97272ab1a6488545dc392160c2fbe316 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 09:42:26 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 15 Jan 2015 08:42:26 +0000 Subject: [issue22560] New SSL implementation based on ssl.MemoryBIO In-Reply-To: <1412548102.84.0.685230620276.issue22560@psf.upfronthosting.co.za> Message-ID: <20150115084222.11585.27456@psf.io> Roundup Robot added the comment: New changeset fb3761de0d3c by Victor Stinner in branch '3.4': Issue #22560: Fix SSLProtocol._on_handshake_complete() https://hg.python.org/cpython/rev/fb3761de0d3c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 09:45:25 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 15 Jan 2015 08:45:25 +0000 Subject: [issue22560] New SSL implementation based on ssl.MemoryBIO In-Reply-To: <1412548102.84.0.685230620276.issue22560@psf.upfronthosting.co.za> Message-ID: <20150115084509.58298.27379@psf.io> Roundup Robot added the comment: New changeset 3c37825d85d3 by Victor Stinner in branch '3.4': Issue #22560: Fix typo: call -> call_soon https://hg.python.org/cpython/rev/3c37825d85d3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 09:46:17 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 15 Jan 2015 08:46:17 +0000 Subject: [issue22560] New SSL implementation based on ssl.MemoryBIO In-Reply-To: <1412548102.84.0.685230620276.issue22560@psf.upfronthosting.co.za> Message-ID: <1421311577.49.0.841076282636.issue22560@psf.upfronthosting.co.za> STINNER Victor added the comment: Buildbots are happy. There is no remaining things to do, I close the issue. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From mal at egenix.com Thu Jan 15 09:48:44 2015 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 15 Jan 2015 09:48:44 +0100 Subject: [issue13881] Stream encoder for zlib_codec doesn't use the incremental encoder In-Reply-To: <1421296992.32.0.202312696753.issue13881@psf.upfronthosting.co.za> References: <1421296992.32.0.202312696753.issue13881@psf.upfronthosting.co.za> Message-ID: <54B77EEC.5050503@egenix.com> On 15.01.2015 05:43, Martin Panter wrote: > > New patch that also fixes StreamWriter.writelines() in general for the byte codecs Could you explain this new undocumented class ? +class _IncrementalBasedWriter(StreamWriter): + """Generic StreamWriter implementation. + + The _EncoderClass attribute must be set to an IncrementalEncoder + class to use. + """ + + def __init__(self, stream, errors='strict'): + super().__init__(stream, errors) + self._encoder = self._Encoder(errors) + + def write(self, object): + self.stream.write(self._encoder.encode(object)) + + def reset(self): + self.stream.write(self._encoder.encode(final=True)) + Note that the doc-string mentions a non-existing attribute and there are doc-string missing for the other methods. The purpose appears to be a StreamWriter which works with an IncrementalEncoder. A proper name would thus be IncrementalStreamWriter which provides an .encode() method which adapts the signature of the incremental encoder to the one expected for StreamWriters and Codecs. -- Marc-Andre Lemburg eGenix.com From report at bugs.python.org Thu Jan 15 09:48:52 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 15 Jan 2015 08:48:52 +0000 Subject: [issue13881] Stream encoder for zlib_codec doesn't use the incremental encoder In-Reply-To: <1421296992.32.0.202312696753.issue13881@psf.upfronthosting.co.za> Message-ID: <54B77EEC.5050503@egenix.com> Marc-Andre Lemburg added the comment: On 15.01.2015 05:43, Martin Panter wrote: > > New patch that also fixes StreamWriter.writelines() in general for the byte codecs Could you explain this new undocumented class ? +class _IncrementalBasedWriter(StreamWriter): + """Generic StreamWriter implementation. + + The _EncoderClass attribute must be set to an IncrementalEncoder + class to use. + """ + + def __init__(self, stream, errors='strict'): + super().__init__(stream, errors) + self._encoder = self._Encoder(errors) + + def write(self, object): + self.stream.write(self._encoder.encode(object)) + + def reset(self): + self.stream.write(self._encoder.encode(final=True)) + Note that the doc-string mentions a non-existing attribute and there are doc-string missing for the other methods. The purpose appears to be a StreamWriter which works with an IncrementalEncoder. A proper name would thus be IncrementalStreamWriter which provides an .encode() method which adapts the signature of the incremental encoder to the one expected for StreamWriters and Codecs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 09:56:12 2015 From: report at bugs.python.org (Petr Viktorin) Date: Thu, 15 Jan 2015 08:56:12 +0000 Subject: [issue22198] Odd floor-division corner case In-Reply-To: <1408034861.79.0.503776123394.issue22198@psf.upfronthosting.co.za> Message-ID: <1421312172.14.0.428846745868.issue22198@psf.upfronthosting.co.za> Petr Viktorin added the comment: ping, is there anything I can do to help push the patch forward? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 10:18:52 2015 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 15 Jan 2015 09:18:52 +0000 Subject: [issue22198] Odd floor-division corner case In-Reply-To: <1408034861.79.0.503776123394.issue22198@psf.upfronthosting.co.za> Message-ID: <1421313532.59.0.543824253551.issue22198@psf.upfronthosting.co.za> Mark Dickinson added the comment: The patch is fine; I just need to find time to look at it properly. That might take a week or two. Sorry for the delay. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 13:25:43 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 15 Jan 2015 12:25:43 +0000 Subject: [issue23242] asyncio: Process must close the transport when the process exit In-Reply-To: <1421277078.82.0.431621848437.issue23242@psf.upfronthosting.co.za> Message-ID: <20150115122510.11583.33994@psf.io> Roundup Robot added the comment: New changeset df493e9c6821 by Victor Stinner in branch '3.4': Issue #23242: asyncio.SubprocessStreamProtocol now closes the subprocess https://hg.python.org/cpython/rev/df493e9c6821 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 13:25:44 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 15 Jan 2015 12:25:44 +0000 Subject: [issue23243] asyncio: emit ResourceWarning warnings if transports/event loops are not explicitly closed In-Reply-To: <1421277484.12.0.751563251482.issue23243@psf.upfronthosting.co.za> Message-ID: <20150115122510.11583.80158@psf.io> Roundup Robot added the comment: New changeset 2f13d53f4680 by Victor Stinner in branch '3.4': Issue #23243: Fix asyncio._UnixWritePipeTransport.close() https://hg.python.org/cpython/rev/2f13d53f4680 New changeset aef0f9b4e729 by Victor Stinner in branch '3.4': Issue #23243: Close explicitly event loops in asyncio tests https://hg.python.org/cpython/rev/aef0f9b4e729 New changeset f9b127188d43 by Victor Stinner in branch '3.4': Issue #23243: Close explicitly transports in asyncio tests https://hg.python.org/cpython/rev/f9b127188d43 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 14:09:40 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 15 Jan 2015 13:09:40 +0000 Subject: [issue17546] Document the circumstances where the locals() dict get updated In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za> Message-ID: <1421327380.94.0.692494038597.issue17546@psf.upfronthosting.co.za> R. David Murray added the comment: Your formulation is more concise, thank you. I suggest dropping the word 'additionally'. Also, "how it does" would be better phrased as "how it changes", I think. (It really should be "whether and how it changes", but in deference to Anatoly's 'advanced English' comment I'm willing to let that imprecision slide). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 14:18:31 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 15 Jan 2015 13:18:31 +0000 Subject: [issue23245] urllib2: urlopen() gets exception(kwargs bug?) In-Reply-To: <1421301694.48.0.880647525512.issue23245@psf.upfronthosting.co.za> Message-ID: <1421327911.38.0.668071689929.issue23245@psf.upfronthosting.co.za> R. David Murray added the comment: More likely http_class isn't what you think it is (ie: it might be an HTTPSConnection subclass that hasn't been updated to deal with 2.7.9. Can you check that? ---------- components: +Library (Lib) -Extension Modules nosy: +alex, r.david.murray type: compile error -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 14:35:23 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 15 Jan 2015 13:35:23 +0000 Subject: [issue23243] asyncio: emit ResourceWarning warnings if transports/event loops are not explicitly closed In-Reply-To: <1421277484.12.0.751563251482.issue23243@psf.upfronthosting.co.za> Message-ID: <1421328923.21.0.487510345045.issue23243@psf.upfronthosting.co.za> STINNER Victor added the comment: I fixed a lot of methods and tests to ensure that all event loops and transports are properly closed. These changes were required to prepare the integration of this change. Many changed were real bug fixes: closing explicitly tranports on error avoids to leak resources. Some ResourceWarning are still emited on SSL server tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 14:36:57 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 15 Jan 2015 13:36:57 +0000 Subject: [issue23242] asyncio: Process must close the transport when the process exit In-Reply-To: <1421277078.82.0.431621848437.issue23242@psf.upfronthosting.co.za> Message-ID: <1421329017.02.0.67237385116.issue23242@psf.upfronthosting.co.za> STINNER Victor added the comment: > I'm not sure that it's the most efficient way to close the transport. It may be better to close the transport in the connection_lost() method of the protocol. "process_exited", not "connection_lost". I implemented this option which is simpler and more efficient (always and immediatly close the transport). Clearing the reference to the transport in the Process is less important, it can be done later in a different issue/changeset. I close this issue. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 15:25:02 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 15 Jan 2015 14:25:02 +0000 Subject: [issue17546] Document the circumstances where the locals() dict get updated In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za> Message-ID: <1421331902.58.0.0662711313709.issue17546@psf.upfronthosting.co.za> Martin Panter added the comment: What about instead of ''' Whether changes to one are reflected in the other after the call returns is undefined; additionally, the dictionary may change unpredictably after the call, and how it does is implementation-specific. ''' substitue this wording: ''' Whether changes to one are reflected in the other after the call returns, and when such updates occur, is undefined and implementation-specific. ''' The old wording seems under-specified. It would allow a function call, garbage collection, etc, to clobber the dictionary, say overwriting with another function?s locals(), before you get a chance to work with the dictionary. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 15:29:10 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 15 Jan 2015 14:29:10 +0000 Subject: [issue18986] Add a case-insensitive case-preserving dict In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za> Message-ID: <1421332150.48.0.320777602173.issue18986@psf.upfronthosting.co.za> Martin Panter added the comment: For the record, this is related to PEP 455 (key-transforming dictionary) ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 15:59:23 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 15 Jan 2015 14:59:23 +0000 Subject: [issue17546] Document the circumstances where the locals() dict get updated In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za> Message-ID: <1421333963.23.0.133175030007.issue17546@psf.upfronthosting.co.za> R. David Murray added the comment: Yeah, the question of thread-safety in regards to what we are talking about here also occurred to me. That is, the wording makes one wonder if locals is thread safe or not. I don't see your suggested wording as making it clearer, though. The problem is that it *is* underspecified. So I think the correct description of the current under-specification is that locals() returns a copy of the current locals namespace. If you modify the thing returned by locals it may or may not update the local namespace. If you modify the local namespace (by doing x = y or its equivalents) the change may or may not be reflected in the object that was returned by locals(). Now, how do we boil that down? Or do we just say it more or less that way? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 16:28:23 2015 From: report at bugs.python.org (Robert Kuska) Date: Thu, 15 Jan 2015 15:28:23 +0000 Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs) In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za> Message-ID: <1421335703.59.0.309274803161.issue20160@psf.upfronthosting.co.za> Robert Kuska added the comment: FYI The bug was found in libffi. I have tried and rebuilt python also with *bundled libffi* with the *same result* (=test failure). There is more info in the bugzilla mentioned in my previous post along with the libffi patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 16:30:40 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 15 Jan 2015 15:30:40 +0000 Subject: [issue23219] asyncio: cancelling wait_for(task, timeout) must also cancel the task In-Reply-To: <1420884133.75.0.926989519431.issue23219@psf.upfronthosting.co.za> Message-ID: <20150115153026.11569.75301@psf.io> Roundup Robot added the comment: New changeset 8adf1896712d by Victor Stinner in branch '3.4': Closes #23219: cancelling asyncio.wait_for() now cancels the task https://hg.python.org/cpython/rev/8adf1896712d ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 16:31:44 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 15 Jan 2015 15:31:44 +0000 Subject: [issue23219] asyncio: cancelling wait_for(task, timeout) must also cancel the task In-Reply-To: <1420884133.75.0.926989519431.issue23219@psf.upfronthosting.co.za> Message-ID: <1421335904.64.0.897541949299.issue23219@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- stage: resolved -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 17:02:47 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 15 Jan 2015 16:02:47 +0000 Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs) In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za> Message-ID: <1421337767.8.0.367001320344.issue20160@psf.upfronthosting.co.za> Steve Dower added the comment: You're running on Fedora, not Windows, so this is not the right issue. You should open a new one and probably post on python-dev to get some attention (since there's no useful nosy lists right now and ctypes has no maintainer). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 17:12:25 2015 From: report at bugs.python.org (Douman) Date: Thu, 15 Jan 2015 16:12:25 +0000 Subject: [issue23245] urllib2: urlopen() gets exception(kwargs bug?) In-Reply-To: <1421301694.48.0.880647525512.issue23245@psf.upfronthosting.co.za> Message-ID: <1421338345.28.0.315898155213.issue23245@psf.upfronthosting.co.za> Douman added the comment: Yes, i checked what is http_class. It is passed as httplib.HTTPSConnection Before submitting this issue i checked httplib.py in my installation of py2 and there https://hg.python.org/cpython/file/2.7/Lib/httplib.py HTTPSConnection has argument "context". Btw, it would be nice to update comments in urllib2 so that it would be more accurate ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 17:16:49 2015 From: report at bugs.python.org (Douman) Date: Thu, 15 Jan 2015 16:16:49 +0000 Subject: [issue23245] urllib2: urlopen() gets exception(kwargs bug?) In-Reply-To: <1421301694.48.0.880647525512.issue23245@psf.upfronthosting.co.za> Message-ID: <1421338609.24.0.598701601022.issue23245@psf.upfronthosting.co.za> Douman added the comment: Btw, i also tried to replace **kwargs with usual argument and it didn't throw exception ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 17:36:58 2015 From: report at bugs.python.org (Douman) Date: Thu, 15 Jan 2015 16:36:58 +0000 Subject: [issue23245] urllib2: urlopen() gets exception(kwargs bug?) In-Reply-To: <1421301694.48.0.880647525512.issue23245@psf.upfronthosting.co.za> Message-ID: <1421339818.88.0.931178249689.issue23245@psf.upfronthosting.co.za> Douman added the comment: Also according to documentation this class was specifically updated with context in 2.7.9 I guess then there should commit related to adding of "context" to HTTPSConnection ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 17:42:59 2015 From: report at bugs.python.org (Douman) Date: Thu, 15 Jan 2015 16:42:59 +0000 Subject: [issue23245] urllib2: urlopen() gets exception(kwargs bug?) In-Reply-To: <1421301694.48.0.880647525512.issue23245@psf.upfronthosting.co.za> Message-ID: <1421340179.29.0.441889532336.issue23245@psf.upfronthosting.co.za> Douman added the comment: It seems to be this one https://hg.python.org/cpython/rev/1882157b298a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 17:50:11 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 15 Jan 2015 16:50:11 +0000 Subject: [issue18835] Add aligned memory variants to the suite of PyMem functions/macros In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za> Message-ID: <1421340611.14.0.152670767356.issue18835@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Due to the realloc() problem, I'm thinking that the best course for Numpy would be to use its own allocator wrapper like Nathaniel outligned. Also, Numpy wants calloc() for faster allocation of zeroed arrays... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 18:04:53 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 15 Jan 2015 17:04:53 +0000 Subject: [issue18986] Add a case-insensitive case-preserving dict In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za> Message-ID: <1421341493.73.0.252038996494.issue18986@psf.upfronthosting.co.za> STINNER Victor added the comment: The API is simple and well defined, the addition is small, I don't understand what is the problem with this enhancement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 18:05:44 2015 From: report at bugs.python.org (Douman) Date: Thu, 15 Jan 2015 17:05:44 +0000 Subject: [issue23245] urllib2: urlopen() gets exception(kwargs bug?) In-Reply-To: <1421301694.48.0.880647525512.issue23245@psf.upfronthosting.co.za> Message-ID: <1421341544.18.0.931443219397.issue23245@psf.upfronthosting.co.za> Douman added the comment: I made additional experiments and now i'm confused When i tried to execute urlopen in python interpeter it worked fine. But it fails for me when i attempt to do so via some helper function in search engine of qBittorent it throw exception https://github.com/qbittorrent/qBittorrent/blob/master/src/searchengine/nova/helpers.py What is curious... all exceptions should be passed without notices, but for some reason python does throw exception even though all are catched and passed ---------- Added file: http://bugs.python.org/file37715/callstack_urllib2_full _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 18:18:20 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 15 Jan 2015 17:18:20 +0000 Subject: [issue23018] Add version info to python In-Reply-To: <1418102862.79.0.624047396863.issue23018@psf.upfronthosting.co.za> Message-ID: <20150115171217.8759.39297@psf.io> Roundup Robot added the comment: New changeset 3f7e483cebef by Steve Dower in branch 'default': Issue 23018: Add version info to python[w].exe https://hg.python.org/cpython/rev/3f7e483cebef ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 18:18:30 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 15 Jan 2015 17:18:30 +0000 Subject: [issue23160] Respect the environment variable SVNROOT in external-common.bat In-Reply-To: <1420356909.91.0.987880987929.issue23160@psf.upfronthosting.co.za> Message-ID: <20150115171819.22413.41947@psf.io> Roundup Robot added the comment: New changeset 294501835890 by Steve Dower in branch '2.7': Closes #23160: Respect the environment variable SVNROOT in external-common.bat (patch by anselm.kruis) https://hg.python.org/cpython/rev/294501835890 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 18:18:52 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 15 Jan 2015 17:18:52 +0000 Subject: [issue23160] Respect the environment variable SVNROOT in external-common.bat In-Reply-To: <1420356909.91.0.987880987929.issue23160@psf.upfronthosting.co.za> Message-ID: <20150115171837.22419.22878@psf.io> Roundup Robot added the comment: New changeset 45e2c95bb802 by Steve Dower in branch '3.4': Closes #23160: Respect the environment variable SVNROOT in external-common.bat (patch by anselm.kruis) https://hg.python.org/cpython/rev/45e2c95bb802 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 18:19:25 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 15 Jan 2015 17:19:25 +0000 Subject: [issue23018] Add version info to python In-Reply-To: <1418102862.79.0.624047396863.issue23018@psf.upfronthosting.co.za> Message-ID: <1421342365.47.0.812690636516.issue23018@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> fixed stage: -> patch review status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 18:51:26 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 15 Jan 2015 17:51:26 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <1420230232.09.0.10127303351.issue23152@psf.upfronthosting.co.za> Message-ID: <1421344286.36.0.161828500398.issue23152@psf.upfronthosting.co.za> Steve Dower added the comment: Victor, I've been testing your patch and it's mostly good (a few obscure errors you'd never find without a compiler), but I think we also need to update the win32_xstat functions in posixmodule.c, since they all try and use the same struct. I don't know how familiar you are with the posixmodule functions, so I can study up on them if needed. It's probably due for some simplifications anyway, since we can now assume that Vista's APIs are always available. I think a lot of the functionality there is now in fileutils.c too, so we don't need so much duplicated code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 19:35:17 2015 From: report at bugs.python.org (mattip) Date: Thu, 15 Jan 2015 18:35:17 +0000 Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs) In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za> Message-ID: <1421346917.37.0.702560808741.issue20160@psf.upfronthosting.co.za> mattip added the comment: it seems the problem is that the bundled libffi version in Modules/_ctypes/libffi needs updating. The fix for aarch64 is a simple one-liner (tested on 2.7 in a aarch64 vm), for both HEAD and 2.7 (attached), but perhaps a better fix would be to update the bundled libffi? ---------- Added file: http://bugs.python.org/file37716/libffi.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 19:40:39 2015 From: report at bugs.python.org (mattip) Date: Thu, 15 Jan 2015 18:40:39 +0000 Subject: [issue11835] python (x64) ctypes incorrectly pass structures parameter In-Reply-To: <1302622766.46.0.0398461644853.issue11835@psf.upfronthosting.co.za> Message-ID: <1421347238.98.0.132547287414.issue11835@psf.upfronthosting.co.za> mattip added the comment: This is a duplicate of issue 20160, and has been fixed. Can someone mark it as a duplicate and close it? ---------- nosy: +mattip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 20:21:00 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 15 Jan 2015 19:21:00 +0000 Subject: [issue20898] Missing 507 response description In-Reply-To: <1394637244.26.0.361164120424.issue20898@psf.upfronthosting.co.za> Message-ID: <1421349660.9.0.0402027113433.issue20898@psf.upfronthosting.co.za> Demian Brecht added the comment: Ping. Would be nice to get this change in before 3.5.0a1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 21:35:42 2015 From: report at bugs.python.org (Drekin) Date: Thu, 15 Jan 2015 20:35:42 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1421354141.99.0.835748670803.issue1602@psf.upfronthosting.co.za> Drekin added the comment: File redirection has nothing to do with win-unicode-console and this issue. When stdout is redirected, it is not a tty so win-unicode-console doesn't replace the stream object, which is the right thing to do. You got UnicodeEncodeError because Python creates sys.stdout with encoding based on your locale. In my case it is cp1250 which cannot encode whole Unicode. You can control the encoding used by setting PYTHONIOENCODING environment variable. For example, if you have a script producer.py, which prints some Unicode characters, and consumer.py, which just does print(input()), then "py producer.py | py consumer.py" shows that redirection works (when PYTHONIOENCODING is set e.g. to utf-8). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 23:04:28 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 15 Jan 2015 22:04:28 +0000 Subject: [issue23211] test.test_logging.SMTPHandlerTest failing on Snow Leopard In-Reply-To: <1420832632.4.0.00679469135671.issue23211@psf.upfronthosting.co.za> Message-ID: <1421359468.99.0.364505052771.issue23211@psf.upfronthosting.co.za> Ned Deily added the comment: Yes, this has the same root cause as the failure in Issue20605 since SMTPServer in smtpd.py uses getaddrinfo. I'm now able to reliably reproduce the failure. The system getaddrinfo failure is seen when the OS X 10.6 system's network configuration is *not* using the local mdns for its primary domain service (which can be checked with "scutil --dns"); it fails when using an external dns as its primary dns service. At least that's one failure scenario. In any case, this seems to have been fixed in later versions of OS X, the problem appears to be unique to getaddrinfo (gethostbyname works OK), and it's only this one test. I'm tempted to just close this as "won't fix"; on the other hand, it's easy enough to change this test to use '127.0.0.0' instead of 'localhost'; there are precedents for doing that for other reasons (Issue18792, for example). Here's a patch that does so and thus avoids the potential problem on 10.6. I'll apply it if there are no objections. ---------- keywords: +patch nosy: +vinay.sajip stage: -> patch review versions: +Python 3.4 Added file: http://bugs.python.org/file37717/issue23211.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 23:08:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 15 Jan 2015 22:08:33 +0000 Subject: [issue22685] memory leak: no transport for pipes by create_subprocess_exec/shell In-Reply-To: <1413894821.03.0.250322427022.issue22685@psf.upfronthosting.co.za> Message-ID: <20150115215844.103315.23805@psf.io> Roundup Robot added the comment: New changeset 992ce0dcfb29 by Victor Stinner in branch '3.4': Issue #22685: Fix test_pause_reading() of asyncio/test_subprocess https://hg.python.org/cpython/rev/992ce0dcfb29 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 15 23:46:09 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 15 Jan 2015 22:46:09 +0000 Subject: =?utf-8?q?=5Bissue20132=5D_Many_incremental_codecs_don=E2=80=99t_handle_f?= =?utf-8?q?ragmented_data?= In-Reply-To: <1388929738.44.0.851837204966.issue20132@psf.upfronthosting.co.za> Message-ID: <1421361969.03.0.433840890948.issue20132@psf.upfronthosting.co.za> Martin Panter added the comment: I opened Issue 23231 about fixing iterencode() and iterdecode() in the general case. I added a patch to Issue 13881 to fix StreamWriter for zlib and bz2, and to fix StreamWriter.writelines() in general. I am adding a patch here to clarify the StreamReader API and fix the StreamReader for the zlib-codec. Plan of other things to do: bz2 StreamReader: Should be implemented similar to the zlib patch above, after Issue 15955 is resolved and we have a max_length parameter to use. Or could be based on Bz2File now. hex decoder: Shouldn?t be too hard to hack a stateful IncrementalDecoder that saves the leftover digit if given an odd number of digits. Create a generic codecs._IncrementalStreamReader class that uses an IncrementalDecoder and buffers unread decoded data, similar to my _IncrementalStreamWriter for Issue 13881. base64 encoder: IncrementalEncoder could encode in base64.MAXBINSIZE chunks base64 decoder: IncrementalDecoder could strip non-alphabet characters using regular expressions, decode in multiples of four characters quopri encoder: would require new implementation or major refactoring of quopri module quopri decoder: check for incomplete trailing escape codes (=, =, =\r) and newlines (\r) uu encoder: write header and trailer via uu module; encode using b2a_uu() uu decoder: factor out header parsing from uu module; buffer and decode line by line based on encoded length unicode-escape, raw-unicode-escape: Stateful decoding would probably require a new -Stateful() function at the C level, though it might be easy to build from the existing implementation. I suggest documenting that stateful decoding is not supported for the time being. utf-7: As Walter said, proper stateful codec is not supported by the C API, despite PyUnicode_DecodeUTF7Stateful(); doing so would probably require significant changes. I suggest documenting a warning for stateful mode (including with TextIOWrapper) about suboptimal encoding and unlimited data buffering for the time being. punycode, unicode_internal: According to test_codecs.py, these also don?t work in stateful mode. Not sure on the details though. ---------- keywords: +patch Added file: http://bugs.python.org/file37718/zlib-reader.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 00:02:43 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 15 Jan 2015 23:02:43 +0000 Subject: =?utf-8?q?=5Bissue20132=5D_Many_incremental_codecs_don=E2=80=99t_handle_f?= =?utf-8?q?ragmented_data?= In-Reply-To: <1421361969.03.0.433840890948.issue20132@psf.upfronthosting.co.za> Message-ID: <54B8470E.5050405@egenix.com> Marc-Andre Lemburg added the comment: On 15.01.2015 23:46, Martin Panter wrote: > > I opened Issue 23231 about fixing iterencode() and iterdecode() in the general case. I added a patch to Issue 13881 to fix StreamWriter for zlib and bz2, and to fix StreamWriter.writelines() in general. > > I am adding a patch here to clarify the StreamReader API and fix the StreamReader for the zlib-codec. Martin, I must be missing some context: what's your master plan with all these codec patches and open tickets ? They are very hard to follow and you're making design changes which need more review and discussion than can easily be done on a few tickets. Regarding the patch: The doc patch seems to just change ordering of sentences and paragraphs. Without additional explanation, it's difficult to determine whether you are changing semantics or not. The "strict" error change is not correct. Most codecs raise a UnicodeError (which is a ValueError subclass) and code expects codecs that work on Unicode to return a UnicodeError, not a ValueError. Only codecs that do not work on Unicode are allowed to raise ValueErrors. ---------- _______________________________________ Python tracker _______________________________________ From mal at egenix.com Fri Jan 16 00:02:38 2015 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 16 Jan 2015 00:02:38 +0100 Subject: =?UTF-8?Q?Re:_[issue20132]_Many_incremental_codecs_don?= =?UTF-8?Q?=e2=80=99t_handle_fragmented_data?= In-Reply-To: <1421361969.03.0.433840890948.issue20132@psf.upfronthosting.co.za> References: <1421361969.03.0.433840890948.issue20132@psf.upfronthosting.co.za> Message-ID: <54B8470E.5050405@egenix.com> On 15.01.2015 23:46, Martin Panter wrote: > > I opened Issue 23231 about fixing iterencode() and iterdecode() in the general case. I added a patch to Issue 13881 to fix StreamWriter for zlib and bz2, and to fix StreamWriter.writelines() in general. > > I am adding a patch here to clarify the StreamReader API and fix the StreamReader for the zlib-codec. Martin, I must be missing some context: what's your master plan with all these codec patches and open tickets ? They are very hard to follow and you're making design changes which need more review and discussion than can easily be done on a few tickets. Regarding the patch: The doc patch seems to just change ordering of sentences and paragraphs. Without additional explanation, it's difficult to determine whether you are changing semantics or not. The "strict" error change is not correct. Most codecs raise a UnicodeError (which is a ValueError subclass) and code expects codecs that work on Unicode to return a UnicodeError, not a ValueError. Only codecs that do not work on Unicode are allowed to raise ValueErrors. -- Marc-Andre Lemburg eGenix.com From report at bugs.python.org Fri Jan 16 00:02:55 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 15 Jan 2015 23:02:55 +0000 Subject: [issue13881] Stream encoder for zlib_codec doesn't use the incremental encoder In-Reply-To: <1327606849.1.0.885842099772.issue13881@psf.upfronthosting.co.za> Message-ID: <1421362975.38.0.87337060597.issue13881@psf.upfronthosting.co.za> Martin Panter added the comment: Sorry, I changed the name of the attribute and forgot to update the doc string. Its new name was _Encoder. Your description was fairly accurate. I am adding patch v3, with an expanded the doc string. Hopefully that explains it a bit better. Since it is just implementing the documented StreamWriter API, I only added brief descriptions of the methods pointing back to the StreamWriter methods. ---------- Added file: http://bugs.python.org/file37719/zlib-bz2-writer.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 00:05:07 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 15 Jan 2015 23:05:07 +0000 Subject: =?utf-8?q?=5Bissue20132=5D_Many_incremental_codecs_don=E2=80=99t_handle_f?= =?utf-8?q?ragmented_data?= In-Reply-To: <54B8470E.5050405@egenix.com> Message-ID: <54B847A1.9030607@egenix.com> Marc-Andre Lemburg added the comment: This addition is wrong as well: The *stream* argument must be a file-like object open for reading - text or binary data, as appropriate for the specific codec. + text or binary data, as appropriate for the specific codec. This stream is + assumed to have ended as soon as a read from it returns no data. Where did you get this idea from ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 01:19:31 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 16 Jan 2015 00:19:31 +0000 Subject: [issue23243] asyncio: emit ResourceWarning warnings if transports/event loops are not explicitly closed In-Reply-To: <1421277484.12.0.751563251482.issue23243@psf.upfronthosting.co.za> Message-ID: <1421367571.45.0.0654328262826.issue23243@psf.upfronthosting.co.za> STINNER Victor added the comment: > Some ResourceWarning are still emited on SSL server tests. Attached server_close.patch is a work-in-process patch to fix this issue on Linux. If I understood correctly, there are two issues: - SelectorEventLoop._accept_connection() doesn't care of the creation of the transport failed - SSLProtocol.eof_received() does not notify the waiter that EOF was received So an application cannot control SSL incoming connections which fail during the handshake? Control: log errors, do something with the socket, etc. See also the STARTTLS feature request: https://code.google.com/p/tulip/issues/detail?id=79 ---------- Added file: http://bugs.python.org/file37720/server_close.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 01:28:31 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 16 Jan 2015 00:28:31 +0000 Subject: =?utf-8?q?=5Bissue20132=5D_Many_incremental_codecs_don=E2=80=99t_handle_f?= =?utf-8?q?ragmented_data?= In-Reply-To: <1388929738.44.0.851837204966.issue20132@psf.upfronthosting.co.za> Message-ID: <1421368111.56.0.757494195506.issue20132@psf.upfronthosting.co.za> Martin Panter added the comment: My ?master plan? is basically to make most of the bytes-to-bytes codecs work as documented in the incremental (stateful) modes. I?m less interested in fixing the text codecs, and the quopri and uu codecs might be too hard, so I was going to propose some documentation warnings for those. If you have a suggestion on how to go about this better, let me know. With my doc change to StreamReader, I wanted to document the different modes that I saw in the base codecs.StreamReader.read() implementation: * read() or read(-1) reads everything * read(size) returns an arbitrary amount of data * read(size, chars) returns exactly *chars* length of data (unless EOF or similar) Previously the case of read(-1, chars) was ambiguous. Also I did not find the description ?an approximate maximum number of decoded bytes? very helpful, considering more than this maximum was read if necessary to get enough *chars*. Regarding the end-of-stream behaviour, I made an assumption but I now realize it was wrong. Experimenting with the UTF-8 codec shows that its StreamReader.read() keeps returning "" when the underlying stream returns no data. But if it was in the middle of a multi-byte sequence, no ?end of data? error is raised, and the multi-byte sequence can be completed if the underlying stream later returns more data. I think the lack of end-of-data checking should be documented. The different cases of ValueError and UnicodeError that you describe make sense. I think the various references to ValueError and UnicodeError should be updated (or replaced with pointers) to match. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 02:03:14 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 16 Jan 2015 01:03:14 +0000 Subject: [issue8450] httplib: false BadStatusLine() raised In-Reply-To: <1271630731.08.0.327097174192.issue8450@psf.upfronthosting.co.za> Message-ID: <1421370194.42.0.4058425535.issue8450@psf.upfronthosting.co.za> Demian Brecht added the comment: This should likely be closed as a duplicate of #3566, which has additional detail. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 02:37:02 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 16 Jan 2015 01:37:02 +0000 Subject: [issue20898] Missing 507 response description In-Reply-To: <1394637244.26.0.361164120424.issue20898@psf.upfronthosting.co.za> Message-ID: <1421372222.47.0.957365448761.issue20898@psf.upfronthosting.co.za> Berker Peksag added the comment: This is mostly a documentation update. Documentation updates can be committed anytime. Also, feature freeze for 3.5 will be started by Beta 1, not Alpha 1 (see PEP 478). I'll commit the patch this weekend. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 03:00:54 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 16 Jan 2015 02:00:54 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1421373654.64.0.427597433646.issue3566@psf.upfronthosting.co.za> Demian Brecht added the comment: Trying to reproduce this on my own in 3.5, 2.7 and 2.5 yields a ConnectionResetError (ECONNRESET), which seems to be correct. That said, this could be due to varying TCP implementations on the server so might still be valid. It could also be due to an older kernel which has been fixed since this was originally reported. Is this still reproducible? If so, can an example be provided? If the error as written is reproducible, I think that the error message should be fixed, but I'm not so sure that any more than that should be done. As far as the RFC goes, I think the MUST clause pointed out can be left to the interpretation of the reader. You /could/ consider http.client as the client, but you could also consider the application that a user is interacting with as the client. Offhand, I think that the library as it is does the right thing in allowing the application code to handle the exceptions as it sees fit. Because http.client in its current state doesn't allow for request pipelining, retries from calling code should be trivial, if that is what the caller intends to do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 03:20:33 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 16 Jan 2015 02:20:33 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1421374833.24.0.835701791961.issue3566@psf.upfronthosting.co.za> Martin Panter added the comment: I believe the BadStatusLine can still happen, depending on the circumstances. When I get a chance I will see if I can make a demonstration. In the meantime these comments from my persistent connection handler might be useful: # If the server closed the connection, # by calling close() or shutdown(SHUT_WR), # before receiving a short request (<= 1 MB), # the "http.client" module raises a BadStatusLine exception. # # To produce EPIPE: # 1. server: close() or shutdown(SHUT_RDWR) # 2. client: send(large request >> 1 MB) # # ENOTCONN probably not possible with current Python, # but could be generated on Linux by: # 1. server: close() or shutdown(SHUT_RDWR) # 2. client: send(finite data) # 3. client: shutdown() # ENOTCONN not covered by ConnectionError even in Python 3.3. # # To produce ECONNRESET: # 1. client: send(finite data) # 2. server: close() without reading all data # 3. client: send() I think these behaviours were from experimenting on Linux with Python 3 sockets, and reading the man pages. I think there should be a new documented exception, a subclass of BadStatusLine for backwards compatibility. Then user code could catch the new exception, and true bad status lines that do not conform to the specification or whatever won?t be caught. I agree that the library shouldn?t be doing any special retrying of its own, but should make it easy for the caller to do so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 03:25:09 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 16 Jan 2015 02:25:09 +0000 Subject: [issue23234] refactor subprocess: use new OSError exceptions, factorize stdin.write() code In-Reply-To: <1421192461.64.0.911516234193.issue23234@psf.upfronthosting.co.za> Message-ID: <1421375109.19.0.360747428816.issue23234@psf.upfronthosting.co.za> Gregory P. Smith added the comment: thanks for the cleanup refactoring! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 03:59:53 2015 From: report at bugs.python.org (Gregory Szorc) Date: Fri, 16 Jan 2015 02:59:53 +0000 Subject: [issue23246] distutils fails to locate vcvarsall with Visual C++ Compiler for Python Message-ID: <1421377193.75.0.720322416964.issue23246@psf.upfronthosting.co.za> New submission from Gregory Szorc: distutils as of Python 2.7.9 is unable to locate vcvarsall.bat if Visual C++ Compiler for Python is the only Visual Studio "distribution" installed. STR: 1) Do a fresh install of Windows + all updates 2) Install Microsoft Visual C++ Compiler for Python from http://www.microsoft.com/en-us/download/details.aspx?id=44266 3) Enter a Visual C++ 2008 command prompt via start menu 4) Attempt to run any |python.exe setup.py| that contains C extensions 5) "Unable to find vcvarsall.bat" Examining the behavior of MSVC for Python's bat scripts and filesystem layout, it is different enough from "full" "distributions" that it confused distutils. First, MSVC for Python doesn't appear to set any meaningful registry entries. So, the registry checking in msvc9compiler fails to find anything. Second, the command environment for MSVC for Python doesn't export VS90COMNTOOLS, so msvc9compiler has no clue where to go looking for files. Third, even if VS90COMNTOOLS is set, msvc9compiler isn't able to find vcvarsall.bat because it is installed in %installdir%/vcvarsall.bat and not %installdir%/VC/vcvarsall.bat, unlike every other Visual Studio AFAICT. Another concern is that distutils.msvc9compiler.find_vcvarsall() first attempts to read from the registry, not the environment. If you are in a MSVC for Python command shell and you also have Visual Studio 2008 installed, distutils will use vcvarsall.bat from the full Visual Studio installation instead of the Python one. I think this is wrong. The MSVC for Python command prompt does have an environment variable that can be used: VCINSTALLDIR. It is set to %installdir%\VC\, which is equivalent to ~/AppData/Local/Programs/Common/Microsoft/Visual C++ for Python/9.0/VC/ if you launch the installer with default options. distutils could be patched to find vcvarsall.bat in %VCINSTALLDIR%\..\vcvarsall.bat Fortunately, a workaround is available: 1) Enter MSVC for Python command prompt 2) SET DISTUTILS_USE_SDK=1 3) SET MSSdk=1 4) python.exe setup.py ... ---------- components: Distutils messages: 234110 nosy: Gregory.Szorc, dstufft, eric.araujo priority: normal severity: normal status: open title: distutils fails to locate vcvarsall with Visual C++ Compiler for Python versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 04:08:28 2015 From: report at bugs.python.org (Gregory Szorc) Date: Fri, 16 Jan 2015 03:08:28 +0000 Subject: [issue23246] distutils fails to locate vcvarsall with Visual C++ Compiler for Python In-Reply-To: <1421377193.75.0.720322416964.issue23246@psf.upfronthosting.co.za> Message-ID: <1421377708.34.0.315670518656.issue23246@psf.upfronthosting.co.za> Gregory Szorc added the comment: The first sentence in my original report is ambiguous. I tested with distutils on Python 2.7.9. But considering the code in question hasn't changed since 2011, I think it's safe to say this isn't a regression in CPython. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 04:29:48 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 16 Jan 2015 03:29:48 +0000 Subject: [issue11835] python (x64) ctypes incorrectly pass structures parameter In-Reply-To: <1302622766.46.0.0398461644853.issue11835@psf.upfronthosting.co.za> Message-ID: <1421378988.01.0.903635911901.issue11835@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> broken ctypes calling convention on MSVC / 64-bit Windows (large structs) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 05:44:04 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 16 Jan 2015 04:44:04 +0000 Subject: [issue23246] distutils fails to locate vcvarsall with Visual C++ Compiler for Python In-Reply-To: <1421377193.75.0.720322416964.issue23246@psf.upfronthosting.co.za> Message-ID: <1421383444.93.0.341314080916.issue23246@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 06:31:03 2015 From: report at bugs.python.org (James Teh) Date: Fri, 16 Jan 2015 05:31:03 +0000 Subject: [issue20916] ssl.enum_certificates() will not return all certificates trusted by Windows In-Reply-To: <1394740101.16.0.76901026465.issue20916@psf.upfronthosting.co.za> Message-ID: <1421386263.29.0.347535294324.issue20916@psf.upfronthosting.co.za> Changes by James Teh : ---------- nosy: +jteh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 07:17:50 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 16 Jan 2015 06:17:50 +0000 Subject: [issue23247] Multibyte codec StreamWriter.reset() crashes Message-ID: <1421389070.93.0.922548564015.issue23247@psf.upfronthosting.co.za> New submission from Martin Panter: $ python3 -c 'import codecs; from io import BytesIO; codecs.getwriter("big5")(BytesIO()).reset()' Segmentation fault (core dumped) [Exit 139] Happens for all the multibyte codecs: broken_stream_codecs = { "big5", "big5hkscs", "cp932", "cp949", "cp950", "euc_jp", "euc_jis_2004", "euc_jisx0213", "euc_kr", "gb2312", "gbk", "gb18030", "hz", "iso2022_jp", "iso2022_jp_1", "iso2022_jp_2", "iso2022_jp_2004", "iso2022_jp_3", "iso2022_jp_ext", "iso2022_kr", "johab", "shift_jis", "shift_jis_2004", "shift_jisx0213", } These codecs also share the property that their StreamReader.read() methods do not accept the second ?chars? parameter: >>> codecs.getreader("big5")(BytesIO()).read(1, 1) Traceback (most recent call last): File "", line 1, in TypeError: read expected at most 1 arguments, got 2 ---------- components: Unicode messages: 234112 nosy: ezio.melotti, haypo, vadmium priority: normal severity: normal status: open title: Multibyte codec StreamWriter.reset() crashes type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 07:37:36 2015 From: report at bugs.python.org (Dmitry Shachnev) Date: Fri, 16 Jan 2015 06:37:36 +0000 Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone constant In-Reply-To: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za> Message-ID: <1421390256.03.0.161717716805.issue22932@psf.upfronthosting.co.za> Dmitry Shachnev added the comment: Now the patch works with tzdata >= 2011k, which is quite old. @David: yes, with the unpatched version only one of the tests should fail. ---------- Added file: http://bugs.python.org/file37721/issue22932_combined_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 09:17:02 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 16 Jan 2015 08:17:02 +0000 Subject: [issue23248] Update ssl data Message-ID: <1421396221.93.0.559881277875.issue23248@psf.upfronthosting.co.za> New submission from Antoine Pitrou: Amusingly OpenSSL has removed some error codes, so perhaps we should only apply this to the default branch. ---------- components: Library (Lib) files: update_ssl_data.patch keywords: patch messages: 234114 nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou priority: normal severity: normal stage: patch review status: open title: Update ssl data type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file37722/update_ssl_data.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 09:18:42 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 16 Jan 2015 08:18:42 +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: <1421396322.13.0.0373322868892.issue15955@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I've posted a review of the latest lzma decompressor patch. I think it'll be able to go in once the comments are addressed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 09:20:37 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 16 Jan 2015 08:20:37 +0000 Subject: [issue23051] multiprocessing.pool methods imap()[_unordered()] deadlock In-Reply-To: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za> Message-ID: <1421396437.9.0.459021185841.issue23051@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The patch would at least need to add a unit test in order to avoid regressions. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 09:31:28 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 16 Jan 2015 08:31:28 +0000 Subject: [issue14953] Reimplement subset of multiprocessing.sharedctypes using memoryview In-Reply-To: <1338303583.56.0.322806581737.issue14953@psf.upfronthosting.co.za> Message-ID: <1421397088.63.0.238211349893.issue14953@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 09:33:43 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 16 Jan 2015 08:33:43 +0000 Subject: [issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers In-Reply-To: <1398499255.25.0.881446688113.issue21354@psf.upfronthosting.co.za> Message-ID: <1421397223.65.0.00383507386328.issue21354@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 09:39:25 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 16 Jan 2015 08:39:25 +0000 Subject: [issue1103213] Adding the missing socket.recvall() method Message-ID: <1421397565.47.0.548389977042.issue1103213@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm frankly not sure why this is useful. If you want a guaranteed read size you should use the buffered layer - i.e. socket.makefile(). No need to complicate the raw socket implementation. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 09:41:04 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 16 Jan 2015 08:41:04 +0000 Subject: [issue20544] Use specific asserts in operator tests In-Reply-To: <1391804710.79.0.27308793582.issue20544@psf.upfronthosting.co.za> Message-ID: <1421397664.86.0.20780293416.issue20544@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 09:49:12 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 16 Jan 2015 08:49:12 +0000 Subject: [issue23133] Pickling of ipaddress classes In-Reply-To: <1419936769.64.0.614386046628.issue23133@psf.upfronthosting.co.za> Message-ID: <1421398152.64.0.186681040995.issue23133@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Patch looks good to me. For further efficiency, addresses could be pickled as ints (but beware of interfaces and networks). ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 10:41:23 2015 From: report at bugs.python.org (Robert Kuska) Date: Fri, 16 Jan 2015 09:41:23 +0000 Subject: [issue23249] test_win32 fails on aarch64 Message-ID: <1421401283.38.0.406623425658.issue23249@psf.upfronthosting.co.za> New submission from Robert Kuska: Original bug report at https://bugzilla.redhat.com/show_bug.cgi?id=1174037 Additional informations at Issue #20160 Note that this was reproduced not only with separate libffi package but also with libffi bundled in python. Reproduced with Python 2.7.9 but same issue should exists also in 3.4.x. Richard Henderson provided fix in original bug report at bugzilla (attached). Summary: ====================================================================== FAIL: test_struct_by_value (ctypes.test.test_win32.Structures) ---------------------------------------------------------------------- Traceback (most recent call last): File "/builddir/build/BUILD/Python-2.7.9/Lib/ctypes/test/test_win32.py", line 112, in test_struct_by_value self.assertEqual(ret.left, left.value) AssertionError: -200 != 10 ---------------------------------------------------------------------- (gdb) b ReturnRect Function "ReturnRect" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (ReturnRect) pending. (gdb) run test_win32.py Starting program: /usr/bin/python test_win32.py Missing separate debuginfos, use: debuginfo-install glibc-2.20.90-12.fc22.aarch64 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, ReturnRect (i=0, ar=..., br=0x59b750, cp=..., dr=..., er=0x59b750, fp=..., gr=) at /usr/src/debug/Python-2.7.9/Modules/_ctypes/_ctypes_test.c:552 552 if (ar.left + br->left + dr.left + er->left + gr.left != left * 5) (gdb) p fp $1 = {x = 4396722194992, y = 5879632} (gdb) p cp $2 = {x = 15, y = 25} (gdb) Consider to apply a patch or update bundled libffi. ---------- components: ctypes files: libffi-henderson messages: 234119 nosy: rkuska priority: normal severity: normal status: open title: test_win32 fails on aarch64 type: crash versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file37723/libffi-henderson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 10:43:32 2015 From: report at bugs.python.org (Robert Kuska) Date: Fri, 16 Jan 2015 09:43:32 +0000 Subject: [issue23249] test_win32 fails on aarch64 In-Reply-To: <1421401283.38.0.406623425658.issue23249@psf.upfronthosting.co.za> Message-ID: <1421401412.74.0.0576888949891.issue23249@psf.upfronthosting.co.za> Changes by Robert Kuska : ---------- keywords: +patch Added file: http://bugs.python.org/file37724/libffi-mattip.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 10:44:33 2015 From: report at bugs.python.org (Robert Kuska) Date: Fri, 16 Jan 2015 09:44:33 +0000 Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs) In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za> Message-ID: <1421401473.79.0.102307897105.issue20160@psf.upfronthosting.co.za> Robert Kuska added the comment: I have created #23249. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 11:06:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 16 Jan 2015 10:06:50 +0000 Subject: [issue23133] Pickling of ipaddress classes In-Reply-To: <1419936769.64.0.614386046628.issue23133@psf.upfronthosting.co.za> Message-ID: <1421402810.98.0.602811420161.issue23133@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, pickling (and especially unpickling) ints is more efficient, but the code will more complex. Interfaces should be pickled as strings for backward compatibility, and interfaces are subclasses of addresses. Here are microbenchmarks: ./python -m timeit -s "import ipaddress, pickle; ips = [ipaddress.ip_address('192.0.2.%s'%i) for i in range(1, 101)]" -- "pickle.dumps(ips)" ./python -m timeit -s "import ipaddress, pickle; ips = [ipaddress.ip_address('2001:db8::%x'%i) for i in range(1, 101)]" -- "pickle.dumps(ips)" ./python -m timeit -s "import ipaddress, pickle; ips = [ipaddress.ip_address('192.0.2.%s'%i) for i in range(1, 101)]; pickled = pickle.dumps(ips)" -- "pickle.loads(pickled)" ./python -m timeit -s "import ipaddress, pickle; ips = [ipaddress.ip_address('2001:db8::%x'%i) for i in range(1, 101)]; pickled = pickle.dumps(ips)" -- "pickle.loads(pickled)" Results for unpatched module: 1000 loops, best of 3: 1.56 msec per loop 1000 loops, best of 3: 1.62 msec per loop 1000 loops, best of 3: 1.08 msec per loop 1000 loops, best of 3: 1.09 msec per loop With ipaddress_pickle.patch: 100 loops, best of 3: 3.43 msec per loop 100 loops, best of 3: 10.6 msec per loop 100 loops, best of 3: 7.76 msec per loop 100 loops, best of 3: 8.58 msec per loop With ipaddress_pickle_2.patch: 1000 loops, best of 3: 1.11 msec per loop 1000 loops, best of 3: 1.16 msec per loop 1000 loops, best of 3: 1.88 msec per loop 100 loops, best of 3: 2.05 msec per loop With ipaddress_pickle_3.patch: 1000 loops, best of 3: 1.12 msec per loop 1000 loops, best of 3: 1.15 msec per loop 1000 loops, best of 3: 1.13 msec per loop 1000 loops, best of 3: 1.15 msec per loop ---------- Added file: http://bugs.python.org/file37725/ipaddress_lightweight_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 11:07:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 16 Jan 2015 10:07:43 +0000 Subject: [issue23133] Pickling of ipaddress classes In-Reply-To: <1419936769.64.0.614386046628.issue23133@psf.upfronthosting.co.za> Message-ID: <1421402863.84.0.0770730724877.issue23133@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file37726/ipaddress_pickle_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 11:07:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 16 Jan 2015 10:07:53 +0000 Subject: [issue23133] Pickling of ipaddress classes In-Reply-To: <1419936769.64.0.614386046628.issue23133@psf.upfronthosting.co.za> Message-ID: <1421402873.73.0.254115765531.issue23133@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file37725/ipaddress_lightweight_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 11:08:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 16 Jan 2015 10:08:02 +0000 Subject: [issue23133] Pickling of ipaddress classes In-Reply-To: <1419936769.64.0.614386046628.issue23133@psf.upfronthosting.co.za> Message-ID: <1421402882.89.0.256346450912.issue23133@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file37726/ipaddress_pickle_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 11:08:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 16 Jan 2015 10:08:25 +0000 Subject: [issue23133] Pickling of ipaddress classes In-Reply-To: <1419936769.64.0.614386046628.issue23133@psf.upfronthosting.co.za> Message-ID: <1421402905.98.0.15770612991.issue23133@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file37727/ipaddress_pickle_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 11:08:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 16 Jan 2015 10:08:51 +0000 Subject: [issue23133] Pickling of ipaddress classes In-Reply-To: <1419936769.64.0.614386046628.issue23133@psf.upfronthosting.co.za> Message-ID: <1421402931.69.0.547944301895.issue23133@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file37728/ipaddress_pickle_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 11:17:15 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 16 Jan 2015 10:17:15 +0000 Subject: =?utf-8?q?=5Bissue20132=5D_Many_incremental_codecs_don=E2=80=99t_handle_f?= =?utf-8?q?ragmented_data?= In-Reply-To: <1388929738.44.0.851837204966.issue20132@psf.upfronthosting.co.za> Message-ID: <1421403435.78.0.00688836512425.issue20132@psf.upfronthosting.co.za> Martin Panter added the comment: There is a flaw with inheriting the readline() method in my patch, and I have decided to give up fixing the StreamReader classes. I did update the documentation in my copy of the patch based on Marc-Andre Lemburg?s feedback if anyone is interested in it, otherwise I am going to focus on some of the incremental codecs now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 11:20:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 16 Jan 2015 10:20:34 +0000 Subject: [issue23133] Pickling of ipaddress classes In-Reply-To: <1419936769.64.0.614386046628.issue23133@psf.upfronthosting.co.za> Message-ID: <1421403634.6.0.0458613062546.issue23133@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: ipaddress_pickle_3.patch breaks one test (testMissingAddressVersion). Is this test needed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 11:43:24 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 16 Jan 2015 10:43:24 +0000 Subject: [issue23133] Pickling of ipaddress classes In-Reply-To: <1419936769.64.0.614386046628.issue23133@psf.upfronthosting.co.za> Message-ID: <1421405004.52.0.990177527743.issue23133@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't understand what the test is for. I think it's safe it's remove it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 11:55:04 2015 From: report at bugs.python.org (=?utf-8?q?Mat=C4=9Bj_Stuchl=C3=ADk?=) Date: Fri, 16 Jan 2015 10:55:04 +0000 Subject: [issue23249] test_win32 fails on aarch64 In-Reply-To: <1421401283.38.0.406623425658.issue23249@psf.upfronthosting.co.za> Message-ID: <1421405704.9.0.971975859327.issue23249@psf.upfronthosting.co.za> Changes by Mat?j Stuchl?k : ---------- nosy: +sYnfo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 11:55:27 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 16 Jan 2015 10:55:27 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1421405727.14.0.632966700565.issue22995@psf.upfronthosting.co.za> Antoine Pitrou added the comment: How many cases does the patch catch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 12:16:21 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 16 Jan 2015 11:16:21 +0000 Subject: [issue1103213] Adding the missing socket.recvall() method Message-ID: <1421406981.41.0.690969235568.issue1103213@psf.upfronthosting.co.za> STINNER Victor added the comment: The patch uses the flag MSG_WAITALL for recv() if available. Extract of the manual page: MSG_WAITALL (since Linux 2.2) This flag requests that the operation block until the full request is satisfied. However, the call may still return less data than requested if a signal is caught, an error or discon- nect occurs, or the next data to be received is of a different type than that returned. It looks interesting, but it doesn't guarantee that you will always get exactly the expected size. You still have to call again recv() to get more data if a signal was received. Jean-Paul Calderone wrote: > Since MSG_WAITALL is already exposed to Python (when the underlying platform provides it), I wonder if this could all be implemented more simply in pure Python. Can you elaborate on the motivation to use C? sendall() is implemented in C while it would be possible to implement it in Python. The same rationale can be used on a large part of the stdlib :-) (The io module is implemented in Python in Python 2.6!) The C gives you a full control on the GIL, signal handle, and it might be faster. Antoine Pitrou wrote: > I'm frankly not sure why this is useful. recvall() allows to easily fix existing code: just replace recv() with recvall(), no need to refactor code to call makefile() which has a different API (ex: read/recv, write/send). The addition is small and well defined. -- About the exception: asyncio.StreamReader.read_exactly() raises an IncompleteReadError which contains the read bytes and inherits from EOFError: see https://docs.python.org/dev/library/asyncio-stream.html#asyncio.StreamReader.readexactly and https://docs.python.org/dev/library/asyncio-stream.html#asyncio.IncompleteReadError The following issue discussed the design on this exception in asyncio: https://code.google.com/p/tulip/issues/detail?id=111 http.client uses an IncompleteRead (which inherits from HTTPException): https://docs.python.org/dev/library/http.client.html#http.client.IncompleteRead ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 14:41:59 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 16 Jan 2015 13:41:59 +0000 Subject: [issue21581] Consider dropping importlib.abc.Loader.create_module() In-Reply-To: <1401115897.78.0.38815519118.issue21581@psf.upfronthosting.co.za> Message-ID: <1421415719.49.0.0184926271323.issue21581@psf.upfronthosting.co.za> Brett Cannon added the comment: create_module() is now slated to be required in Python 3.6. ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 14:42:27 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 16 Jan 2015 13:42:27 +0000 Subject: [issue23013] Tweak wording for importlib.util.LazyLoader in regards to Loader.create_module() In-Reply-To: <1418054954.8.0.232826100302.issue23013@psf.upfronthosting.co.za> Message-ID: <1421415747.44.0.272878368166.issue23013@psf.upfronthosting.co.za> Brett Cannon added the comment: Change went in through making create_module() required. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 14:42:38 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 16 Jan 2015 13:42:38 +0000 Subject: [issue23246] distutils fails to locate vcvarsall with Visual C++ Compiler for Python In-Reply-To: <1421377193.75.0.720322416964.issue23246@psf.upfronthosting.co.za> Message-ID: <1421415758.71.0.26431014996.issue23246@psf.upfronthosting.co.za> Steve Dower added the comment: Setuptools has the code to find the compiler package. We deliberately put it there instead of in distutils to make sure more people would get it. I should probably port the extra check into 2.7.10, but the immediate fix is to import setuptools. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 14:46:02 2015 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 16 Jan 2015 13:46:02 +0000 Subject: [issue23211] test.test_logging.SMTPHandlerTest failing on Snow Leopard In-Reply-To: <1420832632.4.0.00679469135671.issue23211@psf.upfronthosting.co.za> Message-ID: <1421415962.78.0.0811202243776.issue23211@psf.upfronthosting.co.za> Vinay Sajip added the comment: No objections from me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 15:04:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 16 Jan 2015 14:04:05 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1421417045.64.0.0282985235965.issue22995@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: All public classes not designed for pickling explicitly. I tested only operator.methodcaller, mmap.mmap, sqlite3 classes (Connect, Cursor, Row), _socket.socket, select.epoll, _csv.Dialect, but should be more. Instances of these classes can be "pickled", but unpickling either raise an exception (usually TypeError), or returns default or underinitialized object. For other classes the patch changes raised exception type. E.g. pickling zlib.compressobj() raised _pickle.PicklingError: Can't pickle : attribute lookup Compress on zlib failed and with the patch it raises TypeError: can't pickle zlib.Compress objects ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 15:25:00 2015 From: report at bugs.python.org (Jon Dufresne) Date: Fri, 16 Jan 2015 14:25:00 +0000 Subject: [issue23250] http.cookies HttpOnly attribute does not use suggested case-style of HTTP standard Message-ID: <1421418300.49.0.235293790837.issue23250@psf.upfronthosting.co.za> New submission from Jon Dufresne: See http://tools.ietf.org/html/rfc6265#section-5.2.6 Relevant section: --- 5.2.6. The HttpOnly Attribute If the attribute-name case-insensitively matches the string HttpOnly", the user agent MUST append an attribute to the cookie-attribute-list with an attribute-name of HttpOnly and an empty attribute-value. ... If the cookie-attribute-list contains an attribute with an attribute-name of "HttpOnly", set the cookie's http-only-flag to true. Otherwise, set the cookie's http-only-flag to false. --- http.cookies creates this attribute as `httponly` not `HttpOnly`. It is true, when interpreted by the user agent, this attribute is case insensitive, but it seems odd that Python would go out of its way to purposely use a different case then stated in the standard. When looking at other web technologies, the case used in the standard is most typical. The examples in the standard also use the `HttpOnly` style. (Same applies to the Secure flag.) ---------- components: Library (Lib) messages: 234132 nosy: jdufresne priority: normal severity: normal status: open title: http.cookies HttpOnly attribute does not use suggested case-style of HTTP standard type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 15:26:31 2015 From: report at bugs.python.org (Jon Dufresne) Date: Fri, 16 Jan 2015 14:26:31 +0000 Subject: [issue23250] http.cookies HttpOnly attribute does not use suggested case-style of HTTP standard In-Reply-To: <1421418300.49.0.235293790837.issue23250@psf.upfronthosting.co.za> Message-ID: <1421418391.31.0.423812677881.issue23250@psf.upfronthosting.co.za> Changes by Jon Dufresne : ---------- keywords: +patch Added file: http://bugs.python.org/file37729/http-only-case.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 15:48:31 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 16 Jan 2015 14:48:31 +0000 Subject: [issue23233] TypeError in ./setup.py In-Reply-To: <1421180295.13.0.16794585619.issue23233@psf.upfronthosting.co.za> Message-ID: <1421419711.58.0.916766613807.issue23233@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: On one of my computer on one workspace it is reproduced constantly, but I don't know how to reproduce it from clean checkout. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 15:49:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 16 Jan 2015 14:49:59 +0000 Subject: [issue23133] Pickling of ipaddress classes In-Reply-To: <1419936769.64.0.614386046628.issue23133@psf.upfronthosting.co.za> Message-ID: <1421419799.08.0.793682415831.issue23133@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 16:02:09 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 16 Jan 2015 15:02:09 +0000 Subject: [issue23250] http.cookies HttpOnly attribute does not use suggested case-style of HTTP standard In-Reply-To: <1421418300.49.0.235293790837.issue23250@psf.upfronthosting.co.za> Message-ID: <1421420529.08.0.63577442197.issue23250@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray stage: -> commit review versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 17:12:28 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 16 Jan 2015 16:12:28 +0000 Subject: [issue23095] asyncio: race condition when cancelling a _WaitHandleFuture In-Reply-To: <1419122866.29.0.725788641938.issue23095@psf.upfronthosting.co.za> Message-ID: <1421424748.34.0.651113951932.issue23095@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: asyncio: race condition in IocpProactor.wait_for_handle() -> asyncio: race condition when cancelling a _WaitHandleFuture _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 17:35:00 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 16 Jan 2015 16:35:00 +0000 Subject: [issue23095] asyncio: race condition when cancelling a _WaitHandleFuture In-Reply-To: <1419122866.29.0.725788641938.issue23095@psf.upfronthosting.co.za> Message-ID: <1421426100.35.0.753954805154.issue23095@psf.upfronthosting.co.za> STINNER Victor added the comment: The race condition occurs when _WaitHandleFuture().cancel() is called. This object is created by IocpProactor.wait_for_handle(). _WaitHandleFuture().cancel() is only called by 4 tests: - test_cancel_post_init() - test_cancel_make_subprocess_transport_exec - test_wait_for_handle - test_wait_for_handle_cancel It looks like the "GetQueuedCompletionStatus() returned an unexpected event" error is logged when test_wait_for_handle() and/or test_wait_for_handle_cancel() is executed(). Disabling these tests is enough to workaround this issue. Using Tulip, use "python3 runtests.py -r" to reproduce the issue. You may have to run this command multiple times to see the error, the bug is random. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 18:01:06 2015 From: report at bugs.python.org (Akira Li) Date: Fri, 16 Jan 2015 17:01:06 +0000 Subject: [issue23251] mention in time.sleep() docs that it does not block other Python threads Message-ID: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za> New submission from Akira Li: There is the corresponding StackOverflow question with 60K view "time.sleep ? sleeps thread or process?" [1] The documentation patch is attached. [1] http://stackoverflow.com/questions/92928/time-sleep-sleeps-thread-or-process ---------- assignee: docs at python components: Documentation files: docs-time.sleep-other-threads-are-not-blocked.diff keywords: patch messages: 234135 nosy: akira, docs at python priority: normal severity: normal status: open title: mention in time.sleep() docs that it does not block other Python threads type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file37730/docs-time.sleep-other-threads-are-not-blocked.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 18:42:06 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 16 Jan 2015 17:42:06 +0000 Subject: [issue23251] mention in time.sleep() docs that it does not block other Python threads In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za> Message-ID: <1421430126.11.0.957025512222.issue23251@psf.upfronthosting.co.za> R. David Murray added the comment: Can you re-upload the patch without reflowing the paragraph? I think the only thing needed is the addition of the word thread, to mirror the equivalent unix man page phrasing, and I think that's what you've done, but I can't easily tell from the provided patch. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 18:48:19 2015 From: report at bugs.python.org (Gregory Szorc) Date: Fri, 16 Jan 2015 17:48:19 +0000 Subject: [issue23246] distutils fails to locate vcvarsall with Visual C++ Compiler for Python In-Reply-To: <1421377193.75.0.720322416964.issue23246@psf.upfronthosting.co.za> Message-ID: <1421430499.27.0.336493292311.issue23246@psf.upfronthosting.co.za> Gregory Szorc added the comment: Thanks, Steve. The package I was trying to build has its setup.py importing "setup" from distutils, not setuptools. I'll see about porting them to the future. For posterity, https://bitbucket.org/pypa/setuptools/issue/258, which was first released in setuptools 6.0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 18:59:31 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 16 Jan 2015 17:59:31 +0000 Subject: [issue22992] Adding a git developer's guide to Mercurial to devguide In-Reply-To: <1417651753.19.0.905189748743.issue22992@psf.upfronthosting.co.za> Message-ID: <20150116175929.103311.6417@psf.io> Roundup Robot added the comment: New changeset 51c89a0c30b4 by Brett Cannon in branch 'default': Issue #22992: A git developer's guide to hg. https://hg.python.org/devguide/rev/51c89a0c30b4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 19:00:17 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 16 Jan 2015 18:00:17 +0000 Subject: [issue22992] Adding a git developer's guide to Mercurial to devguide In-Reply-To: <1417651753.19.0.905189748743.issue22992@psf.upfronthosting.co.za> Message-ID: <1421431217.12.0.131339161649.issue22992@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for the hard work, Demian! I don't remember how often the devguide is updated online, but it should hopefully be no longer than a day (probably more like an hour). ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 19:20:31 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 16 Jan 2015 18:20:31 +0000 Subject: [issue23246] distutils fails to locate vcvarsall with Visual C++ Compiler for Python In-Reply-To: <1421377193.75.0.720322416964.issue23246@psf.upfronthosting.co.za> Message-ID: <1421432431.23.0.133296034262.issue23246@psf.upfronthosting.co.za> Steve Dower added the comment: FWIW, at some point I will need to do some serious work on this code for Python 3.5, so I'll certainly take your suggestions into account there. But I won't be doing the same for old versions of Python - at most 2.7 may get a check for the extra registry key, but 2.6 and 3.0-3.2 will still need to be using setuptools>=6.0 (which 2.7.10 will ship with). Also, pip forces setuptools onto packages whether they like it or not, so pip installs should always build. Because it's a monkeypatch, "import setuptools" is sufficient to port old setup.py files. All together, there doesn't seem to be an urgent need to get this into the core release. If someone comes up with a simple patch I'll happily review and apply it (and Jason will want a setuptools patch to skip the monkeypatch there), but I need to spend my own dev time on the next release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 19:35:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 16 Jan 2015 18:35:59 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <1421433359.63.0.628676295627.issue22619@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your patches Dmitry. But I think that the code can be made simpler. Here is a patch which refactors extracting code. It splits the code on few generators which do different tasks: iterate over tracebacks or frames linked list, limit the size of proceeded sequence, and generates required fields. Note that the behavior of extract_stack() with negative limit differs if sys.tracebacklimit is specified and less than the length of full traceback. Tests are changed too, now they test all combinations of the limit parameter and sys.tracebacklimit. ---------- stage: -> patch review Added file: http://bugs.python.org/file37731/traceback_negative_limit_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 20:35:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 16 Jan 2015 19:35:05 +0000 Subject: [issue14099] ZipFile.open() should not reopen the underlying file In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za> Message-ID: <1421436905.56.0.840510311054.issue14099@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your report Matt. There is other problem. It is nowhere documented and newer granted and newer mentioned when ZipFile.open() was added, but file-like objects returned by ZipFile.open() could be read in different threads simultaneously. It makes sense because decompressors release GIL and parallel reading compressed file can has benefit. It is easy to fix both issues (I prefer to do this in separate paths), but due to the overall complexity it is safer to withdraw committed changes in maintained releases and apply additional patches only in default branch. ---------- stage: -> patch review Added file: http://bugs.python.org/file37732/zipfile_tellable.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 20:37:37 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 16 Jan 2015 19:37:37 +0000 Subject: [issue14099] ZipFile.open() should not reopen the underlying file In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za> Message-ID: <1421437057.96.0.133886561696.issue14099@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Adding locks almost not affects performance, because reads are done by relative large chunks and locking overhead is small. ---------- Added file: http://bugs.python.org/file37733/zipfile_threadsafe.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 20:38:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 16 Jan 2015 19:38:05 +0000 Subject: [issue14099] ZipFile.open() should not reopen the underlying file In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za> Message-ID: <1421437085.33.0.809846658995.issue14099@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: -Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 20:44:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 16 Jan 2015 19:44:00 +0000 Subject: [issue22286] Allow backslashreplace error handler to be used on input In-Reply-To: <1409136620.65.0.397738586583.issue22286@psf.upfronthosting.co.za> Message-ID: <1421437440.1.0.942728672697.issue22286@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you make a review Nick to get this feature in the first alpha. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 20:55:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 16 Jan 2015 19:55:48 +0000 Subject: [issue23252] Add support of writing to unseekable file in zipfile Message-ID: <1421438148.04.0.307260333821.issue23252@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: ZIP files can be created to transfer it via unseekable streams (pipes, sockets). Mercurial uses a workaround to write ZIP files right to wsgirequest, but this is possible only with writestr(). write() needs seek() to updated file size, compressed sized and CRC. However ZIP file format supports streamed data without writing sizes and CRC before file data. It is possible and desirable to add full support of unseekable output files in zipfile. ---------- assignee: serhiy.storchaka components: Library (Lib) messages: 234145 nosy: serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Add support of writing to unseekable file in zipfile type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 20:56:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 16 Jan 2015 19:56:18 +0000 Subject: [issue14099] ZipFile.open() should not reopen the underlying file In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za> Message-ID: <1421438178.51.0.902985311382.issue14099@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue23252. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 20:59:14 2015 From: report at bugs.python.org (Julian Taylor) Date: Fri, 16 Jan 2015 19:59:14 +0000 Subject: [issue5309] distutils doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <1421438354.6.0.589627502897.issue5309@psf.upfronthosting.co.za> Julian Taylor added the comment: very nice, thanks for adding this. coincidentally numpy added the same to numpy.distutils independently just a week later, though numpy also accepts an environment variable to set the number of jobs. This is useful for e.g. pip installations where one does not control the command line. Also an environment variable allows parallel jobs in environments where it is not guaranteed that the feature is available. E.g. you could just put it into your .bashrc and when building with 3.5 it will just work and 2.7 will not fail. Is the naming --parallel/j already fixed? I'll change the numpy options to the same name then. Please also add it to the release notes so the feature can be discovered easier. ---------- nosy: +jtaylor _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 22:41:09 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 16 Jan 2015 21:41:09 +0000 Subject: [issue23249] test_win32 fails on aarch64 In-Reply-To: <1421401283.38.0.406623425658.issue23249@psf.upfronthosting.co.za> Message-ID: <1421444469.81.0.255344688985.issue23249@psf.upfronthosting.co.za> STINNER Victor added the comment: > libffi-3.2.1 was released on November 12, 2014. You can ftp it from sourceware.org:/pub/libffi/libffi-3.2.1.tar.gz. Does this version include libffi-henderson patch? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 22:58:14 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 16 Jan 2015 21:58:14 +0000 Subject: [issue23251] mention in time.sleep() docs that it does not block other Python threads In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za> Message-ID: <1421445494.04.0.896129658147.issue23251@psf.upfronthosting.co.za> Martin Panter added the comment: There is also a new sentence about the GIL at the end, but leaving the inbetween lines as they were would verify this ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 16 23:56:22 2015 From: report at bugs.python.org (Akira Li) Date: Fri, 16 Jan 2015 22:56:22 +0000 Subject: [issue23251] mention in time.sleep() docs that it does not block other Python threads In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za> Message-ID: <1421448982.95.0.816238681985.issue23251@psf.upfronthosting.co.za> Akira Li added the comment: I do not understand. Have you tried to look at the patch in Rietveld? The new content is highlighted in a darker green. It is clearly visible. I've tested on Chromium, Firefox, Safari. If I won't reflow then the first line will be longer than the recommended 80 in devguide: > The maximum line length is 80 characters for normal text, but > tables, deeply indented code samples and long links may extend > beyond that. I've set *fill-column* to 80 in emacs. Do you suggest other settings? Anyway, it doesn't affect how the final text is shown in a web browser. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 00:11:50 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 16 Jan 2015 23:11:50 +0000 Subject: [issue23253] Delay-load ShellExecute[AW] in os.startfile Message-ID: <1421449910.62.0.491687570058.issue23253@psf.upfronthosting.co.za> New submission from Steve Dower: Currently, pythonXY.dll has a dependency on shell32.dll solely for the os.startfile (Modules/posixmodule.c) function. This is quite a heavy dependency that many would rather not have to load (e.g. lightweight server configurations). It would be nice to delay load the DLL and fail the operation if it is not available. (This is as much a reminder for myself as anything else, but if someone wants to do it then feel free.) ---------- components: Windows messages: 234151 nosy: steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Delay-load ShellExecute[AW] in os.startfile type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 00:15:08 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 16 Jan 2015 23:15:08 +0000 Subject: [issue23251] mention in time.sleep() docs that it does not block other Python threads In-Reply-To: <1421448982.95.0.816238681985.issue23251@psf.upfronthosting.co.za> Message-ID: Andrew Svetlov added the comment: I guess R. David Murray asked you to make the least minimal change, even it breaks the formatting rules. Paragraph reflow is safe when it's done by the Core Developer but it requires additional check (and probably mercurial conflict errors on merging the change with default branch if the last has changes also). In your case I see no problems though, but the final decision is on R. David Murray On Sat, Jan 17, 2015 at 12:56 AM, Akira Li wrote: > > Akira Li added the comment: > > I do not understand. Have you tried to look at the patch in Rietveld? > > The new content is highlighted in a darker green. It is clearly > visible. I've tested on Chromium, Firefox, Safari. > > If I won't reflow then the first line will be longer than the > recommended 80 in devguide: > >> The maximum line length is 80 characters for normal text, but >> tables, deeply indented code samples and long links may extend >> beyond that. > > I've set *fill-column* to 80 in emacs. Do you suggest other settings? > > Anyway, it doesn't affect how the final text is shown in a web > browser. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > _______________________________________________ > docs mailing list > docs at python.org > https://mail.python.org/mailman/listinfo/docs ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 00:21:13 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 16 Jan 2015 23:21:13 +0000 Subject: [issue23251] mention in time.sleep() docs that it does not block other Python threads In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za> Message-ID: <1421450473.71.0.340516559978.issue23251@psf.upfronthosting.co.za> Martin Panter added the comment: What I have sometimes done in this situation is just break the overly long line into two short lines ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 02:46:55 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 17 Jan 2015 01:46:55 +0000 Subject: [issue22986] Improved handling of __class__ assignment In-Reply-To: <1417563561.24.0.575634102448.issue22986@psf.upfronthosting.co.za> Message-ID: <20150117014650.69906.74867@psf.io> Roundup Robot added the comment: New changeset d3671e6ba106 by Benjamin Peterson in branch 'default': merge 3.4 (#22986) https://hg.python.org/cpython/rev/d3671e6ba106 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 02:46:55 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 17 Jan 2015 01:46:55 +0000 Subject: [issue23250] http.cookies HttpOnly attribute does not use suggested case-style of HTTP standard In-Reply-To: <1421418300.49.0.235293790837.issue23250@psf.upfronthosting.co.za> Message-ID: <20150117014650.69906.41991@psf.io> Roundup Robot added the comment: New changeset 0d8380c493ad by Benjamin Peterson in branch '3.4': capitialize "HttpOnly" and "Secure" as they appear in the standard and other impls (closes #23250) https://hg.python.org/cpython/rev/0d8380c493ad ---------- nosy: +python-dev resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 02:48:01 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 17 Jan 2015 01:48:01 +0000 Subject: [issue22986] Improved handling of __class__ assignment In-Reply-To: <1417563561.24.0.575634102448.issue22986@psf.upfronthosting.co.za> Message-ID: <1421459281.02.0.370638541244.issue22986@psf.upfronthosting.co.za> Benjamin Peterson added the comment: (That message should have gone to #23250.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 02:50:10 2015 From: report at bugs.python.org (Irmen de Jong) Date: Sat, 17 Jan 2015 01:50:10 +0000 Subject: [issue1103213] Adding the missing socket.recvall() method Message-ID: <1421459410.61.0.767579993028.issue1103213@psf.upfronthosting.co.za> Irmen de Jong added the comment: I created the patch about 5 years ago and in the meantime a few things have happened: - I've not touched C for a very long time now - I've learned that MSG_WAITALL may be unreliable on certain systems, so any implementation of recvall depending on MSG_WAITALL may inexplicably fail on such systems - I've been using a python implementation of a custom recv loop in Pyro4 for years - it is unclear that a C implementation will provide a measurable performance benefit because I think most of the time is spent in the network I/O anyway, and the GIL is released when doing a normal recv (I hope?) In other words, I will never follow up on my original C-based patch from 5 years ago. I do still like the idea of having a reliable recvall in the stdlib instead of having to code a page long one in my own code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 03:24:37 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 17 Jan 2015 02:24:37 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1421461477.06.0.527187347725.issue15745@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 03:51:23 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 17 Jan 2015 02:51:23 +0000 Subject: [issue23251] mention in time.sleep() docs that it does not block other Python threads In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za> Message-ID: <1421463083.72.0.859674296828.issue23251@psf.upfronthosting.co.za> R. David Murray added the comment: I actually didn't know that reitveld was smart enough to highlight just the text changes in a reflowed paragraph. Nevertheless, for ease of looking at diff in the repository using the hg command (which is not that smart), I prefer to commit doc changes without the reflow, then do the reflow in a separate commit. I don't know if other developers do this or not. I think the patch is fine. ---------- stage: -> commit review versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 04:39:19 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 17 Jan 2015 03:39:19 +0000 Subject: [issue15608] Improve socketserver doc In-Reply-To: <1344541466.79.0.410789330017.issue15608@psf.upfronthosting.co.za> Message-ID: <1421465959.67.0.804521052282.issue15608@psf.upfronthosting.co.za> Martin Panter added the comment: The post makes a bit more sense once you realize the dotted numbers refer to old section numbers (which have moved on now): 20.19.2 ? ?Server Objects? section 20.19.1 ? ?Server Creation Notes? Regarding point 2: Instructions for the user to make a threading or forking are still relevant when using a subclass (e.g. HTTPServer) that does not come with a predefined subclass. However documenting which predefined classes exist would be nice too. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 04:40:19 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 17 Jan 2015 03:40:19 +0000 Subject: [issue14307] Make subclassing SocketServer simpler for non-blocking frameworks In-Reply-To: <1331767378.71.0.470789063251.issue14307@psf.upfronthosting.co.za> Message-ID: <1421466019.73.0.853761667094.issue14307@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 04:46:13 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 17 Jan 2015 03:46:13 +0000 Subject: [issue1429] FD leak in SocketServer when request handler throws exception In-Reply-To: <1194870454.07.0.621713310435.issue1429@psf.upfronthosting.co.za> Message-ID: <1421466373.94.0.641041695953.issue1429@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- title: FD leak in SocketServer -> FD leak in SocketServer when request handler throws exception _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 04:50:47 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 17 Jan 2015 03:50:47 +0000 Subject: [issue13354] tcpserver should document non-threaded long-living connections In-Reply-To: <1320570611.72.0.286817751979.issue13354@psf.upfronthosting.co.za> Message-ID: <1421466647.26.0.936597655686.issue13354@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 04:58:39 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 17 Jan 2015 03:58:39 +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: <1421467119.15.0.150306512241.issue15955@psf.upfronthosting.co.za> Martin Panter added the comment: Adding issue15955_lzma_r5.diff. Main changes from r4: * Consistent Py_ssize_t type for data_size * max_size ? max_length to match Python parameter name * Arranged for EOF handling to occur before, and instead of, saving the input buffer * Removed my LZMAFile test Nikolaus, I hope I am not getting in your way by updating this patch. I though I should take responsibility for removing the test I accidentally added in r4. ---------- Added file: http://bugs.python.org/file37734/issue15955_lzma_r5.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 05:32:55 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 17 Jan 2015 04:32:55 +0000 Subject: [issue23254] Document how to close the TCPServer listening socket Message-ID: <1421469175.0.0.628748486385.issue23254@psf.upfronthosting.co.za> New submission from Martin Panter: Running the example from the Asynchronous Mixins section of the ?socketserver? documentation generates a ResourceWarning: $ ./python -btWall ThreadedTCPServer.py Server loop running in thread: Thread-1 Received: Thread-2: Hello World 1 Received: Thread-3: Hello World 2 Received: Thread-4: Hello World 3 sys:1: ResourceWarning: unclosed There is a server_close() method mentioned in the doc string of the BaseServer class, so I assume it is meant to be part of the API. But there is no mention of it in the reference documentation. I think server.server_close() should be documented, and called after server.shutdown() in the example. A further enhancement might be to turn BaseServer into a context manager, but I would be happy with using the existing server_close() method. ---------- assignee: docs at python components: Documentation messages: 234161 nosy: docs at python, vadmium priority: normal severity: normal status: open title: Document how to close the TCPServer listening socket type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 05:58:27 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 17 Jan 2015 04:58:27 +0000 Subject: [issue23220] IDLE does not display \b backspace correctly. In-Reply-To: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za> Message-ID: <1421470707.77.0.852183213383.issue23220@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Going back to msdos, there are graphic chars for all 256 bytes, including may single and double line box-drawing chars. Many In Idle, I see 5 solid white circles. In FireFox, there are 5 empty circles (on dark background, which are chr(9689). When I copy from FF back to Idle (3.4.2, Win7), there are 5 of each. I have no idea if the 9689s are on the site or added by FF. Here is another difference. >>> print('\x03') # console ? # heart >>> print('\x03') # idle  # lower left single line corner in Idle, box on FF Trying to match console-Idle(tk) print output for control chars even on Windows would be tough. --- I have been planning to add a subsection of the doc that mentions known differences between console interpreter and Idle shell. The result of print() is one of them. Another print difference is that Idle displays many unicode chars that Windows replaces with boxes or ?s, depending on the codepage. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 07:26:41 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 17 Jan 2015 06:26:41 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1421476001.68.0.854161571528.issue3566@psf.upfronthosting.co.za> Martin Panter added the comment: Okay here is a demonstration script, which does two tests: a short basic GET request, and a 2 MB POST request. Output for me is usually: Platform: Linux-3.15.5-2-ARCH-x86_64-with-arch Normal request: getresponse() raised BadStatusLine("''",) 2 MB request: request() raised BrokenPipeError(32, 'Broken pipe'); errno=EPIPE Sometimes I get a BadStatusLine even for the second request: Platform: Linux-3.15.5-2-ARCH-x86_64-with-arch Normal request: getresponse() raised BadStatusLine("''",) 2 MB request: getresponse() raised BadStatusLine("''",) ---------- Added file: http://bugs.python.org/file37735/persistent-closing.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 12:12:55 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 17 Jan 2015 11:12:55 +0000 Subject: [issue20420] BufferedIncrementalEncoder violates IncrementalEncoder interface In-Reply-To: <1390926885.67.0.351173619746.issue20420@psf.upfronthosting.co.za> Message-ID: <1421493175.03.0.736990812859.issue20420@psf.upfronthosting.co.za> Martin Panter added the comment: For what it?s worth, both io.TextIOWrapper and _pyio.TextIOWrapper appear to only ever call IncrementalEncoder.setstate(0). And the newline _decoder_ is not relevant because it doesn?t use any _encoder_. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 14:50:23 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 17 Jan 2015 13:50:23 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1421502623.16.0.121225281853.issue3566@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 14:51:58 2015 From: report at bugs.python.org (Ent) Date: Sat, 17 Jan 2015 13:51:58 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. Message-ID: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> New submission from Ent: Use of http.server.BaseHTTPRequestHandler for exploratory or simple usage, SimpleHTTPRequestHandler provides a good platform to start on. However, the current code in SimpleHTTPRequestHandler's send_head is tightly coupled together as a single unit. This patch aims to break send_head down into composable parts so that any developer can subclass SimpleHTTPRequestHandler to create one's own HTTPRequestHandler class with their own custom behaviour without having to rewrite a lot of repeated code. For example consider a developer wanting to address two usecases * Use SimpleHTTPRequestHandler, but use index.html from a different directory. * For certain GET urls, call on a specific function to response. * Use custom html page instead of index.html class CustomHTTPRequestHandler(SimpleHTTPRequestHandler): def do_GET(self): if self.path =='/': f = self.home_head() elif self.path in self.custom_paths: f = self.special_head() else: f = self.send_head() # ... # Standard Code As a result of the patch, in above scenario instead of copy-pasting logic for browser redirection, getting object for file or directory and, applying headers upon success; Developer can use methods redirect_browser, get_dir_or_html_dir_path and, apply_headers to reduce the code. Basically, applying DRY principle. Note: Since this is but refactoring of existing code without any new functionality being added, no test cases are provided. ---------- components: Library (Lib) files: simplehttp.patch keywords: patch messages: 234165 nosy: last-ent priority: normal severity: normal status: open title: SimpleHTTPRequestHandler refactor for more extensible usage. type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file37736/simplehttp.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 14:54:32 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 17 Jan 2015 13:54:32 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1421502872.94.0.439428416774.issue23255@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> patch review versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 14:55:34 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 17 Jan 2015 13:55:34 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1421502934.83.0.476711375731.issue23255@psf.upfronthosting.co.za> Berker Peksag added the comment: > + base_files = ['index.html', 'index.html'] I guess this should be ['index.htm', 'index.html']. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 15:11:59 2015 From: report at bugs.python.org (Ent) Date: Sat, 17 Jan 2015 14:11:59 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1421503919.52.0.783150430452.issue23255@psf.upfronthosting.co.za> Ent added the comment: Changing base_files to point @ ['index.htm', 'index.html'] ---------- Added file: http://bugs.python.org/file37737/simplehttp1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 15:34:14 2015 From: report at bugs.python.org (Claudiu Popa) Date: Sat, 17 Jan 2015 14:34:14 +0000 Subject: [issue23256] test_ctypes crashes on Windows on debug builds Message-ID: <1421505254.13.0.888402709711.issue23256@psf.upfronthosting.co.za> New submission from Claudiu Popa: Hi, Doing the following on Windows leads to a nasty crash "python_d -m test test_ctypes": [1/1] test_ctypes Fatal Python error: Segmentation fault Current thread 0x000016fc (most recent call first): File "E:\Projects\repos\cpython\lib\unittest\case.py", line 162 in handle File "E:\Projects\repos\cpython\lib\unittest\case.py", line 704 in assertRaises File "E:\Projects\repos\cpython\lib\ctypes\test\test_win32.py", line 47 in test_SEH File "E:\Projects\repos\cpython\lib\unittest\case.py", line 577 in run File "E:\Projects\repos\cpython\lib\unittest\case.py", line 625 in __call__ File "E:\Projects\repos\cpython\lib\unittest\suite.py", line 125 in run File "E:\Projects\repos\cpython\lib\unittest\suite.py", line 87 in __call__ File "E:\Projects\repos\cpython\lib\unittest\suite.py", line 125 in run File "E:\Projects\repos\cpython\lib\unittest\suite.py", line 87 in __call__ File "E:\Projects\repos\cpython\lib\unittest\suite.py", line 125 in run File "E:\Projects\repos\cpython\lib\unittest\suite.py", line 87 in __call__ File "E:\Projects\repos\cpython\lib\unittest\suite.py", line 125 in run File "E:\Projects\repos\cpython\lib\unittest\suite.py", line 87 in __call__ File "E:\Projects\repos\cpython\lib\unittest\suite.py", line 125 in run File "E:\Projects\repos\cpython\lib\unittest\suite.py", line 87 in __call__ File "E:\Projects\repos\cpython\lib\test\support\__init__.py", line 1669 in run File "E:\Projects\repos\cpython\lib\test\support\__init__.py", line 1770 in _run_suite File "E:\Projects\repos\cpython\lib\test\support\__init__.py", line 1804 in run_unittest File "E:\Projects\repos\cpython\lib\test\regrtest.py", line 1283 in test_runner File "E:\Projects\repos\cpython\lib\test\regrtest.py", line 1284 in runtest_inner File "E:\Projects\repos\cpython\lib\test\regrtest.py", line 978 in runtest File "E:\Projects\repos\cpython\lib\test\regrtest.py", line 763 in main File "E:\Projects\repos\cpython\lib\test\regrtest.py", line 1568 in main_in_temp_cwd File "E:\Projects\repos\cpython\lib\test\__main__.py", line 3 in File "E:\Projects\repos\cpython\lib\runpy.py", line 85 in _run_code File "E:\Projects\repos\cpython\lib\runpy.py", line 170 in _run_module_as_main It seems that test_SEH is not properly skipped, since on my machine, sys.executable is in fact cpython\PCbuild\win32\python_d.EXE. Not sure from where the .EXE part comes, but the following patch makes the test pass. diff -r d3671e6ba106 Lib/ctypes/test/test_win32.py --- a/Lib/ctypes/test/test_win32.py Fri Jan 16 20:46:37 2015 -0500 +++ b/Lib/ctypes/test/test_win32.py Sat Jan 17 16:32:23 2015 +0200 @@ -38,7 +38,7 @@ @unittest.skipUnless(sys.platform == "win32", 'Windows-specific test') class FunctionCallTestCase(unittest.TestCase): @unittest.skipUnless('MSC' in sys.version, "SEH only supported by MSC") - @unittest.skipIf(sys.executable.endswith('_d.exe'), + @unittest.skipIf(sys.executable.lower().endswith('_d.exe'), "SEH not enabled in debug builds") def test_SEH(self): # Call functions with invalid arguments, and make sure ---------- components: ctypes messages: 234168 nosy: Claudiu.Popa, zach.ware priority: low severity: normal stage: patch review status: open title: test_ctypes crashes on Windows on debug builds type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 15:53:21 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 17 Jan 2015 14:53:21 +0000 Subject: [issue23256] test_ctypes crashes on Windows on debug builds In-Reply-To: <1421505254.13.0.888402709711.issue23256@psf.upfronthosting.co.za> Message-ID: <20150117145318.118086.41479@psf.io> Roundup Robot added the comment: New changeset 2bbd7b739b85 by Zachary Ware in branch '3.4': Closes #23256: Avoid a crash in test_ctypes https://hg.python.org/cpython/rev/2bbd7b739b85 New changeset b5821f7493c1 by Zachary Ware in branch 'default': Merge with 3.4 (#23256) https://hg.python.org/cpython/rev/b5821f7493c1 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 15:55:55 2015 From: report at bugs.python.org (Zachary Ware) Date: Sat, 17 Jan 2015 14:55:55 +0000 Subject: [issue23256] test_ctypes crashes on Windows on debug builds In-Reply-To: <1421505254.13.0.888402709711.issue23256@psf.upfronthosting.co.za> Message-ID: <1421506555.98.0.331487589835.issue23256@psf.upfronthosting.co.za> Zachary Ware added the comment: The .EXE is very strange, but the fix was simple enough. Thanks for the report. ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 16:19:58 2015 From: report at bugs.python.org (Claudiu Popa) Date: Sat, 17 Jan 2015 15:19:58 +0000 Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za> Message-ID: <1421507998.94.0.569269484538.issue15582@psf.upfronthosting.co.za> Claudiu Popa added the comment: Yury, regarding your last message, is it actually possible to have a subclass which doesn't have a __doc__ attribute in its __dict__, except using slots? __doc__ seems to be set to None every time if it's not specified, so I don't know how could I detect the case where the client sets '__doc__ = None' himself. The following example might be more explanatory: >>> class A: ... __doc__ = "a" ... >>> inspect.getdoc(A) 'a' >>> inspect.getdoc(A()) 'a' >>> class B(A): ... __doc__ = None ... >>> vars(B) mappingproxy({'__doc__': None, '__module__': '__main__'}) >>> B.__dict__ mappingproxy({'__doc__': None, '__module__': '__main__'}) >>> class C(A): pass ... >>> vars(C) mappingproxy({'__doc__': None, '__module__': '__main__'}) >>> Nevertheless, my patch ignores this case, since it operates only on methods. When trying to do inspect.getdoc(Child, parent=Parent), it will try to look for an attribute 'Child' in the mro of Parent and thus it will return None, since this doesn't exist (this can actually be a problem, if that attribute actually exist). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 16:22:31 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 17 Jan 2015 15:22:31 +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: <20150117152228.118084.27035@psf.io> Roundup Robot added the comment: New changeset 00e552a23bcc by Antoine Pitrou in branch 'default': Issue #15955: Add an option to limit output size when decompressing LZMA data. https://hg.python.org/cpython/rev/00e552a23bcc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 16:23:09 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 17 Jan 2015 15:23:09 +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: <1421508189.34.0.323114869605.issue15955@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I've committed the LZMADecompressor patch. Now let's tackle the rest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 16:58:05 2015 From: report at bugs.python.org (Claudiu Popa) Date: Sat, 17 Jan 2015 15:58:05 +0000 Subject: [issue6700] inspect.getsource() returns incorrect source lines In-Reply-To: <1250223562.74.0.274098839265.issue6700@psf.upfronthosting.co.za> Message-ID: <1421510285.83.0.806972965697.issue6700@psf.upfronthosting.co.za> Changes by Claudiu Popa : ---------- nosy: +Claudiu.Popa, yselivanov versions: +Python 3.5 -Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 17:15:32 2015 From: report at bugs.python.org (Claudiu Popa) Date: Sat, 17 Jan 2015 16:15:32 +0000 Subject: [issue21817] `concurrent.futures.ProcessPoolExecutor` swallows tracebacks In-Reply-To: <1403302402.66.0.944637105053.issue21817@psf.upfronthosting.co.za> Message-ID: <1421511332.87.0.0240996310986.issue21817@psf.upfronthosting.co.za> Claudiu Popa added the comment: Here's the updated version of this patch. ---------- type: behavior -> enhancement versions: -Python 3.4 Added file: http://bugs.python.org/file37738/issue21817_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 17:20:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 17 Jan 2015 16:20:24 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1421511624.12.0.555907317837.issue22995@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It is hard to write good tests, because every example is temporary, after adding support of pickling it will be not valid. Here is extended patch. It now handles Python subclasses of builtin classes (except list and dict which are pickleable via iterators) such as socket.socket. Removed several guarding __getstate__() methods. Added few new tests. ---------- Added file: http://bugs.python.org/file37739/pickle_restrictions_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 17:54:12 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 17 Jan 2015 16:54:12 +0000 Subject: [issue23251] mention in time.sleep() docs that it does not block other Python threads In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za> Message-ID: <1421513652.32.0.59016378924.issue23251@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think it's superfluous to mention the GIL here, since it has no impact on the function. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 18:13:52 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 17 Jan 2015 17:13:52 +0000 Subject: [issue23257] Update Windows build/setup instructions in devguide Message-ID: <1421514832.21.0.130284458039.issue23257@psf.upfronthosting.co.za> New submission from Steve Dower: This seems like the best (only?) way to get a devguide patch reviewed... I don't have any concerns, but other people may have some more suggestions for this section that I'm happy to add. ---------- assignee: steve.dower components: Devguide, Windows files: winbuild.patch keywords: patch messages: 234177 nosy: eric.araujo, ezio.melotti, ncoghlan, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: patch review status: open title: Update Windows build/setup instructions in devguide versions: Python 3.5 Added file: http://bugs.python.org/file37740/winbuild.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 18:22:45 2015 From: report at bugs.python.org (SilentGhost) Date: Sat, 17 Jan 2015 17:22:45 +0000 Subject: [issue23257] Update Windows build/setup instructions in devguide In-Reply-To: <1421514832.21.0.130284458039.issue23257@psf.upfronthosting.co.za> Message-ID: <1421515365.7.0.325535485979.issue23257@psf.upfronthosting.co.za> SilentGhost added the comment: Couple of things: 1. "chosen chosen" 2. double space needed before "You can invoke..." ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 18:50:16 2015 From: report at bugs.python.org (Claudiu Popa) Date: Sat, 17 Jan 2015 17:50:16 +0000 Subject: [issue22080] Add windows_helper module helper In-Reply-To: <1406378373.46.0.337360125553.issue22080@psf.upfronthosting.co.za> Message-ID: <1421517016.57.0.141333320041.issue22080@psf.upfronthosting.co.za> Claudiu Popa added the comment: Here's a cleaned up version of the patch. ---------- Added file: http://bugs.python.org/file37741/issue22080_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 18:53:05 2015 From: report at bugs.python.org (Claudiu Popa) Date: Sat, 17 Jan 2015 17:53:05 +0000 Subject: [issue21518] Expose RegUnloadKey in winreg In-Reply-To: <1400346760.52.0.0203244636304.issue21518@psf.upfronthosting.co.za> Message-ID: <1421517185.77.0.805242646355.issue21518@psf.upfronthosting.co.za> Claudiu Popa added the comment: The new patch drops the weird error dance from test_unload_key, it seems to work without it, I don't remember how it failed without it. ---------- Added file: http://bugs.python.org/file37742/issue21518_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 18:54:35 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 17 Jan 2015 17:54:35 +0000 Subject: [issue21817] `concurrent.futures.ProcessPoolExecutor` swallows tracebacks In-Reply-To: <1403302402.66.0.944637105053.issue21817@psf.upfronthosting.co.za> Message-ID: <1421517275.04.0.231098573947.issue21817@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hi, here are some comments about the patch: - RemoteTraceback, ExceptionWithTraceback, rebuild_exc should be private (i.e. with a leading underscore) - in test_traceback, you can use the context manager form of assertRaises instead of the try..except..else construct ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 18:56:18 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 17 Jan 2015 17:56:18 +0000 Subject: [issue23257] Update Windows build/setup instructions in devguide In-Reply-To: <1421514832.21.0.130284458039.issue23257@psf.upfronthosting.co.za> Message-ID: <1421517378.31.0.533049627935.issue23257@psf.upfronthosting.co.za> Steve Dower added the comment: Thanks! Haven't updated the patch, but I've fixed them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 18:59:01 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 17 Jan 2015 17:59:01 +0000 Subject: [issue20916] ssl.enum_certificates() will not return all certificates trusted by Windows In-Reply-To: <1394740101.16.0.76901026465.issue20916@psf.upfronthosting.co.za> Message-ID: <1421517541.02.0.762669245963.issue20916@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 19:00:14 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 17 Jan 2015 18:00:14 +0000 Subject: [issue23253] Delay-load ShellExecute[AW] in os.startfile In-Reply-To: <1421449910.62.0.491687570058.issue23253@psf.upfronthosting.co.za> Message-ID: <1421517614.33.0.280180554968.issue23253@psf.upfronthosting.co.za> Steve Dower added the comment: Attached a patch. Comparing the time for "python.exe -c '0'" with Powershell's Measure-Command tool, it looks like there's a 3-4ms (~8-10%) improvement in startup time too. That's not at all robust, but it's certainly no worse. (I'm not surprised - shell32.dll is a horrendously big dependency and we're better off without it.) ---------- keywords: +patch Added file: http://bugs.python.org/file37743/23253.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 19:00:33 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 17 Jan 2015 18:00:33 +0000 Subject: [issue23253] Delay-load ShellExecute[AW] in os.startfile In-Reply-To: <1421449910.62.0.491687570058.issue23253@psf.upfronthosting.co.za> Message-ID: <1421517633.16.0.443040808037.issue23253@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- assignee: -> steve.dower stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 19:01:25 2015 From: report at bugs.python.org (Akira Li) Date: Sat, 17 Jan 2015 18:01:25 +0000 Subject: [issue23251] mention in time.sleep() docs that it does not block other Python threads In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za> Message-ID: <1421517685.05.0.894528663465.issue23251@psf.upfronthosting.co.za> Akira Li added the comment: > I think it's superfluous to mention the GIL here, since it has no impact on the function. If GIL is not released then all Python code in other threads is effectively blocked. It is worth mentioning explicitly that it is guaranteed to be released during the sleep. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 19:03:47 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 17 Jan 2015 18:03:47 +0000 Subject: [issue23251] mention in time.sleep() docs that it does not block other Python threads In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za> Message-ID: <1421517827.11.0.420423604116.issue23251@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > If GIL is not released then all Python code in other threads is > effectively blocked. But that would be a stupid implementation of sleep(). It is not desirable to clutter the docs with such mentions: most calls to the OS in the stdlib release the GIL. Only if the behaviour was unintuitive (i.e. if it *didn't* release the GIL) would it make sense to document it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 19:05:09 2015 From: report at bugs.python.org (Claudiu Popa) Date: Sat, 17 Jan 2015 18:05:09 +0000 Subject: [issue21817] `concurrent.futures.ProcessPoolExecutor` swallows tracebacks In-Reply-To: <1403302402.66.0.944637105053.issue21817@psf.upfronthosting.co.za> Message-ID: <1421517909.01.0.750701337556.issue21817@psf.upfronthosting.co.za> Claudiu Popa added the comment: Thanks, Antoine! Here's the new version, with your comments addressed. ---------- Added file: http://bugs.python.org/file37744/issue21817_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 19:14:48 2015 From: report at bugs.python.org (Claudiu Popa) Date: Sat, 17 Jan 2015 18:14:48 +0000 Subject: [issue22522] sys.excepthook doesn't receive the traceback when called from code.InteractiveInterpreter In-Reply-To: <1412076539.24.0.326910714196.issue22522@psf.upfronthosting.co.za> Message-ID: <1421518488.86.0.893789482047.issue22522@psf.upfronthosting.co.za> Claudiu Popa added the comment: Ping. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 19:35:58 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 17 Jan 2015 18:35:58 +0000 Subject: [issue23251] mention in time.sleep() docs that it does not block other Python threads In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za> Message-ID: <1421519758.12.0.957858645713.issue23251@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, on consideration I agree with Antoine. That last sentence should be deleted. Otherwise we'd need to mention that the gil was released every place that the gil was released, which would be very redundant. The general rule is that anything that blocks in python releases the GIL, therefore as Antoine says the only time we need to document GIL behavior is when that *doesn't* happen. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 19:37:11 2015 From: report at bugs.python.org (Ethan Furman) Date: Sat, 17 Jan 2015 18:37:11 +0000 Subject: [issue20284] patch to implement PEP 461 (%-interpolation for bytes) In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <1421519831.17.0.0374787731341.issue20284@psf.upfronthosting.co.za> Ethan Furman added the comment: Better patch, along the lines of my original thought: - byarrayformat converts bytearray to bytes - calls bytesformat (now _PyBytes_Format) to do the heavy lifting - uses PyByteArray_FromObject to tranform back to bytearray Now working on in-place format. ---------- Added file: http://bugs.python.org/file37745/issue20284.stoneleaf.03.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 19:54:16 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 17 Jan 2015 18:54:16 +0000 Subject: [issue23239] SSL match_hostname does not accept IP Address In-Reply-To: <1421226292.77.0.451398063166.issue23239@psf.upfronthosting.co.za> Message-ID: <1421520856.26.0.31369666059.issue23239@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch. ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 19:54:25 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 17 Jan 2015 18:54:25 +0000 Subject: [issue23239] SSL match_hostname does not accept IP Address In-Reply-To: <1421226292.77.0.451398063166.issue23239@psf.upfronthosting.co.za> Message-ID: <1421520865.89.0.00193477275409.issue23239@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- keywords: +patch Added file: http://bugs.python.org/file37746/ip_certs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 20:02:48 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 17 Jan 2015 19:02:48 +0000 Subject: [issue21817] `concurrent.futures.ProcessPoolExecutor` swallows tracebacks In-Reply-To: <1403302402.66.0.944637105053.issue21817@psf.upfronthosting.co.za> Message-ID: <20150117190246.104120.1603@psf.io> Roundup Robot added the comment: New changeset a36b402b099b by Antoine Pitrou in branch 'default': Issue #21817: When an exception is raised in a task submitted to a ProcessPoolExecutor, the remote traceback is now displayed in the parent process. https://hg.python.org/cpython/rev/a36b402b099b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 20:04:00 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 17 Jan 2015 19:04:00 +0000 Subject: [issue21817] `concurrent.futures.ProcessPoolExecutor` swallows tracebacks In-Reply-To: <1403302402.66.0.944637105053.issue21817@psf.upfronthosting.co.za> Message-ID: <1421521440.01.0.949259052102.issue21817@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thank you very much. Everything is now committed. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 20:26:53 2015 From: report at bugs.python.org (steve) Date: Sat, 17 Jan 2015 19:26:53 +0000 Subject: [issue23258] Cannot Install Python 3.4.2 on Windows 7 64 bit / screen print attached Message-ID: <1421522813.3.0.624329571132.issue23258@psf.upfronthosting.co.za> New submission from steve: I down loaded and tried to install version 3.4.2 on a Windows 7 64 bit system. 2 error messages came up saying that I had to stop two Windows systems tasks to allow the install to complete. Please see the attached screen print for details. What can I do to resolve this install problem ??? ---------- components: Windows files: Python_install-error-mgg.png messages: 234193 nosy: 20scanman, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Cannot Install Python 3.4.2 on Windows 7 64 bit / screen print attached versions: Python 3.4 Added file: http://bugs.python.org/file37747/Python_install-error-mgg.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 20:35:36 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 17 Jan 2015 19:35:36 +0000 Subject: [issue23248] Update ssl data In-Reply-To: <1421396221.93.0.559881277875.issue23248@psf.upfronthosting.co.za> Message-ID: <1421523336.53.0.575706611585.issue23248@psf.upfronthosting.co.za> Antoine Pitrou added the comment: New patch merges in the old codes. ---------- Added file: http://bugs.python.org/file37748/update_ssl_data2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 20:36:42 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 17 Jan 2015 19:36:42 +0000 Subject: [issue23248] Update ssl data In-Reply-To: <1421396221.93.0.559881277875.issue23248@psf.upfronthosting.co.za> Message-ID: <1421523402.81.0.834450238476.issue23248@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 21:00:29 2015 From: report at bugs.python.org (Mayank Tripathi) Date: Sat, 17 Jan 2015 20:00:29 +0000 Subject: [issue21862] cProfile command-line should accept "-m module_name" as an alternative to script path In-Reply-To: <1403640414.18.0.449527177368.issue21862@psf.upfronthosting.co.za> Message-ID: <1421524829.09.0.375870902675.issue21862@psf.upfronthosting.co.za> Mayank Tripathi added the comment: Now allows parameters after the -m option. ---------- nosy: +oquanox Added file: http://bugs.python.org/file37749/cProfile_module_option.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 21:21:03 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 17 Jan 2015 20:21:03 +0000 Subject: [issue23199] libpython27.a in amd64 release is 32-bit In-Reply-To: <1420764337.42.0.255694319213.issue23199@psf.upfronthosting.co.za> Message-ID: <1421526063.11.0.379852952705.issue23199@psf.upfronthosting.co.za> Steve Dower added the comment: So I've grabbed gendef and dlltool from the latest mingw-w64 and will look at using those in the future for both 2.7 and 3.5. According to objdump, I can use these to create file format pe-i386 and pe-x86-64 with the same tools. Are these the correct formats for 32-bit and 64-bit respectively? My commands are (approximately): gendef - python35.dll > mingwlib.def dlltool --dllname python35.dll --def mingwlib.def --output-lib amd64\libpython35.a -m i386:x86-64 dlltool --dllname python35.dll --def mingwlib.def --output-lib win32\libpython35.a -m i386 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 21:39:50 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 17 Jan 2015 20:39:50 +0000 Subject: [issue23258] Cannot Install Python 3.4.2 on Windows 7 64 bit / screen print attached In-Reply-To: <1421522813.3.0.624329571132.issue23258@psf.upfronthosting.co.za> Message-ID: <1421527190.23.0.124445752599.issue23258@psf.upfronthosting.co.za> Steve Dower added the comment: You can close those applications, or ignore the message and continue, just like the dialog says (if you ignore it, you may need to reboot for installation to complete). You could also try doing a Just for Me installation. Python is not trying to update those programs, which means those programs are blocking Python. You should look for their documentation on how to close them, or report this as a problem to them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 21:46:06 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 17 Jan 2015 20:46:06 +0000 Subject: [issue23259] Remove dummy reuse optimization from sets Message-ID: <1421527566.61.0.766748710579.issue23259@psf.upfronthosting.co.za> New submission from Raymond Hettinger: The lookkey routines in Object/setobject.c have logic to track the first open "freeslot" in a search. The benefit is that new keys can reuse previously deleted slots. The benefit only occurs in cases where keys are added, then some removed, and then more added with no intervening resizes (which clear all dummy entries) and only when the newly added keys happen to land on previously deleted entries. The cost of the optimization is the extra logic in the inner search loop, an extra freeslot stackframe field that needs to be saved and restored, and extra logic on the loop exit. It also causes dummies to "leak" out of the lookkey routines so that the code in contains(), discard(), and insert() all have to check for the dummy case. This patch removes the freeslot tracking. It saves one field on the stackframe, simplifies the lookkey inner-loop logic, simplifies the lookkey "found_null" logic, it confines knowledge of dummies to just the lookkey functions, and it simplifies the code in the insert(), contains(), and discard() functions. In short, it looks like the freeslot idea was a net negative -- it optimized an uncommon case at the cost of slowing and complicating the common cases. ---------- assignee: rhettinger components: Interpreter Core files: late8.diff keywords: patch messages: 234198 nosy: rhettinger priority: low severity: normal stage: patch review status: open title: Remove dummy reuse optimization from sets type: performance versions: Python 3.5 Added file: http://bugs.python.org/file37750/late8.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 22:12:40 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 17 Jan 2015 21:12:40 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1421529160.84.0.418906873187.issue23255@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 22:21:03 2015 From: report at bugs.python.org (Tim Golden) Date: Sat, 17 Jan 2015 21:21:03 +0000 Subject: [issue23253] Delay-load ShellExecute In-Reply-To: <1421517614.33.0.280180554968.issue23253@psf.upfronthosting.co.za> Message-ID: <54BAD252.6060806@timgolden.me.uk> Tim Golden added the comment: I'm +0.75. I think the idea's fine in principle and the patch (by inspection) seems to do the right things. My only concerns are: that posixmodule.c becomes even longer and more involved; and that the benefit might not quite be great enough to justify the added complexity. ---------- title: Delay-load ShellExecute[AW] in os.startfile -> Delay-load ShellExecute _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 22:44:01 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 17 Jan 2015 21:44:01 +0000 Subject: [issue23259] Remove dummy reuse optimization from sets In-Reply-To: <1421527566.61.0.766748710579.issue23259@psf.upfronthosting.co.za> Message-ID: <1421531041.58.0.0371728597931.issue23259@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This can be a common case in following algorithm (mesh optimization): while elems: elem = elems.pop() changed = optimize(elem) if changed: elems.update(neighbors(elem)) ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 23:00:06 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 17 Jan 2015 22:00:06 +0000 Subject: [issue23253] Delay-load ShellExecute In-Reply-To: <1421449910.62.0.491687570058.issue23253@psf.upfronthosting.co.za> Message-ID: <1421532006.91.0.00700663216242.issue23253@psf.upfronthosting.co.za> Steve Dower added the comment: Yeah, I hate touching posixmodule.c for the same reason. It'd be nice to split it up into separate platform files, but nobody is volunteering for that. If you focus on the performance, then yeah, this change probably isn't worth it. OTOH, the number of Windows platforms keep increasing (e.g. ARM, phone/tablet/various sandboxes, etc.) and the fewer dependencies we have the more likely Python will Just Work in them. (And the more value that a split up posixmodule.c will have... guess it'll have to happen eventually.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 17 23:43:15 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 17 Jan 2015 22:43:15 +0000 Subject: [issue18022] Inconsistency between quopri.decodestring() and email.quoprimime.decode() In-Reply-To: <1369059208.07.0.0770184639372.issue18022@psf.upfronthosting.co.za> Message-ID: <1421534595.42.0.0398502387472.issue18022@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 00:11:30 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 17 Jan 2015 23:11:30 +0000 Subject: [issue22919] Update PCBuild for VS 2015 In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za> Message-ID: <1421536290.81.0.997982518718.issue22919@psf.upfronthosting.co.za> Steve Dower added the comment: Closing again, as Victor's issue was resolved (VS 2010 SP1 is needed, and I'm updating the devguide to specify that on #23257). ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 00:12:41 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 17 Jan 2015 23:12:41 +0000 Subject: [issue23260] Update Windows installer Message-ID: <1421536361.51.0.300522765173.issue23260@psf.upfronthosting.co.za> New submission from Steve Dower: Updating the installer for better security and robustness. Large patch coming soon (just getting an issue number to put in NEWS). ---------- assignee: steve.dower components: Windows messages: 234203 nosy: steve.dower, tim.golden, zach.ware priority: release blocker severity: normal status: open title: Update Windows installer type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 00:23:20 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 17 Jan 2015 23:23:20 +0000 Subject: [issue23260] Update Windows installer In-Reply-To: <1421536361.51.0.300522765173.issue23260@psf.upfronthosting.co.za> Message-ID: <1421537000.76.0.441118328313.issue23260@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 00:50:24 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 17 Jan 2015 23:50:24 +0000 Subject: [issue23260] Update Windows installer In-Reply-To: <1421536361.51.0.300522765173.issue23260@psf.upfronthosting.co.za> Message-ID: <1421538624.42.0.299601119312.issue23260@psf.upfronthosting.co.za> Steve Dower added the comment: Patch. I'm also revising Doc/using/windows.rst, but I don't want to delay the initial reviews. I don't think this is perfect, but it works well enough for the first alpha (scheduled for 8 Feb), so I want to get it in and stabilised now rather than at the last minute. There'll be more features and work to do. There's a README.txt file (which I'll attach next) that has an overview of the installer. It'll be worth reading that first before looking at the code. And apologies if the code makes no sense. I'm happy to explain sections, but WiX is about 90% magic (and the rest is MSBuild magic) and so any explanation is likely to be unsatisfactory. I've been working with both of these pretty intently for the last few years and I still don't feel like I've mastered them... ---------- keywords: +patch Added file: http://bugs.python.org/file37751/23260_1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 00:50:46 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 17 Jan 2015 23:50:46 +0000 Subject: [issue23260] Update Windows installer In-Reply-To: <1421536361.51.0.300522765173.issue23260@psf.upfronthosting.co.za> Message-ID: <1421538646.71.0.196309858305.issue23260@psf.upfronthosting.co.za> Changes by Steve Dower : Added file: http://bugs.python.org/file37752/README.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 00:52:25 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 17 Jan 2015 23:52:25 +0000 Subject: [issue23259] Remove dummy reuse optimization from sets In-Reply-To: <1421527566.61.0.766748710579.issue23259@psf.upfronthosting.co.za> Message-ID: <1421538745.45.0.265538821787.issue23259@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Even in the mesh algorithm, we let resizing periodically clean-up the dummies. The idea is to not pay the freeslot tracking cost on every lookup and instead only clean-up periodically (which would likely give better performance for the mesh algorithm as well, since making a single pass clean-up during resizing is cheaper than doing multi-step tracking for every insertion). The slots do get reused, just not immediately. Also, the idea is to not let the possibility of pop-change-update algorithms create a cost for the more common uses of sets (uniquification, fast membership testing, and set-to-set operations such as union, intersection, and difference). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 01:19:04 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 18 Jan 2015 00:19:04 +0000 Subject: [issue23231] Fix codecs.iterencode/decode() by allowing data parameter to be omitted In-Reply-To: <1421153299.35.0.701583632763.issue23231@psf.upfronthosting.co.za> Message-ID: <1421540344.61.0.83422119337.issue23231@psf.upfronthosting.co.za> Martin Panter added the comment: Another idea that doesn?t involve changing the incremental codec APIs is kind of described in : to add format parameters to iterencode() and iterdecode(), which would allow it to determine the right data type to finalize the codecs with. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 01:31:23 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 18 Jan 2015 00:31:23 +0000 Subject: [issue23259] Remove dummy reuse optimization from sets In-Reply-To: <1421527566.61.0.766748710579.issue23259@psf.upfronthosting.co.za> Message-ID: <1421541083.05.0.566948135677.issue23259@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > In short, it looks like the freeslot idea was a net negative -- it > optimized an uncommon case at the cost of slowing and complicating the > common cases. Do you have a benchmark showing the slowing down? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 02:00:28 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 18 Jan 2015 01:00:28 +0000 Subject: [issue23211] test.test_logging.SMTPHandlerTest failing on Snow Leopard In-Reply-To: <1420832632.4.0.00679469135671.issue23211@psf.upfronthosting.co.za> Message-ID: <20150118010015.93185.12649@psf.io> Roundup Robot added the comment: New changeset 90b664532d1c by Ned Deily in branch '3.4': Issue #23211: Workaround test_logging failure on some OS X 10.6 systems: https://hg.python.org/cpython/rev/90b664532d1c New changeset e3dfe942697e by Ned Deily in branch 'default': Issue #23211: merge from 3.4 https://hg.python.org/cpython/rev/e3dfe942697e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 02:02:20 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 18 Jan 2015 01:02:20 +0000 Subject: [issue23211] test.test_logging.SMTPHandlerTest failing on Snow Leopard In-Reply-To: <1420832632.4.0.00679469135671.issue23211@psf.upfronthosting.co.za> Message-ID: <1421542940.33.0.33103605221.issue23211@psf.upfronthosting.co.za> Ned Deily added the comment: OK, the workaround is applied for 3.4.3 and 3.5.0. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 02:20:01 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 18 Jan 2015 01:20:01 +0000 Subject: [issue23259] Remove dummy reuse optimization from sets In-Reply-To: <1421527566.61.0.766748710579.issue23259@psf.upfronthosting.co.za> Message-ID: <1421544001.06.0.455791766238.issue23259@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I've observed the generated assembly has fewer instructions on the critical path and that a register was freed-up. That's enough for me in this case (it's too easy to get trapped in local minimums in timing small changes like this). Do either of you have a technical comment on the patch? If it isn't broken or seriously misguided, I will likely apply it shortly. ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 02:26:40 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 18 Jan 2015 01:26:40 +0000 Subject: [issue23259] Remove dummy reuse optimization from sets In-Reply-To: <1421527566.61.0.766748710579.issue23259@psf.upfronthosting.co.za> Message-ID: <1421544400.39.0.987145107178.issue23259@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Fewer instructions doesn't necessarily translate into better performance. The bottleneck in superscalar, pipelined processors is often the data dependency path between instructions. Adding instructions may as well not slow anything down, if those instructions don't lengthen the dependency path. It would be interesting to know what the impact of the patch is on the workloads that were supposed to be helped by the removed logic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 02:34:19 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 18 Jan 2015 01:34:19 +0000 Subject: [issue23211] test.test_logging.SMTPHandlerTest failing on Snow Leopard In-Reply-To: <1420832632.4.0.00679469135671.issue23211@psf.upfronthosting.co.za> Message-ID: <20150118013412.93193.67531@psf.io> Roundup Robot added the comment: New changeset 65ac2b992673 by Ned Deily in branch '3.4': Issue #23211: Fix patch for 3.4 differences. https://hg.python.org/cpython/rev/65ac2b992673 New changeset 2d71d0f954fb by Ned Deily in branch 'default': Issue #23211: null merge https://hg.python.org/cpython/rev/2d71d0f954fb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 02:36:29 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 18 Jan 2015 01:36:29 +0000 Subject: [issue23211] test.test_logging.SMTPHandlerTest failing on Snow Leopard In-Reply-To: <1420832632.4.0.00679469135671.issue23211@psf.upfronthosting.co.za> Message-ID: <1421544989.03.0.451944735724.issue23211@psf.upfronthosting.co.za> Ned Deily added the comment: I *thought* I had tested 3.4 before; sorry about that! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 03:19:13 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 18 Jan 2015 02:19:13 +0000 Subject: [issue23260] Update Windows installer In-Reply-To: <1421536361.51.0.300522765173.issue23260@psf.upfronthosting.co.za> Message-ID: <1421547553.94.0.0897648551327.issue23260@psf.upfronthosting.co.za> Steve Dower added the comment: As I expected, shortly after posting this I find a significant issue with the way the installer will work. Expect a revised patch soon :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 03:59:42 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 18 Jan 2015 02:59:42 +0000 Subject: [issue23180] Rename IDLE's "Windows" menu item to "Window" In-Reply-To: <1420614987.43.0.350300091598.issue23180@psf.upfronthosting.co.za> Message-ID: <1421549982.63.0.211710510896.issue23180@psf.upfronthosting.co.za> Ned Deily added the comment: LGTM. Terry, should I apply them? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 04:08:32 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 18 Jan 2015 03:08:32 +0000 Subject: [issue23261] Clean-up set.pop() search finger logic Message-ID: <1421550511.96.0.63875506681.issue23261@psf.upfronthosting.co.za> New submission from Raymond Hettinger: The existing search finger is stored in a hackish way (using the hash field of entry zero in the hash table). Replace this with normal coding techniques (saving the field in the set object). Cost one extra field in the set object. Benefit, remove an arcane hack and simplify the set.pop() code just a little bit. ---------- assignee: rhettinger components: Interpreter Core files: finger.diff keywords: patch messages: 234216 nosy: rhettinger priority: low severity: normal status: open title: Clean-up set.pop() search finger logic versions: Python 3.5 Added file: http://bugs.python.org/file37753/finger.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 05:04:34 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 18 Jan 2015 04:04:34 +0000 Subject: [issue23260] Update Windows installer In-Reply-To: <1421536361.51.0.300522765173.issue23260@psf.upfronthosting.co.za> Message-ID: <1421553874.5.0.658114824054.issue23260@psf.upfronthosting.co.za> Steve Dower added the comment: New patch with some changes to how optional debug symbols and binaries are handled. (I misunderstood how a particular WiX feature worked...) ---------- Added file: http://bugs.python.org/file37754/23260_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 05:16:56 2015 From: report at bugs.python.org (Stephan Sokolow) Date: Sun, 18 Jan 2015 04:16:56 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ Message-ID: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> New submission from Stephan Sokolow: As of Firefox 36 (currently in beta channel), the -remote option has been removed. https://www.mozilla.org/en-US/firefox/36.0a2/auroranotes/ https://www.mozilla.org/en-US/firefox/36.0beta/releasenotes/ As such, attempting to open http://www.example.com/ using webbrowser.open() or webbrowser.open_new_tab() results in "File not Found" tabs pointing to these two URLs, respectively: file:///home/ssokolow/openURL%28http://www.example.com/%29 file:///home/ssokolow/openURL%28http://www.example.com/,new-tab%29 As I happen to have the Dead Snakes PPA set up on Lubuntu 14.04 for use with tox, I was able to confirm this as an issue in Python 2.7, 3.1, 3.2, 3.3, and 3.4. ---------- components: Library (Lib) messages: 234218 nosy: ssokolow priority: normal severity: normal status: open title: webbrowser module broken with Firefox 36+ 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 18 05:18:20 2015 From: report at bugs.python.org (Stephan Sokolow) Date: Sun, 18 Jan 2015 04:18:20 +0000 Subject: [issue6671] webbrowser doesn't respect xfce default browser In-Reply-To: <1249814125.92.0.530552321419.issue6671@psf.upfronthosting.co.za> Message-ID: <1421554700.88.0.567564139893.issue6671@psf.upfronthosting.co.za> Changes by Stephan Sokolow : ---------- nosy: +ssokolow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 05:19:59 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 18 Jan 2015 04:19:59 +0000 Subject: [issue23180] Rename IDLE's "Windows" menu item to "Window" In-Reply-To: <1420614987.43.0.350300091598.issue23180@psf.upfronthosting.co.za> Message-ID: <1421554798.99.0.405479714464.issue23180@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I cannot currently test or commit a patch. So go ahead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 06:10:23 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 18 Jan 2015 05:10:23 +0000 Subject: [issue23180] Rename IDLE's "Windows" menu item to "Window" In-Reply-To: <1420614987.43.0.350300091598.issue23180@psf.upfronthosting.co.za> Message-ID: <20150118050957.69926.29171@psf.io> Roundup Robot added the comment: New changeset 9a451aaa8ddb by Ned Deily in branch '2.7': Issue #23180: Rename IDLE "Windows" menu item to "Window". https://hg.python.org/cpython/rev/9a451aaa8ddb New changeset 8c0e5b507794 by Ned Deily in branch '3.4': Issue #23180: Rename IDLE "Windows" menu item to "Window". https://hg.python.org/cpython/rev/8c0e5b507794 New changeset af092c1d3747 by Ned Deily in branch 'default': Issue #23180: merge from 3.4 https://hg.python.org/cpython/rev/af092c1d3747 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 06:13:02 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 18 Jan 2015 05:13:02 +0000 Subject: [issue23180] Rename IDLE's "Windows" menu item to "Window" In-Reply-To: <1420614987.43.0.350300091598.issue23180@psf.upfronthosting.co.za> Message-ID: <1421557982.53.0.21658617173.issue23180@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the patches, Al. Pushed for release in 2.7.10, 3.4.3, and 3.5.0. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 06:44:41 2015 From: report at bugs.python.org (Matt Bachmann) Date: Sun, 18 Jan 2015 05:44:41 +0000 Subject: [issue23263] Python 3 gives misleading errors when validating unicode identifiers Message-ID: <1421559881.85.0.938769960217.issue23263@psf.upfronthosting.co.za> New submission from Matt Bachmann: PEP 3131 changed the definition of valid identifiers to match this pattern * . Currently if you have an invalid character in an identifier you get this error ? = 4 SyntaxError: invalid character in identifier This is fine in most cases. But in some cases the problem is not the character is invalid so much as the character may not be used to START the identifier. One example of this is the "combining grave accent" which is an XID_CONTINUE character but not an XID_START So ?e is an invalid identifier but e? is a valid identifier. So the ? character is not invalid in all cases. The attached patch attempts to clarify this by providing a different error when the start character is invalid. >>> ?e = 4 File "", line 1 ?e = 4 ^ SyntaxError: invalid start character in identifier However, if the character is simply not allowed (as it is neither an XID_START or an XID_CONTINUE character) the original error is used. >>> ?smile = 4 File "", line 1 ?smile = 4 ^ SyntaxError: invalid character in identifier ---------- components: Unicode files: clarify_unicode_identifier_errors.patch keywords: patch messages: 234222 nosy: Matt.Bachmann, ezio.melotti, haypo priority: normal severity: normal status: open title: Python 3 gives misleading errors when validating unicode identifiers type: enhancement versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file37755/clarify_unicode_identifier_errors.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 07:32:33 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 18 Jan 2015 06:32:33 +0000 Subject: [issue20121] quopri_codec newline handling In-Reply-To: <1388836490.83.0.337537980753.issue20121@psf.upfronthosting.co.za> Message-ID: <1421562753.9.0.1137991851.issue20121@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch that clarifies in the documentation and test suite how newlines work in the ?quopri? and ?binascii? modules. It also fixes the native Python implementation to support CRLFs. * \n is used by default (e.g. for soft line breaks if the input has no hard line breaks) * CRLF is used instead if found in input (even in non-text mode!) * Typo errors in documentation * quopri uses istext=True * header flag does not affect newline encoding; only istext affects it One corner case concerns me slightly: binascii.b2a_qp(istext=False) will use \n for soft line breaks by default, but will suddenly switch to CRLF if the input data happens to contain a CRLF sequence. This is despite the CRLFs from the data being encoded and therefore not appearing in the output themselves. ---------- assignee: -> docs at python components: +Documentation keywords: +patch nosy: +docs at python Added file: http://bugs.python.org/file37756/quopri-newline.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 07:43:54 2015 From: report at bugs.python.org (Ent) Date: Sun, 18 Jan 2015 06:43:54 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1421563434.47.0.835973472943.issue23255@psf.upfronthosting.co.za> Ent added the comment: @vadmium: My Mistake. It should read "file path" not "file object". (500 error when submitting to review page.) Renaming get_html_or_dir_path to get_path_or_dir for accurate description. Also renaming copyfile to more pythonic copy_file. ---------- Added file: http://bugs.python.org/file37757/simplehttp-fcn-rnm-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 09:11:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 Jan 2015 08:11:56 +0000 Subject: [issue23264] Add pickle support of dict views Message-ID: <1421568716.9.0.947546089999.issue23264@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: For now dict views are not pickleable in Python 3 (unlike to Python 2 and unlike to dict view iterators). Proposed patch adds pickle support of dict views. ---------- components: Interpreter Core files: pickle_dictviews.patch keywords: patch messages: 234225 nosy: alexandre.vassalotti, pitrou, rhettinger, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Add pickle support of dict views type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file37758/pickle_dictviews.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 09:21:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 Jan 2015 08:21:00 +0000 Subject: [issue23259] Remove dummy reuse optimization from sets In-Reply-To: <1421527566.61.0.766748710579.issue23259@psf.upfronthosting.co.za> Message-ID: <1421569260.52.0.392411525467.issue23259@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In some cases the slowdown is over 100x. $ ./python -m timeit -s "s = set(range(10**4))" -- "s.discard(0); s.add(0)" Unpatched: 1000000 loops, best of 3: 1.68 usec per loop Patched: 10000 loops, best of 3: 183 usec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 09:22:14 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 Jan 2015 08:22:14 +0000 Subject: [issue23181] Unicode "code point" should be two words in documentation In-Reply-To: <1420620228.26.0.565920670024.issue23181@psf.upfronthosting.co.za> Message-ID: <1421569334.94.0.52779703931.issue23181@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 09:32:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 Jan 2015 08:32:46 +0000 Subject: [issue23259] Remove dummy reuse optimization from sets In-Reply-To: <1421527566.61.0.766748710579.issue23259@psf.upfronthosting.co.za> Message-ID: <1421569966.47.0.77112025169.issue23259@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If you want to decrease the number of executed instructions, I suggest to duplicate lookup functions (actually add boolean flag and switch one of two branches). On read lookup function should ignore dummy entries, on modification it should behave as now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 09:33:47 2015 From: report at bugs.python.org (Georg Brandl) Date: Sun, 18 Jan 2015 08:33:47 +0000 Subject: [issue23181] Unicode "code point" should be two words in documentation In-Reply-To: <1420620228.26.0.565920670024.issue23181@psf.upfronthosting.co.za> Message-ID: <1421570027.38.0.897743802515.issue23181@psf.upfronthosting.co.za> Georg Brandl added the comment: Well, go ahead I guess. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 10:18:51 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 18 Jan 2015 09:18:51 +0000 Subject: [issue23098] mknod devices can be >32 bits In-Reply-To: <1419201384.94.0.109155979555.issue23098@psf.upfronthosting.co.za> Message-ID: <20150118091848.93195.41606@psf.io> Roundup Robot added the comment: New changeset 7ee09e2fec13 by Serhiy Storchaka in branch '2.7': Issue #23098: 64-bit dev_t is now supported in the os module. https://hg.python.org/cpython/rev/7ee09e2fec13 New changeset 18703ffea2b3 by Serhiy Storchaka in branch '3.4': Issue #23098: 64-bit dev_t is now supported in the os module. https://hg.python.org/cpython/rev/18703ffea2b3 New changeset fe0fddd6fd21 by Serhiy Storchaka in branch 'default': Issue #23098: 64-bit dev_t is now supported in the os module. https://hg.python.org/cpython/rev/fe0fddd6fd21 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 10:35:48 2015 From: report at bugs.python.org (Al Sweigart) Date: Sun, 18 Jan 2015 09:35:48 +0000 Subject: [issue23218] Modernize the IDLE Find/Replace/Find in Files dialogs In-Reply-To: <1420884051.8.0.416866319984.issue23218@psf.upfronthosting.co.za> Message-ID: <1421573748.49.0.180076388907.issue23218@psf.upfronthosting.co.za> Changes by Al Sweigart : Added file: http://bugs.python.org/file37759/idle_grep_compare2.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 10:40:04 2015 From: report at bugs.python.org (Al Sweigart) Date: Sun, 18 Jan 2015 09:40:04 +0000 Subject: [issue23218] Modernize the IDLE Find/Replace/Find in Files dialogs In-Reply-To: <1420884051.8.0.416866319984.issue23218@psf.upfronthosting.co.za> Message-ID: <1421574004.47.0.68933099249.issue23218@psf.upfronthosting.co.za> Changes by Al Sweigart : Added file: http://bugs.python.org/file37760/idle_find_ui_redesign2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 10:40:35 2015 From: report at bugs.python.org (Al Sweigart) Date: Sun, 18 Jan 2015 09:40:35 +0000 Subject: [issue23218] Modernize the IDLE Find/Replace/Find in Files dialogs In-Reply-To: <1420884051.8.0.416866319984.issue23218@psf.upfronthosting.co.za> Message-ID: <1421574035.55.0.119324794805.issue23218@psf.upfronthosting.co.za> Al Sweigart added the comment: I've made some minor updates: Adding colons to the labels and right-justifying them. These updates can be seen in the second comparison screenshot. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 10:45:18 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 18 Jan 2015 09:45:18 +0000 Subject: [issue23181] Unicode "code point" should be two words in documentation In-Reply-To: <1420620228.26.0.565920670024.issue23181@psf.upfronthosting.co.za> Message-ID: <20150118094514.69906.84841@psf.io> Roundup Robot added the comment: New changeset 0353c7e5e0c2 by Serhiy Storchaka in branch '3.4': Issue #23181: More "codepoint" -> "code point". https://hg.python.org/cpython/rev/0353c7e5e0c2 New changeset c79abee84a39 by Serhiy Storchaka in branch 'default': Issue #23181: More "codepoint" -> "code point". https://hg.python.org/cpython/rev/c79abee84a39 New changeset 2db41d551a4f by Serhiy Storchaka in branch '2.7': Issue #23181: More "codepoint" -> "code point". https://hg.python.org/cpython/rev/2db41d551a4f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 10:47:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 Jan 2015 09:47:58 +0000 Subject: [issue23098] mknod devices can be >32 bits In-Reply-To: <1419201384.94.0.109155979555.issue23098@psf.upfronthosting.co.za> Message-ID: <1421574478.05.0.617150333172.issue23098@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Committed to 2.7 with small change: stat() and makedev() should return int instead of long if possible. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 10:48:54 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 Jan 2015 09:48:54 +0000 Subject: [issue23181] Unicode "code point" should be two words in documentation In-Reply-To: <1420620228.26.0.565920670024.issue23181@psf.upfronthosting.co.za> Message-ID: <1421574534.39.0.431564961915.issue23181@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: docs at python -> serhiy.storchaka status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 10:56:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 Jan 2015 09:56:24 +0000 Subject: [issue22939] integer overflow in iterator object In-Reply-To: <1416912993.1.0.671503723984.issue22939@psf.upfronthosting.co.za> Message-ID: <1421574984.76.0.272602188208.issue22939@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > That way a virtual sequence with PY_SSIZE_T_MAX-1 items would still work (instead of failing unexpectedly). Actually with PY_SSIZE_T_MAX+1 items (indices from 0 to PY_SSIZE_T_MAX inclusive). If Raymond insists I can write more complicated patch, but I don't think that we should complicate the code for this pretty hypotetical case. I'm for committing issue22939v2.patch. ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 10:57:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 Jan 2015 09:57:55 +0000 Subject: [issue23094] Unpickler failing with PicklingError at frame end on readline due to a broken comparison In-Reply-To: <1419117872.02.0.125928182025.issue23094@psf.upfronthosting.co.za> Message-ID: <1421575075.63.0.701572997881.issue23094@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If there are no objections I'm going to commit the patch. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 11:01:45 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 Jan 2015 10:01:45 +0000 Subject: [issue18518] return-ing within code timed with timeit.timeit causes wrong return value of timeit.timeit In-Reply-To: <1374400020.0.0.45788018989.issue18518@psf.upfronthosting.co.za> Message-ID: <1421575305.54.0.532360972909.issue18518@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If there are no objections I'm going to commit the patch. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 11:16:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 Jan 2015 10:16:58 +0000 Subject: [issue9393] shelve.open/bsddb.hashopen exception with unicode paths In-Reply-To: <1280308243.23.0.510970772038.issue9393@psf.upfronthosting.co.za> Message-ID: <1421576218.07.0.587980297894.issue9393@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please update the patch Victor? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 11:17:04 2015 From: report at bugs.python.org (i01100101) Date: Sun, 18 Jan 2015 10:17:04 +0000 Subject: [issue23265] tar.xz support for sdist Message-ID: <1421576224.46.0.598158761162.issue23265@psf.upfronthosting.co.za> New submission from i01100101: The Python standard library includes lzma and support for *tar.xz archives since Python 3.3 but the distutils' 'sdist' command cannot output source distributions as such tarball. I suggest the changed version of distutils.archive_util module attached to this issue in order to tell distutils that tarfile now supports tar.xz (The changes are to the defenition of 'ARCHIVE_FORMATS' and 'make_tarball' ---------- components: Distutils files: archive_util.py messages: 234237 nosy: dstufft, eric.araujo, i01100101 priority: normal severity: normal status: open title: tar.xz support for sdist type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file37761/archive_util.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 11:29:22 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 18 Jan 2015 10:29:22 +0000 Subject: [issue23265] tar.xz support for sdist In-Reply-To: <1421576224.46.0.598158761162.issue23265@psf.upfronthosting.co.za> Message-ID: <1421576962.54.0.544313734846.issue23265@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the suggested patch. Distutils support for xz compression is the subject of already open Issue16314. Perhaps you can review and/or comment on the suggested patch there. ---------- nosy: +ned.deily resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Support xz compression in distutils _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 13:32:34 2015 From: report at bugs.python.org (Markus) Date: Sun, 18 Jan 2015 12:32:34 +0000 Subject: [issue23266] Faster implementation to collapse non-consecutive ip-addresses Message-ID: <1421584354.17.0.398119389429.issue23266@psf.upfronthosting.co.za> New submission from Markus: I found the code used to collapse addresses to be very slow on a large number (64k) of island addresses which are not collapseable. The code at https://github.com/python/cpython/blob/0f164ccc85ff055a32d11ad00017eff768a79625/Lib/ipaddress.py#L349 was found to be guilty, especially the index lookup. The patch changes the code to discard the index lookup and have _find_address_range return the number of items consumed. That way the set operation to dedup the addresses can be dropped as well. Numbers from the testrig I adapted from http://bugs.python.org/issue20826 with 8k non-consecutive addresses: Execution time: 0.6893927365541458 seconds vs. Execution time: 12.116527611762285 seconds MfG Markus K?tter ---------- components: Library (Lib) files: ipaddress_collapse_non_consecutive_performance.diff keywords: patch messages: 234239 nosy: cmn priority: normal severity: normal status: open title: Faster implementation to collapse non-consecutive ip-addresses type: performance versions: Python 3.5 Added file: http://bugs.python.org/file37762/ipaddress_collapse_non_consecutive_performance.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 13:40:52 2015 From: report at bugs.python.org (Markus) Date: Sun, 18 Jan 2015 12:40:52 +0000 Subject: [issue23266] Faster implementation to collapse non-consecutive ip-addresses In-Reply-To: <1421584354.17.0.398119389429.issue23266@psf.upfronthosting.co.za> Message-ID: <1421584852.26.0.560341886547.issue23266@psf.upfronthosting.co.za> Markus added the comment: Added the testrig. ---------- Added file: http://bugs.python.org/file37763/testrig.tar.gz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 14:14:50 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 18 Jan 2015 13:14:50 +0000 Subject: [issue23266] Faster implementation to collapse non-consecutive ip-addresses In-Reply-To: <1421584354.17.0.398119389429.issue23266@psf.upfronthosting.co.za> Message-ID: <1421586890.1.0.486299411739.issue23266@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 14:24:58 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 18 Jan 2015 13:24:58 +0000 Subject: [issue23266] Faster implementation to collapse non-consecutive ip-addresses In-Reply-To: <1421584354.17.0.398119389429.issue23266@psf.upfronthosting.co.za> Message-ID: <1421587498.15.0.0693403098386.issue23266@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This is great, thank you. Can you sign the contributor's agreement? https://www.python.org/psf/contrib/contrib-form/ ---------- nosy: +pitrou, pmoody _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 14:25:46 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 18 Jan 2015 13:25:46 +0000 Subject: [issue23266] Faster implementation to collapse non-consecutive ip-addresses In-Reply-To: <1421584354.17.0.398119389429.issue23266@psf.upfronthosting.co.za> Message-ID: <1421587546.84.0.00168920670133.issue23266@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is an updated patch with a fix to the tests and docstrings. ---------- Added file: http://bugs.python.org/file37764/collapse.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 14:28:16 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 18 Jan 2015 13:28:16 +0000 Subject: [issue23264] Add pickle support of dict views In-Reply-To: <1421568716.9.0.947546089999.issue23264@psf.upfronthosting.co.za> Message-ID: <1421587696.41.0.0352117412272.issue23264@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This looks good to me, thank you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 14:33:39 2015 From: report at bugs.python.org (shani) Date: Sun, 18 Jan 2015 13:33:39 +0000 Subject: [issue23267] multiprocessing pool.py doesn't close inqueue and outqueue pipes on termination Message-ID: <1421588019.18.0.707676170756.issue23267@psf.upfronthosting.co.za> New submission from shani: Multiprocessing pool.py gets SimpleQueue objects as inqueue and outqueue. when it terminates, it doesn't call the close() method of the queues' readers and writers. As a results, 4 file pipes leak in one pool termination. Expected: The pool closes reader and writer pipes of the inqueue and outqueue when it terminates. What did happen: the pool doesn't close the pipes. 4 pipes leak. ---------- components: Library (Lib) messages: 234244 nosy: shanip priority: normal severity: normal status: open title: multiprocessing pool.py doesn't close inqueue and outqueue pipes on termination type: resource usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 15:19:48 2015 From: report at bugs.python.org (Markus) Date: Sun, 18 Jan 2015 14:19:48 +0000 Subject: [issue23266] Faster implementation to collapse non-consecutive ip-addresses In-Reply-To: <1421584354.17.0.398119389429.issue23266@psf.upfronthosting.co.za> Message-ID: <1421590788.8.0.144566811701.issue23266@psf.upfronthosting.co.za> Markus added the comment: I just signed the agreement, ewa@ is processing it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 15:26:41 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 18 Jan 2015 14:26:41 +0000 Subject: [issue23267] multiprocessing pool.py doesn't close inqueue and outqueue pipes on termination In-Reply-To: <1421588019.18.0.707676170756.issue23267@psf.upfronthosting.co.za> Message-ID: <1421591201.35.0.888116624594.issue23267@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +davin, sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 15:28:01 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 18 Jan 2015 14:28:01 +0000 Subject: [issue20284] patch to implement PEP 461 (%-interpolation for bytes) In-Reply-To: <1421519831.17.0.0374787731341.issue20284@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: I will not have to work on optimization before the alpha 1 (February 8, 2015). Ethan: just commit your patch when you consider that it's ready to be merged, we will have time to refactor and enhance the code later. IMO it's more important to have the feature in alpha 1 than having perfect code, because some developer are waiting for this feature and will have more time to provide feedback. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 15:31:42 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 18 Jan 2015 14:31:42 +0000 Subject: [issue9393] shelve.open/bsddb.hashopen exception with unicode paths In-Reply-To: <1280308243.23.0.510970772038.issue9393@psf.upfronthosting.co.za> Message-ID: <1421591502.73.0.102080456341.issue9393@psf.upfronthosting.co.za> STINNER Victor added the comment: > Could you please update the patch Victor? You can update this old patch if you want. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 15:32:21 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 18 Jan 2015 14:32:21 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> Message-ID: <1421591541.65.0.353132928819.issue23262@psf.upfronthosting.co.za> Antoine Pitrou added the comment: What is the right way to do it then? It should also remain compatible with Firefox < 36. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 15:33:01 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 18 Jan 2015 14:33:01 +0000 Subject: [issue9393] shelve.open/bsddb.hashopen exception with unicode paths In-Reply-To: <1280308243.23.0.510970772038.issue9393@psf.upfronthosting.co.za> Message-ID: <1421591581.3.0.796702933507.issue9393@psf.upfronthosting.co.za> STINNER Victor added the comment: Python 3 is not affected: Python 3.5.0a0 (default:61a045ac0006, Jan 15 2015, 00:05:43) [GCC 4.9.2 20141101 (Red Hat 4.9.2-1)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> temppath = u"D:\\???????\\a" >>> import shelve >>> cache = shelve.open(temppath, 'c') (no error) ---------- versions: -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 15:36:09 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 18 Jan 2015 14:36:09 +0000 Subject: [issue9393] shelve.open/bsddb.hashopen exception with unicode paths In-Reply-To: <1280308243.23.0.510970772038.issue9393@psf.upfronthosting.co.za> Message-ID: <1421591769.22.0.414466162453.issue9393@psf.upfronthosting.co.za> STINNER Victor added the comment: > Python 3 is not affected: Oh sorry, dbm_open_unicode-32.patch is still needed. Currently, filenames are encoded to UTF-8 which "works" when the filesystem encoding is UTF-8, but it doesn't work on Windows. ---------- versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 15:36:41 2015 From: report at bugs.python.org (Akira Li) Date: Sun, 18 Jan 2015 14:36:41 +0000 Subject: [issue23251] mention in time.sleep() docs that it does not block other Python threads In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za> Message-ID: <1421591801.5.0.953693832025.issue23251@psf.upfronthosting.co.za> Akira Li added the comment: > Only if the behaviour was unintuitive (i.e. if it *didn't* release the > GIL) would it make sense to document it. There is no intuitive interface, not even the nipple. It's all learned. [1] > Yes, on consideration I agree with Antoine. That last sentence should > be deleted. Otherwise we'd need to mention that the gil was released > every place that the gil was released, which would be very redundant. Whether or not other places mention it is unrelated to the current issue. Though the documentation should mention it more. Many programmers are convinced that Python threads can't be executed in parallel. > The general rule is that anything that blocks in python releases the > GIL, therefore as Antoine says the only time we need to document GIL > behavior is when that *doesn't* happen. The reader of Python documentation is intelegent but not all-knowing. "Blocking" is the first and only job for time.sleep() function. GIL "blocks" Python code. You can't understand what time.sleep does without knowing what happens to GIL. Ask yourself who and why reads the time.sleep() documentation (novice and/or exprerienced Python user). Put yourself into the mind of the reader. [1] http://www.greenend.org.uk/rjk/misc/nipple.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 15:39:56 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 18 Jan 2015 14:39:56 +0000 Subject: [issue23251] mention in time.sleep() docs that it does not block other Python threads In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za> Message-ID: <1421591996.48.0.614296960441.issue23251@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Please let's stop it. Mentioning the GIL in every place in the documentation will only make people more worried and confused about something they shouldn't be confused or worried about. If you think some docs should discuss the GIL and its effect on running threads then I suggest writing a separate document (a HOWTO for example, like the Unicode HOWTO). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 16:24:23 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 18 Jan 2015 15:24:23 +0000 Subject: [issue23266] Faster implementation to collapse non-consecutive ip-addresses In-Reply-To: <1421584354.17.0.398119389429.issue23266@psf.upfronthosting.co.za> Message-ID: <20150118152253.93195.5418@psf.io> Roundup Robot added the comment: New changeset f7508a176a09 by Antoine Pitrou in branch 'default': Issue #23266: Much faster implementation of ipaddress.collapse_addresses() when there are many non-consecutive addresses. https://hg.python.org/cpython/rev/f7508a176a09 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 16:25:17 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 18 Jan 2015 15:25:17 +0000 Subject: [issue23266] Faster implementation to collapse non-consecutive ip-addresses In-Reply-To: <1421584354.17.0.398119389429.issue23266@psf.upfronthosting.co.za> Message-ID: <1421594717.38.0.248333089976.issue23266@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, I've committed the patch. Thank you! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 17:05:28 2015 From: report at bugs.python.org (Brett Cannon) Date: Sun, 18 Jan 2015 16:05:28 +0000 Subject: [issue23253] Delay-load ShellExecute In-Reply-To: <1421449910.62.0.491687570058.issue23253@psf.upfronthosting.co.za> Message-ID: <1421597128.01.0.584749404285.issue23253@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 17:06:18 2015 From: report at bugs.python.org (Brett Cannon) Date: Sun, 18 Jan 2015 16:06:18 +0000 Subject: [issue23253] Delay-load ShellExecute In-Reply-To: <1421449910.62.0.491687570058.issue23253@psf.upfronthosting.co.za> Message-ID: <1421597178.12.0.512111136298.issue23253@psf.upfronthosting.co.za> Brett Cannon added the comment: If you want a robust measurement of startup impact, the benchmark suite has two benchmarks specifically for startup (w/ and w/o site.py). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 17:06:41 2015 From: report at bugs.python.org (Brett Cannon) Date: Sun, 18 Jan 2015 16:06:41 +0000 Subject: [issue23257] Update Windows build/setup instructions in devguide In-Reply-To: <1421514832.21.0.130284458039.issue23257@psf.upfronthosting.co.za> Message-ID: <1421597201.55.0.482080744543.issue23257@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 17:20:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 Jan 2015 16:20:21 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> Message-ID: <1421598021.55.0.462490335908.issue23262@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Details: https://bugzilla.mozilla.org/show_bug.cgi?id=1080319 ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 17:31:59 2015 From: report at bugs.python.org (anupama srinivas murthy) Date: Sun, 18 Jan 2015 16:31:59 +0000 Subject: [issue23217] help() function incorrectly captures comment preceding a nested function In-Reply-To: <1420882396.37.0.573730184021.issue23217@psf.upfronthosting.co.za> Message-ID: <1421598719.84.0.656797243065.issue23217@psf.upfronthosting.co.za> anupama srinivas murthy added the comment: The comment is captured only in the absence of a docstring within the function. The capture happens whether the function is nested or otherwise ---------- nosy: +anupama.srinivas.murthy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 17:42:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 18 Jan 2015 16:42:33 +0000 Subject: [issue23248] Update ssl data In-Reply-To: <1421396221.93.0.559881277875.issue23248@psf.upfronthosting.co.za> Message-ID: <20150118164231.103311.41164@psf.io> Roundup Robot added the comment: New changeset 2eea364c2863 by Antoine Pitrou in branch '3.4': Issue #23248: Update ssl error codes from latest OpenSSL git master. https://hg.python.org/cpython/rev/2eea364c2863 New changeset 15f46b850257 by Antoine Pitrou in branch 'default': Issue #23248: Update ssl error codes from latest OpenSSL git master. https://hg.python.org/cpython/rev/15f46b850257 New changeset 6e03c18f5447 by Antoine Pitrou in branch '2.7': Issue #23248: Update ssl error codes from latest OpenSSL git master. https://hg.python.org/cpython/rev/6e03c18f5447 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 17:42:50 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 18 Jan 2015 16:42:50 +0000 Subject: [issue23248] Update ssl data In-Reply-To: <1421396221.93.0.559881277875.issue23248@psf.upfronthosting.co.za> Message-ID: <1421599370.86.0.238126639961.issue23248@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 17:55:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 Jan 2015 16:55:32 +0000 Subject: [issue22818] Deprecate splitting on possible zero-width re patterns In-Reply-To: <1415444480.37.0.198748558658.issue22818@psf.upfronthosting.co.za> Message-ID: <1421600132.98.0.489596212079.issue22818@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Now patterns which could match only an empty string (e.g. '(?m)^$' or '(?<=\w-)(?=\w)') are rejected at all. They never worked with current regex engine. Updated the documentation. Could anyone please make a review and correct my wording. It is desirable to get this in alpha 1 and receive early feedback. ---------- Added file: http://bugs.python.org/file37765/re_deprecate_split_zero_width_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 18:03:35 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 Jan 2015 17:03:35 +0000 Subject: [issue9393] shelve.open/bsddb.hashopen exception with unicode paths In-Reply-To: <1280308243.23.0.510970772038.issue9393@psf.upfronthosting.co.za> Message-ID: <1421600615.43.0.427797459219.issue9393@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And needed tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 18:21:20 2015 From: report at bugs.python.org (steve) Date: Sun, 18 Jan 2015 17:21:20 +0000 Subject: [issue23258] Cannot Install Python 3.4.2 on Windows 7 64 bit / screen print attached In-Reply-To: <1421527190.23.0.124445752599.issue23258@psf.upfronthosting.co.za> Message-ID: steve added the comment: Thanks.... I killed the Intel task and the Python install worked without problems. There is almost no information on the web about what these Intel tasks do which made the Python install a little scary. Minor warning messages sometimes mask big problems. I'm amazed how comprehensive the Python programming language is. On Sat, Jan 17, 2015 at 3:39 PM, Steve Dower wrote: > > Steve Dower added the comment: > > You can close those applications, or ignore the message and continue, just > like the dialog says (if you ignore it, you may need to reboot for > installation to complete). You could also try doing a Just for Me > installation. > > Python is not trying to update those programs, which means those programs > are blocking Python. You should look for their documentation on how to > close them, or report this as a problem to them. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- title: Cannot Install Python 3.4.2 on Windows 7 64 bit / screen print attached -> Cannot Install Python 3.4.2 on Windows 7 64 bit / screen print attached _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 18:45:16 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 18 Jan 2015 17:45:16 +0000 Subject: [issue22818] Deprecate splitting on possible zero-width re patterns In-Reply-To: <1415444480.37.0.198748558658.issue22818@psf.upfronthosting.co.za> Message-ID: <1421603116.45.0.240021988429.issue22818@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't really understand why "this is definitely a bug". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 18:50:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 Jan 2015 17:50:28 +0000 Subject: [issue22765] Fixes for test_gdb (first frame address, entry values) In-Reply-To: <1414669906.53.0.952011236022.issue22765@psf.upfronthosting.co.za> Message-ID: <1421603428.28.0.145437825111.issue22765@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 19:20:38 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 Jan 2015 18:20:38 +0000 Subject: [issue22818] Deprecate splitting on possible zero-width re patterns In-Reply-To: <1415444480.37.0.198748558658.issue22818@psf.upfronthosting.co.za> Message-ID: <1421605238.49.0.672618974228.issue22818@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Because users expect that split() supports zero-width patterns (as sub() supports them) and regexps in other languages support splitting on zero-width patterns. This looks as accidental implementation detail (see my patch in issue22817 -- the difference is pretty small) frozen in the ages for backward compatibility. We can't change this behavior in maintained releases because this will break mach code which accidentally use zero-width patterns. But we can change it in future as new feature, after deprecating current behavior. This would be very useful feature. For example it would allow to simplify and speed up the regex used for splitting on hyphens in textwrap (something like r'(?<=\w-)(?=\w)'). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 19:27:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 Jan 2015 18:27:23 +0000 Subject: [issue23133] Pickling of ipaddress classes In-Reply-To: <1419936769.64.0.614386046628.issue23133@psf.upfronthosting.co.za> Message-ID: <1421605643.76.0.880939730391.issue23133@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Then I'll remove it. Could you please make a review of optimized patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 19:37:23 2015 From: report at bugs.python.org (Ethan Furman) Date: Sun, 18 Jan 2015 18:37:23 +0000 Subject: [issue20284] patch to implement PEP 461 (%-interpolation for bytes) In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <1421606243.05.0.569986851238.issue20284@psf.upfronthosting.co.za> Ethan Furman added the comment: Here's the patch -- the code for % and %= is in place for bytes and bytearray; I still need to get the doc patch done. I'll commit Wednesday-ish barring problems. Big question ============ Background ---------- There is a Python C ABI function called PyBytes_FromFormat which is used to create bytes objects using the %-interpolation format (it takes a c string and none-or-many c args). Actual Question --------------- Should PyBytes_FromFormat also support the new codes of %a and %b ? My Thoughts ----------- Writing things down is good! %a and %b are both for Python level arguments, not C-level arguments, so %a and %b would make no sense. ---------- Added file: http://bugs.python.org/file37766/issue20284.stoneleaf.04.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 19:43:07 2015 From: report at bugs.python.org (Ethan Furman) Date: Sun, 18 Jan 2015 18:43:07 +0000 Subject: [issue20284] patch to implement PEP 461 (%-interpolation for bytes) In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <1421606587.52.0.796825432135.issue20284@psf.upfronthosting.co.za> Ethan Furman added the comment: Thanks, Victor, for the feedback. I was able to figure out some more of the C side thanks to Georg, and I think the code is looking pretty good. There may be room for optimization by having the bytes code call the unicode implementation for more of the conversions (currently it's only using the unicode fromlong function), but the docs should happen before that. ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 21:02:38 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 Jan 2015 20:02:38 +0000 Subject: [issue23268] Fix comparison of ipaddress classes Message-ID: <1421611358.75.0.717594852846.issue23268@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Here is a patch which fixes following errors in comparison of ipaddress classes. 1. Ordering comparison raised AttributeError when compared with foreign classes. 2. Ordering comparison didn't return NotImplemented when compared with foreign classes. This prevented fallback to foreign class comparison method. 3. There was a bug in _TotalOrderingMixin.__le__(). It could return False instead of NotImplemented if compared network and address of different versions. 4. There was a typo in ComparisonTests.test_incompatible_versions(). As far as functools.total_ordering now is fixed and more correct and tested than _TotalOrderingMixin, _TotalOrderingMixin is dropped away. ---------- components: Library (Lib) files: ipaddress_comparison.patch keywords: patch messages: 234267 nosy: ncoghlan, pmoody, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Fix comparison of ipaddress classes type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37767/ipaddress_comparison.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 21:05:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 Jan 2015 20:05:49 +0000 Subject: [issue21802] Reader of BufferedRWPair is not closed if writer's close() fails In-Reply-To: <1403113942.14.0.852744973704.issue21802@psf.upfronthosting.co.za> Message-ID: <1421611549.62.0.596440459605.issue21802@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. If this patch will be accepted I'll provide larger patch for similar issues in close methods of other classes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 21:11:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 Jan 2015 20:11:08 +0000 Subject: [issue20204] pydocs fails for some C implemented classes In-Reply-To: <1389271655.86.0.224685657695.issue20204@psf.upfronthosting.co.za> Message-ID: <1421611868.87.0.922751037074.issue20204@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think we should add a check to ensure than heap types have the __module__ attribute. ---------- assignee: -> serhiy.storchaka stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 21:13:29 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 18 Jan 2015 20:13:29 +0000 Subject: [issue23133] Pickling of ipaddress classes In-Reply-To: <1419936769.64.0.614386046628.issue23133@psf.upfronthosting.co.za> Message-ID: <1421612009.48.0.0157985169581.issue23133@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The patch looks fine to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 21:14:27 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 Jan 2015 20:14:27 +0000 Subject: [issue7665] test_urllib2 and test_ntpath fail if path contains "\" In-Reply-To: <1263142226.0.0.91918347375.issue7665@psf.upfronthosting.co.za> Message-ID: <1421612067.56.0.331254763408.issue7665@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please look at the patch Senthil? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 21:16:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 Jan 2015 20:16:18 +0000 Subject: [issue9678] uuid._ifconfig_getnode can't work on NetBSD In-Reply-To: <1282705798.9.0.0619423981288.issue9678@psf.upfronthosting.co.za> Message-ID: <1421612178.01.0.118463513674.issue9678@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 21:17:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 Jan 2015 20:17:42 +0000 Subject: [issue9678] uuid._ifconfig_getnode can't work on NetBSD In-Reply-To: <1282705798.9.0.0619423981288.issue9678@psf.upfronthosting.co.za> Message-ID: <1421612262.86.0.788176116098.issue9678@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If no one interesting in testing this issue I'll close it. ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 21:22:15 2015 From: report at bugs.python.org (Gwenlliana) Date: Sun, 18 Jan 2015 20:22:15 +0000 Subject: [issue23217] help() function incorrectly captures comment preceding a nested function In-Reply-To: <1420882396.37.0.573730184021.issue23217@psf.upfronthosting.co.za> Message-ID: <1421612535.62.0.896014519729.issue23217@psf.upfronthosting.co.za> Gwenlliana added the comment: The capture actually worked correctly. It seems to be caused by the artifacts introduced by the evaluation function decorators. Decorator lists for functions are compiled to a series of high-order function applications to the original function, followed by an assignment which stores the resulting function object to the name of the original function. A decompilation of the sample code might be something like this: 3 0 LOAD_CONST 0 () 3 MAKE_FUNCTION 0 6 STORE_NAME 0 (outer) 10 9 LOAD_NAME 0 (outer) 12 LOAD_CONST 1 () 15 MAKE_FUNCTION 0 18 CALL_FUNCTION 1 21 STORE_NAME 1 (f) 24 LOAD_CONST 2 (None) 27 RETURN_VALUE It works in the same way with `f = outer(lambda: None)`. Thus evaluating `f.__name__` or `f.func_name` would actually gives the __name__ property of that inner function object, thus `help(f)` actually queries the help information of function inner. Similarly, lots of properties of the original function object f would be shadowed by the decoration process, including the __doc__ property. You'll find documenting f takes no effect on the value of `f.__doc__`: @outer def f(): """ The docstring of function f """ return >>> help(f) Help on function inner in module tmp: inner() #comment ---------- nosy: +Gwenlliana _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 21:39:56 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 18 Jan 2015 20:39:56 +0000 Subject: [issue23133] Pickling of ipaddress classes In-Reply-To: <1419936769.64.0.614386046628.issue23133@psf.upfronthosting.co.za> Message-ID: <20150118203722.103307.58342@psf.io> Roundup Robot added the comment: New changeset 781b54f7bccc by Serhiy Storchaka in branch 'default': Issue #23133: Pickling of ipaddress objects now produces more compact and https://hg.python.org/cpython/rev/781b54f7bccc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 21:41:26 2015 From: report at bugs.python.org (Gwenlliana) Date: Sun, 18 Jan 2015 20:41:26 +0000 Subject: [issue23217] help() function incorrectly captures comment preceding a nested function In-Reply-To: <1420882396.37.0.573730184021.issue23217@psf.upfronthosting.co.za> Message-ID: <1421613686.61.0.470121066883.issue23217@psf.upfronthosting.co.za> Gwenlliana added the comment: Though standard library contains a workaround on the decorator issue (functools.wraps), but it still failed to patch func_code.co_firstlineno, which led the pydoc module to capture the wrong comment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 21:41:47 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 18 Jan 2015 20:41:47 +0000 Subject: [issue23259] Remove dummy reuse optimization from sets In-Reply-To: <1421527566.61.0.766748710579.issue23259@psf.upfronthosting.co.za> Message-ID: <1421613707.17.0.867600946694.issue23259@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- Removed message: http://bugs.python.org/msg234210 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 21:53:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 Jan 2015 20:53:56 +0000 Subject: [issue23133] Pickling of ipaddress classes In-Reply-To: <1419936769.64.0.614386046628.issue23133@psf.upfronthosting.co.za> Message-ID: <1421614436.69.0.80105661934.issue23133@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Antoine. And here is comparison of pickle size. Unpatched: >>> len(pickle.dumps([ipaddress.ip_address('192.0.2.%s'%i) for i in range(1, 101)])) 2971 >>> len(pickle.dumps([ipaddress.ip_address('2001:db8::%x'%i) for i in range(1, 101)])) 4071 >>> len(pickle.dumps([ipaddress.ip_interface('192.0.2.%s/27'%i) for i in range(1, 101)])) 19341 >>> len(pickle.dumps([ipaddress.ip_interface('2001:db8::%x/124'%i) for i in range(1, 101)])) 22741 >>> len(pickle.dumps([ipaddress.ip_network('192.0.2.%s/27'%(i&-32)) for i in range(1, 101)])) 10614 >>> len(pickle.dumps([ipaddress.ip_interface('2001:db8::%x/124'%(i&-32)) for i in range(1, 101)])) 22741 Patched: >>> len(pickle.dumps([ipaddress.ip_address('192.0.2.%s'%i) for i in range(1, 101)])) 1531 >>> len(pickle.dumps([ipaddress.ip_address('2001:db8::%x'%i) for i in range(1, 101)])) 2631 >>> len(pickle.dumps([ipaddress.ip_interface('192.0.2.%s/27'%i) for i in range(1, 101)])) 2963 >>> len(pickle.dumps([ipaddress.ip_interface('2001:db8::%x/124'%i) for i in range(1, 101)])) 3256 >>> len(pickle.dumps([ipaddress.ip_network('192.0.2.%s/27'%(i&-32)) for i in range(1, 101)])) 2938 >>> len(pickle.dumps([ipaddress.ip_interface('2001:db8::%x/124'%(i&-32)) for i in range(1, 101)])) 3209 ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 21:57:32 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 18 Jan 2015 20:57:32 +0000 Subject: [issue23133] Pickling of ipaddress classes In-Reply-To: <1419936769.64.0.614386046628.issue23133@psf.upfronthosting.co.za> Message-ID: <20150118205728.118088.44788@psf.io> Roundup Robot added the comment: New changeset 712ac77b772b by Serhiy Storchaka in branch 'default': Fixed tests for issue #23133 (pickling of IPv4Network was not tested). https://hg.python.org/cpython/rev/712ac77b772b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 21:58:59 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 18 Jan 2015 20:58:59 +0000 Subject: [issue23259] Remove dummy reuse optimization from sets In-Reply-To: <1421527566.61.0.766748710579.issue23259@psf.upfronthosting.co.za> Message-ID: <1421614739.25.0.753169549852.issue23259@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I'll just close this one. There seems to be little interest in it. Originally, I characterized freeslot tracking as an optimization that mildly benefited an uncommon case (adds/deletes/moreadds) at the expense of the common cases (uniquification, membership testing, and set-to-set operations). As Antoine pointed-out, on some systems the cost of a predictable branch routinely not take can be almost zero. There was still benefit in code simplification, reducing the size of the stack frame, freeing a register that needed to saved and restored when called PyRich_CompareBool(), etc. But no one seems to care about those. As Serhiy found, there is one case where the freeslot tracking benefit wasn't "mild". In the unusual but possible case of deleting and reinserting the exact same value in a large set, dummy reuse prevents a catastrophic linear pile-up. And so it goes. Free slot tracking lives. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 22:13:04 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 18 Jan 2015 21:13:04 +0000 Subject: [issue23261] Clean-up set.pop() search finger logic In-Reply-To: <1421550511.96.0.63875506681.issue23261@psf.upfronthosting.co.za> Message-ID: <20150118211249.118096.64747@psf.io> Roundup Robot added the comment: New changeset 0f90a3bd07f7 by Raymond Hettinger in branch 'default': Issue 23261: Clean-up the hack to store the set.pop() search finger in a hash field instead of the setobject. https://hg.python.org/cpython/rev/0f90a3bd07f7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 22:19:18 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 18 Jan 2015 21:19:18 +0000 Subject: [issue23261] Clean-up set.pop() search finger logic In-Reply-To: <1421550511.96.0.63875506681.issue23261@psf.upfronthosting.co.za> Message-ID: <1421615958.8.0.175726047883.issue23261@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 22:35:21 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 18 Jan 2015 21:35:21 +0000 Subject: [issue23251] mention in time.sleep() docs that it does not block other Python threads In-Reply-To: <1421591996.48.0.614296960441.issue23251@psf.upfronthosting.co.za> Message-ID: Andrew Svetlov added the comment: I'm with Antoine. Yes, GIL is extremely important but please don't put GIL mentions everywhere. On Sun, Jan 18, 2015 at 4:39 PM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > Please let's stop it. Mentioning the GIL in every place in the documentation will only make people more worried and confused about something they shouldn't be confused or worried about. > > If you think some docs should discuss the GIL and its effect on running threads then I suggest writing a separate document (a HOWTO for example, like the Unicode HOWTO). > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 22:47:37 2015 From: report at bugs.python.org (Georg Brandl) Date: Sun, 18 Jan 2015 21:47:37 +0000 Subject: [issue23251] mention in time.sleep() docs that it does not block other Python threads In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za> Message-ID: <1421617657.78.0.794456087521.issue23251@psf.upfronthosting.co.za> Georg Brandl added the comment: Agreed. "of the current thread" is a good addition. The sleep() docs are already longer than I would like. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 22:53:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 Jan 2015 21:53:12 +0000 Subject: [issue23266] Faster implementation to collapse non-consecutive ip-addresses In-Reply-To: <1421584354.17.0.398119389429.issue23266@psf.upfronthosting.co.za> Message-ID: <1421617991.99.0.818777386848.issue23266@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Deduplication should not be omitted. This slowed down collapsing of duplicated addresses. $ ./python -m timeit -s "import ipaddress; ips = [ipaddress.ip_address('2001:db8::1000') for i in range(1000)]" -- "ipaddress.collapse_addresses(ips)" Before f7508a176a09: 100 loops, best of 3: 13.4 msec per loop After f7508a176a09: 10 loops, best of 3: 129 msec per loop Proposed patch restores performance for duplicated addresses and simplifies the code using generators. ---------- nosy: +serhiy.storchaka resolution: fixed -> stage: resolved -> patch review status: closed -> open Added file: http://bugs.python.org/file37768/ipaddress_faster_collapse3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 23:08:30 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 18 Jan 2015 22:08:30 +0000 Subject: [issue23266] Faster implementation to collapse non-consecutive ip-addresses In-Reply-To: <1421584354.17.0.398119389429.issue23266@psf.upfronthosting.co.za> Message-ID: <1421618910.04.0.324140256486.issue23266@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Good catch. What is the performance on the benchmark posted here? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 23:15:14 2015 From: report at bugs.python.org (Stephan Sokolow) Date: Sun, 18 Jan 2015 22:15:14 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> Message-ID: <1421619314.94.0.475613971798.issue23262@psf.upfronthosting.co.za> Stephan Sokolow added the comment: The proper solution is to prefer `start` (Windows), `open` (OSX), or `xdg-open` (everything else... usually but not always present) when present instead of calling the browser directly. That way, you're using the same "delegate to the desktop's associations system and let the user's preferences control new window vs. new tab" behaviour on all OSes where it's reliably possible. (Yes, it would guarantee that all open* functions are equivalent, but that's already the norm in a lot of cases... especially with Firefox where one of the guiding design principles is ensuring that the user retains control of their browsing experience.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 23:26:47 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 18 Jan 2015 22:26:47 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> Message-ID: <1421620007.59.0.975061104544.issue23262@psf.upfronthosting.co.za> Antoine Pitrou added the comment: That doesn't really answer the question. The webbrowser module is already able to use "xdg-open" (though not "open"), but it has a fallback on various concrete browsers (including Firefox) in case xdg-open doesn't work / doesn't exist. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 23:28:38 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 Jan 2015 22:28:38 +0000 Subject: [issue23266] Faster implementation to collapse non-consecutive ip-addresses In-Reply-To: <1421618910.04.0.324140256486.issue23266@psf.upfronthosting.co.za> Message-ID: <4197919.0UK2a4qRuH@raxxla> Serhiy Storchaka added the comment: > What is the performance on the benchmark posted here? The same as with current code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 23:37:18 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 18 Jan 2015 22:37:18 +0000 Subject: [issue23266] Faster implementation to collapse non-consecutive ip-addresses In-Reply-To: <1421584354.17.0.398119389429.issue23266@psf.upfronthosting.co.za> Message-ID: <1421620638.48.0.0758669329687.issue23266@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Then +1. The patch looks fine to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 23:42:20 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 18 Jan 2015 22:42:20 +0000 Subject: [issue23266] Faster implementation to collapse non-consecutive ip-addresses In-Reply-To: <1421584354.17.0.398119389429.issue23266@psf.upfronthosting.co.za> Message-ID: <20150118224217.93187.81301@psf.io> Roundup Robot added the comment: New changeset 021b23a40f9f by Serhiy Storchaka in branch 'default': Issue #23266: Restore the performance of ipaddress.collapse_addresses() whith https://hg.python.org/cpython/rev/021b23a40f9f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 23:43:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 18 Jan 2015 22:43:28 +0000 Subject: [issue23266] Faster implementation to collapse non-consecutive ip-addresses In-Reply-To: <1421584354.17.0.398119389429.issue23266@psf.upfronthosting.co.za> Message-ID: <1421621008.79.0.362502951437.issue23266@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 18 23:58:51 2015 From: report at bugs.python.org (Stephan Sokolow) Date: Sun, 18 Jan 2015 22:58:51 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> Message-ID: <1421621931.83.0.650161343339.issue23262@psf.upfronthosting.co.za> Stephan Sokolow added the comment: Well, then the code which chooses a backend is broken because I have xdg-open and, according to WinPdb, it's using the Mozilla backend. This was my local workaround: if os.name == 'posix' and not platform.mac_ver()[0]: with open(os.devnull, 'wb') as nul: subprocess.Popen(['xdg-open', request_url], stdout=nul, stderr=nul) else: webbrowser.open_new_tab(request_url) (This retrofit branch hasn't yet reached the point where it'll be tested on Windows. I may still add another branch which calls `start` directly if it proves to have the same priority bug on Windows.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 00:00:27 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 18 Jan 2015 23:00:27 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421621931.83.0.650161343339.issue23262@psf.upfronthosting.co.za> Message-ID: <54BC3B07.8070502@free.fr> Antoine Pitrou added the comment: > Well, then the code which chooses a backend is broken because I have xdg-open and, according to WinPdb, it's using the Mozilla backend. You have xdg-open under Windows? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 00:05:35 2015 From: report at bugs.python.org (Stephan Sokolow) Date: Sun, 18 Jan 2015 23:05:35 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> Message-ID: <1421622335.9.0.475793769194.issue23262@psf.upfronthosting.co.za> Stephan Sokolow added the comment: WinPdb = Windowed Pdb, not MS Windows Pdb. `sudo apt-get install winpdb` ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 00:06:59 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 18 Jan 2015 23:06:59 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> Message-ID: <1421622419.95.0.473168206987.issue23262@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Oops, sorry. The best way forward would be for you to investigate and find out why xdg-open isn't preferred in your setting. ---------- versions: +Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 00:09:04 2015 From: report at bugs.python.org (Stephan Sokolow) Date: Sun, 18 Jan 2015 23:09:04 +0000 Subject: [issue23262] webbrowser module broken with Firefox 36+ In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za> Message-ID: <1421622544.0.0.453496616423.issue23262@psf.upfronthosting.co.za> Stephan Sokolow added the comment: Noted. I'm not sure what my schedule will be like, but I'll try. (I may get back to you with an answer later today or I may not within the week.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 00:55:10 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 18 Jan 2015 23:55:10 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1421625310.07.0.304782643696.issue3566@psf.upfronthosting.co.za> Martin Panter added the comment: Spotted code in Python?s own library that maintains a persistent connection and works around this issue: Lib/xmlrpc/client.py:1142 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 00:59:02 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 18 Jan 2015 23:59:02 +0000 Subject: [issue16648] stdib should use new exception types from PEP 3151 In-Reply-To: <1354995347.5.0.732021100427.issue16648@psf.upfronthosting.co.za> Message-ID: <1421625542.38.0.52747235435.issue16648@psf.upfronthosting.co.za> Martin Panter added the comment: I would support adding ENOTCONN under the ConnectionError umbrella. It is caught for shutdown() calls in a few standard library modules. Here is a demo showing how to trigger it (at least on Linux): from socket import create_connection, SHUT_RDWR from socketserver import TCPServer, BaseRequestHandler from threading import Thread server = TCPServer(("", 0), BaseRequestHandler) Thread(target=server.serve_forever).start() client = create_connection(server.server_address) server.shutdown() # Ensure server has closed client connection server.server_close() client.send(bytes(1)) >>> client.shutdown(SHUT_RDWR) Traceback (most recent call last): File "", line 1, in OSError: [Errno 107] Transport endpoint is not connected ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 02:31:34 2015 From: report at bugs.python.org (Anne Moroney) Date: Mon, 19 Jan 2015 01:31:34 +0000 Subject: [issue22317] action argument is not documented in argparse add_subparser() docs In-Reply-To: <1409517563.44.0.056496049443.issue22317@psf.upfronthosting.co.za> Message-ID: <1421631094.94.0.988901186668.issue22317@psf.upfronthosting.co.za> Anne Moroney added the comment: This ticket's patch appears to have already been merged, yet it is open? On 2.7.9 docs [1], it has the exact language. The tutorial page [2] has a nice description as well. Finding this ticket really helped me understand argparse a bit better, and now I vote to close :). AnneTheAgile, inspired by CodeTriage 1.[] ; ; ; ; ; ; ; ; ; ; X.15.4. argparse ? Parser for command-line options, arguments and sub-commands ? Python 2.7.9 documentation https://docs.python.org/2/library action - The basic type of action to be taken when this argument is encountered at the command line. 2.[] ; ; ; ; ; ; ; ; ; ; X.Argparse Tutorial ? Python 2.7.9 documentation https://docs.python.org/2/howto/argparse.html we now specify a new keyword, action, and give it the value "store_true". This means that, if the option is specified, assign the value True to args.verbose. Not specifying it implies False. 3.[] ; ;List of all types of 'action', including customizable ; ; ; ; ; ; ; ; X.15.4. argparse ? Parser for command-line options, arguments and sub-commands ? Python 2.7.9 documentation https://docs.python.org/2/library/argparse.html#action action="store_true" action='store_false' action="count" action='store_const' action='append' action='version' action=CustomFooAction ---------- nosy: +AnneTheAgile _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 02:54:50 2015 From: report at bugs.python.org (Robert Collins) Date: Mon, 19 Jan 2015 01:54:50 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1421632490.29.0.0984430625833.issue17911@psf.upfronthosting.co.za> Robert Collins added the comment: One thing I noticed while working on this, traceback today stats each included file once per frame per call into e.g. format_list. This might actually account for quite some of the overhead. I'll include an optimisation for this in my new API. http://paste.openstack.org/show/158714/ http://paste.openstack.org/show/158715/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 03:09:29 2015 From: report at bugs.python.org (Robert Collins) Date: Mon, 19 Jan 2015 02:09:29 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1421633369.28.0.0966506818625.issue17911@psf.upfronthosting.co.za> Changes by Robert Collins : Added file: http://bugs.python.org/file37769/linecache_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 03:09:59 2015 From: report at bugs.python.org (Robert Collins) Date: Mon, 19 Jan 2015 02:09:59 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1421633399.67.0.489303831133.issue17911@psf.upfronthosting.co.za> Robert Collins added the comment: This is a WIP patch, including it to just share progress. ---------- Added file: http://bugs.python.org/file37770/frame_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 03:12:38 2015 From: report at bugs.python.org (Robert Collins) Date: Mon, 19 Jan 2015 02:12:38 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1421633558.64.0.0260564410685.issue17911@psf.upfronthosting.co.za> Robert Collins added the comment: And this improves the scaling of the cache stating overhead, but we may well want to fix this more fundamentally - e.g. by linking the cache ownership into the import system somehow, so that when a file is reimported, the cached source is automatically evicted, and format_stack etc have no need to stat at all. I tested this with the following script in timeit: import traceback def recurse(count): if count> 0: return recurse(count - 1) return traceback.format_stack() def doit(): len(recurse(500)) ---------- Added file: http://bugs.python.org/file37771/tb_stats_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 06:46:36 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 19 Jan 2015 05:46:36 +0000 Subject: [issue16473] quopri module differences in quoted-printable text with whitespace In-Reply-To: <1352928126.09.0.115783436578.issue16473@psf.upfronthosting.co.za> Message-ID: <1421646396.55.0.543979122118.issue16473@psf.upfronthosting.co.za> Martin Panter added the comment: Three slightly different points here: 1. Decoding trailing whitespace: My understanding is quoted-printable encoding aims to be tolerant of whitespace being added to and removed from the end of encoded lines. So I assume the ?binascii? module is wrong to leave trailing whitespace in the decoded output, and the native ?quopri? implementation is correct to ignore it. 2. CRLF handling: See Issue 20121. It seems CRLF newlines should be valid, and I have added a patch to that issue to make the native Python implementation handle CRLF newlines. 3. Whitespace encoding: The quopri-codec actually sets quotetabs=True. Here is a patch to document and test that, as well as correct the functions used by other codecs. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, vadmium title: quopri module minor difference in decoding quoted-printable text -> quopri module differences in quoted-printable text with whitespace Added file: http://bugs.python.org/file37772/codec-impl.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 06:57:25 2015 From: report at bugs.python.org (Tim Smith) Date: Mon, 19 Jan 2015 05:57:25 +0000 Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za> Message-ID: <1421647045.64.0.926626953748.issue22490@psf.upfronthosting.co.za> Tim Smith added the comment: Homebrew's interest in this ticket was resolved by the release of pip 6, which includes Vinay's change to distlib to use sys.executable instead of __PYVENV_LAUNCHER__. Many thanks! I'm not marking this fixed in case it is useful to leave this open to discuss unsetting __PYVENV_LAUNCHER__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 06:58:33 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 19 Jan 2015 05:58:33 +0000 Subject: [issue21869] Clean up quopri, correct method names encodestring and decodestring In-Reply-To: <1403686270.37.0.341302276582.issue21869@psf.upfronthosting.co.za> Message-ID: <1421647113.43.0.243465134692.issue21869@psf.upfronthosting.co.za> Martin Panter added the comment: Personally I don?t have a problem with the names; I would consider str(), bytes(), bytearray() types all to be ?strings?. However there is precedent in the ?base64? module for renaming to en/decodebytes(); see Issue 3613. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 07:19:21 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 19 Jan 2015 06:19:21 +0000 Subject: [issue17840] base64_codec uses assert for runtime validity checks In-Reply-To: <1366875650.57.0.151905786577.issue17840@psf.upfronthosting.co.za> Message-ID: <1421648361.23.0.666047645733.issue17840@psf.upfronthosting.co.za> Martin Panter added the comment: Is this patch likely to go ahead? It has been sitting around a while and would conflict with patches I am working on. If so, I reckon it would be good to factor out some of the new bits of code (_check_strict, _StrictErrors) into a common place, like the ?codecs? module. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 07:26:53 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 19 Jan 2015 06:26:53 +0000 Subject: [issue16473] quopri module differences in quoted-printable text with whitespace In-Reply-To: <1352928126.09.0.115783436578.issue16473@psf.upfronthosting.co.za> Message-ID: <1421648813.75.0.748791870378.issue16473@psf.upfronthosting.co.za> Martin Panter added the comment: Regarding decoding trailing whitespace, rule #3 says: ?When decoding a Quoted-Printable body, any trailing white space on a line must be deleted, as it will necessarily have been added by intermediate transport agents.? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 08:16:19 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 19 Jan 2015 07:16:19 +0000 Subject: [issue17840] base64_codec uses assert for runtime validity checks In-Reply-To: <1366875650.57.0.151905786577.issue17840@psf.upfronthosting.co.za> Message-ID: <1421651779.64.0.00644589402721.issue17840@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: test needed -> patch review versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 08:16:38 2015 From: report at bugs.python.org (Ent) Date: Mon, 19 Jan 2015 07:16:38 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1421651798.71.0.849130524263.issue23255@psf.upfronthosting.co.za> Ent added the comment: I am having some issues with replying to comments on review page. It is giving 500 error hence posting replies here. @berker.peksag: Thanks! I will add the methods' documentation & examples into the Doc/library/http.server.rst. As well as include a few unit tests. I searched through github and there doesn't seem to be many examples of "BaseHTTPRequestHandler copyfile". Still if you feel it is better not to make this change, I will revert it back. I have submitted the contribuer-form on the same day as I submitted this patch. Waiting for it to be accepted. Thanks again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 08:24:07 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 19 Jan 2015 07:24:07 +0000 Subject: [issue17840] base64_codec uses assert for runtime validity checks In-Reply-To: <1366875650.57.0.151905786577.issue17840@psf.upfronthosting.co.za> Message-ID: <1421652246.99.0.106491360897.issue17840@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch. I left a couple of comments on Rietveld. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 08:35:53 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 19 Jan 2015 07:35:53 +0000 Subject: [issue17840] base64_codec uses assert for runtime validity checks In-Reply-To: <1366875650.57.0.151905786577.issue17840@psf.upfronthosting.co.za> Message-ID: <1421652953.0.0.835935479099.issue17840@psf.upfronthosting.co.za> Martin Panter added the comment: Would also be good to document that errors='ignored' is not allowed. Currently the documentation says The following string values are defined and implemented by all standard Python codecs: * 'strict' * 'ignore' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 10:15:42 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 19 Jan 2015 09:15:42 +0000 Subject: [issue23269] Tighten-up search loops in sets Message-ID: <1421658942.27.0.429398283891.issue23269@psf.upfronthosting.co.za> New submission from Raymond Hettinger: First draft of patch to switch from a table[(i+j)&mask] style of entry calculation to an entry++ style. The entry computation simplifies from add/shl4/and/lea to a single add16. To do this, the linear probes are limited to the length of table rather than wrapping-around. I haven't timed this one yet (have just looked at the assembly) or worked through the implications. The new approach is a little less attractive but may be easier to reason about than the mask wrap-around. Also, it disadvantages small sets where the wrap-around property assured that the linear probes would always fine a hit without any entry being checked more than once. There is a extra setup time before the linear probes to compute the limit. Also, since the loop size is now variable instead of fixed, the inner loop for set_insert_clean() no longer gets unrolled by either GCC or CLANG. With the change, the inner loop of set_insert_clean() is very tight: L436: addq $16, %rax #, entry entry < limit cmpq %rdx, %rax # limit, entry ja L399 #, entry->key == NULL cmpq $0, (%rax) #,* entry jne L436 The code for lookkey() is also tight (though I can't tell why the entry->key gets loaded from memory twice): L102: cmpq %r15, %r13 # tmp170, D.12706 entry->key == dummy jne L103 #, testq %r12, %r12 # freeslot cmove %r14, %r12 # entry -> freeslot L103: addq $16, %r14 #, entry entry++ cmpq %r14, %rbx # entry, limit jb L146 #, movq (%r14), %r13 # MEM[base: entry_65, offset: 0B], D.12706 testq %r13, %r13 # D.12706 entry->key == NULL je L147 #, cmpq %rbp, 8(%r14) # hash, MEM[base: entry_104, offset: 8B] je L148 #, entry->hash == hash ? movq (%r14), %r13 # MEM[base: entry_104, offset: 0B], D.12706 jmp L102 # ---------- assignee: rhettinger components: Interpreter Core files: limit.diff keywords: patch messages: 234308 nosy: rhettinger priority: low severity: normal stage: patch review status: open title: Tighten-up search loops in sets type: performance versions: Python 3.5 Added file: http://bugs.python.org/file37773/limit.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 10:27:20 2015 From: report at bugs.python.org (Michael Vogt) Date: Mon, 19 Jan 2015 09:27:20 +0000 Subject: [issue23228] Crashes when tarfile contains a symlink and unpack directory contain it too In-Reply-To: <1421139302.16.0.710158118765.issue23228@psf.upfronthosting.co.za> Message-ID: <1421659640.35.0.499518720939.issue23228@psf.upfronthosting.co.za> Michael Vogt added the comment: Thanks SilentGhost for your feedback and sorry for my slow reply. I looked into this some more and attached a updated patch with a more complete test. It also covers a crash now that happens when there is a symlink cycle in the tar and on disk. My fix is to remove existing links before unpack and replace them with the link in the tar. This is what gnu tar is also doing (according to http://www.gnu.org/software/tar/manual/html_node/Dealing-with-Old-Files.html). However this seems to be a behavior change of what the tarfile module has traditionally been done so feel free to reject it, I'm open to alternative ideas of course (even though I feel like having the same behavior as gnu tar is desirable). Thanks, Michael ---------- Added file: http://bugs.python.org/file37774/possible-fix-23228-with-test2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 10:50:10 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 19 Jan 2015 09:50:10 +0000 Subject: [issue23270] Use the new __builtin_mul_overflow() of Clang and GCC 5 to check for integer overflow Message-ID: <1421661010.06.0.656712864154.issue23270@psf.upfronthosting.co.za> New submission from STINNER Victor: In CPython, almost all memory allocations are protected against integer overflow with code looking like that: if (length > ((PY_SSIZE_T_MAX - struct_size) / char_size - 1)) { PyErr_NoMemory(); return NULL; } new_size = (struct_size + (length + 1) * char_size); For performances, GCC 5 introduces __builtin_mul_overflow() which is an integer multiplication with overflow check. On x86/x86_64, it is implemented in hardware (assembler instruction JO, jump if overflow, if I remember correctly). The function already exists in Clang: "... which existed in Clang/LLVM for a while" says http://lwn.net/Articles/623368/ According to this mail sent to the Linux kernel mailing list, the Linux kernel has functions like "check_mul_overflow(X, Y, C)". For other compilers, it should be easy to reimplement it, but I don't know what is the most efficient implementation (Py_LOCAL_INLINE function in an header?) GCC 5 changelog: https://gcc.gnu.org/gcc-5/changes.html Note: GCC 5 is not released yet. ---------- messages: 234310 nosy: haypo priority: normal severity: normal status: open title: Use the new __builtin_mul_overflow() of Clang and GCC 5 to check for integer overflow versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 10:51:34 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 19 Jan 2015 09:51:34 +0000 Subject: [issue23270] Use the new __builtin_mul_overflow() of Clang and GCC 5 to check for integer overflow In-Reply-To: <1421661010.06.0.656712864154.issue23270@psf.upfronthosting.co.za> Message-ID: <1421661094.64.0.115471999214.issue23270@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- components: +Interpreter Core nosy: +serhiy.storchaka type: -> performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 10:57:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 19 Jan 2015 09:57:10 +0000 Subject: [issue23269] Tighten-up search loops in sets In-Reply-To: <1421658942.27.0.429398283891.issue23269@psf.upfronthosting.co.za> Message-ID: <1421661430.71.0.527778416943.issue23269@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +pitrou, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 11:16:56 2015 From: report at bugs.python.org (anupama srinivas murthy) Date: Mon, 19 Jan 2015 10:16:56 +0000 Subject: [issue23217] help() function incorrectly captures comment preceding a nested function In-Reply-To: <1420882396.37.0.573730184021.issue23217@psf.upfronthosting.co.za> Message-ID: <1421662616.65.0.684533136484.issue23217@psf.upfronthosting.co.za> anupama srinivas murthy added the comment: In Python 2.7, the capture happens even if there is no decorator. The code: #Hey this is f def f(): return help(f) gives the output: Help on function f in module __main__: f() #Hey this is f whereas a docstring inside the function causes the comment to be ignored. Therefore, the code: #Hey this is f def f(): '''this is the function f''' return help(f) gives the output: Help on function f in module __main__: f() this is the function f @Gwenllina:I need to clarify my previous comment. The docstring that would cause the preceding comment to be ignored must be in the inner function in case of the first example. Placing it in f() still causes comment capture as you said ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 14:56:59 2015 From: report at bugs.python.org (Dionysis Zindros) Date: Mon, 19 Jan 2015 13:56:59 +0000 Subject: [issue23271] Unicode HOWTO documentation error Message-ID: <1421675819.3.0.538078693406.issue23271@psf.upfronthosting.co.za> New submission from Dionysis Zindros: In the Unicode HOTWO documentation for Python 2.x [0], there's an error in the fourth code sample under the section "The Unicode Type". The code states: ``` >>> s = u'Was ever feather so lightly blown to and fro as this multitude?' >>> s.count('e') 5 >>> s.find('feather') 9 >>> s.find('bird') -1 >>> s.replace('feather', 'sand') u'Was ever sand so lightly blown to and fro as this multitude?' >>> s.upper() u'WAS EVER FEATHER SO LIGHTLY BLOWN TO AND FRO AS THIS MULTITUDE?' ``` Notice that in the last line, "sand" was turned back into "feather". The correct last line should have been: ``` u'WAS EVER SAND SO LIGHTLY BLOWN TO AND FRO AS THIS MULTITUDE?' ``` [0] https://docs.python.org/2/howto/unicode.html ---------- assignee: docs at python components: Documentation messages: 234312 nosy: Dionysis.Zindros, docs at python priority: normal severity: normal status: open title: Unicode HOWTO documentation error type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 15:13:54 2015 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 19 Jan 2015 14:13:54 +0000 Subject: [issue23271] Unicode HOWTO documentation error In-Reply-To: <1421675819.3.0.538078693406.issue23271@psf.upfronthosting.co.za> Message-ID: <1421676834.33.0.886161957596.issue23271@psf.upfronthosting.co.za> Eric V. Smith added the comment: The example is correct. If you type it into a python interpreter, you get the results as shown in the example. The .replace() method does not modify the string s. It returns the new value. In the example, the new value is displayed, but is not assigned back to s, so s does not change. ---------- nosy: +eric.smith resolution: -> not a bug stage: -> resolved status: open -> closed type: enhancement -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 16:05:49 2015 From: report at bugs.python.org (=?utf-8?b?THVrw6HFoSBOxJttZWM=?=) Date: Mon, 19 Jan 2015 15:05:49 +0000 Subject: [issue23272] Python built-in comparison problem Message-ID: <1421679949.19.0.258601138429.issue23272@psf.upfronthosting.co.za> Changes by Luk?? N?mec : ---------- nosy: Luk??.N?mec priority: normal severity: normal status: open title: Python built-in comparison problem _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 16:06:36 2015 From: report at bugs.python.org (=?utf-8?b?THVrw6HFoSBOxJttZWM=?=) Date: Mon, 19 Jan 2015 15:06:36 +0000 Subject: [issue23272] Python built-in comparison problem Message-ID: <1421679996.88.0.502769698893.issue23272@psf.upfronthosting.co.za> Changes by Luk?? N?mec : ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 16:34:18 2015 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 19 Jan 2015 15:34:18 +0000 Subject: [issue7665] test_urllib2 and test_ntpath fail if path contains "\" In-Reply-To: <1263142226.0.0.91918347375.issue7665@psf.upfronthosting.co.za> Message-ID: <1421681658.45.0.284257194487.issue7665@psf.upfronthosting.co.za> Senthil Kumaran added the comment: I reviewed the patch Serhiy. It looks good to me, You can go ahead and commit. Thanks! ---------- assignee: orsenthil -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 17:34:37 2015 From: report at bugs.python.org (Demian Brecht) Date: Mon, 19 Jan 2015 16:34:37 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1421685277.85.0.953193363767.issue3566@psf.upfronthosting.co.za> Demian Brecht added the comment: Hi Martin, Thanks for the example code. I'm not sure whether or not this was your intention, but your example demonstrates a misbehaving client, one that seems to expect a persistent connection from a non-persistent server. TCPServer will only serve a single request and will shutdown and close the socket once the response has been written. The reason that you're seeing different responses sometimes (varying between BadStatusLine and BrokenPipeError) is because of an understandable race condition between the client sending the requests and the server fully shutting down the socket and the client receiving FIN. After digging into this, I'm not sure that there is a better way of handling this case. This exception can occur whether the client has issued a request prior to cleaning up and is expecting a response, or the server is simply misbehaving and sends an invalid status line (i.e. change your response code to an empty string to see what I mean). I'll do some further digging, but I don't believe that there's really a good way to determine whether the BadStatusLine is due to a misbehaving server (sending a non-conforming response) or a closed socket. Considering that the client potentially has no way of knowing whether or not a server socket has been closed (in the case of TCPServer, it does a SHUT_WR), I think that BadStatusLine may be the appropriate exception to use here and the resulting action would have to be left up to the client implementation, such as in xmlrpc.client. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 17:37:13 2015 From: report at bugs.python.org (Demian Brecht) Date: Mon, 19 Jan 2015 16:37:13 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1421685433.95.0.163799659086.issue3566@psf.upfronthosting.co.za> Demian Brecht added the comment: > I'm not sure whether or not this was your intention, but your example demonstrates a misbehaving client, one that seems to expect a persistent connection from a non-persistent server. TCPServer will only serve a single request and will shutdown and close the socket once the response has been written. Sorry, I mis-worded that. I'm /assuming/ that the misbehaving client is what you were intending on demonstrating as it shows the server closing the connection before the client expects it to do so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 17:39:03 2015 From: report at bugs.python.org (Zach Welch) Date: Mon, 19 Jan 2015 16:39:03 +0000 Subject: [issue23199] libpython27.a in amd64 release is 32-bit In-Reply-To: <1420764337.42.0.255694319213.issue23199@psf.upfronthosting.co.za> Message-ID: <1421685543.85.0.206748240906.issue23199@psf.upfronthosting.co.za> Zach Welch added the comment: Yes, pe-i386 and pe-x86-64 are the respective 32-bit and 64-bit object formats. Your commands seem reasonable. With gendef, I just let it create a .def file with the same name (i.e. skip the '-' and redirection); in my mind, that reinforces the association between the dll and def files. With dlltool, I did not have to use the -m flag (as x86-64 is the default for me), but I don't see anything wrong with being explicit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 17:51:43 2015 From: report at bugs.python.org (Jean-Paul Calderone) Date: Mon, 19 Jan 2015 16:51:43 +0000 Subject: [issue1103213] Adding the missing socket.recvall() method Message-ID: <1421686303.22.0.508775753836.issue1103213@psf.upfronthosting.co.za> Changes by Jean-Paul Calderone : ---------- nosy: -exarkun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 18:40:20 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 19 Jan 2015 17:40:20 +0000 Subject: [issue14218] include rendered output in addition to markup In-Reply-To: <1331111194.08.0.943407781198.issue14218@psf.upfronthosting.co.za> Message-ID: <1421689220.86.0.944715826453.issue14218@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 18:55:08 2015 From: report at bugs.python.org (Robert Collins) Date: Mon, 19 Jan 2015 17:55:08 +0000 Subject: [issue23273] traceback: formatting a traceback stats the filesystem Message-ID: <1421690108.46.0.51510686328.issue23273@psf.upfronthosting.co.za> New submission from Robert Collins: Discovered in issue 17911, all the traceback calls that render a stack trace end up calling linecache.checkcache, which stats files on disk, making getting a traceback rather more expensive than folk may expect. For "oops, it crashed" situations thats fine, but when used to gather diagnostic details like tulip does, it becomes substantially more wasteful. Since we know when we've reloaded a module, there should be no need to go out to disk at any other time - particularly since if we *haven't* reloaded the module, doing so will just end up showing the wrong source. Further, PEP 302 source code isn't refreshed when the cache is checked, which can lead to stale code in modules that *have* been reloaded. ---------- messages: 234318 nosy: rbcollins priority: normal severity: normal status: open title: traceback: formatting a traceback stats the filesystem _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 18:56:27 2015 From: report at bugs.python.org (Robert Collins) Date: Mon, 19 Jan 2015 17:56:27 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1421690187.52.0.561869830815.issue17911@psf.upfronthosting.co.za> Robert Collins added the comment: I've split out the stat question to http://bugs.python.org/issue23273 - we can optimise it slightly in this patch, but I think its scope creep here, and will be unclear, to dive after a full fix in this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 18:59:47 2015 From: report at bugs.python.org (Michael Schlenker) Date: Mon, 19 Jan 2015 17:59:47 +0000 Subject: [issue23274] make_ssl_data.py in Python 2.7.9 needs Python 3 to run Message-ID: <1421690387.01.0.101283593365.issue23274@psf.upfronthosting.co.za> New submission from Michael Schlenker: The make_ssl_data.py script in Tools/ssl/ needs a python3 to run due to the usage of open(..., encoding='latin1'). This makes usage on a host without python3 installed more complex than needed. It should use io.open(...) to run on both python3 and python2. ---------- components: Demos and Tools messages: 234320 nosy: schlenk priority: normal severity: normal status: open title: make_ssl_data.py in Python 2.7.9 needs Python 3 to run type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 19:08:51 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 19 Jan 2015 18:08:51 +0000 Subject: [issue23274] make_ssl_data.py in Python 2.7.9 needs Python 3 to run In-Reply-To: <1421690387.01.0.101283593365.issue23274@psf.upfronthosting.co.za> Message-ID: <1421690931.33.0.353222037004.issue23274@psf.upfronthosting.co.za> Antoine Pitrou added the comment: That shouldn't be very important. The already-generated _ssl_data.h in the distribution should be enough. ---------- nosy: +alex, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 19:21:45 2015 From: report at bugs.python.org (Michael Schlenker) Date: Mon, 19 Jan 2015 18:21:45 +0000 Subject: [issue23274] make_ssl_data.py in Python 2.7.9 needs Python 3 to run In-Reply-To: <1421690387.01.0.101283593365.issue23274@psf.upfronthosting.co.za> Message-ID: <1421691705.0.0.270702563972.issue23274@psf.upfronthosting.co.za> Michael Schlenker added the comment: yes, priority is probably low. Just stumbled over it when building against openssl 1.0.1L and trying to regen the datafile automatically in a build script. ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 19:34:50 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 19 Jan 2015 18:34:50 +0000 Subject: [issue23274] make_ssl_data.py in Python 2.7.9 needs Python 3 to run In-Reply-To: <1421690387.01.0.101283593365.issue23274@psf.upfronthosting.co.za> Message-ID: <1421692490.1.0.507152493421.issue23274@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Yesterday I've regenerated _ssl_data.h with the latest OpenSSL git, so that should suit you. Be sure to update your hg clone of Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 20:05:47 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Mon, 19 Jan 2015 19:05:47 +0000 Subject: [issue23275] Can assign [] = (), but not () = [] Message-ID: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za> New submission from Devin Jeanpierre: >>> [] = () >>> () = [] File "", line 1 SyntaxError: can't assign to () This contradicts the assignment grammar, which would make both illegal: https://docs.python.org/3/reference/simple_stmts.html#assignment-statements ---------- components: Interpreter Core messages: 234324 nosy: Devin Jeanpierre priority: normal severity: normal status: open title: Can assign [] = (), but not () = [] type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 20:16:58 2015 From: report at bugs.python.org (Cesar Kawakami) Date: Mon, 19 Jan 2015 19:16:58 +0000 Subject: [issue23275] Can assign [] = (), but not () = [] In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za> Message-ID: <1421695018.22.0.73343347234.issue23275@psf.upfronthosting.co.za> Changes by Cesar Kawakami : ---------- nosy: +Cesar.Kawakami _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 20:22:23 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 19 Jan 2015 19:22:23 +0000 Subject: [issue23275] Can assign [] = (), but not () = [] In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za> Message-ID: <1421695343.53.0.887360997417.issue23275@psf.upfronthosting.co.za> R. David Murray added the comment: My guess is that it is not worth complicating the parser in order to make these two cases consistent, and it should be treated as a doc error. We'll see what other developers think. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 21:12:04 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 19 Jan 2015 20:12:04 +0000 Subject: [issue23275] Can assign [] = (), but not () = [] In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za> Message-ID: <1421698324.87.0.220258977023.issue23275@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The starting point is recognizing that this has been around for very long time and is harmless. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 21:14:44 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 19 Jan 2015 20:14:44 +0000 Subject: [issue23269] Tighten-up search loops in sets In-Reply-To: <1421658942.27.0.429398283891.issue23269@psf.upfronthosting.co.za> Message-ID: <1421698484.3.0.33310101125.issue23269@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Patch timings give inconsistent results. GCC-4.9 generates faster code and CLang generates slower code :-( ---------- Added file: http://bugs.python.org/file37775/timings.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 21:15:18 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 19 Jan 2015 20:15:18 +0000 Subject: [issue23269] Tighten-up search loops in sets In-Reply-To: <1421658942.27.0.429398283891.issue23269@psf.upfronthosting.co.za> Message-ID: <1421698518.47.0.431890627532.issue23269@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file37776/limit2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 21:17:07 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 19 Jan 2015 20:17:07 +0000 Subject: [issue23269] Tighten-up search loops in sets In-Reply-To: <1421658942.27.0.429398283891.issue23269@psf.upfronthosting.co.za> Message-ID: <1421698627.25.0.630210769959.issue23269@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file37777/measure_build_set.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 21:17:35 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 19 Jan 2015 20:17:35 +0000 Subject: [issue23269] Tighten-up search loops in sets In-Reply-To: <1421658942.27.0.429398283891.issue23269@psf.upfronthosting.co.za> Message-ID: <1421698655.62.0.877327428504.issue23269@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Either way the improvement doesn't look terrific, so I would suggest not to bother with this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 19 23:22:19 2015 From: report at bugs.python.org (Alfred Krohmer) Date: Mon, 19 Jan 2015 22:22:19 +0000 Subject: [issue23276] hackcheck is broken in association with __setattr__ Message-ID: <1421706139.14.0.239687578391.issue23276@psf.upfronthosting.co.za> New submission from Alfred Krohmer: The following code: import traceback import sys from PyQt5.QtCore import Qt class MetaA(type): pass class A(metaclass=MetaA): pass class MetaB(type): pass class B(metaclass=MetaB): pass for ClassB in B, Qt: print("Trying class %s" % (ClassB.__name__, )) class MyMeta(type(A), type(ClassB)): def __setattr__(cls, key, value): print(cls) super(type, cls).__setattr__(key, value) class MyClass(A, ClassB, metaclass=MyMeta): pass try: setattr(MyClass, 'abc', 123) except: traceback.print_exc(file=sys.stdout) try: type.__setattr__(MyClass, 'test', 42) except: traceback.print_exc(file=sys.stdout) Fails with the following output: Trying class B Traceback (most recent call last): File "test3.py", line 31, in setattr(MyClass, 'abc', 123) File "test3.py", line 25, in __setattr__ super(type, cls).__setattr__(key, value) TypeError: can't apply this __setattr__ to type object Trying class Qt Traceback (most recent call last): File "test3.py", line 31, in setattr(MyClass, 'abc', 123) File "test3.py", line 25, in __setattr__ super(type, cls).__setattr__(key, value) TypeError: can't apply this __setattr__ to sip.wrappertype object Traceback (most recent call last): File "test3.py", line 36, in type.__setattr__(MyClass, 'test', 42) TypeError: can't apply this __setattr__ to sip.wrappertype object The metaclass of a class should be able to update its class' __dict__ my calling super(type, cls).__setattr__ (there is no other way known to me to do this). Furthermore, if subclassing an external class, like Qt, it should be possible to use type.__setattr__(MyClass, ...) externally to change the class' attributes. The error is caused by the hackcheck function in objects/typeobject.c. ---------- components: Interpreter Core, Library (Lib) messages: 234329 nosy: devkid priority: normal severity: normal status: open title: hackcheck is broken in association with __setattr__ 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 20 00:51:49 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 19 Jan 2015 23:51:49 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1421711509.0.0.998400528725.issue3566@psf.upfronthosting.co.za> Martin Panter added the comment: Hi Demian, my intention is to demonstrate normal usage of Python?s HTTP client, whether or not its implementation misbehaves. I am trying to demonstrate a valid persistent server that happens to decide to close the connection after the first request but before reading a second request. Quoting the original post: ?Servers may close a persistent connection after a request due to a timeout or other reason.? I am attaching a second demo script which includes short sleep() calls to emulate a period of time elapsing and the server timing out the connection, which is common for real-world servers. The new script also avoids the EPIPE race by waiting until the server has definitely shut down the socket, and also demonstrates ECONNRESET. However this synchronization is artificial: in the real world the particular failure mode (BadStatusLine/EPIPE/ECONNRESET) may be uncertain. If you are worried about detecting a misbehaving server that closes the connection before even responding to the first request, perhaps the HTTPConnection class could maintain a flag and handle the closed connection differently if it has not already seen a complete response. If you are worried about detecting a misbehaving server that sends an empty status line without closing the connection, there will still be a newline code received. This is already handled separately by existing code: Lib/http/client.py:210 versus Lib/http/client.py:223. I think there should be a separate exception, say called ConnectionClosed, for when the ?status line? is an empty string (""), which is caused by reading the end of the stream. This is valid HTTP behaviour for the second and subsequent requests, so the HTTP library should understand it. BadStatusLine is documented for ?status codes we don?t understand?. The new ConnectionClosed exception should probably be a subclass of BadStatusLine for backwards compatibility. A further enhancement could be to wrap any ConnectionError during the request() stage, or first part of the getresponse() stage, in the same ConnectionClosed exception. Alternatively, the new ConnectionClosed exception could subclass both BadStatusLine and ConnectionError. Either way, code like the XML-RPC client could be simplified to: try: return self.single_request(...) except http.client.ConnectionClosed: #except ConnectionError: # Alternative #retry request once if cached connection has gone cold return self.single_request(...) ---------- Added file: http://bugs.python.org/file37778/persistent-closing.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 00:55:03 2015 From: report at bugs.python.org (Robert Collins) Date: Mon, 19 Jan 2015 23:55:03 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1421711703.54.0.224296855563.issue3566@psf.upfronthosting.co.za> Robert Collins added the comment: FWIW, I agree with the analysis here, its standard HTTP behaviour in the real world, and we should indeed handle it. ---------- nosy: +rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 01:36:09 2015 From: report at bugs.python.org (Neil Girdhar) Date: Tue, 20 Jan 2015 00:36:09 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421714169.71.0.531967679896.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Updated the patch for 3.5. Currently, building fails with TypeError: init_builtin() takes exactly 1 argument (0 given) This is probably due to an argument counting bug, but I am not sure how to debug it. ---------- nosy: +neil.g Added file: http://bugs.python.org/file37779/starunpack3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 02:08:38 2015 From: report at bugs.python.org (eryksun) Date: Tue, 20 Jan 2015 01:08:38 +0000 Subject: [issue23276] hackcheck is broken in association with __setattr__ In-Reply-To: <1421706139.14.0.239687578391.issue23276@psf.upfronthosting.co.za> Message-ID: <1421716118.95.0.0405463110133.issue23276@psf.upfronthosting.co.za> eryksun added the comment: > super(type, cls).__setattr__(key, value) In your case, super(type, cls).__setattr__ references object.__setattr__. >>> super(type, MyClass).__setattr__.__objclass__ That's from the method resolution order (__mro__): >>> print(*MyMeta.__mro__, sep='\n') Instead use super(MyMeta, cls), or in Python 3 just use super() in a method (under the hood the function uses a closure variable named __class__). >>> super(MyMeta, MyClass).__setattr__.__objclass__ > type.__setattr__(MyClass, 'test', 42) The above won't work for a Qt subclass. You need __setattr__ from sip.wrappertype. >>> type.__setattr__(QtClass, 'test', 42) Traceback (most recent call last): File "", line 1, in TypeError: can't apply this __setattr__ to sip.wrappertype object >>> print(*QtMeta.__mro__, sep='\n') >>> super(QtMeta, QtClass).__setattr__.__objclass__ >>> super(QtMeta, QtClass).__setattr__('test', 42) >>> QtClass.test 42 ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 02:17:44 2015 From: report at bugs.python.org (Jon Dufresne) Date: Tue, 20 Jan 2015 01:17:44 +0000 Subject: [issue23277] Cleanup unused and duplicate imports in tests Message-ID: <1421716663.28.0.404138725628.issue23277@psf.upfronthosting.co.za> New submission from Jon Dufresne: Ran variations of the command: $ find . -wholename '*/test/*.py' | xargs flake8 --select=F401,F811 To look for unused or duplicate imports. The attached patch removes them. ---------- components: Tests files: cleanup-unused-imports.patch keywords: patch messages: 234334 nosy: jdufresne priority: normal severity: normal status: open title: Cleanup unused and duplicate imports in tests versions: Python 3.6 Added file: http://bugs.python.org/file37780/cleanup-unused-imports.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 02:55:43 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 20 Jan 2015 01:55:43 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1421718943.42.0.237006645322.issue3566@psf.upfronthosting.co.za> Demian Brecht added the comment: Sorry Martin, I should really not dig into issues like this first thing in the morning ;) My concern about the proposed change isn't whether or not it isn't valid HTTP behaviour, it is. My concern (albeit a small one) is that the change implies an assumption that may not necessarily be true. No matter how valid based on the HTTP spec, it's still an assumption that /can/ potentially lead to confusion. I do agree that a change /should/ be made, I just want to make sure that all potential cases are considered before implementing one. For example, applying the following patch to the first attachment: 52,57c52,53 < self.wfile.write( < b"HTTP/1.1 200 Dropping connection\r\n" < b"Content-Length: 0\r\n" < b"\r\n" < ) < --- > self.wfile.write(b'') > Should the proposed change be made, the above would error out with a ConnectionClosed exception, which is invalid because the connection has not actually been closed and BadStatusLine is actually closer to being correct. Admittedly, this is a little contrived, doesn't adhere to the HTTP spec and is much less likely to happen in the real world than a connection unexpectedly closed by the server, but I don't think it's an unreasonable assumption for lesser used servers or proxies or those in development. In those cases, the proposed change would result in just as much confusion as the current behaviour with connections that are intended to be persistent. In my mind, the one constant through both of these cases is that the response that the client has read is unexpected. In light of that, rather than a ConnectionClosed error, what about UnexpectedResponse, inheriting from BadStatusLine for backwards compatibility and documented as possibly being raised as a result of either case? I think this would cover both cases where a socket has been closed as well as an altogether invalid response. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 03:00:45 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 20 Jan 2015 02:00:45 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1421719245.84.0.121264446965.issue23255@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 03:02:52 2015 From: report at bugs.python.org (Nelson Minar) Date: Tue, 20 Jan 2015 02:02:52 +0000 Subject: [issue23278] multiprocessing maxtasksperchild=1 + logging = task loss Message-ID: <1421719372.42.0.719053884187.issue23278@psf.upfronthosting.co.za> New submission from Nelson Minar: I have a demonstration of a problem where the combination of multiprocessing with maxtasksperchild=1 and the Python logging library causes tasks to occasionally get lost. The bug might be related to issue 22393 or issue 6721, but I'm not certain. issue 10037 and issue 9205 also might be relevant. I've attached sample code, it can also be found at https://gist.github.com/NelsonMinar/022794b6a709ea5b7682 My program uses Pool.imap_unordered() to execute 200 tasks. Each worker task writes a log message and sleeps a short time. The master process uses a timeout on next() to log a status message occasionally. When it works, 200 jobs are completed quickly. When it breaks, roughly 195 of 200 jobs will have completed and next() never raises StopIteration. If everything logs to logging.getLogger() and maxtasksperchild=1, it usually breaks. It appears that sometimes jobs just get lost and don't complete. We've observed that with maxtasksperchild=1 sometimes a new worker process gets created but no work assigned to it. When that happens the task queue never runs to completion. If we log straight to stderr or don't set maxtasksperchild, the run completes. The bug has been observed in Python 2.7.6 and Python 3.4.0 on Ubuntu 14.04 This is a distillation of much more complex application-specific code. Discussion of the bug and original code can be found at https://github.com/openaddresses/machine/issues/51 https://github.com/openaddresses/machine/blob/7c3d0fba8ba0915af2101ace45dfaf5519d5ad85/openaddr/jobs.py Thank you, Nelson ---------- components: Library (Lib) files: bug-demo.py messages: 234336 nosy: nelson priority: normal severity: normal status: open title: multiprocessing maxtasksperchild=1 + logging = task loss type: behavior versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file37781/bug-demo.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 03:28:30 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 20 Jan 2015 02:28:30 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1421720910.13.0.833623470762.issue3566@psf.upfronthosting.co.za> Martin Panter added the comment: Calling self.wfile.write(b"") should be equivalent to not calling write() at all, as far as I understand. Using strace, it does not seem to invoke send() at all. So the result will depend on what is written next. In the case of my code, nothing is written next; the connection is shut down instead. So I don?t believe this case is any different from ?a connection unexpectedly closed by the server?. To be clear, I think the situation we are talking about is: 1. Client connects to server and sends short request; server accepts connection and possibly reads request 2. Server does not write any response, or just calls write(b""), which is equivalent 3. Server shuts down connection 4. Client reads end of stream (b"") instead of proper status line But to address your concern in any case, see the third paragram in . I propose some internal flag like HTTPConnection._initial_response, that gets set to False after the first proper response is received. Then the code could be changed to something like: if not line: # Presumably, the server closed the connection before # sending a valid response. if self._initial_response: raise BadStatusLine(line) else: raise ConnectionClosed("Stream ended before receiving response") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 03:38:02 2015 From: report at bugs.python.org (Robert Collins) Date: Tue, 20 Jan 2015 02:38:02 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1421721482.7.0.66032587209.issue17911@psf.upfronthosting.co.za> Robert Collins added the comment: Stack and Frame looking good, next update will be next Monday, when I finish off my TracebackException class. ---------- Added file: http://bugs.python.org/file37782/issue17911-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 05:30:44 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 20 Jan 2015 04:30:44 +0000 Subject: [issue20898] Missing 507 response description In-Reply-To: <1394637244.26.0.361164120424.issue20898@psf.upfronthosting.co.za> Message-ID: <20150120043038.69920.11060@psf.io> Roundup Robot added the comment: New changeset c8647dab4780 by Berker Peksag in branch 'default': Issue #20898: Add a "HTTP status codes" section to avoid duplication in HTTP docs. https://hg.python.org/cpython/rev/c8647dab4780 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 05:33:13 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 20 Jan 2015 04:33:13 +0000 Subject: [issue20898] Missing 507 response description In-Reply-To: <1394637244.26.0.361164120424.issue20898@psf.upfronthosting.co.za> Message-ID: <1421728393.29.0.423935628969.issue20898@psf.upfronthosting.co.za> Berker Peksag added the comment: Committed now, sorry about the delay. Thanks for the patch, Demian. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 05:42:23 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 20 Jan 2015 04:42:23 +0000 Subject: [issue20898] Missing 507 response description In-Reply-To: <1394637244.26.0.361164120424.issue20898@psf.upfronthosting.co.za> Message-ID: <1421728943.44.0.521504341245.issue20898@psf.upfronthosting.co.za> Demian Brecht added the comment: No worries, thanks for taking care of merging it Berker. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 05:43:45 2015 From: report at bugs.python.org (Chris Angelico) Date: Tue, 20 Jan 2015 04:43:45 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421729025.85.0.0807379896549.issue2292@psf.upfronthosting.co.za> Chris Angelico added the comment: The third version of the patch is huge compared to the other two. Is it all important? I'm seeing a different build failure, and with the size of patch, I'm not sure I'm well placed to figure out what's going on. -- cut -- Traceback (most recent call last): File "", line 2420, in _install File "", line 2366, in _setup File "", line 2329, in _builtin_from_name File "", line 1144, in _load_unlocked File "", line 1114, in _load_backward_compatible File "", line 551, in _requires_builtin_wrapper File "", line 1247, in load_module File "", line 321, in _call_with_frames_removed TypeError: init_builtin() takes exactly 1 argument (0 given) Fatal Python error: Py_Initialize: importlib install failed Current thread 0x00002b7f066c6b20 (most recent call first): Aborted generate-posix-vars failed -- cut -- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 05:44:00 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 20 Jan 2015 04:44:00 +0000 Subject: [issue20121] quopri_codec newline handling In-Reply-To: <1388836490.83.0.337537980753.issue20121@psf.upfronthosting.co.za> Message-ID: <1421729040.48.0.546858290146.issue20121@psf.upfronthosting.co.za> Martin Panter added the comment: Here is patch v2, which fixes some more bugs I uncovered in the quoted-printable encoders: * The binascii version would unnecessarily break a 76-character line (maximum length) if it would end with an =XX escape code * The native Python version would insert soft line breaks in the middle of =XX escape codes ---------- type: -> behavior Added file: http://bugs.python.org/file37783/quopri-newline.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 05:46:45 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 20 Jan 2015 04:46:45 +0000 Subject: [issue22317] action argument is not documented in argparse add_subparser() docs In-Reply-To: <1409517563.44.0.056496049443.issue22317@psf.upfronthosting.co.za> Message-ID: <20150120044642.69916.5392@psf.io> Roundup Robot added the comment: New changeset 350b8e109c42 by Berker Peksag in branch '3.4': Issue #22317: Document the action parameter in ArgumentParser.add_subparsers() docs. https://hg.python.org/cpython/rev/350b8e109c42 New changeset 4709290253e3 by Berker Peksag in branch 'default': Issue #22317: Document the action parameter in ArgumentParser.add_subparsers() docs. https://hg.python.org/cpython/rev/4709290253e3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 05:48:28 2015 From: report at bugs.python.org (Douglas Rudd) Date: Tue, 20 Jan 2015 04:48:28 +0000 Subject: [issue23279] test_site/test_startup_imports fails when mpl_toolkit or logilab based modules installed Message-ID: <1421729308.95.0.570059573722.issue23279@psf.upfronthosting.co.za> New submission from Douglas Rudd: pth files for logilab (e.g. logilab_common, logilab_astng) and mpl_toolkit (e.g. basemap, matplotlib) contain code like the following (taken from basemap 1.0.7): import sys, types, os;p = os.path.join(sys._getframe(1).f_locals['sitedir'], *('mpl_toolkits',));ie = os.path.exists(os.path.join(p,'__init__.py'));m = not ie and sys.modules.setdefault('mpl_toolkits', types.ModuleType('mpl_toolkits'));mp = (m or []) and m.__dict__.setdefault('__path__',[]);(p not in mp) and mp.append(p) This leads to the types module being loaded on import, which then causes test_site/test_startup_imports to fail since types is in collection_mods: collection_mods = {'_collections', 'collections', 'functools', 'heapq', 'itertools', 'keyword', 'operator', 'reprlib', 'types', 'weakref' }.difference(sys.builtin_module_names) self.assertFalse(modules.intersection(collection_mods), stderr) $ python3.4 -c 'import sys; print(set(sys.modules))' {'builtins', '_codecs', 'io', 'errno', 'abc', '_weakref', '_collections_abc', '_bootlocale', 'stat', 'os', '_frozen_importlib', 'encodings.utf_8', '_sitebuiltins', '_sysconfigdata', 'sysconfig', 'posixpath', 'sys', 'mpl_toolkits', '_weakrefset', 'encodings', 'encodings.aliases', 'signal', '__main__', '_stat', 'zipimport', 'genericpath', 'site', '_io', 'posix', 'codecs', 'types', '_imp', 'os.path', '_warnings', 'marshal', '_locale', '_thread', 'encodings.latin_1'} This is a similar bug to http://bugs.python.org/issue20986 I don't know the purpose of this test well enough to propose a fix, but given the number of exceptions already there it doesn't seem to be a robust test. ---------- components: Tests messages: 234345 nosy: drudd priority: normal severity: normal status: open title: test_site/test_startup_imports fails when mpl_toolkit or logilab based modules installed versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 05:49:40 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 20 Jan 2015 04:49:40 +0000 Subject: [issue23278] multiprocessing maxtasksperchild=1 + logging = task loss In-Reply-To: <1421719372.42.0.719053884187.issue23278@psf.upfronthosting.co.za> Message-ID: <1421729380.67.0.334146007165.issue23278@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +sbt, vinay.sajip stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 05:55:47 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 20 Jan 2015 04:55:47 +0000 Subject: [issue22317] action argument is not documented in argparse add_subparser() docs In-Reply-To: <1409517563.44.0.056496049443.issue22317@psf.upfronthosting.co.za> Message-ID: <20150120045542.69900.134@psf.io> Roundup Robot added the comment: New changeset 430236ef507b by Berker Peksag in branch '2.7': Issue #22317: Document the action parameter in ArgumentParser.add_subparsers() docs. https://hg.python.org/cpython/rev/430236ef507b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 05:56:55 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 20 Jan 2015 04:56:55 +0000 Subject: [issue22317] action argument is not documented in argparse add_subparser() docs In-Reply-To: <1409517563.44.0.056496049443.issue22317@psf.upfronthosting.co.za> Message-ID: <1421729815.37.0.482337728243.issue22317@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Mike. Anne, thank you for the ticket triage! The only missing place was the ArgumentParser.add_subparsers() documentation: https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_subparsers ---------- nosy: +berker.peksag resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 06:04:40 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 20 Jan 2015 05:04:40 +0000 Subject: [issue20702] warning in cmdline.rst In-Reply-To: <1392912711.56.0.068160127769.issue20702@psf.upfronthosting.co.za> Message-ID: <1421730280.97.0.959676701509.issue20702@psf.upfronthosting.co.za> Berker Peksag added the comment: I couldn't reproduce it with Sphinx 1.2.3. The only warning I got was Doc/whatsnew/3.4.rst:2138: WARNING: undefined label: idle (if the link has no caption the label must precede a section header) ---------- nosy: +berker.peksag resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 06:38:29 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 20 Jan 2015 05:38:29 +0000 Subject: [issue20898] Missing 507 response description In-Reply-To: <1394637244.26.0.361164120424.issue20898@psf.upfronthosting.co.za> Message-ID: <1421732309.3.0.0197694078915.issue20898@psf.upfronthosting.co.za> Martin Panter added the comment: Just noticed the new documentation says ?http.HTTPStatus.OK is also available as . . . http.server.OK?. I think this is wrong; only the client module (and now the top-level package) have those constants. The enum values are only available in the server module via http.server.BaseHTTPRequestHandler.responses.keys() as far as I can tell. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 06:42:24 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 20 Jan 2015 05:42:24 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1421732544.71.0.186849923259.issue3566@psf.upfronthosting.co.za> Demian Brecht added the comment: > Calling self.wfile.write(b"") should be equivalent to not calling write() at all, as far as I understand. Right (or at least, as I understand it as well). Really, this boils down to a philosophical debate: Should the standard library account for unexpected conditions where possible (within reason of course), or should it only account for conditions as described by specifications? > 1. Client connects to server and sends short request; server accepts connection and possibly reads request > [snip] This flow makes sense and is well accounted for with your proposed change. However, misbehaving cases such as: 1. Client connects to server or proxy (possibly through a tunnel) and sends request; server/proxy accepts connection and possibly reads request 2. Server/proxy intends to send a response, but doesn't for any number of reasons (bug, still in development, etc) 3. The connection is not closed and subsequent requests may succeed Granted, the result is unexpected and doesn't comply with HTTP RFCs. However, leading the user to believe that the connection has been closed when it actually hasn't is misleading. I've spent many an hour trying to hunt down root causes of issues like this and bashed my head against a keyboard in disbelief when I found out what the cause /really/ was. Because of those headaches, I still think that the introduction of an UnexpectedResponse, if well documented, covers both cases nicely, but won't heatedly argue it further :) If others (namely core devs) think that the introduction of ConnectionClosed exception is a better way to go, then I'll bow out. It would maybe be nice to have Senthil chime in on this. > But to address your concern in any case, see the third paragram in . I don't think that should be added at all as the issue that I'm describing can occur at any point, not only the first request. On another note, were you interested in submitting a patch for this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 06:43:57 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 20 Jan 2015 05:43:57 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1421732637.29.0.492242258285.issue3566@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- nosy: -gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 07:03:07 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 20 Jan 2015 06:03:07 +0000 Subject: [issue20898] Missing 507 response description In-Reply-To: <1394637244.26.0.361164120424.issue20898@psf.upfronthosting.co.za> Message-ID: <20150120060219.118078.28087@psf.io> Roundup Robot added the comment: New changeset 3a95a74aca4e by Berker Peksag in branch 'default': Issue #20898: Enum names are only available in the http.client module as constants. https://hg.python.org/cpython/rev/3a95a74aca4e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 07:03:38 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 20 Jan 2015 06:03:38 +0000 Subject: [issue20898] Missing 507 response description In-Reply-To: <1394637244.26.0.361164120424.issue20898@psf.upfronthosting.co.za> Message-ID: <1421733818.69.0.350807236696.issue20898@psf.upfronthosting.co.za> Berker Peksag added the comment: Good catch, thank you Martin. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 07:07:31 2015 From: report at bugs.python.org (Zachary Ware) Date: Tue, 20 Jan 2015 06:07:31 +0000 Subject: [issue23280] Convert binascii.{un}hexlify to Argument Clinic (fix docstrings) Message-ID: <1421734051.68.0.00270883538381.issue23280@psf.upfronthosting.co.za> New submission from Zachary Ware: The Argument Clinic conversion of the binascii module left hexlify and unhexlify with bad docstrings: hexlify(...) b2a_hex($module, data, /) -- Hexadecimal representation of binary data. The return value is a bytes object. This function is also available as "hexlify()". unhexlify(...) a2b_hex($module, hexstr, /) -- Binary data of hexadecimal representation. hexstr must contain an even number of hex digits (upper or lower case). This function is also available as "unhexlify()". Attached patch fixes it, removes the note that the function is also available as itself (leaving the note on {a2b,b2a}_hex), and tests that the functions are in fact aliases. ---------- components: Extension Modules files: binascii_clinic_fix.diff keywords: patch messages: 234353 nosy: serhiy.storchaka, zach.ware priority: normal severity: normal stage: patch review status: open title: Convert binascii.{un}hexlify to Argument Clinic (fix docstrings) type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37784/binascii_clinic_fix.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 07:22:45 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 20 Jan 2015 06:22:45 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1421734965.77.0.163709636319.issue3566@psf.upfronthosting.co.za> Martin Panter added the comment: Yeah I?m happy to put a patch together, once I have an idea of the details. I?d also like to understand your scenario that would mislead the user to believe that the connection has been closed when it actually hasn?t. Can you give a concrete example or demonstration? Given your misbehaving flow: 1. Client connects to server or proxy (possibly through a tunnel) and sends request; server/proxy accepts connection and possibly reads request 2. Server/proxy intends to send a response, but doesn't for any number of reasons (bug, still in development, etc) 3. The connection is not closed and subsequent requests may succeed I would expect the client would still be waiting to read the status line of the response that was never sent in step 2. Eventually the server _would_ probably drop the connection (so ConnectionClosed would not be misleading), or the client would time it out (a different error would be raised). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 07:43:45 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 20 Jan 2015 06:43:45 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1421736225.77.0.946774229611.issue3566@psf.upfronthosting.co.za> R. David Murray added the comment: I think that in other stdlib networking modules, a connection closed error is raised when an operation is attempted on a closed connection. For example, in smtplib, the server may return an error code and then (contrary to the RFC) close the connection. We fixed a bug in smtplib where this was mishandled (the error code was lost and SMTPServerDisconnected was raised instead). Now we return the error code, and the *next* operation on the connection gets the connection closed error. I think this is a good model, but I'm not sure if/how it can be applied here. That is, if the connection has been closed, I think an operation attempted on the connection should raise an exception that makes it clear that the connection is closed (in the case of some stdlib modules, that may be a socket level exception for the operation on the closed socket). I think the remote server writing a blank line to the socket is a very different thing from the remote server closing the connection without writing anything, so I may be misunderstanding something here. Note that handling this is potentially more complicated with https, since in that case we have a wrapper around the socket communication that has some buffering involved. But also note that if a new exception is introduced this becomes a feature and by our normal policies can only go into 3.5. ---------- versions: +Python 3.4, Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 08:09:41 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 20 Jan 2015 07:09:41 +0000 Subject: [issue23277] Cleanup unused and duplicate imports in tests In-Reply-To: <1421716663.28.0.404138725628.issue23277@psf.upfronthosting.co.za> Message-ID: <1421737781.37.0.137570947621.issue23277@psf.upfronthosting.co.za> Berker Peksag added the comment: +1 for cleanup. ---------- nosy: +berker.peksag stage: -> patch review versions: +Python 3.4, Python 3.5 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 08:35:29 2015 From: report at bugs.python.org (=?utf-8?q?Pawe=C5=82_Zduniak?=) Date: Tue, 20 Jan 2015 07:35:29 +0000 Subject: [issue23281] Access violation - pyc file Message-ID: <1421739329.05.0.520185996533.issue23281@psf.upfronthosting.co.za> New submission from Pawe? Zduniak: (950.e58): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Windows\SysWOW64\python27.dll - python27!PyEval_EvalFrameEx+0x1895: 1e0bcb45 8b74b00c mov esi,dword ptr [eax+esi*4+0Ch] ds:002b:0224207c=???????? ---------- components: Windows files: test.pyc messages: 234357 nosy: Pawe?.Zduniak, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Access violation - pyc file type: crash versions: Python 2.7 Added file: http://bugs.python.org/file37785/test.pyc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 08:46:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 20 Jan 2015 07:46:23 +0000 Subject: [issue23280] Convert binascii.{un}hexlify to Argument Clinic (fix docstrings) In-Reply-To: <1421734051.68.0.00270883538381.issue23280@psf.upfronthosting.co.za> Message-ID: <1421739983.57.0.0629838255063.issue23280@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 09:08:17 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 20 Jan 2015 08:08:17 +0000 Subject: [issue23269] Tighten-up search loops in sets In-Reply-To: <1421658942.27.0.429398283891.issue23269@psf.upfronthosting.co.za> Message-ID: <1421741297.77.0.193625172133.issue23269@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 09:11:10 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 20 Jan 2015 08:11:10 +0000 Subject: [issue18898] Apply the setobject optimizations to dictionaries In-Reply-To: <1378012493.62.0.577402281969.issue18898@psf.upfronthosting.co.za> Message-ID: <1421741470.44.0.159807328192.issue18898@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 09:40:20 2015 From: report at bugs.python.org (Alfred Krohmer) Date: Tue, 20 Jan 2015 08:40:20 +0000 Subject: [issue23276] hackcheck is broken in association with __setattr__ In-Reply-To: <1421706139.14.0.239687578391.issue23276@psf.upfronthosting.co.za> Message-ID: <1421743220.38.0.71846891319.issue23276@psf.upfronthosting.co.za> Alfred Krohmer added the comment: Can you elaborate what QtClass and QtMeta is in your case? My original example was reduced to a minimal case and seems to work with your suggestions. The complete example involving SQLalchemy is here: http://stackoverflow.com/questions/28032928/sqlalchemy-multiple-base-classes-not-working and does, however, not work. If I try to do # ... def __setattr__(cls, key, value): super(type(QMediaPlaylist), cls).__setattr__(cls, key, value) return The program segfaults when instantiating the Playlist class. However, this approach seems a little bit strange to me anyhow. The same happens when I try to do: # ... def __setattr__(cls, key, value): super(type(base), cls).__setattr__(cls, key, value) return I think that comes from PyQt specific attributes SQLalchemy is trying to set / replace. So, coming back to the original question, how can I actually set an attribute of my class Playlist from within its metaclass without involving the parent classes of the subclass (type(base) and type(QMediaPlaylist))? Because the __setattr__ from PyQt won't work (segfault) and the one from SQLalchemy does stupid stuff. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 09:56:09 2015 From: report at bugs.python.org (eryksun) Date: Tue, 20 Jan 2015 08:56:09 +0000 Subject: [issue23281] Access violation - pyc file In-Reply-To: <1421739329.05.0.520185996533.issue23281@psf.upfronthosting.co.za> Message-ID: <1421744168.99.0.97566076153.issue23281@psf.upfronthosting.co.za> eryksun added the comment: You attached a corrupt bytecode cache for stdlib bisect.py: >>> f = open('test.pyc', 'rb') >>> magic,tstamp = struct.unpack('>> magic27 = 62211 | (ord('\r') << 16) | (ord('\n') << 24) >>> magic == magic27 True >>> datetime.fromtimestamp(tstamp) datetime.datetime(2011, 3, 8, 2, 39, 36) >>> code = marshal.load(f) >>> dis.dis(code) 1 0 LOAD_CONST 0 ('Bisection algorithms.') 3 STORE_NAME 0 (__doc__) 3 6 LOAD_CONST 1 (0) 9 LOAD_CONST 8 (None) 12 LOAD_CONST 2 () 15 MAKE_FUNCTION 2 18 STORE_NAME 2 (insort_right) 22 21 LOAD_NAME 65282 Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/dis.py", line 43, in dis disassemble(x) File "/usr/lib/python2.7/dis.py", line 97, in disassemble print '(' + co.co_names[oparg] + ')', IndexError: tuple index out of range It's no surprise if this bad file crashed the interpreter. Just delete it. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 10:25:19 2015 From: report at bugs.python.org (Kyle Buzsaki) Date: Tue, 20 Jan 2015 09:25:19 +0000 Subject: [issue23275] Can assign [] = (), but not () = [] In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za> Message-ID: <1421745919.75.0.774207113291.issue23275@psf.upfronthosting.co.za> Kyle Buzsaki added the comment: It seems that assigning to [] is the odd one out in this case. Why is this even possible? >>> [] = () >>> [] = {} >>> [] = set() >>> list() = () File "", line 1 SyntaxError: can't assign to function call >>> () = [] File "", line 1 SyntaxError: can't assign to () >>> {} = [] File "", line 1 SyntaxError: can't assign to literal >>> set() = [] File "", line 1 SyntaxError: can't assign to function call >>> ---------- nosy: +Kyle.Buzsaki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 10:26:07 2015 From: report at bugs.python.org (Ent) Date: Tue, 20 Jan 2015 09:26:07 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1421745967.61.0.999363753204.issue23255@psf.upfronthosting.co.za> Ent added the comment: Following is updated patch with * Refactored code with helper functions * Unit Tests * Documentation - Explanation + Examples SimpleHTTPRequestHandler's copyfile has been renamed to copy_file but not shutils'. ---------- Added file: http://bugs.python.org/file37786/helpers-unittests-docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 10:32:05 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 20 Jan 2015 09:32:05 +0000 Subject: [issue1508475] transparent gzip compression in urllib Message-ID: <1421746325.32.0.829280127131.issue1508475@psf.upfronthosting.co.za> Martin Panter added the comment: The Lib/xmlrpc/client.py file appears to already support compression using ?Content-Encoding: gzip?. Perhaps it could be leveraged for any work on this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 10:40:47 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 20 Jan 2015 09:40:47 +0000 Subject: [issue23275] Can assign [] = (), but not () = [] In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za> Message-ID: <1421746847.63.0.595286514544.issue23275@psf.upfronthosting.co.za> Martin Panter added the comment: But () is the odd one out if you consider >>> [a, b] = range(2) >>> [] = range(0) >>> (a, b) = range(2) >>> () = range(0) File "", line 1 SyntaxError: can't assign to () ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 11:19:31 2015 From: report at bugs.python.org (eryksun) Date: Tue, 20 Jan 2015 10:19:31 +0000 Subject: [issue23275] Can assign [] = (), but not () = [] In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za> Message-ID: <1421749171.02.0.608455967148.issue23275@psf.upfronthosting.co.za> eryksun added the comment: In ast.c, set_context checks for assignment to an empty tuple, but not an empty list. case List_kind: e->v.List.ctx = ctx; s = e->v.List.elts; break; case Tuple_kind: if (asdl_seq_LEN(e->v.Tuple.elts)) { e->v.Tuple.ctx = ctx; s = e->v.Tuple.elts; } else { expr_name = "()"; } break; https://hg.python.org/cpython/file/ab2c023a9432/Python/ast.c#l912 ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 11:33:13 2015 From: report at bugs.python.org (Neil Girdhar) Date: Tue, 20 Jan 2015 10:33:13 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421749993.82.0.738031615939.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Hi Chris. It might be hard to notice, but you're seeing the same build failure. Looking at the patch-to-patch differences, I didn't see anything out of the ordinary. My patch file includes more surrounding lines, dates, and is against a different repository, so it sees a lot of the new matrix multiplication operator stuff, etc. Is there a best practice for creating diff files? I just did hg diff > starunpack3.diff. Anyway, here's a new patch with the "yield *args" code that has been supplanted by "yield from" removed. ---------- Added file: http://bugs.python.org/file37787/starunpack4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 11:37:30 2015 From: report at bugs.python.org (Neil Girdhar) Date: Tue, 20 Jan 2015 10:37:30 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421750250.36.0.560690374896.issue2292@psf.upfronthosting.co.za> Changes by Neil Girdhar : Removed file: http://bugs.python.org/file37787/starunpack4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 11:37:57 2015 From: report at bugs.python.org (Neil Girdhar) Date: Tue, 20 Jan 2015 10:37:57 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421750277.5.0.931036460494.issue2292@psf.upfronthosting.co.za> Changes by Neil Girdhar : Added file: http://bugs.python.org/file37788/starunpack4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 11:39:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 20 Jan 2015 10:39:16 +0000 Subject: [issue23282] Slightly faster set lookup Message-ID: <1421750356.2.0.166287277194.issue23282@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Currently set_lookkey() first tests entry->key == NULL, then entry->hash == hash and entry->key != dummy, and only after that entry->key == key. Proposed patch optimizes the order of comparisons. entry->key == key is tested first as for dicts. And no need to test entry->key != dummy after entry->hash == hash if entry->hash of dummy key is set to -1. Microbenchmark which demonstrates the best case (a lot of lookups of keys existing in the set). $ ./python -m timeit -s "a = list(range(10**6)); s1 = set(a); s2 = set(a)" -- "s1 <= s2" Unpatched: 10 loops, best of 3: 39.4 msec per loop Patched: 10 loops, best of 3: 35.3 msec per loop ---------- components: Interpreter Core files: set_faster_lookup.patch keywords: patch messages: 234367 nosy: pitrou, rhettinger, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Slightly faster set lookup type: performance versions: Python 3.5 Added file: http://bugs.python.org/file37789/set_faster_lookup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 11:48:39 2015 From: report at bugs.python.org (Chris Angelico) Date: Tue, 20 Jan 2015 10:48:39 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421750919.17.0.492962877799.issue2292@psf.upfronthosting.co.za> Chris Angelico added the comment: *facepalm* Of course I am. I don't know how I missed that in there, but maybe I was focusing too much on the abort that followed it to actually read the exception text. Duh. But with the latest version of the patch, I'm seeing something that I'm fairly sure *is* a different failure: gcc -pthread -c -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I. -IInclude -I./Include -DPy_BUILD_CORE -o Python/ast.o Python/ast.c Python/ast.c: In function ?ast_for_call?: Python/ast.c:2433:5: error: ?npositionals? undeclared (first use in this function) Python/ast.c:2433:5: note: each undeclared identifier is reported only once for each function it appears in make: *** [Python/ast.o] Error 1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 12:24:49 2015 From: report at bugs.python.org (eryksun) Date: Tue, 20 Jan 2015 11:24:49 +0000 Subject: [issue23276] hackcheck is broken in association with __setattr__ In-Reply-To: <1421706139.14.0.239687578391.issue23276@psf.upfronthosting.co.za> Message-ID: <1421753089.45.0.431058741944.issue23276@psf.upfronthosting.co.za> eryksun added the comment: > def __setattr__(cls, key, value): > super(type(QMediaPlaylist), cls).__setattr__(cls, key, value) > return > > The program segfaults when instantiating the Playlist class. I'd expect a TypeError because of the extra cls argument. It's already a bound method. FYI, the above finds the next metaclass after type(QMediaPlaylist) in PlaylistMeta.__mro__. It happens that type(QMediaPlaylist) inherits __setattr__ from the next in line (sip.wrappertype), so by a stroke of luck it 'works' (not really since this skips the incompatible sqlalchemy __setattr__). Consider making a playlist class that *has* a SQL table, not one that *is* a SQL table, i.e. use composition instead of inheritance. That sidesteps the incompatible metaclasses. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 12:27:58 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 20 Jan 2015 11:27:58 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421753278.82.0.753519071651.issue2292@psf.upfronthosting.co.za> Berker Peksag added the comment: > Python/ast.c:2433:5: error: ?npositionals? undeclared (first use in this function) Line 2425 should be int i, nargs, nkeywords, npositionals, ngens; ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 12:31:12 2015 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Tue, 20 Jan 2015 11:31:12 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421753472.87.0.90614181067.issue2292@psf.upfronthosting.co.za> Changes by Fred L. Drake, Jr. : ---------- nosy: -fdrake _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 12:38:05 2015 From: report at bugs.python.org (Mark Hammond) Date: Tue, 20 Jan 2015 11:38:05 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1421753885.43.0.814262317685.issue1602@psf.upfronthosting.co.za> Mark Hammond added the comment: > File redirection has nothing to do with win-unicode-console Thank you, that comment is spot on - there are multiple issues being conflated here. This bug is purely about the tty/console behaviour. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 12:54:57 2015 From: report at bugs.python.org (Neil Girdhar) Date: Tue, 20 Jan 2015 11:54:57 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421754897.75.0.498346864256.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Yup, that's it. So two problems down: It has yet to be updated to the most recent Python version It features a now redundant replacement for "yield from" which should be removed I'm working on: It also loses support for calling function with keyword arguments before positional arguments, which is an unnecessary backwards-incompatible change. I'm waiting on some feedback from python-ideas to make sure I know what should be allowed post PEP448. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 14:46:45 2015 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 20 Jan 2015 13:46:45 +0000 Subject: [issue23281] Access violation - pyc file In-Reply-To: <1421739329.05.0.520185996533.issue23281@psf.upfronthosting.co.za> Message-ID: <1421761605.77.0.860484866369.issue23281@psf.upfronthosting.co.za> Eric V. Smith added the comment: Was this file generated by CPython from a .py file? If so, can you share the .py file? If not, how was this file generated? As eryksun says, it appears to not be a valid .pyc file. ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 15:10:37 2015 From: report at bugs.python.org (=?utf-8?q?Pawe=C5=82_Zduniak?=) Date: Tue, 20 Jan 2015 14:10:37 +0000 Subject: [issue23281] Access violation - pyc file In-Reply-To: <1421739329.05.0.520185996533.issue23281@psf.upfronthosting.co.za> Message-ID: <1421763037.58.0.730916466692.issue23281@psf.upfronthosting.co.za> Pawe? Zduniak added the comment: This file is created by fuzzer ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 15:22:57 2015 From: report at bugs.python.org (Brett Cannon) Date: Tue, 20 Jan 2015 14:22:57 +0000 Subject: [issue23281] Access violation - pyc file In-Reply-To: <1421739329.05.0.520185996533.issue23281@psf.upfronthosting.co.za> Message-ID: <1421763777.76.0.496464139045.issue23281@psf.upfronthosting.co.za> Brett Cannon added the comment: If it was created by a fuzzer then this isn't a bug as we do no validation of bytecode formatting as we assume it was generated by Python and not an external, malicious source. ---------- nosy: +brett.cannon resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 15:25:53 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 20 Jan 2015 14:25:53 +0000 Subject: [issue23281] Access violation - pyc file In-Reply-To: <1421739329.05.0.520185996533.issue23281@psf.upfronthosting.co.za> Message-ID: <1421763953.75.0.465616426069.issue23281@psf.upfronthosting.co.za> STINNER Victor added the comment: > we assume it was generated by Python and not an external, malicious source. Said differently: you must not trust .py or .pyc downloaded from untrusted sources. Executing arbitary .py or .pyc file allows to execute arbitrary Python code. Instead of writing complex code to inject machine code in the Python evaluation loop (Python/ceval.c), just execute "import os; os.system('echo pwn!')" which runs an arbitrary shell command. Compile it to .pyc if you want to "exploit" the PYC path. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 17:28:03 2015 From: report at bugs.python.org (Joshua Landau) Date: Tue, 20 Jan 2015 16:28:03 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421771283.12.0.454502382309.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: The problem seems to be that with the removal of - else if (TYPE(ch) == STAR) { - vararg = ast_for_expr(c, CHILD(n, i+1)); - if (!vararg) - return NULL; - i++; - } - else if (TYPE(ch) == DOUBLESTAR) { - kwarg = ast_for_expr(c, CHILD(n, i+1)); - if (!kwarg) - return NULL; - i++; - } the code will ignore any subnodes that aren't of type "argument". However, the grammar still says arglist: (argument ',')* (argument [','] | '*' test [',' '**' test] | '**' test) so this is incorrect. Here's an example of what you might get inner( "a", argument comma *"bcd", star test comma "e", argument comma f=6, argument comma **{"g": 7}, doublestar test comma h=8, argument comma **{"i":9} doublestar test ) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 17:38:53 2015 From: report at bugs.python.org (Neil Girdhar) Date: Tue, 20 Jan 2015 16:38:53 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421771933.88.0.160430890506.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Yes, thank you! That explained it. I am almost done fixing this patch. Here's my progress so far if you want to try it out. Just one test left to fix. ---------- Added file: http://bugs.python.org/file37790/starunpack5.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 18:10:56 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 20 Jan 2015 17:10:56 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1421773856.25.0.880996591807.issue3566@psf.upfronthosting.co.za> Demian Brecht added the comment: TL;DR: Because HTTP is an application-level protocol, it's nearly impossible to gauge how a server will behave given a set of conditions. Because of that, any time that assumptions can be avoided, they should be. @R. David Murray: > That is, if the connection has been closed, I think an operation attempted on the connection should raise an exception that makes it clear that the connection is closed (in the case of some stdlib modules, that may be a socket level exception for the operation on the closed socket). In the typical case, this is exactly what happens. This issue is around a race condition that can occur between the client issuing a request prior to terminating the connection with the server, but the server terminating it prior to processing the request. In these cases, the client is left in a state where as far as it's concerned, it's in a valid state waiting for a response which the server will not issue as it has closed the socket on its side. In this case, the client reading an empty string from the receive buffer implies a closed socket. Unfortunately, it's not entirely uncommon when using persistent connections, as Martin's examples demonstrate. > I think the remote server writing a blank line to the socket is a very different thing from the remote server closing the connection without writing anything, so I may be misunderstanding something here. +1. What Martin is arguing here (Martin, please correct me if I'm wrong) is that a decently behaved server should not, at /any/ time write a blank line to (or effectively no-op) the socket, other than in the case where the socket connection has been closed. While I agree in the typical case, a blend of Postel and Murphy's laws leads me to believe it would be better to expect, accept and handle the unexpected. @Martin: Here's a concrete example of the unexpected behaviour. It's not specific to persistent connections and would be caught by the proposed "first request" solution, but ultimately, similar behaviour may be seen at any time from other servers/sources: http://stackoverflow.com/questions/22813645/options-http-methods-gives-an-empty-response-on-heroku. Googling for "http empty response" and similar search strings should also provide a number of examples where unexpected behaviour is encountered and in which case raising an explicit "ConnectionClosed" error would add to the confusion. Other examples are really hypotheticals and I don't think it's worth digging into them too deeply here. Unexpected behaviour (regardless of whether it's on the first or Nth request) should be captured well enough by now. > Eventually the server _would_ probably drop the connection (so ConnectionClosed would not be misleading) Sure, but you're raising an exception based on future /expected/ behaviour. That's my issue with the proposed solution in general. ConnectionClosed assumes specific behaviour, where literally /anything/ can happen server side. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 18:34:25 2015 From: report at bugs.python.org (Neil Girdhar) Date: Tue, 20 Jan 2015 17:34:25 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421775265.95.0.30472646459.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: All tests pass for me! Would anyone be kind enough to do a code review? ---------- Added file: http://bugs.python.org/file37791/starunpack6.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 18:59:51 2015 From: report at bugs.python.org (Neil Girdhar) Date: Tue, 20 Jan 2015 17:59:51 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421776791.52.0.786078535855.issue2292@psf.upfronthosting.co.za> Changes by Neil Girdhar : Added file: http://bugs.python.org/file37792/starunpack6.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 19:10:21 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 20 Jan 2015 18:10:21 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1421777421.44.0.336241050337.issue3566@psf.upfronthosting.co.za> Demian Brecht added the comment: Now I think I'd like to take my foot out of my mouth. Previous quick experiments that I had done were at the socket level, circumventing some of the logic in the HTTPResponse, mainly the calls to readline() rather than simple socket.recv(). I've confirmed that the /only/ way that the HTTPConnection object can possibly get a 0-length read is, in fact, if the remote host has closed the connection. In light of that, I have no objection at all to the suggested addition of ConnectionClosed exception and my apologies for the added confusion and dragging this issue on much longer than it should have been. I've also attached my proof of concept code for posterity. ---------- Added file: http://bugs.python.org/file37793/zero_response_poc.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 20:03:10 2015 From: report at bugs.python.org (Markus) Date: Tue, 20 Jan 2015 19:03:10 +0000 Subject: [issue23266] Faster implementation to collapse non-consecutive ip-addresses In-Reply-To: <1421584354.17.0.398119389429.issue23266@psf.upfronthosting.co.za> Message-ID: <1421780590.7.0.770117808651.issue23266@psf.upfronthosting.co.za> Markus added the comment: My initial patch was wrong wrt. _find_address_range. It did not loop over equal addresses. Thats why performance with many equal addresses was degraded when dropping the set(). Here is a patch to fix _find_address_range, drop the set, and improve performance again. python3 -m timeit -s "import bipaddress; ips = [bipaddress.ip_address('2001:db8::1000') for i in range(1000)]" -- "bipaddress.collapse_addresses(ips)" 1000 loops, best of 3: 1.76 msec per loop python3 -m timeit -s "import aipaddress; ips = [aipaddress.ip_address('2001:db8::1000') for i in range(1000)]" -- "aipaddress.collapse_addresses(ips)" 1000 loops, best of 3: 1.32 msec per loop ---------- Added file: http://bugs.python.org/file37794/ipaddress_faster_collapse4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 20:15:22 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 20 Jan 2015 19:15:22 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1421781322.83.0.000375171830065.issue3566@psf.upfronthosting.co.za> Demian Brecht added the comment: (Admittedly, I may also have been doing something entirely invalid in previous experiments as well) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 20:20:09 2015 From: report at bugs.python.org (Joshua Landau) Date: Tue, 20 Jan 2015 19:20:09 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421781609.3.0.725185472005.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: This causes a segmentation fault if any keyword arguments come after a **-unpack. Minimal demo: f(**x, x=x) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 20:31:42 2015 From: report at bugs.python.org (Joshua Landau) Date: Tue, 20 Jan 2015 19:31:42 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421782302.2.0.52526861753.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: Just change if (!PyUnicode_Compare(tmp, key)) { when iterating over prior keyword arguments to if (tmp && !PyUnicode_Compare(tmp, key)) { since tmp (the argument's name) can now be NULL. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 20:40:36 2015 From: report at bugs.python.org (Joshua Landau) Date: Tue, 20 Jan 2015 19:40:36 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421782836.2.0.275481741861.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: I take it back; that just causes >>> f(**{}, c=2) XXX lineno: 1, opcode: 105 Traceback (most recent call last): File "", line 1, in SystemError: unknown opcode ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 21:12:40 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 20 Jan 2015 20:12:40 +0000 Subject: [issue23280] Convert binascii.{un}hexlify to Argument Clinic (fix docstrings) In-Reply-To: <1421734051.68.0.00270883538381.issue23280@psf.upfronthosting.co.za> Message-ID: <20150120201215.93177.96706@psf.io> Roundup Robot added the comment: New changeset 1cb2b46c5109 by Zachary Ware in branch '3.4': Issue #23280: Fix docstrings for binascii.(un)hexlify https://hg.python.org/cpython/rev/1cb2b46c5109 New changeset 754c630c98a3 by Zachary Ware in branch 'default': Merge with 3.4 (closes #23280) https://hg.python.org/cpython/rev/754c630c98a3 ---------- nosy: +python-dev resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 21:14:44 2015 From: report at bugs.python.org (Zachary Ware) Date: Tue, 20 Jan 2015 20:14:44 +0000 Subject: [issue23280] Convert binascii.{un}hexlify to Argument Clinic (fix docstrings) In-Reply-To: <1421734051.68.0.00270883538381.issue23280@psf.upfronthosting.co.za> Message-ID: <1421784884.78.0.00562336547728.issue23280@psf.upfronthosting.co.za> Zachary Ware added the comment: Thanks for the (very quick!) review, Serhiy. ---------- assignee: -> zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 21:22:47 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 20 Jan 2015 20:22:47 +0000 Subject: [issue23266] Faster implementation to collapse non-consecutive ip-addresses In-Reply-To: <1421584354.17.0.398119389429.issue23266@psf.upfronthosting.co.za> Message-ID: <1421785367.7.0.0040647429417.issue23266@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Only one duplicated address is degenerated case. When there is a lot of duplicated addresses in range the patch causes regression. $ ./python -m timeit -s "import ipaddress; ips = [ipaddress.ip_address('2001:db8::%x' % (i%100)) for i in range(100000)]" -- "ipaddress.collapse_addresses(ips)" Unpatched: 10 loops, best of 3: 369 msec per loop Patched: 10 loops, best of 3: 1.04 sec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 21:26:45 2015 From: report at bugs.python.org (Alfred Krohmer) Date: Tue, 20 Jan 2015 20:26:45 +0000 Subject: [issue23276] hackcheck is broken in association with __setattr__ In-Reply-To: <1421706139.14.0.239687578391.issue23276@psf.upfronthosting.co.za> Message-ID: <1421785605.6.0.132050401564.issue23276@psf.upfronthosting.co.za> Alfred Krohmer added the comment: > I'd expect a TypeError because of the extra cls argument. It's already a bound method. Sorry, that was a typo. > Consider making a playlist class that *has* a SQL table, not one that *is* a SQL table, i.e. use composition instead of inheritance. That sidesteps the incompatible metaclasses. That would be indeed a solution, but not for the original problem. I think I have an example now that makes my point clear. The following code works as it should: import traceback import sys class MyMeta(type): def __setattr__(cls, key, value): print("OK") class MyClass(metaclass=MyMeta): pass MyClass.abc = 12 # outputs "OK" try: print(MyClass.abc) except: traceback.print_exc(file=sys.stdout) # exception comes here as expected type.__setattr__(MyClass, 'test', 42) # outputs nothing print(MyClass.test) # outputs "42" If I get this right, this should be **valid code** (and it should **not** be a bug, that this actually works). However, above define MyMeta like following: from PyQt5.QtMultimedia import QMediaPlaylist class MyMeta(type(QMediaPlaylist)): def __setattr__(cls, key, value): print("OK") And you get: TypeError: can't apply this __setattr__ to PyQt5.QtCore.pyqtWrapperType object I think that this actually **is** unexpected behaviour. I'm **not** trying to apply __setattr__ to PyQt5.QtCore.pyqtWrapperType but to MyClass! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 21:30:22 2015 From: report at bugs.python.org (Zachary Ware) Date: Tue, 20 Jan 2015 20:30:22 +0000 Subject: [issue23283] Backport Tools/clinic to 3.4 Message-ID: <1421785822.4.0.222715524471.issue23283@psf.upfronthosting.co.za> New submission from Zachary Ware: Larry, in #22120 msg224817, you said: "Since IIUC there's no code in 3.4 that uses an unsigned integer return converter, I'm not backporting the fix." Modules/binascii.c does have one use of an unsigned integer return, resulting in the only not-something-new difference between 3.4 and 3.5's Modules/clinic dir. Is there any reason not to do a quick "hg revert -Cr default Tools/clinic && make clinic && hg commit" on 3.4 to update binascii.c.h? ---------- messages: 234391 nosy: larry, zach.ware priority: normal severity: normal status: open title: Backport Tools/clinic to 3.4 versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 21:42:46 2015 From: report at bugs.python.org (fhahn) Date: Tue, 20 Jan 2015 20:42:46 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421786566.65.0.858742439837.issue2292@psf.upfronthosting.co.za> Changes by fhahn : ---------- nosy: -fhahn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 21:47:40 2015 From: report at bugs.python.org (Nelson Minar) Date: Tue, 20 Jan 2015 20:47:40 +0000 Subject: [issue23278] multiprocessing maxtasksperchild=1 + logging = task loss In-Reply-To: <1421719372.42.0.719053884187.issue23278@psf.upfronthosting.co.za> Message-ID: <1421786860.57.0.480358763608.issue23278@psf.upfronthosting.co.za> Nelson Minar added the comment: Doing some more testing, I noticed that if I ask multiprocessing to also log, the problem stops occurring. If I configure multiprocessing.log_to_stderr() instead, the error still occurs. Here's how I configured multiprocessing logging that makes the problem go away. This goes right at the top of the main() function. mp_logger = multiprocessing.get_logger() mp_logger.propagate=True mp_logger.setLevel(logging.DEBUG) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 22:03:03 2015 From: report at bugs.python.org (Neil Girdhar) Date: Tue, 20 Jan 2015 21:03:03 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421787783.35.0.910450103749.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Thanks. It's probably compile.c under "/* Same dance again for keyword arguments */". nseen remains zero and probably shouldn't. I need to learn more about the opcodes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 22:27:50 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 20 Jan 2015 21:27:50 +0000 Subject: [issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture In-Reply-To: <1419122866.29.0.725788641938.issue23095@psf.upfronthosting.co.za> Message-ID: <1421789270.37.0.304978166834.issue23095@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: asyncio: race condition when cancelling a _WaitHandleFuture -> [Windows] asyncio: race condition when cancelling a _WaitHandleFuture _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 22:39:48 2015 From: report at bugs.python.org (Joshua Landau) Date: Tue, 20 Jan 2015 21:39:48 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421789988.11.0.178034955776.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: I think I've got it working; I'm just working out how to make a patch and adding a test or two. I think I'll also need to sign the contributor agreement. While I'm at it, here are a few other deviations from the PEP: - {*()} and {**{}} aren't supported - [*[0] for i in [0]] gives a SystemError - "return *(1, 2, 3)," fails whilst "*(1, 2, 3)," succeeds ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 22:40:40 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 20 Jan 2015 21:40:40 +0000 Subject: [issue23208] asyncio: add BaseEventLoop._current_handle In-Reply-To: <1420817695.78.0.447471935777.issue23208@psf.upfronthosting.co.za> Message-ID: <1421790039.99.0.211844557479.issue23208@psf.upfronthosting.co.za> STINNER Victor added the comment: @Guido, @Yury: What do you think of this feature? Does it make sense to expose (internally) the "handle currently executed"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 22:51:34 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 20 Jan 2015 21:51:34 +0000 Subject: [issue23208] asyncio: add BaseEventLoop._current_handle In-Reply-To: <1420817695.78.0.447471935777.issue23208@psf.upfronthosting.co.za> Message-ID: <1421790694.32.0.0727122076606.issue23208@psf.upfronthosting.co.za> Yury Selivanov added the comment: > What do you think of this feature? Does it make sense to expose (internally) the "handle currently executed"? I think it's OK to have something like `loop._current_handle` to work ~only~ in debug mode. Enhancing `loop.call_exception_handler` to use it also makes sense. I would also want to make sure, that this property exists only in debug mode and shouldn't be used outside of asyncio. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 23:16:26 2015 From: report at bugs.python.org (Joshua Landau) Date: Tue, 20 Jan 2015 22:16:26 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421792186.29.0.550447025347.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: This was a rather minor fix; I basically moved from STORE_SUBSCR to STORE_MAP and fixed a BUILD_MAP opcode. ---------- Added file: http://bugs.python.org/file37795/starunpack7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 23:20:22 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 20 Jan 2015 22:20:22 +0000 Subject: [issue23199] libpython27.a in amd64 release is 32-bit In-Reply-To: <1420764337.42.0.255694319213.issue23199@psf.upfronthosting.co.za> Message-ID: <1421792422.88.0.38713799981.issue23199@psf.upfronthosting.co.za> Steve Dower added the comment: Just came across this advice on https://github.com/cython/cython/wiki/64BitCythonExtensionsOnWindows: > Do not use MinGW-w64. As you will notice, the MinGW import library for > Python (e.g. libpython27.a) is omitted from the AMD64 version of > Python. This is deliberate. Do not try to make one using dlltool. > There is no official MinGW-w64 release yet, it is still in "beta" and > considered unstable, although you can get a 64-bit build from e.g. > TDM-GCC. There have also been issues with the mingw runtime > conflicting with the MSVC runtime; this can happen from places you > don't expect, such as inside runtime libraries for g++ or gfortran. To > stay on the safe side, avoid MinGW-w64 for now. How accurate is this? Would we be better to omit the mingw libraries from the installer and instead provide the commands (or even a shell script?) to generate it with whatever toolset you're currently using? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 23:42:05 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 20 Jan 2015 22:42:05 +0000 Subject: [issue23208] asyncio: add BaseEventLoop._current_handle (only used in debug mode) In-Reply-To: <1420817695.78.0.447471935777.issue23208@psf.upfronthosting.co.za> Message-ID: <1421793725.34.0.112587618555.issue23208@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: asyncio: add BaseEventLoop._current_handle -> asyncio: add BaseEventLoop._current_handle (only used in debug mode) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 23:51:23 2015 From: report at bugs.python.org (Poor Yorick) Date: Tue, 20 Jan 2015 22:51:23 +0000 Subject: [issue23284] curses, readline, tinfo, and also --prefix, dbm, CPPFLAGS Message-ID: <1421794283.67.0.365311015753.issue23284@psf.upfronthosting.co.za> New submission from Poor Yorick: Building Python-2.7.9 using --prefix, with an ncurses that's linked to libtinfo and a readline that isn't linked to any termcap library, I ran into the trouble that the curses module wan't buing build with the needed -L and -l flags for the libtinfo shared object. I dug into setup.py, and ended up overhauling the readline, curses, and also dbm handling (more on that in another ticket). I also made changes to allow setup.py to pick up options like -isystem from $CPPFLAGS, replacing in the process the "optparse" module with the "argparse" module. Since argparse requires collections.OrderedDict, which isn't yet built at this stage, I added Lib_boot/argparse_boot.py, which uses the pure-Python OrderedDict from https://pypi.python.org/pypi/ordereddict and had setup.py use "argparse_boot" module instead. The build also ran into trouble with system directories that setup.py explicitly adds to inc_dirs and lib_dirs ahead of those of the alternate prefix. The attached files fixed all these issues in my scenario, allowing a succesful build and install of Python-2.7.9. ---------- components: Build hgrepos: 290 messages: 234399 nosy: pooryorick priority: normal severity: normal status: open title: curses, readline, tinfo, and also --prefix, dbm, CPPFLAGS versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 23:53:09 2015 From: report at bugs.python.org (Poor Yorick) Date: Tue, 20 Jan 2015 22:53:09 +0000 Subject: [issue23284] curses, readline, tinfo, and also --prefix, dbm, CPPFLAGS In-Reply-To: <1421794283.67.0.365311015753.issue23284@psf.upfronthosting.co.za> Message-ID: <1421794389.91.0.448943426038.issue23284@psf.upfronthosting.co.za> Changes by Poor Yorick : ---------- hgrepos: -290 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 23:53:48 2015 From: report at bugs.python.org (Poor Yorick) Date: Tue, 20 Jan 2015 22:53:48 +0000 Subject: [issue23284] curses, readline, tinfo, and also --prefix, dbm, CPPFLAGS In-Reply-To: <1421794283.67.0.365311015753.issue23284@psf.upfronthosting.co.za> Message-ID: <1421794428.96.0.172081787529.issue23284@psf.upfronthosting.co.za> Changes by Poor Yorick : ---------- hgrepos: +291 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 23:53:57 2015 From: report at bugs.python.org (Poor Yorick) Date: Tue, 20 Jan 2015 22:53:57 +0000 Subject: [issue23284] curses, readline, tinfo, and also --prefix, dbm, CPPFLAGS In-Reply-To: <1421794283.67.0.365311015753.issue23284@psf.upfronthosting.co.za> Message-ID: <1421794437.89.0.168878562567.issue23284@psf.upfronthosting.co.za> Changes by Poor Yorick : ---------- hgrepos: -291 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 23:54:16 2015 From: report at bugs.python.org (Poor Yorick) Date: Tue, 20 Jan 2015 22:54:16 +0000 Subject: [issue23284] curses, readline, tinfo, and also --prefix, dbm, CPPFLAGS In-Reply-To: <1421794283.67.0.365311015753.issue23284@psf.upfronthosting.co.za> Message-ID: <1421794456.94.0.949615780621.issue23284@psf.upfronthosting.co.za> Changes by Poor Yorick : ---------- hgrepos: +292 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 20 23:55:06 2015 From: report at bugs.python.org (Poor Yorick) Date: Tue, 20 Jan 2015 22:55:06 +0000 Subject: [issue23284] curses, readline, tinfo, and also --prefix, dbm, CPPFLAGS In-Reply-To: <1421794283.67.0.365311015753.issue23284@psf.upfronthosting.co.za> Message-ID: <1421794506.18.0.884241415412.issue23284@psf.upfronthosting.co.za> Changes by Poor Yorick : ---------- keywords: +patch Added file: http://bugs.python.org/file37796/34d54cc5ecfd.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 00:03:28 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 20 Jan 2015 23:03:28 +0000 Subject: [issue23285] PEP 475 - EINTR hanndling Message-ID: <1421795008.21.0.948909551681.issue23285@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- components: Library (Lib) hgrepos: 293 nosy: haypo, neologix, pitrou priority: normal severity: normal status: open title: PEP 475 - EINTR hanndling type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 00:04:33 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 20 Jan 2015 23:04:33 +0000 Subject: [issue23285] PEP 475 - EINTR hanndling Message-ID: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za> New submission from Charles-Fran?ois Natali: The test runs fine on Linux, but hangs in test_send() on OS-X and *BSD. I don't know what's wrong, so if someone with access to one of these OS could have a look, it would be great. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 00:05:45 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 20 Jan 2015 23:05:45 +0000 Subject: [issue23285] PEP 475 - EINTR hanndling In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za> Message-ID: <1421795145.46.0.599924091368.issue23285@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- keywords: +patch Added file: http://bugs.python.org/file37797/ff1274594739.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 00:09:17 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 20 Jan 2015 23:09:17 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za> Message-ID: <1421795357.7.0.635963515482.issue23285@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- title: PEP 475 - EINTR hanndling -> PEP 475 - EINTR handling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 00:09:22 2015 From: report at bugs.python.org (aruseni) Date: Tue, 20 Jan 2015 23:09:22 +0000 Subject: [issue23286] A typo in the tutorial Message-ID: <1421795362.32.0.373442891805.issue23286@psf.upfronthosting.co.za> New submission from aruseni: https://docs.python.org/3/tutorial/introduction.html > Lists also supports operations like concatenation ---------- assignee: docs at python components: Documentation messages: 234401 nosy: aruseni, docs at python priority: normal severity: normal status: open title: A typo in the tutorial _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 00:14:05 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 20 Jan 2015 23:14:05 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za> Message-ID: <1421795645.05.0.890962351895.issue23285@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Perhaps Ned can help on the OS X side of things. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 00:15:08 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 20 Jan 2015 23:15:08 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za> Message-ID: <1421795708.31.0.995402066549.issue23285@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The review diff is weird: it seems it contains changes that aren't EINTR-related (see e.g. argparse.rst). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 00:16:10 2015 From: report at bugs.python.org (Neil Girdhar) Date: Tue, 20 Jan 2015 23:16:10 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421795770.35.0.307497563333.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Post it? It's just "hg diff > a.diff" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 00:19:24 2015 From: report at bugs.python.org (Neil Girdhar) Date: Tue, 20 Jan 2015 23:19:24 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421795964.82.0.266014474278.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: I think there will still be a problem ceval with the way the dicts are combined unfortunately, but that should be easy to fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 00:20:50 2015 From: report at bugs.python.org (Joshua Landau) Date: Tue, 20 Jan 2015 23:20:50 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421796050.68.0.26292087082.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: Aye, I'd done so (see starunpack7.diff). It was the fuss to reapply it ontop of your newer diff and making sure I'd read at least *some* of the devguide before barging on. Anyhow, here's another small fix to deal with the [*[0] for i in [0]] problem. I'm not nearly confident I can touch the grammar, though, so the other problems are out of my reach. ---------- Added file: http://bugs.python.org/file37798/starunpack8.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 00:38:50 2015 From: report at bugs.python.org (Zach Welch) Date: Tue, 20 Jan 2015 23:38:50 +0000 Subject: [issue23199] libpython27.a in amd64 release is 32-bit In-Reply-To: <1420764337.42.0.255694319213.issue23199@psf.upfronthosting.co.za> Message-ID: <1421797130.26.0.795700230332.issue23199@psf.upfronthosting.co.za> Zach Welch added the comment: That's certainly an interesting data point. We are just beginning to use MinGW-w64 internally, so I do not have enough experience to confirm or deny that advice. For various reasons, we must use cross-compiling on a Linux host, so the advice to use a native compiler is moot for our situation. Certainly, documenting the absense of the 64-bit library would be good. Providing a documented script to generate one is better. Providing the library would be ideal, if there will not be forward compatibility or runtime issues. It would be nice to see concrete details about the current state of affairs. The cython project's warning would carry more weight with me if it contained links to specific details: mailing list discussion that led to the "deliberate" decision to omit the 64-bit library, bug reports filed against the mingw-w64 project about the "runtime issues", etc.. That said, such details probably do exist, but my cursory searching has failed to turn them up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 00:41:00 2015 From: report at bugs.python.org (Neil Girdhar) Date: Tue, 20 Jan 2015 23:41:00 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421797260.46.0.549401805709.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Thanks! I've incorporated your changes to deal with the [*[0] for i in [0]] problem, although I don't understand them yet. The problem with using STORE_MAP is you create a new dict for each keyword argument in that situation. I optimized that away. Good catch on the BUILD_MAP opcode problem. I could not figure out why that wasn't working! I added some tests. Did you say you had some tests? One of the tests that both of our code is failing on still is: >>> def f(x, y): ... print(x, y) ... >>> f(x=5, **{'x': 1}, **{'x': 3}, y=2) It's just a problem in ceval that I'll work on now. ---------- Added file: http://bugs.python.org/file37799/starunpack9.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 00:46:26 2015 From: report at bugs.python.org (Joshua Landau) Date: Tue, 20 Jan 2015 23:46:26 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421797586.04.0.338964591168.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: I'm getting >>> f(x=5, **{'x': 1}, **{'x': 3}, y=2) Traceback (most recent call last): File "", line 1, in TypeError: f() got multiple values for keyword argument 'x' Which, as I understand, is the correct result. I'm using starunpack8.diff right now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 00:48:27 2015 From: report at bugs.python.org (Markus) Date: Tue, 20 Jan 2015 23:48:27 +0000 Subject: [issue23266] Faster implementation to collapse non-consecutive ip-addresses In-Reply-To: <1421584354.17.0.398119389429.issue23266@psf.upfronthosting.co.za> Message-ID: <1421797707.43.0.446694550251.issue23266@psf.upfronthosting.co.za> Markus added the comment: Eleminating duplicates before processing is faster once the overhead of the set operation is less than the time required to sort the larger dataset with duplicates. So we are basically comparing sort(data) to sort(set(data)). The optimum depends on the input data. python3 -m timeit -s "import random; import bipaddress; ips = [bipaddress.ip_address('2001:db8::') + i for i in range(100000)]; random.shuffle(ips)" -- "bipaddress.collapse_addresses(ips)" 10 loops, best of 3: 1.49 sec per loop vs. 10 loops, best of 3: 1.59 sec per loop If the data is pre-sorted, possible if you retrieve from database, things are drastically different: python3 -m timeit -s "import random; import bipaddress; ips = [bipaddress.ip_address('2001:db8::') + i for i in range(100000)]; " -- "bipaddress.collapse_addresses(ips)" 10 loops, best of 3: 136 msec per loop vs 10 loops, best of 3: 1.57 sec per loop So for my usecase, I basically have less than 0.1% duplicates (if at all), dropping the set would be better, but ... other usecases will exist. Still, it is easy to "emulate" the use of "sorted(set())" from a users perspective - just call collapse_addresses(set(data)) in case you expect to have duplicates and experience a speedup by inserting unique, possibly even sorted, data. On the other hand, if you have a huge load of 99.99% sorted non collapseable addresses, it is not possible to drop the set() operation in your sorted(set()) from a users perspective, no way to speed things up, and the slowdown you get is x10. That said, I'd drop the set(). Optimization depends on data input, dropping the set() allows the user to optimize base on the nature of his input data. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 00:51:42 2015 From: report at bugs.python.org (Neil Girdhar) Date: Tue, 20 Jan 2015 23:51:42 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421797902.22.0.226375167319.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Why is that correct? The PEP mentions overriding. Right now each dict overrides values from the last silently, which I think makes sense. The keyword arguments you pass in override keys from previous dicts (also good I think). The problem is that you can pass multiple duplicate keyword arguments, and the one below, which I think should succeed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 00:55:34 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 20 Jan 2015 23:55:34 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za> Message-ID: <1421798134.09.0.0227952980319.issue23285@psf.upfronthosting.co.za> Ned Deily added the comment: (It may be several days before I can spend much time on it but I will take a look.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 00:58:24 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 20 Jan 2015 23:58:24 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1421797902.22.0.226375167319.issue2292@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Let's tread careful here. In regular dicts, for better or for worse, {'x': 1, 'x': 2} is defined and returns {'x': 2}. But in keyword arg processing, duplicates are always rejected. This may be an area where we need to adjust the PEP to match that expectation. On Tue, Jan 20, 2015 at 3:51 PM, Neil Girdhar wrote: > > Neil Girdhar added the comment: > > Why is that correct? The PEP mentions overriding. Right now each dict > overrides values from the last silently, which I think makes sense. The > keyword arguments you pass in override keys from previous dicts (also good > I think). The problem is that you can pass multiple duplicate keyword > arguments, and the one below, which I think should succeed. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 01:08:02 2015 From: report at bugs.python.org (Neil Girdhar) Date: Wed, 21 Jan 2015 00:08:02 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421798882.84.0.170081116837.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: That makes sense. If you wanted to override, you could always write: f(**{**a, **b, 'x': 5}) rather than f(**a, **b, x=5) Should I go ahead and fix it so that overriding is always wrong? E.g., f(**{'x': 3}, **{'x': 4}) which currently works? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 01:10:42 2015 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 21 Jan 2015 00:10:42 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1421798882.84.0.170081116837.issue2292@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: SGTM On Tue, Jan 20, 2015 at 4:08 PM, Neil Girdhar wrote: > > Neil Girdhar added the comment: > > That makes sense. > > If you wanted to override, you could always write: > > f(**{**a, **b, 'x': 5}) > > rather than > > f(**a, **b, x=5) > > Should I go ahead and fix it so that overriding is always wrong? E.g., > > f(**{'x': 3}, **{'x': 4}) > > which currently works? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 01:17:12 2015 From: report at bugs.python.org (Joshua Landau) Date: Wed, 21 Jan 2015 00:17:12 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421799432.62.0.758483278026.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: > The problem with using STORE_MAP is you create a new dict for each keyword argument in that situation. You don't; if you look at the disassembly for producing a built-in dict ("dis.dis('{1:2, 2:3, 3:4}')") you'll see they use STORE_MAP too. STORE_MAP seems to just be the map equivalent of LIST_APPEND. I've done simple timings that show my version being faster... Unfortunately, it points out there is definitely a memory leak. This reproduces: def f(a): pass while True: f(**{}, a=1) This goes for both patches 8 and 9. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 01:33:02 2015 From: report at bugs.python.org (John Beck) Date: Wed, 21 Jan 2015 00:33:02 +0000 Subject: [issue23287] ctypes.util.find_library needlessly call crle on Solaris Message-ID: <1421800382.95.0.158394542432.issue23287@psf.upfronthosting.co.za> New submission from John Beck: On Solaris, in Lib/ctypes/util.py, we have code that looks for /usr/bin/crle and calls it to parse its output to try to determine the Default Library Path. This code broke recently (Solaris 12 build 65), as it expects to find a line starting with "Default Library Path (ELF):" but the " (ELF)" part of that line was removed because it was no longer needed. So we need a change here regardless. But it turns out that calling crle is not needed at all because the default library path is a constant on Solaris: "/lib/64:/usr/lib/64" in 64-bit mode and "/lib:/usr/lib" in 32-bit mode. Thus I offer the attached patch for both 2.7 and 3.4. ---------- components: ctypes files: crle-fix.patch keywords: patch messages: 234417 nosy: jbeck priority: normal severity: normal status: open title: ctypes.util.find_library needlessly call crle on Solaris type: resource usage versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file37800/crle-fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 01:40:53 2015 From: report at bugs.python.org (Neil Girdhar) Date: Wed, 21 Jan 2015 00:40:53 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421800853.02.0.520146306396.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Could you try this and tell me how many BUILD_MAPs you're doing? dis.dis("def f(w, x, y, z, r): pass\nf(w=1, **{'x': 2}, y=3, z=4, r=5)") Mine does 2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 01:44:37 2015 From: report at bugs.python.org (Joshua Landau) Date: Wed, 21 Jan 2015 00:44:37 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421801077.89.0.495144621806.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: 2 here as well: 15 LOAD_CONST 2 ('w') 18 LOAD_CONST 3 (1) 21 BUILD_MAP 1 24 LOAD_CONST 4 (2) 27 LOAD_CONST 5 ('x') 30 STORE_MAP 31 BUILD_MAP 1 34 LOAD_CONST 6 (3) 37 LOAD_CONST 7 ('y') 40 STORE_MAP 41 LOAD_CONST 8 (4) 44 LOAD_CONST 9 ('z') 47 STORE_MAP 48 LOAD_CONST 10 (5) 51 LOAD_CONST 11 ('r') 54 STORE_MAP 55 BUILD_MAP_UNPACK 2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 01:47:48 2015 From: report at bugs.python.org (Neil Girdhar) Date: Wed, 21 Jan 2015 00:47:48 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421801268.69.0.646819440146.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: If there is a speed issue, the real answer I think is to add an opcode as suggested in the source code that coalesces keyword arguments into dicts rather than "the weird dance" as the previous authors described it, or turning each argument into an individual dict and merging them at the end as you're doing? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 01:50:02 2015 From: report at bugs.python.org (Neil Girdhar) Date: Wed, 21 Jan 2015 00:50:02 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421801402.61.0.236477224911.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Ah, nice! I didn't realize what STORE_MAP did. I thought it created a map each time. We'll just do it your way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 02:26:45 2015 From: report at bugs.python.org (Neil Girdhar) Date: Wed, 21 Jan 2015 01:26:45 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421803605.01.0.06653997337.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Detecting overrides and raising TypeError. E.g., >>> def f(x, y): ... print(x, y) ... >>> f(x=5, **{'x': 3}, y=2) Traceback (most recent call last): ... TypeError: f() got multiple values for keyword argument 'x' ---------- Added file: http://bugs.python.org/file37801/starunpack10.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 03:03:30 2015 From: report at bugs.python.org (koobs) Date: Wed, 21 Jan 2015 02:03:30 +0000 Subject: [issue22947] Enable 'imageop' - "Multimedia Srvices Feature module" for 64-bit platform In-Reply-To: <1417004311.93.0.975050094816.issue22947@psf.upfronthosting.co.za> Message-ID: <1421805810.45.0.257116621263.issue22947@psf.upfronthosting.co.za> Changes by koobs : ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 05:24:47 2015 From: report at bugs.python.org (Larry Hastings) Date: Wed, 21 Jan 2015 04:24:47 +0000 Subject: [issue23283] Backport Tools/clinic to 3.4 In-Reply-To: <1421785822.4.0.222715524471.issue23283@psf.upfronthosting.co.za> Message-ID: <1421814287.5.0.739431621195.issue23283@psf.upfronthosting.co.za> Larry Hastings added the comment: I would prefer the backport be more selective. There are other changes (set literals, fix "--converters") in trunk that aren't in 3.4 and I wouldn't want them pulled in willy-nilly. However, I'd accept this backport if the patch looks minimal and clean. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 05:43:50 2015 From: report at bugs.python.org (YoSTEALTH) Date: Wed, 21 Jan 2015 04:43:50 +0000 Subject: [issue13299] namedtuple row factory for sqlite3 In-Reply-To: <1320021145.59.0.53370875256.issue13299@psf.upfronthosting.co.za> Message-ID: <1421815430.01.0.727518493422.issue13299@psf.upfronthosting.co.za> YoSTEALTH added the comment: note: sqlite_namedtuplerow.patch _cache method conflicts with attached database with say common table.column name like "id" Using namedtuple method over sqlite3.Row was a terrible idea for me. I thought namedtuple is like tuple so should be faster then dict! wrong. I wasted 2 days change my work to namedtuple and back to sqlite3.Row, the speed difference on my working project was: namedtuple 0.035s/result sqlite3.Rows 0.0019s/result for(speed test) range: 10000 namedtuple 17.3s sqlite3.Rows 0.4s My solution was to use sqlite3.Row (for speed) but to get named like usage by convert dict keys() with setattr names: class dict2named(dict): def __init__(self, *args, **kwargs): super(dict2named, self).__init__(*args, **kwargs) self.__dict__ = self Usage: for i in con.execute('SELECT * FROM table'): yield dict2named(i) Now i can use: print(i.title) and handy dict methods for dash column names: print(i['my-title']) print(i.get('my-title', 'boo')) Now working project speed: sqlite3.Rows 0.0020s/result for(speed test) range: 10000 sqlite3.Rows 0.8s with dict2named converting This i can work with, tiny compromise in speed with better usage. ---------- nosy: +YoSTEALTH _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 08:35:45 2015 From: report at bugs.python.org (koobs) Date: Wed, 21 Jan 2015 07:35:45 +0000 Subject: [issue17975] altinstall should not install libpython3.so (conflict between multiple $VERSIONs) In-Reply-To: <1368542639.2.0.817126483539.issue17975@psf.upfronthosting.co.za> Message-ID: <1421825745.84.0.64612577698.issue17975@psf.upfronthosting.co.za> Changes by koobs : ---------- title: libpython3.so conflicts between $VERSIONs -> altinstall should not install libpython3.so (conflict between multiple $VERSIONs) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 08:36:52 2015 From: report at bugs.python.org (koobs) Date: Wed, 21 Jan 2015 07:36:52 +0000 Subject: [issue17975] altinstall should not install libpython3.so (conflict between multiple $VERSIONs) In-Reply-To: <1368542639.2.0.817126483539.issue17975@psf.upfronthosting.co.za> Message-ID: <1421825812.46.0.273960137101.issue17975@psf.upfronthosting.co.za> koobs added the comment: Adding 3.2 so I (and other downstream packagers) don't forget to backport the fix. ---------- versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 09:15:01 2015 From: report at bugs.python.org (lilydjwg) Date: Wed, 21 Jan 2015 08:15:01 +0000 Subject: [issue5907] repr of time.struct_time type does not eval In-Reply-To: <1241281843.36.0.110450032545.issue5907@psf.upfronthosting.co.za> Message-ID: <1421828101.34.0.826396664112.issue5907@psf.upfronthosting.co.za> Changes by lilydjwg : ---------- nosy: +lilydjwg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 09:15:15 2015 From: report at bugs.python.org (lilydjwg) Date: Wed, 21 Jan 2015 08:15:15 +0000 Subject: [issue11698] Improve repr for structseq objects to show named, but unindexed fields In-Reply-To: <1301264097.04.0.982421975108.issue11698@psf.upfronthosting.co.za> Message-ID: <1421828115.74.0.361149768588.issue11698@psf.upfronthosting.co.za> Changes by lilydjwg : ---------- nosy: +lilydjwg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 09:43:15 2015 From: report at bugs.python.org (Michael Vogt) Date: Wed, 21 Jan 2015 08:43:15 +0000 Subject: [issue23193] Please support "numeric_owner" in tarfile In-Reply-To: <1420728144.57.0.872420723687.issue23193@psf.upfronthosting.co.za> Message-ID: <1421829795.32.0.275024075721.issue23193@psf.upfronthosting.co.za> Michael Vogt added the comment: Thanks everyone for the comments and feedback! Attached is a updated patch with tests and a documentation update. Feedback is very welcome. I decided to skip the test on systems where root is not uid,gid=0. I could also mock that of course if you prefer it this way. Thanks, Michael ---------- Added file: http://bugs.python.org/file37803/tarfile-numeric-owner-with-tests.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 11:02:03 2015 From: report at bugs.python.org (Mayank Tripathi) Date: Wed, 21 Jan 2015 10:02:03 +0000 Subject: [issue23286] A typo in the tutorial In-Reply-To: <1421795362.32.0.373442891805.issue23286@psf.upfronthosting.co.za> Message-ID: <1421834523.21.0.699211919485.issue23286@psf.upfronthosting.co.za> Changes by Mayank Tripathi : ---------- keywords: +patch Added file: http://bugs.python.org/file37804/intro_typo.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 11:37:56 2015 From: report at bugs.python.org (Mike Sampson) Date: Wed, 21 Jan 2015 10:37:56 +0000 Subject: [issue23288] subprocess.Popen close_fds behaviour differs between 3.2 and 3.4 Message-ID: <1421836676.03.0.70112175637.issue23288@psf.upfronthosting.co.za> New submission from Mike Sampson: I'm seeing differing behaviour with subprocess.Popen(..., close_fds = False) between 3.2 and 3.4. The docs don't say this is meant to be the case as far as I can see. Python 3.2.3 on Debian Wheezy ============================= >>> import subprocess >>> import os >>> r,w = os.pipe() >>> p = subprocess.Popen('ls /dev/fd/*', shell = True, close_fds = False) >>> ls: cannot access /dev/fd/5: No such file or directory /dev/fd/0 /dev/fd/1 /dev/fd/2 /dev/fd/3 /dev/fd/4 Python 3.4.2 on Arch Linux ========================== >>> import subprocess >>> import os >>> r,w = os.pipe() >>> p = subprocess.Popen('ls /dev/fd/*', shell = True, close_fds = False) >>> ls: cannot access /dev/fd/3: No such file or directory /dev/fd/0 /dev/fd/1 /dev/fd/2 In 3.4 even though close_fds is False the fds are closed in the child. Using pass_fds works around this though I would like to know if this is a bug, documentation issue, or am I missing something here? ---------- assignee: docs at python components: Documentation messages: 234428 nosy: docs at python, mfs priority: normal severity: normal status: open title: subprocess.Popen close_fds behaviour differs between 3.2 and 3.4 type: behavior versions: Python 3.2, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 11:39:19 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Jan 2015 10:39:19 +0000 Subject: [issue23288] subprocess.Popen close_fds behaviour differs between 3.2 and 3.4 In-Reply-To: <1421836676.03.0.70112175637.issue23288@psf.upfronthosting.co.za> Message-ID: <1421836759.56.0.797903681278.issue23288@psf.upfronthosting.co.za> STINNER Victor added the comment: File descriptors are not closed, but not inherited neither, in Python 3.4. See the PEP 446. To have a reliable behaviour on all platforms and all Python versions, just use the pass_fds parameter. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 11:40:22 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Jan 2015 10:40:22 +0000 Subject: [issue23288] subprocess.Popen close_fds behaviour differs between 3.2 and 3.4 In-Reply-To: <1421836676.03.0.70112175637.issue23288@psf.upfronthosting.co.za> Message-ID: <1421836822.57.0.181522372698.issue23288@psf.upfronthosting.co.za> STINNER Victor added the comment: https://docs.python.org/dev/library/os.html#os.pipe Changed in version 3.4: The new file descriptors are now non-inheritable. If you don't use the subprocess module, you may use os.set_inheritable(). https://docs.python.org/dev/library/os.html#os.set_inheritable ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 06:56:39 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 21 Jan 2015 05:56:39 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: <1421795708.31.0.995402066549.issue23285@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > The review diff is weird: it seems it contains changes that aren't EINTR-related (see e.g. argparse.rst). Here's a manually generated diff. ---------- Added file: http://bugs.python.org/file37802/eintr.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r fe0fddd6fd21 Lib/_pyio.py --- a/Lib/_pyio.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/_pyio.py Wed Jan 21 05:55:58 2015 +0000 @@ -1006,10 +1006,7 @@ current_size = 0 while True: # Read until EOF or until read() would block. - try: - chunk = self.raw.read() - except InterruptedError: - continue + chunk = self.raw.read() if chunk in empty_values: nodata_val = chunk break @@ -1028,10 +1025,7 @@ chunks = [buf[pos:]] wanted = max(self.buffer_size, n) while avail < n: - try: - chunk = self.raw.read(wanted) - except InterruptedError: - continue + chunk = self.raw.read(wanted) if chunk in empty_values: nodata_val = chunk break @@ -1060,12 +1054,7 @@ have = len(self._read_buf) - self._read_pos if have < want or have <= 0: to_read = self.buffer_size - have - while True: - try: - current = self.raw.read(to_read) - except InterruptedError: - continue - break + current = self.raw.read(to_read) if current: self._read_buf = self._read_buf[self._read_pos:] + current self._read_pos = 0 @@ -1214,8 +1203,6 @@ while self._write_buf: try: n = self.raw.write(self._write_buf) - except InterruptedError: - continue except BlockingIOError: raise RuntimeError("self.raw should implement RawIOBase: it " "should not raise BlockingIOError") diff -r fe0fddd6fd21 Lib/distutils/spawn.py --- a/Lib/distutils/spawn.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/distutils/spawn.py Wed Jan 21 05:55:58 2015 +0000 @@ -137,9 +137,6 @@ try: pid, status = os.waitpid(pid, 0) except OSError as exc: - import errno - if exc.errno == errno.EINTR: - continue if not DEBUG: cmd = executable raise DistutilsExecError( diff -r fe0fddd6fd21 Lib/multiprocessing/connection.py --- a/Lib/multiprocessing/connection.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/multiprocessing/connection.py Wed Jan 21 05:55:58 2015 +0000 @@ -365,10 +365,7 @@ def _send(self, buf, write=_write): remaining = len(buf) while True: - try: - n = write(self._handle, buf) - except InterruptedError: - continue + n = write(self._handle, buf) remaining -= n if remaining == 0: break @@ -379,10 +376,7 @@ handle = self._handle remaining = size while remaining > 0: - try: - chunk = read(handle, remaining) - except InterruptedError: - continue + chunk = read(handle, remaining) n = len(chunk) if n == 0: if remaining == size: @@ -595,13 +589,7 @@ self._unlink = None def accept(self): - while True: - try: - s, self._last_accepted = self._socket.accept() - except InterruptedError: - pass - else: - break + s, self._last_accepted = self._socket.accept() s.setblocking(True) return Connection(s.detach()) diff -r fe0fddd6fd21 Lib/multiprocessing/forkserver.py --- a/Lib/multiprocessing/forkserver.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/multiprocessing/forkserver.py Wed Jan 21 05:55:58 2015 +0000 @@ -188,8 +188,6 @@ finally: os._exit(code) - except InterruptedError: - pass except OSError as e: if e.errno != errno.ECONNABORTED: raise @@ -230,13 +228,7 @@ data = b'' length = UNSIGNED_STRUCT.size while len(data) < length: - while True: - try: - s = os.read(fd, length - len(data)) - except InterruptedError: - pass - else: - break + s = os.read(fd, length - len(data)) if not s: raise EOFError('unexpected EOF') data += s @@ -245,13 +237,7 @@ def write_unsigned(fd, n): msg = UNSIGNED_STRUCT.pack(n) while msg: - while True: - try: - nbytes = os.write(fd, msg) - except InterruptedError: - pass - else: - break + nbytes = os.write(fd, msg) if nbytes == 0: raise RuntimeError('should not get here') msg = msg[nbytes:] diff -r fe0fddd6fd21 Lib/multiprocessing/popen_fork.py --- a/Lib/multiprocessing/popen_fork.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/multiprocessing/popen_fork.py Wed Jan 21 05:55:58 2015 +0000 @@ -1,7 +1,6 @@ import os import sys import signal -import errno from . import util @@ -29,8 +28,6 @@ try: pid, sts = os.waitpid(self.pid, flag) except OSError as e: - if e.errno == errno.EINTR: - continue # Child process not yet created. See #1731717 # e.errno == errno.ECHILD == 10 return None diff -r fe0fddd6fd21 Lib/socket.py --- a/Lib/socket.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/socket.py Wed Jan 21 05:55:58 2015 +0000 @@ -572,8 +572,6 @@ except timeout: self._timeout_occurred = True raise - except InterruptedError: - continue except error as e: if e.args[0] in _blocking_errnos: return None diff -r fe0fddd6fd21 Lib/socketserver.py --- a/Lib/socketserver.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/socketserver.py Wed Jan 21 05:55:58 2015 +0000 @@ -553,8 +553,6 @@ try: pid, _ = os.waitpid(-1, 0) self.active_children.discard(pid) - except InterruptedError: - pass except ChildProcessError: # we don't have any children, we're done self.active_children.clear() diff -r fe0fddd6fd21 Lib/subprocess.py --- a/Lib/subprocess.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/subprocess.py Wed Jan 21 05:55:58 2015 +0000 @@ -489,14 +489,6 @@ DEVNULL = -3 -def _eintr_retry_call(func, *args): - while True: - try: - return func(*args) - except InterruptedError: - continue - - # XXX This function is only used by multiprocessing and the test suite, # but it's here so that it can be imported when Python is compiled without # threads. @@ -963,10 +955,10 @@ if self.stdin: self._stdin_write(input) elif self.stdout: - stdout = _eintr_retry_call(self.stdout.read) + stdout = self.stdout.read() self.stdout.close() elif self.stderr: - stderr = _eintr_retry_call(self.stderr.read) + stderr = self.stderr.read() self.stderr.close() self.wait() else: @@ -1410,7 +1402,7 @@ # exception (limited in size) errpipe_data = bytearray() while True: - part = _eintr_retry_call(os.read, errpipe_read, 50000) + part = os.read(errpipe_read, 50000) errpipe_data += part if not part or len(errpipe_data) > 50000: break @@ -1420,7 +1412,7 @@ if errpipe_data: try: - _eintr_retry_call(os.waitpid, self.pid, 0) + os.waitpid(self.pid, 0) except ChildProcessError: pass try: @@ -1505,7 +1497,7 @@ def _try_wait(self, wait_flags): """All callers to this function MUST hold self._waitpid_lock.""" try: - (pid, sts) = _eintr_retry_call(os.waitpid, self.pid, wait_flags) + (pid, sts) = os.waitpid(self.pid, wait_flags) except ChildProcessError: # This happens if SIGCLD is set to be ignored or waiting # for child processes has otherwise been disabled for our diff -r fe0fddd6fd21 Lib/test/eintrdata/eintr_tester.py --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Lib/test/eintrdata/eintr_tester.py Wed Jan 21 05:55:58 2015 +0000 @@ -0,0 +1,232 @@ +""" +This test suite exercises some system calls subject to interruption with EINTR, +to check that it is actually handled transparently. +It is intended to be run by the main test suite within a child process, to +ensure there is no background thread running (so that signals are delivered to +the correct thread). +Signals are generated in-process using setitimer(ITIMER_REAL), which allows +sub-second periodicity (contrarily to signal()). +""" + +import io +import os +import signal +import socket +import time +import unittest + +from test import support + + + at unittest.skipUnless(hasattr(signal, "setitimer"), "requires setitimer()") +class EINTRBaseTest(unittest.TestCase): + """ Base class for EINTR tests. """ + + # delay for initial singal delivery + signal_delay = 0.1 + # signal delivery periodicity + signal_period = 0.2 + # default sleep time for tests - should obviously have: + #??sleep_time > signal_period + sleep_time = 0.5 + + @classmethod + def setUpClass(cls): + cls.orig_handler = signal.signal(signal.SIGALRM, lambda *args: None) + signal.setitimer(signal.ITIMER_REAL, cls.signal_delay, + cls.signal_period) + + @classmethod + def tearDownClass(cls): + signal.setitimer(signal.ITIMER_REAL, cls.signal_delay, 0) + signal.signal(signal.SIGALRM, cls.orig_handler) + + @classmethod + def _sleep(cls): + # default sleep time + time.sleep(cls.sleep_time) + + + at unittest.skipUnless(hasattr(signal, "setitimer"), "requires setitimer()") +class OSEINTRTest(EINTRBaseTest): + """ EINTR tests for the os module. """ + + def _test_wait_multiple(self, wait_func): + for _ in range(3): + pid = os.fork() + if pid == 0: + self._sleep() + os._exit(0) + wait_func() + + def test_wait(self): + self._test_wait_multiple(os.wait) + + @unittest.skipUnless(hasattr(os, 'wait3'), 'requires wait3()') + def test_wait3(self): + self._test_wait_multiple(lambda: os.wait3(0)) + + def _test_wait_single(self, wait_func): + pid = os.fork() + if pid == 0: + self._sleep() + os._exit(0) + else: + wait_func(pid) + + def test_waitpid(self): + self._test_wait_single(lambda pid: os.waitpid(pid, 0)) + + @unittest.skipUnless(hasattr(os, 'wait4'), 'requires wait4()') + def test_wait4(self): + self._test_wait_single(lambda pid: os.wait4(pid, 0)) + + def test_read(self): + rd, wr = os.pipe() + self.addCleanup(os.close, rd) + # wr closed explicitly by parent + + # the payload below are smaller than PIPE_BUF, hence the writes will be + # atomic + datas = [b"hello", b"world", b"spam"] + + pid = os.fork() + if pid == 0: + os.close(rd) + for data in datas: + # let the parent block on read() + self._sleep() + os.write(wr, data) + os._exit(0) + else: + self.addCleanup(os.waitpid, pid, 0) + os.close(wr) + for data in datas: + self.assertEqual(data, os.read(rd, len(data))) + + def test_write(self): + rd, wr = os.pipe() + self.addCleanup(os.close, wr) + # rd closed explicitly by parent + + # we must write enough data for the write() to block + data = b"xyz" * support.PIPE_MAX_SIZE + + pid = os.fork() + if pid == 0: + os.close(wr) + read_data = io.BytesIO() + # let the parent block on write() + self._sleep() + while len(read_data.getvalue()) < len(data): + chunk = os.read(rd, 2 * len(data)) + read_data.write(chunk) + self.assertEqual(read_data.getvalue(), data) + os._exit(0) + else: + os.close(rd) + written = 0 + while written < len(data): + written += os.write(wr, memoryview(data)[written:]) + self.assertEqual(0, os.waitpid(pid, 0)[1]) + + + at unittest.skipUnless(hasattr(signal, "setitimer"), "requires setitimer()") +class SocketEINTRTest(EINTRBaseTest): + """ EINTR tests for the socket module. """ + + @unittest.skipUnless(hasattr(socket, 'socketpair'), 'needs socketpair()') + def _test_recv(self, recv_func): + rd, wr = socket.socketpair() + self.addCleanup(rd.close) + # wr closed explicitly by parent + + # single-byte payload guard us against partial recv + datas = [b"x", b"y", b"z"] + + pid = os.fork() + if pid == 0: + rd.close() + for data in datas: + # let the parent block on recv() + self._sleep() + wr.sendall(data) + os._exit(0) + else: + self.addCleanup(os.waitpid, pid, 0) + wr.close() + for data in datas: + self.assertEqual(data, recv_func(rd, len(data))) + + def test_recv(self): + self._test_recv(socket.socket.recv) + + @unittest.skipUnless(hasattr(socket.socket, 'recvmsg'), 'needs recvmsg()') + def test_recvmsg(self): + self._test_recv(lambda sock, data: sock.recvmsg(data)[0]) + + def _test_send(self, send_func): + rd, wr = socket.socketpair() + self.addCleanup(wr.close) + # rd closed explicitly by parent + + # we must write enough data for the write() to block + data = b"xyz" * support.SOCK_MAX_SIZE + + pid = os.fork() + if pid == 0: + wr.close() + read_data = io.BytesIO() + # let the parent block on send() + self._sleep() + while len(read_data.getvalue()) < len(data): + chunk = rd.recv(2 * len(data)) + read_data.write(chunk) + self.assertEqual(read_data.getvalue(), data) + os._exit(0) + else: + rd.close() + written = 0 + while written < len(data): + sent = send_func(wr, memoryview(data)[written:]) + # sendall() returns None + written += len(data) if sent is None else sent + self.assertEqual(0, os.waitpid(pid, 0)[1]) + + def test_send(self): + self._test_send(socket.socket.send) + + def test_sendall(self): + self._test_send(socket.socket.sendall) + + @unittest.skipUnless(hasattr(socket.socket, 'sendmsg'), 'needs sendmsg()') + def test_sendmsg(self): + self._test_send(lambda sock, data: sock.sendmsg([data])) + + def test_accept(self): + sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) + self.addCleanup(sock.close) + + sock.bind((support.HOST, 0)) + _, port = sock.getsockname() + sock.listen() + + pid = os.fork() + if pid == 0: + # let parent block on accept() + self._sleep() + with socket.create_connection((support.HOST, port)): + self._sleep() + os._exit(0) + else: + self.addCleanup(os.waitpid, pid, 0) + client_sock, _ = sock.accept() + client_sock.close() + + +def test_main(): + support.run_unittest(OSEINTRTest, SocketEINTRTest) + + +if __name__ == "__main__": + test_main() diff -r fe0fddd6fd21 Lib/test/test_eintr.py --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Lib/test/test_eintr.py Wed Jan 21 05:55:58 2015 +0000 @@ -0,0 +1,20 @@ +import os +import signal +import unittest + +from test import script_helper, support + + + at unittest.skipUnless(os.name == "posix", "only supported on Unix") +class EINTRTests(unittest.TestCase): + + @unittest.skipUnless(hasattr(signal, "setitimer"), "requires setitimer()") + def test_all(self): + # Run the tester in a sub-process, to make sure there is only one + # thread (for reliable signal delivery). + tester = support.findfile("eintr_tester.py", subdir="eintrdata") + script_helper.assert_python_ok(tester) + + +if __name__ == "__main__": + unittest.main() diff -r fe0fddd6fd21 Lib/test/test_signal.py --- a/Lib/test/test_signal.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/test/test_signal.py Wed Jan 21 05:55:58 2015 +0000 @@ -587,7 +587,7 @@ r, w = os.pipe() def handler(signum, frame): - pass + 1 / 0 signal.signal(signal.SIGALRM, handler) if interrupt is not None: @@ -604,9 +604,8 @@ try: # blocking call: read from a pipe without data os.read(r, 1) - except OSError as err: - if err.errno != errno.EINTR: - raise + except ZeroDivisionError: + pass else: sys.exit(2) sys.exit(3) diff -r fe0fddd6fd21 Lib/test/test_socket.py --- a/Lib/test/test_socket.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/test/test_socket.py Wed Jan 21 05:55:58 2015 +0000 @@ -3590,7 +3590,7 @@ def setUp(self): super().setUp() orig_alrm_handler = signal.signal(signal.SIGALRM, - lambda signum, frame: None) + lambda signum, frame: 1 / 0) self.addCleanup(signal.signal, signal.SIGALRM, orig_alrm_handler) self.addCleanup(self.setAlarm, 0) @@ -3627,13 +3627,11 @@ self.serv.settimeout(self.timeout) def checkInterruptedRecv(self, func, *args, **kwargs): - # Check that func(*args, **kwargs) raises OSError with an + # Check that func(*args, **kwargs) raises # errno of EINTR when interrupted by a signal. self.setAlarm(self.alarm_time) - with self.assertRaises(OSError) as cm: + with self.assertRaises(ZeroDivisionError) as cm: func(*args, **kwargs) - self.assertNotIsInstance(cm.exception, socket.timeout) - self.assertEqual(cm.exception.errno, errno.EINTR) def testInterruptedRecvTimeout(self): self.checkInterruptedRecv(self.serv.recv, 1024) @@ -3689,12 +3687,10 @@ # Check that func(*args, **kwargs), run in a loop, raises # OSError with an errno of EINTR when interrupted by a # signal. - with self.assertRaises(OSError) as cm: + with self.assertRaises(ZeroDivisionError) as cm: while True: self.setAlarm(self.alarm_time) func(*args, **kwargs) - self.assertNotIsInstance(cm.exception, socket.timeout) - self.assertEqual(cm.exception.errno, errno.EINTR) # Issue #12958: The following tests have problems on OS X prior to 10.7 @support.requires_mac_ver(10, 7) @@ -4062,117 +4058,6 @@ pass -class FileObjectInterruptedTestCase(unittest.TestCase): - """Test that the file object correctly handles EINTR internally.""" - - class MockSocket(object): - def __init__(self, recv_funcs=()): - # A generator that returns callables that we'll call for each - # call to recv(). - self._recv_step = iter(recv_funcs) - - def recv_into(self, buffer): - data = next(self._recv_step)() - assert len(buffer) >= len(data) - buffer[:len(data)] = data - return len(data) - - def _decref_socketios(self): - pass - - def _textiowrap_for_test(self, buffering=-1): - raw = socket.SocketIO(self, "r") - if buffering < 0: - buffering = io.DEFAULT_BUFFER_SIZE - if buffering == 0: - return raw - buffer = io.BufferedReader(raw, buffering) - text = io.TextIOWrapper(buffer, None, None) - text.mode = "rb" - return text - - @staticmethod - def _raise_eintr(): - raise OSError(errno.EINTR, "interrupted") - - def _textiowrap_mock_socket(self, mock, buffering=-1): - raw = socket.SocketIO(mock, "r") - if buffering < 0: - buffering = io.DEFAULT_BUFFER_SIZE - if buffering == 0: - return raw - buffer = io.BufferedReader(raw, buffering) - text = io.TextIOWrapper(buffer, None, None) - text.mode = "rb" - return text - - def _test_readline(self, size=-1, buffering=-1): - mock_sock = self.MockSocket(recv_funcs=[ - lambda : b"This is the first line\nAnd the sec", - self._raise_eintr, - lambda : b"ond line is here\n", - lambda : b"", - lambda : b"", # XXX(gps): io library does an extra EOF read - ]) - fo = mock_sock._textiowrap_for_test(buffering=buffering) - self.assertEqual(fo.readline(size), "This is the first line\n") - self.assertEqual(fo.readline(size), "And the second line is here\n") - - def _test_read(self, size=-1, buffering=-1): - mock_sock = self.MockSocket(recv_funcs=[ - lambda : b"This is the first line\nAnd the sec", - self._raise_eintr, - lambda : b"ond line is here\n", - lambda : b"", - lambda : b"", # XXX(gps): io library does an extra EOF read - ]) - expecting = (b"This is the first line\n" - b"And the second line is here\n") - fo = mock_sock._textiowrap_for_test(buffering=buffering) - if buffering == 0: - data = b'' - else: - data = '' - expecting = expecting.decode('utf-8') - while len(data) != len(expecting): - part = fo.read(size) - if not part: - break - data += part - self.assertEqual(data, expecting) - - def test_default(self): - self._test_readline() - self._test_readline(size=100) - self._test_read() - self._test_read(size=100) - - def test_with_1k_buffer(self): - self._test_readline(buffering=1024) - self._test_readline(size=100, buffering=1024) - self._test_read(buffering=1024) - self._test_read(size=100, buffering=1024) - - def _test_readline_no_buffer(self, size=-1): - mock_sock = self.MockSocket(recv_funcs=[ - lambda : b"a", - lambda : b"\n", - lambda : b"B", - self._raise_eintr, - lambda : b"b", - lambda : b"", - ]) - fo = mock_sock._textiowrap_for_test(buffering=0) - self.assertEqual(fo.readline(size), b"a\n") - self.assertEqual(fo.readline(size), b"Bb") - - def test_no_buffer(self): - self._test_readline_no_buffer() - self._test_readline_no_buffer(size=4) - self._test_read(buffering=0) - self._test_read(size=100, buffering=0) - - class UnbufferedFileObjectClassTestCase(FileObjectClassTestCase): """Repeat the tests from FileObjectClassTestCase with bufsize==0. @@ -5388,7 +5273,6 @@ tests.extend([ NonBlockingTCPTests, FileObjectClassTestCase, - FileObjectInterruptedTestCase, UnbufferedFileObjectClassTestCase, LineBufferedFileObjectClassTestCase, SmallBufferedFileObjectClassTestCase, diff -r fe0fddd6fd21 Lib/test/test_subprocess.py --- a/Lib/test/test_subprocess.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/test/test_subprocess.py Wed Jan 21 05:55:58 2015 +0000 @@ -2421,25 +2421,6 @@ ProcessTestCase.tearDown(self) -class HelperFunctionTests(unittest.TestCase): - @unittest.skipIf(mswindows, "errno and EINTR make no sense on windows") - def test_eintr_retry_call(self): - record_calls = [] - def fake_os_func(*args): - record_calls.append(args) - if len(record_calls) == 2: - raise OSError(errno.EINTR, "fake interrupted system call") - return tuple(reversed(args)) - - self.assertEqual((999, 256), - subprocess._eintr_retry_call(fake_os_func, 256, 999)) - self.assertEqual([(256, 999)], record_calls) - # This time there will be an EINTR so it will loop once. - self.assertEqual((666,), - subprocess._eintr_retry_call(fake_os_func, 666)) - self.assertEqual([(256, 999), (666,), (666,)], record_calls) - - @unittest.skipUnless(mswindows, "Windows-specific tests") class CommandsWithSpaces (BaseTestCase): @@ -2528,7 +2509,6 @@ Win32ProcessTestCase, CommandTests, ProcessTestCaseNoPoll, - HelperFunctionTests, CommandsWithSpaces, ContextManagerTests, ) diff -r fe0fddd6fd21 Modules/_io/fileio.c --- a/Modules/_io/fileio.c Sun Jan 18 11:17:39 2015 +0200 +++ b/Modules/_io/fileio.c Wed Jan 21 05:55:58 2015 +0000 @@ -550,7 +550,7 @@ { Py_buffer pbuf; Py_ssize_t n, len; - int err; + int err, async_err = 0; if (self->fd < 0) return err_closed(); @@ -562,16 +562,19 @@ if (_PyVerify_fd(self->fd)) { len = pbuf.len; - Py_BEGIN_ALLOW_THREADS - errno = 0; + do { + Py_BEGIN_ALLOW_THREADS + errno = 0; #ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - n = read(self->fd, pbuf.buf, (int)len); + if (len > INT_MAX) + len = INT_MAX; + n = read(self->fd, pbuf.buf, (int)len); #else - n = read(self->fd, pbuf.buf, len); + n = read(self->fd, pbuf.buf, len); #endif - Py_END_ALLOW_THREADS + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); } else n = -1; err = errno; @@ -580,7 +583,8 @@ if (err == EAGAIN) Py_RETURN_NONE; errno = err; - PyErr_SetFromErrno(PyExc_IOError); + if (!async_err) + PyErr_SetFromErrno(PyExc_IOError); return NULL; } @@ -627,6 +631,7 @@ Py_ssize_t bytes_read = 0; Py_ssize_t n; size_t bufsize; + int async_err = 0; if (self->fd < 0) return err_closed(); @@ -673,27 +678,23 @@ return NULL; } } - Py_BEGIN_ALLOW_THREADS - errno = 0; - n = bufsize - bytes_read; + do { + Py_BEGIN_ALLOW_THREADS + errno = 0; + n = bufsize - bytes_read; #ifdef MS_WINDOWS - if (n > INT_MAX) - n = INT_MAX; - n = read(self->fd, PyBytes_AS_STRING(result) + bytes_read, (int)n); + if (n > INT_MAX) + n = INT_MAX; + n = read(self->fd, PyBytes_AS_STRING(result) + bytes_read, (int)n); #else - n = read(self->fd, PyBytes_AS_STRING(result) + bytes_read, n); + n = read(self->fd, PyBytes_AS_STRING(result) + bytes_read, n); #endif - Py_END_ALLOW_THREADS + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); if (n == 0) break; if (n < 0) { - if (errno == EINTR) { - if (PyErr_CheckSignals()) { - Py_DECREF(result); - return NULL; - } - continue; - } if (errno == EAGAIN) { if (bytes_read > 0) break; @@ -701,7 +702,8 @@ Py_RETURN_NONE; } Py_DECREF(result); - PyErr_SetFromErrno(PyExc_IOError); + if (!async_err) + PyErr_SetFromErrno(PyExc_IOError); return NULL; } bytes_read += n; @@ -723,6 +725,7 @@ char *ptr; Py_ssize_t n; Py_ssize_t size = -1; + int async_err = 0; PyObject *bytes; if (self->fd < 0) @@ -747,14 +750,17 @@ ptr = PyBytes_AS_STRING(bytes); if (_PyVerify_fd(self->fd)) { - Py_BEGIN_ALLOW_THREADS - errno = 0; + do { + Py_BEGIN_ALLOW_THREADS + errno = 0; #ifdef MS_WINDOWS - n = read(self->fd, ptr, (int)size); + n = read(self->fd, ptr, (int)size); #else - n = read(self->fd, ptr, size); + n = read(self->fd, ptr, size); #endif - Py_END_ALLOW_THREADS + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); } else n = -1; @@ -764,7 +770,8 @@ if (err == EAGAIN) Py_RETURN_NONE; errno = err; - PyErr_SetFromErrno(PyExc_IOError); + if (!async_err) + PyErr_SetFromErrno(PyExc_IOError); return NULL; } @@ -783,7 +790,7 @@ { Py_buffer pbuf; Py_ssize_t n, len; - int err; + int err, async_err = 0; if (self->fd < 0) return err_closed(); @@ -794,24 +801,26 @@ return NULL; if (_PyVerify_fd(self->fd)) { - Py_BEGIN_ALLOW_THREADS - errno = 0; - len = pbuf.len; + do { + Py_BEGIN_ALLOW_THREADS + errno = 0; + len = pbuf.len; #ifdef MS_WINDOWS - if (len > 32767 && isatty(self->fd)) { - /* Issue #11395: the Windows console returns an error (12: not - enough space error) on writing into stdout if stdout mode is - binary and the length is greater than 66,000 bytes (or less, - depending on heap usage). */ - len = 32767; - } - else if (len > INT_MAX) - len = INT_MAX; - n = write(self->fd, pbuf.buf, (int)len); + if (len > 32767 && isatty(self->fd)) { + /* Issue #11395: the Windows console returns an error (12: not + enough space error) on writing into stdout if stdout mode is + binary and the length is greater than 66,000 bytes (or less, + depending on heap usage). */ + len = 32767; + } else if (len > INT_MAX) + len = INT_MAX; + n = write(self->fd, pbuf.buf, (int)len); #else - n = write(self->fd, pbuf.buf, len); + n = write(self->fd, pbuf.buf, len); #endif - Py_END_ALLOW_THREADS + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); } else n = -1; err = errno; @@ -822,7 +831,8 @@ if (err == EAGAIN) Py_RETURN_NONE; errno = err; - PyErr_SetFromErrno(PyExc_IOError); + if (!async_err) + PyErr_SetFromErrno(PyExc_IOError); return NULL; } diff -r fe0fddd6fd21 Modules/posixmodule.c --- a/Modules/posixmodule.c Sun Jan 18 11:17:39 2015 +0200 +++ b/Modules/posixmodule.c Wed Jan 21 05:55:58 2015 +0000 @@ -1361,13 +1361,16 @@ posix_fildes_fd(int fd, int (*func)(int)) { int res; - Py_BEGIN_ALLOW_THREADS - res = (*func)(fd); - Py_END_ALLOW_THREADS - if (res < 0) - return posix_error(); - Py_INCREF(Py_None); - return Py_None; + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + res = (*func)(fd); + Py_END_ALLOW_THREADS + } while (res != 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res != 0) + return (!async_err) ? posix_error() : NULL; + Py_RETURN_NONE; } @@ -3479,11 +3482,16 @@ /*[clinic end generated code: output=3c19fbfd724a8e0f input=8ab11975ca01ee5b]*/ { int res; - Py_BEGIN_ALLOW_THREADS - res = fchmod(fd, mode); - Py_END_ALLOW_THREADS - if (res < 0) - return posix_error(); + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + res = fchmod(fd, mode); + Py_END_ALLOW_THREADS + } while (res != 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res != 0) + return (!async_err) ? posix_error() : NULL; + Py_RETURN_NONE; } #endif /* HAVE_FCHMOD */ @@ -4104,11 +4112,16 @@ /*[clinic end generated code: output=687781cb7d8974d6 input=3af544ba1b13a0d7]*/ { int res; - Py_BEGIN_ALLOW_THREADS - res = fchown(fd, uid, gid); - Py_END_ALLOW_THREADS - if (res < 0) - return posix_error(); + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + res = fchown(fd, uid, gid); + Py_END_ALLOW_THREADS + } while (res != 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res != 0) + return (!async_err) ? posix_error() : NULL; + Py_RETURN_NONE; } #endif /* HAVE_FCHOWN */ @@ -9665,15 +9678,21 @@ os_wait4_impl(PyModuleDef *module, pid_t pid, int options) /*[clinic end generated code: output=20dfb05289d37dc6 input=d11deed0750600ba]*/ { + pid_t res; struct rusage ru; + int async_err = 0; WAIT_TYPE status; WAIT_STATUS_INT(status) = 0; - Py_BEGIN_ALLOW_THREADS - pid = wait4(pid, &status, options, &ru); - Py_END_ALLOW_THREADS - - return wait_helper(pid, WAIT_STATUS_INT(status), &ru); + do { + Py_BEGIN_ALLOW_THREADS + res = wait4(pid, &status, options, &ru); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res < 0) + return (!async_err) ? posix_error() : NULL; + + return wait_helper(res, WAIT_STATUS_INT(status), &ru); } #endif /* HAVE_WAIT4 */ @@ -9744,14 +9763,17 @@ { PyObject *result; int res; + int async_err = 0; siginfo_t si; si.si_pid = 0; - Py_BEGIN_ALLOW_THREADS - res = waitid(idtype, id, &si, options); - Py_END_ALLOW_THREADS - if (res == -1) - return posix_error(); + do { + Py_BEGIN_ALLOW_THREADS + res = waitid(idtype, id, &si, options); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res < 0) + return (!async_err) ? posix_error() : NULL; if (si.si_pid == 0) Py_RETURN_NONE; @@ -9828,16 +9850,20 @@ os_waitpid_impl(PyModuleDef *module, pid_t pid, int options) /*[clinic end generated code: output=095a6b00af70b7ac input=0bf1666b8758fda3]*/ { + pid_t res; + int async_err = 0; WAIT_TYPE status; WAIT_STATUS_INT(status) = 0; - Py_BEGIN_ALLOW_THREADS - pid = waitpid(pid, &status, options); - Py_END_ALLOW_THREADS - if (pid == -1) - return posix_error(); - - return Py_BuildValue("Ni", PyLong_FromPid(pid), WAIT_STATUS_INT(status)); + do { + Py_BEGIN_ALLOW_THREADS + res = waitpid(pid, &status, options); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res < 0) + return (!async_err) ? posix_error() : NULL; + + return Py_BuildValue("Ni", PyLong_FromPid(res), WAIT_STATUS_INT(status)); } #elif defined(HAVE_CWAIT) /* MS C has a variant of waitpid() that's usable for most purposes. */ @@ -9894,15 +9920,19 @@ /*[clinic end generated code: output=c20b95b15ad44a3a input=444c8f51cca5b862]*/ { int status; - - Py_BEGIN_ALLOW_THREADS - pid = _cwait(&status, pid, options); - Py_END_ALLOW_THREADS - if (pid == -1) - return posix_error(); + Py_intptr_t res; + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + res = _cwait(&status, pid, options); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res != 0) + return (!async_err) ? posix_error() : NULL; /* shift the status left a byte so this is more like the POSIX waitpid */ - return Py_BuildValue(_Py_PARSE_INTPTR "i", pid, status << 8); + return Py_BuildValue(_Py_PARSE_INTPTR "i", res, status << 8); } #endif @@ -9943,14 +9973,17 @@ /*[clinic end generated code: output=2a83a9d164e7e6a8 input=03b0182d4a4700ce]*/ { pid_t pid; + int async_err = 0; WAIT_TYPE status; WAIT_STATUS_INT(status) = 0; - Py_BEGIN_ALLOW_THREADS - pid = wait(&status); - Py_END_ALLOW_THREADS - if (pid == -1) - return posix_error(); + do { + Py_BEGIN_ALLOW_THREADS + pid = wait(&status); + Py_END_ALLOW_THREADS + } while (pid < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (pid < 0) + return (!async_err) ? posix_error() : NULL; return Py_BuildValue("Ni", PyLong_FromPid(pid), WAIT_STATUS_INT(status)); } @@ -11080,6 +11113,7 @@ /*[clinic end generated code: output=531e482dd11a99a0 input=76e96f511be0352f]*/ { int res; + int async_err = 0; #if defined(HAVE_DUP3) && \ !(defined(HAVE_FCNTL_H) && defined(F_DUP2FD_CLOEXEC)) /* dup3() is available on Linux 2.6.27+ and glibc 2.9 */ @@ -11103,38 +11137,46 @@ } #elif defined(HAVE_FCNTL_H) && defined(F_DUP2FD_CLOEXEC) - Py_BEGIN_ALLOW_THREADS - if (!inheritable) - res = fcntl(fd, F_DUP2FD_CLOEXEC, fd2); - else - res = dup2(fd, fd2); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + if (!inheritable) + res = fcntl(fd, F_DUP2FD_CLOEXEC, fd2); + else + res = dup2(fd, fd2); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (res < 0) - return posix_error(); + return (!async_err) ? posix_error() : NULL; #else #ifdef HAVE_DUP3 if (!inheritable && dup3_works != 0) { - Py_BEGIN_ALLOW_THREADS - res = dup3(fd, fd2, O_CLOEXEC); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + res = dup3(fd, fd2, O_CLOEXEC); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); if (res < 0) { if (dup3_works == -1) dup3_works = (errno != ENOSYS); if (dup3_works) - return posix_error(); + return (!async_err) ? posix_error() : NULL; } } if (inheritable || dup3_works == 0) { #endif - Py_BEGIN_ALLOW_THREADS - res = dup2(fd, fd2); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + res = dup2(fd, fd2); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); if (res < 0) - return posix_error(); + return (!async_err) ? posix_error() : NULL; if (!inheritable && _Py_set_inheritable(fd2, 0, NULL) < 0) { close(fd2); @@ -11355,6 +11397,7 @@ /*[clinic end generated code: output=1f3bc27260a24968 input=1df2eaa27c0bf1d3]*/ { Py_ssize_t n; + int async_err = 0; PyObject *buffer; if (length < 0) { @@ -11375,13 +11418,16 @@ buffer = PyBytes_FromStringAndSize((char *)NULL, length); if (buffer == NULL) return NULL; - Py_BEGIN_ALLOW_THREADS - n = read(fd, PyBytes_AS_STRING(buffer), READ_CAST length); - Py_END_ALLOW_THREADS + + do { + Py_BEGIN_ALLOW_THREADS + n = read(fd, PyBytes_AS_STRING(buffer), READ_CAST length); + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (n < 0) { Py_DECREF(buffer); - return posix_error(); + return (!async_err) ? posix_error() : NULL; } if (n != length) @@ -11515,6 +11561,7 @@ { int cnt; Py_ssize_t n; + int async_err = 0; struct iovec *iov; Py_buffer *buf; @@ -11529,13 +11576,16 @@ if (iov_setup(&iov, &buf, buffers, cnt, PyBUF_WRITABLE) < 0) return -1; - Py_BEGIN_ALLOW_THREADS - n = readv(fd, iov, cnt); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + n = readv(fd, iov, cnt); + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); iov_cleanup(iov, buf, cnt); if (n < 0) { - posix_error(); + if (!async_err) + posix_error(); return -1; } @@ -11598,6 +11648,7 @@ /*[clinic end generated code: output=7b62bf6c06e20ae8 input=084948dcbaa35d4c]*/ { Py_ssize_t n; + int async_err = 0; PyObject *buffer; if (length < 0) { @@ -11611,12 +11662,16 @@ Py_DECREF(buffer); return posix_error(); } - Py_BEGIN_ALLOW_THREADS - n = pread(fd, PyBytes_AS_STRING(buffer), length, offset); - Py_END_ALLOW_THREADS + + do { + Py_BEGIN_ALLOW_THREADS + n = pread(fd, PyBytes_AS_STRING(buffer), length, offset); + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (n < 0) { Py_DECREF(buffer); - return posix_error(); + return (!async_err) ? posix_error() : NULL; } if (n != length) _PyBytes_Resize(&buffer, n); @@ -11677,6 +11732,7 @@ /*[clinic end generated code: output=aeb96acfdd4d5112 input=3207e28963234f3c]*/ { Py_ssize_t size; + int async_err = 0; Py_ssize_t len = data->len; if (!_PyVerify_fd(fd)) { @@ -11684,17 +11740,21 @@ return -1; } - Py_BEGIN_ALLOW_THREADS -#ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - size = write(fd, data->buf, (int)len); -#else - size = write(fd, data->buf, len); -#endif - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS +#ifdef MS_WINDOWS + if (len > INT_MAX) + len = INT_MAX; + size = write(fd, data->buf, (int)len); +#else + size = write(fd, data->buf, len); +#endif + Py_END_ALLOW_THREADS + } while (size < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (size < 0) { - posix_error(); + if (!async_err) + posix_error(); return -1; } return size; @@ -11713,6 +11773,7 @@ { int in, out; Py_ssize_t ret; + int async_err = 0; off_t offset; #if defined(__FreeBSD__) || defined(__DragonFly__) || defined(__APPLE__) @@ -11775,13 +11836,15 @@ } } - Py_BEGIN_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS #ifdef __APPLE__ - ret = sendfile(in, out, offset, &sbytes, &sf, flags); -#else - ret = sendfile(in, out, offset, len, &sf, &sbytes, flags); -#endif - Py_END_ALLOW_THREADS + ret = sendfile(in, out, offset, &sbytes, &sf, flags); +#else + ret = sendfile(in, out, offset, len, &sf, &sbytes, flags); +#endif + Py_END_ALLOW_THREADS + } while (ret < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (sf.headers != NULL) iov_cleanup(sf.headers, hbuf, sf.hdr_cnt); @@ -11800,7 +11863,7 @@ return posix_error(); } } - return posix_error(); + return (!async_err) ? posix_error() : NULL; } goto done; @@ -11821,21 +11884,26 @@ return NULL; #ifdef linux if (offobj == Py_None) { + do { + Py_BEGIN_ALLOW_THREADS + ret = sendfile(out, in, NULL, count); + Py_END_ALLOW_THREADS + } while (ret < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (ret < 0) + return (!async_err) ? posix_error() : NULL; + return Py_BuildValue("n", ret); + } +#endif + if (!Py_off_t_converter(offobj, &offset)) + return NULL; + + do { Py_BEGIN_ALLOW_THREADS - ret = sendfile(out, in, NULL, count); + ret = sendfile(out, in, &offset, count); Py_END_ALLOW_THREADS - if (ret < 0) - return posix_error(); - return Py_BuildValue("n", ret); - } -#endif - if (!Py_off_t_converter(offobj, &offset)) - return NULL; - Py_BEGIN_ALLOW_THREADS - ret = sendfile(out, in, &offset, count); - Py_END_ALLOW_THREADS + } while (ret < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (ret < 0) - return posix_error(); + return (!async_err) ? posix_error() : NULL; return Py_BuildValue("n", ret); #endif } @@ -11891,15 +11959,18 @@ { STRUCT_STAT st; int res; - - Py_BEGIN_ALLOW_THREADS - res = FSTAT(fd, &st); - Py_END_ALLOW_THREADS + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + res = FSTAT(fd, &st); + Py_END_ALLOW_THREADS + } while (res != 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (res != 0) { #ifdef MS_WINDOWS return PyErr_SetFromWindowsErr(0); #else - return posix_error(); + return (!async_err) ? posix_error() : NULL; #endif } @@ -12185,6 +12256,7 @@ { int cnt; Py_ssize_t result; + int async_err = 0; struct iovec *iov; Py_buffer *buf; @@ -12199,12 +12271,14 @@ return -1; } - Py_BEGIN_ALLOW_THREADS - result = writev(fd, iov, cnt); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + result = writev(fd, iov, cnt); + Py_END_ALLOW_THREADS + } while (result < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); iov_cleanup(iov, buf, cnt); - if (result < 0) + if (result < 0 && !async_err) posix_error(); return result; @@ -12275,17 +12349,20 @@ /*[clinic end generated code: output=ec9cc5b2238e96a7 input=19903f1b3dd26377]*/ { Py_ssize_t size; + int async_err = 0; if (!_PyVerify_fd(fd)) { posix_error(); return -1; } - Py_BEGIN_ALLOW_THREADS - size = pwrite(fd, buffer->buf, (size_t)buffer->len, offset); - Py_END_ALLOW_THREADS - - if (size < 0) + do { + Py_BEGIN_ALLOW_THREADS + size = pwrite(fd, buffer->buf, (size_t)buffer->len, offset); + Py_END_ALLOW_THREADS + } while (size < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + + if (size < 0 && !async_err) posix_error(); return size; } @@ -12353,18 +12430,21 @@ /*[clinic end generated code: output=b3321927546893d0 input=73032e98a36e0e19]*/ { int result; - - Py_BEGIN_ALLOW_THREADS + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS #ifdef HAVE_MKFIFOAT - if (dir_fd != DEFAULT_DIR_FD) - result = mkfifoat(dir_fd, path->narrow, mode); - else -#endif - result = mkfifo(path->narrow, mode); - Py_END_ALLOW_THREADS - - if (result < 0) - return posix_error(); + if (dir_fd != DEFAULT_DIR_FD) + result = mkfifoat(dir_fd, path->narrow, mode); + else +#endif + result = mkfifo(path->narrow, mode); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); + if (result != 0) + return (!async_err) ? posix_error() : NULL; Py_RETURN_NONE; } @@ -12448,18 +12528,21 @@ /*[clinic end generated code: output=f71d54eaf9bb6f1a input=ee44531551a4d83b]*/ { int result; - - Py_BEGIN_ALLOW_THREADS + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS #ifdef HAVE_MKNODAT - if (dir_fd != DEFAULT_DIR_FD) - result = mknodat(dir_fd, path->narrow, mode, device); - else -#endif - result = mknod(path->narrow, mode, device); - Py_END_ALLOW_THREADS - - if (result < 0) - return posix_error(); + if (dir_fd != DEFAULT_DIR_FD) + result = mknodat(dir_fd, path->narrow, mode, device); + else +#endif + result = mknod(path->narrow, mode, device); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); + if (result != 0) + return (!async_err) ? posix_error() : NULL; Py_RETURN_NONE; } @@ -12662,12 +12745,16 @@ /*[clinic end generated code: output=62326766cb9b76bf input=63b43641e52818f2]*/ { int result; - - Py_BEGIN_ALLOW_THREADS - result = ftruncate(fd, length); - Py_END_ALLOW_THREADS - if (result < 0) - return posix_error(); + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + result = ftruncate(fd, length); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); + if (result != 0) + return (!async_err) ? posix_error() : NULL; Py_RETURN_NONE; } #endif /* HAVE_FTRUNCATE */ @@ -12805,14 +12892,16 @@ /*[clinic end generated code: output=0cd702d2065c79db input=d7a2ef0ab2ca52fb]*/ { int result; - - Py_BEGIN_ALLOW_THREADS - result = posix_fallocate(fd, offset, length); - Py_END_ALLOW_THREADS - if (result != 0) { - errno = result; - return posix_error(); - } + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + result = posix_fallocate(fd, offset, length); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); + if (result != 0) + return (!async_err) ? posix_error() : NULL; Py_RETURN_NONE; } #endif /* HAVE_POSIX_FALLOCATE) && !POSIX_FADVISE_AIX_BUG */ @@ -12883,14 +12972,16 @@ /*[clinic end generated code: output=dad93f32c04dd4f7 input=0fbe554edc2f04b5]*/ { int result; - - Py_BEGIN_ALLOW_THREADS - result = posix_fadvise(fd, offset, length, advice); - Py_END_ALLOW_THREADS - if (result != 0) { - errno = result; - return posix_error(); - } + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + result = posix_fadvise(fd, offset, length, advice); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); + if (result != 0) + return (!async_err) ? posix_error() : NULL; Py_RETURN_NONE; } #endif /* HAVE_POSIX_FADVISE && !POSIX_FADVISE_AIX_BUG */ @@ -13745,13 +13836,17 @@ /*[clinic end generated code: output=0e32bf07f946ec0d input=d8122243ac50975e]*/ { int result; + int async_err = 0; struct statvfs st; - Py_BEGIN_ALLOW_THREADS - result = fstatvfs(fd, &st); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + result = fstatvfs(fd, &st); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); if (result != 0) - return posix_error(); + return (!async_err) ? posix_error() : NULL; return _pystatvfs_fromstructstatvfs(st); } diff -r fe0fddd6fd21 Modules/socketmodule.c --- a/Modules/socketmodule.c Sun Jan 18 11:17:39 2015 +0200 +++ b/Modules/socketmodule.c Wed Jan 21 05:55:58 2015 +0000 @@ -2037,6 +2037,7 @@ PyObject *addr = NULL; PyObject *res = NULL; int timeout; + int async_err = 0; #if defined(HAVE_ACCEPT4) && defined(SOCK_CLOEXEC) /* accept4() is available on Linux 2.6.28+ and glibc 2.10 */ static int accept4_works = -1; @@ -2050,27 +2051,27 @@ return select_error(); BEGIN_SELECT_LOOP(s) - - Py_BEGIN_ALLOW_THREADS - timeout = internal_select_ex(s, 0, interval); - if (!timeout) { + do { + Py_BEGIN_ALLOW_THREADS + timeout = internal_select_ex(s, 0, interval); + if (!timeout) { #if defined(HAVE_ACCEPT4) && defined(SOCK_CLOEXEC) - if (accept4_works != 0) { - newfd = accept4(s->sock_fd, SAS2SA(&addrbuf), &addrlen, - SOCK_CLOEXEC); - if (newfd == INVALID_SOCKET && accept4_works == -1) { - /* On Linux older than 2.6.28, accept4() fails with ENOSYS */ - accept4_works = (errno != ENOSYS); + if (accept4_works != 0) { + newfd = accept4(s->sock_fd, SAS2SA(&addrbuf), &addrlen, + SOCK_CLOEXEC); + if (newfd == INVALID_SOCKET && accept4_works == -1) { + /* On Linux older than 2.6.28, accept4() fails with ENOSYS */ + accept4_works = (errno != ENOSYS); + } } + if (accept4_works == 0) + newfd = accept(s->sock_fd, SAS2SA(&addrbuf), &addrlen); +#else + newfd = accept(s->sock_fd, SAS2SA(&addrbuf), &addrlen); +#endif } - if (accept4_works == 0) - newfd = accept(s->sock_fd, SAS2SA(&addrbuf), &addrlen); -#else - newfd = accept(s->sock_fd, SAS2SA(&addrbuf), &addrlen); -#endif - } - Py_END_ALLOW_THREADS - + Py_END_ALLOW_THREADS + } while (newfd < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (timeout == 1) { PyErr_SetString(socket_timeout, "timed out"); return NULL; @@ -2078,7 +2079,7 @@ END_SELECT_LOOP(s) if (newfd == INVALID_SOCKET) - return s->errorhandler(); + return (!async_err) ? s->errorhandler() : NULL; #ifdef MS_WINDOWS if (!SetHandleInformation((HANDLE)newfd, HANDLE_FLAG_INHERIT, 0)) { @@ -2513,10 +2514,8 @@ /* Signals are not errors (though they may raise exceptions). Adapted from PyErr_SetFromErrnoWithFilenameObject(). */ -#ifdef EINTR if (res == EINTR && PyErr_CheckSignals()) return NULL; -#endif return PyLong_FromLong((long) res); } @@ -2650,6 +2649,7 @@ { Py_ssize_t outlen = -1; int timeout; + int async_err = 0; if (!IS_SELECTABLE(s)) { select_error(); @@ -2661,18 +2661,20 @@ } BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS - timeout = internal_select_ex(s, 0, interval); - if (!timeout) { + do { + Py_BEGIN_ALLOW_THREADS + timeout = internal_select_ex(s, 0, interval); + if (!timeout) { #ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - outlen = recv(s->sock_fd, cbuf, (int)len, flags); + if (len > INT_MAX) + len = INT_MAX; + outlen = recv(s->sock_fd, cbuf, (int)len, flags); #else - outlen = recv(s->sock_fd, cbuf, len, flags); -#endif - } - Py_END_ALLOW_THREADS + outlen = recv(s->sock_fd, cbuf, len, flags); +#endif + } + Py_END_ALLOW_THREADS + } while (outlen < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (timeout == 1) { PyErr_SetString(socket_timeout, "timed out"); @@ -2682,7 +2684,8 @@ if (outlen < 0) { /* Note: the call to errorhandler() ALWAYS indirectly returned NULL, so ignore its return value */ - s->errorhandler(); + if (!async_err) + s->errorhandler(); return -1; } return outlen; @@ -2819,6 +2822,7 @@ int timeout; Py_ssize_t n = -1; socklen_t addrlen; + int async_err = 0; *addr = NULL; @@ -2831,21 +2835,23 @@ } BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS - memset(&addrbuf, 0, addrlen); - timeout = internal_select_ex(s, 0, interval); - if (!timeout) { + do { + Py_BEGIN_ALLOW_THREADS + memset(&addrbuf, 0, addrlen); + timeout = internal_select_ex(s, 0, interval); + if (!timeout) { #ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - n = recvfrom(s->sock_fd, cbuf, (int)len, flags, - (void *) &addrbuf, &addrlen); + if (len > INT_MAX) + len = INT_MAX; + n = recvfrom(s->sock_fd, cbuf, (int)len, flags, + (void *) &addrbuf, &addrlen); #else - n = recvfrom(s->sock_fd, cbuf, len, flags, - SAS2SA(&addrbuf), &addrlen); -#endif - } - Py_END_ALLOW_THREADS + n = recvfrom(s->sock_fd, cbuf, len, flags, + SAS2SA(&addrbuf), &addrlen); +#endif + } + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (timeout == 1) { PyErr_SetString(socket_timeout, "timed out"); @@ -2853,7 +2859,8 @@ } END_SELECT_LOOP(s) if (n < 0) { - s->errorhandler(); + if (!async_err) + s->errorhandler(); return -1; } @@ -2993,6 +3000,7 @@ { ssize_t bytes_received = -1; int timeout; + int async_err = 0; sock_addr_t addrbuf; socklen_t addrbuflen; struct msghdr msg = {0}; @@ -3028,25 +3036,29 @@ } BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS; - msg.msg_name = SAS2SA(&addrbuf); - msg.msg_namelen = addrbuflen; - msg.msg_iov = iov; - msg.msg_iovlen = iovlen; - msg.msg_control = controlbuf; - msg.msg_controllen = controllen; - timeout = internal_select_ex(s, 0, interval); - if (!timeout) - bytes_received = recvmsg(s->sock_fd, &msg, flags); - Py_END_ALLOW_THREADS; - if (timeout == 1) { - PyErr_SetString(socket_timeout, "timed out"); - goto finally; - } + do { + Py_BEGIN_ALLOW_THREADS; + msg.msg_name = SAS2SA(&addrbuf); + msg.msg_namelen = addrbuflen; + msg.msg_iov = iov; + msg.msg_iovlen = iovlen; + msg.msg_control = controlbuf; + msg.msg_controllen = controllen; + timeout = internal_select_ex(s, 0, interval); + if (!timeout) + bytes_received = recvmsg(s->sock_fd, &msg, flags); + Py_END_ALLOW_THREADS; + if (timeout == 1) { + PyErr_SetString(socket_timeout, "timed out"); + goto finally; + } + } while (bytes_received < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); END_SELECT_LOOP(s) if (bytes_received < 0) { - s->errorhandler(); + if (!async_err) + s->errorhandler(); goto finally; } @@ -3305,6 +3317,7 @@ { char *buf; Py_ssize_t len, n = -1; + int async_err = 0; int flags = 0, timeout; Py_buffer pbuf; @@ -3319,18 +3332,20 @@ len = pbuf.len; BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS - timeout = internal_select_ex(s, 1, interval); - if (!timeout) { + do { + Py_BEGIN_ALLOW_THREADS + timeout = internal_select_ex(s, 1, interval); + if (!timeout) { #ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - n = send(s->sock_fd, buf, (int)len, flags); + if (len > INT_MAX) + len = INT_MAX; + n = send(s->sock_fd, buf, (int)len, flags); #else - n = send(s->sock_fd, buf, len, flags); -#endif - } - Py_END_ALLOW_THREADS + n = send(s->sock_fd, buf, len, flags); +#endif + } + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (timeout == 1) { PyBuffer_Release(&pbuf); PyErr_SetString(socket_timeout, "timed out"); @@ -3340,7 +3355,7 @@ PyBuffer_Release(&pbuf); if (n < 0) - return s->errorhandler(); + return (!async_err) ? s->errorhandler() : NULL; return PyLong_FromSsize_t(n); } @@ -3359,7 +3374,8 @@ { char *buf; Py_ssize_t len, n = -1; - int flags = 0, timeout, saved_errno; + int async_err = 0; + int flags = 0, timeout; Py_buffer pbuf; if (!PyArg_ParseTuple(args, "y*|i:sendall", &pbuf, &flags)) @@ -3391,29 +3407,16 @@ PyErr_SetString(socket_timeout, "timed out"); return NULL; } - /* PyErr_CheckSignals() might change errno */ - saved_errno = errno; - /* We must run our signal handlers before looping again. - send() can return a successful partial write when it is - interrupted, so we can't restrict ourselves to EINTR. */ - if (PyErr_CheckSignals()) { - PyBuffer_Release(&pbuf); - return NULL; + if (n >= 0) { + buf += n; + len -= n; } - if (n < 0) { - /* If interrupted, try again */ - if (saved_errno == EINTR) - continue; - else - break; - } - buf += n; - len -= n; - } while (len > 0); + } while (len > 0 && (n >= 0 || errno == EINTR) && + !(async_err = PyErr_CheckSignals())); PyBuffer_Release(&pbuf); - if (n < 0) - return s->errorhandler(); + if (n < 0 || async_err) + return (!async_err) ? s->errorhandler() : NULL; Py_INCREF(Py_None); return Py_None; @@ -3439,6 +3442,7 @@ Py_ssize_t len, arglen; sock_addr_t addrbuf; int addrlen, n = -1, flags, timeout; + int async_err = 0; flags = 0; arglen = PyTuple_Size(args); @@ -3473,20 +3477,22 @@ } BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS - timeout = internal_select_ex(s, 1, interval); - if (!timeout) { + do { + Py_BEGIN_ALLOW_THREADS + timeout = internal_select_ex(s, 1, interval); + if (!timeout) { #ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - n = sendto(s->sock_fd, buf, (int)len, flags, - SAS2SA(&addrbuf), addrlen); + if (len > INT_MAX) + len = INT_MAX; + n = sendto(s->sock_fd, buf, (int)len, flags, + SAS2SA(&addrbuf), addrlen); #else - n = sendto(s->sock_fd, buf, len, flags, - SAS2SA(&addrbuf), addrlen); -#endif - } - Py_END_ALLOW_THREADS + n = sendto(s->sock_fd, buf, len, flags, + SAS2SA(&addrbuf), addrlen); +#endif + } + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (timeout == 1) { PyBuffer_Release(&pbuf); @@ -3496,7 +3502,7 @@ END_SELECT_LOOP(s) PyBuffer_Release(&pbuf); if (n < 0) - return s->errorhandler(); + return (!async_err) ? s->errorhandler() : NULL; return PyLong_FromSsize_t(n); } @@ -3528,6 +3534,7 @@ void *controlbuf = NULL; size_t controllen, controllen_last; ssize_t bytes_sent = -1; + int async_err = 0; int addrlen, timeout, flags = 0; PyObject *data_arg, *cmsg_arg = NULL, *addr_arg = NULL, *data_fast = NULL, *cmsg_fast = NULL, *retval = NULL; @@ -3685,19 +3692,23 @@ } BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS; - timeout = internal_select_ex(s, 1, interval); - if (!timeout) - bytes_sent = sendmsg(s->sock_fd, &msg, flags); - Py_END_ALLOW_THREADS; - if (timeout == 1) { - PyErr_SetString(socket_timeout, "timed out"); - goto finally; - } + do { + Py_BEGIN_ALLOW_THREADS; + timeout = internal_select_ex(s, 1, interval); + if (!timeout) + bytes_sent = sendmsg(s->sock_fd, &msg, flags); + Py_END_ALLOW_THREADS; + if (timeout == 1) { + PyErr_SetString(socket_timeout, "timed out"); + goto finally; + } + } while (bytes_sent < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); END_SELECT_LOOP(s) if (bytes_sent < 0) { - s->errorhandler(); + if (!async_err) + s->errorhandler(); goto finally; } retval = PyLong_FromSsize_t(bytes_sent); From report at bugs.python.org Wed Jan 21 11:43:08 2015 From: report at bugs.python.org (Mike Sampson) Date: Wed, 21 Jan 2015 10:43:08 +0000 Subject: [issue23288] subprocess.Popen close_fds behaviour differs between 3.2 and 3.4 In-Reply-To: <1421836676.03.0.70112175637.issue23288@psf.upfronthosting.co.za> Message-ID: <1421836988.13.0.461337608101.issue23288@psf.upfronthosting.co.za> Mike Sampson added the comment: Ah, got it. Didn't see the note on the os.pipe() docs. Thanks. Closing. Sorry for the noise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 11:43:25 2015 From: report at bugs.python.org (Mike Sampson) Date: Wed, 21 Jan 2015 10:43:25 +0000 Subject: [issue23288] subprocess.Popen close_fds behaviour differs between 3.2 and 3.4 In-Reply-To: <1421836676.03.0.70112175637.issue23288@psf.upfronthosting.co.za> Message-ID: <1421837005.76.0.402702217635.issue23288@psf.upfronthosting.co.za> Changes by Mike Sampson : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 11:49:35 2015 From: report at bugs.python.org (Neil Girdhar) Date: Wed, 21 Jan 2015 10:49:35 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421837375.53.0.136712418088.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Added many tests, six of which fail. Started work on grammar to fix new tests. ---------- Added file: http://bugs.python.org/file37805/starunpack11.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 11:53:28 2015 From: report at bugs.python.org (koobs) Date: Wed, 21 Jan 2015 10:53:28 +0000 Subject: [issue22176] update internal libffi copy to 3.1, introducing AArch64 and POWER ELF ABIv2 In-Reply-To: <1407614032.19.0.619633143282.issue22176@psf.upfronthosting.co.za> Message-ID: <1421837608.25.0.578810169299.issue22176@psf.upfronthosting.co.za> Changes by koobs : ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 13:43:00 2015 From: report at bugs.python.org (Piotr Majkrzak) Date: Wed, 21 Jan 2015 12:43:00 +0000 Subject: [issue23289] concurrent.futures.Executor.map is not equivalent to map. Message-ID: <1421844180.03.0.988670092885.issue23289@psf.upfronthosting.co.za> New submission from Piotr Majkrzak: In documentation https://docs.python.org/3/library/concurrent.futures.html#concurrent.futures.Executor.map is writen that this fucntion is equivalent to the builtin map. But it is not true due to the fact that it is not lazy evalueded. The reason is in https://hg.python.org/cpython/file/0893b9ee44ea/Lib/concurrent/futures/_base.py#l548 where the full list of features is created. I don't find any reasonable solutions, but in my case following code was suitable. https://gist.github.com/06bbd83eccd4083c68d0 ---------- components: Library (Lib) messages: 234433 nosy: majkrzak priority: normal severity: normal status: open title: concurrent.futures.Executor.map is not equivalent to map. type: behavior versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 14:29:10 2015 From: report at bugs.python.org (Yuriy Taraday) Date: Wed, 21 Jan 2015 13:29:10 +0000 Subject: [issue12029] Catching virtual subclasses in except clauses In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za> Message-ID: <1421846950.0.0.821639486294.issue12029@psf.upfronthosting.co.za> Yuriy Taraday added the comment: Can we move forward and land this patch? It seems to be working and for some reason it even makes that microbenchmark work faster. ---------- versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 14:43:18 2015 From: report at bugs.python.org (liyang) Date: Wed, 21 Jan 2015 13:43:18 +0000 Subject: [issue12312] is ok In-Reply-To: Message-ID: liyang added the comment: -- name:?? celephone?15011548154 ---------- nosy: +liyang1025 at gmail.com _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 14:46:29 2015 From: report at bugs.python.org (Joshua Landau) Date: Wed, 21 Jan 2015 13:46:29 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421847989.59.0.838490393436.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: Some of the tests seemed to be failing simply because they were incorrect. This fixes that. ---------- Added file: http://bugs.python.org/file37806/starunpack12.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 14:50:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 21 Jan 2015 13:50:08 +0000 Subject: [issue23290] Faster set copying Message-ID: <1421848208.43.0.905402107396.issue23290@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch makes faster creating new set from other set. The benefit is only few percents when there are no hash conflicts, but can be significant if there are hash duplicates. $ ./python -m timeit -s "s = set(range(10**4))" -- "frozenset(s)" Unpatched: 1000 loops, best of 3: 658 usec per loop Patched: 1000 loops, best of 3: 620 usec per loop $ ./python -m timeit -s "s = {i+(j<<64) for i in range(10**3) for j in range(10)}" -- "frozenset(s)" Unpatched: 100 loops, best of 3: 6.72 msec per loop Patched: 100 loops, best of 3: 2.05 msec per loop $ ./python -m timeit -s "s = {i+(j<<64) for i in range(10**2) for j in range(10**2)}" -- "frozenset(s)" Unpatched: 100 loops, best of 3: 14 msec per loop Patched: 100 loops, best of 3: 2.67 msec per loop It should also affect set.copy and operations which makes implicit copy (most set operators). The effect should be larger for objects with slow equality operator. set_find_free_slot() can be used to prevent a catastrophic linear pile-up in issue23259. ---------- components: Interpreter Core messages: 234437 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Faster set copying type: performance versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 14:51:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 21 Jan 2015 13:51:16 +0000 Subject: [issue23290] Faster set copying In-Reply-To: <1421848208.43.0.905402107396.issue23290@psf.upfronthosting.co.za> Message-ID: <1421848276.24.0.636856691657.issue23290@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch nosy: +pitrou, rhettinger Added file: http://bugs.python.org/file37807/set_faster_copy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 14:52:57 2015 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 21 Jan 2015 13:52:57 +0000 Subject: [issue12312] is ok In-Reply-To: Message-ID: <1421848377.88.0.67796250879.issue12312@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- Removed message: http://bugs.python.org/msg234435 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 15:11:23 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 21 Jan 2015 14:11:23 +0000 Subject: [issue12029] Catching virtual subclasses in except clauses In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za> Message-ID: <1421849483.67.0.462492086946.issue12029@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 15:31:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 21 Jan 2015 14:31:09 +0000 Subject: [issue23290] Faster set copying In-Reply-To: <1421848208.43.0.905402107396.issue23290@psf.upfronthosting.co.za> Message-ID: <1421850669.55.0.100013563223.issue23290@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is even faster patch. When there are no dummies in source set we can just dump a table, placing entries at the same indices. $ ./python -m timeit -s "s = set(range(10**4))" -- "frozenset(s)" Unpatched: 1000 loops, best of 3: 658 usec per loop Patched: 1000 loops, best of 3: 631 usec per loop $ ./python -m timeit -s "s = {i+(j<<64) for i in range(10**3) for j in range(10)}" -- "frozenset(s)" Unpatched: 100 loops, best of 3: 6.72 msec per loop Patched: 1000 loops, best of 3: 930 usec per loop $ ./python -m timeit -s "s = {i+(j<<64) for i in range(10**2) for j in range(10**2)}" -- "frozenset(s)" Unpatched: 100 loops, best of 3: 14 msec per loop Patched: 1000 loops, best of 3: 1.12 msec per loop To test other branch we should add dummy entry: s.add(-1); s.discard(-1). $ ./python -m timeit -s "s = {i+(j<<64) for i in range(10**3) for j in range(10)}; s.add(-1); s.discard(-1)" -- "frozenset(s)" Unpatched: 1000 loops, best of 3: 661 usec per loop Patched: 1000 loops, best of 3: 643 usec per loop $ ./python -m timeit -s "s = {i+(j<<64) for i in range(10**3) for j in range(10)}; s.add(-1); s.discard(-1)" -- "frozenset(s)" Unpatched: 100 loops, best of 3: 6.8 msec per loop Patched: 100 loops, best of 3: 2.1 msec per loop $ ./python -m timeit -s "s = {i+(j<<64) for i in range(10**2) for j in range(10**2)}; s.add(-1); s.discard(-1)" -- "frozenset(s)" Unpatched: 100 loops, best of 3: 14 msec per loop Patched: 100 loops, best of 3: 2.71 msec per loop ---------- Added file: http://bugs.python.org/file37808/set_faster_copy_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 15:37:30 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 21 Jan 2015 14:37:30 +0000 Subject: [issue23288] subprocess.Popen close_fds behaviour differs between 3.2 and 3.4 In-Reply-To: <1421836676.03.0.70112175637.issue23288@psf.upfronthosting.co.za> Message-ID: <1421851050.11.0.138402360688.issue23288@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> not a bug stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 16:45:24 2015 From: report at bugs.python.org (Drekin) Date: Wed, 21 Jan 2015 15:45:24 +0000 Subject: [issue17620] Python interactive console doesn't use sys.stdin for input In-Reply-To: <1364921954.86.0.527255608282.issue17620@psf.upfronthosting.co.za> Message-ID: <1421855124.42.0.756548557784.issue17620@psf.upfronthosting.co.za> Drekin added the comment: Unfortunately, I have little or no experience with Python C code and I even don't have a C compiler installed so I cannot experiment. I'll just put my ideas how to solve this here. ? Add sys.__readlinehook__ attribute, which can be set to a function taking a prompt string and returing a line. ? Add C function PyOS_UnicodeReadline (possibly with a better name) which has the same signature as sys.__readlinehook__ (in contrast with the signature of PyOS_Readline). If sys.__readlinehook__ is set, call it; otherwise encode the prompt string using stdout encoding and delegate to PyOS_Readline and decode the string returned using stdin encoding. ? Change the tokenizer and the implementation of input() so it uses PyOS_UnicodeReadline rather than PyOS_Readline. This would solve the problem that utf-16 encoded string cannot be given to the tokenizer and also would bypass the silent assumption that stdin and stdout encodings are the same. Also, readline hook could be easily set from Python code ? no need for ctypes. The package pyreadline could use this. Also, the issue #1602 could be then solved just by changing sys.std* streams and providing a trivial sys.__readlinehook__ delegating to sys.stdout.write and sys.stdin.readline. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 17:35:39 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Jan 2015 16:35:39 +0000 Subject: [issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture In-Reply-To: <1419122866.29.0.725788641938.issue23095@psf.upfronthosting.co.za> Message-ID: <1421858139.24.0.728719194771.issue23095@psf.upfronthosting.co.za> STINNER Victor added the comment: To wait for the exit of the subprocess, we use RegisterWaitForSingleObject(). To cancel this wait, we can use UnregisterWait() which returns immediatly. Problem: UnregisterWait() doesn't tell us if the wait was cancelled or not, the cancellation is asynchronous. Second problem: the wait may have been signaled to the IOCP... or not. The wait may be signaled after the call to UnregisterWait(), since the cancellation is asynchronous (I'm not sure of that, but it doesn't change everything). This can be explained by the implementation: RegisterWaitForSingleObject() is implemented with a pool of threads. Windows XP introduced UnregiterWaitEx() which can be used to be notified when the wait has been cancelled. Cool. But the notification requires an Event object. And how can we asynchronously wait for this Event? Using RegisterWaitForSingleObject()! Wait, what? We were cancelling another RegisterWaitForSingleObject(). To be fully asynchronous (no performance impact), cancelling a RegisterWaitForSingleObject() wait requires a new Event object and call RegisterWaitForSingleObject() on it. -- In Python, we must ensure that the Overlapped object used by RegisterWaitForSingleObject() is kept alive until the wait is signalled, or until we are sure that the wait was cancelled. Otherwise, the program may crash. To keep the Overlapped object alive, we keep indirectly in a _WaitHandleFuture object, and this future is registered in IocpProactor._cache. I'm working on a change to use UnregiterWaitEx(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 18:53:45 2015 From: report at bugs.python.org (Albert Zeyer) Date: Wed, 21 Jan 2015 17:53:45 +0000 Subject: [issue23291] Documentation about Py_Finalize(): Freeing objects Message-ID: <1421862824.96.0.769285888679.issue23291@psf.upfronthosting.co.za> New submission from Albert Zeyer: The documentation about Py_Finalize() about freeing objects is not exactly clear. Esp., when I have called Py_INCREF somewhere, those objects will always have ob_refcnt > 0 unless I call Py_DECREF somewhere, what about these objects? Will they be freed in Py_Finalize() or not? If not, what can I do? I guess calling Py_DECREF after Py_Finalize() is not allowed. I studied the Py_Finalize() code but I'm not exactly sure. It looks like such objects would not get freed (unless some implicit magic is happening somewhere). The comment about the last commented-out PyGC_Collect() call is also insightful and somewhat unsatisfying. Maybe PyObject_Free() still works, although that would not free any further referenced objects, I guess. Also, I'm not exactly sure about the pymalloc arenas. With pymalloc, maybe we could just free all pymalloc arenas and it would free all memory allocated by Python objects? Of course, that would not call any advanced tp_dealloc functions which might be important to be called, but we would never ever call those anyway anymore, or would we (how?)? So, maybe it would be good to do that? ---------- components: Interpreter Core messages: 234441 nosy: Albert.Zeyer priority: normal severity: normal status: open title: Documentation about Py_Finalize(): Freeing objects versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 21:00:29 2015 From: report at bugs.python.org (Mark Summerfield) Date: Wed, 21 Jan 2015 20:00:29 +0000 Subject: [issue23292] Enum doc suggestion Message-ID: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za> New submission from Mark Summerfield: I think it would be worth documenting globals().update(MyEnumeration.__members__) in the "Interesting Examples" section of the enum docs. I suspect that most people will find that importing enums is annoying because they'll get import A print(A.MyEnumeration.MAX) when they're more used to import A print(A.MAX) Of course the latter is easily achieved using the globals().update() trick (as used in signals.py in 3.5). Georg suggested I add this to the tracker. ---------- assignee: docs at python components: Documentation files: py-enum.tar.gz messages: 234442 nosy: docs at python, mark priority: normal severity: normal status: open title: Enum doc suggestion type: enhancement versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file37809/py-enum.tar.gz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 21:01:30 2015 From: report at bugs.python.org (Mark Summerfield) Date: Wed, 21 Jan 2015 20:01:30 +0000 Subject: [issue23292] Enum doc suggestion In-Reply-To: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za> Message-ID: <1421870490.66.0.299225627722.issue23292@psf.upfronthosting.co.za> Mark Summerfield added the comment: Georg said to assign this to Ethan Furman but I don't seem to have that facility. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 21:13:32 2015 From: report at bugs.python.org (Georg Brandl) Date: Wed, 21 Jan 2015 20:13:32 +0000 Subject: [issue23292] Enum doc suggestion In-Reply-To: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za> Message-ID: <1421871212.15.0.205470806078.issue23292@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- assignee: docs at python -> ethan.furman nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 21:21:48 2015 From: report at bugs.python.org (=?utf-8?q?Enrico_Tr=C3=B6ger?=) Date: Wed, 21 Jan 2015 20:21:48 +0000 Subject: [issue23166] urllib2 ignores opener configuration under certain circumstances In-Reply-To: <1420406037.0.0.986455895168.issue23166@psf.upfronthosting.co.za> Message-ID: <1421871707.99.0.179045365507.issue23166@psf.upfronthosting.co.za> Enrico Tr?ger added the comment: I got the same error suddenly with Python 2.7.9. I think this is quite unfortunate because it somewhat breaks existing behaviour, especially that SSL certificate verification is enabled by default. Don't get me wrong, this is the right thing in general and it is important. Still, adding this feature in a 2.7 patch level release and enabling it by default feels quite hard. I guess this will break many scripts and applications which rely on non-verification of SSL certs (which is bad but it was the exisiting behaviour). Anyway, attached is my use case where I use a HTTPS request coupled with HTTP basic authentication and disabled SSL cert verification. As described above, passing a context to urlopen() will override previously configured handlers, unfortunately. In the attached script there is also a workaround which works for me by not using urlopen() but instead calling opener.open() manually after adding the necessary handlers myself. Not nice but works for the moment. ---------- nosy: +eht16 Added file: http://bugs.python.org/file37810/urllib_ssl_auth_test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 22:07:34 2015 From: report at bugs.python.org (Joshua Landau) Date: Wed, 21 Jan 2015 21:07:34 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421874454.54.0.833143991472.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: I think I've fixed the memory leaks (plural). There were also a host of other problems with the _UNPACK opcodes in ceval. Here are the things I remember fixing, although I think I did slightly more: - Not throwing an error when PyDict_New or PyDict_Update fails. - Not doing Py_DECREF on stack items being popped. - Not checking if intersection is non-NULL. - Not doing Py_DECREF on intersection. Now the primary problem is giving good errors; I don't know how to make them look like they came from the function call. I'm not sure I want to, either, since these opcodes are used elsewhere. I do need to check something about this (what requirements are there on how you leave the stack when you "goto error"?), but that's an easy fix if my current guess isn't right. ---------- Added file: http://bugs.python.org/file37811/starunpack13.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 23:07:01 2015 From: report at bugs.python.org (Claudiu Popa) Date: Wed, 21 Jan 2015 22:07:01 +0000 Subject: [issue22885] Arbitrary code execution vulnerability due to unchecked eval() call in dumbdbm module In-Reply-To: <1416163141.0.0.643597983294.issue22885@psf.upfronthosting.co.za> Message-ID: <1421878021.4.0.65917302318.issue22885@psf.upfronthosting.co.za> Claudiu Popa added the comment: Here's a patch which uses ast.literal_eval instead. This doesn't get code executed, since literal_eval will fail loudly for anything other than a literal. There are some issues to consider: - let the current ast.literal_eval call bubble out with a lot of different exceptions - normalize the exception to dbm.dumb.error. I'm leaning towards the first, since it clearly shows that something bad happened in the module and it's a first indicator that someone tampered with the data file. ---------- keywords: +patch nosy: +Claudiu.Popa Added file: http://bugs.python.org/file37812/issue22885.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 23:07:59 2015 From: report at bugs.python.org (Claudiu Popa) Date: Wed, 21 Jan 2015 22:07:59 +0000 Subject: [issue22885] Arbitrary code execution vulnerability due to unchecked eval() call in dumbdbm module In-Reply-To: <1416163141.0.0.643597983294.issue22885@psf.upfronthosting.co.za> Message-ID: <1421878079.07.0.0227071551765.issue22885@psf.upfronthosting.co.za> Changes by Claudiu Popa : ---------- priority: normal -> high stage: -> patch review versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 23:20:40 2015 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 21 Jan 2015 22:20:40 +0000 Subject: [issue22885] Arbitrary code execution vulnerability due to unchecked eval() call in dumbdbm module In-Reply-To: <1416163141.0.0.643597983294.issue22885@psf.upfronthosting.co.za> Message-ID: <1421878840.18.0.361255272059.issue22885@psf.upfronthosting.co.za> Guido van Rossum added the comment: Python 3's exception chaining allows us to do the second (easier to catch without resorting to "except Exception:" or even "except:") while still showing the original exception in the traceback. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 23:32:53 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Jan 2015 22:32:53 +0000 Subject: [issue23293] [Windows] asyncio: race condition related in IocpProactor.connect_pipe() Message-ID: <1421879573.47.0.0852926503812.issue23293@psf.upfronthosting.co.za> New submission from STINNER Victor: Currently, IocpProactor.connect_pipe() is implemented with QueueUserWorkItem() which starts a thread that cannot be interrupted. Because of that, this function requires special cases in _register() and close() methods of IocpProactor. While fixing the issue #23095, I saw that IocpProactor.connect_pipe() causes "GetQueuedCompletionStatus() returned an unexpected event" messages to be logged, but also to hang the test suite. I propose a solution to reimplement IocpProactor.connect_pipe() without a thread: https://code.google.com/p/tulip/issues/detail?id=197 It should fix this issue. ---------- components: Windows, asyncio messages: 234448 nosy: gvanrossum, haypo, steve.dower, tim.golden, yselivanov, zach.ware priority: normal severity: normal status: open title: [Windows] asyncio: race condition related in IocpProactor.connect_pipe() versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 23:34:04 2015 From: report at bugs.python.org (aruseni) Date: Wed, 21 Jan 2015 22:34:04 +0000 Subject: [issue23294] A typo in the tutorial Message-ID: <1421879644.03.0.144985173362.issue23294@psf.upfronthosting.co.za> New submission from aruseni: https://docs.python.org/3/tutorial/controlflow.html > In many ways the object returned by range() behaves as if it is a list, but in fact it isn?t. ---------- messages: 234449 nosy: aruseni priority: normal severity: normal status: open title: A typo in the tutorial _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 23:34:29 2015 From: report at bugs.python.org (aruseni) Date: Wed, 21 Jan 2015 22:34:29 +0000 Subject: [issue23294] A typo in the tutorial In-Reply-To: <1421879644.03.0.144985173362.issue23294@psf.upfronthosting.co.za> Message-ID: <1421879669.63.0.592987590846.issue23294@psf.upfronthosting.co.za> Changes by aruseni : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 23:34:48 2015 From: report at bugs.python.org (Claudiu Popa) Date: Wed, 21 Jan 2015 22:34:48 +0000 Subject: [issue22885] Arbitrary code execution vulnerability due to unchecked eval() call in dumbdbm module In-Reply-To: <1416163141.0.0.643597983294.issue22885@psf.upfronthosting.co.za> Message-ID: <1421879688.8.0.958354193949.issue22885@psf.upfronthosting.co.za> Claudiu Popa added the comment: Thanks for the tip, Guido. The new patch uses exception chaining. If this needs backporting, most probably the first patch can be used. ---------- Added file: http://bugs.python.org/file37813/issue22885_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 23:42:01 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 21 Jan 2015 22:42:01 +0000 Subject: [issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture In-Reply-To: <1419122866.29.0.725788641938.issue23095@psf.upfronthosting.co.za> Message-ID: <20150121224132.103295.79400@psf.io> Roundup Robot added the comment: New changeset fb8a093db8b1 by Victor Stinner in branch '3.4': Issue #23095, asyncio: Rewrite _WaitHandleFuture.cancel() https://hg.python.org/cpython/rev/fb8a093db8b1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 23:46:32 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Jan 2015 22:46:32 +0000 Subject: [issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture In-Reply-To: <1419122866.29.0.725788641938.issue23095@psf.upfronthosting.co.za> Message-ID: <1421880392.55.0.263747812861.issue23095@psf.upfronthosting.co.za> STINNER Victor added the comment: It took me several months to understand this issue. For the beginning of the story, see: https://code.google.com/p/tulip/issues/detail?id=196 But I think that *this* issue can be closed: UnregisterWaitEx() really do what we need in asyncio. I don't like the complex IocpProactor._unregister() function and _WaitCancelFuture class, but it looks that it's how we are supposed to wait until a wait for a handle is cancelled... Windows IOCP API is much complex that what I expected. It's probably because some parts (especially RegisterWaitForSingleObject()) are implemented with threads in user land, not in the kernel. In short, I'm very happy that have fixed this very complex but also very annoying IOCP bug in asyncio. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 21 23:53:59 2015 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 21 Jan 2015 22:53:59 +0000 Subject: [issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture In-Reply-To: <1419122866.29.0.725788641938.issue23095@psf.upfronthosting.co.za> Message-ID: <1421880839.6.0.518502201117.issue23095@psf.upfronthosting.co.za> Guido van Rossum added the comment: Congrats with the fix, and thanks for your perseverance! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 00:19:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 21 Jan 2015 23:19:33 +0000 Subject: [issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture In-Reply-To: <1419122866.29.0.725788641938.issue23095@psf.upfronthosting.co.za> Message-ID: <20150121231853.69910.24905@psf.io> Roundup Robot added the comment: New changeset d3804307cce4 by Victor Stinner in branch '3.4': Issue #23095, asyncio: IocpProactor.close() must not cancel pending https://hg.python.org/cpython/rev/d3804307cce4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 00:22:01 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Jan 2015 23:22:01 +0000 Subject: [issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture In-Reply-To: <1419122866.29.0.725788641938.issue23095@psf.upfronthosting.co.za> Message-ID: <1421882521.3.0.382347738455.issue23095@psf.upfronthosting.co.za> STINNER Victor added the comment: "IocpProactor.close() must not cancel pending _WaitCancelFuture futures" FYI I found this bug when running the trollius test suite. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 00:40:13 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Jan 2015 23:40:13 +0000 Subject: [issue23295] [Windows] asyncio: add UDP support to ProactorEventLoop Message-ID: <1421883613.58.0.0395481360088.issue23295@psf.upfronthosting.co.za> New submission from STINNER Victor: ProactorEventLoop lacks UDP support: create_datagram_endpoint() is not supported. New functions should be added to the _overlapped modul. Example: add maybe WSARecvFrom()? ---------- components: Windows, asyncio messages: 234456 nosy: gvanrossum, haypo, steve.dower, tim.golden, yselivanov, zach.ware priority: normal severity: normal status: open title: [Windows] asyncio: add UDP support to ProactorEventLoop versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 00:41:08 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Jan 2015 23:41:08 +0000 Subject: [issue23293] [Windows] asyncio: race condition related to IocpProactor.connect_pipe() In-Reply-To: <1421879573.47.0.0852926503812.issue23293@psf.upfronthosting.co.za> Message-ID: <1421883668.6.0.0367788891529.issue23293@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: [Windows] asyncio: race condition related in IocpProactor.connect_pipe() -> [Windows] asyncio: race condition related to IocpProactor.connect_pipe() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 01:01:43 2015 From: report at bugs.python.org (Neil Girdhar) Date: Thu, 22 Jan 2015 00:01:43 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421884903.16.0.806150639083.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Very nice! So what's left besides errors? * Fixing the grammar, ast, and compilation for the list, dict, and set comprehension element unpackings > Now the primary problem is giving good errors; I don't know how to make them look like they came from the function call. I'm not sure I want to, either, since these opcodes are used elsewhere. The _UNPACK opcodes are new in this changelist. You can do "hg vdiff" to give a side-by-side diff or just check in the patch review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 01:03:38 2015 From: report at bugs.python.org (Joshua Landau) Date: Thu, 22 Jan 2015 00:03:38 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421885018.12.0.585014023962.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: > The _UNPACK opcodes are new in this changelist. Yup, but they're used in the other unpacking syntax too: (*(1, 2, 3), *(4, 5, 6)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 02:34:44 2015 From: report at bugs.python.org (Neil Girdhar) Date: Thu, 22 Jan 2015 01:34:44 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421890484.29.0.343888280003.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Oh, I see. For BUILD_MAP_UNPACK we don't want to raise on duplicate dict comprehension element unpackings, right? Maybe we should add a different opcode, or else a flag to the opcodes, or else use the top bit of the length parameter? What do you think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 02:44:34 2015 From: report at bugs.python.org (Joshua Landau) Date: Thu, 22 Jan 2015 01:44:34 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421891074.64.0.402880069054.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: Good catch. CALL_FUNCTION seems to split its opcode into two to give it a positional-keyword pair so this seems fine. I'd hope we can do the same thing; personally I would do: BUILD_MAP_UNPACK( position_of_function_in_stack_or_0 << 8 | number_to_pack ) This way if building for a function we can do the check *and* give good errors that match the ones raised from CALL_FUNCTION. When the top 8 bits are 0, we don't do checks. What do you think? Would dual-usage be too confusing? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 02:46:07 2015 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 22 Jan 2015 01:46:07 +0000 Subject: [issue23294] A typo in the tutorial In-Reply-To: <1421879644.03.0.144985173362.issue23294@psf.upfronthosting.co.za> Message-ID: <1421891167.07.0.119264523935.issue23294@psf.upfronthosting.co.za> Eric V. Smith added the comment: What's the typo? I'm not seeing it. ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 03:27:20 2015 From: report at bugs.python.org (Neil Girdhar) Date: Thu, 22 Jan 2015 02:27:20 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421893640.77.0.362658973478.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: I am a huge fan of giving good errors. Looks good to me. Will we need to make sure that the call helper function we worked on produces additional BUILD_MAP_UNPACK opcodes every 256 dictionaries just in case? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 03:38:32 2015 From: report at bugs.python.org (Joshua Landau) Date: Thu, 22 Jan 2015 02:38:32 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421894312.57.0.420596324798.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: Functions are already limited to 255 arguments, so I don't think so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 03:39:32 2015 From: report at bugs.python.org (Neil Girdhar) Date: Thu, 22 Jan 2015 02:39:32 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421894372.72.0.926060539015.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Another option to consider is to just use a bit on the BUILD_MAP_UNPACK and then have a stack marking opcode at the function call (not sure what to call it, but say FUNCTION_CALL_MARK) The advantage would be you don't store or calculate relative stack positions. When the interpreter sees the mark, it stores the function call address for use in BUILD_MAP_UNPACK errors. Although I guess you have 24 bits to store the relative stack position? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 03:43:25 2015 From: report at bugs.python.org (Joshua Landau) Date: Thu, 22 Jan 2015 02:43:25 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421894605.87.0.443233338318.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: According to the standard, int can be only 16 bits long so that only leaves 255/255. However, if the offset is on top of the dictionary count, this is easily enough to clear the limits for the maximum function size (worst case is a merge of 255 dicts with an offset of 1 or a merge of 2 dicts with an offset of 254). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 03:52:51 2015 From: report at bugs.python.org (Neil Girdhar) Date: Thu, 22 Jan 2015 02:52:51 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421895171.94.0.260248164441.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: I see your point: if there are 255 dictionaries, there's no room for neither preceding keyword arguments nor positional arguments. Okay, then I like your solution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 03:57:06 2015 From: report at bugs.python.org (Neil Girdhar) Date: Thu, 22 Jan 2015 02:57:06 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421895426.39.0.576079636196.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Also maybe not in this changelist, but we should consider replacing STORE_MAP and BUILD_MAP with a single opcode BUILD_MAP(n) that produces a dict out of the top n items on the stack just like BUILD_LIST(n) does. What do you think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 04:13:19 2015 From: report at bugs.python.org (Joshua Landau) Date: Thu, 22 Jan 2015 03:13:19 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421896399.32.0.236592046239.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: We wouldn't want to replace STORE_MAP since that's used in dictionary comprehensions, but replacing BUILD_MAP with BUILD_MAP(n) sounds like a great idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 04:18:37 2015 From: report at bugs.python.org (Neil Girdhar) Date: Thu, 22 Jan 2015 03:18:37 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421896717.61.0.263914692456.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: You're right. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 05:40:12 2015 From: report at bugs.python.org (Ben Finney) Date: Thu, 22 Jan 2015 04:40:12 +0000 Subject: =?utf-8?b?W2lzc3VlMjMyOTZdIOKAmHRva2VuaXplLmRldGVjdF9lbmNvZGluZ+KAmSBp?= =?utf-8?q?s_confused_between_text_and_bytes=3A_no_=E2=80=98startswith?= =?utf-8?q?=E2=80=99_method_on_a_byte_string?= Message-ID: <1421901612.51.0.543377948137.issue23296@psf.upfronthosting.co.za> New submission from Ben Finney: In `tokenize.detect_encoding` is the following code:: first = read_or_stop() if first.startswith(BOM_UTF8): # ? The `read_or_stop` function is defined as:: def read_or_stop(): try: return readline() except StopIteration: return b'' So, on catching ``StopIteration``, the return value will be a byte string. The `detect_encoding` code then immediately calls `sartswith`, which fails:: File "/usr/lib/python3.4/tokenize.py", line 409, in detect_encoding if first.startswith(BOM_UTF8): TypeError: startswith first arg must be str or a tuple of str, not bytes One or both of those locations in the code is wrong. Either `read_or_stop` should never return a byte string; or `detect_encoding` should not assume it can call `startswith` on the result. ---------- components: Library (Lib) messages: 234470 nosy: bignose priority: normal severity: normal status: open title: ?tokenize.detect_encoding? is confused between text and bytes: no ?startswith? method on a byte string versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 05:40:26 2015 From: report at bugs.python.org (Ben Finney) Date: Thu, 22 Jan 2015 04:40:26 +0000 Subject: =?utf-8?b?W2lzc3VlMjMyOTddIOKAmHRva2VuaXplLmRldGVjdF9lbmNvZGluZ+KAmSBp?= =?utf-8?q?s_confused_between_text_and_bytes=3A_no_=E2=80=98startswith?= =?utf-8?q?=E2=80=99_method_on_a_byte_string?= Message-ID: <1421901626.89.0.392776519963.issue23297@psf.upfronthosting.co.za> New submission from Ben Finney: In `tokenize.detect_encoding` is the following code:: first = read_or_stop() if first.startswith(BOM_UTF8): # ? The `read_or_stop` function is defined as:: def read_or_stop(): try: return readline() except StopIteration: return b'' So, on catching ``StopIteration``, the return value will be a byte string. The `detect_encoding` code then immediately calls `sartswith`, which fails:: File "/usr/lib/python3.4/tokenize.py", line 409, in detect_encoding if first.startswith(BOM_UTF8): TypeError: startswith first arg must be str or a tuple of str, not bytes One or both of those locations in the code is wrong. Either `read_or_stop` should never return a byte string; or `detect_encoding` should not assume it can call `startswith` on the result. ---------- components: Library (Lib) messages: 234471 nosy: bignose priority: normal severity: normal status: open title: ?tokenize.detect_encoding? is confused between text and bytes: no ?startswith? method on a byte string type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 05:41:05 2015 From: report at bugs.python.org (Ben Finney) Date: Thu, 22 Jan 2015 04:41:05 +0000 Subject: =?utf-8?b?W2lzc3VlMjMyOTddIOKAmHRva2VuaXplLmRldGVjdF9lbmNvZGluZ+KAmSBp?= =?utf-8?q?s_confused_between_text_and_bytes=3A_no_=E2=80=98startswith?= =?utf-8?q?=E2=80=99_method_on_a_byte_string?= In-Reply-To: <1421901626.89.0.392776519963.issue23297@psf.upfronthosting.co.za> Message-ID: <1421901665.58.0.699985983944.issue23297@psf.upfronthosting.co.za> Ben Finney added the comment: Possibly related to issue9969. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 05:58:02 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 22 Jan 2015 04:58:02 +0000 Subject: =?utf-8?b?W2lzc3VlMjMyOTZdIOKAmHRva2VuaXplLmRldGVjdF9lbmNvZGluZ+KAmSBp?= =?utf-8?q?s_confused_between_text_and_bytes=3A_no_=E2=80=98startswith?= =?utf-8?q?=E2=80=99_method_on_a_byte_string?= In-Reply-To: <1421901612.51.0.543377948137.issue23296@psf.upfronthosting.co.za> Message-ID: <1421902682.87.0.247345270683.issue23296@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> duplicate status: open -> closed superseder: -> ?tokenize.detect_encoding? is confused between text and bytes: no ?startswith? method on a byte string _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 06:20:03 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 22 Jan 2015 05:20:03 +0000 Subject: [issue17776] IDLE Internationalization In-Reply-To: <1366207983.79.0.104817094716.issue17776@psf.upfronthosting.co.za> Message-ID: <1421904003.03.0.907406797335.issue17776@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I answered my Q1 in msg187219: test.test_gettest is currently passing, with no skips, on 2.7 and 3.4 on Win 7. patch.diff: I would rather add the 4 lines of the proposed idle_i18n.py to an existing module, perhaps Bindings.py itself, since that is the first place _ will be used. I think +-60 modules is already too many. The binding of '_' to gettext.gettext conflicts with the somewhat common use of '_' as a dummy identifier. I do not know of any such uses in idlelib, but there might be. There are about 4500 lines in idlelib with '_'; too many to review. Someone should do a more refined search with an re that excludes '_' preceded or followed by an identifier char, to skip '__xyz__' or '_x' or 'y_'. If '_ is used for gettest, a new rule to not otherwise bind '_' should be added the currently non-existent Idle maintainer guide. patch2.tar.gz is not readable by Rietveld, Firefox, IE, or Windows. Patches should be uploaded as plaintext.diff or .patch. Damien: Contributors must submit a signed Contributor Agreement. See https://www.python.org/psf/contrib/ and https://www.python.org/psf/contrib/contrib-form/ (the online form). Please do this even before re-uploading patch2. Receipt and acceptance of a form is acknowledged by addition of an * after "Author: nick(real name)". ---------- versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 06:29:07 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 22 Jan 2015 05:29:07 +0000 Subject: =?utf-8?b?W2lzc3VlMjMyOTddIOKAmHRva2VuaXplLmRldGVjdF9lbmNvZGluZ+KAmSBp?= =?utf-8?q?s_confused_between_text_and_bytes=3A_no_=E2=80=98startswith?= =?utf-8?q?=E2=80=99_method_on_a_byte_string?= In-Reply-To: <1421901626.89.0.392776519963.issue23297@psf.upfronthosting.co.za> Message-ID: <1421904547.94.0.433441186024.issue23297@psf.upfronthosting.co.za> R. David Murray added the comment: bytes does support startswith: >>> b'abc'.startswith(b'a') True ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 06:41:53 2015 From: report at bugs.python.org (dongwm) Date: Thu, 22 Jan 2015 05:41:53 +0000 Subject: [issue23298] Add ArgumentParser.add_mutually_dependence_group Message-ID: <1421905312.49.0.407798450784.issue23298@psf.upfronthosting.co.za> New submission from dongwm: Sometimes I need to use argparse like this: >>> parser = argparse.ArgumentParser(prog='PROG') >>> group = parser.add_mutually_dependence_group() >>> group.add_argument('--foo') >>> group.add_argument('--bar') >>> parser.parse_args(['--foo', 'f', '--bar', 'b']) Namespace(bar='b', foo='f') >>> parser.parse_args(['--foo', 'f']) PROG: error: --foo dependence on --bar >>> parser.parse_args(['--bar', 'b']) PROG: error: --bar dependence on --foo I have some optional argument. but if any argument in a group was present on the command line. i need the others must also was present on. so i think ``add_mutually_dependence_group`` does make sense. ---------- components: Library (Lib) files: argparse_lib.patch keywords: patch messages: 234475 nosy: bethard, dongwm priority: normal severity: normal status: open title: Add ArgumentParser.add_mutually_dependence_group type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37814/argparse_lib.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 06:43:46 2015 From: report at bugs.python.org (dongwm) Date: Thu, 22 Jan 2015 05:43:46 +0000 Subject: [issue23298] Add ArgumentParser.add_mutually_dependence_group In-Reply-To: <1421905312.49.0.407798450784.issue23298@psf.upfronthosting.co.za> Message-ID: <1421905426.16.0.491756170408.issue23298@psf.upfronthosting.co.za> Changes by dongwm : Added file: http://bugs.python.org/file37815/argparse_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 06:48:29 2015 From: report at bugs.python.org (dongwm) Date: Thu, 22 Jan 2015 05:48:29 +0000 Subject: [issue23298] Add ArgumentParser.add_mutually_dependence_group In-Reply-To: <1421905312.49.0.407798450784.issue23298@psf.upfronthosting.co.za> Message-ID: <1421905709.1.0.363322045973.issue23298@psf.upfronthosting.co.za> Changes by dongwm : Added file: http://bugs.python.org/file37816/argparse_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 07:05:56 2015 From: report at bugs.python.org (Andy Zobro) Date: Thu, 22 Jan 2015 06:05:56 +0000 Subject: [issue14910] argparse: disable abbreviation In-Reply-To: <1337943742.57.0.897347214609.issue14910@psf.upfronthosting.co.za> Message-ID: <1421906756.5.0.425787899136.issue14910@psf.upfronthosting.co.za> Andy Zobro added the comment: This breaks custom actions. e.g.: class dict_action(argparse.Action): def __init__(self, *a, **k): argparse.Action.__init__(self, *a, **k) TypeError: __init__() got an unexpected keyword argument 'allow_abbrev' ---------- nosy: +xobes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 07:12:42 2015 From: report at bugs.python.org (Andy Zobro) Date: Thu, 22 Jan 2015 06:12:42 +0000 Subject: [issue14910] argparse: disable abbreviation In-Reply-To: <1337943742.57.0.897347214609.issue14910@psf.upfronthosting.co.za> Message-ID: <1421907162.36.0.897905773365.issue14910@psf.upfronthosting.co.za> Andy Zobro added the comment: Ignore previous comment, I wish I could delete it. I simply provided the allow_abbrev to the wrong function and spent zero time investigating the error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 08:28:38 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 22 Jan 2015 07:28:38 +0000 Subject: [issue23154] MSVC 2013 Express needlessly rebuilds code In-Reply-To: <1420288103.47.0.693564742808.issue23154@psf.upfronthosting.co.za> Message-ID: <1421911718.67.0.707615124045.issue23154@psf.upfronthosting.co.za> Mark Lawrence added the comment: I've noticed a similar problem this morning with 5 modules rebuilt under Debug but 29 under Release. I believe the change that triggered me spotting it is this fb8a093db8b1 Issue #23095. Do we need a new issue for this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 09:01:24 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 22 Jan 2015 08:01:24 +0000 Subject: [issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture In-Reply-To: <1419122866.29.0.725788641938.issue23095@psf.upfronthosting.co.za> Message-ID: <1421913684.89.0.450899242919.issue23095@psf.upfronthosting.co.za> STINNER Victor added the comment: test_asyncio hangs on "AMD64 Windows7 SP1 3.x" buildbot: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/5562 The most significant change of this build is the changeset d3804307cce4: "IocpProactor.close() must not cancel pending _WaitCancelFuture futures". [391/391] test_asyncio Timeout (1:00:00)! Current thread 0x000013f8 (most recent call first): File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\asyncio\windows_events.py", line 617 in _unregister File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\asyncio\windows_events.py", line 193 in _unregister_wait_cb File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\asyncio\windows_events.py", line 209 in _unregister_wait File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\asyncio\windows_events.py", line 152 in set_result File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\asyncio\windows_events.py", line 671 in _poll File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\asyncio\windows_events.py", line 386 in select File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\asyncio\base_events.py", line 1081 in _run_once File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\asyncio\base_events.py", line 258 in run_forever File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\asyncio\base_events.py", line 286 in run_until_complete File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_asyncio\test_events.py", line 1695 in test_subprocess_stderr_redirect_to_stdout File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\case.py", line 577 in run File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\case.py", line 625 in __call__ File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 125 in run File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 87 in __call__ File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 125 in run File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 87 in __call__ File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 125 in run File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 87 in __call__ File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 125 in run File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 87 in __call__ File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 125 in run File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 87 in __call__ File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\runner.py", line 168 in run File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 1770 in _run_suite File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 1804 in run_unittest File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\regrtest.py", line 1283 in test_runner File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\regrtest.py", line 1284 in runtest_inner File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\regrtest.py", line 967 in runtest File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\regrtest.py", line 532 in main File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\regrtest.py", line 1568 in main_in_temp_cwd File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\regrtest.py", line 1593 in File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\runpy.py", line 85 in _run_code File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\runpy.py", line 170 in _run_module_as_main ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 09:09:46 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 22 Jan 2015 08:09:46 +0000 Subject: [issue23009] selectors.EpollSelector.select raises exception when nothing to select. In-Reply-To: <1418035005.39.0.294462650059.issue23009@psf.upfronthosting.co.za> Message-ID: <20150122080931.93177.30717@psf.io> Roundup Robot added the comment: New changeset d3a27a27e008 by Victor Stinner in branch '3.4': Issue #23009: Skip test_selectors.test_empty_select() on Windows https://hg.python.org/cpython/rev/d3a27a27e008 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 09:13:01 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 22 Jan 2015 08:13:01 +0000 Subject: =?utf-8?b?W2lzc3VlMjMyOTddIOKAmHRva2VuaXplLmRldGVjdF9lbmNvZGluZ+KAmSBp?= =?utf-8?q?s_confused_between_text_and_bytes=3A_no_=E2=80=98startswith?= =?utf-8?q?=E2=80=99_method_on_a_byte_string?= In-Reply-To: <1421901626.89.0.392776519963.issue23297@psf.upfronthosting.co.za> Message-ID: <1421914381.84.0.988895609374.issue23297@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't understand why do you consider that this issue is a bug. Can you show an example where detect_encoding() raises an exception? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 09:16:53 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 22 Jan 2015 08:16:53 +0000 Subject: [issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture In-Reply-To: <1419122866.29.0.725788641938.issue23095@psf.upfronthosting.co.za> Message-ID: <1421914613.45.0.398766405876.issue23095@psf.upfronthosting.co.za> STINNER Victor added the comment: A different hang on "AMD64 Windows7 SP1 3.4/" buildbot: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.4/builds/805/steps/test/logs/stdio This build is also related to the changeset d3804307cce44f7f02e38166daf6d8227aa45021: "IocpProactor.close() must not cancel pending _WaitCancelFuture futures". IMO it's not a new bug, it's just that it was not seen before. I may be related to the issue #23293. [390/390/1] test_asyncio Timeout (1:00:00)! Current thread 0x000005c8 (most recent call first): File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\asyncio\windows_events.py", line 620 in _unregister File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\asyncio\windows_events.py", line 196 in _unregister_wait_cb File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\asyncio\windows_events.py", line 212 in _unregister_wait File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\asyncio\windows_events.py", line 152 in set_result File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\asyncio\windows_events.py", line 674 in _poll File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\asyncio\windows_events.py", line 389 in select File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\asyncio\base_events.py", line 1081 in _run_once File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\asyncio\base_events.py", line 258 in run_forever File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\asyncio\base_events.py", line 286 in run_until_complete File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\test\test_asyncio\test_subprocess.py", line 211 in test_pause_reading File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\unittest\case.py", line 577 in run File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\unittest\case.py", line 625 in __call__ File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\unittest\suite.py", line 125 in run File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\unittest\suite.py", line 87 in __call__ File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\unittest\suite.py", line 125 in run File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\unittest\suite.py", line 87 in __call__ File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\unittest\suite.py", line 125 in run File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\unittest\suite.py", line 87 in __call__ File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\unittest\suite.py", line 125 in run File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\unittest\suite.py", line 87 in __call__ File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\unittest\runner.py", line 168 in run File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\test\support\__init__.py", line 1769 in _run_suite File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\test\support\__init__.py", line 1803 in run_unittest File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\test\regrtest.py", line 1279 in test_runner File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\test\regrtest.py", line 1280 in runtest_inner File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\test\regrtest.py", line 967 in runtest File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\test\regrtest.py", line 532 in main File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\test\regrtest.py", line 1564 in main_in_temp_cwd File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\test\regrtest.py", line 1589 in File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\runpy.py", line 85 in _run_code File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\runpy.py", li ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 09:19:39 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 22 Jan 2015 08:19:39 +0000 Subject: [issue23295] [Windows] asyncio: add UDP support to ProactorEventLoop In-Reply-To: <1421883613.58.0.0395481360088.issue23295@psf.upfronthosting.co.za> Message-ID: <1421914779.75.0.726727400014.issue23295@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 09:27:20 2015 From: report at bugs.python.org (Neil Girdhar) Date: Thu, 22 Jan 2015 08:27:20 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421915240.02.0.941861647205.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: BUILD_MAP(n) ---------- Added file: http://bugs.python.org/file37817/starunpack14.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 09:36:20 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 22 Jan 2015 08:36:20 +0000 Subject: [issue23009] selectors.EpollSelector.select raises exception when nothing to select. In-Reply-To: <1418035005.39.0.294462650059.issue23009@psf.upfronthosting.co.za> Message-ID: <20150122083603.34206.84045@psf.io> Roundup Robot added the comment: New changeset 4f928c70f135 by Victor Stinner in branch '3.4': Issue #23009: Add missing "import sys" in test_selectors https://hg.python.org/cpython/rev/4f928c70f135 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 09:53:41 2015 From: report at bugs.python.org (Liang Zhang) Date: Thu, 22 Jan 2015 08:53:41 +0000 Subject: [issue23299] Documentation correction - 5.1.4. List Comprehensions Message-ID: <1421916821.61.0.582688428376.issue23299@psf.upfronthosting.co.za> New submission from Liang Zhang: This was copied from Chapter 5 Data Structure in Python language tutorial. The link I was looking for: https://docs.python.org/2.7/tutorial/datastructures.html Some thing might be incorrect and need you to update them in (5.1.4. List Comprehensions) It should be like this: ------------------start------------------ >>> vec = [-4, -2, 0, 2, 4] >>> # create a new list with the values doubled >>> [x*2 for x in vec] [-8, -4, 0, 4, 8] >>> # filter the list to exclude negative numbers >>> [x for x in vec if x >= 0] [0, 2, 4] >>> # apply a function to all the elements >>> [abs(x) for x in vec] [4, 2, 0, 2, 4] >>>>>>>>>>>It should be [0, 2, 4]<<<<<<<<<<< ------------------end------------------ ---------- assignee: docs at python components: Documentation messages: 234485 nosy: Liang.Zhang, docs at python priority: normal severity: normal status: open title: Documentation correction - 5.1.4. List Comprehensions type: resource usage versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 10:20:16 2015 From: report at bugs.python.org (Claudiu Popa) Date: Thu, 22 Jan 2015 09:20:16 +0000 Subject: [issue23078] unittest.mock patch autospec doesn't work on staticmethods In-Reply-To: <1418892323.1.0.910322233262.issue23078@psf.upfronthosting.co.za> Message-ID: <1421918416.21.0.567032857706.issue23078@psf.upfronthosting.co.za> Claudiu Popa added the comment: Here's a patch which does this. One problem could be that staticmethod(some_callable) or classmethod(some_callable) aren't callable per se, but given the fact that users expects Foo.staticmethod or Foo.klassmethod to be callable when patching them, it's something we should consider for fixing. ---------- components: +Library (Lib) -Tests keywords: +patch nosy: +Claudiu.Popa stage: -> patch review Added file: http://bugs.python.org/file37818/issue23078.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 10:39:13 2015 From: report at bugs.python.org (Claudiu Popa) Date: Thu, 22 Jan 2015 09:39:13 +0000 Subject: [issue21518] Expose RegUnloadKey in winreg In-Reply-To: <1400346760.52.0.0203244636304.issue21518@psf.upfronthosting.co.za> Message-ID: <1421919553.63.0.34914259616.issue21518@psf.upfronthosting.co.za> Claudiu Popa added the comment: Ups, the last patch included an extra file. ---------- Added file: http://bugs.python.org/file37819/issue21518_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 10:54:52 2015 From: report at bugs.python.org (Claudiu Popa) Date: Thu, 22 Jan 2015 09:54:52 +0000 Subject: [issue21518] Expose RegUnloadKey in winreg In-Reply-To: <1400346760.52.0.0203244636304.issue21518@psf.upfronthosting.co.za> Message-ID: <1421920492.89.0.971451503568.issue21518@psf.upfronthosting.co.za> Changes by Claudiu Popa : Added file: http://bugs.python.org/file37820/issue21518_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 12:02:20 2015 From: report at bugs.python.org (Neil Girdhar) Date: Thu, 22 Jan 2015 11:02:20 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421924540.66.0.0776458342307.issue2292@psf.upfronthosting.co.za> Changes by Neil Girdhar : Removed file: http://bugs.python.org/file37817/starunpack14.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 12:04:01 2015 From: report at bugs.python.org (Neil Girdhar) Date: Thu, 22 Jan 2015 11:04:01 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421924641.42.0.989044196565.issue2292@psf.upfronthosting.co.za> Changes by Neil Girdhar : Added file: http://bugs.python.org/file37821/starunpack14.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 12:05:55 2015 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 22 Jan 2015 11:05:55 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421924755.08.0.438950797043.issue2292@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: -giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 12:50:08 2015 From: report at bugs.python.org (Guohua Ouyang) Date: Thu, 22 Jan 2015 11:50:08 +0000 Subject: [issue23300] An improper change in httplib.py Message-ID: <1421927408.72.0.18242677241.issue23300@psf.upfronthosting.co.za> New submission from Guohua Ouyang: Following the issue 7776, there is a patch for 2.7 version. Which changes the method of class HTTPConnection from "_set_hostport" to "_get_hostport"[1], it seems introduce in some incompatibility issues. On my system, the file "/usr/lib64/python2.7/site-packages/mercurial/url.py" from package mercurial-3.0-2.fc21 still use the old method "_set_hostport". I met an error "AttributeError: httpsconnection instance has no attribute '_set_hostport'" when use this package. I only see this incompatibility issue so far. And in the file httplib.py itself, [2] still use "self._conn._set_hostport(host, port)", which should be "self._conn._get_hostport(host, port)" if it's settled to rename "_set_hostport" to "_get_hostport". [1] https://github.com/python/cpython/blob/2.7/Lib/httplib.py#L743 [2] https://github.com/python/cpython/blob/2.7/Lib/httplib.py#L1132 ---------- components: Library (Lib) messages: 234488 nosy: guohua priority: normal severity: normal status: open title: An improper change in httplib.py type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 13:14:58 2015 From: report at bugs.python.org (Neil Girdhar) Date: Thu, 22 Jan 2015 12:14:58 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421928898.2.0.0223945792344.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: By the way, Joshua if you wanted to edit the text of the PEP, it might be nice to point out that this replaces itertools.chain.from_iterable. I know you mention one use of itertools.chain, but I think this nicely replaces all uses of both: itertools.chain(a, b, c) is (*x for x in [a, b, c]) itertools.chain.from_iterable(it) is (*x for x in it) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 13:45:52 2015 From: report at bugs.python.org (Martijn Pieters) Date: Thu, 22 Jan 2015 12:45:52 +0000 Subject: [issue7334] ElementTree: file locking in Jython 2.5 (OSError on Windows) In-Reply-To: <1258386968.95.0.507644857951.issue7334@psf.upfronthosting.co.za> Message-ID: <1421930752.62.0.972932581212.issue7334@psf.upfronthosting.co.za> Martijn Pieters added the comment: Indeed, the 2.7 backport was not correctly applied for _elementtree.c, leaving files open because the close_source flag is set to False *again* when opening a filename. Should a new issue be opened or should this ticket be re-opened? ---------- nosy: +mjpieters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 14:30:31 2015 From: report at bugs.python.org (aruseni) Date: Thu, 22 Jan 2015 13:30:31 +0000 Subject: [issue23294] A typo in the tutorial In-Reply-To: <1421879644.03.0.144985173362.issue23294@psf.upfronthosting.co.za> Message-ID: <1421933431.38.0.416887838353.issue23294@psf.upfronthosting.co.za> aruseni added the comment: @Eric You?re right. I thought it should be ?was? instead of ?is?, but it?s actually OK. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 15:10:17 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 22 Jan 2015 14:10:17 +0000 Subject: [issue23154] MSVC 2013 Express needlessly rebuilds code In-Reply-To: <1420288103.47.0.693564742808.issue23154@psf.upfronthosting.co.za> Message-ID: <1421935817.67.0.786366159262.issue23154@psf.upfronthosting.co.za> Steve Dower added the comment: That change modified pythoncore, so I'd expect to see most projects rebuild. Especially under Release, where we don't have some of the build optimizations enabled (because they hurt runtime performance). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 15:32:44 2015 From: report at bugs.python.org (Joshua Landau) Date: Thu, 22 Jan 2015 14:32:44 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421937164.05.0.398990033932.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: I've looked at BUILD_MAP(n). It seems to work and has speed improvements but: - I was wrong about the 16-bit int thing. It turns out CPython is happily treating them as 32 bit as long as they are prefixed by an EXTENDED_ARG bytecode https://docs.python.org/3/library/dis.html#opcode-EXTENDED_ARG This could be used by BUILD_MAP rather than falling back to BUILD_MAP_UNPACK. - It's probably best to not include it here, since it's a disjoint issue. This patch wouldn't really be affected by its absence. Also, if we limit BUILD_MAP_MERGE to 255 dictionaries, this will also apply to the {**a, **b, **c, ...} syntax, although I really can't see it being a problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 15:38:23 2015 From: report at bugs.python.org (Brett Cannon) Date: Thu, 22 Jan 2015 14:38:23 +0000 Subject: [issue23300] An improper change in httplib.py In-Reply-To: <1421927408.72.0.18242677241.issue23300@psf.upfronthosting.co.za> Message-ID: <1421937503.5.0.058211829201.issue23300@psf.upfronthosting.co.za> Brett Cannon added the comment: That leading underscore in the method name means it is not a public API and thus changes are allowed without any backwards-compatibility guarantees. Mercurial will need to update their code to handle this if they want to continue to use the method. ---------- nosy: +brett.cannon resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 16:38:13 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 22 Jan 2015 15:38:13 +0000 Subject: [issue23298] Add ArgumentParser.add_mutually_dependence_group In-Reply-To: <1421905312.49.0.407798450784.issue23298@psf.upfronthosting.co.za> Message-ID: <1421941093.55.0.228491975305.issue23298@psf.upfronthosting.co.za> R. David Murray added the comment: Well, it doesn't make much sense in the English language sense. If I got that error message I'd have no idea what was wrong. It sounds like what you want to do is dynamically make some arguments be required, depending on whether or not other arguments are present or not. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 16:39:19 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 22 Jan 2015 15:39:19 +0000 Subject: [issue23298] Add ArgumentParser.add_mutually_dependence_group In-Reply-To: <1421905312.49.0.407798450784.issue23298@psf.upfronthosting.co.za> Message-ID: <1421941159.66.0.643431645891.issue23298@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 16:43:40 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 22 Jan 2015 15:43:40 +0000 Subject: [issue23299] Documentation correction - 5.1.4. List Comprehensions In-Reply-To: <1421916821.61.0.582688428376.issue23299@psf.upfronthosting.co.za> Message-ID: <1421941420.37.0.6573240614.issue23299@psf.upfronthosting.co.za> R. David Murray added the comment: vec has not been changed. The example is correct. Give it a try :) ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed type: resource usage -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 16:58:05 2015 From: report at bugs.python.org (Sebastian Bank) Date: Thu, 22 Jan 2015 15:58:05 +0000 Subject: [issue23301] ConfigParser does not handle square brackets in section name Message-ID: <1421942285.34.0.084703922586.issue23301@psf.upfronthosting.co.za> New submission from Sebastian Bank: ConfigParser parses section lines containing square brackets like '[spam [eggs] spam]' up to the first instead of the last occurrence of ']' preventing roundtrips: >>> s = StringIO() >>> c1 = ConfigParser() >>> c1.add_section('spam [eggs]') >>> c1.write(s) >>> s.seek(0) >>> c2 = ConfigParser() >>> c2.readfp(s) >>> assert c1.sections() == c2.sections() # fails Potential fix: change the second line of SECTCRE from r'(?P
[^]]+)' to r'(?P
.+?)'. If the parsing behaviour cannot be changed, the user should at least be warned about supplying data that breaks the roundtrip. ---------- components: Library (Lib) messages: 234497 nosy: xflr6 priority: normal severity: normal status: open title: ConfigParser does not handle square brackets in section name type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 17:06:52 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 22 Jan 2015 16:06:52 +0000 Subject: [issue23301] ConfigParser does not handle square brackets in section name In-Reply-To: <1421942285.34.0.084703922586.issue23301@psf.upfronthosting.co.za> Message-ID: <1421942812.21.0.634443666907.issue23301@psf.upfronthosting.co.za> R. David Murray added the comment: This is a duplicate of issue 20923, which was rejected. To argue against the rejection you probably need to provide evidence that this is something that is actually supported by other common ini parsers. And that evidence should be posted to issue 20923. ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> ConfigParser should nested [] in section names. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 17:52:56 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 22 Jan 2015 16:52:56 +0000 Subject: [issue23300] An improper change in httplib.py In-Reply-To: <1421927408.72.0.18242677241.issue23300@psf.upfronthosting.co.za> Message-ID: <1421945576.94.0.931047385097.issue23300@psf.upfronthosting.co.za> Mark Lawrence added the comment: This is a bug first reported here https://mail.python.org/pipermail/python-list/2015-January/697228.html. The problem is that in #7776 r90728 568041fd8090 _set_hostport was renamed to _get_hostport but there is still a call to the former at line 1132 in httplib.py. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 18:00:35 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 22 Jan 2015 17:00:35 +0000 Subject: [issue23302] Small fixes around the use of TCP MSS in http.client Message-ID: <1421946035.45.0.334946806325.issue23302@psf.upfronthosting.co.za> New submission from Demian Brecht: There are a couple of small issues with the determination of whether or not a request can fit in a single TCP/IP packet in http.client. 1. The MSS is hardcoded 2. The TCP data size is calculated as only the message body. This is incorrect as the size of the HTTP headers should also be accounted for. I suggest two changes be made to fix this: 1. The MSS is retrieved (on platforms that support it) using getsockopt(socket.IPPROTO_TCP, socket.TCP_MAXSEG). If the platform doesn't support it (i.e. Windows), it should default to the currently hardcoded value. This does add a requirement for a connection to be established prior to this calculation (currently the connection is only established after). 2. The HTTP headers are added to the full payload size calculation when compared against the connection's MSS value. This is still a best guess based on minimal TCP/IP header sizes, but if options or extension headers are used, the packet may still be split at the lower levels. This is fine because what we're trying to avoid is multiple send()s where the payload is less than the MSS. ---------- messages: 234500 nosy: demian.brecht priority: normal severity: normal status: open title: Small fixes around the use of TCP MSS in http.client _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 18:01:33 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 22 Jan 2015 17:01:33 +0000 Subject: [issue23078] unittest.mock patch autospec doesn't work on staticmethods In-Reply-To: <1418892323.1.0.910322233262.issue23078@psf.upfronthosting.co.za> Message-ID: <1421946093.42.0.631436681069.issue23078@psf.upfronthosting.co.za> Berker Peksag added the comment: Looks like b6ea3dc89a78 is not a valid changeset. Could you attach a patch from the Mercurial repo? ---------- nosy: +berker.peksag versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 18:02:27 2015 From: report at bugs.python.org (Claudiu Popa) Date: Thu, 22 Jan 2015 17:02:27 +0000 Subject: [issue23078] unittest.mock patch autospec doesn't work on staticmethods In-Reply-To: <1418892323.1.0.910322233262.issue23078@psf.upfronthosting.co.za> Message-ID: <1421946147.38.0.588264823858.issue23078@psf.upfronthosting.co.za> Claudiu Popa added the comment: Ups, sorry about that, I'll update the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 18:02:39 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 22 Jan 2015 17:02:39 +0000 Subject: [issue23302] Small fixes around the use of TCP MSS in http.client In-Reply-To: <1421946035.45.0.334946806325.issue23302@psf.upfronthosting.co.za> Message-ID: <1421946159.71.0.28616830815.issue23302@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- components: +Library (Lib) keywords: +patch versions: +Python 3.5 Added file: http://bugs.python.org/file37822/issue23302.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 18:05:21 2015 From: report at bugs.python.org (Claudiu Popa) Date: Thu, 22 Jan 2015 17:05:21 +0000 Subject: [issue23078] unittest.mock patch autospec doesn't work on staticmethods In-Reply-To: <1418892323.1.0.910322233262.issue23078@psf.upfronthosting.co.za> Message-ID: <1421946321.76.0.882424031124.issue23078@psf.upfronthosting.co.za> Changes by Claudiu Popa : Added file: http://bugs.python.org/file37823/issue23078.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 18:12:34 2015 From: report at bugs.python.org (Cory Benfield) Date: Thu, 22 Jan 2015 17:12:34 +0000 Subject: [issue20188] ALPN support for TLS In-Reply-To: <1389153179.88.0.510995543218.issue20188@psf.upfronthosting.co.za> Message-ID: <1421946754.44.0.0769799035039.issue20188@psf.upfronthosting.co.za> Cory Benfield added the comment: Updating to note that OpenSSL 1.0.2 has been released[0], which makes this feature supportable. [0]: https://mta.openssl.org/pipermail/openssl-announce/2015-January/000019.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 18:45:42 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 22 Jan 2015 17:45:42 +0000 Subject: [issue23300] An improper change in httplib.py In-Reply-To: <1421927408.72.0.18242677241.issue23300@psf.upfronthosting.co.za> Message-ID: <1421948742.25.0.163649692205.issue23300@psf.upfronthosting.co.za> Benjamin Peterson added the comment: There's definitely a bug because httplib is now using a method that doesn't exist. ---------- nosy: +benjamin.peterson, orsenthil resolution: wont fix -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 19:09:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 22 Jan 2015 18:09:25 +0000 Subject: [issue23300] httplib is using a method that doesn't exist In-Reply-To: <1421927408.72.0.18242677241.issue23300@psf.upfronthosting.co.za> Message-ID: <1421950165.52.0.431029988392.issue23300@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +nikratio, serhiy.storchaka stage: -> needs patch title: An improper change in httplib.py -> httplib is using a method that doesn't exist type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 19:14:36 2015 From: report at bugs.python.org (Senthil Kumaran) Date: Thu, 22 Jan 2015 18:14:36 +0000 Subject: [issue23300] httplib is using a method that doesn't exist In-Reply-To: <1421927408.72.0.18242677241.issue23300@psf.upfronthosting.co.za> Message-ID: <1421950476.92.0.767321652972.issue23300@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Ouch. Will fix this today. Strange, I think, no coverage exists for that and it has escaped our testing. ---------- assignee: -> orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 19:36:00 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 22 Jan 2015 18:36:00 +0000 Subject: [issue7334] ElementTree: file locking in Jython 2.5 (OSError on Windows) In-Reply-To: <1258386968.95.0.507644857951.issue7334@psf.upfronthosting.co.za> Message-ID: <1421951760.3.0.000775694149364.issue7334@psf.upfronthosting.co.za> Berker Peksag added the comment: > Should a new issue be opened or should this ticket be re-opened? It's a 3 years old backport, I'd say open a new issue. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 19:36:06 2015 From: report at bugs.python.org (Alessio) Date: Thu, 22 Jan 2015 18:36:06 +0000 Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings In-Reply-To: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za> Message-ID: <1421951766.55.0.761244438107.issue11024@psf.upfronthosting.co.za> Alessio added the comment: Not working patch, if I use this method on append I've all messages with 1970 year ---------- nosy: +Pilessio _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 19:41:44 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 22 Jan 2015 18:41:44 +0000 Subject: [issue23300] httplib is using a method that doesn't exist In-Reply-To: <1421927408.72.0.18242677241.issue23300@psf.upfronthosting.co.za> Message-ID: <1421952104.73.0.398259905041.issue23300@psf.upfronthosting.co.za> Demian Brecht added the comment: @Senthil: If you're fixing this today, can you also correct the typo here: https://hg.python.org/cpython/rev/568041fd8090/#l1.27 (s/HTML/HTTP)? Just caught my eye going through the review that Mark linked. ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 19:43:42 2015 From: report at bugs.python.org (Senthil Kumaran) Date: Thu, 22 Jan 2015 18:43:42 +0000 Subject: [issue23300] httplib is using a method that doesn't exist In-Reply-To: <1421927408.72.0.18242677241.issue23300@psf.upfronthosting.co.za> Message-ID: <1421952222.98.0.431832684071.issue23300@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Demian, sure, will do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 21:54:12 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 22 Jan 2015 20:54:12 +0000 Subject: [issue23302] Small fixes around the use of TCP MSS in http.client In-Reply-To: <1421946035.45.0.334946806325.issue23302@psf.upfronthosting.co.za> Message-ID: <1421960052.91.0.178114137712.issue23302@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 22:30:03 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 22 Jan 2015 21:30:03 +0000 Subject: [issue23303] test_license_exists_at_url() of test_site fails on "x86 XP-4 3.4" buildbot Message-ID: <1421962203.05.0.381123323956.issue23303@psf.upfronthosting.co.za> New submission from STINNER Victor: test_license_exists_at_url() of test_site fails on "x86 XP-4 3.4" buildbot. I don't understand why the test pass on "x86 XP-4 3.x", is it the same server? http://buildbot.python.org/all/builders/x86%20XP-4%203.4/builds/747/steps/test/logs/stdio ====================================================================== ERROR: test_license_exists_at_url (test.test_site.ImportSideEffectTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\urllib\request.py", line 1182, in do_open h.request(req.get_method(), req.selector, req.data, headers) File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\http\client.py", line 1088, in request self._send_request(method, url, body, headers) File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\http\client.py", line 1126, in _send_request self.endheaders(body) File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\http\client.py", line 1084, in endheaders self._send_output(message_body) File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\http\client.py", line 922, in _send_output self.send(msg) File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\http\client.py", line 857, in send self.connect() File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\http\client.py", line 1231, in connect server_hostname=server_hostname) File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\ssl.py", line 365, in wrap_socket _context=self) File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\ssl.py", line 583, in __init__ self.do_handshake() File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\ssl.py", line 810, in do_handshake self._sslobj.do_handshake() ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:600) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\test\test_site.py", line 426, in test_license_exists_at_url with urllib.request.urlopen(req) as data: File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\urllib\request.py", line 161, in urlopen return opener.open(url, data, timeout) File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\urllib\request.py", line 469, in open response = meth(req, response) File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\urllib\request.py", line 579, in http_response 'http', request, response, code, msg, hdrs) File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\urllib\request.py", line 501, in error result = self._call_chain(*args) File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\urllib\request.py", line 441, in _call_chain result = func(*args) File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\urllib\request.py", line 684, in http_error_302 return self.parent.open(new, timeout=req.timeout) File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\urllib\request.py", line 463, in open response = self._open(req, data) File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\urllib\request.py", line 481, in _open '_open', req) File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\urllib\request.py", line 441, in _call_chain result = func(*args) File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\urllib\request.py", line 1225, in https_open context=self._context, check_hostname=self._check_hostname) File "D:\cygwin\home\db3l\buildarea\3.4.bolen-windows\build\lib\urllib\request.py", line 1184, in do_open raise URLError(err) urllib.error.URLError: ---------- components: Tests keywords: buildbot messages: 234510 nosy: alex, haypo, pitrou priority: normal severity: normal status: open title: test_license_exists_at_url() of test_site fails on "x86 XP-4 3.4" buildbot versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 22:37:35 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 22 Jan 2015 21:37:35 +0000 Subject: [issue23303] test_license_exists_at_url() of test_site fails on "x86 XP-4 3.4" buildbot In-Reply-To: <1421962203.05.0.381123323956.issue23303@psf.upfronthosting.co.za> Message-ID: <1421962655.82.0.214398392898.issue23303@psf.upfronthosting.co.za> STINNER Victor added the comment: The URL is http://www.python.org/psf/license/ wget tells me that the URL is directed to https://www.python.org/psf/license/ which is redirected to https://docs.python.org/license.html which is redirected to https://docs.python.org/2/license.html. According to Firefox, docs.python.org uses a certificate signed by "DigiCert Inc" with the CN "www.python.org" (hum, it should not be "docs.python.org" ?). Same failure on "x86 Windows7 3.4": http://buildbot.python.org/all/builders/x86%20Windows7%203.4/builds/713/steps/test/logs/stdio And "x86 Ubuntu Shared 3.4": http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.4/builds/795/steps/test/logs/stdio ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 22:42:08 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 22 Jan 2015 21:42:08 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <1420230232.09.0.10127303351.issue23152@psf.upfronthosting.co.za> Message-ID: <1421962928.43.0.963134899607.issue23152@psf.upfronthosting.co.za> STINNER Victor added the comment: > Currently test_largefile is failing on the Windows buildbots Oh yes, I just noticed the following bug on "AMD64 Windows8 3.x": http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x/builds/307/steps/test/logs/stdio [352/391/1] test_largefile Assertion failed: (result != NULL && !PyErr_Occurred()) || (result == NULL && PyErr_Occurred()), file ..\Objects\abstract.c, line 2095 R6010 - abort() has been called Fatal Python error: Aborted Current thread 0x00000ec8 (most recent call first): File "D:\buildarea\3.x.bolen-windows8\build\lib\test\test_largefile.py", line 83 in test_lseek File "D:\buildarea\3.x.bolen-windows8\build\lib\unittest\case.py", line 577 in run File "D:\buildarea\3.x.bolen-windows8\build\lib\unittest\case.py", line 625 in __call__ File "D:\buildarea\3.x.bolen-windows8\build\lib\unittest\suite.py", line 125 in run File "D:\buildarea\3.x.bolen-windows8\build\lib\unittest\suite.py", line 87 in __call__ File "D:\buildarea\3.x.bolen-windows8\build\lib\unittest\suite.py", line 125 in run File "D:\buildarea\3.x.bolen-windows8\build\lib\unittest\suite.py", line 87 in __call__ File "D:\buildarea\3.x.bolen-windows8\build\lib\unittest\suite.py", line 125 in run File "D:\buildarea\3.x.bolen-windows8\build\lib\unittest\suite.py", line 87 in __call__ File "D:\buildarea\3.x.bolen-windows8\build\lib\unittest\runner.py", line 168 in run File "D:\buildarea\3.x.bolen-windows8\build\lib\test\support\__init__.py", line 1770 in _run_suite File "D:\buildarea\3.x.bolen-windows8\build\lib\test\support\__init__.py", line 1804 in run_unittest File "D:\buildarea\3.x.bolen-windows8\build\PCbuild\..\lib\test\regrtest.py", line 1283 in test_runner File "D:\buildarea\3.x.bolen-windows8\build\PCbuild\..\lib\test\regrtest.py", line 1284 in runtest_inner File "D:\buildarea\3.x.bolen-windows8\build\PCbuild\..\lib\test\regrtest.py", line 967 in runtest File "D:\buildarea\3.x.bolen-windows8\build\PCbuild\..\lib\test\regrtest.py", line 763 in main File "D:\buildarea\3.x.bolen-windows8\build\PCbuild\..\lib\test\regrtest.py", line 1568 in main_in_temp_cwd File "D:\buildarea\3.x.bolen-windows8\build\PCbuild\..\lib\test\regrtest.py", line 1593 in ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 22:46:50 2015 From: report at bugs.python.org (CliffM) Date: Thu, 22 Jan 2015 21:46:50 +0000 Subject: [issue23304] Unused Superclass in calendar.py Message-ID: <1421963210.26.0.700938779083.issue23304@psf.upfronthosting.co.za> New submission from CliffM: calendar.py ( lines 17,18 ) is not used : # Exception raised for bad input (with string parameter for details) error = ValueError This could either be deleted OR used as the superclass in the next two class declarations as the comment suggests. ---------- components: Library (Lib), Tests messages: 234513 nosy: CliffM priority: normal severity: normal status: open title: Unused Superclass in calendar.py versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 22:52:57 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 22 Jan 2015 21:52:57 +0000 Subject: [issue5309] distutils doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <1421963577.83.0.340075024495.issue5309@psf.upfronthosting.co.za> Berker Peksag added the comment: Here's a doc patch. ---------- nosy: +berker.peksag Added file: http://bugs.python.org/file37824/issue5309-doc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 23:00:42 2015 From: report at bugs.python.org (SilentGhost) Date: Thu, 22 Jan 2015 22:00:42 +0000 Subject: [issue23304] Unused Superclass in calendar.py In-Reply-To: <1421963210.26.0.700938779083.issue23304@psf.upfronthosting.co.za> Message-ID: <1421964042.58.0.526016267038.issue23304@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- keywords: +easy versions: +Python 3.5 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 23:03:59 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 22 Jan 2015 22:03:59 +0000 Subject: [issue23293] [Windows] asyncio: race condition related to IocpProactor.connect_pipe() In-Reply-To: <1421879573.47.0.0852926503812.issue23293@psf.upfronthosting.co.za> Message-ID: <20150122215832.84253.90451@psf.io> Roundup Robot added the comment: New changeset 1e3a1af0705f by Victor Stinner in branch '3.4': Issue #23293, asyncio: Rewrite IocpProactor.connect_pipe() https://hg.python.org/cpython/rev/1e3a1af0705f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 23:05:38 2015 From: report at bugs.python.org (Neil Girdhar) Date: Thu, 22 Jan 2015 22:05:38 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421964338.57.0.387783984458.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: In that case, another option would be to use that to send the "number of maps" to CALL_FUNCTION and let it do the BUILD_MAP_UNPACK stuff itself. Would that simplify your ideas regarding error handling? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 23:05:44 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 22 Jan 2015 22:05:44 +0000 Subject: [issue23293] [Windows] asyncio: race condition related to IocpProactor.connect_pipe() In-Reply-To: <1421879573.47.0.0852926503812.issue23293@psf.upfronthosting.co.za> Message-ID: <1421964344.58.0.770798652689.issue23293@psf.upfronthosting.co.za> STINNER Victor added the comment: Issue fixed: IocpProactor.connect_pipe() doesn't use "blocking" operations anymore, it's now implemented as polling with non blocking operations. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 23:10:43 2015 From: report at bugs.python.org (Joshua Landau) Date: Thu, 22 Jan 2015 22:10:43 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421964643.9.0.120325806652.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: Why would that simplify things? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 23:13:51 2015 From: report at bugs.python.org (Joshua Landau) Date: Thu, 22 Jan 2015 22:13:51 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421964831.04.0.830511020963.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: I phrased that badly. Whilst I can see minor simplifications to BUILD_MAP_UNPACK, the only way to add more information to CALL_FUNCTION_XXX would be through EXTENDED_ARG. This seems like it would outweigh any benefits, and the tiny duplication of error checking removed would be far dwarfed by the unpacking code in CALL_FUNCTION_XXX. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 23:21:33 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 22 Jan 2015 22:21:33 +0000 Subject: [issue21862] cProfile command-line should accept "-m module_name" as an alternative to script path In-Reply-To: <1403640414.18.0.449527177368.issue21862@psf.upfronthosting.co.za> Message-ID: <1421965293.84.0.0662680103304.issue21862@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 23:27:45 2015 From: report at bugs.python.org (Neil Girdhar) Date: Thu, 22 Jan 2015 22:27:45 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421965665.18.0.64031471854.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Sorry, I don't know enough about how you were planning on using the stack pointer difference to produce good errors. I thought that if you waited for the CALL_FUNCTION to be happening before reporting errors about duplicate parameters it might simplify that code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 23:36:02 2015 From: report at bugs.python.org (Joshua Landau) Date: Thu, 22 Jan 2015 22:36:02 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421966162.65.0.666772183716.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: I imagine it like (in the map unpacking code) func_offset = (oparg >> 8) & 0xFF; num_maps = oparg & 0xFF; // later if (func_offset) { // do checks if (repeated_argument) { raise_error_from_function(PEEK(func_offset + num_maps)); } } This code should be relatively quick, in an already-slow opcode, and rather short. If adding to CALL_FUNCTION_XXX, you would have to add an EXTENDED_ARG opcode (because CALL_FUNCTION_XXX already uses the bottom 16 bits), add checks for the top bits in the opcode, duplicate the (large) dictionary merging function. This doesn't seem like it saves much work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 23:42:01 2015 From: report at bugs.python.org (Neil Girdhar) Date: Thu, 22 Jan 2015 22:42:01 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421966521.62.0.382931938744.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Okay, I didn't realize it was so simple to raise the error from somewhere else. Regarding "duplicate the (large) dictionary merging function" ? of course we would just factor it out into a function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 22 23:57:28 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 22 Jan 2015 22:57:28 +0000 Subject: [issue20188] ALPN support for TLS In-Reply-To: <1389153179.88.0.510995543218.issue20188@psf.upfronthosting.co.za> Message-ID: <1421967448.81.0.313871061383.issue20188@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks. Now it needs someone to submit a patch. ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 00:02:45 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 22 Jan 2015 23:02:45 +0000 Subject: [issue23302] Small fixes around the use of TCP MSS in http.client In-Reply-To: <1421946035.45.0.334946806325.issue23302@psf.upfronthosting.co.za> Message-ID: <1421967765.41.0.573288485053.issue23302@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Or we should acknowledge that this is overkill, and take the same approach as all major web browser: disable the Nagle algorithm. For a protocol like http which is transaction oriented it's probably the best thing to do. ---------- nosy: +neologix, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 00:10:19 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 22 Jan 2015 23:10:19 +0000 Subject: [issue23267] multiprocessing pool.py doesn't close inqueue and outqueue pipes on termination In-Reply-To: <1421588019.18.0.707676170756.issue23267@psf.upfronthosting.co.za> Message-ID: <1421968219.35.0.833887970311.issue23267@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Interestingly, there is no close() method on SimpleQueue... ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 00:24:09 2015 From: report at bugs.python.org (Mark Grandi) Date: Thu, 22 Jan 2015 23:24:09 +0000 Subject: [issue23026] Winreg module doesn't support REG_QWORD, small DWORD doc update In-Reply-To: <1418242433.97.0.849861872047.issue23026@psf.upfronthosting.co.za> Message-ID: <1421969049.12.0.941466671246.issue23026@psf.upfronthosting.co.za> Mark Grandi added the comment: I Attempted to modify Reg2Py and Py2Reg to handle the QWORDs, this is assuming that the only thing that needs to change is just using PyLong_AsUnsignedLongLong()/FromUnsignedLongLong() instead of just UnsignedLong() the patch has the same changes as the 'part1' patch + the Py2Reg and Reg2Py changes ---------- Added file: http://bugs.python.org/file37825/winreg_add_qword_constants_part2_markgrandi.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 00:30:20 2015 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 22 Jan 2015 23:30:20 +0000 Subject: [issue23294] A typo in the tutorial In-Reply-To: <1421879644.03.0.144985173362.issue23294@psf.upfronthosting.co.za> Message-ID: <1421969420.84.0.210210931982.issue23294@psf.upfronthosting.co.za> Eric V. Smith added the comment: No problem! Thanks for looking at the documentation with an inquisitive eye. ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 00:41:13 2015 From: report at bugs.python.org (Joshua Landau) Date: Thu, 22 Jan 2015 23:41:13 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421970073.87.0.270399264506.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: We wouldn't actually need to raise it "from" somewhere else; the line numbering and frame are already correct. The only difficulty is that the traceback currently says # func(a=1, **{'a': 1}) TypeError: func() got multiple values for keyword argument 'arg' ???? To do this from the UNPACK opcode would require knowing where the function is in order to print its name. (We also need to know whether to do the check at all, so we'd be hijacking some bits the UNPACK opcode anyway.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 01:18:29 2015 From: report at bugs.python.org (Neil Girdhar) Date: Fri, 23 Jan 2015 00:18:29 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421972309.23.0.299273698714.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: That's true. But wouldn't the offset always be one (or three or whatever) since if we do BUILD_MAP_UNPACK in a function call it's always right before CALL_FUNCTION? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 01:24:16 2015 From: report at bugs.python.org (Joshua Landau) Date: Fri, 23 Jan 2015 00:24:16 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421972656.56.0.312424569768.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: The stack will have the function, then any number of positional arguments, then optionally an *args, then any number (>= 2) of maps to unpack. To get to the function, you need to know the sum count of all of these. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 02:14:47 2015 From: report at bugs.python.org (Neil Girdhar) Date: Fri, 23 Jan 2015 01:14:47 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421975687.37.0.527103202716.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: What do you mean by the stack will "have the function"? At the point that you're doing BUILD_MAP_UNPACK, CALL_FUNCTION hasn't been executed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 02:21:54 2015 From: report at bugs.python.org (Nikolaus Rath) Date: Fri, 23 Jan 2015 01:21:54 +0000 Subject: [issue23300] httplib is using a method that doesn't exist In-Reply-To: <1421927408.72.0.18242677241.issue23300@psf.upfronthosting.co.za> Message-ID: <1421976114.74.0.484353906695.issue23300@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Serhiy, did you add me to Cc just for information, or is there anything I should be doing (having written the patch that introduced this bug)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 02:27:42 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Jan 2015 01:27:42 +0000 Subject: [issue23295] [Windows] asyncio: add UDP support to ProactorEventLoop In-Reply-To: <1421883613.58.0.0395481360088.issue23295@psf.upfronthosting.co.za> Message-ID: <1421976462.43.0.54874761171.issue23295@psf.upfronthosting.co.za> STINNER Victor added the comment: See also https://code.google.com/p/tulip/issues/detail?id=187 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 02:30:22 2015 From: report at bugs.python.org (Liang Zhang) Date: Fri, 23 Jan 2015 01:30:22 +0000 Subject: [issue23299] Documentation correction - 5.1.4. List Comprehensions In-Reply-To: <1421916821.61.0.582688428376.issue23299@psf.upfronthosting.co.za> Message-ID: <1421976622.59.0.289100807072.issue23299@psf.upfronthosting.co.za> Liang Zhang added the comment: Oh my god! You're right! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 02:36:28 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Jan 2015 01:36:28 +0000 Subject: [issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture In-Reply-To: <1419122866.29.0.725788641938.issue23095@psf.upfronthosting.co.za> Message-ID: <1421976988.77.0.597056601217.issue23095@psf.upfronthosting.co.za> STINNER Victor added the comment: Running "runtests.py test_cancel_post_init test_shell" and "runtests.py test_wait_for_handle test_wait_for_handle_cancel" of Tulip show a different behaviour of _WaitHandleFuture. In one case, the cancelled wait is still signaled, on other case, it's never signaled. Currently, a cancelled _WaitHandleFuture always unregisters the overlapped operation, which causes unexpected event or may lead tests to hang. Never unregisters causes a different issue. Unregistering the overlapped indirectly delete it in memory, which is bad if the completion is still signaled. A workaround is to keep a reference to the unregistered overlopped, but it's an ugly workaround. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 02:41:41 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Jan 2015 01:41:41 +0000 Subject: [issue23290] Faster set copying In-Reply-To: <1421848208.43.0.905402107396.issue23290@psf.upfronthosting.co.za> Message-ID: <1421977301.56.0.183882761022.issue23290@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 02:42:24 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Jan 2015 01:42:24 +0000 Subject: [issue23282] Slightly faster set lookup In-Reply-To: <1421750356.2.0.166287277194.issue23282@psf.upfronthosting.co.za> Message-ID: <1421977344.89.0.932605884462.issue23282@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 02:47:45 2015 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 23 Jan 2015 01:47:45 +0000 Subject: [issue23300] httplib is using a method that doesn't exist In-Reply-To: <1421927408.72.0.18242677241.issue23300@psf.upfronthosting.co.za> Message-ID: <1421977665.59.0.0601519702276.issue23300@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Nikolaus, nothing might be required from your end. Just a good protocol to keep the interested parties in CC. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 03:59:42 2015 From: report at bugs.python.org (Joshua Landau) Date: Fri, 23 Jan 2015 02:59:42 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421981982.26.0.853908267973.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: The function object that's on the stack. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 04:01:08 2015 From: report at bugs.python.org (Neil Girdhar) Date: Fri, 23 Jan 2015 03:01:08 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421982068.44.0.0458666041621.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: when does that get pushed on the stack? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 04:08:54 2015 From: report at bugs.python.org (Joshua Landau) Date: Fri, 23 Jan 2015 03:08:54 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421982534.65.0.536506394401.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: Just before any arguments to the function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 04:15:10 2015 From: report at bugs.python.org (Neil Girdhar) Date: Fri, 23 Jan 2015 03:15:10 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421982910.58.0.276601149384.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Oh, thanks I see, by the LOAD_BUILD_CLASS or VISIT(c, expr, e->v.Call.func) ? Ok, I see. Why do the errors work now for f(x=1, **{'x': 2}) ? these are happening at BUILD_MAP_UNPACK without a stack pointer adjustment. For me, the error message mentions 'f' by name. Is that not the error message you're trying to fix? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 05:03:50 2015 From: report at bugs.python.org (Joshua Landau) Date: Fri, 23 Jan 2015 04:03:50 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421985830.46.0.939250706921.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: No, that happens in CALL_FUNCTION_KW: >>> import dis >>> dis.dis("f(x=1, **{'x': 1})") 1 0 LOAD_NAME 0 (f) 3 LOAD_CONST 0 ('x') 6 LOAD_CONST 1 (1) 9 LOAD_CONST 1 (1) 12 LOAD_CONST 0 ('x') 15 BUILD_MAP 1 18 CALL_FUNCTION_KW 256 (0 positional, 1 keyword pair) 21 RETURN_VALUE There's no call to BUILD_MAP_UNPACK at all. Namely, it's raised from update_keyword_args (in turn from ext_do_call). --- Tangential note: --- In fact, it seems the only reason we keep the mess of unpacking in two places rather than just using BUILD_TUPLE_UNPACK and BUILD_MAP_UNPACK unconditionally is that CALL_FUNCTION_XXX looks to be slightly more efficient by only dealing with the case of a single unpack at the end. I think I see how to make the _UNPACKs fast enough for this case, though, so maybe we could remove it and unify a few things. I'd need to write it up, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 05:33:41 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 23 Jan 2015 04:33:41 +0000 Subject: [issue23302] Small fixes around the use of TCP MSS in http.client In-Reply-To: <1421946035.45.0.334946806325.issue23302@psf.upfronthosting.co.za> Message-ID: <1421987621.44.0.340001640012.issue23302@psf.upfronthosting.co.za> Demian Brecht added the comment: I'm not opposed to that either. The only downside really (at least as far as I'm aware) is the potential substantial influx of packets should an iterable comprised of small chunks of data be passed in as the body, although I would consider that quite a strange edge case for HTTP requests. I'll put together another patch that disables nagle by default and see if anyone has a contrary opinion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 06:14:38 2015 From: report at bugs.python.org (era) Date: Fri, 23 Jan 2015 05:14:38 +0000 Subject: [issue17254] add thai encoding aliases to encodings.aliases In-Reply-To: <1361360924.27.0.663240022367.issue17254@psf.upfronthosting.co.za> Message-ID: <1421990078.26.0.750070856574.issue17254@psf.upfronthosting.co.za> Changes by era : ---------- nosy: +era _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 06:26:36 2015 From: report at bugs.python.org (Neil Girdhar) Date: Fri, 23 Jan 2015 05:26:36 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421990796.67.0.742401885134.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Ah, sorry, yes, this is what I meant (and I see what your'e trying to fix now!): >>> import dis >>> def f(x,y): pass ... >>> dis.dis("f(y=1, **{'x': 1}, x=2)") 1 0 LOAD_NAME 0 (f) 3 LOAD_CONST 0 ('y') 6 LOAD_CONST 1 (1) 9 LOAD_CONST 1 (1) 12 LOAD_CONST 2 ('x') 15 BUILD_MAP 1 18 LOAD_CONST 3 (2) 21 LOAD_CONST 2 ('x') 24 BUILD_MAP 1 27 BUILD_MAP_UNPACK 2 30 CALL_FUNCTION_KW 256 (0 positional, 1 keyword pair) 33 RETURN_VALUE >>> f(y=1, **{'x': 1}, x=2) Traceback (most recent call last): File "", line 1, in TypeError: () got multiple values for keyword argument 'x' >>> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 06:28:59 2015 From: report at bugs.python.org (Neil Girdhar) Date: Fri, 23 Jan 2015 05:28:59 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1421990939.97.0.406324476385.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: I was also thinking of unifying it all, but I couldn't find a way to ensure that the most common case (which I assume is f(x, y, z=0, w=0, *args, **kwargs)) produces no additional opcodes. If you have a nice unification, I look forward to it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 07:47:06 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 23 Jan 2015 06:47:06 +0000 Subject: [issue23302] Small fixes around the use of TCP MSS in http.client In-Reply-To: <1421946035.45.0.334946806325.issue23302@psf.upfronthosting.co.za> Message-ID: <1421995626.84.0.679064552226.issue23302@psf.upfronthosting.co.za> Demian Brecht added the comment: I've attached a new patch disabling Nagle by default, but doing so in connect() as to allow users to override it if they really want to. I've also removed the use of mss in HTTPConnection. This is a backwards incompatible change in two ways: 1. Removing mss as a public attribute of the HTTPConnection. This /could/ be left as a property that pulls the TCP_MAXSEG option once a connection has been established, but I think it's better to just remove it altogether and have the users call into .sock.getsockopt() instead. 2. If someone is expecting to be able to rely on Nagle by default, although I think this is rather unlikely for HTTP. That said, I do agree that this is a simpler, more portable choice to solve the problem. ---------- type: -> behavior Added file: http://bugs.python.org/file37826/issue23302_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 10:13:16 2015 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 23 Jan 2015 09:13:16 +0000 Subject: [issue23300] httplib is using a method that doesn't exist In-Reply-To: <1421927408.72.0.18242677241.issue23300@psf.upfronthosting.co.za> Message-ID: <1422004396.68.0.293875493348.issue23300@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Here is the patch to fix this. I have added a test case covering this change. Please review this and if it is good to go, I will commit it. Thank you. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file37827/23000.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 10:25:13 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Jan 2015 09:25:13 +0000 Subject: [issue22885] Arbitrary code execution vulnerability due to unchecked eval() call in dumbdbm module In-Reply-To: <1416163141.0.0.643597983294.issue22885@psf.upfronthosting.co.za> Message-ID: <1422005113.96.0.704784886094.issue22885@psf.upfronthosting.co.za> STINNER Victor added the comment: + with open(_fname + ".dir", 'w') as stream: + stream.write(content) I don't see where the created file is deleted. Add something like: self.addCleanup(support.unlink, _fname + ".dir") ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 10:32:33 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Jan 2015 09:32:33 +0000 Subject: [issue22947] Enable 'imageop' - "Multimedia Srvices Feature module" for 64-bit platform In-Reply-To: <1417004311.93.0.975050094816.issue22947@psf.upfronthosting.co.za> Message-ID: <1422005553.75.0.476775211155.issue22947@psf.upfronthosting.co.za> STINNER Victor added the comment: The module has been deleted in Python 3. The compilation of the module was probably disabled on 64-bit because of bugs. I don't see any bugfix in your patch. changeset: 6448:b854ca4605e1 branch: legacy-trunk user: Guido van Rossum date: Wed Oct 08 05:05:28 1997 +0000 files: README description: Ready for the release, I'd say. diff -r 31a50468366b -r b854ca4605e1 README --- a/README Wed Oct 08 04:05:08 1997 +0000 +++ b/README Wed Oct 08 05:05:28 1997 +0000 (...) +64-bit platforms: The modules audioop, imageop and rgbimg don't work. + Don't try to enable them in the Modules/Setup file. They + contain code that is quite wordsize sensitive. (If you have a + fix, let me know!) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 10:36:07 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 23 Jan 2015 09:36:07 +0000 Subject: [issue23300] httplib is using a method that doesn't exist In-Reply-To: <1421927408.72.0.18242677241.issue23300@psf.upfronthosting.co.za> Message-ID: <1422005767.18.0.968894189759.issue23300@psf.upfronthosting.co.za> Berker Peksag added the comment: +class TestServer(TestCase): This can be a mixin. + def testHTTPWithConnectHostPost(self): Post -> Port? + self.conn = httplib.HTTP(host=constructor_host, port=constructor_port) or to make the test simpler, self.conn = httplib.HTTP() ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 10:41:18 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Jan 2015 09:41:18 +0000 Subject: [issue16648] stdib should use new exception types from PEP 3151 In-Reply-To: <1354995347.5.0.732021100427.issue16648@psf.upfronthosting.co.za> Message-ID: <1422006078.99.0.912410998074.issue16648@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, I didn't know this issue. FYI I modified the subprocess module to use new specialized OSError exceptions: issue #23234 (changeset 0c5ae257966f). ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 10:53:07 2015 From: report at bugs.python.org (Claudiu Popa) Date: Fri, 23 Jan 2015 09:53:07 +0000 Subject: [issue22885] Arbitrary code execution vulnerability due to unchecked eval() call in dumbdbm module In-Reply-To: <1416163141.0.0.643597983294.issue22885@psf.upfronthosting.co.za> Message-ID: <1422006787.31.0.0732974184942.issue22885@psf.upfronthosting.co.za> Claudiu Popa added the comment: Thanks, Victor. I thought the same thing, but the file is deleted here already, here: https://hg.python.org/cpython/file/981ba93bcbde/Lib/test/test_dbm_dumb.py#l228 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 11:27:32 2015 From: report at bugs.python.org (Piotr Dobrogost) Date: Fri, 23 Jan 2015 10:27:32 +0000 Subject: [issue22889] set a timeout for DNS lookups In-Reply-To: <1416202700.62.0.764636248133.issue22889@psf.upfronthosting.co.za> Message-ID: <1422008852.16.0.637844234942.issue22889@psf.upfronthosting.co.za> Changes by Piotr Dobrogost : ---------- nosy: +piotr.dobrogost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 11:37:03 2015 From: report at bugs.python.org (Juha Lemmetti) Date: Fri, 23 Jan 2015 10:37:03 +0000 Subject: [issue23305] RotatingFileHandler does not rotate if backupCount is 0 Message-ID: <1422009423.63.0.642413518943.issue23305@psf.upfronthosting.co.za> New submission from Juha Lemmetti: If RotatingFileHandler is initialized with backupCount 0, the file does not rotate but grows indefinitely. This is not self-evident from the documentation. Suggestion: either rotate (discard) the log if backupCount==0 or mention the current operation the documentation. The former leaves the user with only one log message at the worst case. In the latter case, the documentation can be modified to explicitly mention what the result will be if backupCount is left to its default value of 0, i.e. that the RotatingFileHandler will grow the file indefinitely regardless of the value of maxBytes value. The default value for the backupCount could also be modified, as the default value does nothing. Tested with Windows-Python2.7, Linux-Python 3.3.2+ (Ubuntu-14.04). Can be reproduced with a simple logging example with backupCount == 0 and maxBytes > 0 ---------- components: Library (Lib) messages: 234552 nosy: Juha.Lemmetti, vinay.sajip priority: normal severity: normal status: open title: RotatingFileHandler does not rotate if backupCount is 0 type: enhancement versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 11:38:41 2015 From: report at bugs.python.org (Florian Berger) Date: Fri, 23 Jan 2015 10:38:41 +0000 Subject: [issue21417] Compression level for zipfile In-Reply-To: <1399053616.42.0.124840881006.issue21417@psf.upfronthosting.co.za> Message-ID: <1422009521.84.0.0866989288355.issue21417@psf.upfronthosting.co.za> Changes by Florian Berger : ---------- nosy: +fberger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 11:56:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 23 Jan 2015 10:56:04 +0000 Subject: [issue16648] stdib should use new exception types from PEP 3151 In-Reply-To: <1354995347.5.0.732021100427.issue16648@psf.upfronthosting.co.za> Message-ID: <1422010564.83.0.528630260082.issue16648@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +refactor subprocess: use new OSError exceptions, factorize stdin.write() code _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 12:57:16 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 23 Jan 2015 11:57:16 +0000 Subject: [issue23282] Slightly faster set lookup In-Reply-To: <1421750356.2.0.166287277194.issue23282@psf.upfronthosting.co.za> Message-ID: <1422014236.01.0.685234011333.issue23282@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Does it slow down other cases? Seems to me like dictionaries would have more "existing key lookups" than sets to justify the optimization, since they're used for attribute lookup and the like, and because you usually want the value associated with existing keys, where a set would usually be used in a "might exist, might not" scenario of membership testing. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 14:23:02 2015 From: report at bugs.python.org (Alessio) Date: Fri, 23 Jan 2015 13:23:02 +0000 Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings In-Reply-To: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za> Message-ID: <1422019382.76.0.277019051748.issue11024@psf.upfronthosting.co.za> Alessio added the comment: Is anybody working with this case? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 15:00:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 23 Jan 2015 14:00:59 +0000 Subject: [issue23282] Slightly faster set lookup In-Reply-To: <1421750356.2.0.166287277194.issue23282@psf.upfronthosting.co.za> Message-ID: <1422021659.66.0.940723971801.issue23282@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Good point Josh. Yes, it may slow down other cases, and there is a difference between sets and dicts. 1. If the key is not contained in the set, then if the first tested entry table[hash & mask] is empty, then the lookup is slowed down by one pointer comparison (2 comparisons instead of 1). If the entry is used then the lookup is not slow downed or even speed up (if need to test more than one additional entries). 2. If the same case is in the set, then if the first tested entry is the set then the lookup will use one comparison instead of 4. In other cases (the key is placed in other entry) the lookup will use at least one comparison less. 3. If the set contains key equal but not identical to tested key, then the lookup will use at least one comparison less. Only first case can cause slowdown. If we test a lot of keys not existing in the set with small ratio between used and allocated entries numbers. May be the worst case is creating a copy of the set. For other operations I did not find significant difference. $ ./python -m timeit -s "s = set(range(10**4))" -- "frozenset(s)" Unpatched: 1000 loops, best of 3: 658 usec per loop Patched: 1000 loops, best of 3: 668 usec per loop But issue23290 prevents this regression. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 15:41:22 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 23 Jan 2015 14:41:22 +0000 Subject: [issue11024] imaplib: Time2Internaldate() returns localized strings In-Reply-To: <1296135301.42.0.767818406183.issue11024@psf.upfronthosting.co.za> Message-ID: <1422024082.1.0.590195476654.issue11024@psf.upfronthosting.co.za> R. David Murray added the comment: I'm not sure why this issue is still open. It looks like Alexander committed the fix. If you are seeing a problem, I think that would be a new bug, and you should open a new issue giving details on how to reproduce the problem you are seeing. ---------- stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 15:43:05 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 23 Jan 2015 14:43:05 +0000 Subject: [issue23305] RotatingFileHandler does not rotate if backupCount is 0 In-Reply-To: <1422009423.63.0.642413518943.issue23305@psf.upfronthosting.co.za> Message-ID: <1422024185.23.0.821535301681.issue23305@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 16:07:12 2015 From: report at bugs.python.org (Ubik) Date: Fri, 23 Jan 2015 15:07:12 +0000 Subject: [issue1681974] mkdtemp fails on Windows if username has non-ASCII character Message-ID: <1422025632.02.0.495904188121.issue1681974@psf.upfronthosting.co.za> Ubik added the comment: As detailed in this SO question: http://stackoverflow.com/questions/28101187/deal-with-unicode-usernames-in-python-mkdtemp I still see the issue in 2.7.8. I use a unicode prefix and changing this is not an option (editing legacy code which expects unicode everywhere) Is there some full proof workaround ? Is the one suggested in the OP good enough ? ---------- nosy: +Ubik _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 16:11:58 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Jan 2015 15:11:58 +0000 Subject: [issue1681974] mkdtemp fails on Windows if username has non-ASCII character Message-ID: <1422025918.05.0.785976229854.issue1681974@psf.upfronthosting.co.za> STINNER Victor added the comment: The best fix is to use Python 3. In 2015, it's maybe time to use Python 3 which has a very good Unicode support. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 16:15:14 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 23 Jan 2015 15:15:14 +0000 Subject: [issue23300] httplib is using a method that doesn't exist In-Reply-To: <1421927408.72.0.18242677241.issue23300@psf.upfronthosting.co.za> Message-ID: <1422026114.71.0.321736405582.issue23300@psf.upfronthosting.co.za> Demian Brecht added the comment: Other than Berker's comments, LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 16:44:48 2015 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 23 Jan 2015 15:44:48 +0000 Subject: [issue21862] cProfile command-line should accept "-m module_name" as an alternative to script path In-Reply-To: <1403640414.18.0.449527177368.issue21862@psf.upfronthosting.co.za> Message-ID: <1422027888.95.0.860786132822.issue21862@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: This change will cause the module to be imported twice: progname = runpy.run_module(args[0])['__file__'] ... and then the runctx() call. What about something like: code = "runpy.run_module(modname, run_name='__main__')" globs = { 'runpy': runpy, 'modname': args[0] } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 17:03:23 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 23 Jan 2015 16:03:23 +0000 Subject: [issue23302] Small fixes around the use of TCP MSS in http.client In-Reply-To: <1421946035.45.0.334946806325.issue23302@psf.upfronthosting.co.za> Message-ID: <20150123160307.55108.13397@psf.io> Roundup Robot added the comment: New changeset 42971b769c0b by Benjamin Peterson in branch 'default': http.client: disable Nagle's algorithm (closes #23302) https://hg.python.org/cpython/rev/42971b769c0b ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 18:10:39 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 23 Jan 2015 17:10:39 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1422033039.28.0.0841417816078.issue23255@psf.upfronthosting.co.za> Demian Brecht added the comment: Thanks for the work! I'm not sure why the last patch doesn't appear on Rietveld, so (unfortunately) here's the result of my review. I've only covered functional aspects in this run at it: + base_files = ['index.html', 'index.htm'] Can you use "index_files"? That's the commonly used term to refer to these files. - def copyfile(self, source, outputfile): + def copy_file(self, source, outputfile): As Berker mentioned, we can't just rename this as it's not backwards compatible. Standard library modules aren't the only dependency. Such a change would cause breakage in, say, any 3rd party code that subclasses SimpleHTTPRequestHandler. This should remain as copyfile. + def redirect_browser(self, path, parts): Can "_browser" be dropped here? This applies to all clients, not only browsers. Additionally, I think that the name is a little misleading. I think it would be better to have a generic public redirect(, status=http.FOUND) method and then an internal _resolve_path() that calls into the redirect method using the Apache-like logic. It also seems like the path parameter is unused so should be dropped. + def get_path_or_dir(self, path): I think the content of this method should be changed to result in consistent output. Right now, you're either returning a file path /or/ a BytesIO object containing the full output of the directory listing. It might make sense to have a single method that takes the path and produces consistent BytesIO object, regardless of whether it's a directory or a file path. + self.send_response(301) Please use the http.HTTPStatus enum for status codes (i.e. http.HTTPStatus.MOVED_PERMANENTLY) + def apply_headers(self, f, path) I don't think that this makes sense as a public API as it is as it only accounts for a 200 response. What if any error conditions are raised with the given file? As this is functionality specific to the single case in which it's used, I think this should either be left as-is, made more generic to handle header values based on any potential state of the file object, or made into a private helper method (indicated by a single underscore prefix to the method name). Also, you should be able to derive the path from the file parameter (f.name), so I'm not sure that the extra path parameter is necessary. + def get_response(self, tail=False) tail should default to None here, otherwise it's a little confusing as to why a parameter that /looks/ like it should be a bool actually expects a string value. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 18:17:16 2015 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 23 Jan 2015 17:17:16 +0000 Subject: [issue1681974] mkdtemp fails on Windows if username has non-ASCII character Message-ID: <1422033436.88.0.257406510285.issue1681974@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Ubik: this issue is closed, as we believe that it does not exist anymore. If you still think there is a bug surrounding mkdtemp, please make a new full bug report. Structure your report as follows: 1. this is what you did 2. this is what happened 3. this is what you expected to happen instead Be as precise as possible. For example, reporting the exact user name of the user might be helpful. If you can, debug the problem, e.g. by arranging to display the value of 'path' and 'b' in line 102 of ntpath.py (assuming the error still occurs on the same line as it did for Markus). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 18:34:50 2015 From: report at bugs.python.org (Ent) Date: Fri, 23 Jan 2015 17:34:50 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1422034490.81.0.217673156777.issue23255@psf.upfronthosting.co.za> Ent added the comment: @demian: That's a tall order! :) I would love to use HTTPStatus but for some reason http/__init__.py is devoid of code related to it - https://hg.python.org/cpython/file/31982d70a52a/Lib/http/__init__.py I wasn't sure why this change was made because it like feels a step backwards. Will someone else be reverting it back or should I just include it in this patch or create another one? As for rest of your comments, I will make the necessary changes and put up next patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 18:43:33 2015 From: report at bugs.python.org (Ent) Date: Fri, 23 Jan 2015 17:43:33 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1422035013.01.0.485066444741.issue23255@psf.upfronthosting.co.za> Ent added the comment: @demian: If you don't mind, could you please elaborate a bit more on `_resolve_path()` you mentioned in the review/comment? Or maybe link me to the type of behaviour you mentioned? I will accordingly make the changes. As for self.apply_headers, I will see if I can make it more generic. As it stands, I have tried not to make any radical changes in existing logic; This being my first patch and all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 18:44:15 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 23 Jan 2015 17:44:15 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1422035055.84.0.558637539109.issue23255@psf.upfronthosting.co.za> Berker Peksag added the comment: > I would love to use HTTPStatus but for some reason http/__init__.py is devoid of code related to it - https://hg.python.org/cpython/file/31982d70a52a/Lib/http/__init__.py See the default branch: https://hg.python.org/cpython/file/default/Lib/http/__init__.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 18:52:21 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 23 Jan 2015 17:52:21 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <1420230232.09.0.10127303351.issue23152@psf.upfronthosting.co.za> Message-ID: <1422035541.36.0.860493924011.issue23152@psf.upfronthosting.co.za> Steve Dower added the comment: Yeah, that's the sole buildbot currently running VS 2015. I'm expecting to have more after VS 2015 RC is released, since that will be "basically finished". Until then, I'm also regularly building with the latest internal versions and tracking issues, but nothing seems to have been introduced since Preview, so that buildbot is a very good guide. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 19:08:58 2015 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 23 Jan 2015 18:08:58 +0000 Subject: [issue23300] httplib is using a method that doesn't exist In-Reply-To: <1421927408.72.0.18242677241.issue23300@psf.upfronthosting.co.za> Message-ID: <1422036538.0.0.654015465598.issue23300@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Addressed Berker's review comments. 1) Made the TestServer a Mixin. (Thanks, that's the correct to do). 2) Changed Post to Port. 3) I went with still using a testdomain and port in the constructor. My idea of the test is to demonstrate that the connect(host,port) is used when given rather than HTTP(host,port). ---------- Added file: http://bugs.python.org/file37828/23000-v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 19:31:06 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 23 Jan 2015 18:31:06 +0000 Subject: [issue23300] httplib is using a method that doesn't exist In-Reply-To: <1421927408.72.0.18242677241.issue23300@psf.upfronthosting.co.za> Message-ID: <1422037866.41.0.624436813021.issue23300@psf.upfronthosting.co.za> Berker Peksag added the comment: LGTM. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 19:34:54 2015 From: report at bugs.python.org (Marat Mavlyutov) Date: Fri, 23 Jan 2015 18:34:54 +0000 Subject: [issue23223] subprocess32 unable to be installed via pip In-Reply-To: <1420988335.84.0.852324840032.issue23223@psf.upfronthosting.co.za> Message-ID: <1422038094.74.0.886932180043.issue23223@psf.upfronthosting.co.za> Marat Mavlyutov added the comment: HI! need that thingie too, did you poke the author? cant find issue tracker at code.google.com ---------- nosy: +Marat.Mavlyutov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 19:41:14 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 23 Jan 2015 18:41:14 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1422035013.01.0.485066444741.issue23255@psf.upfronthosting.co.za> Message-ID: <54C295C5.3030904@gmail.com> Demian Brecht added the comment: > @demian: If you don't mind, could you please elaborate a bit more on `_resolve_path()` you mentioned in the review/comment? Sure. In your patch, you have redirect_browser (or redirect if you renamed it), which sounds like it's allowing for a very generic event to happen: executing a redirect based on a passed in path. What I would expect from calling into this is that the input path would be used as the Location header in the resulting response. For example (using the code as-is): self.redirect_browser('http://example.com/foo/bar/') The above would result in the response Location header being set to input URL. What it's actually doing is a very specific thing: Redirection if the final char in the input URL is '/', which is something that I don't think needs to be exposed as part of the public API. So, my recommendation is to do something like this: def redirect(self, url, status=http.HTTPStatus.FOUND): self.send_response(status) self.send_header('Location', url) self.end_headers() Add a private helper method: def _resolve_path(self, url): parts = urllib.parse.urlsplit(url) [...snip...] return new_path_with_appended_slash And in the body of send_head, do something like: resolved_path = self._resolve_path(path) if path != resolved_path: self.redirect(resolved_path) > As it stands, I have tried not to make any radical changes in existing logic; This being my first patch and all. The tough thing with adding public API in general is that you have to consider both API readability as well as various use cases, not only the one that you're specifically writing code for. To make your first patch a little easier, you /could/ change the public API methods that you've added to private helper methods and rename them as it makes sense. At least in that way, you don't need to worry about making the methods generic and writing tests for each where functionality is enhanced. In reality, it seems that that's exactly what you're trying to achieve: Helper methods where you're grouping logical bodies of code rather than a full blown public API change (but I could be misunderstanding your intentions there). Hope that all makes sense. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 20:24:52 2015 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 23 Jan 2015 19:24:52 +0000 Subject: [issue23202] pyvenv does not fail like documented when a venv already exists In-Reply-To: <1420783324.13.0.763537521613.issue23202@psf.upfronthosting.co.za> Message-ID: <1422041092.08.0.711334085265.issue23202@psf.upfronthosting.co.za> Vinay Sajip added the comment: The behaviour was changed in 3.4 in response to #15776, but the documentation wasn't updated to match. I will update the docs to remove the reference to the error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 20:37:19 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 23 Jan 2015 19:37:19 +0000 Subject: [issue23202] pyvenv does not fail like documented when a venv already exists In-Reply-To: <1420783324.13.0.763537521613.issue23202@psf.upfronthosting.co.za> Message-ID: <20150123193710.55102.43321@psf.io> Roundup Robot added the comment: New changeset a3a44d871d70 by Vinay Sajip in branch 'default': Closes #23202: pyvenv documentation updated to match its behavior. https://hg.python.org/cpython/rev/a3a44d871d70 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 20:54:49 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 23 Jan 2015 19:54:49 +0000 Subject: [issue23207] logging.basicConfig does not validate keyword arguments In-Reply-To: <1420813239.75.0.476507944816.issue23207@psf.upfronthosting.co.za> Message-ID: <20150123195435.118216.63914@psf.io> Roundup Robot added the comment: New changeset 2bc3e839a3a3 by Vinay Sajip in branch '3.4': Issue #23207: logging.basicConfig() now does additional validation of its arguments. https://hg.python.org/cpython/rev/2bc3e839a3a3 New changeset 06ba5e776a6e by Vinay Sajip in branch 'default': Closes #23207: logging.basicConfig() now does additional validation of its arguments. https://hg.python.org/cpython/rev/06ba5e776a6e ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 21:07:45 2015 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 23 Jan 2015 20:07:45 +0000 Subject: [issue23305] RotatingFileHandler does not rotate if backupCount is 0 In-Reply-To: <1422009423.63.0.642413518943.issue23305@psf.upfronthosting.co.za> Message-ID: <1422043665.23.0.164283723792.issue23305@psf.upfronthosting.co.za> Vinay Sajip added the comment: The default parameters for backupCount and maxBytes are both shown as 0. The first paragraph ends with "By default, the file grows indefinitely." The second paragraph says, "If backupCount is non-zero, the system will save old log files by appending the extensions ?.1?, ?.2?". Together, these should indicate that the file will grow indefinitely (and not rotate) if backupCount is left at 0. ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 21:29:27 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 23 Jan 2015 20:29:27 +0000 Subject: [issue23223] subprocess32 unable to be installed via pip In-Reply-To: <1420988335.84.0.852324840032.issue23223@psf.upfronthosting.co.za> Message-ID: <1422044967.37.0.551596923685.issue23223@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I can apply this to subprocess32 but it is going to look much more like: +#ifndef MS_WINDOWS /* WTF is anyone compiling on Windows? Shouldn't work! */ +# define HAVE_UNISTD_H 1 +#endif +#ifdef HAVE_UNISTD_H #include +#endif The real question is why do you need it? _posixsubprocess.c makes no sense to compile on Windows as far as I understand it. subprocess32 in its entirety makes no sense to use on Windows as nobody is testing, maintaining or updating the Windows side of its code. The module backport was created for reliable use on POSIX platforms where the existing python 2.x subprocess module falls short. I recommend: try: import subprocess32 as subprocess except ImportError: import subprocess OR if sys.platform.startswith('win'): import subprocess else: import subprocess32 as subprocess in cross platform code that needs to run on Windows. .... BTW, anyone know what update do I need to make to setup.py and its PIP categorization to mark it as unavailable on Windows? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 21:30:02 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 23 Jan 2015 20:30:02 +0000 Subject: [issue23223] subprocess32 unable to be installed via pip In-Reply-To: <1420988335.84.0.852324840032.issue23223@psf.upfronthosting.co.za> Message-ID: <1422045002.25.0.892876784114.issue23223@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- assignee: -> gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 21:32:08 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 23 Jan 2015 20:32:08 +0000 Subject: [issue20188] ALPN support for TLS In-Reply-To: <1389153179.88.0.510995543218.issue20188@psf.upfronthosting.co.za> Message-ID: <1422045128.54.0.413649530832.issue20188@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Here you are. ---------- keywords: +patch nosy: +benjamin.peterson stage: needs patch -> patch review Added file: http://bugs.python.org/file37829/alpn.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 21:33:46 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 23 Jan 2015 20:33:46 +0000 Subject: [issue20188] ALPN support for TLS In-Reply-To: <1389153179.88.0.510995543218.issue20188@psf.upfronthosting.co.za> Message-ID: <1422045226.82.0.964500855203.issue20188@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Why is that "3.4.3"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 21:36:09 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 23 Jan 2015 20:36:09 +0000 Subject: [issue20188] ALPN support for TLS In-Reply-To: <1422045226.82.0.964500855203.issue20188@psf.upfronthosting.co.za> Message-ID: <1422045367.994222.218051721.4876720D@webmail.messagingengine.com> Benjamin Peterson added the comment: On Fri, Jan 23, 2015, at 15:33, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > Why is that "3.4.3"? I wrote the patch on the 3.4 branch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 21:36:57 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 23 Jan 2015 20:36:57 +0000 Subject: [issue20188] ALPN support for TLS In-Reply-To: <1389153179.88.0.510995543218.issue20188@psf.upfronthosting.co.za> Message-ID: <1422045417.5.0.442404103825.issue20188@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, sure, but that means you plan to make it available in 3.4.3? Why is that? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 21:39:16 2015 From: report at bugs.python.org (Juha Lemmetti) Date: Fri, 23 Jan 2015 20:39:16 +0000 Subject: [issue23305] RotatingFileHandler does not rotate if backupCount is 0 In-Reply-To: <1422009423.63.0.642413518943.issue23305@psf.upfronthosting.co.za> Message-ID: <1422045556.47.0.742228234793.issue23305@psf.upfronthosting.co.za> Juha Lemmetti added the comment: What You point out is true. However, I saw a bug in code where RotatingFileHandler was used, and I had to check the operation using a small test program. For maxBytes, it is explicitly stated that when the value is 0, rollover never occurs. It wouldn't hurt to have the same text for backupCount in the documentation, just for clarity. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 21:39:47 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 23 Jan 2015 20:39:47 +0000 Subject: [issue20188] ALPN support for TLS In-Reply-To: <1422045417.5.0.442404103825.issue20188@psf.upfronthosting.co.za> Message-ID: <1422045585.995053.218053009.31ECEEC3@webmail.messagingengine.com> Benjamin Peterson added the comment: On Fri, Jan 23, 2015, at 15:36, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > Well, sure, but that means you plan to make it available in 3.4.3? Why is > that? No, I'll apply it to 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 21:46:48 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 23 Jan 2015 20:46:48 +0000 Subject: [issue20188] ALPN support for TLS In-Reply-To: <1389153179.88.0.510995543218.issue20188@psf.upfronthosting.co.za> Message-ID: <1422046008.14.0.998349260273.issue20188@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Here's the fixed 3.5 patch. ---------- Added file: http://bugs.python.org/file37830/alpn.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 22:07:56 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 23 Jan 2015 21:07:56 +0000 Subject: [issue20188] ALPN support for TLS In-Reply-To: <1389153179.88.0.510995543218.issue20188@psf.upfronthosting.co.za> Message-ID: <1422047276.02.0.810456824659.issue20188@psf.upfronthosting.co.za> Benjamin Peterson added the comment: update after review comments ---------- Added file: http://bugs.python.org/file37831/alpn.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 22:20:19 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 23 Jan 2015 21:20:19 +0000 Subject: [issue23305] RotatingFileHandler does not rotate if backupCount is 0 In-Reply-To: <1422009423.63.0.642413518943.issue23305@psf.upfronthosting.co.za> Message-ID: <20150123212003.55120.20919@psf.io> Roundup Robot added the comment: New changeset 0375eb71d75e by Vinay Sajip in branch '2.7': Issue #23305: clarified RotatingFileHandler documentation. https://hg.python.org/cpython/rev/0375eb71d75e New changeset 93888975606b by Vinay Sajip in branch '3.4': Issue #23305: clarified RotatingFileHandler documentation. https://hg.python.org/cpython/rev/93888975606b New changeset 67ebf7ae686d by Vinay Sajip in branch 'default': Closes #23305: Merged documentation fix from 3.4. https://hg.python.org/cpython/rev/67ebf7ae686d ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 22:33:58 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 23 Jan 2015 21:33:58 +0000 Subject: [issue20188] ALPN support for TLS In-Reply-To: <1389153179.88.0.510995543218.issue20188@psf.upfronthosting.co.za> Message-ID: <1422048838.14.0.682078478891.issue20188@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- assignee: -> benjamin.peterson stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 23 22:43:03 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 23 Jan 2015 21:43:03 +0000 Subject: [issue20188] ALPN support for TLS In-Reply-To: <1389153179.88.0.510995543218.issue20188@psf.upfronthosting.co.za> Message-ID: <20150123214256.55118.52286@psf.io> Roundup Robot added the comment: New changeset be9fe0c66075 by Benjamin Peterson in branch 'default': add support for ALPN (closes #20188) https://hg.python.org/cpython/rev/be9fe0c66075 New changeset 7ce67d3f0908 by Benjamin Peterson in branch '2.7': pep 466 backport of alpn (#20188) https://hg.python.org/cpython/rev/7ce67d3f0908 ---------- nosy: +python-dev resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 00:16:44 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 23 Jan 2015 23:16:44 +0000 Subject: [issue1060] zipfile cannot handle files larger than 2GB (inside archive) In-Reply-To: <1188423295.47.0.201015368946.issue1060@psf.upfronthosting.co.za> Message-ID: <1422055004.56.0.148368600473.issue1060@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- assignee: gregory.p.smith -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 00:49:26 2015 From: report at bugs.python.org (Danny Yoo) Date: Fri, 23 Jan 2015 23:49:26 +0000 Subject: [issue23306] zlib.crc32 raises OverflowError at argument-parsing time on large strings Message-ID: <1422056966.81.0.518971767948.issue23306@psf.upfronthosting.co.za> New submission from Danny Yoo: Reproduction steps: --- $ python2.7 -c "import zlib;zlib.crc32('a'*(1<<31))" Traceback (most recent call last): File "", line 1, in OverflowError: size does not fit in an int --- We ran into this bug in zlib.crc32 when using zipfile.writestr() with a very large string; as soon as zipfile tried to write the crc checksum, it raised this error. Python 3 does not appear to suffer from this bug. ---------- components: Library (Lib) messages: 234587 nosy: Danny.Yoo, gregory.p.smith priority: normal severity: normal status: open title: zlib.crc32 raises OverflowError at argument-parsing time on large strings type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 00:56:30 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 23 Jan 2015 23:56:30 +0000 Subject: [issue23306] zlib.crc32 raises OverflowError at argument-parsing time on large strings In-Reply-To: <1422056966.81.0.518971767948.issue23306@psf.upfronthosting.co.za> Message-ID: <1422057390.89.0.400487803009.issue23306@psf.upfronthosting.co.za> Gregory P. Smith added the comment: This bug prevents zipfile's writestr() from writing large data (longer than UINT_MAX) to a 64-bit zip file. The zlib.crc32 function which, as written, cannot accept input with a size larger than an unsigned int. https://hg.python.org/cpython/file/94ec4d8cf104/Modules/zlibmodule.c#l964 Python 3 has updated this to call the zlib crc32 function multiple times in this situation: https://hg.python.org/cpython/file/93888975606b/Modules/zlibmodule.c#l1210 so the fix exists, we just need to do this in 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 01:52:11 2015 From: report at bugs.python.org (Danny Yoo) Date: Sat, 24 Jan 2015 00:52:11 +0000 Subject: [issue23306] zlib.crc32 raises OverflowError at argument-parsing time on large strings In-Reply-To: <1422056966.81.0.518971767948.issue23306@psf.upfronthosting.co.za> Message-ID: <1422060731.68.0.759457078819.issue23306@psf.upfronthosting.co.za> Danny Yoo added the comment: Unfortunately, fixing just zlib.crc32 isn't quite enough for our purposes. We still will see OverflowErrow in zipfile if compression is selected. Demonstration code: ############################################ import zipfile ## Possible workaround: monkey-patch crc32 from binascii?! import binascii zipfile.crc32 = binascii.crc32 content = 'a'*(1<<31) filename = '/tmp/zip_test.zip' zf = zipfile.ZipFile(filename, "w", compression=zipfile.ZIP_DEFLATED, allowZip64=True) zf.writestr('big', content) zf.close() zf = zipfile.ZipFile(filename, "r", allowZip64=True) print zf.open('big').read() == content ############################################# This will raise the following error under Python 2.7.6: ############################################# $ python zip_test.py Traceback (most recent call last): File "zip_test.py", line 13, in zf.writestr('big', content) File "/usr/lib/python2.7/zipfile.py", line 1228, in writestr bytes = co.compress(bytes) + co.flush() OverflowError: size does not fit in an int ############################################# If we use compression=zipfile.ZIP_STORED, we don't see this error, but it kind of misses a major point of using zipfile. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 01:55:22 2015 From: report at bugs.python.org (Danny Yoo) Date: Sat, 24 Jan 2015 00:55:22 +0000 Subject: [issue23306] Within zipfile, use of zlib.crc32 raises OverflowError at argument-parsing time on large strings In-Reply-To: <1422056966.81.0.518971767948.issue23306@psf.upfronthosting.co.za> Message-ID: <1422060922.32.0.682121459776.issue23306@psf.upfronthosting.co.za> Changes by Danny Yoo : ---------- title: zlib.crc32 raises OverflowError at argument-parsing time on large strings -> Within zipfile, use of zlib.crc32 raises OverflowError at argument-parsing time on large strings _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 03:41:40 2015 From: report at bugs.python.org (Ethan Furman) Date: Sat, 24 Jan 2015 02:41:40 +0000 Subject: [issue23292] Enum doc suggestion In-Reply-To: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za> Message-ID: <1422067300.58.0.303835573631.issue23292@psf.upfronthosting.co.za> Ethan Furman added the comment: Currently the way to add an Enum's members to a module's namespace is: globals().update(MyEnumeration.__members__) but that seems quite ugly. Is there anywhere else that the user is required to use __xxx__ methods for common functionality? I think a new method, export_to(), would solve the problem much more nicely: @classmethod def export_to(cls, namespace): try: # assume a dict-like namespace namespace.update(cls.__members__) except AttributeError: # or an object-like namespace for name, member in cls.__members__.items(): setattr(namespace, name, member) ---------- nosy: +barry, eli.bendersky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 05:06:04 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 24 Jan 2015 04:06:04 +0000 Subject: [issue20284] patch to implement PEP 461 (%-interpolation for bytes) In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <20150124040554.84273.66005@psf.io> Roundup Robot added the comment: New changeset 8d802fb6ae32 by Ethan Furman in branch 'default': Issue20284: Implement PEP461 https://hg.python.org/cpython/rev/8d802fb6ae32 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 05:42:30 2015 From: report at bugs.python.org (Michiel de Hoon) Date: Sat, 24 Jan 2015 04:42:30 +0000 Subject: [issue23237] Interrupts are lost during readline PyOS_InputHook processing (reopening) In-Reply-To: <1421201583.23.0.507661432161.issue23237@psf.upfronthosting.co.za> Message-ID: <1422074550.61.0.126809208195.issue23237@psf.upfronthosting.co.za> Michiel de Hoon added the comment: I am attaching a patch for this bug for Python 2.7. ---------- keywords: +patch nosy: +mdehoon Added file: http://bugs.python.org/file37832/issue23237.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 07:37:51 2015 From: report at bugs.python.org (Jim Bridgewater) Date: Sat, 24 Jan 2015 06:37:51 +0000 Subject: [issue23307] python hangs on call to numpy.outer Message-ID: <1422081470.94.0.280484065129.issue23307@psf.upfronthosting.co.za> New submission from Jim Bridgewater: python hangs when this script is run and if it is allowed to continue running OS X produces system out of memory errors ---------- files: dome_projection.py messages: 234593 nosy: jwbwater priority: normal severity: normal status: open title: python hangs on call to numpy.outer type: crash versions: Python 2.7 Added file: http://bugs.python.org/file37833/dome_projection.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 08:06:26 2015 From: report at bugs.python.org (Jim Bridgewater) Date: Sat, 24 Jan 2015 07:06:26 +0000 Subject: [issue23307] python hangs on call to numpy.outer In-Reply-To: <1422081470.94.0.280484065129.issue23307@psf.upfronthosting.co.za> Message-ID: <1422083186.18.0.299903109533.issue23307@psf.upfronthosting.co.za> Jim Bridgewater added the comment: Turns out an outer product of two million element vectors takes up a lot of memory. Go figure. ---------- resolution: -> not a bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 08:06:56 2015 From: report at bugs.python.org (Georg Brandl) Date: Sat, 24 Jan 2015 07:06:56 +0000 Subject: [issue23292] Enum doc suggestion In-Reply-To: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za> Message-ID: <1422083216.97.0.695894136742.issue23292@psf.upfronthosting.co.za> Georg Brandl added the comment: Well, for such operations (namespace manipulation) __dict__ is also often used, so I wouldn't say it's too ugly. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 08:16:41 2015 From: report at bugs.python.org (David Motlagh) Date: Sat, 24 Jan 2015 07:16:41 +0000 Subject: [issue23308] a bug in Instructions section 4.1 Message-ID: <1867408449.522169.1422083738920.JavaMail.yahoo@mail.yahoo.com> New submission from David Motlagh: Hi, I either found a bug or ?am doing the steps wrong. ?Could you please check the instructions in Section 4.1 to determine if there really is a syntax error? Thanks,David Motlagh? ---------- messages: 234596 nosy: Dmot priority: normal severity: normal status: open title: a bug in Instructions section 4.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 09:42:50 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 24 Jan 2015 08:42:50 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1422088970.23.0.620705659157.issue3566@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch, including tests and documentation. It ended up a bit more complicated than I anticipated, so I?m interested in hearing other ideas or options. * Added http.client.ConnectionClosed exception * HTTPConnection.close() is implicitly called for a persistent connection closure * BadStatusLine or ConnectionError (rather than new exception) is still raised on first getresponse() * request() raising a ConnectionError does not necessarily mean the server did not send a response, so ConnectionClosed is only raised by getresponse() * ConnectionClosed wraps ECONNRESET from the first recv() of the status line, but not after part of the status line has already been received With this I hope code for making idempotent requests on a persistent connection would look a bit like this: def idempotent_request(connection) try: attempt_request(connection, ...) response = connection.get_response() if response.status == HTTPStatus.REQUEST_TIMEOUT: raise ConnectionClosed(response.reason) except ConnectionClosed: attempt_request(connection, ...) response = connection.get_response() return response def attempt_request(connection): try: connection.request(...) except ConnectionError: pass # Ignore and read server response ---------- keywords: +patch Added file: http://bugs.python.org/file37834/ConnectionClosed.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 10:15:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 24 Jan 2015 09:15:16 +0000 Subject: [issue22885] Arbitrary code execution vulnerability due to unchecked eval() call in dumbdbm module In-Reply-To: <1416163141.0.0.643597983294.issue22885@psf.upfronthosting.co.za> Message-ID: <1422090916.86.0.0209477352925.issue22885@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Raising dbm.dumb.error is behavior change. It would be safer not apply this part in maintained releases. If add sanity checks in 3.5, note that following line "key = key.encode('Latin-1')" can raise an exception too (AttributeError or UnicodeEncodeError). And incorrect data can cause an error later in __getitem__ if pos_and_siz_pair is not a pair of two integers. I think it is worth to split this issue on two issues and fix only security issue here. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 11:44:12 2015 From: report at bugs.python.org (Claudiu Popa) Date: Sat, 24 Jan 2015 10:44:12 +0000 Subject: [issue22885] Arbitrary code execution vulnerability due to unchecked eval() call in dumbdbm module In-Reply-To: <1416163141.0.0.643597983294.issue22885@psf.upfronthosting.co.za> Message-ID: <1422096252.59.0.104024372191.issue22885@psf.upfronthosting.co.za> Claudiu Popa added the comment: Thanks, Serhiy. Only the security issue is fixed in this patch, since eval is replaced by ast.literal_eval and nothing else. Indeed, if the data is something else than what dbm expects after ast.literal_eval, then it would fail, but it would have failed previously too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 11:53:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 24 Jan 2015 10:53:49 +0000 Subject: [issue22885] Arbitrary code execution vulnerability due to unchecked eval() call in dumbdbm module In-Reply-To: <1416163141.0.0.643597983294.issue22885@psf.upfronthosting.co.za> Message-ID: <1422096829.85.0.28949469171.issue22885@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I mean that raising dbm.dumb.error is different issue unrelated to changing eval to ast.literal_eval. See also Raymond's objections in issue21708. issue22885.patch LGTM. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 12:02:00 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 24 Jan 2015 11:02:00 +0000 Subject: [issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__ In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za> Message-ID: <1422097320.7.0.940954678485.issue4395@psf.upfronthosting.co.za> Nick Coghlan added the comment: While Martin's patch doesn't cover all the vagaries of comparison operations discussed above, it fixes the outright error, and provides an appropriate cross-reference to functools.total_ordering. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 12:17:08 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 24 Jan 2015 11:17:08 +0000 Subject: [issue23232] 'codecs' module functionality + its docs -- concerning custom codecs, especially non-string ones In-Reply-To: <1421161467.08.0.0207328104239.issue23232@psf.upfronthosting.co.za> Message-ID: <1422098228.95.0.940990368647.issue23232@psf.upfronthosting.co.za> Nick Coghlan added the comment: Unfortunately, a lot of these things aren't well defined in the docs because they're not especially well defined, period. The codecs module works very well if you stick to the common, well-tested paths (primarily the text encodings), but it's complex enough that there are quite a few dark corners as well. The functional changes in 3.4 and Martin's documentation updates in issue 19548 certainly improved things a bit further. I'm inclined to agree with Marc-Andre's comment on 20132, that we're a bit down in the weeds at the moment, without a clear shared vision of where we *want* to be for the codecs module. A couple of other big issues with the current design of the module are the fact you can't register a codec directly, you have to register a search function (which you then can't unregister) and the fact that the "is a text encoding" flag I added for 3.4 is private, rather than a generally available capability. In terms of this issue, until Martin's last patch, the error handling documentation basically all assumed text codecs. The changes in that patch clarified some areas that could be tested with the bytes-bytes codecs, but left others still vague because it isn't clear what's intended behaviour, and what's an implementation accident in CPython. I've added MAL to the nosy list here as well, since if anyone is going to know the *intended* interaction between error handlers and arbitrary codecs its MAL. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 12:20:18 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 24 Jan 2015 11:20:18 +0000 Subject: [issue23232] 'codecs' module functionality + its docs -- concerning custom codecs, especially non-string ones In-Reply-To: <1421161467.08.0.0207328104239.issue23232@psf.upfronthosting.co.za> Message-ID: <1422098418.06.0.829034856725.issue23232@psf.upfronthosting.co.za> Nick Coghlan added the comment: Regarding the 6 vs 4 interfaces, what's really needed there is a clearer explanation of what functionality depends on each of the three interfaces (basic, stream, incremental), so that a codec developer has a clearer understanding of what won't work if they don't provide a particular interface. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 13:23:33 2015 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 24 Jan 2015 12:23:33 +0000 Subject: [issue23292] Enum doc suggestion In-Reply-To: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za> Message-ID: <1422102213.55.0.7855149694.issue23292@psf.upfronthosting.co.za> Eli Bendersky added the comment: I'm not sure why the current situation is annoying? Python explicitly does not pollute the enclosing namespace with an Enum's members. So when you: import A It's fairly natural that you have access to A.MyEnum and not its members, no? Some modules (like some stdlib modules) may choose to push the enum members up to the module's scope explicitly, but I wouldn't necessarily call it best practice. Namespacing is Pythonic, splashing contents of classes into enclosing namespaces isn't. So I guess what I'm trying to say is that I don't see a reason to explicitly suggest something that is, in general, against the spirit of Python, in the documentation. [P.S. Thanks for reporting, Mark, I love your books!] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 13:40:46 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 24 Jan 2015 12:40:46 +0000 Subject: [issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__ In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za> Message-ID: <1422103246.05.0.874048467624.issue4395@psf.upfronthosting.co.za> Martin Panter added the comment: The reference to @functools.total_ordering was actually already there; I just moved it into the paragraph about relationships between the operators. I should also point out that my description of the default __ne__() assumes that Issue 21408 is resolved; the current behaviour is slightly different. If you think something else could be added to the patch, I?m happy to try and add it. Perhaps the default object.__eq__() behaviour? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 13:48:06 2015 From: report at bugs.python.org (Georg Brandl) Date: Sat, 24 Jan 2015 12:48:06 +0000 Subject: [issue23292] Enum doc suggestion In-Reply-To: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za> Message-ID: <1422103686.9.0.894835555922.issue23292@psf.upfronthosting.co.za> Georg Brandl added the comment: I disagree. I assume that many new enums will be a replacement for module-level constants, but these still have to be available on the module. Keeping backward compatibility is not against the spirit of Python :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 13:54:56 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 24 Jan 2015 12:54:56 +0000 Subject: [issue23307] python hangs on call to numpy.outer In-Reply-To: <1422081470.94.0.280484065129.issue23307@psf.upfronthosting.co.za> Message-ID: <1422104096.86.0.349504358006.issue23307@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 13:57:20 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 24 Jan 2015 12:57:20 +0000 Subject: [issue22286] Allow backslashreplace error handler to be used on input In-Reply-To: <1409136620.65.0.397738586583.issue22286@psf.upfronthosting.co.za> Message-ID: <1422104240.44.0.281944223545.issue22286@psf.upfronthosting.co.za> Nick Coghlan added the comment: +1 from me for merging, although I suspect you'll need to adjust the codecs.rst changes first. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 13:59:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 24 Jan 2015 12:59:12 +0000 Subject: [issue21076] Turn signal.SIG* constants into enums In-Reply-To: <1395935330.94.0.38028035584.issue21076@psf.upfronthosting.co.za> Message-ID: <1422104352.15.0.227580229611.issue21076@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Now signal.signal() accepts inappropriate types. >>> signal.signal(signal.SIGHUP, 0.0) >>> signal.signal(signal.SIGHUP, '0') In 3.4 it raised an exception. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 13:59:30 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 24 Jan 2015 12:59:30 +0000 Subject: [issue9740] Support for HTTP 1.1 persistent connections throughout the standard library In-Reply-To: <1283428611.84.0.131704513964.issue9740@psf.upfronthosting.co.za> Message-ID: <1422104370.84.0.232188004475.issue9740@psf.upfronthosting.co.za> Martin Panter added the comment: See Issue 3566 about tweaking the ?http.client? module?s BadStatusLine handling to be more helpful when implementing persistent connections. I am dumping some thoughts here about persistent connections with the ?http.client? module, gained by working on that bug. * Lib/xmlrpc/client.py appears to have persistent connection support, so may be useful for this bug. * RFC 7230 ?6.5 mentions monitoring for connection closure. This could be be partly implemented inside HTTPConnection by polling for closure before sending a request, but to fully implement might require the co-operation of the user calling into the module to check for closure at other times using select() or similar. * Current ?http.client? assumes that each socket.makefile() object will not buffer any data from a subsequent response. Unsure if this is a problem in the real world, but I ran into it implementing test cases. E.g. if the server anticipates the first few bytes of the subsequent response: c.send(b"HTTP/1.1 200 Okay\r\nContent-Length: 0\r\n\r\n" b"HTTP/") then the client misses the ?HTTP/? and raises BadStatusLine("1.1 200 Okay\r\n"). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 14:02:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 24 Jan 2015 13:02:21 +0000 Subject: [issue21076] Turn signal.SIG* constants into enums In-Reply-To: <1395935330.94.0.38028035584.issue21076@psf.upfronthosting.co.za> Message-ID: <1422104541.9.0.614893051175.issue21076@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And more: >>> import signal >>> signal.signal(1.2, signal.SIG_DFL) >>> signal.signal('1', signal.SIG_DFL) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 14:02:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 24 Jan 2015 13:02:43 +0000 Subject: [issue23292] Enum doc suggestion In-Reply-To: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za> Message-ID: <1422104563.48.0.634533043144.issue23292@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Agree with Eli. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 14:03:33 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 24 Jan 2015 13:03:33 +0000 Subject: [issue23268] Fix comparison of ipaddress classes In-Reply-To: <1421611358.75.0.717594852846.issue23268@psf.upfronthosting.co.za> Message-ID: <1422104613.66.0.475070042678.issue23268@psf.upfronthosting.co.za> Nick Coghlan added the comment: +1, looks good to me. That test for ordering and comparison interoperability is actually pretty neat - I wonder if we could make it more generally available as a "check my class handles NotImplemented correctly" check (in unittest?), which would potentially be useful in pursuing a fix for issue #11477. The fact the default __ne__ implementation doesn't handle NotImplemented correctly should probably be filed as a separate issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 14:06:02 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 24 Jan 2015 13:06:02 +0000 Subject: [issue17840] base64_codec uses assert for runtime validity checks In-Reply-To: <1366875650.57.0.151905786577.issue17840@psf.upfronthosting.co.za> Message-ID: <1422104762.54.0.22219764578.issue17840@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'd be slightly more inclined to file the fact that "ignore" isn't supported by the base64 codec as a potential bug, with changing the docs as one possible resolution. It shouldn't hold up switching from the assertions to proper runtime checks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 14:22:28 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 24 Jan 2015 13:22:28 +0000 Subject: [issue21862] cProfile command-line should accept "-m module_name" as an alternative to script path In-Reply-To: <1403640414.18.0.449527177368.issue21862@psf.upfronthosting.co.za> Message-ID: <1422105748.04.0.647909673204.issue21862@psf.upfronthosting.co.za> Nick Coghlan added the comment: I haven't looked into the details of how cProfile handles command line arguments, but potentially relevant is issue #19982, which proposes adding a "target" parameter that lets runpy run in the context of an existing module object, rather than always creating its own. However, if this can be implemented without that, go ahead - it can always be refactored later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 14:52:40 2015 From: report at bugs.python.org (Marien Zwart) Date: Sat, 24 Jan 2015 13:52:40 +0000 Subject: [issue23309] Hang on interpreter shutdown if daemon thread prints to stdout Message-ID: <1422107560.4.0.0145420431804.issue23309@psf.upfronthosting.co.za> New submission from Marien Zwart: A script spawning a single daemon thread calling print() in a loop (like the attached) will usually hang on shutdown in Python 3.4.2 and hg rev 8d802fb6ae32. Attaching gdb at that point shows the following: (gdb) thread apply all bt Thread 1 (Thread 0x7fd927d58700 (LWP 30274)): #0 sem_wait () at ../sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85 #1 0x00000000005282fe in PyThread_acquire_lock_timed (lock=0x1c5ea30, microseconds=microseconds at entry=-1, intr_flag=intr_flag at entry=0) at Python/thread_pthread.h:352 #2 0x0000000000528414 in PyThread_acquire_lock (lock=, waitflag=waitflag at entry=1) at Python/thread_pthread.h:556 #3 0x0000000000567e4c in _enter_buffered_busy (self=0x7fd927bc2b48) at ./Modules/_io/bufferedio.c:327 #4 buffered_flush (self=0x7fd927bc2b48, args=) at ./Modules/_io/bufferedio.c:874 #5 0x000000000042822a in PyObject_Call (func=0x7fd9277b69d8, arg=, kw=) at Objects/abstract.c:2086 #6 0x00000000004290e4 in call_function_tail (args=0x7fd927b8d048, callable=0x7fd9277b69d8) at Objects/abstract.c:2124 #7 callmethod (is_size_t=1, va=0x7fff5c6cf6b0, format=0x0, func=0x7fd9277b69d8) at Objects/abstract.c:2193 #8 _PyObject_CallMethodId_SizeT (o=, name=, format=0x0) at Objects/abstract.c:2279 #9 0x000000000042822a in PyObject_Call (func=0x7fd9277b6990, arg=, kw=) at Objects/abstract.c:2086 #10 0x0000000000428cc4 in call_function_tail (args=0x7fd927b8d048, callable=0x7fd9277b6990) at Objects/abstract.c:2124 #11 callmethod (is_size_t=0, va=0x7fff5c6cf7e0, format=0x5b9924 "", func=0x7fd9277b6990) at Objects/abstract.c:2193 #12 _PyObject_CallMethodId (o=o at entry=0x7fd927b5d3a8, name=name at entry=0x862b00 , format=format at entry=0x5b9924 "") at Objects/abstract.c:2238 #13 0x000000000050a521 in flush_std_files () at Python/pylifecycle.c:488 #14 0x000000000050a5aa in Py_Finalize () at Python/pylifecycle.c:550 #15 0x000000000041fc92 in Py_Main (argc=-1, argv=0x1) at Modules/main.c:787 #16 0x000000000041be3c in main (argc=2, argv=) at ./Programs/python.c:69 The daemon thread has exited, and the main thread hangs trying to flush stdout. I haven't fully tracked down what happens here, but I think it's this: - daemon thread calls ENTER_BUFFERED on stdout - daemon thread drops the GIL before writing to stdout - main thread grabs the GIL and starts exiting - main thread sets _Py_Finalizing, signaling daemon threads to exit - main thread calls flush_std_files and drops the GIL - daemon thread grabs the GIL and immediately exits, without reaching LEAVE_BUFFERED - main thread deadlocks trying to ENTER_BUFFERED the same file If that is what happens, I don't really see how to fix it (it's an example of daemon threads not releasing their resources, which the documentation warns about). But it's obviously unfortunate if merely writing to stdout/err is such a resource. ---------- components: Interpreter Core files: dio.py messages: 234615 nosy: marienz priority: normal severity: normal status: open title: Hang on interpreter shutdown if daemon thread prints to stdout type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37835/dio.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 15:09:15 2015 From: report at bugs.python.org (Kevin Dwyer) Date: Sat, 24 Jan 2015 14:09:15 +0000 Subject: [issue23308] a bug in Instructions section 4.1 In-Reply-To: <1867408449.522169.1422083738920.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1422108555.04.0.397463859571.issue23308@psf.upfronthosting.co.za> Kevin Dwyer added the comment: @Dmot Can you be more specific about the problem? A link to the instructions that you are following and a verbatim copy of any error message that you see would help to identify what's going wrong. ---------- nosy: +kdwyer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 16:07:47 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 24 Jan 2015 15:07:47 +0000 Subject: [issue23268] Fix comparison of ipaddress classes In-Reply-To: <1421611358.75.0.717594852846.issue23268@psf.upfronthosting.co.za> Message-ID: <1422112067.05.0.896212827951.issue23268@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > The fact the default __ne__ implementation doesn't handle NotImplemented correctly should probably be filed as a separate issue. May be this is a part of issue21408. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 16:18:29 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 24 Jan 2015 15:18:29 +0000 Subject: [issue23268] Fix comparison of ipaddress classes In-Reply-To: <1421611358.75.0.717594852846.issue23268@psf.upfronthosting.co.za> Message-ID: <1422112709.55.0.606509288601.issue23268@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +delegation of `!=` to the right-hand side argument is not always done _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 16:31:45 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 24 Jan 2015 15:31:45 +0000 Subject: [issue21408] delegation of `!=` to the right-hand side argument is not always done In-Reply-To: <1398954687.6.0.574462939929.issue21408@psf.upfronthosting.co.za> Message-ID: <1422113505.79.0.597500768967.issue21408@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Particular case of this bug: >>> class A: ... def __eq__(self, other): return NotImplemented ... >>> A().__eq__(object()) NotImplemented >>> A().__ne__(object()) True The second result should be NotImplemented. Martin's patch LGTM except few style nitpicks to tests. ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 17:32:12 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 24 Jan 2015 16:32:12 +0000 Subject: [issue23199] libpython27.a in amd64 release is 32-bit In-Reply-To: <1420764337.42.0.255694319213.issue23199@psf.upfronthosting.co.za> Message-ID: <1422117132.52.0.728412554215.issue23199@psf.upfronthosting.co.za> Steve Dower added the comment: It looks like #1088716 is where the change was made a bit over 10 years ago. Adding Paul to see if he has any further insight, but I'm pretty sure at that point there was no 64-bit Python (there certainly wasn't a 64-bit Windows that people were using), and probably nobody noticed/cared that it wasn't there. It may even have been missing completely from the 64-bit installer until I took over building and started doing it slightly differently from Martin. I've attached a patch for msi.py that will use mingw-w64's tools when building the installer, but I suspect we're better off putting the instructions there rather than hoping build versions match. Is there a mingw list we can post this thread to for opinions from more people who depend on this lib? ---------- keywords: +patch nosy: +pmoore Added file: http://bugs.python.org/file37836/23199.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 17:45:38 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 24 Jan 2015 16:45:38 +0000 Subject: [issue21408] delegation of `!=` to the right-hand side argument is not always done In-Reply-To: <1398954687.6.0.574462939929.issue21408@psf.upfronthosting.co.za> Message-ID: <1422117938.25.0.188343741254.issue21408@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There are few incorrect implementations of __ne__ in the stdlib. Updated patch removes them. May be we should remove all implementations of __ne__ which are redundant now. ---------- Added file: http://bugs.python.org/file37837/method-not-operator-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 17:49:22 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 24 Jan 2015 16:49:22 +0000 Subject: [issue23253] Delay-load ShellExecute In-Reply-To: <1421449910.62.0.491687570058.issue23253@psf.upfronthosting.co.za> Message-ID: <1422118162.12.0.787477331696.issue23253@psf.upfronthosting.co.za> Steve Dower added the comment: I assume you're referring to normal_startup and startup_nosite in perf.py at h.p.o/benchmarks? Handy to know about (I need to explore our top-level repos more often, obviously), but probably still not going to measure time in the Windows PE loader as accurately as it'd need to be to conclusively prove a speed advantage. I'd probably need to hit up the Windows team for some of their profiling tools to get good numbers here. Still, it's indisputable that this change will reduce the initial memory overhead, so I'll take Tim's 0.75 and run with it :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 17:54:29 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 24 Jan 2015 16:54:29 +0000 Subject: [issue23253] Delay-load ShellExecute In-Reply-To: <1421449910.62.0.491687570058.issue23253@psf.upfronthosting.co.za> Message-ID: <20150124165354.75792.59170@psf.io> Roundup Robot added the comment: New changeset 5bff604a864e by Steve Dower in branch 'default': Closes #23253: Delay-load ShellExecute https://hg.python.org/cpython/rev/5bff604a864e ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 18:20:39 2015 From: report at bugs.python.org (berdario) Date: Sat, 24 Jan 2015 17:20:39 +0000 Subject: [issue23310] MagicMock constructor configuration fails for magic methods Message-ID: <1422120039.57.0.541541438715.issue23310@psf.upfronthosting.co.za> New submission from berdario: I guess this should be expected... too much magic :P >>> from unittest.mock import MagicMock >>> MagicMock(**{'__hash__.return_value': "FIXME"}) Traceback (most recent call last): File "", line 1, in File "/nix/store/qlvbf3n3y34idxcgwwhsi9pq26v28q99-python3-3.4.2/lib/python3.4/unittest/mock.py", line 1772, in __init__ _safe_super(MagicMixin, self).__init__(*args, **kw) File "/nix/store/qlvbf3n3y34idxcgwwhsi9pq26v28q99-python3-3.4.2/lib/python3.4/unittest/mock.py", line 881, in __init__ _spec_state, _new_name, _new_parent, **kwargs File "/nix/store/qlvbf3n3y34idxcgwwhsi9pq26v28q99-python3-3.4.2/lib/python3.4/unittest/mock.py", line 410, in __init__ self.configure_mock(**kwargs) File "/nix/store/qlvbf3n3y34idxcgwwhsi9pq26v28q99-python3-3.4.2/lib/python3.4/unittest/mock.py", line 560, in configure_mock setattr(obj, final, val) AttributeError: 'method-wrapper' object has no attribute 'return_value' The same happens with e.g. __str__ >>> m.configure_mock(**{'__hash__.return_value': 1}) works just fine, instead ---------- components: Library (Lib) messages: 234623 nosy: berdario priority: normal severity: normal status: open title: MagicMock constructor configuration fails for magic methods versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 18:40:01 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 24 Jan 2015 17:40:01 +0000 Subject: [issue23311] Update PC/example_nt and extending/windows.rst Message-ID: <1422121201.94.0.918332856849.issue23311@psf.upfronthosting.co.za> New submission from Steve Dower: The installer for 3.5 will include an option to install debug binaries alongside the release ones, so we should update extending/windows.rst to explain that and generally describe how to build an extension. It should also refer to python3.dll at least once... The example project in PC/example_nt is fairly outdated. It could be updated to automatically find a 3.5 install and use the debug or release binaries/libraries from there. We could also include a 'test' project for PTVS (http://pytools.codeplex.com/) that helps write Python code for testing the extension and also has mixed-mode debugging enabled so people can step between the Python and the C code. (In fact, the PTVS team wants to do a sample project like this anyway, so maybe we can remove PC/example_nt and point to theirs...) ---------- assignee: docs at python components: Documentation, Windows messages: 234624 nosy: docs at python, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Update PC/example_nt and extending/windows.rst versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 18:42:05 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 24 Jan 2015 17:42:05 +0000 Subject: [issue23312] google thinks the docs are mobile unfriendly Message-ID: <1422121325.13.0.140473067698.issue23312@psf.upfronthosting.co.za> New submission from Benjamin Peterson: According to Google webmaster tools, the documentation has the following failings on mobile devices: - The font size is too small. https://developers.google.com/speed/docs/insights/UseLegibleFontSizes - The viewport is not configured. - Touch controls are too close together. You can look at the complaints on (for example) https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fdocs.python.org%2F3%2Flibrary%2Ffunctions.html ---------- assignee: docs at python components: Documentation messages: 234625 nosy: benjamin.peterson, docs at python priority: normal severity: normal stage: needs patch status: open title: google thinks the docs are mobile unfriendly type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 18:44:24 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 24 Jan 2015 17:44:24 +0000 Subject: [issue23311] Update PC/example_nt and extending/windows.rst In-Reply-To: <1422121201.94.0.918332856849.issue23311@psf.upfronthosting.co.za> Message-ID: <1422121464.09.0.180740186158.issue23311@psf.upfronthosting.co.za> Steve Dower added the comment: This is probably also a good place to refer to the changes in #22980 and how they can help when building extensions outside of distutils. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 18:49:53 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 24 Jan 2015 17:49:53 +0000 Subject: [issue23257] Update Windows build/setup instructions in devguide In-Reply-To: <1421514832.21.0.130284458039.issue23257@psf.upfronthosting.co.za> Message-ID: <20150124174949.87123.17956@psf.io> Roundup Robot added the comment: New changeset 41d2d182c260 by Steve Dower in branch 'default': Issue 23257: Update Windows build/setup instructions. https://hg.python.org/devguide/rev/41d2d182c260 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 18:50:13 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 24 Jan 2015 17:50:13 +0000 Subject: [issue23257] Update Windows build/setup instructions in devguide In-Reply-To: <1421514832.21.0.130284458039.issue23257@psf.upfronthosting.co.za> Message-ID: <1422121813.51.0.699099243224.issue23257@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 18:58:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 24 Jan 2015 17:58:34 +0000 Subject: [issue23312] google thinks the docs are mobile unfriendly In-Reply-To: <1422121325.13.0.140473067698.issue23312@psf.upfronthosting.co.za> Message-ID: <1422122314.6.0.513233148294.issue23312@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +georg.brandl, serhiy.storchaka versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 19:03:37 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 24 Jan 2015 18:03:37 +0000 Subject: [issue23260] Update Windows installer In-Reply-To: <1421536361.51.0.300522765173.issue23260@psf.upfronthosting.co.za> Message-ID: <1422122617.22.0.0495784703044.issue23260@psf.upfronthosting.co.za> Steve Dower added the comment: Updated patch, and hopefully it will make it into review this time. I deliberately excluded the image for the using/windows.rst documentation but you can see it at http://imgur.com/CdQaBmp ---------- Added file: http://bugs.python.org/file37838/23260_3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 19:07:24 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 24 Jan 2015 18:07:24 +0000 Subject: [issue23311] Update PC/example_nt and extending/windows.rst In-Reply-To: <1422121201.94.0.918332856849.issue23311@psf.upfronthosting.co.za> Message-ID: <1422122844.99.0.101788417229.issue23311@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 19:19:09 2015 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 24 Jan 2015 18:19:09 +0000 Subject: [issue23292] Enum doc suggestion In-Reply-To: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za> Message-ID: <1422123549.04.0.447063856007.issue23292@psf.upfronthosting.co.za> Eli Bendersky added the comment: Georg, each library writer is entitled to do whatever she wants. Naturally, we can't prevent dumping contents of enums into the module namespaces, and yes, backwards compatibility makes sense for some modules. However, that's tangential to *encouraging* this un-Pythonic behavior by including the trick in the official documentation. After all, namespaces is a good idea (from the Zen of Python), and Enums as namespaces are also a good idea (self-documenting code). There's a huge amount of tricks we could add to the documentation, but we don't. There's wikis for that, blogs, Stack Overflow, Active Python recipes, what have you. I wouldn't spend too much time arguing about this, though. If you feel strongly that this belongs in the standard documentation, go ahead. I just wanted to provide an alternative view of the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 19:42:16 2015 From: report at bugs.python.org (Paul Moore) Date: Sat, 24 Jan 2015 18:42:16 +0000 Subject: [issue23199] libpython27.a in amd64 release is 32-bit In-Reply-To: <1420764337.42.0.255694319213.issue23199@psf.upfronthosting.co.za> Message-ID: <1422124936.55.0.481027167908.issue23199@psf.upfronthosting.co.za> Paul Moore added the comment: There's a lot of politics around the mingw vs mingw64 situation, but in practice I believe the various mingw64 builds are fine. So I see no reason not to supply a correct 64-bit libpythonXY.a. When the patch was made to include the libpythonXY.a file to the msi (wow! I'd forgotten I'd ever done a patch for the MSI build) there was only 32-bit systems, and there certainly wasnt't a 64-bit mingw. The added patch seems like a reasonable approach. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 20:01:58 2015 From: report at bugs.python.org (Gerrit Barrere) Date: Sat, 24 Jan 2015 19:01:58 +0000 Subject: [issue23313] Wrong complex variable being altered Message-ID: <1422126117.91.0.00617792248129.issue23313@psf.upfronthosting.co.za> New submission from Gerrit Barrere: The bug occurs on line 77 of the attached script. When I change the imaginary part of 'z' on line 77, it also changes the imaginary part of 'zload', which is supposed to remain constant. Putting a dummy assignment 'z = z + 0' on line 76 fixes the bug. This is all described in the comments around line 77 also. I found this in the PyCharm IDE by putting a breakpoint just after line 77 and watching variables 'z' and 'zload'. The function 'model()' is called repeatedly in this script, and you can see 'zload' changing every time the function is called. ---------- files: ComplexBug.py messages: 234631 nosy: CarpeCimex priority: normal severity: normal status: open title: Wrong complex variable being altered type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file37839/ComplexBug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 20:13:42 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 24 Jan 2015 19:13:42 +0000 Subject: [issue23313] Wrong complex variable being altered In-Reply-To: <1422126117.91.0.00617792248129.issue23313@psf.upfronthosting.co.za> Message-ID: <1422126822.42.0.688046790612.issue23313@psf.upfronthosting.co.za> Benjamin Peterson added the comment: That's because "z" and "zload" are still referencing the same object. http://nedbatchelder.com/text/names.html ---------- nosy: +benjamin.peterson resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 20:25:07 2015 From: report at bugs.python.org (Georg Brandl) Date: Sat, 24 Jan 2015 19:25:07 +0000 Subject: [issue23292] Enum doc suggestion In-Reply-To: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za> Message-ID: <1422127507.79.0.353585453053.issue23292@psf.upfronthosting.co.za> Georg Brandl added the comment: Likewise, I don't feel strongly that it *should* go in, but I wouldn't object to it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 20:27:57 2015 From: report at bugs.python.org (Georg Brandl) Date: Sat, 24 Jan 2015 19:27:57 +0000 Subject: [issue23312] google thinks the docs are mobile unfriendly In-Reply-To: <1422121325.13.0.140473067698.issue23312@psf.upfronthosting.co.za> Message-ID: <1422127677.31.0.533887776094.issue23312@psf.upfronthosting.co.za> Georg Brandl added the comment: Yes, the theme is anything but "responsive". If someone already knows how to do this, please step forward. I guess it's not too hard to move the sidebar to the top/bottom on mobile, and adapt the font sizes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 20:40:18 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 24 Jan 2015 19:40:18 +0000 Subject: [issue23312] google thinks the docs are mobile unfriendly In-Reply-To: <1422121325.13.0.140473067698.issue23312@psf.upfronthosting.co.za> Message-ID: <1422128418.13.0.58342077734.issue23312@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 20:43:49 2015 From: report at bugs.python.org (Ent) Date: Sat, 24 Jan 2015 19:43:49 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1422128629.81.0.390687893107.issue23255@psf.upfronthosting.co.za> Ent added the comment: New patch for review! Let me know if anything is missing. ---------- Added file: http://bugs.python.org/file37840/jan24th.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 21:59:05 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 24 Jan 2015 20:59:05 +0000 Subject: [issue23300] httplib is using a method that doesn't exist In-Reply-To: <1421927408.72.0.18242677241.issue23300@psf.upfronthosting.co.za> Message-ID: <20150124205826.84275.53833@psf.io> Roundup Robot added the comment: New changeset c2bba3c9424b by Senthil Kumaran in branch '2.7': Fix Issue23300 : httplib.HTTP classe's connect method should use _get_hostport https://hg.python.org/cpython/rev/c2bba3c9424b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 21:59:35 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 24 Jan 2015 20:59:35 +0000 Subject: [issue23260] Update Windows installer In-Reply-To: <1421536361.51.0.300522765173.issue23260@psf.upfronthosting.co.za> Message-ID: <1422133175.61.0.708115068285.issue23260@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 22:00:31 2015 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 24 Jan 2015 21:00:31 +0000 Subject: [issue23300] httplib is using a method that doesn't exist In-Reply-To: <1421927408.72.0.18242677241.issue23300@psf.upfronthosting.co.za> Message-ID: <1422133231.71.0.0344764750968.issue23300@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Fixed in 2.7. Other versions do not have this bug. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 22:01:47 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 24 Jan 2015 21:01:47 +0000 Subject: [issue23300] httplib is using a method that doesn't exist In-Reply-To: <1422133231.71.0.0344764750968.issue23300@psf.upfronthosting.co.za> Message-ID: <1422133305.1379502.218351869.4A678E83@webmail.messagingengine.com> Benjamin Peterson added the comment: On Sat, Jan 24, 2015, at 16:00, Senthil Kumaran wrote: > > Senthil Kumaran added the comment: > > Fixed in 2.7. Other versions do not have this bug. Thank you! Would porting the tests be useful, though? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 24 22:05:01 2015 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 24 Jan 2015 21:05:01 +0000 Subject: [issue23300] httplib is using a method that doesn't exist In-Reply-To: <1421927408.72.0.18242677241.issue23300@psf.upfronthosting.co.za> Message-ID: <1422133501.79.0.571305525239.issue23300@psf.upfronthosting.co.za> Senthil Kumaran added the comment: > Would porting the tests be useful, though? Yes, it will be useful to port the tests to 3.4 and default branch. I will do that. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 00:27:24 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 24 Jan 2015 23:27:24 +0000 Subject: [issue23314] Disabling CRT asserts in debug build Message-ID: <1422142044.09.0.973511381337.issue23314@psf.upfronthosting.co.za> New submission from Steve Dower: When we completely switch Windows builds over to VC14, we're going to encounter some new assert dialogs from the CRT. These won't appear in release builds, but because the buildbots run tests against debug builds they will get in the way. A number of tests attempt operations on bad file descriptors, which will assert and terminate in MSVCRT (I have a fix for the termination coming, but the assertions will still appear). Currently regrtest has a "-n" flag to disable assertions using an MSVCRT function. This works fine with the exception of subprocesses, that do not inherit the setting. The setting is process-wide, so we can't just turn assertions off around the code that may assert. We also can't turn them off completely without affecting users (e.g. #3545 and #4804). #4804 has the discussion leading to the current state where _PyVerify_fd and the -n flag above exist. The _PyVerify_fd function could break with future CRT changes (bearing in mind that Python 3.5 and later will automatically use the latest installed CRT), for which there is an official workaround coming soon, except it won't suppress the assertion dialog for debug builds. I'd like to propose three options: 1. Make faulthandler.enable() also disable assertions in debug builds. (Assertions are for debugging, and enabling faulthandler - at least on Windows - seems to suggest that you want to override the debugger. We also already enable faulthandler for subprocesses in the test suite.) 2. Add an environment variable (PYTHONDISABLECRTASSERT?) and use it to disable assertions on startup. (It looks like at least some tests deliberately block envvars flowing through to subprocesses, so this may require test changes too.) 3. Add a new xoption and use it to disable assertions on startup. Obviously we could do all three, though I kind of like the first one best. Currently, I'm planning to make debug builds available alongside the release versions, as they are necessary for people to build debuggable versions of their extensions, so this is more important than it was in the past. But the problem is very much only on the buildbots/in the test suite and not on user's machines. Thoughts? ---------- components: Windows messages: 234640 nosy: haypo, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Disabling CRT asserts in debug build type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 01:30:55 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 25 Jan 2015 00:30:55 +0000 Subject: [issue21548] pydoc -k IndexError on empty docstring In-Reply-To: <1400661783.43.0.558471008968.issue21548@psf.upfronthosting.co.za> Message-ID: <1422145855.29.0.854349815184.issue21548@psf.upfronthosting.co.za> Berker Peksag added the comment: Here's a patch with tests. ---------- nosy: +berker.peksag stage: -> patch review Added file: http://bugs.python.org/file37841/issue21548.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 01:43:07 2015 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 25 Jan 2015 00:43:07 +0000 Subject: [issue23300] httplib is using a method that doesn't exist In-Reply-To: <1421927408.72.0.18242677241.issue23300@psf.upfronthosting.co.za> Message-ID: <1422146587.95.0.611723125166.issue23300@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Actually, the same tests cannot be ported to 3.4 or default. httplib.HTTP class has been merged to HTTPConnection in 3.x and we don't allow a host, and port in connect(). There is good test coverage for verifying host, port in test_hort_port test in 3.x However, I saw that TunnelTests could see some refactor and a test addition to cover the _tunnel_host, _tunnel_port attributes (which are set using _get_hostport method). Attaching a change to client.test_httplib which refactors TunnelTest and adds a new test called test_set_tunnel_host_port_headers. Please review if this change is Okay. I can push this in 3.4 and default branches. Thanks! ---------- Added file: http://bugs.python.org/file37842/23300-3.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 01:52:01 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 25 Jan 2015 00:52:01 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1422147121.19.0.114723701503.issue3566@psf.upfronthosting.co.za> Martin Panter added the comment: Updated v2 patch. This version avoids intruding into the HTTPConnection.connect() implementation, so that users, tests, etc may still set the undocumented ?sock? attribute without calling the base connect() method. Also code style changes based on feedback to another of my patches. ---------- versions: -Python 2.7, Python 3.4 Added file: http://bugs.python.org/file37843/ConnectionClosed.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 02:01:49 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 25 Jan 2015 01:01:49 +0000 Subject: [issue23232] 'codecs' module functionality + its docs -- concerning custom codecs, especially non-string ones In-Reply-To: <1421161467.08.0.0207328104239.issue23232@psf.upfronthosting.co.za> Message-ID: <1422147709.68.0.952643033224.issue23232@psf.upfronthosting.co.za> Martin Panter added the comment: I am certainly no expert, but this is how I understand the three different kinds of codecs are used: * Stateless codecs: str.encode(), bytes.decode(), etc * Incremental codecs: TextIOWrapper, IncrementalNewlineDecoder * Stream codecs: only stuff inside the ?codecs? module as far as I know: codecs.open(), EncodedFile() etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 02:34:22 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 25 Jan 2015 01:34:22 +0000 Subject: [issue23300] httplib is using a method that doesn't exist In-Reply-To: <1421927408.72.0.18242677241.issue23300@psf.upfronthosting.co.za> Message-ID: <1422149662.14.0.363134835129.issue23300@psf.upfronthosting.co.za> Berker Peksag added the comment: + self.assertDictEqual(self.conn._tunnel_headers, tunnel_headers) You could just use assertEqual. Quoting from docs: "The list of type-specific methods automatically used by assertEqual() are summarized in the following table. Note that it?s usually not necessary to invoke these methods directly." https://docs.python.org/3/library/unittest.html#unittest.TestCase.addTypeEqualityFunc + self.assertTrue(b'CONNECT destination.com' in self.conn.sock.data) + self.assertTrue(b'Host: destination.com' in self.conn.sock.data) You could use assertIn instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 02:38:03 2015 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 25 Jan 2015 01:38:03 +0000 Subject: [issue23300] httplib is using a method that doesn't exist In-Reply-To: <1421927408.72.0.18242677241.issue23300@psf.upfronthosting.co.za> Message-ID: <1422149883.98.0.442696225411.issue23300@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Thanks for the review comments. Updated the patch with the suggested changes. ---------- Added file: http://bugs.python.org/file37844/23300-3.3-v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 02:58:56 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 25 Jan 2015 01:58:56 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <1420230232.09.0.10127303351.issue23152@psf.upfronthosting.co.za> Message-ID: <1422151136.28.0.68413467105.issue23152@psf.upfronthosting.co.za> Steve Dower added the comment: I updated and tested your patch - basically making posixmodule.c use the new _Py_stat_struct throughout instead of the Win32 definition. The tests run fine on my VC14 machine. Should _Py_fstat be conditioned on Py_LIMITED_API in some way, since it's not available pre-3.5? I've never figured out exactly how that should work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 02:59:17 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 25 Jan 2015 01:59:17 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <1420230232.09.0.10127303351.issue23152@psf.upfronthosting.co.za> Message-ID: <1422151157.73.0.978057309835.issue23152@psf.upfronthosting.co.za> Changes by Steve Dower : Added file: http://bugs.python.org/file37845/py_fstat_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 03:31:54 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 25 Jan 2015 02:31:54 +0000 Subject: [issue23303] test_license_exists_at_url() of test_site fails on "x86 XP-4 3.4" buildbot In-Reply-To: <1421962203.05.0.381123323956.issue23303@psf.upfronthosting.co.za> Message-ID: <1422153114.3.0.444061627574.issue23303@psf.upfronthosting.co.za> Ned Deily added the comment: Are the Windows 3.4 and 3.x builds on the buildbot using different versions of OpenSSL? Certificate verifies would fail with 0.9.7. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 03:54:17 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 25 Jan 2015 02:54:17 +0000 Subject: [issue23300] httplib is using a method that doesn't exist In-Reply-To: <1421927408.72.0.18242677241.issue23300@psf.upfronthosting.co.za> Message-ID: <1422154457.35.0.454985902026.issue23300@psf.upfronthosting.co.za> Berker Peksag added the comment: LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 04:27:37 2015 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 25 Jan 2015 03:27:37 +0000 Subject: [issue23300] httplib is using a method that doesn't exist In-Reply-To: <1421927408.72.0.18242677241.issue23300@psf.upfronthosting.co.za> Message-ID: <1422156457.83.0.926553913313.issue23300@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Committed the test changes in fcab9c106f2f (3.4) and a858cde113f2 (3.5) ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 05:47:50 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 25 Jan 2015 04:47:50 +0000 Subject: =?utf-8?q?=5Bissue20132=5D_Many_incremental_codecs_don=E2=80=99t_handle_f?= =?utf-8?q?ragmented_data?= In-Reply-To: <1388929738.44.0.851837204966.issue20132@psf.upfronthosting.co.za> Message-ID: <1422161270.34.0.0315689012966.issue20132@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a new patch which fixes the bytes-to-bytes incremental codecs. It depends on my patches for these other issues being applied first: * Issue 23231: Bytes-to-bytes support for iteren/decode() * Issue 13881: Generic StreamWriter from IncrementalEncoder * Issue 16473: Clarify and test quopri-codec implementation In addition, without the fix for Issue 20121 (Quoted printable soft line breaking), the patch will apply, but there will be test failures. Summary of the changes in this patch: * Fix simple bz2-codec bug uncovered by new tests * Implement stateful hex-codec IncrementalDecoder * Add helpers for getstate() and setstate() to bijectively convert between arbitrary-length byte strings and integers * Implement stateful base64-codec IncrementalEncoder; use it for the StreamWriter * base64-codec IncrementalDecoder * quopri-codec IncrementalEncoder, StreamWriter, IncrementalDecoder * uu-codec IncrementalEncoder, StreamWriter, IncrementalDecoder * Document that bytes-to-bytes StreamReader is not supported * Document stateful raw-/unicode-escape decoding not supported * Warn that stateful UTF-7 encoding may not be optimal, and that stateful UTF-7 decoding may buffer unlimited input This patch is actually generated from a series of patches folded together. If anyone is interested, I could try pushing the original series to a Bitbucket repository or something. ---------- Added file: http://bugs.python.org/file37846/inc-codecs.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 06:00:02 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 25 Jan 2015 05:00:02 +0000 Subject: [issue21279] str.translate documentation incomplete In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za> Message-ID: <1422162002.1.0.512133569611.issue21279@psf.upfronthosting.co.za> Martin Panter added the comment: I?m happy with the new wording in v5. Maybe the docstring in the C module could be reflowed though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 06:14:13 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 25 Jan 2015 05:14:13 +0000 Subject: [issue13881] Stream encoder for zlib_codec doesn't use the incremental encoder In-Reply-To: <1327606849.1.0.885842099772.issue13881@psf.upfronthosting.co.za> Message-ID: <1422162853.43.0.377711088825.issue13881@psf.upfronthosting.co.za> Martin Panter added the comment: Here is patch v4. The stream writer is now automatically generated by default by the CodecInfo constructor if no custom stream writer parameter is supplied. The base64 and quopri codecs are adjusted to also use this default stream writer to help with Issue 20132. ---------- Added file: http://bugs.python.org/file37847/zlib-bz2-writer.v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 06:35:26 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 25 Jan 2015 05:35:26 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <1420230232.09.0.10127303351.issue23152@psf.upfronthosting.co.za> Message-ID: <1422164126.01.0.560946006039.issue23152@psf.upfronthosting.co.za> Steve Dower added the comment: Huh, okay, looks like the patch still isn't sufficient (I forgot to put -uall when testing it...) - there are calls in fileio.c that need changing too. I'll try and do a thorough sweep of calls to fstat and post another patch in the next day or so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 07:05:07 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 25 Jan 2015 06:05:07 +0000 Subject: [issue23119] Remove unicode specialization from set objects In-Reply-To: <1419677411.19.0.303130627071.issue23119@psf.upfronthosting.co.za> Message-ID: <1422165907.19.0.992855675527.issue23119@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks Mark. I appreciate the effort looking at use cases. I'm reopening this one because I have an alternative patch that simplifies the code but keeps the unicode specialization. It replaces the lookkey indirection with a fast and predictable inline test for PyUnicode_CheckExact. The timings show no measureable difference, but the code is simpler and the setobject size is reduced by one pointer. This simplify future maintenance and development as well as making the code more pleasant. ---------- resolution: rejected -> stage: -> patch review status: closed -> open Added file: http://bugs.python.org/file37848/inline_unicode_specialization.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 08:08:43 2015 From: report at bugs.python.org (Demian Brecht) Date: Sun, 25 Jan 2015 07:08:43 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1422169723.08.0.671936237472.issue3566@psf.upfronthosting.co.za> Demian Brecht added the comment: Thanks for the patch Martin (as well as catching a couple issues that I'd run into recently as well). I've left a couple comments up on Rietveld. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 08:26:11 2015 From: report at bugs.python.org (Ent) Date: Sun, 25 Jan 2015 07:26:11 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1422170771.56.0.217124619688.issue23255@psf.upfronthosting.co.za> Ent added the comment: Based on the comments of many good netizens, I have further updated the patch. ---------- Added file: http://bugs.python.org/file37849/jan25.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 08:55:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 Jan 2015 07:55:25 +0000 Subject: [issue23119] Remove unicode specialization from set objects In-Reply-To: <1419677411.19.0.303130627071.issue23119@psf.upfronthosting.co.za> Message-ID: <1422172525.04.0.31429720054.issue23119@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: May be add the unicode specialization right in PyObject_RichCompareBool? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 11:13:01 2015 From: report at bugs.python.org (Georg Brandl) Date: Sun, 25 Jan 2015 10:13:01 +0000 Subject: [issue23312] google thinks the docs are mobile unfriendly In-Reply-To: <1422121325.13.0.140473067698.issue23312@psf.upfronthosting.co.za> Message-ID: <1422180781.49.0.47028834143.issue23312@psf.upfronthosting.co.za> Georg Brandl added the comment: There is already an enhanced theme: https://github.com/ionelmc/sphinx-py3doc-enhanced-theme I will have a look at it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 11:52:47 2015 From: report at bugs.python.org (Akira Li) Date: Sun, 25 Jan 2015 10:52:47 +0000 Subject: [issue23251] mention in time.sleep() docs that it does not block other Python threads In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za> Message-ID: <1422183167.91.0.87198789357.issue23251@psf.upfronthosting.co.za> Akira Li added the comment: I've removed mentioning of GIL and uploaded a new patch. ---------- Added file: http://bugs.python.org/file37850/docs-time.sleep-other-threads-are-not-blocked-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 11:59:27 2015 From: report at bugs.python.org (Mark Summerfield) Date: Sun, 25 Jan 2015 10:59:27 +0000 Subject: [issue23292] Enum doc suggestion In-Reply-To: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za> Message-ID: <1422183567.49.0.226354366351.issue23292@psf.upfronthosting.co.za> Mark Summerfield added the comment: Since this is a bit controversial, I've tried marking it as 'rejected' with this comment. I've also added a very brief explanation and link back to here on my web site: http://www.qtrac.eu/pyenum.html ---------- resolution: -> rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 11:59:42 2015 From: report at bugs.python.org (Mark Summerfield) Date: Sun, 25 Jan 2015 10:59:42 +0000 Subject: [issue23292] Enum doc suggestion In-Reply-To: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za> Message-ID: <1422183582.19.0.556846659713.issue23292@psf.upfronthosting.co.za> Changes by Mark Summerfield : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 12:02:16 2015 From: report at bugs.python.org (Akira Li) Date: Sun, 25 Jan 2015 11:02:16 +0000 Subject: [issue23315] tempfile.mkdtemp fails with non-ascii paths on Python 2 Message-ID: <1422183736.06.0.60780511869.issue23315@psf.upfronthosting.co.za> New submission from Akira Li: Python 2.7.9 (default, Jan 25 2015, 13:41:30) [GCC 4.9.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os, sys, tempfile >>> d = u'\u20ac'.encode(sys.getfilesystemencoding()) # non-ascii >>> if not os.path.isdir(d): os.makedirs(d) ... >>> os.environ['TEMP'] = d >>> tempfile.mkdtemp(prefix=u'') Traceback (most recent call last): File "", line 1, in File ".../python2.7/tempfile.py", line 331, in mkdtemp file = _os.path.join(dir, prefix + name + suffix) File ".../python2.7/posixpath.py", line 80, in join path += '/' + b UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 13: ordinal not in range(128) Related: https://bugs.python.org/issue1681974 ---------- components: Unicode messages: 234662 nosy: akira, ezio.melotti, haypo priority: normal severity: normal status: open title: tempfile.mkdtemp fails with non-ascii paths on Python 2 type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 12:16:00 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 25 Jan 2015 11:16:00 +0000 Subject: [issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used In-Reply-To: <1359599707.26.0.771342463799.issue17088@psf.upfronthosting.co.za> Message-ID: <1422184560.79.0.504663367196.issue17088@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 12:57:46 2015 From: report at bugs.python.org (Neil Girdhar) Date: Sun, 25 Jan 2015 11:57:46 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422187065.99.0.690388584515.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Dict displays work. ---------- Added file: http://bugs.python.org/file37851/starunpack15.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 13:05:10 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 25 Jan 2015 12:05:10 +0000 Subject: [issue23315] tempfile.mkdtemp fails with non-ascii paths on Python 2 In-Reply-To: <1422183736.06.0.60780511869.issue23315@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Why do you use an unicode prefix? Does it work with a bytes prefix? You should use Python 3 if you want the best Unicode support. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 13:32:07 2015 From: report at bugs.python.org (Maries Ionel Cristian) Date: Sun, 25 Jan 2015 12:32:07 +0000 Subject: [issue23312] google thinks the docs are mobile unfriendly In-Reply-To: <1422121325.13.0.140473067698.issue23312@psf.upfronthosting.co.za> Message-ID: <1422189127.47.0.204145594579.issue23312@psf.upfronthosting.co.za> Maries Ionel Cristian added the comment: You can see that theme in action at http://python-aspectlib.readthedocs.org/en/latest/ ---------- nosy: +ionel.mc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 14:10:17 2015 From: report at bugs.python.org (Georg Brandl) Date: Sun, 25 Jan 2015 13:10:17 +0000 Subject: [issue23312] google thinks the docs are mobile unfriendly In-Reply-To: <1422121325.13.0.140473067698.issue23312@psf.upfronthosting.co.za> Message-ID: <1422191417.8.0.694604018345.issue23312@psf.upfronthosting.co.za> Georg Brandl added the comment: Are you ok with us copying parts of the enhancements? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 14:17:44 2015 From: report at bugs.python.org (Maries Ionel Cristian) Date: Sun, 25 Jan 2015 13:17:44 +0000 Subject: [issue23312] google thinks the docs are mobile unfriendly In-Reply-To: <1422121325.13.0.140473067698.issue23312@psf.upfronthosting.co.za> Message-ID: <1422191864.62.0.428871068181.issue23312@psf.upfronthosting.co.za> Maries Ionel Cristian added the comment: Sure, take anything you want. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 14:52:49 2015 From: report at bugs.python.org (Neil Girdhar) Date: Sun, 25 Jan 2015 13:52:49 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422193969.13.0.869107605212.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Dict comprehensions work. ---------- Added file: http://bugs.python.org/file37852/starunpack16.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 14:58:05 2015 From: report at bugs.python.org (Chris Angelico) Date: Sun, 25 Jan 2015 13:58:05 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422194285.76.0.758145725174.issue2292@psf.upfronthosting.co.za> Changes by Chris Angelico : ---------- nosy: -Rosuav _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 15:26:13 2015 From: report at bugs.python.org (Neil Girdhar) Date: Sun, 25 Jan 2015 14:26:13 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422195973.47.0.741301477172.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: All tests pass, polishing. Joshua, I'm still not sure how to do show the right error for the function call with duplicate arguments? ---------- Added file: http://bugs.python.org/file37853/starunpack17.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 16:35:03 2015 From: report at bugs.python.org (Neil Girdhar) Date: Sun, 25 Jan 2015 15:35:03 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422200103.59.0.647364081712.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Fixed all tests except test_parser. New node numbers are not reflected here for some reason. ---------- Added file: http://bugs.python.org/file37854/starunpack18.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 16:43:00 2015 From: report at bugs.python.org (Ethan Furman) Date: Sun, 25 Jan 2015 15:43:00 +0000 Subject: [issue23292] Enum doc suggestion In-Reply-To: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za> Message-ID: <1422200580.36.0.593780380671.issue23292@psf.upfronthosting.co.za> Ethan Furman added the comment: Amusingly enough, I posted a question/answer to StackOverflow (http://stackoverflow.com/q/28130683/208880) and so far the only other respondent posted an answer with similar functionality to my own, and also recommended that such a method be added to the base Enum class. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 16:46:56 2015 From: report at bugs.python.org (Joshua Landau) Date: Sun, 25 Jan 2015 15:46:56 +0000 Subject: [issue23316] Incorrect evaluation order of function arguments with *args Message-ID: <1422200816.31.0.910655700205.issue23316@psf.upfronthosting.co.za> New submission from Joshua Landau: It is claimed that all expressions are evaluated left-to-right, including in functions?. However, f(*a(), b=b()) will evaluate b() before a(). ? https://docs.python.org/3/reference/expressions.html#evaluation-order ---------- components: Interpreter Core messages: 234672 nosy: Joshua.Landau priority: normal severity: normal status: open title: Incorrect evaluation order of function arguments with *args type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 17:28:49 2015 From: report at bugs.python.org (SilentGhost) Date: Sun, 25 Jan 2015 16:28:49 +0000 Subject: [issue23316] Incorrect evaluation order of function arguments with *args In-Reply-To: <1422200816.31.0.910655700205.issue23316@psf.upfronthosting.co.za> Message-ID: <1422203329.31.0.400572466973.issue23316@psf.upfronthosting.co.za> SilentGhost added the comment: It seems, if I read https://docs.python.org/3/reference/expressions.html#calls correctly that the evaluation order of the function arguments is not defined in general, as it depends on your use of keyword argument and exact function signature. Naturally, f(a(), b()) would be evaluated in the order you're expecting. ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 17:39:34 2015 From: report at bugs.python.org (John Posner) Date: Sun, 25 Jan 2015 16:39:34 +0000 Subject: [issue21279] str.translate documentation incomplete In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za> Message-ID: <1422203974.52.0.482881229839.issue21279@psf.upfronthosting.co.za> John Posner added the comment: Per Martin's suggestion, deltas from issue21279.v5.patch: * no change to patch for doc/library/stdtypes.rst * doc string reflowed in patch for objects/unicodeobject.c ---------- Added file: http://bugs.python.org/file37855/issue21279.v6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 17:47:43 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 25 Jan 2015 16:47:43 +0000 Subject: [issue23316] Incorrect evaluation order of function arguments with *args In-Reply-To: <1422200816.31.0.910655700205.issue23316@psf.upfronthosting.co.za> Message-ID: <1422204463.68.0.237428733628.issue23316@psf.upfronthosting.co.za> R. David Murray added the comment: The resolution of issue 16967 argues that this should probably be considered a bug. It certainly goes against normal Python expectations. I think it should also be considered to be of low priority, though. ---------- nosy: +r.david.murray priority: normal -> low stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 18:16:03 2015 From: report at bugs.python.org (Justin Eldridge) Date: Sun, 25 Jan 2015 17:16:03 +0000 Subject: [issue23317] Incorrect description of descriptor invocation in Python Language Reference Message-ID: <1422206163.24.0.274216799196.issue23317@psf.upfronthosting.co.za> New submission from Justin Eldridge: The section titled "Invoking Descriptors" in the Python Language Reference [1] says: Class Binding If binding to a new-style class, A.x is transformed into the call: A.__dict__['x'].__get__(None, A). This suggests that __get__ is looked up on the instance of x, when I believe that it is actually looked up on the type. That is, it's my understanding that A.x invokes: type(A.__dict__['x']).__get__(A.__dict__['x'], None, Foo)) Here's some Python 3.4 code demonstrating this: class A: pass class Descriptor: def __get__(self, obj, cls): print("Getting!") A.x = Descriptor() def replacement_get(obj, cls): print("This is a replacement.") A.__dict__['x'].__get__ = replacement_get Now, writing: >>> A.x Getting! >>> A.__dict__['x'].__get__(None, A) This is a replacement! >>> type(A.__dict__['x']).__get__(A.__dict__['x'], None, A) Getting! The documentation makes a similar statement about instance binding that also appears to be incorrect. This is the case in all versions of the document I could find. What I believe to be the actual behavior is implied by a later section in the same document, which states that the implicit invocation of special methods is only guaranteed to work correctly if the special method is defined on the type, not the instance. This suggests that the statements in "Invoking Descriptors" aren't quite correct, and while the true behavior is a little more verbose, I think it would be worthwhile to update the documentation so as to avoid confusion. [1]: https://docs.python.org/2/reference/datamodel.html#invoking-descriptors ---------- assignee: docs at python components: Documentation messages: 234676 nosy: Justin.Eldridge, docs at python priority: normal severity: normal status: open title: Incorrect description of descriptor invocation in Python Language Reference type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 18:22:01 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 25 Jan 2015 17:22:01 +0000 Subject: [issue20188] ALPN support for TLS In-Reply-To: <1389153179.88.0.510995543218.issue20188@psf.upfronthosting.co.za> Message-ID: <1422206521.9.0.9570852217.issue20188@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 18:31:37 2015 From: report at bugs.python.org (Dave Notman) Date: Sun, 25 Jan 2015 17:31:37 +0000 Subject: [issue23318] (compiled RegEx).split gives unexpected results if () in pattern Message-ID: <1422207097.55.0.514125060003.issue23318@psf.upfronthosting.co.za> New submission from Dave Notman: # Python 3.3.1 (default, Sep 25 2013, 19:30:50) # Linux 3.8.0-35-generic #50-Ubuntu SMP Tue Dec 3 01:25:33 UTC 2013 i686 i686 i686 GNU/Linux import re splitter = re.compile( r'(\s*[+/&;,]\s*)|(\s+and\s+)' ) ll = splitter.split( 'Dave & Sam, Jane and Zoe' ) print(repr(ll)) print( 'Try again with revised RegEx' ) splitter = re.compile( r'(?:(?:\s*[+/&;,]\s*)|(?:\s+and\s+))' ) ll = splitter.split( 'Dave & Sam, Jane and Zoe' ) print(repr(ll)) Results: ['Dave', ' & ', None, 'Sam', ', ', None, 'Jane', None, ' and ', 'Zoe'] Try again with revised RegEx ['Dave', 'Sam', 'Jane', 'Zoe'] ---------- components: Regular Expressions messages: 234677 nosy: dnotmanj, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: (compiled RegEx).split gives unexpected results if () in pattern type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 19:10:22 2015 From: report at bugs.python.org (SilentGhost) Date: Sun, 25 Jan 2015 18:10:22 +0000 Subject: [issue23318] (compiled RegEx).split gives unexpected results if () in pattern In-Reply-To: <1422207097.55.0.514125060003.issue23318@psf.upfronthosting.co.za> Message-ID: <1422209422.52.0.448572609575.issue23318@psf.upfronthosting.co.za> SilentGhost added the comment: Looks like it works exactly as the docs[1] describe: >>> re.split(r'\s*[+/&;,]\s*|\s+and\s+', string) ['Dave', 'Sam', 'Jane', 'Zoe'] You're using capturing groups (parentheses) in your original regex which returns separators as part of a match. [1] https://docs.python.org/3/library/re.html#re.split ---------- nosy: +SilentGhost resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 19:33:17 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 25 Jan 2015 18:33:17 +0000 Subject: [issue23282] Slightly faster set lookup In-Reply-To: <1421750356.2.0.166287277194.issue23282@psf.upfronthosting.co.za> Message-ID: <1422210797.33.0.664536418009.issue23282@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I had intentionally moved the entry->key == key test to be after the hash test. Unlike dicts where exact key matches are norm, sets are used for deduping (cased where keys are equal but not dups). By moving the test inside the entry->key == hash test, we reduce the number of comparisons per loop for collisions and increase the predictability of the entry->key == key branch (once the hash matches, the chance of an equality match is very high. The one part I'm looking at changing is moving the dummy test after the identity key test. However, the dummy test inside the hash test is perfectly predictable (it basicly never matches) and may be cost free. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 19:38:19 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 25 Jan 2015 18:38:19 +0000 Subject: [issue23290] Faster set copying In-Reply-To: <1421848208.43.0.905402107396.issue23290@psf.upfronthosting.co.za> Message-ID: <1422211099.85.0.565443014688.issue23290@psf.upfronthosting.co.za> Raymond Hettinger added the comment: For the time being (while I working on other parts of sets), I'm holding-off an anything that adds more lookkey variants. When the neatening-up and tweaking of search routines comes to a close, I'll revisit this one because it looks like there is a some low hanging fruit here. ---------- resolution: -> later _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 19:42:29 2015 From: report at bugs.python.org (Joshua Landau) Date: Sun, 25 Jan 2015 18:42:29 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422211349.48.0.278617687641.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: Amazing, thanks. I also just uncovered http://bugs.python.org/issue23316; we'll need to support a patch for that. In fact, bad evaluation order is why I haven't yet gotten down my unification strategy. I wouldn't worry about extra opcodes when using *args or **kwargs, though; what matters is mostly avoiding extra copies. I guess a few `timeit`s will show whether I'm right or totally off-base. Most of what's needed for the error stuff is already implemented; one just needs to set the top bit flag (currently just 1<<8) to "1 + arg_count_on_stack()", which is a trivial change. I'll push a patch for that after I'm done fiddling with the unification idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 19:53:37 2015 From: report at bugs.python.org (Matthieu Gautier) Date: Sun, 25 Jan 2015 18:53:37 +0000 Subject: =?utf-8?q?=5Bissue23319=5D_Missing_SWAP=5FINT=C2=A0in_I=5Fset=5Fsw?= Message-ID: <1422212017.26.0.671058309435.issue23319@psf.upfronthosting.co.za> New submission from Matthieu Gautier: I_set_sw function is missing a SWAP_INT. This leads to wrong set of bitfield value. Here is a script to reproduce: ---------- from ctypes import * class HEADER(BigEndianStructure): _fields_ = ( ('pad', c_uint32, 16), ('v1', c_uint32, 4), ('v2', c_uint32, 12) ) b = bytearray(4) header = HEADER.from_buffer(b) header.type = 1 assert b == b'\x00\x00\x10\x00' header.mode = 0x234 assert b == b'\x00\x00\x12\x34' ---------- ---------- components: ctypes files: ctypes_swap_uint.patch keywords: patch messages: 234682 nosy: mgautierfr priority: normal severity: normal status: open title: Missing SWAP_INT?in I_set_sw type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file37856/ctypes_swap_uint.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 20:54:08 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 25 Jan 2015 19:54:08 +0000 Subject: [issue21279] str.translate documentation incomplete In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za> Message-ID: <1422215648.77.0.557238983677.issue21279@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 20:55:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 Jan 2015 19:55:50 +0000 Subject: [issue23282] Slightly faster set lookup In-Reply-To: <1421750356.2.0.166287277194.issue23282@psf.upfronthosting.co.za> Message-ID: <1422215750.5.0.784205166946.issue23282@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What about just removing the dummy test inside the hash test? The benefit is smaller but statistically sygnificant and always positive. $ ./python -m timeit -s "a = list(range(10**6)); s1 = set(a); s2 = set(a)" -- "s1 <= s2" Unpatched: 10 loops, best of 3: 39.3 msec per loop Patched: 10 loops, best of 3: 38.7 msec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 21:28:10 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 25 Jan 2015 20:28:10 +0000 Subject: [issue23317] Incorrect description of descriptor invocation in Python Language Reference In-Reply-To: <1422206163.24.0.274216799196.issue23317@psf.upfronthosting.co.za> Message-ID: <1422217690.54.0.82660210641.issue23317@psf.upfronthosting.co.za> R. David Murray added the comment: I believe that you are correct: special methods are looked up on the type, and this is assumed implicitly in the Class Binding description. (This was not 100% true in python2, but it is in current python3.) But the Class Binding description is correct, since if the __get__ method is *not* defined on the type (of the descriptor), the descriptor instance itself is returned (so explicitly calling type in the "equivalent expression" would be wrong). This is one of the most complex topics to describe in Python (I still don't have it solid in my head and I've been working with Python for years now). If we can come up with clearer wording that is good, but we've tried several times already to improve it :( I don't know what you are referring to for the 'instance binding' that makes the same 'mistake', but I suspect it is also covered by the "special methods are looked up on the type" rule. ---------- nosy: +r.david.murray versions: -Python 3.2, Python 3.3, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 21:31:31 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 25 Jan 2015 20:31:31 +0000 Subject: [issue23269] Tighten-up search loops in sets In-Reply-To: <1421658942.27.0.429398283891.issue23269@psf.upfronthosting.co.za> Message-ID: <1422217891.56.0.664510306819.issue23269@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Reopening this with a better patch that nicely tightens the inner-loop without an algorithmic change or any downside. Currently, the entry computation adds a constant (i+j), masks it (&mask) to wrap on overflow, scales it to a table index (<< 4), and then does the key lookup (one memory access). These steps are sequential (not parallizeable). The patch moves the wrap-on-overflow decision out of the inner loop (adding a single, fast, predictable branch (i + LINEAR_PROBES > mask). The inner-loop then simplifies to an add, fetch, and test (no masking and shifting). The generated code on Clang is very tight: LBB29_26: cmpq $0, (%rsi) # entry->key == NULL je LBB29_30 incq %rdx # j++ addq $16, %rsi # entry++ (done in parallel with the incq) cmpq $9, %rdx # j <= LINEAR_PROBES jbe LBB29_26 On gcc-4.9, the loop is unrolled and we get even better code: leaq (%rbx,%rsi), %rdx # entry = table[i] cmpq $0, (%rdx) # entry.key == NULL je L223 leaq 16(%rbx,%rsi), %rdx # entry = table[i+1]; cmpq $0, (%rdx) # entry.key == NULL je L223 leaq 32(%rbx,%rsi), %rdx cmpq $0, (%rdx) je L223 ---------- resolution: rejected -> status: closed -> open Added file: http://bugs.python.org/file37857/tight2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 21:49:57 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 25 Jan 2015 20:49:57 +0000 Subject: [issue23251] mention in time.sleep() docs that it does not block other Python threads In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za> Message-ID: <20150125204944.84277.39555@psf.io> Roundup Robot added the comment: New changeset 55ad65c4f9e2 by R David Murray in branch '3.4': #23251: Note that time.sleep affects the calling thread only. https://hg.python.org/cpython/rev/55ad65c4f9e2 New changeset 5e01c68cabbf by R David Murray in branch '2.7': #23251: note that time.sleep affects the current thread only. https://hg.python.org/cpython/rev/5e01c68cabbf New changeset 5db28a3199b2 by R David Murray in branch '2.7': #23251: Reflow paragraph. https://hg.python.org/cpython/rev/5db28a3199b2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 21:49:58 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 25 Jan 2015 20:49:58 +0000 Subject: [issue23215] MemoryError with custom error handlers and multibyte codecs In-Reply-To: <1420860783.67.0.50434618074.issue23215@psf.upfronthosting.co.za> Message-ID: <20150125204944.84277.80863@psf.io> Roundup Robot added the comment: New changeset 3a9b1e5fe179 by R David Murray in branch '3.4': #23215: reflow paragraph. https://hg.python.org/cpython/rev/3a9b1e5fe179 New changeset 52a06812d5da by R David Murray in branch 'default': Merge: #23215: note that time.sleep affects the current thread only. https://hg.python.org/cpython/rev/52a06812d5da ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 21:51:27 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 25 Jan 2015 20:51:27 +0000 Subject: [issue23251] mention in time.sleep() docs that it does not block other Python threads In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za> Message-ID: <1422219087.72.0.711004992335.issue23251@psf.upfronthosting.co.za> R. David Murray added the comment: Oops, typoed the issue number. New changeset 3a9b1e5fe179 by R David Murray in branch '3.4': #23215: reflow paragraph. https://hg.python.org/cpython/rev/3a9b1e5fe179 New changeset 52a06812d5da by R David Murray in branch 'default': Merge: #23215: note that time.sleep affects the current thread only. https://hg.python.org/cpython/rev/52a06812d5da ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 21:51:59 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 25 Jan 2015 20:51:59 +0000 Subject: [issue23215] MemoryError with custom error handlers and multibyte codecs In-Reply-To: <1420860783.67.0.50434618074.issue23215@psf.upfronthosting.co.za> Message-ID: <1422219119.11.0.474385726073.issue23215@psf.upfronthosting.co.za> R. David Murray added the comment: Oops, typoed the issue number. That should have been 23251. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 21:52:51 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 25 Jan 2015 20:52:51 +0000 Subject: [issue23251] mention in time.sleep() docs that it does not block other Python threads In-Reply-To: <1421427666.28.0.597926970646.issue23251@psf.upfronthosting.co.za> Message-ID: <1422219171.0.0.396869033874.issue23251@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Akira, but I did not use your patch, since it still had the paragraph reflow in it. ---------- resolution: -> fixed stage: commit review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 21:57:47 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 25 Jan 2015 20:57:47 +0000 Subject: [issue22286] Allow backslashreplace error handler to be used on input In-Reply-To: <1409136620.65.0.397738586583.issue22286@psf.upfronthosting.co.za> Message-ID: <20150125205744.75796.35468@psf.io> Roundup Robot added the comment: New changeset dd8a03e98158 by Serhiy Storchaka in branch 'default': Issue #22286: The "backslashreplace" error handlers now works with https://hg.python.org/cpython/rev/dd8a03e98158 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 22:06:33 2015 From: report at bugs.python.org (Akira Li) Date: Sun, 25 Jan 2015 21:06:33 +0000 Subject: [issue23320] devguide should mention rules about "paragraph reflow" in the documentation Message-ID: <1422219993.92.0.674256323538.issue23320@psf.upfronthosting.co.za> New submission from Akira Li: It is suggested in https://bugs.python.org/issue23251 that only a core Python developer may reflow paragraphs while submitting patches for the Python documentation. It should be codified in devguide: I haven't found the word *reflow* in it. ---------- components: Devguide messages: 234692 nosy: akira, ezio.melotti priority: normal severity: normal status: open title: devguide should mention rules about "paragraph reflow" in the documentation type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 22:11:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 Jan 2015 21:11:21 +0000 Subject: [issue23269] Tighten-up search loops in sets In-Reply-To: <1421658942.27.0.429398283891.issue23269@psf.upfronthosting.co.za> Message-ID: <1422220280.99.0.639667869874.issue23269@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What timing results? There is large chance that first tested entry is empty. May be worth to move this test outside of the loop as in the set_lookup function. "i &= mask;" may be moved to the start of the loop. ---------- Added file: http://bugs.python.org/file37858/tight2a.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 22:24:53 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 25 Jan 2015 21:24:53 +0000 Subject: [issue22286] Allow backslashreplace error handler to be used on input In-Reply-To: <1409136620.65.0.397738586583.issue22286@psf.upfronthosting.co.za> Message-ID: <1422221093.01.0.942062810546.issue22286@psf.upfronthosting.co.za> R. David Murray added the comment: Looks like the buildbots aren't happy with this change. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 22:30:32 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 25 Jan 2015 21:30:32 +0000 Subject: [issue23320] devguide should mention rules about "paragraph reflow" in the documentation In-Reply-To: <1422219993.92.0.674256323538.issue23320@psf.upfronthosting.co.za> Message-ID: <1422221432.88.0.658407844341.issue23320@psf.upfronthosting.co.za> R. David Murray added the comment: That wording is a bit strong :). On that issue I requested a patch without the reflow, because I prefer that. Personally, I think it is in fact worth noting in the devguide that it is better for doc patches to not reflow paragraphs so that it is easier to see just the changed text in the patch file and in the 'hg diff' output. However, since reitveld can handle reflowed paragraphs, other developers my not agree with me on this. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 22:48:38 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 25 Jan 2015 21:48:38 +0000 Subject: [issue23320] devguide should mention rules about "paragraph reflow" in the documentation In-Reply-To: <1422219993.92.0.674256323538.issue23320@psf.upfronthosting.co.za> Message-ID: <1422222518.15.0.171482269321.issue23320@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 23:15:47 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 25 Jan 2015 22:15:47 +0000 Subject: [issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__ In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za> Message-ID: <1422224147.16.0.359155365727.issue4395@psf.upfronthosting.co.za> Martin Panter added the comment: Adding a new patch that just fixes the typo error in the first patch ---------- Added file: http://bugs.python.org/file37859/default-ne-reflected-priority.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 23:20:36 2015 From: report at bugs.python.org (Neil Girdhar) Date: Sun, 25 Jan 2015 22:20:36 +0000 Subject: [issue23316] Incorrect evaluation order of function arguments with *args In-Reply-To: <1422200816.31.0.910655700205.issue23316@psf.upfronthosting.co.za> Message-ID: <1422224436.78.0.642507960776.issue23316@psf.upfronthosting.co.za> Neil Girdhar added the comment: I assume this is the problem: >>> dis.dis('f(*a(), b=b())') 1 0 LOAD_NAME 0 (f) 3 LOAD_NAME 1 (a) 6 CALL_FUNCTION 0 (0 positional, 0 keyword pair) 9 LOAD_CONST 0 ('b') 12 LOAD_NAME 2 (b) 15 CALL_FUNCTION 0 (0 positional, 0 keyword pair) 18 CALL_FUNCTION_VAR 256 (0 positional, 1 keyword pair) 21 RETURN_VALUE ? looks fine. >>> dis.dis('f(b=b(), *a())') 1 0 LOAD_NAME 0 (f) 3 LOAD_NAME 1 (a) 6 CALL_FUNCTION 0 (0 positional, 0 keyword pair) 9 LOAD_CONST 0 ('b') 12 LOAD_NAME 2 (b) 15 CALL_FUNCTION 0 (0 positional, 0 keyword pair) 18 CALL_FUNCTION_VAR 256 (0 positional, 1 keyword pair) 21 RETURN_VALUE Joshua, we could make function calls take: x lists y dictionaries one optional list z dictionaries but we as well do all the merging in advance: one optional list one optional dictionary one optional list one optional dictionary which is representable in three bits, but four is easier to decode I think. ---------- nosy: +neil.g _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 23:28:14 2015 From: report at bugs.python.org (Neil Girdhar) Date: Sun, 25 Jan 2015 22:28:14 +0000 Subject: [issue23316] Incorrect evaluation order of function arguments with *args In-Reply-To: <1422200816.31.0.910655700205.issue23316@psf.upfronthosting.co.za> Message-ID: <1422224894.39.0.342411353088.issue23316@psf.upfronthosting.co.za> Neil Girdhar added the comment: actually, we accept alternation, so maybe a bit to say whether we start with a list or a dict followed by a length of the alternating sequence? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 23:29:30 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 25 Jan 2015 22:29:30 +0000 Subject: [issue23284] curses, readline, tinfo, and also --prefix, dbm, CPPFLAGS In-Reply-To: <1421794283.67.0.365311015753.issue23284@psf.upfronthosting.co.za> Message-ID: <1422224970.07.0.635617516377.issue23284@psf.upfronthosting.co.za> R. David Murray added the comment: At a quick glance this does not seem like a reasonable patch...introducing copies of two stdlib modules is basically a non-starter. Nor do I understand from the description what the problem is that it is trying to solve. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 23:31:40 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 25 Jan 2015 22:31:40 +0000 Subject: [issue21408] delegation of `!=` to the right-hand side argument is not always done In-Reply-To: <1398954687.6.0.574462939929.issue21408@psf.upfronthosting.co.za> Message-ID: <1422225100.38.0.105972903961.issue21408@psf.upfronthosting.co.za> Martin Panter added the comment: I looked over your __ne__ removals from the library, and they all seem sensible to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 23:35:53 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 25 Jan 2015 22:35:53 +0000 Subject: [issue1745722] please add wsgi to SimpleXMLRPCServer Message-ID: <1422225353.19.0.939928016246.issue1745722@psf.upfronthosting.co.za> Berker Peksag added the comment: I've updated the patch for 3.5. I also have cleaned-up the documentation to avoid duplicate content. ---------- components: +Library (Lib) -XML nosy: +berker.peksag versions: +Python 3.5 -Python 3.4 Added file: http://bugs.python.org/file37860/issue1745722.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 23:38:47 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 25 Jan 2015 22:38:47 +0000 Subject: [issue23316] Incorrect evaluation order of function arguments with *args In-Reply-To: <1422200816.31.0.910655700205.issue23316@psf.upfronthosting.co.za> Message-ID: <1422225527.3.0.605138795072.issue23316@psf.upfronthosting.co.za> R. David Murray added the comment: Neil: I presume you are speaking of your in-progress PEP patch, and not the current python code? If so, please keep the discussion of handling this in the context of the PEP to the PEP issue. This issue should be for resolving the bug in the current code (if we choose to do so...if the PEP gets accepted for 3.5 this issue may become irrelevant, as I'm not sure we'd want to fix it in 3.4 for backward compatibility reasons). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 25 23:50:56 2015 From: report at bugs.python.org (Neil Girdhar) Date: Sun, 25 Jan 2015 22:50:56 +0000 Subject: [issue23316] Incorrect evaluation order of function arguments with *args In-Reply-To: <1422200816.31.0.910655700205.issue23316@psf.upfronthosting.co.za> Message-ID: <1422226256.63.0.621520008304.issue23316@psf.upfronthosting.co.za> Neil Girdhar added the comment: Yes, sorry David. I got linked here from the other issue. In any case, in the current code, the longest alternating sequence possible is 4. So one way to solve this is to change the CALL_FUNCTION parameters to be lists and dicts only and then process the final merging in CALL_FUNCTION. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 00:02:42 2015 From: report at bugs.python.org (Neil Girdhar) Date: Sun, 25 Jan 2015 23:02:42 +0000 Subject: [issue23316] Incorrect evaluation order of function arguments with *args In-Reply-To: <1422200816.31.0.910655700205.issue23316@psf.upfronthosting.co.za> Message-ID: <1422226962.91.0.985077134314.issue23316@psf.upfronthosting.co.za> Neil Girdhar added the comment: another option is to add a LIST_EXTEND(stack_difference) opcode that would allow us to take the late iterable and extend a list at some arbitrary stack position. I had to add something like that for dicts for the other issue, so it would follow that pattern. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 00:16:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 Jan 2015 23:16:13 +0000 Subject: [issue23321] Crash in str.decode() with special error handler Message-ID: <1422227773.79.0.793422498408.issue23321@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Debugging build crashes in some circumstances in str.decode() with error handler which produces replacement string with length larger than malformed data. For example the backslashreplace error handler produces 4-character string for every illegal byte. All other standard error handlers produce no longer than 1 character for every illegal unit. Here is a patch which fixes this issue. I'll commit it without review because buildbots are broken without it. This issue is open for reference and post-commit review. ---------- assignee: serhiy.storchaka components: Interpreter Core files: unicode_decode_call_errorhandler_writer.patch keywords: patch messages: 234705 nosy: haypo, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Crash in str.decode() with special error handler type: crash versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37861/unicode_decode_call_errorhandler_writer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 00:18:27 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 25 Jan 2015 23:18:27 +0000 Subject: [issue22286] Allow backslashreplace error handler to be used on input In-Reply-To: <1409136620.65.0.397738586583.issue22286@psf.upfronthosting.co.za> Message-ID: <1422227907.87.0.604296360495.issue22286@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 00:27:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 Jan 2015 23:27:12 +0000 Subject: [issue22286] Allow backslashreplace error handler to be used on input In-Reply-To: <1409136620.65.0.397738586583.issue22286@psf.upfronthosting.co.za> Message-ID: <1422228432.46.0.25424846873.issue22286@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, I see. The patch exposed existing bug in decoding error handing. See issue23321 for this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 00:27:45 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 25 Jan 2015 23:27:45 +0000 Subject: [issue23321] Crash in str.decode() with special error handler In-Reply-To: <1422227773.79.0.793422498408.issue23321@psf.upfronthosting.co.za> Message-ID: <20150125232742.55106.65676@psf.io> Roundup Robot added the comment: New changeset 2de90090e486 by Serhiy Storchaka in branch '3.4': Issue #23321: Fixed a crash in str.decode() when error handler returned https://hg.python.org/cpython/rev/2de90090e486 New changeset 1cd68b3c46aa by Serhiy Storchaka in branch 'default': Issue #23321: Fixed a crash in str.decode() when error handler returned https://hg.python.org/cpython/rev/1cd68b3c46aa ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 00:49:19 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 25 Jan 2015 23:49:19 +0000 Subject: [issue23119] Remove unicode specialization from set objects In-Reply-To: <1419677411.19.0.303130627071.issue23119@psf.upfronthosting.co.za> Message-ID: <1422229759.47.0.70027587288.issue23119@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > May be add the unicode specialization right in PyObject_RichCompareBool? That's a possibility but it has much broader ramifications and might or might not be the right thing to do. I'll leave that for someone else to pursue and keep my sights on sets for while. (If you do modify PyObject_RichCompareBool, take a look moving the surrounding incref/decref pair as well). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 01:13:07 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 Jan 2015 00:13:07 +0000 Subject: [issue23119] Remove unicode specialization from set objects In-Reply-To: <1419677411.19.0.303130627071.issue23119@psf.upfronthosting.co.za> Message-ID: <20150126001257.75794.84387@psf.io> Roundup Robot added the comment: New changeset 20f54cdf351d by Raymond Hettinger in branch 'default': Issue #23119: Simplify setobject by inlining the special case for unicode equality testing. https://hg.python.org/cpython/rev/20f54cdf351d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 01:13:21 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 26 Jan 2015 00:13:21 +0000 Subject: [issue23119] Remove unicode specialization from set objects In-Reply-To: <1419677411.19.0.303130627071.issue23119@psf.upfronthosting.co.za> Message-ID: <1422231200.99.0.379988378708.issue23119@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 02:11:22 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 26 Jan 2015 01:11:22 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1422234682.16.0.197104843333.issue3566@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for the reviews. I agree about the new HTTPResponse flag being a bit awkward; the HTTPResponse class should probably raise the ConnectionClosed exception in all cases. I was wondering if the the HTTPConnection class should wrap this in a PersistentConnectionClosed exception or something if it wasn?t for the first connection, now I?m thinking that should be up to the higher level user, in case they are doing something like HTTP preconnection. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 02:28:24 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 26 Jan 2015 01:28:24 +0000 Subject: [issue11822] Improve disassembly to show embedded code objects In-Reply-To: <1302467152.39.0.854888976189.issue11822@psf.upfronthosting.co.za> Message-ID: <1422235704.02.0.943709156012.issue11822@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 02:36:06 2015 From: report at bugs.python.org (Neil Girdhar) Date: Mon, 26 Jan 2015 01:36:06 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422236166.54.0.111434433452.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Sounds good. I'll stop working until I see your patch. I tried to make it easy for you to implement your error idea wrt BUILD_MAP_UNPACK :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 04:18:47 2015 From: report at bugs.python.org (Robert Collins) Date: Mon, 26 Jan 2015 03:18:47 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1422242327.72.0.776642448174.issue17911@psf.upfronthosting.co.za> Robert Collins added the comment: Right, and a usable API. I believe that this will meet Guido's use case: tb = TracebackException(*sys.exc_info, lookup_lines=False) .... some time later .... if should_show_tb: lines = list(tb.format()) I'm not 100% sold on the public API being a generator, but rather than forcing it one way or the other, I'll let reviewers tell me what they think :) Performance wise, this is better, with the following times: format_stack -> 5.19ms new API to extract and not format -> 3.06ms new API to extract, not lookup lines and not format -> 2.32ms Formatting is then 2-3ms per 500 line traceback actually formatted, which seems terribly slow, but its still better than the 8+ms trunk takes (see my earlier tests). I'll look at tuning the time to render an actual trace later, since I don't like paying high costs in unittest ;) - but AIUI this should be enough to help asyncio as is. Updated test script I used to isolate times with timeit: import traceback def recurse(count, lookup_lines=True): if count> 0: return recurse(count - 1, lookup_lines=lookup_lines) if lookup_lines: return traceback.Stack.extract(traceback.walk_stack(None), lookup_lines=True) else: return traceback.Stack.extract(traceback.walk_stack(None), lookup_lines=False) def doit(): len(recurse(500)) def doit_lazy(): len(recurse(500, False)) ---------- Added file: http://bugs.python.org/file37862/issue17911-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 04:23:16 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 26 Jan 2015 03:23:16 +0000 Subject: [issue23269] Tighten-up search loops in sets In-Reply-To: <1421658942.27.0.429398283891.issue23269@psf.upfronthosting.co.za> Message-ID: <1422242596.81.0.245896021595.issue23269@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > May be worth to move this test outside of the loop as in the > set_lookup function. The loop used to be this way but testing showed no benefit, so a while back I recombined it back to a j=0 start point and the code looked much nicer. I don't really want to go back if I don't have to. There may or may not be a microscopic benefit to moving the leaq 9(%rcx), %rsi / cmpq %rsi, %rax / jae L237 sequence before the table[i+0]->key == NULL check. I don't still have access to VTune to verify that this highly predictable branch is essentially free. I do have a preference at this point for the simpler code -- that will make the future optimization work easier (perhaps inlining the lookkey code into set_insert_key, set_discard, and set_contains). Also, looking at the disassembly of your patch, there is an additional cost for setting up the table[i+1] entry that wasn't there before (two new extra instructions: leaq 1(%rcx), %rsi; salq $4, %rsi; occur before the normal lookup and test sequence: leaq 0(%rbp,%rsi), %rdx; cmpq $0, (%rdx); je L237) That said, if you think it is important to move the table[i+0] test outside the (i + LINEAR_PROBES <= mask) test, just say so and I'll apply your version of the patch instead of mine. Otherwise, I prefer the cleaner code (both C and generated assembly) of my patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 05:31:41 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 26 Jan 2015 04:31:41 +0000 Subject: [issue8796] Deprecate codecs.open() In-Reply-To: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za> Message-ID: <1422246701.35.0.842913073701.issue8796@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 05:35:11 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 Jan 2015 04:35:11 +0000 Subject: [issue19996] httplib infinite read on invalid header In-Reply-To: <1387194945.4.0.440069571587.issue19996@psf.upfronthosting.co.za> Message-ID: <20150126043448.55104.15713@psf.io> Roundup Robot added the comment: New changeset 25ecf3d0ea03 by Benjamin Peterson in branch '3.4': handle headers with no key (closes #19996) https://hg.python.org/cpython/rev/25ecf3d0ea03 New changeset 29923a9987be by Benjamin Peterson in branch 'default': merge 3.4 (#19996) https://hg.python.org/cpython/rev/29923a9987be New changeset 9a4882b12218 by Benjamin Peterson in branch '2.7': simply ignore headers with no name (#19996) https://hg.python.org/cpython/rev/9a4882b12218 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 07:30:29 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 26 Jan 2015 06:30:29 +0000 Subject: [issue23321] Crash in str.decode() with special error handler In-Reply-To: <1422227773.79.0.793422498408.issue23321@psf.upfronthosting.co.za> Message-ID: <1422253829.42.0.208673914318.issue23321@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 07:34:35 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 26 Jan 2015 06:34:35 +0000 Subject: [issue15852] typos in curses argument error messages In-Reply-To: <1346622102.83.0.795568790125.issue15852@psf.upfronthosting.co.za> Message-ID: <1422254075.3.0.000209726123466.issue15852@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 08:21:37 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Jan 2015 07:21:37 +0000 Subject: [issue23269] Tighten-up search loops in sets In-Reply-To: <1421658942.27.0.429398283891.issue23269@psf.upfronthosting.co.za> Message-ID: <1422256897.26.0.32811137993.issue23269@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I have no strong preferences. This code is used very rarely and I have no any example which exposes performance differences. But how large the benefit of your patch? It doesn't make the C code more clean. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 08:31:17 2015 From: report at bugs.python.org (Devin Jeanpierre) Date: Mon, 26 Jan 2015 07:31:17 +0000 Subject: [issue23322] parser module docs missing second example Message-ID: <1422257477.04.0.712021667077.issue23322@psf.upfronthosting.co.za> New submission from Devin Jeanpierre: The port to reST missed the second example: https://docs.python.org/release/2.5/lib/node867.html This is still referred to in the docs, so it is not deliberate. For example, the token module docs say "The second example for the parser module shows how to use the symbol module": https://docs.python.org/3.5/library/token.html#module-token There is no second example, nor any use of the symbol module, in the docs: https://docs.python.org/3.5/library/parser.html ---------- assignee: docs at python components: Documentation messages: 234716 nosy: Devin Jeanpierre, docs at python priority: normal severity: normal status: open title: parser module docs missing second example versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 09:03:38 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 26 Jan 2015 08:03:38 +0000 Subject: [issue23322] parser module docs missing second example In-Reply-To: <1422257477.04.0.712021667077.issue23322@psf.upfronthosting.co.za> Message-ID: <1422259418.13.0.0973173438073.issue23322@psf.upfronthosting.co.za> Berker Peksag added the comment: The second example was removed in https://hg.python.org/cpython/rev/19ca70b463c5 It would be better to just update the "see also" note in the token documentation. ---------- keywords: +easy nosy: +berker.peksag stage: -> needs patch versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 09:07:11 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 Jan 2015 08:07:11 +0000 Subject: [issue21408] delegation of `!=` to the right-hand side argument is not always done In-Reply-To: <1398954687.6.0.574462939929.issue21408@psf.upfronthosting.co.za> Message-ID: <20150126080511.75778.83378@psf.io> Roundup Robot added the comment: New changeset e516badfd3b2 by Serhiy Storchaka in branch '3.4': Issue #21408: The default __ne__() now returns NotImplemented if __eq__() https://hg.python.org/cpython/rev/e516badfd3b2 New changeset 7e9880052401 by Serhiy Storchaka in branch 'default': Issue #21408: The default __ne__() now returns NotImplemented if __eq__() https://hg.python.org/cpython/rev/7e9880052401 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 09:12:28 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 Jan 2015 08:12:28 +0000 Subject: [issue23268] Fix comparison of ipaddress classes In-Reply-To: <1421611358.75.0.717594852846.issue23268@psf.upfronthosting.co.za> Message-ID: <20150126081217.87111.32604@psf.io> Roundup Robot added the comment: New changeset 9a7d965ab80f by Serhiy Storchaka in branch '3.4': Issue #23268: Fixed bugs in the comparison of ipaddress classes. https://hg.python.org/cpython/rev/9a7d965ab80f New changeset 051f2a234d8a by Serhiy Storchaka in branch 'default': Issue #23268: Fixed bugs in the comparison of ipaddress classes. https://hg.python.org/cpython/rev/051f2a234d8a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 09:16:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Jan 2015 08:16:19 +0000 Subject: [issue21408] delegation of `!=` to the right-hand side argument is not always done In-Reply-To: <1398954687.6.0.574462939929.issue21408@psf.upfronthosting.co.za> Message-ID: <1422260179.13.0.865045887464.issue21408@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your contribution Martin. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 09:17:29 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Jan 2015 08:17:29 +0000 Subject: [issue23268] Fix comparison of ipaddress classes In-Reply-To: <1421611358.75.0.717594852846.issue23268@psf.upfronthosting.co.za> Message-ID: <1422260249.06.0.772071085938.issue23268@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 09:29:35 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 Jan 2015 08:29:35 +0000 Subject: [issue7665] test_urllib2 and test_ntpath fail if path contains "\" In-Reply-To: <1263142226.0.0.91918347375.issue7665@psf.upfronthosting.co.za> Message-ID: <20150126082809.87111.60550@psf.io> Roundup Robot added the comment: New changeset 1e12c9e5bc89 by Serhiy Storchaka in branch '2.7': Issue #7665: Fixed tests test_ntpath and test_urllib2 when ran in the https://hg.python.org/cpython/rev/1e12c9e5bc89 New changeset 04fa56628830 by Serhiy Storchaka in branch '3.4': Issue #7665: Fixed tests test_ntpath and test_urllib2 when ran in the https://hg.python.org/cpython/rev/04fa56628830 New changeset 1db1cd711104 by Serhiy Storchaka in branch 'default': Issue #7665: Fixed tests test_ntpath and test_urllib2 when ran in the https://hg.python.org/cpython/rev/1db1cd711104 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 09:31:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Jan 2015 08:31:46 +0000 Subject: [issue7665] test_urllib2 and test_ntpath fail if path contains "\" In-Reply-To: <1263142226.0.0.91918347375.issue7665@psf.upfronthosting.co.za> Message-ID: <1422261106.28.0.772353435349.issue7665@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank for your review Senthil. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 09:36:45 2015 From: report at bugs.python.org (Mark Summerfield) Date: Mon, 26 Jan 2015 08:36:45 +0000 Subject: [issue23292] Enum doc suggestion In-Reply-To: <1421870429.3.0.139624304143.issue23292@psf.upfronthosting.co.za> Message-ID: <1422261405.91.0.950821966976.issue23292@psf.upfronthosting.co.za> Mark Summerfield added the comment: Nice answer Ethan (but I can't vote you up since stack overflow won't let me vote or even comment anymore). As for adding export_to(), it seems like a good idea. However, personally, I think the signature should be hoist_into(namespace, cls, *clses) to allow multiple enums in the same module to be exported in one go. (Just kidding about the new name though.) PS I should have said earlier, thanks Eli:-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 09:38:48 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 Jan 2015 08:38:48 +0000 Subject: [issue23094] Unpickler failing with PicklingError at frame end on readline due to a broken comparison In-Reply-To: <1419117872.02.0.125928182025.issue23094@psf.upfronthosting.co.za> Message-ID: <20150126083820.75774.81118@psf.io> Roundup Robot added the comment: New changeset d5e13b74d377 by Serhiy Storchaka in branch '3.4': Issue #23094: Fixed readline with frames in Python implementation of pickle. https://hg.python.org/cpython/rev/d5e13b74d377 New changeset c347c21e5afa by Serhiy Storchaka in branch 'default': Issue #23094: Fixed readline with frames in Python implementation of pickle. https://hg.python.org/cpython/rev/c347c21e5afa ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 09:40:12 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Jan 2015 08:40:12 +0000 Subject: [issue23321] Crash in str.decode() with special error handler In-Reply-To: <1422253829.47.0.0786754687177.issue23321@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Debugging build crashes in some circumstances in str.decode() (...) buildbots are broken without it Is it a regression? Would it be possible to identify the changeset responsible of the regression? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 09:44:12 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Jan 2015 08:44:12 +0000 Subject: [issue20284] patch to implement PEP 461 (%-interpolation for bytes) In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <1422261852.63.0.67174012068.issue20284@psf.upfronthosting.co.za> STINNER Victor added the comment: It's strange that %s format raises an error about the %b format: >>> b's? %s' % 1 Traceback (most recent call last): File "", line 1, in TypeError: %b requires bytes, or an object that implements __bytes__, not 'int' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 11:07:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 Jan 2015 10:07:33 +0000 Subject: [issue23293] [Windows] asyncio: race condition related to IocpProactor.connect_pipe() In-Reply-To: <1421879573.47.0.0852926503812.issue23293@psf.upfronthosting.co.za> Message-ID: <20150126100729.55128.20988@psf.io> Roundup Robot added the comment: New changeset b6ab8fe16d16 by Victor Stinner in branch '3.4': Issue #23293, asyncio: Cleanup IocpProactor.close() https://hg.python.org/cpython/rev/b6ab8fe16d16 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 11:07:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 Jan 2015 10:07:33 +0000 Subject: [issue23208] asyncio: add BaseEventLoop._current_handle (only used in debug mode) In-Reply-To: <1420817695.78.0.447471935777.issue23208@psf.upfronthosting.co.za> Message-ID: <20150126100729.55128.30617@psf.io> Roundup Robot added the comment: New changeset 54d74f954bf9 by Victor Stinner in branch '3.4': Issue #23208, asyncio: Add BaseEventLoop._current_handle https://hg.python.org/cpython/rev/54d74f954bf9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 11:15:36 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 Jan 2015 10:15:36 +0000 Subject: [issue11578] Increase test coverage for timeit.py In-Reply-To: <1300307227.56.0.233218695639.issue11578@psf.upfronthosting.co.za> Message-ID: <20150126101523.87135.7489@psf.io> Roundup Robot added the comment: New changeset 7e7c825f75ad by Serhiy Storchaka in branch '2.7': Issue #11578: Backported test for the timeit module. https://hg.python.org/cpython/rev/7e7c825f75ad ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 11:15:36 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 Jan 2015 10:15:36 +0000 Subject: [issue18518] return-ing within code timed with timeit.timeit causes wrong return value of timeit.timeit In-Reply-To: <1374400020.0.0.45788018989.issue18518@psf.upfronthosting.co.za> Message-ID: <20150126101523.87135.3001@psf.io> Roundup Robot added the comment: New changeset e8db1cbe416b by Serhiy Storchaka in branch '2.7': Issue #18518: timeit now rejects statements which can't be compiled outside https://hg.python.org/cpython/rev/e8db1cbe416b New changeset a5769fa55791 by Serhiy Storchaka in branch '3.4': Issue #18518: timeit now rejects statements which can't be compiled outside https://hg.python.org/cpython/rev/a5769fa55791 New changeset b0a686260b5d by Serhiy Storchaka in branch 'default': Issue #18518: timeit now rejects statements which can't be compiled outside https://hg.python.org/cpython/rev/b0a686260b5d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 11:26:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Jan 2015 10:26:42 +0000 Subject: [issue23321] Crash in str.decode() with special error handler In-Reply-To: Message-ID: <129300265.9jKHJZWiYC@raxxla> Serhiy Storchaka added the comment: I think the changeset which made decoders to use _PyUnicodeWriter (issue16311) is responsible of the regression. For example consider b'\x80abc'.decode('utf-8', 'backslashreplace'). The writer reserves string buffer with size 4 (every byte produces at most 1 character). First byte is incorrect and replaced by 4-character string '\\x80'. The writer increases min_length but doesn't resize the buffer because its size is enough to write replacement string. But following writes of ASCII characters cause buffer overflow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 11:27:29 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Jan 2015 10:27:29 +0000 Subject: [issue23094] Unpickler failing with PicklingError at frame end on readline due to a broken comparison In-Reply-To: <1419117872.02.0.125928182025.issue23094@psf.upfronthosting.co.za> Message-ID: <1422268049.63.0.683253373972.issue23094@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 11:54:57 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Jan 2015 10:54:57 +0000 Subject: [issue18518] return-ing within code timed with timeit.timeit causes wrong return value of timeit.timeit In-Reply-To: <1374400020.0.0.45788018989.issue18518@psf.upfronthosting.co.za> Message-ID: <1422269697.18.0.19221809453.issue18518@psf.upfronthosting.co.za> STINNER Victor added the comment: Buildbots are unhappy. Example: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%202.7/builds/837/steps/test/logs/stdio 1 test failed: test_timeit Re-running test 'test_timeit' in verbose mode test test_timeit crashed -- : No module named support Traceback (most recent call last): File "./Lib/test/regrtest.py", line 901, in runtest_inner File "/usr/home/buildbot/python/2.7.koobs-freebsd10/build/Lib/test/test_timeit.py", line 8, in from test.support import run_unittest ImportError: No module named support [44296 refs] *** Error code 1 ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 12:13:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Jan 2015 11:13:11 +0000 Subject: [issue18518] return-ing within code timed with timeit.timeit causes wrong return value of timeit.timeit In-Reply-To: <1374400020.0.0.45788018989.issue18518@psf.upfronthosting.co.za> Message-ID: <1422270791.7.0.0872298987954.issue18518@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Already fixed in 617c226da195. Needs time for buildbots to rerun tests. I didn't noticed error when backported tests because there was local file support.py in my workspace. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 12:17:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Jan 2015 11:17:41 +0000 Subject: [issue19361] Specialize exceptions thrown by JSON parser In-Reply-To: <1382527334.08.0.362620105205.issue19361@psf.upfronthosting.co.za> Message-ID: <1422271061.86.0.0816568175951.issue19361@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 12:17:42 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 Jan 2015 11:17:42 +0000 Subject: [issue19361] Specialize exceptions thrown by JSON parser In-Reply-To: <1382527334.08.0.362620105205.issue19361@psf.upfronthosting.co.za> Message-ID: <20150126111718.55102.49020@psf.io> Roundup Robot added the comment: New changeset 07af9847dbec by Serhiy Storchaka in branch 'default': Issue #19361: JSON decoder now raises JSONDecodeError instead of ValueError. https://hg.python.org/cpython/rev/07af9847dbec ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 13:02:56 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 Jan 2015 12:02:56 +0000 Subject: [issue14099] ZipFile.open() should not reopen the underlying file In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za> Message-ID: <20150126120212.84259.39272@psf.io> Roundup Robot added the comment: New changeset ae42c4576438 by Serhiy Storchaka in branch '2.7': Issue #14099: Backout changeset c2c4cde55f6f (except adapted tests). https://hg.python.org/cpython/rev/ae42c4576438 New changeset 680b47c96e08 by Serhiy Storchaka in branch '3.4': Issue #14099: Backout changeset e5bb3044402b (except adapted tests). https://hg.python.org/cpython/rev/680b47c96e08 New changeset 4973ccd46e32 by Serhiy Storchaka in branch 'default': Issue #14099: Writing to ZipFile and reading multiple ZipExtFiles is https://hg.python.org/cpython/rev/4973ccd46e32 New changeset 9cbf9f96920d by Serhiy Storchaka in branch 'default': Issue #14099: Restored support of writing ZIP files to tellable but https://hg.python.org/cpython/rev/9cbf9f96920d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 13:05:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Jan 2015 12:05:57 +0000 Subject: [issue14099] ZipFile.open() should not reopen the underlying file In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za> Message-ID: <1422273957.54.0.356037546314.issue14099@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry Stepan and David, but for this feature you need wait 3.5. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 13:07:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Jan 2015 12:07:46 +0000 Subject: [issue22818] Deprecate splitting on possible zero-width re patterns In-Reply-To: <1415444480.37.0.198748558658.issue22818@psf.upfronthosting.co.za> Message-ID: <1422274066.14.0.690311997523.issue22818@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could anyone please make a review (mainly documentation)? It would be good to get this change in first alpha. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 13:41:03 2015 From: report at bugs.python.org (Alessio) Date: Mon, 26 Jan 2015 12:41:03 +0000 Subject: [issue23323] Issue with imaplib and append messages passing a tuple with flags Message-ID: <1422276063.41.0.625016569735.issue23323@psf.upfronthosting.co.za> New submission from Alessio: In example when appending a message with more than one flag in a tuple with imaplib: print flags ('\\Answered', '\\Seen') connection.append('INBOX', flags, date, msg) --------------------------------------------------------------------------- TypeError Traceback (most recent call last) in () ----> 1 connection.append('INBOX', flags, date, msg[1][0][1]) /usr/lib/python2.7/imaplib.py in append(self, mailbox, flags, date_time, message) 326 if flags: 327 if (flags[0],flags[-1]) != ('(',')'): --> 328 flags = '(%s)' % flags 329 else: 330 flags = None TypeError: not all arguments converted during string formatting When I have only one flag to append: print flags Out[70]: ('\\Answered',) connection.append('INBOX', flags, date, msg) Out[74]: ('OK', ['[APPENDUID 1 1012] APPEND completed']) Any ideas? Thanks ---------- components: Library (Lib) messages: 234738 nosy: Pilessio priority: normal severity: normal status: open title: Issue with imaplib and append messages passing a tuple with flags versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 14:04:22 2015 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 26 Jan 2015 13:04:22 +0000 Subject: [issue23323] Issue with imaplib and append messages passing a tuple with flags In-Reply-To: <1422276063.41.0.625016569735.issue23323@psf.upfronthosting.co.za> Message-ID: <1422277462.51.0.688137660841.issue23323@psf.upfronthosting.co.za> Eric V. Smith added the comment: flags is supposed to be a string. This is not well documented, like much of the module. Try: flags = r'(\Answered \Seen)' ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 14:12:20 2015 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 26 Jan 2015 13:12:20 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1422277940.61.0.0937084839782.issue17911@psf.upfronthosting.co.za> Nick Coghlan added the comment: I put some detailed comments in the review, but my main large scale concern is with the "traceback.Frame" name. Making "frame object" an ambiguous phrase seems like a bad idea to me, so I've suggested making it "FrameSummary" (or "FrameInfo", but on reflection I prefer the more explicit term). That would then suggest also making it "traceback.StackSummary" for consistency. I think having the top level API be an iterable would be OK, but may be a little surprising. Is there a major advantage to avoiding building the whole traceback in memory? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 14:38:35 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 26 Jan 2015 13:38:35 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1422279515.23.0.383442376354.issue17911@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > tb = TracebackException(*sys.exc_info, lookup_lines=False) You don't need an exception tuple in Python 3, the exception instance is enough. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 14:56:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Jan 2015 13:56:56 +0000 Subject: [issue22818] Deprecate splitting on possible zero-width re patterns In-Reply-To: <1415444480.37.0.198748558658.issue22818@psf.upfronthosting.co.za> Message-ID: <1422280616.79.0.964626727628.issue22818@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Ezio for your review. Updated patch includes most of your suggestions. But I think some places still can be dim. ---------- Added file: http://bugs.python.org/file37863/re_deprecate_split_zero_width_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 15:04:31 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 26 Jan 2015 14:04:31 +0000 Subject: [issue23323] Issue with imaplib and append messages passing a tuple with flags In-Reply-To: <1422276063.41.0.625016569735.issue23323@psf.upfronthosting.co.za> Message-ID: <1422281071.39.0.801453776336.issue23323@psf.upfronthosting.co.za> R. David Murray added the comment: Indeed, as with much of the early email related code in the stdlib, the documentation assumes way too much familiarity with the relevant RFC...which is really hard to read. We should add a few more details to the docs (like FLAGS being a string) even if we don't have the resources to do a full overhaul. ---------- assignee: -> docs at python components: +Documentation -Library (Lib) nosy: +docs at python, r.david.murray stage: -> needs patch versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 15:05:24 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 Jan 2015 14:05:24 +0000 Subject: [issue23293] [Windows] asyncio: race condition related to IocpProactor.connect_pipe() In-Reply-To: <1421879573.47.0.0852926503812.issue23293@psf.upfronthosting.co.za> Message-ID: <20150126140500.84279.8787@psf.io> Roundup Robot added the comment: New changeset 99c3e304a4ea by Victor Stinner in branch '3.4': Issue #23293, asyncio: Rewrite IocpProactor.connect_pipe() as a coroutine https://hg.python.org/cpython/rev/99c3e304a4ea ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 15:06:06 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Jan 2015 14:06:06 +0000 Subject: [issue23208] asyncio: add BaseEventLoop._current_handle (only used in debug mode) In-Reply-To: <1420817695.78.0.447471935777.issue23208@psf.upfronthosting.co.za> Message-ID: <1422281166.61.0.994095426718.issue23208@psf.upfronthosting.co.za> STINNER Victor added the comment: I commited current_handle.patch. It's only a first step, I will also change the logger or calls to the logger to use this traceback of the current handle. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 15:08:01 2015 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=) Date: Mon, 26 Jan 2015 14:08:01 +0000 Subject: [issue14910] argparse: disable abbreviation In-Reply-To: <1337943742.57.0.897347214609.issue14910@psf.upfronthosting.co.za> Message-ID: <1422281281.55.0.777559440423.issue14910@psf.upfronthosting.co.za> Changes by R?mi Rampin : ---------- nosy: +remram _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 15:09:42 2015 From: report at bugs.python.org (Ethan Furman) Date: Mon, 26 Jan 2015 14:09:42 +0000 Subject: [issue20284] patch to implement PEP 461 (%-interpolation for bytes) In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <1422281382.28.0.899320896048.issue20284@psf.upfronthosting.co.za> Ethan Furman added the comment: it does seem a bit odd -- on the other hand, %s is an alias for %b, is deprecated for new 3-only code, and this might help serve as a reminder of that. Or we could fix it. ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 15:19:52 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Jan 2015 14:19:52 +0000 Subject: [issue23187] Segmentation fault, possibly asyncio related In-Reply-To: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za> Message-ID: <1422281992.5.0.308483518439.issue23187@psf.upfronthosting.co.za> STINNER Victor added the comment: Since the issue looks to be related to a third party module (ujson), I close this issue. Note: On UNIX, asyncio is fully implemented in Python, I don't see how it could corrupt internal Python structures. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 15:22:18 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Jan 2015 14:22:18 +0000 Subject: [issue23046] asyncio.BaseEventLoop is documented, but only exported via asyncio.base_events In-Reply-To: <1418454792.43.0.104807870648.issue23046@psf.upfronthosting.co.za> Message-ID: <1422282138.68.0.0536438525655.issue23046@psf.upfronthosting.co.za> STINNER Victor added the comment: Since there is already an open issue suggesting to document AbstractServer (and Server), I close this issue. The original bug was fixed: BaseEventLoop is now part of the asyncio namespace. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 15:23:05 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Jan 2015 14:23:05 +0000 Subject: [issue23057] [Windows] asyncio: support signal handlers on Windows (feature request) In-Reply-To: <1418674256.87.0.827009141117.issue23057@psf.upfronthosting.co.za> Message-ID: <1422282185.42.0.871518314242.issue23057@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: asyncio loop on Windows should stop on keyboard interrupt -> [Windows] asyncio: support signal handlers on Windows (feature request) type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 16:37:12 2015 From: report at bugs.python.org (Demian Brecht) Date: Mon, 26 Jan 2015 15:37:12 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1422286632.25.0.37330489273.issue3566@psf.upfronthosting.co.za> Demian Brecht added the comment: > now I?m thinking that should be up to the higher level user +1. A closed connection is a closed connection, whether it's persistent or not. The higher level code should be responsible for the context, not the connection level. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 16:45:05 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 Jan 2015 15:45:05 +0000 Subject: [issue20284] patch to implement PEP 461 (%-interpolation for bytes) In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <20150126154456.84273.62515@psf.io> Roundup Robot added the comment: New changeset db7ec64aac39 by Victor Stinner in branch 'default': Issue #20284: Fix a compilation warning on Windows https://hg.python.org/cpython/rev/db7ec64aac39 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 16:45:05 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 Jan 2015 15:45:05 +0000 Subject: [issue15859] PyUnicode_EncodeFSDefault win32 inconsistancy. In-Reply-To: <1346736283.51.0.0156916220677.issue15859@psf.upfronthosting.co.za> Message-ID: <20150126154456.84273.15322@psf.io> Roundup Robot added the comment: New changeset e124aab5d9a0 by Victor Stinner in branch 'default': Issue #15859: PyUnicode_EncodeFSDefault(), PyUnicode_EncodeMBCS() and https://hg.python.org/cpython/rev/e124aab5d9a0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 16:48:24 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Jan 2015 15:48:24 +0000 Subject: [issue15859] PyUnicode_EncodeFSDefault win32 inconsistancy. In-Reply-To: <1346736283.51.0.0156916220677.issue15859@psf.upfronthosting.co.za> Message-ID: <1422287304.78.0.304613288648.issue15859@psf.upfronthosting.co.za> STINNER Victor added the comment: I applied fix_unicode_v2.diff to Python 3.5. For older Python versions, it's easy to workaround this issue: ensure explicitly that your object is a Unicode object using PyUnicode_Check(). You may write your function to call PyUnicode_EncodeFSDefault() with a PyUnicode_Check() check. I prefer to not touch the stable 3.4 branch. ---------- resolution: remind -> fixed status: open -> closed versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 17:30:05 2015 From: report at bugs.python.org (Martin Richard) Date: Mon, 26 Jan 2015 16:30:05 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1422289805.02.0.0493327992402.issue17911@psf.upfronthosting.co.za> Changes by Martin Richard : ---------- nosy: +martius _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 17:40:48 2015 From: report at bugs.python.org (Demian Brecht) Date: Mon, 26 Jan 2015 16:40:48 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1422290448.86.0.752069037341.issue23255@psf.upfronthosting.co.za> Demian Brecht added the comment: Thanks for the extra effort on this to satisfy multiple people's opinions. It's never an easy thing, especially when dealing with a decentralized group. My following comments are largely based on the public API. I haven't done a full review of the changes made to the tests. All extraneous spaces should be removed. For example the first line here: + + redirect_path = self._redirect_path(path) + if redirect_path: > Lists the files we want the server to check and render to client. We can add/remove file names as required. Order of files denotes priority. Defaults to ['index.htm', 'index.html'] I think this might read a little better as: "Overridable index files. If any of these files are present in a request pointing to a directory on the server's file system, the contents of the file will be returned. Otherwise, a directory listing will be returned. Defaults to ['index.htm', 'index.html']. Order of files denotes priority. That said, I'm not a wordsmith so there may be a (much) better way of structuring this. > +class HTTPStatusType(Enum): This doesn't sit quite well with me and I think it really should be removed. There are very few cases (if any) that I can think of where this would be useful. Cases where I've encountered the need for a range check generally is around subsets (i.e. 200 and 201 mean entirely different things and /shouldn't/ be globbed together). Additionally (this is subjective), I find it a little strange that the value of an enum is a range. If for some reason it stays, I think the values should at least be sets allowing for O(1) lookup. > + def redirect(self, url, status=HTTPStatus.MOVED_PERMANENTLY): There should be an assertion in this block that the status is one of the redirect codes (301, 302, 308). Calling redirect('/foo', status=200) doesn't make sense. >+ if os.path.isfile(path): + return self.get_file(path) + + # `path` has file with filename in self.index_files + for index_file in self.index_files: + index = os.path.join(path, index_file) Before the directory-related logic executes, you could add a check in for isdir() and short circuit with a 404 rather than relying on an index file not being found and then running into list_directory(), which would result in a 404 with the message "No permission to list directory", which isn't actually correct in the case where the directory doesn't exist. > get_status_type, apply_success_headers, apply_headers I think that these three methods should be removed as they're superfluous, make the code less readable and is inconsistent with how responses and headers are sent throughout the rest of server.py. The general practice is: self.send_response() self.send_header() self.send_header() self.end_headers() The code in this patch should match that. get_status_type is not needed as it /should/, if anything, be a single line passthrough to a reverse lookup mapping. Iterating over each enum followed by an iteration over each value is not optimal behaviour (O(N) rather than O(1)). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 17:42:00 2015 From: report at bugs.python.org (Neil Girdhar) Date: Mon, 26 Jan 2015 16:42:00 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422290520.51.0.701121417188.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Is this correct? >>> f(*i for i in ['abc', 'def']) ['a', 'b', 'c', 'd', 'e', 'f'] [] >>> f(**i for i in ['abc', 'def']) File "", line 1 f(**i for i in ['abc', 'def']) ^ SyntaxError: invalid syntax Should neither work? Both? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 17:42:23 2015 From: report at bugs.python.org (Neil Girdhar) Date: Mon, 26 Jan 2015 16:42:23 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422290543.81.0.0225831760801.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: >>> def f(a, *b): print(list(a), list(b)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 17:43:30 2015 From: report at bugs.python.org (Neil Girdhar) Date: Mon, 26 Jan 2015 16:43:30 +0000 Subject: [issue23316] Incorrect evaluation order of function arguments with *args In-Reply-To: <1422200816.31.0.910655700205.issue23316@psf.upfronthosting.co.za> Message-ID: <1422290610.72.0.0702290988024.issue23316@psf.upfronthosting.co.za> Neil Girdhar added the comment: After thinking about this a bit more, my suggestion is not to fix it. Instead, I suggest that PEP 8 be modified to suggest that all positional arguments and iterable argument unpackings precede keyword arguments and keyword argument unpackings. Then, a tool like autopep8 is free to reorganize argument lists. Such reorganization will not be possible if f(*a(), b=b()) is different than f(b=b(), *a()). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 17:44:21 2015 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 26 Jan 2015 16:44:21 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1422290520.51.0.701121417188.issue2292@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Both. On Jan 26, 2015 8:42 AM, "Neil Girdhar" wrote: > > Neil Girdhar added the comment: > > Is this correct? > > >>> f(*i for i in ['abc', 'def']) > ['a', 'b', 'c', 'd', 'e', 'f'] [] > >>> f(**i for i in ['abc', 'def']) > File "", line 1 > f(**i for i in ['abc', 'def']) > ^ > SyntaxError: invalid syntax > > Should neither work? Both? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 17:54:18 2015 From: report at bugs.python.org (Neil Girdhar) Date: Mon, 26 Jan 2015 16:54:18 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422291258.1.0.443067560291.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Could you help me understand this a bit better? I always thought of f(x for x in l) as equivalent to f( (x for x in l) ). So, I can see that f(*x for x in l) should be equivalent to f( (*x for x in l) ). How should we interpret f(**x for x in l)? Is it then f( {**x for x in l} )? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 17:55:28 2015 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 26 Jan 2015 16:55:28 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1422290543.81.0.0225831760801.issue2292@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Wait, with that f() definition I'd expect a different result from the former -- each letter as a new arg. Right? On Jan 26, 2015 8:42 AM, "Neil Girdhar" wrote: > > Neil Girdhar added the comment: > > >>> def f(a, *b): print(list(a), list(b)) > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 17:56:27 2015 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 26 Jan 2015 16:56:27 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: Message-ID: Guido van Rossum added the comment: Let's wait until I have a keyboard. In 20 min. On Jan 26, 2015 8:55 AM, "Guido van Rossum" wrote: > Wait, with that f() definition I'd expect a different result from the > former -- each letter as a new arg. Right? > On Jan 26, 2015 8:42 AM, "Neil Girdhar" wrote: > >> >> Neil Girdhar added the comment: >> >> >>> def f(a, *b): print(list(a), list(b)) >> >> ---------- >> >> _______________________________________ >> Python tracker >> >> _______________________________________ >> > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 17:58:52 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Jan 2015 16:58:52 +0000 Subject: [issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture In-Reply-To: <1419122866.29.0.725788641938.issue23095@psf.upfronthosting.co.za> Message-ID: <1422291532.56.0.851062876946.issue23095@psf.upfronthosting.co.za> STINNER Victor added the comment: Pseudo-code: --- handle = ... fut = proactor.wait_for_handle(handle) fut.cancel() loop.close() --- Windows functions called in this code: - A: call RegisterWaitForSingleObject() on an handle - A: call UnregisterWaitEx() with an event - B: call RegisterWaitForSingleObject() on this event - B: the wait on this event completes: the completion is signaled with PostToQueueCallback() (our internal callback passed to RegisterWaitForSingleObject()) - A: _unregister_wait_cb() is called on the future A - (but the wait on the object A is never signaled by PostToQueueCallback()) In short, UnregisterWaitEx() is called before the callback passed to RegisterWaitForSingleObject() is called. In this case, the callback is never called, and so the completion of the wait is never signaled. Internally, RegisterWaitForSingleObject() is implemented as a pool of threads calling WaitForMultipleObjects(). The default limit for the pool is 500 threads. WaitForMultipleObjects() is limited to 64 objects. Each thread uses a timer and computes a timeout. The timer is awaken to cancel a wait. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 18:19:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Jan 2015 17:19:43 +0000 Subject: [issue22818] Deprecate splitting on possible zero-width re patterns In-Reply-To: <1415444480.37.0.198748558658.issue22818@psf.upfronthosting.co.za> Message-ID: <1422292783.05.0.18959441811.issue22818@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated patch includes Ezio's suggestions. Thank you Ezio, they looks great to me. ---------- Added file: http://bugs.python.org/file37864/re_deprecate_split_zero_width_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 18:54:08 2015 From: report at bugs.python.org (Justin Eldridge) Date: Mon, 26 Jan 2015 17:54:08 +0000 Subject: [issue23317] Incorrect description of descriptor invocation in Python Language Reference In-Reply-To: <1422206163.24.0.274216799196.issue23317@psf.upfronthosting.co.za> Message-ID: <1422294848.47.0.208362125773.issue23317@psf.upfronthosting.co.za> Justin Eldridge added the comment: Ah, I see how writing a description of this which is both concise and precise would be difficult, especially for Python 2. > But the Class Binding description is correct, since if the __get__ method is > *not* defined on the type (of the descriptor), the descriptor instance itself > is returned (so explicitly calling type in the "equivalent expression" would be > wrong) I see, but couldn't this also be held against the current "equivalent"? That is, saying A.x is equivalent to A.__dict__['x'].__get__(None, A) is not stricly true when __get__ isn't defined on type(x). I think I see now why this is difficult to document cleanly, and the "Special method lookup" section of the documentation does a good job of explaining this. The issue isn't exclusive to descriptors. It affects, for example, the documentation on rich comparison operators, which says that x == y invokes x.__eq__(y), when this hasn't quite been true since old-style classes. So saying x == y is equivalent to x.__eq__(y) isn't really correct, and saying that it is equivalent to type(x).__eq__(x,y) isn't quite right either, as implicit invocation may bypass the metaclass's __getattribute__. The latter, however, seems "less wrong". Is there a reason that the former is preferred by the documentation? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 19:28:37 2015 From: report at bugs.python.org (Joshua Landau) Date: Mon, 26 Jan 2015 18:28:37 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422296917.29.0.0744597813521.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: If we're supporting f(**x for x in y) surely we should also support f(x: y for x, y in z) I personally don't like this idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 19:36:18 2015 From: report at bugs.python.org (Robert Collins) Date: Mon, 26 Jan 2015 18:36:18 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1422297378.59.0.744555673815.issue17911@psf.upfronthosting.co.za> Robert Collins added the comment: Thanks for the review - shall action it all as it seems all good improvements. Two key notes: the use of an exception triple is useful to ease backports of this: a primary goal for me is being able to use the locals stuff in unittest for existing production code bases like OpenStack: there's a balance to be struck between new shiny features like __traceback__ and backporting. I'll consider the idea of value-or-triple; if all the consuming code is going to be using the triple interface I'm not sure the value one would, drumroll please, have value. The locals stuff is as you note not complete or exposed yet. I wanted it in the design to be able to vet that it will actually be feasible without a later API break. I'm not -quite- there but I do also agree that it doesn't need to be in the output layer yet (in fact there's a different ticket for that anyway). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 19:38:27 2015 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 26 Jan 2015 18:38:27 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422297507.26.0.0610830503462.issue2292@psf.upfronthosting.co.za> Guido van Rossum added the comment: So I think the test function here should be: def f(*a, **k): print(list(a), list(k)) Then we can try things like: f(x for x in ['ab', 'cd']) which prints a generator object, because this is interpreted as an argument that's a generator expression. But now let's consider: f(*x for x in ['ab', 'cd']) I personally expected this to be equivalent to: f(*'ab', *'cd') IOW: f('a', 'b', 'c', 'd') However, it seems your current patch (#18) interprets it as still passing a single argument which is the generator expression (*x for x in ['ab', 'cd']) which in turn is equivalent to iter(['a', 'b', 'c', 'd']), IOW f() is called with a single argument that is a generator. The PEP doesn't give clarity on what to do here. The question now is, should we interpret things like *x for x in ... as an extended form of generator expression, or as an extended form of *arg? I somehow think the latter is more useful and also the more logical extension. My reasoning is that the PEP supports things like f(*a, *b) and it would be fairly logical to interpret f(*x for x in xs) as doing the *x thing for each x in the list xs. I think this same interpretation works for [*x for x in xs] and {*x for x in xs}, and we can also extend it to ** in {} and in calls (obviously ** has no meaning in list comprehensions or generator expressions). BTW I think I found another bug in patch #18: >>> {**1} 1 >>> That should be an error. An edge case I'm not sure about: should {**x} accept an iterable of (key, value) pairs, like dict(x)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 19:41:24 2015 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 26 Jan 2015 18:41:24 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422297684.09.0.926371162652.issue2292@psf.upfronthosting.co.za> Guido van Rossum added the comment: @Joshua: Re: f(x: y for x, y in z) I don't think that follows at all. We support f(**d) now, but if d == {'a': 1, 'b': 2}, it is equivalent to f(a=1, b=2), not f(a: 1, b: 2). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 19:59:07 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Jan 2015 18:59:07 +0000 Subject: [issue21076] Turn signal.SIG* constants into enums In-Reply-To: <1395935330.94.0.38028035584.issue21076@psf.upfronthosting.co.za> Message-ID: <1422298747.75.0.441495217843.issue21076@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And more, as far as standard signal handler is tested for identity, signal.SIG_DFL and _signal.SIG_DFL should be the same object. Current code works only due to coincidence of two circumstances: 1) Small integers are cached in CPython. 2) SIG_DFL and SIG_IGN are small integers on common platforms. When small integer caching is disabled (NSMALLPOSINTS == NSMALLPOSINTS == 0) or when platform depended macros SIG_DFL and SIG_IGN are not small integers, the signal module will mystically fail. The simplest way to solve this issue is to backout turning SIG_DFL and SIG_IGN into enums. ---------- resolution: fixed -> stage: resolved -> patch review type: -> behavior Added file: http://bugs.python.org/file37865/signal_no_enum_handlers.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 19:59:32 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 26 Jan 2015 18:59:32 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1422297378.59.0.744555673815.issue17911@psf.upfronthosting.co.za> Message-ID: <54C68E90.5090103@free.fr> Antoine Pitrou added the comment: Le 26/01/2015 19:36, Robert Collins a ?crit : > > Two key notes: the use of an exception triple is useful to ease backports of this Then I'd recommend making it exception-or-tuple (rather than a *exc_info), so that both situations are satisfied. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 20:06:55 2015 From: report at bugs.python.org (Ethan Furman) Date: Mon, 26 Jan 2015 19:06:55 +0000 Subject: [issue21076] Turn signal.SIG* constants into enums In-Reply-To: <1395935330.94.0.38028035584.issue21076@psf.upfronthosting.co.za> Message-ID: <1422299215.64.0.237534454521.issue21076@psf.upfronthosting.co.za> Ethan Furman added the comment: I know nothing about this part of CPython, but wouldn't the correct solution be to not compare by identity? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 20:18:32 2015 From: report at bugs.python.org (Joshua Landau) Date: Mon, 26 Jan 2015 19:18:32 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422299912.93.0.468871144722.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: Quick-fix for Guido's bug attached. I'm not familiar with this part of the code, yet, so take this tentatively. I just changed while (containers > 1) { to while (containers) { --- @Guido My comments were assuming `f(**x for x in y)` meant `f({**x for x in y})`. I see your reasoning, but I don't like how your version has (x for y in z for x in y) == (*y for y in z) f(x for y in z for x in y) != f(*y for y in z) This seems like a tripping point. I've never wanted to unpack a 2D iterable into an argument list, so personally I'm not convinced by the value-add either. ---------- Added file: http://bugs.python.org/file37866/starunpack19.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 20:37:46 2015 From: report at bugs.python.org (Joshua Landau) Date: Mon, 26 Jan 2015 19:37:46 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422301066.24.0.936820087631.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: Update for the error messages fix. I've put aside the idea of unifying things for now because there are a couple of interdependencies I wasn't expecting and I absolutely don't want the fast-path for f(x) to get slower. ---------- Added file: http://bugs.python.org/file37867/starunpack20.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 20:41:26 2015 From: report at bugs.python.org (Neil Girdhar) Date: Mon, 26 Jan 2015 19:41:26 +0000 Subject: [issue23316] Incorrect evaluation order of function arguments with *args In-Reply-To: <1422200816.31.0.910655700205.issue23316@psf.upfronthosting.co.za> Message-ID: <1422301286.11.0.709132921624.issue23316@psf.upfronthosting.co.za> Neil Girdhar added the comment: (I also suggest that the evaluation order within a function argument list to be defined to be positional and iterable before keyword, otherwise left-to-right???rather than strictly left-to-right). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 21:36:56 2015 From: report at bugs.python.org (Alan Yorinks) Date: Mon, 26 Jan 2015 20:36:56 +0000 Subject: [issue23324] Python 3.4.2 running slow on Ubuntu 14.10 Message-ID: <1422304616.63.0.532936343926.issue23324@psf.upfronthosting.co.za> New submission from Alan Yorinks: Folks, I am not trying to waste anyone's time. If this is not the correct mailing list to get this problem resolved, please point me to the correct one. To summarize my problem, if I run the configuration below with python 3.4.2 on Linux, the program reacts to user input (changing a potentiometer) extremely slowly. If I run the exact same code on Windows, there is no slow down. Also, if I run the exact same setup using pypy 3.2.4, there is no slowdown. I also tried running the software on pypy 3.2.4 on Linux and there is no slowdown. The only problem I encounter is using Python 3.4.2 on Linux. Python 2.7.8 works without issue on both Linux and Windows. The setup to reproduce the problem is not complicated but requires PyMata to be installed on an Arduino Uno or Leonardo attached to the computer. Prerequisites: OS: Ubuntu Linux 14.10. Python: 3.4.2 PyMata 2.02 or can be installed from PyPi Requires PySerial 2.7 Arduino Uno or Leonardo microcontroller with StandardFirmata installed. Program to be executed: located in the PyMata/examples/digital_analog_io directory. The file is polling_digital_analog_io.py. How the problem exhibits itself: When adjusting the potentiometer to set the intensity level of the LED, the intensity level greatly lags the pot adjustment. On Python 2.7 on Linux and Windows, on Python 3.4.2 on Windows, and on pypy3.2.4 on Linux, there is no lag and the program behaves as expected. The only variable is the Linux version of Python 3.4.2, so it is my belief that python 3.4.2 for linux has issues. I will be happy to provide any additional information to help resolve this. Again if this is the wrong mailing list, please point me to the correct one. ---------- components: Interpreter Core messages: 234774 nosy: MrYsLab priority: normal severity: normal status: open title: Python 3.4.2 running slow on Ubuntu 14.10 versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 21:38:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Jan 2015 20:38:30 +0000 Subject: [issue23325] Turn SIG_DFL and SIG_IGN into functions Message-ID: <1422304710.21.0.213579052731.issue23325@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: In C the SIG_DFL and SIG_IGN macros expand into integral expressions that are not equal to an address of any function. In Python they are int objects with platform depended values. Second argument of the signal() function should be SIG_DFL, SIG_IGN, or a function. The getsignal() function returns SIG_DFL, SIG_IGN, None, or a function. They are tested for identity in signal() and getsignal() returns identical values. So actually SIG_DFL and SIG_IGN are just singletons. I propose to turn SIG_DFL and SIG_IGN into functions. Benefits: 1. They will have names and self-descriptive representation. 2. They will have docstrings. 3. The signature of signal() will be simpler. The type of second argument would be function. 4. Their pickling will be portable. This patch depends on the backout of turning these constants to enums (issue21076). ---------- components: Library (Lib) files: signal_std_handlers.patch keywords: patch messages: 234775 nosy: ethan.furman, giampaolo.rodola, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Turn SIG_DFL and SIG_IGN into functions type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file37868/signal_std_handlers.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 21:39:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Jan 2015 20:39:42 +0000 Subject: [issue21076] Turn signal.SIG* constants into enums In-Reply-To: <1395935330.94.0.38028035584.issue21076@psf.upfronthosting.co.za> Message-ID: <1422304782.08.0.268494773797.issue21076@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I have other proposition -- turn them into functions (issue23325). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 21:44:35 2015 From: report at bugs.python.org (Robert Collins) Date: Mon, 26 Jan 2015 20:44:35 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1422305075.74.0.275844945976.issue17911@psf.upfronthosting.co.za> Robert Collins added the comment: The generator thing: the code was refactoring not so long ago to be generator based internally with lists as a UI shim. I don't think there is a major advantage either way. Less buffering on one hand. Less convenient in some cases on the other. Simple use like ''.join(foo.format()) is going to be unaffected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 22:32:54 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 Jan 2015 21:32:54 +0000 Subject: [issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture In-Reply-To: <1419122866.29.0.725788641938.issue23095@psf.upfronthosting.co.za> Message-ID: <20150126213214.55110.14633@psf.io> Roundup Robot added the comment: New changeset 36e80c6599aa by Victor Stinner in branch '3.4': Issue #23095, asyncio: Fix _WaitHandleFuture.cancel() https://hg.python.org/cpython/rev/36e80c6599aa ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 22:34:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Jan 2015 21:34:40 +0000 Subject: [issue23326] Remove redundant __ne__ implementations Message-ID: <1422308079.14.0.124539148403.issue23326@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: As far as default __ne__ implementation delegates to __eq__, concrete __ne__ implementations are mostly redundant. They make sens when default __ne__ did not handle non-comparable types correctly, but now it is fixed. Proposed patch removes correct but redundant __ne__ implementations (incorrect implementations were removed in issue21408). ---------- components: Library (Lib) files: remove___ne__.patch keywords: patch messages: 234779 nosy: serhiy.storchaka, vadmium priority: normal severity: normal stage: patch review status: open title: Remove redundant __ne__ implementations type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file37869/remove___ne__.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 22:35:37 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Jan 2015 21:35:37 +0000 Subject: [issue4395] Document auto __ne__ generation; provide a use case for non-trivial __ne__ In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za> Message-ID: <1422308137.67.0.603935879888.issue4395@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue23326. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 22:48:41 2015 From: report at bugs.python.org (Robert Collins) Date: Mon, 26 Jan 2015 21:48:41 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1422308921.57.0.695843267728.issue17911@psf.upfronthosting.co.za> Robert Collins added the comment: And for profit, review changes applied (minus the small number I disagreed with). I've clarified in the code why the exc_info tuple break out is still used (compat with the legacy API is the strongest argument). I haven't fleshed out the locals thing properly yet, I'm going to do one more iteration on that then ask for a final review before committing. (Unless we're in freeze ATM ?) ---------- Added file: http://bugs.python.org/file37870/issue17911-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 23:04:09 2015 From: report at bugs.python.org (Robert Collins) Date: Mon, 26 Jan 2015 22:04:09 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1422309849.93.0.855009000395.issue17911@psf.upfronthosting.co.za> Robert Collins added the comment: actually, strike that, I'm happy with this pending a final +1 from another reviewer. Finishing the locals stuff is a separate patch, and will look like a single new parameter to StackSummary.extract, similarly on TracebackException.__init__ and then change the format logic to show it. @Antoine - I'm not super happy with inspecting the first arg to do type-or-value stuff, if you feel its a super issue we can do it, but I'd rather wait and add it once we've got some feedback. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 23:27:25 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 Jan 2015 22:27:25 +0000 Subject: [issue23321] Crash in str.decode() with special error handler In-Reply-To: <1422227773.79.0.793422498408.issue23321@psf.upfronthosting.co.za> Message-ID: <20150126222618.29588.9266@psf.io> Roundup Robot added the comment: New changeset 1e8937861ee3 by Victor Stinner in branch 'default': Issue #22286, #23321: Fix failing test on Windows code page 932 https://hg.python.org/cpython/rev/1e8937861ee3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 23:27:25 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 26 Jan 2015 22:27:25 +0000 Subject: [issue22286] Allow backslashreplace error handler to be used on input In-Reply-To: <1409136620.65.0.397738586583.issue22286@psf.upfronthosting.co.za> Message-ID: <20150126222618.29588.52038@psf.io> Roundup Robot added the comment: New changeset 1e8937861ee3 by Victor Stinner in branch 'default': Issue #22286, #23321: Fix failing test on Windows code page 932 https://hg.python.org/cpython/rev/1e8937861ee3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 23:36:03 2015 From: report at bugs.python.org (Neil Girdhar) Date: Mon, 26 Jan 2015 22:36:03 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422311763.82.0.321558038961.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: fixed a minor bug with the function address, and made a number of polishing changes. ---------- Added file: http://bugs.python.org/file37871/starunpack21.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 23:43:56 2015 From: report at bugs.python.org (Swapneel Ambre) Date: Mon, 26 Jan 2015 22:43:56 +0000 Subject: [issue23327] zipimport to import from non-ascii pathname on Windows Message-ID: <1422312236.18.0.216782202017.issue23327@psf.upfronthosting.co.za> New submission from Swapneel Ambre: On Windows, using zipimport module APIs like get_filename on a file with non-ascii characters in the full path fails with UnicodeEncodeError: 'mbcs' codec can't encode characters in position 0--1: invalid character ( Full output attached in errorlog.txt ). The issue is that Modules/zipimport.c has a function compile_source which tries to run PyUnicode_EncodeFSDefault on the pathname. On Windows, the default encoding is 'mbcs' which cannot handle unicode characters. This has already been fixed in the import machinery on python 3 ( see issue http://bugs.python.org/issue13758, http://bugs.python.org/issue11619). The solution is to pass the pathname as Unicode directly to the compiler. ---------- components: Unicode, Windows files: errorlog.txt messages: 234786 nosy: amswap, ezio.melotti, haypo, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: zipimport to import from non-ascii pathname on Windows type: crash versions: Python 3.4 Added file: http://bugs.python.org/file37872/errorlog.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 23:45:34 2015 From: report at bugs.python.org (Swapneel Ambre) Date: Mon, 26 Jan 2015 22:45:34 +0000 Subject: [issue23327] zipimport to import from non-ascii pathname on Windows In-Reply-To: <1422312236.18.0.216782202017.issue23327@psf.upfronthosting.co.za> Message-ID: <1422312334.76.0.536016231739.issue23327@psf.upfronthosting.co.za> Swapneel Ambre added the comment: I am attaching the test script I have used to reproduce the issue. ---------- Added file: http://bugs.python.org/file37873/zipimport_test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 23:46:09 2015 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 26 Jan 2015 22:46:09 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1422312369.24.0.735240338728.issue17911@psf.upfronthosting.co.za> Nick Coghlan added the comment: On the triple-or-value front, the main case I see for considering the "you don't need exception state triples any more" argument already lost is the fact exc_info still returns a triple, and __exit__ methods still accept them as unpacked arguments. The C level exception handling APIs are also all still exception state triple based. In this view, __traceback__ is primarily about accessing *chained* tracebacks, while the top-level APIs still focus on exception state triples. This perspective also has the virtue of confining use of the Python 3 only exception traceback attribute to code that is taking advantage of a Python 3 only feature (i.e. exception chaining). For chaining independent exception state handling, working with exception state triples then remains the "one obvious way to do it", a way which is conveniently also source compatible between Python 2 and 3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 23:49:34 2015 From: report at bugs.python.org (Swapneel Ambre) Date: Mon, 26 Jan 2015 22:49:34 +0000 Subject: [issue23327] zipimport to import from non-ascii pathname on Windows In-Reply-To: <1422312236.18.0.216782202017.issue23327@psf.upfronthosting.co.za> Message-ID: <1422312574.79.0.655660217964.issue23327@psf.upfronthosting.co.za> Swapneel Ambre added the comment: I have tried to fix this by calling Py_CompileStringObject instead of Py_CompileString , thus avoiding the need to Encode the pathname. Please see zipimport_fix.patch for the possible fix. ---------- keywords: +patch Added file: http://bugs.python.org/file37874/zipimport_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 23:52:13 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Jan 2015 22:52:13 +0000 Subject: [issue23327] zipimport to import from non-ascii pathname on Windows In-Reply-To: <1422312236.18.0.216782202017.issue23327@psf.upfronthosting.co.za> Message-ID: <1422312733.72.0.621109131616.issue23327@psf.upfronthosting.co.za> STINNER Victor added the comment: > Please see zipimport_fix.patch for the possible fix. The solution looks good. Can you please try to convert zipimport_test.py to a patch for test_zipimport.py and combine it with zipimport_fix.patch to create a complete patch? You should also sign the contributor agreement: https://www.python.org/psf/contrib/contrib-form/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 23:53:28 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Jan 2015 22:53:28 +0000 Subject: [issue23095] [Windows] asyncio: race condition when cancelling a _WaitHandleFuture In-Reply-To: <1419122866.29.0.725788641938.issue23095@psf.upfronthosting.co.za> Message-ID: <1422312808.33.0.338102523715.issue23095@psf.upfronthosting.co.za> STINNER Victor added the comment: I fixed many other issues related to the IocpProactor. This time it should be ok. I ran the Tulip and Trollius test suite a lot of times, in release and debug mode. I didn't see any warning nor hang. I also ran test_asyncio of Python as well. I close this issue again. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 26 23:55:39 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Jan 2015 22:55:39 +0000 Subject: [issue23327] zipimport to import from non-ascii pathname on Windows In-Reply-To: <1422312236.18.0.216782202017.issue23327@psf.upfronthosting.co.za> Message-ID: <1422312939.41.0.966034701686.issue23327@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't understand the issue: does it only concern the name of the ZIP file? Or also paths inside the ZIP? In both cases, the workaround is to use only ASCII names. I spent a lot of times on supporting any Unicode name, everyone in Python. I didn't expect that people have so different and crazy use cases :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 00:00:04 2015 From: report at bugs.python.org (Carol Willing) Date: Mon, 26 Jan 2015 23:00:04 +0000 Subject: [issue23324] Nonblocking serial io using Arduino and Ubuntu 14.10 (Python 3.4.2) performance slowdown In-Reply-To: <1422304616.63.0.532936343926.issue23324@psf.upfronthosting.co.za> Message-ID: <1422313204.33.0.164089439929.issue23324@psf.upfronthosting.co.za> Carol Willing added the comment: Alan, Thanks for reporting your issue. I have spent some time looking at it, and I have triaged it as best as I am able for the other developers and you. I am editing the issue title for clarity. The issue is related to nonblocking i/o between a 'linux' (Ubuntu 14.10) system and an Arduino and the performance difference of the i/o channel noticed by the user on Python 3.4.2 and 2.7.9. Third party packages (PyMata and pySerial) as well as threading module of CPython are used by the application that was reported in the original issue. Due to hardware constraints, I have not duplicated the issue. I have done some research on the sources used by the application. At the lowest level, i/o between the Arduino and the system is dependent on operating system implementation differences. There are differences between how i/o is implemented by pySerial for different operating systems. Comments in the pySerial source and docs state that nonblocking io and read differ and some functions (such as the nonblocking() method are highlighted as not portable.) There are also comments in the pySerial source code that not all systems support polling properly (presumably at their lower level os code). Though perhaps not directly related (but at least tangentially), this blog post explains some nonblocking differences between Python 3 and Python 2 (the last few paragraphs are most relevant). http://ballingt.com/2014/03/01/nonblocking-stdin-in-python-3.html --------------------------------------------------- Notes from a reverse walkthrough of the source code --------------------------------------------------- In PyMata/examples/digital_analog_io/polling_digital_analog_io.py, analog = board.analog_read(POTENTIOMETER) In PyMata/pymata.py, Python's threading module is imported, and the PyMata class contains the API: data_lock = threading.Lock() is set analog_read(self, pin) method uses the data_lock and returns data value from pymata's command_handler's analog_response_table Pymata's command_handler PyMata/pymata_command_handler.py has the following information in its docstring: There is no blocking in either communications direction. There is blocking when accessing the data tables through the _data_lock The get_analog_response_table method uses the data_lock. PyMata's pymata_serial.py uses pySerial's class serial.Serial to open and initialize a serial port. The following lines are in the __init__ for PyMataSerial class: # without this, running python 3.4 is extremely sluggish if sys.platform == 'linux': # noinspection PyUnresolvedReferences self.arduino.nonblocking() It should be noted that programs using pySerial's nonblocking() method are not portable. The following is the run method for PyMataSerial: def run(self): """ This method continually runs. If an incoming character is available on the serial port it is read and placed on the _command_deque @return: Never Returns """ while not self.is_stopped(): # we can get an OSError: [Errno9] Bad file descriptor when shutting down # just ignore it try: if self.arduino.inWaiting(): c = self.arduino.read() self.command_deque.append(ord(c)) except OSError: pass except IOError: self.stop() self.close() The pySerial inWaiting() method is used to determine whether there are bytes to be read by the read() method. The source for pySerial http://svn.code.sf.net/p/pyserial/code/trunk/pyserial/serial/serialutil.py points out variations between Python 2 and 3 for string vs byte reading. Interestingly, pySerial's Serial class can be assembled in two ways: 1) using pySerial's file-like emulation or 2) using io.RawIOBase. >From http://svn.code.sf.net/p/pyserial/code/trunk/pyserial/serial/serialposix.py, # assemble Serial class with the platform specific implementation and the base # for file-like behavior. for Python 2.6 and newer, that provide the new I/O # library, derive from io.RawIOBase try: import io except ImportError: # classic version with our own file-like emulation class Serial(PosixSerial, FileLike): pass else: # io library present class Serial(PosixSerial, io.RawIOBase): pass class PosixPollSerial(Serial): """\ Poll based read implementation. Not all systems support poll properly. However this one has better handling of errors, such as a device disconnecting while it's in use (e.g. USB-serial unplugged). """ ---------- components: +IO nosy: +willingc title: Python 3.4.2 running slow on Ubuntu 14.10 -> Nonblocking serial io using Arduino and Ubuntu 14.10 (Python 3.4.2) performance slowdown type: -> performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 00:01:39 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Jan 2015 23:01:39 +0000 Subject: [issue23324] Nonblocking serial io using Arduino and Ubuntu 14.10 (Python 3.4.2) performance slowdown In-Reply-To: <1422304616.63.0.532936343926.issue23324@psf.upfronthosting.co.za> Message-ID: <1422313299.52.0.831236214563.issue23324@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 00:12:33 2015 From: report at bugs.python.org (Swapneel Ambre) Date: Mon, 26 Jan 2015 23:12:33 +0000 Subject: [issue23327] zipimport to import from non-ascii pathname on Windows In-Reply-To: <1422312236.18.0.216782202017.issue23327@psf.upfronthosting.co.za> Message-ID: <1422313953.49.0.417461130332.issue23327@psf.upfronthosting.co.za> Swapneel Ambre added the comment: Sorry I was not very clear about the use case. The name of the zipfile or any parent directory name could contain non-ascii characters. Consider a use case where you want to ship some product with third party module shipped as an egg file (say example.egg) along with your product. You don't have control over where the product files gets installed. Someone could install the product files under say C:\?\product_name. So both your product (exe or python files) and the egg files are installed under a path with non-ascii characters in it. Any import statements trying to import modules from the egg file will fail with UnicodeEncodeError as zipimport will try to use PyUnicode_EncodeFSDefault with 'mbcs' encoding on Windows. I hope the use case is clearer now. I do agree that it is a corner case scenario and using ASCII names is a better option :-) I will create a complete patch and sign contributor agreement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 00:22:14 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 26 Jan 2015 23:22:14 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1422314534.74.0.229750193911.issue17911@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > In this view, __traceback__ is primarily about accessing *chained* > tracebacks Please let's not make up sophistic arguments when the only motivation for triples is backwards compatibility of *existing* APIs. Exception triples are an unnecessary bother in Python 3. This new API should accept exception instances primarily. Accepting triples as well is ok but it shouldn't be made the only possibility. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 00:30:57 2015 From: report at bugs.python.org (Robert Collins) Date: Mon, 26 Jan 2015 23:30:57 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1422315057.67.0.99933845598.issue17911@psf.upfronthosting.co.za> Robert Collins added the comment: So its fairly simple IMO: it will be more code, not less, to support the non-triple API, *and* it can be added later, unless we're proposing not to support the triple API at all (which hasn't been proposed AFAICT). To me thats a fairly strong argument for adding non-triple support later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 00:34:01 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 26 Jan 2015 23:34:01 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1422315057.67.0.99933845598.issue17911@psf.upfronthosting.co.za> Message-ID: <54C6CEE6.7050701@free.fr> Antoine Pitrou added the comment: Le 27/01/2015 00:30, Robert Collins a ?crit : > > Robert Collins added the comment: > > So its fairly simple IMO: it will be more code, not less, to support the non-triple API, *and* it can be added later, unless we're proposing not to support the triple API at all (which hasn't been proposed AFAICT). I am proposing it. Passing a single exception instance is the natural way of expressing such an API. Crippling Python 3 APIs for the purpose of backwards compatibility is not ok. Nobody wants to write some_func(exc.__class__, exc, exc.__traceback__) when they could simply write some_func(exc). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 00:40:00 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Jan 2015 23:40:00 +0000 Subject: [issue23327] zipimport to import from non-ascii pathname on Windows In-Reply-To: <1422313953.49.0.417461130332.issue23327@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > I do agree that it is a corner case scenario and using ASCII names is a better option :-) Since the patch is short, I see no problem to fix this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 00:48:17 2015 From: report at bugs.python.org (Robert Collins) Date: Mon, 26 Jan 2015 23:48:17 +0000 Subject: [issue22936] traceback module has no way to show locals In-Reply-To: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za> Message-ID: <1422316097.57.0.755981265962.issue22936@psf.upfronthosting.co.za> Robert Collins added the comment: First cut implementation. I'm sure there is lots we can add, but this will make things nicer in and of itself. Thanks for the pointer to cgitb, I've skimmed it and its definitely much more comprehensive. I'm not entirely sure about the best way to glue it and the new traceback API together; or even if thats needed. ---------- keywords: +patch Added file: http://bugs.python.org/file37875/issue-22936-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 00:49:17 2015 From: report at bugs.python.org (Neil Girdhar) Date: Mon, 26 Jan 2015 23:49:17 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422316157.05.0.180138162367.issue2292@psf.upfronthosting.co.za> Changes by Neil Girdhar : Added file: http://bugs.python.org/file37876/starunpack22.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 00:53:20 2015 From: report at bugs.python.org (Neil Girdhar) Date: Mon, 26 Jan 2015 23:53:20 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422316400.18.0.785288828678.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Everything seems to work except two tests are still failing: parser and venv. Any ideas Joshua? Also, we have to decide what to do with f(*x for x in l) and f(**x for x in l). ---------- Added file: http://bugs.python.org/file37877/starunpack23.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 01:53:06 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 27 Jan 2015 00:53:06 +0000 Subject: [issue23286] A typo in the tutorial In-Reply-To: <1421795362.32.0.373442891805.issue23286@psf.upfronthosting.co.za> Message-ID: <20150127005227.74305.57204@psf.io> Roundup Robot added the comment: New changeset b3f0d7f50544 by Berker Peksag in branch '3.4': Issue #23286: Fix typo in the tutorial. https://hg.python.org/cpython/rev/b3f0d7f50544 New changeset 8cb151ff1575 by Berker Peksag in branch 'default': Issue #23286: Fix typo in the tutorial. https://hg.python.org/cpython/rev/8cb151ff1575 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 01:54:20 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 27 Jan 2015 00:54:20 +0000 Subject: [issue23286] A typo in the tutorial In-Reply-To: <1421795362.32.0.373442891805.issue23286@psf.upfronthosting.co.za> Message-ID: <1422320060.8.0.104779163181.issue23286@psf.upfronthosting.co.za> Berker Peksag added the comment: Fixed. Thanks for the patch! ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 01:59:01 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 27 Jan 2015 00:59:01 +0000 Subject: [issue5309] distutils doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <20150127005853.74291.56286@psf.io> Roundup Robot added the comment: New changeset 107669985805 by Berker Peksag in branch 'default': Add whatsnew entry for issue #5309. https://hg.python.org/cpython/rev/107669985805 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 02:05:46 2015 From: report at bugs.python.org (Robert Collins) Date: Tue, 27 Jan 2015 01:05:46 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1422320746.46.0.0413011852484.issue17911@psf.upfronthosting.co.za> Robert Collins added the comment: Why do you consider it crippling? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 03:19:11 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 27 Jan 2015 02:19:11 +0000 Subject: [issue22671] Typo in class io.BufferedIOBase docs In-Reply-To: <1413711352.27.0.0253692424247.issue22671@psf.upfronthosting.co.za> Message-ID: <1422325151.86.0.670211999306.issue22671@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 03:42:23 2015 From: report at bugs.python.org (Vipul Sharma) Date: Tue, 27 Jan 2015 02:42:23 +0000 Subject: [issue23322] parser module docs missing second example In-Reply-To: <1422257477.04.0.712021667077.issue23322@psf.upfronthosting.co.za> Message-ID: <1422326543.02.0.360148051089.issue23322@psf.upfronthosting.co.za> Vipul Sharma added the comment: Can I work on this ? This would be my first contribution here also it looks good for a beginner ---------- nosy: +Vipul.Sharma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 03:48:36 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 27 Jan 2015 02:48:36 +0000 Subject: [issue23322] parser module docs missing second example In-Reply-To: <1422257477.04.0.712021667077.issue23322@psf.upfronthosting.co.za> Message-ID: <1422326916.39.0.559039444298.issue23322@psf.upfronthosting.co.za> Berker Peksag added the comment: Welcome, please go ahead and send a patch. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 06:33:58 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 27 Jan 2015 05:33:58 +0000 Subject: [issue23269] Tighten-up search loops in sets In-Reply-To: <1421658942.27.0.429398283891.issue23269@psf.upfronthosting.co.za> Message-ID: <20150127053355.29566.76592@psf.io> Roundup Robot added the comment: New changeset 0b2a3d764e63 by Raymond Hettinger in branch 'default': Issue #23269: Tighten search_loop in set_insert_clean() https://hg.python.org/cpython/rev/0b2a3d764e63 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 06:35:28 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 27 Jan 2015 05:35:28 +0000 Subject: [issue23269] Tighten-up search loops in sets In-Reply-To: <1421658942.27.0.429398283891.issue23269@psf.upfronthosting.co.za> Message-ID: <1422336928.69.0.352917415575.issue23269@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Applied Sirhiy's version of the patch but may switch to the j=0 version later. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 08:03:55 2015 From: report at bugs.python.org (Andy Reitz) Date: Tue, 27 Jan 2015 07:03:55 +0000 Subject: [issue23328] urllib2 fails for proxy credentials that contain a '/' character Message-ID: <1422342235.17.0.905041944591.issue23328@psf.upfronthosting.co.za> New submission from Andy Reitz: On Python 2.7.9, if I set an https_proxy environment variable, where the password contains a '/' character, urllib2 fails. Given this test code: import os, urllib os.environ['http_proxy'] = "http://someuser:a/b at 10.11.12.13:1234" f = urllib.urlopen('http://www.python.org') data = f.read() print data I expect this error message (because my sample proxy is totally bogus): [areitz at SOMEHOST ~]$ python2.7 test.py Traceback (most recent call last): File "test.py", line 3, in f = urllib.urlopen('http://www.python.org') File "/usr/lib64/python2.7/urllib.py", line 87, in urlopen return opener.open(url) File "/usr/lib64/python2.7/urllib.py", line 213, in open return getattr(self, name)(url) File "/usr/lib64/python2.7/urllib.py", line 350, in open_http h.endheaders(data) File "/usr/lib64/python2.7/httplib.py", line 997, in endheaders self._send_output(message_body) File "/usr/lib64/python2.7/httplib.py", line 850, in _send_output self.send(msg) File "/usr/lib64/python2.7/httplib.py", line 812, in send self.connect() File "/usr/lib64/python2.7/httplib.py", line 793, in connect self.timeout, self.source_address) File "/usr/lib64/python2.7/socket.py", line 571, in create_connection raise err IOError: [Errno socket error] [Errno 101] Network is unreachable Instead, I receive this error: [areitz at SOMEHOST ~]$ python2.7 test.py Traceback (most recent call last): File "test.py", line 3, in f = urllib.urlopen('http://www.python.org') File "/usr/lib64/python2.7/urllib.py", line 87, in urlopen return opener.open(url) File "/usr/lib64/python2.7/urllib.py", line 213, in open return getattr(self, name)(url) File "/usr/lib64/python2.7/urllib.py", line 339, in open_http h = httplib.HTTP(host) File "/usr/lib64/python2.7/httplib.py", line 1107, in __init__ self._setup(self._connection_class(host, port, strict)) File "/usr/lib64/python2.7/httplib.py", line 712, in __init__ (self.host, self.port) = self._get_hostport(host, port) File "/usr/lib64/python2.7/httplib.py", line 754, in _get_hostport raise InvalidURL("nonnumeric port: '%s'" % host[i+1:]) httplib.InvalidURL: nonnumeric port: 'a' Note that from the error, it seems as if urllib2 is incorrectly parsing the password from the proxy URL. When trying this with curl 7.19.7, I see the proper behavior (the correct password is parsed from the proxy URL). ---------- components: Library (Lib) messages: 234809 nosy: Andy.Reitz priority: normal severity: normal status: open title: urllib2 fails for proxy credentials that contain a '/' character type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 08:28:54 2015 From: report at bugs.python.org (Andy Reitz) Date: Tue, 27 Jan 2015 07:28:54 +0000 Subject: [issue23328] urllib2 fails for proxy credentials that contain a '/' character In-Reply-To: <1422342235.17.0.905041944591.issue23328@psf.upfronthosting.co.za> Message-ID: <1422343734.6.0.160635284649.issue23328@psf.upfronthosting.co.za> Andy Reitz added the comment: Sorry, went a bit too quickly -- here is the sample code that I meant to use: import os, urllib2 os.environ['http_proxy'] = "http://someuser:a/b at 10.11.12.13:1234" f = urllib2.urlopen('http://www.python.org') data = f.read() print data And the stack trace that I receive: Traceback (most recent call last): File "test.py", line 3, in f = urllib2.urlopen('http://www.python.org') File "/usr/lib64/python2.7/urllib2.py", line 154, in urlopen return opener.open(url, data, timeout) File "/usr/lib64/python2.7/urllib2.py", line 431, in open response = self._open(req, data) File "/usr/lib64/python2.7/urllib2.py", line 449, in _open '_open', req) File "/usr/lib64/python2.7/urllib2.py", line 409, in _call_chain result = func(*args) File "/usr/lib64/python2.7/urllib2.py", line 1227, in http_open return self.do_open(httplib.HTTPConnection, req) File "/usr/lib64/python2.7/urllib2.py", line 1166, in do_open h = http_class(host, timeout=req.timeout, **http_conn_args) File "/usr/lib64/python2.7/httplib.py", line 712, in __init__ (self.host, self.port) = self._get_hostport(host, port) File "/usr/lib64/python2.7/httplib.py", line 754, in _get_hostport raise InvalidURL("nonnumeric port: '%s'" % host[i+1:]) httplib.InvalidURL: nonnumeric port: 'a' It actually looks the same -- so I suppose this issue affects both urllib and urllib2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 09:06:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 27 Jan 2015 08:06:16 +0000 Subject: [issue23290] Faster set copying In-Reply-To: <1421848208.43.0.905402107396.issue23290@psf.upfronthosting.co.za> Message-ID: <1422345976.47.0.454402844301.issue23290@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Actually set_find_free_slot() is not needed because there is set_insert_clean(). Results with using set_insert_clean(): $ ./python -m timeit -s "s = set(range(10**4))" -- "frozenset(s)" Unpatched: 1000 loops, best of 3: 700 usec per loop Patched: 1000 loops, best of 3: 570 usec per loop Speed up: 23% $ ./python -m timeit -s "s = {i+(j<<64) for i in range(10**4//2) for j in range(2)}" -- "frozenset(s)" Unpatched: 100 loops, best of 3: 2.2 msec per loop Patched: 1000 loops, best of 3: 765 usec per loop Speed up: 188% $ ./python -m timeit -s "s = set(range(10**4)); s.add(-1); s.discard(-1)" -- "frozenset(s)" Unpatched: 1000 loops, best of 3: 700 usec per loop Patched: 1000 loops, best of 3: 605 usec per loop Speed up: 16% $ ./python -m timeit -s "s = {i+(j<<64) for i in range(10**4//2) for j in range(2)}; s.add(-1); s.discard(-1)" -- "frozenset(s)" Unpatched: 100 loops, best of 3: 2.2 msec per loop Patched: 1000 loops, best of 3: 1.06 msec per loop Speed up: 108% Note that unpatched version is 6% slower now than before, perhaps due to issue23119. ---------- Added file: http://bugs.python.org/file37878/set_faster_copy_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 09:33:03 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 27 Jan 2015 08:33:03 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1422347583.36.0.452149103553.issue17911@psf.upfronthosting.co.za> Antoine Pitrou added the comment: It's tedious and complicated compared to the natural way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 09:54:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 27 Jan 2015 08:54:56 +0000 Subject: [issue22286] Allow backslashreplace error handler to be used on input In-Reply-To: <1409136620.65.0.397738586583.issue22286@psf.upfronthosting.co.za> Message-ID: <1422348896.11.0.0304366448549.issue22286@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 09:56:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 27 Jan 2015 08:56:11 +0000 Subject: [issue18518] return-ing within code timed with timeit.timeit causes wrong return value of timeit.timeit In-Reply-To: <1374400020.0.0.45788018989.issue18518@psf.upfronthosting.co.za> Message-ID: <1422348971.12.0.24814787924.issue18518@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 10:26:05 2015 From: report at bugs.python.org (Matej Cepl) Date: Tue, 27 Jan 2015 09:26:05 +0000 Subject: [issue14465] xml.etree.ElementTree: add feature to prettify XML output In-Reply-To: <1333294084.01.0.984287406664.issue14465@psf.upfronthosting.co.za> Message-ID: <1422350765.48.0.445478273527.issue14465@psf.upfronthosting.co.za> Changes by Matej Cepl : ---------- nosy: +mcepl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 10:27:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 27 Jan 2015 09:27:44 +0000 Subject: [issue23191] fnmatch regex cache use is not threadsafe In-Reply-To: <1420722137.58.0.63717437035.issue23191@psf.upfronthosting.co.za> Message-ID: <1422350864.12.0.0624333828871.issue23191@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 10:41:42 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 27 Jan 2015 09:41:42 +0000 Subject: [issue23191] fnmatch regex cache use is not threadsafe In-Reply-To: <1420722137.58.0.63717437035.issue23191@psf.upfronthosting.co.za> Message-ID: <20150127094133.29588.30916@psf.io> Roundup Robot added the comment: New changeset fe12c34c39eb by Serhiy Storchaka in branch '2.7': Issue #23191: fnmatch functions that use caching are now threadsafe. https://hg.python.org/cpython/rev/fe12c34c39eb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 10:42:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 27 Jan 2015 09:42:51 +0000 Subject: [issue23191] fnmatch regex cache use is not threadsafe In-Reply-To: <1420722137.58.0.63717437035.issue23191@psf.upfronthosting.co.za> Message-ID: <1422351771.39.0.874487855027.issue23191@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 11:14:52 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 27 Jan 2015 10:14:52 +0000 Subject: [issue23329] _ssl cannot be compiled with LibreSSL anymore (on OpenBSD 5.5) because of ALPN Message-ID: <1422353692.3.0.280216678648.issue23329@psf.upfronthosting.co.za> New submission from STINNER Victor: Recently, the issue #20188 "ALPN support for TLS" was fixed. The problem is that the check for the ALPN feature doesn't work with LibreSSL: /* ALPN added in OpenSSL 1.0.2 */ #if OPENSSL_VERSION_NUMBER >= 0x1000200fL && !defined(OPENSSL_NO_TLSEXT) # define HAVE_ALPN #endif On the buildbot OpenBSD 5.5 with LibreSSL, OPENSSL_VERSION_NUMBER is 2.x instead of 1.0.x. See also the issue #23177. A workaround would be to disable the feature if LIBRESSL_VERSION_NUMBER is defined. http://buildbot.python.org/all/builders/x86%20OpenBSD%205.5%203.x/builds/1333/steps/test/logs/stdio using PTY: False running build running build_ext ldd: /usr/lib/libreadline.a: not an ELF executable INFO: Can't locate Tcl/Tk libs and/or headers building '_ssl' extension gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I./Include -I. -IInclude -I/usr/local/include -I/home/python-builds/3.x.borja-openbsd-x86/build/Include -I/home/python-builds/3.x.borja-openbsd-x86/build -c /home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ssl.c -o build/temp.openbsd-5.6-i386-3.5-pydebug/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ssl.o /home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ssl.c: In function 'PySSL_selected_alpn_protocol': /home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ssl.c:1481: warning: implicit declaration of function 'SSL_get0_alpn_selected' /home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ssl.c: In function '_set_alpn_protocols': /home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ssl.c:2404: warning: implicit declaration of function 'SSL_CTX_set_alpn_protos' /home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ssl.c:2406: warning: implicit declaration of function 'SSL_CTX_set_alpn_select_cb' gcc -pthread -shared -fPIC build/temp.openbsd-5.6-i386-3.5-pydebug/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ssl.o -L/usr/local/lib -lssl -lcrypto -o build/lib.openbsd-5.6-i386-3.5-pydebug/_ssl.so building '_ctypes' extension gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -Ibuild/temp.openbsd-5.6-i386-3.5-pydebug/libffi/include -Ibuild/temp.openbsd-5.6-i386-3.5-pydebug/libffi -I/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/home/python-builds/3.x.borja-openbsd-x86/build/Include -I/home/python-builds/3.x.borja-openbsd-x86/build -c /home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/_ctypes.c -o build/temp.openbsd-5.6-i386-3.5-pydebug/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/_ctypes.o -Wall -fexceptions gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -Ibuild/temp.openbsd-5.6-i386-3.5-pydebug/libffi/include -Ibuild/temp.openbsd-5.6-i386-3.5-pydebug/libffi -I/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/home/python-builds/3.x.borja-openbsd-x86/build/Include -I/home/python-builds/3.x.borja-openbsd-x86/build -c /home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/callbacks.c -o build/temp.openbsd-5.6-i386-3.5-pydebug/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/callbacks.o -Wall -fexceptions gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -Ibuild/temp.openbsd-5.6-i386-3.5-pydebug/libffi/include -Ibuild/temp.openbsd-5.6-i386-3.5-pydebug/libffi -I/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/home/python-builds/3.x.borja-openbsd-x86/build/Include -I/home/python-builds/3.x.borja-openbsd-x86/build -c /home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/callproc.c -o build/temp.openbsd-5.6-i386-3.5-pydebug/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/callproc.o -Wall -fexceptions gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -Ibuild/temp.openbsd-5.6-i386-3.5-pydebug/libffi/include -Ibuild/temp.openbsd-5.6-i386-3.5-pydebug/libffi -I/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/home/python-builds/3.x.borja-openbsd-x86/build/Include -I/home/python-builds/3.x.borja-openbsd-x86/build -c /home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/stgdict.c -o build/temp.openbsd-5.6-i386-3.5-pydebug/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/stgdict.o -Wall -fexceptions gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -Ibuild/temp.openbsd-5.6-i386-3.5-pydebug/libffi/include -Ibuild/temp.openbsd-5.6-i386-3.5-pydebug/libffi -I/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/home/python-builds/3.x.borja-openbsd-x86/build/Include -I/home/python-builds/3.x.borja-openbsd-x86/build -c /home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/cfield.c -o build/temp.openbsd-5.6-i386-3.5-pydebug/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/cfield.o -Wall -fexceptions gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -Ibuild/temp.openbsd-5.6-i386-3.5-pydebug/libffi/include -Ibuild/temp.openbsd-5.6-i386-3.5-pydebug/libffi -I/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/home/python-builds/3.x.borja-openbsd-x86/build/Include -I/home/python-builds/3.x.borja-openbsd-x86/build -c /home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/libffi/src/prep_cif.c -o build/temp.openbsd-5.6-i386-3.5-pydebug/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/libffi/src/prep_cif.o -Wall -fexceptions gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -Ibuild/temp.openbsd-5.6-i386-3.5-pydebug/libffi/include -Ibuild/temp.openbsd-5.6-i386-3.5-pydebug/libffi -I/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/home/python-builds/3.x.borja-openbsd-x86/build/Include -I/home/python-builds/3.x.borja-openbsd-x86/build -c /home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/libffi/src/closures.c -o build/temp.openbsd-5.6-i386-3.5-pydebug/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/libffi/src/closures.o -Wall -fexceptions gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -Ibuild/temp.openbsd-5.6-i386-3.5-pydebug/libffi/include -Ibuild/temp.openbsd-5.6-i386-3.5-pydebug/libffi -I/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/home/python-builds/3.x.borja-openbsd-x86/build/Include -I/home/python-builds/3.x.borja-openbsd-x86/build -c /home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/libffi/src/x86/ffi.c -o build/temp.openbsd-5.6-i386-3.5-pydebug/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/libffi/src/x86/ffi.o -Wall -fexceptions gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -Ibuild/temp.openbsd-5.6-i386-3.5-pydebug/libffi/include -Ibuild/temp.openbsd-5.6-i386-3.5-pydebug/libffi -I/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/libffi/src -I./Include -I. -IInclude -I/usr/local/include -I/home/python-builds/3.x.borja-openbsd-x86/build/Include -I/home/python-builds/3.x.borja-openbsd-x86/build -c /home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/libffi/src/x86/freebsd.S -o build/temp.openbsd-5.6-i386-3.5-pydebug/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/libffi/src/x86/freebsd.o -Wall -fexceptions gcc -pthread -shared -fPIC build/temp.openbsd-5.6-i386-3.5-pydebug/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/_ctypes.o build/temp.openbsd-5.6-i386-3.5-pydebug/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/callbacks.o build/temp.openbsd-5.6-i386-3.5-pydebug/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/callproc.o build/temp.openbsd-5.6-i386-3.5-pydebug/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/stgdict.o build/temp.openbsd-5.6-i386-3.5-pydebug/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/cfield.o build/temp.openbsd-5.6-i386-3.5-pydebug/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/libffi/src/prep_cif.o build/temp.openbsd-5.6-i386-3.5-pydebug/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/libffi/src/closures.o build/temp.openbsd-5.6-i386-3.5-pydebug/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.openbsd-5.6-i386-3.5-pydebug/home/python-builds/3.x.borja-openbsd-x86/build/Modules/_ctypes/libffi/src/x86/freebsd.o -L/usr/local/lib -o build/lib.openbsd-5.6-i386-3.5-pydebug/_ctypes.so ./python:build/lib.openbsd-5.6-i386-3.5-pydebug/_ssl.so: undefined symbol 'SSL_CTX_set_alpn_protos' ./python:build/lib.openbsd-5.6-i386-3.5-pydebug/_ssl.so: undefined symbol 'SSL_get0_alpn_selected' ./python:build/lib.openbsd-5.6-i386-3.5-pydebug/_ssl.so: undefined symbol 'SSL_CTX_set_alpn_select_cb' *** WARNING: renaming "_ssl" since importing it failed: Cannot load specified object ./python:build/lib.openbsd-5.6-i386-3.5-pydebug/_ctypes.so: undefined symbol 'ffi_call_win32' *** WARNING: renaming "_ctypes" since importing it failed: Cannot load specified object Python build finished successfully! The necessary bits to build these optional modules were not found: _tkinter ossaudiodev spwd To find the necessary bits, look in setup.py in detect_modules() for the module's name. Following modules built successfully but were removed because they could not be imported: _ctypes _ssl ---------- components: Extension Modules messages: 234814 nosy: haypo, rpointel, spil priority: normal severity: normal status: open title: _ssl cannot be compiled with LibreSSL anymore (on OpenBSD 5.5) because of ALPN type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 11:15:51 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 27 Jan 2015 10:15:51 +0000 Subject: [issue23177] test_ssl: failures on OpenBSD with LibreSSL In-Reply-To: <1420541656.17.0.750310163886.issue23177@psf.upfronthosting.co.za> Message-ID: <1422353751.89.0.796761121298.issue23177@psf.upfronthosting.co.za> STINNER Victor added the comment: _ssl cannot be compiled with LibreSSL anymore (on OpenBSD 5.5) because of ALPN: see issue #23329. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 11:16:13 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 27 Jan 2015 10:16:13 +0000 Subject: [issue20188] ALPN support for TLS In-Reply-To: <1389153179.88.0.510995543218.issue20188@psf.upfronthosting.co.za> Message-ID: <1422353773.21.0.458179875901.issue20188@psf.upfronthosting.co.za> STINNER Victor added the comment: _ssl cannot be compiled with LibreSSL anymore (on OpenBSD 5.5) because of ALPN: see issue #23329. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 11:23:02 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 27 Jan 2015 10:23:02 +0000 Subject: [issue14465] xml.etree.ElementTree: add feature to prettify XML output In-Reply-To: <1333294084.01.0.984287406664.issue14465@psf.upfronthosting.co.za> Message-ID: <1422354182.29.0.948029729642.issue14465@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 11:50:26 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 27 Jan 2015 10:50:26 +0000 Subject: [issue23329] _ssl cannot be compiled with LibreSSL anymore (on OpenBSD 5.5) because of ALPN In-Reply-To: <1422353692.3.0.280216678648.issue23329@psf.upfronthosting.co.za> Message-ID: <1422355826.44.0.786433816642.issue23329@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 12:13:17 2015 From: report at bugs.python.org (Thomas Roos) Date: Tue, 27 Jan 2015 11:13:17 +0000 Subject: [issue23330] h2py.py regular expression missing Message-ID: <1422357197.95.0.836847227653.issue23330@psf.upfronthosting.co.za> New submission from Thomas Roos: Hi, my issue was that SO_BINDTODEVICE symbol was not defined in /Lib/plat-linux2/IN.py which is generated by h2py.py. This is because the regex is missing out include dirs with "-" in the name. In my yocto cross build system this define is in asm-generic, don't know about other build systems. .../usr/include/asm-generic/socket.h:#define SO_BINDTODEVICE 25 so could you please change following regex in h2py.py (patch attached) -p_include = re.compile('^[\t ]*#[\t ]*include[\t ]+<([a-zA-Z0-9_/\.]+)') +p_include = re.compile('^[\t ]*#[\t ]*include[\t ]+<([a-zA-Z0-9_/\.-]+)') ---------- components: Cross-Build files: IN.py.patch keywords: patch messages: 234817 nosy: Thomas.Roos priority: normal severity: normal status: open title: h2py.py regular expression missing type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file37879/IN.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 13:30:53 2015 From: report at bugs.python.org (Vipul Sharma) Date: Tue, 27 Jan 2015 12:30:53 +0000 Subject: [issue23322] parser module docs missing second example In-Reply-To: <1422257477.04.0.712021667077.issue23322@psf.upfronthosting.co.za> Message-ID: <1422361853.24.0.317438653434.issue23322@psf.upfronthosting.co.za> Vipul Sharma added the comment: Should I just remove the "See also" segment or just update its content like "See also: module parser.. Provides an interface to Python?s internal parser and byte-code compiler" ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 14:09:19 2015 From: report at bugs.python.org (Isaac Jurado) Date: Tue, 27 Jan 2015 13:09:19 +0000 Subject: [issue23331] Add non-interactive version of Bdb.runcall Message-ID: <1422364159.49.0.0950037579412.issue23331@psf.upfronthosting.co.za> New submission from Isaac Jurado: The Bdb.runcall method shows a prompt right at the beginning of the function. If breakpoints are defined, it is sometimes handy to skip the prompt until the next breakpoint, if any. This use case came up in our development environment for a Django application, from where we needed to set breakpoints only for certain request, allowing other request to run without interruption. Our solution was to wrap with a WSGI middleware, something like this: import sys from bdb import BdbQuit from pdb import Pdb class DebuggingMiddleware(object): def __init__(self, app): self.aplicacion = app self.debugger = Pdb() our_setup_breakpoints_function(self.debugger) def __call__(self, environ, start_response): environ['DEBUGGER'] = self.debugger frame = sys._getframe() self.debugger.reset() frame.f_trace = self.debugger.trace_dispatch self.debugger.botframe = frame self.debugger._set_stopinfo(frame, None, -1) sys.settrace(self.debugger.trace_dispatch) try: return self.aplicacion(environ, start_response) except BdbQuit: pass # Return None implicitly finally: self.debugger.quitting = 1 sys.settrace(None) As you can see, it is basically a mix of Bdb.set_trace and Bdb.set_continue which we came up by trial and error. If there was something like Bdb.runcall_no_prompt or an extra flag to Bdb.runcall to trigger this behaviour, this copy and paste would not be necessary. ---------- components: Library (Lib) messages: 234819 nosy: etanol priority: normal severity: normal status: open title: Add non-interactive version of Bdb.runcall type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 14:23:04 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 27 Jan 2015 13:23:04 +0000 Subject: [issue17911] traceback: add a new thin class storing a traceback without storing local variables In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1422364984.09.0.397768580574.issue17911@psf.upfronthosting.co.za> Nick Coghlan added the comment: Most of the time when I'm working heavily with exceptions it's something related to contextlib, so I'm likely getting my exception details from either sys.exc_info() or the arguments to __exit__. That means I start out with an exception triple, and the only time I need to look at type(exc) or exc.__traceback__ is when I'm following exception chains. However, Antoine's right that if you got your exception from an *except clause* rather than one of the more indirect APIs, then you're just going to have the exception, rather than an exception triple. So I think that's where the argument for accepting "exception-or-triple" comes from: handling an exception directly is for use with except clauses, while handling triples is convenient for use with sys.exc_info(), __exit__ methods and for general backwards compatibility. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 15:50:51 2015 From: report at bugs.python.org (Alan Yorinks) Date: Tue, 27 Jan 2015 14:50:51 +0000 Subject: [issue23324] Nonblocking serial io using Arduino and Ubuntu 14.10 (Python 3.4.2) performance slowdown In-Reply-To: <1422304616.63.0.532936343926.issue23324@psf.upfronthosting.co.za> Message-ID: <1422370251.12.0.328255867181.issue23324@psf.upfronthosting.co.za> Alan Yorinks added the comment: Additional information: When using another example from PyMata, examples/digital_analog_io/callback_digital_analog_io.py, by adding the line: if sys.platform == 'linux': # noinspection PyUnresolvedReferences self.arduino.nonblocking() Allowed the program to run without much noticeable lag. This program is a lot less io intensive. Also, setting the pyserial init option, writeTimeout, did not seem to affect performance when running either test program. I have run cProfile and ran the output through pyprof2calltree for the polling_digital_analog_io.py example. I am attaching the result of pyprof2calltree to a file called 3. I will provide a similar file for the run with python 2.7.8 in an addtional comment (I can't attach more than 1 file per comment). ---------- Added file: http://bugs.python.org/file37880/3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 16:06:18 2015 From: report at bugs.python.org (Alan Yorinks) Date: Tue, 27 Jan 2015 15:06:18 +0000 Subject: [issue23324] Nonblocking serial io using Arduino and Ubuntu 14.10 (Python 3.4.2) performance slowdown In-Reply-To: <1422304616.63.0.532936343926.issue23324@psf.upfronthosting.co.za> Message-ID: <1422371178.18.0.150301378057.issue23324@psf.upfronthosting.co.za> Alan Yorinks added the comment: I don't see the file I attached in the previous comment, so I have uploaded 4 files to google drive at: https://drive.google.com/folderview?id=0B0adDMMjxksDRGtiWFowVUh0RlE&usp=sharing These files are the result of running a cProfile for polling_digital_analog_io.py through pyprof2calltree. The file "2" is for python 2.7.8 and "3" is for python 3.4.2 They can be viewed using kcachegrind. I have also included "2c" and "3c" for the results of running callback_digital_analog_io.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 16:22:45 2015 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 27 Jan 2015 15:22:45 +0000 Subject: [issue23328] urllib2 fails for proxy credentials that contain a '/' character In-Reply-To: <1422342235.17.0.905041944591.issue23328@psf.upfronthosting.co.za> Message-ID: <1422372165.92.0.952935884544.issue23328@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Yup, can confirm that this is problem. As Andy recognized, there is parsing error that fails on '/' character in the password. The environ based proxies are used by urllib rather than urllib2. (The test case if relies on environ proxy, should use urllib.urlopen()), but the failure is coming from parsing done in httplib, so it affects both urllib and urllib2. ---------- assignee: -> orsenthil nosy: +orsenthil stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 17:02:42 2015 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Tue, 27 Jan 2015 16:02:42 +0000 Subject: [issue23232] 'codecs' module functionality + its docs -- concerning custom codecs, especially non-string ones In-Reply-To: <1421161467.08.0.0207328104239.issue23232@psf.upfronthosting.co.za> Message-ID: <1422374562.78.0.603213357087.issue23232@psf.upfronthosting.co.za> Walter D?rwald added the comment: That analysis seems correct to me. Stateless and stream codecs were the original implementation. 2006 I implemented incremental codecs: http://bugs.python.org/issue1436130 The intent was to have stateful codecs that can work with iterators and generators. When Guido began reimplementing the io machinery for Python 3 he used incremental codecs as the basis. ---------- nosy: +doerwalter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 17:10:42 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 27 Jan 2015 16:10:42 +0000 Subject: [issue23329] _ssl cannot be compiled with LibreSSL anymore (on OpenBSD 5.5) because of ALPN In-Reply-To: <1422353692.3.0.280216678648.issue23329@psf.upfronthosting.co.za> Message-ID: <20150127161029.74295.8898@psf.io> Roundup Robot added the comment: New changeset 53e94a687570 by Benjamin Peterson in branch 'default': disable ALPN on LibreSSL, which has a large version number, but not ALPN support (closes #23329) https://hg.python.org/cpython/rev/53e94a687570 New changeset f7fd2776e80d by Benjamin Peterson in branch '2.7': disable ALPN on LibreSSL, which has a large version number, but not ALPN support (closes #23329) https://hg.python.org/cpython/rev/f7fd2776e80d ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 17:16:56 2015 From: report at bugs.python.org (Stefan Krah) Date: Tue, 27 Jan 2015 16:16:56 +0000 Subject: [issue22668] memoryview.format is corrupted due to dangling shared pointer In-Reply-To: <1413670433.7.0.452107994688.issue22668@psf.upfronthosting.co.za> Message-ID: <1422375416.71.0.4319270003.issue22668@psf.upfronthosting.co.za> Stefan Krah added the comment: Thanks for the detailed report! Making a private copy of 'format' for each memoryview generally sounds like the best solution. However, format strings can be arbitrarily large, so we'd need to store the copy in the ob_array after shape, strides and suboffsets. This of course would slow down memoryview creation in the general case. Given that the disappearing format strings are only created during casting, I think we can get away with a local solution (see patch). ---------- Added file: http://bugs.python.org/file37881/issue22668-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 17:38:15 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 27 Jan 2015 16:38:15 +0000 Subject: [issue23329] _ssl cannot be compiled with LibreSSL anymore (on OpenBSD 5.5) because of ALPN In-Reply-To: <1422353692.3.0.280216678648.issue23329@psf.upfronthosting.co.za> Message-ID: <1422376695.04.0.250658178812.issue23329@psf.upfronthosting.co.za> STINNER Victor added the comment: Cool, the issue looks like the issue has been fixed: the _ssl module can be build again. http://buildbot.python.org/all/builders/x86%20OpenBSD%205.5%203.x/builds/1334/steps/compile/logs/stdio Thanks for the quick fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 17:56:09 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 27 Jan 2015 16:56:09 +0000 Subject: [issue23329] _ssl cannot be compiled with LibreSSL anymore (on OpenBSD 5.5) because of ALPN In-Reply-To: <1422353692.3.0.280216678648.issue23329@psf.upfronthosting.co.za> Message-ID: <1422377769.66.0.535154579329.issue23329@psf.upfronthosting.co.za> Benjamin Peterson added the comment: (Thanks for pointing out the problem and the fix.) ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 18:37:29 2015 From: report at bugs.python.org (Mirko Vogt) Date: Tue, 27 Jan 2015 17:37:29 +0000 Subject: [issue23332] datetime.isoformat() -> explicitly mark UTC string as such Message-ID: <1422380249.92.0.118157289878.issue23332@psf.upfronthosting.co.za> New submission from Mirko Vogt: I trapped into a pitfall today with web programming using DateTime.isoformat() in the backend and Javascript on the frontend side. isoformat() string'yfies a DateTime-object according to ISO 8601, which states that, if no timezone is specified, the string is supposed to be interpreted as UTC implicitly. isoformat() doesn't append any TZ if the object is UTC - so far so good. However when interacting with JavaScript that leads to errors, as the ECMAScript ed 6 draft states (and most browser act like that): "date time strings without a time zone are to be treated as local, not UTC)."[1] That is not Python's fault - however considering the issues this behaviour could cause as well as following the philosophy 'explicit is better than implicit', I'd suggest explicitly marking UTC-strings as such by adding a trailing 'Z'. According ISO 8601 that is totally fine, optional though. [1]https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse ---------- messages: 234829 nosy: mirkovogt priority: normal severity: normal status: open title: datetime.isoformat() -> explicitly mark UTC string as such type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 18:47:25 2015 From: report at bugs.python.org (Ent) Date: Tue, 27 Jan 2015 17:47:25 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1422380845.58.0.383273057023.issue23255@psf.upfronthosting.co.za> Ent added the comment: Latest patch with simpler(?) logic? @Demian: This is a tough task! And I appreciate your kind words. I have gone through your comments and I have made a few changes as per your suggestion but I have refrained from a few as well. > get_status_type, apply_success_headers, apply_headers The reason I wrote these three methods is that when a new dev wants to try out the library, he shouldn't have to handcode all the boilerplate. It makes no sense to to re-write this part of code for each new implementation. It can always be overwritten when required and it follows existing functionality. But I understand your idea of what should be part of Public API and I have changed the access levels of most of such methods to class methods. I have updated `get_status_type` to be of O(1) (hopefully) and removed HTTPStatusType. I think since it is quite easy to overwrite `apply_headers` & `_get_status_type`, the default implementation can be straight up used by anyone with no modification and still yield satisfactory behaviour. As for Doc, I really have no idea how to make it better. Maybe someone else can submit a patch later on? Or if you are fine, I will include your own Doc. Thanks again. ---------- Added file: http://bugs.python.org/file37882/jan27th.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 18:53:59 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 27 Jan 2015 17:53:59 +0000 Subject: [issue23332] datetime.isoformat() -> explicitly mark UTC string as such In-Reply-To: <1422380249.92.0.118157289878.issue23332@psf.upfronthosting.co.za> Message-ID: <1422381239.81.0.759734539458.issue23332@psf.upfronthosting.co.za> R. David Murray added the comment: I wonder what the chances are that doing that would break other software with the opposite assumption (an assumption based on past Python behavior). ---------- nosy: +belopolsky, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 18:57:48 2015 From: report at bugs.python.org (Mirko Vogt) Date: Tue, 27 Jan 2015 17:57:48 +0000 Subject: [issue23332] datetime.isoformat() -> explicitly mark UTC string as such In-Reply-To: <1422380249.92.0.118157289878.issue23332@psf.upfronthosting.co.za> Message-ID: <1422381468.99.0.404445692708.issue23332@psf.upfronthosting.co.za> Mirko Vogt added the comment: Both implementations behave according the standard. If you assume otherwise you violate the standard - as JavaScript does. If that change would break software, that software was broken from the beginning. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 19:22:11 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 27 Jan 2015 18:22:11 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1422382931.4.0.781407159786.issue23255@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the updated patch. I will tweak the docs before I commit the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 19:40:16 2015 From: report at bugs.python.org (Mirko Vogt) Date: Tue, 27 Jan 2015 18:40:16 +0000 Subject: [issue23332] datetime.isoformat() -> explicitly mark UTC string as such In-Reply-To: <1422380249.92.0.118157289878.issue23332@psf.upfronthosting.co.za> Message-ID: <1422384016.54.0.181096103325.issue23332@psf.upfronthosting.co.za> Mirko Vogt added the comment: Actually I'm not sure anymore whether NOT specifying a timezone is valid at all. Even though the Spidermonkey documentation itself states, that it doesn't behave according to the ISO standard, several documents say that specifying the timezone is crucial (either "Z" or "+/-XX:XX"). I also found documents describing the standard which explicitly state that by default the local time is assumed, as JavaScript does. Either way - there's so much different information and therewith confusion out there, that I highly recommend always specifying the timezone and would consider behaving otherwise as a bug. Implementations usually don't throw an error but just assume something when the TZ designator is missing, which results in just different meanings. Needless to say that doesn't make the situation any better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 19:47:49 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 27 Jan 2015 18:47:49 +0000 Subject: [issue23332] datetime.isoformat() -> explicitly mark UTC string as such In-Reply-To: <1422380249.92.0.118157289878.issue23332@psf.upfronthosting.co.za> Message-ID: <1422384469.17.0.980483817752.issue23332@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Do I understand correctly that the request is to append '+00:00' to the result of dt.isoformat() when dt is naive? If so, -1. Python's datetime module does not dictate how naive datetime instances should be interpreted. UTC by default and local by default are both valid choices, but local by default is often preferable. There are at least two reasons for that: 1. Local time is the "na?ve" time. Using UTC implies certain amount of sophistication. 2. Interpreting naive times as UTC is unnecessary because it is very easy to create aware instances with tzinfo=timezone.utc. When communicating with javascript and in general when writing software for the Internet, I recommend using aware datetime instances. For example, >>> from datetime import * >>> datetime.now(timezone.utc).isoformat() '2015-01-27T18:27:33.216857+00:00' ---------- type: behavior -> enhancement versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 19:52:56 2015 From: report at bugs.python.org (Mirko Vogt) Date: Tue, 27 Jan 2015 18:52:56 +0000 Subject: [issue23332] datetime.isoformat() -> explicitly mark UTC string as such In-Reply-To: <1422380249.92.0.118157289878.issue23332@psf.upfronthosting.co.za> Message-ID: <1422384776.25.0.223788854815.issue23332@psf.upfronthosting.co.za> Mirko Vogt added the comment: from datetime import * In [4]: datetime.utcnow().isoformat() Out[4]: '2015-01-27T18:51:18.332566' When using utcnow() e.g. I would expect the result definitely being marked as UTC. ---------- type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 19:56:19 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 27 Jan 2015 18:56:19 +0000 Subject: [issue23332] datetime.isoformat() -> explicitly mark UTC string as such In-Reply-To: <1422380249.92.0.118157289878.issue23332@psf.upfronthosting.co.za> Message-ID: <1422384979.72.0.439774119778.issue23332@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > I highly recommend always specifying the timezone and would consider behaving otherwise as a bug. I agree, and the datetime module lets you do that already: >>> dt = datetime.now(timezone.utc) >>> dt.isoformat() '2015-01-27T18:53:40.380075+00:00' or if you prefer local timezone, >>> dt.astimezone().isoformat() '2015-01-27T13:53:40.380075-05:00' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 20:00:51 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 27 Jan 2015 19:00:51 +0000 Subject: [issue23332] datetime.isoformat() -> explicitly mark UTC string as such In-Reply-To: <1422380249.92.0.118157289878.issue23332@psf.upfronthosting.co.za> Message-ID: <1422385251.05.0.135999078725.issue23332@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > When using utcnow() e.g. I would expect the result definitely being marked as UTC. Don't use utcnow(). This is a leftover from the times when there was no timezone support in datetime. The documentation for utcnow [1] already points you in the right direction, but we can consider formally deprecating it together with utcfromtimestamp. [1] https://docs.python.org/3/library/datetime.html#datetime.datetime.utcnow ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 20:02:28 2015 From: report at bugs.python.org (Mirko Vogt) Date: Tue, 27 Jan 2015 19:02:28 +0000 Subject: [issue23332] datetime.isoformat() -> explicitly mark UTC string as such In-Reply-To: <1422380249.92.0.118157289878.issue23332@psf.upfronthosting.co.za> Message-ID: <1422385348.96.0.540807702998.issue23332@psf.upfronthosting.co.za> Mirko Vogt added the comment: I never said there is no way to result in an ISO 8601 string with UTC stated explicitly. I showed a case where I think it is correct to assume UTC is stated ( e.g. utcnow()), however the result of isoformat() doesn't do so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 20:08:06 2015 From: report at bugs.python.org (Swapneel Ambre) Date: Tue, 27 Jan 2015 19:08:06 +0000 Subject: [issue23327] zipimport to import from non-ascii pathname on Windows In-Reply-To: <1422312236.18.0.216782202017.issue23327@psf.upfronthosting.co.za> Message-ID: <1422385686.38.0.234454891486.issue23327@psf.upfronthosting.co.za> Swapneel Ambre added the comment: Attaching a combined patch. I updated testUnencodable testcase from test_zipimport.py. Verified that without my fix, the testcase fails and it passes with my fix. ---------- Added file: http://bugs.python.org/file37883/zipimport_fix_withtest.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 20:09:44 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 27 Jan 2015 19:09:44 +0000 Subject: [issue23332] datetime.isoformat() -> explicitly mark UTC string as such In-Reply-To: <1422380249.92.0.118157289878.issue23332@psf.upfronthosting.co.za> Message-ID: <1422385784.4.0.283508934565.issue23332@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: What is your specific proposal? As I explained, we cannot assume that naive timezone instances are in UTC because while sometimes they are (as in datetime.utcnow()), more often they are not (as in datetime.now()). So changing dt.isoformat() when dt is naive is wrong. Another alternative would be to return aware instances from utcnow(), but that would break a lot of code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 20:11:06 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 27 Jan 2015 19:11:06 +0000 Subject: [issue23332] datetime.isoformat() -> explicitly mark UTC string as such In-Reply-To: <1422380249.92.0.118157289878.issue23332@psf.upfronthosting.co.za> Message-ID: <1422385866.03.0.116234697641.issue23332@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: s/timezone instances/datetime instances/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 20:20:27 2015 From: report at bugs.python.org (Mirko Vogt) Date: Tue, 27 Jan 2015 19:20:27 +0000 Subject: [issue23332] datetime.isoformat() -> explicitly mark UTC string as such In-Reply-To: <1422380249.92.0.118157289878.issue23332@psf.upfronthosting.co.za> Message-ID: <1422386427.73.0.0681076077935.issue23332@psf.upfronthosting.co.za> Mirko Vogt added the comment: I got that - so marking utcnow() as deprecated seems like a good idea. But it's not just about utcnow() but also now(). now() also doesn't return any timezone stated by default - which I would still consider as a bug. However making now() require a TZ being specified would probably also break a lot of code. But then, using function called isoformat() - on whatever object, naive or not - I'd expect a timezone being specified - since that's what I finally think the ISO-standard actually says. I see that my initial proposal doesn't work out, but I'm still not happy with the current situation I'm however also not sure how to change properly without breaking existing code using those functions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 20:26:18 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 27 Jan 2015 19:26:18 +0000 Subject: [issue23332] datetime.isoformat() -> explicitly mark UTC string as such In-Reply-To: <1422380249.92.0.118157289878.issue23332@psf.upfronthosting.co.za> Message-ID: <1422386778.84.0.464994712236.issue23332@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Mirko, You may want to review #9527. I don't think we left any stone unturned in this area. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 20:32:57 2015 From: report at bugs.python.org (Mirko Vogt) Date: Tue, 27 Jan 2015 19:32:57 +0000 Subject: [issue23332] datetime.isoformat() -> explicitly mark UTC string as such In-Reply-To: <1422380249.92.0.118157289878.issue23332@psf.upfronthosting.co.za> Message-ID: <1422387177.48.0.527694500609.issue23332@psf.upfronthosting.co.za> Mirko Vogt added the comment: Just to clarify my problem - then I'll just happily use datetime.now(tzutc()).isoformat() - There is datetime.now() which is supposed to be used (no utcnow() anymore) - datetime.now() might return a naive object, when no TZ is specified - *However* also the naive variant implements the class isoformat() which is described as "Return a string representing the date in ISO 8601 format" - ISO 8601 can and should be understood such as the TZ-designator is required (I think we agreed on that). - However isoformat() called on a naive object returns a string with no TZ designator I would at least suggesting adding a note for isoformat() about being called on naive datetime objects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 20:40:15 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 27 Jan 2015 19:40:15 +0000 Subject: [issue23055] PyUnicode_FromFormatV crasher In-Reply-To: <1418663915.64.0.885404540917.issue23055@psf.upfronthosting.co.za> Message-ID: <1422387615.42.0.84084115847.issue23055@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Georg, what is your word as release manager of 3.2/3.3? I would commit the patch in 2.7 if there are no objections. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 21:01:25 2015 From: report at bugs.python.org (Georg Brandl) Date: Tue, 27 Jan 2015 20:01:25 +0000 Subject: [issue23055] PyUnicode_FromFormatV crasher In-Reply-To: <1418663915.64.0.885404540917.issue23055@psf.upfronthosting.co.za> Message-ID: <1422388885.38.0.448386127874.issue23055@psf.upfronthosting.co.za> Georg Brandl added the comment: It's fine to commit it to both branches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 21:33:44 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 27 Jan 2015 20:33:44 +0000 Subject: [issue23055] PyUnicode_FromFormatV crasher In-Reply-To: <1418663915.64.0.885404540917.issue23055@psf.upfronthosting.co.za> Message-ID: <20150127203334.126657.39811@psf.io> Roundup Robot added the comment: New changeset e6b9e277fbf4 by Serhiy Storchaka in branch '2.7': Issue #23055: Fixed a buffer overflow in PyUnicode_FromFormatV. Analysis https://hg.python.org/cpython/rev/e6b9e277fbf4 New changeset f849f937f78c by Serhiy Storchaka in branch '3.2': Issue #23055: Fixed a buffer overflow in PyUnicode_FromFormatV. Analysis https://hg.python.org/cpython/rev/f849f937f78c New changeset 6caed177a028 by Serhiy Storchaka in branch '3.3': Issue #23055: Fixed a buffer overflow in PyUnicode_FromFormatV. Analysis https://hg.python.org/cpython/rev/6caed177a028 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 21:36:27 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 27 Jan 2015 20:36:27 +0000 Subject: [issue19949] Explicitly skip or mask skipped/disabled tests in test_xpickle In-Reply-To: <1386696725.08.0.917922388786.issue19949@psf.upfronthosting.co.za> Message-ID: <1422390987.28.0.434907788534.issue19949@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 21:45:41 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 27 Jan 2015 20:45:41 +0000 Subject: [issue19949] Explicitly skip or mask skipped/disabled tests in test_xpickle In-Reply-To: <1386696725.08.0.917922388786.issue19949@psf.upfronthosting.co.za> Message-ID: <20150127204528.126655.16613@psf.io> Roundup Robot added the comment: New changeset 94d8524086bd by Serhiy Storchaka in branch '2.7': Issue #19949: The test_xpickle test now tests compatibility with installed https://hg.python.org/cpython/rev/94d8524086bd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 21:46:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 27 Jan 2015 20:46:13 +0000 Subject: [issue23055] PyUnicode_FromFormatV crasher In-Reply-To: <1418663915.64.0.885404540917.issue23055@psf.upfronthosting.co.za> Message-ID: <1422391573.44.0.411576426465.issue23055@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 21:47:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 27 Jan 2015 20:47:11 +0000 Subject: [issue19949] Explicitly skip or mask skipped/disabled tests in test_xpickle In-Reply-To: <1386696725.08.0.917922388786.issue19949@psf.upfronthosting.co.za> Message-ID: <1422391631.64.0.9560829468.issue19949@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 21:51:47 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 27 Jan 2015 20:51:47 +0000 Subject: [issue11145] '%o' % user-defined instance In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za> Message-ID: <1422391907.3.0.00128566713057.issue11145@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Hey, Armin. Do you want to continue bug hunting? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 21:57:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 27 Jan 2015 20:57:05 +0000 Subject: [issue19681] test_repr (test.test_functools.TestPartialC) failures In-Reply-To: <1385044476.32.0.977131973544.issue19681@psf.upfronthosting.co.za> Message-ID: <1422392225.0.0.788907548729.issue19681@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- keywords: +needs review stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 21:59:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 27 Jan 2015 20:59:00 +0000 Subject: [issue22079] Ensure in PyType_Ready() that base class of static type is static In-Reply-To: <1406378199.04.0.952325428414.issue22079@psf.upfronthosting.co.za> Message-ID: <1422392340.96.0.843498539718.issue22079@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 22:02:13 2015 From: report at bugs.python.org (Hanno Zulla) Date: Tue, 27 Jan 2015 21:02:13 +0000 Subject: [issue2504] Add gettext.pgettext() and variants support In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za> Message-ID: <1422392533.5.0.426250480714.issue2504@psf.upfronthosting.co.za> Hanno Zulla added the comment: Can we please get pgettext for Python? ---------- nosy: +Hanno.Zulla _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 22:13:29 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 27 Jan 2015 21:13:29 +0000 Subject: [issue2504] Add gettext.pgettext() and variants support In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za> Message-ID: <1422393209.59.0.833158679999.issue2504@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 23:09:27 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 27 Jan 2015 22:09:27 +0000 Subject: [issue19681] test_repr (test.test_functools.TestPartialC) failures In-Reply-To: <1385044476.32.0.977131973544.issue19681@psf.upfronthosting.co.za> Message-ID: <1422396567.62.0.907962183929.issue19681@psf.upfronthosting.co.za> Berker Peksag added the comment: issue19681_2.patch LGTM. ---------- nosy: +berker.peksag stage: patch review -> commit review versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 23:17:33 2015 From: report at bugs.python.org (Armin Rigo) Date: Tue, 27 Jan 2015 22:17:33 +0000 Subject: [issue11145] '%o' % user-defined instance In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za> Message-ID: <1422397053.82.0.470562543489.issue11145@psf.upfronthosting.co.za> Armin Rigo added the comment: Sorry, your patch still contains similar issues. I postponed continuing to bounce it back and forth, but it seems that someone else needs to take my place now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 23:39:34 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 27 Jan 2015 22:39:34 +0000 Subject: [issue23333] asyncio: call protocol.connection_lost() when the creation of transport failed Message-ID: <1422398373.98.0.602533535675.issue23333@psf.upfronthosting.co.za> New submission from STINNER Victor: While working on the issue #23243 ("asyncio: emit ResourceWarning warnings if transports/event loops are not explicitly closed"), I saw that SelectorEventLoop._accept_connection() currently ignores errors on the creation of a transport. When a server gets an incoming connection: it calls sock.accept(), creates a protocol, and then create the transport. It doesn't wait until the connection_made() of the protocol is called (until the transport was successfully created). For example, for a SSL server, the client may decide to close the connection because it doesn't trust the server certificate. In this case, the SSL handshake fails at server side. Currently, the user of the asyncio API cannot decide how to handle this failure. I propose to call the connection_lost() method of the protocol with the exception, even if the connection_made() method of the protocol was not called (and will never be called). Attached patch implements this idea. It's a change in the undocumented "state machine" of protocols. Before, it was not possible to switch directly to connection_lost(): there is even an assertion which ensures that it never occurs in some unit tests. A server may log the connection failure, blacklist temporarely the client IP, etc. Problem: Since the protocol doesn't know the transport yet, it doesn't have access to the socket, and so cannot retrieve the IP address of the client. Maybe a new method should be added to protocols to handle this case? How do other event loops (Twisted, eventlet, Tornado, etc.) handle failures on incoming connection? ---------- components: asyncio files: accept_error.patch keywords: patch messages: 234856 nosy: gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio: call protocol.connection_lost() when the creation of transport failed versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37884/accept_error.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 23:41:16 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 27 Jan 2015 22:41:16 +0000 Subject: [issue23333] asyncio: call protocol.connection_lost() when the creation of transport failed In-Reply-To: <1422398373.98.0.602533535675.issue23333@psf.upfronthosting.co.za> Message-ID: <1422398476.1.0.327291922935.issue23333@psf.upfronthosting.co.za> Antoine Pitrou added the comment: IMO, connection_lost() should never be called if connection_made() wasn't called. That's a breach of the API contract. (at one point, I suggested a connection_failed() for that purpose, but it was shut down - it was in relationship to the idea of a reconnecting client, but can still be more broadly useful) ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 23:41:30 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 27 Jan 2015 22:41:30 +0000 Subject: [issue23243] asyncio: emit ResourceWarning warnings if transports/event loops are not explicitly closed In-Reply-To: <1421277484.12.0.751563251482.issue23243@psf.upfronthosting.co.za> Message-ID: <1422398490.76.0.295903792177.issue23243@psf.upfronthosting.co.za> STINNER Victor added the comment: > - SelectorEventLoop._accept_connection() doesn't care of the creation of the transport failed Fixing this issue requires to change the design of asyncio, so I chose to open a new issue: issue #23333. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 23:45:44 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 27 Jan 2015 22:45:44 +0000 Subject: [issue13128] httplib debuglevel on CONNECT doesn't print response headers In-Reply-To: <1318050704.97.0.551622649018.issue13128@psf.upfronthosting.co.za> Message-ID: <1422398744.84.0.535248046554.issue13128@psf.upfronthosting.co.za> Demian Brecht added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 23:47:06 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 27 Jan 2015 22:47:06 +0000 Subject: [issue23333] asyncio: call protocol.connection_lost() when the creation of transport failed In-Reply-To: <1422398476.1.0.327291922935.issue23333@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: FYI I opened a thread about this issue on the Tulip mailing list. Antoine Pitrou added the comment: > IMO, connection_lost() should never be called if connection_made() wasn't called. That's a breach of the API contract. Yes, I agree. > (at one point, I suggested a connection_failed() for that purpose, but it was shut down - it was in relationship to the idea of a reconnecting client, but can still be more broadly useful) I like the "connection_failed" name. We may call protocol.connection_failed(transport), so the protocol gets access to the socket and so to the IP addres. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 27 23:58:23 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 27 Jan 2015 22:58:23 +0000 Subject: [issue13128] httplib debuglevel on CONNECT doesn't print response headers In-Reply-To: <1318050704.97.0.551622649018.issue13128@psf.upfronthosting.co.za> Message-ID: <1422399503.19.0.335348373877.issue13128@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch! Could you revert unrelated changes (whitespaces, PEP 8 etc.) if you have time? ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 00:10:44 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 27 Jan 2015 23:10:44 +0000 Subject: [issue13128] httplib debuglevel on CONNECT doesn't print response headers In-Reply-To: <1422399503.19.0.335348373877.issue13128@psf.upfronthosting.co.za> Message-ID: <54C81AEE.9030108@gmail.com> Demian Brecht added the comment: Sure, I should have some time later today to do so. Should such changes not be made as they're encountered in order to clean up the older code that isn't up to spec? Or should they only be made as the code is modified? On 2015-01-27 2:58 PM, Berker Peksag wrote: > > Berker Peksag added the comment: > > Thanks for the patch! Could you revert unrelated changes (whitespaces, PEP 8 etc.) if you have time? > > ---------- > stage: patch review -> commit review > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 00:21:11 2015 From: report at bugs.python.org (Mayank Tripathi) Date: Tue, 27 Jan 2015 23:21:11 +0000 Subject: [issue21862] cProfile command-line should accept "-m module_name" as an alternative to script path In-Reply-To: <1403640414.18.0.449527177368.issue21862@psf.upfronthosting.co.za> Message-ID: <1422400871.23.0.9971718234.issue21862@psf.upfronthosting.co.za> Mayank Tripathi added the comment: Updated the patch and added docs and tests. ---------- Added file: http://bugs.python.org/file37885/cProfile_module_option_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 00:26:04 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 27 Jan 2015 23:26:04 +0000 Subject: [issue23333] asyncio: call protocol.connection_lost() when the creation of transport failed In-Reply-To: <1422398373.98.0.602533535675.issue23333@psf.upfronthosting.co.za> Message-ID: <1422401164.15.0.145241609657.issue23333@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, accept_error.patch causes issues with the new SSL implementation. SSLProtocol.feed_data() is called before SSLProtocol.connection_made() is called. _SelectorSocketTransport constructor calls loop.add_reader() immediatly, but it only schedules a call to protocol.connection_made() with loop.call_soon(). The call to loop.add_reader() should maybe be scheduled after the call to connection_made()? To ensure that protocol methods (feed_data) are not called before connection_made() has been called. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 00:34:58 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 27 Jan 2015 23:34:58 +0000 Subject: [issue23208] asyncio: add BaseEventLoop._current_handle (only used in debug mode) In-Reply-To: <1420817695.78.0.447471935777.issue23208@psf.upfronthosting.co.za> Message-ID: <20150127233454.130342.16640@psf.io> Roundup Robot added the comment: New changeset d61d1e73674f by Victor Stinner in branch '3.4': asyncio: sync with Tulip https://hg.python.org/cpython/rev/d61d1e73674f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 03:04:58 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 28 Jan 2015 02:04:58 +0000 Subject: [issue23334] http.client refactor Message-ID: <1422410696.55.0.10985599454.issue23334@psf.upfronthosting.co.za> New submission from Demian Brecht: This is an attempt to bring a little more sanity to the http.client module through improvements to the architecture. The overarching intention of the patch is to modularize the HTTP versions, providing the following benefits: * Make each protocol easier to work on independent of one another * Make integrating future versions easier. This is intended as a stepping stone to integrating support for HTTP 2 * Separation of concerns between connection and application protocol Immediate issues that this solves: * Content-Length when a list is passed in. Currently the content length is set to the size of the list rather than the sum of the elements of the list * Provides a little more user-friendly errors when invalid objects are passed in as header values Note: This is still in a WIP progress state but shouldn't take much longer to get into a commit-able state. There's some work to be done on deserialization and it's entirely documentation. However, tests are passing so I figured now would be a good time to get initial feedback on the work. In hindsight, a PEP would likely have been best (it was initially intended to be put into httplib3, but I thought I might as well try it as a patch submission given it's largely backwards compatible). ---------- components: Library (Lib) files: http_proto.patch keywords: patch messages: 234866 nosy: demian.brecht priority: normal severity: normal status: open title: http.client refactor type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file37886/http_proto.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 03:06:28 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 28 Jan 2015 02:06:28 +0000 Subject: [issue23334] http.client refactor In-Reply-To: <1422410696.55.0.10985599454.issue23334@psf.upfronthosting.co.za> Message-ID: <1422410788.21.0.843065442933.issue23334@psf.upfronthosting.co.za> Demian Brecht added the comment: Note that this patch also depends on Antoine's TransformDict patch in #18986. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 03:09:36 2015 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 28 Jan 2015 02:09:36 +0000 Subject: [issue23334] http.client refactor In-Reply-To: <1422410696.55.0.10985599454.issue23334@psf.upfronthosting.co.za> Message-ID: <1422410976.6.0.49983093362.issue23334@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 03:14:44 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 28 Jan 2015 02:14:44 +0000 Subject: [issue23334] http.client refactor In-Reply-To: <1422410696.55.0.10985599454.issue23334@psf.upfronthosting.co.za> Message-ID: <1422411284.28.0.835344570274.issue23334@psf.upfronthosting.co.za> Demian Brecht added the comment: Attaching a file /with/ http.proto this time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 03:22:42 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 28 Jan 2015 02:22:42 +0000 Subject: [issue23334] http.client refactor In-Reply-To: <1422410696.55.0.10985599454.issue23334@psf.upfronthosting.co.za> Message-ID: <1422411762.03.0.762545960787.issue23334@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 03:51:35 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 28 Jan 2015 02:51:35 +0000 Subject: [issue23334] http.client refactor In-Reply-To: <1422410696.55.0.10985599454.issue23334@psf.upfronthosting.co.za> Message-ID: <1422413495.15.0.596690819629.issue23334@psf.upfronthosting.co.za> Changes by Demian Brecht : Added file: http://bugs.python.org/file37887/http_proto_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 03:52:15 2015 From: report at bugs.python.org (Ethan Furman) Date: Wed, 28 Jan 2015 02:52:15 +0000 Subject: [issue23334] http.client refactor In-Reply-To: <1422410696.55.0.10985599454.issue23334@psf.upfronthosting.co.za> Message-ID: <1422413535.8.0.784765324942.issue23334@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 04:14:06 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 28 Jan 2015 03:14:06 +0000 Subject: [issue23334] http.client refactor In-Reply-To: <1422410696.55.0.10985599454.issue23334@psf.upfronthosting.co.za> Message-ID: <1422414846.86.0.135918609947.issue23334@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 04:34:12 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 28 Jan 2015 03:34:12 +0000 Subject: [issue23334] http.client refactor In-Reply-To: <1422410696.55.0.10985599454.issue23334@psf.upfronthosting.co.za> Message-ID: <1422416052.74.0.996047713737.issue23334@psf.upfronthosting.co.za> R. David Murray added the comment: Quantifying "largely" will be important. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 04:38:49 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 28 Jan 2015 03:38:49 +0000 Subject: [issue23152] fstat64 required on Windows In-Reply-To: <1420230232.09.0.10127303351.issue23152@psf.upfronthosting.co.za> Message-ID: <1422416329.06.0.0756010073655.issue23152@psf.upfronthosting.co.za> Steve Dower added the comment: Looks like it was only the _io module needing more updates. New patch attached. ---------- Added file: http://bugs.python.org/file37888/py_fstat_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 05:21:26 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 28 Jan 2015 04:21:26 +0000 Subject: [issue23335] _ssl.c cannot be compiled with older versions of OpenSSL Message-ID: <1422418886.09.0.55350529771.issue23335@psf.upfronthosting.co.za> New submission from Ned Deily: _ssl.c compilation is broken on default and 27 when building with older (pre-1.0.1 ?) versions of OpenSSL: /py/dev/3x/source/Modules/_ssl.c:2296:24: error: use of undeclared identifier 'OPENSSL_NPN_NEGOTIATED' if (alpn && ret != OPENSSL_NPN_NEGOTIATED) The code added by eaa38b75cc78 (default) and 94ec4d8cf104 (2.7) doesn't account for the possibility that NPN is not available. (The Snow Leopard buildbots are down at the moment but I would expect them to be failing with this.) ---------- messages: 234871 nosy: benjamin.peterson, ned.deily priority: critical severity: normal stage: needs patch status: open title: _ssl.c cannot be compiled with older versions of OpenSSL versions: Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 05:22:36 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 28 Jan 2015 04:22:36 +0000 Subject: [issue20188] ALPN support for TLS In-Reply-To: <1389153179.88.0.510995543218.issue20188@psf.upfronthosting.co.za> Message-ID: <1422418956.69.0.133181755243.issue20188@psf.upfronthosting.co.za> Ned Deily added the comment: _ssl.c cannot be compiled with pre-NPN versions of OpenSSL: see Issue23335. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 07:02:27 2015 From: report at bugs.python.org (cindykrafft) Date: Wed, 28 Jan 2015 06:02:27 +0000 Subject: [issue23336] Thread.LockType is misnamed Message-ID: <1422424947.14.0.409463431872.issue23336@psf.upfronthosting.co.za> New submission from cindykrafft: The tp_name field in thread.LockType is set as "thread.lock". This is incorrect and conflicts with the value set in dummy_thread. Python 2.7.6 (default, Sep 9 2014, 15:04:36) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.39)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import thread >>> import dummy_thread >>> thread.LockType.__name__ 'lock' >>> dummy_thread.LockType.__name__ 'LockType' Code which depends on the ability to look up a class based on module and name (see the following code taken from pickle.py) breaks due to this behavior, so my preferred fix would be to change tp_name to a value consistent with dummy_thread. try: __import__(module) mod = sys.modules[module] klass = getattr(mod, name) except (ImportError, KeyError, AttributeError): raise PicklingError( "Can't pickle %r: it's not found as %s.%s" % (obj, module, name)) Happy to submit a patch if someone could confirm. ---------- components: Library (Lib) messages: 234873 nosy: cindykrafft priority: normal severity: normal status: open title: Thread.LockType is misnamed type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 08:53:48 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 28 Jan 2015 07:53:48 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za> Message-ID: <1422431627.99.0.846258759079.issue23285@psf.upfronthosting.co.za> Ned Deily added the comment: I added a few prints to the send and receive loops of _test_send. When running on a reasonably current Debian testing Linux: ./python Lib/test/eintrdata/eintr_tester.py test_read (__main__.OSEINTRTest) ... ok test_wait (__main__.OSEINTRTest) ... ok test_wait3 (__main__.OSEINTRTest) ... ok test_wait4 (__main__.OSEINTRTest) ... ok test_waitpid (__main__.OSEINTRTest) ... ok test_write (__main__.OSEINTRTest) ... ok test_accept (__main__.SocketEINTRTest) ... ok test_recv (__main__.SocketEINTRTest) ... ok test_recvmsg (__main__.SocketEINTRTest) ... ok test_send (__main__.SocketEINTRTest) ... len(data) = 50331651 sent = 183360, written = 183360 sent = 50148291, written = 50331651 chunk = 50331651, total read = 50331651 ok test_sendall (__main__.SocketEINTRTest) ... len(data) = 50331651 chunk = 49323840, total read = 49323840 sent = None, written = 50331651 chunk = 1007811, total read = 50331651 ok test_sendmsg (__main__.SocketEINTRTest) ... len(data) = 50331651 sent = 183360, written = 183360 sent = 50148291, written = 50331651 chunk = 50331651, total read = 50331651 ok ---------------------------------------------------------------------- Ran 12 tests in 10.139s OK When run on OS X (10.10.1): test_read (__main__.OSEINTRTest) ... ok test_wait (__main__.OSEINTRTest) ... ok test_wait3 (__main__.OSEINTRTest) ... ok test_wait4 (__main__.OSEINTRTest) ... ok test_waitpid (__main__.OSEINTRTest) ... ok test_write (__main__.OSEINTRTest) ... ok test_accept (__main__.SocketEINTRTest) ... ok test_recv (__main__.SocketEINTRTest) ... ok test_recvmsg (__main__.SocketEINTRTest) ... ok test_send (__main__.SocketEINTRTest) ... len(data) = 50331651 sent = 8192, written = 8192 chunk = 8192, total read = 8192 chunk = 8192, total read = 16384 sent = 16384, written = 24576 chunk = 8192, total read = 24576 chunk = 8192, total read = 32768 chunk = 8192, total read = 40960 chunk = 8192, total read = 49152 sent = 32768, written = 57344 chunk = 8192, total read = 57344 chunk = 8192, total read = 65536 chunk = 8192, total read = 73728 chunk = 8192, total read = 81920 chunk = 8192, total read = 90112 sent = 40960, written = 98304 chunk = 8192, total read = 98304 chunk = 8192, total read = 106496 chunk = 8192, total read = 114688 chunk = 8192, total read = 122880 sent = 32768, written = 131072 chunk = 8192, total read = 131072 chunk = 8192, total read = 139264 chunk = 8192, total read = 147456 chunk = 8192, total read = 155648 chunk = 8192, total read = 163840 sent = 40960, written = 172032 chunk = 8192, total read = 172032 chunk = 8192, total read = 180224 chunk = 8192, total read = 188416 chunk = 8192, total read = 196608 sent = 32768, written = 204800 chunk = 8192, total read = 204800 chunk = 8192, total read = 212992 chunk = 8192, total read = 221184 chunk = 8192, total read = 229376 chunk = 8192, total read = 237568 sent = 40960, written = 245760 chunk = 8192, total read = 245760 chunk = 8192, total read = 253952 chunk = 8192, total read = 262144 chunk = 8192, total read = 270336 sent = 32768, written = 278528 chunk = 8192, total read = 278528 chunk = 8192, total read = 286720 chunk = 8192, total read = 294912 chunk = 8192, total read = 303104 chunk = 8192, total read = 311296 sent = 40960, written = 319488 [... and so on] When run standalone, the tests do eventually finish without error but take a *long* time to do so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 09:04:35 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 28 Jan 2015 08:04:35 +0000 Subject: [issue23335] _ssl.c cannot be compiled with older versions of OpenSSL In-Reply-To: <1422418886.09.0.55350529771.issue23335@psf.upfronthosting.co.za> Message-ID: <1422432275.45.0.0997383711126.issue23335@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 10:02:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 28 Jan 2015 09:02:09 +0000 Subject: [issue22609] Constructors of some mapping classes don't accept `self` keyword argument In-Reply-To: <1413029049.09.0.127316928921.issue22609@psf.upfronthosting.co.za> Message-ID: <1422435729.82.0.119915877738.issue22609@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: So may be close this issue? See also issue22958. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 10:10:31 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 28 Jan 2015 09:10:31 +0000 Subject: [issue22079] Ensure in PyType_Ready() that base class of static type is static In-Reply-To: <1406378199.04.0.952325428414.issue22079@psf.upfronthosting.co.za> Message-ID: <20150128091026.39288.84660@psf.io> Roundup Robot added the comment: New changeset c087ac6fc171 by Serhiy Storchaka in branch '2.7': Issue #22079: PyType_Ready() now checks that statically allocated type has https://hg.python.org/cpython/rev/c087ac6fc171 New changeset 747855f29b9d by Serhiy Storchaka in branch '3.4': Issue #22079: PyType_Ready() now checks that statically allocated type has https://hg.python.org/cpython/rev/747855f29b9d New changeset eb26255e11f1 by Serhiy Storchaka in branch 'default': Issue #22079: PyType_Ready() now checks that statically allocated type has https://hg.python.org/cpython/rev/eb26255e11f1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 10:20:29 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 28 Jan 2015 09:20:29 +0000 Subject: [issue22721] pprint output for sets and dicts is not stable In-Reply-To: <1414170050.02.0.186594262536.issue22721@psf.upfronthosting.co.za> Message-ID: <1422436829.67.0.378292132556.issue22721@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 10:23:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 28 Jan 2015 09:23:56 +0000 Subject: [issue14260] re.groupindex is available for modification and continues to work, having incorrect data inside it In-Reply-To: <1331530103.22.0.0779581075646.issue14260@psf.upfronthosting.co.za> Message-ID: <1422437036.44.0.886465679324.issue14260@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- keywords: +needs review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 10:26:11 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 28 Jan 2015 09:26:11 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: <1422431627.99.0.846258759079.issue23285@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > I added a few prints to the send and receive loops of _test_send. When running on a reasonably current Debian testing Linux: Thanks, that's what I was suspecting, but I really don't understand why 200ms isn't enough for a socket write to actually do something: maybe OS-X and *BSD schedulers are large timeslice... Could you try by increasing signal_period to e.g. 0.5, and sleep_time to 1? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 10:27:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 28 Jan 2015 09:27:41 +0000 Subject: [issue5700] io.FileIO calls flush() after file closed In-Reply-To: <1238945758.46.0.01809197792.issue5700@psf.upfronthosting.co.za> Message-ID: <1422437261.7.0.473540105614.issue5700@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 11:14:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 28 Jan 2015 10:14:02 +0000 Subject: [issue18898] Apply the setobject optimizations to dictionaries In-Reply-To: <1378012493.62.0.577402281969.issue18898@psf.upfronthosting.co.za> Message-ID: <1422440042.37.0.525893250529.issue18898@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: noincref.diff doesn't contain all necessary changes. For example dummy is increfed in dict_pop() and dict_popitem() and may be decrefed at insert. As in sets we can got rid of few comparisons with dummy if set dummy hashes to -1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 11:24:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 28 Jan 2015 10:24:08 +0000 Subject: [issue22687] horrible performance of textwrap.wrap() with a long word In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za> Message-ID: <1422440648.19.0.521824079027.issue22687@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. What can I do to move this issue forward? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 11:24:42 2015 From: report at bugs.python.org (Marc) Date: Wed, 28 Jan 2015 10:24:42 +0000 Subject: [issue23337] Run python with restricted rights Message-ID: <1422440682.84.0.195958964107.issue23337@psf.upfronthosting.co.za> New submission from Marc: Hi, We work in a school within a domain and pupils are using different restricted account on this domain. We tried to install Python 3.4 and it's work with an Administrator Account. With Children account , we got the message "IDLE's subprocess didn't make connection. Either IDLE can't start a subprocess or personal firewall software is blocking the connection" . We checked if there is any python file in the python.exe directory like advised on http://stackoverflow.com/questions/874757/python-idle-subprocess-error. We also tried to give more right on the python directory for the children account. If anyone have a solution please let me know. Thanks ---------- components: Windows files: python_error.png messages: 234883 nosy: marcd, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Run python with restricted rights type: crash versions: Python 3.4 Added file: http://bugs.python.org/file37889/python_error.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 11:29:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 28 Jan 2015 10:29:34 +0000 Subject: [issue18813] Speed up slice object processing In-Reply-To: <1377204772.02.0.934295206007.issue18813@psf.upfronthosting.co.za> Message-ID: <1422440974.43.0.346349895488.issue18813@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: So may be close this issue as it doesn't affect performance? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 11:31:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 28 Jan 2015 10:31:11 +0000 Subject: [issue15381] Optimize BytesIO to do less reallocations when written, similarly to StringIO In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za> Message-ID: <1422441071.36.0.64346995087.issue15381@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 11:52:51 2015 From: report at bugs.python.org (Makoto Kato) Date: Wed, 28 Jan 2015 10:52:51 +0000 Subject: [issue23338] PyErr_Format in ctypes uses invalid parameter Message-ID: <1422442371.36.0.968367348117.issue23338@psf.upfronthosting.co.za> New submission from Makoto Kato: This is CYGWIN build only. When ctypes cannot find function in CDataType_in_dll, it uses PyErr_Format. But it passes invalid parameters. ---------- components: ctypes messages: 234886 nosy: mkato priority: normal severity: normal status: open title: PyErr_Format in ctypes uses invalid parameter type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 11:55:56 2015 From: report at bugs.python.org (Makoto Kato) Date: Wed, 28 Jan 2015 10:55:56 +0000 Subject: [issue23338] PyErr_Format in ctypes uses invalid parameter In-Reply-To: <1422442371.36.0.968367348117.issue23338@psf.upfronthosting.co.za> Message-ID: <1422442556.86.0.968112478468.issue23338@psf.upfronthosting.co.za> Makoto Kato added the comment: add fix for ctypes of 2.7 branch. I don't know correct way to attach patch and process for patch. (I am new commer). So please let me know correct way if incorrect. ---------- hgrepos: +294 keywords: +patch Added file: http://bugs.python.org/file37890/py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 11:59:31 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 28 Jan 2015 10:59:31 +0000 Subject: [issue23338] PyErr_Format in ctypes uses invalid parameter In-Reply-To: <1422442371.36.0.968367348117.issue23338@psf.upfronthosting.co.za> Message-ID: <1422442771.14.0.889543689264.issue23338@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 11:59:47 2015 From: report at bugs.python.org (ThiefMaster) Date: Wed, 28 Jan 2015 10:59:47 +0000 Subject: [issue23339] dict_values should be comparable with a set Message-ID: <1422442787.53.0.167316115622.issue23339@psf.upfronthosting.co.za> New submission from ThiefMaster: >>> d = {'1': '2'} >>> {'1'} < d.keys() False >>> {'1'} < set(d.values()) False >>> {'1'} < d.values() Traceback (most recent call last): File "", line 1, in TypeError: unorderable types: set() < dict_values() Same for e.g. the `-` operator. Since dict_keys acts like a real set I think dict_values should do so, too. At least if all the values are hashable. ---------- components: Library (Lib) messages: 234888 nosy: ThiefMaster priority: normal severity: normal status: open title: dict_values should be comparable with a set versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 12:36:06 2015 From: report at bugs.python.org (mirabilos) Date: Wed, 28 Jan 2015 11:36:06 +0000 Subject: [issue23332] datetime.isoformat() -> explicitly mark UTC string as such In-Reply-To: <1422380249.92.0.118157289878.issue23332@psf.upfronthosting.co.za> Message-ID: <1422444966.76.0.176094520563.issue23332@psf.upfronthosting.co.za> mirabilos added the comment: There?s another minor bug here: UTC should append ?Z?, not ?+00:00?, which other timezones at that offset can do. Agreed about no timezone being ?floating? time in many instances, e.g. the iCalendar format uses that. ---------- nosy: +mirabilos _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 13:58:03 2015 From: report at bugs.python.org (Ramchandra Apte) Date: Wed, 28 Jan 2015 12:58:03 +0000 Subject: [issue23337] Run python with restricted rights In-Reply-To: <1422440682.84.0.195958964107.issue23337@psf.upfronthosting.co.za> Message-ID: <1422449883.43.0.948161627172.issue23337@psf.upfronthosting.co.za> Ramchandra Apte added the comment: BTW I think this is more of a support request than an issue. I might be stating the obvious, but is there any firewall software installed? ---------- nosy: +Ramchandra Apte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 14:27:24 2015 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 28 Jan 2015 13:27:24 +0000 Subject: [issue23193] Please support "numeric_owner" in tarfile In-Reply-To: <1420728144.57.0.872420723687.issue23193@psf.upfronthosting.co.za> Message-ID: <1422451644.63.0.224982613602.issue23193@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 14:36:27 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 28 Jan 2015 13:36:27 +0000 Subject: [issue23332] datetime.isoformat() -> explicitly mark UTC string as such In-Reply-To: <1422380249.92.0.118157289878.issue23332@psf.upfronthosting.co.za> Message-ID: <1422452187.89.0.963145590016.issue23332@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Why do you call it a bug? Specifying UTC as +00:00 is perfectly valid by ISO 8601 and some RFCs that are based on the ISO standard recommend against using the Z code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 14:38:29 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 28 Jan 2015 13:38:29 +0000 Subject: [issue23332] datetime.isoformat() -> explicitly mark UTC string as such In-Reply-To: <1422380249.92.0.118157289878.issue23332@psf.upfronthosting.co.za> Message-ID: <1422452309.4.0.940395729457.issue23332@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > ISO 8601 can and should be understood such as the TZ-designator is required (I think we agreed on that). No. There is no such requirement in ISO 8601 as far as I remember. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 14:40:57 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 28 Jan 2015 13:40:57 +0000 Subject: [issue22798] time.mktime doesn't update time.tzname In-Reply-To: <1415189548.18.0.514821385606.issue22798@psf.upfronthosting.co.za> Message-ID: <1422452457.61.0.102290956938.issue22798@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 14:41:08 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 28 Jan 2015 13:41:08 +0000 Subject: [issue22799] wrong time.timezone In-Reply-To: <1415199606.3.0.192697818647.issue22799@psf.upfronthosting.co.za> Message-ID: <1422452468.48.0.699890220918.issue22799@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 14:43:22 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 28 Jan 2015 13:43:22 +0000 Subject: [issue22799] wrong time.timezone In-Reply-To: <1415199606.3.0.192697818647.issue22799@psf.upfronthosting.co.za> Message-ID: <1422452602.81.0.211575139227.issue22799@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Isn't this a duplicate of #13466? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 15:42:56 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 28 Jan 2015 14:42:56 +0000 Subject: [issue23339] dict_values should be comparable with a set In-Reply-To: <1422442787.53.0.167316115622.issue23339@psf.upfronthosting.co.za> Message-ID: <1422456176.97.0.0766250975362.issue23339@psf.upfronthosting.co.za> R. David Murray added the comment: values cannot be a set, since unlike keys it may contain unhashable objects. It would be...really strange and contrary to Python's philosophy to have the validity of an operation depend on the specific data values in a structure rather than its type. Python is a strongly typed language. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 15:45:16 2015 From: report at bugs.python.org (Vipul Sharma) Date: Wed, 28 Jan 2015 14:45:16 +0000 Subject: [issue23304] Unused Superclass in calendar.py In-Reply-To: <1421963210.26.0.700938779083.issue23304@psf.upfronthosting.co.za> Message-ID: <1422456316.34.0.552979962045.issue23304@psf.upfronthosting.co.za> Vipul Sharma added the comment: I am submitting a patch file, hope this works. Please review it and correct me if I am wrong anywhere as this is my first contribution. ---------- keywords: +patch nosy: +Vipul.Sharma Added file: http://bugs.python.org/file37891/calendar_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 16:01:29 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 28 Jan 2015 15:01:29 +0000 Subject: [issue23334] http.client refactor In-Reply-To: <1422416052.74.0.996047713737.issue23334@psf.upfronthosting.co.za> Message-ID: <54C8F9C2.7090602@gmail.com> Demian Brecht added the comment: On 2015-01-27 7:34 PM, R. David Murray wrote: > Quantifying "largely" will be important. Understandably. In terms of the public API, all changes should be purely additive and 100% backwards compatible. "largely" is referring to some of the private API that has been removed (i.e. _output and _send_output) as they're no longer needed. This should also hold true for upcoming changes as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 16:25:20 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 28 Jan 2015 15:25:20 +0000 Subject: [issue13128] httplib debuglevel on CONNECT doesn't print response headers In-Reply-To: <1318050704.97.0.551622649018.issue13128@psf.upfronthosting.co.za> Message-ID: <1422458720.32.0.025905860215.issue13128@psf.upfronthosting.co.za> Demian Brecht added the comment: New patch removes unrelated changes. ---------- Added file: http://bugs.python.org/file37892/issue13128_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 16:41:16 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 28 Jan 2015 15:41:16 +0000 Subject: [issue23334] http.client refactor In-Reply-To: <1422410696.55.0.10985599454.issue23334@psf.upfronthosting.co.za> Message-ID: <1422459676.82.0.148937208929.issue23334@psf.upfronthosting.co.za> R. David Murray added the comment: Although they are private interfaces we may decide we need a deprecation release before dropping them. Sometimes what we do in cases like this is go ahead and make the changes, but also provide the old methods via a backward-compatible shim and have them emit deprecation warnings. (I haven't looked at your specific changes, and unfortunately probably won't have time to do so :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 16:49:05 2015 From: report at bugs.python.org (Alex Potapenko) Date: Wed, 28 Jan 2015 15:49:05 +0000 Subject: [issue23340] armv7l C++ exceptions issue Message-ID: <1422460145.75.0.667594511432.issue23340@psf.upfronthosting.co.za> New submission from Alex Potapenko: I run Python on an arm-brcm-linux-uclibcgnueabi router. Python was cross-compiled using hndtools-arm-linux-2.6.36-uclibc-4.5.3 toolchain. While trying to use deluge, I realised that there's something wrong with handling C++ exceptions in C++ extension modules: they're not being caught at all. I tested whether C++ exception handling works on my system in general, and concluded it does work fine. I then wrote a simple C++ extension module with a try-catch block in the init function, that has a "throw 1" in the try section and a "catch (...)" section (see module.cpp), and I got "terminate called after throwing an instance of 'int'" when trying to load the module. Tested this with Python 2.7.9 and 3.4.2, however I had similar issues with other versions, such as 2.7.3 and 2.6.9. I'm not sure whether this is a Python issue, or a specific build issue, but I'm stuck here and any help is greatly appreciated! ---------- components: Extension Modules files: module.cpp messages: 234899 nosy: alllexx priority: normal severity: normal status: open title: armv7l C++ exceptions issue type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file37893/module.cpp _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 16:54:48 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 28 Jan 2015 15:54:48 +0000 Subject: [issue23334] http.client refactor In-Reply-To: <1422459676.82.0.148937208929.issue23334@psf.upfronthosting.co.za> Message-ID: <54C9063F.1080406@gmail.com> Demian Brecht added the comment: On 2015-01-28 7:41 AM, R. David Murray wrote: > Although they are private interfaces we may decide we need a deprecation release before dropping them. Sometimes what we do in cases like this is go ahead and make the changes, but also provide the old methods via a backward-compatible shim and have them emit deprecation warnings. That makes sense. If it's decided that's the path that should be pursued, I'll add them in once the functional/test/doc changes have all been made. Thanks for the heads up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 17:17:22 2015 From: report at bugs.python.org (Akira Li) Date: Wed, 28 Jan 2015 16:17:22 +0000 Subject: [issue22799] wrong time.timezone In-Reply-To: <1415199606.3.0.192697818647.issue22799@psf.upfronthosting.co.za> Message-ID: <1422461842.52.0.486931763821.issue22799@psf.upfronthosting.co.za> Akira Li added the comment: > Isn't this a duplicate of #13466? In what way is it a duplicate? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 17:36:15 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 28 Jan 2015 16:36:15 +0000 Subject: [issue23340] armv7l C++ exceptions issue In-Reply-To: <1422460145.75.0.667594511432.issue23340@psf.upfronthosting.co.za> Message-ID: <1422462975.12.0.606504792099.issue23340@psf.upfronthosting.co.za> R. David Murray added the comment: For a problem like this you should post to the python-list mailing list. In addition to the bug tracker not being a place to get help, you are actually more likely to find people who can help you on python-list. We don't actually deal with C++ extensions while developing Python itself so other python users are more likely to have experience in this area. If you do manage to identify a python bug (which seems unlikely, there are certainly other people successfully using C++ with Python) you can come back and reopen this issue. ---------- nosy: +r.david.murray stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 17:45:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 28 Jan 2015 16:45:22 +0000 Subject: [issue20416] Marshal: special case int and float, don't use references In-Reply-To: <1390903848.78.0.660754858197.issue20416@psf.upfronthosting.co.za> Message-ID: <1422463522.54.0.923277922118.issue20416@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is more general solution. For simple values (ints, floats, complex numbers, short strings) it is faster to use the value itself as a key than create new integer object (id). Without the patch: data ver. dumps(ms) loads(ms) size(KiB) genData 2 103.9 186.4 4090.7 genData 3 250.3 196.8 4090.7 genData 4 223.5 182.5 3651.3 [1000]*10**6 2 98.6 134.8 4882.8 [1000]*10**6 3 491.1 62.2 4882.8 [1000]*10**6 4 494.9 62.1 4882.8 [1000.0]*10**6 2 173.5 158.4 8789.1 [1000.0]*10**6 3 494.8 62.2 4882.8 [1000.0]*10**6 4 491.4 62.8 4882.8 [1000.0j]*10**6 2 288.8 221.4 16601.6 [1000.0j]*10**6 3 493.6 62.4 4882.8 [1000.0j]*10**6 4 489.2 62.0 4882.8 20 pydecimals 2 85.0 114.7 3936.5 20 pydecimals 3 97.2 44.3 3373.4 20 pydecimals 4 86.2 40.0 3297.5 With marshal3_numbers.patch: data ver. dumps(ms) loads(ms) size(KiB) genData 3 108.4 187.5 4090.7 genData 4 83.0 179.3 3651.3 [1000]*10**6 3 104.2 145.8 4882.8 [1000]*10**6 4 103.9 147.0 4882.8 [1000.0]*10**6 3 177.4 154.5 8789.1 [1000.0]*10**6 4 177.1 164.2 8789.1 [1000.0j]*10**6 3 501.6 61.1 4882.8 [1000.0j]*10**6 4 501.6 62.3 4882.8 20 pydecimals 3 95.2 41.9 3373.4 20 pydecimals 4 83.5 38.5 3297.5 With marshal_refs_by_value.patch: data ver. dumps(ms) loads(ms) size(KiB) genData 3 150.4 197.0 4090.7 genData 4 122.1 184.8 3651.3 [1000]*10**6 3 169.1 62.3 4882.8 [1000]*10**6 4 169.2 62.2 4882.8 [1000.0]*10**6 3 313.5 62.2 4882.8 [1000.0]*10**6 4 312.8 62.3 4882.8 [1000.0j]*10**6 3 410.6 62.5 4882.8 [1000.0j]*10**6 4 410.5 62.3 4882.8 20 pydecimals 3 68.5 41.1 3373.4 20 pydecimals 4 57.5 39.8 3297.5 The marshal_refs_by_value.patch produces data so compact as unpatched code does, but dumps faster. Usually it dumps slower than marshal3_numbers.patch, but may produce smaller data and loads faster. Surprisingly it dumps the code of the _pydecimal module faster. As side effect the patch can turn some simple equal values to identical objects. ---------- components: +Interpreter Core stage: -> patch review Added file: http://bugs.python.org/file37894/marshal_refs_by_value.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 17:46:03 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 28 Jan 2015 16:46:03 +0000 Subject: [issue20416] Marshal: special case int and float, don't use references In-Reply-To: <1390903848.78.0.660754858197.issue20416@psf.upfronthosting.co.za> Message-ID: <1422463563.37.0.744141126405.issue20416@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file37895/bench_issue20416.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 18:07:23 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 28 Jan 2015 17:07:23 +0000 Subject: [issue23335] _ssl.c cannot be compiled with older versions of OpenSSL In-Reply-To: <1422418886.09.0.55350529771.issue23335@psf.upfronthosting.co.za> Message-ID: <20150128170653.39278.56206@psf.io> Roundup Robot added the comment: New changeset 16f982f93a47 by Benjamin Peterson in branch 'default': ifdef our way to compatibility with old openssl (closes #23335) https://hg.python.org/cpython/rev/16f982f93a47 New changeset 1addc4f0f10c by Benjamin Peterson in branch '2.7': ifdef our way to compatibility with old openssl (closes #23335) https://hg.python.org/cpython/rev/1addc4f0f10c ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 19:00:00 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 28 Jan 2015 18:00:00 +0000 Subject: [issue22799] wrong time.timezone In-Reply-To: <1415199606.3.0.192697818647.issue22799@psf.upfronthosting.co.za> Message-ID: <1422468000.76.0.322134799263.issue22799@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Please take a look at msg148208. I agree with MAL that time module globals timezone and daylight should be deprecated in favor of tm_gmtoff or datetime.astimezone(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 19:09:00 2015 From: report at bugs.python.org (Ethan Furman) Date: Wed, 28 Jan 2015 18:09:00 +0000 Subject: [issue11145] '%o' % user-defined instance In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za> Message-ID: <1422468540.56.0.67941950324.issue11145@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 19:16:14 2015 From: report at bugs.python.org (Alex Potapenko) Date: Wed, 28 Jan 2015 18:16:14 +0000 Subject: [issue23340] armv7l C++ exceptions issue In-Reply-To: <1422460145.75.0.667594511432.issue23340@psf.upfronthosting.co.za> Message-ID: <1422468974.37.0.736152552826.issue23340@psf.upfronthosting.co.za> Alex Potapenko added the comment: Thank you for your reply, David! I will come back and reopen if I do identify a python bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 19:55:49 2015 From: report at bugs.python.org (Akira Li) Date: Wed, 28 Jan 2015 18:55:49 +0000 Subject: [issue22799] wrong time.timezone In-Reply-To: <1415199606.3.0.192697818647.issue22799@psf.upfronthosting.co.za> Message-ID: <1422471349.39.0.525165398338.issue22799@psf.upfronthosting.co.za> Akira Li added the comment: I agree that time.timezone, time.altzone is not enough in the general case. Because UTC offset may be different at different dates for reasons unrelated to DST transitions therefore any solution that doesn't take into account a given date/time into account will fail. *Nothing* works in the general case. Nothing. But it doesn't mean that the current behaviour of time.timezone can't be improved for this particular use-case: lt = time.localtime() # in a short-lived script assertEqual(lt.tm_gmtoff, -[time.timezone, time.altzone][lt.tm_isdst]) The test checks values for the current time (time.localtime()). It should work in *most* cases if time.timezone/altzone have correct values at import time. Perhaps synchronizing time.timezone with C timezone variable as I've mentioned before http://bugs.python.org/issue22798 may fix this issue too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 20:26:05 2015 From: report at bugs.python.org (Dan LaMotte) Date: Wed, 28 Jan 2015 19:26:05 +0000 Subject: [issue23341] Issue parsing valid cookie Message-ID: <1422473165.15.0.717728203911.issue23341@psf.upfronthosting.co.za> New submission from Dan LaMotte: I recently discovered that a valid cookie (by the RFC) is not parse-able by the Cookie library in python's standard library. import Cookie c = Cookie.SimpleCookie('key=[ab]cd[ef]') print c.keys() # yields [] When quoted, it works fine: c = Cookie.SimpleCookie('key="[ab]cd[ef]"') print c.keys() # yields ['key'] I noticed the issue after upgrading to Python 2.7.9 (was previously at 2.7.2). The issue cropped up in our internal Django Web site when another internal site used a cookie in a similar format to the above and due to the sort order of the cookies, it appeared before the sessionid cookie we use with Django. Effectively, parsing of the cookie header stops and the sessionid is never read which ... to Django ... means you are not logged in. So, attempt to login, no errors, redirect to new page after successful login and you still appear not logged in. References: cookie-value in http://tools.ietf.org/html/rfc6265#section-4.1 token in http://tools.ietf.org/html/rfc2616#section-2.2 cookie-pair = cookie-name "=" cookie-value cookie-name = token ... The code correctly disallows brackets [ and ] in cookie-name's, but ends up disallowing them in cookie-value's as well which is not RFC Compliant. We noticed this issue in Chrome but not Firefox. Our guess is that Firefox quotes its cookie-values which the code handles just fine. ---------- messages: 234908 nosy: dlamotte priority: normal severity: normal status: open title: Issue parsing valid cookie versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 20:42:37 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 28 Jan 2015 19:42:37 +0000 Subject: [issue23341] Issue parsing valid cookie In-Reply-To: <1422473165.15.0.717728203911.issue23341@psf.upfronthosting.co.za> Message-ID: <1422474156.99.0.573230385126.issue23341@psf.upfronthosting.co.za> R. David Murray added the comment: This may be a duplicate of issue 22931. If so please add your comments there and close this one. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 20:56:42 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 28 Jan 2015 19:56:42 +0000 Subject: [issue19980] Improve help('non-topic') response In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za> Message-ID: <1422475002.22.0.172618352626.issue19980@psf.upfronthosting.co.za> Mark Lawrence added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 21:01:32 2015 From: report at bugs.python.org (Ishan Khare) Date: Wed, 28 Jan 2015 20:01:32 +0000 Subject: [issue22086] Tab indent no longer works in interpreter In-Reply-To: <1406396060.4.0.777513387491.issue22086@psf.upfronthosting.co.za> Message-ID: <1422475292.51.0.556768978681.issue22086@psf.upfronthosting.co.za> Ishan Khare added the comment: what is the current state of this issue, reading the http://bugs.python.org/issue5845 and its changesets, it seems that all the changes that were made during that issue no longer exists, like: fix-5845.diff -> adds a function named enablerlcompleter (as specified in diff) in file Lib/site.py , which i cannot find in current Lib/site.py (https://hg.python.org/cpython/file/1addc4f0f10c/Lib/site.py) ---------- nosy: +Ishan.Khare _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 21:17:22 2015 From: report at bugs.python.org (Dan LaMotte) Date: Wed, 28 Jan 2015 20:17:22 +0000 Subject: [issue23341] Issue parsing valid cookie In-Reply-To: <1422473165.15.0.717728203911.issue23341@psf.upfronthosting.co.za> Message-ID: <1422476242.73.0.417026814495.issue23341@psf.upfronthosting.co.za> Dan LaMotte added the comment: Yes, this is a duplicate of that bug. Sorry. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 21:19:07 2015 From: report at bugs.python.org (Dan LaMotte) Date: Wed, 28 Jan 2015 20:19:07 +0000 Subject: [issue22931] cookies with square brackets in value In-Reply-To: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za> Message-ID: <1422476347.6.0.515090918311.issue22931@psf.upfronthosting.co.za> Changes by Dan LaMotte : ---------- nosy: +dlamotte _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 21:23:56 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 28 Jan 2015 20:23:56 +0000 Subject: [issue23341] Issue parsing valid cookie In-Reply-To: <1422473165.15.0.717728203911.issue23341@psf.upfronthosting.co.za> Message-ID: <1422476636.72.0.0873122368612.issue23341@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> duplicate stage: -> resolved superseder: -> cookies with square brackets in value _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 21:25:54 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 28 Jan 2015 20:25:54 +0000 Subject: [issue22931] cookies with square brackets in value In-Reply-To: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za> Message-ID: <1422476754.56.0.301792468609.issue22931@psf.upfronthosting.co.za> Demian Brecht added the comment: Ping for review/commit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 21:42:55 2015 From: report at bugs.python.org (Neil Girdhar) Date: Wed, 28 Jan 2015 20:42:55 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422477775.88.0.616828694546.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Fixed a couple bugs and added a test. Incremented the magic number. ---------- Added file: http://bugs.python.org/file37896/starunpack24.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 22:27:12 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 28 Jan 2015 21:27:12 +0000 Subject: [issue23304] Unused Superclass in calendar.py In-Reply-To: <1421963210.26.0.700938779083.issue23304@psf.upfronthosting.co.za> Message-ID: <1422480432.98.0.74309832018.issue23304@psf.upfronthosting.co.za> Berker Peksag added the comment: Looks like "error" was unused since https://hg.python.org/cpython/rev/acdc0b9a6c78#l2.48 (see also https://hg.python.org/cpython/rev/6ee380349c84/ for time.gmtime()). LGTM. ---------- nosy: +berker.peksag stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 22:46:15 2015 From: report at bugs.python.org (Neil Girdhar) Date: Wed, 28 Jan 2015 21:46:15 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422481575.78.0.118647720544.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Just need to fix the parser now. Minimal example: >>> parser.sequence2st(parser.expr("{1}").totuple()) Traceback (most recent call last): File "", line 1, in parser.ParserError: Expected node type 12, got 302. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 22:53:03 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 28 Jan 2015 21:53:03 +0000 Subject: [issue23304] Unused Superclass in calendar.py In-Reply-To: <1421963210.26.0.700938779083.issue23304@psf.upfronthosting.co.za> Message-ID: <1422481983.12.0.20248567586.issue23304@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I suppose that calendar.error is here for compatibility. It is an alias to ValueError, so that errors raised by the calendar module can be catched with the "except calendar.error:" statement. Making calendar.error different class will likely break user code. I am inclined to reject this patch. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 23:13:39 2015 From: report at bugs.python.org (Thomas Kluyver) Date: Wed, 28 Jan 2015 22:13:39 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess Message-ID: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> New submission from Thomas Kluyver: This follows on from the python-ideas thread starting here: https://mail.python.org/pipermail/python-ideas/2015-January/031479.html subprocess gains: - A CompletedProcess class representing a process that has finished, with attributes args, returncode, stdout and stderr - A run() function which runs a process to completion and returns a CompletedProcess instance, aiming to unify the functionality of call, check_call and check_output - CalledProcessError and TimeoutExceeded now have a stderr attribute, to avoid throwing away potentially relevant information. Things I'm not sure about: 1. Should run() capture stdout/stderr by default? I opted not to, for consistency with Popen and with shells. 2. I gave run() a check_returncode parameter, but it feels quite a long name for a parameter. Is 'check' clear enough to use as the parameter name? 3. Popen has an 'args' attribute, while CalledProcessError and TimeoutExpired have 'cmd'. CompletedProcess sits between those cases, so which name should it use? For now, it's args. ---------- components: Library (Lib) files: subprocess_run.patch keywords: patch messages: 234918 nosy: takluyver priority: normal severity: normal status: open title: run() - unified high-level interface for subprocess type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file37897/subprocess_run.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 23:16:04 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 28 Jan 2015 22:16:04 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1422483364.8.0.448726806383.issue23342@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 23:20:44 2015 From: report at bugs.python.org (Hobs) Date: Wed, 28 Jan 2015 22:20:44 +0000 Subject: [issue23343] operator precedence table for `not x` has an operand, while the others do not Message-ID: <1422483644.76.0.913289618164.issue23343@psf.upfronthosting.co.za> New submission from Hobs: Shouldn't the [operator precedence table](https://docs.python.org/3.4/reference/expressions.html#operator-precedence), 5th row, 1st column, just say "`not`" rather than "`not` x"? The other rows are identified by the keyword for the operator and don't include any operand(s). Is there some other expression that includes `not` that should have a different position in the precedence table? ---------- assignee: docs at python components: Documentation messages: 234919 nosy: Hobson.Lane, docs at python priority: normal severity: normal status: open title: operator precedence table for `not x` has an operand, while the others do not type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 23:22:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 28 Jan 2015 22:22:06 +0000 Subject: [issue23344] Faster marshalling Message-ID: <1422483726.85.0.28053556963.issue23344@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Currently writing marshalled data to buffer is not very efficient. Data is written byte by byte with testing conditions p->fp != NULL and p->ptr != p->end for every byte. Proposed patch makes writing to buffer faster. Benchmark results: $ ./python -m timeit -s "import marshal; d = compile(open('Lib/_pydecimal.py').read(), '_pydecimal.py', 'exec')" -- "marshal.dumps(d)" Unpatched: 100 loops, best of 3: 4.64 msec per loop Patched: 100 loops, best of 3: 3.39 msec per loop $ ./python -m timeit -s "import marshal; a = ['%010x' % i for i in range(10**4)]" -- "marshal.dumps(a)" Unpatched: 1000 loops, best of 3: 1.96 msec per loop Patched: 1000 loops, best of 3: 1.32 msec per loop $ ./python -m timeit -s "import marshal; a = ['%0100x' % i for i in range(10**4)]" -- "marshal.dumps(a)" Unpatched: 100 loops, best of 3: 10.3 msec per loop Patched: 100 loops, best of 3: 3.39 msec per loop ---------- components: Interpreter Core files: marshal_faster_write.patch keywords: patch messages: 234920 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Faster marshalling type: performance versions: Python 3.5 Added file: http://bugs.python.org/file37898/marshal_faster_write.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 23:23:35 2015 From: report at bugs.python.org (Hobs) Date: Wed, 28 Jan 2015 22:23:35 +0000 Subject: [issue23343] operator precedence table for `not x` has an operand, while the others do not In-Reply-To: <1422483644.76.0.913289618164.issue23343@psf.upfronthosting.co.za> Message-ID: <1422483815.1.0.601153801512.issue23343@psf.upfronthosting.co.za> Hobs added the comment: Just noticed the other entries for not. Not a bug. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 23:41:10 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 28 Jan 2015 22:41:10 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1422484870.07.0.655762184523.issue23342@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 23:44:01 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 28 Jan 2015 22:44:01 +0000 Subject: [issue23343] operator precedence table for `not x` has an operand, while the others do not In-Reply-To: <1422483644.76.0.913289618164.issue23343@psf.upfronthosting.co.za> Message-ID: <1422485041.95.0.0453245352851.issue23343@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 23:46:58 2015 From: report at bugs.python.org (Thomas Kluyver) Date: Wed, 28 Jan 2015 22:46:58 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1422485218.78.0.623980630353.issue23342@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Another question: With this patch, CalledProcessError and TimeoutExceeded exceptions now have attributes called output and stderr. It would seem less surprising for output to be called stdout, but we can't break existing code that relies on the output attribute. Using properties, either stdout or output could be made an alias for the other, so both names work. Is this desirable? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 23:51:49 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 28 Jan 2015 22:51:49 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1422485509.84.0.922555137535.issue23342@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- assignee: -> gregory.p.smith nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 28 23:53:50 2015 From: report at bugs.python.org (Ethan Furman) Date: Wed, 28 Jan 2015 22:53:50 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1422485630.2.0.870206525811.issue23342@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 00:03:40 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 28 Jan 2015 23:03:40 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1422486220.67.0.134893296353.issue23342@psf.upfronthosting.co.za> Gregory P. Smith added the comment: A 1) Opting not to capture by default is good. Let people explicitly request that. A 2) "check" seems like a reasonable parameter name for the "should i raise if rc != 0" bool. I don't have any other good bikeshed name suggestions. A 3) Calling it args the same way Popen does is consistent. That the attribute on the exceptions is 'cmd' is a bit of an old wart but seems reasonable. Neither the name 'args' or 'cmd' is actually good for any use in subprocess as it is already an unfortunately multi-typed parameter. It can either be a string or it can be a sequence of strings. The documentation is not clear about what type(s) 'cmd' may be. A Another) Now that they gain a stderr attribute, having a corresponding stdout one would make sense. Implement it as a property and document it with a versionadded 3.5 as usual. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 00:30:59 2015 From: report at bugs.python.org (Ethan Furman) Date: Wed, 28 Jan 2015 23:30:59 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1422487859.33.0.488781520975.issue23342@psf.upfronthosting.co.za> Ethan Furman added the comment: I haven't checked the code, but does check_output and friends combine stdout and stderr when ouput=PIPE? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 00:35:06 2015 From: report at bugs.python.org (Thomas Kluyver) Date: Wed, 28 Jan 2015 23:35:06 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1422488106.43.0.102181214509.issue23342@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Updated patch following Gregory's suggestions: - The check_returncode parameter is now called check. The method on CompletedProcess is still check_returncode, though. - Clarified the docs about args - CalledProcessError and TimeoutExceeded gain a stdout property as an alias of output Ethan: to combine stdout and stderr in check_output, you need to pass stderr=subprocess.STDOUT - it doesn't assume you want that. I did consider having a simplified interface so you could pass e.g. capture='combine', or capture='stdout', but I don't think the brevity is worth the loss of flexibility. ---------- Added file: http://bugs.python.org/file37899/subprocess_run2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 00:36:56 2015 From: report at bugs.python.org (Lothsahn) Date: Wed, 28 Jan 2015 23:36:56 +0000 Subject: [issue13697] python RLock implementation unsafe with signals In-Reply-To: <1325538793.4.0.376965160112.issue13697@psf.upfronthosting.co.za> Message-ID: <1422488216.19.0.385576729722.issue13697@psf.upfronthosting.co.za> Lothsahn added the comment: I am using Python 2.6.5 (we will be upgrading to Python 2.7.9 soon) and I recently ran into this bug. If I do any locking in a signal handler with RLocks, the entire system can deadlock. I'm using this to serialize my IO so we don't have mismatched lines in our logs. It looks like RLock was implemented in C in 3.2. While I don't care about the performance benefits of that rewrite, having a non-deadlocking RLock implementation would be nice. Not sure if this issue can be fixed in 2.7, but it would be nice. C RLock implementation here: http://bugs.python.org/issue3001 ---------- nosy: +Lothsahn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 00:39:47 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 28 Jan 2015 23:39:47 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: Gregory P. Smith added the comment: Ethan: check_output combines them when stdout=subprocess.STDOUT is passed ( https://docs.python.org/3.5/library/subprocess.html#subprocess.STDOUT). Never pass stdout=PIPE or stderr= PIPE to call() or check*() methods as that will lead to a deadlock when a pipe buffer fills up. check_output() won't even allow you pass in stdout as it needs to set that to PIPE internally, but you could still do the wrong thing and pass stderr=PIPE without it warning you. the documentation tells people not to do this. i don't recall why we haven't made it warn or raise when someone tries. (but that should be a separate issue/change) On Wed Jan 28 2015 at 3:30:59 PM Ethan Furman wrote: > > Ethan Furman added the comment: > > I haven't checked the code, but does check_output and friends combine > stdout and stderr when ouput=PIPE? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 00:44:03 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 28 Jan 2015 23:44:03 +0000 Subject: [issue13697] python RLock implementation unsafe with signals In-Reply-To: <1325538793.4.0.376965160112.issue13697@psf.upfronthosting.co.za> Message-ID: <1422488643.42.0.529638623256.issue13697@psf.upfronthosting.co.za> STINNER Victor added the comment: FYI I proposed a fix for eventlet to fix eventlet with Python 3 when monkey-patching is used: https://github.com/eventlet/eventlet/pull/187 The change forces the Python implementation of RLock, which is compatible with eventlet monkey-patching. The Python implementation of RLock gets the thread identifier from the monkey-patched threading module, whereas the C implementation calls directly a C function to get the identifier which is incompatible with eventlet. If the Python implementation is simply dropped, eventlet may uses its own implementation (copy/paste code from older Python version). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 00:48:53 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 28 Jan 2015 23:48:53 +0000 Subject: [issue23333] asyncio: call protocol.connection_lost() when the creation of transport failed In-Reply-To: <1422398373.98.0.602533535675.issue23333@psf.upfronthosting.co.za> Message-ID: <1422488933.27.0.949836664159.issue23333@psf.upfronthosting.co.za> STINNER Victor added the comment: > The call to loop.add_reader() should maybe be scheduled after the call to connection_made()? To ensure that protocol methods (feed_data) are not called before connection_made() has been called. Fixed by: --- changeset: 94360:1b35bef31bf8 branch: 3.4 tag: tip user: Victor Stinner date: Thu Jan 29 00:36:51 2015 +0100 files: Lib/asyncio/selector_events.py Lib/test/test_asyncio/test_selector_events.py description: asyncio: Fix _SelectorSocketTransport constructor Only start reading when connection_made() has been called: protocol.data_received() must not be called before protocol.connection_made(). --- Other fix related to this issue: --- changeset: 94358:1da90ebae442 branch: 3.4 parent: 94355:263344bb2107 user: Victor Stinner date: Thu Jan 29 00:35:56 2015 +0100 files: Lib/asyncio/sslproto.py Lib/test/test_asyncio/test_sslproto.py description: asyncio: Fix SSLProtocol.eof_received() Wake-up the waiter if it is not done yet. --- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 01:03:43 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 29 Jan 2015 00:03:43 +0000 Subject: [issue23333] asyncio: add a new Protocol.connection_failed() method In-Reply-To: <1422398373.98.0.602533535675.issue23333@psf.upfronthosting.co.za> Message-ID: <1422489823.11.0.0477554829576.issue23333@psf.upfronthosting.co.za> STINNER Victor added the comment: New patch which adds a new Protocol.connection_failed() method. The method is called when the creation of the transport failed, ie. when the connection failed, on SSL handshake failure for example. The patch also closes the transport on connection failure (avoid a ResourceWarning with patch of the issue #23243). ---------- title: asyncio: call protocol.connection_lost() when the creation of transport failed -> asyncio: add a new Protocol.connection_failed() method Added file: http://bugs.python.org/file37900/connection_failed.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 01:04:45 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 29 Jan 2015 00:04:45 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1422489885.88.0.63091145134.issue23342@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 01:54:26 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 29 Jan 2015 00:54:26 +0000 Subject: [issue18982] Add tests for CLI of the calendar module In-Reply-To: <1378674520.21.0.168914844213.issue18982@psf.upfronthosting.co.za> Message-ID: <1422492866.88.0.73506470659.issue18982@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 01:58:32 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 29 Jan 2015 00:58:32 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za> Message-ID: <1422493112.13.0.637480910452.issue23285@psf.upfronthosting.co.za> Ned Deily added the comment: It turns out the times are not important; the hangup is the default size of the socket buffers on OS X and possibly BSD in general. In my case, the send and receive buffers are 8192, which explains why the chunks written are so small. I somewhat arbitrarily changed the sizes of the buffers in _test_send with: rd.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, support.SOCK_MAX_SIZE // 3) wr.setsockopt(socket.SOL_SOCKET, socket.SO_SNDBUF, support.SOCK_MAX_SIZE // 3) The results were: test_send (__main__.SocketEINTRTest) ... rd SO_RCVBUF default was 8192, wr SO_SNDBUF default was 8192 len(data) = 50331651 sent = 5592405, written = 5592405 chunk = 5592405, total read = 5592405 chunk = 5592405, total read = 11184810 chunk = 5592405, total read = 16777215 sent = 16777215, written = 22369620 chunk = 5592405, total read = 22369620 chunk = 5592405, total read = 27962025 chunk = 5592405, total read = 33554430 chunk = 5592405, total read = 39146835 sent = 22369620, written = 44739240 chunk = 5592405, total read = 44739240 sent = 5592411, written = 50331651 chunk = 5592405, total read = 50331645 chunk = 6, total read = 50331651 ok test_sendall (__main__.SocketEINTRTest) ... rd SO_RCVBUF default was 8192, wr SO_SNDBUF default was 8192 len(data) = 50331651 chunk = 5592405, total read = 5592405 chunk = 5592405, total read = 11184810 chunk = 5592405, total read = 16777215 chunk = 5592405, total read = 22369620 chunk = 5592405, total read = 27962025 chunk = 5592405, total read = 33554430 chunk = 5592405, total read = 39146835 chunk = 5592405, total read = 44739240 sent = None, written = 50331651 chunk = 5592405, total read = 50331645 chunk = 6, total read = 50331651 ok test_sendmsg (__main__.SocketEINTRTest) ... rd SO_RCVBUF default was 8192, wr SO_SNDBUF default was 8192 len(data) = 50331651 sent = 5592405, written = 5592405 chunk = 5592405, total read = 5592405 chunk = 5592405, total read = 11184810 chunk = 5592405, total read = 16777215 chunk = 5592405, total read = 22369620 chunk = 5592405, total read = 27962025 sent = 27962025, written = 33554430 chunk = 5592405, total read = 33554430 chunk = 5592405, total read = 39146835 chunk = 5592405, total read = 44739240 sent = 16777221, written = 50331651 chunk = 5592405, total read = 50331645 chunk = 6, total read = 50331651 ok I dunno if a value that large will work in all environments, so the code to call setsockopt might need to be smarter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 01:59:28 2015 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 29 Jan 2015 00:59:28 +0000 Subject: [issue23340] armv7l C++ exceptions issue In-Reply-To: <1422460145.75.0.667594511432.issue23340@psf.upfronthosting.co.za> Message-ID: <1422493168.71.0.307801500964.issue23340@psf.upfronthosting.co.za> Eric V. Smith added the comment: I agree with David that this isn't the right venue. That said, the likely problem is that Python's main() is written in C, not C++, so some needed runtime support for exceptions is not getting initialized. ---------- nosy: +eric.smith resolution: -> not a bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 02:20:40 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 29 Jan 2015 01:20:40 +0000 Subject: [issue13330] Attempt full test coverage of LocaleTextCalendar.formatweekday In-Reply-To: <1320300850.58.0.556745870791.issue13330@psf.upfronthosting.co.za> Message-ID: <1422494440.67.0.507824669761.issue13330@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 02:23:47 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 29 Jan 2015 01:23:47 +0000 Subject: [issue23212] Update Windows and OS X installer copies of OpenSSL to 1.0.1l In-Reply-To: <1420833910.43.0.203396056169.issue23212@psf.upfronthosting.co.za> Message-ID: <1422494627.14.0.0691890812764.issue23212@psf.upfronthosting.co.za> Ned Deily added the comment: Update: 1.0.1l is now released as of 1/15. (1.0.2 was released as of 1/22 but it might be premature to go to that.) ---------- nosy: -ronaldoussoren title: Update Windows and OS X installer copies of OpenSSL to 1.0.1k -> Update Windows and OS X installer copies of OpenSSL to 1.0.1l _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 02:31:43 2015 From: report at bugs.python.org (Makoto Kato) Date: Thu, 29 Jan 2015 01:31:43 +0000 Subject: [issue23338] PyErr_Format in ctypes uses invalid parameter In-Reply-To: <1422442371.36.0.968367348117.issue23338@psf.upfronthosting.co.za> Message-ID: <1422495103.29.0.775971689496.issue23338@psf.upfronthosting.co.za> Makoto Kato added the comment: for master ---------- hgrepos: +295 Added file: http://bugs.python.org/file37901/py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 03:04:12 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 29 Jan 2015 02:04:12 +0000 Subject: [issue23345] test_ssl fails on OS X 10.10.2 with latest patch level of OpenSSL libs Message-ID: <1422497052.81.0.264375405718.issue23345@psf.upfronthosting.co.za> New submission from Ned Deily: With the latest maintenance release of OS X 10.10 (10.10.2), the OpenSSL libs have reached a patch level that fails the sanity test in test_ssl: test_ssl: testing with 'OpenSSL 0.9.8zc 15 Oct 2014' (0, 9, 8, 28, 15) under Mac ('10.10.2', ('', '', ''), 'x86_64') HAS_SNI = True OP_ALL = 0x 7ff [...] ====================================================================== FAIL: test_openssl_version (test.test_ssl.BasicSocketTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/py/dev/3x/source/Lib/test/test_ssl.py", line 309, in test_openssl_version self.assertLessEqual(patch, 26) AssertionError: 28 not less than or equal to 26 Is there anything special about 26 or can the value just be bumped? ---------- messages: 234935 nosy: ned.deily, pitrou priority: critical severity: normal stage: needs patch status: open title: test_ssl fails on OS X 10.10.2 with latest patch level of OpenSSL libs versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 03:04:20 2015 From: report at bugs.python.org (Andre Roberge) Date: Thu, 29 Jan 2015 02:04:20 +0000 Subject: [issue10716] Modernize pydoc to use better HTML and separate CSS In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za> Message-ID: <1422497060.75.0.978590929064.issue10716@psf.upfronthosting.co.za> Andre Roberge added the comment: If anyone is still interested in this, I did that today (scratching a personal itch - not knowing this had been filed before). What I have done: 1. Moved all the font/color information to a separate css file 2. Used html5 syntax. 3. Recreated a css style sheet that approximate the current look 4. Created a new, very simple style sheet, that is used as a default. It could stand to be greatly improved upon. 5. Checked the validity (W3C) of a sample of the pages generated. This required me to include some empty
and
tags. 6. Added an option to start the server with an optional, user-defined css stylesheet. 7. Made some small unrelated edit (adding spaces after commas, removing extra spaces before commas, etc.) to reduce the amount of noise from my linter. I implemented this as a separate project; I did not attempt to run any existing unit tests, nor create new ones. Other than for the additional option (user defined style sheet), I tried to avoid making any change to the functionality. The styling possible to do is thus limited as I mostly replaced existing strings/templates by new ones. My implementation can be found at https://github.com/aroberge/mod_pydoc (sorry, not an hg repo). I did not include a license; I took the existing pydoc without asking permission. It can be understood to be under the original license. ---------- nosy: +aroberge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 03:09:47 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 29 Jan 2015 02:09:47 +0000 Subject: [issue23333] asyncio: add a new Protocol.connection_failed() method In-Reply-To: <1422398373.98.0.602533535675.issue23333@psf.upfronthosting.co.za> Message-ID: <1422497387.16.0.603164539129.issue23333@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file37902/accept_connection_failed.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 03:11:54 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 29 Jan 2015 02:11:54 +0000 Subject: [issue23333] asyncio: add a new Protocol.connection_failed() method In-Reply-To: <1422398373.98.0.602533535675.issue23333@psf.upfronthosting.co.za> Message-ID: <1422497514.11.0.2028994793.issue23333@psf.upfronthosting.co.za> STINNER Victor added the comment: I splitted connection_failed.patch in two parts: - connection_failed-2.patch: add Protocol.connection_failed() and call when the creation of a transport failed because connection_made() was called - accept_connection_failed.patch: Fix BaseSelectorEventLoop._accept_conncetion(). On error, call connection_failed() and then close the transport. ---------- Added file: http://bugs.python.org/file37903/connection_failed-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 03:13:02 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 29 Jan 2015 02:13:02 +0000 Subject: [issue23333] asyncio: add a new Protocol.connection_failed() method In-Reply-To: <1422398373.98.0.602533535675.issue23333@psf.upfronthosting.co.za> Message-ID: <1422497582.84.0.98168076556.issue23333@psf.upfronthosting.co.za> STINNER Victor added the comment: > - connection_failed-2.patch: add Protocol.connection_failed() and call when the creation of a transport failed because connection_made() was called Oops. "... *before* connection_made() was called". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 03:15:46 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 29 Jan 2015 02:15:46 +0000 Subject: [issue23212] Update Windows and OS X installer copies of OpenSSL to 1.0.1l In-Reply-To: <1420833910.43.0.203396056169.issue23212@psf.upfronthosting.co.za> Message-ID: <1422497746.36.0.34754573556.issue23212@psf.upfronthosting.co.za> Zachary Ware added the comment: I got the 1.0.1l sources prepared and committed to svn.python.org 12 days ago, but got pulled away from it before I had a chance to build and test it. Steve, Tim, if one of you has a chance to test it out before I do, please don't hesitate. Note that the 1.0.1k sources were also prepared and committed, but are completely useless for Windows (which was why 1.0.1l was released, if I'm not mistaken). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 03:50:57 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 29 Jan 2015 02:50:57 +0000 Subject: [issue10716] Modernize pydoc to use better HTML and separate CSS In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za> Message-ID: <1422499857.07.0.717532602805.issue10716@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks! Apparently, we were working on the same issue simultaneously. I was working on the HTML and CSS parts (didn't touch to Lib/pydoc.py yet). I can combine our work, if you could - create a separate branch (no need to be a Hg repo, I can create a patch from GitHub) - revert whitespace and PEP 8 changes - revert the new -c option in mod_pydoc.py ---------- keywords: -gsoc nosy: +berker.peksag versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 03:58:10 2015 From: report at bugs.python.org (Andre Roberge) Date: Thu, 29 Jan 2015 02:58:10 +0000 Subject: [issue10716] Modernize pydoc to use better HTML and separate CSS In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za> Message-ID: <1422500290.0.0.882438378457.issue10716@psf.upfronthosting.co.za> Andre Roberge added the comment: I could certainly create a new branch and revert the PEP8 changes and the new -c option, but before I do this, could you confirm that the new html output would be deemed to be acceptable? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 04:25:51 2015 From: report at bugs.python.org (Andre Roberge) Date: Thu, 29 Jan 2015 03:25:51 +0000 Subject: [issue10716] Modernize pydoc to use better HTML and separate CSS In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za> Message-ID: <1422501951.55.0.34298560593.issue10716@psf.upfronthosting.co.za> Andre Roberge added the comment: Rather than creating a new branch, I took another copy of pydoc.py, kept its name, and only applied the html-related changes in it. (no new -c option, no unrelated PEP8 changes to the best of my knowledge.) The original pydoc.py referred to pydoc_data/_pydoc.css (which was an empty file). I put the "minimal new styling" option in that file. I noticed that some former had no href attribute; I changed the "name" attribute to "id", since "name" is deprecated in html 5. However, my styling option shows these as actual links whereas they are inactive. An example of this can be seen in _codecs ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 04:59:05 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 29 Jan 2015 03:59:05 +0000 Subject: [issue22989] HTTPResponse.msg not as documented In-Reply-To: <1417632317.82.0.906874710781.issue22989@psf.upfronthosting.co.za> Message-ID: <1422503945.82.0.790204541729.issue22989@psf.upfronthosting.co.za> Martin Panter added the comment: Documenting the ?headers? attribute is also discussed in Issue 12707 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 05:32:18 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 29 Jan 2015 04:32:18 +0000 Subject: [issue21228] Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse? In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za> Message-ID: <1422505938.1.0.798592940199.issue21228@psf.upfronthosting.co.za> Martin Panter added the comment: Related: Issue 12707, about deprecating some methods in favour of attributes ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 05:44:46 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 29 Jan 2015 04:44:46 +0000 Subject: [issue12707] Deprecate addinfourl getters In-Reply-To: <1312760770.57.0.2285900636.issue12707@psf.upfronthosting.co.za> Message-ID: <1422506686.28.0.055688227957.issue12707@psf.upfronthosting.co.za> Martin Panter added the comment: I think it would be okay to deprecate the methods in the documentation, but they should not be removed nor trigger warnings any time soon. Currently the following related methods and attributes are documented: * addinfourl.getcode() == HTTPResponse.status == HTTPError.code * HTTPResponse.reason == HTTPError.reason (HTTPError documentation is vague on this.) * addinfourl.geturl() * addinfourl.info() == HTTPResponse.msg == HTTPError.headers (But see Issue 22989 and patch in Issue 21228 for a quirk with HTTPResponse.) It would be nice to ensure these three classes all implement the same ?Response? interface, except that geturl() and ?url? may not be appropriate for HTTPResponse. The ?code? and ?headers? attributes should definitely be documented for consistency. I propose also adding and documenting ?reason?. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 05:52:53 2015 From: report at bugs.python.org (Denis Sukhonin) Date: Thu, 29 Jan 2015 04:52:53 +0000 Subject: [issue23346] shutil.rmtree doesn't work correctly on FreeBSD. Message-ID: <1422507173.88.0.069796427202.issue23346@psf.upfronthosting.co.za> New submission from Denis Sukhonin: shutil.rmtree doesn't work correctly on FreeBSD 9.1. For example if I create a path /tmp/test and try to remove it, I get an exception: >>> shutil.rmtree('/tmp/test') Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python3.4/shutil.py", line 463, in rmtree _rmtree_safe_fd(fd, path, onerror) File "/usr/local/lib/python3.4/shutil.py", line 385, in _rmtree_safe_fd onerror(os.listdir, path, sys.exc_info()) File "/usr/local/lib/python3.4/shutil.py", line 382, in _rmtree_safe_fd names = os.listdir(topfd) OSError: [Errno 22] Invalid argument: '/tmp/test' --- shutil._use_fd_functions has value True. When I change it to False, the shutil.rmtree works perfecty. Version info: >>> print(sys.version) 3.4.2 (default, Dec 22 2014, 21:56:20) [GCC 4.2.1 20070831 patched [FreeBSD]] >>> print(sys.platform) freebsd9 $ uname -r 9.1-RELEASE ---------- components: Library (Lib) messages: 234946 nosy: negval priority: normal severity: normal status: open title: shutil.rmtree doesn't work correctly on FreeBSD. type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 06:06:51 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 29 Jan 2015 05:06:51 +0000 Subject: [issue12707] Deprecate addinfourl getters In-Reply-To: <1312760770.57.0.2285900636.issue12707@psf.upfronthosting.co.za> Message-ID: <1422508011.93.0.511546459785.issue12707@psf.upfronthosting.co.za> Martin Panter added the comment: Blessing a geturl() method or ?url? attribute on HTTPError might require Issue 13567 to be fixed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 06:30:23 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 29 Jan 2015 05:30:23 +0000 Subject: [issue12707] Deprecate addinfourl getters In-Reply-To: <1312760770.57.0.2285900636.issue12707@psf.upfronthosting.co.za> Message-ID: <1422509423.34.0.566923805719.issue12707@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 06:32:45 2015 From: report at bugs.python.org (Ent) Date: Thu, 29 Jan 2015 05:32:45 +0000 Subject: [issue23255] SimpleHTTPRequestHandler refactor for more extensible usage. In-Reply-To: <1421502718.52.0.546532418197.issue23255@psf.upfronthosting.co.za> Message-ID: <1422509565.61.0.863199396759.issue23255@psf.upfronthosting.co.za> Ent added the comment: Thanks for the update! I wasn't expecting this to be such a friendly & positive experience. Glad to be proven wrong :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 08:12:55 2015 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 29 Jan 2015 07:12:55 +0000 Subject: [issue18813] Speed up slice object processing In-Reply-To: <1377204772.02.0.934295206007.issue18813@psf.upfronthosting.co.za> Message-ID: <1422515575.13.0.235811055974.issue18813@psf.upfronthosting.co.za> Stefan Behnel added the comment: Closing as not worth doing. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 08:28:23 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 29 Jan 2015 07:28:23 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: <1422493112.13.0.637480910452.issue23285@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > It turns out the times are not important; the hangup is the default size of the socket buffers on OS X and possibly BSD in general. In my case, the send and receive buffers are 8192, which explains why the chunks written are so small. Hmmm... Basically, with a much smaller socket buffer, we get much more context switches, which increases drastically the test runtime. But I must admit I'm still really surprised by the time it takes on OS-X: with a SOCK_MAX_SIZE of 16MB and a socket buffer size of 8kb, that's 2000 calls to send with context switches between the sender and receiver - and thie overhead should be much less on a two core machine. I'll try to increase the socket buffer size and see what the buildbots do: most of them will probably cap it at around 100k, but that'll hopefully be enough. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 08:29:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 Jan 2015 07:29:06 +0000 Subject: [issue18982] Add tests for CLI of the calendar module In-Reply-To: <1378674520.21.0.168914844213.issue18982@psf.upfronthosting.co.za> Message-ID: <1422516546.35.0.110236242833.issue18982@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated test addresses Berker's comments. ---------- Added file: http://bugs.python.org/file37904/test_calendar_cli_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 08:42:33 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 29 Jan 2015 07:42:33 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: Message-ID: Charles-Fran?ois Natali added the comment: > Charles-Fran?ois Natali added the comment: > > Hmmm... > Basically, with a much smaller socket buffer, we get much more context > switches, which increases drastically the test runtime. > But I must admit I'm still really surprised by the time it takes on > OS-X: with a SOCK_MAX_SIZE of 16MB and a socket buffer size of 8kb, > that's 2000 calls to send with context switches between the sender and > receiver - and thie overhead should be much less on a two core > machine. OK, actually the receiver is completely CPU-bound, because of memory allocation for the socket.recv() buffer I'll play with recv_into() and profile a bit more. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 09:33:57 2015 From: report at bugs.python.org (Sebastian Bank) Date: Thu, 29 Jan 2015 08:33:57 +0000 Subject: [issue20923] ConfigParser should nested [] in section names. In-Reply-To: <1394806905.89.0.637343755468.issue20923@psf.upfronthosting.co.za> Message-ID: <1422520437.33.0.991810342428.issue20923@psf.upfronthosting.co.za> Sebastian Bank added the comment: If this is the intended behaviuour, I guess ConfigParser should warn the user if he supplies a section name with a ']' (prevent failed roundtrips). See http://bugs.python.org/issue23301 The current behaviour looks like the opposite of Postel's law. ---------- nosy: +xflr6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 09:41:44 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 29 Jan 2015 08:41:44 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za> Message-ID: <1422520904.67.0.603658888202.issue23285@psf.upfronthosting.co.za> Ned Deily added the comment: eintr-1.diff doesn't seem to make any significant difference from eintr.diff on my system. It's still pegging a CPU at 100% and takes 7 minutes wall time to complete. $ time ./python ~/Projects/PyDev/active/dev/3x/source/Lib/test/eintrdata/eintr_tester.py test_read (__main__.OSEINTRTest) ... ok test_wait (__main__.OSEINTRTest) ... ok test_wait3 (__main__.OSEINTRTest) ... ok test_wait4 (__main__.OSEINTRTest) ... ok test_waitpid (__main__.OSEINTRTest) ... ok test_write (__main__.OSEINTRTest) ... ok test_accept (__main__.SocketEINTRTest) ... ok test_recv (__main__.SocketEINTRTest) ... ok test_recvmsg (__main__.SocketEINTRTest) ... ok test_send (__main__.SocketEINTRTest) ... ok test_sendall (__main__.SocketEINTRTest) ... ok test_sendmsg (__main__.SocketEINTRTest) ... ok ---------------------------------------------------------------------- Ran 12 tests in 439.966s OK real 7m20.276s user 5m7.575s sys 2m9.846s ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 10:21:45 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 29 Jan 2015 09:21:45 +0000 Subject: [issue23345] test_ssl fails on OS X 10.10.2 with latest patch level of OpenSSL libs In-Reply-To: <1422497052.81.0.264375405718.issue23345@psf.upfronthosting.co.za> Message-ID: <1422523305.98.0.60963940801.issue23345@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The assumption was that the patch level represented a letter (from 'a' to 'z'), but we can certainly relax that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 10:22:33 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 29 Jan 2015 09:22:33 +0000 Subject: [issue23345] test_ssl fails on OS X 10.10.2 with latest patch level of OpenSSL libs In-Reply-To: <1422497052.81.0.264375405718.issue23345@psf.upfronthosting.co.za> Message-ID: <1422523353.54.0.00380370775257.issue23345@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Er... OS X 10.10 ships OpenSSL 0.9.8?? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 09:12:29 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 29 Jan 2015 08:12:29 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: Message-ID: Charles-Fran?ois Natali added the comment: OK, it turns out the culprit was repeated calls to BytesIO.getvalue(), which forced large allocations upon reception of every message. The patch attached fixes this (without changing the socket buffer size). ---------- Added file: http://bugs.python.org/file37905/eintr-1.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r fe0fddd6fd21 Lib/_pyio.py --- a/Lib/_pyio.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/_pyio.py Thu Jan 29 07:59:47 2015 +0000 @@ -1006,10 +1006,7 @@ current_size = 0 while True: # Read until EOF or until read() would block. - try: - chunk = self.raw.read() - except InterruptedError: - continue + chunk = self.raw.read() if chunk in empty_values: nodata_val = chunk break @@ -1028,10 +1025,7 @@ chunks = [buf[pos:]] wanted = max(self.buffer_size, n) while avail < n: - try: - chunk = self.raw.read(wanted) - except InterruptedError: - continue + chunk = self.raw.read(wanted) if chunk in empty_values: nodata_val = chunk break @@ -1060,12 +1054,7 @@ have = len(self._read_buf) - self._read_pos if have < want or have <= 0: to_read = self.buffer_size - have - while True: - try: - current = self.raw.read(to_read) - except InterruptedError: - continue - break + current = self.raw.read(to_read) if current: self._read_buf = self._read_buf[self._read_pos:] + current self._read_pos = 0 @@ -1214,8 +1203,6 @@ while self._write_buf: try: n = self.raw.write(self._write_buf) - except InterruptedError: - continue except BlockingIOError: raise RuntimeError("self.raw should implement RawIOBase: it " "should not raise BlockingIOError") diff -r fe0fddd6fd21 Lib/distutils/spawn.py --- a/Lib/distutils/spawn.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/distutils/spawn.py Thu Jan 29 07:59:47 2015 +0000 @@ -137,9 +137,6 @@ try: pid, status = os.waitpid(pid, 0) except OSError as exc: - import errno - if exc.errno == errno.EINTR: - continue if not DEBUG: cmd = executable raise DistutilsExecError( diff -r fe0fddd6fd21 Lib/multiprocessing/connection.py --- a/Lib/multiprocessing/connection.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/multiprocessing/connection.py Thu Jan 29 07:59:47 2015 +0000 @@ -365,10 +365,7 @@ def _send(self, buf, write=_write): remaining = len(buf) while True: - try: - n = write(self._handle, buf) - except InterruptedError: - continue + n = write(self._handle, buf) remaining -= n if remaining == 0: break @@ -379,10 +376,7 @@ handle = self._handle remaining = size while remaining > 0: - try: - chunk = read(handle, remaining) - except InterruptedError: - continue + chunk = read(handle, remaining) n = len(chunk) if n == 0: if remaining == size: @@ -595,13 +589,7 @@ self._unlink = None def accept(self): - while True: - try: - s, self._last_accepted = self._socket.accept() - except InterruptedError: - pass - else: - break + s, self._last_accepted = self._socket.accept() s.setblocking(True) return Connection(s.detach()) diff -r fe0fddd6fd21 Lib/multiprocessing/forkserver.py --- a/Lib/multiprocessing/forkserver.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/multiprocessing/forkserver.py Thu Jan 29 07:59:47 2015 +0000 @@ -188,8 +188,6 @@ finally: os._exit(code) - except InterruptedError: - pass except OSError as e: if e.errno != errno.ECONNABORTED: raise @@ -230,13 +228,7 @@ data = b'' length = UNSIGNED_STRUCT.size while len(data) < length: - while True: - try: - s = os.read(fd, length - len(data)) - except InterruptedError: - pass - else: - break + s = os.read(fd, length - len(data)) if not s: raise EOFError('unexpected EOF') data += s @@ -245,13 +237,7 @@ def write_unsigned(fd, n): msg = UNSIGNED_STRUCT.pack(n) while msg: - while True: - try: - nbytes = os.write(fd, msg) - except InterruptedError: - pass - else: - break + nbytes = os.write(fd, msg) if nbytes == 0: raise RuntimeError('should not get here') msg = msg[nbytes:] diff -r fe0fddd6fd21 Lib/multiprocessing/popen_fork.py --- a/Lib/multiprocessing/popen_fork.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/multiprocessing/popen_fork.py Thu Jan 29 07:59:47 2015 +0000 @@ -1,7 +1,6 @@ import os import sys import signal -import errno from . import util @@ -29,8 +28,6 @@ try: pid, sts = os.waitpid(self.pid, flag) except OSError as e: - if e.errno == errno.EINTR: - continue # Child process not yet created. See #1731717 # e.errno == errno.ECHILD == 10 return None diff -r fe0fddd6fd21 Lib/socket.py --- a/Lib/socket.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/socket.py Thu Jan 29 07:59:47 2015 +0000 @@ -572,8 +572,6 @@ except timeout: self._timeout_occurred = True raise - except InterruptedError: - continue except error as e: if e.args[0] in _blocking_errnos: return None diff -r fe0fddd6fd21 Lib/socketserver.py --- a/Lib/socketserver.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/socketserver.py Thu Jan 29 07:59:47 2015 +0000 @@ -553,8 +553,6 @@ try: pid, _ = os.waitpid(-1, 0) self.active_children.discard(pid) - except InterruptedError: - pass except ChildProcessError: # we don't have any children, we're done self.active_children.clear() diff -r fe0fddd6fd21 Lib/subprocess.py --- a/Lib/subprocess.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/subprocess.py Thu Jan 29 07:59:47 2015 +0000 @@ -489,14 +489,6 @@ DEVNULL = -3 -def _eintr_retry_call(func, *args): - while True: - try: - return func(*args) - except InterruptedError: - continue - - # XXX This function is only used by multiprocessing and the test suite, # but it's here so that it can be imported when Python is compiled without # threads. @@ -963,10 +955,10 @@ if self.stdin: self._stdin_write(input) elif self.stdout: - stdout = _eintr_retry_call(self.stdout.read) + stdout = self.stdout.read() self.stdout.close() elif self.stderr: - stderr = _eintr_retry_call(self.stderr.read) + stderr = self.stderr.read() self.stderr.close() self.wait() else: @@ -1410,7 +1402,7 @@ # exception (limited in size) errpipe_data = bytearray() while True: - part = _eintr_retry_call(os.read, errpipe_read, 50000) + part = os.read(errpipe_read, 50000) errpipe_data += part if not part or len(errpipe_data) > 50000: break @@ -1420,7 +1412,7 @@ if errpipe_data: try: - _eintr_retry_call(os.waitpid, self.pid, 0) + os.waitpid(self.pid, 0) except ChildProcessError: pass try: @@ -1505,7 +1497,7 @@ def _try_wait(self, wait_flags): """All callers to this function MUST hold self._waitpid_lock.""" try: - (pid, sts) = _eintr_retry_call(os.waitpid, self.pid, wait_flags) + (pid, sts) = os.waitpid(self.pid, wait_flags) except ChildProcessError: # This happens if SIGCLD is set to be ignored or waiting # for child processes has otherwise been disabled for our diff -r fe0fddd6fd21 Lib/test/eintrdata/eintr_tester.py --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Lib/test/eintrdata/eintr_tester.py Thu Jan 29 07:59:47 2015 +0000 @@ -0,0 +1,233 @@ +""" +This test suite exercises some system calls subject to interruption with EINTR, +to check that it is actually handled transparently. +It is intended to be run by the main test suite within a child process, to +ensure there is no background thread running (so that signals are delivered to +the correct thread). +Signals are generated in-process using setitimer(ITIMER_REAL), which allows +sub-second periodicity (contrarily to signal()). +""" + +import io +import os +import signal +import socket +import time +import unittest + +from test import support + + + at unittest.skipUnless(hasattr(signal, "setitimer"), "requires setitimer()") +class EINTRBaseTest(unittest.TestCase): + """ Base class for EINTR tests. """ + + # delay for initial signal delivery + signal_delay = 0.1 + # signal delivery periodicity + signal_period = 0.1 + # default sleep time for tests - should obviously have: + #??sleep_time > signal_period + sleep_time = 0.2 + + @classmethod + def setUpClass(cls): + cls.orig_handler = signal.signal(signal.SIGALRM, lambda *args: None) + signal.setitimer(signal.ITIMER_REAL, cls.signal_delay, + cls.signal_period) + + @classmethod + def tearDownClass(cls): + signal.setitimer(signal.ITIMER_REAL, cls.signal_delay, 0) + signal.signal(signal.SIGALRM, cls.orig_handler) + + @classmethod + def _sleep(cls): + # default sleep time + time.sleep(cls.sleep_time) + + + at unittest.skipUnless(hasattr(signal, "setitimer"), "requires setitimer()") +class OSEINTRTest(EINTRBaseTest): + """ EINTR tests for the os module. """ + + def _test_wait_multiple(self, wait_func): + num = 3 + for _ in range(num): + pid = os.fork() + if pid == 0: + self._sleep() + os._exit(0) + for _ in range(num): + wait_func() + + def test_wait(self): + self._test_wait_multiple(os.wait) + + @unittest.skipUnless(hasattr(os, 'wait3'), 'requires wait3()') + def test_wait3(self): + self._test_wait_multiple(lambda: os.wait3(0)) + + def _test_wait_single(self, wait_func): + pid = os.fork() + if pid == 0: + self._sleep() + os._exit(0) + else: + wait_func(pid) + + def test_waitpid(self): + self._test_wait_single(lambda pid: os.waitpid(pid, 0)) + + @unittest.skipUnless(hasattr(os, 'wait4'), 'requires wait4()') + def test_wait4(self): + self._test_wait_single(lambda pid: os.wait4(pid, 0)) + + def test_read(self): + rd, wr = os.pipe() + self.addCleanup(os.close, rd) + # wr closed explicitly by parent + + # the payload below are smaller than PIPE_BUF, hence the writes will be + # atomic + datas = [b"hello", b"world", b"spam"] + + pid = os.fork() + if pid == 0: + os.close(rd) + for data in datas: + # let the parent block on read() + self._sleep() + os.write(wr, data) + os._exit(0) + else: + self.addCleanup(os.waitpid, pid, 0) + os.close(wr) + for data in datas: + self.assertEqual(data, os.read(rd, len(data))) + + def test_write(self): + rd, wr = os.pipe() + self.addCleanup(os.close, wr) + # rd closed explicitly by parent + + # we must write enough data for the write() to block + data = b"xyz" * support.PIPE_MAX_SIZE + + pid = os.fork() + if pid == 0: + os.close(wr) + read_data = io.BytesIO() + # let the parent block on write() + self._sleep() + while len(read_data.getvalue()) < len(data): + chunk = os.read(rd, 2 * len(data)) + read_data.write(chunk) + self.assertEqual(read_data.getvalue(), data) + os._exit(0) + else: + os.close(rd) + written = 0 + while written < len(data): + written += os.write(wr, memoryview(data)[written:]) + self.assertEqual(0, os.waitpid(pid, 0)[1]) + + + at unittest.skipUnless(hasattr(signal, "setitimer"), "requires setitimer()") +class SocketEINTRTest(EINTRBaseTest): + """ EINTR tests for the socket module. """ + + @unittest.skipUnless(hasattr(socket, 'socketpair'), 'needs socketpair()') + def _test_recv(self, recv_func): + rd, wr = socket.socketpair() + self.addCleanup(rd.close) + # wr closed explicitly by parent + + # single-byte payload guard us against partial recv + datas = [b"x", b"y", b"z"] + + pid = os.fork() + if pid == 0: + rd.close() + for data in datas: + # let the parent block on recv() + self._sleep() + wr.sendall(data) + os._exit(0) + else: + self.addCleanup(os.waitpid, pid, 0) + wr.close() + for data in datas: + self.assertEqual(data, recv_func(rd, len(data))) + + def test_recv(self): + self._test_recv(socket.socket.recv) + + @unittest.skipUnless(hasattr(socket.socket, 'recvmsg'), 'needs recvmsg()') + def test_recvmsg(self): + self._test_recv(lambda sock, data: sock.recvmsg(data)[0]) + + def _test_send(self, send_func): + rd, wr = socket.socketpair() + self.addCleanup(wr.close) + # rd closed explicitly by parent + + # we must write enough data for the write() to block + data = b"xyz" * support.SOCK_MAX_SIZE + + pid = os.fork() + if pid == 0: + wr.close() + # let the parent block on send() + self._sleep() + chunks = [] + while sum(len(chunk) for chunk in chunks) < len(data): + chunks.append(rd.recv(len(data))) + self.assertEqual(b''.join(chunks), data) + os._exit(0) + else: + rd.close() + written = 0 + while written < len(data): + sent = send_func(wr, memoryview(data)[written:]) + # sendall() returns None + written += len(data) if sent is None else sent + self.assertEqual(0, os.waitpid(pid, 0)[1]) + + def test_send(self): + self._test_send(socket.socket.send) + + def test_sendall(self): + self._test_send(socket.socket.sendall) + + @unittest.skipUnless(hasattr(socket.socket, 'sendmsg'), 'needs sendmsg()') + def test_sendmsg(self): + self._test_send(lambda sock, data: sock.sendmsg([data])) + + def test_accept(self): + sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) + self.addCleanup(sock.close) + + sock.bind((support.HOST, 0)) + _, port = sock.getsockname() + sock.listen() + + pid = os.fork() + if pid == 0: + # let parent block on accept() + self._sleep() + with socket.create_connection((support.HOST, port)): + self._sleep() + os._exit(0) + else: + self.addCleanup(os.waitpid, pid, 0) + client_sock, _ = sock.accept() + client_sock.close() + + +def test_main(): + support.run_unittest(OSEINTRTest, SocketEINTRTest) + + +if __name__ == "__main__": + test_main() diff -r fe0fddd6fd21 Lib/test/test_eintr.py --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Lib/test/test_eintr.py Thu Jan 29 07:59:47 2015 +0000 @@ -0,0 +1,20 @@ +import os +import signal +import unittest + +from test import script_helper, support + + + at unittest.skipUnless(os.name == "posix", "only supported on Unix") +class EINTRTests(unittest.TestCase): + + @unittest.skipUnless(hasattr(signal, "setitimer"), "requires setitimer()") + def test_all(self): + # Run the tester in a sub-process, to make sure there is only one + # thread (for reliable signal delivery). + tester = support.findfile("eintr_tester.py", subdir="eintrdata") + script_helper.assert_python_ok(tester) + + +if __name__ == "__main__": + unittest.main() diff -r fe0fddd6fd21 Lib/test/test_signal.py --- a/Lib/test/test_signal.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/test/test_signal.py Thu Jan 29 07:59:47 2015 +0000 @@ -587,7 +587,7 @@ r, w = os.pipe() def handler(signum, frame): - pass + 1 / 0 signal.signal(signal.SIGALRM, handler) if interrupt is not None: @@ -604,9 +604,8 @@ try: # blocking call: read from a pipe without data os.read(r, 1) - except OSError as err: - if err.errno != errno.EINTR: - raise + except ZeroDivisionError: + pass else: sys.exit(2) sys.exit(3) diff -r fe0fddd6fd21 Lib/test/test_socket.py --- a/Lib/test/test_socket.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/test/test_socket.py Thu Jan 29 07:59:47 2015 +0000 @@ -3590,7 +3590,7 @@ def setUp(self): super().setUp() orig_alrm_handler = signal.signal(signal.SIGALRM, - lambda signum, frame: None) + lambda signum, frame: 1 / 0) self.addCleanup(signal.signal, signal.SIGALRM, orig_alrm_handler) self.addCleanup(self.setAlarm, 0) @@ -3627,13 +3627,11 @@ self.serv.settimeout(self.timeout) def checkInterruptedRecv(self, func, *args, **kwargs): - # Check that func(*args, **kwargs) raises OSError with an + # Check that func(*args, **kwargs) raises # errno of EINTR when interrupted by a signal. self.setAlarm(self.alarm_time) - with self.assertRaises(OSError) as cm: + with self.assertRaises(ZeroDivisionError) as cm: func(*args, **kwargs) - self.assertNotIsInstance(cm.exception, socket.timeout) - self.assertEqual(cm.exception.errno, errno.EINTR) def testInterruptedRecvTimeout(self): self.checkInterruptedRecv(self.serv.recv, 1024) @@ -3689,12 +3687,10 @@ # Check that func(*args, **kwargs), run in a loop, raises # OSError with an errno of EINTR when interrupted by a # signal. - with self.assertRaises(OSError) as cm: + with self.assertRaises(ZeroDivisionError) as cm: while True: self.setAlarm(self.alarm_time) func(*args, **kwargs) - self.assertNotIsInstance(cm.exception, socket.timeout) - self.assertEqual(cm.exception.errno, errno.EINTR) # Issue #12958: The following tests have problems on OS X prior to 10.7 @support.requires_mac_ver(10, 7) @@ -4062,117 +4058,6 @@ pass -class FileObjectInterruptedTestCase(unittest.TestCase): - """Test that the file object correctly handles EINTR internally.""" - - class MockSocket(object): - def __init__(self, recv_funcs=()): - # A generator that returns callables that we'll call for each - # call to recv(). - self._recv_step = iter(recv_funcs) - - def recv_into(self, buffer): - data = next(self._recv_step)() - assert len(buffer) >= len(data) - buffer[:len(data)] = data - return len(data) - - def _decref_socketios(self): - pass - - def _textiowrap_for_test(self, buffering=-1): - raw = socket.SocketIO(self, "r") - if buffering < 0: - buffering = io.DEFAULT_BUFFER_SIZE - if buffering == 0: - return raw - buffer = io.BufferedReader(raw, buffering) - text = io.TextIOWrapper(buffer, None, None) - text.mode = "rb" - return text - - @staticmethod - def _raise_eintr(): - raise OSError(errno.EINTR, "interrupted") - - def _textiowrap_mock_socket(self, mock, buffering=-1): - raw = socket.SocketIO(mock, "r") - if buffering < 0: - buffering = io.DEFAULT_BUFFER_SIZE - if buffering == 0: - return raw - buffer = io.BufferedReader(raw, buffering) - text = io.TextIOWrapper(buffer, None, None) - text.mode = "rb" - return text - - def _test_readline(self, size=-1, buffering=-1): - mock_sock = self.MockSocket(recv_funcs=[ - lambda : b"This is the first line\nAnd the sec", - self._raise_eintr, - lambda : b"ond line is here\n", - lambda : b"", - lambda : b"", # XXX(gps): io library does an extra EOF read - ]) - fo = mock_sock._textiowrap_for_test(buffering=buffering) - self.assertEqual(fo.readline(size), "This is the first line\n") - self.assertEqual(fo.readline(size), "And the second line is here\n") - - def _test_read(self, size=-1, buffering=-1): - mock_sock = self.MockSocket(recv_funcs=[ - lambda : b"This is the first line\nAnd the sec", - self._raise_eintr, - lambda : b"ond line is here\n", - lambda : b"", - lambda : b"", # XXX(gps): io library does an extra EOF read - ]) - expecting = (b"This is the first line\n" - b"And the second line is here\n") - fo = mock_sock._textiowrap_for_test(buffering=buffering) - if buffering == 0: - data = b'' - else: - data = '' - expecting = expecting.decode('utf-8') - while len(data) != len(expecting): - part = fo.read(size) - if not part: - break - data += part - self.assertEqual(data, expecting) - - def test_default(self): - self._test_readline() - self._test_readline(size=100) - self._test_read() - self._test_read(size=100) - - def test_with_1k_buffer(self): - self._test_readline(buffering=1024) - self._test_readline(size=100, buffering=1024) - self._test_read(buffering=1024) - self._test_read(size=100, buffering=1024) - - def _test_readline_no_buffer(self, size=-1): - mock_sock = self.MockSocket(recv_funcs=[ - lambda : b"a", - lambda : b"\n", - lambda : b"B", - self._raise_eintr, - lambda : b"b", - lambda : b"", - ]) - fo = mock_sock._textiowrap_for_test(buffering=0) - self.assertEqual(fo.readline(size), b"a\n") - self.assertEqual(fo.readline(size), b"Bb") - - def test_no_buffer(self): - self._test_readline_no_buffer() - self._test_readline_no_buffer(size=4) - self._test_read(buffering=0) - self._test_read(size=100, buffering=0) - - class UnbufferedFileObjectClassTestCase(FileObjectClassTestCase): """Repeat the tests from FileObjectClassTestCase with bufsize==0. @@ -5388,7 +5273,6 @@ tests.extend([ NonBlockingTCPTests, FileObjectClassTestCase, - FileObjectInterruptedTestCase, UnbufferedFileObjectClassTestCase, LineBufferedFileObjectClassTestCase, SmallBufferedFileObjectClassTestCase, diff -r fe0fddd6fd21 Lib/test/test_subprocess.py --- a/Lib/test/test_subprocess.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/test/test_subprocess.py Thu Jan 29 07:59:47 2015 +0000 @@ -2421,25 +2421,6 @@ ProcessTestCase.tearDown(self) -class HelperFunctionTests(unittest.TestCase): - @unittest.skipIf(mswindows, "errno and EINTR make no sense on windows") - def test_eintr_retry_call(self): - record_calls = [] - def fake_os_func(*args): - record_calls.append(args) - if len(record_calls) == 2: - raise OSError(errno.EINTR, "fake interrupted system call") - return tuple(reversed(args)) - - self.assertEqual((999, 256), - subprocess._eintr_retry_call(fake_os_func, 256, 999)) - self.assertEqual([(256, 999)], record_calls) - # This time there will be an EINTR so it will loop once. - self.assertEqual((666,), - subprocess._eintr_retry_call(fake_os_func, 666)) - self.assertEqual([(256, 999), (666,), (666,)], record_calls) - - @unittest.skipUnless(mswindows, "Windows-specific tests") class CommandsWithSpaces (BaseTestCase): @@ -2528,7 +2509,6 @@ Win32ProcessTestCase, CommandTests, ProcessTestCaseNoPoll, - HelperFunctionTests, CommandsWithSpaces, ContextManagerTests, ) diff -r fe0fddd6fd21 Modules/_io/fileio.c --- a/Modules/_io/fileio.c Sun Jan 18 11:17:39 2015 +0200 +++ b/Modules/_io/fileio.c Thu Jan 29 07:59:47 2015 +0000 @@ -550,7 +550,7 @@ { Py_buffer pbuf; Py_ssize_t n, len; - int err; + int err, async_err = 0; if (self->fd < 0) return err_closed(); @@ -562,16 +562,19 @@ if (_PyVerify_fd(self->fd)) { len = pbuf.len; - Py_BEGIN_ALLOW_THREADS - errno = 0; + do { + Py_BEGIN_ALLOW_THREADS + errno = 0; #ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - n = read(self->fd, pbuf.buf, (int)len); + if (len > INT_MAX) + len = INT_MAX; + n = read(self->fd, pbuf.buf, (int)len); #else - n = read(self->fd, pbuf.buf, len); + n = read(self->fd, pbuf.buf, len); #endif - Py_END_ALLOW_THREADS + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); } else n = -1; err = errno; @@ -580,7 +583,8 @@ if (err == EAGAIN) Py_RETURN_NONE; errno = err; - PyErr_SetFromErrno(PyExc_IOError); + if (!async_err) + PyErr_SetFromErrno(PyExc_IOError); return NULL; } @@ -627,6 +631,7 @@ Py_ssize_t bytes_read = 0; Py_ssize_t n; size_t bufsize; + int async_err = 0; if (self->fd < 0) return err_closed(); @@ -673,27 +678,23 @@ return NULL; } } - Py_BEGIN_ALLOW_THREADS - errno = 0; - n = bufsize - bytes_read; + do { + Py_BEGIN_ALLOW_THREADS + errno = 0; + n = bufsize - bytes_read; #ifdef MS_WINDOWS - if (n > INT_MAX) - n = INT_MAX; - n = read(self->fd, PyBytes_AS_STRING(result) + bytes_read, (int)n); + if (n > INT_MAX) + n = INT_MAX; + n = read(self->fd, PyBytes_AS_STRING(result) + bytes_read, (int)n); #else - n = read(self->fd, PyBytes_AS_STRING(result) + bytes_read, n); + n = read(self->fd, PyBytes_AS_STRING(result) + bytes_read, n); #endif - Py_END_ALLOW_THREADS + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); if (n == 0) break; if (n < 0) { - if (errno == EINTR) { - if (PyErr_CheckSignals()) { - Py_DECREF(result); - return NULL; - } - continue; - } if (errno == EAGAIN) { if (bytes_read > 0) break; @@ -701,7 +702,8 @@ Py_RETURN_NONE; } Py_DECREF(result); - PyErr_SetFromErrno(PyExc_IOError); + if (!async_err) + PyErr_SetFromErrno(PyExc_IOError); return NULL; } bytes_read += n; @@ -723,6 +725,7 @@ char *ptr; Py_ssize_t n; Py_ssize_t size = -1; + int async_err = 0; PyObject *bytes; if (self->fd < 0) @@ -747,14 +750,17 @@ ptr = PyBytes_AS_STRING(bytes); if (_PyVerify_fd(self->fd)) { - Py_BEGIN_ALLOW_THREADS - errno = 0; + do { + Py_BEGIN_ALLOW_THREADS + errno = 0; #ifdef MS_WINDOWS - n = read(self->fd, ptr, (int)size); + n = read(self->fd, ptr, (int)size); #else - n = read(self->fd, ptr, size); + n = read(self->fd, ptr, size); #endif - Py_END_ALLOW_THREADS + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); } else n = -1; @@ -764,7 +770,8 @@ if (err == EAGAIN) Py_RETURN_NONE; errno = err; - PyErr_SetFromErrno(PyExc_IOError); + if (!async_err) + PyErr_SetFromErrno(PyExc_IOError); return NULL; } @@ -783,7 +790,7 @@ { Py_buffer pbuf; Py_ssize_t n, len; - int err; + int err, async_err = 0; if (self->fd < 0) return err_closed(); @@ -794,24 +801,26 @@ return NULL; if (_PyVerify_fd(self->fd)) { - Py_BEGIN_ALLOW_THREADS - errno = 0; - len = pbuf.len; + do { + Py_BEGIN_ALLOW_THREADS + errno = 0; + len = pbuf.len; #ifdef MS_WINDOWS - if (len > 32767 && isatty(self->fd)) { - /* Issue #11395: the Windows console returns an error (12: not - enough space error) on writing into stdout if stdout mode is - binary and the length is greater than 66,000 bytes (or less, - depending on heap usage). */ - len = 32767; - } - else if (len > INT_MAX) - len = INT_MAX; - n = write(self->fd, pbuf.buf, (int)len); + if (len > 32767 && isatty(self->fd)) { + /* Issue #11395: the Windows console returns an error (12: not + enough space error) on writing into stdout if stdout mode is + binary and the length is greater than 66,000 bytes (or less, + depending on heap usage). */ + len = 32767; + } else if (len > INT_MAX) + len = INT_MAX; + n = write(self->fd, pbuf.buf, (int)len); #else - n = write(self->fd, pbuf.buf, len); + n = write(self->fd, pbuf.buf, len); #endif - Py_END_ALLOW_THREADS + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); } else n = -1; err = errno; @@ -822,7 +831,8 @@ if (err == EAGAIN) Py_RETURN_NONE; errno = err; - PyErr_SetFromErrno(PyExc_IOError); + if (!async_err) + PyErr_SetFromErrno(PyExc_IOError); return NULL; } diff -r fe0fddd6fd21 Modules/posixmodule.c --- a/Modules/posixmodule.c Sun Jan 18 11:17:39 2015 +0200 +++ b/Modules/posixmodule.c Thu Jan 29 07:59:47 2015 +0000 @@ -1361,13 +1361,16 @@ posix_fildes_fd(int fd, int (*func)(int)) { int res; - Py_BEGIN_ALLOW_THREADS - res = (*func)(fd); - Py_END_ALLOW_THREADS - if (res < 0) - return posix_error(); - Py_INCREF(Py_None); - return Py_None; + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + res = (*func)(fd); + Py_END_ALLOW_THREADS + } while (res != 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res != 0) + return (!async_err) ? posix_error() : NULL; + Py_RETURN_NONE; } @@ -3479,11 +3482,16 @@ /*[clinic end generated code: output=3c19fbfd724a8e0f input=8ab11975ca01ee5b]*/ { int res; - Py_BEGIN_ALLOW_THREADS - res = fchmod(fd, mode); - Py_END_ALLOW_THREADS - if (res < 0) - return posix_error(); + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + res = fchmod(fd, mode); + Py_END_ALLOW_THREADS + } while (res != 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res != 0) + return (!async_err) ? posix_error() : NULL; + Py_RETURN_NONE; } #endif /* HAVE_FCHMOD */ @@ -4104,11 +4112,16 @@ /*[clinic end generated code: output=687781cb7d8974d6 input=3af544ba1b13a0d7]*/ { int res; - Py_BEGIN_ALLOW_THREADS - res = fchown(fd, uid, gid); - Py_END_ALLOW_THREADS - if (res < 0) - return posix_error(); + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + res = fchown(fd, uid, gid); + Py_END_ALLOW_THREADS + } while (res != 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res != 0) + return (!async_err) ? posix_error() : NULL; + Py_RETURN_NONE; } #endif /* HAVE_FCHOWN */ @@ -9602,12 +9615,17 @@ { pid_t pid; struct rusage ru; + int async_err = 0; WAIT_TYPE status; WAIT_STATUS_INT(status) = 0; - Py_BEGIN_ALLOW_THREADS - pid = wait3(&status, options, &ru); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + pid = wait3(&status, options, &ru); + Py_END_ALLOW_THREADS + } while (pid < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (pid < 0) + return (!async_err) ? posix_error() : NULL; return wait_helper(pid, WAIT_STATUS_INT(status), &ru); } @@ -9665,15 +9683,21 @@ os_wait4_impl(PyModuleDef *module, pid_t pid, int options) /*[clinic end generated code: output=20dfb05289d37dc6 input=d11deed0750600ba]*/ { + pid_t res; struct rusage ru; + int async_err = 0; WAIT_TYPE status; WAIT_STATUS_INT(status) = 0; - Py_BEGIN_ALLOW_THREADS - pid = wait4(pid, &status, options, &ru); - Py_END_ALLOW_THREADS - - return wait_helper(pid, WAIT_STATUS_INT(status), &ru); + do { + Py_BEGIN_ALLOW_THREADS + res = wait4(pid, &status, options, &ru); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res < 0) + return (!async_err) ? posix_error() : NULL; + + return wait_helper(res, WAIT_STATUS_INT(status), &ru); } #endif /* HAVE_WAIT4 */ @@ -9744,14 +9768,17 @@ { PyObject *result; int res; + int async_err = 0; siginfo_t si; si.si_pid = 0; - Py_BEGIN_ALLOW_THREADS - res = waitid(idtype, id, &si, options); - Py_END_ALLOW_THREADS - if (res == -1) - return posix_error(); + do { + Py_BEGIN_ALLOW_THREADS + res = waitid(idtype, id, &si, options); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res < 0) + return (!async_err) ? posix_error() : NULL; if (si.si_pid == 0) Py_RETURN_NONE; @@ -9828,16 +9855,20 @@ os_waitpid_impl(PyModuleDef *module, pid_t pid, int options) /*[clinic end generated code: output=095a6b00af70b7ac input=0bf1666b8758fda3]*/ { + pid_t res; + int async_err = 0; WAIT_TYPE status; WAIT_STATUS_INT(status) = 0; - Py_BEGIN_ALLOW_THREADS - pid = waitpid(pid, &status, options); - Py_END_ALLOW_THREADS - if (pid == -1) - return posix_error(); - - return Py_BuildValue("Ni", PyLong_FromPid(pid), WAIT_STATUS_INT(status)); + do { + Py_BEGIN_ALLOW_THREADS + res = waitpid(pid, &status, options); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res < 0) + return (!async_err) ? posix_error() : NULL; + + return Py_BuildValue("Ni", PyLong_FromPid(res), WAIT_STATUS_INT(status)); } #elif defined(HAVE_CWAIT) /* MS C has a variant of waitpid() that's usable for most purposes. */ @@ -9894,15 +9925,19 @@ /*[clinic end generated code: output=c20b95b15ad44a3a input=444c8f51cca5b862]*/ { int status; - - Py_BEGIN_ALLOW_THREADS - pid = _cwait(&status, pid, options); - Py_END_ALLOW_THREADS - if (pid == -1) - return posix_error(); + Py_intptr_t res; + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + res = _cwait(&status, pid, options); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res != 0) + return (!async_err) ? posix_error() : NULL; /* shift the status left a byte so this is more like the POSIX waitpid */ - return Py_BuildValue(_Py_PARSE_INTPTR "i", pid, status << 8); + return Py_BuildValue(_Py_PARSE_INTPTR "i", res, status << 8); } #endif @@ -9943,14 +9978,17 @@ /*[clinic end generated code: output=2a83a9d164e7e6a8 input=03b0182d4a4700ce]*/ { pid_t pid; + int async_err = 0; WAIT_TYPE status; WAIT_STATUS_INT(status) = 0; - Py_BEGIN_ALLOW_THREADS - pid = wait(&status); - Py_END_ALLOW_THREADS - if (pid == -1) - return posix_error(); + do { + Py_BEGIN_ALLOW_THREADS + pid = wait(&status); + Py_END_ALLOW_THREADS + } while (pid < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (pid < 0) + return (!async_err) ? posix_error() : NULL; return Py_BuildValue("Ni", PyLong_FromPid(pid), WAIT_STATUS_INT(status)); } @@ -11080,6 +11118,7 @@ /*[clinic end generated code: output=531e482dd11a99a0 input=76e96f511be0352f]*/ { int res; + int async_err = 0; #if defined(HAVE_DUP3) && \ !(defined(HAVE_FCNTL_H) && defined(F_DUP2FD_CLOEXEC)) /* dup3() is available on Linux 2.6.27+ and glibc 2.9 */ @@ -11103,38 +11142,46 @@ } #elif defined(HAVE_FCNTL_H) && defined(F_DUP2FD_CLOEXEC) - Py_BEGIN_ALLOW_THREADS - if (!inheritable) - res = fcntl(fd, F_DUP2FD_CLOEXEC, fd2); - else - res = dup2(fd, fd2); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + if (!inheritable) + res = fcntl(fd, F_DUP2FD_CLOEXEC, fd2); + else + res = dup2(fd, fd2); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (res < 0) - return posix_error(); + return (!async_err) ? posix_error() : NULL; #else #ifdef HAVE_DUP3 if (!inheritable && dup3_works != 0) { - Py_BEGIN_ALLOW_THREADS - res = dup3(fd, fd2, O_CLOEXEC); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + res = dup3(fd, fd2, O_CLOEXEC); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); if (res < 0) { if (dup3_works == -1) dup3_works = (errno != ENOSYS); if (dup3_works) - return posix_error(); + return (!async_err) ? posix_error() : NULL; } } if (inheritable || dup3_works == 0) { #endif - Py_BEGIN_ALLOW_THREADS - res = dup2(fd, fd2); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + res = dup2(fd, fd2); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); if (res < 0) - return posix_error(); + return (!async_err) ? posix_error() : NULL; if (!inheritable && _Py_set_inheritable(fd2, 0, NULL) < 0) { close(fd2); @@ -11355,6 +11402,7 @@ /*[clinic end generated code: output=1f3bc27260a24968 input=1df2eaa27c0bf1d3]*/ { Py_ssize_t n; + int async_err = 0; PyObject *buffer; if (length < 0) { @@ -11375,13 +11423,16 @@ buffer = PyBytes_FromStringAndSize((char *)NULL, length); if (buffer == NULL) return NULL; - Py_BEGIN_ALLOW_THREADS - n = read(fd, PyBytes_AS_STRING(buffer), READ_CAST length); - Py_END_ALLOW_THREADS + + do { + Py_BEGIN_ALLOW_THREADS + n = read(fd, PyBytes_AS_STRING(buffer), READ_CAST length); + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (n < 0) { Py_DECREF(buffer); - return posix_error(); + return (!async_err) ? posix_error() : NULL; } if (n != length) @@ -11515,6 +11566,7 @@ { int cnt; Py_ssize_t n; + int async_err = 0; struct iovec *iov; Py_buffer *buf; @@ -11529,13 +11581,16 @@ if (iov_setup(&iov, &buf, buffers, cnt, PyBUF_WRITABLE) < 0) return -1; - Py_BEGIN_ALLOW_THREADS - n = readv(fd, iov, cnt); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + n = readv(fd, iov, cnt); + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); iov_cleanup(iov, buf, cnt); if (n < 0) { - posix_error(); + if (!async_err) + posix_error(); return -1; } @@ -11598,6 +11653,7 @@ /*[clinic end generated code: output=7b62bf6c06e20ae8 input=084948dcbaa35d4c]*/ { Py_ssize_t n; + int async_err = 0; PyObject *buffer; if (length < 0) { @@ -11611,12 +11667,16 @@ Py_DECREF(buffer); return posix_error(); } - Py_BEGIN_ALLOW_THREADS - n = pread(fd, PyBytes_AS_STRING(buffer), length, offset); - Py_END_ALLOW_THREADS + + do { + Py_BEGIN_ALLOW_THREADS + n = pread(fd, PyBytes_AS_STRING(buffer), length, offset); + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (n < 0) { Py_DECREF(buffer); - return posix_error(); + return (!async_err) ? posix_error() : NULL; } if (n != length) _PyBytes_Resize(&buffer, n); @@ -11677,6 +11737,7 @@ /*[clinic end generated code: output=aeb96acfdd4d5112 input=3207e28963234f3c]*/ { Py_ssize_t size; + int async_err = 0; Py_ssize_t len = data->len; if (!_PyVerify_fd(fd)) { @@ -11684,17 +11745,21 @@ return -1; } - Py_BEGIN_ALLOW_THREADS -#ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - size = write(fd, data->buf, (int)len); -#else - size = write(fd, data->buf, len); -#endif - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS +#ifdef MS_WINDOWS + if (len > INT_MAX) + len = INT_MAX; + size = write(fd, data->buf, (int)len); +#else + size = write(fd, data->buf, len); +#endif + Py_END_ALLOW_THREADS + } while (size < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (size < 0) { - posix_error(); + if (!async_err) + posix_error(); return -1; } return size; @@ -11713,6 +11778,7 @@ { int in, out; Py_ssize_t ret; + int async_err = 0; off_t offset; #if defined(__FreeBSD__) || defined(__DragonFly__) || defined(__APPLE__) @@ -11775,13 +11841,15 @@ } } - Py_BEGIN_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS #ifdef __APPLE__ - ret = sendfile(in, out, offset, &sbytes, &sf, flags); -#else - ret = sendfile(in, out, offset, len, &sf, &sbytes, flags); -#endif - Py_END_ALLOW_THREADS + ret = sendfile(in, out, offset, &sbytes, &sf, flags); +#else + ret = sendfile(in, out, offset, len, &sf, &sbytes, flags); +#endif + Py_END_ALLOW_THREADS + } while (ret < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (sf.headers != NULL) iov_cleanup(sf.headers, hbuf, sf.hdr_cnt); @@ -11800,7 +11868,7 @@ return posix_error(); } } - return posix_error(); + return (!async_err) ? posix_error() : NULL; } goto done; @@ -11821,21 +11889,26 @@ return NULL; #ifdef linux if (offobj == Py_None) { + do { + Py_BEGIN_ALLOW_THREADS + ret = sendfile(out, in, NULL, count); + Py_END_ALLOW_THREADS + } while (ret < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (ret < 0) + return (!async_err) ? posix_error() : NULL; + return Py_BuildValue("n", ret); + } +#endif + if (!Py_off_t_converter(offobj, &offset)) + return NULL; + + do { Py_BEGIN_ALLOW_THREADS - ret = sendfile(out, in, NULL, count); + ret = sendfile(out, in, &offset, count); Py_END_ALLOW_THREADS - if (ret < 0) - return posix_error(); - return Py_BuildValue("n", ret); - } -#endif - if (!Py_off_t_converter(offobj, &offset)) - return NULL; - Py_BEGIN_ALLOW_THREADS - ret = sendfile(out, in, &offset, count); - Py_END_ALLOW_THREADS + } while (ret < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (ret < 0) - return posix_error(); + return (!async_err) ? posix_error() : NULL; return Py_BuildValue("n", ret); #endif } @@ -11891,15 +11964,18 @@ { STRUCT_STAT st; int res; - - Py_BEGIN_ALLOW_THREADS - res = FSTAT(fd, &st); - Py_END_ALLOW_THREADS + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + res = FSTAT(fd, &st); + Py_END_ALLOW_THREADS + } while (res != 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (res != 0) { #ifdef MS_WINDOWS return PyErr_SetFromWindowsErr(0); #else - return posix_error(); + return (!async_err) ? posix_error() : NULL; #endif } @@ -12185,6 +12261,7 @@ { int cnt; Py_ssize_t result; + int async_err = 0; struct iovec *iov; Py_buffer *buf; @@ -12199,12 +12276,14 @@ return -1; } - Py_BEGIN_ALLOW_THREADS - result = writev(fd, iov, cnt); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + result = writev(fd, iov, cnt); + Py_END_ALLOW_THREADS + } while (result < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); iov_cleanup(iov, buf, cnt); - if (result < 0) + if (result < 0 && !async_err) posix_error(); return result; @@ -12275,17 +12354,20 @@ /*[clinic end generated code: output=ec9cc5b2238e96a7 input=19903f1b3dd26377]*/ { Py_ssize_t size; + int async_err = 0; if (!_PyVerify_fd(fd)) { posix_error(); return -1; } - Py_BEGIN_ALLOW_THREADS - size = pwrite(fd, buffer->buf, (size_t)buffer->len, offset); - Py_END_ALLOW_THREADS - - if (size < 0) + do { + Py_BEGIN_ALLOW_THREADS + size = pwrite(fd, buffer->buf, (size_t)buffer->len, offset); + Py_END_ALLOW_THREADS + } while (size < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + + if (size < 0 && !async_err) posix_error(); return size; } @@ -12353,18 +12435,21 @@ /*[clinic end generated code: output=b3321927546893d0 input=73032e98a36e0e19]*/ { int result; - - Py_BEGIN_ALLOW_THREADS + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS #ifdef HAVE_MKFIFOAT - if (dir_fd != DEFAULT_DIR_FD) - result = mkfifoat(dir_fd, path->narrow, mode); - else -#endif - result = mkfifo(path->narrow, mode); - Py_END_ALLOW_THREADS - - if (result < 0) - return posix_error(); + if (dir_fd != DEFAULT_DIR_FD) + result = mkfifoat(dir_fd, path->narrow, mode); + else +#endif + result = mkfifo(path->narrow, mode); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); + if (result != 0) + return (!async_err) ? posix_error() : NULL; Py_RETURN_NONE; } @@ -12448,18 +12533,21 @@ /*[clinic end generated code: output=f71d54eaf9bb6f1a input=ee44531551a4d83b]*/ { int result; - - Py_BEGIN_ALLOW_THREADS + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS #ifdef HAVE_MKNODAT - if (dir_fd != DEFAULT_DIR_FD) - result = mknodat(dir_fd, path->narrow, mode, device); - else -#endif - result = mknod(path->narrow, mode, device); - Py_END_ALLOW_THREADS - - if (result < 0) - return posix_error(); + if (dir_fd != DEFAULT_DIR_FD) + result = mknodat(dir_fd, path->narrow, mode, device); + else +#endif + result = mknod(path->narrow, mode, device); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); + if (result != 0) + return (!async_err) ? posix_error() : NULL; Py_RETURN_NONE; } @@ -12662,12 +12750,16 @@ /*[clinic end generated code: output=62326766cb9b76bf input=63b43641e52818f2]*/ { int result; - - Py_BEGIN_ALLOW_THREADS - result = ftruncate(fd, length); - Py_END_ALLOW_THREADS - if (result < 0) - return posix_error(); + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + result = ftruncate(fd, length); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); + if (result != 0) + return (!async_err) ? posix_error() : NULL; Py_RETURN_NONE; } #endif /* HAVE_FTRUNCATE */ @@ -12805,14 +12897,16 @@ /*[clinic end generated code: output=0cd702d2065c79db input=d7a2ef0ab2ca52fb]*/ { int result; - - Py_BEGIN_ALLOW_THREADS - result = posix_fallocate(fd, offset, length); - Py_END_ALLOW_THREADS - if (result != 0) { - errno = result; - return posix_error(); - } + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + result = posix_fallocate(fd, offset, length); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); + if (result != 0) + return (!async_err) ? posix_error() : NULL; Py_RETURN_NONE; } #endif /* HAVE_POSIX_FALLOCATE) && !POSIX_FADVISE_AIX_BUG */ @@ -12883,14 +12977,16 @@ /*[clinic end generated code: output=dad93f32c04dd4f7 input=0fbe554edc2f04b5]*/ { int result; - - Py_BEGIN_ALLOW_THREADS - result = posix_fadvise(fd, offset, length, advice); - Py_END_ALLOW_THREADS - if (result != 0) { - errno = result; - return posix_error(); - } + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + result = posix_fadvise(fd, offset, length, advice); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); + if (result != 0) + return (!async_err) ? posix_error() : NULL; Py_RETURN_NONE; } #endif /* HAVE_POSIX_FADVISE && !POSIX_FADVISE_AIX_BUG */ @@ -13745,13 +13841,17 @@ /*[clinic end generated code: output=0e32bf07f946ec0d input=d8122243ac50975e]*/ { int result; + int async_err = 0; struct statvfs st; - Py_BEGIN_ALLOW_THREADS - result = fstatvfs(fd, &st); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + result = fstatvfs(fd, &st); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); if (result != 0) - return posix_error(); + return (!async_err) ? posix_error() : NULL; return _pystatvfs_fromstructstatvfs(st); } diff -r fe0fddd6fd21 Modules/socketmodule.c --- a/Modules/socketmodule.c Sun Jan 18 11:17:39 2015 +0200 +++ b/Modules/socketmodule.c Thu Jan 29 07:59:47 2015 +0000 @@ -2037,6 +2037,7 @@ PyObject *addr = NULL; PyObject *res = NULL; int timeout; + int async_err = 0; #if defined(HAVE_ACCEPT4) && defined(SOCK_CLOEXEC) /* accept4() is available on Linux 2.6.28+ and glibc 2.10 */ static int accept4_works = -1; @@ -2050,27 +2051,27 @@ return select_error(); BEGIN_SELECT_LOOP(s) - - Py_BEGIN_ALLOW_THREADS - timeout = internal_select_ex(s, 0, interval); - if (!timeout) { + do { + Py_BEGIN_ALLOW_THREADS + timeout = internal_select_ex(s, 0, interval); + if (!timeout) { #if defined(HAVE_ACCEPT4) && defined(SOCK_CLOEXEC) - if (accept4_works != 0) { - newfd = accept4(s->sock_fd, SAS2SA(&addrbuf), &addrlen, - SOCK_CLOEXEC); - if (newfd == INVALID_SOCKET && accept4_works == -1) { - /* On Linux older than 2.6.28, accept4() fails with ENOSYS */ - accept4_works = (errno != ENOSYS); + if (accept4_works != 0) { + newfd = accept4(s->sock_fd, SAS2SA(&addrbuf), &addrlen, + SOCK_CLOEXEC); + if (newfd == INVALID_SOCKET && accept4_works == -1) { + /* On Linux older than 2.6.28, accept4() fails with ENOSYS */ + accept4_works = (errno != ENOSYS); + } } + if (accept4_works == 0) + newfd = accept(s->sock_fd, SAS2SA(&addrbuf), &addrlen); +#else + newfd = accept(s->sock_fd, SAS2SA(&addrbuf), &addrlen); +#endif } - if (accept4_works == 0) - newfd = accept(s->sock_fd, SAS2SA(&addrbuf), &addrlen); -#else - newfd = accept(s->sock_fd, SAS2SA(&addrbuf), &addrlen); -#endif - } - Py_END_ALLOW_THREADS - + Py_END_ALLOW_THREADS + } while (newfd < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (timeout == 1) { PyErr_SetString(socket_timeout, "timed out"); return NULL; @@ -2078,7 +2079,7 @@ END_SELECT_LOOP(s) if (newfd == INVALID_SOCKET) - return s->errorhandler(); + return (!async_err) ? s->errorhandler() : NULL; #ifdef MS_WINDOWS if (!SetHandleInformation((HANDLE)newfd, HANDLE_FLAG_INHERIT, 0)) { @@ -2513,10 +2514,8 @@ /* Signals are not errors (though they may raise exceptions). Adapted from PyErr_SetFromErrnoWithFilenameObject(). */ -#ifdef EINTR if (res == EINTR && PyErr_CheckSignals()) return NULL; -#endif return PyLong_FromLong((long) res); } @@ -2650,6 +2649,7 @@ { Py_ssize_t outlen = -1; int timeout; + int async_err = 0; if (!IS_SELECTABLE(s)) { select_error(); @@ -2661,18 +2661,20 @@ } BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS - timeout = internal_select_ex(s, 0, interval); - if (!timeout) { + do { + Py_BEGIN_ALLOW_THREADS + timeout = internal_select_ex(s, 0, interval); + if (!timeout) { #ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - outlen = recv(s->sock_fd, cbuf, (int)len, flags); + if (len > INT_MAX) + len = INT_MAX; + outlen = recv(s->sock_fd, cbuf, (int)len, flags); #else - outlen = recv(s->sock_fd, cbuf, len, flags); -#endif - } - Py_END_ALLOW_THREADS + outlen = recv(s->sock_fd, cbuf, len, flags); +#endif + } + Py_END_ALLOW_THREADS + } while (outlen < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (timeout == 1) { PyErr_SetString(socket_timeout, "timed out"); @@ -2682,7 +2684,8 @@ if (outlen < 0) { /* Note: the call to errorhandler() ALWAYS indirectly returned NULL, so ignore its return value */ - s->errorhandler(); + if (!async_err) + s->errorhandler(); return -1; } return outlen; @@ -2819,6 +2822,7 @@ int timeout; Py_ssize_t n = -1; socklen_t addrlen; + int async_err = 0; *addr = NULL; @@ -2831,21 +2835,23 @@ } BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS - memset(&addrbuf, 0, addrlen); - timeout = internal_select_ex(s, 0, interval); - if (!timeout) { + do { + Py_BEGIN_ALLOW_THREADS + memset(&addrbuf, 0, addrlen); + timeout = internal_select_ex(s, 0, interval); + if (!timeout) { #ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - n = recvfrom(s->sock_fd, cbuf, (int)len, flags, - (void *) &addrbuf, &addrlen); + if (len > INT_MAX) + len = INT_MAX; + n = recvfrom(s->sock_fd, cbuf, (int)len, flags, + (void *) &addrbuf, &addrlen); #else - n = recvfrom(s->sock_fd, cbuf, len, flags, - SAS2SA(&addrbuf), &addrlen); -#endif - } - Py_END_ALLOW_THREADS + n = recvfrom(s->sock_fd, cbuf, len, flags, + SAS2SA(&addrbuf), &addrlen); +#endif + } + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (timeout == 1) { PyErr_SetString(socket_timeout, "timed out"); @@ -2853,7 +2859,8 @@ } END_SELECT_LOOP(s) if (n < 0) { - s->errorhandler(); + if (!async_err) + s->errorhandler(); return -1; } @@ -2993,6 +3000,7 @@ { ssize_t bytes_received = -1; int timeout; + int async_err = 0; sock_addr_t addrbuf; socklen_t addrbuflen; struct msghdr msg = {0}; @@ -3028,25 +3036,29 @@ } BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS; - msg.msg_name = SAS2SA(&addrbuf); - msg.msg_namelen = addrbuflen; - msg.msg_iov = iov; - msg.msg_iovlen = iovlen; - msg.msg_control = controlbuf; - msg.msg_controllen = controllen; - timeout = internal_select_ex(s, 0, interval); - if (!timeout) - bytes_received = recvmsg(s->sock_fd, &msg, flags); - Py_END_ALLOW_THREADS; - if (timeout == 1) { - PyErr_SetString(socket_timeout, "timed out"); - goto finally; - } + do { + Py_BEGIN_ALLOW_THREADS; + msg.msg_name = SAS2SA(&addrbuf); + msg.msg_namelen = addrbuflen; + msg.msg_iov = iov; + msg.msg_iovlen = iovlen; + msg.msg_control = controlbuf; + msg.msg_controllen = controllen; + timeout = internal_select_ex(s, 0, interval); + if (!timeout) + bytes_received = recvmsg(s->sock_fd, &msg, flags); + Py_END_ALLOW_THREADS; + if (timeout == 1) { + PyErr_SetString(socket_timeout, "timed out"); + goto finally; + } + } while (bytes_received < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); END_SELECT_LOOP(s) if (bytes_received < 0) { - s->errorhandler(); + if (!async_err) + s->errorhandler(); goto finally; } @@ -3305,6 +3317,7 @@ { char *buf; Py_ssize_t len, n = -1; + int async_err = 0; int flags = 0, timeout; Py_buffer pbuf; @@ -3319,18 +3332,20 @@ len = pbuf.len; BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS - timeout = internal_select_ex(s, 1, interval); - if (!timeout) { + do { + Py_BEGIN_ALLOW_THREADS + timeout = internal_select_ex(s, 1, interval); + if (!timeout) { #ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - n = send(s->sock_fd, buf, (int)len, flags); + if (len > INT_MAX) + len = INT_MAX; + n = send(s->sock_fd, buf, (int)len, flags); #else - n = send(s->sock_fd, buf, len, flags); -#endif - } - Py_END_ALLOW_THREADS + n = send(s->sock_fd, buf, len, flags); +#endif + } + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (timeout == 1) { PyBuffer_Release(&pbuf); PyErr_SetString(socket_timeout, "timed out"); @@ -3340,7 +3355,7 @@ PyBuffer_Release(&pbuf); if (n < 0) - return s->errorhandler(); + return (!async_err) ? s->errorhandler() : NULL; return PyLong_FromSsize_t(n); } @@ -3359,7 +3374,8 @@ { char *buf; Py_ssize_t len, n = -1; - int flags = 0, timeout, saved_errno; + int async_err = 0; + int flags = 0, timeout; Py_buffer pbuf; if (!PyArg_ParseTuple(args, "y*|i:sendall", &pbuf, &flags)) @@ -3391,29 +3407,16 @@ PyErr_SetString(socket_timeout, "timed out"); return NULL; } - /* PyErr_CheckSignals() might change errno */ - saved_errno = errno; - /* We must run our signal handlers before looping again. - send() can return a successful partial write when it is - interrupted, so we can't restrict ourselves to EINTR. */ - if (PyErr_CheckSignals()) { - PyBuffer_Release(&pbuf); - return NULL; + if (n >= 0) { + buf += n; + len -= n; } - if (n < 0) { - /* If interrupted, try again */ - if (saved_errno == EINTR) - continue; - else - break; - } - buf += n; - len -= n; - } while (len > 0); + } while (len > 0 && (n >= 0 || errno == EINTR) && + !(async_err = PyErr_CheckSignals())); PyBuffer_Release(&pbuf); - if (n < 0) - return s->errorhandler(); + if (n < 0 || async_err) + return (!async_err) ? s->errorhandler() : NULL; Py_INCREF(Py_None); return Py_None; @@ -3439,6 +3442,7 @@ Py_ssize_t len, arglen; sock_addr_t addrbuf; int addrlen, n = -1, flags, timeout; + int async_err = 0; flags = 0; arglen = PyTuple_Size(args); @@ -3473,20 +3477,22 @@ } BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS - timeout = internal_select_ex(s, 1, interval); - if (!timeout) { + do { + Py_BEGIN_ALLOW_THREADS + timeout = internal_select_ex(s, 1, interval); + if (!timeout) { #ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - n = sendto(s->sock_fd, buf, (int)len, flags, - SAS2SA(&addrbuf), addrlen); + if (len > INT_MAX) + len = INT_MAX; + n = sendto(s->sock_fd, buf, (int)len, flags, + SAS2SA(&addrbuf), addrlen); #else - n = sendto(s->sock_fd, buf, len, flags, - SAS2SA(&addrbuf), addrlen); -#endif - } - Py_END_ALLOW_THREADS + n = sendto(s->sock_fd, buf, len, flags, + SAS2SA(&addrbuf), addrlen); +#endif + } + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (timeout == 1) { PyBuffer_Release(&pbuf); @@ -3496,7 +3502,7 @@ END_SELECT_LOOP(s) PyBuffer_Release(&pbuf); if (n < 0) - return s->errorhandler(); + return (!async_err) ? s->errorhandler() : NULL; return PyLong_FromSsize_t(n); } @@ -3528,6 +3534,7 @@ void *controlbuf = NULL; size_t controllen, controllen_last; ssize_t bytes_sent = -1; + int async_err = 0; int addrlen, timeout, flags = 0; PyObject *data_arg, *cmsg_arg = NULL, *addr_arg = NULL, *data_fast = NULL, *cmsg_fast = NULL, *retval = NULL; @@ -3685,19 +3692,23 @@ } BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS; - timeout = internal_select_ex(s, 1, interval); - if (!timeout) - bytes_sent = sendmsg(s->sock_fd, &msg, flags); - Py_END_ALLOW_THREADS; - if (timeout == 1) { - PyErr_SetString(socket_timeout, "timed out"); - goto finally; - } + do { + Py_BEGIN_ALLOW_THREADS; + timeout = internal_select_ex(s, 1, interval); + if (!timeout) + bytes_sent = sendmsg(s->sock_fd, &msg, flags); + Py_END_ALLOW_THREADS; + if (timeout == 1) { + PyErr_SetString(socket_timeout, "timed out"); + goto finally; + } + } while (bytes_sent < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); END_SELECT_LOOP(s) if (bytes_sent < 0) { - s->errorhandler(); + if (!async_err) + s->errorhandler(); goto finally; } retval = PyLong_FromSsize_t(bytes_sent); From report at bugs.python.org Thu Jan 29 10:42:30 2015 From: report at bugs.python.org (Marc) Date: Thu, 29 Jan 2015 09:42:30 +0000 Subject: [issue23337] Run python with restricted rights In-Reply-To: <1422440682.84.0.195958964107.issue23337@psf.upfronthosting.co.za> Message-ID: <1422524550.63.0.917603930518.issue23337@psf.upfronthosting.co.za> Marc added the comment: Hi Ramchandra, I actually have an AV (Sophos) but no firewall on the computer ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 10:54:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 Jan 2015 09:54:25 +0000 Subject: [issue23346] shutil.rmtree doesn't work correctly on FreeBSD. In-Reply-To: <1422507173.88.0.069796427202.issue23346@psf.upfronthosting.co.za> Message-ID: <1422525265.21.0.199782369889.issue23346@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: topfd is '/tmp/test'. But it should be file descriptor, an integer. What os.open('/tmp/test', os.O_RDONLY) returns? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 11:57:55 2015 From: report at bugs.python.org (Denis Sukhonin) Date: Thu, 29 Jan 2015 10:57:55 +0000 Subject: [issue23346] shutil.rmtree doesn't work correctly on FreeBSD. In-Reply-To: <1422507173.88.0.069796427202.issue23346@psf.upfronthosting.co.za> Message-ID: <1422529074.99.0.784011551429.issue23346@psf.upfronthosting.co.za> Denis Sukhonin added the comment: It returns an integer. >>> import os >>> os.open('/tmp/test', os.O_RDONLY) 3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 12:10:55 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 29 Jan 2015 11:10:55 +0000 Subject: [issue23345] test_ssl fails on OS X 10.10.2 with latest patch level of OpenSSL libs In-Reply-To: <1422497052.81.0.264375405718.issue23345@psf.upfronthosting.co.za> Message-ID: <1422529855.41.0.383832238162.issue23345@psf.upfronthosting.co.za> Ned Deily added the comment: Yep, 0.9.8 is the newest and presumably last major of version of OpenSSL in OS X. OpenSSL has been officially deprecated by Apple in OS X since OS X 10.7; it's only there for third-party products shipped by Apple in OS X, like Python. Their own apps use Apple's own frameworks like SecTransform and CommonCrypto. (See, for example, http://rentzsch.tumblr.com/post/33696323211/wherein-i-write-apples-technote-about-openssl-on) Apple also ships 0.9.7 shared libs in 10.10 for really old applications. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 12:24:58 2015 From: report at bugs.python.org (Alex Potapenko) Date: Thu, 29 Jan 2015 11:24:58 +0000 Subject: [issue23340] armv7l C++ exceptions issue In-Reply-To: <1422460145.75.0.667594511432.issue23340@psf.upfronthosting.co.za> Message-ID: <1422530698.75.0.464468166241.issue23340@psf.upfronthosting.co.za> Alex Potapenko added the comment: Thank you for giving me a hint, Eric! Even though you weren't 100% right, your got me thinking in the right direction, and I found out in the end that I have to explicitly link python with libgcc_s on build time. Now everything works fine. This looks like a uClibc issue, and it should be noted somewhere for others who might encounter similar problems, I suppose. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 12:30:20 2015 From: report at bugs.python.org (Alex Potapenko) Date: Thu, 29 Jan 2015 11:30:20 +0000 Subject: [issue23340] uClibc C++ exceptions issue In-Reply-To: <1422460145.75.0.667594511432.issue23340@psf.upfronthosting.co.za> Message-ID: <1422531020.46.0.124402352089.issue23340@psf.upfronthosting.co.za> Changes by Alex Potapenko : ---------- title: armv7l C++ exceptions issue -> uClibc C++ exceptions issue _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 12:56:50 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 29 Jan 2015 11:56:50 +0000 Subject: [issue23347] asyncio: fix and refactor creation of subprocess transports Message-ID: <1422532609.81.0.0177270416952.issue23347@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patch fix and refactors the creation of asyncio subprocess transports. It fixes the code handling errors. Changes: * Add a wait() method to wait until the child process exit * The constructor now accepts an optional waiter parameter. The _post_init() coroutine must not be called explicitly anymore. It makes subprocess transports closer to other transports, and it gives more freedom if we want later to change completly how subprocess transports are created. * close() now kills the process instead of kindly terminate it: the child process may ignore SIGTERM and continue to run. Call explicitly terminate() and wait() if you want to kindly terminate the child process. * close() now logs a warning in debug mode if the process is still running and needs to be killed * _make_subprocess_transport() is now fully asynchronous again: if the creation of the transport failed, wait asynchronously for the process eixt. Before the wait was synchronous. This change requires close() to *kill*, and not terminate, the child process. * Remove the _kill_wait() method, replaced with a more agressive close() method. It fixes _make_subprocess_transport() on error. BaseSubprocessTransport.close() calls the close() method of pipe transports, whereas _kill_wait() closed directly pipes of the subprocess.Popen object without unregistering file descriptors from the selector (which caused severe bugs). * These changes make subprocess.py much simpler! wait() is a coroutine, which is something uncommon. Is it ok to start using coroutines in transports, at least for subprocess transports? ---------- components: asyncio files: subprocess_wait.patch keywords: patch messages: 234963 nosy: gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio: fix and refactor creation of subprocess transports versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37906/subprocess_wait.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 13:01:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 Jan 2015 12:01:56 +0000 Subject: [issue23346] shutil.rmtree doesn't work correctly on FreeBSD. In-Reply-To: <1422529074.99.0.784011551429.issue23346@psf.upfronthosting.co.za> Message-ID: <10779939.m4SC2D0k86@raxxla> Serhiy Storchaka added the comment: Does os.listdir(os.open('/tmp/test', os.O_RDONLY)) work? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 13:50:41 2015 From: report at bugs.python.org (Denis Sukhonin) Date: Thu, 29 Jan 2015 12:50:41 +0000 Subject: [issue23346] shutil.rmtree doesn't work correctly on FreeBSD. In-Reply-To: <1422507173.88.0.069796427202.issue23346@psf.upfronthosting.co.za> Message-ID: <1422535841.5.0.135809218497.issue23346@psf.upfronthosting.co.za> Denis Sukhonin added the comment: No, it throws 22. >>> os.listdir(os.open('/tmp/test', os.O_RDONLY)) Traceback (most recent call last): File "", line 1, in OSError: [Errno 22] Invalid argument ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 13:54:49 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 29 Jan 2015 12:54:49 +0000 Subject: [issue23346] shutil.rmtree doesn't work correctly on FreeBSD. In-Reply-To: <1422507173.88.0.069796427202.issue23346@psf.upfronthosting.co.za> Message-ID: <1422536089.24.0.632530725141.issue23346@psf.upfronthosting.co.za> STINNER Victor added the comment: >> Does os.listdir(os.open('/tmp/test', os.O_RDONLY)) work? > No, it throws 22. Oh, too bad. Maybe we can detect this at Python compilation. If not, rmtree() should detect the failure and switch back to the unsafe implementation (which uses paths, not file descriptors). ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 13:55:00 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 29 Jan 2015 12:55:00 +0000 Subject: [issue23346] shutil.rmtree doesn't work correctly on FreeBSD. In-Reply-To: <1422507173.88.0.069796427202.issue23346@psf.upfronthosting.co.za> Message-ID: <1422536100.31.0.183581274563.issue23346@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 14:09:37 2015 From: report at bugs.python.org (koobs) Date: Thu, 29 Jan 2015 13:09:37 +0000 Subject: [issue23346] shutil.rmtree doesn't work correctly on FreeBSD. In-Reply-To: <1422507173.88.0.069796427202.issue23346@psf.upfronthosting.co.za> Message-ID: <1422536977.42.0.683438574409.issue23346@psf.upfronthosting.co.za> Changes by koobs : ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 14:12:20 2015 From: report at bugs.python.org (koobs) Date: Thu, 29 Jan 2015 13:12:20 +0000 Subject: [issue11578] Increase test coverage for timeit.py In-Reply-To: <1300307227.56.0.233218695639.issue11578@psf.upfronthosting.co.za> Message-ID: <1422537140.91.0.999123532268.issue11578@psf.upfronthosting.co.za> koobs added the comment: 7e7c825f75ad832d973542bfcf9ecd6e5dd3f981 broke koobs-freebsd9 and koobs-freebsd10, with: ====================================================================== FAIL: test_main_exception (test.test_timeit.TestTimeit) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/python/2.7.koobs-freebsd9/build/Lib/test/test_timeit.py", line 300, in test_main_exception self.assert_exc_string(error_stringio.getvalue(), 'ZeroDivisionError') File "/usr/home/buildbot/python/2.7.koobs-freebsd9/build/Lib/test/test_timeit.py", line 195, in assert_exc_string self.assertTrue(exc_lines[0].startswith('Traceback')) AssertionError: False is not true ---------------------------------------------------------------------- ---------- nosy: +koobs status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 14:15:32 2015 From: report at bugs.python.org (Tomasz Wasilczyk) Date: Thu, 29 Jan 2015 13:15:32 +0000 Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za> Message-ID: <1422537332.69.0.507789909029.issue17797@psf.upfronthosting.co.za> Tomasz Wasilczyk added the comment: It seems that bug remains *not* fixed. Just like eaducac pointed out, there are cases when underlying file handle is -2, which is not a valid file handle, but *is* a valid handle (which is GetCurrentThread). Thus, provided dup solution accepts it, while it shouldn't. However, suggested GetStdHandle check still doesn't work for me. While working on the related Spoon issue, I've worked out a working solution (see the patch attached). Tomek, Spoon.net dev ---------- keywords: +patch nosy: +twasilczyk at spoon Added file: http://bugs.python.org/file37907/python-3.3.5-fdvalidation.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 14:16:56 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 29 Jan 2015 13:16:56 +0000 Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za> Message-ID: <1422537416.59.0.704622021514.issue17797@psf.upfronthosting.co.za> STINNER Victor added the comment: @steve.dower: Do you have info on this issue? ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 14:17:23 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 29 Jan 2015 13:17:23 +0000 Subject: [issue23333] asyncio: add a new Protocol.connection_failed() method In-Reply-To: <1422398373.98.0.602533535675.issue23333@psf.upfronthosting.co.za> Message-ID: <20150129131705.39292.98323@psf.io> Roundup Robot added the comment: New changeset c4fd6df9aea6 by Victor Stinner in branch '3.4': asyncio: sync with Tulip https://hg.python.org/cpython/rev/c4fd6df9aea6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 14:18:07 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 29 Jan 2015 13:18:07 +0000 Subject: [issue23333] asyncio: add a new Protocol.connection_failed() method In-Reply-To: <1422398373.98.0.602533535675.issue23333@psf.upfronthosting.co.za> Message-ID: <1422537487.28.0.979696230678.issue23333@psf.upfronthosting.co.za> STINNER Victor added the comment: I commited a simplified version of accept_connection_failed.patch, without the call to connection_failed(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 14:34:54 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 29 Jan 2015 13:34:54 +0000 Subject: [issue22668] memoryview.format is corrupted due to dangling shared pointer In-Reply-To: <1413670433.7.0.452107994688.issue22668@psf.upfronthosting.co.za> Message-ID: <20150129133446.96074.34032@psf.io> Roundup Robot added the comment: New changeset e9c1fca50b46 by Stefan Krah in branch '3.4': Issue #22668: Ensure that format strings survive slicing after casting. https://hg.python.org/cpython/rev/e9c1fca50b46 New changeset 37112bd3dfb3 by Stefan Krah in branch 'default': Closes #22668: Merge from 3.4. https://hg.python.org/cpython/rev/37112bd3dfb3 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 15:08:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 Jan 2015 14:08:12 +0000 Subject: [issue23346] shutil.rmtree doesn't work correctly on FreeBSD. In-Reply-To: <1422535841.5.0.135809218497.issue23346@psf.upfronthosting.co.za> Message-ID: <7080490.BOZ32lsHR6@raxxla> Serhiy Storchaka added the comment: What if add a slash at the end of the path? os.listdir(os.open('/tmp/test/', os.O_RDONLY)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 15:30:32 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 29 Jan 2015 14:30:32 +0000 Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za> Message-ID: <1422541832.68.0.497241280966.issue17797@psf.upfronthosting.co.za> Steve Dower added the comment: This is fixed in VS2015 last time I tried it. I've proposed workarounds for this before, but it's never affected any official build do there's never been any traction. The fstat patch is normally the check that I use. I don't know what Tomasz means that it's not fixed. Fixes like this don't magically appear in earlier VS versions, and while VS2015 does have the fix, it's not quite ready for production work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 15:42:00 2015 From: report at bugs.python.org (Guillaume) Date: Thu, 29 Jan 2015 14:42:00 +0000 Subject: [issue23348] distutils.LooseVersion fails to compare two valid versions Message-ID: <1422542520.54.0.739308889883.issue23348@psf.upfronthosting.co.za> New submission from Guillaume: $ python2.7 -c "from distutils.version import LooseVersion as V; print V('3.16.0-0.bpo.4-amd64') > V('3.16-0.bpo.2-amd64')" False $ python3.4 -c "from distutils.version import LooseVersion as V; print(V('3.16.0-0.bpo.4-amd64') > V('3.16-0.bpo.2-amd64'))" Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.4/distutils/version.py", line 70, in __gt__ c = self._cmp(other) File "/usr/lib/python3.4/distutils/version.py", line 343, in _cmp if self.version < other.version: TypeError: unorderable types: int() < str() Same thing with python3.2 et python3.3. I find this on Debian. They recently change the numerotation of backported kernels. ---------- components: Distutils messages: 234975 nosy: dstufft, eric.araujo, maethor priority: normal severity: normal status: open title: distutils.LooseVersion fails to compare two valid versions type: behavior versions: Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 16:02:04 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 29 Jan 2015 15:02:04 +0000 Subject: [issue23348] distutils.LooseVersion fails to compare two valid versions In-Reply-To: <1422542520.54.0.739308889883.issue23348@psf.upfronthosting.co.za> Message-ID: <1422543724.87.0.189150531797.issue23348@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 16:42:52 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 29 Jan 2015 15:42:52 +0000 Subject: [issue22668] memoryview.format is corrupted due to dangling shared pointer In-Reply-To: <1413670433.7.0.452107994688.issue22668@psf.upfronthosting.co.za> Message-ID: <1422546172.35.0.520377483766.issue22668@psf.upfronthosting.co.za> R. David Murray added the comment: The buildbots aren't happy. This one errors in the added test: http://buildbot.python.org/all/builders/System%20Z%20Linux%203.x/builds/2595/steps/test/logs/stdio Another one had a MemoryError in lib2to3 tests. Not sure what is going on, but the one above at least is related to this issue. (That's not a very descriptive name for a test, by the way, though it did allow me to find the issue easily ;) ---------- nosy: +r.david.murray status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 17:06:41 2015 From: report at bugs.python.org (Denis Sukhonin) Date: Thu, 29 Jan 2015 16:06:41 +0000 Subject: [issue23346] shutil.rmtree doesn't work correctly on FreeBSD. In-Reply-To: <1422507173.88.0.069796427202.issue23346@psf.upfronthosting.co.za> Message-ID: <1422547601.54.0.406790572196.issue23346@psf.upfronthosting.co.za> Denis Sukhonin added the comment: The same problem. >>> os.listdir(os.open('/tmp/test/', os.O_RDONLY)) Traceback (most recent call last): File "", line 1, in OSError: [Errno 22] Invalid argument ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 17:41:56 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 29 Jan 2015 16:41:56 +0000 Subject: [issue22668] memoryview.format is corrupted due to dangling shared pointer In-Reply-To: <1413670433.7.0.452107994688.issue22668@psf.upfronthosting.co.za> Message-ID: <20150129164153.25841.89864@psf.io> Roundup Robot added the comment: New changeset 9a4af12dcc9d by Stefan Krah in branch '3.4': Issue #22668: Remove endianness assumption in test. https://hg.python.org/cpython/rev/9a4af12dcc9d New changeset da0ca7b1351f by Stefan Krah in branch 'default': Issue #22668: Merge from 3.4. https://hg.python.org/cpython/rev/da0ca7b1351f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 17:42:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 Jan 2015 16:42:09 +0000 Subject: [issue12743] C API marshalling doc contains XXX In-Reply-To: <1313160183.82.0.137409262179.issue12743@psf.upfronthosting.co.za> Message-ID: <1422549729.95.0.57972605923.issue12743@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> needs patch type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 17:43:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 Jan 2015 16:43:41 +0000 Subject: [issue23344] Faster marshalling In-Reply-To: <1422483726.85.0.28053556963.issue23344@psf.upfronthosting.co.za> Message-ID: <1422549821.28.0.700989448403.issue23344@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +kristjan.jonsson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 17:54:02 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 29 Jan 2015 16:54:02 +0000 Subject: [issue23243] asyncio: emit ResourceWarning warnings if transports/event loops are not explicitly closed In-Reply-To: <1421277484.12.0.751563251482.issue23243@psf.upfronthosting.co.za> Message-ID: <20150129165357.106379.90754@psf.io> Roundup Robot added the comment: New changeset 543f770f62f0 by Victor Stinner in branch '3.4': Issue #23243, asyncio: Emit a ResourceWarning when an event loop or a transport https://hg.python.org/cpython/rev/543f770f62f0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 17:55:05 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 29 Jan 2015 16:55:05 +0000 Subject: [issue23243] asyncio: emit ResourceWarning warnings if transports/event loops are not explicitly closed In-Reply-To: <1421277484.12.0.751563251482.issue23243@psf.upfronthosting.co.za> Message-ID: <1422550505.87.0.521626109534.issue23243@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, I commited my change adding destructors on Python 3.4 and newer to emit warnings when event loops or transports are not explicitly closed. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 18:16:10 2015 From: report at bugs.python.org (Poor Yorick) Date: Thu, 29 Jan 2015 17:16:10 +0000 Subject: [issue23284] curses, readline, tinfo, and also --prefix, dbm, CPPFLAGS In-Reply-To: <1421794283.67.0.365311015753.issue23284@psf.upfronthosting.co.za> Message-ID: <1422551770.06.0.662995624995.issue23284@psf.upfronthosting.co.za> Poor Yorick added the comment: An attempt to build python-2.7.9 resulted in this error: renaming "readline" since importing it failed ... undefined symbol: UP This happened because setup.py chose "-lncursesw" as the readline terminal library. Although libncursesw.so itself links to libtinfow.so, in order to succeed with the "--as-needed" linker flag, setup.py would have to directly choose libtinfow.so. The part of the patch that deals with that does not rely on the other changes that were made to accomodate -isystem in CPPFLAGS. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 18:46:49 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 29 Jan 2015 17:46:49 +0000 Subject: [issue23284] curses, readline, tinfo, and also --prefix, dbm, CPPFLAGS In-Reply-To: <1421794283.67.0.365311015753.issue23284@psf.upfronthosting.co.za> Message-ID: <1422553609.07.0.815492657945.issue23284@psf.upfronthosting.co.za> Stefan Krah added the comment: What system are you using? The patch is quite large, and the existing libtinfo logic should work on most systems. Is the main problem that ldd is not found? ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 19:06:49 2015 From: report at bugs.python.org (Poor Yorick) Date: Thu, 29 Jan 2015 18:06:49 +0000 Subject: [issue23284] curses, readline, tinfo, and also --prefix, dbm, CPPFLAGS In-Reply-To: <1421794283.67.0.365311015753.issue23284@psf.upfronthosting.co.za> Message-ID: <1422554809.02.0.0575636618757.issue23284@psf.upfronthosting.co.za> Poor Yorick added the comment: ldd was found. That patch does abstract and generalize ldd usage into a function for reuse. I'm building Python as part of a rather large software collection that lives in an alternate prefix. The main issue with the termcap library is that with the --as-needed linker flag, which more modern build systems prefer, linking to libncurses.so isn't sufficient, even when libncurses.so itself links to libtinfo.so, but that's what setup.py decides to do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 19:20:24 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 29 Jan 2015 18:20:24 +0000 Subject: [issue22668] memoryview.format is corrupted due to dangling shared pointer In-Reply-To: <1413670433.7.0.452107994688.issue22668@psf.upfronthosting.co.za> Message-ID: <1422555624.4.0.238158821077.issue22668@psf.upfronthosting.co.za> Stefan Krah added the comment: Thanks, David. The tests assumed little-endian, which is now fixed. The MemoryError is sporadic and unrelated -- the OpenIndiana bot often has system load issues. I don't see any more related failures, please reopen if you do. :) ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 19:35:30 2015 From: report at bugs.python.org (Maciej Zagrabski) Date: Thu, 29 Jan 2015 18:35:30 +0000 Subject: [issue21258] Add __iter__ support for mock_open In-Reply-To: <1397671005.18.0.0743040241878.issue21258@psf.upfronthosting.co.za> Message-ID: <1422556530.92.0.60934696604.issue21258@psf.upfronthosting.co.za> Maciej Zagrabski added the comment: Provided path did not work for me. Probably because lack of __next__ handler. I noticed that issue when interacting with cvs.reader and cvs.DictReader. After simple modification it seems to work fine. ---------- nosy: +mucka versions: +Python 3.4 Added file: http://bugs.python.org/file37908/mock_new.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 20:18:52 2015 From: report at bugs.python.org (Tomasz Wasilczyk) Date: Thu, 29 Jan 2015 19:18:52 +0000 Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za> Message-ID: <1422559132.9.0.326441648259.issue17797@psf.upfronthosting.co.za> Tomasz Wasilczyk added the comment: I don't mean fixing VS, but providing a workaround in Python code, when compiled with VS2012. I know newer VS versions are fixed. Do you mean, VS2012 is not supported? If it's not - then LibreOffice team have a problem, because their official release is built with this suite. If it is supported, and you don't want to alter behavior for other versions, then a patch may also contain an ifdef for MSVC 11.0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 20:36:26 2015 From: report at bugs.python.org (Poor Yorick) Date: Thu, 29 Jan 2015 19:36:26 +0000 Subject: [issue23284] curses, readline, tinfo, and also --prefix, dbm, CPPFLAGS In-Reply-To: <1421794283.67.0.365311015753.issue23284@psf.upfronthosting.co.za> Message-ID: <1422560186.0.0.640343775461.issue23284@psf.upfronthosting.co.za> Poor Yorick added the comment: The wholesale inclusion of two additional files makes the patch look larger than it is. The modifications to setup.py address three different issues. The modifications for each issue don't overlap much, so they could be cherry-picked fairly easily. For the readline issue, all that's needed is the new function, "ldd_find_library_file" and then the changes from line 704 to about line 773 that deal directly with readline and ncurses. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 20:56:04 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 29 Jan 2015 19:56:04 +0000 Subject: [issue23284] curses, readline, tinfo, and also --prefix, dbm, CPPFLAGS In-Reply-To: <1421794283.67.0.365311015753.issue23284@psf.upfronthosting.co.za> Message-ID: <1422561364.58.0.291672310173.issue23284@psf.upfronthosting.co.za> Stefan Krah added the comment: I think even the curses changes alone are rather large, especially for 2.7. Perhaps you could give us exact instructions how to reproduce the issue (OS, version, build command line). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 20:56:13 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 29 Jan 2015 19:56:13 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: <1422520904.67.0.603658888202.issue23285@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > eintr-1.diff doesn't seem to make any significant difference from eintr.diff on my system. It's still pegging a CPU at 100% and takes 7 minutes wall time to complete. Alright, enough played: the patch attached uses a memoryview and socket.recv_into() to remove all memory allocations: if this doesn't fix your problem, I don't know what's going on... ---------- Added file: http://bugs.python.org/file37909/eintr-2.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r fe0fddd6fd21 Lib/_pyio.py --- a/Lib/_pyio.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/_pyio.py Thu Jan 29 19:53:06 2015 +0000 @@ -1006,10 +1006,7 @@ current_size = 0 while True: # Read until EOF or until read() would block. - try: - chunk = self.raw.read() - except InterruptedError: - continue + chunk = self.raw.read() if chunk in empty_values: nodata_val = chunk break @@ -1028,10 +1025,7 @@ chunks = [buf[pos:]] wanted = max(self.buffer_size, n) while avail < n: - try: - chunk = self.raw.read(wanted) - except InterruptedError: - continue + chunk = self.raw.read(wanted) if chunk in empty_values: nodata_val = chunk break @@ -1060,12 +1054,7 @@ have = len(self._read_buf) - self._read_pos if have < want or have <= 0: to_read = self.buffer_size - have - while True: - try: - current = self.raw.read(to_read) - except InterruptedError: - continue - break + current = self.raw.read(to_read) if current: self._read_buf = self._read_buf[self._read_pos:] + current self._read_pos = 0 @@ -1214,8 +1203,6 @@ while self._write_buf: try: n = self.raw.write(self._write_buf) - except InterruptedError: - continue except BlockingIOError: raise RuntimeError("self.raw should implement RawIOBase: it " "should not raise BlockingIOError") diff -r fe0fddd6fd21 Lib/distutils/spawn.py --- a/Lib/distutils/spawn.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/distutils/spawn.py Thu Jan 29 19:53:06 2015 +0000 @@ -137,9 +137,6 @@ try: pid, status = os.waitpid(pid, 0) except OSError as exc: - import errno - if exc.errno == errno.EINTR: - continue if not DEBUG: cmd = executable raise DistutilsExecError( diff -r fe0fddd6fd21 Lib/multiprocessing/connection.py --- a/Lib/multiprocessing/connection.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/multiprocessing/connection.py Thu Jan 29 19:53:06 2015 +0000 @@ -365,10 +365,7 @@ def _send(self, buf, write=_write): remaining = len(buf) while True: - try: - n = write(self._handle, buf) - except InterruptedError: - continue + n = write(self._handle, buf) remaining -= n if remaining == 0: break @@ -379,10 +376,7 @@ handle = self._handle remaining = size while remaining > 0: - try: - chunk = read(handle, remaining) - except InterruptedError: - continue + chunk = read(handle, remaining) n = len(chunk) if n == 0: if remaining == size: @@ -595,13 +589,7 @@ self._unlink = None def accept(self): - while True: - try: - s, self._last_accepted = self._socket.accept() - except InterruptedError: - pass - else: - break + s, self._last_accepted = self._socket.accept() s.setblocking(True) return Connection(s.detach()) diff -r fe0fddd6fd21 Lib/multiprocessing/forkserver.py --- a/Lib/multiprocessing/forkserver.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/multiprocessing/forkserver.py Thu Jan 29 19:53:06 2015 +0000 @@ -188,8 +188,6 @@ finally: os._exit(code) - except InterruptedError: - pass except OSError as e: if e.errno != errno.ECONNABORTED: raise @@ -230,13 +228,7 @@ data = b'' length = UNSIGNED_STRUCT.size while len(data) < length: - while True: - try: - s = os.read(fd, length - len(data)) - except InterruptedError: - pass - else: - break + s = os.read(fd, length - len(data)) if not s: raise EOFError('unexpected EOF') data += s @@ -245,13 +237,7 @@ def write_unsigned(fd, n): msg = UNSIGNED_STRUCT.pack(n) while msg: - while True: - try: - nbytes = os.write(fd, msg) - except InterruptedError: - pass - else: - break + nbytes = os.write(fd, msg) if nbytes == 0: raise RuntimeError('should not get here') msg = msg[nbytes:] diff -r fe0fddd6fd21 Lib/multiprocessing/popen_fork.py --- a/Lib/multiprocessing/popen_fork.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/multiprocessing/popen_fork.py Thu Jan 29 19:53:06 2015 +0000 @@ -1,7 +1,6 @@ import os import sys import signal -import errno from . import util @@ -29,8 +28,6 @@ try: pid, sts = os.waitpid(self.pid, flag) except OSError as e: - if e.errno == errno.EINTR: - continue # Child process not yet created. See #1731717 # e.errno == errno.ECHILD == 10 return None diff -r fe0fddd6fd21 Lib/socket.py --- a/Lib/socket.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/socket.py Thu Jan 29 19:53:06 2015 +0000 @@ -572,8 +572,6 @@ except timeout: self._timeout_occurred = True raise - except InterruptedError: - continue except error as e: if e.args[0] in _blocking_errnos: return None diff -r fe0fddd6fd21 Lib/socketserver.py --- a/Lib/socketserver.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/socketserver.py Thu Jan 29 19:53:06 2015 +0000 @@ -553,8 +553,6 @@ try: pid, _ = os.waitpid(-1, 0) self.active_children.discard(pid) - except InterruptedError: - pass except ChildProcessError: # we don't have any children, we're done self.active_children.clear() diff -r fe0fddd6fd21 Lib/subprocess.py --- a/Lib/subprocess.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/subprocess.py Thu Jan 29 19:53:06 2015 +0000 @@ -489,14 +489,6 @@ DEVNULL = -3 -def _eintr_retry_call(func, *args): - while True: - try: - return func(*args) - except InterruptedError: - continue - - # XXX This function is only used by multiprocessing and the test suite, # but it's here so that it can be imported when Python is compiled without # threads. @@ -963,10 +955,10 @@ if self.stdin: self._stdin_write(input) elif self.stdout: - stdout = _eintr_retry_call(self.stdout.read) + stdout = self.stdout.read() self.stdout.close() elif self.stderr: - stderr = _eintr_retry_call(self.stderr.read) + stderr = self.stderr.read() self.stderr.close() self.wait() else: @@ -1410,7 +1402,7 @@ # exception (limited in size) errpipe_data = bytearray() while True: - part = _eintr_retry_call(os.read, errpipe_read, 50000) + part = os.read(errpipe_read, 50000) errpipe_data += part if not part or len(errpipe_data) > 50000: break @@ -1420,7 +1412,7 @@ if errpipe_data: try: - _eintr_retry_call(os.waitpid, self.pid, 0) + os.waitpid(self.pid, 0) except ChildProcessError: pass try: @@ -1505,7 +1497,7 @@ def _try_wait(self, wait_flags): """All callers to this function MUST hold self._waitpid_lock.""" try: - (pid, sts) = _eintr_retry_call(os.waitpid, self.pid, wait_flags) + (pid, sts) = os.waitpid(self.pid, wait_flags) except ChildProcessError: # This happens if SIGCLD is set to be ignored or waiting # for child processes has otherwise been disabled for our diff -r fe0fddd6fd21 Lib/test/eintrdata/eintr_tester.py --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Lib/test/eintrdata/eintr_tester.py Thu Jan 29 19:53:06 2015 +0000 @@ -0,0 +1,234 @@ +""" +This test suite exercises some system calls subject to interruption with EINTR, +to check that it is actually handled transparently. +It is intended to be run by the main test suite within a child process, to +ensure there is no background thread running (so that signals are delivered to +the correct thread). +Signals are generated in-process using setitimer(ITIMER_REAL), which allows +sub-second periodicity (contrarily to signal()). +""" + +import io +import os +import signal +import socket +import time +import unittest + +from test import support + + + at unittest.skipUnless(hasattr(signal, "setitimer"), "requires setitimer()") +class EINTRBaseTest(unittest.TestCase): + """ Base class for EINTR tests. """ + + # delay for initial signal delivery + signal_delay = 0.1 + # signal delivery periodicity + signal_period = 0.1 + # default sleep time for tests - should obviously have: + #??sleep_time > signal_period + sleep_time = 0.2 + + @classmethod + def setUpClass(cls): + cls.orig_handler = signal.signal(signal.SIGALRM, lambda *args: None) + signal.setitimer(signal.ITIMER_REAL, cls.signal_delay, + cls.signal_period) + + @classmethod + def tearDownClass(cls): + signal.setitimer(signal.ITIMER_REAL, cls.signal_delay, 0) + signal.signal(signal.SIGALRM, cls.orig_handler) + + @classmethod + def _sleep(cls): + # default sleep time + time.sleep(cls.sleep_time) + + + at unittest.skipUnless(hasattr(signal, "setitimer"), "requires setitimer()") +class OSEINTRTest(EINTRBaseTest): + """ EINTR tests for the os module. """ + + def _test_wait_multiple(self, wait_func): + num = 3 + for _ in range(num): + pid = os.fork() + if pid == 0: + self._sleep() + os._exit(0) + for _ in range(num): + wait_func() + + def test_wait(self): + self._test_wait_multiple(os.wait) + + @unittest.skipUnless(hasattr(os, 'wait3'), 'requires wait3()') + def test_wait3(self): + self._test_wait_multiple(lambda: os.wait3(0)) + + def _test_wait_single(self, wait_func): + pid = os.fork() + if pid == 0: + self._sleep() + os._exit(0) + else: + wait_func(pid) + + def test_waitpid(self): + self._test_wait_single(lambda pid: os.waitpid(pid, 0)) + + @unittest.skipUnless(hasattr(os, 'wait4'), 'requires wait4()') + def test_wait4(self): + self._test_wait_single(lambda pid: os.wait4(pid, 0)) + + def test_read(self): + rd, wr = os.pipe() + self.addCleanup(os.close, rd) + # wr closed explicitly by parent + + # the payload below are smaller than PIPE_BUF, hence the writes will be + # atomic + datas = [b"hello", b"world", b"spam"] + + pid = os.fork() + if pid == 0: + os.close(rd) + for data in datas: + # let the parent block on read() + self._sleep() + os.write(wr, data) + os._exit(0) + else: + self.addCleanup(os.waitpid, pid, 0) + os.close(wr) + for data in datas: + self.assertEqual(data, os.read(rd, len(data))) + + def test_write(self): + rd, wr = os.pipe() + self.addCleanup(os.close, wr) + # rd closed explicitly by parent + + # we must write enough data for the write() to block + data = b"xyz" * support.PIPE_MAX_SIZE + + pid = os.fork() + if pid == 0: + os.close(wr) + read_data = io.BytesIO() + # let the parent block on write() + self._sleep() + while len(read_data.getvalue()) < len(data): + chunk = os.read(rd, 2 * len(data)) + read_data.write(chunk) + self.assertEqual(read_data.getvalue(), data) + os._exit(0) + else: + os.close(rd) + written = 0 + while written < len(data): + written += os.write(wr, memoryview(data)[written:]) + self.assertEqual(0, os.waitpid(pid, 0)[1]) + + + at unittest.skipUnless(hasattr(signal, "setitimer"), "requires setitimer()") +class SocketEINTRTest(EINTRBaseTest): + """ EINTR tests for the socket module. """ + + @unittest.skipUnless(hasattr(socket, 'socketpair'), 'needs socketpair()') + def _test_recv(self, recv_func): + rd, wr = socket.socketpair() + self.addCleanup(rd.close) + # wr closed explicitly by parent + + # single-byte payload guard us against partial recv + datas = [b"x", b"y", b"z"] + + pid = os.fork() + if pid == 0: + rd.close() + for data in datas: + # let the parent block on recv() + self._sleep() + wr.sendall(data) + os._exit(0) + else: + self.addCleanup(os.waitpid, pid, 0) + wr.close() + for data in datas: + self.assertEqual(data, recv_func(rd, len(data))) + + def test_recv(self): + self._test_recv(socket.socket.recv) + + @unittest.skipUnless(hasattr(socket.socket, 'recvmsg'), 'needs recvmsg()') + def test_recvmsg(self): + self._test_recv(lambda sock, data: sock.recvmsg(data)[0]) + + def _test_send(self, send_func): + rd, wr = socket.socketpair() + self.addCleanup(wr.close) + # rd closed explicitly by parent + + # we must send enough data for the send() to block + data = b"xyz" * (support.SOCK_MAX_SIZE // 3) + + pid = os.fork() + if pid == 0: + wr.close() + # let the parent block on send() + self._sleep() + received_data = bytearray(len(data)) + n = 0 + while n < len(data): + n += rd.recv_into(memoryview(received_data)[n:]) + self.assertEqual(received_data, data) + os._exit(0) + else: + rd.close() + written = 0 + while written < len(data): + sent = send_func(wr, memoryview(data)[written:]) + # sendall() returns None + written += len(data) if sent is None else sent + self.assertEqual(0, os.waitpid(pid, 0)[1]) + + def test_send(self): + self._test_send(socket.socket.send) + + def test_sendall(self): + self._test_send(socket.socket.sendall) + + @unittest.skipUnless(hasattr(socket.socket, 'sendmsg'), 'needs sendmsg()') + def test_sendmsg(self): + self._test_send(lambda sock, data: sock.sendmsg([data])) + + def test_accept(self): + sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) + self.addCleanup(sock.close) + + sock.bind((support.HOST, 0)) + _, port = sock.getsockname() + sock.listen() + + pid = os.fork() + if pid == 0: + # let parent block on accept() + self._sleep() + with socket.create_connection((support.HOST, port)): + self._sleep() + os._exit(0) + else: + self.addCleanup(os.waitpid, pid, 0) + client_sock, _ = sock.accept() + client_sock.close() + + +def test_main(): + support.run_unittest(OSEINTRTest, SocketEINTRTest) + + +if __name__ == "__main__": + test_main() diff -r fe0fddd6fd21 Lib/test/test_eintr.py --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Lib/test/test_eintr.py Thu Jan 29 19:53:06 2015 +0000 @@ -0,0 +1,20 @@ +import os +import signal +import unittest + +from test import script_helper, support + + + at unittest.skipUnless(os.name == "posix", "only supported on Unix") +class EINTRTests(unittest.TestCase): + + @unittest.skipUnless(hasattr(signal, "setitimer"), "requires setitimer()") + def test_all(self): + # Run the tester in a sub-process, to make sure there is only one + # thread (for reliable signal delivery). + tester = support.findfile("eintr_tester.py", subdir="eintrdata") + script_helper.assert_python_ok(tester) + + +if __name__ == "__main__": + unittest.main() diff -r fe0fddd6fd21 Lib/test/test_signal.py --- a/Lib/test/test_signal.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/test/test_signal.py Thu Jan 29 19:53:06 2015 +0000 @@ -587,7 +587,7 @@ r, w = os.pipe() def handler(signum, frame): - pass + 1 / 0 signal.signal(signal.SIGALRM, handler) if interrupt is not None: @@ -604,9 +604,8 @@ try: # blocking call: read from a pipe without data os.read(r, 1) - except OSError as err: - if err.errno != errno.EINTR: - raise + except ZeroDivisionError: + pass else: sys.exit(2) sys.exit(3) diff -r fe0fddd6fd21 Lib/test/test_socket.py --- a/Lib/test/test_socket.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/test/test_socket.py Thu Jan 29 19:53:06 2015 +0000 @@ -3590,7 +3590,7 @@ def setUp(self): super().setUp() orig_alrm_handler = signal.signal(signal.SIGALRM, - lambda signum, frame: None) + lambda signum, frame: 1 / 0) self.addCleanup(signal.signal, signal.SIGALRM, orig_alrm_handler) self.addCleanup(self.setAlarm, 0) @@ -3627,13 +3627,11 @@ self.serv.settimeout(self.timeout) def checkInterruptedRecv(self, func, *args, **kwargs): - # Check that func(*args, **kwargs) raises OSError with an + # Check that func(*args, **kwargs) raises # errno of EINTR when interrupted by a signal. self.setAlarm(self.alarm_time) - with self.assertRaises(OSError) as cm: + with self.assertRaises(ZeroDivisionError) as cm: func(*args, **kwargs) - self.assertNotIsInstance(cm.exception, socket.timeout) - self.assertEqual(cm.exception.errno, errno.EINTR) def testInterruptedRecvTimeout(self): self.checkInterruptedRecv(self.serv.recv, 1024) @@ -3689,12 +3687,10 @@ # Check that func(*args, **kwargs), run in a loop, raises # OSError with an errno of EINTR when interrupted by a # signal. - with self.assertRaises(OSError) as cm: + with self.assertRaises(ZeroDivisionError) as cm: while True: self.setAlarm(self.alarm_time) func(*args, **kwargs) - self.assertNotIsInstance(cm.exception, socket.timeout) - self.assertEqual(cm.exception.errno, errno.EINTR) # Issue #12958: The following tests have problems on OS X prior to 10.7 @support.requires_mac_ver(10, 7) @@ -4062,117 +4058,6 @@ pass -class FileObjectInterruptedTestCase(unittest.TestCase): - """Test that the file object correctly handles EINTR internally.""" - - class MockSocket(object): - def __init__(self, recv_funcs=()): - # A generator that returns callables that we'll call for each - # call to recv(). - self._recv_step = iter(recv_funcs) - - def recv_into(self, buffer): - data = next(self._recv_step)() - assert len(buffer) >= len(data) - buffer[:len(data)] = data - return len(data) - - def _decref_socketios(self): - pass - - def _textiowrap_for_test(self, buffering=-1): - raw = socket.SocketIO(self, "r") - if buffering < 0: - buffering = io.DEFAULT_BUFFER_SIZE - if buffering == 0: - return raw - buffer = io.BufferedReader(raw, buffering) - text = io.TextIOWrapper(buffer, None, None) - text.mode = "rb" - return text - - @staticmethod - def _raise_eintr(): - raise OSError(errno.EINTR, "interrupted") - - def _textiowrap_mock_socket(self, mock, buffering=-1): - raw = socket.SocketIO(mock, "r") - if buffering < 0: - buffering = io.DEFAULT_BUFFER_SIZE - if buffering == 0: - return raw - buffer = io.BufferedReader(raw, buffering) - text = io.TextIOWrapper(buffer, None, None) - text.mode = "rb" - return text - - def _test_readline(self, size=-1, buffering=-1): - mock_sock = self.MockSocket(recv_funcs=[ - lambda : b"This is the first line\nAnd the sec", - self._raise_eintr, - lambda : b"ond line is here\n", - lambda : b"", - lambda : b"", # XXX(gps): io library does an extra EOF read - ]) - fo = mock_sock._textiowrap_for_test(buffering=buffering) - self.assertEqual(fo.readline(size), "This is the first line\n") - self.assertEqual(fo.readline(size), "And the second line is here\n") - - def _test_read(self, size=-1, buffering=-1): - mock_sock = self.MockSocket(recv_funcs=[ - lambda : b"This is the first line\nAnd the sec", - self._raise_eintr, - lambda : b"ond line is here\n", - lambda : b"", - lambda : b"", # XXX(gps): io library does an extra EOF read - ]) - expecting = (b"This is the first line\n" - b"And the second line is here\n") - fo = mock_sock._textiowrap_for_test(buffering=buffering) - if buffering == 0: - data = b'' - else: - data = '' - expecting = expecting.decode('utf-8') - while len(data) != len(expecting): - part = fo.read(size) - if not part: - break - data += part - self.assertEqual(data, expecting) - - def test_default(self): - self._test_readline() - self._test_readline(size=100) - self._test_read() - self._test_read(size=100) - - def test_with_1k_buffer(self): - self._test_readline(buffering=1024) - self._test_readline(size=100, buffering=1024) - self._test_read(buffering=1024) - self._test_read(size=100, buffering=1024) - - def _test_readline_no_buffer(self, size=-1): - mock_sock = self.MockSocket(recv_funcs=[ - lambda : b"a", - lambda : b"\n", - lambda : b"B", - self._raise_eintr, - lambda : b"b", - lambda : b"", - ]) - fo = mock_sock._textiowrap_for_test(buffering=0) - self.assertEqual(fo.readline(size), b"a\n") - self.assertEqual(fo.readline(size), b"Bb") - - def test_no_buffer(self): - self._test_readline_no_buffer() - self._test_readline_no_buffer(size=4) - self._test_read(buffering=0) - self._test_read(size=100, buffering=0) - - class UnbufferedFileObjectClassTestCase(FileObjectClassTestCase): """Repeat the tests from FileObjectClassTestCase with bufsize==0. @@ -5388,7 +5273,6 @@ tests.extend([ NonBlockingTCPTests, FileObjectClassTestCase, - FileObjectInterruptedTestCase, UnbufferedFileObjectClassTestCase, LineBufferedFileObjectClassTestCase, SmallBufferedFileObjectClassTestCase, diff -r fe0fddd6fd21 Lib/test/test_subprocess.py --- a/Lib/test/test_subprocess.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/test/test_subprocess.py Thu Jan 29 19:53:06 2015 +0000 @@ -2421,25 +2421,6 @@ ProcessTestCase.tearDown(self) -class HelperFunctionTests(unittest.TestCase): - @unittest.skipIf(mswindows, "errno and EINTR make no sense on windows") - def test_eintr_retry_call(self): - record_calls = [] - def fake_os_func(*args): - record_calls.append(args) - if len(record_calls) == 2: - raise OSError(errno.EINTR, "fake interrupted system call") - return tuple(reversed(args)) - - self.assertEqual((999, 256), - subprocess._eintr_retry_call(fake_os_func, 256, 999)) - self.assertEqual([(256, 999)], record_calls) - # This time there will be an EINTR so it will loop once. - self.assertEqual((666,), - subprocess._eintr_retry_call(fake_os_func, 666)) - self.assertEqual([(256, 999), (666,), (666,)], record_calls) - - @unittest.skipUnless(mswindows, "Windows-specific tests") class CommandsWithSpaces (BaseTestCase): @@ -2528,7 +2509,6 @@ Win32ProcessTestCase, CommandTests, ProcessTestCaseNoPoll, - HelperFunctionTests, CommandsWithSpaces, ContextManagerTests, ) diff -r fe0fddd6fd21 Modules/_io/fileio.c --- a/Modules/_io/fileio.c Sun Jan 18 11:17:39 2015 +0200 +++ b/Modules/_io/fileio.c Thu Jan 29 19:53:06 2015 +0000 @@ -550,7 +550,7 @@ { Py_buffer pbuf; Py_ssize_t n, len; - int err; + int err, async_err = 0; if (self->fd < 0) return err_closed(); @@ -562,16 +562,19 @@ if (_PyVerify_fd(self->fd)) { len = pbuf.len; - Py_BEGIN_ALLOW_THREADS - errno = 0; + do { + Py_BEGIN_ALLOW_THREADS + errno = 0; #ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - n = read(self->fd, pbuf.buf, (int)len); + if (len > INT_MAX) + len = INT_MAX; + n = read(self->fd, pbuf.buf, (int)len); #else - n = read(self->fd, pbuf.buf, len); + n = read(self->fd, pbuf.buf, len); #endif - Py_END_ALLOW_THREADS + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); } else n = -1; err = errno; @@ -580,7 +583,8 @@ if (err == EAGAIN) Py_RETURN_NONE; errno = err; - PyErr_SetFromErrno(PyExc_IOError); + if (!async_err) + PyErr_SetFromErrno(PyExc_IOError); return NULL; } @@ -627,6 +631,7 @@ Py_ssize_t bytes_read = 0; Py_ssize_t n; size_t bufsize; + int async_err = 0; if (self->fd < 0) return err_closed(); @@ -673,27 +678,23 @@ return NULL; } } - Py_BEGIN_ALLOW_THREADS - errno = 0; - n = bufsize - bytes_read; + do { + Py_BEGIN_ALLOW_THREADS + errno = 0; + n = bufsize - bytes_read; #ifdef MS_WINDOWS - if (n > INT_MAX) - n = INT_MAX; - n = read(self->fd, PyBytes_AS_STRING(result) + bytes_read, (int)n); + if (n > INT_MAX) + n = INT_MAX; + n = read(self->fd, PyBytes_AS_STRING(result) + bytes_read, (int)n); #else - n = read(self->fd, PyBytes_AS_STRING(result) + bytes_read, n); + n = read(self->fd, PyBytes_AS_STRING(result) + bytes_read, n); #endif - Py_END_ALLOW_THREADS + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); if (n == 0) break; if (n < 0) { - if (errno == EINTR) { - if (PyErr_CheckSignals()) { - Py_DECREF(result); - return NULL; - } - continue; - } if (errno == EAGAIN) { if (bytes_read > 0) break; @@ -701,7 +702,8 @@ Py_RETURN_NONE; } Py_DECREF(result); - PyErr_SetFromErrno(PyExc_IOError); + if (!async_err) + PyErr_SetFromErrno(PyExc_IOError); return NULL; } bytes_read += n; @@ -723,6 +725,7 @@ char *ptr; Py_ssize_t n; Py_ssize_t size = -1; + int async_err = 0; PyObject *bytes; if (self->fd < 0) @@ -747,14 +750,17 @@ ptr = PyBytes_AS_STRING(bytes); if (_PyVerify_fd(self->fd)) { - Py_BEGIN_ALLOW_THREADS - errno = 0; + do { + Py_BEGIN_ALLOW_THREADS + errno = 0; #ifdef MS_WINDOWS - n = read(self->fd, ptr, (int)size); + n = read(self->fd, ptr, (int)size); #else - n = read(self->fd, ptr, size); + n = read(self->fd, ptr, size); #endif - Py_END_ALLOW_THREADS + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); } else n = -1; @@ -764,7 +770,8 @@ if (err == EAGAIN) Py_RETURN_NONE; errno = err; - PyErr_SetFromErrno(PyExc_IOError); + if (!async_err) + PyErr_SetFromErrno(PyExc_IOError); return NULL; } @@ -783,7 +790,7 @@ { Py_buffer pbuf; Py_ssize_t n, len; - int err; + int err, async_err = 0; if (self->fd < 0) return err_closed(); @@ -794,24 +801,26 @@ return NULL; if (_PyVerify_fd(self->fd)) { - Py_BEGIN_ALLOW_THREADS - errno = 0; - len = pbuf.len; + do { + Py_BEGIN_ALLOW_THREADS + errno = 0; + len = pbuf.len; #ifdef MS_WINDOWS - if (len > 32767 && isatty(self->fd)) { - /* Issue #11395: the Windows console returns an error (12: not - enough space error) on writing into stdout if stdout mode is - binary and the length is greater than 66,000 bytes (or less, - depending on heap usage). */ - len = 32767; - } - else if (len > INT_MAX) - len = INT_MAX; - n = write(self->fd, pbuf.buf, (int)len); + if (len > 32767 && isatty(self->fd)) { + /* Issue #11395: the Windows console returns an error (12: not + enough space error) on writing into stdout if stdout mode is + binary and the length is greater than 66,000 bytes (or less, + depending on heap usage). */ + len = 32767; + } else if (len > INT_MAX) + len = INT_MAX; + n = write(self->fd, pbuf.buf, (int)len); #else - n = write(self->fd, pbuf.buf, len); + n = write(self->fd, pbuf.buf, len); #endif - Py_END_ALLOW_THREADS + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); } else n = -1; err = errno; @@ -822,7 +831,8 @@ if (err == EAGAIN) Py_RETURN_NONE; errno = err; - PyErr_SetFromErrno(PyExc_IOError); + if (!async_err) + PyErr_SetFromErrno(PyExc_IOError); return NULL; } diff -r fe0fddd6fd21 Modules/posixmodule.c --- a/Modules/posixmodule.c Sun Jan 18 11:17:39 2015 +0200 +++ b/Modules/posixmodule.c Thu Jan 29 19:53:06 2015 +0000 @@ -1361,13 +1361,16 @@ posix_fildes_fd(int fd, int (*func)(int)) { int res; - Py_BEGIN_ALLOW_THREADS - res = (*func)(fd); - Py_END_ALLOW_THREADS - if (res < 0) - return posix_error(); - Py_INCREF(Py_None); - return Py_None; + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + res = (*func)(fd); + Py_END_ALLOW_THREADS + } while (res != 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res != 0) + return (!async_err) ? posix_error() : NULL; + Py_RETURN_NONE; } @@ -3479,11 +3482,16 @@ /*[clinic end generated code: output=3c19fbfd724a8e0f input=8ab11975ca01ee5b]*/ { int res; - Py_BEGIN_ALLOW_THREADS - res = fchmod(fd, mode); - Py_END_ALLOW_THREADS - if (res < 0) - return posix_error(); + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + res = fchmod(fd, mode); + Py_END_ALLOW_THREADS + } while (res != 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res != 0) + return (!async_err) ? posix_error() : NULL; + Py_RETURN_NONE; } #endif /* HAVE_FCHMOD */ @@ -4104,11 +4112,16 @@ /*[clinic end generated code: output=687781cb7d8974d6 input=3af544ba1b13a0d7]*/ { int res; - Py_BEGIN_ALLOW_THREADS - res = fchown(fd, uid, gid); - Py_END_ALLOW_THREADS - if (res < 0) - return posix_error(); + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + res = fchown(fd, uid, gid); + Py_END_ALLOW_THREADS + } while (res != 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res != 0) + return (!async_err) ? posix_error() : NULL; + Py_RETURN_NONE; } #endif /* HAVE_FCHOWN */ @@ -9602,12 +9615,17 @@ { pid_t pid; struct rusage ru; + int async_err = 0; WAIT_TYPE status; WAIT_STATUS_INT(status) = 0; - Py_BEGIN_ALLOW_THREADS - pid = wait3(&status, options, &ru); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + pid = wait3(&status, options, &ru); + Py_END_ALLOW_THREADS + } while (pid < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (pid < 0) + return (!async_err) ? posix_error() : NULL; return wait_helper(pid, WAIT_STATUS_INT(status), &ru); } @@ -9665,15 +9683,21 @@ os_wait4_impl(PyModuleDef *module, pid_t pid, int options) /*[clinic end generated code: output=20dfb05289d37dc6 input=d11deed0750600ba]*/ { + pid_t res; struct rusage ru; + int async_err = 0; WAIT_TYPE status; WAIT_STATUS_INT(status) = 0; - Py_BEGIN_ALLOW_THREADS - pid = wait4(pid, &status, options, &ru); - Py_END_ALLOW_THREADS - - return wait_helper(pid, WAIT_STATUS_INT(status), &ru); + do { + Py_BEGIN_ALLOW_THREADS + res = wait4(pid, &status, options, &ru); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res < 0) + return (!async_err) ? posix_error() : NULL; + + return wait_helper(res, WAIT_STATUS_INT(status), &ru); } #endif /* HAVE_WAIT4 */ @@ -9744,14 +9768,17 @@ { PyObject *result; int res; + int async_err = 0; siginfo_t si; si.si_pid = 0; - Py_BEGIN_ALLOW_THREADS - res = waitid(idtype, id, &si, options); - Py_END_ALLOW_THREADS - if (res == -1) - return posix_error(); + do { + Py_BEGIN_ALLOW_THREADS + res = waitid(idtype, id, &si, options); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res < 0) + return (!async_err) ? posix_error() : NULL; if (si.si_pid == 0) Py_RETURN_NONE; @@ -9828,16 +9855,20 @@ os_waitpid_impl(PyModuleDef *module, pid_t pid, int options) /*[clinic end generated code: output=095a6b00af70b7ac input=0bf1666b8758fda3]*/ { + pid_t res; + int async_err = 0; WAIT_TYPE status; WAIT_STATUS_INT(status) = 0; - Py_BEGIN_ALLOW_THREADS - pid = waitpid(pid, &status, options); - Py_END_ALLOW_THREADS - if (pid == -1) - return posix_error(); - - return Py_BuildValue("Ni", PyLong_FromPid(pid), WAIT_STATUS_INT(status)); + do { + Py_BEGIN_ALLOW_THREADS + res = waitpid(pid, &status, options); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res < 0) + return (!async_err) ? posix_error() : NULL; + + return Py_BuildValue("Ni", PyLong_FromPid(res), WAIT_STATUS_INT(status)); } #elif defined(HAVE_CWAIT) /* MS C has a variant of waitpid() that's usable for most purposes. */ @@ -9894,15 +9925,19 @@ /*[clinic end generated code: output=c20b95b15ad44a3a input=444c8f51cca5b862]*/ { int status; - - Py_BEGIN_ALLOW_THREADS - pid = _cwait(&status, pid, options); - Py_END_ALLOW_THREADS - if (pid == -1) - return posix_error(); + Py_intptr_t res; + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + res = _cwait(&status, pid, options); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res != 0) + return (!async_err) ? posix_error() : NULL; /* shift the status left a byte so this is more like the POSIX waitpid */ - return Py_BuildValue(_Py_PARSE_INTPTR "i", pid, status << 8); + return Py_BuildValue(_Py_PARSE_INTPTR "i", res, status << 8); } #endif @@ -9943,14 +9978,17 @@ /*[clinic end generated code: output=2a83a9d164e7e6a8 input=03b0182d4a4700ce]*/ { pid_t pid; + int async_err = 0; WAIT_TYPE status; WAIT_STATUS_INT(status) = 0; - Py_BEGIN_ALLOW_THREADS - pid = wait(&status); - Py_END_ALLOW_THREADS - if (pid == -1) - return posix_error(); + do { + Py_BEGIN_ALLOW_THREADS + pid = wait(&status); + Py_END_ALLOW_THREADS + } while (pid < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (pid < 0) + return (!async_err) ? posix_error() : NULL; return Py_BuildValue("Ni", PyLong_FromPid(pid), WAIT_STATUS_INT(status)); } @@ -11080,6 +11118,7 @@ /*[clinic end generated code: output=531e482dd11a99a0 input=76e96f511be0352f]*/ { int res; + int async_err = 0; #if defined(HAVE_DUP3) && \ !(defined(HAVE_FCNTL_H) && defined(F_DUP2FD_CLOEXEC)) /* dup3() is available on Linux 2.6.27+ and glibc 2.9 */ @@ -11103,38 +11142,46 @@ } #elif defined(HAVE_FCNTL_H) && defined(F_DUP2FD_CLOEXEC) - Py_BEGIN_ALLOW_THREADS - if (!inheritable) - res = fcntl(fd, F_DUP2FD_CLOEXEC, fd2); - else - res = dup2(fd, fd2); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + if (!inheritable) + res = fcntl(fd, F_DUP2FD_CLOEXEC, fd2); + else + res = dup2(fd, fd2); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (res < 0) - return posix_error(); + return (!async_err) ? posix_error() : NULL; #else #ifdef HAVE_DUP3 if (!inheritable && dup3_works != 0) { - Py_BEGIN_ALLOW_THREADS - res = dup3(fd, fd2, O_CLOEXEC); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + res = dup3(fd, fd2, O_CLOEXEC); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); if (res < 0) { if (dup3_works == -1) dup3_works = (errno != ENOSYS); if (dup3_works) - return posix_error(); + return (!async_err) ? posix_error() : NULL; } } if (inheritable || dup3_works == 0) { #endif - Py_BEGIN_ALLOW_THREADS - res = dup2(fd, fd2); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + res = dup2(fd, fd2); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); if (res < 0) - return posix_error(); + return (!async_err) ? posix_error() : NULL; if (!inheritable && _Py_set_inheritable(fd2, 0, NULL) < 0) { close(fd2); @@ -11355,6 +11402,7 @@ /*[clinic end generated code: output=1f3bc27260a24968 input=1df2eaa27c0bf1d3]*/ { Py_ssize_t n; + int async_err = 0; PyObject *buffer; if (length < 0) { @@ -11375,13 +11423,16 @@ buffer = PyBytes_FromStringAndSize((char *)NULL, length); if (buffer == NULL) return NULL; - Py_BEGIN_ALLOW_THREADS - n = read(fd, PyBytes_AS_STRING(buffer), READ_CAST length); - Py_END_ALLOW_THREADS + + do { + Py_BEGIN_ALLOW_THREADS + n = read(fd, PyBytes_AS_STRING(buffer), READ_CAST length); + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (n < 0) { Py_DECREF(buffer); - return posix_error(); + return (!async_err) ? posix_error() : NULL; } if (n != length) @@ -11515,6 +11566,7 @@ { int cnt; Py_ssize_t n; + int async_err = 0; struct iovec *iov; Py_buffer *buf; @@ -11529,13 +11581,16 @@ if (iov_setup(&iov, &buf, buffers, cnt, PyBUF_WRITABLE) < 0) return -1; - Py_BEGIN_ALLOW_THREADS - n = readv(fd, iov, cnt); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + n = readv(fd, iov, cnt); + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); iov_cleanup(iov, buf, cnt); if (n < 0) { - posix_error(); + if (!async_err) + posix_error(); return -1; } @@ -11598,6 +11653,7 @@ /*[clinic end generated code: output=7b62bf6c06e20ae8 input=084948dcbaa35d4c]*/ { Py_ssize_t n; + int async_err = 0; PyObject *buffer; if (length < 0) { @@ -11611,12 +11667,16 @@ Py_DECREF(buffer); return posix_error(); } - Py_BEGIN_ALLOW_THREADS - n = pread(fd, PyBytes_AS_STRING(buffer), length, offset); - Py_END_ALLOW_THREADS + + do { + Py_BEGIN_ALLOW_THREADS + n = pread(fd, PyBytes_AS_STRING(buffer), length, offset); + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (n < 0) { Py_DECREF(buffer); - return posix_error(); + return (!async_err) ? posix_error() : NULL; } if (n != length) _PyBytes_Resize(&buffer, n); @@ -11677,6 +11737,7 @@ /*[clinic end generated code: output=aeb96acfdd4d5112 input=3207e28963234f3c]*/ { Py_ssize_t size; + int async_err = 0; Py_ssize_t len = data->len; if (!_PyVerify_fd(fd)) { @@ -11684,17 +11745,21 @@ return -1; } - Py_BEGIN_ALLOW_THREADS -#ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - size = write(fd, data->buf, (int)len); -#else - size = write(fd, data->buf, len); -#endif - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS +#ifdef MS_WINDOWS + if (len > INT_MAX) + len = INT_MAX; + size = write(fd, data->buf, (int)len); +#else + size = write(fd, data->buf, len); +#endif + Py_END_ALLOW_THREADS + } while (size < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (size < 0) { - posix_error(); + if (!async_err) + posix_error(); return -1; } return size; @@ -11713,6 +11778,7 @@ { int in, out; Py_ssize_t ret; + int async_err = 0; off_t offset; #if defined(__FreeBSD__) || defined(__DragonFly__) || defined(__APPLE__) @@ -11775,13 +11841,15 @@ } } - Py_BEGIN_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS #ifdef __APPLE__ - ret = sendfile(in, out, offset, &sbytes, &sf, flags); -#else - ret = sendfile(in, out, offset, len, &sf, &sbytes, flags); -#endif - Py_END_ALLOW_THREADS + ret = sendfile(in, out, offset, &sbytes, &sf, flags); +#else + ret = sendfile(in, out, offset, len, &sf, &sbytes, flags); +#endif + Py_END_ALLOW_THREADS + } while (ret < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (sf.headers != NULL) iov_cleanup(sf.headers, hbuf, sf.hdr_cnt); @@ -11800,7 +11868,7 @@ return posix_error(); } } - return posix_error(); + return (!async_err) ? posix_error() : NULL; } goto done; @@ -11821,21 +11889,26 @@ return NULL; #ifdef linux if (offobj == Py_None) { + do { + Py_BEGIN_ALLOW_THREADS + ret = sendfile(out, in, NULL, count); + Py_END_ALLOW_THREADS + } while (ret < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (ret < 0) + return (!async_err) ? posix_error() : NULL; + return Py_BuildValue("n", ret); + } +#endif + if (!Py_off_t_converter(offobj, &offset)) + return NULL; + + do { Py_BEGIN_ALLOW_THREADS - ret = sendfile(out, in, NULL, count); + ret = sendfile(out, in, &offset, count); Py_END_ALLOW_THREADS - if (ret < 0) - return posix_error(); - return Py_BuildValue("n", ret); - } -#endif - if (!Py_off_t_converter(offobj, &offset)) - return NULL; - Py_BEGIN_ALLOW_THREADS - ret = sendfile(out, in, &offset, count); - Py_END_ALLOW_THREADS + } while (ret < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (ret < 0) - return posix_error(); + return (!async_err) ? posix_error() : NULL; return Py_BuildValue("n", ret); #endif } @@ -11891,15 +11964,18 @@ { STRUCT_STAT st; int res; - - Py_BEGIN_ALLOW_THREADS - res = FSTAT(fd, &st); - Py_END_ALLOW_THREADS + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + res = FSTAT(fd, &st); + Py_END_ALLOW_THREADS + } while (res != 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (res != 0) { #ifdef MS_WINDOWS return PyErr_SetFromWindowsErr(0); #else - return posix_error(); + return (!async_err) ? posix_error() : NULL; #endif } @@ -12185,6 +12261,7 @@ { int cnt; Py_ssize_t result; + int async_err = 0; struct iovec *iov; Py_buffer *buf; @@ -12199,12 +12276,14 @@ return -1; } - Py_BEGIN_ALLOW_THREADS - result = writev(fd, iov, cnt); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + result = writev(fd, iov, cnt); + Py_END_ALLOW_THREADS + } while (result < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); iov_cleanup(iov, buf, cnt); - if (result < 0) + if (result < 0 && !async_err) posix_error(); return result; @@ -12275,17 +12354,20 @@ /*[clinic end generated code: output=ec9cc5b2238e96a7 input=19903f1b3dd26377]*/ { Py_ssize_t size; + int async_err = 0; if (!_PyVerify_fd(fd)) { posix_error(); return -1; } - Py_BEGIN_ALLOW_THREADS - size = pwrite(fd, buffer->buf, (size_t)buffer->len, offset); - Py_END_ALLOW_THREADS - - if (size < 0) + do { + Py_BEGIN_ALLOW_THREADS + size = pwrite(fd, buffer->buf, (size_t)buffer->len, offset); + Py_END_ALLOW_THREADS + } while (size < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + + if (size < 0 && !async_err) posix_error(); return size; } @@ -12353,18 +12435,21 @@ /*[clinic end generated code: output=b3321927546893d0 input=73032e98a36e0e19]*/ { int result; - - Py_BEGIN_ALLOW_THREADS + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS #ifdef HAVE_MKFIFOAT - if (dir_fd != DEFAULT_DIR_FD) - result = mkfifoat(dir_fd, path->narrow, mode); - else -#endif - result = mkfifo(path->narrow, mode); - Py_END_ALLOW_THREADS - - if (result < 0) - return posix_error(); + if (dir_fd != DEFAULT_DIR_FD) + result = mkfifoat(dir_fd, path->narrow, mode); + else +#endif + result = mkfifo(path->narrow, mode); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); + if (result != 0) + return (!async_err) ? posix_error() : NULL; Py_RETURN_NONE; } @@ -12448,18 +12533,21 @@ /*[clinic end generated code: output=f71d54eaf9bb6f1a input=ee44531551a4d83b]*/ { int result; - - Py_BEGIN_ALLOW_THREADS + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS #ifdef HAVE_MKNODAT - if (dir_fd != DEFAULT_DIR_FD) - result = mknodat(dir_fd, path->narrow, mode, device); - else -#endif - result = mknod(path->narrow, mode, device); - Py_END_ALLOW_THREADS - - if (result < 0) - return posix_error(); + if (dir_fd != DEFAULT_DIR_FD) + result = mknodat(dir_fd, path->narrow, mode, device); + else +#endif + result = mknod(path->narrow, mode, device); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); + if (result != 0) + return (!async_err) ? posix_error() : NULL; Py_RETURN_NONE; } @@ -12662,12 +12750,16 @@ /*[clinic end generated code: output=62326766cb9b76bf input=63b43641e52818f2]*/ { int result; - - Py_BEGIN_ALLOW_THREADS - result = ftruncate(fd, length); - Py_END_ALLOW_THREADS - if (result < 0) - return posix_error(); + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + result = ftruncate(fd, length); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); + if (result != 0) + return (!async_err) ? posix_error() : NULL; Py_RETURN_NONE; } #endif /* HAVE_FTRUNCATE */ @@ -12805,14 +12897,16 @@ /*[clinic end generated code: output=0cd702d2065c79db input=d7a2ef0ab2ca52fb]*/ { int result; - - Py_BEGIN_ALLOW_THREADS - result = posix_fallocate(fd, offset, length); - Py_END_ALLOW_THREADS - if (result != 0) { - errno = result; - return posix_error(); - } + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + result = posix_fallocate(fd, offset, length); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); + if (result != 0) + return (!async_err) ? posix_error() : NULL; Py_RETURN_NONE; } #endif /* HAVE_POSIX_FALLOCATE) && !POSIX_FADVISE_AIX_BUG */ @@ -12883,14 +12977,16 @@ /*[clinic end generated code: output=dad93f32c04dd4f7 input=0fbe554edc2f04b5]*/ { int result; - - Py_BEGIN_ALLOW_THREADS - result = posix_fadvise(fd, offset, length, advice); - Py_END_ALLOW_THREADS - if (result != 0) { - errno = result; - return posix_error(); - } + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + result = posix_fadvise(fd, offset, length, advice); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); + if (result != 0) + return (!async_err) ? posix_error() : NULL; Py_RETURN_NONE; } #endif /* HAVE_POSIX_FADVISE && !POSIX_FADVISE_AIX_BUG */ @@ -13745,13 +13841,17 @@ /*[clinic end generated code: output=0e32bf07f946ec0d input=d8122243ac50975e]*/ { int result; + int async_err = 0; struct statvfs st; - Py_BEGIN_ALLOW_THREADS - result = fstatvfs(fd, &st); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + result = fstatvfs(fd, &st); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); if (result != 0) - return posix_error(); + return (!async_err) ? posix_error() : NULL; return _pystatvfs_fromstructstatvfs(st); } diff -r fe0fddd6fd21 Modules/socketmodule.c --- a/Modules/socketmodule.c Sun Jan 18 11:17:39 2015 +0200 +++ b/Modules/socketmodule.c Thu Jan 29 19:53:06 2015 +0000 @@ -2037,6 +2037,7 @@ PyObject *addr = NULL; PyObject *res = NULL; int timeout; + int async_err = 0; #if defined(HAVE_ACCEPT4) && defined(SOCK_CLOEXEC) /* accept4() is available on Linux 2.6.28+ and glibc 2.10 */ static int accept4_works = -1; @@ -2050,27 +2051,27 @@ return select_error(); BEGIN_SELECT_LOOP(s) - - Py_BEGIN_ALLOW_THREADS - timeout = internal_select_ex(s, 0, interval); - if (!timeout) { + do { + Py_BEGIN_ALLOW_THREADS + timeout = internal_select_ex(s, 0, interval); + if (!timeout) { #if defined(HAVE_ACCEPT4) && defined(SOCK_CLOEXEC) - if (accept4_works != 0) { - newfd = accept4(s->sock_fd, SAS2SA(&addrbuf), &addrlen, - SOCK_CLOEXEC); - if (newfd == INVALID_SOCKET && accept4_works == -1) { - /* On Linux older than 2.6.28, accept4() fails with ENOSYS */ - accept4_works = (errno != ENOSYS); + if (accept4_works != 0) { + newfd = accept4(s->sock_fd, SAS2SA(&addrbuf), &addrlen, + SOCK_CLOEXEC); + if (newfd == INVALID_SOCKET && accept4_works == -1) { + /* On Linux older than 2.6.28, accept4() fails with ENOSYS */ + accept4_works = (errno != ENOSYS); + } } + if (accept4_works == 0) + newfd = accept(s->sock_fd, SAS2SA(&addrbuf), &addrlen); +#else + newfd = accept(s->sock_fd, SAS2SA(&addrbuf), &addrlen); +#endif } - if (accept4_works == 0) - newfd = accept(s->sock_fd, SAS2SA(&addrbuf), &addrlen); -#else - newfd = accept(s->sock_fd, SAS2SA(&addrbuf), &addrlen); -#endif - } - Py_END_ALLOW_THREADS - + Py_END_ALLOW_THREADS + } while (newfd < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (timeout == 1) { PyErr_SetString(socket_timeout, "timed out"); return NULL; @@ -2078,7 +2079,7 @@ END_SELECT_LOOP(s) if (newfd == INVALID_SOCKET) - return s->errorhandler(); + return (!async_err) ? s->errorhandler() : NULL; #ifdef MS_WINDOWS if (!SetHandleInformation((HANDLE)newfd, HANDLE_FLAG_INHERIT, 0)) { @@ -2513,10 +2514,8 @@ /* Signals are not errors (though they may raise exceptions). Adapted from PyErr_SetFromErrnoWithFilenameObject(). */ -#ifdef EINTR if (res == EINTR && PyErr_CheckSignals()) return NULL; -#endif return PyLong_FromLong((long) res); } @@ -2650,6 +2649,7 @@ { Py_ssize_t outlen = -1; int timeout; + int async_err = 0; if (!IS_SELECTABLE(s)) { select_error(); @@ -2661,18 +2661,20 @@ } BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS - timeout = internal_select_ex(s, 0, interval); - if (!timeout) { + do { + Py_BEGIN_ALLOW_THREADS + timeout = internal_select_ex(s, 0, interval); + if (!timeout) { #ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - outlen = recv(s->sock_fd, cbuf, (int)len, flags); + if (len > INT_MAX) + len = INT_MAX; + outlen = recv(s->sock_fd, cbuf, (int)len, flags); #else - outlen = recv(s->sock_fd, cbuf, len, flags); -#endif - } - Py_END_ALLOW_THREADS + outlen = recv(s->sock_fd, cbuf, len, flags); +#endif + } + Py_END_ALLOW_THREADS + } while (outlen < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (timeout == 1) { PyErr_SetString(socket_timeout, "timed out"); @@ -2682,7 +2684,8 @@ if (outlen < 0) { /* Note: the call to errorhandler() ALWAYS indirectly returned NULL, so ignore its return value */ - s->errorhandler(); + if (!async_err) + s->errorhandler(); return -1; } return outlen; @@ -2819,6 +2822,7 @@ int timeout; Py_ssize_t n = -1; socklen_t addrlen; + int async_err = 0; *addr = NULL; @@ -2831,21 +2835,23 @@ } BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS - memset(&addrbuf, 0, addrlen); - timeout = internal_select_ex(s, 0, interval); - if (!timeout) { + do { + Py_BEGIN_ALLOW_THREADS + memset(&addrbuf, 0, addrlen); + timeout = internal_select_ex(s, 0, interval); + if (!timeout) { #ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - n = recvfrom(s->sock_fd, cbuf, (int)len, flags, - (void *) &addrbuf, &addrlen); + if (len > INT_MAX) + len = INT_MAX; + n = recvfrom(s->sock_fd, cbuf, (int)len, flags, + (void *) &addrbuf, &addrlen); #else - n = recvfrom(s->sock_fd, cbuf, len, flags, - SAS2SA(&addrbuf), &addrlen); -#endif - } - Py_END_ALLOW_THREADS + n = recvfrom(s->sock_fd, cbuf, len, flags, + SAS2SA(&addrbuf), &addrlen); +#endif + } + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (timeout == 1) { PyErr_SetString(socket_timeout, "timed out"); @@ -2853,7 +2859,8 @@ } END_SELECT_LOOP(s) if (n < 0) { - s->errorhandler(); + if (!async_err) + s->errorhandler(); return -1; } @@ -2993,6 +3000,7 @@ { ssize_t bytes_received = -1; int timeout; + int async_err = 0; sock_addr_t addrbuf; socklen_t addrbuflen; struct msghdr msg = {0}; @@ -3028,25 +3036,29 @@ } BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS; - msg.msg_name = SAS2SA(&addrbuf); - msg.msg_namelen = addrbuflen; - msg.msg_iov = iov; - msg.msg_iovlen = iovlen; - msg.msg_control = controlbuf; - msg.msg_controllen = controllen; - timeout = internal_select_ex(s, 0, interval); - if (!timeout) - bytes_received = recvmsg(s->sock_fd, &msg, flags); - Py_END_ALLOW_THREADS; - if (timeout == 1) { - PyErr_SetString(socket_timeout, "timed out"); - goto finally; - } + do { + Py_BEGIN_ALLOW_THREADS; + msg.msg_name = SAS2SA(&addrbuf); + msg.msg_namelen = addrbuflen; + msg.msg_iov = iov; + msg.msg_iovlen = iovlen; + msg.msg_control = controlbuf; + msg.msg_controllen = controllen; + timeout = internal_select_ex(s, 0, interval); + if (!timeout) + bytes_received = recvmsg(s->sock_fd, &msg, flags); + Py_END_ALLOW_THREADS; + if (timeout == 1) { + PyErr_SetString(socket_timeout, "timed out"); + goto finally; + } + } while (bytes_received < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); END_SELECT_LOOP(s) if (bytes_received < 0) { - s->errorhandler(); + if (!async_err) + s->errorhandler(); goto finally; } @@ -3305,6 +3317,7 @@ { char *buf; Py_ssize_t len, n = -1; + int async_err = 0; int flags = 0, timeout; Py_buffer pbuf; @@ -3319,18 +3332,20 @@ len = pbuf.len; BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS - timeout = internal_select_ex(s, 1, interval); - if (!timeout) { + do { + Py_BEGIN_ALLOW_THREADS + timeout = internal_select_ex(s, 1, interval); + if (!timeout) { #ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - n = send(s->sock_fd, buf, (int)len, flags); + if (len > INT_MAX) + len = INT_MAX; + n = send(s->sock_fd, buf, (int)len, flags); #else - n = send(s->sock_fd, buf, len, flags); -#endif - } - Py_END_ALLOW_THREADS + n = send(s->sock_fd, buf, len, flags); +#endif + } + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (timeout == 1) { PyBuffer_Release(&pbuf); PyErr_SetString(socket_timeout, "timed out"); @@ -3340,7 +3355,7 @@ PyBuffer_Release(&pbuf); if (n < 0) - return s->errorhandler(); + return (!async_err) ? s->errorhandler() : NULL; return PyLong_FromSsize_t(n); } @@ -3359,7 +3374,8 @@ { char *buf; Py_ssize_t len, n = -1; - int flags = 0, timeout, saved_errno; + int async_err = 0; + int flags = 0, timeout; Py_buffer pbuf; if (!PyArg_ParseTuple(args, "y*|i:sendall", &pbuf, &flags)) @@ -3391,29 +3407,16 @@ PyErr_SetString(socket_timeout, "timed out"); return NULL; } - /* PyErr_CheckSignals() might change errno */ - saved_errno = errno; - /* We must run our signal handlers before looping again. - send() can return a successful partial write when it is - interrupted, so we can't restrict ourselves to EINTR. */ - if (PyErr_CheckSignals()) { - PyBuffer_Release(&pbuf); - return NULL; + if (n >= 0) { + buf += n; + len -= n; } - if (n < 0) { - /* If interrupted, try again */ - if (saved_errno == EINTR) - continue; - else - break; - } - buf += n; - len -= n; - } while (len > 0); + } while (len > 0 && (n >= 0 || errno == EINTR) && + !(async_err = PyErr_CheckSignals())); PyBuffer_Release(&pbuf); - if (n < 0) - return s->errorhandler(); + if (n < 0 || async_err) + return (!async_err) ? s->errorhandler() : NULL; Py_INCREF(Py_None); return Py_None; @@ -3439,6 +3442,7 @@ Py_ssize_t len, arglen; sock_addr_t addrbuf; int addrlen, n = -1, flags, timeout; + int async_err = 0; flags = 0; arglen = PyTuple_Size(args); @@ -3473,20 +3477,22 @@ } BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS - timeout = internal_select_ex(s, 1, interval); - if (!timeout) { + do { + Py_BEGIN_ALLOW_THREADS + timeout = internal_select_ex(s, 1, interval); + if (!timeout) { #ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - n = sendto(s->sock_fd, buf, (int)len, flags, - SAS2SA(&addrbuf), addrlen); + if (len > INT_MAX) + len = INT_MAX; + n = sendto(s->sock_fd, buf, (int)len, flags, + SAS2SA(&addrbuf), addrlen); #else - n = sendto(s->sock_fd, buf, len, flags, - SAS2SA(&addrbuf), addrlen); -#endif - } - Py_END_ALLOW_THREADS + n = sendto(s->sock_fd, buf, len, flags, + SAS2SA(&addrbuf), addrlen); +#endif + } + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (timeout == 1) { PyBuffer_Release(&pbuf); @@ -3496,7 +3502,7 @@ END_SELECT_LOOP(s) PyBuffer_Release(&pbuf); if (n < 0) - return s->errorhandler(); + return (!async_err) ? s->errorhandler() : NULL; return PyLong_FromSsize_t(n); } @@ -3528,6 +3534,7 @@ void *controlbuf = NULL; size_t controllen, controllen_last; ssize_t bytes_sent = -1; + int async_err = 0; int addrlen, timeout, flags = 0; PyObject *data_arg, *cmsg_arg = NULL, *addr_arg = NULL, *data_fast = NULL, *cmsg_fast = NULL, *retval = NULL; @@ -3685,19 +3692,23 @@ } BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS; - timeout = internal_select_ex(s, 1, interval); - if (!timeout) - bytes_sent = sendmsg(s->sock_fd, &msg, flags); - Py_END_ALLOW_THREADS; - if (timeout == 1) { - PyErr_SetString(socket_timeout, "timed out"); - goto finally; - } + do { + Py_BEGIN_ALLOW_THREADS; + timeout = internal_select_ex(s, 1, interval); + if (!timeout) + bytes_sent = sendmsg(s->sock_fd, &msg, flags); + Py_END_ALLOW_THREADS; + if (timeout == 1) { + PyErr_SetString(socket_timeout, "timed out"); + goto finally; + } + } while (bytes_sent < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); END_SELECT_LOOP(s) if (bytes_sent < 0) { - s->errorhandler(); + if (!async_err) + s->errorhandler(); goto finally; } retval = PyLong_FromSsize_t(bytes_sent); From report at bugs.python.org Thu Jan 29 22:07:58 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 29 Jan 2015 21:07:58 +0000 Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za> Message-ID: <1422565678.74.0.00334870020642.issue17797@psf.upfronthosting.co.za> Steve Dower added the comment: It's not supported for building Python, is what I meant. I don't know what the status is for Microsoft support of VS2012, but I'd expect it's security fix only by now. Being able to support building Python with alternative compilers is a task that we don't have the volunteers to support, especially on Windows. That said, I'm not against taking patches like this to improve it, but I'd expect they'll be treated as an enhancement and won't make it into any version before 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 22:21:04 2015 From: report at bugs.python.org (Davin Potts) Date: Thu, 29 Jan 2015 21:21:04 +0000 Subject: [issue8094] Multiprocessing infinite loop In-Reply-To: <1268125314.35.0.202558750367.issue8094@psf.upfronthosting.co.za> Message-ID: <1422566464.73.0.349026063093.issue8094@psf.upfronthosting.co.za> Davin Potts added the comment: On Windows 7 (64-bit), it was not possible to reproduce any infinite looping behavior with the supplied example code. Specifically, with the two examples from Benjamin, the observed behavior when running them was the same under 2.7.8 and default (3.5): a RuntimeError results with a message suggesting that the code perhaps needs to leverage the "if __name__ == '__main__'" idiom to avoid having both parent and all subsequent children processes starting up a new process because they're all unintentionally running the same lines of code intended only for the parent to run. Adding that idiomatic test to each of the two examples permits them to run to a happy conclusion. That is, in the case of the first example we make that one-line code change to read: # --- import multiprocessing def f(m): print(m) if __name__ == '__main__': p = multiprocessing.Process(target=f, args=('pouet',)) p.start() # --- This would be a recommended practice on unix-y systems as well as Windows. Aside: It was not possible to reproduce the issue injected by Darren either -- perhaps the example code provided was not quite what he intended. The infinite looping behavior described in the original issue description might well have been reproducible in much earlier releases. In the current default (3.5) branch (or in 2.7.8), it is no longer possible to reproduce. I'm tempted to mark this as "out of date" but instead will opt for "works for me" and close the issue. ---------- nosy: +davin resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 22:34:19 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 29 Jan 2015 21:34:19 +0000 Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za> Message-ID: <1422567258.99.0.19387417994.issue17797@psf.upfronthosting.co.za> Mark Lawrence added the comment: An enhancement can only go into 3.5, not 3.4. This has to happen before beta 1 which is currently scheduled for May 24 2015. I'm against the idea as it would create too many compatibility issues. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 22:52:52 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 29 Jan 2015 21:52:52 +0000 Subject: [issue18982] Add tests for CLI of the calendar module In-Reply-To: <1378674520.21.0.168914844213.issue18982@psf.upfronthosting.co.za> Message-ID: <1422568372.67.0.125450842389.issue18982@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 23:01:17 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 29 Jan 2015 22:01:17 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za> Message-ID: <1422568877.7.0.576866690516.issue23285@psf.upfronthosting.co.za> Ned Deily added the comment: With eintr-2.diff, fast!: $ time ./python ~/Projects/PyDev/active/dev/3x/source/Lib/test/eintrdata/eintr_tester.py test_read (__main__.OSEINTRTest) ... ok test_wait (__main__.OSEINTRTest) ... ok test_wait3 (__main__.OSEINTRTest) ... ok test_wait4 (__main__.OSEINTRTest) ... ok test_waitpid (__main__.OSEINTRTest) ... ok test_write (__main__.OSEINTRTest) ... ok test_accept (__main__.SocketEINTRTest) ... ok test_recv (__main__.SocketEINTRTest) ... ok test_recvmsg (__main__.SocketEINTRTest) ... ok test_send (__main__.SocketEINTRTest) ... ok test_sendall (__main__.SocketEINTRTest) ... ok test_sendmsg (__main__.SocketEINTRTest) ... ok ---------------------------------------------------------------------- Ran 12 tests in 7.652s OK real 0m7.959s user 0m2.573s sys 0m1.604s Instrumented test_send, 3 socket.send calls, many socket.recv_into calls: test_send (__main__.SocketEINTRTest) ... rd SO_RCVBUF default was 8192, wr SO_SNDBUF default was 8192 len(data) = 16777215 sent = 8192, total written = 8192 sent = 4440064, total written = 4448256 sent = 12328959, total written = 16777215 received = 8192, total read = 8192 received = 8192, total read = 16384 received = 8192, total read = 24576 [...] received = 8192, total read = 16760832 received = 8192, total read = 16769024 received = 8191, total read = 16777215 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 23:06:48 2015 From: report at bugs.python.org (Tomasz Wasilczyk) Date: Thu, 29 Jan 2015 22:06:48 +0000 Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za> Message-ID: <1422569208.79.0.926173941102.issue17797@psf.upfronthosting.co.za> Tomasz Wasilczyk added the comment: In such case, I agree it's an "enhancement", not a "bugfix". Could go into 3.5 branch. How about changing the ifdef to the following, to avoid any issues on non-MSVS2012: #if defined(MS_WINDOWS) && defined(HAVE_FSTAT) && defined(_MSC_VER) && _MSC_VER == 1700 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 23:37:17 2015 From: report at bugs.python.org (Poor Yorick) Date: Thu, 29 Jan 2015 22:37:17 +0000 Subject: [issue23284] curses, readline, tinfo, and also --prefix, dbm, CPPFLAGS In-Reply-To: <1421794283.67.0.365311015753.issue23284@psf.upfronthosting.co.za> Message-ID: <1422571037.77.0.405101516084.issue23284@psf.upfronthosting.co.za> Poor Yorick added the comment: Larger changes represent more work on the part of the submitter ;) The following should reproduce the readline problem: Have the current setup.py detect as the readline termcap library a libncurses.so that itself links against libtinfo.so. Without the --as-needed flag, this is sufficient, since libtinfo ends up being indirectly linked to readline.so, through libncurses.so. Not that it was ever the right approach, but absent --as-needed, it happens to work. Then, make sure the --as-needed flag is passed to the link command for the readline.so module. In that case, even though there is a "-lncurses" argument, the linke will not link libncurses.so to readline.so because readline.so doesn't directly need any symbols provided by libncurses.so. The readline module will then fail to load because terminal library symbols like UP will be missing. Without --as-needed, superfluous links between shared objects proliferate through a software collection. --as-needed is becoming more common, so it would be good if setup.py didn't break because of it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 23:40:54 2015 From: report at bugs.python.org (Davin Potts) Date: Thu, 29 Jan 2015 22:40:54 +0000 Subject: [issue15101] multiprocessing pool finalizer can fail if triggered in background pool thread In-Reply-To: <1340030021.48.0.355749717921.issue15101@psf.upfronthosting.co.za> Message-ID: <1422571254.18.0.154207071249.issue15101@psf.upfronthosting.co.za> Davin Potts added the comment: Having reviewed the code commits made by Richard more than 2.5 years ago in conjunction with his related code commits from already-closed Issue #15064, I am led to conclude that all the items described in this issue have been addressed and implemented. Specifically, the "quick fix" has been implemented in Richard's commits from 2.5+ years ago, use of context managers was introduced in certain places as part of Issue #15064, and any further opportunities for leveraging context managers should reasonably be described in a new, separate issue. The only outstanding item might be the desire for a test case to ensure Richard's improvements are not inadvertently undone in the future but given the nature of the changes and the age of this issue, I'm voting to go ahead and close this issue as resolved years ago. ---------- nosy: +davin resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 23:53:39 2015 From: report at bugs.python.org (Davin Potts) Date: Thu, 29 Jan 2015 22:53:39 +0000 Subject: [issue8144] muliprocessing shutdown infinite loop In-Reply-To: <1268617866.73.0.54561408378.issue8144@psf.upfronthosting.co.za> Message-ID: <1422572019.54.0.756181616416.issue8144@psf.upfronthosting.co.za> Davin Potts added the comment: At nearly 5 years of age, this issue unfortunately never saw a viable demonstration of how to provoke the reported behavior. Hopefully the reporter either (1) discovered the nature of the problem originated elsewhere and he was able to quickly fix it, or (2) won the lottery and merrily forgot all about this issue (and many other real-world issues). Many things have changed in the multiprocessing module in the last 5 years and it is difficult to see how one might deliberately reproduce this now. In the event that there is a reproducible issue like described herein, we hope that someone will step forward to open a new issue with more information. ---------- nosy: +davin resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 00:00:58 2015 From: report at bugs.python.org (Peter Inglesby) Date: Thu, 29 Jan 2015 23:00:58 +0000 Subject: [issue16482] pdb.set_trace() clobbering traceback on error In-Reply-To: <1353002125.56.0.265106335805.issue16482@psf.upfronthosting.co.za> Message-ID: <1422572458.46.0.657629957926.issue16482@psf.upfronthosting.co.za> Peter Inglesby added the comment: I've just hit this. Is there anything I can do to help get this fixed?` ---------- nosy: +inglesp _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 00:07:57 2015 From: report at bugs.python.org (Davin Potts) Date: Thu, 29 Jan 2015 23:07:57 +0000 Subject: [issue18620] multiprocessing page leaves out important part of Pool example In-Reply-To: <1375389044.82.0.349700607179.issue18620@psf.upfronthosting.co.za> Message-ID: <1422572877.33.0.383666191497.issue18620@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 00:09:02 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 29 Jan 2015 23:09:02 +0000 Subject: [issue23347] asyncio: fix and refactor creation of subprocess transports In-Reply-To: <1422532609.81.0.0177270416952.issue23347@psf.upfronthosting.co.za> Message-ID: <20150129230858.106335.12246@psf.io> Roundup Robot added the comment: New changeset a5efd5021ca1 by Victor Stinner in branch '3.4': asyncio: sync with Tulip https://hg.python.org/cpython/rev/a5efd5021ca1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 00:17:44 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 29 Jan 2015 23:17:44 +0000 Subject: [issue23347] asyncio: fix and refactor creation of subprocess transports In-Reply-To: <1422532609.81.0.0177270416952.issue23347@psf.upfronthosting.co.za> Message-ID: <20150129231739.25849.31578@psf.io> Roundup Robot added the comment: New changeset dadc372f46fa by Victor Stinner in branch '3.4': Issue #23347, asyncio: Make BaseSubprocessTransport.wait() private https://hg.python.org/cpython/rev/dadc372f46fa ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 00:19:29 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 29 Jan 2015 23:19:29 +0000 Subject: [issue23347] asyncio: fix and refactor creation of subprocess transports In-Reply-To: <1422532609.81.0.0177270416952.issue23347@psf.upfronthosting.co.za> Message-ID: <1422573569.72.0.963611079998.issue23347@psf.upfronthosting.co.za> STINNER Victor added the comment: I commited my change with small changes. "wait() is a coroutine, which is something uncommon. Is it ok to start using coroutines in transports, at least for subprocess transports?" I made the method private (renamed to _wait()). ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 00:26:31 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 29 Jan 2015 23:26:31 +0000 Subject: [issue20284] patch to implement PEP 461 (%-interpolation for bytes) In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <1422573991.67.0.225732959436.issue20284@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 00:37:34 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 29 Jan 2015 23:37:34 +0000 Subject: [issue21962] No timeout for asyncio.Event.wait() or asyncio.Condition.wait() ? In-Reply-To: <1405110230.82.0.890171299066.issue21962@psf.upfronthosting.co.za> Message-ID: <20150129233730.39268.65259@psf.io> Roundup Robot added the comment: New changeset 21010940f8c1 by Victor Stinner in branch '3.4': Issue #21962, asyncio doc: Suggest the usage of wait_for() to replace https://hg.python.org/cpython/rev/21010940f8c1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 00:38:27 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 29 Jan 2015 23:38:27 +0000 Subject: [issue21962] No timeout for asyncio.Event.wait() or asyncio.Condition.wait() ? In-Reply-To: <1405110230.82.0.890171299066.issue21962@psf.upfronthosting.co.za> Message-ID: <1422574707.86.0.952069085608.issue21962@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, I made a minimal change to the asyncio documentation to suggest the usage of wait_for(). If you would like to enhance the documentation (ex: add some examples), please write a patch. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 00:48:22 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 29 Jan 2015 23:48:22 +0000 Subject: [issue23284] curses, readline, tinfo, and also --prefix, dbm, CPPFLAGS In-Reply-To: <1422571037.77.0.405101516084.issue23284@psf.upfronthosting.co.za> Message-ID: <20150129234810.GA2667@bytereef.org> Stefan Krah added the comment: I still don't understand why libncurses is linked against libtinfo but libreadline is not. Again, what is your OS? Example Ubuntu (a modern system): $ ldd /lib/x86_64-linux-gnu/libncurses.so.5 linux-vdso.so.1 => (0x00007fff5bfed000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fcb8b43a000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fcb8b211000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcb8ae4a000) /lib64/ld-linux-x86-64.so.2 (0x00007fcb8b87d000) $ ldd /lib/x86_64-linux-gnu/libreadline.so.6 linux-vdso.so.1 => (0x00007fff8c5fe000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f43055a0000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f43051da000) /lib64/ld-linux-x86-64.so.2 (0x00007f4305a2b000) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 01:10:13 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 30 Jan 2015 00:10:13 +0000 Subject: [issue23334] http.client refactor In-Reply-To: <1422410696.55.0.10985599454.issue23334@psf.upfronthosting.co.za> Message-ID: <1422576613.81.0.469059420468.issue23334@psf.upfronthosting.co.za> Demian Brecht added the comment: Digging into this more, I've opened up a can of worms that will result in http.client not looking nearly at all like http.client. I'll work this into httplib3 and will open this conversation back up if it gets any traction. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 01:13:03 2015 From: report at bugs.python.org (Poor Yorick) Date: Fri, 30 Jan 2015 00:13:03 +0000 Subject: [issue23284] curses, readline, tinfo, and also --prefix, dbm, CPPFLAGS In-Reply-To: <1421794283.67.0.365311015753.issue23284@psf.upfronthosting.co.za> Message-ID: <1422576783.4.0.112102370229.issue23284@psf.upfronthosting.co.za> Poor Yorick added the comment: Ths OS is RHEL 6, but that's not so important because the entire collection, including readline, is built from source and installed into an alternate location. With the exception of a few essential shared objects from the system, everything else is contained in the alternate location. Here's what the readline INSTALL document says: Readline uses the termcap functions, but does not link with the termcap or curses library itself, allowing applications which link with readline to choose an appropriate library. So if you don't monkey with the readline distribution, but build and install it as-is, you get a libreadline.so that's not linked to a termcap library. That's the situation for our software collection. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 01:22:08 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 30 Jan 2015 00:22:08 +0000 Subject: [issue23347] asyncio: fix and refactor creation of subprocess transports In-Reply-To: <1422532609.81.0.0177270416952.issue23347@psf.upfronthosting.co.za> Message-ID: <20150130002202.25841.91407@psf.io> Roundup Robot added the comment: New changeset c1d92f7221a5 by Victor Stinner in branch '3.4': Issue #23347, asyncio: send_signal(), terminate(), kill() don't check if the https://hg.python.org/cpython/rev/c1d92f7221a5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 01:32:33 2015 From: report at bugs.python.org (Neil Girdhar) Date: Fri, 30 Jan 2015 00:32:33 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422577953.78.0.978015418074.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: All tests pass. @Guido: can we get some clarification on f(*? and f(**?? One option is to make them illegal for now and then open them up in a future PEP when it's more clear what's wanted? ---------- Added file: http://bugs.python.org/file37911/starunpack25.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 01:32:48 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 30 Jan 2015 00:32:48 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za> Message-ID: <1422577968.95.0.632527812765.issue23285@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> patch review versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 01:39:28 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 30 Jan 2015 00:39:28 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za> Message-ID: <1422578368.13.0.614272614825.issue23285@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Victor, do you think there's anything left to do? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 02:07:08 2015 From: report at bugs.python.org (Richard Hansen) Date: Fri, 30 Jan 2015 01:07:08 +0000 Subject: [issue23349] memoryview.to_bytes() and PyBuffer_ToContiguous() off-by-one error for non-contiguous buffers Message-ID: <1422580028.66.0.282678068687.issue23349@psf.upfronthosting.co.za> New submission from Richard Hansen: PyBuffer_ToContiguous() has an off-by-one error when copying a buffer it thinks is non-contiguous. To reproduce, put the following in foo.pyx and compile with Cython v0.21.2: cpdef foo(): cdef unsigned char[:] v = bytearray("testing") print repr(memoryview(v).tobytes()) >>> import foo >>> foo.foo() 'estingt' (This issue was fixed for Python 3.x in issue #12834 but it was not fixed for Python 2.7.) ---------- components: Interpreter Core files: PyBuffer_ToContiguous.patch keywords: patch messages: 235011 nosy: rhansen priority: normal severity: normal status: open title: memoryview.to_bytes() and PyBuffer_ToContiguous() off-by-one error for non-contiguous buffers type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file37912/PyBuffer_ToContiguous.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 02:12:42 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 30 Jan 2015 01:12:42 +0000 Subject: [issue23350] Content-length is incorrect when request body is a list or tuple Message-ID: <1422580362.11.0.520529959905.issue23350@psf.upfronthosting.co.za> New submission from Demian Brecht: Rather than summing the value of each element of a list or tuple to use as the value of the content-length header, the length of the list or tuple is used. ---------- files: list_content_length.patch keywords: patch messages: 235012 nosy: demian.brecht priority: normal severity: normal status: open title: Content-length is incorrect when request body is a list or tuple Added file: http://bugs.python.org/file37913/list_content_length.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 02:13:13 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 30 Jan 2015 01:13:13 +0000 Subject: [issue23350] Content-length is incorrect when request body is a list or tuple In-Reply-To: <1422580362.11.0.520529959905.issue23350@psf.upfronthosting.co.za> Message-ID: <1422580393.26.0.605282880807.issue23350@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- components: +Library (Lib) type: -> behavior versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 02:23:52 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 30 Jan 2015 01:23:52 +0000 Subject: [issue23350] Content-length is incorrect when request body is a list or tuple In-Reply-To: <1422580362.11.0.520529959905.issue23350@psf.upfronthosting.co.za> Message-ID: <1422581032.67.0.331637213594.issue23350@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 02:28:12 2015 From: report at bugs.python.org (Piotr Jurkiewicz) Date: Fri, 30 Jan 2015 01:28:12 +0000 Subject: [issue23351] socket.settimeout(5.0) does not have any effect Message-ID: <1422581292.34.0.901742947923.issue23351@psf.upfronthosting.co.za> New submission from Piotr Jurkiewicz: After setting socket.settimeout(5.0), socket.send() returns immediately, instead of returning after specified timeout. Steps to reproduce: Open two python interpreters. In the first one (the receiver) execute: >>> import socket >>> r = socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM) >>> r.bind("test.sock") In the second one (the sender) execute: >>> import socket >>> s = socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM) Then run the following command 11 times: >>> s.sendto("msg", "test.sock") On the 12 run command will block. This happens because datagram sockets queue on Linux is 11 messages long. Interrupt the command. So far so good. Then set sender socket timeout: >>> s.settimeout(5.0) Expected behavior: s.sendto() should block for a 5 seconds and THEN raise error 11 (EAGAIN/EWOULDBLOCK). Actual behavior: s.sendto() raises the error IMMEDIATELY. >>> s.sendto("msg", "test.sock") Traceback (most recent call last): File "", line 1, in socket.error: [Errno 11] Resource temporarily unavailable So, in fact, s.settimeout(5.0) does not have any effect. I think that problem is that settimeout() sets the socket to the non-blocking mode (docs say: "Timeout mode internally sets the socket in non-blocking mode."). As described [here](http://stackoverflow.com/q/13556972/2178047) setting timeout on non-blocking sockets is impossible. In fact, when I set timeout manually with setsockopt(), everything works as expected: >>> s.setblocking(1) #go back to blocking mode >>> tv = struct.pack("ll", 5, 0) >>> s.setsockopt(socket.SOL_SOCKET, socket.SO_SNDTIMEO, tv) Now s.sendto() raises the error after 5 seconds, as expected. ---------- components: IO, Library (Lib) messages: 235013 nosy: piotrjurkiewicz priority: normal severity: normal status: open title: socket.settimeout(5.0) does not have any effect type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 02:33:45 2015 From: report at bugs.python.org (Richard Hansen) Date: Fri, 30 Jan 2015 01:33:45 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL Message-ID: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> New submission from Richard Hansen: According to https://docs.python.org/2/c-api/buffer.html#the-new-style-py-buffer-struct if the suboffsets member of Py_buffer is non-NULL and all members of the array are negative, the buffer may be contiguous. PyBuffer_IsContiguous() does not behave this way. It assumes that if the suboffsets member is non-NULL then at least one member of the array is non-negative, and thus assumes that the buffer is non-contiguous. This is not always correct. One consequence of this bug is PyBuffer_ToContiguous() (and thus memoryview.tobytes()) falls back to slow (and currently buggy, see issue #23349) memory copying code. Attached is a patch that fixes this bug. The patch is against 2.7 but can be trivially modified to apply to 3.x. ---------- components: Interpreter Core files: PyBuffer_IsContiguous.patch keywords: patch messages: 235014 nosy: rhansen priority: normal severity: normal status: open title: PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file37914/PyBuffer_IsContiguous.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 02:34:42 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 30 Jan 2015 01:34:42 +0000 Subject: [issue23351] socket.settimeout(5.0) does not have any effect In-Reply-To: <1422581292.34.0.901742947923.issue23351@psf.upfronthosting.co.za> Message-ID: <1422581682.06.0.234996475716.issue23351@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The way socket timeouts are implemented is by using select() to determine whether the socket is ready for read/write. In this case, select() probably marks the socket ready even though the queue is full, which later raises EAGAIN. About SO_SNDTIMEO and SO_RCVTIMEO, POSIX says "it is implementation-defined whether the SO_SNDTIMEO option can be set". Also, they would not necessarily apply to other operations such as accept(). ---------- nosy: +neologix, pitrou versions: -Python 3.2, Python 3.3, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 02:35:07 2015 From: report at bugs.python.org (Richard Hansen) Date: Fri, 30 Jan 2015 01:35:07 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422581707.91.0.00353144310603.issue23352@psf.upfronthosting.co.za> Changes by Richard Hansen : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 02:39:50 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 30 Jan 2015 01:39:50 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422581990.19.0.785233834813.issue23352@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The patch has an obvious syntax error :-) Other than that, adding a comment would be nice. Bonus points if you can write a test (3.x has infrastructure for that, see Lib/test/test_buffer.py). ---------- nosy: +pitrou, skrah stage: -> patch review versions: -Python 3.2, Python 3.3, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 02:42:25 2015 From: report at bugs.python.org (Richard Hansen) Date: Fri, 30 Jan 2015 01:42:25 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422582145.75.0.280699472634.issue23352@psf.upfronthosting.co.za> Richard Hansen added the comment: > The patch has an obvious syntax error :-) Doh! > Other than that, adding a comment would be nice. Agreed, will do. > Bonus points if you can write a test (3.x has infrastructure for that, see Lib/test/test_buffer.py). I'll take a look. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 03:46:10 2015 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 30 Jan 2015 02:46:10 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1422577953.78.0.978015418074.issue2292@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Hi Neil, I think disallowing them is the best approach. There doesn't seem to be a good use case that would be thwarted. Hopefully the syntactic prohibition isn't too hard to implement. On Thu, Jan 29, 2015 at 4:32 PM, Neil Girdhar wrote: > > Neil Girdhar added the comment: > > All tests pass. > > @Guido: can we get some clarification on f(*? and f(**?? One option is to > make them illegal for now and then open them up in a future PEP when it's > more clear what's wanted? > > ---------- > Added file: http://bugs.python.org/file37911/starunpack25.diff > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 06:04:36 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 30 Jan 2015 05:04:36 +0000 Subject: [issue23350] Content-length is incorrect when request body is a list or tuple In-Reply-To: <1422580362.11.0.520529959905.issue23350@psf.upfronthosting.co.za> Message-ID: <1422594276.07.0.50352331545.issue23350@psf.upfronthosting.co.za> Demian Brecht added the comment: Updated patch based on review. ---------- Added file: http://bugs.python.org/file37915/list_content_length_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 06:11:07 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 30 Jan 2015 05:11:07 +0000 Subject: [issue23350] Content-length is incorrect when request body is a list or tuple In-Reply-To: <1422580362.11.0.520529959905.issue23350@psf.upfronthosting.co.za> Message-ID: <1422594667.88.0.509288471901.issue23350@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 06:45:06 2015 From: report at bugs.python.org (Richard Hansen) Date: Fri, 30 Jan 2015 05:45:06 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422596706.05.0.207820500074.issue23352@psf.upfronthosting.co.za> Richard Hansen added the comment: I've attached a new version of the patch. Suggestions for simplifying the test code would be appreciated. ---------- Added file: http://bugs.python.org/file37916/PyBuffer_IsContiguous_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 06:51:20 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 30 Jan 2015 05:51:20 +0000 Subject: [issue23350] Content-length is incorrect when request body is a list or tuple In-Reply-To: <1422580362.11.0.520529959905.issue23350@psf.upfronthosting.co.za> Message-ID: <1422597080.87.0.0588867536102.issue23350@psf.upfronthosting.co.za> Martin Panter added the comment: [Edit Error: 'utf8' codec can't decode byte 0xe2 in position 207: invalid continuation byte] The documentation currently says ?Content-Length header should be explicitly provided when the body is an iterable?. See Lib/urllib/request.py:1133 for how it is done for urlopen(), using memoryview(), which is probabaly more correct. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 06:51:37 2015 From: report at bugs.python.org (Richard Hansen) Date: Fri, 30 Jan 2015 05:51:37 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422597097.57.0.823021583058.issue23352@psf.upfronthosting.co.za> Changes by Richard Hansen : ---------- versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 06:52:11 2015 From: report at bugs.python.org (Richard Hansen) Date: Fri, 30 Jan 2015 05:52:11 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422597131.91.0.856249517209.issue23352@psf.upfronthosting.co.za> Changes by Richard Hansen : ---------- versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 07:30:12 2015 From: report at bugs.python.org (Richard Hansen) Date: Fri, 30 Jan 2015 06:30:12 +0000 Subject: [issue23349] PyBuffer_ToContiguous() off-by-one error for non-contiguous buffers In-Reply-To: <1422580028.66.0.282678068687.issue23349@psf.upfronthosting.co.za> Message-ID: <1422599412.63.0.908377110923.issue23349@psf.upfronthosting.co.za> Changes by Richard Hansen : ---------- title: memoryview.to_bytes() and PyBuffer_ToContiguous() off-by-one error for non-contiguous buffers -> PyBuffer_ToContiguous() off-by-one error for non-contiguous buffers _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 07:41:09 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 30 Jan 2015 06:41:09 +0000 Subject: [issue13322] buffered read() and write() does not raise BlockingIOError In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za> Message-ID: <1422600069.59.0.617808361974.issue13322@psf.upfronthosting.co.za> Martin Panter added the comment: My experiments with buffered and unbuffered readers wrapping a non-blocking TCP socket, with no data received: Method Buffered impl. Buffered doc. SocketIO impl. RawIOBase doc. ========= ============== =============== ============== ============== read None BlockingIOError None None read1 b"" [unclear] readinto None BlockingIOError None None readinto1 None BlockingIOError readall None [unclear] peek b"" [unclear] readline b"" [unspecified] OSError [unspecified] readlines [] [unspecified] OSError [unspecified] __next__ StopIteration [unspecified] OSError [unspecified] The non-blocking behaviour of BufferedReader matches the RawIOBase documentation better than its own documentation. I?m not sure which way it should be fixed. Is this a documentation bug or an implementation bug? I propose to change the read1() and peek() methods to behave like the others (whether than be returning None or raising BlockingIOError). It would be nice to have a way to differentiate non-blocking data being unavailable from hard EOF, at least for non-interactive mode, and the added consistency would be nice. A non-blocking BufferedReader use case: to be able to peek one byte of a HTTP response stream to see if the connection has been closed. Plain sockets support MSG_PEEK, but SSL sockets don?t, and a BufferedReader is already being used. Later when actually parsing the response, the reader is set to blocking mode. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 07:48:55 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 30 Jan 2015 06:48:55 +0000 Subject: [issue5811] io.BufferedReader.peek(): Documentation differs from Implementation In-Reply-To: <1240380953.7.0.732520909261.issue5811@psf.upfronthosting.co.za> Message-ID: <1422600535.5.0.1609241341.issue5811@psf.upfronthosting.co.za> Martin Panter added the comment: The non-blocking behaviour that I documented in my patch is under question in Issue 13322. I think it would be nice change the implementation to either return None or raise BlockingIOError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 07:54:50 2015 From: report at bugs.python.org (Makoto Kato) Date: Fri, 30 Jan 2015 06:54:50 +0000 Subject: [issue23338] PyErr_Format in ctypes uses invalid parameter In-Reply-To: <1422442371.36.0.968367348117.issue23338@psf.upfronthosting.co.za> Message-ID: <1422600890.13.0.773384335833.issue23338@psf.upfronthosting.co.za> Changes by Makoto Kato : Removed file: http://bugs.python.org/file37901/py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 07:56:32 2015 From: report at bugs.python.org (Makoto Kato) Date: Fri, 30 Jan 2015 06:56:32 +0000 Subject: [issue23338] PyErr_Format in ctypes uses invalid parameter In-Reply-To: <1422442371.36.0.968367348117.issue23338@psf.upfronthosting.co.za> Message-ID: <1422600992.67.0.162544419551.issue23338@psf.upfronthosting.co.za> Makoto Kato added the comment: updated. for master ---------- hgrepos: +296 Added file: http://bugs.python.org/file37917/py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 07:56:58 2015 From: report at bugs.python.org (Makoto Kato) Date: Fri, 30 Jan 2015 06:56:58 +0000 Subject: [issue23338] PyErr_Format in ctypes uses invalid parameter In-Reply-To: <1422442371.36.0.968367348117.issue23338@psf.upfronthosting.co.za> Message-ID: <1422601018.84.0.610844008415.issue23338@psf.upfronthosting.co.za> Changes by Makoto Kato : ---------- hgrepos: -295 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 08:02:00 2015 From: report at bugs.python.org (Makoto Kato) Date: Fri, 30 Jan 2015 07:02:00 +0000 Subject: [issue23338] PyErr_Format in ctypes uses invalid parameter In-Reply-To: <1422442371.36.0.968367348117.issue23338@psf.upfronthosting.co.za> Message-ID: <1422601320.8.0.86642861738.issue23338@psf.upfronthosting.co.za> Makoto Kato added the comment: updated for python 2.7 ---------- versions: +Python 3.6 -Python 2.7 Added file: http://bugs.python.org/file37918/py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 08:02:11 2015 From: report at bugs.python.org (Makoto Kato) Date: Fri, 30 Jan 2015 07:02:11 +0000 Subject: [issue23338] PyErr_Format in ctypes uses invalid parameter In-Reply-To: <1422442371.36.0.968367348117.issue23338@psf.upfronthosting.co.za> Message-ID: <1422601331.38.0.0788804165383.issue23338@psf.upfronthosting.co.za> Changes by Makoto Kato : Removed file: http://bugs.python.org/file37890/py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 08:21:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 30 Jan 2015 07:21:10 +0000 Subject: [issue19256] Optimize marshal format and add version token. In-Reply-To: <1381703408.57.0.928931596293.issue19256@psf.upfronthosting.co.za> Message-ID: <1422602470.42.0.23371421108.issue19256@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Largest modules in the stdlib have up to 800 references. So it would be worth to have 4 opcodes for short (10-bit) ref indices. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 09:03:13 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 30 Jan 2015 08:03:13 +0000 Subject: [issue23351] socket.settimeout(5.0) does not have any effect In-Reply-To: <1422581682.06.0.234996475716.issue23351@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > The way socket timeouts are implemented is by using select() to determine whether the socket is ready for read/write. In this case, select() probably marks the socket ready even though the queue is full, which later raises EAGAIN. Indeed, and this looks like a kernel bug. Working as expected on a RHEL6: $ python /tmp/test_unix_sock_timeout.py ('sending ', 0) took 0.000s ('sending ', 1) took 0.000s ('sending ', 2) took 0.000s ('sending ', 3) took 0.000s ('sending ', 4) took 0.000s ('sending ', 5) took 0.000s ('sending ', 6) took 0.000s ('sending ', 7) took 0.000s ('sending ', 8) took 0.000s ('sending ', 9) took 0.000s ('sending ', 10) took 0.000s ('sending ', 11) took 1.000s Traceback (most recent call last): File "/tmp/test_unix_sock_timeout.py", line 17, in s.sendto("hello", SOCKNAME) socket.timeout: timed out > About SO_SNDTIMEO and SO_RCVTIMEO, POSIX says "it is implementation-defined whether the SO_SNDTIMEO option can be set". Also, they would not necessarily apply to other operations such as accept(). Exactly, the current way timeouts are implemented ar The Right Way, IMO. ---------- Added file: http://bugs.python.org/file37919/test_unix_sock_timeout.py _______________________________________ Python tracker _______________________________________ -------------- next part -------------- import itertools import os import socket import time SOCKNAME = "/tmp/test.sock" if os.fork() == 0: time.sleep(1) s = socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM) s.settimeout(1) for i in itertools.count(): print("sending ", i) t0 = time.time() try: s.sendto("hello", SOCKNAME) finally: print("took {:.3f}s".format(time.time() - t0)) else: os.remove(SOCKNAME) s = socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM) s.bind(SOCKNAME) os.waitpid(-1, 0) From report at bugs.python.org Fri Jan 30 09:45:58 2015 From: report at bugs.python.org (Neil Girdhar) Date: Fri, 30 Jan 2015 08:45:58 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422607558.49.0.747842569039.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Ready for a code review: Blocked f(*x for x?) as requested. Polished up parsermodule.c. ---------- Added file: http://bugs.python.org/file37920/starunpack26.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 29 23:49:06 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 29 Jan 2015 22:49:06 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: <1422568877.7.0.576866690516.issue23285@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > With eintr-2.diff, fast!: Victory \?/. > Instrumented test_send, 3 socket.send calls, many socket.recv_into calls: Yep, that's expected. I think we should keep the default socket buffer size: it increases the test coverage, and it's probably not worth trying to increase it to make the test a bit faster, especially since it spends so much time sleeping. Antoine, I'm now happy with the patch, so we'll be waiting for your decision on the PEP with Victor :-). ---------- Added file: http://bugs.python.org/file37910/eintr-3.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r fe0fddd6fd21 Lib/_pyio.py --- a/Lib/_pyio.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/_pyio.py Thu Jan 29 22:20:01 2015 +0000 @@ -1006,10 +1006,7 @@ current_size = 0 while True: # Read until EOF or until read() would block. - try: - chunk = self.raw.read() - except InterruptedError: - continue + chunk = self.raw.read() if chunk in empty_values: nodata_val = chunk break @@ -1028,10 +1025,7 @@ chunks = [buf[pos:]] wanted = max(self.buffer_size, n) while avail < n: - try: - chunk = self.raw.read(wanted) - except InterruptedError: - continue + chunk = self.raw.read(wanted) if chunk in empty_values: nodata_val = chunk break @@ -1060,12 +1054,7 @@ have = len(self._read_buf) - self._read_pos if have < want or have <= 0: to_read = self.buffer_size - have - while True: - try: - current = self.raw.read(to_read) - except InterruptedError: - continue - break + current = self.raw.read(to_read) if current: self._read_buf = self._read_buf[self._read_pos:] + current self._read_pos = 0 @@ -1214,8 +1203,6 @@ while self._write_buf: try: n = self.raw.write(self._write_buf) - except InterruptedError: - continue except BlockingIOError: raise RuntimeError("self.raw should implement RawIOBase: it " "should not raise BlockingIOError") diff -r fe0fddd6fd21 Lib/distutils/spawn.py --- a/Lib/distutils/spawn.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/distutils/spawn.py Thu Jan 29 22:20:01 2015 +0000 @@ -137,9 +137,6 @@ try: pid, status = os.waitpid(pid, 0) except OSError as exc: - import errno - if exc.errno == errno.EINTR: - continue if not DEBUG: cmd = executable raise DistutilsExecError( diff -r fe0fddd6fd21 Lib/multiprocessing/connection.py --- a/Lib/multiprocessing/connection.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/multiprocessing/connection.py Thu Jan 29 22:20:01 2015 +0000 @@ -365,10 +365,7 @@ def _send(self, buf, write=_write): remaining = len(buf) while True: - try: - n = write(self._handle, buf) - except InterruptedError: - continue + n = write(self._handle, buf) remaining -= n if remaining == 0: break @@ -379,10 +376,7 @@ handle = self._handle remaining = size while remaining > 0: - try: - chunk = read(handle, remaining) - except InterruptedError: - continue + chunk = read(handle, remaining) n = len(chunk) if n == 0: if remaining == size: @@ -595,13 +589,7 @@ self._unlink = None def accept(self): - while True: - try: - s, self._last_accepted = self._socket.accept() - except InterruptedError: - pass - else: - break + s, self._last_accepted = self._socket.accept() s.setblocking(True) return Connection(s.detach()) diff -r fe0fddd6fd21 Lib/multiprocessing/forkserver.py --- a/Lib/multiprocessing/forkserver.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/multiprocessing/forkserver.py Thu Jan 29 22:20:01 2015 +0000 @@ -188,8 +188,6 @@ finally: os._exit(code) - except InterruptedError: - pass except OSError as e: if e.errno != errno.ECONNABORTED: raise @@ -230,13 +228,7 @@ data = b'' length = UNSIGNED_STRUCT.size while len(data) < length: - while True: - try: - s = os.read(fd, length - len(data)) - except InterruptedError: - pass - else: - break + s = os.read(fd, length - len(data)) if not s: raise EOFError('unexpected EOF') data += s @@ -245,13 +237,7 @@ def write_unsigned(fd, n): msg = UNSIGNED_STRUCT.pack(n) while msg: - while True: - try: - nbytes = os.write(fd, msg) - except InterruptedError: - pass - else: - break + nbytes = os.write(fd, msg) if nbytes == 0: raise RuntimeError('should not get here') msg = msg[nbytes:] diff -r fe0fddd6fd21 Lib/multiprocessing/popen_fork.py --- a/Lib/multiprocessing/popen_fork.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/multiprocessing/popen_fork.py Thu Jan 29 22:20:01 2015 +0000 @@ -1,7 +1,6 @@ import os import sys import signal -import errno from . import util @@ -29,8 +28,6 @@ try: pid, sts = os.waitpid(self.pid, flag) except OSError as e: - if e.errno == errno.EINTR: - continue # Child process not yet created. See #1731717 # e.errno == errno.ECHILD == 10 return None diff -r fe0fddd6fd21 Lib/socket.py --- a/Lib/socket.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/socket.py Thu Jan 29 22:20:01 2015 +0000 @@ -572,8 +572,6 @@ except timeout: self._timeout_occurred = True raise - except InterruptedError: - continue except error as e: if e.args[0] in _blocking_errnos: return None diff -r fe0fddd6fd21 Lib/socketserver.py --- a/Lib/socketserver.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/socketserver.py Thu Jan 29 22:20:01 2015 +0000 @@ -553,8 +553,6 @@ try: pid, _ = os.waitpid(-1, 0) self.active_children.discard(pid) - except InterruptedError: - pass except ChildProcessError: # we don't have any children, we're done self.active_children.clear() diff -r fe0fddd6fd21 Lib/subprocess.py --- a/Lib/subprocess.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/subprocess.py Thu Jan 29 22:20:01 2015 +0000 @@ -489,14 +489,6 @@ DEVNULL = -3 -def _eintr_retry_call(func, *args): - while True: - try: - return func(*args) - except InterruptedError: - continue - - # XXX This function is only used by multiprocessing and the test suite, # but it's here so that it can be imported when Python is compiled without # threads. @@ -963,10 +955,10 @@ if self.stdin: self._stdin_write(input) elif self.stdout: - stdout = _eintr_retry_call(self.stdout.read) + stdout = self.stdout.read() self.stdout.close() elif self.stderr: - stderr = _eintr_retry_call(self.stderr.read) + stderr = self.stderr.read() self.stderr.close() self.wait() else: @@ -1410,7 +1402,7 @@ # exception (limited in size) errpipe_data = bytearray() while True: - part = _eintr_retry_call(os.read, errpipe_read, 50000) + part = os.read(errpipe_read, 50000) errpipe_data += part if not part or len(errpipe_data) > 50000: break @@ -1420,7 +1412,7 @@ if errpipe_data: try: - _eintr_retry_call(os.waitpid, self.pid, 0) + os.waitpid(self.pid, 0) except ChildProcessError: pass try: @@ -1505,7 +1497,7 @@ def _try_wait(self, wait_flags): """All callers to this function MUST hold self._waitpid_lock.""" try: - (pid, sts) = _eintr_retry_call(os.waitpid, self.pid, wait_flags) + (pid, sts) = os.waitpid(self.pid, wait_flags) except ChildProcessError: # This happens if SIGCLD is set to be ignored or waiting # for child processes has otherwise been disabled for our diff -r fe0fddd6fd21 Lib/test/eintrdata/eintr_tester.py --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Lib/test/eintrdata/eintr_tester.py Thu Jan 29 22:20:01 2015 +0000 @@ -0,0 +1,234 @@ +""" +This test suite exercises some system calls subject to interruption with EINTR, +to check that it is actually handled transparently. +It is intended to be run by the main test suite within a child process, to +ensure there is no background thread running (so that signals are delivered to +the correct thread). +Signals are generated in-process using setitimer(ITIMER_REAL), which allows +sub-second periodicity (contrarily to signal()). +""" + +import io +import os +import signal +import socket +import time +import unittest + +from test import support + + + at unittest.skipUnless(hasattr(signal, "setitimer"), "requires setitimer()") +class EINTRBaseTest(unittest.TestCase): + """ Base class for EINTR tests. """ + + # delay for initial signal delivery + signal_delay = 0.1 + # signal delivery periodicity + signal_period = 0.1 + # default sleep time for tests - should obviously have: + #??sleep_time > signal_period + sleep_time = 0.2 + + @classmethod + def setUpClass(cls): + cls.orig_handler = signal.signal(signal.SIGALRM, lambda *args: None) + signal.setitimer(signal.ITIMER_REAL, cls.signal_delay, + cls.signal_period) + + @classmethod + def tearDownClass(cls): + signal.setitimer(signal.ITIMER_REAL, 0, 0) + signal.signal(signal.SIGALRM, cls.orig_handler) + + @classmethod + def _sleep(cls): + # default sleep time + time.sleep(cls.sleep_time) + + + at unittest.skipUnless(hasattr(signal, "setitimer"), "requires setitimer()") +class OSEINTRTest(EINTRBaseTest): + """ EINTR tests for the os module. """ + + def _test_wait_multiple(self, wait_func): + num = 3 + for _ in range(num): + pid = os.fork() + if pid == 0: + self._sleep() + os._exit(0) + for _ in range(num): + wait_func() + + def test_wait(self): + self._test_wait_multiple(os.wait) + + @unittest.skipUnless(hasattr(os, 'wait3'), 'requires wait3()') + def test_wait3(self): + self._test_wait_multiple(lambda: os.wait3(0)) + + def _test_wait_single(self, wait_func): + pid = os.fork() + if pid == 0: + self._sleep() + os._exit(0) + else: + wait_func(pid) + + def test_waitpid(self): + self._test_wait_single(lambda pid: os.waitpid(pid, 0)) + + @unittest.skipUnless(hasattr(os, 'wait4'), 'requires wait4()') + def test_wait4(self): + self._test_wait_single(lambda pid: os.wait4(pid, 0)) + + def test_read(self): + rd, wr = os.pipe() + self.addCleanup(os.close, rd) + # wr closed explicitly by parent + + # the payload below are smaller than PIPE_BUF, hence the writes will be + # atomic + datas = [b"hello", b"world", b"spam"] + + pid = os.fork() + if pid == 0: + os.close(rd) + for data in datas: + # let the parent block on read() + self._sleep() + os.write(wr, data) + os._exit(0) + else: + self.addCleanup(os.waitpid, pid, 0) + os.close(wr) + for data in datas: + self.assertEqual(data, os.read(rd, len(data))) + + def test_write(self): + rd, wr = os.pipe() + self.addCleanup(os.close, wr) + # rd closed explicitly by parent + + # we must write enough data for the write() to block + data = b"xyz" * support.PIPE_MAX_SIZE + + pid = os.fork() + if pid == 0: + os.close(wr) + read_data = io.BytesIO() + # let the parent block on write() + self._sleep() + while len(read_data.getvalue()) < len(data): + chunk = os.read(rd, 2 * len(data)) + read_data.write(chunk) + self.assertEqual(read_data.getvalue(), data) + os._exit(0) + else: + os.close(rd) + written = 0 + while written < len(data): + written += os.write(wr, memoryview(data)[written:]) + self.assertEqual(0, os.waitpid(pid, 0)[1]) + + + at unittest.skipUnless(hasattr(signal, "setitimer"), "requires setitimer()") +class SocketEINTRTest(EINTRBaseTest): + """ EINTR tests for the socket module. """ + + @unittest.skipUnless(hasattr(socket, 'socketpair'), 'needs socketpair()') + def _test_recv(self, recv_func): + rd, wr = socket.socketpair() + self.addCleanup(rd.close) + # wr closed explicitly by parent + + # single-byte payload guard us against partial recv + datas = [b"x", b"y", b"z"] + + pid = os.fork() + if pid == 0: + rd.close() + for data in datas: + # let the parent block on recv() + self._sleep() + wr.sendall(data) + os._exit(0) + else: + self.addCleanup(os.waitpid, pid, 0) + wr.close() + for data in datas: + self.assertEqual(data, recv_func(rd, len(data))) + + def test_recv(self): + self._test_recv(socket.socket.recv) + + @unittest.skipUnless(hasattr(socket.socket, 'recvmsg'), 'needs recvmsg()') + def test_recvmsg(self): + self._test_recv(lambda sock, data: sock.recvmsg(data)[0]) + + def _test_send(self, send_func): + rd, wr = socket.socketpair() + self.addCleanup(wr.close) + # rd closed explicitly by parent + + # we must send enough data for the send() to block + data = b"xyz" * (support.SOCK_MAX_SIZE // 3) + + pid = os.fork() + if pid == 0: + wr.close() + # let the parent block on send() + self._sleep() + received_data = bytearray(len(data)) + n = 0 + while n < len(data): + n += rd.recv_into(memoryview(received_data)[n:]) + self.assertEqual(received_data, data) + os._exit(0) + else: + rd.close() + written = 0 + while written < len(data): + sent = send_func(wr, memoryview(data)[written:]) + # sendall() returns None + written += len(data) if sent is None else sent + self.assertEqual(0, os.waitpid(pid, 0)[1]) + + def test_send(self): + self._test_send(socket.socket.send) + + def test_sendall(self): + self._test_send(socket.socket.sendall) + + @unittest.skipUnless(hasattr(socket.socket, 'sendmsg'), 'needs sendmsg()') + def test_sendmsg(self): + self._test_send(lambda sock, data: sock.sendmsg([data])) + + def test_accept(self): + sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) + self.addCleanup(sock.close) + + sock.bind((support.HOST, 0)) + _, port = sock.getsockname() + sock.listen() + + pid = os.fork() + if pid == 0: + # let parent block on accept() + self._sleep() + with socket.create_connection((support.HOST, port)): + self._sleep() + os._exit(0) + else: + self.addCleanup(os.waitpid, pid, 0) + client_sock, _ = sock.accept() + client_sock.close() + + +def test_main(): + support.run_unittest(OSEINTRTest, SocketEINTRTest) + + +if __name__ == "__main__": + test_main() diff -r fe0fddd6fd21 Lib/test/test_eintr.py --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Lib/test/test_eintr.py Thu Jan 29 22:20:01 2015 +0000 @@ -0,0 +1,20 @@ +import os +import signal +import unittest + +from test import script_helper, support + + + at unittest.skipUnless(os.name == "posix", "only supported on Unix") +class EINTRTests(unittest.TestCase): + + @unittest.skipUnless(hasattr(signal, "setitimer"), "requires setitimer()") + def test_all(self): + # Run the tester in a sub-process, to make sure there is only one + # thread (for reliable signal delivery). + tester = support.findfile("eintr_tester.py", subdir="eintrdata") + script_helper.assert_python_ok(tester) + + +if __name__ == "__main__": + unittest.main() diff -r fe0fddd6fd21 Lib/test/test_signal.py --- a/Lib/test/test_signal.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/test/test_signal.py Thu Jan 29 22:20:01 2015 +0000 @@ -587,7 +587,7 @@ r, w = os.pipe() def handler(signum, frame): - pass + 1 / 0 signal.signal(signal.SIGALRM, handler) if interrupt is not None: @@ -604,9 +604,8 @@ try: # blocking call: read from a pipe without data os.read(r, 1) - except OSError as err: - if err.errno != errno.EINTR: - raise + except ZeroDivisionError: + pass else: sys.exit(2) sys.exit(3) diff -r fe0fddd6fd21 Lib/test/test_socket.py --- a/Lib/test/test_socket.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/test/test_socket.py Thu Jan 29 22:20:01 2015 +0000 @@ -3590,7 +3590,7 @@ def setUp(self): super().setUp() orig_alrm_handler = signal.signal(signal.SIGALRM, - lambda signum, frame: None) + lambda signum, frame: 1 / 0) self.addCleanup(signal.signal, signal.SIGALRM, orig_alrm_handler) self.addCleanup(self.setAlarm, 0) @@ -3627,13 +3627,11 @@ self.serv.settimeout(self.timeout) def checkInterruptedRecv(self, func, *args, **kwargs): - # Check that func(*args, **kwargs) raises OSError with an + # Check that func(*args, **kwargs) raises # errno of EINTR when interrupted by a signal. self.setAlarm(self.alarm_time) - with self.assertRaises(OSError) as cm: + with self.assertRaises(ZeroDivisionError) as cm: func(*args, **kwargs) - self.assertNotIsInstance(cm.exception, socket.timeout) - self.assertEqual(cm.exception.errno, errno.EINTR) def testInterruptedRecvTimeout(self): self.checkInterruptedRecv(self.serv.recv, 1024) @@ -3689,12 +3687,10 @@ # Check that func(*args, **kwargs), run in a loop, raises # OSError with an errno of EINTR when interrupted by a # signal. - with self.assertRaises(OSError) as cm: + with self.assertRaises(ZeroDivisionError) as cm: while True: self.setAlarm(self.alarm_time) func(*args, **kwargs) - self.assertNotIsInstance(cm.exception, socket.timeout) - self.assertEqual(cm.exception.errno, errno.EINTR) # Issue #12958: The following tests have problems on OS X prior to 10.7 @support.requires_mac_ver(10, 7) @@ -4062,117 +4058,6 @@ pass -class FileObjectInterruptedTestCase(unittest.TestCase): - """Test that the file object correctly handles EINTR internally.""" - - class MockSocket(object): - def __init__(self, recv_funcs=()): - # A generator that returns callables that we'll call for each - # call to recv(). - self._recv_step = iter(recv_funcs) - - def recv_into(self, buffer): - data = next(self._recv_step)() - assert len(buffer) >= len(data) - buffer[:len(data)] = data - return len(data) - - def _decref_socketios(self): - pass - - def _textiowrap_for_test(self, buffering=-1): - raw = socket.SocketIO(self, "r") - if buffering < 0: - buffering = io.DEFAULT_BUFFER_SIZE - if buffering == 0: - return raw - buffer = io.BufferedReader(raw, buffering) - text = io.TextIOWrapper(buffer, None, None) - text.mode = "rb" - return text - - @staticmethod - def _raise_eintr(): - raise OSError(errno.EINTR, "interrupted") - - def _textiowrap_mock_socket(self, mock, buffering=-1): - raw = socket.SocketIO(mock, "r") - if buffering < 0: - buffering = io.DEFAULT_BUFFER_SIZE - if buffering == 0: - return raw - buffer = io.BufferedReader(raw, buffering) - text = io.TextIOWrapper(buffer, None, None) - text.mode = "rb" - return text - - def _test_readline(self, size=-1, buffering=-1): - mock_sock = self.MockSocket(recv_funcs=[ - lambda : b"This is the first line\nAnd the sec", - self._raise_eintr, - lambda : b"ond line is here\n", - lambda : b"", - lambda : b"", # XXX(gps): io library does an extra EOF read - ]) - fo = mock_sock._textiowrap_for_test(buffering=buffering) - self.assertEqual(fo.readline(size), "This is the first line\n") - self.assertEqual(fo.readline(size), "And the second line is here\n") - - def _test_read(self, size=-1, buffering=-1): - mock_sock = self.MockSocket(recv_funcs=[ - lambda : b"This is the first line\nAnd the sec", - self._raise_eintr, - lambda : b"ond line is here\n", - lambda : b"", - lambda : b"", # XXX(gps): io library does an extra EOF read - ]) - expecting = (b"This is the first line\n" - b"And the second line is here\n") - fo = mock_sock._textiowrap_for_test(buffering=buffering) - if buffering == 0: - data = b'' - else: - data = '' - expecting = expecting.decode('utf-8') - while len(data) != len(expecting): - part = fo.read(size) - if not part: - break - data += part - self.assertEqual(data, expecting) - - def test_default(self): - self._test_readline() - self._test_readline(size=100) - self._test_read() - self._test_read(size=100) - - def test_with_1k_buffer(self): - self._test_readline(buffering=1024) - self._test_readline(size=100, buffering=1024) - self._test_read(buffering=1024) - self._test_read(size=100, buffering=1024) - - def _test_readline_no_buffer(self, size=-1): - mock_sock = self.MockSocket(recv_funcs=[ - lambda : b"a", - lambda : b"\n", - lambda : b"B", - self._raise_eintr, - lambda : b"b", - lambda : b"", - ]) - fo = mock_sock._textiowrap_for_test(buffering=0) - self.assertEqual(fo.readline(size), b"a\n") - self.assertEqual(fo.readline(size), b"Bb") - - def test_no_buffer(self): - self._test_readline_no_buffer() - self._test_readline_no_buffer(size=4) - self._test_read(buffering=0) - self._test_read(size=100, buffering=0) - - class UnbufferedFileObjectClassTestCase(FileObjectClassTestCase): """Repeat the tests from FileObjectClassTestCase with bufsize==0. @@ -5388,7 +5273,6 @@ tests.extend([ NonBlockingTCPTests, FileObjectClassTestCase, - FileObjectInterruptedTestCase, UnbufferedFileObjectClassTestCase, LineBufferedFileObjectClassTestCase, SmallBufferedFileObjectClassTestCase, diff -r fe0fddd6fd21 Lib/test/test_subprocess.py --- a/Lib/test/test_subprocess.py Sun Jan 18 11:17:39 2015 +0200 +++ b/Lib/test/test_subprocess.py Thu Jan 29 22:20:01 2015 +0000 @@ -2421,25 +2421,6 @@ ProcessTestCase.tearDown(self) -class HelperFunctionTests(unittest.TestCase): - @unittest.skipIf(mswindows, "errno and EINTR make no sense on windows") - def test_eintr_retry_call(self): - record_calls = [] - def fake_os_func(*args): - record_calls.append(args) - if len(record_calls) == 2: - raise OSError(errno.EINTR, "fake interrupted system call") - return tuple(reversed(args)) - - self.assertEqual((999, 256), - subprocess._eintr_retry_call(fake_os_func, 256, 999)) - self.assertEqual([(256, 999)], record_calls) - # This time there will be an EINTR so it will loop once. - self.assertEqual((666,), - subprocess._eintr_retry_call(fake_os_func, 666)) - self.assertEqual([(256, 999), (666,), (666,)], record_calls) - - @unittest.skipUnless(mswindows, "Windows-specific tests") class CommandsWithSpaces (BaseTestCase): @@ -2528,7 +2509,6 @@ Win32ProcessTestCase, CommandTests, ProcessTestCaseNoPoll, - HelperFunctionTests, CommandsWithSpaces, ContextManagerTests, ) diff -r fe0fddd6fd21 Modules/_io/fileio.c --- a/Modules/_io/fileio.c Sun Jan 18 11:17:39 2015 +0200 +++ b/Modules/_io/fileio.c Thu Jan 29 22:20:01 2015 +0000 @@ -550,7 +550,7 @@ { Py_buffer pbuf; Py_ssize_t n, len; - int err; + int err, async_err = 0; if (self->fd < 0) return err_closed(); @@ -562,16 +562,19 @@ if (_PyVerify_fd(self->fd)) { len = pbuf.len; - Py_BEGIN_ALLOW_THREADS - errno = 0; + do { + Py_BEGIN_ALLOW_THREADS + errno = 0; #ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - n = read(self->fd, pbuf.buf, (int)len); + if (len > INT_MAX) + len = INT_MAX; + n = read(self->fd, pbuf.buf, (int)len); #else - n = read(self->fd, pbuf.buf, len); + n = read(self->fd, pbuf.buf, len); #endif - Py_END_ALLOW_THREADS + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); } else n = -1; err = errno; @@ -580,7 +583,8 @@ if (err == EAGAIN) Py_RETURN_NONE; errno = err; - PyErr_SetFromErrno(PyExc_IOError); + if (!async_err) + PyErr_SetFromErrno(PyExc_IOError); return NULL; } @@ -627,6 +631,7 @@ Py_ssize_t bytes_read = 0; Py_ssize_t n; size_t bufsize; + int async_err = 0; if (self->fd < 0) return err_closed(); @@ -673,27 +678,23 @@ return NULL; } } - Py_BEGIN_ALLOW_THREADS - errno = 0; - n = bufsize - bytes_read; + do { + Py_BEGIN_ALLOW_THREADS + errno = 0; + n = bufsize - bytes_read; #ifdef MS_WINDOWS - if (n > INT_MAX) - n = INT_MAX; - n = read(self->fd, PyBytes_AS_STRING(result) + bytes_read, (int)n); + if (n > INT_MAX) + n = INT_MAX; + n = read(self->fd, PyBytes_AS_STRING(result) + bytes_read, (int)n); #else - n = read(self->fd, PyBytes_AS_STRING(result) + bytes_read, n); + n = read(self->fd, PyBytes_AS_STRING(result) + bytes_read, n); #endif - Py_END_ALLOW_THREADS + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); if (n == 0) break; if (n < 0) { - if (errno == EINTR) { - if (PyErr_CheckSignals()) { - Py_DECREF(result); - return NULL; - } - continue; - } if (errno == EAGAIN) { if (bytes_read > 0) break; @@ -701,7 +702,8 @@ Py_RETURN_NONE; } Py_DECREF(result); - PyErr_SetFromErrno(PyExc_IOError); + if (!async_err) + PyErr_SetFromErrno(PyExc_IOError); return NULL; } bytes_read += n; @@ -723,6 +725,7 @@ char *ptr; Py_ssize_t n; Py_ssize_t size = -1; + int async_err = 0; PyObject *bytes; if (self->fd < 0) @@ -747,14 +750,17 @@ ptr = PyBytes_AS_STRING(bytes); if (_PyVerify_fd(self->fd)) { - Py_BEGIN_ALLOW_THREADS - errno = 0; + do { + Py_BEGIN_ALLOW_THREADS + errno = 0; #ifdef MS_WINDOWS - n = read(self->fd, ptr, (int)size); + n = read(self->fd, ptr, (int)size); #else - n = read(self->fd, ptr, size); + n = read(self->fd, ptr, size); #endif - Py_END_ALLOW_THREADS + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); } else n = -1; @@ -764,7 +770,8 @@ if (err == EAGAIN) Py_RETURN_NONE; errno = err; - PyErr_SetFromErrno(PyExc_IOError); + if (!async_err) + PyErr_SetFromErrno(PyExc_IOError); return NULL; } @@ -783,7 +790,7 @@ { Py_buffer pbuf; Py_ssize_t n, len; - int err; + int err, async_err = 0; if (self->fd < 0) return err_closed(); @@ -794,24 +801,26 @@ return NULL; if (_PyVerify_fd(self->fd)) { - Py_BEGIN_ALLOW_THREADS - errno = 0; - len = pbuf.len; + do { + Py_BEGIN_ALLOW_THREADS + errno = 0; + len = pbuf.len; #ifdef MS_WINDOWS - if (len > 32767 && isatty(self->fd)) { - /* Issue #11395: the Windows console returns an error (12: not - enough space error) on writing into stdout if stdout mode is - binary and the length is greater than 66,000 bytes (or less, - depending on heap usage). */ - len = 32767; - } - else if (len > INT_MAX) - len = INT_MAX; - n = write(self->fd, pbuf.buf, (int)len); + if (len > 32767 && isatty(self->fd)) { + /* Issue #11395: the Windows console returns an error (12: not + enough space error) on writing into stdout if stdout mode is + binary and the length is greater than 66,000 bytes (or less, + depending on heap usage). */ + len = 32767; + } else if (len > INT_MAX) + len = INT_MAX; + n = write(self->fd, pbuf.buf, (int)len); #else - n = write(self->fd, pbuf.buf, len); + n = write(self->fd, pbuf.buf, len); #endif - Py_END_ALLOW_THREADS + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); } else n = -1; err = errno; @@ -822,7 +831,8 @@ if (err == EAGAIN) Py_RETURN_NONE; errno = err; - PyErr_SetFromErrno(PyExc_IOError); + if (!async_err) + PyErr_SetFromErrno(PyExc_IOError); return NULL; } diff -r fe0fddd6fd21 Modules/posixmodule.c --- a/Modules/posixmodule.c Sun Jan 18 11:17:39 2015 +0200 +++ b/Modules/posixmodule.c Thu Jan 29 22:20:01 2015 +0000 @@ -1361,13 +1361,16 @@ posix_fildes_fd(int fd, int (*func)(int)) { int res; - Py_BEGIN_ALLOW_THREADS - res = (*func)(fd); - Py_END_ALLOW_THREADS - if (res < 0) - return posix_error(); - Py_INCREF(Py_None); - return Py_None; + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + res = (*func)(fd); + Py_END_ALLOW_THREADS + } while (res != 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res != 0) + return (!async_err) ? posix_error() : NULL; + Py_RETURN_NONE; } @@ -3479,11 +3482,16 @@ /*[clinic end generated code: output=3c19fbfd724a8e0f input=8ab11975ca01ee5b]*/ { int res; - Py_BEGIN_ALLOW_THREADS - res = fchmod(fd, mode); - Py_END_ALLOW_THREADS - if (res < 0) - return posix_error(); + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + res = fchmod(fd, mode); + Py_END_ALLOW_THREADS + } while (res != 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res != 0) + return (!async_err) ? posix_error() : NULL; + Py_RETURN_NONE; } #endif /* HAVE_FCHMOD */ @@ -4104,11 +4112,16 @@ /*[clinic end generated code: output=687781cb7d8974d6 input=3af544ba1b13a0d7]*/ { int res; - Py_BEGIN_ALLOW_THREADS - res = fchown(fd, uid, gid); - Py_END_ALLOW_THREADS - if (res < 0) - return posix_error(); + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + res = fchown(fd, uid, gid); + Py_END_ALLOW_THREADS + } while (res != 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res != 0) + return (!async_err) ? posix_error() : NULL; + Py_RETURN_NONE; } #endif /* HAVE_FCHOWN */ @@ -9602,12 +9615,17 @@ { pid_t pid; struct rusage ru; + int async_err = 0; WAIT_TYPE status; WAIT_STATUS_INT(status) = 0; - Py_BEGIN_ALLOW_THREADS - pid = wait3(&status, options, &ru); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + pid = wait3(&status, options, &ru); + Py_END_ALLOW_THREADS + } while (pid < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (pid < 0) + return (!async_err) ? posix_error() : NULL; return wait_helper(pid, WAIT_STATUS_INT(status), &ru); } @@ -9665,15 +9683,21 @@ os_wait4_impl(PyModuleDef *module, pid_t pid, int options) /*[clinic end generated code: output=20dfb05289d37dc6 input=d11deed0750600ba]*/ { + pid_t res; struct rusage ru; + int async_err = 0; WAIT_TYPE status; WAIT_STATUS_INT(status) = 0; - Py_BEGIN_ALLOW_THREADS - pid = wait4(pid, &status, options, &ru); - Py_END_ALLOW_THREADS - - return wait_helper(pid, WAIT_STATUS_INT(status), &ru); + do { + Py_BEGIN_ALLOW_THREADS + res = wait4(pid, &status, options, &ru); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res < 0) + return (!async_err) ? posix_error() : NULL; + + return wait_helper(res, WAIT_STATUS_INT(status), &ru); } #endif /* HAVE_WAIT4 */ @@ -9744,14 +9768,17 @@ { PyObject *result; int res; + int async_err = 0; siginfo_t si; si.si_pid = 0; - Py_BEGIN_ALLOW_THREADS - res = waitid(idtype, id, &si, options); - Py_END_ALLOW_THREADS - if (res == -1) - return posix_error(); + do { + Py_BEGIN_ALLOW_THREADS + res = waitid(idtype, id, &si, options); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res < 0) + return (!async_err) ? posix_error() : NULL; if (si.si_pid == 0) Py_RETURN_NONE; @@ -9828,16 +9855,20 @@ os_waitpid_impl(PyModuleDef *module, pid_t pid, int options) /*[clinic end generated code: output=095a6b00af70b7ac input=0bf1666b8758fda3]*/ { + pid_t res; + int async_err = 0; WAIT_TYPE status; WAIT_STATUS_INT(status) = 0; - Py_BEGIN_ALLOW_THREADS - pid = waitpid(pid, &status, options); - Py_END_ALLOW_THREADS - if (pid == -1) - return posix_error(); - - return Py_BuildValue("Ni", PyLong_FromPid(pid), WAIT_STATUS_INT(status)); + do { + Py_BEGIN_ALLOW_THREADS + res = waitpid(pid, &status, options); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res < 0) + return (!async_err) ? posix_error() : NULL; + + return Py_BuildValue("Ni", PyLong_FromPid(res), WAIT_STATUS_INT(status)); } #elif defined(HAVE_CWAIT) /* MS C has a variant of waitpid() that's usable for most purposes. */ @@ -9894,15 +9925,19 @@ /*[clinic end generated code: output=c20b95b15ad44a3a input=444c8f51cca5b862]*/ { int status; - - Py_BEGIN_ALLOW_THREADS - pid = _cwait(&status, pid, options); - Py_END_ALLOW_THREADS - if (pid == -1) - return posix_error(); + Py_intptr_t res; + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + res = _cwait(&status, pid, options); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res != 0) + return (!async_err) ? posix_error() : NULL; /* shift the status left a byte so this is more like the POSIX waitpid */ - return Py_BuildValue(_Py_PARSE_INTPTR "i", pid, status << 8); + return Py_BuildValue(_Py_PARSE_INTPTR "i", res, status << 8); } #endif @@ -9943,14 +9978,17 @@ /*[clinic end generated code: output=2a83a9d164e7e6a8 input=03b0182d4a4700ce]*/ { pid_t pid; + int async_err = 0; WAIT_TYPE status; WAIT_STATUS_INT(status) = 0; - Py_BEGIN_ALLOW_THREADS - pid = wait(&status); - Py_END_ALLOW_THREADS - if (pid == -1) - return posix_error(); + do { + Py_BEGIN_ALLOW_THREADS + pid = wait(&status); + Py_END_ALLOW_THREADS + } while (pid < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (pid < 0) + return (!async_err) ? posix_error() : NULL; return Py_BuildValue("Ni", PyLong_FromPid(pid), WAIT_STATUS_INT(status)); } @@ -11080,6 +11118,7 @@ /*[clinic end generated code: output=531e482dd11a99a0 input=76e96f511be0352f]*/ { int res; + int async_err = 0; #if defined(HAVE_DUP3) && \ !(defined(HAVE_FCNTL_H) && defined(F_DUP2FD_CLOEXEC)) /* dup3() is available on Linux 2.6.27+ and glibc 2.9 */ @@ -11103,38 +11142,46 @@ } #elif defined(HAVE_FCNTL_H) && defined(F_DUP2FD_CLOEXEC) - Py_BEGIN_ALLOW_THREADS - if (!inheritable) - res = fcntl(fd, F_DUP2FD_CLOEXEC, fd2); - else - res = dup2(fd, fd2); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + if (!inheritable) + res = fcntl(fd, F_DUP2FD_CLOEXEC, fd2); + else + res = dup2(fd, fd2); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (res < 0) - return posix_error(); + return (!async_err) ? posix_error() : NULL; #else #ifdef HAVE_DUP3 if (!inheritable && dup3_works != 0) { - Py_BEGIN_ALLOW_THREADS - res = dup3(fd, fd2, O_CLOEXEC); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + res = dup3(fd, fd2, O_CLOEXEC); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); if (res < 0) { if (dup3_works == -1) dup3_works = (errno != ENOSYS); if (dup3_works) - return posix_error(); + return (!async_err) ? posix_error() : NULL; } } if (inheritable || dup3_works == 0) { #endif - Py_BEGIN_ALLOW_THREADS - res = dup2(fd, fd2); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + res = dup2(fd, fd2); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); if (res < 0) - return posix_error(); + return (!async_err) ? posix_error() : NULL; if (!inheritable && _Py_set_inheritable(fd2, 0, NULL) < 0) { close(fd2); @@ -11355,6 +11402,7 @@ /*[clinic end generated code: output=1f3bc27260a24968 input=1df2eaa27c0bf1d3]*/ { Py_ssize_t n; + int async_err = 0; PyObject *buffer; if (length < 0) { @@ -11375,13 +11423,16 @@ buffer = PyBytes_FromStringAndSize((char *)NULL, length); if (buffer == NULL) return NULL; - Py_BEGIN_ALLOW_THREADS - n = read(fd, PyBytes_AS_STRING(buffer), READ_CAST length); - Py_END_ALLOW_THREADS + + do { + Py_BEGIN_ALLOW_THREADS + n = read(fd, PyBytes_AS_STRING(buffer), READ_CAST length); + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (n < 0) { Py_DECREF(buffer); - return posix_error(); + return (!async_err) ? posix_error() : NULL; } if (n != length) @@ -11515,6 +11566,7 @@ { int cnt; Py_ssize_t n; + int async_err = 0; struct iovec *iov; Py_buffer *buf; @@ -11529,13 +11581,16 @@ if (iov_setup(&iov, &buf, buffers, cnt, PyBUF_WRITABLE) < 0) return -1; - Py_BEGIN_ALLOW_THREADS - n = readv(fd, iov, cnt); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + n = readv(fd, iov, cnt); + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); iov_cleanup(iov, buf, cnt); if (n < 0) { - posix_error(); + if (!async_err) + posix_error(); return -1; } @@ -11598,6 +11653,7 @@ /*[clinic end generated code: output=7b62bf6c06e20ae8 input=084948dcbaa35d4c]*/ { Py_ssize_t n; + int async_err = 0; PyObject *buffer; if (length < 0) { @@ -11611,12 +11667,16 @@ Py_DECREF(buffer); return posix_error(); } - Py_BEGIN_ALLOW_THREADS - n = pread(fd, PyBytes_AS_STRING(buffer), length, offset); - Py_END_ALLOW_THREADS + + do { + Py_BEGIN_ALLOW_THREADS + n = pread(fd, PyBytes_AS_STRING(buffer), length, offset); + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (n < 0) { Py_DECREF(buffer); - return posix_error(); + return (!async_err) ? posix_error() : NULL; } if (n != length) _PyBytes_Resize(&buffer, n); @@ -11677,6 +11737,7 @@ /*[clinic end generated code: output=aeb96acfdd4d5112 input=3207e28963234f3c]*/ { Py_ssize_t size; + int async_err = 0; Py_ssize_t len = data->len; if (!_PyVerify_fd(fd)) { @@ -11684,17 +11745,21 @@ return -1; } - Py_BEGIN_ALLOW_THREADS -#ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - size = write(fd, data->buf, (int)len); -#else - size = write(fd, data->buf, len); -#endif - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS +#ifdef MS_WINDOWS + if (len > INT_MAX) + len = INT_MAX; + size = write(fd, data->buf, (int)len); +#else + size = write(fd, data->buf, len); +#endif + Py_END_ALLOW_THREADS + } while (size < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (size < 0) { - posix_error(); + if (!async_err) + posix_error(); return -1; } return size; @@ -11713,6 +11778,7 @@ { int in, out; Py_ssize_t ret; + int async_err = 0; off_t offset; #if defined(__FreeBSD__) || defined(__DragonFly__) || defined(__APPLE__) @@ -11775,13 +11841,15 @@ } } - Py_BEGIN_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS #ifdef __APPLE__ - ret = sendfile(in, out, offset, &sbytes, &sf, flags); -#else - ret = sendfile(in, out, offset, len, &sf, &sbytes, flags); -#endif - Py_END_ALLOW_THREADS + ret = sendfile(in, out, offset, &sbytes, &sf, flags); +#else + ret = sendfile(in, out, offset, len, &sf, &sbytes, flags); +#endif + Py_END_ALLOW_THREADS + } while (ret < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (sf.headers != NULL) iov_cleanup(sf.headers, hbuf, sf.hdr_cnt); @@ -11800,7 +11868,7 @@ return posix_error(); } } - return posix_error(); + return (!async_err) ? posix_error() : NULL; } goto done; @@ -11821,21 +11889,26 @@ return NULL; #ifdef linux if (offobj == Py_None) { + do { + Py_BEGIN_ALLOW_THREADS + ret = sendfile(out, in, NULL, count); + Py_END_ALLOW_THREADS + } while (ret < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (ret < 0) + return (!async_err) ? posix_error() : NULL; + return Py_BuildValue("n", ret); + } +#endif + if (!Py_off_t_converter(offobj, &offset)) + return NULL; + + do { Py_BEGIN_ALLOW_THREADS - ret = sendfile(out, in, NULL, count); + ret = sendfile(out, in, &offset, count); Py_END_ALLOW_THREADS - if (ret < 0) - return posix_error(); - return Py_BuildValue("n", ret); - } -#endif - if (!Py_off_t_converter(offobj, &offset)) - return NULL; - Py_BEGIN_ALLOW_THREADS - ret = sendfile(out, in, &offset, count); - Py_END_ALLOW_THREADS + } while (ret < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (ret < 0) - return posix_error(); + return (!async_err) ? posix_error() : NULL; return Py_BuildValue("n", ret); #endif } @@ -11891,15 +11964,18 @@ { STRUCT_STAT st; int res; - - Py_BEGIN_ALLOW_THREADS - res = FSTAT(fd, &st); - Py_END_ALLOW_THREADS + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + res = FSTAT(fd, &st); + Py_END_ALLOW_THREADS + } while (res != 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (res != 0) { #ifdef MS_WINDOWS return PyErr_SetFromWindowsErr(0); #else - return posix_error(); + return (!async_err) ? posix_error() : NULL; #endif } @@ -12185,6 +12261,7 @@ { int cnt; Py_ssize_t result; + int async_err = 0; struct iovec *iov; Py_buffer *buf; @@ -12199,12 +12276,14 @@ return -1; } - Py_BEGIN_ALLOW_THREADS - result = writev(fd, iov, cnt); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + result = writev(fd, iov, cnt); + Py_END_ALLOW_THREADS + } while (result < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); iov_cleanup(iov, buf, cnt); - if (result < 0) + if (result < 0 && !async_err) posix_error(); return result; @@ -12275,17 +12354,20 @@ /*[clinic end generated code: output=ec9cc5b2238e96a7 input=19903f1b3dd26377]*/ { Py_ssize_t size; + int async_err = 0; if (!_PyVerify_fd(fd)) { posix_error(); return -1; } - Py_BEGIN_ALLOW_THREADS - size = pwrite(fd, buffer->buf, (size_t)buffer->len, offset); - Py_END_ALLOW_THREADS - - if (size < 0) + do { + Py_BEGIN_ALLOW_THREADS + size = pwrite(fd, buffer->buf, (size_t)buffer->len, offset); + Py_END_ALLOW_THREADS + } while (size < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + + if (size < 0 && !async_err) posix_error(); return size; } @@ -12353,18 +12435,21 @@ /*[clinic end generated code: output=b3321927546893d0 input=73032e98a36e0e19]*/ { int result; - - Py_BEGIN_ALLOW_THREADS + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS #ifdef HAVE_MKFIFOAT - if (dir_fd != DEFAULT_DIR_FD) - result = mkfifoat(dir_fd, path->narrow, mode); - else -#endif - result = mkfifo(path->narrow, mode); - Py_END_ALLOW_THREADS - - if (result < 0) - return posix_error(); + if (dir_fd != DEFAULT_DIR_FD) + result = mkfifoat(dir_fd, path->narrow, mode); + else +#endif + result = mkfifo(path->narrow, mode); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); + if (result != 0) + return (!async_err) ? posix_error() : NULL; Py_RETURN_NONE; } @@ -12448,18 +12533,21 @@ /*[clinic end generated code: output=f71d54eaf9bb6f1a input=ee44531551a4d83b]*/ { int result; - - Py_BEGIN_ALLOW_THREADS + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS #ifdef HAVE_MKNODAT - if (dir_fd != DEFAULT_DIR_FD) - result = mknodat(dir_fd, path->narrow, mode, device); - else -#endif - result = mknod(path->narrow, mode, device); - Py_END_ALLOW_THREADS - - if (result < 0) - return posix_error(); + if (dir_fd != DEFAULT_DIR_FD) + result = mknodat(dir_fd, path->narrow, mode, device); + else +#endif + result = mknod(path->narrow, mode, device); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); + if (result != 0) + return (!async_err) ? posix_error() : NULL; Py_RETURN_NONE; } @@ -12662,12 +12750,16 @@ /*[clinic end generated code: output=62326766cb9b76bf input=63b43641e52818f2]*/ { int result; - - Py_BEGIN_ALLOW_THREADS - result = ftruncate(fd, length); - Py_END_ALLOW_THREADS - if (result < 0) - return posix_error(); + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + result = ftruncate(fd, length); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); + if (result != 0) + return (!async_err) ? posix_error() : NULL; Py_RETURN_NONE; } #endif /* HAVE_FTRUNCATE */ @@ -12805,14 +12897,16 @@ /*[clinic end generated code: output=0cd702d2065c79db input=d7a2ef0ab2ca52fb]*/ { int result; - - Py_BEGIN_ALLOW_THREADS - result = posix_fallocate(fd, offset, length); - Py_END_ALLOW_THREADS - if (result != 0) { - errno = result; - return posix_error(); - } + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + result = posix_fallocate(fd, offset, length); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); + if (result != 0) + return (!async_err) ? posix_error() : NULL; Py_RETURN_NONE; } #endif /* HAVE_POSIX_FALLOCATE) && !POSIX_FADVISE_AIX_BUG */ @@ -12883,14 +12977,16 @@ /*[clinic end generated code: output=dad93f32c04dd4f7 input=0fbe554edc2f04b5]*/ { int result; - - Py_BEGIN_ALLOW_THREADS - result = posix_fadvise(fd, offset, length, advice); - Py_END_ALLOW_THREADS - if (result != 0) { - errno = result; - return posix_error(); - } + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + result = posix_fadvise(fd, offset, length, advice); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); + if (result != 0) + return (!async_err) ? posix_error() : NULL; Py_RETURN_NONE; } #endif /* HAVE_POSIX_FADVISE && !POSIX_FADVISE_AIX_BUG */ @@ -13745,13 +13841,17 @@ /*[clinic end generated code: output=0e32bf07f946ec0d input=d8122243ac50975e]*/ { int result; + int async_err = 0; struct statvfs st; - Py_BEGIN_ALLOW_THREADS - result = fstatvfs(fd, &st); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + result = fstatvfs(fd, &st); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); if (result != 0) - return posix_error(); + return (!async_err) ? posix_error() : NULL; return _pystatvfs_fromstructstatvfs(st); } diff -r fe0fddd6fd21 Modules/socketmodule.c --- a/Modules/socketmodule.c Sun Jan 18 11:17:39 2015 +0200 +++ b/Modules/socketmodule.c Thu Jan 29 22:20:01 2015 +0000 @@ -2037,6 +2037,7 @@ PyObject *addr = NULL; PyObject *res = NULL; int timeout; + int async_err = 0; #if defined(HAVE_ACCEPT4) && defined(SOCK_CLOEXEC) /* accept4() is available on Linux 2.6.28+ and glibc 2.10 */ static int accept4_works = -1; @@ -2050,27 +2051,27 @@ return select_error(); BEGIN_SELECT_LOOP(s) - - Py_BEGIN_ALLOW_THREADS - timeout = internal_select_ex(s, 0, interval); - if (!timeout) { + do { + Py_BEGIN_ALLOW_THREADS + timeout = internal_select_ex(s, 0, interval); + if (!timeout) { #if defined(HAVE_ACCEPT4) && defined(SOCK_CLOEXEC) - if (accept4_works != 0) { - newfd = accept4(s->sock_fd, SAS2SA(&addrbuf), &addrlen, - SOCK_CLOEXEC); - if (newfd == INVALID_SOCKET && accept4_works == -1) { - /* On Linux older than 2.6.28, accept4() fails with ENOSYS */ - accept4_works = (errno != ENOSYS); + if (accept4_works != 0) { + newfd = accept4(s->sock_fd, SAS2SA(&addrbuf), &addrlen, + SOCK_CLOEXEC); + if (newfd == INVALID_SOCKET && accept4_works == -1) { + /* On Linux older than 2.6.28, accept4() fails with ENOSYS */ + accept4_works = (errno != ENOSYS); + } } + if (accept4_works == 0) + newfd = accept(s->sock_fd, SAS2SA(&addrbuf), &addrlen); +#else + newfd = accept(s->sock_fd, SAS2SA(&addrbuf), &addrlen); +#endif } - if (accept4_works == 0) - newfd = accept(s->sock_fd, SAS2SA(&addrbuf), &addrlen); -#else - newfd = accept(s->sock_fd, SAS2SA(&addrbuf), &addrlen); -#endif - } - Py_END_ALLOW_THREADS - + Py_END_ALLOW_THREADS + } while (newfd < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (timeout == 1) { PyErr_SetString(socket_timeout, "timed out"); return NULL; @@ -2078,7 +2079,7 @@ END_SELECT_LOOP(s) if (newfd == INVALID_SOCKET) - return s->errorhandler(); + return (!async_err) ? s->errorhandler() : NULL; #ifdef MS_WINDOWS if (!SetHandleInformation((HANDLE)newfd, HANDLE_FLAG_INHERIT, 0)) { @@ -2513,10 +2514,8 @@ /* Signals are not errors (though they may raise exceptions). Adapted from PyErr_SetFromErrnoWithFilenameObject(). */ -#ifdef EINTR if (res == EINTR && PyErr_CheckSignals()) return NULL; -#endif return PyLong_FromLong((long) res); } @@ -2650,6 +2649,7 @@ { Py_ssize_t outlen = -1; int timeout; + int async_err = 0; if (!IS_SELECTABLE(s)) { select_error(); @@ -2661,18 +2661,20 @@ } BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS - timeout = internal_select_ex(s, 0, interval); - if (!timeout) { + do { + Py_BEGIN_ALLOW_THREADS + timeout = internal_select_ex(s, 0, interval); + if (!timeout) { #ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - outlen = recv(s->sock_fd, cbuf, (int)len, flags); + if (len > INT_MAX) + len = INT_MAX; + outlen = recv(s->sock_fd, cbuf, (int)len, flags); #else - outlen = recv(s->sock_fd, cbuf, len, flags); -#endif - } - Py_END_ALLOW_THREADS + outlen = recv(s->sock_fd, cbuf, len, flags); +#endif + } + Py_END_ALLOW_THREADS + } while (outlen < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (timeout == 1) { PyErr_SetString(socket_timeout, "timed out"); @@ -2682,7 +2684,8 @@ if (outlen < 0) { /* Note: the call to errorhandler() ALWAYS indirectly returned NULL, so ignore its return value */ - s->errorhandler(); + if (!async_err) + s->errorhandler(); return -1; } return outlen; @@ -2819,6 +2822,7 @@ int timeout; Py_ssize_t n = -1; socklen_t addrlen; + int async_err = 0; *addr = NULL; @@ -2831,21 +2835,23 @@ } BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS - memset(&addrbuf, 0, addrlen); - timeout = internal_select_ex(s, 0, interval); - if (!timeout) { + do { + Py_BEGIN_ALLOW_THREADS + memset(&addrbuf, 0, addrlen); + timeout = internal_select_ex(s, 0, interval); + if (!timeout) { #ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - n = recvfrom(s->sock_fd, cbuf, (int)len, flags, - (void *) &addrbuf, &addrlen); + if (len > INT_MAX) + len = INT_MAX; + n = recvfrom(s->sock_fd, cbuf, (int)len, flags, + (void *) &addrbuf, &addrlen); #else - n = recvfrom(s->sock_fd, cbuf, len, flags, - SAS2SA(&addrbuf), &addrlen); -#endif - } - Py_END_ALLOW_THREADS + n = recvfrom(s->sock_fd, cbuf, len, flags, + SAS2SA(&addrbuf), &addrlen); +#endif + } + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (timeout == 1) { PyErr_SetString(socket_timeout, "timed out"); @@ -2853,7 +2859,8 @@ } END_SELECT_LOOP(s) if (n < 0) { - s->errorhandler(); + if (!async_err) + s->errorhandler(); return -1; } @@ -2993,6 +3000,7 @@ { ssize_t bytes_received = -1; int timeout; + int async_err = 0; sock_addr_t addrbuf; socklen_t addrbuflen; struct msghdr msg = {0}; @@ -3028,25 +3036,29 @@ } BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS; - msg.msg_name = SAS2SA(&addrbuf); - msg.msg_namelen = addrbuflen; - msg.msg_iov = iov; - msg.msg_iovlen = iovlen; - msg.msg_control = controlbuf; - msg.msg_controllen = controllen; - timeout = internal_select_ex(s, 0, interval); - if (!timeout) - bytes_received = recvmsg(s->sock_fd, &msg, flags); - Py_END_ALLOW_THREADS; - if (timeout == 1) { - PyErr_SetString(socket_timeout, "timed out"); - goto finally; - } + do { + Py_BEGIN_ALLOW_THREADS; + msg.msg_name = SAS2SA(&addrbuf); + msg.msg_namelen = addrbuflen; + msg.msg_iov = iov; + msg.msg_iovlen = iovlen; + msg.msg_control = controlbuf; + msg.msg_controllen = controllen; + timeout = internal_select_ex(s, 0, interval); + if (!timeout) + bytes_received = recvmsg(s->sock_fd, &msg, flags); + Py_END_ALLOW_THREADS; + if (timeout == 1) { + PyErr_SetString(socket_timeout, "timed out"); + goto finally; + } + } while (bytes_received < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); END_SELECT_LOOP(s) if (bytes_received < 0) { - s->errorhandler(); + if (!async_err) + s->errorhandler(); goto finally; } @@ -3305,6 +3317,7 @@ { char *buf; Py_ssize_t len, n = -1; + int async_err = 0; int flags = 0, timeout; Py_buffer pbuf; @@ -3319,18 +3332,20 @@ len = pbuf.len; BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS - timeout = internal_select_ex(s, 1, interval); - if (!timeout) { + do { + Py_BEGIN_ALLOW_THREADS + timeout = internal_select_ex(s, 1, interval); + if (!timeout) { #ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - n = send(s->sock_fd, buf, (int)len, flags); + if (len > INT_MAX) + len = INT_MAX; + n = send(s->sock_fd, buf, (int)len, flags); #else - n = send(s->sock_fd, buf, len, flags); -#endif - } - Py_END_ALLOW_THREADS + n = send(s->sock_fd, buf, len, flags); +#endif + } + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (timeout == 1) { PyBuffer_Release(&pbuf); PyErr_SetString(socket_timeout, "timed out"); @@ -3340,7 +3355,7 @@ PyBuffer_Release(&pbuf); if (n < 0) - return s->errorhandler(); + return (!async_err) ? s->errorhandler() : NULL; return PyLong_FromSsize_t(n); } @@ -3359,7 +3374,8 @@ { char *buf; Py_ssize_t len, n = -1; - int flags = 0, timeout, saved_errno; + int async_err = 0; + int flags = 0, timeout; Py_buffer pbuf; if (!PyArg_ParseTuple(args, "y*|i:sendall", &pbuf, &flags)) @@ -3391,29 +3407,16 @@ PyErr_SetString(socket_timeout, "timed out"); return NULL; } - /* PyErr_CheckSignals() might change errno */ - saved_errno = errno; - /* We must run our signal handlers before looping again. - send() can return a successful partial write when it is - interrupted, so we can't restrict ourselves to EINTR. */ - if (PyErr_CheckSignals()) { - PyBuffer_Release(&pbuf); - return NULL; + if (n >= 0) { + buf += n; + len -= n; } - if (n < 0) { - /* If interrupted, try again */ - if (saved_errno == EINTR) - continue; - else - break; - } - buf += n; - len -= n; - } while (len > 0); + } while (len > 0 && (n >= 0 || errno == EINTR) && + !(async_err = PyErr_CheckSignals())); PyBuffer_Release(&pbuf); - if (n < 0) - return s->errorhandler(); + if (n < 0 || async_err) + return (!async_err) ? s->errorhandler() : NULL; Py_INCREF(Py_None); return Py_None; @@ -3439,6 +3442,7 @@ Py_ssize_t len, arglen; sock_addr_t addrbuf; int addrlen, n = -1, flags, timeout; + int async_err = 0; flags = 0; arglen = PyTuple_Size(args); @@ -3473,20 +3477,22 @@ } BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS - timeout = internal_select_ex(s, 1, interval); - if (!timeout) { + do { + Py_BEGIN_ALLOW_THREADS + timeout = internal_select_ex(s, 1, interval); + if (!timeout) { #ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - n = sendto(s->sock_fd, buf, (int)len, flags, - SAS2SA(&addrbuf), addrlen); + if (len > INT_MAX) + len = INT_MAX; + n = sendto(s->sock_fd, buf, (int)len, flags, + SAS2SA(&addrbuf), addrlen); #else - n = sendto(s->sock_fd, buf, len, flags, - SAS2SA(&addrbuf), addrlen); -#endif - } - Py_END_ALLOW_THREADS + n = sendto(s->sock_fd, buf, len, flags, + SAS2SA(&addrbuf), addrlen); +#endif + } + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (timeout == 1) { PyBuffer_Release(&pbuf); @@ -3496,7 +3502,7 @@ END_SELECT_LOOP(s) PyBuffer_Release(&pbuf); if (n < 0) - return s->errorhandler(); + return (!async_err) ? s->errorhandler() : NULL; return PyLong_FromSsize_t(n); } @@ -3528,6 +3534,7 @@ void *controlbuf = NULL; size_t controllen, controllen_last; ssize_t bytes_sent = -1; + int async_err = 0; int addrlen, timeout, flags = 0; PyObject *data_arg, *cmsg_arg = NULL, *addr_arg = NULL, *data_fast = NULL, *cmsg_fast = NULL, *retval = NULL; @@ -3685,19 +3692,23 @@ } BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS; - timeout = internal_select_ex(s, 1, interval); - if (!timeout) - bytes_sent = sendmsg(s->sock_fd, &msg, flags); - Py_END_ALLOW_THREADS; - if (timeout == 1) { - PyErr_SetString(socket_timeout, "timed out"); - goto finally; - } + do { + Py_BEGIN_ALLOW_THREADS; + timeout = internal_select_ex(s, 1, interval); + if (!timeout) + bytes_sent = sendmsg(s->sock_fd, &msg, flags); + Py_END_ALLOW_THREADS; + if (timeout == 1) { + PyErr_SetString(socket_timeout, "timed out"); + goto finally; + } + } while (bytes_sent < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); END_SELECT_LOOP(s) if (bytes_sent < 0) { - s->errorhandler(); + if (!async_err) + s->errorhandler(); goto finally; } retval = PyLong_FromSsize_t(bytes_sent); From report at bugs.python.org Fri Jan 30 12:42:09 2015 From: report at bugs.python.org (Neil Girdhar) Date: Fri, 30 Jan 2015 11:42:09 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422618129.51.0.537697106185.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Fixed a bug and added a test. ---------- Added file: http://bugs.python.org/file37921/starunpack27.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 12:54:16 2015 From: report at bugs.python.org (Neil Girdhar) Date: Fri, 30 Jan 2015 11:54:16 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422618856.25.0.212715132304.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Is it possible to edit the PEP to reflect the current design decisions? Specifically: * Remove: "Because of the new levity for * and ** unpackings, it may be advisable to lift some or all of these restrictions." (in both abstract and specification) * Extend: "Currently duplicate arguments raise TypeError. This remains true for duplicate arguments provided through multiple keyword argument unpackings, e.g. f(**{'x': 2}, **{'x': 3}) * Add some examples of dictionary overriding to the list of examples: >>> {'x': 1, **{'x': 2}} {'x': 2} >>> {**{'x': 2}, 'x': 1} {'x': 1} * Remove "if the restrictions are kept" (they are) * Remove "If they are removed completely..." * In disadvantages, remove "if the current are kept" (they are). Don't write "* unpackings", write "iterable unpackings" * Remove "if the current restrictions are lifted" * Remove "Implementation" section (it's done!) * Add to specification: "f(*x for x in it) and f(**x for x in it)" remain SyntaxErrors. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 14:10:57 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 30 Jan 2015 13:10:57 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422623457.19.0.150529829033.issue23352@psf.upfronthosting.co.za> Stefan Krah added the comment: PEP-3118 says: Py_buffer.suboffsets: "If all suboffsets are negative (i.e. no de-referencing is needed, then this must be NULL (the default value)." I would be inclined to go with the PEP here and make a doc fix instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 15:08:56 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 30 Jan 2015 14:08:56 +0000 Subject: [issue23353] gnerator bug with exception: tstate->exc_value is not cleared after an except block Message-ID: <1422626936.33.0.830645939586.issue23353@psf.upfronthosting.co.za> New submission from STINNER Victor: Since my changeset a5efd5021ca1, the Python test suite starts to fail randomly. Running test_asyncio modifies sys.exc_info(): it is not (None, None, None) after the execution of test_asyncio. The problem comes from test_cancel_make_subprocess_transport_exec() of Lib/test/test_asyncio/test_subprocess.py. I tried to write a simple script which does not depend on Python to reproduce the issue. See attached excinfo_bug2.py script. Output: --- exc_info after except (, MyException(), ) exc_info at exit (, MyException(), ) --- exc_info is supposed to be (None, None, None), at least at exit. I will try to write an even simpler script to identify the bug. ---------- files: excinfo_bug2.py messages: 235033 nosy: haypo priority: normal severity: normal status: open title: gnerator bug with exception: tstate->exc_value is not cleared after an except block versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37922/excinfo_bug2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 15:29:25 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 30 Jan 2015 14:29:25 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422628165.72.0.142566121053.issue23352@psf.upfronthosting.co.za> Stefan Krah added the comment: For the record: I'm myself guilty of accepting all-negative suboffsets in memoryview.c (see init_slice()) and I think there's even a test for it. However, while it's ok for a specific function to accept this corner case, I'm not sure about is_contiguous(). People might rely on the fact that contiguous implies suboffsets==NULL. Sebastian, did this special case ever come up in the context of NumPy? ---------- nosy: +seberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 15:35:07 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 30 Jan 2015 14:35:07 +0000 Subject: [issue23349] PyBuffer_ToContiguous() off-by-one error for non-contiguous buffers In-Reply-To: <1422580028.66.0.282678068687.issue23349@psf.upfronthosting.co.za> Message-ID: <1422628507.63.0.692189638196.issue23349@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 16:00:50 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 30 Jan 2015 15:00:50 +0000 Subject: [issue23284] Improve termcap detection in setup.py In-Reply-To: <1421794283.67.0.365311015753.issue23284@psf.upfronthosting.co.za> Message-ID: <1422630050.85.0.808121834933.issue23284@psf.upfronthosting.co.za> Stefan Krah added the comment: Ok thanks, I understand the issue now. I'm focusing this issue on the termcap detection. For the other parts of the patch you'd have to open separate issues. As an aside, the ncurses maintainer seems to endorse a distro enforced choice for libreadline's termcap: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602720 ---------- title: curses, readline, tinfo, and also --prefix, dbm, CPPFLAGS -> Improve termcap detection in setup.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 16:21:32 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 30 Jan 2015 15:21:32 +0000 Subject: [issue23284] Improve termcap detection in setup.py In-Reply-To: <1421794283.67.0.365311015753.issue23284@psf.upfronthosting.co.za> Message-ID: <1422631292.69.0.592258158599.issue23284@psf.upfronthosting.co.za> Stefan Krah added the comment: FWIW, even http://www.linuxfromscratch.org/lfs/view/stable/chapter06/readline.html enforces -ncurses linking of readline. [They should be compiling ncurses with tinfo split out though and use -tinfo instead.] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 16:57:44 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 30 Jan 2015 15:57:44 +0000 Subject: [issue23353] gnerator bug with exception: tstate->exc_value is not cleared after an except block In-Reply-To: <1422626936.33.0.830645939586.issue23353@psf.upfronthosting.co.za> Message-ID: <1422633464.57.0.961369316007.issue23353@psf.upfronthosting.co.za> STINNER Victor added the comment: I simplified the script even more: 287 lines (6 functions/generators, 7 classes/exceptions) => 28 lines (1 generator)! ---------- Added file: http://bugs.python.org/file37923/excinfo_bug6.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 17:01:47 2015 From: report at bugs.python.org (Neil Girdhar) Date: Fri, 30 Jan 2015 16:01:47 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422633707.49.0.0569440081943.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Fixed a bug in ceval.c; added a test to test_unpack_ex. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 17:01:59 2015 From: report at bugs.python.org (Neil Girdhar) Date: Fri, 30 Jan 2015 16:01:59 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422633719.82.0.138856887528.issue2292@psf.upfronthosting.co.za> Changes by Neil Girdhar : Added file: http://bugs.python.org/file37924/starunpack28.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 17:02:24 2015 From: report at bugs.python.org (Neil Girdhar) Date: Fri, 30 Jan 2015 16:02:24 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422633744.52.0.244046768816.issue2292@psf.upfronthosting.co.za> Changes by Neil Girdhar : Removed file: http://bugs.python.org/file37924/starunpack28.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 17:02:37 2015 From: report at bugs.python.org (Neil Girdhar) Date: Fri, 30 Jan 2015 16:02:37 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422633757.24.0.700986690535.issue2292@psf.upfronthosting.co.za> Changes by Neil Girdhar : Added file: http://bugs.python.org/file37925/starunpack28.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 17:06:32 2015 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 30 Jan 2015 16:06:32 +0000 Subject: [issue23348] distutils.LooseVersion fails to compare two valid versions In-Reply-To: <1422542520.54.0.739308889883.issue23348@psf.upfronthosting.co.za> Message-ID: <1422633992.3.0.531411442193.issue23348@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks for the report. I think there?s already a long discussion in another ticket but don?t have time to search right now. ---------- resolution: -> duplicate _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 17:22:16 2015 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 30 Jan 2015 16:22:16 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1422618856.25.0.212715132304.issue2292@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: For the PEP update, please check out the PEP repo at hg.python.org and send a patch to peps at python.org. On Jan 30, 2015 3:54 AM, "Neil Girdhar" wrote: > > Neil Girdhar added the comment: > > Is it possible to edit the PEP to reflect the current design decisions? > > Specifically: > > * Remove: "Because of the new levity for * and ** unpackings, it may be > advisable to lift some or all of these restrictions." (in both abstract and > specification) > * Extend: "Currently duplicate arguments raise TypeError. This remains > true for duplicate arguments provided through multiple keyword argument > unpackings, e.g. f(**{'x': 2}, **{'x': 3}) > * Add some examples of dictionary overriding to the list of examples: > > >>> {'x': 1, **{'x': 2}} > {'x': 2} > > >>> {**{'x': 2}, 'x': 1} > {'x': 1} > > * Remove "if the restrictions are kept" (they are) > * Remove "If they are removed completely..." > * In disadvantages, remove "if the current are kept" (they are). Don't > write "* unpackings", write "iterable unpackings" > * Remove "if the current restrictions are lifted" > * Remove "Implementation" section (it's done!) > * Add to specification: "f(*x for x in it) and f(**x for x in it)" remain > SyntaxErrors. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 17:36:03 2015 From: report at bugs.python.org (Neil Girdhar) Date: Fri, 30 Jan 2015 16:36:03 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422635763.09.0.219529848338.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Another bug, another test. ---------- Added file: http://bugs.python.org/file37926/starunpack29.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 18:20:18 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 30 Jan 2015 17:20:18 +0000 Subject: [issue23349] PyBuffer_ToContiguous() off-by-one error for non-contiguous buffers In-Reply-To: <1422580028.66.0.282678068687.issue23349@psf.upfronthosting.co.za> Message-ID: <1422638418.38.0.539020196929.issue23349@psf.upfronthosting.co.za> Stefan Krah added the comment: Looks good, here's a patch with tests. ---------- Added file: http://bugs.python.org/file37927/issue23349-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 18:27:25 2015 From: report at bugs.python.org (Guillaume) Date: Fri, 30 Jan 2015 17:27:25 +0000 Subject: [issue23348] distutils.LooseVersion fails to compare two valid versions In-Reply-To: <1422542520.54.0.739308889883.issue23348@psf.upfronthosting.co.za> Message-ID: <1422638845.01.0.292682990549.issue23348@psf.upfronthosting.co.za> Guillaume added the comment: Do you mean http://bugs.python.org/issue14894 ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 18:31:40 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 30 Jan 2015 17:31:40 +0000 Subject: [issue23351] socket.settimeout(5.0) does not have any effect In-Reply-To: <1422581292.34.0.901742947923.issue23351@psf.upfronthosting.co.za> Message-ID: <1422639100.74.0.621775221164.issue23351@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The test script works on Ubuntu 14.10 as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 18:45:36 2015 From: report at bugs.python.org (Lukasz Szybalski) Date: Fri, 30 Jan 2015 17:45:36 +0000 Subject: [issue16318] FTP_TLS in ftplib not supporting prot_p storlines in FTP7.5 In-Reply-To: <1351120164.32.0.969400884781.issue16318@psf.upfronthosting.co.za> Message-ID: <1422639936.77.0.660150883642.issue16318@psf.upfronthosting.co.za> Lukasz Szybalski added the comment: Hello, We are having issues usign ftplib for implicit TLS over port 990 I'm referencing a solution that states "For the implicit FTP TLS/SSL(defualt port 990), our client program must build a TLS/SSL connection right after the socket is created. But python's class FTP_TLS doesn't reload the connect function from class FTP. We need to fix it:" http://stackoverflow.com/questions/12164470/python-ftp-tls-connection-issue {{{ #ImplicityTLS.py from ftplib import FTP_TLS import socket import ssl class tyFTP(FTP_TLS): def __init__(self, host='', user='', passwd='', acct='', keyfile=None, certfile=None, timeout=60): FTP_TLS.__init__(self, host, user, passwd, acct, keyfile, certfile, timeout) def connect(self, host='', port=0, timeout=-999): if host != '': self.host = host if port > 0: self.port = port if timeout != -999: self.timeout = timeout try: self.sock = socket.create_connection((self.host, self.port), self.timeout) self.af = self.sock.family self.sock = ssl.wrap_socket(self.sock, self.keyfile, self.certfile, ssl_version=ssl.PROTOCOL_TLSv1) self.file = self.sock.makefile('rb') self.welcome = self.getresp() except Exception as e: print e return self.welcome }}} Then from my main application I did this: {{{ from ImplicityTLS import tyFTP server = tyFTP() server.connect(host="xxxxx", port=990) server.login(user="yyyy", passwd="fffff") server.prot_p() }}} ---------- nosy: +lszyba1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 19:33:54 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 30 Jan 2015 18:33:54 +0000 Subject: [issue22986] Improved handling of __class__ assignment In-Reply-To: <1417563561.24.0.575634102448.issue22986@psf.upfronthosting.co.za> Message-ID: <20150130183345.39268.35337@psf.io> Roundup Robot added the comment: New changeset c0d25de5919e by Benjamin Peterson in branch 'default': allow changing __class__ between a heaptype and non-heaptype in some cases (closes #22986) https://hg.python.org/cpython/rev/c0d25de5919e ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 20:03:43 2015 From: report at bugs.python.org (Davin Potts) Date: Fri, 30 Jan 2015 19:03:43 +0000 Subject: [issue8534] multiprocessing not working from egg In-Reply-To: <1272279135.33.0.722115657871.issue8534@psf.upfronthosting.co.za> Message-ID: <1422644623.07.0.936927530467.issue8534@psf.upfronthosting.co.za> Davin Potts added the comment: The example demonstrating the issue is reproducible on Windows (tested on Windows 7 64-bit, specifically) with 2.7.9. Complications arising from how multiprocessing creates new processes on Windows combined with conventions in the import system in 2.7.9 result in the problem being triggered here. This issue is specific to Windows platform use: It was not possible to reproduce the issue on OS X nor Linux with 2.7.9. As played out in the discussion around issue10845 (long since closed), solutions were devised and put into place as part of PEP451, exposed first in Python 3.4. And so it was not possible to reproduce this issue with default (3.5) on Windows 7. It is very much appreciated anytime such a nice, clean demonstration code is provided and more than doubly so anytime a proposed patch is also offered. While the supplied/proposed patch does provide some workaround it is not yet a comprehensive solution and appears to potentially cause complications in other scenarios. The current best effort at a comprehensive solution is reflected in the changes designed and now implemented in 3.4. Two aspects to the resolution on this issue: * For the 2.x branches, it is unlikely that we will see a backport of PEP451 and so a more comprehensive solution might depend upon some other fundamental changes to how multiprocessing operates on Windows platforms but there are no such plans to invest that level of effort into 2.7. It is still possible that someone might become so motivated about multiprocessing+Windows+2.7 but that seems ever more unlikely. * For the 3.x branches, we have verified that changes in 3.4 have resulted in a fix for this particular issue. Overall, marking this as fixed in 3.[4-5]. ---------- nosy: +davin resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 20:11:50 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 30 Jan 2015 19:11:50 +0000 Subject: [issue23349] PyBuffer_ToContiguous() off-by-one error for non-contiguous buffers In-Reply-To: <1422580028.66.0.282678068687.issue23349@psf.upfronthosting.co.za> Message-ID: <20150130191140.25845.26273@psf.io> Roundup Robot added the comment: New changeset a9305102c892 by Stefan Krah in branch '2.7': Issue #23349: Fix off-by-one error in PyBuffer_ToContiguous(). Initial patch https://hg.python.org/cpython/rev/a9305102c892 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 20:29:53 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 30 Jan 2015 19:29:53 +0000 Subject: [issue11578] Increase test coverage for timeit.py In-Reply-To: <1300307227.56.0.233218695639.issue11578@psf.upfronthosting.co.za> Message-ID: <1422646193.1.0.512640187995.issue11578@psf.upfronthosting.co.za> Stefan Krah added the comment: I think all 2.7 bots are broken. :) ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 20:43:35 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 30 Jan 2015 19:43:35 +0000 Subject: [issue20416] Marshal: special case int and float, don't use references In-Reply-To: <1390903848.78.0.660754858197.issue20416@psf.upfronthosting.co.za> Message-ID: <1422647015.2.0.296790844606.issue20416@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here are results of the benchmark which measures dump and load time for all pyc files in the stdlib (including tests). https://bitbucket.org/storchaka/cpython-stuff/src/default/marshal/marshalbench.py $ find * -name __pycache__ -exec rm -rf '{}' + $ ./python -m compileall -qq -r 99 Lib $ find Lib -name '*.pyc' | xargs ./python marshalbench.py Without the patch: ver. dumps loads size 770.3 19941.2 0 695.7 1178.4 19941.2 1 680.4 1180.9 19941.2 2 635.9 1115.9 19941.2 3 896.3 757.3 19941.2 4 748.0 700.6 19941.2 With marshal3_numbers.patch: ver. dumps loads size 750.5 19946.1 0 690.2 1173.7 19946.1 1 678.2 1166.6 19946.1 2 630.9 1105.2 19946.1 3 873.2 751.5 19946.1 4 724.6 687.6 19946.1 With marshal_refs_by_value.patch: ver. dumps loads size 780.2 19935.8 0 712.7 1202.6 19935.8 1 713.8 1195.1 19935.8 2 676.5 1126.0 19935.8 3 686.1 762.7 19935.8 4 515.1 697.6 19935.8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 20:44:25 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 30 Jan 2015 19:44:25 +0000 Subject: [issue23055] PyUnicode_FromFormatV crasher In-Reply-To: <1418663915.64.0.885404540917.issue23055@psf.upfronthosting.co.za> Message-ID: <1422647065.94.0.784837638341.issue23055@psf.upfronthosting.co.za> Stefan Krah added the comment: I think in 2.7 there's a slight problem since e6b9e277fbf4: [1/1] test_unicode Debug memory block at address p=0x7f4ebba3fae0: API 'o' 100 bytes originally requested The 7 pad bytes at p-7 are FORBIDDENBYTE, as expected. The 8 pad bytes at tail=0x7f4ebba3fb44 are not all FORBIDDENBYTE (0xfb): at tail+0: 0x00 *** OUCH at tail+1: 0xfb at tail+2: 0xfb at tail+3: 0xfb at tail+4: 0xfb at tail+5: 0xfb at tail+6: 0xfb at tail+7: 0xfb The block was made by call #659785 to debug malloc/realloc. Data at p: 20 20 20 20 20 20 20 20 ... 20 20 20 20 20 31 32 33 Fatal Python error: bad trailing pad byte Aborted (core dumped) ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 21:10:03 2015 From: report at bugs.python.org (Richard Hansen) Date: Fri, 30 Jan 2015 20:10:03 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422648603.95.0.871371965964.issue23352@psf.upfronthosting.co.za> Richard Hansen added the comment: > People might rely on the fact that contiguous implies suboffsets==NULL. Cython (currently) relies on all-negatives being acceptable and equivalent to suboffsets==NULL. See: https://github.com/cython/cython/pull/367 http://thread.gmane.org/gmane.comp.python.cython.devel/15569 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 21:22:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 30 Jan 2015 20:22:55 +0000 Subject: [issue23055] PyUnicode_FromFormatV crasher In-Reply-To: <1418663915.64.0.885404540917.issue23055@psf.upfronthosting.co.za> Message-ID: <1422649375.93.0.368270222932.issue23055@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 21:36:32 2015 From: report at bugs.python.org (Sebastian Berg) Date: Fri, 30 Jan 2015 20:36:32 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422650191.99.0.7380985221.issue23352@psf.upfronthosting.co.za> Sebastian Berg added the comment: Numpy does not understand suboffsets. The buffers we create will always have them NULL. The other way around.... To be honest, think it is probably ignoring the whole fact that they might exist at all :/, really needs to be fixed if it is the case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 22:15:48 2015 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 30 Jan 2015 21:15:48 +0000 Subject: [issue23348] distutils.LooseVersion fails to compare two valid versions In-Reply-To: <1422542520.54.0.739308889883.issue23348@psf.upfronthosting.co.za> Message-ID: <1422652548.54.0.981160098988.issue23348@psf.upfronthosting.co.za> ?ric Araujo added the comment: Yes, thanks. Please weigh in on the other ticket. ---------- status: open -> closed superseder: -> distutils.LooseVersion fails to compare number and a word _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 22:16:07 2015 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 30 Jan 2015 21:16:07 +0000 Subject: [issue14894] distutils.LooseVersion fails to compare number and a word In-Reply-To: <1337805749.61.0.661955519892.issue14894@psf.upfronthosting.co.za> Message-ID: <1422652567.97.0.83786721023.issue14894@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- assignee: eric.araujo -> versions: +Python 3.5 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 22:35:30 2015 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 30 Jan 2015 21:35:30 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422653730.76.0.352672923056.issue2292@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: -eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 22:36:05 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 30 Jan 2015 21:36:05 +0000 Subject: [issue23055] PyUnicode_FromFormatV crasher In-Reply-To: <1418663915.64.0.885404540917.issue23055@psf.upfronthosting.co.za> Message-ID: <20150130213559.96090.70339@psf.io> Roundup Robot added the comment: New changeset e5d79e6deeb5 by Serhiy Storchaka in branch '2.7': Issue #23055: Fixed off-by-one error in PyUnicode_FromFormatV. https://hg.python.org/cpython/rev/e5d79e6deeb5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 22:39:15 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 30 Jan 2015 21:39:15 +0000 Subject: [issue23055] PyUnicode_FromFormatV crasher In-Reply-To: <1418663915.64.0.885404540917.issue23055@psf.upfronthosting.co.za> Message-ID: <1422653955.83.0.201354181646.issue23055@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Backported tests exposed off-by-one error in PyUnicode_FromFormatV. This error was fixed in 3.x in changeset ac768c8e13ac (issue7228). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 22:40:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 30 Jan 2015 21:40:24 +0000 Subject: [issue23055] PyUnicode_FromFormatV crasher In-Reply-To: <1418663915.64.0.885404540917.issue23055@psf.upfronthosting.co.za> Message-ID: <1422654024.84.0.664645475897.issue23055@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Stefan for pointing on tests failure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 22:43:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 30 Jan 2015 21:43:02 +0000 Subject: [issue11578] Increase test coverage for timeit.py In-Reply-To: <1300307227.56.0.233218695639.issue11578@psf.upfronthosting.co.za> Message-ID: <1422654182.25.0.947058845453.issue11578@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 22:48:07 2015 From: report at bugs.python.org (Joshua Landau) Date: Fri, 30 Jan 2015 21:48:07 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1422654487.66.0.103117802382.issue2292@psf.upfronthosting.co.za> Joshua Landau added the comment: Special-cased `(*i for i in x)` to use YIELD_FROM instead of looping. Speed improved, albeit still only half as fast as chain.from_iterable. Fixed error message check in test_syntax and removed semicolons. ---------- Added file: http://bugs.python.org/file37928/starunpack30.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 23:02:44 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 30 Jan 2015 22:02:44 +0000 Subject: [issue23055] PyUnicode_FromFormatV crasher In-Reply-To: <1418663915.64.0.885404540917.issue23055@psf.upfronthosting.co.za> Message-ID: <1422655364.24.0.587866302994.issue23055@psf.upfronthosting.co.za> Stefan Krah added the comment: I think I still get a problem in 2.7: [1/1] test_unicode ==23430== Invalid read of size 1 ==23430== at 0x484541: PyUnicodeUCS2_FromFormatV (unicodeobject.c:736) ==23430== by 0x485C75: PyUnicodeUCS2_FromFormat (unicodeobject.c:1083) 736 for (f = format; *f; f++) { (gdb) p format $1 = 0x71d45f4 "%" (gdb) p f $2 = 0x71d45f6 "" So format=="%", first f++ happens at 738, second f++ happens implicitly at the end of the for loop. The *f condition in 736 is then an invalid read. Perhaps use while for the outer loop and a break? (It's just my personal preference, I sometimes get confused by incrementing at the end and also inside for loops.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 23:20:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 30 Jan 2015 22:20:16 +0000 Subject: [issue23055] PyUnicode_FromFormatV crasher In-Reply-To: <1418663915.64.0.885404540917.issue23055@psf.upfronthosting.co.za> Message-ID: <1422656416.44.0.854680070906.issue23055@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, I think following patch will help. ---------- Added file: http://bugs.python.org/file37929/issue23055_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 30 23:42:38 2015 From: report at bugs.python.org (Matt Frank) Date: Fri, 30 Jan 2015 22:42:38 +0000 Subject: [issue20306] Lack of pw_gecos field in Android's struct passwd causes cross-compilation for the pwd module to fail In-Reply-To: <1390155821.88.0.335321844624.issue20306@psf.upfronthosting.co.za> Message-ID: <1422657758.48.0.866376472018.issue20306@psf.upfronthosting.co.za> Matt Frank added the comment: Apologies. That last patch includes diffs to generated files (configure and pyconfig.h.in). This version just patches Modules/pwdmodule.c and configure.ac. After applying the patch please run "autoheader" and "autoconf" to correctly regenerate configure and pyconfig.h.in. ---------- Added file: http://bugs.python.org/file37930/pw_gecos-field-workaround-with-config_ac-mods.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 00:01:32 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 30 Jan 2015 23:01:32 +0000 Subject: [issue23055] PyUnicode_FromFormatV crasher In-Reply-To: <1418663915.64.0.885404540917.issue23055@psf.upfronthosting.co.za> Message-ID: <1422658892.97.0.0856893364229.issue23055@psf.upfronthosting.co.za> Stefan Krah added the comment: issue23055_2.patch looks good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 00:17:13 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 30 Jan 2015 23:17:13 +0000 Subject: [issue23055] PyUnicode_FromFormatV crasher In-Reply-To: <1418663915.64.0.885404540917.issue23055@psf.upfronthosting.co.za> Message-ID: <20150130231706.106309.32394@psf.io> Roundup Robot added the comment: New changeset 245c9f372a34 by Serhiy Storchaka in branch '2.7': Issue #23055: Fixed read-past-the-end error in PyUnicode_FromFormatV. https://hg.python.org/cpython/rev/245c9f372a34 New changeset 9fe1d861f486 by Serhiy Storchaka in branch '3.2': Issue #23055: Fixed read-past-the-end error in PyUnicode_FromFormatV. https://hg.python.org/cpython/rev/9fe1d861f486 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 00:22:42 2015 From: report at bugs.python.org (koobs) Date: Fri, 30 Jan 2015 23:22:42 +0000 Subject: [issue11578] Increase test coverage for timeit.py In-Reply-To: <1300307227.56.0.233218695639.issue11578@psf.upfronthosting.co.za> Message-ID: <1422660162.41.0.52557333179.issue11578@psf.upfronthosting.co.za> Changes by koobs : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 00:44:06 2015 From: report at bugs.python.org (matham) Date: Fri, 30 Jan 2015 23:44:06 +0000 Subject: [issue14613] time.time can return NaN In-Reply-To: <1334751988.35.0.313625977941.issue14613@psf.upfronthosting.co.za> Message-ID: <1422661446.65.0.362195864921.issue14613@psf.upfronthosting.co.za> matham added the comment: Hi guys, I'm running into this issue on windows 7 using python 2.7.8 (x86) from the python website. The following exception occurs while cython code calls a python function which emits a log. When replaying the same code it happens consistently: Traceback (most recent call last): File "g:\python\dev2\kivy\kivy\core\image\img_ffpyplayer.py", line 28, in _log_callback logger_func[level]('ImageLoaderFFPy: {}'.format(message)) File "E:\Python27\lib\logging\__init__.py", line 1186, in error self._log(ERROR, msg, args, **kwargs) File "E:\Python27\lib\logging\__init__.py", line 1278, in _log record = self.makeRecord(self.name, level, fn, lno, msg, args, exc_info, func, extra) File "E:\Python27\lib\logging\__init__.py", line 1252, in makeRecord rv = LogRecord(name, level, fn, lno, msg, args, exc_info, func) File "E:\Python27\lib\logging\__init__.py", line 287, in __init__ self.msecs = (ct - long(ct)) * 1000 ValueError: cannot convert float NaN to integer Even weirder, if I add a line like `print time.time()` right before `ct = time.time()` in logging\__init__.py no error occurs. But if I duplicate the print line twice, it crashes right there instead of raising an exception. ---------- nosy: +matham _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 00:47:55 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 30 Jan 2015 23:47:55 +0000 Subject: [issue14613] time.time can return NaN In-Reply-To: <1334751988.35.0.313625977941.issue14613@psf.upfronthosting.co.za> Message-ID: <1422661675.97.0.791519184877.issue14613@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm interested to investigate this issue, but right now I have no idea how to reproduce it. If I cannot reproduce the issue, I cannot investigate it. Are you able to write a short Python script to reproduce the issue? Did you modify manually the system time? It looks like your application uses Kivy. Many Kivy does some maths which causes issues with the FPU and the error is reported later in time.time()? (I don't see how...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 01:13:17 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 31 Jan 2015 00:13:17 +0000 Subject: [issue11578] Increase test coverage for timeit.py In-Reply-To: <1300307227.56.0.233218695639.issue11578@psf.upfronthosting.co.za> Message-ID: <20150131001303.39292.15180@psf.io> Roundup Robot added the comment: New changeset aa6f8e067ec3 by Serhiy Storchaka in branch '2.7': Use float division to avoid deprecation warning in test_timeit (issue #11578). https://hg.python.org/cpython/rev/aa6f8e067ec3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 01:22:21 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 31 Jan 2015 00:22:21 +0000 Subject: [issue23353] generator bug with exception: tstate->exc_value is not cleared after an except block In-Reply-To: <1422626936.33.0.830645939586.issue23353@psf.upfronthosting.co.za> Message-ID: <1422663741.26.0.316768160361.issue23353@psf.upfronthosting.co.za> STINNER Victor added the comment: Last major change related to generators in Python/ceval.c: --- changeset: 47594:212a1fee6bf9 parent: 47585:b0ef00187a7e user: Benjamin Peterson date: Wed Jun 11 15:59:43 2008 +0000 files: Doc/library/dis.rst Doc/library/inspect.rst Doc/library/sys.rst Doc/reference/datamodel.rst Include/frameobject.h Include/opcode.h Lib/doctest.py Li description: #3021: Antoine Pitrou's Lexical exception handlers --- This change introduced SWAP_EXC_STATE() and SAVE_EXC_STATE(). ---------- title: gnerator bug with exception: tstate->exc_value is not cleared after an except block -> generator bug with exception: tstate->exc_value is not cleared after an except block _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 01:39:04 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 31 Jan 2015 00:39:04 +0000 Subject: [issue20169] random module doc page has broken links In-Reply-To: <1389135190.46.0.595431802912.issue20169@psf.upfronthosting.co.za> Message-ID: <1422664744.73.0.556031400104.issue20169@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 01:45:11 2015 From: report at bugs.python.org (Demian Brecht) Date: Sat, 31 Jan 2015 00:45:11 +0000 Subject: [issue23350] Content-length is incorrect when request body is a list or tuple In-Reply-To: <1422597080.87.0.0588867536102.issue23350@psf.upfronthosting.co.za> Message-ID: <54CC2593.3040508@gmail.com> Demian Brecht added the comment: On 2015-01-29 9:51 PM, Martin Panter wrote: > The documentation currently says ?Content-Length header should be explicitly provided when the body is an iterable?. See Lib/urllib/request.py:1133 for how it is done for urlopen(), using memoryview(), which is probabaly more correct. Sure, entirely disabling computing the content length if the body is an iterable is one way to address it, but I'm not convinced that it's better. If the ability is there to compute the content length, why not do so? The current implementation /should/ be correct whether elements are bytes or strings (the default encoding doesn't allow for multi-byte chars, so len(raw_string) should equal len(encoded_string)) when encoded using the new block of encoding code I added in the patch. Is there something that I'm missing? I could possibly see an argument for performance as you're iterating over each element in the list, but that would be entirely circumvented if the user defines the content length up front. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 01:48:20 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 31 Jan 2015 00:48:20 +0000 Subject: [issue23353] generator bug with exception: tstate->exc_value is not cleared after an except block In-Reply-To: <1422626936.33.0.830645939586.issue23353@psf.upfronthosting.co.za> Message-ID: <1422665300.82.0.889579755378.issue23353@psf.upfronthosting.co.za> STINNER Victor added the comment: Attached gen_exc_value.patch changes how generators handle the currently handled exception (tstate->exc_value). The patch probably lacks tests to test the exact behaviour of sys.exc_info(). The 3 examples below can be used to write such tests. But before investing time on an implemenation, I would like to ensure that I correctly understood the bug and discuss how it should be fixed. Currently, a generator inherits the currently handled exception from the "caller" (function calling next(), gen.send() or gen.throw()). With the patch, the generator and its caller don't share the exception anymore. The generator still remembers the current exception when it is interrupted by yield. It's still possible to pass the exception from the caller to the generator using the throw() method of the generator. My patch doesn't change the behaviour of throw(): see the example 3 below. The patch also fixes the initial issue: "./python -m test test_asyncio test_functools" doesn't fail anymore. Python 2.7 is also affected by the bug. I don't know yet if it's safe to change the behaviour of currently handled exception in Python 2 generators. It may break backward compatibility. We should probably check applications which heavily depends on generators. For example, the Trollius and Twisted projects use generators for coroutines in asynchronous programming. The backward compatibility also matters in Python 3.4, so same question: should we change the behaviour of Python 3.4? Can it break applications? In Python 3, the currently handled exception is more important than in Python 2, because it is used to automatically fill the __context__ attribute of raised exceptions. I didn't test the behaviour of yield-from yet, I don't know how my patch changes its behaviour. Example 1: --- import sys def gen(): print(sys.exc_info()) yield g = gen() try: raise ValueError except Exception: next(g) --- Original output: --- (, ValueError(), ) --- With the patch: --- (None, None, None) --- Example 2: --- import sys def gen(): try: yield raise TypeError() except: print(sys.exc_info()) print(sys.exc_info()) yield g = gen() next(g) try: raise ValueError except Exception: next(g) --- Original output: --- (, TypeError(), ) (, ValueError(), ) --- With the patch: --- (, TypeError(), ) (None, None, None) --- Example 3: --- import sys def gen(): try: try: yield except: print(sys.exc_info()) raise TypeError() except Exception as exc: print("TypeError context:", repr(exc.__context__)) yield g = gen() next(g) try: raise ValueError except Exception as exc: g.throw(exc) --- Original output: --- (, ValueError(), ) TypeError context: ValueError() (, ValueError(), ) --- With the patch (unchanged): --- (, ValueError(), ) TypeError context: ValueError() (None, None, None) --- ---------- keywords: +patch versions: +Python 2.7 Added file: http://bugs.python.org/file37931/gen_exc_value.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 01:48:35 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 31 Jan 2015 00:48:35 +0000 Subject: [issue23353] generator bug with exception: tstate->exc_value is not cleared after an except block In-Reply-To: <1422626936.33.0.830645939586.issue23353@psf.upfronthosting.co.za> Message-ID: <1422665315.24.0.0362997216717.issue23353@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +pitrou, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 01:53:11 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 31 Jan 2015 00:53:11 +0000 Subject: [issue23353] generator bug with exception: tstate->exc_value is not cleared after an except block In-Reply-To: <1422626936.33.0.830645939586.issue23353@psf.upfronthosting.co.za> Message-ID: <1422665591.39.0.612547911407.issue23353@psf.upfronthosting.co.za> STINNER Victor added the comment: See also: * PEP 3134: Exception Chaining and Embedded Tracebacks (Python 3.0) * Issue #3021: Lexical exception handlers (Python 3.0) -- thread: https://mail.python.org/pipermail/python-3000/2008-May/013740.html * PEP 380: Syntax for Delegating to a Subgenerator (Python 3.3) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 01:57:01 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 31 Jan 2015 00:57:01 +0000 Subject: [issue17188] Document 'from None' in raise statement doc. In-Reply-To: <1360631999.8.0.76627095073.issue17188@psf.upfronthosting.co.za> Message-ID: <1422665821.6.0.720319155428.issue17188@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: needs patch -> patch review versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 02:06:23 2015 From: report at bugs.python.org (matham) Date: Sat, 31 Jan 2015 01:06:23 +0000 Subject: [issue14613] time.time can return NaN In-Reply-To: <1334751988.35.0.313625977941.issue14613@psf.upfronthosting.co.za> Message-ID: <1422666383.05.0.103254892822.issue14613@psf.upfronthosting.co.za> matham added the comment: Ok, first, I was able to make it happen outside of kivy using only my code. However, I'm not sure it's of much help because it's using my ffmpeg based code (https://github.com/matham/ffpyplayer) which is not a simple script :) The issue happens when ffmpeg emits logs through a c(cython) callback which calls the python logging code. But it only happened when I played a specific video. That's why i doubt I'd be able to make it happen in a sterile environment with a simple script. Also, I'm pretty sure that the log calling code is executed from ffmpeg's internal secondary threads (which I protect it with a mutex). Anyway, I decided to upgrade my ffmpeg libraries to the most recent ffmpeg version and the problem went away. So was this maybe some bug in older ffmpeg which corrupted python? If you're interested in replicating it with the older ffmpeg, I can post some code using my ffpyplayer library. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 02:10:21 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 31 Jan 2015 01:10:21 +0000 Subject: [issue23353] generator bug with exception: tstate->exc_value is not cleared after an except block In-Reply-To: <1422626936.33.0.830645939586.issue23353@psf.upfronthosting.co.za> Message-ID: <1422666621.56.0.0799265434782.issue23353@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, by the way: keeping the exception after the except block is also a tricky reference leak. In Python 3, since exceptions store their traceback, this issue may keep a lot of objects alive too long, whereas they are expected to be destroyed much earlier. When I started to investigate this issue, it took me 2 hours to begin to understand why so many objects were kept alive. It looks like a reference cycle, a reference leak, or other kind of complex memory leak. Clearing manually local variables (ex: "self = None" in methods) is not enough. Python 2 has a sys.exc_clear() method which can be used to workaround this issue. It cannot be used in Python 3 since the function was removed in Python 3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 02:16:57 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 31 Jan 2015 01:16:57 +0000 Subject: [issue23353] generator bug with exception: tstate->exc_value is not cleared after an except block In-Reply-To: <1422626936.33.0.830645939586.issue23353@psf.upfronthosting.co.za> Message-ID: <1422667017.55.0.0628203842001.issue23353@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Currently, a generator inherits the currently handled exception from > the "caller" This is expected, since this is how normal functions behave. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 02:24:39 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 31 Jan 2015 01:24:39 +0000 Subject: [issue23353] generator bug with exception: tstate->exc_value is not cleared after an except block In-Reply-To: <1422626936.33.0.830645939586.issue23353@psf.upfronthosting.co.za> Message-ID: <1422667479.09.0.540431768532.issue23353@psf.upfronthosting.co.za> STINNER Victor added the comment: Attached gen_exc_value_py27.patch: Patch for Python 2.7. No unit test yet. The full test suite of trollius pass on the patched Python 2.7 and on the patched Python 3.5. The full test suite of asyncio also pass on the patched Python 3.5. ---------- Added file: http://bugs.python.org/file37932/gen_exc_value_py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 02:29:17 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 31 Jan 2015 01:29:17 +0000 Subject: [issue23350] Content-length is incorrect when request body is a list or tuple In-Reply-To: <1422580362.11.0.520529959905.issue23350@psf.upfronthosting.co.za> Message-ID: <1422667757.73.0.014600514684.issue23350@psf.upfronthosting.co.za> Martin Panter added the comment: Sorry my comment was a bit rushed. I wasn?t saying this feature shouldn?t be added. I guess I was pointing out two things: 1. Someone should updated the documentation to say that Content-Length no longer has to be explicitly provided for lists and tuples. 2. Perhaps you could consider using the same len(memoryview) * memoryview.itemsize technique used in urllib, so that the length of e.g. array.array("I", range(3)) is correct. But that is tangential to what you are trying to achieve, and now I realize coping with Latin-1 encoding at the same time might make it a bit too complicated, so perhaps don?t worry about it :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 02:38:15 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 31 Jan 2015 01:38:15 +0000 Subject: [issue23353] generator bug with exception: tstate->exc_value is not cleared after an except block In-Reply-To: <1422667017.55.0.0628203842001.issue23353@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > > Currently, a generator inherits the currently handled exception from > > the "caller" > > This is expected, since this is how normal functions behave. Do you see how to fix the issue without changing the behaviour? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 04:32:48 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 31 Jan 2015 03:32:48 +0000 Subject: [issue23353] generator bug with exception: tstate->exc_value is not cleared after an except block In-Reply-To: <1422626936.33.0.830645939586.issue23353@psf.upfronthosting.co.za> Message-ID: <1422675168.31.0.598334098289.issue23353@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Attached patch fixes the test script and doesn't break any test. ---------- Added file: http://bugs.python.org/file37933/gen_exc_state_restore.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 04:36:30 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 31 Jan 2015 03:36:30 +0000 Subject: [issue23353] generator bug with exception: tstate->exc_value is not cleared after an except block In-Reply-To: <1422626936.33.0.830645939586.issue23353@psf.upfronthosting.co.za> Message-ID: <1422675390.85.0.686784886508.issue23353@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Note the patch also fixes the reference leak in test_asyncio. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 04:40:41 2015 From: report at bugs.python.org (SoniEx2) Date: Sat, 31 Jan 2015 03:40:41 +0000 Subject: [issue23354] Loading 2 GiLOC file which raises exception causes wrong traceback Message-ID: <1422675641.92.0.509373230042.issue23354@psf.upfronthosting.co.za> New submission from SoniEx2: I loaded a file with 2 GiLOC followed by "assert False" and this was the error/traceback: Traceback (most recent call last): File "test.py", line -2147483647, in AssertionError ---------- components: Interpreter Core messages: 235079 nosy: SoniEx2 priority: normal severity: normal status: open title: Loading 2 GiLOC file which raises exception causes wrong traceback type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 05:16:07 2015 From: report at bugs.python.org (Ethan Furman) Date: Sat, 31 Jan 2015 04:16:07 +0000 Subject: [issue23354] Loading 2 GiLOC file which raises exception causes wrong traceback In-Reply-To: <1422675641.92.0.509373230042.issue23354@psf.upfronthosting.co.za> Message-ID: <1422677767.09.0.268140109459.issue23354@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 06:25:04 2015 From: report at bugs.python.org (kai keliikuli) Date: Sat, 31 Jan 2015 05:25:04 +0000 Subject: [issue23355] rsplit duplicates split behavior Message-ID: <1422681902.98.0.718785741175.issue23355@psf.upfronthosting.co.za> New submission from kai keliikuli: 'a b'.split() == 'a b'.rsplit() ---------- messages: 235080 nosy: kai.keliikuli priority: normal severity: normal status: open title: rsplit duplicates split behavior type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 06:56:05 2015 From: report at bugs.python.org (eryksun) Date: Sat, 31 Jan 2015 05:56:05 +0000 Subject: [issue23355] rsplit duplicates split behavior In-Reply-To: <1422681902.98.0.718785741175.issue23355@psf.upfronthosting.co.za> Message-ID: <1422683765.39.0.73926674516.issue23355@psf.upfronthosting.co.za> eryksun added the comment: The result of str.split and str.rsplit can differ depending on the optional 2nd parameter, maxsplit: >>> 'a b c'.split(None, 1) ['a', 'b c'] >>> 'a b c'.rsplit(None, 1) ['a b', 'c'] https://docs.python.org/2/library/stdtypes.html#str.rsplit ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 07:05:18 2015 From: report at bugs.python.org (Zachary Ware) Date: Sat, 31 Jan 2015 06:05:18 +0000 Subject: [issue23355] rsplit duplicates split behavior In-Reply-To: <1422681902.98.0.718785741175.issue23355@psf.upfronthosting.co.za> Message-ID: <1422684318.25.0.779293455918.issue23355@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 07:23:41 2015 From: report at bugs.python.org (Zachary Ware) Date: Sat, 31 Jan 2015 06:23:41 +0000 Subject: [issue23308] a bug in Instructions section 4.1 In-Reply-To: <1867408449.522169.1422083738920.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1422685421.08.0.358495925705.issue23308@psf.upfronthosting.co.za> Zachary Ware added the comment: I'm not seeing any problem with any section 4.1. If you can provide a direct link to the problem and a description of it, please reopen the issue. ---------- nosy: +zach.ware resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 08:32:21 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 31 Jan 2015 07:32:21 +0000 Subject: [issue23316] Incorrect evaluation order of function arguments with *args In-Reply-To: <1422200816.31.0.910655700205.issue23316@psf.upfronthosting.co.za> Message-ID: <1422689541.52.0.648391334524.issue23316@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I expect left to right as documented (and designed by Guido). His OK or clarification would be to intentionally do differently. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 08:36:45 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 31 Jan 2015 07:36:45 +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: <1422689805.58.0.897262074123.issue15955@psf.upfronthosting.co.za> Martin Panter added the comment: Nikolaus, do you still plan on doing the bzip module? If not, I could have a go when I get a chance. I?m also keen for the GzipFile decompression to be fixed, if anyone wants to review my gzip-bomb.patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 08:37:11 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 31 Jan 2015 07:37:11 +0000 Subject: [issue23320] devguide should mention rules about "paragraph reflow" in the documentation In-Reply-To: <1422219993.92.0.674256323538.issue23320@psf.upfronthosting.co.za> Message-ID: <1422689831.51.0.367120588793.issue23320@psf.upfronthosting.co.za> Terry J. Reedy added the comment: For normal paragraphs, long and short lines make no difference to Sphinx and subsequent output. I would like to know and have documented when (how uneven the lines) a reflow is otherwise considered necessary. ---------- nosy: +georg.brandl, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 08:48:51 2015 From: report at bugs.python.org (Georg Brandl) Date: Sat, 31 Jan 2015 07:48:51 +0000 Subject: [issue23320] devguide should mention rules about "paragraph reflow" in the documentation In-Reply-To: <1422219993.92.0.674256323538.issue23320@psf.upfronthosting.co.za> Message-ID: <1422690531.06.0.154802916959.issue23320@psf.upfronthosting.co.za> Georg Brandl added the comment: For patches to be reviewed (whether submitted by a core developer or not), there should be as little spurious changes as possible. In the final commit, it's ok, but not mandatory, to reflow the paragraphs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 08:51:38 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 31 Jan 2015 07:51:38 +0000 Subject: [issue23055] PyUnicode_FromFormatV crasher In-Reply-To: <1418663915.64.0.885404540917.issue23055@psf.upfronthosting.co.za> Message-ID: <1422690698.11.0.603088537289.issue23055@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 08:52:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 31 Jan 2015 07:52:39 +0000 Subject: [issue11578] Increase test coverage for timeit.py In-Reply-To: <1300307227.56.0.233218695639.issue11578@psf.upfronthosting.co.za> Message-ID: <1422690759.61.0.668624592435.issue11578@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 08:52:45 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 31 Jan 2015 07:52:45 +0000 Subject: [issue23337] Run python with restricted rights In-Reply-To: <1422440682.84.0.195958964107.issue23337@psf.upfronthosting.co.za> Message-ID: <1422690765.15.0.327435909889.issue23337@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I agree that this would have been better asked on python-list. However... I would like a better handle on when this occurs to either make it happens less or better document workarounds. How did you install python? The .msi installer from python.org? Which directory? 34 or 64 bit? Which Windows version? Install for all users or just one account? How start Idle? In the meanwhile, at a Command Prompt command line, > python -m idlelib -n should work. ---------- components: +IDLE nosy: +terry.reedy stage: -> test needed type: crash -> behavior versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 09:15:38 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 31 Jan 2015 08:15:38 +0000 Subject: [issue23326] Remove redundant __ne__ implementations In-Reply-To: <1422308079.14.0.124539148403.issue23326@psf.upfronthosting.co.za> Message-ID: <1422692138.1.0.252395589387.issue23326@psf.upfronthosting.co.za> Martin Panter added the comment: I looked at all the instances of __ne__() identified in the patch, and they all seem redundant with the __eq__() implementations, so I think this patch is good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 09:40:39 2015 From: report at bugs.python.org (py.user) Date: Sat, 31 Jan 2015 08:40:39 +0000 Subject: [issue23356] In argparse docs simplify example about argline Message-ID: <1422693639.9.0.487352753219.issue23356@psf.upfronthosting.co.za> New submission from py.user: The example is: def convert_arg_line_to_args(self, arg_line): for arg in arg_line.split(): if not arg.strip(): continue yield arg str.split() with default delimiters never returns empty or whitespace strings in the list. >>> ' x x '.split() ['x', 'x'] >>> ' '.split() [] >>> Therefore, the if condition doesn't ever continue the loop. It can be written: def convert_arg_line_to_args(self, arg_line): for arg in arg_line.split(): yield arg It's the same as: def convert_arg_line_to_args(self, arg_line): return iter(arg_line.split()) I guess, nothing uses next() for the result: def convert_arg_line_to_args(self, arg_line): return arg_line.split() Applied a patch with the last variant. ---------- assignee: docs at python components: Documentation, Library (Lib) files: args_ex_argline.diff keywords: patch messages: 235089 nosy: docs at python, py.user priority: normal severity: normal status: open title: In argparse docs simplify example about argline type: performance versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file37934/args_ex_argline.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 09:58:10 2015 From: report at bugs.python.org (py.user) Date: Sat, 31 Jan 2015 08:58:10 +0000 Subject: [issue23356] In argparse docs simplify example about argline In-Reply-To: <1422693639.9.0.487352753219.issue23356@psf.upfronthosting.co.za> Message-ID: <1422694690.48.0.0469123970958.issue23356@psf.upfronthosting.co.za> py.user added the comment: Url https://docs.python.org/3/library/argparse.html#customizing-file-parsing ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 09:58:14 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 31 Jan 2015 08:58:14 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: <1422578368.13.0.614272614825.issue23285@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: I just realized I didn't retry upon EINTR for open(): eintr-4.diff adds this, along with tests (using a fifo). Also, I added comments explaining why we don't retry upon close() (see e.g. http://lwn.net/Articles/576478/ and http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-09/3000.html). ---------- Added file: http://bugs.python.org/file37935/eintr-4.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 7e6340e67618 Lib/_pyio.py --- a/Lib/_pyio.py Fri Jan 30 00:16:31 2015 +0100 +++ b/Lib/_pyio.py Fri Jan 30 22:08:27 2015 +0000 @@ -1006,10 +1006,7 @@ current_size = 0 while True: # Read until EOF or until read() would block. - try: - chunk = self.raw.read() - except InterruptedError: - continue + chunk = self.raw.read() if chunk in empty_values: nodata_val = chunk break @@ -1028,10 +1025,7 @@ chunks = [buf[pos:]] wanted = max(self.buffer_size, n) while avail < n: - try: - chunk = self.raw.read(wanted) - except InterruptedError: - continue + chunk = self.raw.read(wanted) if chunk in empty_values: nodata_val = chunk break @@ -1060,12 +1054,7 @@ have = len(self._read_buf) - self._read_pos if have < want or have <= 0: to_read = self.buffer_size - have - while True: - try: - current = self.raw.read(to_read) - except InterruptedError: - continue - break + current = self.raw.read(to_read) if current: self._read_buf = self._read_buf[self._read_pos:] + current self._read_pos = 0 @@ -1214,8 +1203,6 @@ while self._write_buf: try: n = self.raw.write(self._write_buf) - except InterruptedError: - continue except BlockingIOError: raise RuntimeError("self.raw should implement RawIOBase: it " "should not raise BlockingIOError") diff -r 7e6340e67618 Lib/distutils/spawn.py --- a/Lib/distutils/spawn.py Fri Jan 30 00:16:31 2015 +0100 +++ b/Lib/distutils/spawn.py Fri Jan 30 22:08:27 2015 +0000 @@ -137,9 +137,6 @@ try: pid, status = os.waitpid(pid, 0) except OSError as exc: - import errno - if exc.errno == errno.EINTR: - continue if not DEBUG: cmd = executable raise DistutilsExecError( diff -r 7e6340e67618 Lib/multiprocessing/connection.py --- a/Lib/multiprocessing/connection.py Fri Jan 30 00:16:31 2015 +0100 +++ b/Lib/multiprocessing/connection.py Fri Jan 30 22:08:27 2015 +0000 @@ -365,10 +365,7 @@ def _send(self, buf, write=_write): remaining = len(buf) while True: - try: - n = write(self._handle, buf) - except InterruptedError: - continue + n = write(self._handle, buf) remaining -= n if remaining == 0: break @@ -379,10 +376,7 @@ handle = self._handle remaining = size while remaining > 0: - try: - chunk = read(handle, remaining) - except InterruptedError: - continue + chunk = read(handle, remaining) n = len(chunk) if n == 0: if remaining == size: @@ -595,13 +589,7 @@ self._unlink = None def accept(self): - while True: - try: - s, self._last_accepted = self._socket.accept() - except InterruptedError: - pass - else: - break + s, self._last_accepted = self._socket.accept() s.setblocking(True) return Connection(s.detach()) diff -r 7e6340e67618 Lib/multiprocessing/forkserver.py --- a/Lib/multiprocessing/forkserver.py Fri Jan 30 00:16:31 2015 +0100 +++ b/Lib/multiprocessing/forkserver.py Fri Jan 30 22:08:27 2015 +0000 @@ -188,8 +188,6 @@ finally: os._exit(code) - except InterruptedError: - pass except OSError as e: if e.errno != errno.ECONNABORTED: raise @@ -230,13 +228,7 @@ data = b'' length = UNSIGNED_STRUCT.size while len(data) < length: - while True: - try: - s = os.read(fd, length - len(data)) - except InterruptedError: - pass - else: - break + s = os.read(fd, length - len(data)) if not s: raise EOFError('unexpected EOF') data += s @@ -245,13 +237,7 @@ def write_unsigned(fd, n): msg = UNSIGNED_STRUCT.pack(n) while msg: - while True: - try: - nbytes = os.write(fd, msg) - except InterruptedError: - pass - else: - break + nbytes = os.write(fd, msg) if nbytes == 0: raise RuntimeError('should not get here') msg = msg[nbytes:] diff -r 7e6340e67618 Lib/multiprocessing/popen_fork.py --- a/Lib/multiprocessing/popen_fork.py Fri Jan 30 00:16:31 2015 +0100 +++ b/Lib/multiprocessing/popen_fork.py Fri Jan 30 22:08:27 2015 +0000 @@ -1,7 +1,6 @@ import os import sys import signal -import errno from . import util @@ -29,8 +28,6 @@ try: pid, sts = os.waitpid(self.pid, flag) except OSError as e: - if e.errno == errno.EINTR: - continue # Child process not yet created. See #1731717 # e.errno == errno.ECHILD == 10 return None diff -r 7e6340e67618 Lib/socket.py --- a/Lib/socket.py Fri Jan 30 00:16:31 2015 +0100 +++ b/Lib/socket.py Fri Jan 30 22:08:27 2015 +0000 @@ -572,8 +572,6 @@ except timeout: self._timeout_occurred = True raise - except InterruptedError: - continue except error as e: if e.args[0] in _blocking_errnos: return None diff -r 7e6340e67618 Lib/socketserver.py --- a/Lib/socketserver.py Fri Jan 30 00:16:31 2015 +0100 +++ b/Lib/socketserver.py Fri Jan 30 22:08:27 2015 +0000 @@ -553,8 +553,6 @@ try: pid, _ = os.waitpid(-1, 0) self.active_children.discard(pid) - except InterruptedError: - pass except ChildProcessError: # we don't have any children, we're done self.active_children.clear() diff -r 7e6340e67618 Lib/subprocess.py --- a/Lib/subprocess.py Fri Jan 30 00:16:31 2015 +0100 +++ b/Lib/subprocess.py Fri Jan 30 22:08:27 2015 +0000 @@ -489,14 +489,6 @@ DEVNULL = -3 -def _eintr_retry_call(func, *args): - while True: - try: - return func(*args) - except InterruptedError: - continue - - # XXX This function is only used by multiprocessing and the test suite, # but it's here so that it can be imported when Python is compiled without # threads. @@ -963,10 +955,10 @@ if self.stdin: self._stdin_write(input) elif self.stdout: - stdout = _eintr_retry_call(self.stdout.read) + stdout = self.stdout.read() self.stdout.close() elif self.stderr: - stderr = _eintr_retry_call(self.stderr.read) + stderr = self.stderr.read() self.stderr.close() self.wait() else: @@ -1410,7 +1402,7 @@ # exception (limited in size) errpipe_data = bytearray() while True: - part = _eintr_retry_call(os.read, errpipe_read, 50000) + part = os.read(errpipe_read, 50000) errpipe_data += part if not part or len(errpipe_data) > 50000: break @@ -1420,7 +1412,7 @@ if errpipe_data: try: - _eintr_retry_call(os.waitpid, self.pid, 0) + os.waitpid(self.pid, 0) except ChildProcessError: pass try: @@ -1505,7 +1497,7 @@ def _try_wait(self, wait_flags): """All callers to this function MUST hold self._waitpid_lock.""" try: - (pid, sts) = _eintr_retry_call(os.waitpid, self.pid, wait_flags) + (pid, sts) = os.waitpid(self.pid, wait_flags) except ChildProcessError: # This happens if SIGCLD is set to be ignored or waiting # for child processes has otherwise been disabled for our diff -r 7e6340e67618 Lib/test/eintrdata/eintr_tester.py --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Lib/test/eintrdata/eintr_tester.py Fri Jan 30 22:08:27 2015 +0000 @@ -0,0 +1,260 @@ +""" +This test suite exercises some system calls subject to interruption with EINTR, +to check that it is actually handled transparently. +It is intended to be run by the main test suite within a child process, to +ensure there is no background thread running (so that signals are delivered to +the correct thread). +Signals are generated in-process using setitimer(ITIMER_REAL), which allows +sub-second periodicity (contrarily to signal()). +""" + +import io +import os +import signal +import socket +import time +import unittest + +from test import support + + + at unittest.skipUnless(hasattr(signal, "setitimer"), "requires setitimer()") +class EINTRBaseTest(unittest.TestCase): + """ Base class for EINTR tests. """ + + # delay for initial signal delivery + signal_delay = 0.1 + # signal delivery periodicity + signal_period = 0.1 + # default sleep time for tests - should obviously have: + #??sleep_time > signal_period + sleep_time = 0.2 + + @classmethod + def setUpClass(cls): + cls.orig_handler = signal.signal(signal.SIGALRM, lambda *args: None) + signal.setitimer(signal.ITIMER_REAL, cls.signal_delay, + cls.signal_period) + + @classmethod + def tearDownClass(cls): + signal.setitimer(signal.ITIMER_REAL, 0, 0) + signal.signal(signal.SIGALRM, cls.orig_handler) + + @classmethod + def _sleep(cls): + # default sleep time + time.sleep(cls.sleep_time) + + + at unittest.skipUnless(hasattr(signal, "setitimer"), "requires setitimer()") +class OSEINTRTest(EINTRBaseTest): + """ EINTR tests for the os module. """ + + def _test_wait_multiple(self, wait_func): + num = 3 + for _ in range(num): + pid = os.fork() + if pid == 0: + self._sleep() + os._exit(0) + for _ in range(num): + wait_func() + + def test_wait(self): + self._test_wait_multiple(os.wait) + + @unittest.skipUnless(hasattr(os, 'wait3'), 'requires wait3()') + def test_wait3(self): + self._test_wait_multiple(lambda: os.wait3(0)) + + def _test_wait_single(self, wait_func): + pid = os.fork() + if pid == 0: + self._sleep() + os._exit(0) + else: + wait_func(pid) + + def test_waitpid(self): + self._test_wait_single(lambda pid: os.waitpid(pid, 0)) + + @unittest.skipUnless(hasattr(os, 'wait4'), 'requires wait4()') + def test_wait4(self): + self._test_wait_single(lambda pid: os.wait4(pid, 0)) + + def test_read(self): + rd, wr = os.pipe() + self.addCleanup(os.close, rd) + # wr closed explicitly by parent + + # the payload below are smaller than PIPE_BUF, hence the writes will be + # atomic + datas = [b"hello", b"world", b"spam"] + + pid = os.fork() + if pid == 0: + os.close(rd) + for data in datas: + # let the parent block on read() + self._sleep() + os.write(wr, data) + os._exit(0) + else: + self.addCleanup(os.waitpid, pid, 0) + os.close(wr) + for data in datas: + self.assertEqual(data, os.read(rd, len(data))) + + def test_write(self): + rd, wr = os.pipe() + self.addCleanup(os.close, wr) + # rd closed explicitly by parent + + # we must write enough data for the write() to block + data = b"xyz" * support.PIPE_MAX_SIZE + + pid = os.fork() + if pid == 0: + os.close(wr) + read_data = io.BytesIO() + # let the parent block on write() + self._sleep() + while len(read_data.getvalue()) < len(data): + chunk = os.read(rd, 2 * len(data)) + read_data.write(chunk) + self.assertEqual(read_data.getvalue(), data) + os._exit(0) + else: + os.close(rd) + written = 0 + while written < len(data): + written += os.write(wr, memoryview(data)[written:]) + self.assertEqual(0, os.waitpid(pid, 0)[1]) + + + at unittest.skipUnless(hasattr(signal, "setitimer"), "requires setitimer()") +class SocketEINTRTest(EINTRBaseTest): + """ EINTR tests for the socket module. """ + + @unittest.skipUnless(hasattr(socket, 'socketpair'), 'needs socketpair()') + def _test_recv(self, recv_func): + rd, wr = socket.socketpair() + self.addCleanup(rd.close) + # wr closed explicitly by parent + + # single-byte payload guard us against partial recv + datas = [b"x", b"y", b"z"] + + pid = os.fork() + if pid == 0: + rd.close() + for data in datas: + # let the parent block on recv() + self._sleep() + wr.sendall(data) + os._exit(0) + else: + self.addCleanup(os.waitpid, pid, 0) + wr.close() + for data in datas: + self.assertEqual(data, recv_func(rd, len(data))) + + def test_recv(self): + self._test_recv(socket.socket.recv) + + @unittest.skipUnless(hasattr(socket.socket, 'recvmsg'), 'needs recvmsg()') + def test_recvmsg(self): + self._test_recv(lambda sock, data: sock.recvmsg(data)[0]) + + def _test_send(self, send_func): + rd, wr = socket.socketpair() + self.addCleanup(wr.close) + # rd closed explicitly by parent + + # we must send enough data for the send() to block + data = b"xyz" * (support.SOCK_MAX_SIZE // 3) + + pid = os.fork() + if pid == 0: + wr.close() + # let the parent block on send() + self._sleep() + received_data = bytearray(len(data)) + n = 0 + while n < len(data): + n += rd.recv_into(memoryview(received_data)[n:]) + self.assertEqual(received_data, data) + os._exit(0) + else: + rd.close() + written = 0 + while written < len(data): + sent = send_func(wr, memoryview(data)[written:]) + # sendall() returns None + written += len(data) if sent is None else sent + self.assertEqual(0, os.waitpid(pid, 0)[1]) + + def test_send(self): + self._test_send(socket.socket.send) + + def test_sendall(self): + self._test_send(socket.socket.sendall) + + @unittest.skipUnless(hasattr(socket.socket, 'sendmsg'), 'needs sendmsg()') + def test_sendmsg(self): + self._test_send(lambda sock, data: sock.sendmsg([data])) + + def test_accept(self): + sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) + self.addCleanup(sock.close) + + sock.bind((support.HOST, 0)) + _, port = sock.getsockname() + sock.listen() + + pid = os.fork() + if pid == 0: + # let parent block on accept() + self._sleep() + with socket.create_connection((support.HOST, port)): + self._sleep() + os._exit(0) + else: + self.addCleanup(os.waitpid, pid, 0) + client_sock, _ = sock.accept() + client_sock.close() + + @unittest.skipUnless(hasattr(os, 'mkfifo'), 'needs mkfifo()') + def _test_open(self, do_open_close_reader, do_open_close_writer): + # Use a fifo: until the child opens it for reading, the parent will + # block when trying to open it for writing. + support.unlink(support.TESTFN) + os.mkfifo(support.TESTFN) + self.addCleanup(support.unlink, support.TESTFN) + + pid = os.fork() + if pid == 0: + # let the parent block + self._sleep() + do_open_close_reader(support.TESTFN) + os._exit(0) + else: + self.addCleanup(os.waitpid, pid, 0) + do_open_close_writer(support.TESTFN) + + def test_open(self): + self._test_open(lambda path: open(path, 'r').close(), + lambda path: open(path, 'w').close()) + + def test_os_open(self): + self._test_open(lambda path: os.close(os.open(path, os.O_RDONLY)), + lambda path: os.close(os.open(path, os.O_WRONLY))) + + +def test_main(): + support.run_unittest(OSEINTRTest, SocketEINTRTest) + + +if __name__ == "__main__": + test_main() diff -r 7e6340e67618 Lib/test/test_eintr.py --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Lib/test/test_eintr.py Fri Jan 30 22:08:27 2015 +0000 @@ -0,0 +1,20 @@ +import os +import signal +import unittest + +from test import script_helper, support + + + at unittest.skipUnless(os.name == "posix", "only supported on Unix") +class EINTRTests(unittest.TestCase): + + @unittest.skipUnless(hasattr(signal, "setitimer"), "requires setitimer()") + def test_all(self): + # Run the tester in a sub-process, to make sure there is only one + # thread (for reliable signal delivery). + tester = support.findfile("eintr_tester.py", subdir="eintrdata") + script_helper.assert_python_ok(tester) + + +if __name__ == "__main__": + unittest.main() diff -r 7e6340e67618 Lib/test/test_signal.py --- a/Lib/test/test_signal.py Fri Jan 30 00:16:31 2015 +0100 +++ b/Lib/test/test_signal.py Fri Jan 30 22:08:27 2015 +0000 @@ -587,7 +587,7 @@ r, w = os.pipe() def handler(signum, frame): - pass + 1 / 0 signal.signal(signal.SIGALRM, handler) if interrupt is not None: @@ -604,9 +604,8 @@ try: # blocking call: read from a pipe without data os.read(r, 1) - except OSError as err: - if err.errno != errno.EINTR: - raise + except ZeroDivisionError: + pass else: sys.exit(2) sys.exit(3) diff -r 7e6340e67618 Lib/test/test_socket.py --- a/Lib/test/test_socket.py Fri Jan 30 00:16:31 2015 +0100 +++ b/Lib/test/test_socket.py Fri Jan 30 22:08:27 2015 +0000 @@ -3590,7 +3590,7 @@ def setUp(self): super().setUp() orig_alrm_handler = signal.signal(signal.SIGALRM, - lambda signum, frame: None) + lambda signum, frame: 1 / 0) self.addCleanup(signal.signal, signal.SIGALRM, orig_alrm_handler) self.addCleanup(self.setAlarm, 0) @@ -3627,13 +3627,11 @@ self.serv.settimeout(self.timeout) def checkInterruptedRecv(self, func, *args, **kwargs): - # Check that func(*args, **kwargs) raises OSError with an + # Check that func(*args, **kwargs) raises # errno of EINTR when interrupted by a signal. self.setAlarm(self.alarm_time) - with self.assertRaises(OSError) as cm: + with self.assertRaises(ZeroDivisionError) as cm: func(*args, **kwargs) - self.assertNotIsInstance(cm.exception, socket.timeout) - self.assertEqual(cm.exception.errno, errno.EINTR) def testInterruptedRecvTimeout(self): self.checkInterruptedRecv(self.serv.recv, 1024) @@ -3689,12 +3687,10 @@ # Check that func(*args, **kwargs), run in a loop, raises # OSError with an errno of EINTR when interrupted by a # signal. - with self.assertRaises(OSError) as cm: + with self.assertRaises(ZeroDivisionError) as cm: while True: self.setAlarm(self.alarm_time) func(*args, **kwargs) - self.assertNotIsInstance(cm.exception, socket.timeout) - self.assertEqual(cm.exception.errno, errno.EINTR) # Issue #12958: The following tests have problems on OS X prior to 10.7 @support.requires_mac_ver(10, 7) @@ -4062,117 +4058,6 @@ pass -class FileObjectInterruptedTestCase(unittest.TestCase): - """Test that the file object correctly handles EINTR internally.""" - - class MockSocket(object): - def __init__(self, recv_funcs=()): - # A generator that returns callables that we'll call for each - # call to recv(). - self._recv_step = iter(recv_funcs) - - def recv_into(self, buffer): - data = next(self._recv_step)() - assert len(buffer) >= len(data) - buffer[:len(data)] = data - return len(data) - - def _decref_socketios(self): - pass - - def _textiowrap_for_test(self, buffering=-1): - raw = socket.SocketIO(self, "r") - if buffering < 0: - buffering = io.DEFAULT_BUFFER_SIZE - if buffering == 0: - return raw - buffer = io.BufferedReader(raw, buffering) - text = io.TextIOWrapper(buffer, None, None) - text.mode = "rb" - return text - - @staticmethod - def _raise_eintr(): - raise OSError(errno.EINTR, "interrupted") - - def _textiowrap_mock_socket(self, mock, buffering=-1): - raw = socket.SocketIO(mock, "r") - if buffering < 0: - buffering = io.DEFAULT_BUFFER_SIZE - if buffering == 0: - return raw - buffer = io.BufferedReader(raw, buffering) - text = io.TextIOWrapper(buffer, None, None) - text.mode = "rb" - return text - - def _test_readline(self, size=-1, buffering=-1): - mock_sock = self.MockSocket(recv_funcs=[ - lambda : b"This is the first line\nAnd the sec", - self._raise_eintr, - lambda : b"ond line is here\n", - lambda : b"", - lambda : b"", # XXX(gps): io library does an extra EOF read - ]) - fo = mock_sock._textiowrap_for_test(buffering=buffering) - self.assertEqual(fo.readline(size), "This is the first line\n") - self.assertEqual(fo.readline(size), "And the second line is here\n") - - def _test_read(self, size=-1, buffering=-1): - mock_sock = self.MockSocket(recv_funcs=[ - lambda : b"This is the first line\nAnd the sec", - self._raise_eintr, - lambda : b"ond line is here\n", - lambda : b"", - lambda : b"", # XXX(gps): io library does an extra EOF read - ]) - expecting = (b"This is the first line\n" - b"And the second line is here\n") - fo = mock_sock._textiowrap_for_test(buffering=buffering) - if buffering == 0: - data = b'' - else: - data = '' - expecting = expecting.decode('utf-8') - while len(data) != len(expecting): - part = fo.read(size) - if not part: - break - data += part - self.assertEqual(data, expecting) - - def test_default(self): - self._test_readline() - self._test_readline(size=100) - self._test_read() - self._test_read(size=100) - - def test_with_1k_buffer(self): - self._test_readline(buffering=1024) - self._test_readline(size=100, buffering=1024) - self._test_read(buffering=1024) - self._test_read(size=100, buffering=1024) - - def _test_readline_no_buffer(self, size=-1): - mock_sock = self.MockSocket(recv_funcs=[ - lambda : b"a", - lambda : b"\n", - lambda : b"B", - self._raise_eintr, - lambda : b"b", - lambda : b"", - ]) - fo = mock_sock._textiowrap_for_test(buffering=0) - self.assertEqual(fo.readline(size), b"a\n") - self.assertEqual(fo.readline(size), b"Bb") - - def test_no_buffer(self): - self._test_readline_no_buffer() - self._test_readline_no_buffer(size=4) - self._test_read(buffering=0) - self._test_read(size=100, buffering=0) - - class UnbufferedFileObjectClassTestCase(FileObjectClassTestCase): """Repeat the tests from FileObjectClassTestCase with bufsize==0. @@ -5388,7 +5273,6 @@ tests.extend([ NonBlockingTCPTests, FileObjectClassTestCase, - FileObjectInterruptedTestCase, UnbufferedFileObjectClassTestCase, LineBufferedFileObjectClassTestCase, SmallBufferedFileObjectClassTestCase, diff -r 7e6340e67618 Lib/test/test_subprocess.py --- a/Lib/test/test_subprocess.py Fri Jan 30 00:16:31 2015 +0100 +++ b/Lib/test/test_subprocess.py Fri Jan 30 22:08:27 2015 +0000 @@ -2421,25 +2421,6 @@ ProcessTestCase.tearDown(self) -class HelperFunctionTests(unittest.TestCase): - @unittest.skipIf(mswindows, "errno and EINTR make no sense on windows") - def test_eintr_retry_call(self): - record_calls = [] - def fake_os_func(*args): - record_calls.append(args) - if len(record_calls) == 2: - raise OSError(errno.EINTR, "fake interrupted system call") - return tuple(reversed(args)) - - self.assertEqual((999, 256), - subprocess._eintr_retry_call(fake_os_func, 256, 999)) - self.assertEqual([(256, 999)], record_calls) - # This time there will be an EINTR so it will loop once. - self.assertEqual((666,), - subprocess._eintr_retry_call(fake_os_func, 666)) - self.assertEqual([(256, 999), (666,), (666,)], record_calls) - - @unittest.skipUnless(mswindows, "Windows-specific tests") class CommandsWithSpaces (BaseTestCase): @@ -2528,7 +2509,6 @@ Win32ProcessTestCase, CommandTests, ProcessTestCaseNoPoll, - HelperFunctionTests, CommandsWithSpaces, ContextManagerTests, ) diff -r 7e6340e67618 Modules/_io/fileio.c --- a/Modules/_io/fileio.c Fri Jan 30 00:16:31 2015 +0100 +++ b/Modules/_io/fileio.c Fri Jan 30 22:08:27 2015 +0000 @@ -218,6 +218,7 @@ #ifdef HAVE_FSTAT struct stat fdfstat; #endif + int async_err = 0; assert(PyFileIO_Check(oself)); if (self->fd >= 0) { @@ -360,15 +361,18 @@ errno = 0; if (opener == Py_None) { - Py_BEGIN_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS #ifdef MS_WINDOWS - if (widename != NULL) - self->fd = _wopen(widename, flags, 0666); - else + if (widename != NULL) + self->fd = _wopen(widename, flags, 0666); + else #endif - self->fd = open(name, flags, 0666); + self->fd = open(name, flags, 0666); - Py_END_ALLOW_THREADS + Py_END_ALLOW_THREADS + } while (self->fd < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); } else { PyObject *fdobj; @@ -397,7 +401,8 @@ fd_is_own = 1; if (self->fd < 0) { - PyErr_SetFromErrnoWithFilenameObject(PyExc_OSError, nameobj); + if (!async_err) + PyErr_SetFromErrnoWithFilenameObject(PyExc_OSError, nameobj); goto error; } @@ -550,7 +555,7 @@ { Py_buffer pbuf; Py_ssize_t n, len; - int err; + int err, async_err = 0; if (self->fd < 0) return err_closed(); @@ -562,16 +567,19 @@ if (_PyVerify_fd(self->fd)) { len = pbuf.len; - Py_BEGIN_ALLOW_THREADS - errno = 0; + do { + Py_BEGIN_ALLOW_THREADS + errno = 0; #ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - n = read(self->fd, pbuf.buf, (int)len); + if (len > INT_MAX) + len = INT_MAX; + n = read(self->fd, pbuf.buf, (int)len); #else - n = read(self->fd, pbuf.buf, len); + n = read(self->fd, pbuf.buf, len); #endif - Py_END_ALLOW_THREADS + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); } else n = -1; err = errno; @@ -580,7 +588,8 @@ if (err == EAGAIN) Py_RETURN_NONE; errno = err; - PyErr_SetFromErrno(PyExc_IOError); + if (!async_err) + PyErr_SetFromErrno(PyExc_IOError); return NULL; } @@ -627,6 +636,7 @@ Py_ssize_t bytes_read = 0; Py_ssize_t n; size_t bufsize; + int async_err = 0; if (self->fd < 0) return err_closed(); @@ -673,27 +683,23 @@ return NULL; } } - Py_BEGIN_ALLOW_THREADS - errno = 0; - n = bufsize - bytes_read; + do { + Py_BEGIN_ALLOW_THREADS + errno = 0; + n = bufsize - bytes_read; #ifdef MS_WINDOWS - if (n > INT_MAX) - n = INT_MAX; - n = read(self->fd, PyBytes_AS_STRING(result) + bytes_read, (int)n); + if (n > INT_MAX) + n = INT_MAX; + n = read(self->fd, PyBytes_AS_STRING(result) + bytes_read, (int)n); #else - n = read(self->fd, PyBytes_AS_STRING(result) + bytes_read, n); + n = read(self->fd, PyBytes_AS_STRING(result) + bytes_read, n); #endif - Py_END_ALLOW_THREADS + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); if (n == 0) break; if (n < 0) { - if (errno == EINTR) { - if (PyErr_CheckSignals()) { - Py_DECREF(result); - return NULL; - } - continue; - } if (errno == EAGAIN) { if (bytes_read > 0) break; @@ -701,7 +707,8 @@ Py_RETURN_NONE; } Py_DECREF(result); - PyErr_SetFromErrno(PyExc_IOError); + if (!async_err) + PyErr_SetFromErrno(PyExc_IOError); return NULL; } bytes_read += n; @@ -723,6 +730,7 @@ char *ptr; Py_ssize_t n; Py_ssize_t size = -1; + int async_err = 0; PyObject *bytes; if (self->fd < 0) @@ -747,14 +755,17 @@ ptr = PyBytes_AS_STRING(bytes); if (_PyVerify_fd(self->fd)) { - Py_BEGIN_ALLOW_THREADS - errno = 0; + do { + Py_BEGIN_ALLOW_THREADS + errno = 0; #ifdef MS_WINDOWS - n = read(self->fd, ptr, (int)size); + n = read(self->fd, ptr, (int)size); #else - n = read(self->fd, ptr, size); + n = read(self->fd, ptr, size); #endif - Py_END_ALLOW_THREADS + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); } else n = -1; @@ -764,7 +775,8 @@ if (err == EAGAIN) Py_RETURN_NONE; errno = err; - PyErr_SetFromErrno(PyExc_IOError); + if (!async_err) + PyErr_SetFromErrno(PyExc_IOError); return NULL; } @@ -783,7 +795,7 @@ { Py_buffer pbuf; Py_ssize_t n, len; - int err; + int err, async_err = 0; if (self->fd < 0) return err_closed(); @@ -794,24 +806,26 @@ return NULL; if (_PyVerify_fd(self->fd)) { - Py_BEGIN_ALLOW_THREADS - errno = 0; - len = pbuf.len; + do { + Py_BEGIN_ALLOW_THREADS + errno = 0; + len = pbuf.len; #ifdef MS_WINDOWS - if (len > 32767 && isatty(self->fd)) { - /* Issue #11395: the Windows console returns an error (12: not - enough space error) on writing into stdout if stdout mode is - binary and the length is greater than 66,000 bytes (or less, - depending on heap usage). */ - len = 32767; - } - else if (len > INT_MAX) - len = INT_MAX; - n = write(self->fd, pbuf.buf, (int)len); + if (len > 32767 && isatty(self->fd)) { + /* Issue #11395: the Windows console returns an error (12: not + enough space error) on writing into stdout if stdout mode is + binary and the length is greater than 66,000 bytes (or less, + depending on heap usage). */ + len = 32767; + } else if (len > INT_MAX) + len = INT_MAX; + n = write(self->fd, pbuf.buf, (int)len); #else - n = write(self->fd, pbuf.buf, len); + n = write(self->fd, pbuf.buf, len); #endif - Py_END_ALLOW_THREADS + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); } else n = -1; err = errno; @@ -822,7 +836,8 @@ if (err == EAGAIN) Py_RETURN_NONE; errno = err; - PyErr_SetFromErrno(PyExc_IOError); + if (!async_err) + PyErr_SetFromErrno(PyExc_IOError); return NULL; } diff -r 7e6340e67618 Modules/posixmodule.c --- a/Modules/posixmodule.c Fri Jan 30 00:16:31 2015 +0100 +++ b/Modules/posixmodule.c Fri Jan 30 22:08:27 2015 +0000 @@ -1361,13 +1361,16 @@ posix_fildes_fd(int fd, int (*func)(int)) { int res; - Py_BEGIN_ALLOW_THREADS - res = (*func)(fd); - Py_END_ALLOW_THREADS - if (res < 0) - return posix_error(); - Py_INCREF(Py_None); - return Py_None; + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + res = (*func)(fd); + Py_END_ALLOW_THREADS + } while (res != 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res != 0) + return (!async_err) ? posix_error() : NULL; + Py_RETURN_NONE; } @@ -3479,11 +3482,16 @@ /*[clinic end generated code: output=3c19fbfd724a8e0f input=8ab11975ca01ee5b]*/ { int res; - Py_BEGIN_ALLOW_THREADS - res = fchmod(fd, mode); - Py_END_ALLOW_THREADS - if (res < 0) - return posix_error(); + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + res = fchmod(fd, mode); + Py_END_ALLOW_THREADS + } while (res != 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res != 0) + return (!async_err) ? posix_error() : NULL; + Py_RETURN_NONE; } #endif /* HAVE_FCHMOD */ @@ -4104,11 +4112,16 @@ /*[clinic end generated code: output=687781cb7d8974d6 input=3af544ba1b13a0d7]*/ { int res; - Py_BEGIN_ALLOW_THREADS - res = fchown(fd, uid, gid); - Py_END_ALLOW_THREADS - if (res < 0) - return posix_error(); + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + res = fchown(fd, uid, gid); + Py_END_ALLOW_THREADS + } while (res != 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res != 0) + return (!async_err) ? posix_error() : NULL; + Py_RETURN_NONE; } #endif /* HAVE_FCHOWN */ @@ -9602,12 +9615,17 @@ { pid_t pid; struct rusage ru; + int async_err = 0; WAIT_TYPE status; WAIT_STATUS_INT(status) = 0; - Py_BEGIN_ALLOW_THREADS - pid = wait3(&status, options, &ru); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + pid = wait3(&status, options, &ru); + Py_END_ALLOW_THREADS + } while (pid < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (pid < 0) + return (!async_err) ? posix_error() : NULL; return wait_helper(pid, WAIT_STATUS_INT(status), &ru); } @@ -9665,15 +9683,21 @@ os_wait4_impl(PyModuleDef *module, pid_t pid, int options) /*[clinic end generated code: output=20dfb05289d37dc6 input=d11deed0750600ba]*/ { + pid_t res; struct rusage ru; + int async_err = 0; WAIT_TYPE status; WAIT_STATUS_INT(status) = 0; - Py_BEGIN_ALLOW_THREADS - pid = wait4(pid, &status, options, &ru); - Py_END_ALLOW_THREADS - - return wait_helper(pid, WAIT_STATUS_INT(status), &ru); + do { + Py_BEGIN_ALLOW_THREADS + res = wait4(pid, &status, options, &ru); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res < 0) + return (!async_err) ? posix_error() : NULL; + + return wait_helper(res, WAIT_STATUS_INT(status), &ru); } #endif /* HAVE_WAIT4 */ @@ -9744,14 +9768,17 @@ { PyObject *result; int res; + int async_err = 0; siginfo_t si; si.si_pid = 0; - Py_BEGIN_ALLOW_THREADS - res = waitid(idtype, id, &si, options); - Py_END_ALLOW_THREADS - if (res == -1) - return posix_error(); + do { + Py_BEGIN_ALLOW_THREADS + res = waitid(idtype, id, &si, options); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res < 0) + return (!async_err) ? posix_error() : NULL; if (si.si_pid == 0) Py_RETURN_NONE; @@ -9828,16 +9855,20 @@ os_waitpid_impl(PyModuleDef *module, pid_t pid, int options) /*[clinic end generated code: output=095a6b00af70b7ac input=0bf1666b8758fda3]*/ { + pid_t res; + int async_err = 0; WAIT_TYPE status; WAIT_STATUS_INT(status) = 0; - Py_BEGIN_ALLOW_THREADS - pid = waitpid(pid, &status, options); - Py_END_ALLOW_THREADS - if (pid == -1) - return posix_error(); - - return Py_BuildValue("Ni", PyLong_FromPid(pid), WAIT_STATUS_INT(status)); + do { + Py_BEGIN_ALLOW_THREADS + res = waitpid(pid, &status, options); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res < 0) + return (!async_err) ? posix_error() : NULL; + + return Py_BuildValue("Ni", PyLong_FromPid(res), WAIT_STATUS_INT(status)); } #elif defined(HAVE_CWAIT) /* MS C has a variant of waitpid() that's usable for most purposes. */ @@ -9894,15 +9925,19 @@ /*[clinic end generated code: output=c20b95b15ad44a3a input=444c8f51cca5b862]*/ { int status; - - Py_BEGIN_ALLOW_THREADS - pid = _cwait(&status, pid, options); - Py_END_ALLOW_THREADS - if (pid == -1) - return posix_error(); + Py_intptr_t res; + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + res = _cwait(&status, pid, options); + Py_END_ALLOW_THREADS + } while (res < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (res != 0) + return (!async_err) ? posix_error() : NULL; /* shift the status left a byte so this is more like the POSIX waitpid */ - return Py_BuildValue(_Py_PARSE_INTPTR "i", pid, status << 8); + return Py_BuildValue(_Py_PARSE_INTPTR "i", res, status << 8); } #endif @@ -9943,14 +9978,17 @@ /*[clinic end generated code: output=2a83a9d164e7e6a8 input=03b0182d4a4700ce]*/ { pid_t pid; + int async_err = 0; WAIT_TYPE status; WAIT_STATUS_INT(status) = 0; - Py_BEGIN_ALLOW_THREADS - pid = wait(&status); - Py_END_ALLOW_THREADS - if (pid == -1) - return posix_error(); + do { + Py_BEGIN_ALLOW_THREADS + pid = wait(&status); + Py_END_ALLOW_THREADS + } while (pid < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (pid < 0) + return (!async_err) ? posix_error() : NULL; return Py_BuildValue("Ni", PyLong_FromPid(pid), WAIT_STATUS_INT(status)); } @@ -10837,6 +10875,7 @@ /*[clinic end generated code: output=05b68fc4ed5e29c9 input=ad8623b29acd2934]*/ { int fd; + int async_err = 0; #ifdef O_CLOEXEC int *atomic_flag_works = &_Py_open_cloexec_works; @@ -10850,22 +10889,25 @@ flags |= O_CLOEXEC; #endif - Py_BEGIN_ALLOW_THREADS -#ifdef MS_WINDOWS - if (path->wide) - fd = _wopen(path->wide, flags, mode); - else + do { + Py_BEGIN_ALLOW_THREADS +#ifdef MS_WINDOWS + if (path->wide) + fd = _wopen(path->wide, flags, mode); + else #endif #ifdef HAVE_OPENAT - if (dir_fd != DEFAULT_DIR_FD) - fd = openat(dir_fd, path->narrow, flags, mode); - else -#endif - fd = open(path->narrow, flags, mode); - Py_END_ALLOW_THREADS + if (dir_fd != DEFAULT_DIR_FD) + fd = openat(dir_fd, path->narrow, flags, mode); + else +#endif + fd = open(path->narrow, flags, mode); + Py_END_ALLOW_THREADS + } while (fd < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (fd == -1) { - PyErr_SetFromErrnoWithFilenameObject(PyExc_OSError, path->object); + if (!async_err) + PyErr_SetFromErrnoWithFilenameObject(PyExc_OSError, path->object); return -1; } @@ -10924,6 +10966,10 @@ int res; if (!_PyVerify_fd(fd)) return posix_error(); + /* We do not want to retry upon EINTR: see http://lwn.net/Articles/576478/ + * and http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-09/3000.html + * for more details. + */ Py_BEGIN_ALLOW_THREADS res = close(fd); Py_END_ALLOW_THREADS @@ -11089,6 +11135,10 @@ if (!_PyVerify_fd_dup2(fd, fd2)) return posix_error(); + /* dup2() can fail with EINTR if the target FD is already open, because it + * then has to be closed. See os_close_impl() for why we don't handle EINTR + * upon close(), and therefore below. + */ #ifdef MS_WINDOWS Py_BEGIN_ALLOW_THREADS res = dup2(fd, fd2); @@ -11355,6 +11405,7 @@ /*[clinic end generated code: output=1f3bc27260a24968 input=1df2eaa27c0bf1d3]*/ { Py_ssize_t n; + int async_err = 0; PyObject *buffer; if (length < 0) { @@ -11375,13 +11426,16 @@ buffer = PyBytes_FromStringAndSize((char *)NULL, length); if (buffer == NULL) return NULL; - Py_BEGIN_ALLOW_THREADS - n = read(fd, PyBytes_AS_STRING(buffer), READ_CAST length); - Py_END_ALLOW_THREADS + + do { + Py_BEGIN_ALLOW_THREADS + n = read(fd, PyBytes_AS_STRING(buffer), READ_CAST length); + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (n < 0) { Py_DECREF(buffer); - return posix_error(); + return (!async_err) ? posix_error() : NULL; } if (n != length) @@ -11515,6 +11569,7 @@ { int cnt; Py_ssize_t n; + int async_err = 0; struct iovec *iov; Py_buffer *buf; @@ -11529,13 +11584,16 @@ if (iov_setup(&iov, &buf, buffers, cnt, PyBUF_WRITABLE) < 0) return -1; - Py_BEGIN_ALLOW_THREADS - n = readv(fd, iov, cnt); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + n = readv(fd, iov, cnt); + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); iov_cleanup(iov, buf, cnt); if (n < 0) { - posix_error(); + if (!async_err) + posix_error(); return -1; } @@ -11598,6 +11656,7 @@ /*[clinic end generated code: output=7b62bf6c06e20ae8 input=084948dcbaa35d4c]*/ { Py_ssize_t n; + int async_err = 0; PyObject *buffer; if (length < 0) { @@ -11611,12 +11670,16 @@ Py_DECREF(buffer); return posix_error(); } - Py_BEGIN_ALLOW_THREADS - n = pread(fd, PyBytes_AS_STRING(buffer), length, offset); - Py_END_ALLOW_THREADS + + do { + Py_BEGIN_ALLOW_THREADS + n = pread(fd, PyBytes_AS_STRING(buffer), length, offset); + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (n < 0) { Py_DECREF(buffer); - return posix_error(); + return (!async_err) ? posix_error() : NULL; } if (n != length) _PyBytes_Resize(&buffer, n); @@ -11677,6 +11740,7 @@ /*[clinic end generated code: output=aeb96acfdd4d5112 input=3207e28963234f3c]*/ { Py_ssize_t size; + int async_err = 0; Py_ssize_t len = data->len; if (!_PyVerify_fd(fd)) { @@ -11684,17 +11748,21 @@ return -1; } - Py_BEGIN_ALLOW_THREADS -#ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - size = write(fd, data->buf, (int)len); -#else - size = write(fd, data->buf, len); -#endif - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS +#ifdef MS_WINDOWS + if (len > INT_MAX) + len = INT_MAX; + size = write(fd, data->buf, (int)len); +#else + size = write(fd, data->buf, len); +#endif + Py_END_ALLOW_THREADS + } while (size < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (size < 0) { - posix_error(); + if (!async_err) + posix_error(); return -1; } return size; @@ -11713,6 +11781,7 @@ { int in, out; Py_ssize_t ret; + int async_err = 0; off_t offset; #if defined(__FreeBSD__) || defined(__DragonFly__) || defined(__APPLE__) @@ -11775,13 +11844,15 @@ } } - Py_BEGIN_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS #ifdef __APPLE__ - ret = sendfile(in, out, offset, &sbytes, &sf, flags); -#else - ret = sendfile(in, out, offset, len, &sf, &sbytes, flags); -#endif - Py_END_ALLOW_THREADS + ret = sendfile(in, out, offset, &sbytes, &sf, flags); +#else + ret = sendfile(in, out, offset, len, &sf, &sbytes, flags); +#endif + Py_END_ALLOW_THREADS + } while (ret < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (sf.headers != NULL) iov_cleanup(sf.headers, hbuf, sf.hdr_cnt); @@ -11800,7 +11871,7 @@ return posix_error(); } } - return posix_error(); + return (!async_err) ? posix_error() : NULL; } goto done; @@ -11821,21 +11892,26 @@ return NULL; #ifdef linux if (offobj == Py_None) { + do { + Py_BEGIN_ALLOW_THREADS + ret = sendfile(out, in, NULL, count); + Py_END_ALLOW_THREADS + } while (ret < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + if (ret < 0) + return (!async_err) ? posix_error() : NULL; + return Py_BuildValue("n", ret); + } +#endif + if (!Py_off_t_converter(offobj, &offset)) + return NULL; + + do { Py_BEGIN_ALLOW_THREADS - ret = sendfile(out, in, NULL, count); + ret = sendfile(out, in, &offset, count); Py_END_ALLOW_THREADS - if (ret < 0) - return posix_error(); - return Py_BuildValue("n", ret); - } -#endif - if (!Py_off_t_converter(offobj, &offset)) - return NULL; - Py_BEGIN_ALLOW_THREADS - ret = sendfile(out, in, &offset, count); - Py_END_ALLOW_THREADS + } while (ret < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (ret < 0) - return posix_error(); + return (!async_err) ? posix_error() : NULL; return Py_BuildValue("n", ret); #endif } @@ -11891,15 +11967,18 @@ { STRUCT_STAT st; int res; - - Py_BEGIN_ALLOW_THREADS - res = FSTAT(fd, &st); - Py_END_ALLOW_THREADS + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + res = FSTAT(fd, &st); + Py_END_ALLOW_THREADS + } while (res != 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (res != 0) { #ifdef MS_WINDOWS return PyErr_SetFromWindowsErr(0); #else - return posix_error(); + return (!async_err) ? posix_error() : NULL; #endif } @@ -12185,6 +12264,7 @@ { int cnt; Py_ssize_t result; + int async_err = 0; struct iovec *iov; Py_buffer *buf; @@ -12199,12 +12279,14 @@ return -1; } - Py_BEGIN_ALLOW_THREADS - result = writev(fd, iov, cnt); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + result = writev(fd, iov, cnt); + Py_END_ALLOW_THREADS + } while (result < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); iov_cleanup(iov, buf, cnt); - if (result < 0) + if (result < 0 && !async_err) posix_error(); return result; @@ -12275,17 +12357,20 @@ /*[clinic end generated code: output=ec9cc5b2238e96a7 input=19903f1b3dd26377]*/ { Py_ssize_t size; + int async_err = 0; if (!_PyVerify_fd(fd)) { posix_error(); return -1; } - Py_BEGIN_ALLOW_THREADS - size = pwrite(fd, buffer->buf, (size_t)buffer->len, offset); - Py_END_ALLOW_THREADS - - if (size < 0) + do { + Py_BEGIN_ALLOW_THREADS + size = pwrite(fd, buffer->buf, (size_t)buffer->len, offset); + Py_END_ALLOW_THREADS + } while (size < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); + + if (size < 0 && !async_err) posix_error(); return size; } @@ -12353,18 +12438,21 @@ /*[clinic end generated code: output=b3321927546893d0 input=73032e98a36e0e19]*/ { int result; - - Py_BEGIN_ALLOW_THREADS + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS #ifdef HAVE_MKFIFOAT - if (dir_fd != DEFAULT_DIR_FD) - result = mkfifoat(dir_fd, path->narrow, mode); - else -#endif - result = mkfifo(path->narrow, mode); - Py_END_ALLOW_THREADS - - if (result < 0) - return posix_error(); + if (dir_fd != DEFAULT_DIR_FD) + result = mkfifoat(dir_fd, path->narrow, mode); + else +#endif + result = mkfifo(path->narrow, mode); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); + if (result != 0) + return (!async_err) ? posix_error() : NULL; Py_RETURN_NONE; } @@ -12448,18 +12536,21 @@ /*[clinic end generated code: output=f71d54eaf9bb6f1a input=ee44531551a4d83b]*/ { int result; - - Py_BEGIN_ALLOW_THREADS + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS #ifdef HAVE_MKNODAT - if (dir_fd != DEFAULT_DIR_FD) - result = mknodat(dir_fd, path->narrow, mode, device); - else -#endif - result = mknod(path->narrow, mode, device); - Py_END_ALLOW_THREADS - - if (result < 0) - return posix_error(); + if (dir_fd != DEFAULT_DIR_FD) + result = mknodat(dir_fd, path->narrow, mode, device); + else +#endif + result = mknod(path->narrow, mode, device); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); + if (result != 0) + return (!async_err) ? posix_error() : NULL; Py_RETURN_NONE; } @@ -12662,12 +12753,16 @@ /*[clinic end generated code: output=62326766cb9b76bf input=63b43641e52818f2]*/ { int result; - - Py_BEGIN_ALLOW_THREADS - result = ftruncate(fd, length); - Py_END_ALLOW_THREADS - if (result < 0) - return posix_error(); + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + result = ftruncate(fd, length); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); + if (result != 0) + return (!async_err) ? posix_error() : NULL; Py_RETURN_NONE; } #endif /* HAVE_FTRUNCATE */ @@ -12805,14 +12900,16 @@ /*[clinic end generated code: output=0cd702d2065c79db input=d7a2ef0ab2ca52fb]*/ { int result; - - Py_BEGIN_ALLOW_THREADS - result = posix_fallocate(fd, offset, length); - Py_END_ALLOW_THREADS - if (result != 0) { - errno = result; - return posix_error(); - } + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + result = posix_fallocate(fd, offset, length); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); + if (result != 0) + return (!async_err) ? posix_error() : NULL; Py_RETURN_NONE; } #endif /* HAVE_POSIX_FALLOCATE) && !POSIX_FADVISE_AIX_BUG */ @@ -12883,14 +12980,16 @@ /*[clinic end generated code: output=dad93f32c04dd4f7 input=0fbe554edc2f04b5]*/ { int result; - - Py_BEGIN_ALLOW_THREADS - result = posix_fadvise(fd, offset, length, advice); - Py_END_ALLOW_THREADS - if (result != 0) { - errno = result; - return posix_error(); - } + int async_err = 0; + + do { + Py_BEGIN_ALLOW_THREADS + result = posix_fadvise(fd, offset, length, advice); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); + if (result != 0) + return (!async_err) ? posix_error() : NULL; Py_RETURN_NONE; } #endif /* HAVE_POSIX_FADVISE && !POSIX_FADVISE_AIX_BUG */ @@ -13745,13 +13844,17 @@ /*[clinic end generated code: output=0e32bf07f946ec0d input=d8122243ac50975e]*/ { int result; + int async_err = 0; struct statvfs st; - Py_BEGIN_ALLOW_THREADS - result = fstatvfs(fd, &st); - Py_END_ALLOW_THREADS + do { + Py_BEGIN_ALLOW_THREADS + result = fstatvfs(fd, &st); + Py_END_ALLOW_THREADS + } while (result != 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); if (result != 0) - return posix_error(); + return (!async_err) ? posix_error() : NULL; return _pystatvfs_fromstructstatvfs(st); } diff -r 7e6340e67618 Modules/socketmodule.c --- a/Modules/socketmodule.c Fri Jan 30 00:16:31 2015 +0100 +++ b/Modules/socketmodule.c Fri Jan 30 22:08:27 2015 +0000 @@ -2037,6 +2037,7 @@ PyObject *addr = NULL; PyObject *res = NULL; int timeout; + int async_err = 0; #if defined(HAVE_ACCEPT4) && defined(SOCK_CLOEXEC) /* accept4() is available on Linux 2.6.28+ and glibc 2.10 */ static int accept4_works = -1; @@ -2050,27 +2051,27 @@ return select_error(); BEGIN_SELECT_LOOP(s) - - Py_BEGIN_ALLOW_THREADS - timeout = internal_select_ex(s, 0, interval); - if (!timeout) { + do { + Py_BEGIN_ALLOW_THREADS + timeout = internal_select_ex(s, 0, interval); + if (!timeout) { #if defined(HAVE_ACCEPT4) && defined(SOCK_CLOEXEC) - if (accept4_works != 0) { - newfd = accept4(s->sock_fd, SAS2SA(&addrbuf), &addrlen, - SOCK_CLOEXEC); - if (newfd == INVALID_SOCKET && accept4_works == -1) { - /* On Linux older than 2.6.28, accept4() fails with ENOSYS */ - accept4_works = (errno != ENOSYS); + if (accept4_works != 0) { + newfd = accept4(s->sock_fd, SAS2SA(&addrbuf), &addrlen, + SOCK_CLOEXEC); + if (newfd == INVALID_SOCKET && accept4_works == -1) { + /* On Linux older than 2.6.28, accept4() fails with ENOSYS */ + accept4_works = (errno != ENOSYS); + } } + if (accept4_works == 0) + newfd = accept(s->sock_fd, SAS2SA(&addrbuf), &addrlen); +#else + newfd = accept(s->sock_fd, SAS2SA(&addrbuf), &addrlen); +#endif } - if (accept4_works == 0) - newfd = accept(s->sock_fd, SAS2SA(&addrbuf), &addrlen); -#else - newfd = accept(s->sock_fd, SAS2SA(&addrbuf), &addrlen); -#endif - } - Py_END_ALLOW_THREADS - + Py_END_ALLOW_THREADS + } while (newfd < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (timeout == 1) { PyErr_SetString(socket_timeout, "timed out"); return NULL; @@ -2078,7 +2079,7 @@ END_SELECT_LOOP(s) if (newfd == INVALID_SOCKET) - return s->errorhandler(); + return (!async_err) ? s->errorhandler() : NULL; #ifdef MS_WINDOWS if (!SetHandleInformation((HANDLE)newfd, HANDLE_FLAG_INHERIT, 0)) { @@ -2513,10 +2514,8 @@ /* Signals are not errors (though they may raise exceptions). Adapted from PyErr_SetFromErrnoWithFilenameObject(). */ -#ifdef EINTR if (res == EINTR && PyErr_CheckSignals()) return NULL; -#endif return PyLong_FromLong((long) res); } @@ -2650,6 +2649,7 @@ { Py_ssize_t outlen = -1; int timeout; + int async_err = 0; if (!IS_SELECTABLE(s)) { select_error(); @@ -2661,18 +2661,20 @@ } BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS - timeout = internal_select_ex(s, 0, interval); - if (!timeout) { + do { + Py_BEGIN_ALLOW_THREADS + timeout = internal_select_ex(s, 0, interval); + if (!timeout) { #ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - outlen = recv(s->sock_fd, cbuf, (int)len, flags); + if (len > INT_MAX) + len = INT_MAX; + outlen = recv(s->sock_fd, cbuf, (int)len, flags); #else - outlen = recv(s->sock_fd, cbuf, len, flags); -#endif - } - Py_END_ALLOW_THREADS + outlen = recv(s->sock_fd, cbuf, len, flags); +#endif + } + Py_END_ALLOW_THREADS + } while (outlen < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (timeout == 1) { PyErr_SetString(socket_timeout, "timed out"); @@ -2682,7 +2684,8 @@ if (outlen < 0) { /* Note: the call to errorhandler() ALWAYS indirectly returned NULL, so ignore its return value */ - s->errorhandler(); + if (!async_err) + s->errorhandler(); return -1; } return outlen; @@ -2819,6 +2822,7 @@ int timeout; Py_ssize_t n = -1; socklen_t addrlen; + int async_err = 0; *addr = NULL; @@ -2831,21 +2835,23 @@ } BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS - memset(&addrbuf, 0, addrlen); - timeout = internal_select_ex(s, 0, interval); - if (!timeout) { + do { + Py_BEGIN_ALLOW_THREADS + memset(&addrbuf, 0, addrlen); + timeout = internal_select_ex(s, 0, interval); + if (!timeout) { #ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - n = recvfrom(s->sock_fd, cbuf, (int)len, flags, - (void *) &addrbuf, &addrlen); + if (len > INT_MAX) + len = INT_MAX; + n = recvfrom(s->sock_fd, cbuf, (int)len, flags, + (void *) &addrbuf, &addrlen); #else - n = recvfrom(s->sock_fd, cbuf, len, flags, - SAS2SA(&addrbuf), &addrlen); -#endif - } - Py_END_ALLOW_THREADS + n = recvfrom(s->sock_fd, cbuf, len, flags, + SAS2SA(&addrbuf), &addrlen); +#endif + } + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (timeout == 1) { PyErr_SetString(socket_timeout, "timed out"); @@ -2853,7 +2859,8 @@ } END_SELECT_LOOP(s) if (n < 0) { - s->errorhandler(); + if (!async_err) + s->errorhandler(); return -1; } @@ -2993,6 +3000,7 @@ { ssize_t bytes_received = -1; int timeout; + int async_err = 0; sock_addr_t addrbuf; socklen_t addrbuflen; struct msghdr msg = {0}; @@ -3028,25 +3036,29 @@ } BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS; - msg.msg_name = SAS2SA(&addrbuf); - msg.msg_namelen = addrbuflen; - msg.msg_iov = iov; - msg.msg_iovlen = iovlen; - msg.msg_control = controlbuf; - msg.msg_controllen = controllen; - timeout = internal_select_ex(s, 0, interval); - if (!timeout) - bytes_received = recvmsg(s->sock_fd, &msg, flags); - Py_END_ALLOW_THREADS; - if (timeout == 1) { - PyErr_SetString(socket_timeout, "timed out"); - goto finally; - } + do { + Py_BEGIN_ALLOW_THREADS; + msg.msg_name = SAS2SA(&addrbuf); + msg.msg_namelen = addrbuflen; + msg.msg_iov = iov; + msg.msg_iovlen = iovlen; + msg.msg_control = controlbuf; + msg.msg_controllen = controllen; + timeout = internal_select_ex(s, 0, interval); + if (!timeout) + bytes_received = recvmsg(s->sock_fd, &msg, flags); + Py_END_ALLOW_THREADS; + if (timeout == 1) { + PyErr_SetString(socket_timeout, "timed out"); + goto finally; + } + } while (bytes_received < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); END_SELECT_LOOP(s) if (bytes_received < 0) { - s->errorhandler(); + if (!async_err) + s->errorhandler(); goto finally; } @@ -3305,6 +3317,7 @@ { char *buf; Py_ssize_t len, n = -1; + int async_err = 0; int flags = 0, timeout; Py_buffer pbuf; @@ -3319,18 +3332,20 @@ len = pbuf.len; BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS - timeout = internal_select_ex(s, 1, interval); - if (!timeout) { + do { + Py_BEGIN_ALLOW_THREADS + timeout = internal_select_ex(s, 1, interval); + if (!timeout) { #ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - n = send(s->sock_fd, buf, (int)len, flags); + if (len > INT_MAX) + len = INT_MAX; + n = send(s->sock_fd, buf, (int)len, flags); #else - n = send(s->sock_fd, buf, len, flags); -#endif - } - Py_END_ALLOW_THREADS + n = send(s->sock_fd, buf, len, flags); +#endif + } + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (timeout == 1) { PyBuffer_Release(&pbuf); PyErr_SetString(socket_timeout, "timed out"); @@ -3340,7 +3355,7 @@ PyBuffer_Release(&pbuf); if (n < 0) - return s->errorhandler(); + return (!async_err) ? s->errorhandler() : NULL; return PyLong_FromSsize_t(n); } @@ -3359,7 +3374,8 @@ { char *buf; Py_ssize_t len, n = -1; - int flags = 0, timeout, saved_errno; + int async_err = 0; + int flags = 0, timeout; Py_buffer pbuf; if (!PyArg_ParseTuple(args, "y*|i:sendall", &pbuf, &flags)) @@ -3391,29 +3407,16 @@ PyErr_SetString(socket_timeout, "timed out"); return NULL; } - /* PyErr_CheckSignals() might change errno */ - saved_errno = errno; - /* We must run our signal handlers before looping again. - send() can return a successful partial write when it is - interrupted, so we can't restrict ourselves to EINTR. */ - if (PyErr_CheckSignals()) { - PyBuffer_Release(&pbuf); - return NULL; + if (n >= 0) { + buf += n; + len -= n; } - if (n < 0) { - /* If interrupted, try again */ - if (saved_errno == EINTR) - continue; - else - break; - } - buf += n; - len -= n; - } while (len > 0); + } while (len > 0 && (n >= 0 || errno == EINTR) && + !(async_err = PyErr_CheckSignals())); PyBuffer_Release(&pbuf); - if (n < 0) - return s->errorhandler(); + if (n < 0 || async_err) + return (!async_err) ? s->errorhandler() : NULL; Py_INCREF(Py_None); return Py_None; @@ -3439,6 +3442,7 @@ Py_ssize_t len, arglen; sock_addr_t addrbuf; int addrlen, n = -1, flags, timeout; + int async_err = 0; flags = 0; arglen = PyTuple_Size(args); @@ -3473,20 +3477,22 @@ } BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS - timeout = internal_select_ex(s, 1, interval); - if (!timeout) { + do { + Py_BEGIN_ALLOW_THREADS + timeout = internal_select_ex(s, 1, interval); + if (!timeout) { #ifdef MS_WINDOWS - if (len > INT_MAX) - len = INT_MAX; - n = sendto(s->sock_fd, buf, (int)len, flags, - SAS2SA(&addrbuf), addrlen); + if (len > INT_MAX) + len = INT_MAX; + n = sendto(s->sock_fd, buf, (int)len, flags, + SAS2SA(&addrbuf), addrlen); #else - n = sendto(s->sock_fd, buf, len, flags, - SAS2SA(&addrbuf), addrlen); -#endif - } - Py_END_ALLOW_THREADS + n = sendto(s->sock_fd, buf, len, flags, + SAS2SA(&addrbuf), addrlen); +#endif + } + Py_END_ALLOW_THREADS + } while (n < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (timeout == 1) { PyBuffer_Release(&pbuf); @@ -3496,7 +3502,7 @@ END_SELECT_LOOP(s) PyBuffer_Release(&pbuf); if (n < 0) - return s->errorhandler(); + return (!async_err) ? s->errorhandler() : NULL; return PyLong_FromSsize_t(n); } @@ -3528,6 +3534,7 @@ void *controlbuf = NULL; size_t controllen, controllen_last; ssize_t bytes_sent = -1; + int async_err = 0; int addrlen, timeout, flags = 0; PyObject *data_arg, *cmsg_arg = NULL, *addr_arg = NULL, *data_fast = NULL, *cmsg_fast = NULL, *retval = NULL; @@ -3685,19 +3692,23 @@ } BEGIN_SELECT_LOOP(s) - Py_BEGIN_ALLOW_THREADS; - timeout = internal_select_ex(s, 1, interval); - if (!timeout) - bytes_sent = sendmsg(s->sock_fd, &msg, flags); - Py_END_ALLOW_THREADS; - if (timeout == 1) { - PyErr_SetString(socket_timeout, "timed out"); - goto finally; - } + do { + Py_BEGIN_ALLOW_THREADS; + timeout = internal_select_ex(s, 1, interval); + if (!timeout) + bytes_sent = sendmsg(s->sock_fd, &msg, flags); + Py_END_ALLOW_THREADS; + if (timeout == 1) { + PyErr_SetString(socket_timeout, "timed out"); + goto finally; + } + } while (bytes_sent < 0 && errno == EINTR && + !(async_err = PyErr_CheckSignals())); END_SELECT_LOOP(s) if (bytes_sent < 0) { - s->errorhandler(); + if (!async_err) + s->errorhandler(); goto finally; } retval = PyLong_FromSsize_t(bytes_sent); From report at bugs.python.org Sat Jan 31 10:35:20 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 31 Jan 2015 09:35:20 +0000 Subject: [issue23285] PEP 475 - EINTR handling In-Reply-To: Message-ID: STINNER Victor added the comment: Charles-Fran?ois Natali added the comment: > I just realized I didn't retry upon EINTR for open(): eintr-4.diff > adds this, along with tests (using a fifo). > > Also, I added comments explaining why we don't retry upon close() (see > e.g. http://lwn.net/Articles/576478/ and > http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-09/3000.html). I didn't read these articles yet, but I will. IMO the PEP must be updated if we don't retry in close(), since close() is used as an example where "EINTR is unexpected"! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 10:46:32 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 31 Jan 2015 09:46:32 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1422697592.93.0.0739211581788.issue23342@psf.upfronthosting.co.za> Martin Panter added the comment: Maybe you don?t want to touch the implementation of the ?older high-level API? for fear of subtly breaking something, but for clarification, and perhaps documentation, would the old functions now be equivalent to this? def call(***): # Verify PIPE not in (stdout, stderr) if needed return run(***).returncode def check_call(***): # Verify PIPE not in (stdout, stderr) if needed run(***, check=True) def check_output(***): # Verify stderr != PIPE if needed return run(***, check=True, stdout=PIPE) If they are largely equivalent, perhaps simplify the documentation of them in terms of run(), and move them closer to the run() documentation. Is it worth making the CalledProcessError exception a subclass of CompletedProcess? They seem to be basically storing the same information. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 10:50:15 2015 From: report at bugs.python.org (=?utf-8?q?Ra=C3=BAl_Cumplido?=) Date: Sat, 31 Jan 2015 09:50:15 +0000 Subject: [issue23357] pyvenv help shows incorrect usage Message-ID: <1422697815.11.0.353784279673.issue23357@psf.upfronthosting.co.za> New submission from Ra?l Cumplido: Currently when you execute pyvenv the help message is wrong: host@~ $ pyvenv usage: venv [-h] [--system-site-packages] [--symlinks | --copies] [--clear] [--upgrade] [--without-pip] ENV_DIR [ENV_DIR ...] venv: error: the following arguments are required: ENV_DIR Based on the docs on https://docs.python.org/3/library/venv.html it should be: host@~ $ pyvenv usage: pyvenv [-h] [--system-site-packages] [--symlinks | --copies] [--clear] [--upgrade] [--without-pip] ENV_DIR [ENV_DIR ...] pyvenv: error: the following arguments are required: ENV_DIR Basically instead of saying usage venv it should say usage pyvenv but if you execute the module it should be venv: host@~ $ python3.5 -m venv usage: venv [-h] [--system-site-packages] [--symlinks | --copies] [--clear] [--upgrade] [--without-pip] ENV_DIR [ENV_DIR ...] venv: error: the following arguments are required: ENV_DIR ---------- components: Library (Lib) messages: 235094 nosy: raulcd priority: normal severity: normal status: open title: pyvenv help shows incorrect usage type: enhancement versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 10:51:57 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 31 Jan 2015 09:51:57 +0000 Subject: [issue22765] Fixes for test_gdb (first frame address, entry values) In-Reply-To: <1414669906.53.0.952011236022.issue22765@psf.upfronthosting.co.za> Message-ID: <20150131095106.106389.19373@psf.io> Roundup Robot added the comment: New changeset 47a9cb7ec0cb by Serhiy Storchaka in branch '2.7': Issue #22765: Fixed test_gdb failures. Supressed unexpected gdb output. https://hg.python.org/cpython/rev/47a9cb7ec0cb New changeset 5b5a581d91c8 by Serhiy Storchaka in branch '3.4': Issue #22765: Fixed test_gdb failures. Supressed unexpected gdb output. https://hg.python.org/cpython/rev/5b5a581d91c8 New changeset 3813a5282eac by Serhiy Storchaka in branch 'default': Issue #22765: Fixed test_gdb failures. Supressed unexpected gdb output. https://hg.python.org/cpython/rev/3813a5282eac ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 10:53:47 2015 From: report at bugs.python.org (=?utf-8?q?Ra=C3=BAl_Cumplido?=) Date: Sat, 31 Jan 2015 09:53:47 +0000 Subject: [issue23357] pyvenv help shows incorrect usage In-Reply-To: <1422697815.11.0.353784279673.issue23357@psf.upfronthosting.co.za> Message-ID: <1422698027.69.0.662808657942.issue23357@psf.upfronthosting.co.za> Ra?l Cumplido added the comment: Patch that solves the issue. I am on Misc/ACKS on branch 3.4 but not on default branch. I would appreciate if that gets merged to be added :) ---------- keywords: +patch Added file: http://bugs.python.org/file37936/23357.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 11:09:07 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 31 Jan 2015 10:09:07 +0000 Subject: [issue23353] generator bug with exception: tstate->exc_value is not cleared after an except block In-Reply-To: <1422626936.33.0.830645939586.issue23353@psf.upfronthosting.co.za> Message-ID: <20150131100902.96078.47032@psf.io> Roundup Robot added the comment: New changeset 4555da8c3091 by Victor Stinner in branch '3.4': Issue #23353: Fix the exception handling of generators in PyEval_EvalFrameEx(). https://hg.python.org/cpython/rev/4555da8c3091 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 11:15:40 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 31 Jan 2015 10:15:40 +0000 Subject: [issue23353] generator bug with exception: tstate->exc_value is not cleared after an except block In-Reply-To: <1422626936.33.0.830645939586.issue23353@psf.upfronthosting.co.za> Message-ID: <1422699340.71.0.596907291084.issue23353@psf.upfronthosting.co.za> STINNER Victor added the comment: I agree that it's better to not change the behaviour of generators, backward compatibility matters :-) I wrote tests using my examples and I combined them with gen_exc_state_restore.patch. I commited the changeset in Python 3.4 and 3.5. Backporting the fix to Python 2.7 looks more complex because the EXCEPT_HANDLE try block type and the POP_EXCEPT instruction are new in Python 3.0: introduced by 212a1fee6bf9 from the issue #3021. What do you think? Is it worth to fix this issue in Python 2.7? I plan to workaround this bug in Tulip to support Python 3.3. I will also workaround it in Trollius to support Python 2.6 and newer. So for me, it's ok to live with this known bug. It's just yet another generator bug. asyncio/trollius already work around a yield-from bug (issue #21209) ;-) > Note the patch also fixes the reference leak in test_asyncio. Yes, as I explained in msg235072, this bug caused strange "memory leaks". ---------- Added file: http://bugs.python.org/file37937/gen_exc_value_py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 11:15:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 31 Jan 2015 10:15:40 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <1422699340.14.0.577611822743.issue16840@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is test failure related to this issue: http://buildbot.python.org/all/builders/AMD64%20Windows8%202.7/builds/156/steps/test/logs/stdio test test_tk failed -- Traceback (most recent call last): File "D:\buildarea\2.7.bolen-windows8\build\lib\lib-tk\test\test_tkinter\test_widgets.py", line 91, in test_use wid = parent.winfo_id() File "D:\buildarea\2.7.bolen-windows8\build\lib\lib-tk\Tkinter.py", line 839, in winfo_id self.tk.call('winfo', 'id', self._w)) TclError: integer value too large to represent ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 11:24:05 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 31 Jan 2015 10:24:05 +0000 Subject: [issue21408] delegation of `!=` to the right-hand side argument is not always done In-Reply-To: <1398954687.6.0.574462939929.issue21408@psf.upfronthosting.co.za> Message-ID: <20150131102358.25841.17282@psf.io> Roundup Robot added the comment: New changeset 3603bae63c13 by Serhiy Storchaka in branch 'default': Issue #23326: Removed __ne__ implementations. Since fixing default __ne__ https://hg.python.org/cpython/rev/3603bae63c13 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 11:24:05 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 31 Jan 2015 10:24:05 +0000 Subject: [issue23326] Remove redundant __ne__ implementations In-Reply-To: <1422308079.14.0.124539148403.issue23326@psf.upfronthosting.co.za> Message-ID: <20150131102358.25841.85885@psf.io> Roundup Robot added the comment: New changeset 3603bae63c13 by Serhiy Storchaka in branch 'default': Issue #23326: Removed __ne__ implementations. Since fixing default __ne__ https://hg.python.org/cpython/rev/3603bae63c13 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 12:42:02 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 31 Jan 2015 11:42:02 +0000 Subject: [issue23358] BaseServer missing from socketserver.__all__ Message-ID: <1422704522.18.0.713790375362.issue23358@psf.upfronthosting.co.za> New submission from Martin Panter: This patch adds BaseServer to __all__. It also adds a test case that should automatically fail if someone defines a new function or class in the ?socketserver? module and does not update __all__. ---------- components: Library (Lib) files: socketserver-all.patch keywords: patch messages: 235102 nosy: vadmium priority: normal severity: normal status: open title: BaseServer missing from socketserver.__all__ type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file37938/socketserver-all.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 13:23:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 31 Jan 2015 12:23:49 +0000 Subject: [issue15381] Optimize BytesIO to do less reallocations when written, similarly to StringIO In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za> Message-ID: <1422707029.94.0.977059479027.issue15381@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated patch addresses Antoine's comment. ---------- Added file: http://bugs.python.org/file37939/bytesio_resized_bytes-6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 13:24:57 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 31 Jan 2015 12:24:57 +0000 Subject: [issue23353] generator bug with exception: tstate->exc_value is not cleared after an except block In-Reply-To: <1422626936.33.0.830645939586.issue23353@psf.upfronthosting.co.za> Message-ID: <1422707097.56.0.43579505067.issue23353@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think your patch for 2.7 is wrong as was your patch for 3.x. You shouldn't change the behaviour of sys.exc_info() in the nominal case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 13:26:07 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 31 Jan 2015 12:26:07 +0000 Subject: [issue23254] Document how to close the TCPServer listening socket In-Reply-To: <1421469175.0.0.628748486385.issue23254@psf.upfronthosting.co.za> Message-ID: <1422707167.87.0.9031865125.issue23254@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a simple patch to add server_close() to the documentation, and a simple test to ensure it closes the socket. ---------- keywords: +patch versions: +Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37940/server_close.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 13:38:02 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 31 Jan 2015 12:38:02 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1422707882.57.0.559412059278.issue3566@psf.upfronthosting.co.za> Martin Panter added the comment: I have changed my opinion of the ?peek hack? from . It would be useful when doing non-idempotent requests like POST, to avoid sending a request when we know it is going to fail. I looked into how to implement it so that it works for SSL (which does not support MSG_PEEK), and the neatest solution I could think of would require changing the non-blocking behaviour of BufferedReader.peek(), as described in Issue 13322. So I will leave that for later. Adding ConnectionClosed.v3.patch; main changes: * Removed the connection_reused flag to HTTPResponse * ConnectionClosed raised even for the first request of a connection * Added HTTPConnection.closed flag, which the user may check before a request to see if a fresh connection will be made, or an existing connection will be reused * ConnectionClosed now subclasses both BadStatusLine and ConnectionError * Fixed http.client.__all__ and added a somewhat automated test for it BTW these patches kind of depend on Issue 5811 to confirm that BufferedReader.peek() will definitely return at least one byte unless at EOF. ---------- Added file: http://bugs.python.org/file37941/ConnectionClosed.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 14:03:16 2015 From: report at bugs.python.org (Stefan Krah) Date: Sat, 31 Jan 2015 13:03:16 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422709396.8.0.304975685749.issue23352@psf.upfronthosting.co.za> Stefan Krah added the comment: Cython doesn't follow the spec though (use Python 3): from _testbuffer import * cpdef foo(): cdef unsigned char[:] v = bytearray(b"testing") nd = ndarray(v, getbuf=PyBUF_ND) print(nd.suboffsets) nd = ndarray(v, getbuf=PyBUF_FULL) print(nd.suboffsets) Cython hands out suboffsets even for a PyBUF_ND request, which is definitely wrong. For a PyBUF_FULL request they should only be provided *if needed*. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 14:12:03 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 31 Jan 2015 13:12:03 +0000 Subject: [issue23099] BytesIO and StringIO values unavailable when closed In-Reply-To: <1419248477.31.0.512702147737.issue23099@psf.upfronthosting.co.za> Message-ID: <1422709923.64.0.71052163008.issue23099@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Why not just copy the StringIO documentation? ---------- Added file: http://bugs.python.org/file37942/bytesio_exported_reject_close.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 15:26:07 2015 From: report at bugs.python.org (Stefan Krah) Date: Sat, 31 Jan 2015 14:26:07 +0000 Subject: [issue23349] PyBuffer_ToContiguous() off-by-one error for non-contiguous buffers In-Reply-To: <1422580028.66.0.282678068687.issue23349@psf.upfronthosting.co.za> Message-ID: <1422714367.07.0.495231919444.issue23349@psf.upfronthosting.co.za> Stefan Krah added the comment: Should be fixed, thanks for the patch. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 15:47:47 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 31 Jan 2015 14:47:47 +0000 Subject: [issue23353] generator bug with exception: tstate->exc_value is not cleared after an except block In-Reply-To: <1422626936.33.0.830645939586.issue23353@psf.upfronthosting.co.za> Message-ID: <1422715667.79.0.429460263344.issue23353@psf.upfronthosting.co.za> Antoine Pitrou added the comment: It would have been nice to wait for a review. Generator tests are already in test_exceptions.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 15:53:58 2015 From: report at bugs.python.org (Stefan Krah) Date: Sat, 31 Jan 2015 14:53:58 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422716038.79.0.138391808942.issue23352@psf.upfronthosting.co.za> Stefan Krah added the comment: To summarize, I think this is different from #22445, which also requests relaxed contiguity tests. #22445 is motivated by the fact that slicing can create a certain class of contiguous buffers that aren't recognized as such. No such reason exists here: All-negative suboffsets are only created if a buffer provider chooses to hand them out instead of NULL. To my knowledge only Cython does this, and it's against the PEP (though strictly speaking not against the docs). So I'm -0.5 on this change in general and -1 for 2.7. I'd reject the issue, but let's wait for Antoine's opinion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 16:06:55 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 31 Jan 2015 15:06:55 +0000 Subject: [issue23353] generator bug with exception: tstate->exc_value is not cleared after an except block In-Reply-To: <1422626936.33.0.830645939586.issue23353@psf.upfronthosting.co.za> Message-ID: <1422716815.0.0.186468769205.issue23353@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Additional simple tests for test_exceptions.py. ---------- Added file: http://bugs.python.org/file37943/exctests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 16:16:36 2015 From: report at bugs.python.org (Stefan Krah) Date: Sat, 31 Jan 2015 15:16:36 +0000 Subject: [issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za> Message-ID: <1422717396.97.0.196003604294.issue12834@psf.upfronthosting.co.za> Stefan Krah added the comment: Fixed for 2.7 in #22668. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 16:17:31 2015 From: report at bugs.python.org (Stefan Krah) Date: Sat, 31 Jan 2015 15:17:31 +0000 Subject: [issue12834] memoryview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays In-Reply-To: <1314211505.01.0.756597830367.issue12834@psf.upfronthosting.co.za> Message-ID: <1422717451.46.0.753176109861.issue12834@psf.upfronthosting.co.za> Stefan Krah added the comment: Sorry, #23349. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 16:28:10 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 31 Jan 2015 15:28:10 +0000 Subject: [issue23354] Loading 2 GiLOC file which raises exception causes wrong traceback In-Reply-To: <1422675641.92.0.509373230042.issue23354@psf.upfronthosting.co.za> Message-ID: <1422718090.85.0.0547890657833.issue23354@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 17:15:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 31 Jan 2015 16:15:18 +0000 Subject: [issue23353] generator bug with exception: tstate->exc_value is not cleared after an except block In-Reply-To: <1422626936.33.0.830645939586.issue23353@psf.upfronthosting.co.za> Message-ID: <1422720918.57.0.678971241276.issue23353@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If you need non-normalized exception for testing, a NameError generated by interpreter is not normalized. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 17:27:14 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 31 Jan 2015 16:27:14 +0000 Subject: [issue23353] generator bug with exception: tstate->exc_value is not cleared after an except block In-Reply-To: <1422626936.33.0.830645939586.issue23353@psf.upfronthosting.co.za> Message-ID: <1422721634.81.0.895781149189.issue23353@psf.upfronthosting.co.za> STINNER Victor added the comment: > It would have been nice to wait for a review. Generator tests are already in test_exceptions.py. Sorry, I wanted to quickly push your fix to fix buildbots. I dislike being the responsible of turning all buildbots to red... Before working on this issue, I didn't know test_generators. Well, I didn't know test_exceptions neither :-) test_exceptions.py sounds like a better name for checks on the currently handled exception :-) I saw that test_generators.py is mostly written with doctests. At the beginning, doctests were shiny and fun. Now I consider that it's worse than classic unit tests and I plan to rewrite doctests to unittest.TestCase classes. I will open a new issue for that. > I think your patch for 2.7 is wrong as was your patch for 3.x. You shouldn't change the behaviour of sys.exc_info() in the nominal case. I now agree that gen_exc_value.patch was wrong. gen_exc_value_py27.patch was just a backport of my patch to Python 2.7. (Oh I see that I uploaded gen_exc_value_py27.patch twice, it's a mistake.) In my previous message, I asked myself if it would be possible to backport your patch (gen_exc_state_restore.patch) to Python 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 17:28:49 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 31 Jan 2015 16:28:49 +0000 Subject: [issue23353] generator bug with exception: tstate->exc_value is not cleared after an except block In-Reply-To: <1422626936.33.0.830645939586.issue23353@psf.upfronthosting.co.za> Message-ID: <1422721729.49.0.370759202353.issue23353@psf.upfronthosting.co.za> STINNER Victor added the comment: By the way: buildbots are green again, cool. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 17:34:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 31 Jan 2015 16:34:40 +0000 Subject: [issue23326] Remove redundant __ne__ implementations In-Reply-To: <1422308079.14.0.124539148403.issue23326@psf.upfronthosting.co.za> Message-ID: <1422722080.2.0.626052469254.issue23326@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Martin and Georg for your reviews. ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 17:35:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 31 Jan 2015 16:35:46 +0000 Subject: [issue22765] Fixes for test_gdb (first frame address, entry values) In-Reply-To: <1414669906.53.0.952011236022.issue22765@psf.upfronthosting.co.za> Message-ID: <1422722146.84.0.265659111315.issue22765@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your contribution Bohuslav. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 17:53:32 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 31 Jan 2015 16:53:32 +0000 Subject: [issue23357] pyvenv help shows incorrect usage In-Reply-To: <1422697815.11.0.353784279673.issue23357@psf.upfronthosting.co.za> Message-ID: <1422723212.2.0.117543908417.issue23357@psf.upfronthosting.co.za> STINNER Victor added the comment: Could you please write an unit test for non-regression? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 18:23:09 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 31 Jan 2015 17:23:09 +0000 Subject: [issue23326] Remove redundant __ne__ implementations In-Reply-To: <1422308079.14.0.124539148403.issue23326@psf.upfronthosting.co.za> Message-ID: <1422724989.83.0.175417264358.issue23326@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Nice work. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 18:53:23 2015 From: report at bugs.python.org (Stefan Krah) Date: Sat, 31 Jan 2015 17:53:23 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422726803.1.0.67307458532.issue23352@psf.upfronthosting.co.za> Stefan Krah added the comment: Prepare for a partial reversal of opinion. :) Indexing *can* actually create all-negative suboffsets in a natural way: >>> from _testbuffer import * >>> nd = ndarray([1,2,3,4,5,6,7,8,9,10,11,12], shape=[3,4], flags=ND_PIL) >>> nd.tolist() [[1, 2, 3, 4], [5, 6, 7, 8], [9, 10, 11, 12]] >>> >>> x = nd[1] >>> x.tolist() [5, 6, 7, 8] >>> x.suboffsets (-1,) >>> This leaves me +-0 for the change, with the caveat that applications might break. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 19:33:37 2015 From: report at bugs.python.org (Nikolaus Rath) Date: Sat, 31 Jan 2015 18:33:37 +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: <1422729217.01.0.67473299525.issue15955@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Yes, I still plan to do it, but I haven't started yet. That said, I certainly won't be offended if someone else implements the feature either. Please just let me know when you start working on this (I'll do the same), so there's no duplication of efforts. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 19:37:26 2015 From: report at bugs.python.org (Nikolaus Rath) Date: Sat, 31 Jan 2015 18:37:26 +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: <1422729446.05.0.129216791237.issue15955@psf.upfronthosting.co.za> Nikolaus Rath added the comment: On a more practical note: I believe Nadeem at one point said that the bz2 module is not exactly an example for good stdlib coding, while the lzma module's implementation is quite clean. Therefore Therefore, one idea I had for the bz2 module was to "port" the lzma module to use the bzip2 library (instead of adding a max_size parameter to the bz2 module). Just something to consider if you find time to work on this before me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 19:51:52 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 31 Jan 2015 18:51:52 +0000 Subject: [issue23352] PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL In-Reply-To: <1422581625.15.0.953074491863.issue23352@psf.upfronthosting.co.za> Message-ID: <1422730312.92.0.183929424518.issue23352@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't have an opinion on this. I've never seen suboffsets in use; but it seems reasonable to detect a "dummy suboffsets" array and recognize it as contiguous. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 21:13:07 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 31 Jan 2015 20:13:07 +0000 Subject: [issue23212] Update Windows and OS X installer copies of OpenSSL to 1.0.1l In-Reply-To: <1420833910.43.0.203396056169.issue23212@psf.upfronthosting.co.za> Message-ID: <1422735187.88.0.148422176604.issue23212@psf.upfronthosting.co.za> Steve Dower added the comment: I'll make the change for Windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 21:28:31 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 31 Jan 2015 20:28:31 +0000 Subject: [issue23199] libpython27.a in amd64 release is 32-bit In-Reply-To: <1420764337.42.0.255694319213.issue23199@psf.upfronthosting.co.za> Message-ID: <20150131202826.106293.54369@psf.io> Roundup Robot added the comment: New changeset 536a816e7232 by Steve Dower in branch '2.7': Issue #23199: libpython27.a in amd64 release is 32-bit https://hg.python.org/cpython/rev/536a816e7232 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 21:28:58 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 31 Jan 2015 20:28:58 +0000 Subject: [issue23212] Update Windows and OS X installer copies of OpenSSL to 1.0.1l In-Reply-To: <1420833910.43.0.203396056169.issue23212@psf.upfronthosting.co.za> Message-ID: <20150131202853.39284.39116@psf.io> Roundup Robot added the comment: New changeset c8d7df3cb854 by Steve Dower in branch '2.7': Issue #23212: Update Windows copy of OpenSSL to 1.0.1l https://hg.python.org/cpython/rev/c8d7df3cb854 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 21:31:53 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 31 Jan 2015 20:31:53 +0000 Subject: [issue23212] Update Windows and OS X installer copies of OpenSSL to 1.0.1l In-Reply-To: <1420833910.43.0.203396056169.issue23212@psf.upfronthosting.co.za> Message-ID: <20150131203144.96082.21219@psf.io> Roundup Robot added the comment: New changeset 8049954bc0e4 by Steve Dower in branch '3.4': Issue #23212: Update Windows copy of OpenSSL to 1.0.1l https://hg.python.org/cpython/rev/8049954bc0e4 New changeset 469ff344f8fd by Steve Dower in branch 'default': Issue #23212: Update Windows copy of OpenSSL to 1.0.1l https://hg.python.org/cpython/rev/469ff344f8fd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 21:33:07 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 31 Jan 2015 20:33:07 +0000 Subject: [issue23258] Cannot Install Python 3.4.2 on Windows 7 64 bit / screen print attached In-Reply-To: <1421522813.3.0.624329571132.issue23258@psf.upfronthosting.co.za> Message-ID: <1422736387.39.0.506234967995.issue23258@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 21:35:22 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 31 Jan 2015 20:35:22 +0000 Subject: [issue20983] Python 3.4 'repair' Windows installation does not install pip & setuptools packages In-Reply-To: <1395248368.62.0.321132661018.issue20983@psf.upfronthosting.co.za> Message-ID: <1422736522.89.0.0324481012113.issue20983@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 21:41:54 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 31 Jan 2015 20:41:54 +0000 Subject: [issue19955] When adding .PY and .PYW to PATHEXT, it replaced string instead of appending In-Reply-To: <1386803247.34.0.411424382912.issue19955@psf.upfronthosting.co.za> Message-ID: <1422736914.96.0.297157900795.issue19955@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 22:18:56 2015 From: report at bugs.python.org (=?utf-8?q?Ra=C3=BAl_Cumplido?=) Date: Sat, 31 Jan 2015 21:18:56 +0000 Subject: [issue23357] pyvenv help shows incorrect usage In-Reply-To: <1422697815.11.0.353784279673.issue23357@psf.upfronthosting.co.za> Message-ID: <1422739136.42.0.683361497026.issue23357@psf.upfronthosting.co.za> Ra?l Cumplido added the comment: Added tests (hope is what you expect) and changed some bits on the test file to be pep8 comliant. ---------- Added file: http://bugs.python.org/file37944/23357.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 22:37:58 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 31 Jan 2015 21:37:58 +0000 Subject: [issue23359] Speed-up set_lookkey() Message-ID: <1422740278.04.0.89058521092.issue23359@psf.upfronthosting.co.za> New submission from Raymond Hettinger: This patch applies three techniques to tighten-up the generated code for the lookkey() for sets. I'm not sure I want to do this because it expands the size of the code quite a bit (much like the previously existing lookkey specializations did). As such, it offends my sense of beauty and neatness. That said, it greatly tightens the inner search loop and in the handful of timings I've done so far, it provides a good speed-up for smaller sets (ones that fit in L1 and L2 cache) and minor improvements for bigger sets (where running time is dominated by cost of fetching a cache-line with a key/hash pair). The three transformations are: 1.) Make two variants of lookkey, one with an early-out for a dummy entry and one that treats a dummy entry as an active entry. This eliminates the freeslot tracking in both cases. In the first case (early-out), it frees one register (the one for the freeslot), it simplifies the inner-loop test (no need to see if freeslot is NULL), it provides an early-out (return on dummy rather than continuing to search), and it simplifies the return code (just return entry, no need to check the freeslot). In the second case (dummies treated as active), it frees two registers (one for freeslot and the other for &dummy) and it removes the dummy/freeslot inner-loop test entirely. That eliminated inner inner-loop code used to look like this in gcc-4.9: cmpq %r15, %rbp entry->key != dummny jne L375 | testq %r13, %r13 freelslot == NULL | cmove %rbx, %r13 | L375: <---| And the eliminated inner loop code was even worse with clang: leaq __dummy_struct(%rip), %rax cmpq %rax, %r14 entry->key==dummy sete %al testq %rbx, %rbx freeslot==NULL sete %cl testb %cl, %al cmovneq %r13, %rbx freeslot ?= entry 2.) Avoid the &mask step for computing indices when not needed. Using the same technique that is used in set_insert_clean, we test to see if there is a possible wrap-around during the linear probes. If not, we can skip the lengthy address calculation for table[(i+j)&mask] and instead use entry++. This saves the sequentially dependent steps of add j, the bitwise-and with the mask, a shift left by four to scale the index, and the add to the table start address. It replaces those steps with a single entry++ which codes as an add $16. 3). In the linear_probe inner-loop for the ignore dummy case, replace (entry->key==NULL) with (entry->hash==0 && entry->key==NULL). While that looks like a step backward adding an extra test, that second test is essentially free (a register compare and branch which is nearly 100% predictable). The benefit is that the inner-loop only needs to fetch the entry->hash value and doesn't need to fetch entry->key. This doesn't sound like much but it cuts the number of memory accesses per loop in half. Individually, three transformations don't seem like much, but they take already tight code and cut the work more than in-half (for the L1 and L2 case). Collectively, it frees a couple of registers for better register allocation, it reduces the number of compares inside the loop, in substantially reduces the time for the entry address calculation, and in the ignore-dummy case cuts the number of memory accesses per loop in half. The resulting code is astonishingly tight compared to the original and looks almost as tight as the code in set_insert_clean(). --- inner-loop of set_lookkey_dummy_allowed() --- L393: cmpq %r8, (%rbx) entry->key == dummy je L453 cmpq %r12, %rbx entry == limit movq %rbx, %r14 je L506 L412: movq 16(%r14), %rbp leaq 16(%r14), %rbx testq %rbp, %rbp entry->key NULL je L449 cmpq 8(%rbx), %r15 entry->hash == hash jne L393 --- inner-loop of set_lookkey_dummy_ignored() --- L846: cmpq %r13, %rbx entry == limit je L942 addq $16, %rbx entry++ movq 8(%rbx), %rax entry->hash == NULL testq %rax, %rax jne L845 cmpq $0, (%rbx) entry->key == NULL (not in the inner loop) je L905 L845: cmpq %r12, %rax entry->hash == tgt jne L846 Before anything can go forward, more timings are needed and I need to come to terms with the code expansion back to size it was before the old lookkey specializations where removed. For now, I just want to document the work that has been done. Anyway, here it is if someone wants to experiment with it. Expect benefits in the cases where the inner-loop matters (small to medium sized sets that have collisions -- giant sets benefit as well but their lookup speed is dominated by the cost to fetch a single random cache line). ---------- files: hoisted_and_specialized.diff keywords: patch messages: 235131 nosy: rhettinger priority: low severity: normal stage: patch review status: open title: Speed-up set_lookkey() type: performance versions: Python 3.5 Added file: http://bugs.python.org/file37945/hoisted_and_specialized.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 22:57:09 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 31 Jan 2015 21:57:09 +0000 Subject: [issue23359] Speed-up set_lookkey() In-Reply-To: <1422740278.04.0.89058521092.issue23359@psf.upfronthosting.co.za> Message-ID: <1422741429.91.0.486737381351.issue23359@psf.upfronthosting.co.za> Raymond Hettinger added the comment: One further possible transformation is to inline set_lookkey_dummy_allowed() inside set_insert_key() which is the only place it is used. That saves all the test and branch code inside the latter (all that code does is reconstruct the exit points for set_lookkey_dummy_allowed() which were already known). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 22:57:23 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 31 Jan 2015 21:57:23 +0000 Subject: [issue23359] Speed-up set_lookkey() In-Reply-To: <1422740278.04.0.89058521092.issue23359@psf.upfronthosting.co.za> Message-ID: <1422741443.9.0.984853802526.issue23359@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 22:57:24 2015 From: report at bugs.python.org (Thomas Kluyver) Date: Sat, 31 Jan 2015 21:57:24 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1422741444.05.0.487376025058.issue23342@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Yep, they are pretty much equivalent to those, except: - check_call has a 'return 0' if it succeeds - add '.stdout' to the end of the expression for check_output I'll work on documenting the trio in those terms. If people want, some/all of the trio could also be implemented on top of run(). check_output() would be the most likely candidate for this, since I copied that code to create run(). I'd probably leave call and check_call as separate implementations to avoid subtle bugs, though. Sharing inheritance between CalledProcessError and CompletedProcess: That would mean that either CompletedProcess is an exception class, even though it's not used as such, or CalledProcessError uses multiple inheritance. I think duplicating a few attributes is preferable to having to think about multiple inheritance, especially since the names aren't all the same (cmd vs args, output vs stdout). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 31 23:34:04 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 31 Jan 2015 22:34:04 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1422743644.9.0.559637240473.issue23342@psf.upfronthosting.co.za> Martin Panter added the comment: It?s okay to leave them as independent classes, if you don?t want multiple inheritance. I was just putting the idea out there. It is a similar pattern to the HTTPError exception and HTTPResponse return value for urlopen(). ---------- _______________________________________ Python tracker _______________________________________