From report at bugs.python.org Wed Jan 1 00:22:13 2014 From: report at bugs.python.org (Martin Panter) Date: Tue, 31 Dec 2013 23:22:13 +0000 Subject: [issue6135] subprocess seems to use local encoding and give no choice In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za> Message-ID: <1388532133.69.0.688074677903.issue6135@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 1 02:45:31 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 01 Jan 2014 01:45:31 +0000 Subject: [issue19714] Add tests for importlib.machinery.WindowsRegistryFinder In-Reply-To: <1385139731.13.0.379714643713.issue19714@psf.upfronthosting.co.za> Message-ID: <1388540731.41.0.121721451651.issue19714@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +vajrasky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 1 02:52:10 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Jan 2014 01:52:10 +0000 Subject: [issue20055] On Windows NT 6 with administrator account, there are two failing tests on test_shutil.py In-Reply-To: <1387810124.3.0.485695266122.issue20055@psf.upfronthosting.co.za> Message-ID: <3dvFjz4WcCz7Llb@mail.python.org> Roundup Robot added the comment: New changeset 0f888589dbcd by Antoine Pitrou in branch '3.3': Issue #20055: Fix test_shutil under Windows with symlink privileges held. http://hg.python.org/cpython/rev/0f888589dbcd New changeset 6fd3d473e1c2 by Antoine Pitrou in branch 'default': Issue #20055: Fix test_shutil under Windows with symlink privileges held. http://hg.python.org/cpython/rev/6fd3d473e1c2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 1 02:52:31 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 01 Jan 2014 01:52:31 +0000 Subject: [issue20055] On Windows NT 6 with administrator account, there are two failing tests on test_shutil.py In-Reply-To: <1387810124.3.0.485695266122.issue20055@psf.upfronthosting.co.za> Message-ID: <1388541151.98.0.991515610098.issue20055@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Pushed, thank you! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 1 02:56:22 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 01 Jan 2014 01:56:22 +0000 Subject: [issue20099] a new idea In-Reply-To: <1388503131.58.0.100306022546.issue20099@psf.upfronthosting.co.za> Message-ID: <1388541382.32.0.549060354408.issue20099@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This isn't a bug, please use https://mail.python.org/mailman/listinfo/python-ideas if you want to propose ideas. ---------- nosy: +pitrou resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 1 05:51:49 2014 From: report at bugs.python.org (Paul Sokolovsky) Date: Wed, 01 Jan 2014 04:51:49 +0000 Subject: [issue1346238] A constant folding optimization pass for the AST Message-ID: <1388551909.49.0.326252300697.issue1346238@psf.upfronthosting.co.za> Paul Sokolovsky added the comment: 8 years after the original patch, there's still no trivial constant folding in bytecode generated (because peephole of course is not a real optimizer to consistently catch all cases): $ cat const.py FOO = 1 BAR = FOO + 2 + 4 $ python --version Python 2.7.3 $ python -OO -m dis const.py 1 0 LOAD_CONST 0 (1) 3 STORE_NAME 0 (FOO) 2 6 LOAD_NAME 0 (FOO) 9 LOAD_CONST 1 (2) 12 BINARY_ADD 13 LOAD_CONST 2 (4) 16 BINARY_ADD 17 STORE_NAME 1 (BAR) 20 LOAD_CONST 3 (None) 23 RETURN_VALUE $ python3.3 --version Python 3.3.3 $ python3.3 -OO -m dis const.py 1 0 LOAD_CONST 0 (1) 3 STORE_NAME 0 (FOO) 2 6 LOAD_NAME 0 (FOO) 9 LOAD_CONST 1 (2) 12 BINARY_ADD 13 LOAD_CONST 2 (4) 16 BINARY_ADD 17 STORE_NAME 1 (BAR) 20 LOAD_CONST 3 (None) 23 RETURN_VALUE ---------- nosy: +pfalcon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 1 10:23:56 2014 From: report at bugs.python.org (Stefan Behnel) Date: Wed, 01 Jan 2014 09:23:56 +0000 Subject: [issue19108] Benchmark runner tries to execute external Python command and fails on error reporting In-Reply-To: <1380297636.45.0.339184347104.issue19108@psf.upfronthosting.co.za> Message-ID: <1388568236.06.0.491982201915.issue19108@psf.upfronthosting.co.za> Stefan Behnel added the comment: *bump* - patch pending review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 1 12:01:47 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 01 Jan 2014 11:01:47 +0000 Subject: [issue20065] Python-3.3.3/Modules/socketmodule.c:1660:14: error: 'CAN_RAW' undeclared (first use in this function) In-Reply-To: <1387961196.27.0.560814998744.issue20065@psf.upfronthosting.co.za> Message-ID: <1388574107.95.0.157906274545.issue20065@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- assignee: -> neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 1 12:21:17 2014 From: report at bugs.python.org (Peter Santoro) Date: Wed, 01 Jan 2014 11:21:17 +0000 Subject: [issue20102] shutil._make_zipfile possible resource leak Message-ID: <1388575277.51.0.394331001558.issue20102@psf.upfronthosting.co.za> New submission from Peter Santoro: Now that zipfile.ZipFile supports the context manager protocol, shouldn't shutil._make_zipfile make use of it to avoid the possibility of the archive file not being closed properly if an exception occurs? It should be noted that shutil._unpack_zipfile does use try/finally to ensure that files are closed. ---------- components: Library (Lib) files: shutil.diff keywords: patch messages: 207132 nosy: peter at psantoro.net priority: normal severity: normal status: open title: shutil._make_zipfile possible resource leak type: behavior versions: Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file33291/shutil.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 1 12:42:32 2014 From: report at bugs.python.org (Jeremy Kloth) Date: Wed, 01 Jan 2014 11:42:32 +0000 Subject: [issue20101] Determine correct behavior for time functions on Windows In-Reply-To: <1388526152.52.0.960629914987.issue20101@psf.upfronthosting.co.za> Message-ID: <1388576552.15.0.782347409387.issue20101@psf.upfronthosting.co.za> Changes by Jeremy Kloth : ---------- nosy: +jkloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 1 15:02:30 2014 From: report at bugs.python.org (Mitchell Model) Date: Wed, 01 Jan 2014 14:02:30 +0000 Subject: [issue20077] Format of TypeError differs between comparison and arithmetic operators In-Reply-To: <1388106970.8.0.6745803605.issue20077@psf.upfronthosting.co.za> Message-ID: <1388584950.88.0.567436397945.issue20077@psf.upfronthosting.co.za> Mitchell Model added the comment: Patch looks good to me. I like the choice to drop the parens. This is my first time reviewing a change; did I go through the right mechanics? I clicked Review on the issue's patch, looked at the diff, and a published a message similar to this one. Was I supposed to do something else? Is that message what "Review" is looking for? Was the "Please review" directed at me? Am I supposed to make a comment like "looks good" here? do something else? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 1 16:24:33 2014 From: report at bugs.python.org (Gennadiy Zlobin) Date: Wed, 01 Jan 2014 15:24:33 +0000 Subject: [issue20075] help(open) eats first line In-Reply-To: <1388090120.87.0.478863756961.issue20075@psf.upfronthosting.co.za> Message-ID: <1388589873.64.0.54306774279.issue20075@psf.upfronthosting.co.za> Gennadiy Zlobin added the comment: Zachary, thank you for review. Here's the updated patch. ---------- Added file: http://bugs.python.org/file33292/20075-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 1 17:12:00 2014 From: report at bugs.python.org (Mitchell Model) Date: Wed, 01 Jan 2014 16:12:00 +0000 Subject: [issue20103] Documentation of itertools.accumulate is confused Message-ID: <1388592720.87.0.970906154406.issue20103@psf.upfronthosting.co.za> New submission from Mitchell Model: The documentation of itertools.accumulate (10.1) starts out with 2 misleading sentences: "Make an iterator that returns accumulated sums. Elements may be any addable type..." It then goes on to show examples of using the func parameter added in 3.3 that are not additions. It should be changed to something like: "Make an iterator that returns accumulated values. Elements may be any type that can be an argument to func. Func defaults to addition, so by default elements can be any addable types, ..." My wording is awkward, but you get the idea. I think this is a significant documentation issue, not just a nit. ---------- assignee: docs at python components: Documentation messages: 207135 nosy: MLModel, docs at python priority: normal severity: normal status: open title: Documentation of itertools.accumulate is confused versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 1 17:55:56 2014 From: report at bugs.python.org (Gennadiy Zlobin) Date: Wed, 01 Jan 2014 16:55:56 +0000 Subject: [issue20098] email policy needs a mangle_from setting In-Reply-To: <1388446517.27.0.863185292033.issue20098@psf.upfronthosting.co.za> Message-ID: <1388595356.77.0.0195238239283.issue20098@psf.upfronthosting.co.za> Gennadiy Zlobin added the comment: I created the patch, please review it. ---------- keywords: +patch nosy: +gennad Added file: http://bugs.python.org/file33293/20098.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 1 18:03:10 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 01 Jan 2014 17:03:10 +0000 Subject: [issue20103] Documentation of itertools.accumulate is confused In-Reply-To: <1388592720.87.0.970906154406.issue20103@psf.upfronthosting.co.za> Message-ID: <1388595790.84.0.391414267668.issue20103@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 1 19:13:20 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 01 Jan 2014 18:13:20 +0000 Subject: [issue20104] expose posix_spawn(p) Message-ID: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za> New submission from Benjamin Peterson: posix_spawn is a nice, efficient replacement for fork()/exec(). We should expose it and possibly use it in subprocess where possible. ---------- components: Extension Modules messages: 207137 nosy: benjamin.peterson priority: normal severity: normal stage: needs patch status: open title: expose posix_spawn(p) type: performance versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 1 19:22:17 2014 From: report at bugs.python.org (Gennadiy Zlobin) Date: Wed, 01 Jan 2014 18:22:17 +0000 Subject: [issue20104] expose posix_spawn(p) In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za> Message-ID: <1388600537.16.0.47096614944.issue20104@psf.upfronthosting.co.za> Changes by Gennadiy Zlobin : ---------- nosy: +gennad _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 1 19:36:01 2014 From: report at bugs.python.org (Alex Gaynor) Date: Wed, 01 Jan 2014 18:36:01 +0000 Subject: [issue20104] expose posix_spawn(p) In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za> Message-ID: <1388601361.37.0.589997404769.issue20104@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 1 19:54:16 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 01 Jan 2014 18:54:16 +0000 Subject: [issue19108] Benchmark runner tries to execute external Python command and fails on error reporting In-Reply-To: <1380297636.45.0.339184347104.issue19108@psf.upfronthosting.co.za> Message-ID: <1388602456.59.0.593555386487.issue19108@psf.upfronthosting.co.za> R. David Murray added the comment: The patch looks good to me, but since I'm not familiar with perf.py I'm not a good person to do a final review and commit it. One trivial question: why do you check for tupleness in PythonRuntime's init? Don't you control the input on both code paths to obtaining the version? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 1 21:03:48 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 01 Jan 2014 20:03:48 +0000 Subject: [issue20104] expose posix_spawn(p) In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za> Message-ID: <1388606627.99.0.257378724412.issue20104@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +gregory.p.smith, neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 1 22:17:39 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 01 Jan 2014 21:17:39 +0000 Subject: [issue20104] expose posix_spawn(p) In-Reply-To: <1388600000.81.0.911230526926.issue20104@psf.upfronthosting.co.za> Message-ID: <1388611059.05.0.458743759532.issue20104@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Unless it could replace the fork+exec code path in its entirety, which I do not believe is possible, I see posix_spawn() as a distraction and additional maintenance burden with no benefit. http://pubs.opengroup.org/onlinepubs/7999959899/functions/posix_spawn.html Read the RATIONALE section. The posix_spawn API was not created to make subprocess creation easier (i'd argue that it is the same burden to setup a proper call to posix_spawn as it is to do everything right for fork and exec). One notable thing posix_spawn() does not support: setsid() (start_new_session=True) of the child process. Obviously it also couldn't handle the arbitrary preexec_fn but preexec_fn is in general considered harmful. ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 00:37:54 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Jan 2014 23:37:54 +0000 Subject: [issue20065] Python-3.3.3/Modules/socketmodule.c:1660:14: error: 'CAN_RAW' undeclared (first use in this function) In-Reply-To: <1387961196.27.0.560814998744.issue20065@psf.upfronthosting.co.za> Message-ID: <1388619474.04.0.501532012236.issue20065@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 00:48:10 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 01 Jan 2014 23:48:10 +0000 Subject: [issue20098] email policy needs a mangle_from setting In-Reply-To: <1388446517.27.0.863185292033.issue20098@psf.upfronthosting.co.za> Message-ID: <1388620090.23.0.61235684359.issue20098@psf.upfronthosting.co.za> R. David Murray added the comment: Sorry, my message wasn't clear. The current default needs to remain the same. What needs to be added is email.policy.Policy.mange_from, which should be True in the compat32 policy and False in EmailPolicy. Then it needs to be hooked up the Generator, so that an explicit specificaion in the __init__ overrides the policy, but specifying one of EmailPolicy dervived policies will override the default value of the __init__ argument if the argument is not speicifed explicitly in the Generator constructor call. (Backward compatibility is a pain.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 03:03:08 2014 From: report at bugs.python.org (Tim Peters) Date: Thu, 02 Jan 2014 02:03:08 +0000 Subject: [issue20101] Determine correct behavior for time functions on Windows In-Reply-To: <1388526152.52.0.960629914987.issue20101@psf.upfronthosting.co.za> Message-ID: <1388628188.32.0.901199671874.issue20101@psf.upfronthosting.co.za> Tim Peters added the comment: I'm not sanguine about fixing any of this :-( The Microsoft docs are awful, and the more web searches I do the more I realize that absolutely everyone is confused, just taking their best guesses. FYI, here are results from your new program on my 32-bit Vista box: 3.4.0b1 (default:9d1fb265b88a, Dec 10 2013, 18:48:53) [MSC v.1600 32 bit (Intel)] Windows-Vista-6.0.6002-SP2 Running: ... monotonic namespace(adjustable=False, implementation='GetTickCount64()', monotonic=True, resolution=0.015625) ......................... total: 25 good: 25 bad: 0 [(0.5, 25)] time namespace(adjustable=True, implementation='GetSystemTimeAsFileTime()', monotonic=False, resolution=0.015625) FFFFFFFFFFFFFFFFFFFFFFFFF total: 25 good: 0 bad: 25 [(0.4999678134918213, 5), (0.4999680519104004, 20)] clock namespace(adjustable=False, implementation='QueryPerformanceCounter()', monotonic=True, resolution=2.793651148400146e-07) FFFFFFFFFFFFFFFFFFFF.FFFF total: 25 good: 1 bad: 24 [(0.49919109830998076, 1), (0.4996682539261279, 1), (0.4997051301212867, 1), (0.4997221713932909, 1), (0.49972636187001385, 1), (0.499727479330474, 1), (0.49973139044208104, 1), (0.49973390472811463, 1), (0.4997383745699526, 1), (0.49974479996759325, 1), (0.4997501079047755, 1), (0.4997501079047756, 1), (0.49975318092104004, 1), (0.499756533302417, 1), (0.4997598856837939, 1), (0.49976239996982863, 1), (0.49976714917678144, 1), (0.49977078092327387, 1), (0.49977189838373315, 1), (0.4997724571139628, 1), (0.499777765051145, 1), (0.49979173330688553, 1), (0.4997973206091828, 1), (0.4998065396579734, 1), (0.500726488981142, 1)] perf_counter namespace(adjustable=False, implementation='QueryPerformanceCounter()', monotonic=True, resolution=2.793651148400146e-07) Same clock as time.clock ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 03:23:33 2014 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 02 Jan 2014 02:23:33 +0000 Subject: [issue20105] Codec exception chaining is losing traceback details Message-ID: <1388629413.58.0.988087871801.issue20105@psf.upfronthosting.co.za> New submission from Nick Coghlan: The exception chaining in the codecs subsystem is currently losing the details of the original traceback. Compare this traceback from Python 3.3: >>> codecs.decode(b"abcdefgh", "hex_codec") Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.3/encodings/hex_codec.py", line 20, in hex_decode return (binascii.a2b_hex(input), len(input)) binascii.Error: Non-hexadecimal digit found With the current behaviour of Python 3.4: >>> codecs.decode(b"abcdefgh", "hex") binascii.Error: Non-hexadecimal digit found The above exception was the direct cause of the following exception: Traceback (most recent call last): File "", line 1, in binascii.Error: decoding with 'hex' codec failed (Error: Non-hexadecimal digit found) The original traceback header and details are missing in the latter. It should look more like the following: >>> try: ... 1/0 ... except Exception as e: ... raise Exception("Explicit chaining") from e ... Traceback (most recent call last): File "", line 2, in ZeroDivisionError: division by zero The above exception was the direct cause of the following exception: Traceback (most recent call last): File "", line 4, in Exception: Explicit chaining ---------- assignee: ncoghlan components: Interpreter Core keywords: 3.4regression messages: 207142 nosy: ncoghlan priority: deferred blocker severity: normal stage: test needed status: open title: Codec exception chaining is losing traceback details type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 04:09:07 2014 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Jan 2014 03:09:07 +0000 Subject: [issue20097] Bad use of `self` in importlib In-Reply-To: <1388435202.0.0.988564041108.issue20097@psf.upfronthosting.co.za> Message-ID: <1388632147.35.0.707199435539.issue20097@psf.upfronthosting.co.za> Eric Snow added the comment: Here's a patch with tests that cover find_module() and find_spec() for WindowsRegistryFinder (the missing case) and fixes the bug. ---------- keywords: +patch nosy: +eric.snow stage: test needed -> patch review Added file: http://bugs.python.org/file33294/issue20097-tests.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 04:12:27 2014 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Jan 2014 03:12:27 +0000 Subject: [issue20097] Bad use of `self` in importlib In-Reply-To: <1388435202.0.0.988564041108.issue20097@psf.upfronthosting.co.za> Message-ID: <1388632347.94.0.55543426074.issue20097@psf.upfronthosting.co.za> Eric Snow added the comment: The patch passes on my linux box and on my windows 7 laptop (using Visual Studio 2010 Express). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 04:16:56 2014 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Jan 2014 03:16:56 +0000 Subject: [issue20097] Bad use of `self` in importlib In-Reply-To: <1388435202.0.0.988564041108.issue20097@psf.upfronthosting.co.za> Message-ID: <1388632616.35.0.437722128093.issue20097@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file33294/issue20097-tests.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 04:17:37 2014 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Jan 2014 03:17:37 +0000 Subject: [issue20097] Bad use of `self` in importlib In-Reply-To: <1388435202.0.0.988564041108.issue20097@psf.upfronthosting.co.za> Message-ID: <1388632657.83.0.232792568178.issue20097@psf.upfronthosting.co.za> Eric Snow added the comment: Here's an updated patch that fixes as copy-and-paste mistake. ---------- Added file: http://bugs.python.org/file33295/issue20097-tests.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 06:20:42 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Thu, 02 Jan 2014 05:20:42 +0000 Subject: [issue20080] Unused variable in Lib/sqlite3/test/factory.py In-Reply-To: <1388141762.46.0.0728784342465.issue20080@psf.upfronthosting.co.za> Message-ID: <1388640042.65.0.0231900913625.issue20080@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Thanks, Eric! Attached the patch to address Eric's concern. ---------- Added file: http://bugs.python.org/file33296/unused_variable_in_factory_py_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 09:28:15 2014 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 02 Jan 2014 08:28:15 +0000 Subject: [issue2943] Distutils should generate a better error message when the SDK is not installed In-Reply-To: <1211455981.94.0.404413935613.issue2943@psf.upfronthosting.co.za> Message-ID: <1388651295.81.0.101621206825.issue2943@psf.upfronthosting.co.za> Mark Lawrence added the comment: How about "Error: vcvarsall.bat not found - VC++ not installed or wrong version" ? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 11:19:39 2014 From: report at bugs.python.org (Tabrez Mohammed) Date: Thu, 02 Jan 2014 10:19:39 +0000 Subject: [issue20106] warn_dir is always true for install_data, even if an install_dir is specified Message-ID: <1388657979.45.0.323765356952.issue20106@psf.upfronthosting.co.za> New submission from Tabrez Mohammed: In run(), there is a warning message printed to the console if warn_dir is '1': if self.warn_dir: self.warn("setup script did not provide a directory for " "'%s' -- installing right in '%s'" % (f, self.install_dir)) warn_dir should be unset in run to suppress the warning if an install_dir is specified. ---------- components: Distutils messages: 207148 nosy: tabrezm priority: normal severity: normal status: open title: warn_dir is always true for install_data, even if an install_dir is specified type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 11:22:23 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 02 Jan 2014 10:22:23 +0000 Subject: [issue20107] Revert PEP 453 integration Message-ID: <1388658143.96.0.201779546814.issue20107@psf.upfronthosting.co.za> New submission from Martin v. L?wis: According to PEP 453, the integration of pip must be reverted if PIP 1.5 was not released by December 29. AFAICT, this hasn't happened. So is it ok that I revert the PIP integration by Saturday? ---------- messages: 207149 nosy: dstufft, larry, loewis, ncoghlan priority: release blocker severity: normal status: open title: Revert PEP 453 integration versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 11:25:19 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Jan 2014 10:25:19 +0000 Subject: [issue20107] Revert PEP 453 integration In-Reply-To: <1388658143.96.0.201779546814.issue20107@psf.upfronthosting.co.za> Message-ID: <1388658319.92.0.986873603585.issue20107@psf.upfronthosting.co.za> STINNER Victor added the comment: > So is it ok that I revert the PIP integration by Saturday? I'm not ok, this PEP is expected by many users. There is for example, an article on the PEP: http://lwn.net/Articles/570471/ > According to PEP 453, the integration of pip must be reverted if PIP 1.5 was not released by December 29. AFAICT, this hasn't happened. What is the status of PIP 1.5? Is there an expected release date? Or a list of blocker bugs? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 11:30:34 2014 From: report at bugs.python.org (Donald Stufft) Date: Thu, 02 Jan 2014 10:30:34 +0000 Subject: [issue20107] Revert PEP 453 integration In-Reply-To: <1388658143.96.0.201779546814.issue20107@psf.upfronthosting.co.za> Message-ID: <1388658634.96.0.650886972585.issue20107@psf.upfronthosting.co.za> Donald Stufft added the comment: It's basically ready for a release. We had a last minute bug with distlib that was fixed by distlib 0.6 released on 12-31. I was giving the rc that had that bug fix a day or two for any other issues to surface before making the final release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 11:31:39 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 02 Jan 2014 10:31:39 +0000 Subject: [issue20107] Revert PEP 453 integration In-Reply-To: <1388658143.96.0.201779546814.issue20107@psf.upfronthosting.co.za> Message-ID: <1388658699.08.0.463858224618.issue20107@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The only "known" (to me) release date of PIP is documented on http://www.pip-installer.org/en/latest/news.html "Beta and final releases of 1.5 are planned for end of 2013." Apparently, this hasn't happened, either. Something *must* happen by Saturday, I veto the release of 3.4b2 with no final PIP 1.5 release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 11:32:45 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 02 Jan 2014 10:32:45 +0000 Subject: [issue20107] Revert PEP 453 integration In-Reply-To: <1388658143.96.0.201779546814.issue20107@psf.upfronthosting.co.za> Message-ID: <1388658765.52.0.983142867553.issue20107@psf.upfronthosting.co.za> Larry Hastings added the comment: I agree--though it would be better if you simply got it in before Saturday. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 11:35:23 2014 From: report at bugs.python.org (Donald Stufft) Date: Thu, 02 Jan 2014 10:35:23 +0000 Subject: [issue20107] Revert PEP 453 integration In-Reply-To: <1388658143.96.0.201779546814.issue20107@psf.upfronthosting.co.za> Message-ID: <1388658923.4.0.394985034158.issue20107@psf.upfronthosting.co.za> Donald Stufft added the comment: I'll have it released today, there are no known issues with the last rc of pip. I just didn't want to release the fix to the distlib issue without a day or two of an RC (which we've now had) and the folks who reported the issue verifying it fixed for them (which they've now done). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 11:41:30 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 02 Jan 2014 10:41:30 +0000 Subject: [issue20107] Revert PEP 453 integration In-Reply-To: <1388658143.96.0.201779546814.issue20107@psf.upfronthosting.co.za> Message-ID: <1388659290.63.0.127593234644.issue20107@psf.upfronthosting.co.za> Martin v. L?wis added the comment: But it's not in git, AFAICT, https://github.com/pypa/pip/blob/1.5.X/pip/__init__.py still has "1.5rc4" in 93820f5e37, and pypi.python.org/pypi/pip still points to 1.4.1. So what do you mean by "released today"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 11:44:30 2014 From: report at bugs.python.org (Donald Stufft) Date: Thu, 02 Jan 2014 10:44:30 +0000 Subject: [issue20107] Revert PEP 453 integration In-Reply-To: <1388658143.96.0.201779546814.issue20107@psf.upfronthosting.co.za> Message-ID: <1388659470.25.0.352236927918.issue20107@psf.upfronthosting.co.za> Donald Stufft added the comment: It's not released yet, I'll have it (future tense) release today. It's roughly 6am here and I'm getting ready to get my daughter ready for school. I just happened to check my email before starting that. Once I get her on the bus I'll do the release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 11:45:41 2014 From: report at bugs.python.org (Tim Golden) Date: Thu, 02 Jan 2014 10:45:41 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1388418707.17.0.699182247009.issue18314@psf.upfronthosting.co.za> Message-ID: <52C54352.9030106@timgolden.me.uk> Tim Golden added the comment: I'll have a look at this in a week or so when I'm back on-line. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 11:47:21 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 02 Jan 2014 10:47:21 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za> Message-ID: <1388659641.14.0.380466546563.issue18314@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: test needed -> patch review versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 12:54:03 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jan 2014 11:54:03 +0000 Subject: [issue18829] csv produces confusing error message when passed a non-string delimiter In-Reply-To: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za> Message-ID: <3dw7223C3Rz7LjR@mail.python.org> Roundup Robot added the comment: New changeset 0daf7f02c97f by Victor Stinner in branch '3.3': Issue #18829: Add tests for the csv module for invalid characters (delimiter, http://hg.python.org/cpython/rev/0daf7f02c97f New changeset ccb52323039f by Victor Stinner in branch 'default': (Merge 3.3) Issue #18829: Add tests for the csv module for invalid characters http://hg.python.org/cpython/rev/ccb52323039f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 13:03:14 2014 From: report at bugs.python.org (Holger Waldmann) Date: Thu, 02 Jan 2014 12:03:14 +0000 Subject: [issue2943] Distutils should generate a better error message when the SDK is not installed In-Reply-To: <1211455981.94.0.404413935613.issue2943@psf.upfronthosting.co.za> Message-ID: <1388664194.34.0.965757573733.issue2943@psf.upfronthosting.co.za> Holger Waldmann added the comment: On Python 3.3.3 it is even worse. I am using Python 3.3.3 (32bit) on Windows 7 (64bit). Visual Studio C++ 2008 Express Edition is properly installed. Note: I use Python 32bit because Visual Studio C++ 2008 Express Edition includes only the 32bit compiler. Using Google I did find the instructions on http://stackoverflow.com/q/2817869/284795 But they were of no help. There are two problems that are not addressed. Problem #1: distutils/msvc9compiler.py decides to look for the 32bit registry key (because it is a 32bit Python) but it should look for the 64bit registry key (because it is a 64bit Windows). Problem #2: distutils/msvc9compiler.py decides to look for VERSION=10 I did some reverse engineering on the module to find this information. Why is this not documented? After setting VS100COMNTOOLS=%VS90COMNTOOLS% everything worked fine. ---------- nosy: +waldhol versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 13:41:30 2014 From: report at bugs.python.org (Jakub Wilk) Date: Thu, 02 Jan 2014 12:41:30 +0000 Subject: [issue19619] Blacklist base64, hex, ... codecs from bytes.decode() and str.encode() In-Reply-To: <1384562829.72.0.617857672471.issue19619@psf.upfronthosting.co.za> Message-ID: <1388666490.66.0.785071458028.issue19619@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 13:41:35 2014 From: report at bugs.python.org (Jakub Wilk) Date: Thu, 02 Jan 2014 12:41:35 +0000 Subject: [issue20093] Wrong OSError message from os.rename() when dst is a non-empty directory In-Reply-To: <1388278227.56.0.603151192526.issue20093@psf.upfronthosting.co.za> Message-ID: <1388666495.62.0.390377083275.issue20093@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 13:41:40 2014 From: report at bugs.python.org (Jakub Wilk) Date: Thu, 02 Jan 2014 12:41:40 +0000 Subject: [issue20050] distutils should check PyPI certs when connecting to it In-Reply-To: <1387673525.81.0.630232623355.issue20050@psf.upfronthosting.co.za> Message-ID: <1388666500.27.0.988405108999.issue20050@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 13:42:36 2014 From: report at bugs.python.org (Jakub Wilk) Date: Thu, 02 Jan 2014 12:42:36 +0000 Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ... In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za> Message-ID: <1388666556.08.0.0441278914159.issue7475@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 14:12:57 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jan 2014 13:12:57 +0000 Subject: [issue19728] PEP 453: enable pip by default in the Windows binary installers In-Reply-To: <1385171243.96.0.0357035720605.issue19728@psf.upfronthosting.co.za> Message-ID: <3dw8n44k8hz7LjR@mail.python.org> Roundup Robot added the comment: New changeset 4c7b3e7fd4ca by Martin v. L?wis in branch 'default': Issue #19728: Enable pip installation by default on Windows. http://hg.python.org/cpython/rev/4c7b3e7fd4ca ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 14:13:35 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 02 Jan 2014 13:13:35 +0000 Subject: [issue19728] PEP 453: enable pip by default in the Windows binary installers In-Reply-To: <1385171243.96.0.0357035720605.issue19728@psf.upfronthosting.co.za> Message-ID: <1388668415.31.0.387253426751.issue19728@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The command works fine; I have now integrated it into the installer. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 14:20:07 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 02 Jan 2014 13:20:07 +0000 Subject: [issue20101] Determine correct behavior for time functions on Windows In-Reply-To: <1388526152.52.0.960629914987.issue20101@psf.upfronthosting.co.za> Message-ID: <1388668807.04.0.330193820935.issue20101@psf.upfronthosting.co.za> Martin v. L?wis added the comment: As a further datapoint, it would be good to find out whether any of you has NTP enabled, and if so, against what time server. To find out, open the clock settings ("Datums- und Uhrzeiteinstellungen ?ndern"), and go to NTP tab ("Internetzeit"). ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 14:21:33 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 02 Jan 2014 13:21:33 +0000 Subject: [issue20000] SSLContext.get_ca_certs() and self-signed certs In-Reply-To: <1387220030.99.0.0276464783547.issue20000@psf.upfronthosting.co.za> Message-ID: <1388668893.56.0.44609402555.issue20000@psf.upfronthosting.co.za> Martin v. L?wis added the comment: BTW, congrats to issue 20,000. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 14:34:00 2014 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 02 Jan 2014 13:34:00 +0000 Subject: [issue19744] test_venv fails if SSL/TLS is not available In-Reply-To: <1385257125.97.0.543842843872.issue19744@psf.upfronthosting.co.za> Message-ID: <1388669640.21.0.459181631987.issue19744@psf.upfronthosting.co.za> Nick Coghlan added the comment: This should be fixed, so I don't think it's a release blocker any more, but I also don't want to close it until Tim confirms it also works for him. ---------- priority: release blocker -> deferred blocker status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 15:01:59 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Jan 2014 14:01:59 +0000 Subject: [issue20101] Determine correct behavior for time functions on Windows In-Reply-To: <1388526152.52.0.960629914987.issue20101@psf.upfronthosting.co.za> Message-ID: <1388671319.54.0.829393021933.issue20101@psf.upfronthosting.co.za> STINNER Victor added the comment: time.get_clock_info("time") and time.get_clock_info("monotonic") is currently using GetSystemTimeAdjustment(). In msg206886 it was said that "GetSystemTimeAdjustment is not the function to look at." Should we modify this function to use NtQueryTimerResolution() instead? TimeAdjustmentDisabled argument of GetSystemTimeAdjustment() is current ignored. Is it a bug? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 15:44:02 2014 From: report at bugs.python.org (Donald Stufft) Date: Thu, 02 Jan 2014 14:44:02 +0000 Subject: [issue20107] Revert PEP 453 integration In-Reply-To: <1388658143.96.0.201779546814.issue20107@psf.upfronthosting.co.za> Message-ID: <1388673842.13.0.718065917258.issue20107@psf.upfronthosting.co.za> Donald Stufft added the comment: pip 1.5 is released and CPython has been updated. ---------- assignee: -> dstufft resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 15:54:41 2014 From: report at bugs.python.org (Zachary Ware) Date: Thu, 02 Jan 2014 14:54:41 +0000 Subject: [issue20101] Determine correct behavior for time functions on Windows In-Reply-To: <1388668807.04.0.330193820935.issue20101@psf.upfronthosting.co.za> Message-ID: Zachary Ware added the comment: Martin v. L?wis wrote: > As a further datapoint, it would be good to find out whether any of you has NTP enabled, and if so, against what time server. To find out, open the clock settings ("Datums- und Uhrzeiteinstellungen ?ndern"), and go to NTP tab ("Internetzeit"). My 32-bit box is on a domain, and thus I can't access that tab. However, according to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DateTime\Servers (see [1]) it looks to me like NTP is enabled, with 5 servers listed: time.windows.com followed by 4 different time*.nist.gov servers. I expect the 64-bit box to be checking time.windows.com; if I find anything different when I get a chance to look at it, I'll report my findings. [1] http://superuser.com/questions/161759/where-do-i-find-the-internet-time-ntp-settings-in-windows-7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 16:03:25 2014 From: report at bugs.python.org (Zachary Ware) Date: Thu, 02 Jan 2014 15:03:25 +0000 Subject: [issue19143] Finding the Windows version getting messier In-Reply-To: <1380675004.25.0.239416620624.issue19143@psf.upfronthosting.co.za> Message-ID: <1388675005.54.0.0440935257735.issue19143@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 16:12:13 2014 From: report at bugs.python.org (Zachary Ware) Date: Thu, 02 Jan 2014 15:12:13 +0000 Subject: [issue18604] Consolidate gui available checks in test.support In-Reply-To: <1375229615.82.0.560303267268.issue18604@psf.upfronthosting.co.za> Message-ID: <1388675533.25.0.751520300282.issue18604@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 16:43:31 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jan 2014 15:43:31 +0000 Subject: [issue20101] Determine correct behavior for time functions on Windows In-Reply-To: <1388526152.52.0.960629914987.issue20101@psf.upfronthosting.co.za> Message-ID: <3dwD6p1rgqz7LjS@mail.python.org> Roundup Robot added the comment: New changeset 82df66a091da by Zachary Ware in branch '3.3': Issue #20101: Allow test_monotonic to pass on Windows machines on which http://hg.python.org/cpython/rev/82df66a091da New changeset e2a1400b7db9 by Zachary Ware in branch 'default': Issue #20101: Merge with 3.3 http://hg.python.org/cpython/rev/e2a1400b7db9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 17:38:06 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 02 Jan 2014 16:38:06 +0000 Subject: [issue16113] SHA-3 (Keccak) support may need to be removed before 3.4 In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za> Message-ID: <1388680686.18.0.479132451733.issue16113@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'm going to remove sha3 from the trunk tomorrow unless I hear otherwise. Python shouldn't implement something called "sha3" until SHA-3 actually is a standard. According to the current NIST timeline, the comment period on the draft FIPS should have ended by now, but AFAICT, the draft FIPS that starts the 90 day comment period hasn't even been published yet. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 17:40:21 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Jan 2014 16:40:21 +0000 Subject: [issue16113] SHA-3 (Keccak) support may need to be removed before 3.4 In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za> Message-ID: <1388680821.72.0.381320362024.issue16113@psf.upfronthosting.co.za> STINNER Victor added the comment: Will it be possible/easy to maintain a sha3 module on PyPI? It would be nice to have to for Python 2.6-3.4. @Christian: Are you interested to do that? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 17:44:00 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 02 Jan 2014 16:44:00 +0000 Subject: [issue16113] SHA-3 (Keccak) support may need to be removed before 3.4 In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za> Message-ID: <1388681040.51.0.311676300029.issue16113@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Either that, or we call it something else than "sha3"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 17:44:07 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 02 Jan 2014 16:44:07 +0000 Subject: [issue17997] ssl.match_hostname(): sub string wildcard should not match IDNA prefix In-Reply-To: <1368799493.86.0.504478450601.issue17997@psf.upfronthosting.co.za> Message-ID: <1388681047.5.0.152343645004.issue17997@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Just to clarify the status of this issue: it *only* blocks 3.2. ---------- priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 17:47:45 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 02 Jan 2014 16:47:45 +0000 Subject: [issue19749] test_venv failure on AIX: 'module' object has no attribute 'O_NOFOLLOW' In-Reply-To: <1385296830.18.0.279935527114.issue19749@psf.upfronthosting.co.za> Message-ID: <1388681265.88.0.345402212133.issue19749@psf.upfronthosting.co.za> Martin v. L?wis added the comment: test_venv now passes on that buildbot, apparently since PIP 1.5 has fixed the issue, and is now bundled with Python. ---------- nosy: +loewis resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 17:52:11 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 02 Jan 2014 16:52:11 +0000 Subject: [issue19347] PEP 453 implementation tracking issue In-Reply-To: <1382442514.8.0.354499850572.issue19347@psf.upfronthosting.co.za> Message-ID: <1388681531.52.0.355386831515.issue19347@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I propose to downgrade this from "release blocker" again. "prefer to have everything we can sorted" is IMO not a sufficient rationale to block the release; if taken literally, 3.4 could never ever release since it doesn't have everything sorted out that I would personally want to sort out some time in Python. If individual subissues should block the release, the should be promoted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 17:54:53 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 02 Jan 2014 16:54:53 +0000 Subject: [issue19407] PEP 453: update the "Installing Python Modules" documentation In-Reply-To: <1382791475.83.0.387983167617.issue19407@psf.upfronthosting.co.za> Message-ID: <1388681693.82.0.451643860825.issue19407@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I suggest that a documentation issue cannot be a release blocker. Most people read the documentation online, and will read an update once it is available. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 17:56:38 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 02 Jan 2014 16:56:38 +0000 Subject: [issue16043] xmlrpc: gzip_decode has unlimited read() In-Reply-To: <1348570326.9.0.587983624118.issue16043@psf.upfronthosting.co.za> Message-ID: <1388681798.83.0.0103024090748.issue16043@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Demoting this from release blocker: apparently, the release-blocking property was only intended for 2.6.9, which has been released. ---------- nosy: +loewis priority: release blocker -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 18:29:15 2014 From: report at bugs.python.org (Joost van Zwieten) Date: Thu, 02 Jan 2014 17:29:15 +0000 Subject: [issue20108] cannot pass kwarg `func` to `inspect.getcallargs` Message-ID: <1388683755.05.0.409989472701.issue20108@psf.upfronthosting.co.za> New submission from Joost van Zwieten: Consider the following example. import inspect inspect.getcallargs(lambda **kwargs: None, func=1) IMHO `getcallargs` should return {'kwargs': {'func': 1}} however, Python (versions 3.3 and 3.4) throws the following exception instead: TypeError: getcallargs() got multiple values for argument 'func' This can be easily solved in `lib/inspect.py` by changing def getcallargs(func, *positional, **named): into def getcallargs(*func_and_positional, **named): func, *positional = func_and_positional Best regards, Joost van Zwieten ---------- components: Library (Lib) messages: 207177 nosy: joostvanzwieten priority: normal severity: normal status: open title: cannot pass kwarg `func` to `inspect.getcallargs` type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 19:01:47 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Jan 2014 18:01:47 +0000 Subject: [issue20109] TestProgram is mentioned in the unittest docs but is not documented Message-ID: <1388685707.72.0.688331916968.issue20109@psf.upfronthosting.co.za> New submission from R. David Murray: IMO, TestProgram should either be made anonymous in the docs ('main returns an object that has a results attribute...') or its external API should be formally documented. If results is the only external API other than its init (which is documented as unittest.main), then I would suggest the former. In either case exactly what 'results' contains should be clarified. ---------- assignee: docs at python components: Documentation messages: 207178 nosy: docs at python, r.david.murray priority: normal severity: normal status: open title: TestProgram is mentioned in the unittest docs but is not documented versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 19:27:05 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jan 2014 18:27:05 +0000 Subject: [issue20108] cannot pass kwarg `func` to `inspect.getcallargs` In-Reply-To: <1388683755.05.0.409989472701.issue20108@psf.upfronthosting.co.za> Message-ID: <3dwHlX49r1z7Lk2@mail.python.org> Roundup Robot added the comment: New changeset b0d472e3ff42 by Benjamin Peterson in branch '3.3': avoid parameter name clash (closes #20108) http://hg.python.org/cpython/rev/b0d472e3ff42 New changeset c265675cd8e2 by Benjamin Peterson in branch 'default': merge 3.3 (closes #20108) http://hg.python.org/cpython/rev/c265675cd8e2 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 19:44:50 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jan 2014 18:44:50 +0000 Subject: [issue17282] document the defaultTest parameter to unittest.main() In-Reply-To: <1361664894.83.0.085559336561.issue17282@psf.upfronthosting.co.za> Message-ID: <3dwJ8128J5z7LjS@mail.python.org> Roundup Robot added the comment: New changeset 045e7a587f3c by R David Murray in branch '3.3': #17282: Document unittest.main defaultTest argument. http://hg.python.org/cpython/rev/045e7a587f3c New changeset 69b5f6924553 by R David Murray in branch '2.7': #17282: Document unittest.main defaultTest argument. http://hg.python.org/cpython/rev/69b5f6924553 New changeset 1bbf8c263d3c by R David Murray in branch 'default': Merge and update #17282: Document unittest.main defaultTest argument. http://hg.python.org/cpython/rev/1bbf8c263d3c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 19:44:50 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jan 2014 18:44:50 +0000 Subject: [issue15132] Let unittest.TestProgram()'s defaultTest argument be a list In-Reply-To: <1340353530.68.0.240528814016.issue15132@psf.upfronthosting.co.za> Message-ID: <3dwJ820TvXz7LjY@mail.python.org> Roundup Robot added the comment: New changeset 1bbf8c263d3c by R David Murray in branch 'default': Merge and update #17282: Document unittest.main defaultTest argument. http://hg.python.org/cpython/rev/1bbf8c263d3c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 19:46:34 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Jan 2014 18:46:34 +0000 Subject: [issue17282] document the defaultTest parameter to unittest.main() In-Reply-To: <1361664894.83.0.085559336561.issue17282@psf.upfronthosting.co.za> Message-ID: <1388688394.69.0.574396708464.issue17282@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks Kyle. I reworded it a bit to clarify the precedence of argv over defaultTest. (Also FYI your patch had stray spaces at the ends of the lines.) ---------- nosy: +r.david.murray resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 20:41:53 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Thu, 02 Jan 2014 19:41:53 +0000 Subject: [issue20110] Misleading word used for __annotations__ Message-ID: <1388691713.84.0.436758245185.issue20110@psf.upfronthosting.co.za> New submission from Claudiu.Popa: The documentation for `__annotations__` specify that the dict contains the parameter names ``or`` the return, but this is misleading, because `return` exists even if the parameter keys are present. ---------- assignee: docs at python components: Documentation files: doc_annotation.patch keywords: patch messages: 207183 nosy: Claudiu.Popa, docs at python priority: normal severity: normal status: open title: Misleading word used for __annotations__ versions: Python 3.4 Added file: http://bugs.python.org/file33297/doc_annotation.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 21:17:04 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 02 Jan 2014 20:17:04 +0000 Subject: [issue16113] SHA-3 (Keccak) support may need to be removed before 3.4 In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za> Message-ID: <1388693824.6.0.555212852286.issue16113@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I would not bother pulling this out until the week before RC1 if the standard has not yet been declared final. Otherwise, -1 on keeping it under another name. The only hashes we bundle should be standard ones as those are the only ones people will want to use in the long run. We'd be saddled with carrying along a non-standard likely not widely used algorithm implementation forever otherwise. even if sha3 isn't declared before 3.4rc1, people building 3.4 against a sufficiently modern version of openssl that includes sha3 (as i'm sure some version will) will still have access to the algorithm. otherwise i'm sure someone will package this as a module on pypi for older pythons regardless. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 21:29:00 2014 From: report at bugs.python.org (July Tikhonov) Date: Thu, 02 Jan 2014 20:29:00 +0000 Subject: [issue20111] pathlib.PurePath.with_suffix() allows creation of otherwise impossible paths Message-ID: <1388694540.82.0.701601871731.issue20111@psf.upfronthosting.co.za> New submission from July Tikhonov: This is not a real-world example, but it brokes some invariant (part of path must not contain separator): >>> pathlib.PurePath('/a/b.c.d').with_suffix('///') PurePosixPath('/a/b.c///') >>> pathlib.PurePath('/a/b.c.d').with_suffix('/not/split/into/parts').parts ('/', 'a', 'b.c/not/split/into/parts') I think these cases should raise an error. I would also like to consider the following to be an error, since the argument of with_suffix() is not exactly a suffix: >>> PurePath('/a/b.c.d').with_suffix('e') PurePosixPath('/a/b.ce') but I'm far less sure in this case. ---------- components: Library (Lib) messages: 207185 nosy: july, pitrou priority: normal severity: normal status: open title: pathlib.PurePath.with_suffix() allows creation of otherwise impossible paths versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 21:30:09 2014 From: report at bugs.python.org (Tim Peters) Date: Thu, 02 Jan 2014 20:30:09 +0000 Subject: [issue20101] Determine correct behavior for time functions on Windows In-Reply-To: <1388526152.52.0.960629914987.issue20101@psf.upfronthosting.co.za> Message-ID: <1388694609.46.0.422907114315.issue20101@psf.upfronthosting.co.za> Tim Peters added the comment: 1. I'm sync'ing with north-america.pool.ntp.org. But the docs on my box say "Your clock is typically updated once a week", and I believe it. 2. I just ran Zach's program again, with the same Python, and _this_ time 'time' passed 25 times (as did 'monotonic'). 'time' failed 25 times in the output I pasted here before. 'clock' failed 25 times again. Here are the passing values for this run of 'time': [(0.5001208782196045, 4), (0.5001211166381836, 6), (0.5001218318939209, 5), (0.5001220703125, 10)] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 21:33:27 2014 From: report at bugs.python.org (July Tikhonov) Date: Thu, 02 Jan 2014 20:33:27 +0000 Subject: [issue20111] pathlib.PurePath.with_suffix() allows creation of otherwise impossible paths In-Reply-To: <1388694540.82.0.701601871731.issue20111@psf.upfronthosting.co.za> Message-ID: <1388694807.22.0.788321804941.issue20111@psf.upfronthosting.co.za> Changes by July Tikhonov : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 21:52:23 2014 From: report at bugs.python.org (Christian Heimes) Date: Thu, 02 Jan 2014 20:52:23 +0000 Subject: [issue16113] SHA-3 (Keccak) support may need to be removed before 3.4 In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za> Message-ID: <1388695943.76.0.64072773091.issue16113@psf.upfronthosting.co.za> Christian Heimes added the comment: I have created a backport of the sha3 for Python 2.6 to 3.3 about an year ago. It's on PyPI: https://pypi.python.org/pypi/pysha3 . I'm planing to update the code with SHAKE256 and SHAKE512 support soonish, too. I have very high confidence that NIST is neither going to change the parameters or padding for SHA3 nor is NIST going to deviate from the original Keccak proposal. In case you still prefer to remove SHA3 I suggest that we stick to GPS' plan and wait until RC1. The attached patch removes all code and documentation for SHA3. ---------- Added file: http://bugs.python.org/file33298/remove_sha3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 21:54:13 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Jan 2014 20:54:13 +0000 Subject: [issue20111] pathlib.PurePath.with_suffix() allows creation of otherwise impossible paths In-Reply-To: <1388694540.82.0.701601871731.issue20111@psf.upfronthosting.co.za> Message-ID: <1388696053.87.0.598659715184.issue20111@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 22:13:34 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 02 Jan 2014 21:13:34 +0000 Subject: [issue16113] SHA-3 (Keccak) support may need to be removed before 3.4 In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za> Message-ID: <1388697214.96.0.264637865157.issue16113@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Ok, this this remains a release blocker. I'm still +1 for removing it, and I'm -0 for removing it just before the release candidate. AFAICT, there is *zero* (.000000001) chance that it actually becomes a NIST standard before the Python release is made. According to the current timeline: http://csrc.nist.gov/groups/ST/hash/sha-3/timeline_fips.html the *submission to the secretary* (of commerce) was scheduled for Q2. With the current delay, this must become Q3, so the publication as a standard might happen in Q4 (not sure how long the Secretary of Commerce needs to study the specification of a hash algorithm). What might happen is that a draft is published by the time the RC is made. I'd then still be -1 on including something in Python that only implements a draft standard. So we could just as well remove it right away. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 22:16:03 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 02 Jan 2014 21:16:03 +0000 Subject: [issue16113] SHA-3 (Keccak) support may need to be removed before 3.4 In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za> Message-ID: <1388697363.86.0.420508804858.issue16113@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I agree with Martin that it should be removed right now. It's not really reasonable to call something SHA-3 if it's not SHA-3, even in beta versions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 22:26:49 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 02 Jan 2014 21:26:49 +0000 Subject: [issue17997] ssl.match_hostname(): sub string wildcard should not match IDNA prefix In-Reply-To: <1368799493.86.0.504478450601.issue17997@psf.upfronthosting.co.za> Message-ID: <1388698009.8.0.562634658913.issue17997@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 22:46:43 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Jan 2014 21:46:43 +0000 Subject: [issue16113] SHA-3 (Keccak) support may need to be removed before 3.4 In-Reply-To: <1388697363.86.0.420508804858.issue16113@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: OpenSSL doesn't implement SHA-3 yet, it's strange to have SHA-3 in Python but not in OpenSSL. If the standard is still a draft, I agree to remove the code right now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 22:52:53 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 02 Jan 2014 21:52:53 +0000 Subject: [issue16113] SHA-3 (Keccak) support may need to be removed before 3.4 In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za> Message-ID: <1388699573.16.0.984484302038.issue16113@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Given the likely delay in the standard Martin cites, I've change my mind: agreed. Go ahead and remove it for 3.4. We'll have an official sha3 in Python 3.5. Early adopters can live with PyPI. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 23:07:35 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 02 Jan 2014 22:07:35 +0000 Subject: [issue16113] SHA-3 (Keccak) support may need to be removed before 3.4 In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za> Message-ID: <1388700455.26.0.471829717447.issue16113@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I just looked at the hash-forum archives (*) http://cio.nist.gov/esd/emaildir/lists/hash-forum/msg02809.html which says that they plan to publish the draft "soon after Christmas". They also indicate how the padding open issue might get resolved (append 1111 for SHAKE, 1101 for the SHA-2 drop-ins). Not sure whether this is what Christian has already implemented. (*) See http://crypto.stackexchange.com/questions/10645/are-nists-changes-to-keccak-sha-3-problematic for the password ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 23:19:04 2014 From: report at bugs.python.org (Zachary Ware) Date: Thu, 02 Jan 2014 22:19:04 +0000 Subject: [issue20101] Determine correct behavior for time functions on Windows In-Reply-To: <1388526152.52.0.960629914987.issue20101@psf.upfronthosting.co.za> Message-ID: <1388701144.52.0.640869079835.issue20101@psf.upfronthosting.co.za> Zachary Ware added the comment: I ran the same test on all of the Windows buildbots, with the following results: x86 XP-4: http://buildbot.python.org/all/builders/x86%20XP-4%20custom/builds/33/steps/test/logs/stdio monotonic: good time: good clock/perf_counter: 10 failures x86 Windows7 http://buildbot.python.org/all/builders/x86%20Windows7%20custom/builds/37/steps/test/logs/stdio monotonic: good time: 24 failures clock/perf_counter: 11 failures AMD64 Windows7 SP1 http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%20custom/builds/41/steps/test/logs/stdio All good x86 Windows Server 2003 http://buildbot.python.org/all/builders/x86%20Windows%20Server%202003%20%5BSB%5D%20custom/builds/33/steps/test/logs/stdio monotonic: good time: good clock/perf_counter: all failures AMD64 Windows Server 2008R2 http://buildbot.python.org/all/builders/AMD64%20Windows%20Server%202008%20%5BSB%5D%20custom/builds/17/steps/test/logs/stdio All good x86 Windows Server 2008R2 http://buildbot.python.org/all/builders/x86%20Windows%20Server%202008%20%5BSB%5D%20custom/builds/0/steps/test/logs/stdio All good Also, I noticed three different resolutions for monotonic: mine, Tim's, and 0.0100144 on the XP-4 bot. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 23:32:32 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Jan 2014 22:32:32 +0000 Subject: [issue20112] The documentation for http.server error_message_format is inadequate. Message-ID: <1388701952.2.0.132957137739.issue20112@psf.upfronthosting.co.za> New submission from R. David Murray: The description of error_message_format does not give enough information to use it. The description should talk about how it is used (ie: using % formatting) and the fact that when filled in it should form a complete html document because it will be sent as the error response body. It should not talk about what "the code key should be", etc, but should instead say what they *will* be, and cross reference the send_error method as the thing that uses it. ---------- assignee: docs at python components: Documentation messages: 207194 nosy: docs at python, r.david.murray priority: normal severity: normal stage: needs patch status: open title: The documentation for http.server error_message_format is inadequate. type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 23:48:38 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jan 2014 22:48:38 +0000 Subject: [issue20110] Misleading word used for __annotations__ In-Reply-To: <1388691713.84.0.436758245185.issue20110@psf.upfronthosting.co.za> Message-ID: <3dwPYL0z4xz7LjN@mail.python.org> Roundup Robot added the comment: New changeset 203ca77ea819 by Benjamin Peterson in branch '3.3': correct word for __annotations__ doc (closes #20110) http://hg.python.org/cpython/rev/203ca77ea819 New changeset 3e75f649e93b by Benjamin Peterson in branch 'default': merge 3.3 (#20110) http://hg.python.org/cpython/rev/3e75f649e93b ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 2 23:52:39 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 02 Jan 2014 22:52:39 +0000 Subject: [issue20111] pathlib.PurePath.with_suffix() allows creation of otherwise impossible paths In-Reply-To: <1388694540.82.0.701601871731.issue20111@psf.upfronthosting.co.za> Message-ID: <1388703159.16.0.609149065684.issue20111@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thank you for reporting this! You're right, this is a bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 00:07:36 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jan 2014 23:07:36 +0000 Subject: [issue20111] pathlib.PurePath.with_suffix() allows creation of otherwise impossible paths In-Reply-To: <1388694540.82.0.701601871731.issue20111@psf.upfronthosting.co.za> Message-ID: <3dwPzD0SDjz7LjS@mail.python.org> Roundup Robot added the comment: New changeset ef2b2ddd27c8 by Antoine Pitrou in branch 'default': Issue #20111: pathlib.Path.with_suffix() now sanity checks the given suffix. http://hg.python.org/cpython/rev/ef2b2ddd27c8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 00:08:25 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 02 Jan 2014 23:08:25 +0000 Subject: [issue20111] pathlib.PurePath.with_suffix() allows creation of otherwise impossible paths In-Reply-To: <1388694540.82.0.701601871731.issue20111@psf.upfronthosting.co.za> Message-ID: <1388704105.93.0.13555469491.issue20111@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I've committed a fix: ValueError is now raised for invalid suffixes. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 03:15:56 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Jan 2014 02:15:56 +0000 Subject: [issue20097] Bad use of `self` in importlib In-Reply-To: <1388435202.0.0.988564041108.issue20097@psf.upfronthosting.co.za> Message-ID: <1388715356.68.0.944308743539.issue20097@psf.upfronthosting.co.za> STINNER Victor added the comment: Would it be possible to put @unittest.skipUnless(...) on WindowsRegistryFinderTests instead of duplicating it? Except of this nit, the patch looks good to me. Note: WindowsRegistryFinder.find_spec() contains the comment: # XXX untested! Need a Windows person to write tests (otherwise mock out appropriately) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 03:17:00 2014 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 03 Jan 2014 02:17:00 +0000 Subject: [issue19347] PEP 453 implementation tracking issue In-Reply-To: <1388681531.52.0.355386831515.issue19347@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: Agreed, it was mostly to ensure we reviewed the status to make sure we were happy with progress. The only remaining "must fix" item is the docs update, and that's shouldn't block beta 2 (although I'll still try to get at least an initial version done now that pip 1.5 is released). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 03:19:56 2014 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 03 Jan 2014 02:19:56 +0000 Subject: [issue19407] PEP 453: update the "Installing Python Modules" documentation In-Reply-To: <1388681693.82.0.451643860825.issue19407@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: Agreed, this was set to ensure Larry followed up with a "Please explain" if I didn't get it done in a timely manner. I'll still try to get it done for the beta, but I still have linux.conf.aupreparation to do, so it may slip to the first RC. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 03:20:13 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Jan 2014 02:20:13 +0000 Subject: [issue1346238] A constant folding optimization pass for the AST Message-ID: <1388715613.63.0.965128750458.issue1346238@psf.upfronthosting.co.za> STINNER Victor added the comment: My astoptimizer project has an experimental support of constant folding. It works in the same file, or constants can be propagated to other files using config.add_constant('NAME', value). https://bitbucket.org/haypo/astoptimizer/ ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 03:21:17 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 03 Jan 2014 02:21:17 +0000 Subject: [issue19347] PEP 453 implementation tracking issue In-Reply-To: <1382442514.8.0.354499850572.issue19347@psf.upfronthosting.co.za> Message-ID: <1388715677.46.0.459230371576.issue19347@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 05:20:48 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jan 2014 04:20:48 +0000 Subject: [issue18585] Add a text truncation function In-Reply-To: <1375102150.65.0.445691594018.issue18585@psf.upfronthosting.co.za> Message-ID: <3dwXwb6WV6z7LkN@mail.python.org> Roundup Robot added the comment: New changeset 536a2cf5f1d2 by Daniel Holth in branch 'default': Issue #18585: speed zipfile import by only generating zipfile._ZipDecryptor on demand http://hg.python.org/cpython/rev/536a2cf5f1d2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 05:22:26 2014 From: report at bugs.python.org (Daniel Holth) Date: Fri, 03 Jan 2014 04:22:26 +0000 Subject: [issue18585] Add a text truncation function In-Reply-To: <1375102150.65.0.445691594018.issue18585@psf.upfronthosting.co.za> Message-ID: <1388722946.8.0.0516584945992.issue18585@psf.upfronthosting.co.za> Daniel Holth added the comment: Previous changeset was meant for #18515 ---------- nosy: +dholth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 06:15:20 2014 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 03 Jan 2014 05:15:20 +0000 Subject: [issue19407] PEP 453: update the "Installing Python Modules" documentation In-Reply-To: <1382791475.83.0.387983167617.issue19407@psf.upfronthosting.co.za> Message-ID: <1388726120.98.0.17199389087.issue19407@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 06:20:09 2014 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 03 Jan 2014 05:20:09 +0000 Subject: [issue19347] PEP 453 implementation tracking issue In-Reply-To: <1382442514.8.0.354499850572.issue19347@psf.upfronthosting.co.za> Message-ID: <1388726409.3.0.454841384035.issue19347@psf.upfronthosting.co.za> Nick Coghlan added the comment: Actually, with the docs update being the only remaining "this really should be done before 3.4 is released" issue related to PEP 453, I think this tracking issue has now served its purpose. So, closing this umbrella issue now, since issue 19407 covers the docs update. Thanks again to everyone that contributed the various bits and pieces needed to make the PEP a reality :) ---------- dependencies: -PEP 453: update the "Installing Python Modules" documentation resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 06:32:00 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jan 2014 05:32:00 +0000 Subject: [issue20097] Bad use of `self` in importlib In-Reply-To: <1388435202.0.0.988564041108.issue20097@psf.upfronthosting.co.za> Message-ID: <3dwZV86J8bz7Ljv@mail.python.org> Roundup Robot added the comment: New changeset 7dbb4c6cd30e by Eric Snow in branch 'default': Issue #20097: Fix bad use of "self" in importlib's WindowsRegistryFinder. http://hg.python.org/cpython/rev/7dbb4c6cd30e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 06:39:24 2014 From: report at bugs.python.org (Eric Snow) Date: Fri, 03 Jan 2014 05:39:24 +0000 Subject: [issue20097] Bad use of `self` in importlib In-Reply-To: <1388435202.0.0.988564041108.issue20097@psf.upfronthosting.co.za> Message-ID: <1388727564.56.0.710629931244.issue20097@psf.upfronthosting.co.za> Eric Snow added the comment: Thanks for the review, Victor. As to that note, it is the subject of issue #19714. ---------- assignee: brett.cannon -> eric.snow dependencies: -Add tests for importlib.machinery.WindowsRegistryFinder resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 06:42:39 2014 From: report at bugs.python.org (Eric Snow) Date: Fri, 03 Jan 2014 05:42:39 +0000 Subject: [issue19714] Add tests for importlib.machinery.WindowsRegistryFinder In-Reply-To: <1385139731.13.0.379714643713.issue19714@psf.upfronthosting.co.za> Message-ID: <1388727759.23.0.513059201739.issue19714@psf.upfronthosting.co.za> Eric Snow added the comment: I added 2 rudimentary tests for issue #20097 which gives at least coverage in the test suite, but we need the following tests still: * registry entry exists and module is found (spec returned) * registry entry exists and module is not found (None returned) Depending on what time I have I may take a stab at this using test_winreg as an example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 07:13:54 2014 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 03 Jan 2014 06:13:54 +0000 Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and sys.stdout on UNIX for the C locale In-Reply-To: <1386952820.2.0.77364136667.issue19977@psf.upfronthosting.co.za> Message-ID: <1388729634.1.0.0196609438794.issue19977@psf.upfronthosting.co.za> Nick Coghlan added the comment: Larry: I'm assuming it's way too late to make a change like this for the 3.4 release? Slavek: assuming this change is made for 3.5 upstream, we may want to look at backporting it as a 3.4 patch in Fedora (as part of the Python-3-by-default project). Otherwise it's very easy to provoke Python 3 into throwing Unicode errors when attempting to print data provided by the OS. ---------- nosy: +bkabrda, larry type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 07:31:15 2014 From: report at bugs.python.org (Eric Snow) Date: Fri, 03 Jan 2014 06:31:15 +0000 Subject: [issue19944] Make importlib.find_spec load packages as needed In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za> Message-ID: <1388730675.3.0.35568723906.issue19944@psf.upfronthosting.co.za> Eric Snow added the comment: Good points, Nick. I was trying to limit touches on _bootstrap.py for 3.4, but that "simple" patch is mostly just a hacky band-aid. Here's a patch that hopefully stands on its own and still limits touches. (The patch is the bare-bones changes only.) There are 2 things in particular with this patch that I'd like to be sure others are comfortable with: * an import statement (for resolve_name) inside find_spec() * the use of builtins.__import__() instead of importlib.import_module() Regarding the "nested" import, I didn't want to import the submodule at the top level due to possible future circular imports (there aren't any now with importlib.util, but still...). At the same time, to me using something out of a submodule in the parent module in this way is a bit of a bad code smell. I'd be more inclined to move the resolve_name() implementation into _bootstrap.py to resolve it, but even better may be to move it to __init__.py as a private name and then import it into importlib.util. As it stands, the patch simply uses the "nested" import. As to using builtins.__import__() when importing the parent module, that seems like it would result in less surprising results in the (uncommon) case that someone is using a custom __import__() that would yield a different result than importlib.import_module(). In the case of find_spec() that makes more sense to me. ---------- Added file: http://bugs.python.org/file33299/issue19944-find-spec-mirror-import-module-direct.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 08:01:04 2014 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 03 Jan 2014 07:01:04 +0000 Subject: [issue19944] Make importlib.find_spec load packages as needed In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za> Message-ID: <1388732464.02.0.0564614328837.issue19944@psf.upfronthosting.co.za> Nick Coghlan added the comment: Actually, why *is* find_spec at package level, rather than in util with resolve_name? I know we said it was at package level in the PEP, but we never really gave the question serious thought. Also, why use builtins.__import__ rather than using __import__ directly? (A comment as to why you're using __import__ over import_module would also be good - I assume it's to get the automatic check for the __path__ attribute) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 08:59:56 2014 From: report at bugs.python.org (Eric Snow) Date: Fri, 03 Jan 2014 07:59:56 +0000 Subject: [issue19944] Make importlib.find_spec load packages as needed In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za> Message-ID: <1388735996.78.0.797647745609.issue19944@psf.upfronthosting.co.za> Eric Snow added the comment: find_spec() is at package level because find_module() is and for no other good reason I'm aware of. I'd be just fine with moving it to util. I don't expect it to be used enough to warrant that top-level placement. Regarding builtins.__import__(), I'm using it in the event that someone "installed" their own __import__() which gives a different result than import_module(). Thus the parent used by find_spec() will be the expected one. I agree that comment about this would be good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 09:17:10 2014 From: report at bugs.python.org (Eric Snow) Date: Fri, 03 Jan 2014 08:17:10 +0000 Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451 In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za> Message-ID: <1388737030.15.0.278991644652.issue19713@psf.upfronthosting.co.za> Eric Snow added the comment: Here's a patch that updates a couple files to not use find_module/load_module. These are the only changes like this (of consequence) outside pydoc, pkgutil, and importlib, which are covered by other tickets. ---------- Added file: http://bugs.python.org/file33300/issue19713-switch-to-new-api.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 09:19:15 2014 From: report at bugs.python.org (Eric Snow) Date: Fri, 03 Jan 2014 08:19:15 +0000 Subject: [issue19708] Check pkgutil for anything missing for PEP 451 Message-ID: <1388737155.79.0.00404454007765.issue19708@psf.upfronthosting.co.za> New submission from Eric Snow: Here's a patch that does the minimum of updating pkgutil and its tests to move away from find_module/load_module. I'm not sure there is much more to do than this. ---------- keywords: +patch Added file: http://bugs.python.org/file33301/issue19708-use-new-api.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 09:21:20 2014 From: report at bugs.python.org (Eric Snow) Date: Fri, 03 Jan 2014 08:21:20 +0000 Subject: [issue19703] Update pydoc to PEP 451 In-Reply-To: <1386308732.16.0.241139477522.issue19703@psf.upfronthosting.co.za> Message-ID: <1388737280.0.0.994471692444.issue19703@psf.upfronthosting.co.za> Eric Snow added the comment: Here's a patch that updates pydoc to move away from find_module/load_module. These 4 don't need to change for PEP 451: safeimport() HTMLDoc.docmodule() HTMLDoc.index() TextDoc.docmodule() ---------- keywords: +patch Added file: http://bugs.python.org/file33302/issue19703-use-new-api.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 09:29:56 2014 From: report at bugs.python.org (Eric Snow) Date: Fri, 03 Jan 2014 08:29:56 +0000 Subject: [issue19699] Update zipimport for PEP 451 In-Reply-To: <1385137762.02.0.629134883022.issue19699@psf.upfronthosting.co.za> Message-ID: <1388737796.84.0.741784809213.issue19699@psf.upfronthosting.co.za> Eric Snow added the comment: Could this wait for 3.5? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 11:47:59 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Jan 2014 10:47:59 +0000 Subject: [issue16039] imaplib: unlimited readline() from connection In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za> Message-ID: <1388746079.33.0.710689960278.issue16039@psf.upfronthosting.co.za> STINNER Victor added the comment: Why is this issue still open? The issue was fixed in Python 2.6.9. Why is the issue a release blocker? The issue was also fixed in the future Python 3.4 (in default). ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 11:59:26 2014 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 03 Jan 2014 10:59:26 +0000 Subject: [issue19699] Update zipimport for PEP 451 In-Reply-To: <1385137762.02.0.629134883022.issue19699@psf.upfronthosting.co.za> Message-ID: <1388746766.1.0.716700476026.issue19699@psf.upfronthosting.co.za> Nick Coghlan added the comment: I don't see any problem with postponing the zipimport updates until 3.5 (we won't be updating the extension module handling until then anyway, since that requires C API additions). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 12:19:28 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Jan 2014 11:19:28 +0000 Subject: [issue20113] os.readv() and os.writev() don't raise an OSError on readv()/writev() failure Message-ID: <1388747968.16.0.893473617326.issue20113@psf.upfronthosting.co.za> New submission from STINNER Victor: Example: $ python3 Python 3.3.2 (default, Nov 8 2013, 13:38:57) [GCC 4.8.2 20131017 (Red Hat 4.8.2-1)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.fstat(19) Traceback (most recent call last): File "", line 1, in OSError: [Errno 9] Bad file descriptor >>> buf=bytearray(10) >>> os.readv(19, [buf]) -1 I would expect an OSError on os.readv() instead of -1. Moreover, empty list of buffers are not handled correctly: $ python3 Python 3.3.2 (default, Nov 8 2013, 13:38:57) [GCC 4.8.2 20131017 (Red Hat 4.8.2-1)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.readv(0, []) Traceback (most recent call last): File "", line 1, in SystemError: error return without exception set Attached patch should fix both issues. ---------- messages: 207220 nosy: haypo priority: normal severity: normal status: open title: os.readv() and os.writev() don't raise an OSError on readv()/writev() failure versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 12:21:21 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Jan 2014 11:21:21 +0000 Subject: [issue20113] os.readv() and os.writev() don't raise an OSError on readv()/writev() failure In-Reply-To: <1388747968.16.0.893473617326.issue20113@psf.upfronthosting.co.za> Message-ID: <1388748081.74.0.226242115766.issue20113@psf.upfronthosting.co.za> STINNER Victor added the comment: os.readv() and os.writev() were added in Python 3.3 with the issue #10812. ---------- keywords: +patch nosy: +serhiy.storchaka Added file: http://bugs.python.org/file33303/readv_writev.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 12:27:16 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jan 2014 11:27:16 +0000 Subject: [issue18294] zlib module is not completly 64-bit safe In-Reply-To: <1372107882.97.0.731855490225.issue18294@psf.upfronthosting.co.za> Message-ID: <3dwkNg2h42z7Ljs@mail.python.org> Roundup Robot added the comment: New changeset 0cca6c5513d2 by Victor Stinner in branch 'default': Issue #18294: Fix uint_converter() in zlibmodule.c, fix the "> UINT_MAX" check http://hg.python.org/cpython/rev/0cca6c5513d2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 13:17:44 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Jan 2014 12:17:44 +0000 Subject: [issue20114] Sporadic failure of test_semaphore_tracker() of test_multiprocessing_forkserver on FreeBSD 9 buildbot Message-ID: <1388751464.62.0.0417954391884.issue20114@psf.upfronthosting.co.za> New submission from STINNER Victor: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%203.x/builds/6085/steps/test/logs/stdio ====================================================================== FAIL: test_semaphore_tracker (test.test_multiprocessing_forkserver.TestSemaphoreTracker) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/_test_multiprocessing.py", line 3661, in test_semaphore_tracker _multiprocessing.sem_unlink(name2) AssertionError: OSError not raised ---------- keywords: buildbot messages: 207223 nosy: haypo, sbt priority: normal severity: normal status: open title: Sporadic failure of test_semaphore_tracker() of test_multiprocessing_forkserver on FreeBSD 9 buildbot versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 13:24:41 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jan 2014 12:24:41 +0000 Subject: [issue16039] imaplib: unlimited readline() from connection In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za> Message-ID: <1388751881.53.0.551906900233.issue16039@psf.upfronthosting.co.za> R. David Murray added the comment: Presumably because it has not been fixed in 2.7. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 14:11:02 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jan 2014 13:11:02 +0000 Subject: [issue16113] SHA-3 (Keccak) support may need to be removed before 3.4 In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za> Message-ID: <3dwmhL5V1Mz7LjV@mail.python.org> Roundup Robot added the comment: New changeset 52350d325b41 by Martin v. L?wis in branch 'default': * Issue #16113: Remove sha3 module again. http://hg.python.org/cpython/rev/52350d325b41 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 14:13:21 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 03 Jan 2014 13:13:21 +0000 Subject: [issue16113] SHA-3 (Keccak) support may need to be removed before 3.4 In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za> Message-ID: <1388754801.4.0.16994696376.issue16113@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I have now removed the aha code. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 14:13:47 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Jan 2014 13:13:47 +0000 Subject: [issue16039] imaplib: unlimited readline() from connection In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za> Message-ID: <1388754827.94.0.0375024945087.issue16039@psf.upfronthosting.co.za> STINNER Victor added the comment: "Since the merge 2.6 -> 2.7 did not apply cleanly, and had other problems. I null merged the 2.6 changes. I'll leave it to Benjamin to work out whatever patches 2.7 needs." So Benjamin, is there a reason to not fix this security vulnerability in Python 2.7? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 14:14:41 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Jan 2014 13:14:41 +0000 Subject: [issue20113] os.readv() and os.writev() don't raise an OSError on readv()/writev() failure In-Reply-To: <1388747968.16.0.893473617326.issue20113@psf.upfronthosting.co.za> Message-ID: <1388754881.51.0.244347944444.issue20113@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +rosslagerwall _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 15:48:09 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Jan 2014 14:48:09 +0000 Subject: [issue16113] SHA-3 (Keccak) support may need to be removed before 3.4 In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za> Message-ID: <1388760489.31.0.287439977254.issue16113@psf.upfronthosting.co.za> STINNER Victor added the comment: @Martin: It looks like the _overlapped module is not more compiled on Windows. http://buildbot.python.org/all/builders/x86%20Windows%20Server%202008%20%5BSB%5D%203.x/builds/2032/steps/test/logs/stdio test test_asyncio crashed -- Traceback (most recent call last): File "E:\home\cpython\buildslave\x86\3.x.snakebite-win2k8r2sp1-x86\build\lib\asyncio\__init__.py", line 16, in from . import _overlapped ImportError: cannot import name '_overlapped' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "../lib/test/regrtest.py", line 1278, in runtest_inner test_runner() File "E:\home\cpython\buildslave\x86\3.x.snakebite-win2k8r2sp1-x86\build\lib\test\test_asyncio\__init__.py", line 31, in test_main run_unittest(suite()) File "E:\home\cpython\buildslave\x86\3.x.snakebite-win2k8r2sp1-x86\build\lib\test\test_asyncio\__init__.py", line 21, in suite __import__(mod_name) File "E:\home\cpython\buildslave\x86\3.x.snakebite-win2k8r2sp1-x86\build\lib\test\test_asyncio\test_base_events.py", line 11, in from asyncio import base_events File "E:\home\cpython\buildslave\x86\3.x.snakebite-win2k8r2sp1-x86\build\lib\asyncio\__init__.py", line 18, in import _overlapped # Will also be exported. ImportError: No module named '_overlapped' ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 15:54:24 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 03 Jan 2014 14:54:24 +0000 Subject: [issue16113] SHA-3 (Keccak) support may need to be removed before 3.4 In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za> Message-ID: <1388760864.15.0.0848650213975.issue16113@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Thanks for the report. Restored in 8a3718f31188 ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 16:27:18 2014 From: report at bugs.python.org (Boris FELD) Date: Fri, 03 Jan 2014 15:27:18 +0000 Subject: =?utf-8?q?=5Bissue13943=5D_distutils=E2=80=99_build=5Fpy_fails_when_packa?= =?utf-8?q?ge_string_is_unicode?= In-Reply-To: <1328388068.27.0.743003863578.issue13943@psf.upfronthosting.co.za> Message-ID: <1388762838.86.0.0528988812852.issue13943@psf.upfronthosting.co.za> Boris FELD added the comment: I've the same problem today with package https://pypi.python.org/pypi/httpretty/0.7.1 but only when I try to install one of my project which requires httpretty, if I try to install it directly it works like a charm. pip install httpretty -> works pip install mypkg -> doesn't works Looks like HTTPretty is using __file__ variable in setup.py (https://github.com/gabrielfalcao/HTTPretty/blob/master/setup.py#L35) and pip seems to pass the file as unicode: http://0bin.net/paste/dQfsSAmguWNYyY7w#0O/gcrWA44wKicfTdsGT4KqRYhbZLyhN9BUXNQD1XZA= At the last line: "__file__=u'/home/lothiraldan/.virtualenvs/test/build/httpretty/setup.py'" ---------- nosy: +Boris.FELD _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 16:58:42 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 03 Jan 2014 15:58:42 +0000 Subject: [issue19699] Update zipimport for PEP 451 In-Reply-To: <1385137762.02.0.629134883022.issue19699@psf.upfronthosting.co.za> Message-ID: <1388764722.73.0.0459455047021.issue19699@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 17:14:46 2014 From: report at bugs.python.org (Luca Faustin) Date: Fri, 03 Jan 2014 16:14:46 +0000 Subject: [issue19023] ctypes docs: Unimplemented and undocumented features In-Reply-To: <1379246270.23.0.998338553474.issue19023@psf.upfronthosting.co.za> Message-ID: <1388765686.8.0.409456561583.issue19023@psf.upfronthosting.co.za> Changes by Luca Faustin : ---------- nosy: +faustinl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 17:57:40 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 03 Jan 2014 16:57:40 +0000 Subject: [issue16039] imaplib: unlimited readline() from connection In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za> Message-ID: <1388768260.87.0.900729851338.issue16039@psf.upfronthosting.co.za> Benjamin Peterson added the comment: There's no reason not to fix it assuming the patch is good... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 18:59:13 2014 From: report at bugs.python.org (Armin Rigo) Date: Fri, 03 Jan 2014 17:59:13 +0000 Subject: [issue20115] NUL bytes in commented lines Message-ID: <1388771953.42.0.332804570753.issue20115@psf.upfronthosting.co.za> New submission from Armin Rigo: This is probably the smallest example of a .py file that behaves differently in CPython vs PyPy, and for once, I'd argue that the CPython behavior is unexpected: # make the file: >>> open('x.py', 'wb').write('#\x00\na') # run it: python x.py Expected: either some SyntaxError, or "NameError: global name 'a' is not defined". Got: nothing. It seems that CPython completely ignores the line that is immediately after a line with a '#' and a following '\x00'. ---------- components: Interpreter Core messages: 207232 nosy: arigo priority: low severity: normal status: open title: NUL bytes in commented lines type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 19:02:46 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Jan 2014 18:02:46 +0000 Subject: [issue20115] NUL bytes in commented lines In-Reply-To: <1388771953.42.0.332804570753.issue20115@psf.upfronthosting.co.za> Message-ID: <1388772166.15.0.215835849044.issue20115@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 20:02:15 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jan 2014 19:02:15 +0000 Subject: [issue16039] imaplib: unlimited readline() from connection In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za> Message-ID: <1388775735.36.0.0452080630432.issue16039@psf.upfronthosting.co.za> R. David Murray added the comment: Applied to 2.7 in dd906f4ab923. ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 20:14:08 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jan 2014 19:14:08 +0000 Subject: [issue17460] Remove the strict and related params completely removing the 0.9 support In-Reply-To: <1363618864.34.0.693275947596.issue17460@psf.upfronthosting.co.za> Message-ID: <3dwwlL6x7Jz7Lkd@mail.python.org> Roundup Robot added the comment: New changeset f9bb9c11363a by R David Murray in branch 'default': whatsnew: porting note for HTTP[S]Connection strict parameter removal. http://hg.python.org/cpython/rev/f9bb9c11363a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 20:25:29 2014 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 03 Jan 2014 19:25:29 +0000 Subject: [issue20114] Sporadic failure of test_semaphore_tracker() of test_multiprocessing_forkserver on FreeBSD 9 buildbot In-Reply-To: <1388751464.62.0.0417954391884.issue20114@psf.upfronthosting.co.za> Message-ID: <1388777129.33.0.452522564564.issue20114@psf.upfronthosting.co.za> Richard Oudkerk added the comment: How often has this happened? If the machine was very loaded then maybe the timeout was not enough time for the semaphore to be cleaned up by the tracker process. But I would expect 1 second to be more than ample. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 20:28:13 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 03 Jan 2014 19:28:13 +0000 Subject: =?utf-8?q?=5Bissue13943=5D_distutils=E2=80=99_build=5Fpy_fails_when_packa?= =?utf-8?q?ge_string_is_unicode?= In-Reply-To: <1328388068.27.0.743003863578.issue13943@psf.upfronthosting.co.za> Message-ID: <1388777293.53.0.637744488426.issue13943@psf.upfronthosting.co.za> ?ric Araujo added the comment: It?s strange that this would happen when installing as a dependency and not when installing directly. Pip can change faster than stdlib is released, could you report the bug to them and see if it?s possible to pass __file__ as a byte string? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 20:39:19 2014 From: report at bugs.python.org (Ruben D. Orduz) Date: Fri, 03 Jan 2014 19:39:19 +0000 Subject: [issue20116] urlparse.parse_qs should take argument for query separator Message-ID: <1388777959.1.0.144368039339.issue20116@psf.upfronthosting.co.za> New submission from Ruben D. Orduz: Currently urlparse.parse_qs (http://hg.python.org/cpython/file/2.7/Lib/urlparse.py#l150) assumes and uses ';' as a query string separator with no way to overwrite that. There are several web service APIs out there that use ';' as list separator (e.g. [URL]?fruits=lemon;lime&family=citrus). Although ';' seems like a sensible choice for a default, there should be a way to overwrite it. ---------- messages: 207237 nosy: ruben.orduz priority: normal severity: normal status: open title: urlparse.parse_qs should take argument for query separator type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 20:42:00 2014 From: report at bugs.python.org (Daniel Holth) Date: Fri, 03 Jan 2014 19:42:00 +0000 Subject: [issue18515] zipfile._ZipDecryptor generates wasteful crc32 table on import In-Reply-To: <1374331044.49.0.0628884037506.issue18515@psf.upfronthosting.co.za> Message-ID: <1388778120.21.0.637526803418.issue18515@psf.upfronthosting.co.za> Daniel Holth added the comment: Fixed in http://hg.python.org/cpython/rev/536a2cf5f1d2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 20:42:00 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jan 2014 19:42:00 +0000 Subject: [issue16039] imaplib: unlimited readline() from connection In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za> Message-ID: <1388778120.29.0.222477006214.issue16039@psf.upfronthosting.co.za> R. David Murray added the comment: And we're getting test failures in the SSL version of the test. No similar failure reports in the tracker, and the same test has been running on the Python3 branch for a while now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 21:00:50 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 03 Jan 2014 20:00:50 +0000 Subject: [issue19538] Changed function prototypes in the PEP 384 stable ABI In-Reply-To: <1384028904.73.0.822920006161.issue19538@psf.upfronthosting.co.za> Message-ID: <1388779250.43.0.160593241179.issue19538@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I agree with Serhiy. This use case is not "supported", i.e. it getting this compiler warning if you implement a function from the interpreter core is not a bug. The work-around that he suggests sounds reasonable to me. ---------- nosy: +loewis resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 21:01:06 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jan 2014 20:01:06 +0000 Subject: [issue20116] urlparse.parse_qs should take argument for query separator In-Reply-To: <1388777959.1.0.144368039339.issue20116@psf.upfronthosting.co.za> Message-ID: <1388779266.55.0.937927174949.issue20116@psf.upfronthosting.co.za> R. David Murray added the comment: As an enhancement, this could only go into 3.5. ---------- nosy: +r.david.murray versions: +Python 3.5 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 21:08:41 2014 From: report at bugs.python.org (Ruben D. Orduz) Date: Fri, 03 Jan 2014 20:08:41 +0000 Subject: [issue20116] urlparse.parse_qs should take argument for query separator In-Reply-To: <1388777959.1.0.144368039339.issue20116@psf.upfronthosting.co.za> Message-ID: <1388779721.03.0.524415719141.issue20116@psf.upfronthosting.co.za> Ruben D. Orduz added the comment: So, are you suggesting I should change to a different type if desired for 2.7.x or leave for release to 3.5 and then submit a patch to backport it to 2.7.x? I apologize, not sure how the workflow works in these cases. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 21:23:05 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jan 2014 20:23:05 +0000 Subject: [issue20116] urlparse.parse_qs should take argument for query separator In-Reply-To: <1388777959.1.0.144368039339.issue20116@psf.upfronthosting.co.za> Message-ID: <1388780585.27.0.446438847264.issue20116@psf.upfronthosting.co.za> R. David Murray added the comment: I'm saying that this is a change that can be made only in 3.5. if you want to submit a patch here for 2.7 for other people to use that's fine, but it won't get applied. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 21:24:30 2014 From: report at bugs.python.org (Ruben D. Orduz) Date: Fri, 03 Jan 2014 20:24:30 +0000 Subject: [issue20116] urlparse.parse_qs should take argument for query separator In-Reply-To: <1388777959.1.0.144368039339.issue20116@psf.upfronthosting.co.za> Message-ID: <1388780670.41.0.776077590493.issue20116@psf.upfronthosting.co.za> Ruben D. Orduz added the comment: Ah, gotcha. I think I will leave as is then. Thanks for clarifying. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 21:37:14 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jan 2014 20:37:14 +0000 Subject: [issue19526] Review additions to the stable ABI of Python 3.4 In-Reply-To: <1383909495.56.0.906628582778.issue19526@psf.upfronthosting.co.za> Message-ID: <3dwybG0CnWz7Ljw@mail.python.org> Roundup Robot added the comment: New changeset 15bad3abfac9 by Martin v. L?wis in branch 'default': Issue #19526: Exclude all new API from the stable ABI. http://hg.python.org/cpython/rev/15bad3abfac9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 21:40:00 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 03 Jan 2014 20:40:00 +0000 Subject: [issue19526] Review additions to the stable ABI of Python 3.4 In-Reply-To: <1383909495.56.0.906628582778.issue19526@psf.upfronthosting.co.za> Message-ID: <1388781600.22.0.119341788545.issue19526@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The procedure to obtain the new API was this: * write a C file #define Py_LIMITED_API #include * compile this with gcc -E | grep -v '#' * diff and inspect the two preprocessor outputs. Ideally, they come out empty, but they currently show lots of (legitimate) const additions, and some reformattings ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 21:59:53 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 03 Jan 2014 20:59:53 +0000 Subject: [issue15012] test issue In-Reply-To: <1338954222.11.0.497891813063.issue15012@psf.upfronthosting.co.za> Message-ID: <1388782793.1.0.136449860824.issue15012@psf.upfronthosting.co.za> Benjamin Peterson added the comment: testing 1, 2, 3 ---------- nosy: +benjamin.peterson -brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 22:00:21 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 03 Jan 2014 21:00:21 +0000 Subject: [issue15012] test issue In-Reply-To: <1338954222.11.0.497891813063.issue15012@psf.upfronthosting.co.za> Message-ID: <1388782821.34.0.295791626538.issue15012@psf.upfronthosting.co.za> Benjamin Peterson added the comment: testing again... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 22:52:14 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 03 Jan 2014 21:52:14 +0000 Subject: [issue20114] Sporadic failure of test_semaphore_tracker() of test_multiprocessing_forkserver on FreeBSD 9 buildbot In-Reply-To: <1388751464.62.0.0417954391884.issue20114@psf.upfronthosting.co.za> Message-ID: <1388785934.63.0.977045069974.issue20114@psf.upfronthosting.co.za> Stefan Krah added the comment: The machine has a high load: 6 processes at 100% CPU, one of which is the FreeBSD virtual machine. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 23:05:54 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jan 2014 22:05:54 +0000 Subject: [issue18960] First line can be executed twice In-Reply-To: <1378559493.77.0.649785663787.issue18960@psf.upfronthosting.co.za> Message-ID: <1388786754.98.0.174385943735.issue18960@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which fixes this issue (and related issues). * Encoding declaration now detected in second line only if first line is spaces-only (this is needed for support -x option) or comment-only (needed for she-bang). * Fixed support for -x option. * PyTokenizer_FromString() no longer check encoding declaration in second line if it was found in first line. * Fixed encoding detection in the tokenize module, in IDLE, in 2to3 and in the findnocoding script. ---------- assignee: -> serhiy.storchaka keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file33304/source_encoding_second_line.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 23:20:39 2014 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 03 Jan 2014 22:20:39 +0000 Subject: [issue20117] subprocess on Windows: wrong return code with shell=True Message-ID: <1388787639.9.0.977617126521.issue20117@psf.upfronthosting.co.za> New submission from Guido van Rossum: A little birdie told me: """ Bug in Python subprocess doesn't allow to detect if command executed through Windows system shell exists. If command doesn't exist, windows shell returns 9009 exit code (127 on Linux): ---[a.bat]--- @echo off nonex echo %ERRORLEVEL% > a.bat 'nonex' is not recognized as an internal or external command, operable program or batch file. 9009 However, when executed with Python, the return code is different on Python 2.7/3.3: ---[x.py]--- import subprocess p = subprocess.Popen("nonex", shell=True) print(p.wait()) > python x.py 'nonex' is not recognized as an internal or external command, operable program or batch file. 1 The same script executed on Linux gives correct result: # python x.py /bin/sh: non-existent: command not found 127 ---[a.sh]--- nonex echo $? """ There's some more research at http://goo.gl/xEg2b1 Seems the culprit is cmd.exe, which is executed by Python internally. It looks like it fails to return corresponding code 9009. Possibly all that needs to be done is documenting this wart, if we can't do anything about it? ---------- messages: 207251 nosy: ezio.melotti, gvanrossum priority: low severity: normal stage: needs patch status: open title: subprocess on Windows: wrong return code with shell=True type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 23:22:59 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jan 2014 22:22:59 +0000 Subject: [issue20118] test_imaplib test_linetoolong fails on 2.7 in SSL test on some buildbots Message-ID: <1388787779.06.0.335033013809.issue20118@psf.upfronthosting.co.za> New submission from R. David Murray: test.test_imaplib.ThreadedNetworkedTestsSSL.test_linetoolong, added as part of the fix for security (DOS attack) issue 16039, is failing on 2.7 on some buildbots (FreeBSD, OpenIndia, Windows). On some platforms (FreeBSD at least) the failure seems to be intermittent. Running the tests with the same randseed on linux does not reproduce the problem. Running the test under -F on linux does not produce any failures. Since this is a DOS security issue, and since the failure is that the exception comes from the ssl module instead of being an imaplib error but it nevertheless blocks the attack, I've left the patch in. But the reason for the failure should be determined and either the test or the code fixed. (In the meantime I'll mark the test to be skipped). ---------- components: Library (Lib) messages: 207252 nosy: r.david.murray priority: normal severity: normal stage: needs patch status: open title: test_imaplib test_linetoolong fails on 2.7 in SSL test on some buildbots type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 23:27:31 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jan 2014 22:27:31 +0000 Subject: [issue20118] test_imaplib test_linetoolong fails on 2.7 in SSL test on some buildbots In-Reply-To: <1388787779.06.0.335033013809.issue20118@psf.upfronthosting.co.za> Message-ID: <3dx12V6mJJz7Lk1@mail.python.org> Roundup Robot added the comment: New changeset d7ae948d9eee by R David Murray in branch '2.7': #16039/#20118: temporarily skip failing imaplib SSL test. http://hg.python.org/cpython/rev/d7ae948d9eee ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 23:27:32 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jan 2014 22:27:32 +0000 Subject: [issue16039] imaplib: unlimited readline() from connection In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za> Message-ID: <3dx12W4qrsz7Lk1@mail.python.org> Roundup Robot added the comment: New changeset d7ae948d9eee by R David Murray in branch '2.7': #16039/#20118: temporarily skip failing imaplib SSL test. http://hg.python.org/cpython/rev/d7ae948d9eee ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 3 23:34:44 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Jan 2014 22:34:44 +0000 Subject: [issue16039] imaplib: unlimited readline() from connection In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za> Message-ID: <1388788484.08.0.648836787828.issue16039@psf.upfronthosting.co.za> STINNER Victor added the comment: Reopen, a test is failing. ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 00:00:36 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jan 2014 23:00:36 +0000 Subject: [issue16039] imaplib: unlimited readline() from connection In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za> Message-ID: <1388790036.69.0.442408927152.issue16039@psf.upfronthosting.co.za> R. David Murray added the comment: I opened a new issue for the failing test: issue 20118, so I don't see a reason to keep this open. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 00:21:33 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Jan 2014 23:21:33 +0000 Subject: [issue16039] imaplib: unlimited readline() from connection In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za> Message-ID: <1388791293.7.0.708494447932.issue16039@psf.upfronthosting.co.za> STINNER Victor added the comment: "I opened a new issue for the failing test: issue 20118, so I don't see a reason to keep this open." Ok, I wasn't aware of this issue. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 00:57:07 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jan 2014 23:57:07 +0000 Subject: [issue18310] itertools.tee() can't accept keyword arguments In-Reply-To: <1372270091.7.0.0269629805126.issue18310@psf.upfronthosting.co.za> Message-ID: <1388793427.79.0.832465922444.issue18310@psf.upfronthosting.co.za> Terry J. Reedy added the comment: It is an unfortunate (to my mind) but true fact that the docs do not indicate which functions are coded in C and for such functions, whether args passable by position can also be passed by name. If one wishes to pass by name, one simply has to experiment. The problem is possibly a bit worse for itertools because its docs have 'equivalent' Python code that is not quite equivalent for position-only C parameters. Solutions would be a fit topic for python-ideas list. The tee docs do not describe 'n' as a keyword. They only indicate its default value, which is a different issue altogether. The word 'keyword' only appears in the 'product' entry to describe the 'repeat' parameter. It there means 'pass by name only', as product() takes an indefinite number of positional iterables, so that a repeat value cannot be passed by position. 'user': please do not play with the Status: value. This is a good way to make yourself unpopular with developers. If a developer 'closes' an issue and you wish it 'reopened', ask and explain, and be willing for the request to be ignored or rejected. ---------- nosy: +terry.reedy stage: -> committed/rejected status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 01:04:18 2014 From: report at bugs.python.org (Gennadiy Zlobin) Date: Sat, 04 Jan 2014 00:04:18 +0000 Subject: [issue19255] Don't "wipe" builtins at shutdown In-Reply-To: <1381700055.32.0.691639350713.issue19255@psf.upfronthosting.co.za> Message-ID: <1388793858.05.0.234821440385.issue19255@psf.upfronthosting.co.za> Gennadiy Zlobin added the comment: I'm not 100% sure that this is what intended, but probably this patch can fix it? Please review it. ---------- keywords: +patch nosy: +gennad Added file: http://bugs.python.org/file33305/19255.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 01:05:52 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 04 Jan 2014 00:05:52 +0000 Subject: [issue20090] slight ambiguity in README.txt instructions for building docs In-Reply-To: <1388243674.59.0.297728620179.issue20090@psf.upfronthosting.co.za> Message-ID: <1388793952.7.0.553225206902.issue20090@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 01:17:11 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 04 Jan 2014 00:17:11 +0000 Subject: [issue20103] Documentation of itertools.accumulate is confused In-Reply-To: <1388592720.87.0.970906154406.issue20103@psf.upfronthosting.co.za> Message-ID: <1388794631.45.0.936910246522.issue20103@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Somewhat orthogonal to Mitchell's suggestion, I would change 'returns' to 'yields' and expand 'elements' to 'elements of *iterable*'. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 01:17:24 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 04 Jan 2014 00:17:24 +0000 Subject: [issue20103] Documentation of itertools.accumulate is confused In-Reply-To: <1388592720.87.0.970906154406.issue20103@psf.upfronthosting.co.za> Message-ID: <1388794644.38.0.496299211306.issue20103@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 01:18:25 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 04 Jan 2014 00:18:25 +0000 Subject: [issue20117] subprocess on Windows: wrong return code with shell=True In-Reply-To: <1388787639.9.0.977617126521.issue20117@psf.upfronthosting.co.za> Message-ID: <1388794705.28.0.0349712278449.issue20117@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +brian.curtin, giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 01:19:51 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 04 Jan 2014 00:19:51 +0000 Subject: [issue20103] Documentation of itertools.accumulate is confused In-Reply-To: <1388592720.87.0.970906154406.issue20103@psf.upfronthosting.co.za> Message-ID: <1388794791.28.0.484440860356.issue20103@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy nosy: +ezio.melotti type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 01:27:23 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 04 Jan 2014 00:27:23 +0000 Subject: [issue20116] urlparse.parse_qs should take argument for query separator In-Reply-To: <1388777959.1.0.144368039339.issue20116@psf.upfronthosting.co.za> Message-ID: <1388795243.31.0.000387166198577.issue20116@psf.upfronthosting.co.za> Senthil Kumaran added the comment: If you could point to RFC which states the list of characters which can be used as valid query string separators, we can include that list. (Of course in 3.5) ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 01:30:48 2014 From: report at bugs.python.org (Ruben D. Orduz) Date: Sat, 04 Jan 2014 00:30:48 +0000 Subject: [issue20116] urlparse.parse_qs should take argument for query separator In-Reply-To: <1388777959.1.0.144368039339.issue20116@psf.upfronthosting.co.za> Message-ID: <1388795448.9.0.0432616352497.issue20116@psf.upfronthosting.co.za> Ruben D. Orduz added the comment: Senthil, The RFC can be found here: http://tools.ietf.org/html/rfc3986#section-2.2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 01:33:35 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 04 Jan 2014 00:33:35 +0000 Subject: [issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not In-Reply-To: <1388260592.79.0.323683192221.issue20092@psf.upfronthosting.co.za> Message-ID: <1388795615.46.0.332569602457.issue20092@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I believe this is my suggestion 2) in msg206715 of #19995, and I think it better than 3) (and 1) alone). Thanks for moving this forward. I believe what Guido said is that indexes (integers in the broad sense) are (or should be) a subset of things convertible to ints. I concur completely. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 01:33:51 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 04 Jan 2014 00:33:51 +0000 Subject: [issue20092] type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not In-Reply-To: <1388260592.79.0.323683192221.issue20092@psf.upfronthosting.co.za> Message-ID: <1388795631.47.0.965290302758.issue20092@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 02:31:44 2014 From: report at bugs.python.org (HCT) Date: Sat, 04 Jan 2014 01:31:44 +0000 Subject: [issue19729] [regression] str.format sublevel format parsing broken in Python 3.3.3 In-Reply-To: <1385173002.6.0.538237708826.issue19729@psf.upfronthosting.co.za> Message-ID: <1388799104.57.0.722704570803.issue19729@psf.upfronthosting.co.za> HCT added the comment: just want to know if there is any tentative schedule to release 3.3.4. the PEP for 3.3 schedule doesn't talk about 3.3.4, so I'm not sure if the decision was to leave latest 3.3 with this broken regression or fix it and release 3.3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 04:56:31 2014 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 04 Jan 2014 03:56:31 +0000 Subject: [issue18310] itertools.tee() can't accept keyword arguments In-Reply-To: <1372270091.7.0.0269629805126.issue18310@psf.upfronthosting.co.za> Message-ID: <1388807791.9.0.799841981654.issue18310@psf.upfronthosting.co.za> Mark Lawrence added the comment: >From the glossary Quote keyword argument: an argument preceded by an identifier (e.g. name=) in a function call or passed as a value in a dictionary preceded by **. For example, 3 and 5 are both keyword arguments in the following calls to complex(): complex(real=3, imag=5) complex(**{'real': 3, 'imag': 5}) End Quote >From itertools docs "itertools.tee(iterable, n=2) Return n independent iterators from a single iterable", so what is this if it's not a keyword argument? Surely all that's needed in this case is for the docs to read "itertools.tee(iterable[, n]) Return n independent iterators from a single iterable where n defaults to 2" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 05:13:31 2014 From: report at bugs.python.org (nlevitt@gmail.com) Date: Sat, 04 Jan 2014 04:13:31 +0000 Subject: [issue20119] pdb c(ont(inue)) optional one-time-only breakpoint (like perl debugger) Message-ID: <1388808811.19.0.853662131976.issue20119@psf.upfronthosting.co.za> New submission from nlevitt at gmail.com: The continue command in perl's debugger (perl -d) supports setting a one-time-only breakpoint. IMHO this is incredibly useful. For instance when stepping through a program, if you get stuck in a loop, you can move past it with a simple one line command "c [line-after-loop]". pdb could have the same thing! ---------- files: pdb-continue-onetime-bp-00.diff keywords: patch messages: 207266 nosy: nlevitt at gmail.com priority: normal severity: normal status: open title: pdb c(ont(inue)) optional one-time-only breakpoint (like perl debugger) type: enhancement Added file: http://bugs.python.org/file33306/pdb-continue-onetime-bp-00.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 07:45:58 2014 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sat, 04 Jan 2014 06:45:58 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za> Message-ID: <1388817958.52.0.892543235555.issue3982@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 07:57:30 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 04 Jan 2014 06:57:30 +0000 Subject: [issue20118] test_imaplib test_linetoolong fails on 2.7 in SSL test on some buildbots In-Reply-To: <1388787779.06.0.335033013809.issue20118@psf.upfronthosting.co.za> Message-ID: <1388818650.96.0.230263004159.issue20118@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 08:09:10 2014 From: report at bugs.python.org (Eric Snow) Date: Sat, 04 Jan 2014 07:09:10 +0000 Subject: [issue19697] refactor pythonrun.c to make use of specs (__main__.__spec__) In-Reply-To: <1385137546.91.0.531425476426.issue19697@psf.upfronthosting.co.za> Message-ID: <1388819350.98.0.335021608272.issue19697@psf.upfronthosting.co.za> Eric Snow added the comment: Here's an outline of how I see __main__.__spec__ playing out relative to the various cmdline interfaces. == == == === ==== ======== ======== ======== ======== ============ - -c -m dir file name loader origin cached has_location == == == === ==== ======== ======== ======== ======== ============ __main__ builtin - None False X __main__ builtin - None False X __main__ builtin -c None False X (finder) (finder) (finder) (finder) (finder) X __main__ path None True X __main__ path None True == == == === ==== ======== ======== ======== ======== ============ Note: __main__.__spec__ in the -m case is addressed in issue #19700. Thoughts? See: [1] http://docs.python.org/3.4/using/cmdline.html [2] Python/pythonrun.c [3] Modules/main.c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 08:10:23 2014 From: report at bugs.python.org (Eric Snow) Date: Sat, 04 Jan 2014 07:10:23 +0000 Subject: [issue19697] refactor pythonrun.c to make use of specs (__main__.__spec__) In-Reply-To: <1385137546.91.0.531425476426.issue19697@psf.upfronthosting.co.za> Message-ID: <1388819423.94.0.705451939744.issue19697@psf.upfronthosting.co.za> Eric Snow added the comment: For the record, normal start-up happens like this (simplified): 1. prep for and create/initialize interpreter 2. exec the site module in the __main__ namespace (unless -S) 3. do the interface-specific stuff Note: exec of the site module does not impact the spec. In the case where -i/PYTHONINSPECT is issued (or implied): 1. ... 2. ... 3. exec the PYTHONSTARTUP script (if set and it exists) 4. do the interface-specific stuff 5. start the REPL Note: the -i case does not impact the spec, nor does the exec of any PYTHONSTARTUP script. See: [1] http://docs.python.org/3.4/using/cmdline.html [2] Python/pythonrun.c [3] Modules/main.c [4] PEP 432 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 08:14:23 2014 From: report at bugs.python.org (Eric Snow) Date: Sat, 04 Jan 2014 07:14:23 +0000 Subject: [issue19697] refactor pythonrun.c to make use of specs (__main__.__spec__) In-Reply-To: <1385137546.91.0.531425476426.issue19697@psf.upfronthosting.co.za> Message-ID: <1388819663.61.0.73592798117.issue19697@psf.upfronthosting.co.za> Eric Snow added the comment: Food for thought: We could (for 3.5) add an importer just for __main__ that gives us the appropriate spec and loads __main__ accordingly. Such a loader could even incorporate exec of the site module (and any PYTHONSTARTUP script). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 08:30:00 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 04 Jan 2014 07:30:00 +0000 Subject: [issue18310] itertools.tee() can't accept keyword arguments In-Reply-To: <1372270091.7.0.0269629805126.issue18310@psf.upfronthosting.co.za> Message-ID: <1388820600.69.0.317635918848.issue18310@psf.upfronthosting.co.za> Terry J. Reedy added the comment: 'name=val' in a signature (not a call) merely indicates that name has a default. The 2.x use of [] to indicate the the parameter with a default is optional was dropped as redundant in the 3.x docs. The 2.x; tee doc has [, n=2]. The 3.x doc is correctly according to the 3.x doc standard. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 08:45:39 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 04 Jan 2014 07:45:39 +0000 Subject: [issue19697] refactor pythonrun.c to make use of specs (__main__.__spec__) In-Reply-To: <1385137546.91.0.531425476426.issue19697@psf.upfronthosting.co.za> Message-ID: <1388821539.9.0.0528782308143.issue19697@psf.upfronthosting.co.za> Nick Coghlan added the comment: You'd also need to update the new multiprocessing code - it currently expects "__main__.__spec__ == None" for all the run-from-a-path-or-stdin cases. The -m switch and running __main__ from a supplied sys.path entry (the "dir" entry in your table) are both already handled by the runpy changes in issue 19700. The remaining cases where __main__.__spec__ is currently None: - interactive prompt - -c switch - running from stdin - running directly from a source or bytecode file To be honest, I'm not sure it actually makes sense to try to manufacture a pseudo-spec for those cases. A main script may not be importable as a module (e.g. a hyphen in its name, or no .py suffix), and you *definitely* can't import a file that doesn't exist on disk (REPL, stdin, -c). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 09:09:52 2014 From: report at bugs.python.org (Eric Snow) Date: Sat, 04 Jan 2014 08:09:52 +0000 Subject: [issue19697] refactor pythonrun.c to make use of specs (__main__.__spec__) In-Reply-To: <1385137546.91.0.531425476426.issue19697@psf.upfronthosting.co.za> Message-ID: <1388822992.38.0.49448284608.issue19697@psf.upfronthosting.co.za> Eric Snow added the comment: I'm fine with leaving __spec__ as None for those remaining cases. It definitely simplifies this ticket. :) Do you see any reason to not close this one at this point? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 09:20:22 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 04 Jan 2014 08:20:22 +0000 Subject: [issue19697] Document the possible values for __main__.__spec__ In-Reply-To: <1385137546.91.0.531425476426.issue19697@psf.upfronthosting.co.za> Message-ID: <1388823622.49.0.0642934058925.issue19697@psf.upfronthosting.co.za> Nick Coghlan added the comment: I think we need to document this somewhere. Not exactly sure where though - a new subsection in the import reference, perhaps? ---------- title: refactor pythonrun.c to make use of specs (__main__.__spec__) -> Document the possible values for __main__.__spec__ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 09:37:23 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jan 2014 08:37:23 +0000 Subject: [issue18960] First line can be executed twice In-Reply-To: <1378559493.77.0.649785663787.issue18960@psf.upfronthosting.co.za> Message-ID: <1388824643.76.0.642850657801.issue18960@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, I had not compiled the code after last change, so first patch is wrong. Here is fixed patch. ---------- Added file: http://bugs.python.org/file33307/source_encoding_second_line_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 09:54:35 2014 From: report at bugs.python.org (Thomas Levine) Date: Sat, 04 Jan 2014 08:54:35 +0000 Subject: [issue20120] Percent-signs (%) in .pypirc should not be interpolated Message-ID: <1388825675.42.0.435893533792.issue20120@psf.upfronthosting.co.za> New submission from Thomas Levine: This works fine in Python 2.7, but it fails in Python 3.3. [tlevine at wildebeest mailfest-scoreboard]$ python3 --version Python 3.3.3 [tlevine at wildebeest mailfest-scoreboard]$ python3 setup.py register sdist running register Traceback (most recent call last): File "setup.py", line 11, in scripts=['scoreboard'] File "/usr/lib/python3.3/distutils/core.py", line 148, in setup dist.run_commands() File "/usr/lib/python3.3/distutils/dist.py", line 929, in run_commands self.run_command(cmd) File "/usr/lib/python3.3/distutils/dist.py", line 948, in run_command cmd_obj.run() File "/usr/lib/python3.3/distutils/command/register.py", line 45, in run self._set_config() File "/usr/lib/python3.3/distutils/command/register.py", line 71, in _set_config config = self._read_pypirc() File "/usr/lib/python3.3/distutils/config.py", line 83, in _read_pypirc current[key] = config.get(server, key) File "/usr/lib/python3.3/configparser.py", line 790, in get d) File "/usr/lib/python3.3/configparser.py", line 391, in before_get self._interpolate_some(parser, option, L, value, section, defaults, 1) File "/usr/lib/python3.3/configparser.py", line 440, in _interpolate_some "found: %r" % (rest,)) configparser.InterpolationSyntaxError: '%' must be followed by '%' or '(', found: '%rest-of-my-password' Here are the relevant files. [tlevine at wildebeest mailfest-scoreboard]$ cat ~/.pypirc [distutils] index-servers = pypi [pypi] username:tlevine password:yh^%#rest-of-my-password [tlevine at wildebeest mailfest-scoreboard]$ cat setup.py #!/usr/bin/env python3 from distutils.core import setup setup(name='mailfest-scoreboard', version='0.0.1', description='Score mailfest participants', author='Thomas Levine', author_email='_ at thomaslevine.com', url='https://github.com/tlevine/mailfest-scoreboard', scripts=['scoreboard'] ) ---------- components: Distutils messages: 207275 nosy: tlevine priority: normal severity: normal status: open title: Percent-signs (%) in .pypirc should not be interpolated type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 10:06:41 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jan 2014 09:06:41 +0000 Subject: [issue17432] PyUnicode_ functions not accessible in Limited API on Windows In-Reply-To: <1363385884.71.0.776131230148.issue17432@psf.upfronthosting.co.za> Message-ID: <3dxHD10L0pz7LjZ@mail.python.org> Roundup Robot added the comment: New changeset ea0aa3e32ab5 by Martin v. L?wis in branch '3.3': Issue #17432: Drop UCS2 from names of Unicode functions in python3.def. http://hg.python.org/cpython/rev/ea0aa3e32ab5 New changeset 0ea09c824d9b by Martin v. L?wis in branch 'default': Merge with 3.3: Issue #17432: Drop UCS2 from names of Unicode functions in python3.def. http://hg.python.org/cpython/rev/0ea09c824d9b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 10:33:18 2014 From: report at bugs.python.org (Thomas Levine) Date: Sat, 04 Jan 2014 09:33:18 +0000 Subject: [issue20120] Percent-signs (%) in .pypirc should not be interpolated In-Reply-To: <1388825675.42.0.435893533792.issue20120@psf.upfronthosting.co.za> Message-ID: <1388827998.18.0.1684241931.issue20120@psf.upfronthosting.co.za> Thomas Levine added the comment: The relevant section distutils/config.py seems no different in Python 2.7, so now I see this as a bug in configparser. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 10:44:14 2014 From: report at bugs.python.org (Thomas Levine) Date: Sat, 04 Jan 2014 09:44:14 +0000 Subject: [issue20120] Percent-signs (%) in .pypirc should not be interpolated In-Reply-To: <1388825675.42.0.435893533792.issue20120@psf.upfronthosting.co.za> Message-ID: <1388828654.8.0.909002687364.issue20120@psf.upfronthosting.co.za> Thomas Levine added the comment: Hmm now it looks to me like this is the intended behavior. http://hg.python.org/cpython/file/ea0aa3e32ab5/Lib/test/test_configparser.py#l1541 Switching the single percent sign (%) to two (%%) in .pypirc makes it work. Maybe we can make a nicer error message though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 11:32:11 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 04 Jan 2014 10:32:11 +0000 Subject: [issue19526] Review additions to the stable ABI of Python 3.4 In-Reply-To: <1383909495.56.0.906628582778.issue19526@psf.upfronthosting.co.za> Message-ID: <1388831531.08.0.679996089557.issue19526@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 11:33:00 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 04 Jan 2014 10:33:00 +0000 Subject: [issue17432] PyUnicode_ functions not accessible in Limited API on Windows In-Reply-To: <1363385884.71.0.776131230148.issue17432@psf.upfronthosting.co.za> Message-ID: <1388831580.96.0.141584799862.issue17432@psf.upfronthosting.co.za> Martin v. L?wis added the comment: This is now fixed for 3.3 and 3.4. Sorry it took so long. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 11:37:30 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sat, 04 Jan 2014 10:37:30 +0000 Subject: [issue13115] tp_as_{number, sequence, mapping} can't be set using PyType_FromSpec In-Reply-To: <1317910226.56.0.365091018544.issue13115@psf.upfronthosting.co.za> Message-ID: <1388831850.02.0.62567258359.issue13115@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Since 3.2 has seen its last bugfix release, this won't be added to 3.2 anymore. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 12:49:18 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 Jan 2014 11:49:18 +0000 Subject: [issue20115] NUL bytes in commented lines In-Reply-To: <1388771953.42.0.332804570753.issue20115@psf.upfronthosting.co.za> Message-ID: <1388836158.4.0.34890978942.issue20115@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> needs patch type: compile error -> behavior versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 12:54:50 2014 From: report at bugs.python.org (Fred Stober) Date: Sat, 04 Jan 2014 11:54:50 +0000 Subject: [issue20121] quopri_codec newline handling Message-ID: <1388836490.83.0.337537980753.issue20121@psf.upfronthosting.co.za> New submission from Fred Stober: While trying to encode some binary data, I encountered this behaviour of the quopri_codec: >>> '\r\n\n'.encode('quopri_codec').decode('quopri_codec') '\r\n\r\n' >>> '\n\r\n'.encode('quopri_codec').decode('quopri_codec') '\n\n' If this behaviour is really intended, it should be mentioned in the documentation that this coded is not bijective. ---------- components: Library (Lib) messages: 207281 nosy: fredstober priority: normal severity: normal status: open title: quopri_codec newline handling versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 14:18:07 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jan 2014 13:18:07 +0000 Subject: [issue20115] NUL bytes in commented lines In-Reply-To: <1388771953.42.0.332804570753.issue20115@psf.upfronthosting.co.za> Message-ID: <1388841487.49.0.120445439362.issue20115@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Indeed. CPython parser reads first line '#\x00\n' and save it in the buffer. But because C strings are used here (result of decode_str()), the line is truncated to '#'. As far as this data is not ended by '\n', it considered incomplete and next line is read and appended: '#' + 'a' -> '#a'. And this line is commented out now. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 14:34:04 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jan 2014 13:34:04 +0000 Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ... In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za> Message-ID: <1388842444.94.0.937763457502.issue7475@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Docstrings for new codecs mention bytes.transform() and bytes.untransform() which are nonexistent. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 15:03:35 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 04 Jan 2014 14:03:35 +0000 Subject: [issue2226] Small _abcoll Bugs / Oddities In-Reply-To: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za> Message-ID: <1388844215.89.0.353787942717.issue2226@psf.upfronthosting.co.za> Nick Coghlan added the comment: Raymond, will you have a chance to look at this before 3.4rc1? Otherwise I'd like to take it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 15:03:23 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 04 Jan 2014 14:03:23 +0000 Subject: [issue8743] set() operators don't work with collections.Set instances In-Reply-To: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za> Message-ID: <1388844203.18.0.462070440265.issue8743@psf.upfronthosting.co.za> Nick Coghlan added the comment: Raymond, will you have a chance to look at this before 3.4rc1? Otherwise I'd like to take it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 15:43:42 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 04 Jan 2014 14:43:42 +0000 Subject: [issue5131] pprint doesn't know how to print a defaultdict In-Reply-To: <1233592442.21.0.0563262599933.issue5131@psf.upfronthosting.co.za> Message-ID: <1388846622.56.0.148997046462.issue5131@psf.upfronthosting.co.za> Nick Coghlan added the comment: Closing this as a duplicate of issue 7434 (which is about redesigning pprint to make it easier to add support for new types) ---------- nosy: +ncoghlan resolution: accepted -> duplicate stage: patch review -> committed/rejected status: open -> closed superseder: -> general pprint rewrite _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 15:46:57 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 04 Jan 2014 14:46:57 +0000 Subject: [issue7434] general pprint rewrite In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za> Message-ID: <1388846817.41.0.543052382369.issue7434@psf.upfronthosting.co.za> Nick Coghlan added the comment: With PEP 443 added for Python 3.4, I believe ?ukasz intended to pursue a new pprint implementation based on functools.singledispatch. That has obviously missed feature freeze for Python 3.4, but it's still a reasonable idea to pursue for 3.5. In addition to OrderedDict (mentioned above) and defaultdict (which was mentioned in issue 5131), an updated pprint would also allow us to add support for the new dict view types, collections.deque, etc. Ideally, we'd also have a standard lazy import mechanism in 3.5, so these definitions could go in the collections module, but only installed if pprint was also imported. Otherwise, having pprint depend on collections would likely be preferable to having the dependency run the other way. ---------- nosy: +ncoghlan versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 16:19:13 2014 From: report at bugs.python.org (Richard Oudkerk) Date: Sat, 04 Jan 2014 15:19:13 +0000 Subject: [issue20114] Sporadic failure of test_semaphore_tracker() of test_multiprocessing_forkserver on FreeBSD 9 buildbot In-Reply-To: <1388751464.62.0.0417954391884.issue20114@psf.upfronthosting.co.za> Message-ID: <1388848753.54.0.412595914047.issue20114@psf.upfronthosting.co.za> Richard Oudkerk added the comment: It is probably harmless then. I don't think increasing the timeout is necessary -- the multiprocessing tests already take a long time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 16:26:48 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Jan 2014 15:26:48 +0000 Subject: [issue20120] Percent-signs (%) in .pypirc should not be interpolated In-Reply-To: <1388825675.42.0.435893533792.issue20120@psf.upfronthosting.co.za> Message-ID: <1388849208.54.0.283285310536.issue20120@psf.upfronthosting.co.za> R. David Murray added the comment: It could be an issue of which configparser is/was used. ---------- nosy: +lukasz.langa, r.david.murray versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 16:28:53 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Jan 2014 15:28:53 +0000 Subject: [issue20121] quopri_codec newline handling In-Reply-To: <1388836490.83.0.337537980753.issue20121@psf.upfronthosting.co.za> Message-ID: <1388849333.12.0.0534021497851.issue20121@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 16:35:38 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 04 Jan 2014 15:35:38 +0000 Subject: [issue20115] NUL bytes in commented lines In-Reply-To: <1388771953.42.0.332804570753.issue20115@psf.upfronthosting.co.za> Message-ID: <1388849738.74.0.334292642537.issue20115@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I guess NULL bytes should just be banned. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 17:24:58 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jan 2014 16:24:58 +0000 Subject: [issue20122] Move CallTips tests to idle_tests Message-ID: <1388852698.51.0.14863260737.issue20122@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch moves CallTips tests from Lib/idlelib/CallTips.py to Lib/idlelib/idle_test/test_calltips.py and converts them to unittests. Private keyword-only parameter _namespace was added to fetch_tip() and get_entity(). ---------- components: IDLE, Tests files: test_calltips.patch keywords: patch messages: 207291 nosy: kbk, roger.serwy, serhiy.storchaka, terry.reedy priority: normal severity: normal stage: patch review status: open title: Move CallTips tests to idle_tests type: enhancement versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33308/test_calltips.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 17:26:15 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jan 2014 16:26:15 +0000 Subject: [issue16630] IDLE: Calltip fails if __getattr__ raises exception In-Reply-To: <1354844775.58.0.855877358898.issue16630@psf.upfronthosting.co.za> Message-ID: <1388852775.13.0.700560084833.issue16630@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Move CallTips tests to idle_tests versions: +Python 2.7 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 17:28:05 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jan 2014 16:28:05 +0000 Subject: [issue19903] Idle: Use inspect.signature for calltips In-Reply-To: <1386289306.22.0.0855188637089.issue19903@psf.upfronthosting.co.za> Message-ID: <1388852885.54.0.0762913079391.issue19903@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Move CallTips tests to idle_tests _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 17:28:54 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jan 2014 16:28:54 +0000 Subject: [issue16655] IDLE list.append calltips test failures In-Reply-To: <1355106680.63.0.980843765647.issue16655@psf.upfronthosting.co.za> Message-ID: <1388852934.32.0.64914146469.issue16655@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Move CallTips tests to idle_tests _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 17:29:51 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jan 2014 16:29:51 +0000 Subject: [issue7883] CallTips.py _find_constructor does not work In-Reply-To: <1265631103.87.0.399117397925.issue7883@psf.upfronthosting.co.za> Message-ID: <1388852991.75.0.362371119953.issue7883@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Move CallTips tests to idle_tests _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 17:48:09 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jan 2014 16:48:09 +0000 Subject: [issue16638] support multi-line docstring signatures in IDLE calltips In-Reply-To: <1354909776.12.0.96265352257.issue16638@psf.upfronthosting.co.za> Message-ID: <1388854089.75.0.504913529641.issue16638@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Move CallTips tests to idle_tests _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 18:26:00 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jan 2014 17:26:00 +0000 Subject: [issue15027] Faster UTF-32 encoding In-Reply-To: <1339077451.46.0.686170991807.issue15027@psf.upfronthosting.co.za> Message-ID: <3dxVJ73ckZz7Ljf@mail.python.org> Roundup Robot added the comment: New changeset b72c5573c5e7 by Serhiy Storchaka in branch 'default': Issue #15027: Rewrite the UTF-32 encoder. It is now 1.6x to 3.5x faster. http://hg.python.org/cpython/rev/b72c5573c5e7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 18:29:34 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jan 2014 17:29:34 +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: <1388856574.42.0.30717609974.issue17576@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I have doubts about this issue, so I have unassigned it from myself. ---------- assignee: serhiy.storchaka -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 18:32:35 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jan 2014 17:32:35 +0000 Subject: [issue15027] Faster UTF-32 encoding In-Reply-To: <1339077451.46.0.686170991807.issue15027@psf.upfronthosting.co.za> Message-ID: <1388856755.35.0.859118548817.issue15027@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Gregory for your review. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 19:00:19 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 Jan 2014 18:00:19 +0000 Subject: [issue20120] Percent-signs (%) in .pypirc should not be interpolated In-Reply-To: <1388825675.42.0.435893533792.issue20120@psf.upfronthosting.co.za> Message-ID: <1388858419.02.0.296616506946.issue20120@psf.upfronthosting.co.za> Antoine Pitrou added the comment: In 3.x, the ConfigParser class is 2.x's SafeConfigParser, and the parsing rules are different (stricter, it seems). It's probably a won't fix, I'd say. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 19:04:26 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 04 Jan 2014 18:04:26 +0000 Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and sys.stdout on UNIX for the C locale In-Reply-To: <1386952820.2.0.77364136667.issue19977@psf.upfronthosting.co.za> Message-ID: <1388858666.67.0.147946868156.issue19977@psf.upfronthosting.co.za> Larry Hastings added the comment: Yeah, unless there was a *huge* amount of support for changing this, it's way too late for 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 19:06:16 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 04 Jan 2014 18:06:16 +0000 Subject: [issue19927] Path-based loaders lack a meaningful __eq__() implementation. In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za> Message-ID: <1388858776.92.0.890106532974.issue19927@psf.upfronthosting.co.za> Larry Hastings added the comment: So, not to yank your chain, but... I'm okay with checking this in. Yes, we're already in beta, but ModuleSpec is brand new, and the sense I get is that this use case is obscure even for ModuleSpec. The only installed base is beta 1 users, and given that this is new functionality... Anyway. I expect to tag late tonight, say in twelve hours. Can you check it in before then? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 19:07:48 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Jan 2014 18:07:48 +0000 Subject: [issue20120] Percent-signs (%) in .pypirc should not be interpolated In-Reply-To: <1388825675.42.0.435893533792.issue20120@psf.upfronthosting.co.za> Message-ID: <1388858868.26.0.393815933618.issue20120@psf.upfronthosting.co.za> R. David Murray added the comment: "More rational" is probably closer to the truth :). Yeah, it's probably a won't fix, but it would be nice to have ?ukasz's input. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 19:28:22 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 Jan 2014 18:28:22 +0000 Subject: [issue7434] general pprint rewrite In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za> Message-ID: <1388860102.82.0.88050976384.issue7434@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Ideally, we'd also have a standard lazy import mechanism in 3.5, so these definitions could go in the collections module, but only installed if pprint was also imported. That sounds more like an on-import hook than a lazy import mechanism, no? ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 19:28:50 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 Jan 2014 18:28:50 +0000 Subject: [issue7434] general pprint rewrite In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za> Message-ID: <1388860130.13.0.665709576217.issue7434@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Oops... no, it's not easy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 19:29:14 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 Jan 2014 18:29:14 +0000 Subject: [issue7434] general pprint rewrite In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za> Message-ID: <1388860154.1.0.696363989556.issue7434@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, so why did Roundup add the easy keyword and doesn't want to remove it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 19:35:50 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 04 Jan 2014 18:35:50 +0000 Subject: [issue7434] general pprint rewrite In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za> Message-ID: <1388860550.4.0.0658988389511.issue7434@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: -easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 19:41:17 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 04 Jan 2014 18:41:17 +0000 Subject: [issue15027] Faster UTF-32 encoding In-Reply-To: <1339077451.46.0.686170991807.issue15027@psf.upfronthosting.co.za> Message-ID: <1388860877.07.0.0276703123314.issue15027@psf.upfronthosting.co.za> Larry Hastings added the comment: Isn't this a new feature? ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 19:44:55 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 04 Jan 2014 18:44:55 +0000 Subject: [issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za> Message-ID: <1388861095.41.0.356248242217.issue19995@psf.upfronthosting.co.za> Larry Hastings added the comment: I'm willing to risk it in 3.4. Can you check it in in the next twelve hours? (Sorry for the short notice, it slipped my mind until just now.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 20:09:29 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jan 2014 19:09:29 +0000 Subject: [issue19976] Argument Clinic: generate second arg for METH_NOARGS In-Reply-To: <1386945786.12.0.418187279765.issue19976@psf.upfronthosting.co.za> Message-ID: <3dxXbX5x0Pz7Ljf@mail.python.org> Roundup Robot added the comment: New changeset c4ababa110a2 by Larry Hastings in branch 'default': Issue #19976: Argument Clinic METH_NOARGS functions now always http://hg.python.org/cpython/rev/c4ababa110a2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 20:59:30 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jan 2014 19:59:30 +0000 Subject: [issue15027] Faster UTF-32 encoding In-Reply-To: <1339077451.46.0.686170991807.issue15027@psf.upfronthosting.co.za> Message-ID: <1388865570.63.0.758085611905.issue15027@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry if I have missed. Should I revert changeset b72c5573c5e7? This patch doesn't introduce new functions and doesn't change behavior. Without this patch the UTF-32 encoder is up to 2.5x slower in 3.4 than in 3.3 (due to issue12892). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 21:10:40 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 04 Jan 2014 20:10:40 +0000 Subject: [issue15027] Faster UTF-32 encoding In-Reply-To: <1339077451.46.0.686170991807.issue15027@psf.upfronthosting.co.za> Message-ID: <1388866240.53.0.386110200636.issue15027@psf.upfronthosting.co.za> Larry Hastings added the comment: Would you describe it as a "bug fix" or a "security fix"? If it's neither of those things, then you need special permission to add it during beta. And given that this patch has the possibility of causing bugs, I'd prefer to not accept it for 3.4. Please revert it for now. If you think it should go in to 3.4, you may ask on python-dev that it be considered and take a poll. (Note that the poll is not binding on me; this is still solely my decision. However if there was an uproar of support for your patch, that would certainly cause me to reconsider.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 21:26:40 2014 From: report at bugs.python.org (Ned Deily) Date: Sat, 04 Jan 2014 20:26:40 +0000 Subject: [issue20119] pdb c(ont(inue)) optional one-time-only breakpoint (like perl debugger) In-Reply-To: <1388808811.19.0.853662131976.issue20119@psf.upfronthosting.co.za> Message-ID: <1388867200.05.0.696523634855.issue20119@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 21:37:52 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jan 2014 20:37:52 +0000 Subject: [issue20078] zipfile - ZipExtFile.read goes into 100% CPU infinite loop on maliciously binary edited zips In-Reply-To: <1388110280.6.0.508484621949.issue20078@psf.upfronthosting.co.za> Message-ID: <1388867872.51.0.267683628482.issue20078@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch with tests for all supported compression types. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file33309/zipfile_eof.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 21:43:08 2014 From: report at bugs.python.org (Eric Snow) Date: Sat, 04 Jan 2014 20:43:08 +0000 Subject: [issue19927] Path-based loaders lack a meaningful __eq__() implementation. In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za> Message-ID: <1388868188.51.0.186957252257.issue19927@psf.upfronthosting.co.za> Eric Snow added the comment: I'll commit it in a little while. Thanks. ---------- versions: +Python 3.4 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 21:45:12 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jan 2014 20:45:12 +0000 Subject: [issue19659] Document Argument Clinic In-Reply-To: <1384907080.98.0.430269997716.issue19659@psf.upfronthosting.co.za> Message-ID: <3dxZjz1l51z7LmC@mail.python.org> Roundup Robot added the comment: New changeset e2280bf5c263 by Larry Hastings in branch 'default': Issue #19659: Added documentation for Argument Clinic. http://hg.python.org/cpython/rev/e2280bf5c263 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 21:45:59 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 04 Jan 2014 20:45:59 +0000 Subject: [issue19659] Document Argument Clinic In-Reply-To: <1384907080.98.0.430269997716.issue19659@psf.upfronthosting.co.za> Message-ID: <1388868359.88.0.13407676365.issue19659@psf.upfronthosting.co.za> Larry Hastings added the comment: I hid it in the howto directory. Nobody'll look in there! :D ---------- assignee: -> larry resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 21:51:11 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jan 2014 20:51:11 +0000 Subject: [issue15027] Faster UTF-32 encoding In-Reply-To: <1339077451.46.0.686170991807.issue15027@psf.upfronthosting.co.za> Message-ID: <3dxZrt71rZz7LjS@mail.python.org> Roundup Robot added the comment: New changeset 1e345924f7ea by Serhiy Storchaka in branch 'default': Reverted changeset b72c5573c5e7 (issue #15027). http://hg.python.org/cpython/rev/1e345924f7ea ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 21:55:35 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jan 2014 20:55:35 +0000 Subject: [issue15027] Faster UTF-32 encoding In-Reply-To: <1339077451.46.0.686170991807.issue15027@psf.upfronthosting.co.za> Message-ID: <1388868935.57.0.735302731245.issue15027@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: fixed -> stage: committed/rejected -> patch review status: closed -> open versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 22:33:11 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 Jan 2014 21:33:11 +0000 Subject: [issue19659] Document Argument Clinic In-Reply-To: <1384907080.98.0.430269997716.issue19659@psf.upfronthosting.co.za> Message-ID: <1388871191.21.0.320567817702.issue19659@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I hid it in the howto directory. Nobody'll look in there! :D I think using a dotfile would make the hiding more efficient. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 22:48:12 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 04 Jan 2014 21:48:12 +0000 Subject: [issue19843] Wait for multiple sub-processes to terminate In-Reply-To: <1385826813.77.0.0339260517434.issue19843@psf.upfronthosting.co.za> Message-ID: <1388872092.09.0.269417192778.issue19843@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I'd rather see it bake in psutils for a while longer regardless of implementation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 23:13:49 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jan 2014 22:13:49 +0000 Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451 In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za> Message-ID: <3dxchD3MD4z7Ljf@mail.python.org> Roundup Robot added the comment: New changeset a18c1a4cf30a by Eric Snow in branch 'default': Issue #19713: Move away from using find_module/load_module. http://hg.python.org/cpython/rev/a18c1a4cf30a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 23:13:49 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jan 2014 22:13:49 +0000 Subject: [issue19708] Check pkgutil for anything missing for PEP 451 In-Reply-To: <1388737155.79.0.00404454007765.issue19708@psf.upfronthosting.co.za> Message-ID: <3dxchF1HcVz7Ljf@mail.python.org> Roundup Robot added the comment: New changeset acebe574ab08 by Eric Snow in branch 'default': Issue #19708: Update pkgutil to use the new importer APIs. http://hg.python.org/cpython/rev/acebe574ab08 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 23:13:50 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jan 2014 22:13:50 +0000 Subject: [issue19927] Path-based loaders lack a meaningful __eq__() implementation. In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za> Message-ID: <3dxchF6Trtz7Ljf@mail.python.org> Roundup Robot added the comment: New changeset a72a0e4dad20 by Eric Snow in branch 'default': Issue #19927: Add __eq__ to path-based loaders in importlib. http://hg.python.org/cpython/rev/a72a0e4dad20 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 23:14:47 2014 From: report at bugs.python.org (Eric Snow) Date: Sat, 04 Jan 2014 22:14:47 +0000 Subject: [issue19927] Path-based loaders lack a meaningful __eq__() implementation. In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za> Message-ID: <1388873687.74.0.911478064098.issue19927@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 23:16:20 2014 From: report at bugs.python.org (Eric Snow) Date: Sat, 04 Jan 2014 22:16:20 +0000 Subject: [issue19708] Check pkgutil for anything missing for PEP 451 In-Reply-To: <1388737155.79.0.00404454007765.issue19708@psf.upfronthosting.co.za> Message-ID: <1388873780.97.0.0359833835758.issue19708@psf.upfronthosting.co.za> Eric Snow added the comment: There wasn't much left to do for pkgutil after all. :) ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 23:19:38 2014 From: report at bugs.python.org (Eric Snow) Date: Sat, 04 Jan 2014 22:19:38 +0000 Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451 In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za> Message-ID: <1388873978.16.0.177301841125.issue19713@psf.upfronthosting.co.za> Eric Snow added the comment: At this point the only places using find_module and load_module are pydoc, importlib, and some oddballs that aren't worth worrying about. Issue #19703 covers the pydoc changes. ---------- dependencies: +Update pydoc to PEP 451 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 23:27:05 2014 From: report at bugs.python.org (Eric Snow) Date: Sat, 04 Jan 2014 22:27:05 +0000 Subject: [issue20123] pydoc.synopsis fails to load binary modules Message-ID: <1388874425.94.0.221860493391.issue20123@psf.upfronthosting.co.za> New submission from Eric Snow: I'm guessing this is a very seldom (never?) used code path. I've included a patch to test and fix the problem. The patch includes several related tests for pydoc. $ py3 -c 'import pydoc; pydoc.synopsis("/opt/python3.4/lib/python3.4/lib-dynload/time.cpython-34m.so")' Traceback (most recent call last): File "/opt/python3.4/lib/python3.4/tokenize.py", line 368, in find_cookie line_string = line.decode('utf-8') UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf4 in position 96: invalid continuation byte During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 1, in File "/opt/python3.4/lib/python3.4/pydoc.py", line 229, in synopsis file = tokenize.open(filename) File "/opt/python3.4/lib/python3.4/tokenize.py", line 429, in open encoding, lines = detect_encoding(buffer.readline) File "/opt/python3.4/lib/python3.4/tokenize.py", line 409, in detect_encoding encoding = find_cookie(first) File "/opt/python3.4/lib/python3.4/tokenize.py", line 373, in find_cookie raise SyntaxError(msg) SyntaxError: invalid or missing encoding declaration for '/opt/python3.4/lib/python3.4/lib-dynload/time.cpython-34m.so' ---------- messages: 207319 nosy: eric.snow, larry priority: normal severity: normal stage: patch review status: open title: pydoc.synopsis fails to load binary modules type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 23:36:27 2014 From: report at bugs.python.org (Eric Snow) Date: Sat, 04 Jan 2014 22:36:27 +0000 Subject: [issue19703] Update pydoc to PEP 451 In-Reply-To: <1386308732.16.0.241139477522.issue19703@psf.upfronthosting.co.za> Message-ID: <1388874987.86.0.194897306679.issue19703@psf.upfronthosting.co.za> Eric Snow added the comment: Here's a new patch relative to the patch for issue #20123. ---------- dependencies: +pydoc.synopsis fails to load binary modules Added file: http://bugs.python.org/file33310/issue19703-use-new-api.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 23:36:51 2014 From: report at bugs.python.org (Eric Snow) Date: Sat, 04 Jan 2014 22:36:51 +0000 Subject: [issue19703] Update pydoc to PEP 451 In-Reply-To: <1386308732.16.0.241139477522.issue19703@psf.upfronthosting.co.za> Message-ID: <1388875011.32.0.955957432093.issue19703@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file33302/issue19703-use-new-api.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 23:37:43 2014 From: report at bugs.python.org (Eric Snow) Date: Sat, 04 Jan 2014 22:37:43 +0000 Subject: [issue20123] pydoc.synopsis fails to load binary modules In-Reply-To: <1388874425.94.0.221860493391.issue20123@psf.upfronthosting.co.za> Message-ID: <1388875063.47.0.957642187925.issue20123@psf.upfronthosting.co.za> Eric Snow added the comment: FYI, I found this while working on issue #19703. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 4 23:57:49 2014 From: report at bugs.python.org (Eric Snow) Date: Sat, 04 Jan 2014 22:57:49 +0000 Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451 In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za> Message-ID: <1388876269.03.0.970409169348.issue19713@psf.upfronthosting.co.za> Eric Snow added the comment: I should clarify. That last commit was not the patch that adds the warnings. I'm going to update that patch and attach it here when I get the chance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 00:48:56 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Jan 2014 23:48:56 +0000 Subject: [issue20124] The documentation for the atTime parameter of TimedRotatimeFileHandler is confusing Message-ID: <1388879336.03.0.25076651665.issue20124@psf.upfronthosting.co.za> New submission from R. David Murray: The docs say that you can specify 'atTime' with a 'when' of 'midnight', but that makes no sense on the face of it. atTime with a weekday specification makes sense, but it would also make sense to use atTime with a when of D (and an interval), which is not mentioned as a possibility. It could also make sense to use it with other intervals (in other words, use the atTime as the starting point for the rotation calculation, instead of the last mod time or 'now'). If that doesn't work it should be stated that atTime will be ignored in those cases. Probably all the time related entries should be rewritten with the existence of atTime in mind, in order to clarify all the possible (and not possible) interactions. ---------- assignee: docs at python components: Documentation messages: 207323 nosy: docs at python, r.david.murray, vinay.sajip priority: normal severity: normal stage: needs patch status: open title: The documentation for the atTime parameter of TimedRotatimeFileHandler is confusing versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 02:27:21 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 05 Jan 2014 01:27:21 +0000 Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451 In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za> Message-ID: <1388885241.06.0.375410220348.issue19713@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: About last commit: Is there a way to avoid using private objects when removing uses of load_module? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 03:16:39 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 05 Jan 2014 02:16:39 +0000 Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451 In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za> Message-ID: <1388888199.7.0.184666769218.issue19713@psf.upfronthosting.co.za> Nick Coghlan added the comment: Arfrever: not at this point. We really should have an importlib.util.load_from_spec() that hides those internal details. Larry - can we get away with adding that? It didn't become obvious it was a missing API until Eric started doing these conversions. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 03:17:52 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 02:17:52 +0000 Subject: [issue20125] We need a good replacement for direct use of load_module(), post-PEP 451 Message-ID: <1388888272.45.0.255353824658.issue20125@psf.upfronthosting.co.za> New submission from Eric Snow: In issue #19713, it came up that while PEP 451 deprecated Loader.load_module(), it did not provide a suitable replacement for calling it directly. We've worked around this in the stdlib by making calls to private APIs, but that won't work so well for the community at large. The importlib._bootstrap._SpecMethods class is one we had considered making public, but decided to defer that decision until people demonstrated an interest/need. At this point in the 3.4 release cycle I'm not sure how much we can do about it. Adding something like the following would be easy, but then we'd be stuck indefinitely with an API that we may just deprecate in 3.5 (a one-hit wonder), though that might be the lesser evil. def load_from_spec(spec): _spec = importlib._bootstrap._SpecMethods(spec) return _spec.load() Adding that as a recipe to the load_module() docs wouldn't work too well either, since we'd still be advocating the use of a private API as a workaround. To be honest, I'll have to defer to Brett, Nick, et al. on this one. They have the experience to know the best approach to take here. I just haven't been in the majors long enough. (Where'd Guido put the keys to that time machine?) ---------- components: Library (Lib) messages: 207326 nosy: Arfrever, brett.cannon, eric.snow, ncoghlan priority: high severity: normal status: open title: We need a good replacement for direct use of load_module(), post-PEP 451 type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 03:19:25 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 02:19:25 +0000 Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451 In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za> Message-ID: <1388888365.1.0.767713879103.issue19713@psf.upfronthosting.co.za> Eric Snow added the comment: Hmm. That's a good question. There really isn't a simple, public-API replacement. I've opened issue #20125 to discuss our options. Feel free to offer any suggestions there. Thanks for bringing this up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 03:20:13 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 02:20:13 +0000 Subject: [issue20125] We need a good replacement for direct use of load_module(), post-PEP 451 In-Reply-To: <1388888272.45.0.255353824658.issue20125@psf.upfronthosting.co.za> Message-ID: <1388888413.45.0.557409346261.issue20125@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 03:20:54 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 05 Jan 2014 02:20:54 +0000 Subject: [issue20123] pydoc.synopsis fails to load binary modules In-Reply-To: <1388874425.94.0.221860493391.issue20123@psf.upfronthosting.co.za> Message-ID: <1388888454.77.0.432025986919.issue20123@psf.upfronthosting.co.za> Larry Hastings added the comment: Well please get a second opinion. I don't know why you added me, I'm not qualified. ---------- nosy: +brett.cannon, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 03:21:33 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 05 Jan 2014 02:21:33 +0000 Subject: [issue19659] Document Argument Clinic In-Reply-To: <1384907080.98.0.430269997716.issue19659@psf.upfronthosting.co.za> Message-ID: <1388888493.11.0.272349241718.issue19659@psf.upfronthosting.co.za> Larry Hastings added the comment: Doesn't help on Windows, junior! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 03:22:51 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 02:22:51 +0000 Subject: [issue20123] pydoc.synopsis fails to load binary modules In-Reply-To: <1388874425.94.0.221860493391.issue20123@psf.upfronthosting.co.za> Message-ID: <1388888571.8.0.240100851633.issue20123@psf.upfronthosting.co.za> Eric Snow added the comment: Not sure why I nosy'ed you, either. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 03:29:13 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 05 Jan 2014 02:29:13 +0000 Subject: [issue19927] Path-based loaders lack a meaningful __eq__() implementation. In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za> Message-ID: <1388888953.13.0.804807802232.issue19927@psf.upfronthosting.co.za> Larry Hastings added the comment: You broke buildbots. Please fix. http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x/builds/1389 ---------- assignee: -> eric.snow priority: normal -> high resolution: fixed -> stage: committed/rejected -> needs patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 03:32:17 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 05 Jan 2014 02:32:17 +0000 Subject: [issue19927] Path-based loaders lack a meaningful __eq__() implementation. In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za> Message-ID: <1388889137.96.0.309831422942.issue19927@psf.upfronthosting.co.za> Larry Hastings added the comment: Hmm, hard to see how you caused that with the path loader change. Still please take a quick look. I fired off another build to see if it was a transient error, but that'll take a while. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 03:45:12 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 02:45:12 +0000 Subject: [issue19927] Path-based loaders lack a meaningful __eq__() implementation. In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za> Message-ID: <1388889912.44.0.763925214046.issue19927@psf.upfronthosting.co.za> Eric Snow added the comment: I'll take a look. It could be something with #19713 or #19708 that also failed there. The other failing buildbot for those 3 changesets is http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/7800. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 03:47:42 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 05 Jan 2014 02:47:42 +0000 Subject: [issue20123] pydoc.synopsis fails to load binary modules In-Reply-To: <1388874425.94.0.221860493391.issue20123@psf.upfronthosting.co.za> Message-ID: <1388890062.43.0.165835361979.issue20123@psf.upfronthosting.co.za> R. David Murray added the comment: In 2.7 the code just does an open. Victor changed it to call tokenize.open in 3.2, but tokenize.open obviously only works on python source files. So the logic of that method is now completely wrong. I'm not sure the logic made a lot of sense even before...if the extension is binary it just closes it again. So the initial open is for its side effect of returning None if the file can't be opened. Anyway, the logic of that method clearly needs to be rewritten. And obviously there are some missing tests.... I don't see any patch attached to the issue, by the way. ---------- nosy: +haypo, r.david.murray versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 03:52:25 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 02:52:25 +0000 Subject: [issue20123] pydoc.synopsis fails to load binary modules In-Reply-To: <1388874425.94.0.221860493391.issue20123@psf.upfronthosting.co.za> Message-ID: <1388890345.72.0.271624833506.issue20123@psf.upfronthosting.co.za> Eric Snow added the comment: Thanks for taking a look. Here's the patch that I totally forget to attach. ---------- keywords: +patch Added file: http://bugs.python.org/file33311/issue20123-fix-pydoc-synopsis.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 04:00:23 2014 From: report at bugs.python.org (lotus@blossomhillranch.com) Date: Sun, 05 Jan 2014 03:00:23 +0000 Subject: [issue20126] sched doesn't handle events added after scheduler starts Message-ID: <1388890823.36.0.322424274213.issue20126@psf.upfronthosting.co.za> New submission from lotus at blossomhillranch.com: Events added after the scheduler is running, with a delay value before the next event, do not run at the correct time. import sched import time import threading def event( eventNum ): print( 'event', eventNum, time.time() ) s = sched.scheduler() s.enter( 0,1,event, (0,) ) s.enter(10,1,event, (1,) ) t = threading.Thread( target = s.run ) t.start() s.enter( 5,1,event, (2,) ) OUTPUT event 0 1388890197.7716181 event 2 1388890207.7340584 event 1 1388890207.7347224 ---------- messages: 207336 nosy: lotus at blossomhillranch.com priority: normal severity: normal status: open title: sched doesn't handle events added after scheduler starts type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 04:15:09 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 05 Jan 2014 03:15:09 +0000 Subject: [issue20123] pydoc.synopsis fails to load binary modules In-Reply-To: <1388874425.94.0.221860493391.issue20123@psf.upfronthosting.co.za> Message-ID: <1388891709.3.0.34224301299.issue20123@psf.upfronthosting.co.za> R. David Murray added the comment: Is it the case that given a filename, it might be possible to load a module even if open(filename) fails? I think the logic is clearer in the form where it is not pulled out into a separate helper function. You can avoid the double check on the extension by doing: if filename.endswith(importlib.machinery.BYTECODE_SUFFIXES): loader = importlib.machinery.SourcelessFileLoader('__temp__', filename) elif filename.endswith(importlib.machinery.EXTENSION_SUFFIXES): loader = importlib.machinery.ExtensionFileLoader('__temp__', filename) else: loader = None if loader: xxxxx else: xxxxx ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 04:18:14 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 03:18:14 +0000 Subject: [issue20127] Race condition in test_threaded_import.task()? Message-ID: <1388891894.47.0.893825432716.issue20127@psf.upfronthosting.co.za> New submission from Eric Snow: While looking at the logs of a buildbot failure [1], I took a look at Lib/test/test_threaded_import.py. In ThreadedImportTests.check_parallel_module_init() it makes a bunch of threaded calls to the module-level "task()" function. There may be a race condition in the finally clause of that function. I don't have a lot of time to investigate further right now, but I'll take a closer look when I get the chance. [1] http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/7800 ---------- components: Tests messages: 207338 nosy: eric.snow priority: normal severity: normal status: open title: Race condition in test_threaded_import.task()? type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 04:20:18 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 03:20:18 +0000 Subject: [issue19927] Path-based loaders lack a meaningful __eq__() implementation. In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za> Message-ID: <1388892018.92.0.467848089873.issue19927@psf.upfronthosting.co.za> Eric Snow added the comment: The windows buildbot failure looks like a race condition in a test unrelated to my changes (see issue #20127). I'm looking at the FreeBSD failure now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 04:21:43 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 03:21:43 +0000 Subject: [issue19927] Path-based loaders lack a meaningful __eq__() implementation. In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za> Message-ID: <1388892103.11.0.854003108682.issue19927@psf.upfronthosting.co.za> Eric Snow added the comment: Which passed on the subsequent run... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 04:30:35 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 03:30:35 +0000 Subject: [issue19927] Path-based loaders lack a meaningful __eq__() implementation. In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za> Message-ID: <1388892635.28.0.71964306344.issue19927@psf.upfronthosting.co.za> Eric Snow added the comment: The FreeBSD failure happened in test_threading (apparently), where it was the last test to "finish". In the passing run it finished 339/388 -- the seed was different (1253928 vs. 5389019). This does not seem to be related to my 3 changesets. I'm guessing it's one of those lingering race conditions we have sprinkled here and there. ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 04:31:09 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 05 Jan 2014 03:31:09 +0000 Subject: [issue1065986] Fix pydoc crashing on unicode strings Message-ID: <1388892669.23.0.791564107296.issue1065986@psf.upfronthosting.co.za> R. David Murray added the comment: Made some review comments. Looks good in general and it seems like the tests are fairly comprehensive. I haven't tried to run any additional experiments, but I don't see how it could make things worse, since the new code paths will only do something different if unicode objects are actually involved. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 04:40:07 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 05 Jan 2014 03:40:07 +0000 Subject: [issue20126] sched doesn't handle events added after scheduler starts In-Reply-To: <1388890823.36.0.322424274213.issue20126@psf.upfronthosting.co.za> Message-ID: <1388893207.81.0.777010077434.issue20126@psf.upfronthosting.co.za> R. David Murray added the comment: I believe this is a duplicate of issue 16165, which has already been fixed. ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> sched.scheduler.run() blocks scheduler _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 04:40:34 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 03:40:34 +0000 Subject: [issue20123] pydoc.synopsis fails to load binary modules In-Reply-To: <1388874425.94.0.221860493391.issue20123@psf.upfronthosting.co.za> Message-ID: <1388893234.28.0.0205894970257.issue20123@psf.upfronthosting.co.za> Eric Snow added the comment: Sounds good to me. Here's an updated patch. ---------- Added file: http://bugs.python.org/file33312/issue20123-fix-pydoc-synopsis.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 04:40:41 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 03:40:41 +0000 Subject: [issue20123] pydoc.synopsis fails to load binary modules In-Reply-To: <1388874425.94.0.221860493391.issue20123@psf.upfronthosting.co.za> Message-ID: <1388893241.71.0.208190692932.issue20123@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file33311/issue20123-fix-pydoc-synopsis.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 04:47:41 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 05 Jan 2014 03:47:41 +0000 Subject: [issue20123] pydoc.synopsis fails to load binary modules In-Reply-To: <1388874425.94.0.221860493391.issue20123@psf.upfronthosting.co.za> Message-ID: <1388893661.91.0.881064877506.issue20123@psf.upfronthosting.co.za> R. David Murray added the comment: Looks good, except you can replace those any calls with simple calls to endswith using a tuple of strings (I forgot the call to tuple in my example). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 04:58:39 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Jan 2014 03:58:39 +0000 Subject: [issue20123] pydoc.synopsis fails to load binary modules In-Reply-To: <1388874425.94.0.221860493391.issue20123@psf.upfronthosting.co.za> Message-ID: <3dxmL64htgz7Lnt@mail.python.org> Roundup Robot added the comment: New changeset d6c3fb8d5f84 by Eric Snow in branch 'default': Issue 20123: Fix pydoc.synopsis() for "binary" modules. http://hg.python.org/cpython/rev/d6c3fb8d5f84 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 04:59:42 2014 From: report at bugs.python.org (Martin Panter) Date: Sun, 05 Jan 2014 03:59:42 +0000 Subject: [issue19729] [regression] str.format sublevel format parsing broken in Python 3.3.3 In-Reply-To: <1385173002.6.0.538237708826.issue19729@psf.upfronthosting.co.za> Message-ID: <1388894382.18.0.0757853644515.issue19729@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 05:00:08 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 04:00:08 +0000 Subject: [issue20123] pydoc.synopsis fails to load binary modules In-Reply-To: <1388874425.94.0.221860493391.issue20123@psf.upfronthosting.co.za> Message-ID: <1388894408.2.0.693247919928.issue20123@psf.upfronthosting.co.za> Eric Snow added the comment: Ah, I missed that in your earlier suggestion. I followed your recommendation. Thanks for that. :) ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 05:44:01 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 04:44:01 +0000 Subject: [issue20123] pydoc.synopsis fails to load binary modules In-Reply-To: <1388874425.94.0.221860493391.issue20123@psf.upfronthosting.co.za> Message-ID: <1388897041.38.0.944451094663.issue20123@psf.upfronthosting.co.za> Eric Snow added the comment: This broke one of the FreeBSD buildbots: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%203.x/builds/6102 ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 06:05:37 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Jan 2014 05:05:37 +0000 Subject: [issue20123] pydoc.synopsis fails to load binary modules In-Reply-To: <1388874425.94.0.221860493391.issue20123@psf.upfronthosting.co.za> Message-ID: <3dxnqN4hLdz7Ll7@mail.python.org> Roundup Robot added the comment: New changeset ff3be21338d5 by Eric Snow in branch 'default': Issue 20123: try using a different builtin module in a pydoc test. http://hg.python.org/cpython/rev/ff3be21338d5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 06:29:25 2014 From: report at bugs.python.org (moijes12) Date: Sun, 05 Jan 2014 05:29:25 +0000 Subject: [issue724459] Add documentation about line endings in email messages. Message-ID: <1388899765.56.0.103057178677.issue724459@psf.upfronthosting.co.za> Changes by moijes12 : ---------- nosy: -moijes12 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 06:30:01 2014 From: report at bugs.python.org (moijes12) Date: Sun, 05 Jan 2014 05:30:01 +0000 Subject: [issue11681] -b option undocumented In-Reply-To: <1301100825.87.0.69977993755.issue11681@psf.upfronthosting.co.za> Message-ID: <1388899801.67.0.554440043761.issue11681@psf.upfronthosting.co.za> Changes by moijes12 : ---------- nosy: -moijes12 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 06:31:07 2014 From: report at bugs.python.org (moijes12) Date: Sun, 05 Jan 2014 05:31:07 +0000 Subject: [issue2679] email.feedparser regex duplicate In-Reply-To: <1209045140.34.0.682842030487.issue2679@psf.upfronthosting.co.za> Message-ID: <1388899867.53.0.315633383949.issue2679@psf.upfronthosting.co.za> Changes by moijes12 : ---------- nosy: -moijes12 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 06:32:00 2014 From: report at bugs.python.org (moijes12) Date: Sun, 05 Jan 2014 05:32:00 +0000 Subject: [issue16321] Move eq.h out of stringlib In-Reply-To: <1351157379.02.0.714048258846.issue16321@psf.upfronthosting.co.za> Message-ID: <1388899920.6.0.384622313228.issue16321@psf.upfronthosting.co.za> Changes by moijes12 : ---------- nosy: -moijes12 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 07:06:10 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Jan 2014 06:06:10 +0000 Subject: [issue20123] pydoc.synopsis fails to load binary modules In-Reply-To: <1388874425.94.0.221860493391.issue20123@psf.upfronthosting.co.za> Message-ID: <3dxq9G25wmz7Llr@mail.python.org> Roundup Robot added the comment: New changeset efcf163d04f5 by Eric Snow in branch 'default': Issue 20123: Disable a problematic test. http://hg.python.org/cpython/rev/efcf163d04f5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 07:08:58 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 06:08:58 +0000 Subject: [issue20123] pydoc.synopsis fails to load binary modules In-Reply-To: <1388874425.94.0.221860493391.issue20123@psf.upfronthosting.co.za> Message-ID: <1388902138.67.0.9903764997.issue20123@psf.upfronthosting.co.za> Eric Snow added the comment: I've run out of time to trouble-shoot the failure (specific to 1 buildbot). Until I can get back to it, I've disabled the problematic test (even though it's only a problem on 1 buildbot). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 07:31:55 2014 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Sun, 05 Jan 2014 06:31:55 +0000 Subject: [issue20120] Percent-signs (%) in .pypirc should not be interpolated In-Reply-To: <1388825675.42.0.435893533792.issue20120@psf.upfronthosting.co.za> Message-ID: <1388903515.9.0.651499273419.issue20120@psf.upfronthosting.co.za> ?ukasz Langa added the comment: Yes, that's wontfix but we can make the error message more friendly so I'll leave this open. The .pypirc parser should have been RawConfigParser from the start, the interpolation mechanism is obscure enough it's probably not used. Unfortunately this "probably" means we cannot easily switch it to RawConfigParser now. ---------- assignee: -> lukasz.langa versions: +Python 3.5 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 08:10:27 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 07:10:27 +0000 Subject: [issue20128] Re-enable test_modules_search_builtin() in test_pydoc Message-ID: <1388905827.82.0.948519018287.issue20128@psf.upfronthosting.co.za> New submission from Eric Snow: The test (added in issue #20123) broke one of the stable FreeBSD buildbots: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%203.x/builds/6102 The log for that test run indicates the traceback and the test can be found in Lib/test/test_pydoc.py (PydocImportTest.test_modules_search_builtin). The problem could be one (or more) of several possibilities: * the test is broken in an esoteric way * the buildbot has issues * the platform has issues * the test exposes some other underlying bug elsewhere The test itself is not critical but I hope to re-enable it before beta 2 ends in a couple weeks. Stefan: any insight you could offer on the problem, particularly relative to the platform and buildbot, would be greatly appreciated. ---------- assignee: eric.snow components: Tests messages: 207353 nosy: eric.snow, skrah priority: high severity: normal stage: needs patch status: open title: Re-enable test_modules_search_builtin() in test_pydoc type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 08:11:50 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 07:11:50 +0000 Subject: [issue20123] pydoc.synopsis fails to load binary modules In-Reply-To: <1388874425.94.0.221860493391.issue20123@psf.upfronthosting.co.za> Message-ID: <1388905910.04.0.176605753433.issue20123@psf.upfronthosting.co.za> Eric Snow added the comment: The buildbot is happy again. I'll address fixing that test in issue #20128. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 08:12:17 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 07:12:17 +0000 Subject: [issue19927] Path-based loaders lack a meaningful __eq__() implementation. In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za> Message-ID: <1388905937.69.0.284837459147.issue19927@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 08:12:51 2014 From: report at bugs.python.org (Martin Panter) Date: Sun, 05 Jan 2014 07:12:51 +0000 Subject: [issue11681] -b option undocumented In-Reply-To: <1301100825.87.0.69977993755.issue11681@psf.upfronthosting.co.za> Message-ID: <1388905971.76.0.623818231163.issue11681@psf.upfronthosting.co.za> Martin Panter added the comment: Try this to trigger a warning: python2 -b -c 'bytearray("3") == u"3"' -c:1: BytesWarning: Comparison between bytearray and string ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 08:14:32 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 05 Jan 2014 07:14:32 +0000 Subject: [issue20123] pydoc.synopsis fails to load binary modules In-Reply-To: <1388874425.94.0.221860493391.issue20123@psf.upfronthosting.co.za> Message-ID: <1388906072.94.0.0896484091537.issue20123@psf.upfronthosting.co.za> Larry Hastings added the comment: Thanks for seeing this through, Eric. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 08:20:12 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 07:20:12 +0000 Subject: [issue19703] Update pydoc to PEP 451 In-Reply-To: <1386308732.16.0.241139477522.issue19703@psf.upfronthosting.co.za> Message-ID: <1388906412.34.0.780449638546.issue19703@psf.upfronthosting.co.za> Eric Snow added the comment: Here's a slightly updated patch. ---------- assignee: -> eric.snow stage: -> patch review type: -> enhancement Added file: http://bugs.python.org/file33313/issue19703-use-new-api.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 08:20:24 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 07:20:24 +0000 Subject: [issue19703] Update pydoc to PEP 451 In-Reply-To: <1386308732.16.0.241139477522.issue19703@psf.upfronthosting.co.za> Message-ID: <1388906424.29.0.776725566782.issue19703@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file33310/issue19703-use-new-api.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 08:22:34 2014 From: report at bugs.python.org (Armin Rigo) Date: Sun, 05 Jan 2014 07:22:34 +0000 Subject: [issue20115] NUL bytes in commented lines In-Reply-To: <1388771953.42.0.332804570753.issue20115@psf.upfronthosting.co.za> Message-ID: <1388906554.64.0.575753619874.issue20115@psf.upfronthosting.co.za> Armin Rigo added the comment: Fwiw, both exec and eval() ban NUL bytes, which means that there is a strange case in which some files can be imported, but not loaded and exec'ed. So I agree with Benjamin. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 08:24:05 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 07:24:05 +0000 Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451 In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za> Message-ID: <1388906645.63.0.591349616283.issue19713@psf.upfronthosting.co.za> Eric Snow added the comment: Okay, there were a few lingering changes (mostly related to importlib.find_loader). Here's a patch. ---------- Added file: http://bugs.python.org/file33314/issue19713-more-API-adjustments.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 08:38:17 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 07:38:17 +0000 Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451 In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za> Message-ID: <1388907497.1.0.476525919422.issue19713@psf.upfronthosting.co.za> Eric Snow added the comment: Here's a patch that should round out the changes for this ticket, adding the various deprecation warnings. Most of the patch involves silencing warnings or cleaning up importlib tests relative to the deprecated APIs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 08:38:57 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 07:38:57 +0000 Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451 In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za> Message-ID: <1388907537.89.0.564542259475.issue19713@psf.upfronthosting.co.za> Eric Snow added the comment: ...and the patch. ---------- Added file: http://bugs.python.org/file33315/issue19713-deprecation-warnings.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 08:39:07 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 07:39:07 +0000 Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451 In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za> Message-ID: <1388907547.75.0.538158789475.issue19713@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- dependencies: +Check pkgutil for anything missing for PEP 451 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 08:39:18 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 07:39:18 +0000 Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451 In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za> Message-ID: <1388907558.97.0.269641819309.issue19713@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file33202/issue19713-deprecation-warnings.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 08:39:53 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 07:39:53 +0000 Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451 In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za> Message-ID: <1388907593.21.0.136577530817.issue19713@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- assignee: -> eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 08:45:32 2014 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 05 Jan 2014 07:45:32 +0000 Subject: [issue20129] 3.4 on windows 7 can't import IntEnum Message-ID: <1388907932.96.0.334255876283.issue20129@psf.upfronthosting.co.za> New submission from Mark Lawrence: c:\Users\Mark\CrossCode>py -3.4 -c "from enum import IntEnum" Traceback (most recent call last): File "", line 1, in ImportError: cannot import name 'IntEnum' I had earlier tried to install the complete 3.4 setup on Windows 7 but, for the first time that I'd ever seen, the installation rolled back. So I installed without pip and then ran this command "py -3.4 -m ensurepip" which gave me this:- Traceback (most recent call last): File "C:\Python34\lib\runpy.py", line 160, in _run_module_as_main "__main__", fname, loader, pkg_name) File "C:\Python34\lib\runpy.py", line 73, in _run_code exec(code, run_globals) File "C:\Python34\lib\ensurepip\__main__.py", line 66, in main() File "C:\Python34\lib\ensurepip\__main__.py", line 61, in main default_pip=args.default_pip, File "C:\Python34\lib\ensurepip\__init__.py", line 92, in bootstrap _run_pip(args + [p[0] for p in _PROJECTS], additional_paths) File "C:\Python34\lib\ensurepip\__init__.py", line 28, in _run_pip import pip File "C:\Users\Mark\AppData\Local\Temp\tmpysmgllcx\pip-1.5.rc1-py2.py3-none-any.whl\pip\__init__.py", line 9, in File "C:\Users\Mark\AppData\Local\Temp\tmpysmgllcx\pip-1.5.rc1-py2.py3-none-any.whl\pip\backwardcompat\__init__.py", lin File "C:\Python34\lib\urllib\request.py", line 88, in import http.client File "C:\Python34\lib\http\client.py", line 69, in import email.parser File "C:\Python34\lib\email\parser.py", line 13, in from email.feedparser import FeedParser, BytesFeedParser File "C:\Python34\lib\email\feedparser.py", line 27, in from email import message File "C:\Python34\lib\email\message.py", line 14, in from email import utils File "C:\Python34\lib\email\utils.py", line 30, in import socket File "C:\Python34\lib\socket.py", line 51, in from enum import IntEnum ImportError: cannot import name 'IntEnum' I suspect my installation is corrupt somehow but thought it safer to flag this just in case. ---------- components: Library (Lib) messages: 207362 nosy: BreamoreBoy priority: normal severity: normal status: open title: 3.4 on windows 7 can't import IntEnum type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 08:53:51 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 05 Jan 2014 07:53:51 +0000 Subject: [issue20122] Move CallTips tests to idle_tests In-Reply-To: <1388852698.51.0.14863260737.issue20122@psf.upfronthosting.co.za> Message-ID: <1388908431.16.0.760214865696.issue20122@psf.upfronthosting.co.za> Terry J. Reedy added the comment: It is a good idea to make this a separate patch;-). Will look carefully after sleep. ---------- assignee: -> terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 08:58:54 2014 From: report at bugs.python.org (Akira Kitada) Date: Sun, 05 Jan 2014 07:58:54 +0000 Subject: [issue1065986] Fix pydoc crashing on unicode strings Message-ID: <1388908734.51.0.120698196104.issue1065986@psf.upfronthosting.co.za> Akira Kitada added the comment: Made a few more adjustments to fix things r.david.murray pointed out. ---------- Added file: http://bugs.python.org/file33316/issue1065986-6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 08:59:33 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 05 Jan 2014 07:59:33 +0000 Subject: [issue19944] Make importlib.find_spec load packages as needed In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za> Message-ID: <1388908773.19.0.731467584663.issue19944@psf.upfronthosting.co.za> Eric Snow added the comment: Brett: What do you think about moving importlib.find_spec() to importlib.util? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 09:13:38 2014 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 05 Jan 2014 08:13:38 +0000 Subject: [issue20129] 3.4 on windows 7 can't import IntEnum In-Reply-To: <1388907932.96.0.334255876283.issue20129@psf.upfronthosting.co.za> Message-ID: <1388909618.01.0.639907902908.issue20129@psf.upfronthosting.co.za> Mark Lawrence added the comment: Bah humbug just found an old enum.py file hanging around. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 09:23:54 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 05 Jan 2014 08:23:54 +0000 Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451 In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za> Message-ID: <1388910234.29.0.0971198262965.issue19713@psf.upfronthosting.co.za> Larry Hastings added the comment: I can accept the fourth patch in its current state. Is that a rollup patch, including all the previous patches, or is it independent? Is there a patch I can look at for this new API? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 11:22:35 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 05 Jan 2014 10:22:35 +0000 Subject: [issue20130] asyncio: implement a synchronous executor if concurrent.futures is missing Message-ID: <1388917355.05.0.21952188677.issue20130@psf.upfronthosting.co.za> New submission from STINNER Victor: On old FreeBSD platforms (FreeBSD 6), concurrent.futures cannot be used and fail with an ImportError because of a limit on POSIX semaphores: see issue #10798. (See also maybe issue #10348 "multiprocessing: use SysV semaphores on FreeBSD" closed as WONTFIX.) For asyncio, the test is currently skipped on this platform: see issue #19635. (See also maybe issue #19295 "Make asyncio work without threads" closed as WONTFIX.) I propose to implement a simple fallback using an synchronous executor (block until we get the result) which would be used by getaddrinfo() and getnameinfo() methods of EventLoop. This issue is also motivated by my Trollius project, a backport of asyncio for Python 2.7, where concurrent.futures is not available. An optional backport, the "futures" project, can be used: https://pypi.python.org/pypi/futures Attached patch is a work-in-progress, it removes the dependency to concurrent.futures but doesn't implement the synchronous executor yet. It's the changes I wrote in Trollius 0.1. https://pypi.python.org/pypi/trollius ---------- files: asyncio_sync.patch keywords: patch messages: 207368 nosy: gvanrossum, haypo priority: normal severity: normal status: open title: asyncio: implement a synchronous executor if concurrent.futures is missing versions: Python 3.4 Added file: http://bugs.python.org/file33317/asyncio_sync.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 11:27:48 2014 From: report at bugs.python.org (Stefan Krah) Date: Sun, 05 Jan 2014 10:27:48 +0000 Subject: [issue20128] Re-enable test_modules_search_builtin() in test_pydoc In-Reply-To: <1388905827.82.0.948519018287.issue20128@psf.upfronthosting.co.za> Message-ID: <20140105102747.GA25850@sleipnir.bytereef.org> Stefan Krah added the comment: The buildbot runs --without-doc-strings. Usually you just have to add the @requires_docstrings decorator to some tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 12:31:30 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jan 2014 11:31:30 +0000 Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3 In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za> Message-ID: <1388921490.42.0.398499551215.issue13153@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: As far as the patch becomes too complicated, I propose minimalist patch which fixes only this issue. I.e. IDLE will no longer silently closed when paste some unusual text (non-BMP on Windows or illegal UTF-8 on Linux). It fixes converting Tcl string to Python string for arguments of Python callback. \xc0\x80 is translated to the NUL character (U+0000) because Tcl uses "modified" UTF-8. All other illegal UTF-8 codes are replaced by the replacement character (U+FFFD). ---------- Added file: http://bugs.python.org/file33318/tkinter_pythoncmd_args.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 13:06:39 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Sun, 05 Jan 2014 12:06:39 +0000 Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3 In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za> Message-ID: <1388923599.05.0.646745188086.issue13153@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I completely lost track which problem is being solved here. Is it still "IDLE crashes when pasting non-BMP unicode char on Py3"? If so, how is this patch solving it? IMO, the issue shouhldn't have been reopened. Instead, a new issue should have started. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 13:39:29 2014 From: report at bugs.python.org (Andreas Kloeckner) Date: Sun, 05 Jan 2014 12:39:29 +0000 Subject: [issue20131] warnings module offers no documented, programmatic way to reset "seen-warning" flag Message-ID: <1388925569.4.0.616104920228.issue20131@psf.upfronthosting.co.za> New submission from Andreas Kloeckner: For tests and doctests, it is often desirable to show or verify that a certain warning occurs. Unfortunately, if the warning has been hit previously, it will not be issued again. It would be great if there were a documented, unified way to reset this 'seen' flag. Related stackoverflow posts showing that I'm not the first person to have this need: * https://stackoverflow.com/questions/19428761/python-showing-once-warnings-again-resetting-all-warning-registries * https://stackoverflow.com/questions/2418570/testing-warnings-with-doctest Neither of these has a satisfactory solution. ---------- components: Library (Lib) messages: 207372 nosy: inducer priority: normal severity: normal status: open title: warnings module offers no documented, programmatic way to reset "seen-warning" flag versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 13:39:43 2014 From: report at bugs.python.org (Andreas Kloeckner) Date: Sun, 05 Jan 2014 12:39:43 +0000 Subject: [issue20131] warnings module offers no documented, programmatic way to reset "seen-warning" flag In-Reply-To: <1388925569.4.0.616104920228.issue20131@psf.upfronthosting.co.za> Message-ID: <1388925583.87.0.622909306535.issue20131@psf.upfronthosting.co.za> Changes by Andreas Kloeckner : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 14:11:34 2014 From: report at bugs.python.org (Martin Panter) Date: Sun, 05 Jan 2014 13:11:34 +0000 Subject: [issue19524] ResourceWarning when urlopen() forgets the HTTPConnection object In-Reply-To: <1383882317.08.0.635493267684.issue19524@psf.upfronthosting.co.za> Message-ID: <1388927494.28.0.630177295795.issue19524@psf.upfronthosting.co.za> Martin Panter added the comment: The Issue 12692 fix has been backported to the 3.3 branch, and it fixes this bug. However here is an updated patch (against revision 28337a8fb502 in the ?3.3? branch) consisting of two left over bits you might still want to use: 1. My test case 2. Explicitly closing the HTTP connection when an invalid response is received. E.g. urlopen("http://google.com:443") would still leak the connection without this. ---------- Added file: http://bugs.python.org/file33319/test+except-close.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 14:31:14 2014 From: report at bugs.python.org (Martin Panter) Date: Sun, 05 Jan 2014 13:31:14 +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: <1388928674.81.0.0099512813253.issue13881@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 14:48:58 2014 From: report at bugs.python.org (Martin Panter) Date: Sun, 05 Jan 2014 13:48:58 +0000 Subject: =?utf-8?q?=5Bissue20132=5D_Many_incremental_codecs_don=E2=80=99t_handle_f?= =?utf-8?q?ragmented_data?= Message-ID: <1388929738.44.0.851837204966.issue20132@psf.upfronthosting.co.za> New submission from Martin Panter: Many of the incremental codecs do not handle fragmented data very well. In the past I think I was interested in using the Base-64 and Quoted-printable codecs, and playing with other codecs today reveals many more issues. A lot of the issues reflect missing functionality, so maybe the simplest solution would be to document the codecs that don?t work. Incremental decoding issues: >>> str().join(codecs.iterdecode(iter((b"\\", b"u2013")), "unicode-escape")) UnicodeDecodeError: 'unicodeescape' codec can't decode byte 0x5c in position 0: \ at end of string # Same deal for raw-unicode-escape. >>> bytes().join(codecs.iterdecode(iter((b"3", b"3")), "hex-codec")) binascii.Error: Odd-length string >>> bytes().join(codecs.iterdecode(iter((b"A", b"A==")), "base64-codec")) binascii.Error: Incorrect padding >>> bytes().join(codecs.iterdecode(iter((b"=", b"3D")), "quopri-codec")) b'3D' # Should return b"=" >>> codecs.getincrementaldecoder("uu-codec")().decode(b"begin ") ValueError: Truncated input data Incremental encoding issues: >>> e = codecs.getincrementalencoder("base64-codec")(); codecs.decode(e.encode(b"1") + e.encode(b"2", final=True), "base64-codec") b'1' # Should be b"12" >>> e = codecs.getincrementalencoder("quopri-codec")(); e.encode(b"1" * 50) + e.encode(b"2" * 50, final=True) b'1111111111111111111111111111111111111111111111111122222222222222222222222222222222222222222222222222' # I suspect the line should have been split in two >>> e = codecs.getincrementalencoder("uu-codec")(); codecs.decode(e.encode(b"1") + e.encode(b"2", final=True), "uu-codec") b'1' # Should be b"12" I also noticed iterdecode() does not work with ?uu-codec?: >>> bytes().join(codecs.iterdecode(iter((b"begin 666 \n \nend\n",)), "uu-codec")) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.3/codecs.py", line 1032, in iterdecode output = decoder.decode(b"", True) File "/usr/lib/python3.3/encodings/uu_codec.py", line 80, in decode return uu_decode(input, self.errors)[0] File "/usr/lib/python3.3/encodings/uu_codec.py", line 45, in uu_decode raise ValueError('Missing "begin" line in input data') ValueError: Missing "begin" line in input data And iterencode() does not work with any of the byte encoders, because it does not know what kind of empty string to pass to IncrementalEncoder.encode(final=True): >>> bytes().join(codecs.iterencode(iter(()), "base64-codec")) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.3/codecs.py", line 1014, in iterencode output = encoder.encode("", True) File "/usr/lib/python3.3/encodings/base64_codec.py", line 31, in encode return base64.encodebytes(input) File "/usr/lib/python3.3/base64.py", line 343, in encodebytes raise TypeError("expected bytes, not %s" % s.__class__.__name__) TypeError: expected bytes, not str Finally, incremental UTF-7 encoding is suboptimal, and the decoder seems to buffer unlimited data, both defeating the purpose of using an incremental codec: >>> bytes().join(codecs.iterencode("\xA9" * 2, "utf-7")) b'+AKk-+AKk-' # b"+AKkAqQ-" would be better >>> d = codecs.getincrementaldecoder("utf-7")() >>> d.decode(b"+") b'' >>> any(d.decode(b"AAAAAAAA" * 100000) for _ in range(10)) False # No data returned: everything must be buffered >>> d.decode(b"-") == "\x00" * 3000000 True # Returned all buffered data in one go ---------- components: Library (Lib) messages: 207374 nosy: vadmium priority: normal severity: normal status: open title: Many incremental codecs don?t handle fragmented data type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 14:49:32 2014 From: report at bugs.python.org (Martin Panter) Date: Sun, 05 Jan 2014 13:49:32 +0000 Subject: [issue8796] Deprecate codecs.open() In-Reply-To: <1274642875.55.0.470910509558.issue8796@psf.upfronthosting.co.za> Message-ID: <1388929772.15.0.363063182916.issue8796@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 14:51:51 2014 From: report at bugs.python.org (Martin Panter) Date: Sun, 05 Jan 2014 13:51:51 +0000 Subject: [issue19548] 'codecs' module docs improvements In-Reply-To: <1384133353.82.0.173341188397.issue19548@psf.upfronthosting.co.za> Message-ID: <1388929911.53.0.307323221469.issue19548@psf.upfronthosting.co.za> Martin Panter added the comment: Addition to the list of improvements: * Under codecs.IncrementalEncoder.reset() it mentions calling encode('', final=True). This call does not work as written for the byte encoders in my experience, because they do not accept empty text strings. Perhaps it should just say to use the final=True flag with no data. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 15:05:16 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Sun, 05 Jan 2014 14:05:16 +0000 Subject: [issue19885] lzma segfault when __init__ with non-existent file after executing the constructor (Python 2.7) In-Reply-To: <1386174826.17.0.707477231335.issue19885@psf.upfronthosting.co.za> Message-ID: <1388930716.28.0.60831496238.issue19885@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Okay, sorry guys. The python 2.7 lzma binding is Fedora specific one. I already submitted bug there: https://bugzilla.redhat.com/show_bug.cgi?id=1048581 ---------- resolution: -> invalid status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 15:05:47 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Sun, 05 Jan 2014 14:05:47 +0000 Subject: [issue19885] lzma segfault when __init__ with non-existent file after executing the constructor (Python 2.7) In-Reply-To: <1386174826.17.0.707477231335.issue19885@psf.upfronthosting.co.za> Message-ID: <1388930747.98.0.19193860136.issue19885@psf.upfronthosting.co.za> Changes by Vajrasky Kok : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 15:43:11 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 Jan 2014 14:43:11 +0000 Subject: [issue20130] asyncio: implement a synchronous executor if concurrent.futures is missing In-Reply-To: <1388917355.05.0.21952188677.issue20130@psf.upfronthosting.co.za> Message-ID: <1388932991.07.0.40231787224.issue20130@psf.upfronthosting.co.za> Antoine Pitrou added the comment: That doesn't sound like a very good idea, only to support FreeBSD 6. Synchronous execution blocks the event loop waiting for I/O, which basically destroys the point of having an event loop. Let users of FreeBSD 6 upgrade their systems instead, IMHO. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 15:50:39 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Jan 2014 14:50:39 +0000 Subject: [issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za> Message-ID: <3dy2pQ2W2rz7LpF@mail.python.org> Roundup Robot added the comment: New changeset 2f81f0e331f6 by Ethan Furman in branch 'default': Issue19995: %o, %x, %X now only accept ints http://hg.python.org/cpython/rev/2f81f0e331f6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 15:54:59 2014 From: report at bugs.python.org (Ethan Furman) Date: Sun, 05 Jan 2014 14:54:59 +0000 Subject: [issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za> Message-ID: <1388933699.08.0.0258275863645.issue19995@psf.upfronthosting.co.za> Ethan Furman added the comment: I was travelling yesterday and wasn't sure about the time stamp. Looks like I missed the 12-hour cutoff. Let me know if I should backout the commit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 16:13:02 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 Jan 2014 15:13:02 +0000 Subject: [issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za> Message-ID: <1388934782.82.0.648852491976.issue19995@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ethan, I thought we were going the deprecation route? This *will* break code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 16:13:57 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jan 2014 15:13:57 +0000 Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3 In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za> Message-ID: <1388934837.13.0.747874201547.issue13153@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, it is still the same issue. The root of issue is in converting strings when passed to Python-implemented callbacks. When a text is pasted in IDLE window, the callback is called (for highlighting). The callback is a command created by Tcl_CreateCommand from PythonCmd. PythonCmd is a wrapper which converts arguments (char*) to Python strings and then pass them to Python command. Arguments are encoded in "modified UTF-8" [1], i.e. the NUL character is represented as \xc0\x80, they can contains other invalid UTF-8 sequences (such as encoded surrogates). When decoding arguments to Python strings are failed, main Tcl loop is broken and IDLE silently closed. When astral character is pasted on Windows, it first encoded to UTF-16 by Windows, then Tcl encodes every 16-bit surrogate to modified UTF-8. The result is not valid UTF-8. On X Window systems the X selection value usually is UTF-8 encoded (the type is UTF8_STRING), but can contains invalid UTF-8 sequences. I will open separate issue to fix other bugs related to Tcl <-> Python string conversions. The last patch fixes only initial issue which is most important. [1] http://en.wikipedia.org/wiki/UTF-8#Modified_UTF-8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 16:13:57 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 Jan 2014 15:13:57 +0000 Subject: [issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za> Message-ID: <1388934837.38.0.624771701456.issue19995@psf.upfronthosting.co.za> Antoine Pitrou added the comment: (also, there are typos: "shuld", "psuedo") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 16:16:19 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jan 2014 15:16:19 +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: <1388934979.18.0.129740081184.issue20132@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +doerwalter, haypo, lemburg, loewis, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 16:17:23 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jan 2014 15:17:23 +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: <1388935043.82.0.375847123061.issue13881@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +doerwalter, lemburg, loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 16:18:01 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jan 2014 15:18:01 +0000 Subject: [issue19548] 'codecs' module docs improvements In-Reply-To: <1384133353.82.0.173341188397.issue19548@psf.upfronthosting.co.za> Message-ID: <1388935081.45.0.232040455326.issue19548@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +doerwalter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 16:20:53 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 05 Jan 2014 15:20:53 +0000 Subject: [issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za> Message-ID: <1388935253.87.0.582022757676.issue19995@psf.upfronthosting.co.za> Larry Hastings added the comment: Antoine: I made the call to bite the bullet and fix it. If that's a terrible idea we can change it before RC1. But from my (admittedly dim) understanding of the issue, we're going to have to fix this sooner or later, and sooner is probably better. If by permitting this I've made a terrible mistake, could you do me a favor and summarize the issue and the alternatives so I can understand it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 16:37:03 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 05 Jan 2014 15:37:03 +0000 Subject: [issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za> Message-ID: <1388936223.25.0.815072080031.issue19995@psf.upfronthosting.co.za> Larry Hastings added the comment: And, yes, Ethan's checkin missed the cutoff for beta 2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 16:38:03 2014 From: report at bugs.python.org (Ethan Furman) Date: Sun, 05 Jan 2014 15:38:03 +0000 Subject: [issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za> Message-ID: <1388936283.78.0.107419623278.issue19995@psf.upfronthosting.co.za> Ethan Furman added the comment: I think the code-breakage issue is that although this is a bug now, it did not use to be a bug. (Or maybe it was always a bug, but nobody noticed -- I don't know when hex() and oct() were introduced.) Basically, having %o and %x work with floats was the intended behavior, as there were tests to make sure it worked. But hex() and oct() were designed to only work with integer types, resulting in two ways to get an octal or hexadecimal string, one of which worked with non-ints, and one which didn't. tarfile.py, for example, was using %o to convert a stat member (a timestamp?) from int/float to octal. It is agreed that working with non-ints is no longer the intended behavior, but there is undoubtedly code that uses it -- especially in cases where the return value could be either an int or a float. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 18:24:36 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 05 Jan 2014 17:24:36 +0000 Subject: [issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za> Message-ID: <1388942676.56.0.580662663008.issue19995@psf.upfronthosting.co.za> R. David Murray added the comment: Given that even the stdlib used it, there is no question in my mind that a deprecation period is required. We don't just arbitrarily break peoples code on purpose, we give them at least a release in which to fix it first. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 18:30:01 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 Jan 2014 17:30:01 +0000 Subject: [issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za> Message-ID: <1388943001.74.0.429464180519.issue19995@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Keep in mind that with new-style division, it's easy to get a float even if all your inputs are ints. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 19:11:52 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 05 Jan 2014 18:11:52 +0000 Subject: [issue20130] asyncio: implement a synchronous executor if concurrent.futures is missing In-Reply-To: <1388932991.07.0.40231787224.issue20130@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: 2014/1/5 Antoine Pitrou : > That doesn't sound like a very good idea, only to support FreeBSD 6. Well, if the patch is rejected here, I will propose it in Tulip, or I will keep it only in Trollius (the port on Python 2.7). The idea of this issue was discussed on the python-tulip group and approved by Guido van Rossum: https://groups.google.com/forum/#!msg/python-tulip/1CbjmZTXINM/pR-_CVga7bUJ > Synchronous execution blocks the event loop waiting for I/O, which basically destroys the point of having an event loop. asyncio only uses the executor to resolve host names. Resolution is usually fast, and you may only resolve a name once at startup. But I agree that it's slower than supporting asynchronous resolution. I hope that asyncio will get its down asynchronous DNS resolver! There are existing projects: https://pyuv.readthedocs.org/en/release-0.6.1/dns.html (Asynchronous DNS resolver using c-ares for pyuv) http://code.google.com/p/asyncdns/ https://code.google.com/p/adns-python/ (Python interface to GNU adns asynchronous resolver library) etc. > Let users of FreeBSD 6 upgrade their systems instead, IMHO. Well, sometimes you don't have the choice of your OS :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 19:15:13 2014 From: report at bugs.python.org (Ethan Furman) Date: Sun, 05 Jan 2014 18:15:13 +0000 Subject: [issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za> Message-ID: <1388945713.27.0.33883757707.issue19995@psf.upfronthosting.co.za> Ethan Furman added the comment: I'll switch it to a deprecation warning instead sometime this week. The changes to datamodel.rst and tarfile.py should stay, I think. test_format and test_unicode will both verify current* behavior and check for the deprecation warning, and unicodeobject.c will generate the warning but keep current behavior. Once 3.5 is tagged I'll put the updates to these three files there. * By 'current' I mean accepting non-ints. ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 19:30:51 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 05 Jan 2014 18:30:51 +0000 Subject: [issue20131] warnings module offers no documented, programmatic way to reset "seen-warning" flag In-Reply-To: <1388925569.4.0.616104920228.issue20131@psf.upfronthosting.co.za> Message-ID: <1388946651.9.0.144682128487.issue20131@psf.upfronthosting.co.za> R. David Murray added the comment: The easy answer for unittest is to use assertWarns. For versions where that doesn't exist you could implement the same technique yourself. Exposing a 'clear everything' function in the warnings module might not be a bad idea, but otherwise for doctest I'd think the catch_warnings context manager would be the correct answer, and that is documented. Given the above, I guess this issue is a request to expose a "clear everything" function in the warnings module, which I think is a reasonable idea. (I think it would be nice to add some support stuff to doctest to make things like this easier, but that is a totally separate issue.) ---------- nosy: +brett.cannon, r.david.murray versions: +Python 3.5 -Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 20:04:58 2014 From: report at bugs.python.org (lotus@blossomhillranch.com) Date: Sun, 05 Jan 2014 19:04:58 +0000 Subject: [issue20126] sched doesn't handle events added after scheduler starts In-Reply-To: <1388890823.36.0.322424274213.issue20126@psf.upfronthosting.co.za> Message-ID: <1388948698.71.0.816381510922.issue20126@psf.upfronthosting.co.za> lotus at blossomhillranch.com added the comment: i saw that issue before i submitted this one, but it says it was fixed a year ago. i assumed a patch from a year ago would be in 3.3.1. when i see an issue closed with a patch accepted, how do i determine which python version will contain that patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 20:06:20 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 05 Jan 2014 19:06:20 +0000 Subject: [issue20130] asyncio: implement a synchronous executor if concurrent.futures is missing In-Reply-To: <1388917355.05.0.21952188677.issue20130@psf.upfronthosting.co.za> Message-ID: <1388948780.74.0.227549081382.issue20130@psf.upfronthosting.co.za> STINNER Victor added the comment: Here is an implementation of a synchrounous executor: https://bitbucket.org/haypo/trollius/commits/1bc2c23854e6717007a5a6df42470afa49c79b99 The changes are larger than what I expected. On Python 3.4, if concurrent.futures is only missing on FreeBSD 6, I agree that it's ok to ask users to upgrade their OS. @Guido: Are you interested by this change, since Tulip requires at least Python 3.3 which has also concurrent.futures? The fallback is probably only needed by the Trollius project in practice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 20:13:08 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 05 Jan 2014 19:13:08 +0000 Subject: [issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za> Message-ID: <1388949188.2.0.226652352273.issue19995@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Merely from reading the docs, including the hex() and {}.format sections, I consider the current '%x' % 1.5 == '1' a bug in that I would expect either a Type or Value Error or a hex fraction(!) ('1,8') matching the core of the output of float.hex(1.5). But given the history, I agree that a deprecation notice is needed first. In 3.3 section 6.1.3.1. Format Specification Mini-Language, integer and float conversions are in separate tables, so no confusion is possible. In 3.3 section 4.7.2. printf-style String Formatting there is just one table with all conversion chars. I think the table would be clearer if it were somehow split into three sections: perhaps 3 otherwise blank rows containing 'integer', 'float', and 'other' in the Conversion column. (I don't know if this works for .rst tables.) I think I would change the table for 3.4 with a note 8 that 'o', 'x', and 'X' currently accept floats by calling int() on the value, but that this implicit behavior is deprecated, so one should be explicit. The DeprecationWarning should also give the same remedy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 20:16:43 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 Jan 2014 19:16:43 +0000 Subject: [issue20130] asyncio: implement a synchronous executor if concurrent.futures is missing In-Reply-To: <1388948780.74.0.227549081382.issue20130@psf.upfronthosting.co.za> Message-ID: <1388949400.2272.0.camel@fsol> Antoine Pitrou added the comment: > Here is an implementation of a synchrounous executor: > https://bitbucket.org/haypo/trollius/commits/1bc2c23854e6717007a5a6df42470afa49c79b99 Where is executor.py? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 20:23:47 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 05 Jan 2014 19:23:47 +0000 Subject: [issue20130] asyncio: implement a synchronous executor if concurrent.futures is missing In-Reply-To: <1388917355.05.0.21952188677.issue20130@psf.upfronthosting.co.za> Message-ID: <1388949827.08.0.124676942072.issue20130@psf.upfronthosting.co.za> STINNER Victor added the comment: > Where is executor.py? Hum, maybe I forgot to push it :-) https://bitbucket.org/haypo/trollius/src/tip/asyncio/executor.py?at=trollius Code of the synchronous executor: https://bitbucket.org/haypo/trollius/src/8f28756d63c2c9f09c3a7c1df420796eca9ff08b/asyncio/executor.py?at=trollius#cl-60 I only defined methods used by asyncio. I didn't try to implement the full API (ex: it's not possible to cancel a Future). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 20:27:44 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 05 Jan 2014 19:27:44 +0000 Subject: [issue20130] asyncio: implement a synchronous executor if concurrent.futures is missing In-Reply-To: <1388949827.08.0.124676942072.issue20130@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > https://bitbucket.org/haypo/trollius/src/8f28756d63c2c9f09c3a7c1df420796eca9ff08b/asyncio/executor.py?at=trollius#cl-60 Oh, there was a forgotten "raise" instruction. I added it to test the exception case, but it looks like this case is not tested by asyncio test suite. (I just removed the "raise" instruction.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 20:46:30 2014 From: report at bugs.python.org (Matthias Klose) Date: Sun, 05 Jan 2014 19:46:30 +0000 Subject: [issue1322] platform.dist() has unpredictable result under Linux In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za> Message-ID: <1388951190.05.0.4128482863.issue1322@psf.upfronthosting.co.za> Matthias Klose added the comment: Victor, what should be returned if the code name is not set? None, empty string, or the description field of the lsb-release file? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 21:21:36 2014 From: report at bugs.python.org (Stefan Krah) Date: Sun, 05 Jan 2014 20:21:36 +0000 Subject: [issue19732] python fails to build when configured with --with-system-libmpdec In-Reply-To: <1385195580.05.0.00984042109495.issue19732@psf.upfronthosting.co.za> Message-ID: <1388953296.77.0.77731019842.issue19732@psf.upfronthosting.co.za> Stefan Krah added the comment: I?ve released mpdecimal-2.4.0: http://www.bytereef.org/mpdecimal/download.html sha256sum: ========== 996c73b63868699c4f86694671bd7ff3d1a8a88d8af2c22a5abe0c9a5845cf75 mpdecimal-2.4.0.tar.gz On obscure architectures I would recommend to run `make check` (leaves asserts in!). The fastest binaries are generated with: ./configure CFLAGS=-DNDEBUG make profile The -flto option appears to slow things down, -O3 instead of -O2 is the same or slightly worse in my experience. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 21:22:10 2014 From: report at bugs.python.org (Stefan Krah) Date: Sun, 05 Jan 2014 20:22:10 +0000 Subject: [issue19732] python fails to build when configured with --with-system-libmpdec In-Reply-To: <1385195580.05.0.00984042109495.issue19732@psf.upfronthosting.co.za> Message-ID: <1388953330.36.0.697728174042.issue19732@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 21:39:40 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Jan 2014 20:39:40 +0000 Subject: [issue1065986] Fix pydoc crashing on unicode strings Message-ID: <3dyBY74Mh7z7LjP@mail.python.org> Roundup Robot added the comment: New changeset bf077fc97fdd by R David Murray in branch '2.7': #1065986: Make pydoc handle unicode strings. http://hg.python.org/cpython/rev/bf077fc97fdd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 21:42:28 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 05 Jan 2014 20:42:28 +0000 Subject: [issue1065986] Fix pydoc crashing on unicode strings Message-ID: <1388954548.63.0.683104132915.issue1065986@psf.upfronthosting.co.za> R. David Murray added the comment: Committed, thanks Akira. The support for --disable-unicode is not fully tested. I tried running the tests but the _io module wasn't built, so regrtest doesn't work. A command line invocation of pydoc worked fine, though. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 22:21:04 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jan 2014 21:21:04 +0000 Subject: [issue20133] Convert the audioop module to use Argument Clinic Message-ID: <1388956864.17.0.114751586443.issue20133@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Here is a patch which converts the audioop module to use Argument Clinic. 26 functions are converted. Also it adds docstrings for audioop functions. There are two problems: * Test test_string crashes. Perhaps here is a bug in Argument Clinic (Py_buffer arguments are not initialized). * Pydoc for ratecv (and only for this function) returns: ratecv = ---------- components: Extension Modules files: audioop_clinic.patch keywords: patch messages: 207401 nosy: larry, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Convert the audioop module to use Argument Clinic type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file33320/audioop_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 22:59:41 2014 From: report at bugs.python.org (Brett Cannon) Date: Sun, 05 Jan 2014 21:59:41 +0000 Subject: [issue19944] Make importlib.find_spec load packages as needed In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za> Message-ID: <1388959181.38.0.478598123748.issue19944@psf.upfronthosting.co.za> Brett Cannon added the comment: Moving to importlib.util is fine by me. I put find_loader() to mirror import_module(), but honestly the former is much less used compared to the latter, so moving it to importlib.util makes sense. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 23:14:27 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Jan 2014 22:14:27 +0000 Subject: [issue1065986] Fix pydoc crashing on unicode strings Message-ID: <3dyDfV3QNGz7LrK@mail.python.org> Roundup Robot added the comment: New changeset e57660acc6d4 by R David Murray in branch '2.7': #1065986: add missing error handler in pydoc unicode fix. http://hg.python.org/cpython/rev/e57660acc6d4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 23:25:30 2014 From: report at bugs.python.org (Brett Cannon) Date: Sun, 05 Jan 2014 22:25:30 +0000 Subject: [issue20125] We need a good replacement for direct use of load_module(), post-PEP 451 In-Reply-To: <1388888272.45.0.255353824658.issue20125@psf.upfronthosting.co.za> Message-ID: <1388960730.63.0.89872717719.issue20125@psf.upfronthosting.co.za> Brett Cannon added the comment: I say just be patient and wait. No need to rush this as load_module() is still allowed to exist and be used. And if I manage to create SpecLoader than even new-fangled loaders and get load_module() for free. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 23:27:45 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 05 Jan 2014 22:27:45 +0000 Subject: [issue20126] sched doesn't handle events added after scheduler starts In-Reply-To: <1388890823.36.0.322424274213.issue20126@psf.upfronthosting.co.za> Message-ID: <1388960865.39.0.772105170668.issue20126@psf.upfronthosting.co.za> R. David Murray added the comment: Search for the issue number in Misc/NEWS. It looks like it was indeed included in 3.3.1. Can you figure out why that fix didn't fix your problem? ---------- resolution: duplicate -> stage: committed/rejected -> status: closed -> open superseder: sched.scheduler.run() blocks scheduler -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 5 23:28:47 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 05 Jan 2014 22:28:47 +0000 Subject: [issue20126] sched doesn't handle events added after scheduler starts In-Reply-To: <1388890823.36.0.322424274213.issue20126@psf.upfronthosting.co.za> Message-ID: <1388960927.23.0.662252111864.issue20126@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 00:00:33 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jan 2014 23:00:33 +0000 Subject: [issue20126] sched doesn't handle events added after scheduler starts In-Reply-To: <1388890823.36.0.322424274213.issue20126@psf.upfronthosting.co.za> Message-ID: <1388962833.79.0.118863975689.issue20126@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is because the scheduler already has executed first event and slept on delaying second event before you have added third event. This is unavoidable for this implementation. sched.scheduler can't be waked when sleep. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 00:05:26 2014 From: report at bugs.python.org (lotus@blossomhillranch.com) Date: Sun, 05 Jan 2014 23:05:26 +0000 Subject: [issue20126] sched doesn't handle events added after scheduler starts In-Reply-To: <1388890823.36.0.322424274213.issue20126@psf.upfronthosting.co.za> Message-ID: <1388963126.58.0.869906234767.issue20126@psf.upfronthosting.co.za> lotus at blossomhillranch.com added the comment: i looks like a different issue. 16165 says you can't add events while the scheduler is running. in my case, i can add them, but they don't run at the correct time. i'll guess at what the problem is... when you start the scheduler, the thread sleeps until the first scheduled event. when you add an event after the scheduler is running, the scheduler doesn't re-evaluate how long it should sleep. sched.enter(), sched.enterabs(), and sched.cancel() should probably send a signal to the scheduler thread to recalculate the time of the next event. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 00:20:05 2014 From: report at bugs.python.org (lotus@blossomhillranch.com) Date: Sun, 05 Jan 2014 23:20:05 +0000 Subject: [issue20126] sched doesn't handle events added after scheduler starts In-Reply-To: <1388890823.36.0.322424274213.issue20126@psf.upfronthosting.co.za> Message-ID: <1388964005.31.0.362368748684.issue20126@psf.upfronthosting.co.za> lotus at blossomhillranch.com added the comment: ok, makes sense. can we put a note in the manual about this limitation? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 03:47:59 2014 From: report at bugs.python.org (INADA Naoki) Date: Mon, 06 Jan 2014 02:47:59 +0000 Subject: [issue20134] typo: s/coping/copying/ Message-ID: <1388976479.8.0.729846608286.issue20134@psf.upfronthosting.co.za> New submission from INADA Naoki: http://docs.python.org/3.3/library/unittest.mock-examples.html#coping-with-mutable-arguments "coping" should be "copying"? ---------- assignee: docs at python components: Documentation messages: 207409 nosy: docs at python, naoki priority: normal severity: normal status: open title: typo: s/coping/copying/ versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 04:37:24 2014 From: report at bugs.python.org (Xiaoqing Rong) Date: Mon, 06 Jan 2014 03:37:24 +0000 Subject: [issue20135] mutate list Message-ID: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za> New submission from Xiaoqing Rong: I was using IDLE (Python GUI) for Python 3.3.3. I don't know if this is a bug or you guys intend it to be this way: >>> x=[1,2] >>> y=x >>> y.append(3) >>> x [1, 2, 3] personally i'd prefer x stays as [1,2] when i'm trying to mutate y also: >>> def f1(m,n=['haha']): if m==n: print('m==n') else: print('m!=n') n.append('yaya') >>> f1(['haha']) m==n >>> f1(['haha']) m!=n I'd prefer getting consistent results when calling functions like f1 ---------- messages: 207410 nosy: m123orning priority: normal severity: normal status: open title: mutate list type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 04:53:54 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Jan 2014 03:53:54 +0000 Subject: [issue20135] mutate list In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za> Message-ID: <1388980434.95.0.966114421626.issue20135@psf.upfronthosting.co.za> R. David Murray added the comment: Both of these are FAQs, but to my surprise there don't seem to be answers to them in the FAQ list. We should add some. Yes, both of these behaviors is intentional. The first is an important part of the language design: 'variable' names are just pointers to objects, so x and y point to the same object. The second is the same issue combined with another design feature: the objects on the right side of the = in a def statement are evaluated/created at the time the def statement is executed, not at the time the function is called. So 'n' points to the same object every time the function is called. I'm going to leave this open until someone either points me to the FAQ entries I missed, or we add them. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, r.david.murray versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 05:17:59 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 06 Jan 2014 04:17:59 +0000 Subject: [issue20134] typo: s/coping/copying/ In-Reply-To: <1388976479.8.0.729846608286.issue20134@psf.upfronthosting.co.za> Message-ID: <1388981879.0.0.179938268206.issue20134@psf.upfronthosting.co.za> Benjamin Peterson added the comment: No, see https://en.wiktionary.org/wiki/cope ---------- nosy: +benjamin.peterson resolution: -> later status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 05:18:09 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 06 Jan 2014 04:18:09 +0000 Subject: [issue20134] typo: s/coping/copying/ In-Reply-To: <1388976479.8.0.729846608286.issue20134@psf.upfronthosting.co.za> Message-ID: <1388981889.52.0.455879131318.issue20134@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: later -> invalid _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 08:24:25 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Mon, 06 Jan 2014 07:24:25 +0000 Subject: [issue20121] quopri_codec newline handling In-Reply-To: <1388836490.83.0.337537980753.issue20121@psf.upfronthosting.co.za> Message-ID: <1388993065.34.0.144751738271.issue20121@psf.upfronthosting.co.za> Vajrasky Kok added the comment: The quopri_codec uses binascii.b2a_qp method. >>> binascii.b2a_qp('\r\n\n\n\n') '\r\n\r\n\r\n\r\n' The logic in b2a_qp when dealing with newlines is check whether the first line uses \r\n or \n. If it uses \r\n, then all remaning lines' new lines will be converted to \r\n. if it uses \n, then all remaning lines' new lines will be converted to \n. It has comment on the source code. /* See if this string is using CRLF line ends */ /* XXX: this function has the side effect of converting all of * the end of lines to be the same depending on this detection * here */ I am not sure what the appropriate action here. But doc fix should be acceptable. ---------- nosy: +vajrasky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 08:39:50 2014 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Mon, 06 Jan 2014 07:39:50 +0000 Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and sys.stdout on UNIX for the C locale In-Reply-To: <1386952820.2.0.77364136667.issue19977@psf.upfronthosting.co.za> Message-ID: <1388993990.91.0.947112954257.issue19977@psf.upfronthosting.co.za> Bohuslav "Slavek" Kabrda added the comment: Nick: Sure, once there is an upstream solution that people have agreed on, I'll look into backporting it, NP. Thanks for letting me know about this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 09:57:08 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 06 Jan 2014 08:57:08 +0000 Subject: [issue1322] platform.dist() has unpredictable result under Linux In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za> Message-ID: <1388998628.97.0.95216818832.issue1322@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: None of the linked patch URLs work anymore. Could someone please upload a current patch to the ticket for review ? As mentioned before, I don't believe that changing the function to first try the lsb-release will result in the same results as what the functions returns now (for the distributions where it gives correct results). Furthermore, the file does not appear to be available on all major platforms. Only the lsb-release binary has become somewhat of a standard, so trying the file first, then the lsb-release binary will in most cases result in spawning a process. As example, on openSUSE 11.4, the lsb-release binary reads the /etc/SuSE-release file and then returns these results: > lsb-release -a LSB Version: n/a Distributor ID: SUSE LINUX Description: openSUSE 11.4 (x86_64) Release: 11.4 Codename: Celadon Note that taking these results would result in platform.dist() to return ('SUSE LINUX', '11.4', 'x86_64') instead of the current ('SuSE', '11.4', 'x86_64'). Finally, I think after all these years, the whole concept of linux_distribution() has failed due to the distributions using too many different ways of describing themselves. I'd be +1 on deprecating the functionality altogether and remove linux_distribution()/dist() in the long run. The functionality is better left to a package which can be updated more easily on PyPI. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 10:02:49 2014 From: report at bugs.python.org (A. Libotean) Date: Mon, 06 Jan 2014 09:02:49 +0000 Subject: [issue20136] Logging: StreamHandler does not use OS line separator. Message-ID: <1388998969.13.0.29066681056.issue20136@psf.upfronthosting.co.za> New submission from A. Libotean: The StreamHandler implementation uses hardcoded Unix/Linux line separators. This generates inconveniences when running on Windows as the file viewers expect DOS line terminators. I've attached a fix that will use os.linesep as the line terminator thus making the log files usable with Windows utilities. Please revise the fix and consider including it. ---------- components: Library (Lib) files: streamhandler.py messages: 207416 nosy: alibotean priority: normal severity: normal status: open title: Logging: StreamHandler does not use OS line separator. type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file33321/streamhandler.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 10:19:31 2014 From: report at bugs.python.org (A. Libotean) Date: Mon, 06 Jan 2014 09:19:31 +0000 Subject: [issue20137] Logging: RotatingFileHandler computes string length instead of byte representation length. Message-ID: <1388999971.66.0.938288838593.issue20137@psf.upfronthosting.co.za> New submission from A. Libotean: Current implementation of RotatingFileHandler ignores the encoding when computing the entry byte length. I've attached a modified version that will compute the entry lenght in bytes. ---------- components: Library (Lib) files: rotatingfilehandler.py messages: 207417 nosy: alibotean priority: normal severity: normal status: open title: Logging: RotatingFileHandler computes string length instead of byte representation length. type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file33322/rotatingfilehandler.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 10:46:59 2014 From: report at bugs.python.org (Armin Ronacher) Date: Mon, 06 Jan 2014 09:46:59 +0000 Subject: [issue20138] wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode Message-ID: <1389001619.16.0.909145148031.issue20138@psf.upfronthosting.co.za> New submission from Armin Ronacher: I just noticed through looking through someone else's WSGI framework that wsgiref is incorrectly handling URL handling. It does not go through the WSGI coding dance in the wsgiref.utils.request_uri function. Testcase through werkzeug: >>> from wsgiref.util import request_uri >>> from werkzeug.test import create_environ >>> from werkzeug.urls import url_parse, url_unquote >>> env = create_environ('/\N{SNOWMAN}') >>> url_parse(request_uri(env)).path '/%C3%A2%C2%98%C2%83' >>> url_unquote(url_parse(request_uri(env)).path) '/?\x98\x83' >>> _ == '/\N{SNOWMAN}' False If this passes tests then I'm assuming that wsgiref is doing the inverse bug somewhere else. I will look into it later, but this behavior is definitely broken. ---------- messages: 207418 nosy: aronacher priority: normal severity: normal status: open title: wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 10:47:50 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 06 Jan 2014 09:47:50 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <1389001670.94.0.23637355367.issue19081@psf.upfronthosting.co.za> Gregory P. Smith added the comment: attaching a patch for 3.3. up next, 3.4: So long as I get to it before the release candidates the approach can likely be improved for 3.4 to actually hold the zip file we're importing from open for the life of the process instead of doing all of these stat calls. That'd also get rid of the platform specific trick used to get the os.fstat function without being able to import the os module. ---------- Added file: http://bugs.python.org/file33323/issue19081-33-gps04.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 10:49:02 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 06 Jan 2014 09:49:02 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <1389001742.53.0.880219350151.issue19081@psf.upfronthosting.co.za> Changes by Gregory P. Smith : Removed file: http://bugs.python.org/file31860/issue19081-gps01.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 10:49:10 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 06 Jan 2014 09:49:10 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <1389001750.78.0.910821781282.issue19081@psf.upfronthosting.co.za> Changes by Gregory P. Smith : Removed file: http://bugs.python.org/file31869/issue19081-gps02.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 11:24:09 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Mon, 06 Jan 2014 10:24:09 +0000 Subject: [issue16074] Bad error message in os.rename, os.link, and os.symlink In-Reply-To: <1348820000.8.0.496903200143.issue16074@psf.upfronthosting.co.za> Message-ID: <1389003849.4.0.774984889594.issue16074@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Jakub Wilk, yeah, I missed that one. Jason Gerard DeRose, thanks for the additional information. Anyway, I already "persuaded" Ruby developers to specialize the message, although it's only for creating symlink. https://bugs.ruby-lang.org/issues/9263 As of Python, let's leave that for Python 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 11:24:27 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 06 Jan 2014 10:24:27 +0000 Subject: [issue1322] platform.dist() has unpredictable result under Linux In-Reply-To: <1388998628.97.0.95216818832.issue1322@psf.upfronthosting.co.za> Message-ID: <52CA8458.2010807@egenix.com> Marc-Andre Lemburg added the comment: Another example on openSUSE 12.3: # lsb-release -a LSB Version: n/a Distributor ID: openSUSE project Description: openSUSE 12.3 (x86_64) Release: 12.3 Codename: Dartmouth This would result in ('openSUSE project', '11.4', 'x86_64'). I don't think such distribution name changes are useful in practice. The existing linux_distribution() code always returns 'SuSE' for these (and likewise for other distributions). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 11:26:10 2014 From: report at bugs.python.org (Matthias Klose) Date: Mon, 06 Jan 2014 10:26:10 +0000 Subject: [issue1322] platform.dist() has unpredictable result under Linux In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za> Message-ID: <1389003970.06.0.708589739748.issue1322@psf.upfronthosting.co.za> Matthias Klose added the comment: sure, then please let's deprecate that for 3.4, and remove in 3.5. /etc/os-release introduce the next set of different names. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 11:36:35 2014 From: report at bugs.python.org (Paul Moore) Date: Mon, 06 Jan 2014 10:36:35 +0000 Subject: [issue20139] Python installer does not install a "pip" command (just "pip3" and "pip3.4") Message-ID: <1389004595.51.0.303248047302.issue20139@psf.upfronthosting.co.za> New submission from Paul Moore: The Python 3.4b2 installer for Windows does not install a "pip.exe" wrapper when the default options are selected. Only the "pip3.exe" and "pip3.4.exe" commands are provided. The documentation for ensurepip makes it clear that this is the default behaviour, but there is no comment in either the PEP or in "Python Setup and Usage" stating that this is what happens. Also, I imagine that people will expect a "pip" command to be available by default, so an explanation of *why* only the versioned commands are installed should be added. (It may be that having the unversioned command as well is actually the correct thing to do, on Windows if not on Unix - I can't recall the details of the discussion. If so, maybe the correct thing to do is to change the Windows installer behaviour). ---------- assignee: dstufft components: Documentation messages: 207423 nosy: dstufft, ncoghlan, pmoore priority: normal severity: normal status: open title: Python installer does not install a "pip" command (just "pip3" and "pip3.4") type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 11:43:52 2014 From: report at bugs.python.org (=?utf-8?q?Jarek_=C5=9Amiejczak?=) Date: Mon, 06 Jan 2014 10:43:52 +0000 Subject: [issue20140] UnicodeDecodeError in ntpath.py when home dir contains non-ascii signs Message-ID: <1389005031.99.0.692658963376.issue20140@psf.upfronthosting.co.za> New submission from Jarek ?miejczak: Full traceback: https://gist.github.com/jarekps/2729ee1917ea372e6642 Error's starts in pip but after investigation of traceback it looks like it is python's issue (version 2.7.5). Windows version: 8.1 Enterprise x64 with Polish language pack. Feel free to ask if any additional information is necessary. ---------- components: Windows messages: 207424 nosy: Jarek.?miejczak priority: normal severity: normal status: open title: UnicodeDecodeError in ntpath.py when home dir contains non-ascii signs type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 11:47:29 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Jan 2014 10:47:29 +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: <1389005249.59.0.446911344726.issue20140@psf.upfronthosting.co.za> STINNER Victor added the comment: > https://gist.github.com/jarekps/2729ee1917ea372e6642 Copy of the output: --- C:\Users\Jaros?aw>pip Traceback (most recent call last): File "c:\python27\Scripts\pip-script.py", line 9, in load_entry_point('pip==1.5', 'console_scripts', 'pip')() File "c:\python27\lib\site-packages\distribute-0.6.49-py2.7.egg\pkg_resources.py", line 345, in load_entry_point return get_distribution(dist).load_entry_point(group, name) File "c:\python27\lib\site-packages\distribute-0.6.49-py2.7.egg\pkg_resources.py", line 2381, in load_entry_point return ep.load() File "c:\python27\lib\site-packages\distribute-0.6.49-py2.7.egg\pkg_resources.py", line 2087, in load entry = __import__(self.module_name, globals(),globals(), ['__name__']) File "c:\python27\lib\site-packages\pip\__init__.py", line 11, in from pip.vcs import git, mercurial, subversion, bazaar # noqa File "c:\python27\lib\site-packages\pip\vcs\subversion.py", line 4, in from pip.index import Link File "c:\python27\lib\site-packages\pip\index.py", line 16, in from pip.wheel import Wheel, wheel_ext, wheel_setuptools_support File "c:\python27\lib\site-packages\pip\wheel.py", line 23, in from pip._vendor.distlib.scripts import ScriptMaker File "c:\python27\lib\site-packages\pip\_vendor\distlib\scripts.py", line 15, in from .resources import finder File "c:\python27\lib\site-packages\pip\_vendor\distlib\resources.py", line 105, in cache = Cache() File "c:\python27\lib\site-packages\pip\_vendor\distlib\resources.py", line 40, in __init__ base = os.path.join(get_cache_base(), 'resource-cache') File "c:\python27\lib\ntpath.py", line 108, in join path += "\\" + b UnicodeDecodeError: 'ascii' codec can't decode byte 0xb3 in position 14: ordinal not in range(128) --- It looks like a bug in distlib.resources, not in Python. os.path.join() works correctly if all arguments are bytes strings (str type). I should work if all arguments are Unicode strings only containing ASCII characters. (I don't know if it works if all aruments are Unicode strings.) In your case, it looks like os.path.join() is called with a unicode and a bytes string. ---------- nosy: +haypo, ncoghlan, vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 11:48:00 2014 From: report at bugs.python.org (Graham Dumpleton) Date: Mon, 06 Jan 2014 10:48:00 +0000 Subject: [issue20138] wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode In-Reply-To: <1389001619.16.0.909145148031.issue20138@psf.upfronthosting.co.za> Message-ID: <1389005280.26.0.487507199049.issue20138@psf.upfronthosting.co.za> Changes by Graham Dumpleton : ---------- nosy: +grahamd _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 11:53:01 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Mon, 06 Jan 2014 10:53:01 +0000 Subject: [issue1322] platform.dist() has unpredictable result under Linux In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za> Message-ID: <1389005581.15.0.422285659271.issue1322@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the patch to deprecate platform.dist and platform.linux_distribution. ---------- nosy: +vajrasky Added file: http://bugs.python.org/file33324/deprecate_platform_dist.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 12:07:49 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 06 Jan 2014 11:07:49 +0000 Subject: [issue1322] platform.dist() has unpredictable result under Linux In-Reply-To: <1389005581.15.0.422285659271.issue1322@psf.upfronthosting.co.za> Message-ID: <52CA8E82.50801@egenix.com> Marc-Andre Lemburg added the comment: On 06.01.2014 11:53, Vajrasky Kok wrote: > > Here is the patch to deprecate platform.dist and platform.linux_distribution. > > ---------- > nosy: +vajrasky > Added file: http://bugs.python.org/file33324/deprecate_platform_dist.patch Thanks. I think we'll need to do this in three steps: 1. pending deprecation in 3.4 2. deprecation in 3.5 3. removal in 3.6 Please also add a note to these steps to the warning text and a deprecation notice to the documentation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 12:07:57 2014 From: report at bugs.python.org (Jeremy Kloth) Date: Mon, 06 Jan 2014 11:07:57 +0000 Subject: [issue20139] Python installer does not install a "pip" command (just "pip3" and "pip3.4") In-Reply-To: <1389004595.51.0.303248047302.issue20139@psf.upfronthosting.co.za> Message-ID: <1389006477.43.0.528176834977.issue20139@psf.upfronthosting.co.za> Changes by Jeremy Kloth : ---------- nosy: +jkloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 12:07:58 2014 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 06 Jan 2014 11:07:58 +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: <1389006478.48.0.0937430989363.issue20140@psf.upfronthosting.co.za> Vinay Sajip added the comment: It's not failing specifically because of distlib or os.path.join functionality: it's failing because, given a Unicode path C:\Users\Jaros?aw\..., Python is attempting to decode it using the default, ASCII codec. I'll certainly look at updating distlib to handle this case, but the same problem could bite the user in other areas. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 12:32:55 2014 From: report at bugs.python.org (Florian Apolloner) Date: Mon, 06 Jan 2014 11:32:55 +0000 Subject: [issue20138] wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode In-Reply-To: <1389001619.16.0.909145148031.issue20138@psf.upfronthosting.co.za> Message-ID: <1389007975.64.0.709806922877.issue20138@psf.upfronthosting.co.za> Changes by Florian Apolloner : ---------- nosy: +apollo13 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 13:11:00 2014 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 06 Jan 2014 12:11:00 +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: <1389010260.21.0.859557730041.issue20140@psf.upfronthosting.co.za> Vinay Sajip added the comment: Jarek: I can't easily test this in my environment; perhaps you can help. Could you change, in the file c:\python27\lib\site-packages\pip\_vendor\distlib\resources.py, line 40 from base = os.path.join(get_cache_base(), 'resource-cache') to base = os.path.join(get_cache_base(), str('resource-cache')) to see if that resolves the problem? Currently, 'resource-cache' is a Unicode string (because of "from __future__ import unicode_literals" in the containing module) and that causes Python to try and convert the get_cache_base() result to Unicode using ASCII, which leads to the failure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 13:56:24 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jan 2014 12:56:24 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <1389012984.38.0.865615818225.issue19081@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 14:12:14 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jan 2014 13:12:14 +0000 Subject: [issue20141] Argument Clinic: broken support for 'O!' Message-ID: <1389013934.21.0.28397308089.issue20141@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: First, the documentation says that syntax for 'O!' conversion is object(type='name_of_Python_type'), but actually the type argument should be the name of C structure which represents Python type. I.e. object(type='list') is rejected, and object(type='PyList_Type') is accepted. Second, from this declaration /*[clinic] module spam spam.ham items: object(type='PyList_Type') / [clinic]*/ Argument Clinic generates following parsing code: if (!PyArg_ParseTuple(args, "O!:ham", PyList_Type, &items)) goto exit; It is wrong, should be &PyList_Type. ---------- assignee: docs at python components: Build, Documentation messages: 207430 nosy: docs at python, larry, serhiy.storchaka priority: release blocker severity: normal status: open title: Argument Clinic: broken support for 'O!' type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 14:47:22 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 06 Jan 2014 13:47:22 +0000 Subject: [issue20141] Argument Clinic: broken support for 'O!' In-Reply-To: <1389013934.21.0.28397308089.issue20141@psf.upfronthosting.co.za> Message-ID: <1389016042.07.0.317942312955.issue20141@psf.upfronthosting.co.za> Larry Hastings added the comment: So a documentation error and having to manually specify "&" at the front of your string means it's "broken"? Nevertheless, I'll take a look at it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 14:50:27 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jan 2014 13:50:27 +0000 Subject: [issue20141] Argument Clinic: broken support for 'O!' In-Reply-To: <1389016042.07.0.317942312955.issue20141@psf.upfronthosting.co.za> Message-ID: <5147104.dQgs7oKGiW@raxxla> Serhiy Storchaka added the comment: You can't manually specify "&" at the front of the name. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 14:55:57 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jan 2014 13:55:57 +0000 Subject: [issue20141] Argument Clinic: broken support for 'O!' In-Reply-To: <1389013934.21.0.28397308089.issue20141@psf.upfronthosting.co.za> Message-ID: <1389016557.59.0.689925800077.issue20141@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file33325/spammodule.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 15:05:53 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jan 2014 14:05:53 +0000 Subject: [issue20142] Argument Clinic: Py_buffer parameters are not initialized Message-ID: <1389017153.04.0.847004275231.issue20142@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Argument Clinic doesn't initialize Py_buffer parameters. It generates cleanup code: /* Cleanup for data */ if (data.buf) PyBuffer_Release(&data); And if PyArg_ParseTuple() is failed, the buf attribute can contains arbitrary (non-NULL) data. This causes crash in PyBuffer_Release(). See issue20133 for working example. ---------- components: Build files: spammodule.c messages: 207433 nosy: larry, serhiy.storchaka priority: release blocker severity: normal status: open title: Argument Clinic: Py_buffer parameters are not initialized type: crash versions: Python 3.4 Added file: http://bugs.python.org/file33326/spammodule.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 15:19:53 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jan 2014 14:19:53 +0000 Subject: [issue20143] Argument Clinic: negative line numbers Message-ID: <1389017993.56.0.244329561856.issue20143@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: In case of error Argument Clinic sometimes reports negative line numbers. ---------- messages: 207434 nosy: larry, serhiy.storchaka priority: normal severity: normal status: open title: Argument Clinic: negative line numbers type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 15:23:13 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jan 2014 14:23:13 +0000 Subject: [issue20144] Argument Clinic doesn't support named constants as default values Message-ID: <1389018193.74.0.0273889485321.issue20144@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: For example it doesn't support PY_SSIZE_T_MAX as default value for Py_ssize_t argument. Is there any way to specify it? This is required for converting the _sre module. ---------- components: Build messages: 207435 nosy: larry, serhiy.storchaka priority: normal severity: normal status: open title: Argument Clinic doesn't support named constants as default values versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 15:28:17 2014 From: report at bugs.python.org (the mulhern) Date: Mon, 06 Jan 2014 14:28:17 +0000 Subject: [issue20145] unittest.assert*Regex functions should verify that expected_regex has a valid type Message-ID: <1389018497.06.0.693451933582.issue20145@psf.upfronthosting.co.za> New submission from the mulhern: A normal thing for a developer to do is to convert a use of an assert* function to a use of an assert*Regex function and foolishly forget to actually specify the expected regular expression. If they do this, the test will always pass because the callable expression will be in the place of the expected regular expression and the callable expression will, therefore, be None. It would be nice if in the constructor in AssertRaisesBaseContext (for 3.5) not only was the expected regex converted to a regex (if actually a string or bytes) but if it's not if it were checked if it were a valid regular expression object and an exception raised if this is not the case. In the current version of AssertRaisesBaseContext.handle the comments say that if the callable object is None then the function is being used as a context manager. Not always the case, alas, perhaps the developer just forgot to add that necessary regular expression before the callable object. ---------- messages: 207436 nosy: the.mulhern priority: normal severity: normal status: open title: unittest.assert*Regex functions should verify that expected_regex has a valid type type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 15:31:10 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 06 Jan 2014 14:31:10 +0000 Subject: [issue20139] Python installer does not install a "pip" command (just "pip3" and "pip3.4") In-Reply-To: <1389004595.51.0.303248047302.issue20139@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: This is deliberate - the unversioned command is only installed into virtual environments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 15:57:29 2014 From: report at bugs.python.org (Paul Moore) Date: Mon, 06 Jan 2014 14:57:29 +0000 Subject: [issue20139] Python installer does not install a "pip" command (just "pip3" and "pip3.4") In-Reply-To: <1389004595.51.0.303248047302.issue20139@psf.upfronthosting.co.za> Message-ID: <1389020249.82.0.0230891210887.issue20139@psf.upfronthosting.co.za> Paul Moore added the comment: Fair enough. Can the justification be recorded somewhere, please? It's inconsistent with most other Python commands on Windows. (I don't recall what the justification was, and can't come up with a search that locates the discussion thread). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 16:02:34 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 06 Jan 2014 15:02:34 +0000 Subject: [issue20139] Python installer does not install a "pip" command (just "pip3" and "pip3.4") In-Reply-To: <1389020249.82.0.0230891210887.issue20139@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: I'm not sure we specifically considered the Windows case - we were avoiding the name collision with pip for Python 2 on POSIX systems. The decision on which names to install is actually made in pip itself, though, ensurepip just indicates what kind of install it is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 16:09:40 2014 From: report at bugs.python.org (Paul Moore) Date: Mon, 06 Jan 2014 15:09:40 +0000 Subject: [issue20139] Python installer does not install a "pip" command (just "pip3" and "pip3.4") In-Reply-To: <1389004595.51.0.303248047302.issue20139@psf.upfronthosting.co.za> Message-ID: <1389020980.44.0.389588608478.issue20139@psf.upfronthosting.co.za> Paul Moore added the comment: It would not be impossible for the ensurepip call in the Windows installer to set the --default-pip flag, if that gives a better user experience on Windows. I'm not wedded to either answer myself, but given that versioned executable names are uncommon on Windows, I can easily imagine a series of bug reports saying "I asked for pip to be installed, and it's not there". Making a deliberate decision one way or the other and documenting it seems like the minimum reasonable approach. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 16:19:43 2014 From: report at bugs.python.org (Alexandru Gheorghe) Date: Mon, 06 Jan 2014 15:19:43 +0000 Subject: [issue20146] UserDict module docs link is obsolete Message-ID: <1389021583.36.0.157919967896.issue20146@psf.upfronthosting.co.za> New submission from Alexandru Gheorghe: FILE /usr/lib/python2.7/UserDict.py MODULE DOCS http://docs.python.org/library/UserDict Reference link to online documentation is invalid. (Probably) Should be: http://docs.python.org/library/userdict.html Happens on Debian 7 Wheezy x86_64: Python 2.7.3 , [GCC 4.7.2] on linux2 ---------- assignee: docs at python components: Documentation messages: 207441 nosy: docs at python, drunax priority: normal severity: normal status: open title: UserDict module docs link is obsolete type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 16:22:43 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 06 Jan 2014 15:22:43 +0000 Subject: [issue18515] zipfile._ZipDecryptor generates wasteful crc32 table on import In-Reply-To: <1374331044.49.0.0628884037506.issue18515@psf.upfronthosting.co.za> Message-ID: <1389021763.22.0.909314746281.issue18515@psf.upfronthosting.co.za> Larry Hastings added the comment: Since this isn't a bugfix, it was inappropriate to check this in after feature-freeze for 3.4. However it looks harmless enough, so I'm not asking you to revert it at this time. I guess it's easier to get forgiveness than permission, huh. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 16:30:10 2014 From: report at bugs.python.org (Torsten Landschoff) Date: Mon, 06 Jan 2014 15:30:10 +0000 Subject: [issue20147] multiprocessing.Queue.get() raises queue.Empty exception if even if an item is available Message-ID: <1389022210.55.0.898891193549.issue20147@psf.upfronthosting.co.za> New submission from Torsten Landschoff: The behaviour of multiprocessing.Queue surprised me today in that Queue.get() may raise an exception even if an item is immediately available. I tried to flush entries without blocking by using the timeout=0 keyword argument: $ /opt/python3/bin/python3 Python 3.4.0b1 (default:247f12fecf2b, Jan 6 2014, 14:50:23) [GCC 4.6.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from multiprocessing import Queue >>> q = Queue() >>> q.put("hi") >>> q.get(timeout=0) Traceback (most recent call last): File "", line 1, in File "/opt/python3/lib/python3.4/multiprocessing/queues.py", line 107, in get raise Empty queue.Empty Actually even passing a small non-zero timeout will not give me my queue entry: >>> q.get(timeout=1e-6) Traceback (most recent call last): File "", line 1, in File "/home/torsten/opensrc/cpython/Lib/multiprocessing/queues.py", line 107, in get raise Empty queue.Empty Expected behaviour for me would be to return the item that is in the queue. I know that there is a kwarg *block* which gives me the desired behaviour: >>> q.get(block=False) 'hi' In my case the get call is embedded in my own module which does not currently expose the block parameter. My local solution is of course to update the wrapper: if timeout == 0: timeout = None block = False However I see a few smells here in the python standard library. First, everything else seems to accept timeout=0 as nonblocking: >>> import threading >>> lock = threading.Lock() >>> lock.acquire(timeout=0) True >>> from queue import Queue >>> q = Queue() >>> q.put("hi") >>> q.get(timeout=0) 'hi' Of special note is that queue.Queue behaves as I would have expected. IMHO it should be consistent with multiprocessing.Queue. Also note that queue.Queue.get() and queue.Queue.put() name their blocking flag "block", while everybody else uses "blocking". As a side note, I think the current approach is flawed in computing the deadline. Basically it does the following: deadline = time.time() + timeout if not self._rlock.acquire(block, timeout): raise Empty timeout = deadline - time.time() if timeout < 0 or not self._poll(timeout): raise Empty On my system, just taking the time twice and computing the delta takes 2 microseconds: >>> import time >>> t0 = time.time(); time.time() - t0 2.384185791015625e-06 Therefore calling Queue.get(block, timeout) with 0 < timeout < 2e-6 will never return anything from the queue even though Queue.get(block=False) would do that. This contradicts the idea that Queue.get(block=False) will return faster than with block=True with any timeout > 0. Apart from that, as Python does not currently support waiting on multiple sources, we currently often check a queue with a small timeout concurrently with doing other stuff. In case the system get really loaded, I would expect this to cause problems because the updated timeout may fall below zero. Suggested patch attached. ---------- components: Library (Lib) files: queue_timeout_0.diff keywords: patch messages: 207443 nosy: torsten priority: normal severity: normal status: open title: multiprocessing.Queue.get() raises queue.Empty exception if even if an item is available type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file33327/queue_timeout_0.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 16:49:54 2014 From: report at bugs.python.org (Torsten Landschoff) Date: Mon, 06 Jan 2014 15:49:54 +0000 Subject: [issue20147] multiprocessing.Queue.get() raises queue.Empty exception if even if an item is available In-Reply-To: <1389022210.55.0.898891193549.issue20147@psf.upfronthosting.co.za> Message-ID: <1389023394.06.0.144053437883.issue20147@psf.upfronthosting.co.za> Changes by Torsten Landschoff : Added file: http://bugs.python.org/file33328/queue_timeout_1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 16:50:12 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 06 Jan 2014 15:50:12 +0000 Subject: [issue20144] Argument Clinic doesn't support named constants as default values In-Reply-To: <1389018193.74.0.0273889485321.issue20144@psf.upfronthosting.co.za> Message-ID: <1389023412.39.0.547274753087.issue20144@psf.upfronthosting.co.za> Larry Hastings added the comment: Here's the problem. Let's say I gave you a way of specifying a symbolic constant for the default value for C. What value should we use for the default value in Python? Keep in mind, it has to be expressed as a static value that can be stored as a string as part of the __text_signature__ at the front of the docstring. If you can answer that question, we can solve the problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 16:55:30 2014 From: report at bugs.python.org (Daniel Holth) Date: Mon, 06 Jan 2014 15:55:30 +0000 Subject: [issue18515] zipfile._ZipDecryptor generates wasteful crc32 table on import In-Reply-To: <1389021763.22.0.909314746281.issue18515@psf.upfronthosting.co.za> Message-ID: <1389023729.17566.67212781.268DC9D5@webmail.messagingengine.com> Daniel Holth added the comment: Thanks. I guess I know who to ask now. It was just painful seeing so much import-time computation, pretty much guaranteed to happen every time Python starts up, being wasted on a feature that is rarely used. On the Raspberry Pi the majority of the import time is spent building this table and the speed difference is noticeable. On Mon, Jan 6, 2014, at 10:22 AM, Larry Hastings wrote: > > Larry Hastings added the comment: > > Since this isn't a bugfix, it was inappropriate to check this in after > feature-freeze for 3.4. However it looks harmless enough, so I'm not > asking you to revert it at this time. > > I guess it's easier to get forgiveness than permission, huh. > > ---------- > nosy: +larry > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 16:58:07 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Jan 2014 15:58:07 +0000 Subject: [issue20136] Logging: StreamHandler does not use OS line separator. In-Reply-To: <1388998969.13.0.29066681056.issue20136@psf.upfronthosting.co.za> Message-ID: <1389023887.76.0.588091437275.issue20136@psf.upfronthosting.co.za> R. David Murray added the comment: The IO system should automatically take care of the linesep conversion when writing to a text stream. Are you sure you specified that the output was a text file? ---------- nosy: +r.david.murray, vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 17:00:45 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Jan 2014 16:00:45 +0000 Subject: [issue20137] Logging: RotatingFileHandler computes string length instead of byte representation length. In-Reply-To: <1388999971.66.0.938288838593.issue20137@psf.upfronthosting.co.za> Message-ID: <1389024045.35.0.820809265042.issue20137@psf.upfronthosting.co.za> R. David Murray added the comment: Could you please upload your proposed fix as a patch file (universal diff)? ---------- nosy: +r.david.murray, vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 17:04:29 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jan 2014 16:04:29 +0000 Subject: [issue20148] Convert the _sre module to use Argument Clinic Message-ID: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Here is preliminary patch which converts the _sre module to use Argument Clinic. 22 functions are converted. There are thre problems: * Issue20141. The code was manually edited after Argument Clinic (and should be edited again for next run of Argument Clinic). * Issue20144. Literal 1000000000 is temporary used instead of PY_SSIZE_T_MAX. * Pydoc for _sre.compile (and only for this function) returns: _sre.compile = ---------- components: Extension Modules, Regular Expressions messages: 207448 nosy: ezio.melotti, larry, mrabarnett, serhiy.storchaka priority: normal severity: normal status: open title: Convert the _sre module to use Argument Clinic type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 17:05:26 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jan 2014 16:05:26 +0000 Subject: [issue20148] Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1389024326.89.0.161607736346.issue20148@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch Added file: http://bugs.python.org/file33329/sre_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 17:11:17 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 06 Jan 2014 16:11:17 +0000 Subject: [issue20144] Argument Clinic doesn't support named constants as default values In-Reply-To: <1389018193.74.0.0273889485321.issue20144@psf.upfronthosting.co.za> Message-ID: <1389024677.31.0.209128878163.issue20144@psf.upfronthosting.co.za> Larry Hastings added the comment: As an example, consider pattern_match() in _sre.c. This implements the match method on a pattern object; in other words, re.compile().match(). The third parameter, endpos, defaults to PY_SSIZE_T_MAX in C. What should inspect.Signature() report as the default value for endpos? We can't look up the proper value for PY_SSIZE_T_MAX, because the default value inspect.Signature() uses was written out as text when Argument Clinic processed the function. As a hint, the documentation for match() dodges this problem by outright lying. It claims that the prototype for the function is: match(string[, pos[, endpos]]) which is a lie. pattern_match() parses its arguments by calling PyArg_ParseTupleAndKeywords() with a format string of "O|nn". which means, for example, you could call: match("abc", endpos=5) The documentation claims this is invalid but it works fine. In other words, it's a sticky problem, and the people who had it before us didn't try to solve it properly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 17:17:07 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 06 Jan 2014 16:17:07 +0000 Subject: [issue20148] Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1389025027.88.0.729983204414.issue20148@psf.upfronthosting.co.za> Larry Hastings added the comment: Obviously we can't live with manually editing the output from Argument Clinic, so I'll get you a fix for O! today. Maybe we could use a better literal value? Like 2**31 - 1? I don't understand the pydoc thing. Can you elaborate? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 17:18:52 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jan 2014 16:18:52 +0000 Subject: [issue20144] Argument Clinic doesn't support named constants as default values In-Reply-To: <1389018193.74.0.0273889485321.issue20144@psf.upfronthosting.co.za> Message-ID: <1389025132.28.0.310067978279.issue20144@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Not always default value can be expressed in Python. Current docstring for the match() method says "match(string[, pos[, endpos]])". For this particular case it can be written as "match(string, pos=0, endpos=sys.maxsize)". And this is very common case (see also str.find(sub[, start[, end]]), etc). Perhaps there are cases in which the default value is not PY_SSIZE_T_MAX and None is not accepted (as for dir_fd parameter in os functions). So as minimum Argument Clinic can support sys.maxsize, and as maximum, it should support arbitrary values. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 17:36:10 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jan 2014 16:36:10 +0000 Subject: [issue20148] Convert the _sre module to use Argument Clinic In-Reply-To: <1389025027.88.0.729983204414.issue20148@psf.upfronthosting.co.za> Message-ID: <1455556.BT0J5S8uBO@raxxla> Serhiy Storchaka added the comment: > Maybe we could use a better literal value? Like 2**31 - 1? This only a placeholder. It will be replaced by named constant in final patch. 2**31 - 1 is not better here than any other arbitrary value. > I don't understand the pydoc thing. Can you elaborate? Pydoc for _sre.compile doesn't output signature and docstring, but only mentioned above line. There is similar issue in audioop module (issue20133) for the ratecv function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 17:38:52 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 06 Jan 2014 16:38:52 +0000 Subject: [issue20144] Argument Clinic doesn't support named constants as default values In-Reply-To: <1389018193.74.0.0273889485321.issue20144@psf.upfronthosting.co.za> Message-ID: <1389026332.15.0.981213690679.issue20144@psf.upfronthosting.co.za> Larry Hastings added the comment: "sys.maxsize" won't work. inspect.Signature parses the __text_signature__ using ast.parse, and it only recognizes constant values and named constants (True/False/None) for the default value for parameters. Playing with ast, it looks like we'd have to support a tree of Attribute nodes, then look up sys (or whatever) and recursively getattr on it. Which would be new code. Anyway it seems like a bad idea: import inspect import re import sys sys.maxsize = 3 inspect.signature(re.compile(".*").match) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 17:43:53 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jan 2014 16:43:53 +0000 Subject: [issue20144] Argument Clinic doesn't support named constants as default values In-Reply-To: <1389026332.15.0.981213690679.issue20144@psf.upfronthosting.co.za> Message-ID: <1494572.qqOzVpnkQg@raxxla> Serhiy Storchaka added the comment: Then perhaps these methods can not be converted to use Argument Clinic now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 17:48:06 2014 From: report at bugs.python.org (Jeremy Kloth) Date: Mon, 06 Jan 2014 16:48:06 +0000 Subject: [issue20144] Argument Clinic doesn't support named constants as default values In-Reply-To: <1389018193.74.0.0273889485321.issue20144@psf.upfronthosting.co.za> Message-ID: <1389026886.82.0.34962824156.issue20144@psf.upfronthosting.co.za> Changes by Jeremy Kloth : ---------- nosy: +jkloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 17:57:11 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 06 Jan 2014 16:57:11 +0000 Subject: [issue20141] Argument Clinic: broken support for 'O!' In-Reply-To: <1389013934.21.0.28397308089.issue20141@psf.upfronthosting.co.za> Message-ID: <1389027431.19.0.100511652493.issue20141@psf.upfronthosting.co.za> Larry Hastings added the comment: Actually, the documentation (the "howto") states: Note that object() must explicitly support each Python type you specify for the type argument. Currently it only supports str. It should be easy to add more, just edit Tools/clinic/clinic.py, search for O! in the text, and add more entries to the dict mapping types to strings just above it. Maybe this is a bad API. But it's not broken. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 18:07:59 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jan 2014 17:07:59 +0000 Subject: [issue20133] Convert the audioop module to use Argument Clinic In-Reply-To: <1388956864.17.0.114751586443.issue20133@psf.upfronthosting.co.za> Message-ID: <1389028079.08.0.994271861666.issue20133@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Argument Clinic: Py_buffer parameters are not initialized _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 18:08:14 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jan 2014 17:08:14 +0000 Subject: [issue20148] Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1389028094.21.0.458514867146.issue20148@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Argument Clinic doesn't support named constants as default values, Argument Clinic: broken support for 'O!' _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 18:12:59 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 06 Jan 2014 17:12:59 +0000 Subject: [issue20142] Argument Clinic: Py_buffer parameters are not initialized In-Reply-To: <1389017153.04.0.847004275231.issue20142@psf.upfronthosting.co.za> Message-ID: <1389028379.26.0.796721013747.issue20142@psf.upfronthosting.co.za> Larry Hastings added the comment: Here's a patch, please review. You can see how Py_buffer variables are initialized in zlibmodule.c in the patch. ---------- Added file: http://bugs.python.org/file33330/larry.clinic.py_buffer.initialization.patch.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 18:42:24 2014 From: report at bugs.python.org (Daniel Grace) Date: Mon, 06 Jan 2014 17:42:24 +0000 Subject: [issue20149] 'with instance' references class's __enter__ attribute rather than instance's Message-ID: <1389030144.11.0.294634334929.issue20149@psf.upfronthosting.co.za> New submission from Daniel Grace: I was writing code for a class that uses one threading.RLock per object. For convenience, I wanted to be able to use that lock's context manager and acquire/release methods without referencing the lock directly, so I opted to take a shortcut by assigning self.__enter__ = self.lock.__enter__ and so forth. This fails in Python 3.3.1 (self-compiled on Debian) and both "3.3.2+" and "2.7.5+" (currently available Ubuntu packages). Judging by the error messages, it looks 'with' is examining the __enter__ and __exit__ attributes defined on the instance's class, rather than those defined on the instance itself. The workaround here is simple enough, but I'm under the impression that it shouldn't be needed anyways. Test case follows: import threading class Foo(object): # Uncommenting these yields "NoneType is not callable" rather than an AttributeError # __enter__ = None # __exit__ = None # acquire = None # release = None # lock = None def __init__(self): self.lock = threading.RLock() print(repr(self.lock)) self.__enter__ = self.lock.__enter__ self.__exit__ = self.lock.__exit__ self.acquire = self.lock.acquire self.release = self.lock.release foo = Foo() # These all function as expected. The fourth line fails (correctly) on 2.7.5. print(repr(foo.__enter__)) print(repr(foo.__exit__)) print(foo.__enter__()) print(foo.__exit__()) # This does not with foo: pass ---------- components: Interpreter Core messages: 207457 nosy: dewin priority: normal severity: normal status: open title: 'with instance' references class's __enter__ attribute rather than instance's type: behavior versions: Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 18:51:43 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Jan 2014 17:51:43 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <3dykmt4mMLzQd9@mail.python.org> Roundup Robot added the comment: New changeset 8dbf8edb7128 by Gregory P. Smith in branch '2.7': Fixes issue19081: When a zipimport .zip file in sys.path being imported http://hg.python.org/cpython/rev/8dbf8edb7128 New changeset 90a99059aa36 by Gregory P. Smith in branch '2.7': news entry for issue19081 fix. http://hg.python.org/cpython/rev/90a99059aa36 New changeset cbeb22969da1 by Gregory P. Smith in branch '2.7': normalize whitespace from prior issue19081 fix commit. http://hg.python.org/cpython/rev/cbeb22969da1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 19:16:01 2014 From: report at bugs.python.org (Thomas Robitaille) Date: Mon, 06 Jan 2014 18:16:01 +0000 Subject: [issue20150] API breakage in string formatting with :s option Message-ID: <1389032161.42.0.577933973443.issue20150@psf.upfronthosting.co.za> New submission from Thomas Robitaille: The following code: >>> "{0:s}".format([1,2,3]) no longer works in Python 3.4b1, and gives the following exception: >>> "{0:s}".format([1,2,3]) Traceback (most recent call last): File "", line 1, in TypeError: non-empty format string passed to object.__format__ This worked previously in Python 2.6-3.3: >>> "{0:s}".format([1,2,3]) '[1, 2, 3]' If this is a deliberate change, it should be included in the 'What's new in Python 3.4' ---------- components: Interpreter Core messages: 207459 nosy: Thomas.Robitaille priority: normal severity: normal status: open title: API breakage in string formatting with :s option versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 19:18:55 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jan 2014 18:18:55 +0000 Subject: [issue20142] Argument Clinic: Py_buffer parameters are not initialized In-Reply-To: <1389017153.04.0.847004275231.issue20142@psf.upfronthosting.co.za> Message-ID: <1389032335.99.0.784868768994.issue20142@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. But is not {NULL} enough for Py_buffer initialization? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 19:20:19 2014 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 06 Jan 2014 18:20:19 +0000 Subject: [issue20150] API breakage in string formatting with :s option In-Reply-To: <1389032161.42.0.577933973443.issue20150@psf.upfronthosting.co.za> Message-ID: <1389032419.84.0.559142304886.issue20150@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +eric.smith, ezio.melotti, larry type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 19:20:48 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jan 2014 18:20:48 +0000 Subject: [issue20142] Argument Clinic: Py_buffer parameters are not initialized In-Reply-To: <1389017153.04.0.847004275231.issue20142@psf.upfronthosting.co.za> Message-ID: <1389032448.56.0.788056032305.issue20142@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Or perhaps we should introduce macros Py_buffer_INIT. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 19:24:39 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 06 Jan 2014 18:24:39 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <1389032679.37.0.784456523276.issue19081@psf.upfronthosting.co.za> Gregory P. Smith added the comment: The Windows 7 buildbot is unhappy after that change and failing one of the new tests: ERROR: testZipFileChangesAfterFirstImport (test.test_zipimport.ZipFileModifiedAfterImportTestCase) Alter the zip file after caching its index and try an import. ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\buildbot.python.org\2.7.kloth-win64\build\lib\test\test_zipimport.py", line 446, in testZipFileChangesAfterFirstImport ziptest_a = __import__("ziptest_a", globals(), locals(), ["test_value"]) ZipImportError: bad local file header in C:\buildbot.python.org\2.7.kloth-win64\build\build\test_python_4388\junk95142.zip It sounds like it was unable to find or properly use an fstat function. I'll fix it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 19:27:36 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 06 Jan 2014 18:27:36 +0000 Subject: [issue20144] Argument Clinic doesn't support named constants as default values In-Reply-To: <1389018193.74.0.0273889485321.issue20144@psf.upfronthosting.co.za> Message-ID: <1389032856.9.0.862823317297.issue20144@psf.upfronthosting.co.za> Larry Hastings added the comment: Attached is an example of how we could support simple named constants in __text_signature__. The change to posixmodule.c is just a hack to exercise the code in inspect.Signature; I didn't have a good example handy. When I apply the patch and run "x.py", I see: (path, *, dir_fd=None, follow_symlinks=True, fake=9223372036854775807) This patch is just an example; I don't propose to check it in in this state. (We'd still need to modify Argument Clinic to support these named constants, too.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 19:30:14 2014 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 06 Jan 2014 18:30:14 +0000 Subject: [issue20150] API breakage in string formatting with :s option In-Reply-To: <1389032161.42.0.577933973443.issue20150@psf.upfronthosting.co.za> Message-ID: <1389033014.72.0.528434067759.issue20150@psf.upfronthosting.co.za> Eric V. Smith added the comment: See issue 7994 and issue 9856. This behavior has been deprecated for a while, and is now an error. ---------- assignee: -> eric.smith resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 19:33:22 2014 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 06 Jan 2014 18:33:22 +0000 Subject: [issue20150] API change in string formatting with :s option should be documented in What's New. In-Reply-To: <1389032161.42.0.577933973443.issue20150@psf.upfronthosting.co.za> Message-ID: <1389033202.17.0.23169831435.issue20150@psf.upfronthosting.co.za> Eric V. Smith added the comment: Oops, I missed the "should be documented" part of your message. That's true, and I'll leave this open. But I'll change it to a doc request and assign it accordingly. ---------- assignee: eric.smith -> docs at python components: +Documentation -Interpreter Core nosy: +docs at python resolution: invalid -> status: closed -> open title: API breakage in string formatting with :s option -> API change in string formatting with :s option should be documented in What's New. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 19:34:33 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Jan 2014 18:34:33 +0000 Subject: [issue20142] Argument Clinic: Py_buffer parameters are not initialized In-Reply-To: <1389017153.04.0.847004275231.issue20142@psf.upfronthosting.co.za> Message-ID: <3dylkJ0mKJzSfC@mail.python.org> Roundup Robot added the comment: New changeset 16ff19d1d367 by Larry Hastings in branch 'default': Issue #20142: Py_buffer variables generated by Argument Clinic are now http://hg.python.org/cpython/rev/16ff19d1d367 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 19:35:06 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 06 Jan 2014 18:35:06 +0000 Subject: [issue20142] Argument Clinic: Py_buffer parameters are not initialized In-Reply-To: <1389017153.04.0.847004275231.issue20142@psf.upfronthosting.co.za> Message-ID: <1389033306.17.0.239821964191.issue20142@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- assignee: -> larry resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 19:45:22 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 06 Jan 2014 18:45:22 +0000 Subject: [issue20144] Argument Clinic doesn't support named constants as default values In-Reply-To: <1389018193.74.0.0273889485321.issue20144@psf.upfronthosting.co.za> Message-ID: <1389033922.0.0.33426410114.issue20144@psf.upfronthosting.co.za> Larry Hastings added the comment: Whoops, forgot to attach the file. here it is. ---------- Added file: http://bugs.python.org/file33331/larry.simple.named.constants.in.text.signature.example _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 19:52:16 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 06 Jan 2014 18:52:16 +0000 Subject: [issue20143] Argument Clinic: negative line numbers In-Reply-To: <1389017993.56.0.244329561856.issue20143@psf.upfronthosting.co.za> Message-ID: <1389034336.09.0.790195755942.issue20143@psf.upfronthosting.co.za> Larry Hastings added the comment: I've seen the problem before, but was too busy to fix it. Give me a reproducable test case and I'll fix it. ---------- assignee: -> larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 20:10:57 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Jan 2014 19:10:57 +0000 Subject: [issue20143] Argument Clinic: negative line numbers In-Reply-To: <1389017993.56.0.244329561856.issue20143@psf.upfronthosting.co.za> Message-ID: <3dymXJ2Fg3z7Ljs@mail.python.org> Roundup Robot added the comment: New changeset 9c8d31d69044 by Larry Hastings in branch 'default': Issue #20143: The line numbers reported in Argument Clinic errors are http://hg.python.org/cpython/rev/9c8d31d69044 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 20:12:10 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 06 Jan 2014 19:12:10 +0000 Subject: [issue20143] Argument Clinic: negative line numbers In-Reply-To: <1389017993.56.0.244329561856.issue20143@psf.upfronthosting.co.za> Message-ID: <1389035530.97.0.630066170803.issue20143@psf.upfronthosting.co.za> Larry Hastings added the comment: Oh, golly, this was one of those "what was I thinking?" sorts of bugs. The problem (and the fix) was obvious once I stared at it long enough. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 20:40:09 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 06 Jan 2014 19:40:09 +0000 Subject: [issue20144] Argument Clinic doesn't support named constants as default values In-Reply-To: <1389018193.74.0.0273889485321.issue20144@psf.upfronthosting.co.za> Message-ID: <1389037209.06.0.93062299933.issue20144@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: It seems a little unfortunate that you lose the symbolic default, especially since the expanded number just appears random. >>> print(inspect.signature(os.stat)) (path, *, dir_fd=None, follow_symlinks=True, fake=9223372036854775807) >>> sys.maxsize 9223372036854775807 ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 20:44:25 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Jan 2014 19:44:25 +0000 Subject: [issue20149] 'with instance' references class's __enter__ attribute rather than instance's In-Reply-To: <1389030144.11.0.294634334929.issue20149@psf.upfronthosting.co.za> Message-ID: <1389037465.59.0.681978660042.issue20149@psf.upfronthosting.co.za> R. David Murray added the comment: "magic methods" like __enter__ and __exit__ are only looked up on the class, not on the instance. This is by design. In some older versions of Python some specific methods (and I think __enter__ and __exit__ were among them for a time) were looked up on the instances, but this was a bug. (Personally I think it would be nice if they were looked up on the instances, but there are good reasons why this is not done.) ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 20:49:09 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jan 2014 19:49:09 +0000 Subject: [issue20151] Convert the binascii module to use Argument Clinic Message-ID: <1389037748.15.0.70999359123.issue20151@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Here is a patch which converts the binascii module to use Argument Clinic. 14 functions are converted. There is one known issue. Pydoc doesn't show signature and docstring for several functions: a2b_qp, b2a_qp, crc32. ---------- components: Extension Modules files: binascii_clinic.patch keywords: patch messages: 207473 nosy: larry, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Convert the binascii module to use Argument Clinic type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file33332/binascii_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 21:18:13 2014 From: report at bugs.python.org (Brett Cannon) Date: Mon, 06 Jan 2014 20:18:13 +0000 Subject: [issue20152] Use Argument Clinic with _imp Message-ID: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> New submission from Brett Cannon: Since _imp isn't directly exposed it isn't a priority to do the conversion, but for maintenance and such it should still occur. ---------- assignee: brett.cannon messages: 207474 nosy: brett.cannon, larry priority: low severity: normal stage: needs patch status: open title: Use Argument Clinic with _imp versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 21:18:22 2014 From: report at bugs.python.org (Brett Cannon) Date: Mon, 06 Jan 2014 20:18:22 +0000 Subject: [issue20152] Use Argument Clinic with _imp In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1389039502.4.0.951755406193.issue20152@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- components: +Extension Modules _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 21:23:55 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 06 Jan 2014 20:23:55 +0000 Subject: [issue20144] Argument Clinic doesn't support named constants as default values In-Reply-To: <1389018193.74.0.0273889485321.issue20144@psf.upfronthosting.co.za> Message-ID: <1389039835.92.0.703506930327.issue20144@psf.upfronthosting.co.za> Larry Hastings added the comment: It is unfortunate, but on the other hand that's what happens in Python too: >>> import sys >>> import inspect >>> def foo(blah=sys.maxsize): pass ... >>> str(inspect.signature(foo)) '(blah=9223372036854775807)' Nick proposed something we could use to fix these (I think he called them "named constants") but it's not in the language yet. Anyway propagating those all the way from Argument Clinic to inspect.Signature would be tricky. Could you live with this being checked in to 3.4? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 21:29:15 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 06 Jan 2014 20:29:15 +0000 Subject: [issue20144] Argument Clinic doesn't support named constants as default values In-Reply-To: <1389039835.92.0.703506930327.issue20144@psf.upfronthosting.co.za> Message-ID: <20140106152916.3bcd5291@anarchist.wooz.org> Barry A. Warsaw added the comment: On Jan 06, 2014, at 08:23 PM, Larry Hastings wrote: >Could you live with this being checked in to 3.4? For sure! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 21:46:44 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 Jan 2014 20:46:44 +0000 Subject: [issue19255] Don't "wipe" builtins at shutdown In-Reply-To: <1381700055.32.0.691639350713.issue19255@psf.upfronthosting.co.za> Message-ID: <1389041204.91.0.53999994217.issue19255@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the patch, Gennadiy. Two comments: 1) I don't think re-doing the whole initialization like that is ok. It's too brutal and may also not work as you want. 2) To validate your changes, you should add a unit test anyway (in test_builtin perhaps). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 21:47:47 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 Jan 2014 20:47:47 +0000 Subject: [issue19255] Don't "wipe" builtins at shutdown In-Reply-To: <1381700055.32.0.691639350713.issue19255@psf.upfronthosting.co.za> Message-ID: <1389041267.9.0.76013906662.issue19255@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Also, since such changes are subtle and error-prone, I think it's better to defer until 3.5 now that 3.4b2 has been released. Serhiy, what do you think? ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 21:51:24 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 06 Jan 2014 20:51:24 +0000 Subject: [issue20144] Argument Clinic doesn't support named constants as default values In-Reply-To: <1389018193.74.0.0273889485321.issue20144@psf.upfronthosting.co.za> Message-ID: <1389041484.38.0.91142615227.issue20144@psf.upfronthosting.co.za> Larry Hastings added the comment: Attached is a patch supporting simple symbolic constants. It works from beginning to end--you specify it in the Argument Clinic input and it shows up in the inspect.Signature and uses the constant in the generated C code. One complication: when using one of these constants, I force you to specify a c_default. Which is now automatically supported on all converters, as is py_default. I converted pattern_match in _sre.c as a sample. I won't check that part of the patch in; it's just to give you an idea of what it looks like for the user. ---------- Added file: http://bugs.python.org/file33333/larry.simple.symbolic.constant.default.values.diff.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 21:56:21 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 06 Jan 2014 20:56:21 +0000 Subject: [issue19723] Argument Clinic should add markers for humans In-Reply-To: <1385150644.99.0.984146693257.issue19723@psf.upfronthosting.co.za> Message-ID: <1389041781.43.0.417907208537.issue19723@psf.upfronthosting.co.za> Guido van Rossum added the comment: I grepped for clinic in the source code and I have a hunch why this confusing: each clinic-generated block has *three* marker comments, each containing [clinic] or [clinic checksum: ...]. TBH I can't always tell on which side of the comment the generated code sits, so I agree it would be nice if there was an additional keyword clearly indicating begin/end. Looking more carefully it seems the pattern is /*[clinic] . . (this seems to be the clinic input) . [clinic]*/ . . (this seems to be generated) . /*[clinic checksum: da39a3ee5e6b4b0d3255bfef95601890afd80709]*/ I expect things would be clearer to the uninitiated if instead they said something like: /*[clinic input] . . . [clinic start generated code]*/ . . . /*[clinic end generated code; checksum: da39a3ee5e6b4b0d3255bfef95601890afd80709]*/ Larry, would that be easy? ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 21:57:56 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 Jan 2014 20:57:56 +0000 Subject: [issue20144] Argument Clinic doesn't support named constants as default values In-Reply-To: <1389018193.74.0.0273889485321.issue20144@psf.upfronthosting.co.za> Message-ID: <1389041876.01.0.54533146335.issue20144@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 22:00:13 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 06 Jan 2014 21:00:13 +0000 Subject: [issue19723] Argument Clinic should add markers for humans In-Reply-To: <1385150644.99.0.984146693257.issue19723@psf.upfronthosting.co.za> Message-ID: <1389042013.53.0.974847128173.issue19723@psf.upfronthosting.co.za> Larry Hastings added the comment: And for Python blocks would you suggest /*[python input] ... [python start generated code]*/ ... /*[python end generated code; checksum: da39a3ee5e6b4b0d3255bfef95601890afd80709]*/ To answer your question: no, it wouldn't be hard. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 22:01:36 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 06 Jan 2014 21:01:36 +0000 Subject: [issue19723] Argument Clinic should add markers for humans In-Reply-To: <1385150644.99.0.984146693257.issue19723@psf.upfronthosting.co.za> Message-ID: <1389042096.24.0.153829131805.issue19723@psf.upfronthosting.co.za> Guido van Rossum added the comment: Yes. Then I suggest working on a patch before people get too deep into the conversion project. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 22:04:12 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jan 2014 21:04:12 +0000 Subject: [issue20144] Argument Clinic doesn't support named constants as default values In-Reply-To: <1389039835.92.0.703506930327.issue20144@psf.upfronthosting.co.za> Message-ID: <1472485.67sFbGPdFy@raxxla> Serhiy Storchaka added the comment: I proposed contrary approach. Allow docstring to fake signature. >>> import sys >>> import inspect >>> def foo(blah=sys.maxsize): "foo(blah=sys.maxsize)" pass ... >>> str(inspect.signature(foo)) '(blah=sys.maxsize)' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 22:08:23 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Jan 2014 21:08:23 +0000 Subject: [issue19255] Don't "wipe" builtins at shutdown In-Reply-To: <1381700055.32.0.691639350713.issue19255@psf.upfronthosting.co.za> Message-ID: <1389042503.52.0.3805715435.issue19255@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 22:09:07 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 06 Jan 2014 21:09:07 +0000 Subject: [issue20144] Argument Clinic doesn't support named constants as default values In-Reply-To: <1389018193.74.0.0273889485321.issue20144@psf.upfronthosting.co.za> Message-ID: <1389042547.77.0.0151700275716.issue20144@psf.upfronthosting.co.za> Larry Hastings added the comment: storchaka: You propose a result, not an approach. How do you propose we do that? In any case, I think making *that* work would be way too big a change for 3.4. Whatever you proposed would only be appropriate for 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 22:19:07 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jan 2014 21:19:07 +0000 Subject: [issue19723] Argument Clinic should add markers for humans In-Reply-To: <1385150644.99.0.984146693257.issue19723@psf.upfronthosting.co.za> Message-ID: <1389043147.73.0.279208447355.issue19723@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Why not just move most (except implementation function headers) generated code out to separate file? Right now the list of symbols in the Kate editor contains three names for every function: BINASCII_A2B_UU_METHODDEF, binascii_a2b_uu and binascii_a2b_uu_impl. This makes navigation cumbersome. Also when I search function name a2b_uu, I found 13 occurrences (it will be decreased to 2 or 3 if move generated code out). So search is not helpful too, ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 22:35:50 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 06 Jan 2014 21:35:50 +0000 Subject: [issue19723] Argument Clinic should add markers for humans In-Reply-To: <1385150644.99.0.984146693257.issue19723@psf.upfronthosting.co.za> Message-ID: <1389044150.98.0.240395386745.issue19723@psf.upfronthosting.co.za> Guido van Rossum added the comment: I use Emacs, so I have no idea what would help for Kate. I suppose Kate is programmable? Maybe you can add some kind of filter for this purpose? If e.g. binascii_a2b_uu_impl were moved to a different file, how would binascii_a2b_uu call it without exposing the symbol externally? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 22:37:33 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 Jan 2014 21:37:33 +0000 Subject: [issue19723] Argument Clinic should add markers for humans In-Reply-To: <1389044150.98.0.240395386745.issue19723@psf.upfronthosting.co.za> Message-ID: <1389044250.2265.2.camel@fsol> Antoine Pitrou added the comment: > If e.g. binascii_a2b_uu_impl were moved to a different file, how would > binascii_a2b_uu call it without exposing the symbol externally? I think "stitching it with #include" is the only workable solution. We already do this for e.g. stringlib. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 22:44:10 2014 From: report at bugs.python.org (Chris Rebert) Date: Mon, 06 Jan 2014 21:44:10 +0000 Subject: [issue20138] wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode In-Reply-To: <1389001619.16.0.909145148031.issue20138@psf.upfronthosting.co.za> Message-ID: <1389044650.69.0.852322584236.issue20138@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 22:55:11 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 06 Jan 2014 21:55:11 +0000 Subject: [issue19723] Argument Clinic should add markers for humans In-Reply-To: <1385150644.99.0.984146693257.issue19723@psf.upfronthosting.co.za> Message-ID: <1389045311.35.0.494964991666.issue19723@psf.upfronthosting.co.za> Guido van Rossum added the comment: And the stringlib situation confuses the hell out of me already. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 22:58:43 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Jan 2014 21:58:43 +0000 Subject: [issue20153] New-in-3.4 weakref finalizer doc section is already out of date. Message-ID: <1389045523.36.0.692306072283.issue20153@psf.upfronthosting.co.za> New submission from R. David Murray: The following discussion section in the weakref docs: http://docs.python.org/dev/library/weakref.html#comparing-finalizers-with-del-methods which was added in 3.4, is out of date because of the GC improvements. It should be tweaked to match the new reality. (I've already deleted the Note under __callback__.) ---------- assignee: docs at python components: Documentation messages: 207489 nosy: docs at python, pitrou, r.david.murray, sbt priority: normal severity: normal stage: needs patch status: open title: New-in-3.4 weakref finalizer doc section is already out of date. type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 23:06:49 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jan 2014 22:06:49 +0000 Subject: [issue19723] Argument Clinic should add markers for humans In-Reply-To: <1385150644.99.0.984146693257.issue19723@psf.upfronthosting.co.za> Message-ID: <1389046009.09.0.94739939131.issue19723@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > I use Emacs, so I have no idea what would help for Kate. I suppose Kate is programmable? Maybe you can add some kind of filter for this purpose? In comparision with Emacs it is not programmable. > If e.g. binascii_a2b_uu_impl were moved to a different file, how would binascii_a2b_uu call it without exposing the symbol externally? No, I propose to move generated binascii_a2b_uu__doc__, BINASCII_A2B_UU_METHODDEF and binascii_a2b_uu to separate file, and left clinic input and binascii_a2b_uu_impl in main file. Then #include "binascii.clinic" should be added before the list of module functions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 6 23:09:37 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jan 2014 22:09:37 +0000 Subject: [issue19723] Argument Clinic should add markers for humans In-Reply-To: <1385150644.99.0.984146693257.issue19723@psf.upfronthosting.co.za> Message-ID: <1389046177.91.0.956952091078.issue19723@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In contrast to stringlib programmers should not look in these generated files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 00:06:45 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 06 Jan 2014 23:06:45 +0000 Subject: [issue19723] Argument Clinic should add markers for humans In-Reply-To: <1385150644.99.0.984146693257.issue19723@psf.upfronthosting.co.za> Message-ID: <1389049605.58.0.403810905158.issue19723@psf.upfronthosting.co.za> Guido van Rossum added the comment: Then the separate file version looks much worse to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 00:07:12 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 06 Jan 2014 23:07:12 +0000 Subject: [issue19723] Argument Clinic should add markers for humans In-Reply-To: <1385150644.99.0.984146693257.issue19723@psf.upfronthosting.co.za> Message-ID: <1389049632.15.0.398331813786.issue19723@psf.upfronthosting.co.za> Larry Hastings added the comment: If it's source code, programmers will need to examine it from time to time. A more important distinction imo: stringlib is type-parameterized like some sort of prehistoric C++ template specialization. Thankfully the gunk generated by Argument Clinic is free of such dizzying technology. Another approach to making Clinic output easier to read--which I thought I also proposed at one point--would be to save up most of the Clinic output in an "accumulator", then emit the contents of the accumulator on demand. Clinic could probably get away with only generating a prototype for the generated function, the macro for the methoddef, and the prototype (sans semicolon) for the impl. The bulk of the generated code, the implementation of the generated function and the docstring, would go in the "accumulator" and could be tucked away anywhere in the file you like. I could even make it idiot-proof; if you haven't emptied the accumulator before the end of the file, it could tack the correct Clinic block on the end for you. Here's a quick mockup of what that would look like: /*[clinic] zlib.compress bytes: Py_buffer Binary data to be compressed. [ level: int Compression level, in 0-9. ] / Returns compressed string. [clinic]*/ #define ZLIB_COMPRESS_METHODDEF \ {"compress", (PyCFunction)zlib_compress, METH_VARARGS, zlib_compress__doc__}, static PyObject * zlib_compress(PyModuleDef *module, PyObject *args); static PyObject * zlib_compress_impl(PyModuleDef *module, Py_buffer *bytes, int group_right_1, int level) /*[clinic checksum: 9f055a396620bc1a8a13d74c3496249528b32b0d]*/ { PyObject *ReturnVal = NULL; Byte *input, *output = NULL; unsigned int length; ... Not sure how far this suggestion ever got; I think maybe I only showed it to Stefan Krah, who said it wouldn't help his use case so I dropped it. Any good? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 01:07:48 2014 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 07 Jan 2014 00:07:48 +0000 Subject: [issue20154] Deadlock in asyncio.StreamReader.readexactly() Message-ID: <1389053268.48.0.216080788193.issue20154@psf.upfronthosting.co.za> New submission from Guido van Rossum: There's currently a deadlock in StreamReader.readexactly() -- if the requested size is larger than the buffer limit for pause, the transport may be paused with no way to unpause it. See http://code.google.com/p/tulip/issues/detail?id=99 in the Tulip tracker. ---------- assignee: gvanrossum messages: 207494 nosy: gvanrossum priority: high severity: normal stage: test needed status: open title: Deadlock in asyncio.StreamReader.readexactly() type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 01:09:29 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Jan 2014 00:09:29 +0000 Subject: [issue20154] Deadlock in asyncio.StreamReader.readexactly() In-Reply-To: <1389053268.48.0.216080788193.issue20154@psf.upfronthosting.co.za> Message-ID: <3dyv8m71gFz7LjN@mail.python.org> Roundup Robot added the comment: New changeset 54d32e01bbfd by Guido van Rossum in branch 'default': asyncio: Fix deadlock in readexactly(). Fixes issue #20154. http://hg.python.org/cpython/rev/54d32e01bbfd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 01:15:52 2014 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 07 Jan 2014 00:15:52 +0000 Subject: [issue20154] Deadlock in asyncio.StreamReader.readexactly() In-Reply-To: <1389053268.48.0.216080788193.issue20154@psf.upfronthosting.co.za> Message-ID: <1389053752.06.0.0799303504987.issue20154@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'd appreciate help writing a test. (Debugging this already set me back enough hours.) ---------- resolution: -> remind _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 01:19:11 2014 From: report at bugs.python.org (Jeff Allen) Date: Tue, 07 Jan 2014 00:19:11 +0000 Subject: [issue20155] Regression test test_httpservers fails, hangs on Windows Message-ID: <1389053951.39.0.997653737297.issue20155@psf.upfronthosting.co.za> New submission from Jeff Allen: When I run: start python -m test.test_httpservers test_request_line_trimming reports ERROR, and the test hangs at test_version_none. If I run a copy of the test in which the latter test is skipped with @unittest.skipIf(sys.platform == "win32", "..."), the error report is: ====================================================================== ERROR: test_request_line_trimming (__main__.BaseHTTPServerTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "test_httpservers.py", line 122, in test_request_line_trimming res = self.con.getresponse() File "C:\Python33\lib\http\client.py", line 1131, in getresponse response.begin() File "C:\Python33\lib\http\client.py", line 354, in begin version, status, reason = self._read_status() File "C:\Python33\lib\http\client.py", line 316, in _read_status line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1") File "C:\Python33\lib\socket.py", line 297, in readinto return self._sock.recv_into(b) ConnectionResetError: [WinError 10054] An existing connection was forcibly closed by the remote host This is essentially the same for Python 2.7.6 and for the current development tip of Jython 2.7b1+, which is actually where the problem first manifested. My machine is running 64-bit Windows 7 SP1, recently re-installed to a new, empty disk. Careful testing, elaborating the failing tests, shows that what is sent in PUT and GET operations is not quite what is received. Something tampers with the connection between the client and the server. (Identical traffic where the verbs are not PUT and GET arrives as sent.) Something fiddles with the forward message, for example "correcting" the spurious \n in test_request_line_trimming to a full \r\n, and holding back the payload of a PUT even when it was in the first packet. On the reverse path, it appears to act on the error response itself by closing the connection, without passing it to the client. Disabling the firewall (Windows Firewall and a commercial one), with the network cable unplugged, makes no difference. Nor does stopping anti-virus, anti-phishing, parental controls, etc.. However, stopping the Windows Basic Filtering Engine (BFE), makes the regression test run without error. Stopping the BFE takes out several dependent services, including Windows Firewall, but it seems likely the BFE itself is the culprit. Although the cause lies in the platform, not in Python, it seems to me still an "issue" for Python that the tests fail on a common platform practically out of the box. I'll work on this in the context of the Jython test and report back here. ---------- components: Library (Lib), Windows messages: 207497 nosy: jeff.allen priority: normal severity: normal status: open title: Regression test test_httpservers fails, hangs on Windows versions: Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 01:56:52 2014 From: report at bugs.python.org (Lewis Levin) Date: Tue, 07 Jan 2014 00:56:52 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za> Message-ID: <1389056212.92.0.684385992961.issue12641@psf.upfronthosting.co.za> Lewis Levin added the comment: This is broken for Python 2.7.4. Is it fixed in 2.7.6? gcc deprecated -mno-cygwin. It's not there any more. There shouldn't be a discussion. This is an incredibly poor example of how fragmentation and poor process result in poor quality open source software--in the corners, even when the overall code is excellent. Over 2 years on something this trivial. Hundreds of lines of discussion. There wasn't really any reason for this to have persisted. ---------- nosy: +lewisl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 01:59:07 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 07 Jan 2014 00:59:07 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za> Message-ID: <1389056347.18.0.280442227987.issue12641@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > This is broken for Python 2.7.4. Is it fixed in 2.7.6? The fix is in 2.7.6, yes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 04:01:31 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Tue, 07 Jan 2014 03:01:31 +0000 Subject: [issue1322] platform.dist() has unpredictable result under Linux In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za> Message-ID: <1389063691.6.0.699684822144.issue1322@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Thanks for the review. Attached the patch to address Marc-Andre Lemburg's concern. ---------- Added file: http://bugs.python.org/file33334/deprecate_platform_dist_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 04:51:07 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Jan 2014 03:51:07 +0000 Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451 In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za> Message-ID: <3dz04V2YMtz7Ljv@mail.python.org> Roundup Robot added the comment: New changeset 37caaf21f827 by Eric Snow in branch 'default': Issue 19713: Add PEP 451-related deprecations. http://hg.python.org/cpython/rev/37caaf21f827 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 04:51:07 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Jan 2014 03:51:07 +0000 Subject: [issue19703] Update pydoc to PEP 451 In-Reply-To: <1386308732.16.0.241139477522.issue19703@psf.upfronthosting.co.za> Message-ID: <3dz04W0fC1z7Ljv@mail.python.org> Roundup Robot added the comment: New changeset f67ccb4490ea by Eric Snow in branch 'default': Issue #19703: Update pydoc to use the new importer APIs. http://hg.python.org/cpython/rev/f67ccb4490ea ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 04:52:46 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 07 Jan 2014 03:52:46 +0000 Subject: [issue19703] Update pydoc to PEP 451 In-Reply-To: <1386308732.16.0.241139477522.issue19703@psf.upfronthosting.co.za> Message-ID: <1389066766.12.0.433202805648.issue19703@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 04:55:08 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 07 Jan 2014 03:55:08 +0000 Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451 In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za> Message-ID: <1389066908.3.0.937673108697.issue19713@psf.upfronthosting.co.za> Eric Snow added the comment: Larry: There wasn't any API change for this issue. It was a matter of fixing up places that were still using find_module/find_loader/load_module. ---------- resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 04:57:04 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 07 Jan 2014 03:57:04 +0000 Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451 In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za> Message-ID: <1389067024.48.0.731162847609.issue19713@psf.upfronthosting.co.za> Eric Snow added the comment: Also: changeset: 88332:bfcbe41e892d4451b53bb5674fc4fa4ae791ec8c user: Eric Snow date: Mon Jan 06 20:42:59 2014 -0700 summary: Remove more usage of APIs deprecated by PEP 451. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 05:00:40 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 07 Jan 2014 04:00:40 +0000 Subject: [issue20125] We need a good replacement for direct use of load_module(), post-PEP 451 In-Reply-To: <1388888272.45.0.255353824658.issue20125@psf.upfronthosting.co.za> Message-ID: <1389067240.92.0.473687141208.issue20125@psf.upfronthosting.co.za> Eric Snow added the comment: Yeah, waiting on this until 3.5 is fine with me. Arfrever brought it up so I at least wanted to track it. ---------- stage: -> needs patch versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 05:04:43 2014 From: report at bugs.python.org (Joshua Chia) Date: Tue, 07 Jan 2014 04:04:43 +0000 Subject: [issue20156] bz2.BZ2File.read() does not treat growing input file properly Message-ID: <1389067483.09.0.426788772717.issue20156@psf.upfronthosting.co.za> New submission from Joshua Chia: When using bz2.BZ2File to read an input file that is growing slowly, repeated read()ing eventually catches up to the end and subsequently fails to produce any more data while the input file continues growing. In 2.7, the symptom is that read() keeps returning no data even after the file grows. In 3.3, the symptom is "EOFError: Compressed file ended before the end-of-stream marker was reached". The correct behavior is to not consume partial compressed data during read() and be able to read() properly later after the input file grows. The EOFError should not be raised until close() is called and the file is found to not ending at an end-of-stream marker. While some existing software may depend on the current behavior, the new behavior may break the existing software. However, predicating the new behavior on constructor parameter buffer being non-zero may mitigate incompatibility problems as using buffer during reading currently doesn't seem to make much sense. To repro the problem, use the attached slow-copy.py to slowly copy a large-enough source bz2 file to a destination bz2 file. Then run the following script on the slowly-growing destination bz2 file: import bz2 import sys import time if len(sys.argv) != 2: exit(1) total = 0 with bz2.BZ2File(sys.argv[1], 'r', buffering=8192) as input: while True: bytes = input.read(8192) bytes = len(bytes) total += bytes print('{} {}'.format(total, bytes)) if bytes < 8192: time.sleep(0.5) ---------- components: Library (Lib) files: slow-copy.py messages: 207506 nosy: Joshua.Chia priority: normal severity: normal status: open title: bz2.BZ2File.read() does not treat growing input file properly type: behavior versions: Python 2.7, Python 3.3 Added file: http://bugs.python.org/file33335/slow-copy.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 06:21:49 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 07 Jan 2014 05:21:49 +0000 Subject: [issue19944] Make importlib.find_spec load packages as needed In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za> Message-ID: <1389072109.97.0.810713176907.issue19944@psf.upfronthosting.co.za> Eric Snow added the comment: Here's an update to the patch. It includes doc and test changes. It also moves find_spec() into importlib.util. (I'm removing the other patches since I don't consider them valid approaches any longer). ---------- Added file: http://bugs.python.org/file33336/issue19944-find-spec-mirror-import-module-direct.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 06:21:58 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 07 Jan 2014 05:21:58 +0000 Subject: [issue19944] Make importlib.find_spec load packages as needed In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za> Message-ID: <1389072118.95.0.329115952385.issue19944@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file33299/issue19944-find-spec-mirror-import-module-direct.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 06:22:08 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 07 Jan 2014 05:22:08 +0000 Subject: [issue19944] Make importlib.find_spec load packages as needed In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za> Message-ID: <1389072128.24.0.217394910618.issue19944@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file33112/issue19944-find-spec-mirror-import-module-simple.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 06:22:14 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 07 Jan 2014 05:22:14 +0000 Subject: [issue19944] Make importlib.find_spec load packages as needed In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za> Message-ID: <1389072134.85.0.0312622498793.issue19944@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file33111/issue19944-find-spec-mirror-import-module.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 06:22:24 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 07 Jan 2014 05:22:24 +0000 Subject: [issue19944] Make importlib.find_spec load packages as needed In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za> Message-ID: <1389072144.21.0.238732566813.issue19944@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file33087/issue19944-find-spec-parent-module.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 06:22:56 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 07 Jan 2014 05:22:56 +0000 Subject: [issue19944] Make importlib.find_spec load packages as needed In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za> Message-ID: <1389072176.21.0.810377233885.issue19944@psf.upfronthosting.co.za> Eric Snow added the comment: (...and to reduce any confusion on which patch is under consideration.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 06:27:47 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 07 Jan 2014 05:27:47 +0000 Subject: [issue18864] Implementation for PEP 451 (importlib.machinery.ModuleSpec) In-Reply-To: <1377672978.26.0.119702109188.issue18864@psf.upfronthosting.co.za> Message-ID: <1389072467.4.0.500667803247.issue18864@psf.upfronthosting.co.za> Eric Snow added the comment: About the only thing left for this ticket is to finish up writing a few tests and round out some documentation. ---------- dependencies: -Update pickle to take advantage of PEP 451, Update zipimport for PEP 451 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 06:32:28 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 07 Jan 2014 05:32:28 +0000 Subject: [issue18864] Implementation for PEP 451 (importlib.machinery.ModuleSpec) In-Reply-To: <1377672978.26.0.119702109188.issue18864@psf.upfronthosting.co.za> Message-ID: <1389072748.7.0.241203145946.issue18864@psf.upfronthosting.co.za> Eric Snow added the comment: There are a few lingering to-do comments that will need to be addressed as part of the remaining work: Lib/test/test_importlib/extension/test_case_sensitivity.py:# XXX find_spec tests Lib/test/test_importlib/extension/test_finder.py:# XXX find_spec tests Lib/test/test_importlib/source/test_file_loader.py: mod = loader.load_module('_temp') # XXX Lib/test/test_importlib/source/test_file_loader.py: # XXX Change to use exec_module(). Lib/test/test_importlib/test_windows.py: # XXX Need a test that finds the spec via the registry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 06:35:04 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 07 Jan 2014 05:35:04 +0000 Subject: [issue19944] Make importlib.find_spec load packages as needed In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za> Message-ID: <1389072904.87.0.812961931072.issue19944@psf.upfronthosting.co.za> Eric Snow added the comment: If nothing else comes up, this will be the last PEP-451 functional change for 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 09:42:46 2014 From: report at bugs.python.org (Victor Varvariuc) Date: Tue, 07 Jan 2014 08:42:46 +0000 Subject: [issue14119] Ability to adjust queue size in Executors In-Reply-To: <1330129142.34.0.452763799677.issue14119@psf.upfronthosting.co.za> Message-ID: <1389084166.64.0.483951119499.issue14119@psf.upfronthosting.co.za> Victor Varvariuc added the comment: Maybe I should have created another issue for this, but without this issue being solved, the new issue will not help much. Here it is: http://hg.python.org/cpython/file/37caaf21f827/Lib/concurrent/futures/thread.py#l63 After running an work item `work_queue.task_done()` is not called. So it's difficult to know if worker threads have any more work to do. http://stackoverflow.com/questions/20965754/determine-if-worker-threads-are-doing-any-work?noredirect=1#comment31495804_20965754 ---------- nosy: +Victor.Varvariuc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 10:08:52 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jan 2014 09:08:52 +0000 Subject: [issue20157] Argument Clinic generates wrong keyword parameter name for "default" Message-ID: <1389085732.24.0.553020879492.issue20157@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: For the "default" keyword parameter Argument Clinic generates wrong name "default_value" in the _keywords array. /*[clinic] module spam spam.ham default: int = 1 [clinic]*/ ... static PyObject * spam_ham(PyModuleDef *module, PyObject *args, PyObject *kwargs) { PyObject *return_value = NULL; static char *_keywords[] = {"default_value", NULL}; int default_value = 1; if (!PyArg_ParseTupleAndKeywords(args, kwargs, "|i:ham", _keywords, &default_value)) goto exit; ... ---------- components: Build files: spammodule.c messages: 207513 nosy: larry, serhiy.storchaka priority: release blocker severity: normal stage: needs patch status: open title: Argument Clinic generates wrong keyword parameter name for "default" type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file33337/spammodule.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 10:11:25 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Jan 2014 09:11:25 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <3dz7B46ZHwz7Lkl@mail.python.org> Roundup Robot added the comment: New changeset e09644eb6b20 by Gregory P. Smith in branch '2.7': Should fix the issue19081 fix on Windows. Don't let the previous http://hg.python.org/cpython/rev/e09644eb6b20 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 10:12:09 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jan 2014 09:12:09 +0000 Subject: [issue20158] Argument Clinic: add --clean option Message-ID: <1389085929.13.0.245678018197.issue20158@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: It will be helpful to add the --clean option for the clinic tool, which removes all Argument Clinic generated code. ---------- messages: 207515 nosy: larry, serhiy.storchaka priority: normal severity: normal status: open title: Argument Clinic: add --clean option type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 10:26:25 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 09:26:25 +0000 Subject: [issue20158] Argument Clinic: add --clean option In-Reply-To: <1389085929.13.0.245678018197.issue20158@psf.upfronthosting.co.za> Message-ID: <1389086785.27.0.0689301427565.issue20158@psf.upfronthosting.co.za> Larry Hastings added the comment: When would you want this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 10:27:18 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 09:27:18 +0000 Subject: [issue20157] Argument Clinic generates wrong keyword parameter name for "default" In-Reply-To: <1389085732.24.0.553020879492.issue20157@psf.upfronthosting.co.za> Message-ID: <1389086838.81.0.797985492244.issue20157@psf.upfronthosting.co.za> Larry Hastings added the comment: I'll fix this but it's low priority for today. It's not a release blocker; we could release Python 3.4 with this bug. ---------- assignee: -> larry priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 10:29:27 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jan 2014 09:29:27 +0000 Subject: [issue20159] Convert the ElementTree module to use Argument Clinic Message-ID: <1389086966.47.0.33615845784.issue20159@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Here is a patch which converts xml.etree.ElementTree accelerator module to use Argument Clinic. 34 methods are converted. Not converted __init__ methods (is Argument Clinic support it?) and the SubElement function which seems can't be converted. ---------- components: Extension Modules, XML files: etree_clinic.patch keywords: patch messages: 207518 nosy: eli.bendersky, larry, scoder, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Convert the ElementTree module to use Argument Clinic type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file33338/etree_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 10:29:52 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jan 2014 09:29:52 +0000 Subject: [issue20159] Convert the ElementTree module to use Argument Clinic In-Reply-To: <1389086966.47.0.33615845784.issue20159@psf.upfronthosting.co.za> Message-ID: <1389086992.95.0.512140775621.issue20159@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Argument Clinic generates wrong keyword parameter name for "default", Argument Clinic: broken support for 'O!' _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 10:34:18 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 07 Jan 2014 09:34:18 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <1389087258.25.0.0103807741144.issue19081@psf.upfronthosting.co.za> Gregory P. Smith added the comment: updated 3.3 patch based off the changes made to the 2.7 one. ---------- Added file: http://bugs.python.org/file33339/issue19081-33-gps05.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 10:34:45 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 07 Jan 2014 09:34:45 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <1389087285.44.0.623922290042.issue19081@psf.upfronthosting.co.za> Changes by Gregory P. Smith : Removed file: http://bugs.python.org/file33323/issue19081-33-gps04.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 10:37:54 2014 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 07 Jan 2014 09:37:54 +0000 Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit Windows (large structs) Message-ID: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za> New submission from Mark Dickinson: The argument-passing code for passing structs larger than 8 bytes is broken on 64-bit Windows, leading to potential segmentation faults or other unpredictable behaviour. According to http://msdn.microsoft.com/en-us/library/zthk2dkh.aspx structs not of size 1, 2, 4 or 8 bytes should be passed by pointer. ctypes instead puts sizeof(struct) bytes onto the stack. The offending code is in ffi_prep_args in /Modules/_ctypes/libffi_msvc/ffi.c, which apparently hasn't been kept up to date with the /Modules/_ctypes/libffi/src/x86/ffi.c. The latter module works correctly: it has an extra #ifdef X86_WIN64 block (shown below) to take care of structs not of size 1, 2, 4 or 8. That block is missing in the libffi_msvc version. z = (*p_arg)->size; #ifdef X86_WIN64 if (z > sizeof(ffi_arg) || ((*p_arg)->type == FFI_TYPE_STRUCT && (z != 1 && z != 2 && z != 4 && z != 8)) #if FFI_TYPE_DOUBLE != FFI_TYPE_LONGDOUBLE || ((*p_arg)->type == FFI_TYPE_LONGDOUBLE) #endif ) { z = sizeof(ffi_arg); *(void **)argp = *p_argv; } else if ((*p_arg)->type == FFI_TYPE_FLOAT) { memcpy(argp, *p_argv, z); } else #endif It looks to me as though issue 17310 may be related. Credit for this discovery should go to Freek Mank. ---------- components: ctypes messages: 207520 nosy: mark.dickinson priority: high severity: normal status: open title: broken ctypes calling convention on MSVC / 64-bit Windows (large structs) type: crash versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 10:38:39 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jan 2014 09:38:39 +0000 Subject: [issue20161] inspect.signature fails on some functions which use Argument Clinic Message-ID: <1389087519.42.0.859376106795.issue20161@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: inspect.signature fails on some functions which use Argument Clinic. For example after applying issue20133 or issue20151 it fails for audioop.ratecv and binascii.a2b_qp. >>> inspect.signature(audioop.ratecv) Traceback (most recent call last): File "", line 1, in File "/home/serhiy/py/cpython/Lib/inspect.py", line 1468, in signature return Signature.from_builtin(obj) File "/home/serhiy/py/cpython/Lib/inspect.py", line 1989, in from_builtin p(name, default) File "/home/serhiy/py/cpython/Lib/inspect.py", line 1982, in p default = default.n AttributeError: type object '_empty' has no attribute 'n' ---------- messages: 207521 nosy: larry, serhiy.storchaka priority: release blocker severity: normal status: open title: inspect.signature fails on some functions which use Argument Clinic type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 10:40:01 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jan 2014 09:40:01 +0000 Subject: [issue20151] Convert the binascii module to use Argument Clinic In-Reply-To: <1389037748.15.0.70999359123.issue20151@psf.upfronthosting.co.za> Message-ID: <1389087601.06.0.0872940214859.issue20151@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +inspect.signature fails on some functions which use Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 10:40:11 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jan 2014 09:40:11 +0000 Subject: [issue20133] Convert the audioop module to use Argument Clinic In-Reply-To: <1388956864.17.0.114751586443.issue20133@psf.upfronthosting.co.za> Message-ID: <1389087611.07.0.863236154532.issue20133@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +inspect.signature fails on some functions which use Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 10:40:29 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jan 2014 09:40:29 +0000 Subject: [issue20148] Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1389087629.94.0.124235118851.issue20148@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +inspect.signature fails on some functions which use Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 10:45:52 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 09:45:52 +0000 Subject: [issue20161] inspect.signature fails on some functions which use Argument Clinic In-Reply-To: <1389087519.42.0.859376106795.issue20161@psf.upfronthosting.co.za> Message-ID: <1389087952.14.0.851864810478.issue20161@psf.upfronthosting.co.za> Larry Hastings added the comment: I already noticed this; it'll be fixed in the patch for #20144. But thanks for the report! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 11:39:34 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 10:39:34 +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: <1389091174.6.0.690041435815.issue20160@psf.upfronthosting.co.za> Larry Hastings added the comment: For the record, I'd be very happy to accept a patch for this into 3.4 at any time. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 12:36:48 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jan 2014 11:36:48 +0000 Subject: [issue20158] Argument Clinic: add --clean option In-Reply-To: <1389086785.27.0.0689301427565.issue20158@psf.upfronthosting.co.za> Message-ID: <3669481.xhe3f0pGBB@raxxla> Serhiy Storchaka added the comment: As fast as it is possible. This shouldn't be hard task, Argument Clinic already clean old generated code before inserting new code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 12:38:55 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 11:38:55 +0000 Subject: [issue20158] Argument Clinic: add --clean option In-Reply-To: <1389085929.13.0.245678018197.issue20158@psf.upfronthosting.co.za> Message-ID: <1389094735.85.0.105602174653.issue20158@psf.upfronthosting.co.za> Larry Hastings added the comment: I meant, under what circumstances would you want to use this? I don't know why you would ever want --clean. Removing the output from the Argument Clinic blocks would break any file using it. And Argument Clinic is sufficiently fast, if you were worried about the output being wrong you could just run it again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 12:52:15 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 11:52:15 +0000 Subject: [issue20144] Argument Clinic doesn't support named constants as default values In-Reply-To: <1389018193.74.0.0273889485321.issue20144@psf.upfronthosting.co.za> Message-ID: <1389095535.37.0.297693581124.issue20144@psf.upfronthosting.co.za> Larry Hastings added the comment: Here's a second patch; I think this is ready to go in I cleaned up the node parsing a lot. It now knows how to parse the following types of default values: * Number (this applies to both ints and floats) * String ('hello') * Attribute (sys.maxsize) * Named constant (None, True, False) As long as I'm fixing this, I want to add support for any other values we're going to want. Did I miss any? Note that we can't really support container types, because initializing them on the C side isn't practical. Also, the tests don't exercise all of the above possible node types, just because I couldn't remember builtins that used those types. We'll fill in the remaining tests as we port new functions to Argument Clinic. If I can get a quick LGTM review, I'll check this in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 13:00:55 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 12:00:55 +0000 Subject: [issue20144] Argument Clinic doesn't support named constants as default values In-Reply-To: <1389018193.74.0.0273889485321.issue20144@psf.upfronthosting.co.za> Message-ID: <1389096055.25.0.718741251225.issue20144@psf.upfronthosting.co.za> Larry Hastings added the comment: Oops! I forgot to actually attach the new patch. I'm dumb. ---------- Added file: http://bugs.python.org/file33340/larry.simple.symbolic.constant.default.values.diff.2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 13:06:56 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 12:06:56 +0000 Subject: [issue19723] Argument Clinic should add markers for humans In-Reply-To: <1385150644.99.0.984146693257.issue19723@psf.upfronthosting.co.za> Message-ID: <1389096416.22.0.990075827139.issue19723@psf.upfronthosting.co.za> Larry Hastings added the comment: Antoine just suggested that, if we used this "accumulator" thing, we'd want a convention for where the generated text should go. I actually have an answer for that: near the end, below the implementations of the module / class methods, but above the methoddef/type structures and the module init function. My reasoning: when I navigate CPython C files implementing a module or a type, when I know what entry point I want I just search for its name. When I don't know what I want, I jump to the end, then scroll up until I find the name in the init function or the structures. So I wouldn't want the code at the very end; that would screw up that navigation mode. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 13:10:17 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 07 Jan 2014 12:10:17 +0000 Subject: [issue19723] Argument Clinic should add markers for humans In-Reply-To: <1385150644.99.0.984146693257.issue19723@psf.upfronthosting.co.za> Message-ID: <1389096617.83.0.523749068534.issue19723@psf.upfronthosting.co.za> Stefan Krah added the comment: > I think maybe I only showed it to Stefan Krah, who said it wouldn't help his use case so I dropped it. I think we were talking about _decimal, where any tool will interfere with the 100% code coverage patches. But that's a special case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 14:05:26 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jan 2014 13:05:26 +0000 Subject: [issue20158] Argument Clinic: add --clean option In-Reply-To: <1389094735.85.0.105602174653.issue20158@psf.upfronthosting.co.za> Message-ID: <2572164.DJy2o9EQmm@raxxla> Serhiy Storchaka added the comment: This would just make sources more readable and editable. While I read, write or edit code, I don't want generated code distract me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 14:09:41 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jan 2014 13:09:41 +0000 Subject: [issue2263] struct.pack() + numpy int raises SystemError In-Reply-To: <1205134764.8.0.415620235375.issue2263@psf.upfronthosting.co.za> Message-ID: <1389100181.95.0.0113237990858.issue2263@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 14:09:48 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jan 2014 13:09:48 +0000 Subject: [issue9307] Py_TPFLAGS_LONG_SUBCLASS is not documented In-Reply-To: <1279561825.23.0.120090245801.issue9307@psf.upfronthosting.co.za> Message-ID: <1389100188.05.0.899455641303.issue9307@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 14:10:01 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 13:10:01 +0000 Subject: [issue20158] Argument Clinic: add --clean option In-Reply-To: <1389085929.13.0.245678018197.issue20158@psf.upfronthosting.co.za> Message-ID: <1389100201.46.0.123778808952.issue20158@psf.upfronthosting.co.za> Larry Hastings added the comment: I don't think Argument Clinic should do this. It would leave the file in a broken state. But if it's an option on clinic.py it might tempt somebody into using it, then they'd be confused. If you want this functionality, please hack it up yourself locally. I wouldn't accept this as a patch. Personally I just got used to the Clinic generated code. ---------- resolution: -> rejected stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 14:20:48 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 13:20:48 +0000 Subject: [issue20141] Argument Clinic: broken support for 'O!' In-Reply-To: <1389013934.21.0.28397308089.issue20141@psf.upfronthosting.co.za> Message-ID: <1389100848.6.0.590090012957.issue20141@psf.upfronthosting.co.za> Larry Hastings added the comment: Attached is a new, simpler approach for supporting O!. The object() converter now takes two arguments: * type, which is the type you want the parameter declared as (e.g. "PyUnicodeObject *") * subclass_of, which is the PyTypeObject you want to enforce the value is an instance of (e.g. "&PyUnicode_Type") The old approach was kind of a lovely idea, but was too complicated, and it would have meant registering any new type (like third-party types). This is less convenient, but simple. And it would lend itself well to making a custom converter if you used it a lot. I'll write some documentation for it now, but I wanted to post the code so I could get a review. p.s. Why was is marked "crash" and "release blocker"? That's very inaccurate. And assigned to docs? WTH? ---------- assignee: docs at python -> larry nosy: -docs at python priority: release blocker -> normal stage: -> patch review type: crash -> behavior Added file: http://bugs.python.org/file33341/larry.argument.clinic.o-bang.rethink.diff.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 14:22:36 2014 From: report at bugs.python.org (Yury V. Zaytsev) Date: Tue, 07 Jan 2014 13:22:36 +0000 Subject: [issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64 Message-ID: <1389100955.98.0.880527340764.issue20162@psf.upfronthosting.co.za> New submission from Yury V. Zaytsev: Hi, When I try the following: ./python -m test -v test_hash on a self-compiled Python 3.4.0b2 on RHEL 6.5 / ppc64, it fails. Please let me know which additional information I can supply to diagnose the problem. The complete traceback below: == CPython 3.4.0b2 (default, Jan 6 2014, 15:23:43) [GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] == Linux-2.6.32-431.el6.ppc64-ppc64-with-redhat-6.5-Santiago big-endian == hash algorithm: siphash24 64bit == /XXX/build/test_python_13082 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) [1/1] test_hash test_empty_string (test.test_hash.BytesHashRandomizationTests) ... ok test_fixed_hash (test.test_hash.BytesHashRandomizationTests) ... ok test_long_fixed_hash (test.test_hash.BytesHashRandomizationTests) ... ok test_null_hash (test.test_hash.BytesHashRandomizationTests) ... ok test_randomized_hash (test.test_hash.BytesHashRandomizationTests) ... ok test_randomized_hash (test.test_hash.DatetimeDateTests) ... ok test_randomized_hash (test.test_hash.DatetimeDatetimeTests) ... ok test_randomized_hash (test.test_hash.DatetimeTimeTests) ... ok test_hashes (test.test_hash.HashBuiltinsTestCase) ... ok test_hash_distribution (test.test_hash.HashDistributionTestCase) ... FAIL test_coerced_floats (test.test_hash.HashEqualityTestCase) ... ok test_coerced_integers (test.test_hash.HashEqualityTestCase) ... ok test_numeric_literals (test.test_hash.HashEqualityTestCase) ... ok test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... ok test_default_hash (test.test_hash.HashInheritanceTestCase) ... ok test_error_hash (test.test_hash.HashInheritanceTestCase) ... ok test_fixed_hash (test.test_hash.HashInheritanceTestCase) ... ok test_hashable (test.test_hash.HashInheritanceTestCase) ... ok test_not_hashable (test.test_hash.HashInheritanceTestCase) ... ok test_empty_string (test.test_hash.MemoryviewHashRandomizationTests) ... ok test_fixed_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok test_long_fixed_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok test_null_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok test_randomized_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok test_empty_string (test.test_hash.StrHashRandomizationTests) ... ok test_fixed_hash (test.test_hash.StrHashRandomizationTests) ... ok test_long_fixed_hash (test.test_hash.StrHashRandomizationTests) ... ok test_null_hash (test.test_hash.StrHashRandomizationTests) ... ok test_randomized_hash (test.test_hash.StrHashRandomizationTests) ... ok test_ucs2_string (test.test_hash.StrHashRandomizationTests) ... ok ====================================================================== FAIL: test_hash_distribution (test.test_hash.HashDistributionTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/XXX/Lib/test/test_hash.py", line 340, in test_hash_distribution self.assertGreater(len(s15), 8, prefix) AssertionError: 1 not greater than 8 : abc ---------------------------------------------------------------------- Ran 30 tests in 0.694s FAILED (failures=1) 1 test failed: test_hash Thanks! ---------- components: Tests messages: 207533 nosy: zaytsev priority: normal severity: normal status: open title: Test test_hash_distribution fails on RHEL 6.5 / ppc64 type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 14:24:31 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 07 Jan 2014 13:24:31 +0000 Subject: [issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64 In-Reply-To: <1389100955.98.0.880527340764.issue20162@psf.upfronthosting.co.za> Message-ID: <1389101071.06.0.266686182708.issue20162@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- components: +Interpreter Core nosy: +David.Edelsohn, christian.heimes, dmalcolm priority: normal -> high type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 14:28:03 2014 From: report at bugs.python.org (Yury V. Zaytsev) Date: Tue, 07 Jan 2014 13:28:03 +0000 Subject: [issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64 In-Reply-To: <1389100955.98.0.880527340764.issue20162@psf.upfronthosting.co.za> Message-ID: <1389101283.96.0.634725331593.issue20162@psf.upfronthosting.co.za> Yury V. Zaytsev added the comment: As requested by Victor Stinner: ./python -c 'import sys; print(sys.hash_info)' sys.hash_info(width=64, modulus=2305843009213693951, inf=314159, nan=0, imag=1000003, algorithm='siphash24', hash_bits=64, seed_bits=128, cutoff=0) ---------- components: -Interpreter Core type: behavior -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 14:39:38 2014 From: report at bugs.python.org (Yury V. Zaytsev) Date: Tue, 07 Jan 2014 13:39:38 +0000 Subject: [issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64 In-Reply-To: <1389100955.98.0.880527340764.issue20162@psf.upfronthosting.co.za> Message-ID: <1389101978.64.0.0915684110624.issue20162@psf.upfronthosting.co.za> Yury V. Zaytsev added the comment: Sorry for accidentally rolling back your changes to the bug, Antoine! ---------- components: +Interpreter Core -Tests type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 14:40:08 2014 From: report at bugs.python.org (Yury V. Zaytsev) Date: Tue, 07 Jan 2014 13:40:08 +0000 Subject: [issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64 In-Reply-To: <1389100955.98.0.880527340764.issue20162@psf.upfronthosting.co.za> Message-ID: <1389102008.05.0.797279179472.issue20162@psf.upfronthosting.co.za> Changes by Yury V. Zaytsev : ---------- components: +Tests _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 14:42:13 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Jan 2014 13:42:13 +0000 Subject: [issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64 In-Reply-To: <1389100955.98.0.880527340764.issue20162@psf.upfronthosting.co.za> Message-ID: <3dzFBX49CpzPVW@mail.python.org> Roundup Robot added the comment: New changeset 81f8b4744f1a by Victor Stinner in branch 'default': Issue #20162: test_hash_distribution() uses subTest() to mention the prefix in http://hg.python.org/cpython/rev/81f8b4744f1a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 14:49:56 2014 From: report at bugs.python.org (Yury V. Zaytsev) Date: Tue, 07 Jan 2014 13:49:56 +0000 Subject: [issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64 In-Reply-To: <1389100955.98.0.880527340764.issue20162@psf.upfronthosting.co.za> Message-ID: <1389102596.19.0.685944979594.issue20162@psf.upfronthosting.co.za> Yury V. Zaytsev added the comment: ====================================================================== FAIL: test_hash_distribution (test.test_hash.HashDistributionTestCase) (prefix='abc') ---------------------------------------------------------------------- Traceback (most recent call last): File "/XXX/Lib/test/test_hash.py", line 341, in test_hash_distribution self.assertGreater(len(s15), 8, prefix) AssertionError: 1 not greater than 8 : abc ====================================================================== FAIL: test_hash_distribution (test.test_hash.HashDistributionTestCase) (prefix='abcdefghabc') ---------------------------------------------------------------------- Traceback (most recent call last): File "/XXX/Lib/test/test_hash.py", line 341, in test_hash_distribution self.assertGreater(len(s15), 8, prefix) AssertionError: 1 not greater than 8 : abcdefghabc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 14:57:09 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jan 2014 13:57:09 +0000 Subject: [issue20141] Argument Clinic: broken support for 'O!' In-Reply-To: <1389013934.21.0.28397308089.issue20141@psf.upfronthosting.co.za> Message-ID: <1389103029.89.0.672584430957.issue20141@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It is marked "crash" because Argument Clinic generates code which crashes. It is assigned to docs because this feature documentation is misleading. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 15:19:12 2014 From: report at bugs.python.org (Yury V. Zaytsev) Date: Tue, 07 Jan 2014 14:19:12 +0000 Subject: [issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64 In-Reply-To: <1389100955.98.0.880527340764.issue20162@psf.upfronthosting.co.za> Message-ID: <1389104352.91.0.890670729526.issue20162@psf.upfronthosting.co.za> Yury V. Zaytsev added the comment: To check whether the problem is in the _le64toh() macro as suggested by Victor Stinner, I've tried the attached patch and the problem is gone. As it turns out, there actually seem to be two problems: First, HAVE_ENDIAN_H is properly defined, because the correct include file is found, but HAVE_LETOH64 is not defined, even though it exists in the system and is working. Therefore, the macro implementation is used instead. However, the second problem is that apparently something is wrong about the macro, even though Victor says it looks fine on the paper, because when macro is replaced by a function from glibc like in my patch, it works. The solution to the first problem, I guess, is to add a proper check to the configure script. I don't have a solution for the second problem. For the record, the test output with the patch applied: bash-4.1$ ./python -m test -v test_hash == CPython 3.4.0b2 (default, Jan 7 2014, 15:03:44) [GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] == Linux-2.6.32-431.el6.ppc64-ppc64-with-redhat-6.5-Santiago big-endian == hash algorithm: siphash24 64bit == /XXX/build/test_python_27880 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) [1/1] test_hash test_empty_string (test.test_hash.BytesHashRandomizationTests) ... ok test_fixed_hash (test.test_hash.BytesHashRandomizationTests) ... ok test_long_fixed_hash (test.test_hash.BytesHashRandomizationTests) ... ok test_null_hash (test.test_hash.BytesHashRandomizationTests) ... ok test_randomized_hash (test.test_hash.BytesHashRandomizationTests) ... ok test_randomized_hash (test.test_hash.DatetimeDateTests) ... ok test_randomized_hash (test.test_hash.DatetimeDatetimeTests) ... ok test_randomized_hash (test.test_hash.DatetimeTimeTests) ... ok test_hashes (test.test_hash.HashBuiltinsTestCase) ... ok test_hash_distribution (test.test_hash.HashDistributionTestCase) ... ok test_coerced_floats (test.test_hash.HashEqualityTestCase) ... ok test_coerced_integers (test.test_hash.HashEqualityTestCase) ... ok test_numeric_literals (test.test_hash.HashEqualityTestCase) ... ok test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... ok test_default_hash (test.test_hash.HashInheritanceTestCase) ... ok test_error_hash (test.test_hash.HashInheritanceTestCase) ... ok test_fixed_hash (test.test_hash.HashInheritanceTestCase) ... ok test_hashable (test.test_hash.HashInheritanceTestCase) ... ok test_not_hashable (test.test_hash.HashInheritanceTestCase) ... ok test_empty_string (test.test_hash.MemoryviewHashRandomizationTests) ... ok test_fixed_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok test_long_fixed_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok test_null_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok test_randomized_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok test_empty_string (test.test_hash.StrHashRandomizationTests) ... ok test_fixed_hash (test.test_hash.StrHashRandomizationTests) ... ok test_long_fixed_hash (test.test_hash.StrHashRandomizationTests) ... ok test_null_hash (test.test_hash.StrHashRandomizationTests) ... ok test_randomized_hash (test.test_hash.StrHashRandomizationTests) ... ok test_ucs2_string (test.test_hash.StrHashRandomizationTests) ... ok ---------------------------------------------------------------------- Ran 30 tests in 0.759s OK 1 test OK. ---------- keywords: +patch Added file: http://bugs.python.org/file33342/pyhash.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 15:28:01 2014 From: report at bugs.python.org (Yury V. Zaytsev) Date: Tue, 07 Jan 2014 14:28:01 +0000 Subject: [issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64 In-Reply-To: <1389100955.98.0.880527340764.issue20162@psf.upfronthosting.co.za> Message-ID: <1389104881.52.0.176837549012.issue20162@psf.upfronthosting.co.za> Yury V. Zaytsev added the comment: I was also asked to mention this: https://github.com/majek/csiphash/blob/master/csiphash.c as an alternative implementation of siphash and platform checks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 15:35:51 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 14:35:51 +0000 Subject: [issue19723] Argument Clinic should add markers for humans In-Reply-To: <1385150644.99.0.984146693257.issue19723@psf.upfronthosting.co.za> Message-ID: <1389105351.01.0.121515267484.issue19723@psf.upfronthosting.co.za> Larry Hastings added the comment: Patch attached. I tweaked the punctuation in the last line, from this: /*[clinic end generated code; checksum: {checksum}]*/ ^ ^ to this: | | v v /*[clinic end generated code: checksum={checksum}]*/ Guido, can you live with that? I think it's a slight improvement but I'm not committed enough to fight about it. I'll change it back if you want it your way. ---------- Added file: http://bugs.python.org/file33343/larry.change.clinic.markers.diff.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 15:45:13 2014 From: report at bugs.python.org (dellair jie) Date: Tue, 07 Jan 2014 14:45:13 +0000 Subject: [issue20163] ValueError: time data does not match format Message-ID: <1389105913.13.0.195664624668.issue20163@psf.upfronthosting.co.za> New submission from dellair jie: Hello, We are using Python 3.3.2 for HPUX11.31. The following error happens only on HPUX, works on SunOS, RHEL, AIX. python Python 3.3.2 (default, Dec 9 2013, 14:04:25) [C] on hp-ux11 Type "help", "copyright", "credits" or "license" for more information. >>> from datetime import datetime >>> datetime.strptime ("10-Dec-13.20:07:49", "%d-%b-%y.%H:%M:%S") Traceback (most recent call last): File "", line 1, in File "/python/lib/python3.3/_strptime.py", line 500, in _strptime_datetime tt, fraction = _strptime(data_string, format) File "/python/lib/python3.3/_strptime.py", line 337, in _strptime (data_string, format)) ValueError: time data '10-Dec-13.20:07:49' does not match format '%d-%b-%y.%H:%M:%S' It looks like a bug. Could you please shed some lights? Thanks in advance, Br, Li ---------- components: Library (Lib) messages: 207542 nosy: dellair.jie priority: normal severity: normal status: open title: ValueError: time data does not match format type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 15:54:43 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 07 Jan 2014 14:54:43 +0000 Subject: [issue20126] sched doesn't handle events added after scheduler starts In-Reply-To: <1388890823.36.0.322424274213.issue20126@psf.upfronthosting.co.za> Message-ID: <1389106483.47.0.509947392112.issue20126@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: I don't think this should be documented as personally I wouldn't expect this use case to be working in the first place. ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 15:58:33 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 14:58:33 +0000 Subject: [issue20158] Argument Clinic: add --clean option In-Reply-To: <1389085929.13.0.245678018197.issue20158@psf.upfronthosting.co.za> Message-ID: <1389106713.02.0.47111471584.issue20158@psf.upfronthosting.co.za> Larry Hastings added the comment: Consider: if you ran "clinic.py --clean" on a C file, then tried to use "make clinic", the makefile would first try to build the C file. But since the C file is now broken, the make would fail. And you can't use "make clinic" to regenerate the Clinic output. Obviously this is fixable, but for someone unfamiliar with Argument Clinic this could be very confusing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 16:00:24 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jan 2014 15:00:24 +0000 Subject: [issue20163] ValueError: time data does not match format In-Reply-To: <1389105913.13.0.195664624668.issue20163@psf.upfronthosting.co.za> Message-ID: <1389106824.16.0.0435629018957.issue20163@psf.upfronthosting.co.za> STINNER Victor added the comment: Try to isolate which field fails. Example: >>> import time >>> time.strptime ("10-Dec-13.20:07:49", "%d-%b-%y.%H:%M:%S") time.struct_time(tm_year=2013, tm_mon=12, tm_mday=10, tm_hour=20, tm_min=7, tm_sec=49, tm_wday=1, tm_yday=344, tm_isdst=-1) >>> time.strptime ("10-Dec-13", "%d-%b-%y") time.struct_time(tm_year=2013, tm_mon=12, tm_mday=10, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=1, tm_yday=344, tm_isdst=-1) >>> time.strptime ("10-Dec", "%d-%b") time.struct_time(tm_year=1900, tm_mon=12, tm_mday=10, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=0, tm_yday=344, tm_isdst=-1) >>> time.strptime ("Dec", "%b") time.struct_time(tm_year=1900, tm_mon=12, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=5, tm_yday=335, tm_isdst=-1) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 16:06:32 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 15:06:32 +0000 Subject: [issue20141] Argument Clinic: broken support for 'O!' In-Reply-To: <1389013934.21.0.28397308089.issue20141@psf.upfronthosting.co.za> Message-ID: <1389107192.08.0.158271932406.issue20141@psf.upfronthosting.co.za> Larry Hastings added the comment: There are lots of ways you can crash Python by giving erroneous input to Argument Clinic. Clinic has no visibility into the C type system, so it has no way of verifying whether or not the type objects you pass in are correct. That's unfixable and not really interesting. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 16:39:00 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 15:39:00 +0000 Subject: [issue20144] Argument Clinic doesn't support named constants as default values In-Reply-To: <1389018193.74.0.0273889485321.issue20144@psf.upfronthosting.co.za> Message-ID: <1389109140.19.0.915893488014.issue20144@psf.upfronthosting.co.za> Larry Hastings added the comment: At Antoine's suggestion, I added a custom function to testcapi that exercises all the different possible types for default values in a text signature. Also the docs have been updated. LGTU? ---------- Added file: http://bugs.python.org/file33344/larry.simple.symbolic.constant.default.values.diff.3.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 16:42:44 2014 From: report at bugs.python.org (dellair jie) Date: Tue, 07 Jan 2014 15:42:44 +0000 Subject: [issue20163] ValueError: time data does not match format In-Reply-To: <1389105913.13.0.195664624668.issue20163@psf.upfronthosting.co.za> Message-ID: <1389109364.57.0.167831934505.issue20163@psf.upfronthosting.co.za> dellair jie added the comment: Victor, Thanks for the comment. Isolated, the error happens at: >>> import time >>> time.strptime ("Dec", "%b") Traceback (most recent call last): File "", line 1, in File "/python/lib/python3.3/_strptime.py", line 494, in _strptime_time tt = _strptime(data_string, format)[0] File "/python/lib/python3.3/_strptime.py", line 340, in _strptime data_string[found.end():]) ValueError: unconverted data remains: Dec ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 16:43:42 2014 From: report at bugs.python.org (dellair jie) Date: Tue, 07 Jan 2014 15:43:42 +0000 Subject: [issue20163] ValueError: time data does not match format In-Reply-To: <1389105913.13.0.195664624668.issue20163@psf.upfronthosting.co.za> Message-ID: <1389109422.25.0.555611567833.issue20163@psf.upfronthosting.co.za> dellair jie added the comment: The output of command: $ date +'%b' Jan $ uname -a HP-UX test5 B.11.31 U ia64 4201936010 unlimited-user license ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 16:57:26 2014 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 07 Jan 2014 15:57:26 +0000 Subject: [issue19723] Argument Clinic should add markers for humans In-Reply-To: <1385150644.99.0.984146693257.issue19723@psf.upfronthosting.co.za> Message-ID: <1389110246.34.0.673293962573.issue19723@psf.upfronthosting.co.za> Guido van Rossum added the comment: The new syntax is fine; I was only giving an example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 17:00:11 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jan 2014 16:00:11 +0000 Subject: [issue20163] ValueError: time data does not match format In-Reply-To: <1389105913.13.0.195664624668.issue20163@psf.upfronthosting.co.za> Message-ID: <1389110411.25.0.975255895697.issue20163@psf.upfronthosting.co.za> STINNER Victor added the comment: > >>> time.strptime ("Dec", "%b") > ValueError: unconverted data remains: Dec Ok, so what is the name of the December month? >>> import time >>> time.strftime("%b", time.gmtime(1387036705)) 'Dec' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 17:15:27 2014 From: report at bugs.python.org (Chris Adams) Date: Tue, 07 Jan 2014 16:15:27 +0000 Subject: [issue20164] Undocumented KeyError from os.path.expanduser Message-ID: <1389111327.1.0.12442170212.issue20164@psf.upfronthosting.co.za> New submission from Chris Adams: This is a more general version of #10496: os.path.expanduser is documented as returning the unmodified string if it cannot be expanded (http://docs.python.org/3/library/os.path.html#os.path.expanduser) but there's one edge case where this can fail: when running without HOME in the environment: https://github.com/python/cpython/blob/3.3/Lib/posixpath.py#L259-L263 In this case, pwd.getpwuid is called and although it's not documented as such, it raises a KeyError anytime the underlying POSIX getpwuid() call fails: https://github.com/python/cpython/blob/3.3/Modules/pwdmodule.c#L119-L120 Reproducing this deliberately: cadams at Io:~ $ sudo -H python Python 2.7.5 (default, Aug 25 2013, 00:04:04) [GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> import posix >>> posix.setuid(1001) >>> posix.seteuid(1001) >>> os.environ.pop('HOME') '/var/root' >>> os.path.expanduser("~") Traceback (most recent call last): File "", line 1, in File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/posixpath.py", line 269, in expanduser userhome = pwd.getpwuid(os.getuid()).pw_dir KeyError: 'getpwuid(): uid not found: 1001' Context: * https://github.com/toastdriven/django-haystack/issues/924 * https://github.com/kennethreitz/requests/issues/1846. ---------- components: Library (Lib) messages: 207552 nosy: acdha priority: normal severity: normal status: open title: Undocumented KeyError from os.path.expanduser versions: Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 17:22:50 2014 From: report at bugs.python.org (dellair jie) Date: Tue, 07 Jan 2014 16:22:50 +0000 Subject: [issue20163] ValueError: time data does not match format In-Reply-To: <1389105913.13.0.195664624668.issue20163@psf.upfronthosting.co.za> Message-ID: <1389111770.06.0.816643113281.issue20163@psf.upfronthosting.co.za> dellair jie added the comment: We get an empty string for the name. :) >>> time.strftime("%b", time.gmtime(1387036705)) '' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 17:30:21 2014 From: report at bugs.python.org (Yury V. Zaytsev) Date: Tue, 07 Jan 2014 16:30:21 +0000 Subject: [issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64 In-Reply-To: <1389100955.98.0.880527340764.issue20162@psf.upfronthosting.co.za> Message-ID: <1389112221.16.0.521989144735.issue20162@psf.upfronthosting.co.za> Yury V. Zaytsev added the comment: After lots of fiddling, I can tell you what's wrong with the macro: apparently it's a compiler bug, visible at -O2 and disappearing at -O1. Assembly output is attached, unfortunately, I'm no ppc64 expert, so I can't immediately tell what exactly went wrong. In any case, the first half of the bug (missing check for HAVE_LETOH64) which triggered the second half still seems valid. I think it's not feasible to upgrade the compiler on RHEL 6.5 (unless someone with a subscription wants to have a go), but fixing the first part should avoid the compiler bug altogether. ---------- Added file: http://bugs.python.org/file33345/le64toh.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 17:38:31 2014 From: report at bugs.python.org (Yury V. Zaytsev) Date: Tue, 07 Jan 2014 16:38:31 +0000 Subject: [issue20164] Undocumented KeyError from os.path.expanduser In-Reply-To: <1389111327.1.0.12442170212.issue20164@psf.upfronthosting.co.za> Message-ID: <1389112711.04.0.0491878764522.issue20164@psf.upfronthosting.co.za> Yury V. Zaytsev added the comment: Amusingly, it's also the case on BG/Q compute nodes. Only this morning, I cooked up the following patch: --- a/Lib/posixpath.py +++ b/Lib/posixpath.py @@ -237,7 +237,11 @@ def expanduser(path): if i == 1: if 'HOME' not in os.environ: import pwd - userhome = pwd.getpwuid(os.getuid()).pw_dir + try: + userhome = pwd.getpwuid(os.getuid()).pw_dir + except KeyError: + import warnings + warnings.warn('Unable to auto-detect $HOME, export it or functionality such as user-installed modules will not work!', RuntimeWarning) else: userhome = os.environ['HOME'] else: I think it's a bit harsh to fail completely, but returning silently also doesn't sound like a good idea, so I decided to issue a warning instead; the wording should be probably tweaked by a native speaker of English though. What do you think? ---------- nosy: +zaytsev type: -> behavior versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 17:38:35 2014 From: report at bugs.python.org (Dave Malcolm) Date: Tue, 07 Jan 2014 16:38:35 +0000 Subject: [issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64 In-Reply-To: <1389112221.16.0.521989144735.issue20162@psf.upfronthosting.co.za> Message-ID: <1389112642.20755.6.camel@surprise> Dave Malcolm added the comment: On Tue, 2014-01-07 at 16:30 +0000, Yury V. Zaytsev wrote: > Yury V. Zaytsev added the comment: > > After lots of fiddling, I can tell you what's wrong with the macro: apparently it's a compiler bug, visible at -O2 and disappearing at -O1. Can you reduce the suspected compiler bug to a minimal reproducer? Please then run it through the preprocessor using gcc's -E option, and then attach it to this bug. What exact version of the compiler are you using, and with what flags? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 17:44:57 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jan 2014 16:44:57 +0000 Subject: [issue20163] ValueError: time data does not match format In-Reply-To: <1389105913.13.0.195664624668.issue20163@psf.upfronthosting.co.za> Message-ID: <1389113097.16.0.291281590791.issue20163@psf.upfronthosting.co.za> STINNER Victor added the comment: > We get an empty string for the name. :) Ok, it's maybe time to upgrade to Linux :-) (How old is HPUX? I didn't know that it's still in use.) I don't see how Python could workaround the issue if strftime("%b") doesn't work. An option would be to reimplemenet strftime() (in Python?), see #3173. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 17:45:28 2014 From: report at bugs.python.org (Yury V. Zaytsev) Date: Tue, 07 Jan 2014 16:45:28 +0000 Subject: [issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64 In-Reply-To: <1389100955.98.0.880527340764.issue20162@psf.upfronthosting.co.za> Message-ID: <1389113128.56.0.59362502523.issue20162@psf.upfronthosting.co.za> Yury V. Zaytsev added the comment: Hi David, It's gcc from RHEL 6.5 gcc-4.4.7-4.el6.ppc64, the flags are "-DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes" vs. "-DNDEBUG -g -fwrapv -O1 -Wall -Wstrict-prototypes". The problem is, I can't isolate it. We honestly tried it with Victor, but gcc doesn't want to miscompile a trivial example. You can see in the attachment as far as I could get: I wrapped the macro in a function, so that it doesn't inline and compared the assembly of the good and bad object files. Hope that helps! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 17:52:00 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jan 2014 16:52:00 +0000 Subject: [issue20158] Argument Clinic: add --clean option In-Reply-To: <1389106713.02.0.47111471584.issue20158@psf.upfronthosting.co.za> Message-ID: <3073690.S5mkKPhaxB@raxxla> Serhiy Storchaka added the comment: How it differs from the case when you just edit clinic declaration and *_impl function? Until you run clinic on this source file, it is broken. I see that peoples already confused by Argument Clinic and manually edit generated code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 17:52:13 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Jan 2014 16:52:13 +0000 Subject: [issue20096] Mention modernize and future in Python 2/3 porting HOWTO In-Reply-To: <1388432630.2.0.0690952057164.issue20096@psf.upfronthosting.co.za> Message-ID: <3dzKPm4XBNzSXf@mail.python.org> Roundup Robot added the comment: New changeset e4d98ed54c53 by Brett Cannon in branch 'default': Issue #20096: Update the Python 2/3 porting HOWTO to focus on http://hg.python.org/cpython/rev/e4d98ed54c53 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 17:52:21 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 16:52:21 +0000 Subject: [issue20157] Argument Clinic generates wrong keyword parameter name for "default" In-Reply-To: <1389085732.24.0.553020879492.issue20157@psf.upfronthosting.co.za> Message-ID: <1389113541.69.0.676856056408.issue20157@psf.upfronthosting.co.za> Larry Hastings added the comment: The problem was an easy fix. However, while fixing it I discovered another problem (if "[clinic]*/" was the last line, and it didn't have an eol, Clinic would append another "[clinic]*/"). I fixed that too and added a regression test. Okay? ---------- Added file: http://bugs.python.org/file33346/larry.clinic.keyword.renamer.diff.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 17:52:37 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 07 Jan 2014 16:52:37 +0000 Subject: [issue20096] Mention modernize and future in Python 2/3 porting HOWTO In-Reply-To: <1388432630.2.0.0690952057164.issue20096@psf.upfronthosting.co.za> Message-ID: <1389113557.3.0.409643509445.issue20096@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: docs at python -> brett.cannon resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 17:53:19 2014 From: report at bugs.python.org (Yury V. Zaytsev) Date: Tue, 07 Jan 2014 16:53:19 +0000 Subject: [issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64 In-Reply-To: <1389100955.98.0.880527340764.issue20162@psf.upfronthosting.co.za> Message-ID: <1389113599.75.0.716424697312.issue20162@psf.upfronthosting.co.za> Yury V. Zaytsev added the comment: Look for _le64toh ;-) ---------- Added file: http://bugs.python.org/file33347/pyhash.preproc.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 17:58:41 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 16:58:41 +0000 Subject: [issue20158] Argument Clinic: add --clean option In-Reply-To: <1389085929.13.0.245678018197.issue20158@psf.upfronthosting.co.za> Message-ID: <1389113921.52.0.600380899027.issue20158@psf.upfronthosting.co.za> Larry Hastings added the comment: If you edit the Clinic input and don't run clinic.py on it, it's out-of-date but not broken. If you edit the Clinic output and make a mistake, it's *your* fault. If you ran clinic.py --clean, now you've broken your file *and* the normal Clinic build system and you were using the tool correctly. It's the *tool's* fault. I will admit to having very little interest in adding a command-line option called "--clean" that breaks everything. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 18:07:37 2014 From: report at bugs.python.org (Yury V. Zaytsev) Date: Tue, 07 Jan 2014 17:07:37 +0000 Subject: [issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64 In-Reply-To: <1389100955.98.0.880527340764.issue20162@psf.upfronthosting.co.za> Message-ID: <1389114457.95.0.727976599468.issue20162@psf.upfronthosting.co.za> Yury V. Zaytsev added the comment: Digging more into it, I guess I know why we couldn't come up with a minimal reproducer for this problem. If I compile with -O2 instead of -O1, I get the following warning from gcc: Python/pyhash.c:413: warning: dereferencing pointer 'pt.32' does break strict-aliasing rules which points to the following line: case 4: *((PY_UINT32_T*)&pt[0]) = *((PY_UINT32_T*)&m[0]); break; If I re-compile with -O2, but -fno-strict-aliasing, then the result doesn't fail. Not sure if siphash code can be changed to not require aliasing, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 18:11:26 2014 From: report at bugs.python.org (Yury V. Zaytsev) Date: Tue, 07 Jan 2014 17:11:26 +0000 Subject: [issue10496] Python startup should not require passwd entry In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za> Message-ID: <1389114686.85.0.231797139963.issue10496@psf.upfronthosting.co.za> Changes by Yury V. Zaytsev : ---------- nosy: +zaytsev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 18:16:52 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 17:16:52 +0000 Subject: [issue20144] Argument Clinic doesn't support named constants as default values In-Reply-To: <1389018193.74.0.0273889485321.issue20144@psf.upfronthosting.co.za> Message-ID: <1389115012.59.0.0474052363039.issue20144@psf.upfronthosting.co.za> Larry Hastings added the comment: Incorporated suggestions from Serhiy. Thanks, Serhiy! ---------- Added file: http://bugs.python.org/file33348/larry.simple.symbolic.constant.default.values.diff.4.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 18:25:47 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jan 2014 17:25:47 +0000 Subject: [issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64 In-Reply-To: <1389100955.98.0.880527340764.issue20162@psf.upfronthosting.co.za> Message-ID: <1389115547.26.0.692668675898.issue20162@psf.upfronthosting.co.za> STINNER Victor added the comment: > Python/pyhash.c:413: warning: dereferencing pointer 'pt.32' does break strict-aliasing rules Attached patch siphash_ppc64.patch should fix this aliasing issue. ---------- nosy: +haypo Added file: http://bugs.python.org/file33349/siphash_ppc64.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 18:27:42 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 07 Jan 2014 17:27:42 +0000 Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451 In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za> Message-ID: <1389115662.46.0.0979116008763.issue19713@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: > New changeset 37caaf21f827 by Eric Snow in branch 'default': > Issue 19713: Add PEP 451-related deprecations. > http://hg.python.org/cpython/rev/37caaf21f827 > ... > - spec.loader.load_module(spec.name) > + try: > + _warnings > + except NameError: > + # We must be importing builtins in setup(). > + spec.loader.load_module(spec.name) > + else: > + spec.loader.load_module(spec.name) Is this correct? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 18:32:31 2014 From: report at bugs.python.org (Yury V. Zaytsev) Date: Tue, 07 Jan 2014 17:32:31 +0000 Subject: [issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64 In-Reply-To: <1389100955.98.0.880527340764.issue20162@psf.upfronthosting.co.za> Message-ID: <1389115951.59.0.771451890628.issue20162@psf.upfronthosting.co.za> Yury V. Zaytsev added the comment: Related issue where memcpy() was discussed: http://bugs.python.org/issue19183 . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 18:33:29 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Jan 2014 17:33:29 +0000 Subject: [issue20072] Ttk tests fail when wantobjects is false In-Reply-To: <1388082006.36.0.0879597768975.issue20072@psf.upfronthosting.co.za> Message-ID: <3dzLKN0cp6z7LjM@mail.python.org> Roundup Robot added the comment: New changeset 2d81d0d42ae2 by Serhiy Storchaka in branch '3.3': Issue #20072: Fixed multiple errors in tkinter with wantobjects is False. http://hg.python.org/cpython/rev/2d81d0d42ae2 New changeset 1628cd94db52 by Serhiy Storchaka in branch 'default': Issue #20072: Fixed multiple errors in tkinter with wantobjects is False. http://hg.python.org/cpython/rev/1628cd94db52 New changeset 89b3836f7378 by Serhiy Storchaka in branch '2.7': Issue #20072: Fixed multiple errors in tkinter with wantobjects is False. http://hg.python.org/cpython/rev/89b3836f7378 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 18:34:01 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jan 2014 17:34:01 +0000 Subject: [issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64 In-Reply-To: <1389115547.26.0.692668675898.issue20162@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Attached patch siphash_ppc64.patch should fix this aliasing issue. It looks like memcpy was discussed in the initial issue #19183 for performances. IMO the function must first produce the good result, and then be fast :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 18:37:39 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jan 2014 17:37:39 +0000 Subject: [issue18515] zipfile._ZipDecryptor generates wasteful crc32 table on import In-Reply-To: <1374331044.49.0.0628884037506.issue18515@psf.upfronthosting.co.za> Message-ID: <1389116259.9.0.714473437775.issue18515@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 18:49:24 2014 From: report at bugs.python.org (Christian Heimes) Date: Tue, 07 Jan 2014 17:49:24 +0000 Subject: [issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64 In-Reply-To: <1389100955.98.0.880527340764.issue20162@psf.upfronthosting.co.za> Message-ID: <1389116964.26.0.867265929466.issue20162@psf.upfronthosting.co.za> Christian Heimes added the comment: Oh heck ... I didn't run into this issue when I was testing siphash on all platforms. Could it be a compiler bug? I'd rather not change the code and deviate from the reference implementation. It's a performance critical part... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 18:53:16 2014 From: report at bugs.python.org (dellair jie) Date: Tue, 07 Jan 2014 17:53:16 +0000 Subject: [issue20163] ValueError: time data does not match format In-Reply-To: <1389105913.13.0.195664624668.issue20163@psf.upfronthosting.co.za> Message-ID: <1389117196.01.0.669150212597.issue20163@psf.upfronthosting.co.za> dellair jie added the comment: Victor, HPUX 11.31 was first released in 2007, we keep upgrading and the latest update is in 2013. ^_^ A workaround sounds fine. By re-implementing strftime(), do you mean to patch it from: http://bugs.python.org/issue1777412? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 18:57:15 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jan 2014 17:57:15 +0000 Subject: [issue20078] zipfile - ZipExtFile.read goes into 100% CPU infinite loop on maliciously binary edited zips In-Reply-To: <1388110280.6.0.508484621949.issue20078@psf.upfronthosting.co.za> Message-ID: <1389117435.76.0.76186201561.issue20078@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Looks as 2.7 is not affected. If there are no objections I will commit this patch tomorrow. ---------- versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 19:05:30 2014 From: report at bugs.python.org (Yury V. Zaytsev) Date: Tue, 07 Jan 2014 18:05:30 +0000 Subject: [issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64 In-Reply-To: <1389100955.98.0.880527340764.issue20162@psf.upfronthosting.co.za> Message-ID: <1389117930.69.0.435958804958.issue20162@psf.upfronthosting.co.za> Yury V. Zaytsev added the comment: Hi Christian, Dave says "it's not a compiler bug; the code is slightly violating the C standard, and the compiler optimizes based on a strict reading of the rules". If I compile with -O2 and higher (while -O3 is the default for Python, as far as I can understand), the compiler correctly warns me about possible issues; as you can see, the macro itself is not at fault, even. It's just that in my particular (rare) mix of circumstances: being big endian, using the macro instead of the glibc function due to the first part of the bug, etc. it results in miscompilation, and in your case, it remains a warning, but the result still works. I think the "clean" solutions to this problem are as follows: 1) Do not break strict aliasing (use memcpy() instead or something) 2) Disable strict aliasing based optimizations (-fno-strict-aliasing) In addition, fixing the first part of the bug (wrongly using a macro even if le64toh is available), will mask the second part for me again, but I'm not sure if it will re-surface at some point later or not :) Hope that helps! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 19:08:04 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jan 2014 18:08:04 +0000 Subject: [issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64 In-Reply-To: <1389100955.98.0.880527340764.issue20162@psf.upfronthosting.co.za> Message-ID: <1389118084.02.0.999745295132.issue20162@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: On platforms where unaligned access is not an issue, gcc produces for memcpy() an optimal binary code equivalent to simple assignment of 32-bit value. Only MSVC produces slow code, but Windows works only on platforms where unaligned access is not an issue. So we can use simple assignment when _MSC_VER is defined and memcpy() in other cases (it is what I was proposed in issue19183 for PY_UHASH_CPY). ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 19:14:36 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jan 2014 18:14:36 +0000 Subject: [issue18960] First line can be executed twice In-Reply-To: <1378559493.77.0.649785663787.issue18960@psf.upfronthosting.co.za> Message-ID: <1389118476.62.0.985853130887.issue18960@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Benjamin, current version (without switch) looks more clean to me. Are you insist? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 19:18:24 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jan 2014 18:18:24 +0000 Subject: [issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64 In-Reply-To: <1389118084.02.0.999745295132.issue20162@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Only MSVC produces slow code, but Windows works only on platforms where unaligned access is not an issue. My patch uses Py_MEMCPY() which uses a loop to copy bytes on Visual Studio for length smaller than 16 bytes (SipHash copies 4 bytes). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 19:28:47 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jan 2014 18:28:47 +0000 Subject: [issue20158] Argument Clinic: add --clean option In-Reply-To: <1389113921.52.0.600380899027.issue20158@psf.upfronthosting.co.za> Message-ID: <5028840.QuXXqeWxsF@raxxla> Serhiy Storchaka added the comment: If you ran clinic.py --clean and then not ran clinic.py without --clean, it's *your* fault. And you will noticed this when run make. I have named this option --clean because it is similar to 'make clean' and 'make distclean'. If you want make automatically call clinic.py, lets 'make clinic' create the .clinic file, 'clinic.py --clean' remove it, and 'make' check if this file exists and run 'make clinic' otherwise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 19:29:08 2014 From: report at bugs.python.org (Chris Adams) Date: Tue, 07 Jan 2014 18:29:08 +0000 Subject: [issue20164] Undocumented KeyError from os.path.expanduser In-Reply-To: <1389111327.1.0.12442170212.issue20164@psf.upfronthosting.co.za> Message-ID: <1389119348.8.0.910394570799.issue20164@psf.upfronthosting.co.za> Chris Adams added the comment: Other than hoisting the warnings import to the top (PEP-8) that seems entirely reasonable to me. The user report which we got was confusing because it was non-obvious where it came from - a warning or other pointer would have helped the original reporter get an idea as to what was failing earlier. The other two changes I'd suggest would be documentation updates: os.path.expanduser noting that KeyError may be raised when HOME is undefined and pwd.getpwuid fails for the active user pwd.getpwuid noting that KeyErrors will be raised when the underlying POSIX call fails ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 19:32:03 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 18:32:03 +0000 Subject: [issue20158] Argument Clinic: add --clean option In-Reply-To: <1389085929.13.0.245678018197.issue20158@psf.upfronthosting.co.za> Message-ID: <1389119523.78.0.820530291062.issue20158@psf.upfronthosting.co.za> Larry Hastings added the comment: I must admit I am losing patience with this conversation. Argument Clinic is not going to provide an attractively-named option that breaks your build and requires fixing by hand. The bug is closed, the feature is not happening, it's my hope that we can now move on. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 19:49:00 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 07 Jan 2014 18:49:00 +0000 Subject: [issue19255] Don't "wipe" builtins at shutdown In-Reply-To: <1381700055.32.0.691639350713.issue19255@psf.upfronthosting.co.za> Message-ID: <1389120540.59.0.872693643357.issue19255@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is simpler patch with a test. ---------- Added file: http://bugs.python.org/file33350/builtins_cleanup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 20:25:21 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 07 Jan 2014 19:25:21 +0000 Subject: [issue20165] unittest TestResult wasSuccessful returns True when there are unexpected successes Message-ID: <1389122721.74.0.155844601606.issue20165@psf.upfronthosting.co.za> New submission from Gregory P. Smith: Python 3.3.3+ (3.3:28337a8fb502+, Jan 7 2014, 01:32:44) [GCC 4.6.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import unittest >>> r = unittest.result.TestResult() >>> r.wasSuccessful() True >>> r.addUnexpectedSuccess("weird!") >>> r.wasSuccessful() True An unexpected success is not a good thing and indicates a problem. the wasSuccessful() method should include a check for len(self.unexpectedSuccesses) == 0 as part of its condition. ---------- assignee: gregory.p.smith messages: 207582 nosy: gregory.p.smith priority: normal severity: normal stage: needs patch status: open title: unittest TestResult wasSuccessful returns True when there are unexpected successes type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 20:26:35 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 07 Jan 2014 19:26:35 +0000 Subject: [issue20165] unittest TestResult wasSuccessful returns True when there are unexpected successes In-Reply-To: <1389122721.74.0.155844601606.issue20165@psf.upfronthosting.co.za> Message-ID: <1389122795.09.0.764515205424.issue20165@psf.upfronthosting.co.za> Gregory P. Smith added the comment: somewhat related - https://code.google.com/p/unittest-ext/issues/detail?id=22 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 20:48:38 2014 From: report at bugs.python.org (jarod) Date: Tue, 07 Jan 2014 19:48:38 +0000 Subject: [issue20166] window x64 c-extensions not works on python3.4.0b2 Message-ID: <1389124118.85.0.0740185864803.issue20166@psf.upfronthosting.co.za> New submission from jarod: After installing python3.4.0b2.amd64 and rebuild modules, most of them stoped works. List of modules is [psutil, ujson]. Exception occurs on importing module: import error: dynamic module does not define init function PyInit_ and I found solution (workaround) - need change declaration of init function: Line: PyObject *PyInit_(void) was changed to: PyMODINIT_FUNC PyInit_(void) and module works fine after rebuild. All works fine with 3.4.0b1 and all alpha versions. I have windows8.1 x64. ---------- components: Build, Windows messages: 207584 nosy: jarod priority: normal severity: normal status: open title: window x64 c-extensions not works on python3.4.0b2 versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 20:53:54 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Jan 2014 19:53:54 +0000 Subject: [issue20144] Argument Clinic doesn't support named constants as default values In-Reply-To: <1389018193.74.0.0273889485321.issue20144@psf.upfronthosting.co.za> Message-ID: <3dzPRP5K4Dz7Lk9@mail.python.org> Roundup Robot added the comment: New changeset c96dba33f019 by Larry Hastings in branch 'default': Issue #20144: Argument Clinic now supports simple constants as parameter http://hg.python.org/cpython/rev/c96dba33f019 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 21:06:20 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 20:06:20 +0000 Subject: [issue20144] Argument Clinic doesn't support named constants as default values In-Reply-To: <1389018193.74.0.0273889485321.issue20144@psf.upfronthosting.co.za> Message-ID: <1389125180.91.0.333841110528.issue20144@psf.upfronthosting.co.za> Larry Hastings added the comment: Argument Clinic now supports simple constants like "sys.maxsize" as default values for arguments for builtins. I'm assuming this gets you basically what you wanted; if this isn't sufficient please open a new issue. ---------- assignee: -> larry resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 21:13:45 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Jan 2014 20:13:45 +0000 Subject: [issue20141] Argument Clinic: broken support for 'O!' In-Reply-To: <1389013934.21.0.28397308089.issue20141@psf.upfronthosting.co.za> Message-ID: <3dzPtK1WRNz7LjQ@mail.python.org> Roundup Robot added the comment: New changeset ddb5cd3e0860 by Larry Hastings in branch 'default': Issue #20141: Improved Argument Clinic's support for the PyArg_Parse "O!" http://hg.python.org/cpython/rev/ddb5cd3e0860 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 21:18:45 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 20:18:45 +0000 Subject: [issue20141] Argument Clinic: broken support for 'O!' In-Reply-To: <1389013934.21.0.28397308089.issue20141@psf.upfronthosting.co.za> Message-ID: <1389125925.05.0.0416525334146.issue20141@psf.upfronthosting.co.za> Larry Hastings added the comment: Argument Clinic's support for "O!" is now simpler and more flexible. It's not as convenient as the previous API, but that API wasn't really sustainable. I'm assuming this fixes your problem; if not please open a new issue. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 21:21:45 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Jan 2014 20:21:45 +0000 Subject: [issue20157] Argument Clinic generates wrong keyword parameter name for "default" In-Reply-To: <1389085732.24.0.553020879492.issue20157@psf.upfronthosting.co.za> Message-ID: <3dzQ3X6HSJz7LjR@mail.python.org> Roundup Robot added the comment: New changeset f61c63ec4e70 by Larry Hastings in branch 'default': Issue #20157: When Argument Clinic renames a parameter because its name http://hg.python.org/cpython/rev/f61c63ec4e70 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 21:22:10 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 20:22:10 +0000 Subject: [issue20157] Argument Clinic generates wrong keyword parameter name for "default" In-Reply-To: <1389085732.24.0.553020879492.issue20157@psf.upfronthosting.co.za> Message-ID: <1389126130.39.0.22663271549.issue20157@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 21:42:28 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Jan 2014 20:42:28 +0000 Subject: [issue19273] Update PCbuild/readme.txt In-Reply-To: <1381956724.6.0.425752006149.issue19273@psf.upfronthosting.co.za> Message-ID: <3dzQWR6jZZz7LjV@mail.python.org> Roundup Robot added the comment: New changeset e8307cf23af4 by Larry Hastings in branch 'default': Issue #19273: The marker comments Argument Clinic uses have been changed http://hg.python.org/cpython/rev/e8307cf23af4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 21:43:42 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 20:43:42 +0000 Subject: [issue19723] Argument Clinic should add markers for humans In-Reply-To: <1385150644.99.0.984146693257.issue19723@psf.upfronthosting.co.za> Message-ID: <1389127422.63.0.972497555754.issue19723@psf.upfronthosting.co.za> Larry Hastings added the comment: I'm assuming this is sufficient. If further bikeshedding is needed please reopen the issue. ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 21:46:48 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 07 Jan 2014 20:46:48 +0000 Subject: [issue20166] window x64 c-extensions not works on python3.4.0b2 In-Reply-To: <1389124118.85.0.0740185864803.issue20166@psf.upfronthosting.co.za> Message-ID: <1389127608.05.0.245114209348.issue20166@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +brian.curtin, tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 21:52:52 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Jan 2014 20:52:52 +0000 Subject: [issue19719] add importlib.abc.SpecLoader and SpecFinder In-Reply-To: <1385144115.2.0.854403656611.issue19719@psf.upfronthosting.co.za> Message-ID: <3dzQlR6rm0z7LjQ@mail.python.org> Roundup Robot added the comment: New changeset 21786a7f8036 by Brett Cannon in branch 'default': Issue #19719: Update various finder and loader ABCs such that their http://hg.python.org/cpython/rev/21786a7f8036 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 21:53:14 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 07 Jan 2014 20:53:14 +0000 Subject: [issue19719] add importlib.abc.SpecLoader and SpecFinder In-Reply-To: <1385144115.2.0.854403656611.issue19719@psf.upfronthosting.co.za> Message-ID: <1389127994.76.0.547610348205.issue19719@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 21:53:31 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 20:53:31 +0000 Subject: [issue20161] inspect.signature fails on some functions which use Argument Clinic In-Reply-To: <1389087519.42.0.859376106795.issue20161@psf.upfronthosting.co.za> Message-ID: <1389128011.94.0.630057420683.issue20161@psf.upfronthosting.co.za> Larry Hastings added the comment: Fixed as a side effect of fixing #20144. And by the way this was never a release blocker. ---------- assignee: -> larry priority: release blocker -> normal resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 21:53:45 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 20:53:45 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1389128025.08.0.183771086536.issue20148@psf.upfronthosting.co.za> Larry Hastings added the comment: Can you refresh the patch? I think all the problems you cited are fixed, and also the comments Argument Clinic uses were all changed. I'll review when you have a fresh patch. ---------- title: Convert the _sre module to use Argument Clinic -> Derby: Convert the _sre module to use Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 21:54:34 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 20:54:34 +0000 Subject: [issue20133] Derby: Convert the audioop module to use Argument Clinic In-Reply-To: <1388956864.17.0.114751586443.issue20133@psf.upfronthosting.co.za> Message-ID: <1389128074.11.0.116443611794.issue20133@psf.upfronthosting.co.za> Larry Hastings added the comment: Can you refresh the patch? I think all the problems you cited are fixed, and also the comments Argument Clinic uses were all changed. I'll review when you have a fresh patch. ---------- title: Convert the audioop module to use Argument Clinic -> Derby: Convert the audioop module to use Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 21:55:08 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 20:55:08 +0000 Subject: [issue20151] Derby: Convert the binascii module to use Argument Clinic In-Reply-To: <1389037748.15.0.70999359123.issue20151@psf.upfronthosting.co.za> Message-ID: <1389128108.0.0.071280888164.issue20151@psf.upfronthosting.co.za> Larry Hastings added the comment: Can you refresh the patch? The comments Argument Clinic uses were all changed. I'll review when you have a fresh patch. ---------- title: Convert the binascii module to use Argument Clinic -> Derby: Convert the binascii module to use Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 21:56:04 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 20:56:04 +0000 Subject: [issue20159] Derby: Convert the ElementTree module to use Argument Clinic In-Reply-To: <1389086966.47.0.33615845784.issue20159@psf.upfronthosting.co.za> Message-ID: <1389128164.02.0.374014196806.issue20159@psf.upfronthosting.co.za> Larry Hastings added the comment: Can you refresh the patch? The comments Argument Clinic uses were all changed. I'll review when you have a fresh patch. And I'll look at __init__ and subelement then. ---------- title: Convert the ElementTree module to use Argument Clinic -> Derby: Convert the ElementTree module to use Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 21:57:10 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 20:57:10 +0000 Subject: [issue20152] Derby: Convert the _imp module to use Argument Clinic In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1389128230.72.0.873261582759.issue20152@psf.upfronthosting.co.za> Larry Hastings added the comment: I'm normalizing the names of these issues so they're easier to read and to search for. ---------- title: Use Argument Clinic with _imp -> Derby: Convert the _imp module to use Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 21:57:38 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jan 2014 20:57:38 +0000 Subject: [issue20167] Exception on IDLE closing Message-ID: <1389128258.47.0.666257212012.issue20167@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: When run IDLE with file name as agument $ ./python -m idlelib.idle Lib/decimal.py and then close or exit it, following traceback is printed: Exception ignored in: > Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/idlelib/MultiCall.py", line 230, in __del__ File "/home/serhiy/py/cpython/Lib/tkinter/__init__.py", line 1043, in unbind _tkinter.TclError: can't invoke "bind" command: application has been destroyed Exception ignored in: > Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/idlelib/MultiCall.py", line 230, in __del__ File "/home/serhiy/py/cpython/Lib/tkinter/__init__.py", line 1043, in unbind _tkinter.TclError: can't invoke "bind" command: application has been destroyed Exception ignored in: > Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/idlelib/MultiCall.py", line 230, in __del__ File "/home/serhiy/py/cpython/Lib/tkinter/__init__.py", line 1043, in unbind _tkinter.TclError: can't invoke "bind" command: application has been destroyed Exception ignored in: > Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/idlelib/MultiCall.py", line 230, in __del__ File "/home/serhiy/py/cpython/Lib/tkinter/__init__.py", line 1043, in unbind _tkinter.TclError: can't invoke "bind" command: application has been destroyed This is occurred only in 3.4. ---------- components: IDLE keywords: 3.4regression messages: 207599 nosy: kbk, roger.serwy, serhiy.storchaka, terry.reedy priority: high severity: normal status: open title: Exception on IDLE closing type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 22:03:59 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jan 2014 21:03:59 +0000 Subject: [issue20168] Derby: Convert the _tkinter module to use Argument Clinic Message-ID: <1389128639.57.0.613370502446.issue20168@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: In progress. Actually many functions are not very suitable for Argument Clinic. ---------- components: Extension Modules, Tkinter messages: 207600 nosy: serhiy.storchaka priority: normal severity: normal status: open title: Derby: Convert the _tkinter module to use Argument Clinic type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 22:04:21 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jan 2014 21:04:21 +0000 Subject: [issue20168] Derby: Convert the _tkinter module to use Argument Clinic In-Reply-To: <1389128639.57.0.613370502446.issue20168@psf.upfronthosting.co.za> Message-ID: <1389128661.3.0.593117913098.issue20168@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 22:04:49 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 07 Jan 2014 21:04:49 +0000 Subject: [issue20165] unittest TestResult wasSuccessful returns True when there are unexpected successes In-Reply-To: <1389122721.74.0.155844601606.issue20165@psf.upfronthosting.co.za> Message-ID: <1389128689.02.0.243397419737.issue20165@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- nosy: +michael.foord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 22:05:40 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jan 2014 21:05:40 +0000 Subject: [issue20144] Argument Clinic doesn't support named constants as default values In-Reply-To: <1389125180.91.0.333841110528.issue20144@psf.upfronthosting.co.za> Message-ID: <1788078.KeBsLtmRLc@raxxla> Serhiy Storchaka added the comment: Thank you Larry for all your fixes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 22:06:53 2014 From: report at bugs.python.org (Brian Quinlan) Date: Tue, 07 Jan 2014 21:06:53 +0000 Subject: [issue14119] Ability to adjust queue size in Executors In-Reply-To: <1330129142.34.0.452763799677.issue14119@psf.upfronthosting.co.za> Message-ID: <1389128813.84.0.766431189881.issue14119@psf.upfronthosting.co.za> Brian Quinlan added the comment: Hi Victor, I don't understand your problem. Could you be very specific in your description? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 22:09:23 2014 From: report at bugs.python.org (Jeremy Kloth) Date: Tue, 07 Jan 2014 21:09:23 +0000 Subject: [issue20168] Derby: Convert the _tkinter module to use Argument Clinic In-Reply-To: <1389128639.57.0.613370502446.issue20168@psf.upfronthosting.co.za> Message-ID: <1389128963.3.0.740648944959.issue20168@psf.upfronthosting.co.za> Changes by Jeremy Kloth : ---------- nosy: +jkloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 22:15:45 2014 From: report at bugs.python.org (=?utf-8?q?Jarek_=C5=9Amiejczak?=) Date: Tue, 07 Jan 2014 21:15:45 +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: <1389129345.17.0.086662598383.issue20140@psf.upfronthosting.co.za> Jarek ?miejczak added the comment: @Vinay.Sajip After adding change you suggested i'm getting different error: --- C:\Users\Jaros?aw>pip install virtualenv Downloading/unpacking virtualenv Running setup.py (path:c:\users\jarosa~1\appdata\local\temp\pip_build_Jaros?a \virtualenv\setup.py) egg_info for package virtualenv warning: no previously-included files matching '*' found under directory 'd cs\_templates' warning: no previously-included files matching '*' found under directory 'd cs\_build' Cleaning up... Exception: Traceback (most recent call last): File "c:\python27\lib\site-packages\pip\basecommand.py", line 122, in main status = self.run(options, args) File "c:\python27\lib\site-packages\pip\commands\install.py", line 270, in ru requirement_set.prepare_files(finder, force_root_egg_info=self.bundle, bund e=self.bundle) File "c:\python27\lib\site-packages\pip\req.py", line 1211, in prepare_files req_to_install.assert_source_matches_version() File "c:\python27\lib\site-packages\pip\req.py", line 451, in assert_source_m tches_version % (display_path(self.source_dir), version, self)) UnicodeDecodeError: 'ascii' codec can't decode byte 0xb3 in position 62: ordina not in range(128) Traceback (most recent call last): File "c:\python27\Scripts\pip-script.py", line 9, in load_entry_point('pip==1.5', 'console_scripts', 'pip')() File "c:\python27\lib\site-packages\pip\__init__.py", line 185, in main return command.main(cmd_args) File "c:\python27\lib\site-packages\pip\basecommand.py", line 161, in main text = '\n'.join(complete_log) UnicodeDecodeError: 'ascii' codec can't decode byte 0xb3 in position 77: ordina not in range(128) C:\Users\Jaros?aw> --- It looks like this needs a little more changes in pip to solve this issue. What's strange: In Windows 8.1, name of home directory is first name saved in your Microsoft Profile (if you log via this profile of course), so it should be a pretty common issue (i think). Thanks for your fast reaction and support. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 22:35:33 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 21:35:33 +0000 Subject: [issue20168] Derby: Convert the _tkinter module to use Argument Clinic In-Reply-To: <1389128639.57.0.613370502446.issue20168@psf.upfronthosting.co.za> Message-ID: <1389130533.92.0.82812108038.issue20168@psf.upfronthosting.co.za> Larry Hastings added the comment: What functions, and what makes them unsuitable? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 22:58:06 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jan 2014 21:58:06 +0000 Subject: [issue20168] Derby: Convert the _tkinter module to use Argument Clinic In-Reply-To: <1389130533.92.0.82812108038.issue20168@psf.upfronthosting.co.za> Message-ID: <9594188.oEjLz4mIuz@raxxla> Serhiy Storchaka added the comment: call() just converts all args to Tcl list. Is Argument Clinic supports *args and **kwargs? I'm not sure there is a benefit with using Argument Clinic here. splitlist() and split() first call PyArg_ParseTuple with one argument, check the input, and then may call PyArg_ParseTuple with other argument. They need large refactoring to use Argument Clinic. getint(), getdouble(), getboolean() first manually unpack arguments tuple, and then may call PyArg_ParseTuple. Same as above. setvar()/globalsetvar(), getvar()/globalgetvar(), unsetvar()/globalunsetvar() shares common code parametrized by flags. I think this is resolvable. But worse, they can delegates their execution to other thread and should save all arguments in events queue. And this looks absolutely unsuitable for Argument Clinic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 23:01:11 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Jan 2014 22:01:11 +0000 Subject: [issue12837] Patch for issue #12810 removed a valid check on socket ancillary data In-Reply-To: <1314223005.88.0.145323709249.issue12837@psf.upfronthosting.co.za> Message-ID: <3dzSGH0mtYz7LjS@mail.python.org> Roundup Robot added the comment: New changeset 407c9c297ff7 by Brett Cannon in branch 'default': Issue #12837: Silence a Clang compiler warning on OS X. http://hg.python.org/cpython/rev/407c9c297ff7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 23:03:29 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Jan 2014 22:03:29 +0000 Subject: [issue19723] Argument Clinic should add markers for humans In-Reply-To: <1385150644.99.0.984146693257.issue19723@psf.upfronthosting.co.za> Message-ID: <3dzSJw3nM6z7Ljs@mail.python.org> Roundup Robot added the comment: New changeset aa153113d273 by Zachary Ware in branch 'default': Issue #19723: Fix issue number typo in Misc/NEWS http://hg.python.org/cpython/rev/aa153113d273 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 23:03:51 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 07 Jan 2014 22:03:51 +0000 Subject: [issue12837] Patch for issue #12810 removed a valid check on socket ancillary data In-Reply-To: <1314223005.88.0.145323709249.issue12837@psf.upfronthosting.co.za> Message-ID: <1389132231.81.0.120090037741.issue12837@psf.upfronthosting.co.za> Brett Cannon added the comment: Ended up going with my solution as I just couldn't guarantee 100% that David's approach would always be right (for no fault of David's; at this point I just want a solution and so I'm willing to use compiler tricks to get it as I grok those). Anyway, thanks to everyone for helping with this over the years. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 23:11:15 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 22:11:15 +0000 Subject: [issue20168] Derby: Convert the _tkinter module to use Argument Clinic In-Reply-To: <1389128639.57.0.613370502446.issue20168@psf.upfronthosting.co.za> Message-ID: <1389132675.01.0.41424391418.issue20168@psf.upfronthosting.co.za> Larry Hastings added the comment: (It would have made it easier on me if you'd used the C function names, instead of the names in the module.) I agree. In retrospect, it's not surprising that things in _tkinter aren't suitable, as it appears to be a shunt for calling things in Tcl. For what it's worth, Argument Clinic is only intended for functions that use PyArg_ParseTuple or PyArg_ParseTupleOrKeywords to parse their arguments. So something like call is and will forever be unsuitable. (And reading _tkinter.c this has reminded me why I don't like Tcl ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 23:18:45 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 07 Jan 2014 22:18:45 +0000 Subject: [issue20166] window x64 c-extensions not works on python3.4.0b2 In-Reply-To: <1389124118.85.0.0740185864803.issue20166@psf.upfronthosting.co.za> Message-ID: <1389133125.62.0.0369412344984.issue20166@psf.upfronthosting.co.za> Stefan Krah added the comment: Thanks for the report! -- That's due to the commit in #9709. PyMODINIT_FUNC is more than ten years old, so I hoped people would be using by now. On the other hand that's serious breakage. Martin, would you have time to make a call on whether to revert the change? ---------- nosy: +larry, loewis, skrah priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 23:25:57 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Jan 2014 22:25:57 +0000 Subject: [issue19723] Argument Clinic should add markers for humans In-Reply-To: <1385150644.99.0.984146693257.issue19723@psf.upfronthosting.co.za> Message-ID: <3dzSpr6w6fz7Ljd@mail.python.org> Roundup Robot added the comment: New changeset e634b377d5cc by Larry Hastings in branch 'default': Issue #19723: Missed one conversion to the new Argument Clinic syntax. http://hg.python.org/cpython/rev/e634b377d5cc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 23:53:10 2014 From: report at bugs.python.org (Roy Smith) Date: Tue, 07 Jan 2014 22:53:10 +0000 Subject: [issue20169] random module doc page has broken links Message-ID: <1389135190.46.0.595431802912.issue20169@psf.upfronthosting.co.za> New submission from Roy Smith: On http://docs.python.org/2/library/random.html, the links to random() go to the module, not the function. Thus: Almost all module functions depend on the basic function random(), If you lick on random(), you get to http://docs.python.org/2/library/random.html#module-random This looks like the same problem as issue19416. ---------- assignee: docs at python components: Documentation messages: 207612 nosy: docs at python, roysmith priority: normal severity: normal status: open title: random module doc page has broken links versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 7 23:56:03 2014 From: report at bugs.python.org (Roy Smith) Date: Tue, 07 Jan 2014 22:56:03 +0000 Subject: [issue20169] random module doc page has broken links In-Reply-To: <1389135190.46.0.595431802912.issue20169@psf.upfronthosting.co.za> Message-ID: <1389135363.96.0.082436127176.issue20169@psf.upfronthosting.co.za> Roy Smith added the comment: Ugh, that should say, "if you CLICK on random()". Really wish I was filing this from my phone so I could blame it on autocorrect. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 00:41:03 2014 From: report at bugs.python.org (Michael Foord) Date: Tue, 07 Jan 2014 23:41:03 +0000 Subject: [issue20165] unittest TestResult wasSuccessful returns True when there are unexpected successes In-Reply-To: <1389122721.74.0.155844601606.issue20165@psf.upfronthosting.co.za> Message-ID: <1389138063.98.0.522007952839.issue20165@psf.upfronthosting.co.za> Michael Foord added the comment: I'm pretty sure this has been debated before (and the status quo is the result). Trying to find the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 00:43:05 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 23:43:05 +0000 Subject: [issue20170] Derby #1: Convert 137 sites to Argument Clinic in Modules/posixmodule.c Message-ID: <1389138185.8.0.104398826507.issue20170@psf.upfronthosting.co.za> New submission from Larry Hastings: This issue is part of the Great Argument Clinic Conversion Derby, where we're trying to convert as much of Python 3.4 to use Argument Clinic as we can before Release Candidate 1 on January 19. This issue asks you to change the following bundle of files: Modules/posixmodule.c: 137 sites Talk to me (larry) if you only want to attack part of a bundle. For instructions on how to convert a function to work with Argument Clinic, read the "howto": http://docs.python.org/dev/howto/clinic.html ---------- assignee: larry components: Library (Lib) keywords: easy messages: 207615 nosy: larry priority: normal severity: normal stage: needs patch status: open title: Derby #1: Convert 137 sites to Argument Clinic in Modules/posixmodule.c type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 00:43:56 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 23:43:56 +0000 Subject: [issue20171] Derby #2: Convert 115 sites to Argument Clinic in Modules/_cursesmodule.c Message-ID: <1389138236.79.0.916600121015.issue20171@psf.upfronthosting.co.za> New submission from Larry Hastings: This issue is part of the Great Argument Clinic Conversion Derby, where we're trying to convert as much of Python 3.4 to use Argument Clinic as we can before Release Candidate 1 on January 19. This issue asks you to change the following bundle of files: Modules/_cursesmodule.c: 115 sites Talk to me (larry) if you only want to attack part of a bundle. For instructions on how to convert a function to work with Argument Clinic, read the "howto": http://docs.python.org/dev/howto/clinic.html ---------- components: Library (Lib) messages: 207616 nosy: larry priority: normal severity: normal stage: needs patch status: open title: Derby #2: Convert 115 sites to Argument Clinic in Modules/_cursesmodule.c type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 00:45:08 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 23:45:08 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) Message-ID: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> New submission from Larry Hastings: This issue is part of the Great Argument Clinic Conversion Derby, where we're trying to convert as much of Python 3.4 to use Argument Clinic as we can before Release Candidate 1 on January 19. This issue asks you to change the following bundle of files: PC/msvcrtmodule.c: 18 sites PC/winreg.c: 24 sites PC/winsound.c: 3 sites Modules/_winapi.c: 22 sites Talk to me (larry) if you only want to attack part of a bundle. For instructions on how to convert a function to work with Argument Clinic, read the "howto": http://docs.python.org/dev/howto/clinic.html ---------- components: Extension Modules messages: 207617 nosy: larry priority: normal severity: normal stage: needs patch status: open title: Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 00:45:47 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 23:45:47 +0000 Subject: [issue20170] Derby #1: Convert 137 sites to Argument Clinic in Modules/posixmodule.c In-Reply-To: <1389138185.8.0.104398826507.issue20170@psf.upfronthosting.co.za> Message-ID: <1389138347.63.0.0524626366498.issue20170@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- components: +Extension Modules -Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 00:45:52 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 23:45:52 +0000 Subject: [issue20171] Derby #2: Convert 115 sites to Argument Clinic in Modules/_cursesmodule.c In-Reply-To: <1389138236.79.0.916600121015.issue20171@psf.upfronthosting.co.za> Message-ID: <1389138352.0.0.918434095623.issue20171@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- components: +Extension Modules -Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 00:46:33 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 23:46:33 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files Message-ID: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> New submission from Larry Hastings: This issue is part of the Great Argument Clinic Conversion Derby, where we're trying to convert as much of Python 3.4 to use Argument Clinic as we can before Release Candidate 1 on January 19. This issue asks you to change the following bundle of files: Modules/_codecsmodule.c: 43 sites Modules/sha1module.c: 2 sites Modules/sha256module.c: 3 sites Modules/sha512module.c: 3 sites Modules/md5module.c: 2 sites Talk to me (larry) if you only want to attack part of a bundle. For instructions on how to convert a function to work with Argument Clinic, read the "howto": http://docs.python.org/dev/howto/clinic.html ---------- components: Extension Modules messages: 207618 nosy: larry priority: normal severity: normal stage: needs patch status: open title: Derby #4: Convert 53 sites to Argument Clinic across 5 files type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 00:47:41 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 23:47:41 +0000 Subject: [issue20174] Derby #5: Convert 50 sites to Argument Clinic across 3 files Message-ID: <1389138461.92.0.709656306175.issue20174@psf.upfronthosting.co.za> New submission from Larry Hastings: This issue is part of the Great Argument Clinic Conversion Derby, where we're trying to convert as much of Python 3.4 to use Argument Clinic as we can before Release Candidate 1 on January 19. This issue asks you to change the following bundle of files: Modules/socketmodule.c: 47 sites Modules/socketmodule.h: 1 sites Modules/_functoolsmodule.c: 2 sites Talk to me (larry) if you only want to attack part of a bundle. For instructions on how to convert a function to work with Argument Clinic, read the "howto": http://docs.python.org/dev/howto/clinic.html ---------- components: Extension Modules messages: 207619 nosy: larry priority: normal severity: normal stage: needs patch status: open title: Derby #5: Convert 50 sites to Argument Clinic across 3 files type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 00:48:19 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 23:48:19 +0000 Subject: [issue20175] Derby #6: Convert 50 sites to Argument Clinic across 8 files Message-ID: <1389138499.96.0.517173661563.issue20175@psf.upfronthosting.co.za> New submission from Larry Hastings: This issue is part of the Great Argument Clinic Conversion Derby, where we're trying to convert as much of Python 3.4 to use Argument Clinic as we can before Release Candidate 1 on January 19. This issue asks you to change the following bundle of files: Modules/_io/bufferedio.c: 13 sites Modules/_io/bytesio.c: 6 sites Modules/_io/fileio.c: 6 sites Modules/_io/iobase.c: 4 sites Modules/_io/stringio.c: 5 sites Modules/_io/textio.c: 8 sites Modules/_multiprocessing/multiprocessing.c: 3 sites Modules/_multiprocessing/semaphore.c: 5 sites Talk to me (larry) if you only want to attack part of a bundle. For instructions on how to convert a function to work with Argument Clinic, read the "howto": http://docs.python.org/dev/howto/clinic.html ---------- components: Extension Modules messages: 207620 nosy: larry priority: normal severity: normal stage: needs patch status: open title: Derby #6: Convert 50 sites to Argument Clinic across 8 files type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 00:48:54 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 23:48:54 +0000 Subject: [issue20176] Derby #7: Convert 51 sites to Argument Clinic across 3 files Message-ID: <1389138534.56.0.00725638903782.issue20176@psf.upfronthosting.co.za> New submission from Larry Hastings: This issue is part of the Great Argument Clinic Conversion Derby, where we're trying to convert as much of Python 3.4 to use Argument Clinic as we can before Release Candidate 1 on January 19. This issue asks you to change the following bundle of files: Modules/_elementtree.c: 31 sites PC/_msi.c: 15 sites PC/bdist_wininst/install.c: 5 sites Talk to me (larry) if you only want to attack part of a bundle. For instructions on how to convert a function to work with Argument Clinic, read the "howto": http://docs.python.org/dev/howto/clinic.html ---------- components: Extension Modules messages: 207621 nosy: larry priority: normal severity: normal stage: needs patch status: open title: Derby #7: Convert 51 sites to Argument Clinic across 3 files type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 00:49:34 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 23:49:34 +0000 Subject: [issue20177] Derby #8: Convert 52 sites to Argument Clinic across 3 files Message-ID: <1389138574.32.0.892814928986.issue20177@psf.upfronthosting.co.za> New submission from Larry Hastings: This issue is part of the Great Argument Clinic Conversion Derby, where we're trying to convert as much of Python 3.4 to use Argument Clinic as we can before Release Candidate 1 on January 19. This issue asks you to change the following bundle of files: Modules/_datetimemodule.c: 20 sites Modules/timemodule.c: 8 sites Modules/_decimal/_decimal.c: 24 sites Talk to me (larry) if you only want to attack part of a bundle. For instructions on how to convert a function to work with Argument Clinic, read the "howto": http://docs.python.org/dev/howto/clinic.html ---------- components: Extension Modules messages: 207622 nosy: larry priority: normal severity: normal stage: needs patch status: open title: Derby #8: Convert 52 sites to Argument Clinic across 3 files type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 00:50:50 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 23:50:50 +0000 Subject: [issue20176] Derby #7: Convert 51 sites to Argument Clinic across 3 files In-Reply-To: <1389138534.56.0.00725638903782.issue20176@psf.upfronthosting.co.za> Message-ID: <1389138650.18.0.770787100029.issue20176@psf.upfronthosting.co.za> Larry Hastings added the comment: Sorry, meant to convert a different issue into this issue. ---------- resolution: -> duplicate stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 00:52:09 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 23:52:09 +0000 Subject: [issue20159] Derby #7: Convert 51 sites to Argument Clinic across 3 files In-Reply-To: <1389086966.47.0.33615845784.issue20159@psf.upfronthosting.co.za> Message-ID: <1389138729.48.0.968990556177.issue20159@psf.upfronthosting.co.za> Larry Hastings added the comment: (Converting this issue into Derby entry #7. Serhiy has stated that he is abandoning his ElementTree patch; it may make a good starting point for you if you take over this issue.) This issue is part of the Great Argument Clinic Conversion Derby, where we're trying to convert as much of Python 3.4 to use Argument Clinic as we can before Release Candidate 1 on January 19. This issue asks you to change the following bundle of files: Modules/_elementtree.c: 31 sites PC/_msi.c: 15 sites PC/bdist_wininst/install.c: 5 sites Talk to me (larry) if you only want to attack part of a bundle. For instructions on how to convert a function to work with Argument Clinic, read the "howto": http://docs.python.org/dev/howto/clinic.html ---------- stage: patch review -> needs patch title: Derby: Convert the ElementTree module to use Argument Clinic -> Derby #7: Convert 51 sites to Argument Clinic across 3 files _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 00:52:27 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 23:52:27 +0000 Subject: [issue20170] Derby #1: Convert 137 sites to Argument Clinic in Modules/posixmodule.c In-Reply-To: <1389138185.8.0.104398826507.issue20170@psf.upfronthosting.co.za> Message-ID: <1389138747.5.0.141254117332.issue20170@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 00:52:31 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 23:52:31 +0000 Subject: [issue20171] Derby #2: Convert 115 sites to Argument Clinic in Modules/_cursesmodule.c In-Reply-To: <1389138236.79.0.916600121015.issue20171@psf.upfronthosting.co.za> Message-ID: <1389138751.89.0.671561780247.issue20171@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 00:52:36 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 23:52:36 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1389138756.66.0.428790581401.issue20173@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 00:52:42 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 23:52:42 +0000 Subject: [issue20174] Derby #5: Convert 50 sites to Argument Clinic across 3 files In-Reply-To: <1389138461.92.0.709656306175.issue20174@psf.upfronthosting.co.za> Message-ID: <1389138762.28.0.949960681484.issue20174@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 00:52:46 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 23:52:46 +0000 Subject: [issue20175] Derby #6: Convert 50 sites to Argument Clinic across 8 files In-Reply-To: <1389138499.96.0.517173661563.issue20175@psf.upfronthosting.co.za> Message-ID: <1389138766.69.0.121420217835.issue20175@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 00:52:51 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 23:52:51 +0000 Subject: [issue20177] Derby #8: Convert 52 sites to Argument Clinic across 3 files In-Reply-To: <1389138574.32.0.892814928986.issue20177@psf.upfronthosting.co.za> Message-ID: <1389138771.32.0.689129881676.issue20177@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 00:53:29 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jan 2014 23:53:29 +0000 Subject: [issue20175] Derby #6: Convert 50 sites to Argument Clinic across 8 files In-Reply-To: <1389138499.96.0.517173661563.issue20175@psf.upfronthosting.co.za> Message-ID: <1389138809.11.0.69867330455.issue20175@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 00:55:50 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 07 Jan 2014 23:55:50 +0000 Subject: [issue20152] Derby: Convert the _imp module to use Argument Clinic In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1389138950.14.0.11203887334.issue20152@psf.upfronthosting.co.za> Brett Cannon added the comment: I have attached my conversion of import.c. Larry, can you look it over to make sure I did it as expected? I tried to not have to write my own converter for O& as the docs seem to suggest object(converter='...') should work, but I got an error instead. ---------- assignee: brett.cannon -> larry keywords: +patch status: open -> pending Added file: http://bugs.python.org/file33351/import_ac.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 00:56:51 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jan 2014 23:56:51 +0000 Subject: [issue20133] Derby: Convert the audioop module to use Argument Clinic In-Reply-To: <1388956864.17.0.114751586443.issue20133@psf.upfronthosting.co.za> Message-ID: <1389139011.33.0.529043074347.issue20133@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is refreshed patch. ---------- Added file: http://bugs.python.org/file33352/audioop_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 00:57:19 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jan 2014 23:57:19 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1389139039.09.0.881546972477.issue20148@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is refreshed patch. ---------- Added file: http://bugs.python.org/file33353/sre_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 00:58:03 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jan 2014 23:58:03 +0000 Subject: [issue20151] Derby: Convert the binascii module to use Argument Clinic In-Reply-To: <1389037748.15.0.70999359123.issue20151@psf.upfronthosting.co.za> Message-ID: <1389139083.43.0.90917705808.issue20151@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is refreshed patch. ---------- Added file: http://bugs.python.org/file33354/binascii_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 00:58:29 2014 From: report at bugs.python.org (Michael Foord) Date: Tue, 07 Jan 2014 23:58:29 +0000 Subject: [issue20165] unittest TestResult wasSuccessful returns True when there are unexpected successes In-Reply-To: <1389122721.74.0.155844601606.issue20165@psf.upfronthosting.co.za> Message-ID: <1389139109.91.0.765973963017.issue20165@psf.upfronthosting.co.za> Michael Foord added the comment: Hmmm... TestTools has wasSuccessful return False on an unexpected success [1] and I can't find an issue for any previous discussion. I don't use unexpected success, so I have no particular horse in this race but it seems more logical that wasSuccessful should return False when there are unexpected successes. [1] https://code.launchpad.net/~jml/testtools/unexpected-success-2/+merge/42050 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 01:00:46 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jan 2014 00:00:46 +0000 Subject: [issue20159] Derby: Convert the ElementTree module to use Argument Clinic In-Reply-To: <1389128164.02.0.374014196806.issue20159@psf.upfronthosting.co.za> Message-ID: <1694566.4sTcveBoDY@raxxla> Serhiy Storchaka added the comment: Here is refreshed patch. ---------- title: Derby #7: Convert 51 sites to Argument Clinic across 3 files -> Derby: Convert the ElementTree module to use Argument Clinic Added file: http://bugs.python.org/file33355/etree_clinic.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r e634b377d5cc Modules/_elementtree.c --- a/Modules/_elementtree.c Tue Jan 07 14:25:26 2014 -0800 +++ b/Modules/_elementtree.c Wed Jan 08 01:42:50 2014 +0200 @@ -368,6 +368,12 @@ return attrib; } +/*[clinic input] +module _elementtree +class _elementtree.Element +[clinic start generated code]*/ +/*[clinic end generated code: checksum=da39a3ee5e6b4b0d3255bfef95601890afd80709]*/ + static int element_init(PyObject *self, PyObject *args, PyObject *kwds) { @@ -654,25 +660,80 @@ /* -------------------------------------------------------------------- */ -static PyObject* -element_append(ElementObject* self, PyObject* args) +/*[clinic input] +_elementtree.Element.append + + self: self(type='ElementObject *') + subelement: object(subclass_of='&Element_Type') + / + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_Element_append__doc__, +"append(subelement)"); + +#define _ELEMENTTREE_ELEMENT_APPEND_METHODDEF \ + {"append", (PyCFunction)_elementtree_Element_append, METH_VARARGS, _elementtree_Element_append__doc__}, + +static PyObject * +_elementtree_Element_append_impl(ElementObject *self, PyObject *subelement); + +static PyObject * +_elementtree_Element_append(PyObject *self, PyObject *args) { - PyObject* element; - if (!PyArg_ParseTuple(args, "O!:append", &Element_Type, &element)) - return NULL; - - if (element_add_subelement(self, element) < 0) + PyObject *return_value = NULL; + PyObject *subelement; + + if (!PyArg_ParseTuple(args, + "O!:append", + &Element_Type, &subelement)) + goto exit; + return_value = _elementtree_Element_append_impl((ElementObject *)self, subelement); + +exit: + return return_value; +} + +static PyObject * +_elementtree_Element_append_impl(ElementObject *self, PyObject *subelement) +/*[clinic end generated code: checksum=2657014068bf9a52d383c72699454858243643a6]*/ +{ + if (element_add_subelement(self, subelement) < 0) return NULL; Py_RETURN_NONE; } -static PyObject* -element_clearmethod(ElementObject* self, PyObject* args) +/*[clinic input] +_elementtree.Element.clear + + self: self(type='ElementObject *') + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_Element_clear__doc__, +"clear()"); + +#define _ELEMENTTREE_ELEMENT_CLEAR_METHODDEF \ + {"clear", (PyCFunction)_elementtree_Element_clear, METH_NOARGS, _elementtree_Element_clear__doc__}, + +static PyObject * +_elementtree_Element_clear_impl(ElementObject *self); + +static PyObject * +_elementtree_Element_clear(PyObject *self, PyObject *Py_UNUSED(ignored)) { - if (!PyArg_ParseTuple(args, ":clear")) - return NULL; - + PyObject *return_value = NULL; + + return_value = _elementtree_Element_clear_impl((ElementObject *)self); + + return return_value; +} + +static PyObject * +_elementtree_Element_clear_impl(ElementObject *self) +/*[clinic end generated code: checksum=b112605d2110394281eaabbf17b7458fc1037828]*/ +{ dealloc_extra(self); Py_INCREF(Py_None); @@ -686,15 +747,39 @@ Py_RETURN_NONE; } -static PyObject* -element_copy(ElementObject* self, PyObject* args) +/*[clinic input] +_elementtree.Element.__copy__ + + self: self(type='ElementObject *') + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_Element___copy____doc__, +"__copy__()"); + +#define _ELEMENTTREE_ELEMENT___COPY___METHODDEF \ + {"__copy__", (PyCFunction)_elementtree_Element___copy__, METH_NOARGS, _elementtree_Element___copy____doc__}, + +static PyObject * +_elementtree_Element___copy___impl(ElementObject *self); + +static PyObject * +_elementtree_Element___copy__(PyObject *self, PyObject *Py_UNUSED(ignored)) +{ + PyObject *return_value = NULL; + + return_value = _elementtree_Element___copy___impl((ElementObject *)self); + + return return_value; +} + +static PyObject * +_elementtree_Element___copy___impl(ElementObject *self) +/*[clinic end generated code: checksum=7a0523cd605533c0e69293b9a4fcbecc6e072ba2]*/ { int i; ElementObject* element; - if (!PyArg_ParseTuple(args, ":__copy__")) - return NULL; - element = (ElementObject*) create_new_element( self->tag, (self->extra) ? self->extra->attrib : Py_None); if (!element) @@ -725,8 +810,24 @@ return (PyObject*) element; } -static PyObject* -element_deepcopy(ElementObject* self, PyObject* args) +/*[clinic input] +_elementtree.Element.__deepcopy__ + + self: self(type='ElementObject *') + memo: object + / + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_Element___deepcopy____doc__, +"__deepcopy__(memo)"); + +#define _ELEMENTTREE_ELEMENT___DEEPCOPY___METHODDEF \ + {"__deepcopy__", (PyCFunction)_elementtree_Element___deepcopy__, METH_O, _elementtree_Element___deepcopy____doc__}, + +static PyObject * +_elementtree_Element___deepcopy__(ElementObject *self, PyObject *memo) +/*[clinic end generated code: checksum=f337046f0f00f6dc0dfc3dbf45553e310672f56b]*/ { int i; ElementObject* element; @@ -736,10 +837,6 @@ PyObject* tail; PyObject* id; - PyObject* memo; - if (!PyArg_ParseTuple(args, "O:__deepcopy__", &memo)) - return NULL; - tag = deepcopy(self->tag, memo); if (!tag) return NULL; @@ -810,17 +907,48 @@ return NULL; } -static PyObject* -element_sizeof(PyObject* myself, PyObject* args) +/*[clinic input] +_elementtree.Element.__sizeof__ -> Py_ssize_t + + self: self(type='ElementObject *') + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_Element___sizeof____doc__, +"__sizeof__()"); + +#define _ELEMENTTREE_ELEMENT___SIZEOF___METHODDEF \ + {"__sizeof__", (PyCFunction)_elementtree_Element___sizeof__, METH_NOARGS, _elementtree_Element___sizeof____doc__}, + +static Py_ssize_t +_elementtree_Element___sizeof___impl(ElementObject *self); + +static PyObject * +_elementtree_Element___sizeof__(PyObject *self, PyObject *Py_UNUSED(ignored)) { - ElementObject *self = (ElementObject*)myself; + PyObject *return_value = NULL; + Py_ssize_t _return_value; + + _return_value = _elementtree_Element___sizeof___impl((ElementObject *)self); + if ((_return_value == -1) && PyErr_Occurred()) + goto exit; + return_value = PyLong_FromSsize_t(_return_value); + +exit: + return return_value; +} + +static Py_ssize_t +_elementtree_Element___sizeof___impl(ElementObject *self) +/*[clinic end generated code: checksum=5e3e8a02ed3a3c73c99467e90f8b840277286cb7]*/ +{ Py_ssize_t result = sizeof(ElementObject); if (self->extra) { result += sizeof(ElementObjectExtra); if (self->extra->children != self->extra->_children) result += sizeof(PyObject*) * self->extra->allocated; } - return PyLong_FromSsize_t(result); + return result; } /* dict keys for getstate/setstate. */ @@ -836,8 +964,35 @@ * any unnecessary structures there; and (b) it buys compatibility with 3.2 * pickles. See issue #16076. */ +/*[clinic input] +_elementtree.Element.__getstate__ + + self: self(type='ElementObject *') + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_Element___getstate____doc__, +"__getstate__()"); + +#define _ELEMENTTREE_ELEMENT___GETSTATE___METHODDEF \ + {"__getstate__", (PyCFunction)_elementtree_Element___getstate__, METH_NOARGS, _elementtree_Element___getstate____doc__}, + static PyObject * -element_getstate(ElementObject *self) +_elementtree_Element___getstate___impl(ElementObject *self); + +static PyObject * +_elementtree_Element___getstate__(PyObject *self, PyObject *Py_UNUSED(ignored)) +{ + PyObject *return_value = NULL; + + return_value = _elementtree_Element___getstate___impl((ElementObject *)self); + + return return_value; +} + +static PyObject * +_elementtree_Element___getstate___impl(ElementObject *self) +/*[clinic end generated code: checksum=54ff075281a1ea36af223e690490204bc27748fb]*/ { int i, noattrib; PyObject *instancedict = NULL, *children; @@ -952,6 +1107,7 @@ /* __setstate__ for Element instance from the Python implementation. * 'state' should be the instance dict. */ + static PyObject * element_setstate_from_Python(ElementObject *self, PyObject *state) { @@ -977,8 +1133,24 @@ return retval; } +/*[clinic input] +_elementtree.Element.__setstate__ + + self: self(type='ElementObject *') + state: object + / + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_Element___setstate____doc__, +"__setstate__(state)"); + +#define _ELEMENTTREE_ELEMENT___SETSTATE___METHODDEF \ + {"__setstate__", (PyCFunction)_elementtree_Element___setstate__, METH_O, _elementtree_Element___setstate____doc__}, + static PyObject * -element_setstate(ElementObject *self, PyObject *state) +_elementtree_Element___setstate__(ElementObject *self, PyObject *state) +/*[clinic end generated code: checksum=bd75aec0601d95cfd4ada7d5aa4b6597f7209422]*/ { if (!PyDict_CheckExact(state)) { PyErr_Format(PyExc_TypeError, @@ -1032,21 +1204,33 @@ return 1; /* unknown type; might be path expression */ } -static PyObject* -element_extend(ElementObject* self, PyObject* args) +/*[clinic input] +_elementtree.Element.extend + + self: self(type='ElementObject *') + elements: object + / + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_Element_extend__doc__, +"extend(elements)"); + +#define _ELEMENTTREE_ELEMENT_EXTEND_METHODDEF \ + {"extend", (PyCFunction)_elementtree_Element_extend, METH_O, _elementtree_Element_extend__doc__}, + +static PyObject * +_elementtree_Element_extend(ElementObject *self, PyObject *elements) +/*[clinic end generated code: checksum=a5102ac72eb6ab1d742a8c6c06f5ee4c5e219580]*/ { PyObject* seq; Py_ssize_t i, seqlen = 0; - PyObject* seq_in; - if (!PyArg_ParseTuple(args, "O:extend", &seq_in)) - return NULL; - - seq = PySequence_Fast(seq_in, ""); + seq = PySequence_Fast(elements, ""); if (!seq) { PyErr_Format( PyExc_TypeError, - "expected sequence, not \"%.200s\"", Py_TYPE(seq_in)->tp_name + "expected sequence, not \"%.200s\"", Py_TYPE(elements)->tp_name ); return NULL; } @@ -1074,23 +1258,53 @@ Py_RETURN_NONE; } -static PyObject* -element_find(ElementObject *self, PyObject *args, PyObject *kwds) +/*[clinic input] +_elementtree.Element.find + + self: self(type='ElementObject *') + path: object + namespaces: object = None + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_Element_find__doc__, +"find(path, namespaces=None)"); + +#define _ELEMENTTREE_ELEMENT_FIND_METHODDEF \ + {"find", (PyCFunction)_elementtree_Element_find, METH_VARARGS|METH_KEYWORDS, _elementtree_Element_find__doc__}, + +static PyObject * +_elementtree_Element_find_impl(ElementObject *self, PyObject *path, PyObject *namespaces); + +static PyObject * +_elementtree_Element_find(PyObject *self, PyObject *args, PyObject *kwargs) +{ + PyObject *return_value = NULL; + static char *_keywords[] = {"path", "namespaces", NULL}; + PyObject *path; + PyObject *namespaces = Py_None; + + if (!PyArg_ParseTupleAndKeywords(args, kwargs, + "O|O:find", _keywords, + &path, &namespaces)) + goto exit; + return_value = _elementtree_Element_find_impl((ElementObject *)self, path, namespaces); + +exit: + return return_value; +} + +static PyObject * +_elementtree_Element_find_impl(ElementObject *self, PyObject *path, PyObject *namespaces) +/*[clinic end generated code: checksum=636eddffd045f4ff6d3538514285824437eabde6]*/ { int i; - PyObject* tag; - PyObject* namespaces = Py_None; - static char *kwlist[] = {"path", "namespaces", 0}; elementtreestate *st = ET_STATE_GLOBAL; - if (!PyArg_ParseTupleAndKeywords(args, kwds, "O|O:find", kwlist, - &tag, &namespaces)) - return NULL; - - if (checkpath(tag) || namespaces != Py_None) { + if (checkpath(path) || namespaces != Py_None) { _Py_IDENTIFIER(find); return _PyObject_CallMethodId( - st->elementpath_obj, &PyId_find, "OOO", self, tag, namespaces + st->elementpath_obj, &PyId_find, "OOO", self, path, namespaces ); } @@ -1100,7 +1314,7 @@ for (i = 0; i < self->extra->length; i++) { PyObject* item = self->extra->children[i]; if (Element_CheckExact(item) && - PyObject_RichCompareBool(((ElementObject*)item)->tag, tag, Py_EQ) == 1) { + PyObject_RichCompareBool(((ElementObject*)item)->tag, path, Py_EQ) == 1) { Py_INCREF(item); return item; } @@ -1109,24 +1323,55 @@ Py_RETURN_NONE; } -static PyObject* -element_findtext(ElementObject *self, PyObject *args, PyObject *kwds) +/*[clinic input] +_elementtree.Element.findtext + + self: self(type='ElementObject *') + path: object + default: object = None + namespaces: object = None + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_Element_findtext__doc__, +"findtext(path, default=None, namespaces=None)"); + +#define _ELEMENTTREE_ELEMENT_FINDTEXT_METHODDEF \ + {"findtext", (PyCFunction)_elementtree_Element_findtext, METH_VARARGS|METH_KEYWORDS, _elementtree_Element_findtext__doc__}, + +static PyObject * +_elementtree_Element_findtext_impl(ElementObject *self, PyObject *path, PyObject *default_value, PyObject *namespaces); + +static PyObject * +_elementtree_Element_findtext(PyObject *self, PyObject *args, PyObject *kwargs) +{ + PyObject *return_value = NULL; + static char *_keywords[] = {"path", "default", "namespaces", NULL}; + PyObject *path; + PyObject *default_value = Py_None; + PyObject *namespaces = Py_None; + + if (!PyArg_ParseTupleAndKeywords(args, kwargs, + "O|OO:findtext", _keywords, + &path, &default_value, &namespaces)) + goto exit; + return_value = _elementtree_Element_findtext_impl((ElementObject *)self, path, default_value, namespaces); + +exit: + return return_value; +} + +static PyObject * +_elementtree_Element_findtext_impl(ElementObject *self, PyObject *path, PyObject *default_value, PyObject *namespaces) +/*[clinic end generated code: checksum=1bdd762f714aef8cee0f62faa4afc4eb8f21b58c]*/ { int i; - PyObject* tag; - PyObject* default_value = Py_None; - PyObject* namespaces = Py_None; _Py_IDENTIFIER(findtext); - static char *kwlist[] = {"path", "default", "namespaces", 0}; elementtreestate *st = ET_STATE_GLOBAL; - if (!PyArg_ParseTupleAndKeywords(args, kwds, "O|OO:findtext", kwlist, - &tag, &default_value, &namespaces)) - return NULL; - - if (checkpath(tag) || namespaces != Py_None) + if (checkpath(path) || namespaces != Py_None) return _PyObject_CallMethodId( - st->elementpath_obj, &PyId_findtext, "OOOO", self, tag, default_value, namespaces + st->elementpath_obj, &PyId_findtext, "OOOO", self, path, default_value, namespaces ); if (!self->extra) { @@ -1137,7 +1382,7 @@ for (i = 0; i < self->extra->length; i++) { ElementObject* item = (ElementObject*) self->extra->children[i]; if (Element_CheckExact(item) && - (PyObject_RichCompareBool(item->tag, tag, Py_EQ) == 1)) { + (PyObject_RichCompareBool(item->tag, path, Py_EQ) == 1)) { PyObject* text = element_get_text(item); if (text == Py_None) return PyUnicode_New(0, 0); @@ -1150,20 +1395,51 @@ return default_value; } -static PyObject* -element_findall(ElementObject *self, PyObject *args, PyObject *kwds) +/*[clinic input] +_elementtree.Element.findall + + self: self(type='ElementObject *') + path: object + namespaces: object = None + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_Element_findall__doc__, +"findall(path, namespaces=None)"); + +#define _ELEMENTTREE_ELEMENT_FINDALL_METHODDEF \ + {"findall", (PyCFunction)_elementtree_Element_findall, METH_VARARGS|METH_KEYWORDS, _elementtree_Element_findall__doc__}, + +static PyObject * +_elementtree_Element_findall_impl(ElementObject *self, PyObject *path, PyObject *namespaces); + +static PyObject * +_elementtree_Element_findall(PyObject *self, PyObject *args, PyObject *kwargs) +{ + PyObject *return_value = NULL; + static char *_keywords[] = {"path", "namespaces", NULL}; + PyObject *path; + PyObject *namespaces = Py_None; + + if (!PyArg_ParseTupleAndKeywords(args, kwargs, + "O|O:findall", _keywords, + &path, &namespaces)) + goto exit; + return_value = _elementtree_Element_findall_impl((ElementObject *)self, path, namespaces); + +exit: + return return_value; +} + +static PyObject * +_elementtree_Element_findall_impl(ElementObject *self, PyObject *path, PyObject *namespaces) +/*[clinic end generated code: checksum=e126482bd3635e7ccfb83ba5bfb12c282b509e44]*/ { int i; PyObject* out; - PyObject* tag; - PyObject* namespaces = Py_None; - static char *kwlist[] = {"path", "namespaces", 0}; + PyObject* tag = path; elementtreestate *st = ET_STATE_GLOBAL; - if (!PyArg_ParseTupleAndKeywords(args, kwds, "O|O:findall", kwlist, - &tag, &namespaces)) - return NULL; - if (checkpath(tag) || namespaces != Py_None) { _Py_IDENTIFIER(findall); return _PyObject_CallMethodId( @@ -1192,36 +1468,95 @@ return out; } -static PyObject* -element_iterfind(ElementObject *self, PyObject *args, PyObject *kwds) +/*[clinic input] +_elementtree.Element.iterfind + + self: self(type='ElementObject *') + path: object + namespaces: object = None + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_Element_iterfind__doc__, +"iterfind(path, namespaces=None)"); + +#define _ELEMENTTREE_ELEMENT_ITERFIND_METHODDEF \ + {"iterfind", (PyCFunction)_elementtree_Element_iterfind, METH_VARARGS|METH_KEYWORDS, _elementtree_Element_iterfind__doc__}, + +static PyObject * +_elementtree_Element_iterfind_impl(ElementObject *self, PyObject *path, PyObject *namespaces); + +static PyObject * +_elementtree_Element_iterfind(PyObject *self, PyObject *args, PyObject *kwargs) { - PyObject* tag; - PyObject* namespaces = Py_None; + PyObject *return_value = NULL; + static char *_keywords[] = {"path", "namespaces", NULL}; + PyObject *path; + PyObject *namespaces = Py_None; + + if (!PyArg_ParseTupleAndKeywords(args, kwargs, + "O|O:iterfind", _keywords, + &path, &namespaces)) + goto exit; + return_value = _elementtree_Element_iterfind_impl((ElementObject *)self, path, namespaces); + +exit: + return return_value; +} + +static PyObject * +_elementtree_Element_iterfind_impl(ElementObject *self, PyObject *path, PyObject *namespaces) +/*[clinic end generated code: checksum=15f071c02d939b097f57c37132904e5bd19efa4c]*/ +{ + PyObject* tag = path; _Py_IDENTIFIER(iterfind); - static char *kwlist[] = {"path", "namespaces", 0}; elementtreestate *st = ET_STATE_GLOBAL; - if (!PyArg_ParseTupleAndKeywords(args, kwds, "O|O:iterfind", kwlist, - &tag, &namespaces)) { - return NULL; - } - return _PyObject_CallMethodId( st->elementpath_obj, &PyId_iterfind, "OOO", self, tag, namespaces); } -static PyObject* -element_get(ElementObject* self, PyObject* args, PyObject* kwds) +/*[clinic input] +_elementtree.Element.get + + self: self(type='ElementObject *') + key: object + default: object = None + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_Element_get__doc__, +"get(key, default=None)"); + +#define _ELEMENTTREE_ELEMENT_GET_METHODDEF \ + {"get", (PyCFunction)_elementtree_Element_get, METH_VARARGS|METH_KEYWORDS, _elementtree_Element_get__doc__}, + +static PyObject * +_elementtree_Element_get_impl(ElementObject *self, PyObject *key, PyObject *default_value); + +static PyObject * +_elementtree_Element_get(PyObject *self, PyObject *args, PyObject *kwargs) +{ + PyObject *return_value = NULL; + static char *_keywords[] = {"key", "default", NULL}; + PyObject *key; + PyObject *default_value = Py_None; + + if (!PyArg_ParseTupleAndKeywords(args, kwargs, + "O|O:get", _keywords, + &key, &default_value)) + goto exit; + return_value = _elementtree_Element_get_impl((ElementObject *)self, key, default_value); + +exit: + return return_value; +} + +static PyObject * +_elementtree_Element_get_impl(ElementObject *self, PyObject *key, PyObject *default_value) +/*[clinic end generated code: checksum=91ae50e2b73068eefe8fbfa7c3fd15df298b0e98]*/ { PyObject* value; - static char* kwlist[] = {"key", "default", 0}; - - PyObject* key; - PyObject* default_value = Py_None; - - if (!PyArg_ParseTupleAndKeywords(args, kwds, "O|O:get", kwlist, &key, - &default_value)) - return NULL; if (!self->extra || self->extra->attrib == Py_None) value = default_value; @@ -1235,17 +1570,41 @@ return value; } -static PyObject* -element_getchildren(ElementObject* self, PyObject* args) +/*[clinic input] +_elementtree.Element.getchildren + + self: self(type='ElementObject *') + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_Element_getchildren__doc__, +"getchildren()"); + +#define _ELEMENTTREE_ELEMENT_GETCHILDREN_METHODDEF \ + {"getchildren", (PyCFunction)_elementtree_Element_getchildren, METH_NOARGS, _elementtree_Element_getchildren__doc__}, + +static PyObject * +_elementtree_Element_getchildren_impl(ElementObject *self); + +static PyObject * +_elementtree_Element_getchildren(PyObject *self, PyObject *Py_UNUSED(ignored)) +{ + PyObject *return_value = NULL; + + return_value = _elementtree_Element_getchildren_impl((ElementObject *)self); + + return return_value; +} + +static PyObject * +_elementtree_Element_getchildren_impl(ElementObject *self) +/*[clinic end generated code: checksum=afae4354dc5231ba76ce51be3fcf6146fa327d58]*/ { int i; PyObject* list; /* FIXME: report as deprecated? */ - if (!PyArg_ParseTuple(args, ":getchildren")) - return NULL; - if (!self->extra) return PyList_New(0); @@ -1267,25 +1626,78 @@ create_elementiter(ElementObject *self, PyObject *tag, int gettext); +/*[clinic input] +_elementtree.Element.iter + + self: self(type='ElementObject *') + tag: object = None + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_Element_iter__doc__, +"iter(tag=None)"); + +#define _ELEMENTTREE_ELEMENT_ITER_METHODDEF \ + {"iter", (PyCFunction)_elementtree_Element_iter, METH_VARARGS|METH_KEYWORDS, _elementtree_Element_iter__doc__}, + static PyObject * -element_iter(ElementObject *self, PyObject *args, PyObject *kwds) +_elementtree_Element_iter_impl(ElementObject *self, PyObject *tag); + +static PyObject * +_elementtree_Element_iter(PyObject *self, PyObject *args, PyObject *kwargs) { - PyObject* tag = Py_None; - static char* kwlist[] = {"tag", 0}; - - if (!PyArg_ParseTupleAndKeywords(args, kwds, "|O:iter", kwlist, &tag)) - return NULL; - + PyObject *return_value = NULL; + static char *_keywords[] = {"tag", NULL}; + PyObject *tag = Py_None; + + if (!PyArg_ParseTupleAndKeywords(args, kwargs, + "|O:iter", _keywords, + &tag)) + goto exit; + return_value = _elementtree_Element_iter_impl((ElementObject *)self, tag); + +exit: + return return_value; +} + +static PyObject * +_elementtree_Element_iter_impl(ElementObject *self, PyObject *tag) +/*[clinic end generated code: checksum=996b1537be06ed54b57c9ee79cf05219dced62e3]*/ +{ return create_elementiter(self, tag, 0); } -static PyObject* -element_itertext(ElementObject* self, PyObject* args) +/*[clinic input] +_elementtree.Element.itertext + + self: self(type='ElementObject *') + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_Element_itertext__doc__, +"itertext()"); + +#define _ELEMENTTREE_ELEMENT_ITERTEXT_METHODDEF \ + {"itertext", (PyCFunction)_elementtree_Element_itertext, METH_NOARGS, _elementtree_Element_itertext__doc__}, + +static PyObject * +_elementtree_Element_itertext_impl(ElementObject *self); + +static PyObject * +_elementtree_Element_itertext(PyObject *self, PyObject *Py_UNUSED(ignored)) { - if (!PyArg_ParseTuple(args, ":itertext")) - return NULL; - + PyObject *return_value = NULL; + + return_value = _elementtree_Element_itertext_impl((ElementObject *)self); + + return return_value; +} + +static PyObject * +_elementtree_Element_itertext_impl(ElementObject *self) +/*[clinic end generated code: checksum=46ee60dbf63f1c07205dc267333aef4d47cec1c9]*/ +{ return create_elementiter(self, Py_None, 1); } @@ -1307,17 +1719,48 @@ return self->extra->children[index]; } -static PyObject* -element_insert(ElementObject* self, PyObject* args) +/*[clinic input] +_elementtree.Element.insert + + self: self(type='ElementObject *') + index: int + subelement: object(subclass_of='&Element_Type') + / + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_Element_insert__doc__, +"insert(index, subelement)"); + +#define _ELEMENTTREE_ELEMENT_INSERT_METHODDEF \ + {"insert", (PyCFunction)_elementtree_Element_insert, METH_VARARGS, _elementtree_Element_insert__doc__}, + +static PyObject * +_elementtree_Element_insert_impl(ElementObject *self, int index, PyObject *subelement); + +static PyObject * +_elementtree_Element_insert(PyObject *self, PyObject *args) +{ + PyObject *return_value = NULL; + int index; + PyObject *subelement; + + if (!PyArg_ParseTuple(args, + "iO!:insert", + &index, &Element_Type, &subelement)) + goto exit; + return_value = _elementtree_Element_insert_impl((ElementObject *)self, index, subelement); + +exit: + return return_value; +} + +static PyObject * +_elementtree_Element_insert_impl(ElementObject *self, int index, PyObject *subelement) +/*[clinic end generated code: checksum=7ad6a209044ad042f2487c42f7c7c5627d9c7a37]*/ { int i; - int index; - PyObject* element; - if (!PyArg_ParseTuple(args, "iO!:insert", &index, - &Element_Type, &element)) - return NULL; - if (!self->extra) { if (create_extra(self, NULL) < 0) return NULL; @@ -1337,32 +1780,80 @@ for (i = self->extra->length; i > index; i--) self->extra->children[i] = self->extra->children[i-1]; - Py_INCREF(element); - self->extra->children[index] = element; + Py_INCREF(subelement); + self->extra->children[index] = subelement; self->extra->length++; Py_RETURN_NONE; } -static PyObject* -element_items(ElementObject* self, PyObject* args) +/*[clinic input] +_elementtree.Element.items + + self: self(type='ElementObject *') + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_Element_items__doc__, +"items()"); + +#define _ELEMENTTREE_ELEMENT_ITEMS_METHODDEF \ + {"items", (PyCFunction)_elementtree_Element_items, METH_NOARGS, _elementtree_Element_items__doc__}, + +static PyObject * +_elementtree_Element_items_impl(ElementObject *self); + +static PyObject * +_elementtree_Element_items(PyObject *self, PyObject *Py_UNUSED(ignored)) { - if (!PyArg_ParseTuple(args, ":items")) - return NULL; - + PyObject *return_value = NULL; + + return_value = _elementtree_Element_items_impl((ElementObject *)self); + + return return_value; +} + +static PyObject * +_elementtree_Element_items_impl(ElementObject *self) +/*[clinic end generated code: checksum=6da79e8ab42972f525e6e861b7c4a484f276355a]*/ +{ if (!self->extra || self->extra->attrib == Py_None) return PyList_New(0); return PyDict_Items(self->extra->attrib); } -static PyObject* -element_keys(ElementObject* self, PyObject* args) +/*[clinic input] +_elementtree.Element.keys + + self: self(type='ElementObject *') + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_Element_keys__doc__, +"keys()"); + +#define _ELEMENTTREE_ELEMENT_KEYS_METHODDEF \ + {"keys", (PyCFunction)_elementtree_Element_keys, METH_NOARGS, _elementtree_Element_keys__doc__}, + +static PyObject * +_elementtree_Element_keys_impl(ElementObject *self); + +static PyObject * +_elementtree_Element_keys(PyObject *self, PyObject *Py_UNUSED(ignored)) { - if (!PyArg_ParseTuple(args, ":keys")) - return NULL; - + PyObject *return_value = NULL; + + return_value = _elementtree_Element_keys_impl((ElementObject *)self); + + return return_value; +} + +static PyObject * +_elementtree_Element_keys_impl(ElementObject *self) +/*[clinic end generated code: checksum=793f43a3dac2f01b7666d889f093e3f512d482f3]*/ +{ if (!self->extra || self->extra->attrib == Py_None) return PyList_New(0); @@ -1378,16 +1869,48 @@ return self->extra->length; } -static PyObject* -element_makeelement(PyObject* self, PyObject* args, PyObject* kw) +/*[clinic input] +_elementtree.Element.makeelement + + self: self(type='ElementObject *') + tag: object + attrib: object + / + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_Element_makeelement__doc__, +"makeelement(tag, attrib)"); + +#define _ELEMENTTREE_ELEMENT_MAKEELEMENT_METHODDEF \ + {"makeelement", (PyCFunction)_elementtree_Element_makeelement, METH_VARARGS, _elementtree_Element_makeelement__doc__}, + +static PyObject * +_elementtree_Element_makeelement_impl(ElementObject *self, PyObject *tag, PyObject *attrib); + +static PyObject * +_elementtree_Element_makeelement(PyObject *self, PyObject *args) +{ + PyObject *return_value = NULL; + PyObject *tag; + PyObject *attrib; + + if (!PyArg_ParseTuple(args, + "OO:makeelement", + &tag, &attrib)) + goto exit; + return_value = _elementtree_Element_makeelement_impl((ElementObject *)self, tag, attrib); + +exit: + return return_value; +} + +static PyObject * +_elementtree_Element_makeelement_impl(ElementObject *self, PyObject *tag, PyObject *attrib) +/*[clinic end generated code: checksum=a6361094d69138417544cf031f3df2d669510053]*/ { PyObject* elem; - PyObject* tag; - PyObject* attrib; - if (!PyArg_ParseTuple(args, "OO:makeelement", &tag, &attrib)) - return NULL; - attrib = PyDict_Copy(attrib); if (!attrib) return NULL; @@ -1399,15 +1922,46 @@ return elem; } -static PyObject* -element_remove(ElementObject* self, PyObject* args) +/*[clinic input] +_elementtree.Element.remove + + self: self(type='ElementObject *') + subelement: object(subclass_of='&Element_Type') + / + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_Element_remove__doc__, +"remove(subelement)"); + +#define _ELEMENTTREE_ELEMENT_REMOVE_METHODDEF \ + {"remove", (PyCFunction)_elementtree_Element_remove, METH_VARARGS, _elementtree_Element_remove__doc__}, + +static PyObject * +_elementtree_Element_remove_impl(ElementObject *self, PyObject *subelement); + +static PyObject * +_elementtree_Element_remove(PyObject *self, PyObject *args) +{ + PyObject *return_value = NULL; + PyObject *subelement; + + if (!PyArg_ParseTuple(args, + "O!:remove", + &Element_Type, &subelement)) + goto exit; + return_value = _elementtree_Element_remove_impl((ElementObject *)self, subelement); + +exit: + return return_value; +} + +static PyObject * +_elementtree_Element_remove_impl(ElementObject *self, PyObject *subelement) +/*[clinic end generated code: checksum=461762446933dbcaf0dd5f2bddd5075ee6594a10]*/ { int i; - PyObject* element; - if (!PyArg_ParseTuple(args, "O!:remove", &Element_Type, &element)) - return NULL; - if (!self->extra) { /* element has no children, so raise exception */ PyErr_SetString( @@ -1418,14 +1972,14 @@ } for (i = 0; i < self->extra->length; i++) { - if (self->extra->children[i] == element) + if (self->extra->children[i] == subelement) break; - if (PyObject_RichCompareBool(self->extra->children[i], element, Py_EQ) == 1) + if (PyObject_RichCompareBool(self->extra->children[i], subelement, Py_EQ) == 1) break; } if (i == self->extra->length) { - /* element is not in children, so raise exception */ + /* subelement is not in children, so raise exception */ PyErr_SetString( PyExc_ValueError, "list.remove(x): x not in list" @@ -1452,16 +2006,48 @@ return PyUnicode_FromFormat("", self); } -static PyObject* -element_set(ElementObject* self, PyObject* args) +/*[clinic input] +_elementtree.Element.set + + self: self(type='ElementObject *') + key: object + value: object + / + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_Element_set__doc__, +"set(key, value)"); + +#define _ELEMENTTREE_ELEMENT_SET_METHODDEF \ + {"set", (PyCFunction)_elementtree_Element_set, METH_VARARGS, _elementtree_Element_set__doc__}, + +static PyObject * +_elementtree_Element_set_impl(ElementObject *self, PyObject *key, PyObject *value); + +static PyObject * +_elementtree_Element_set(PyObject *self, PyObject *args) +{ + PyObject *return_value = NULL; + PyObject *key; + PyObject *value; + + if (!PyArg_ParseTuple(args, + "OO:set", + &key, &value)) + goto exit; + return_value = _elementtree_Element_set_impl((ElementObject *)self, key, value); + +exit: + return return_value; +} + +static PyObject * +_elementtree_Element_set_impl(ElementObject *self, PyObject *key, PyObject *value) +/*[clinic end generated code: checksum=bff41191c04d8ebb5ca002101771cc54575ef34c]*/ { PyObject* attrib; - PyObject* key; - PyObject* value; - if (!PyArg_ParseTuple(args, "OO:set", &key, &value)) - return NULL; - if (!self->extra) { if (create_extra(self, NULL) < 0) return NULL; @@ -1744,37 +2330,37 @@ static PyMethodDef element_methods[] = { - {"clear", (PyCFunction) element_clearmethod, METH_VARARGS}, - - {"get", (PyCFunction) element_get, METH_VARARGS | METH_KEYWORDS}, - {"set", (PyCFunction) element_set, METH_VARARGS}, - - {"find", (PyCFunction) element_find, METH_VARARGS | METH_KEYWORDS}, - {"findtext", (PyCFunction) element_findtext, METH_VARARGS | METH_KEYWORDS}, - {"findall", (PyCFunction) element_findall, METH_VARARGS | METH_KEYWORDS}, - - {"append", (PyCFunction) element_append, METH_VARARGS}, - {"extend", (PyCFunction) element_extend, METH_VARARGS}, - {"insert", (PyCFunction) element_insert, METH_VARARGS}, - {"remove", (PyCFunction) element_remove, METH_VARARGS}, - - {"iter", (PyCFunction) element_iter, METH_VARARGS | METH_KEYWORDS}, - {"itertext", (PyCFunction) element_itertext, METH_VARARGS}, - {"iterfind", (PyCFunction) element_iterfind, METH_VARARGS | METH_KEYWORDS}, - - {"getiterator", (PyCFunction) element_iter, METH_VARARGS | METH_KEYWORDS}, - {"getchildren", (PyCFunction) element_getchildren, METH_VARARGS}, - - {"items", (PyCFunction) element_items, METH_VARARGS}, - {"keys", (PyCFunction) element_keys, METH_VARARGS}, - - {"makeelement", (PyCFunction) element_makeelement, METH_VARARGS}, - - {"__copy__", (PyCFunction) element_copy, METH_VARARGS}, - {"__deepcopy__", (PyCFunction) element_deepcopy, METH_VARARGS}, - {"__sizeof__", element_sizeof, METH_NOARGS}, - {"__getstate__", (PyCFunction)element_getstate, METH_NOARGS}, - {"__setstate__", (PyCFunction)element_setstate, METH_O}, + _ELEMENTTREE_ELEMENT_CLEAR_METHODDEF + + _ELEMENTTREE_ELEMENT_GET_METHODDEF + _ELEMENTTREE_ELEMENT_SET_METHODDEF + + _ELEMENTTREE_ELEMENT_FIND_METHODDEF + _ELEMENTTREE_ELEMENT_FINDTEXT_METHODDEF + _ELEMENTTREE_ELEMENT_FINDALL_METHODDEF + + _ELEMENTTREE_ELEMENT_APPEND_METHODDEF + _ELEMENTTREE_ELEMENT_EXTEND_METHODDEF + _ELEMENTTREE_ELEMENT_INSERT_METHODDEF + _ELEMENTTREE_ELEMENT_REMOVE_METHODDEF + + _ELEMENTTREE_ELEMENT_ITER_METHODDEF + _ELEMENTTREE_ELEMENT_ITERTEXT_METHODDEF + _ELEMENTTREE_ELEMENT_ITERFIND_METHODDEF + + {"getiterator", (PyCFunction)_elementtree_Element_iter, METH_VARARGS|METH_KEYWORDS, _elementtree_Element_iter__doc__}, + _ELEMENTTREE_ELEMENT_GETCHILDREN_METHODDEF + + _ELEMENTTREE_ELEMENT_ITEMS_METHODDEF + _ELEMENTTREE_ELEMENT_KEYS_METHODDEF + + _ELEMENTTREE_ELEMENT_MAKEELEMENT_METHODDEF + + _ELEMENTTREE_ELEMENT___COPY___METHODDEF + _ELEMENTTREE_ELEMENT___DEEPCOPY___METHODDEF + _ELEMENTTREE_ELEMENT___SIZEOF___METHODDEF + _ELEMENTTREE_ELEMENT___GETSTATE___METHODDEF + _ELEMENTTREE_ELEMENT___SETSTATE___METHODDEF {NULL, NULL} }; @@ -2262,6 +2848,11 @@ return (PyObject *)t; } +/*[clinic input] +class _elementtree.TreeBuilder +[clinic start generated code]*/ +/*[clinic end generated code: checksum=da39a3ee5e6b4b0d3255bfef95601890afd80709]*/ + static int treebuilder_init(PyObject *self, PyObject *args, PyObject *kwds) { @@ -2598,23 +3189,47 @@ /* -------------------------------------------------------------------- */ /* methods (in alphabetical order) */ -static PyObject* -treebuilder_data(TreeBuilderObject* self, PyObject* args) +/*[clinic input] +_elementtree.TreeBuilder.data + + self: self(type='TreeBuilderObject *') + data: object + / + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_TreeBuilder_data__doc__, +"data(data)"); + +#define _ELEMENTTREE_TREEBUILDER_DATA_METHODDEF \ + {"data", (PyCFunction)_elementtree_TreeBuilder_data, METH_O, _elementtree_TreeBuilder_data__doc__}, + +static PyObject * +_elementtree_TreeBuilder_data(TreeBuilderObject *self, PyObject *data) +/*[clinic end generated code: checksum=c8bc9ede07a4b79d1f937c442d6990ebc8b180db]*/ { - PyObject* data; - if (!PyArg_ParseTuple(args, "O:data", &data)) - return NULL; - return treebuilder_handle_data(self, data); } -static PyObject* -treebuilder_end(TreeBuilderObject* self, PyObject* args) +/*[clinic input] +_elementtree.TreeBuilder.end + + self: self(type='TreeBuilderObject *') + tag: object + / + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_TreeBuilder_end__doc__, +"end(tag)"); + +#define _ELEMENTTREE_TREEBUILDER_END_METHODDEF \ + {"end", (PyCFunction)_elementtree_TreeBuilder_end, METH_O, _elementtree_TreeBuilder_end__doc__}, + +static PyObject * +_elementtree_TreeBuilder_end(TreeBuilderObject *self, PyObject *tag) +/*[clinic end generated code: checksum=82bee0547d56fa6b029f8732b4d3c7f15f5d011c]*/ { - PyObject* tag; - if (!PyArg_ParseTuple(args, "O:end", &tag)) - return NULL; - return treebuilder_handle_end(self, tag); } @@ -2634,31 +3249,87 @@ return res; } -static PyObject* -treebuilder_close(TreeBuilderObject* self, PyObject* args) +/*[clinic input] +_elementtree.TreeBuilder.close + + self: self(type='TreeBuilderObject *') + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_TreeBuilder_close__doc__, +"close()"); + +#define _ELEMENTTREE_TREEBUILDER_CLOSE_METHODDEF \ + {"close", (PyCFunction)_elementtree_TreeBuilder_close, METH_NOARGS, _elementtree_TreeBuilder_close__doc__}, + +static PyObject * +_elementtree_TreeBuilder_close_impl(TreeBuilderObject *self); + +static PyObject * +_elementtree_TreeBuilder_close(PyObject *self, PyObject *Py_UNUSED(ignored)) { - if (!PyArg_ParseTuple(args, ":close")) - return NULL; - + PyObject *return_value = NULL; + + return_value = _elementtree_TreeBuilder_close_impl((TreeBuilderObject *)self); + + return return_value; +} + +static PyObject * +_elementtree_TreeBuilder_close_impl(TreeBuilderObject *self) +/*[clinic end generated code: checksum=04499971c07c3de69d131ca3885664749c4a48b7]*/ +{ return treebuilder_done(self); } -static PyObject* -treebuilder_start(TreeBuilderObject* self, PyObject* args) +/*[clinic input] +_elementtree.TreeBuilder.start + + self: self(type='TreeBuilderObject *') + tag: object + attrs: object = None + / + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_TreeBuilder_start__doc__, +"start(tag, attrs=None)"); + +#define _ELEMENTTREE_TREEBUILDER_START_METHODDEF \ + {"start", (PyCFunction)_elementtree_TreeBuilder_start, METH_VARARGS, _elementtree_TreeBuilder_start__doc__}, + +static PyObject * +_elementtree_TreeBuilder_start_impl(TreeBuilderObject *self, PyObject *tag, PyObject *attrs); + +static PyObject * +_elementtree_TreeBuilder_start(PyObject *self, PyObject *args) { - PyObject* tag; - PyObject* attrib = Py_None; - if (!PyArg_ParseTuple(args, "O|O:start", &tag, &attrib)) - return NULL; - - return treebuilder_handle_start(self, tag, attrib); + PyObject *return_value = NULL; + PyObject *tag; + PyObject *attrs = Py_None; + + if (!PyArg_ParseTuple(args, + "O|O:start", + &tag, &attrs)) + goto exit; + return_value = _elementtree_TreeBuilder_start_impl((TreeBuilderObject *)self, tag, attrs); + +exit: + return return_value; } +static PyObject * +_elementtree_TreeBuilder_start_impl(TreeBuilderObject *self, PyObject *tag, PyObject *attrs) +/*[clinic end generated code: checksum=e1c32bce2ff2880e4756348b489e1eace4b7c442]*/ +{ + return treebuilder_handle_start(self, tag, attrs); +} + static PyMethodDef treebuilder_methods[] = { - {"data", (PyCFunction) treebuilder_data, METH_VARARGS}, - {"start", (PyCFunction) treebuilder_start, METH_VARARGS}, - {"end", (PyCFunction) treebuilder_end, METH_VARARGS}, - {"close", (PyCFunction) treebuilder_close, METH_VARARGS}, + _ELEMENTTREE_TREEBUILDER_DATA_METHODDEF + _ELEMENTTREE_TREEBUILDER_START_METHODDEF + _ELEMENTTREE_TREEBUILDER_END_METHODDEF + _ELEMENTTREE_TREEBUILDER_CLOSE_METHODDEF {NULL, NULL} }; @@ -3209,6 +3880,11 @@ return (PyObject *)self; } +/*[clinic input] +class _elementtree.XMLParser +[clinic start generated code]*/ +/*[clinic end generated code: checksum=da39a3ee5e6b4b0d3255bfef95601890afd80709]*/ + static int xmlparser_init(PyObject *self, PyObject *args, PyObject *kwds) { @@ -3369,15 +4045,39 @@ Py_RETURN_NONE; } -static PyObject* -xmlparser_close(XMLParserObject* self, PyObject* args) +/*[clinic input] +_elementtree.XMLParser.close + + self: self(type='XMLParserObject *') + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_XMLParser_close__doc__, +"close()"); + +#define _ELEMENTTREE_XMLPARSER_CLOSE_METHODDEF \ + {"close", (PyCFunction)_elementtree_XMLParser_close, METH_NOARGS, _elementtree_XMLParser_close__doc__}, + +static PyObject * +_elementtree_XMLParser_close_impl(XMLParserObject *self); + +static PyObject * +_elementtree_XMLParser_close(PyObject *self, PyObject *Py_UNUSED(ignored)) +{ + PyObject *return_value = NULL; + + return_value = _elementtree_XMLParser_close_impl((XMLParserObject *)self); + + return return_value; +} + +static PyObject * +_elementtree_XMLParser_close_impl(XMLParserObject *self) +/*[clinic end generated code: checksum=e559a2ddc0d5eb10cd73b4af4eef751d3f266757]*/ { /* end feeding data to parser */ PyObject* res; - if (!PyArg_ParseTuple(args, ":close")) - return NULL; - res = expat_parse(self, "", 0, 1); if (!res) return NULL; @@ -3395,15 +4095,31 @@ } } -static PyObject* -xmlparser_feed(XMLParserObject* self, PyObject* arg) +/*[clinic input] +_elementtree.XMLParser.feed + + self: self(type='XMLParserObject *') + data: object + / + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_XMLParser_feed__doc__, +"feed(data)"); + +#define _ELEMENTTREE_XMLPARSER_FEED_METHODDEF \ + {"feed", (PyCFunction)_elementtree_XMLParser_feed, METH_O, _elementtree_XMLParser_feed__doc__}, + +static PyObject * +_elementtree_XMLParser_feed(XMLParserObject *self, PyObject *data) +/*[clinic end generated code: checksum=4946fd63df292c934b8f4d4a4c4d1e5d46330d61]*/ { /* feed data to parser */ - if (PyUnicode_Check(arg)) { + if (PyUnicode_Check(data)) { Py_ssize_t data_len; - const char *data = PyUnicode_AsUTF8AndSize(arg, &data_len); - if (data == NULL) + const char *data_ptr = PyUnicode_AsUTF8AndSize(data, &data_len); + if (data_ptr == NULL) return NULL; if (data_len > INT_MAX) { PyErr_SetString(PyExc_OverflowError, "size does not fit in an int"); @@ -3411,12 +4127,12 @@ } /* Explicitly set UTF-8 encoding. Return code ignored. */ (void)EXPAT(SetEncoding)(self->parser, "utf-8"); - return expat_parse(self, data, (int)data_len, 0); + return expat_parse(self, data_ptr, (int)data_len, 0); } else { Py_buffer view; PyObject *res; - if (PyObject_GetBuffer(arg, &view, PyBUF_SIMPLE) < 0) + if (PyObject_GetBuffer(data, &view, PyBUF_SIMPLE) < 0) return NULL; if (view.len > INT_MAX) { PyBuffer_Release(&view); @@ -3429,8 +4145,24 @@ } } -static PyObject* -xmlparser_parse_whole(XMLParserObject* self, PyObject* args) +/*[clinic input] +_elementtree.XMLParser._parse_whole + + self: self(type='XMLParserObject *') + file: object + / + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_XMLParser__parse_whole__doc__, +"_parse_whole(file)"); + +#define _ELEMENTTREE_XMLPARSER__PARSE_WHOLE_METHODDEF \ + {"_parse_whole", (PyCFunction)_elementtree_XMLParser__parse_whole, METH_O, _elementtree_XMLParser__parse_whole__doc__}, + +static PyObject * +_elementtree_XMLParser__parse_whole(XMLParserObject *self, PyObject *file) +/*[clinic end generated code: checksum=1de535f1ffda36f6063de9c643d867d05a7fabe4]*/ { /* (internal) parse the whole input, until end of stream */ PyObject* reader; @@ -3438,11 +4170,7 @@ PyObject* temp; PyObject* res; - PyObject* fileobj; - if (!PyArg_ParseTuple(args, "O:_parse", &fileobj)) - return NULL; - - reader = PyObject_GetAttrString(fileobj, "read"); + reader = PyObject_GetAttrString(file, "read"); if (!reader) return NULL; @@ -3503,25 +4231,83 @@ return res; } -static PyObject* -xmlparser_doctype(XMLParserObject *self, PyObject *args) +/*[clinic input] +_elementtree.XMLParser.doctype + + self: self(type='XMLParserObject *') + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_XMLParser_doctype__doc__, +"doctype()"); + +#define _ELEMENTTREE_XMLPARSER_DOCTYPE_METHODDEF \ + {"doctype", (PyCFunction)_elementtree_XMLParser_doctype, METH_NOARGS, _elementtree_XMLParser_doctype__doc__}, + +static PyObject * +_elementtree_XMLParser_doctype_impl(XMLParserObject *self); + +static PyObject * +_elementtree_XMLParser_doctype(PyObject *self, PyObject *Py_UNUSED(ignored)) +{ + PyObject *return_value = NULL; + + return_value = _elementtree_XMLParser_doctype_impl((XMLParserObject *)self); + + return return_value; +} + +static PyObject * +_elementtree_XMLParser_doctype_impl(XMLParserObject *self) +/*[clinic end generated code: checksum=a4be49db2c4827ccbee8f4511468d05d0dec0281]*/ { Py_RETURN_NONE; } -static PyObject* -xmlparser_setevents(XMLParserObject *self, PyObject* args) +/*[clinic input] +_elementtree.XMLParser._setevents + + self: self(type='XMLParserObject *') + events_queue: object(subclass_of='&PyList_Type') + events_to_report: object = None + / + +[clinic start generated code]*/ + +PyDoc_STRVAR(_elementtree_XMLParser__setevents__doc__, +"_setevents(events_queue, events_to_report=None)"); + +#define _ELEMENTTREE_XMLPARSER__SETEVENTS_METHODDEF \ + {"_setevents", (PyCFunction)_elementtree_XMLParser__setevents, METH_VARARGS, _elementtree_XMLParser__setevents__doc__}, + +static PyObject * +_elementtree_XMLParser__setevents_impl(XMLParserObject *self, PyObject *events_queue, PyObject *events_to_report); + +static PyObject * +_elementtree_XMLParser__setevents(PyObject *self, PyObject *args) +{ + PyObject *return_value = NULL; + PyObject *events_queue; + PyObject *events_to_report = Py_None; + + if (!PyArg_ParseTuple(args, + "O!|O:_setevents", + &PyList_Type, &events_queue, &events_to_report)) + goto exit; + return_value = _elementtree_XMLParser__setevents_impl((XMLParserObject *)self, events_queue, events_to_report); + +exit: + return return_value; +} + +static PyObject * +_elementtree_XMLParser__setevents_impl(XMLParserObject *self, PyObject *events_queue, PyObject *events_to_report) +/*[clinic end generated code: checksum=fb035b7fbf8a08b852467eecd664d0058ce56344]*/ { /* activate element event reporting */ Py_ssize_t i, seqlen; TreeBuilderObject *target; - - PyObject *events_queue; - PyObject *events_to_report = Py_None; PyObject *events_seq; - if (!PyArg_ParseTuple(args, "O!|O:_setevents", &PyList_Type, &events_queue, - &events_to_report)) - return NULL; if (!TreeBuilder_CheckExact(self->target)) { PyErr_SetString( @@ -3606,11 +4392,11 @@ } static PyMethodDef xmlparser_methods[] = { - {"feed", (PyCFunction) xmlparser_feed, METH_O}, - {"close", (PyCFunction) xmlparser_close, METH_VARARGS}, - {"_parse_whole", (PyCFunction) xmlparser_parse_whole, METH_VARARGS}, - {"_setevents", (PyCFunction) xmlparser_setevents, METH_VARARGS}, - {"doctype", (PyCFunction) xmlparser_doctype, METH_VARARGS}, + _ELEMENTTREE_XMLPARSER_FEED_METHODDEF + _ELEMENTTREE_XMLPARSER_CLOSE_METHODDEF + _ELEMENTTREE_XMLPARSER__PARSE_WHOLE_METHODDEF + _ELEMENTTREE_XMLPARSER__SETEVENTS_METHODDEF + _ELEMENTTREE_XMLPARSER_DOCTYPE_METHODDEF {NULL, NULL} }; From report at bugs.python.org Wed Jan 8 01:04:27 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jan 2014 00:04:27 +0000 Subject: [issue20159] Derby: Convert the ElementTree module to use Argument Clinic In-Reply-To: <1389086966.47.0.33615845784.issue20159@psf.upfronthosting.co.za> Message-ID: <1389139467.53.0.2452209728.issue20159@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 01:06:00 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jan 2014 00:06:00 +0000 Subject: [issue20159] Derby: Convert the ElementTree module to use Argument Clinic In-Reply-To: <1389086966.47.0.33615845784.issue20159@psf.upfronthosting.co.za> Message-ID: <1389139560.25.0.835441935687.issue20159@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, what's the strange idea to group unrelated modules together? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 01:10:39 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 00:10:39 +0000 Subject: [issue20159] Derby: Convert the ElementTree module to use Argument Clinic In-Reply-To: <1389086966.47.0.33615845784.issue20159@psf.upfronthosting.co.za> Message-ID: <1389139839.13.0.669219143378.issue20159@psf.upfronthosting.co.za> Larry Hastings added the comment: As I discussed with you on IRC, the problem is, we have 129 files with sites that need examining. I was advised that creating 129 issues on the tracker was a bad idea. So I had to combine them together somehow. I wrote a Python script to group them into bundles of approximately 50 sites, and it work largely at random. I did ask you several times for feedback on the bundles, as you had expressed some interest in how the bundles were aggregated, but you did not respond. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 01:13:16 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 00:13:16 +0000 Subject: [issue20159] Derby #7: Convert 51 sites to Argument Clinic across 3 files -> Derby: Convert the ElementTree module to use Argument Clinic In-Reply-To: <1389086966.47.0.33615845784.issue20159@psf.upfronthosting.co.za> Message-ID: <1389139996.77.0.632001939706.issue20159@psf.upfronthosting.co.za> Larry Hastings added the comment: Since you have abandoned your patch, please stop changing the issue title on me. ---------- title: Derby: Convert the ElementTree module to use Argument Clinic -> Derby #7: Convert 51 sites to Argument Clinic across 3 files -> Derby: Convert the ElementTree module to use Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 01:14:38 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 00:14:38 +0000 Subject: [issue20178] Derby #9: Convert 52 sites to Argument Clinic across 11 files Message-ID: <1389140078.91.0.720761635456.issue20178@psf.upfronthosting.co.za> New submission from Larry Hastings: This issue is part of the Great Argument Clinic Conversion Derby, where we're trying to convert as much of Python 3.4 to use Argument Clinic as we can before Release Candidate 1 on January 19. This issue asks you to change the following bundle of files: Modules/_ctypes/_ctypes.c: 8 sites Modules/_ctypes/_ctypes_test.c: 1 sites Modules/_ctypes/callproc.c: 14 sites Modules/_ctypes/stgdict.c: 0 sites Modules/_curses_panel.c: 3 sites Modules/_sqlite/cache.c: 1 sites Modules/_sqlite/connection.c: 12 sites Modules/_sqlite/cursor.c: 5 sites Modules/_sqlite/microprotocols.c: 1 sites Modules/_sqlite/module.c: 6 sites Modules/_sqlite/row.c: 1 sites Talk to me (larry) if you only want to attack part of a bundle. For instructions on how to convert a function to work with Argument Clinic, read the "howto": http://docs.python.org/dev/howto/clinic.html ---------- components: Extension Modules messages: 207634 nosy: larry priority: normal severity: normal stage: needs patch status: open title: Derby #9: Convert 52 sites to Argument Clinic across 11 files type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 01:15:20 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 00:15:20 +0000 Subject: [issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4 files Message-ID: <1389140120.63.0.492860390436.issue20179@psf.upfronthosting.co.za> New submission from Larry Hastings: This issue is part of the Great Argument Clinic Conversion Derby, where we're trying to convert as much of Python 3.4 to use Argument Clinic as we can before Release Candidate 1 on January 19. This issue asks you to change the following bundle of files: Modules/overlapped.c: 21 sites Modules/_ssl.c: 20 sites Objects/bytes_methods.c: 1 sites Objects/bytesobject.c: 8 sites Talk to me (larry) if you only want to attack part of a bundle. For instructions on how to convert a function to work with Argument Clinic, read the "howto": http://docs.python.org/dev/howto/clinic.html ---------- components: Extension Modules messages: 207635 nosy: larry priority: normal severity: normal stage: needs patch status: open title: Derby #10: Convert 50 sites to Argument Clinic across 4 files type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 01:16:02 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 00:16:02 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files Message-ID: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za> New submission from Larry Hastings: This issue is part of the Great Argument Clinic Conversion Derby, where we're trying to convert as much of Python 3.4 to use Argument Clinic as we can before Release Candidate 1 on January 19. This issue asks you to change the following bundle of files: Modules/_collectionsmodule.c: 4 sites Modules/itertoolsmodule.c: 11 sites Modules/_randommodule.c: 1 sites Objects/unicodeobject.c: 14 sites Modules/xxlimited.c: 4 sites Modules/xxmodule.c: 5 sites Modules/xxsubtype.c: 5 sites Objects/stringlib/find.h: 1 sites Objects/stringlib/transmogrify.h: 5 sites Talk to me (larry) if you only want to attack part of a bundle. For instructions on how to convert a function to work with Argument Clinic, read the "howto": http://docs.python.org/dev/howto/clinic.html ---------- components: Extension Modules messages: 207636 nosy: larry priority: normal severity: normal stage: needs patch status: open title: Derby #11: Convert 50 sites to Argument Clinic across 9 files type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 01:16:43 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 00:16:43 +0000 Subject: [issue20181] Derby #12: Convert 50 sites to Argument Clinic across 4 files Message-ID: <1389140203.53.0.198441160626.issue20181@psf.upfronthosting.co.za> New submission from Larry Hastings: This issue is part of the Great Argument Clinic Conversion Derby, where we're trying to convert as much of Python 3.4 to use Argument Clinic as we can before Release Candidate 1 on January 19. This issue asks you to change the following bundle of files: Objects/bytearrayobject.c: 13 sites Modules/parsermodule.c: 13 sites Modules/unicodedata.c: 12 sites Modules/readline.c: 12 sites Talk to me (larry) if you only want to attack part of a bundle. For instructions on how to convert a function to work with Argument Clinic, read the "howto": http://docs.python.org/dev/howto/clinic.html ---------- components: Extension Modules messages: 207637 nosy: larry priority: normal severity: normal stage: needs patch status: open title: Derby #12: Convert 50 sites to Argument Clinic across 4 files type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 01:17:25 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jan 2014 00:17:25 +0000 Subject: [issue20159] Derby #7: Convert 51 sites to Argument Clinic across 3 files -> Derby: Convert the ElementTree module to use Argument Clinic In-Reply-To: <1389139996.77.0.632001939706.issue20159@psf.upfronthosting.co.za> Message-ID: <2878624.33b6qfMOmQ@raxxla> Serhiy Storchaka added the comment: This is ridiculous. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 01:17:37 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 00:17:37 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files Message-ID: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> New submission from Larry Hastings: This issue is part of the Great Argument Clinic Conversion Derby, where we're trying to convert as much of Python 3.4 to use Argument Clinic as we can before Release Candidate 1 on January 19. This issue asks you to change the following bundle of files: Modules/signalmodule.c: 12 sites Modules/selectmodule.c: 12 sites Modules/zlibmodule.c: 11 sites Python/sysmodule.c: 10 sites Modules/_hashopenssl.c: 5 sites Talk to me (larry) if you only want to attack part of a bundle. For instructions on how to convert a function to work with Argument Clinic, read the "howto": http://docs.python.org/dev/howto/clinic.html ---------- components: Extension Modules messages: 207639 nosy: larry priority: normal severity: normal stage: needs patch status: open title: Derby #13: Convert 50 sites to Argument Clinic across 5 files type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 01:18:09 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 00:18:09 +0000 Subject: [issue20183] Derby #14: Convert 50 sites to Argument Clinic across 6 files Message-ID: <1389140289.9.0.366061884326.issue20183@psf.upfronthosting.co.za> New submission from Larry Hastings: This issue is part of the Great Argument Clinic Conversion Derby, where we're trying to convert as much of Python 3.4 to use Argument Clinic as we can before Release Candidate 1 on January 19. This issue asks you to change the following bundle of files: Modules/mmapmodule.c: 10 sites Modules/_localemodule.c: 10 sites Modules/zipimport.c: 9 sites Modules/ossaudiodev.c: 9 sites Modules/_testbuffer.c: 9 sites Modules/_struct.c: 3 sites Talk to me (larry) if you only want to attack part of a bundle. For instructions on how to convert a function to work with Argument Clinic, read the "howto": http://docs.python.org/dev/howto/clinic.html ---------- components: Extension Modules messages: 207640 nosy: larry priority: normal severity: normal stage: needs patch status: open title: Derby #14: Convert 50 sites to Argument Clinic across 6 files type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 01:21:06 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 00:21:06 +0000 Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1389140466.18.0.404050333165.issue20152@psf.upfronthosting.co.za> Larry Hastings added the comment: (Brett: in order to avoid creating 129 differet issues on the tracker, I'm bundling files together into groups of 50 sites. You don't have to tackle the whole list if you don't want to.) This issue is part of the Great Argument Clinic Conversion Derby, where we're trying to convert as much of Python 3.4 to use Argument Clinic as we can before Release Candidate 1 on January 19. This issue asks you to change the following bundle of files: Python/import.c: 8 sites Modules/cmathmodule.c: 8 sites Modules/cjkcodecs/multibytecodec.c: 8 sites Modules/arraymodule.c: 8 sites Modules/pyexpat.c: 7 sites Modules/fcntlmodule.c: 7 sites Modules/pwdmodule.c: 2 sites Modules/spwdmodule.c: 1 sites Modules/grpmodule.c: 1 sites Talk to me (larry) if you only want to attack part of a bundle. For instructions on how to convert a function to work with Argument Clinic, read the "howto": http://docs.python.org/dev/howto/clinic.html ---------- priority: low -> normal status: pending -> open title: Derby: Convert the _imp module to use Argument Clinic -> Derby #15: Convert 50 sites to Argument Clinic across 9 files type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 01:21:44 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 00:21:44 +0000 Subject: [issue20184] Derby #16: Convert 50 sites to Argument Clinic across 9 files Message-ID: <1389140504.71.0.617730511292.issue20184@psf.upfronthosting.co.za> New submission from Larry Hastings: This issue is part of the Great Argument Clinic Conversion Derby, where we're trying to convert as much of Python 3.4 to use Argument Clinic as we can before Release Candidate 1 on January 19. This issue asks you to change the following bundle of files: Modules/faulthandler.c: 7 sites Modules/_pickle.c: 7 sites Modules/_lzmamodule.c: 7 sites Python/bltinmodule.c: 6 sites Modules/termios.c: 6 sites Modules/syslogmodule.c: 6 sites Modules/_dbmmodule.c: 4 sites Modules/_gdbmmodule.c: 2 sites Modules/_json.c: 5 sites Talk to me (larry) if you only want to attack part of a bundle. For instructions on how to convert a function to work with Argument Clinic, read the "howto": http://docs.python.org/dev/howto/clinic.html ---------- components: Extension Modules messages: 207642 nosy: larry priority: normal severity: normal stage: needs patch status: open title: Derby #16: Convert 50 sites to Argument Clinic across 9 files type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 01:22:19 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 00:22:19 +0000 Subject: [issue20185] Derby #17: Convert 50 sites to Argument Clinic across 14 files Message-ID: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> New submission from Larry Hastings: This issue is part of the Great Argument Clinic Conversion Derby, where we're trying to convert as much of Python 3.4 to use Argument Clinic as we can before Release Candidate 1 on January 19. This issue asks you to change the following bundle of files: Objects/typeobject.c: 5 sites Objects/longobject.c: 5 sites Objects/listobject.c: 5 sites Objects/floatobject.c: 4 sites Modules/resource.c: 4 sites Modules/_threadmodule.c: 4 sites Modules/_bz2module.c: 4 sites Modules/_bisectmodule.c: 4 sites Python/marshal.c: 3 sites Objects/exceptions.c: 3 sites Modules/nismodule.c: 3 sites Modules/gcmodule.c: 3 sites Python/_warnings.c: 2 sites Modules/_cryptmodule.c: 1 sites Talk to me (larry) if you only want to attack part of a bundle. For instructions on how to convert a function to work with Argument Clinic, read the "howto": http://docs.python.org/dev/howto/clinic.html ---------- components: Extension Modules messages: 207643 nosy: larry priority: normal severity: normal stage: needs patch status: open title: Derby #17: Convert 50 sites to Argument Clinic across 14 files type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 01:23:06 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 00:23:06 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files Message-ID: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> New submission from Larry Hastings: This issue is part of the Great Argument Clinic Conversion Derby, where we're trying to convert as much of Python 3.4 to use Argument Clinic as we can before Release Candidate 1 on January 19. This issue asks you to change the following bundle of files: Objects/tupleobject.c: 2 sites Objects/memoryobject.c: 2 sites Objects/descrobject.c: 2 sites Objects/complexobject.c: 2 sites Modules/_operator.c: 2 sites Modules/_opcode.c: 2 sites Modules/_lsprof.c: 2 sites Modules/_heapqmodule.c: 2 sites Objects/weakrefobject.c: 1 sites Objects/structseq.c: 1 sites Objects/rangeobject.c: 1 sites Objects/object.c: 1 sites Objects/moduleobject.c: 1 sites Objects/funcobject.c: 1 sites Objects/fileobject.c: 1 sites Objects/enumobject.c: 1 sites Objects/codeobject.c: 1 sites Objects/boolobject.c: 1 sites Modules/symtablemodule.c: 1 sites Modules/mathmodule.c: 1 sites Modules/_tracemalloc.c: 1 sites Modules/_io/_iomodule.c: 1 sites Modules/_csv.c: 1 sites Talk to me (larry) if you only want to attack part of a bundle. For instructions on how to convert a function to work with Argument Clinic, read the "howto": http://docs.python.org/dev/howto/clinic.html ---------- components: Extension Modules messages: 207644 nosy: larry priority: normal severity: normal stage: needs patch status: open title: Derby #18: Convert 31 sites to Argument Clinic across 23 files type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 01:25:28 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 00:25:28 +0000 Subject: [issue20133] Derby: Convert the audioop module to use Argument Clinic In-Reply-To: <1388956864.17.0.114751586443.issue20133@psf.upfronthosting.co.za> Message-ID: <1389140728.05.0.84996994453.issue20133@psf.upfronthosting.co.za> Larry Hastings added the comment: Serhiy: Assigning to you because you wrote a patch; if you don't want the issue, sorry, please undo it. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 01:25:38 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 00:25:38 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1389140738.82.0.393238256389.issue20148@psf.upfronthosting.co.za> Larry Hastings added the comment: Serhiy: Assigning to you because you wrote a patch; if you don't want the issue, sorry, please undo it. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 01:25:45 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 00:25:45 +0000 Subject: [issue20151] Derby: Convert the binascii module to use Argument Clinic In-Reply-To: <1389037748.15.0.70999359123.issue20151@psf.upfronthosting.co.za> Message-ID: <1389140745.93.0.612767631159.issue20151@psf.upfronthosting.co.za> Larry Hastings added the comment: Serhiy: Assigning to you because you wrote a patch; if you don't want the issue, sorry, please undo it. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 01:26:09 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 Jan 2014 00:26:09 +0000 Subject: [issue20169] random module doc page has broken links In-Reply-To: <1389135190.46.0.595431802912.issue20169@psf.upfronthosting.co.za> Message-ID: <1389140769.33.0.454608357055.issue20169@psf.upfronthosting.co.za> R. David Murray added the comment: I started to make some quick changes to fix this, but it turns out that the Random *class* isn't even documented in the docs except for the introductory paragraphs. IMO that ought to be fixed, too, since the intro even talks about subclassing it. ---------- nosy: +r.david.murray stage: -> needs patch versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 01:31:45 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 00:31:45 +0000 Subject: [issue20187] The Great Argument Clinic Conversion Derby Meta-Issue Message-ID: <1389141105.5.0.459903580868.issue20187@psf.upfronthosting.co.za> New submission from Larry Hastings: This is a meta-issue tracking all the Argument Clinic Derby sub-issues. ---------- assignee: larry components: email messages: 207649 nosy: barry, larry, r.david.murray priority: normal severity: normal stage: needs patch status: open title: The Great Argument Clinic Conversion Derby Meta-Issue type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 01:33:00 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 00:33:00 +0000 Subject: [issue20187] The Great Argument Clinic Conversion Derby Meta-Issue In-Reply-To: <1389141105.5.0.459903580868.issue20187@psf.upfronthosting.co.za> Message-ID: <1389141180.74.0.471339798075.issue20187@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- dependencies: +Derby: Convert the audioop module to use Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 01:33:08 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 00:33:08 +0000 Subject: [issue20187] The Great Argument Clinic Conversion Derby Meta-Issue In-Reply-To: <1389141105.5.0.459903580868.issue20187@psf.upfronthosting.co.za> Message-ID: <1389141188.28.0.950459968482.issue20187@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- dependencies: +Derby: Convert the _sre module to use Argument Clinic -Derby: Convert the audioop module to use Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 01:34:48 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 00:34:48 +0000 Subject: [issue20187] The Great Argument Clinic Conversion Derby Meta-Issue In-Reply-To: <1389141105.5.0.459903580868.issue20187@psf.upfronthosting.co.za> Message-ID: <1389141288.73.0.641883992659.issue20187@psf.upfronthosting.co.za> Larry Hastings added the comment: The issue tracker isn't letting me add all the dependencies to the dependency list. For the record, here are the numbers: #20133 #20148 #20151 #20152 #20159 #20168 #20170 #20171 #20172 #20173 #20174 #20175 #20177 #20178 #20179 #20180 #20181 #20182 #20183 #20184 #20185 #20186 (so far) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 01:52:55 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 08 Jan 2014 00:52:55 +0000 Subject: [issue20183] Derby #14: Convert 50 sites to Argument Clinic across 6 files In-Reply-To: <1389140289.9.0.366061884326.issue20183@psf.upfronthosting.co.za> Message-ID: <1389142375.71.0.831089607413.issue20183@psf.upfronthosting.co.za> Stefan Krah added the comment: Could you take out _testbuffer.c? It has 100% coverage patches which would break and it is not a public module. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 01:55:27 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 08 Jan 2014 00:55:27 +0000 Subject: [issue20177] Derby #8: Convert 52 sites to Argument Clinic across 3 files In-Reply-To: <1389138574.32.0.892814928986.issue20177@psf.upfronthosting.co.za> Message-ID: <1389142527.59.0.731232617493.issue20177@psf.upfronthosting.co.za> Stefan Krah added the comment: Please take out _decimal.c. It has a huge test suite that would break entirely. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 02:03:40 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 01:03:40 +0000 Subject: [issue20183] Derby #14: Convert 41 sites to Argument Clinic across 5 files In-Reply-To: <1389140289.9.0.366061884326.issue20183@psf.upfronthosting.co.za> Message-ID: <1389143020.68.0.50518539716.issue20183@psf.upfronthosting.co.za> Larry Hastings added the comment: Sure. Whoever takes ownership of this issue: please ignore _testbuffer.c. ---------- title: Derby #14: Convert 50 sites to Argument Clinic across 6 files -> Derby #14: Convert 41 sites to Argument Clinic across 5 files _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 02:04:41 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 01:04:41 +0000 Subject: [issue20177] Derby #8: Convert 28 sites to Argument Clinic across 2 files In-Reply-To: <1389138574.32.0.892814928986.issue20177@psf.upfronthosting.co.za> Message-ID: <1389143081.54.0.901579007263.issue20177@psf.upfronthosting.co.za> Larry Hastings added the comment: Absolutely. decimal is a very special case. Whoever takes over this issue: please ignore the part about _decimal.c. ---------- title: Derby #8: Convert 52 sites to Argument Clinic across 3 files -> Derby #8: Convert 28 sites to Argument Clinic across 2 files _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 02:36:37 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 Jan 2014 01:36:37 +0000 Subject: [issue20187] The Great Argument Clinic Conversion Derby Meta-Issue In-Reply-To: <1389141105.5.0.459903580868.issue20187@psf.upfronthosting.co.za> Message-ID: <1389144997.44.0.332861244461.issue20187@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- dependencies: +Derby #10: Convert 50 sites to Argument Clinic across 4 files, Derby #11: Convert 50 sites to Argument Clinic across 9 files, Derby #12: Convert 50 sites to Argument Clinic across 4 files, Derby #13: Convert 50 sites to Argument Clinic across 5 files, Derby #14: Convert 41 sites to Argument Clinic across 5 files, Derby #15: Convert 50 sites to Argument Clinic across 9 files, Derby #16: Convert 50 sites to Argument Clinic across 9 files, Derby #17: Convert 50 sites to Argument Clinic across 14 files, Derby #18: Convert 31 sites to Argument Clinic across 23 files, Derby #1: Convert 137 sites to Argument Clinic in Modules/posixmodule.c, Derby #2: Convert 115 sites to Argument Clinic in Modules/_cursesmodule.c, Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows), Derby #4: Convert 53 sites to Argument Clinic across 5 files, Derby #5: Convert 50 sites to Argument Clinic across 3 files, Derby #6: Convert 50 sites to Argument Clinic across 8 files, Derby #7: Convert 51 sites to Argument Clinic across 3 files -> Derby: Convert the ElementTree module to use Argument Clinic, Derby #8: Convert 28 sites to Argument Clinic across 2 files, Derby #9: Convert 52 sites to Argument Clinic across 11 files, Derby: Convert the _tkinter module to use Argument Clinic, Derby: Convert the audioop module to use Argument Clinic, Derby: Convert the binascii module to use Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 02:54:17 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 08 Jan 2014 01:54:17 +0000 Subject: [issue20187] The Great Argument Clinic Conversion Derby Meta-Issue In-Reply-To: <1389141105.5.0.459903580868.issue20187@psf.upfronthosting.co.za> Message-ID: <1389146057.0.0.752938000695.issue20187@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 03:14:09 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 08 Jan 2014 02:14:09 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <1389147249.65.0.0696670403277.issue19081@psf.upfronthosting.co.za> Changes by Gregory P. Smith : Added file: http://bugs.python.org/file33356/issue19081-33-gps06.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 03:14:17 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 08 Jan 2014 02:14:17 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <1389147257.85.0.632517626002.issue19081@psf.upfronthosting.co.za> Changes by Gregory P. Smith : Removed file: http://bugs.python.org/file33339/issue19081-33-gps05.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 03:34:46 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Jan 2014 02:34:46 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <3dzZKx2l3Bz7LjR@mail.python.org> Roundup Robot added the comment: New changeset 2807a5f011e4 by Gregory P. Smith in branch '3.3': Fixes Issue #19081: When a zipimport .zip file in sys.path being imported from http://hg.python.org/cpython/rev/2807a5f011e4 New changeset 20b77ff040b6 by Gregory P. Smith in branch 'default': Fixes issue #19081: When a zipimport .zip file in sys.path being imported from http://hg.python.org/cpython/rev/20b77ff040b6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 03:40:01 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Jan 2014 02:40:01 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <3dzZS04w0Qz7LjX@mail.python.org> Roundup Robot added the comment: New changeset 5609135c6e86 by Gregory P. Smith in branch '2.7': cleanup for the issue 19081 fix - pull the file open and close outside of the http://hg.python.org/cpython/rev/5609135c6e86 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 03:44:12 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 08 Jan 2014 02:44:12 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <1389149052.56.0.406613394822.issue19081@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I believe this is done. I'm opting not to go for a more complicated "cache the open FILE* with the zip_directory_cache" approach for 3.4 due to complexity and time. long term: It'd be ideal if zipimport weren't a pile of C code separate from the zipfile module itself. importlib is baked in, perhaps a pure python zipimport and zipfile could be baked in someday. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 04:42:46 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Wed, 08 Jan 2014 03:42:46 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1389152566.59.0.942431422024.issue7776@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Ok, this is a bit of a mess. Issue #11448 contains a patch for the documentation. But the functionality itself is still not working. With the (I believe) intended usage, we have: >>> import http.client >>> conn = http.client.HTTPSConnection("localhost",8080) >>> conn.set_tunnel("www.python.org") >>> conn.request("HEAD","/index.html") What happens then is this: - request() calls _send_request(), which calls _put_request() - _put_request() generates a "Host: localhost:8080" header - _send_request() calls sendheaders(), calls _send_output() - _send_output() calls send(), which calls connect() - connect() connects to localhost:8080 and calls _tunnel() - _tunnel() sets self.host to www.python.org and establishes the tunnel, but the Host: header has already been generated, and the proxy host name and port is now lost - The request is send with a wrong Host header - When calling close() and connect(), connect will now try to connect directly to www.python.org, but attempt to use it as a proxy to tunnel to itself. ---------- nosy: +Nikratio title: httplib.py: ._tunnel() broken -> http.client.HTTPConnection tunneling is broken versions: +Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 04:49:16 2014 From: report at bugs.python.org (Mark Nottingham) Date: Wed, 08 Jan 2014 03:49:16 +0000 Subject: [issue5639] Support TLS SNI extension in ssl module In-Reply-To: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za> Message-ID: <1389152956.49.0.378668068519.issue5639@psf.upfronthosting.co.za> Mark Nottingham added the comment: This is *not* a feature request, it's a bug fix in the underlying protocols. Client sides that do not send SNI are actively hurting the Web and the Internet by constraining the deployment of TLS. The closest analogy would be if Python's HTTP client side didn't emit a Host header, and the excuse were "But we only advertise ourselves as HTTP/1.0." The biggest difference being that this has additional security impact. The pain of lack of support for SNI is completely borne by the server-side, not the client (here, Python). As such, this is not a feature for Python client-side developers, but an interop / scaling / security issue for the Web and Internet overall. ---------- nosy: +mnot _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 04:52:59 2014 From: report at bugs.python.org (Mark Nottingham) Date: Wed, 08 Jan 2014 03:52:59 +0000 Subject: [issue20188] ALPN support for TLS Message-ID: <1389153179.88.0.510995543218.issue20188@psf.upfronthosting.co.za> New submission from Mark Nottingham: In #14204, support for NPN was added. Subsequently, NPN has been superseded by ALPN in the IETF, and support for it is coming in OpenSSL 1.0.2. http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg http://rt.openssl.org/Ticket/Display.html?id=3073 http://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=NEWS ---------- components: Extension Modules messages: 207660 nosy: mnot priority: normal severity: normal status: open title: ALPN support for TLS type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 05:10:12 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Wed, 08 Jan 2014 04:10:12 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1389154212.21.0.802935392975.issue7776@psf.upfronthosting.co.za> Nikolaus Rath added the comment: I have attached a patch that should fix the issue. ---------- keywords: +patch Added file: http://bugs.python.org/file33357/issue7776.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 05:42:49 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 08 Jan 2014 04:42:49 +0000 Subject: [issue18960] First line can be executed twice In-Reply-To: <1378559493.77.0.649785663787.issue18960@psf.upfronthosting.co.za> Message-ID: <1389156169.68.0.18034878911.issue18960@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Yeah, I'm okay now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 05:43:10 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Wed, 08 Jan 2014 04:43:10 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1389156190.75.0.150346646119.issue7776@psf.upfronthosting.co.za> Nikolaus Rath added the comment: New patch revision, this time includes unit tests. ---------- Added file: http://bugs.python.org/file33358/issue7776_rev1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 05:46:17 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Wed, 08 Jan 2014 04:46:17 +0000 Subject: [issue10983] Errors in http.client.HTTPConnection class (python3) In-Reply-To: <1295732961.38.0.859825723182.issue10983@psf.upfronthosting.co.za> Message-ID: <1389156377.79.0.451305415662.issue10983@psf.upfronthosting.co.za> Nikolaus Rath added the comment: There were actually a few additional bugs. I fixed them, and added testcases, in issue 7776. ---------- nosy: +Nikratio _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 05:48:27 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Wed, 08 Jan 2014 04:48:27 +0000 Subject: [issue11448] docs for HTTPConnection.set_tunnel are ambiguous In-Reply-To: <1299636529.48.0.302129596868.issue11448@psf.upfronthosting.co.za> Message-ID: <1389156507.23.0.271068092772.issue11448@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Is there anything that needs to be done to get this patch applied? It would be nice if this could be committed together with the patch in issue 7776. ---------- nosy: +Nikratio _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 05:48:51 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Wed, 08 Jan 2014 04:48:51 +0000 Subject: [issue11448] docs for HTTPConnection.set_tunnel are ambiguous In-Reply-To: <1299636529.48.0.302129596868.issue11448@psf.upfronthosting.co.za> Message-ID: <1389156531.66.0.899090565511.issue11448@psf.upfronthosting.co.za> Changes by Nikolaus Rath : ---------- type: -> enhancement versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 05:53:18 2014 From: report at bugs.python.org (Brian Curtin) Date: Wed, 08 Jan 2014 04:53:18 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1389156798.92.0.810455256943.issue7776@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- nosy: -brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 06:05:57 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Wed, 08 Jan 2014 05:05:57 +0000 Subject: [issue19414] iter(ordered_dict) yields keys not in dict in some circumstances In-Reply-To: <1382844474.66.0.775956254592.issue19414@psf.upfronthosting.co.za> Message-ID: <1389157557.24.0.47380535044.issue19414@psf.upfronthosting.co.za> Nikolaus Rath added the comment: I have attached a patch that fixes this issue. Looking at Raymonds comments in issue 19332, I have kept new code out of the critical path in __iter__ and instead modified the __delitem__ method (I assume that an element is removed only once, but may be iterated over many times). The updated __delitem__ now also updates the prev and next links of the removed item itself. When the current item is removed during an iteration, the iteration thus stops. I hope that's an acceptable solution. ---------- keywords: +patch Added file: http://bugs.python.org/file33359/issue19414.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 06:13:54 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Wed, 08 Jan 2014 05:13:54 +0000 Subject: [issue12704] Language Reference: Clarify behaviour of yield when generator is not resumed In-Reply-To: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za> Message-ID: <1389158034.37.0.863573372543.issue12704@psf.upfronthosting.co.za> Nikolaus Rath added the comment: *ping* Any comments on the updated patch? Can it be applied? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 06:17:27 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Wed, 08 Jan 2014 05:17:27 +0000 Subject: [issue18574] BaseHTTPRequestHandler.handle_expect_100() sends invalid response In-Reply-To: <1374971787.85.0.837580893432.issue18574@psf.upfronthosting.co.za> Message-ID: <1389158247.42.0.925851194168.issue18574@psf.upfronthosting.co.za> Nikolaus Rath added the comment: *ping* Is there anything wrong with the patch? What do I have to do to get it applied? ---------- Added file: http://bugs.python.org/file33360/issue18574.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 06:25:20 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Wed, 08 Jan 2014 05:25:20 +0000 Subject: [issue6627] threading.local() does not work with C-created threads In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za> Message-ID: <1389158720.04.0.379213664377.issue6627@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Here's a patch that (I think) incorporates all the comments. If someone could apply it, that would be great :-). ---------- keywords: +patch versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file33361/issue6627.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 06:45:55 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Wed, 08 Jan 2014 05:45:55 +0000 Subject: [issue17811] Improve os.readv() and os.writev() documentation and docstring In-Reply-To: <1366579468.26.0.0312151391842.issue17811@psf.upfronthosting.co.za> Message-ID: <1389159955.6.0.362442645084.issue17811@psf.upfronthosting.co.za> Nikolaus Rath added the comment: I have attached a patch that takes into account your comments. Would this be suitable for inclusion? ---------- keywords: +patch Added file: http://bugs.python.org/file33362/issue17811.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 06:47:22 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Wed, 08 Jan 2014 05:47:22 +0000 Subject: [issue17814] Popen.stdin/stdout/stderr documentation should mention object type In-Reply-To: <1366586086.38.0.427506521088.issue17814@psf.upfronthosting.co.za> Message-ID: <1389160042.67.0.301957174614.issue17814@psf.upfronthosting.co.za> Nikolaus Rath added the comment: *ping* Is this suitable for inclusion? Or do I need to do anything else? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 06:53:45 2014 From: report at bugs.python.org (Victor Varvariuc) Date: Wed, 08 Jan 2014 05:53:45 +0000 Subject: [issue14119] Ability to adjust queue size in Executors In-Reply-To: <1330129142.34.0.452763799677.issue14119@psf.upfronthosting.co.za> Message-ID: <1389160425.39.0.501573639957.issue14119@psf.upfronthosting.co.za> Victor Varvariuc added the comment: Hi Brian, In one my projects I had to monkey-patch module `concurrent.futures.thread:60`( http://hg.python.org/cpython/file/37caaf21f827/Lib/concurrent/futures/thread.py#l60) with: def _worker(executor_reference, work_queue): try: while True: work_item = work_queue.get(block=True) if work_item is not None: work_item.run() work_queue.task_done() # <-- added this line continue executor = executor_reference() # Exit if: # - The interpreter is shutting down OR # - The executor that owns the worker has been collected OR # - The executor that owns the worker has been shutdown. if futures_thread._shutdown or executor is None or executor._shutdown: # Notice other workers work_queue.put(None) return del executor except BaseException: futures_thread._base.LOGGER.critical('Exception in worker', exc_info=True) This helps me to control the state of the work queue -- I can see if there are any work items still being processed: if executor._work_queue.unfinished_tasks: # executor is still producing something ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 06:54:39 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 08 Jan 2014 05:54:39 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <1389160479.6.0.770958979626.issue19081@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 06:59:47 2014 From: report at bugs.python.org (Eric Snow) Date: Wed, 08 Jan 2014 05:59:47 +0000 Subject: [issue20123] pydoc.synopsis fails to load binary modules In-Reply-To: <1388874425.94.0.221860493391.issue20123@psf.upfronthosting.co.za> Message-ID: <1389160787.95.0.732800057835.issue20123@psf.upfronthosting.co.za> Eric Snow added the comment: I realized today that this should probably be fixed in 3.3 as well, as RDM implied by marking it as also a 3.3 bug. :) ---------- resolution: fixed -> stage: committed/rejected -> patch review status: closed -> open versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 07:24:00 2014 From: report at bugs.python.org (Eric Snow) Date: Wed, 08 Jan 2014 06:24:00 +0000 Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451 In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za> Message-ID: <1389162240.38.0.417793007791.issue19713@psf.upfronthosting.co.za> Eric Snow added the comment: Good catch. I've gone through looking for other such left-overs from earlier patches that included deprecation warnings for loader.load_module(), but this is the only one I found. However, I did notice that _SpecMethods.from_module() does not get used anywhere. For now I'm going to remove it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 07:33:35 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Jan 2014 06:33:35 +0000 Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451 In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za> Message-ID: <3dzgdV400kz7LjR@mail.python.org> Roundup Robot added the comment: New changeset c0b0e7aef360 by Eric Snow in branch 'default': Issue 19713: Remove PEP 451-related code that should have been factored out. http://hg.python.org/cpython/rev/c0b0e7aef360 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 07:34:27 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 08 Jan 2014 06:34:27 +0000 Subject: [issue20103] Documentation of itertools.accumulate is confused In-Reply-To: <1388592720.87.0.970906154406.issue20103@psf.upfronthosting.co.za> Message-ID: <1389162867.26.0.322182893686.issue20103@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: docs at python -> rhettinger priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 07:43:39 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 08 Jan 2014 06:43:39 +0000 Subject: [issue2226] Small _abcoll Bugs / Oddities In-Reply-To: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za> Message-ID: <1389163419.43.0.251607330395.issue2226@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Yes, I'll have a look shortly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 08:19:39 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 08 Jan 2014 07:19:39 +0000 Subject: [issue20169] random module doc page has broken links In-Reply-To: <1389135190.46.0.595431802912.issue20169@psf.upfronthosting.co.za> Message-ID: <1389165579.81.0.972682555818.issue20169@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: docs at python -> rhettinger nosy: +rhettinger priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 10:29:41 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 08 Jan 2014 09:29:41 +0000 Subject: [issue20165] unittest TestResult wasSuccessful returns True when there are unexpected successes In-Reply-To: <1389122721.74.0.155844601606.issue20165@psf.upfronthosting.co.za> Message-ID: <1389173381.83.0.641192416621.issue20165@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I'm not comfortable changing this for 2.7 or 3.3 in case some code is unfortunately is depending on this behavior. But as it is it does seem like the kind of thing that can hide problems (tests that are passing that are not expected to). Here's a patch for 3.4 (minus the documentation update that'll need to explicitly mention this with a versionchanged::). ---------- keywords: +patch stage: needs patch -> patch review versions: -Python 2.7, Python 3.3 Added file: http://bugs.python.org/file33363/issue20165-gps01.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 10:32:36 2014 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Wed, 08 Jan 2014 09:32:36 +0000 Subject: [issue19804] test_uuid.TestUUID.test_find_mac() fails In-Reply-To: <1385521168.13.0.486814911092.issue19804@psf.upfronthosting.co.za> Message-ID: <1389173556.31.0.330130691824.issue19804@psf.upfronthosting.co.za> Bohuslav "Slavek" Kabrda added the comment: When building for Fedora, we usually use minimal buildroot, that doesn't have net-tools (e.g. ifconfig and others) installed, so this test fails for us. It'd probably be best to skip this based on whether ifconfig binary can be found or not. ---------- nosy: +bkabrda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 11:12:30 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 08 Jan 2014 10:12:30 +0000 Subject: [issue19804] test_uuid.TestUUID.test_find_mac() fails In-Reply-To: <1385521168.13.0.486814911092.issue19804@psf.upfronthosting.co.za> Message-ID: <1389175950.4.0.478386775565.issue19804@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- resolution: fixed -> stage: committed/rejected -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 12:16:39 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 08 Jan 2014 11:16:39 +0000 Subject: [issue20188] ALPN support for TLS In-Reply-To: <1389153179.88.0.510995543218.issue20188@psf.upfronthosting.co.za> Message-ID: <1389179799.32.0.583511796349.issue20188@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +christian.heimes, giampaolo.rodola, janssen, pitrou versions: -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 12:20:44 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Wed, 08 Jan 2014 11:20:44 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1389180044.5.0.958392546019.issue20173@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Okay, here is my first attempt. I only worked on one file (Modules/sha1module.c). I need to see whether I hit the mark or not. If yes, I can do the other files as well. Anyway, handling the keyword argument was kinda tough. There was no example so I had to shoot in the dark. ---------- keywords: +patch nosy: +vajrasky Added file: http://bugs.python.org/file33364/clinic_sha1module.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 12:32:31 2014 From: report at bugs.python.org (Nadeem Vawda) Date: Wed, 08 Jan 2014 11:32:31 +0000 Subject: [issue20185] Derby #17: Convert 50 sites to Argument Clinic across 14 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1389180751.03.0.0787772647378.issue20185@psf.upfronthosting.co.za> Changes by Nadeem Vawda : ---------- nosy: +nadeem.vawda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 12:32:38 2014 From: report at bugs.python.org (Nadeem Vawda) Date: Wed, 08 Jan 2014 11:32:38 +0000 Subject: [issue20184] Derby #16: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140504.71.0.617730511292.issue20184@psf.upfronthosting.co.za> Message-ID: <1389180758.9.0.395037959881.issue20184@psf.upfronthosting.co.za> Changes by Nadeem Vawda : ---------- nosy: +nadeem.vawda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 12:32:41 2014 From: report at bugs.python.org (Nadeem Vawda) Date: Wed, 08 Jan 2014 11:32:41 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1389180761.06.0.844504594695.issue20182@psf.upfronthosting.co.za> Changes by Nadeem Vawda : ---------- nosy: +nadeem.vawda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 12:52:39 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 11:52:39 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1389181959.19.0.733946308367.issue20173@psf.upfronthosting.co.za> Larry Hastings added the comment: Just one comment on your patch. The documentation already tells you how to handle keyword arguments (section 8 tells you how to handle default values, section 9 tells you how to handle | in the format string). If you have any suggestions on how I could improve the documentation I'd be happy to try it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 13:47:40 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 12:47:40 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types Message-ID: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> New submission from Larry Hastings: Stefan added some docstring text signatures by hand, only to discover that inspect.Signature still didn't recognize them. Specifically, decimal.Decimal.compare was unrecognized. This is a method_descriptor object, which is a type that isn't even exposed in types. Rather than go on a search-and-destroy mission for all these different builtin types, I'm going to change inspect.Signature so as a fallback at the end it says "if it has a __call__ and a valid __text_signature__, just use that". ---------- assignee: larry components: Library (Lib) messages: 207681 nosy: larry, skrah priority: normal severity: normal stage: needs patch status: open title: inspect.Signature doesn't recognize all builtin types type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 14:31:26 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 13:31:26 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389187886.94.0.732592643849.issue20189@psf.upfronthosting.co.za> Larry Hastings added the comment: Okay, learned some things. 1) inspect already has an ismethoddescriptor(). So I'll try to do this properly by 2) The real problem is that method_descriptor doesn't have __text_signature__. I only added that to PyCFunctionObject. I'll make the code generic and add it to method_descriptor, classmethod_descriptor, and wrapper_descriptor. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 14:35:00 2014 From: report at bugs.python.org (=?utf-8?q?Martin_H=C3=A4cker?=) Date: Wed, 08 Jan 2014 13:35:00 +0000 Subject: [issue20190] dict() in dict(foo='bar') raises Message-ID: <1389188100.33.0.555885401078.issue20190@psf.upfronthosting.co.za> New submission from Martin H?cker: I was quite surprised by this behavior: >>> dict() in [dict()] True >>> dict() in [] False >>> dict() in dict(foo='bar').keys() Traceback (most recent call last): File "", line 1, in TypeError: unhashable type: 'dict' >>> dict() in list(dict(foo='bar').keys()) False I think it should change. Calling dict.keys() one expects to get list like behavior and not having to ensure that everything that is checked for inclusion there has to be hasheable. If it helps, this is also a regression from python 2.6/7 where this works as expected. ---------- messages: 207683 nosy: dwt priority: normal severity: normal status: open title: dict() in dict(foo='bar') raises versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 14:35:18 2014 From: report at bugs.python.org (=?utf-8?q?Martin_H=C3=A4cker?=) Date: Wed, 08 Jan 2014 13:35:18 +0000 Subject: [issue20190] dict() in dict(foo='bar').keys() raises In-Reply-To: <1389188100.33.0.555885401078.issue20190@psf.upfronthosting.co.za> Message-ID: <1389188118.75.0.463053183032.issue20190@psf.upfronthosting.co.za> Changes by Martin H?cker : ---------- title: dict() in dict(foo='bar') raises -> dict() in dict(foo='bar').keys() raises _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 14:38:45 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jan 2014 13:38:45 +0000 Subject: [issue20190] dict() in dict(foo='bar').keys() raises In-Reply-To: <1389188100.33.0.555885401078.issue20190@psf.upfronthosting.co.za> Message-ID: <1389188325.8.0.464812804894.issue20190@psf.upfronthosting.co.za> STINNER Victor added the comment: "key in dict" checks if dict has the specified key. Dictionary keys must be hashable. Dictionaries are not hashable. > If it helps, this is also a regression from python 2.6/7 where this works as expected. dict.keys() return a list in Python 2, whereas it returns a special object "dict_keys". The behaviour of Python 2 is more a side effect than an expected behaviour. Python 2: >>> dict() in dict(key="value") TypeError: unhashable type: 'dict' Python 3 behaviour is correct. ---------- nosy: +haypo resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 15:18:47 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jan 2014 14:18:47 +0000 Subject: [issue20130] asyncio: implement a synchronous executor if concurrent.futures is missing In-Reply-To: <1388917355.05.0.21952188677.issue20130@psf.upfronthosting.co.za> Message-ID: <1389190727.2.0.83857139682.issue20130@psf.upfronthosting.co.za> STINNER Victor added the comment: The synchronous executor has been implemented in Trollius 0.1.1. I now agree with Antoine Pitrou that it's overkill to implement in CPython since only one old platform don't support concurrent.futures. On FreeBSD 6: increase the limit of POSIX semaphore, or upgrade to a more recent FreeBSD version, or use Trollius. ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 15:33:42 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jan 2014 14:33:42 +0000 Subject: [issue20191] resource.prlimit(int, int, str) crashs Message-ID: <1389191622.9.0.0763750909735.issue20191@psf.upfronthosting.co.za> New submission from STINNER Victor: $ ./python -c 'import resource; resource.prlimit(-3, 11, "\udbff\udfff")' Erreur de segmentation (core dumped) The problem is a generic problem with PyArg_Parse functions and "(O)" format. With this format, the caller does not hold a reference to the object nor the tuple. If arbitrary Python code is executed before the object is used, the object pointer becomes a dangling pointer. resource.prlimit() uses: if (!PyArg_ParseTuple(args, _Py_PARSE_PID "i|(OO):prlimit", &pid, &resource, &curobj, &maxobj)) return NULL; In this issue, it's worse: the string is casted to a sequence, and each string character becomes a temporary substring of 1 character. The problem is that PyArg_ParseTuple() nor resource_prlimit() hold the reference, and so the curobj and maxobj are dangling pointer. Options: - raise an error if the second parameter is not a tuple: implement the check in prlimit() or i PyArg_ParseTuple()? - hold a reference to the sequence, to curobj and to maxobj instead of using borrowed references ---------- messages: 207686 nosy: haypo, serhiy.storchaka priority: normal severity: normal status: open title: resource.prlimit(int, int, str) crashs type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 15:36:11 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Jan 2014 14:36:11 +0000 Subject: [issue20113] os.readv() and os.writev() don't raise an OSError on readv()/writev() failure In-Reply-To: <1388747968.16.0.893473617326.issue20113@psf.upfronthosting.co.za> Message-ID: <3dztLL552Fz7LjZ@mail.python.org> Roundup Robot added the comment: New changeset 1437f499024d by Victor Stinner in branch '3.3': Issue #20113: os.readv() and os.writev() now raise an OSError exception on http://hg.python.org/cpython/rev/1437f499024d New changeset cd50efdce294 by Victor Stinner in branch 'default': (Merge 3.3) Issue #20113: os.readv() and os.writev() now raise an OSError http://hg.python.org/cpython/rev/cd50efdce294 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 15:39:30 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jan 2014 14:39:30 +0000 Subject: [issue20113] os.readv() and os.writev() don't raise an OSError on readv()/writev() failure In-Reply-To: <1388747968.16.0.893473617326.issue20113@psf.upfronthosting.co.za> Message-ID: <1389191970.2.0.170197480471.issue20113@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 16:01:53 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Jan 2014 15:01:53 +0000 Subject: [issue20113] os.readv() and os.writev() don't raise an OSError on readv()/writev() failure In-Reply-To: <1388747968.16.0.893473617326.issue20113@psf.upfronthosting.co.za> Message-ID: <3dztw11t5Gz7LjM@mail.python.org> Roundup Robot added the comment: New changeset 1993a8ec3f19 by Victor Stinner in branch '3.3': Issue #20113: Fix test_posix on OpenIndiana http://hg.python.org/cpython/rev/1993a8ec3f19 New changeset f1f707dd7cae by Victor Stinner in branch 'default': (Merge 3.3) Issue #20113: Fix test_posix on OpenIndiana http://hg.python.org/cpython/rev/f1f707dd7cae ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 16:39:29 2014 From: report at bugs.python.org (Brett Cannon) Date: Wed, 08 Jan 2014 15:39:29 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <1389195569.58.0.849516579885.issue19081@psf.upfronthosting.co.za> Brett Cannon added the comment: While replacing zipimport with a pure Python version using importlib would be a great feather to have in importlib's cap, the dependencies in zipfile would make that somewhat difficult: http://hg.python.org/cpython/file/f1f707dd7cae/Lib/zipfile.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 16:49:45 2014 From: report at bugs.python.org (Meador Inge) Date: Wed, 08 Jan 2014 15:49:45 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389196185.87.0.877743894083.issue20189@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 16:53:50 2014 From: report at bugs.python.org (Meador Inge) Date: Wed, 08 Jan 2014 15:53:50 +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: <1389196430.75.0.304056459078.issue20160@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 17:09:00 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Wed, 08 Jan 2014 16:09:00 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1389197340.24.0.545474681782.issue20173@psf.upfronthosting.co.za> Vajrasky Kok added the comment: An example how to convert keyword argument would be very helpful. I searched the example from existing code but nothing shows up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 17:16:01 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 16:16:01 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1389197761.76.0.966024815958.issue20173@psf.upfronthosting.co.za> Larry Hastings added the comment: To be precise: a "keyword argument" is something that happens on the caller side. What you're talking about is a "positional-or-keyword parameter". And parameters are positional-or-keyword by default. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 17:20:05 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jan 2014 16:20:05 +0000 Subject: [issue20191] resource.prlimit(int, int, str) crashs In-Reply-To: <1389191622.9.0.0763750909735.issue20191@psf.upfronthosting.co.za> Message-ID: <1389198005.82.0.503403412368.issue20191@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for good example, Victor. See issue6083 for early discussion. As for options: - I afraid we can't raise an error if the second parameter is not a tuple right now. Rather we should first emit deprecation warning, and raise an error only several releases later. - We can't turn borrowed references into non-borrowed references, because it will cause reference leaks in existing code. So what we should to do: * Convert all codes in the stdlib to not use "(...)" in PyArg_ParseTuple(). This was mainly done in issue6083. Perhaps resource.prlimit() was added after this. * Deprecate this dangerous feature. Early is better. And emit a warning to all core developers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 18:37:12 2014 From: report at bugs.python.org (Joseph Bylund) Date: Wed, 08 Jan 2014 17:37:12 +0000 Subject: [issue20192] pprint chokes on set containing frozenset Message-ID: <1389202631.98.0.662803177988.issue20192@psf.upfronthosting.co.za> New submission from Joseph Bylund: Expected: pprint the object Observed: crash with: set([Traceback (most recent call last): File "./test.py", line 7, in pp.pprint(myset) File "/usr/lib/python2.7/pprint.py", line 117, in pprint self._format(object, self._stream, 0, 0, {}, 0) File "/usr/lib/python2.7/pprint.py", line 194, in _format object = _sorted(object) File "/usr/lib/python2.7/pprint.py", line 82, in _sorted return sorted(iterable) TypeError: can only compare to a set Steps to repro: #!/usr/bin/python import pprint pp = pprint.PrettyPrinter(indent=4) myset = set(xrange(3)) myset.add(frozenset(xrange(10))) pp.pprint(myset) ---------- messages: 207693 nosy: jbylund priority: normal severity: normal status: open title: pprint chokes on set containing frozenset type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 18:51:11 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 17:51:11 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389203471.33.0.935290876075.issue20189@psf.upfronthosting.co.za> Larry Hastings added the comment: Here's a patch that adds __text_signature__ support for three more builtin types: method_descriptor classmethod_descriptor wrapper_descriptor method-wrapper The patch also modifies inspect.Signature so it recognizes these types. ---------- Added file: http://bugs.python.org/file33365/larry.support.text_signature.on.more.types.diff.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 19:00:29 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 Jan 2014 18:00:29 +0000 Subject: [issue20192] pprint chokes on set containing frozenset In-Reply-To: <1389202631.98.0.662803177988.issue20192@psf.upfronthosting.co.za> Message-ID: <1389204029.07.0.694791403097.issue20192@psf.upfronthosting.co.za> R. David Murray added the comment: FYI, 'crash' is for when the CPython interpreter segfaults, not when python produces a traceback. Sets and frozensets are not comparable to anything except themselves, unlike most other Python2 datatypes. In Python3, most disparate types are not comparable, including sets and frozensets. To fix this issue in 2.7's pprint I think we would have to backport the fix from issue 3976. ---------- components: +Library (Lib) nosy: +r.david.murray type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 20:03:31 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jan 2014 19:03:31 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic Message-ID: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: In progress. These modules have similar interfaces and common maintainer. ---------- assignee: serhiy.storchaka components: Extension Modules messages: 207696 nosy: nadeem.vawda, serhiy.storchaka priority: normal severity: normal status: open title: Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 20:03:44 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jan 2014 19:03:44 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1389207824.81.0.131751541535.issue20193@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 20:58:31 2014 From: report at bugs.python.org (Brett Cannon) Date: Wed, 08 Jan 2014 19:58:31 +0000 Subject: [issue20194] Add :deprecated: marker to formatter docs Message-ID: <1389211111.33.0.543249498103.issue20194@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: brett.cannon components: Documentation nosy: brett.cannon priority: normal severity: normal status: open title: Add :deprecated: marker to formatter docs versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 20:58:47 2014 From: report at bugs.python.org (Brett Cannon) Date: Wed, 08 Jan 2014 19:58:47 +0000 Subject: [issue20195] Add :deprecated: marker to imp docs Message-ID: <1389211127.27.0.285308920291.issue20195@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: brett.cannon components: Documentation nosy: brett.cannon priority: normal severity: normal status: open title: Add :deprecated: marker to imp docs versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 21:32:49 2014 From: report at bugs.python.org (Brett Cannon) Date: Wed, 08 Jan 2014 20:32:49 +0000 Subject: [issue20194] Add :deprecated: marker to formatter module docs Message-ID: <1389213169.83.0.84586296159.issue20194@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- title: Add :deprecated: marker to formatter docs -> Add :deprecated: marker to formatter module docs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 21:33:36 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 20:33:36 +0000 Subject: [issue20187] The Great Argument Clinic Conversion Derby Meta-Issue In-Reply-To: <1389141105.5.0.459903580868.issue20187@psf.upfronthosting.co.za> Message-ID: <1389213216.45.0.0292131137221.issue20187@psf.upfronthosting.co.za> Larry Hastings added the comment: Here's how the files were parceled out into the various bundles: #20170 Derby #1: Convert 137 sites to Argument Clinic in Modules/posixmodule.c Modules/posixmodule.c: 137 sites #20171 Derby #2: Convert 115 sites to Argument Clinic in Modules/_cursesmodule.c Modules/_cursesmodule.c: 115 sites #20172 Derby #3: Convert 67 sites to Argument Clinic across 4 files PC/msvcrtmodule.c: 18 sites PC/winreg.c: 24 sites PC/winsound.c: 3 sites Modules/_winapi.c: 22 sites #20173 Derby #4: Convert 53 sites to Argument Clinic across 5 files Modules/_codecsmodule.c: 43 sites Modules/sha1module.c: 2 sites Modules/sha256module.c: 3 sites Modules/sha512module.c: 3 sites Modules/md5module.c: 2 sites #20174 Derby #5: Convert 50 sites to Argument Clinic across 3 files Modules/socketmodule.c: 47 sites Modules/socketmodule.h: 1 sites Modules/_functoolsmodule.c: 2 sites #20175 Derby #6: Convert 50 sites to Argument Clinic across 8 files Modules/_io/bufferedio.c: 13 sites Modules/_io/bytesio.c: 6 sites Modules/_io/fileio.c: 6 sites Modules/_io/iobase.c: 4 sites Modules/_io/stringio.c: 5 sites Modules/_io/textio.c: 8 sites Modules/_multiprocessing/multiprocessing.c: 3 sites Modules/_multiprocessing/semaphore.c: 5 sites #20159 Derby #7: Convert 51 sites to Argument Clinic across 3 files Modules/_elementtree.c: 31 sites PC/_msi.c: 15 sites PC/bdist_wininst/install.c: 5 sites #20177 Derby #8: Convert 52 sites to Argument Clinic across 3 files Modules/_datetimemodule.c: 20 sites Modules/timemodule.c: 8 sites Modules/_decimal/_decimal.c: 24 sites #20178 Derby #9: Convert 52 sites to Argument Clinic across 11 files Modules/_ctypes/_ctypes.c: 8 sites Modules/_ctypes/_ctypes_test.c: 1 sites Modules/_ctypes/callproc.c: 14 sites Modules/_ctypes/stgdict.c: 0 sites Modules/_curses_panel.c: 3 sites Modules/_sqlite/cache.c: 1 sites Modules/_sqlite/connection.c: 12 sites Modules/_sqlite/cursor.c: 5 sites Modules/_sqlite/microprotocols.c: 1 sites Modules/_sqlite/module.c: 6 sites Modules/_sqlite/row.c: 1 sites #20179 Derby #10: Convert 50 sites to Argument Clinic across 4 files Modules/overlapped.c: 21 sites Modules/_ssl.c: 20 sites Objects/bytes_methods.c: 1 sites Objects/bytesobject.c: 8 sites #20180 Derby #11: Convert 50 sites to Argument Clinic across 9 files Modules/_collectionsmodule.c: 4 sites Modules/itertoolsmodule.c: 11 sites Modules/_randommodule.c: 1 sites Objects/unicodeobject.c: 14 sites Modules/xxlimited.c: 4 sites Modules/xxmodule.c: 5 sites Modules/xxsubtype.c: 5 sites Objects/stringlib/find.h: 1 sites Objects/stringlib/transmogrify.h: 5 sites #20181 Derby #12: Convert 50 sites to Argument Clinic across 4 files Objects/bytearrayobject.c: 13 sites Modules/parsermodule.c: 13 sites Modules/unicodedata.c: 12 sites Modules/readline.c: 12 sites #20182 Derby #13: Convert 50 sites to Argument Clinic across 5 files Modules/signalmodule.c: 12 sites Modules/selectmodule.c: 12 sites Modules/zlibmodule.c: 11 sites Python/sysmodule.c: 10 sites Modules/_hashopenssl.c: 5 sites #20183 Derby #14: Convert 50 sites to Argument Clinic across 6 files Modules/mmapmodule.c: 10 sites Modules/_localemodule.c: 10 sites Modules/zipimport.c: 9 sites Modules/ossaudiodev.c: 9 sites Modules/_testbuffer.c: 9 sites Modules/_struct.c: 3 sites #20152 Derby #15: Convert 50 sites to Argument Clinic across 9 files Python/import.c: 8 sites Modules/cmathmodule.c: 8 sites Modules/cjkcodecs/multibytecodec.c: 8 sites Modules/arraymodule.c: 8 sites Modules/pyexpat.c: 7 sites Modules/fcntlmodule.c: 7 sites Modules/pwdmodule.c: 2 sites Modules/spwdmodule.c: 1 sites Modules/grpmodule.c: 1 sites #20184 Derby #16: Convert 50 sites to Argument Clinic across 9 files Modules/faulthandler.c: 7 sites Modules/_pickle.c: 7 sites Modules/_lzmamodule.c: 7 sites Python/bltinmodule.c: 6 sites Modules/termios.c: 6 sites Modules/syslogmodule.c: 6 sites Modules/_dbmmodule.c: 4 sites Modules/_gdbmmodule.c: 2 sites Modules/_json.c: 5 sites #20185 Derby #17: Convert 50 sites to Argument Clinic across 14 files Objects/typeobject.c: 5 sites Objects/longobject.c: 5 sites Objects/listobject.c: 5 sites Objects/floatobject.c: 4 sites Modules/resource.c: 4 sites Modules/_threadmodule.c: 4 sites Modules/_bz2module.c: 4 sites Modules/_bisectmodule.c: 4 sites Python/marshal.c: 3 sites Objects/exceptions.c: 3 sites Modules/nismodule.c: 3 sites Modules/gcmodule.c: 3 sites Python/_warnings.c: 2 sites Modules/_cryptmodule.c: 1 sites #20186 Derby #18: Convert 31 sites to Argument Clinic across 23 files Objects/tupleobject.c: 2 sites Objects/memoryobject.c: 2 sites Objects/descrobject.c: 2 sites Objects/complexobject.c: 2 sites Modules/_operator.c: 2 sites Modules/_opcode.c: 2 sites Modules/_lsprof.c: 2 sites Modules/_heapqmodule.c: 2 sites Objects/weakrefobject.c: 1 sites Objects/structseq.c: 1 sites Objects/rangeobject.c: 1 sites Objects/object.c: 1 sites Objects/moduleobject.c: 1 sites Objects/funcobject.c: 1 sites Objects/fileobject.c: 1 sites Objects/enumobject.c: 1 sites Objects/codeobject.c: 1 sites Objects/boolobject.c: 1 sites Modules/symtablemodule.c: 1 sites Modules/mathmodule.c: 1 sites Modules/_tracemalloc.c: 1 sites Modules/_io/_iomodule.c: 1 sites Modules/_csv.c: 1 sites ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 21:33:44 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Wed, 08 Jan 2014 20:33:44 +0000 Subject: [issue20188] ALPN support for TLS In-Reply-To: <1389153179.88.0.510995543218.issue20188@psf.upfronthosting.co.za> Message-ID: <1389213224.58.0.0989196951582.issue20188@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 21:40:00 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 20:40:00 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1389213600.29.0.167206660992.issue20193@psf.upfronthosting.co.za> Larry Hastings added the comment: I'd prefer it if you use the existing Derby issues. It's hard enough for me to keep track of what's going on as it is, and it's unhelpful of you to create a redundant issue. If you'd like some help figuring out how to work with the existing issues please talk to me. Please close this issue. zlib is in Derby #13, issue #20182. _lzma is in Derby #16, issue #20184. _bz2 is in Derby #17, issue #20185. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 21:43:48 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 20:43:48 +0000 Subject: [issue20168] Derby: Convert the _tkinter module to use Argument Clinic In-Reply-To: <1389128639.57.0.613370502446.issue20168@psf.upfronthosting.co.za> Message-ID: <1389213828.33.0.4260483485.issue20168@psf.upfronthosting.co.za> Larry Hastings added the comment: So do you think there are any entry points worth converting in _tkinter, or should we close this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 22:17:00 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jan 2014 21:17:00 +0000 Subject: [issue20196] Argument Clinic generates invalid code for optional parameter Message-ID: <1389215820.54.0.23969623905.issue20196@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Argument Clinic generates invalid code for optional parameter if there are no mandatory parameters except self. Example: /*[clinic input] zlib.Decompress.flush self: self(type="compobject *") [ length: uint the initial size of the output buffer. ] / Return a bytes object containing any remaining decompressed data. [clinic start generated code]*/ Generates: ... switch (PyTuple_Size(args)) { case 0: if (!PyArg_ParseTuple(args, ":flush", )) return NULL; break; ... Note a comma in PyArg_ParseTuple. ---------- components: Build messages: 207700 nosy: larry, serhiy.storchaka priority: normal severity: normal status: open title: Argument Clinic generates invalid code for optional parameter versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 22:25:14 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 21:25:14 +0000 Subject: [issue20196] Argument Clinic generates invalid code for optional parameter In-Reply-To: <1389215820.54.0.23969623905.issue20196@psf.upfronthosting.co.za> Message-ID: <1389216314.1.0.0472642859353.issue20196@psf.upfronthosting.co.za> Larry Hastings added the comment: Good catch! It should be an easy fix, but I won't be able to get to it until tomorrow. ---------- assignee: -> larry stage: -> needs patch type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 22:25:48 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 08 Jan 2014 21:25:48 +0000 Subject: [issue20166] window x64 c-extensions not works on python3.4.0b2 In-Reply-To: <1389124118.85.0.0740185864803.issue20166@psf.upfronthosting.co.za> Message-ID: <1389216348.77.0.332872513159.issue20166@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 22:38:19 2014 From: report at bugs.python.org (Fabrice Aneche) Date: Wed, 08 Jan 2014 21:38:19 +0000 Subject: [issue20197] Support WebP image format detection in imghdr module Message-ID: <1389217099.41.0.299916311184.issue20197@psf.upfronthosting.co.za> New submission from Fabrice Aneche: Detect the webp file format (RIFF container + WEBP), return webp as format detected. ---------- components: Library (Lib) files: imghdr_webp.patch keywords: patch messages: 207702 nosy: akhenakh, gregory.p.smith priority: normal severity: normal status: open title: Support WebP image format detection in imghdr module type: enhancement versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file33366/imghdr_webp.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 22:41:11 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 08 Jan 2014 21:41:11 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1389217271.52.0.700504362769.issue20172@psf.upfronthosting.co.za> Zachary Ware added the comment: I'll take a stab at this one, but I may make you rue the day you said you'd review until your eyes bleed ;) Here's a partial patch to PC/winreg.c, converting only the CloseKey function just to make sure I have some basic idea of what I'm doing. (Also, if anyone else wants this one, please don't hesitate on account of me; just let me know and it's yours.) ---------- keywords: +patch nosy: +zach.ware Added file: http://bugs.python.org/file33367/issue20172.partial.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 22:53:07 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jan 2014 21:53:07 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389213600.29.0.167206660992.issue20193@psf.upfronthosting.co.za> Message-ID: <23548625.lTrPWFr8ZA@raxxla> Serhiy Storchaka added the comment: Here are completed patches for the _bz2 and _lzma modules (only constructors are not converted) and preliminary patch for the zlib module. There are issues in the zlib module: * Argument Clinic generates invalid code for zlib_Decompress_flush (issue20196). * Argument Clinic can simulate optional positional parameters without default Python values only using groups, and resulting code differs from original and is too cumbersome (see code for zlib_compress, zlib_decompress, zlib_Decompress_flush). * I have experimented in zlib_decompressobj, and I got good compact code, but wrong docstring ("decompressobj(wbits=None, zdict=None)"). Needed a way to specify optional parameters without default Python values. Correct signature should be something like "decompressobj([wbits], [zdict])". * Previous approach is not applicable to compressobj because Py_buffer can't have default value. Seems as compressobj is not compatible with Argument Clinic. * This is not specific to this patch, but pydoc produces wrong outputs for compressobj. Perhaps there are other issues, this is only preliminary patch. Larry, I don't want to scatter patches for these related modules and merge them with patches for totally unrelated modules. And I think it would be cumbersome to Nadeem Vawda to make reviews in such circumstances. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 22:53:43 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jan 2014 21:53:43 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1389218023.64.0.000756454581241.issue20193@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch Added file: http://bugs.python.org/file33368/bz2_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 22:53:53 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jan 2014 21:53:53 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1389218033.84.0.345741584951.issue20193@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file33369/lzma_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 22:54:14 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jan 2014 21:54:14 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1389218054.82.0.341950525085.issue20193@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file33370/zlib_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 22:54:33 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 08 Jan 2014 21:54:33 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1389218073.95.0.357408577889.issue20172@psf.upfronthosting.co.za> Zachary Ware added the comment: To possibly ease review (and for keeping track of what I'm doing), I'm linking hg.python.org/sandbox/zware#issue20172 where I'll try to do a commit per converted function. ---------- hgrepos: +216 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 23:00:25 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jan 2014 22:00:25 +0000 Subject: [issue20168] Derby: Convert the _tkinter module to use Argument Clinic In-Reply-To: <1389213828.33.0.4260483485.issue20168@psf.upfronthosting.co.za> Message-ID: <1616052.SvJZAa90vM@raxxla> Serhiy Storchaka added the comment: You misunderstood me. I already have 1018-lines patch which converts about 24 functions and methods to Argument Clinic church. And I'm working on left functions. Do you want to get unfinished patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 23:22:57 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Wed, 08 Jan 2014 22:22:57 +0000 Subject: [issue20197] Support WebP image format detection in imghdr module In-Reply-To: <1389217099.41.0.299916311184.issue20197@psf.upfronthosting.co.za> Message-ID: <1389219777.18.0.412852578432.issue20197@psf.upfronthosting.co.za> Changes by Claudiu.Popa : ---------- nosy: +Claudiu.Popa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 23:30:12 2014 From: report at bugs.python.org (Meador Inge) Date: Wed, 08 Jan 2014 22:30:12 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1389220212.06.0.282285901223.issue20193@psf.upfronthosting.co.za> Meador Inge added the comment: > Larry, I don't want to scatter patches for these related modules and merge > them with patches for totally unrelated modules. And I think it would be > cumbersome to Nadeem Vawda to make reviews in such circumstances. Maybe so, but it will more productive if we can all agree on a method to organize the work so that we don't duplicate effort and it is clear which issues to contribute to. Larry seems to have organized that by sending out multiple mails and opening issues. Opening other issues because you don't agree with the way the organizer has chosen to cut up the work is counterproductive. ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 23:51:47 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 Jan 2014 22:51:47 +0000 Subject: [issue18011] Inconsistency between b32decode() documentation, docstring and code In-Reply-To: <1368951549.72.0.00589705304437.issue18011@psf.upfronthosting.co.za> Message-ID: <1389221507.16.0.85622094674.issue18011@psf.upfronthosting.co.za> R. David Murray added the comment: For future reference, because this patch changed the type of an error, it should not have been applied to a maintenance release (3.3). Since the change has already been released in 3.3.3, it is now better not to revert it. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 8 23:53:14 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jan 2014 22:53:14 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389220212.06.0.282285901223.issue20193@psf.upfronthosting.co.za> Message-ID: <4542497.nvPRRoxZgo@raxxla> Serhiy Storchaka added the comment: I didn't even know for which of the dozens of random issues Larry randomly assigned these modules. And this organization does not look productive. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 00:00:44 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jan 2014 23:00:44 +0000 Subject: [issue18011] Inconsistency between b32decode() documentation, docstring and code In-Reply-To: <1368951549.72.0.00589705304437.issue18011@psf.upfronthosting.co.za> Message-ID: <1389222044.49.0.269332675161.issue18011@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is not incompatible change because b32decode() already raised this type of an error. Third-party code which use b32decode() was either incorrect (if it catches only TypeError or binascii.Error when any of them could raised) or is not broken by this change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 00:02:51 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 Jan 2014 23:02:51 +0000 Subject: [issue18011] Inconsistency between b32decode() documentation, docstring and code In-Reply-To: <1368951549.72.0.00589705304437.issue18011@psf.upfronthosting.co.za> Message-ID: <1389222171.72.0.423974542193.issue18011@psf.upfronthosting.co.za> R. David Murray added the comment: But code could be catching TypeError specifically looking for the alphabet error, since that is how it was documented. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 00:39:30 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 23:39:30 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1389224370.08.0.785741165182.issue20193@psf.upfronthosting.co.za> Larry Hastings added the comment: I did correct that "where is file X" problem; issue #20187 is a meta-issue for the whole Derby, and it has a list of all the issues and what files they map to. I'm sorry that this is not an optimal solution for organization, but it should be workable, and it only has to last us a week or two, and I felt like I was spending enough time trying to organize the Derby as it was. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 00:56:05 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 23:56:05 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1389225365.76.0.699357842618.issue20193@psf.upfronthosting.co.za> Larry Hastings added the comment: > * I have experimented in zlib_decompressobj, and I got good compact > code, but wrong docstring ("decompressobj(wbits=None, zdict=None)"). > Needed a way to specify optional parameters without default Python > values. Correct signature should be something like > "decompressobj([wbits], [zdict])". "decompressobj([wbits], [zdict])" isn't valid Python. "decompressobj(wbits=None, zdict=None)" is; both wbits and zdict are positional-or-keyword parameters with defaults. If you were writing decompressobj() in Python, and you wanted to simulate its argument parsing as closely as possible, you'd write what Argument Clinic generated. You shouldn't use a default of "None" for wbits, though (and Argument Clinic shouldn't have let you). How about_zlib.MAX_WBITS ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 00:56:32 2014 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 08 Jan 2014 23:56:32 +0000 Subject: [issue20153] New-in-3.4 weakref finalizer doc section is already out of date. In-Reply-To: <1389045523.36.0.692306072283.issue20153@psf.upfronthosting.co.za> Message-ID: <1389225392.01.0.35241223466.issue20153@psf.upfronthosting.co.za> Richard Oudkerk added the comment: The following from the docs is wrong: > ... module globals are no longer forced to None during interpreter > shutdown. Actually, in 3.4 module globals *sometimes* get forced to None during interpreter shutdown, so the version the __del__ method can still raise an exception. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 00:57:40 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 23:57:40 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1389225460.29.0.274725194288.issue20172@psf.upfronthosting.co.za> Larry Hastings added the comment: The piecemeal approach sounds fine, but I'm only going to review patches once you post them here. (I'm not sure I can get to reviewing your patch today, but definitely tomorrow.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 00:58:16 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 08 Jan 2014 23:58:16 +0000 Subject: [issue20168] Derby: Convert the _tkinter module to use Argument Clinic In-Reply-To: <1389128639.57.0.613370502446.issue20168@psf.upfronthosting.co.za> Message-ID: <1389225496.17.0.546518486971.issue20168@psf.upfronthosting.co.za> Larry Hastings added the comment: Oh, okay. That sounds fine, and I'm not in a hurry. Please post the patch whenever you're ready, thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 01:02:14 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jan 2014 00:02:14 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1389225734.59.0.766789066851.issue20193@psf.upfronthosting.co.za> Larry Hastings added the comment: > Previous approach is not applicable to compressobj because > Py_buffer can't have default value. Seems as compressobj is > not compatible with Argument Clinic. Then perhaps we can fix Argument Clinic to be compatible. Py_buffer doesn't like default values because they mostly don't make sense. However, I suspect a default value of "None" is fine. I'll sleep on it and hopefully I can come up with something that will work tomorrow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 01:07:23 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jan 2014 00:07:23 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1389226043.76.0.478430825649.issue20172@psf.upfronthosting.co.za> Larry Hastings added the comment: I lied, I just looked at it. You said it was only one function, so it went quickly. It looks totally fine. In fact, Argument Clinic is generating better code than the original! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 01:08:30 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jan 2014 00:08:30 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1389226110.36.0.813573944885.issue20172@psf.upfronthosting.co.za> Larry Hastings added the comment: Oh, and, p.s. I was a Win32 developer for about fifteen years. I don't touch it anymore, but I consider myself still competent to read patches for simple stuff like the registry library. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 01:12:02 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jan 2014 00:12:02 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389226322.5.0.740461204034.issue20189@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 01:52:46 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jan 2014 00:52:46 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1389228766.25.0.118610429629.issue20193@psf.upfronthosting.co.za> Larry Hastings added the comment: I just realized, you're misunderstanding what the first line of the docstring is. When you run help(function_written_in_Python), the first line of the help is the function's signature rendered in text. That's generated by "pydoc", which gets signature information from inspect. Now, it used to be that this didn't work for builtins. pydoc would look at the function, say "I can't get metadata for this function, I'll skip it". And it'd just print the builtin's docstring. Builtins worked around this problem by having their first line *look* like a Python signature. So the user kind of couldn't tell the difference. As part of adding Argument Clinic, I changed this. Now the first line of a docstring is a machine-readable representation of the signature of the function. Internally it gets split off from the docstring--you won't see it if you look at builtin.__doc__. Instead this first line is provided via a new property called __text_signature__. inspect.Signature supports builtins by parsing this string. As it happens, the format of the string happens to look exactly like a Python function definition. Because... it is! inspect.Signature parses the string by passing it in to ast.parse. "decompressobj([wbits], [zdict])" is not legal Python; if you gave that to ast.parse it would reject it. (I tried, with PEP 457, but so far nobody has been interested.) On the other hand, ast.parse is totally happy with "decompressobj(wbits=None, zdict=None)". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 02:35:08 2014 From: report at bugs.python.org (bagrat lazaryan) Date: Thu, 09 Jan 2014 01:35:08 +0000 Subject: [issue20198] xml.etree.ElementTree.ElementTree.write attribute sorting Message-ID: <1389231308.67.0.0933451284696.issue20198@psf.upfronthosting.co.za> New submission from bagrat lazaryan: xml.etree.ElementTree.ElementTree.write method (and, as a derivative, xml.etree.ElementTree.tostring function) sorts attributes in lexical order. while an admissible behavior instead of the randomness inherited from ordinary dict, this prevents a picky user to have her own custom ordering by passing an OrderedDict to Element, SubElement and the like (i guess there are none). that is to say: if ----------------------------------- e = Element("tag", OrderedDict([("a", "a"), ("c", "c"), ("b", "b")])) ----------------------------------- then both ----------------------------------- tostring(e) ElementTree(e).write("xml.xml") ----------------------------------- will result in ----------------------------------- ----------------------------------- while the intention of the user was ----------------------------------- ---------- components: Library (Lib) messages: 207721 nosy: bagratte priority: normal severity: normal status: open title: xml.etree.ElementTree.ElementTree.write attribute sorting type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 02:43:20 2014 From: report at bugs.python.org (bagrat lazaryan) Date: Thu, 09 Jan 2014 01:43:20 +0000 Subject: [issue17390] display python version on idle title bar In-Reply-To: <1362920194.83.0.464215113749.issue17390@psf.upfronthosting.co.za> Message-ID: <1389231800.98.0.571452895876.issue17390@psf.upfronthosting.co.za> Changes by bagrat lazaryan : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 02:54:52 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Thu, 09 Jan 2014 01:54:52 +0000 Subject: [issue20174] Derby #5: Convert 50 sites to Argument Clinic across 3 files In-Reply-To: <1389138461.92.0.709656306175.issue20174@psf.upfronthosting.co.za> Message-ID: <1389232492.41.0.84454254296.issue20174@psf.upfronthosting.co.za> Ryan Smith-Roberts added the comment: Taking a crack at this. socketmodule.h: just a comment, skipping. _functools.c: kind-of skipping, because the relevant functions are not normally directly called (pickle protocol __reduce__ and __setstate__ on partial, __call__ on cmp wrapper). Will add simple docstrings for the pickle protocol handlers though. ---------- nosy: +rmsr _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 03:07:02 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Jan 2014 02:07:02 +0000 Subject: [issue20199] status of module_for_loader and utils._module_to_load Message-ID: <1389233222.57.0.373422642128.issue20199@psf.upfronthosting.co.za> New submission from R. David Murray: The whatsnew currently says that module_for_loader is pending deprecation in favor of utils.module_to_load, but there is no such function. Instead there is a private function utils._module_to_load...even though there is a news entry that claimed that the non-private name was added (but there are no docs for it, nor any associated issue number). So, importlib experts, can you clean up the docs and/or code please? :) ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 207723 nosy: brett.cannon, docs at python, eric.snow, r.david.murray priority: normal severity: normal stage: needs patch status: open title: status of module_for_loader and utils._module_to_load type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 03:17:50 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Thu, 09 Jan 2014 02:17:50 +0000 Subject: [issue20200] Argument Clinic howto: custom self_converter example broken Message-ID: <1389233870.77.0.302352935939.issue20200@psf.upfronthosting.co.za> New submission from Ryan Smith-Roberts: The custom converter declaration is wrapped with [clinic input] when it should be [python input]. Patch attached. ---------- files: argument_clinic_docfix.patch keywords: patch messages: 207724 nosy: rmsr priority: normal severity: normal status: open title: Argument Clinic howto: custom self_converter example broken Added file: http://bugs.python.org/file33371/argument_clinic_docfix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 04:34:16 2014 From: report at bugs.python.org (Zachary Ware) Date: Thu, 09 Jan 2014 03:34:16 +0000 Subject: [issue20200] Argument Clinic howto: custom self_converter example broken In-Reply-To: <1389233870.77.0.302352935939.issue20200@psf.upfronthosting.co.za> Message-ID: <1389238456.74.0.309791094323.issue20200@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, larry stage: -> patch review versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 04:58:32 2014 From: report at bugs.python.org (Eric Snow) Date: Thu, 09 Jan 2014 03:58:32 +0000 Subject: [issue20199] status of module_for_loader and utils._module_to_load In-Reply-To: <1389233222.57.0.373422642128.issue20199@psf.upfronthosting.co.za> Message-ID: <1389239912.6.0.393562391681.issue20199@psf.upfronthosting.co.za> Eric Snow added the comment: utils.module_to_load() has been removed (it was introduced in 3.4) and module_for_loader() remains deprecated. The import machinery now does the work that both functions did, rendering them unnecessary. I guess I failed to take a look at whatsnew relative all the PEP 451 changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 05:12:42 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Thu, 09 Jan 2014 04:12:42 +0000 Subject: [issue20174] Derby #5: Convert 50 sites to Argument Clinic across 3 files In-Reply-To: <1389138461.92.0.709656306175.issue20174@psf.upfronthosting.co.za> Message-ID: <1389240762.4.0.0563832629272.issue20174@psf.upfronthosting.co.za> Changes by Ryan Smith-Roberts : ---------- keywords: +patch Added file: http://bugs.python.org/file33372/argument_clinic_functools.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 05:39:56 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Thu, 09 Jan 2014 04:39:56 +0000 Subject: [issue20201] Argument Clinic: rwbuffer support broken Message-ID: <1389242396.52.0.166931579233.issue20201@psf.upfronthosting.co.za> New submission from Ryan Smith-Roberts: Following the howto's instructions on the new syntax for the 'w*' argument, one gets an exception: ... File "Tools/clinic/clinic.py", line 1780, in converter_init elif types == (bytearray_type | rwuffer_type): NameError: global name 'rwuffer_type' is not defined Easy fix, patch attached. ---------- files: argument_clinic_rwbuffer.patch keywords: patch messages: 207726 nosy: rmsr priority: normal severity: normal status: open title: Argument Clinic: rwbuffer support broken Added file: http://bugs.python.org/file33373/argument_clinic_rwbuffer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 05:40:49 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Thu, 09 Jan 2014 04:40:49 +0000 Subject: [issue20201] Argument Clinic: rwbuffer support broken In-Reply-To: <1389242396.52.0.166931579233.issue20201@psf.upfronthosting.co.za> Message-ID: <1389242449.81.0.925905546019.issue20201@psf.upfronthosting.co.za> Ryan Smith-Roberts added the comment: I'm such a goofball, how about some bug metadata ---------- components: +Build type: -> compile error versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 07:13:57 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 09 Jan 2014 06:13:57 +0000 Subject: [issue20201] Argument Clinic: rwbuffer support broken In-Reply-To: <1389242396.52.0.166931579233.issue20201@psf.upfronthosting.co.za> Message-ID: <1389248037.03.0.645346757527.issue20201@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 07:47:42 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Thu, 09 Jan 2014 06:47:42 +0000 Subject: [issue20202] ArgumentClinic howto: document change in Py_buffer lifecycle management Message-ID: <1389250062.45.0.978565094508.issue20202@psf.upfronthosting.co.za> New submission from Ryan Smith-Roberts: Almost didn't catch that PyBuffer_Release isn't needed. Also we need a verb/adjective for applying AC. Cure? "zlibmodule has already been cured." ---------- assignee: docs at python components: Documentation messages: 207728 nosy: docs at python, larry, rmsr priority: normal severity: normal status: open title: ArgumentClinic howto: document change in Py_buffer lifecycle management versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 08:28:42 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jan 2014 07:28:42 +0000 Subject: [issue20168] Derby: Convert the _tkinter module to use Argument Clinic In-Reply-To: <1389128639.57.0.613370502446.issue20168@psf.upfronthosting.co.za> Message-ID: <1389252522.26.0.202109528287.issue20168@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Argument Clinic generates invalid code for optional parameter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 08:50:21 2014 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 09 Jan 2014 07:50:21 +0000 Subject: [issue20198] xml.etree.ElementTree.ElementTree.write attribute sorting In-Reply-To: <1389231308.67.0.0933451284696.issue20198@psf.upfronthosting.co.za> Message-ID: <1389253821.86.0.564082500362.issue20198@psf.upfronthosting.co.za> Stefan Behnel added the comment: IMHO, it makes sense to support this. My intuition tells me that lxml also handles this as expected, by accident through iteration. Not sure how to do this correctly in ET, though. Special case dict? Or special case OrderedDict? Both would leave some reasonable use cases uncovered, e.g. dict subclasses that do not impact iteration, and self-implemented OrderedDict-like types. And being too broad in the special casing will certainly kill someone's doctests somewhere... Given that OrderedDict is the one way to do this in recent Python versions, I guess it would be reasonable to special case on that type. ---------- nosy: +eli.bendersky, scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 08:53:55 2014 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 09 Jan 2014 07:53:55 +0000 Subject: [issue20198] xml.etree.ElementTree.ElementTree.write attribute sorting In-Reply-To: <1389253821.86.0.564082500362.issue20198@psf.upfronthosting.co.za> Message-ID: <52CE5592.7080209@users.sourceforge.net> Stefan Behnel added the comment: > My intuition tells me that lxml also handles this as expected, by accident through iteration. And, obviously, it doesn't. It sorts, too. :) I'm ok with switching for both libraries. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 09:03:20 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Thu, 09 Jan 2014 08:03:20 +0000 Subject: [issue20203] ArgumentClinic: support middle optional argument Message-ID: <1389254600.21.0.692966775904.issue20203@psf.upfronthosting.co.za> New submission from Ryan Smith-Roberts: socket.sendto is apparently even weirder than addch or range: the optional argument is in the *middle*. Attempting this configuration gets me: Function sendto has an unsupported group configuration. (Unexpected state 5) An expected unexpected configuration? :) ---------- components: Build messages: 207731 nosy: larry, rmsr priority: normal severity: normal status: open title: ArgumentClinic: support middle optional argument type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 09:28:05 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Thu, 09 Jan 2014 08:28:05 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1389256085.36.0.892304749743.issue20173@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Okay, this is my second attempt. I want to get METH_VARGS but I always get METH_O for positional parameters. Is there any way to circumvent this? The documentation does not cover this. ---------- Added file: http://bugs.python.org/file33374/clinic_sha1module_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 10:34:36 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jan 2014 09:34:36 +0000 Subject: [issue20159] Derby #7: Convert 51 sites to Argument Clinic across 3 files -> Derby: Convert the ElementTree module to use Argument Clinic In-Reply-To: <1389086966.47.0.33615845784.issue20159@psf.upfronthosting.co.za> Message-ID: <1389260076.27.0.6618171402.issue20159@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> eli.bendersky dependencies: +Add docstrings for ElementTree module stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 13:47:35 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jan 2014 12:47:35 +0000 Subject: [issue20204] pydocs fails for some C implemented classes Message-ID: <1389271655.86.0.224685657695.issue20204@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: In 3.4 pydoc fails for the TkappType and TkttType names in the _tkinter module. $ ./python -m pydoc _tkinter.TkappType Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/runpy.py", line 189, in _run_module_as_main "__main__", mod_spec) File "/home/serhiy/py/cpython/Lib/runpy.py", line 87, in _run_code exec(code, run_globals) File "/home/serhiy/py/cpython/Lib/pydoc.py", line 2593, in cli() File "/home/serhiy/py/cpython/Lib/pydoc.py", line 2558, in cli help.help(arg) File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1840, in help elif request: doc(request, 'Help on %s:', output=self._output) File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1578, in doc pager(render_doc(thing, title, forceload)) File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1555, in render_doc module = inspect.getmodule(object) File "/home/serhiy/py/cpython/Lib/inspect.py", line 610, in getmodule file = getabsfile(object, _filename) File "/home/serhiy/py/cpython/Lib/inspect.py", line 593, in getabsfile _filename = getsourcefile(object) or getfile(object) File "/home/serhiy/py/cpython/Lib/inspect.py", line 569, in getsourcefile filename = getfile(object) File "/home/serhiy/py/cpython/Lib/inspect.py", line 519, in getfile object = sys.modules.get(object.__module__) AttributeError: __module__ And same for _tkinter.TkttType. This issue can be easy fixed for the _tkinter module, but general solution is needed, because pydoc in 3.4 still can be broken for third-party code. ---------- files: tkinter_typespecs.patch keywords: 3.4regression, patch messages: 207733 nosy: serhiy.storchaka priority: normal severity: normal status: open title: pydocs fails for some C implemented classes type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file33375/tkinter_typespecs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 13:51:24 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jan 2014 12:51:24 +0000 Subject: [issue20204] pydocs fails for some C implemented classes In-Reply-To: <1389271655.86.0.224685657695.issue20204@psf.upfronthosting.co.za> Message-ID: <1389271884.0.0.597936641791.issue20204@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +brett.cannon, eric.snow, ncoghlan priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 13:52:32 2014 From: report at bugs.python.org (Stefano Lattarini) Date: Thu, 09 Jan 2014 12:52:32 +0000 Subject: [issue20165] unittest TestResult wasSuccessful returns True when there are unexpected successes In-Reply-To: <1389122721.74.0.155844601606.issue20165@psf.upfronthosting.co.za> Message-ID: <1389271952.33.0.914436814798.issue20165@psf.upfronthosting.co.za> Stefano Lattarini added the comment: Since I too was bitten by this issue, I'd like to support Gregory's request, and report my rationale for changing the current behaviour. With the current behaviour, we could see (and I *have* seen) scenarios like this: 1. A test exposing a known bug is written, and the test is marked as "expected failure". 2. Some refactoring and code improvements follow. 3. They improve the overall behaviour/correctness of the program or library under test, to the point of fixing the bug "behind the scenes". 4. The developer doesn't notice the fix though, since the testing framework doesn't warn him "strongly enough" of the fact that the test marked as expected failure has begun to pass. (To reiterate, the current behaviour of just printing a warning saying "some test passed unexpectedly" on the standard output is not good enough of a warning; it's easy to miss, and worse, it's *certain* that it will be missed if the tests are run by some CI systems or a similar wrapper system -- those would only report failures due to non-zero exit statuses.) 5. Without noticing that the issue has been fixed, the developer does some further changes, which again re-introduce the bug, or a similar one that the test still marked as "expected failure" could easily catch. 6. That test starts to fail again; but since it has remained marked as "expected failure" all along, the fact is not reported to the developer in any way. So the bug has managed to sneak back in, unnoticed. In addition to this rationale, another (weaker) reason to change the existing behaviour would be the "principle of least surprise". Among other widely used testing framework (for python, or language-agnostic) many of those which support the concept of "expected failure" will throw hard errors by default when a test marked as expected failure starts to pass; among these are: * Python libs: - py.test (http://pytest.org) - Nose (https://pypi.python.org/pypi/nose/1.3.0) * Language-agnostic protocols/frameworks: - the TAP protocol (the standard in the Perl world) (http://en.wikipedia.org/wiki/Test_Anything_Protocol) - the Automake "Simple Tests" framework (http://www.gnu.org/software/automake/manual/html_node/Tests.html) ---------- nosy: +slattarini _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 13:54:25 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Jan 2014 12:54:25 +0000 Subject: [issue20078] zipfile - ZipExtFile.read goes into 100% CPU infinite loop on maliciously binary edited zips In-Reply-To: <1388110280.6.0.508484621949.issue20078@psf.upfronthosting.co.za> Message-ID: <3f0S2S2bzRz7LjM@mail.python.org> Roundup Robot added the comment: New changeset 0cf1defd5ac4 by Serhiy Storchaka in branch '3.3': Issue #20078: Reading malformed zipfiles no longer hangs with 100% CPU http://hg.python.org/cpython/rev/0cf1defd5ac4 New changeset 79ea4ce431b1 by Serhiy Storchaka in branch 'default': Issue #20078: Reading malformed zipfiles no longer hangs with 100% CPU http://hg.python.org/cpython/rev/79ea4ce431b1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 14:18:49 2014 From: report at bugs.python.org (=?utf-8?q?Stefan_M=C3=BCller?=) Date: Thu, 09 Jan 2014 13:18:49 +0000 Subject: [issue20205] inspect.getsource(), P302 loader and '<..>' filenames Message-ID: <1389273529.73.0.188399599981.issue20205@psf.upfronthosting.co.za> New submission from Stefan M?ller: Following situation * python 2.7.6 * module loaded via a PEP302 loader. * the loader has get_source(fullname) * assigns a dummy string as a file: module.__file__ == "" Then inspect.getsource(module) throws IOError: could not get source code I tired to track this down, and it seems to be caused by linecache.updatecache(..) with has if not filename or (filename.startswith('<') and filename.endswith('>')): return [] at the beginning. This seems too restrictive me. Without the 'if' it would try to read the file from disk, and if that fails check if there is a loader, without a loader it returns [], so there would not be any behaviour change for non-loader modules if the 'if' was removed, only an additional disk access. I suggest to remove the 'if'. Workaround: Don't use '<>' for the dummy file name, but I've read somewhere that those '<>' are a convention for such use-cases. ---------- components: Library (Lib) messages: 207736 nosy: stefan.mueller priority: normal severity: normal status: open title: inspect.getsource(), P302 loader and '<..>' filenames type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 15:21:58 2014 From: report at bugs.python.org (Andras Timar) Date: Thu, 09 Jan 2014 14:21:58 +0000 Subject: [issue20206] email quoted-printable encoding issue Message-ID: <1389277318.78.0.594676720592.issue20206@psf.upfronthosting.co.za> New submission from Andras Timar: Try this sample script: # coding=utf-8 import email import email.charset import email.message c = email.charset.Charset('utf-8') c.body_encoding = email.charset.QP m = email.message.Message() m.set_payload("This is a Greek letter upsilon: ?", c) print(m.as_string()) Actual result: "This is a Greek letter upsilon: =CF" Expected result: "This is a Greek letter upsilon: =CF=85" ---------- components: Library (Lib) messages: 207737 nosy: timar priority: normal severity: normal status: open title: email quoted-printable encoding issue type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 15:40:20 2014 From: report at bugs.python.org (Milap Bhojak) Date: Thu, 09 Jan 2014 14:40:20 +0000 Subject: [issue20206] email quoted-printable encoding issue In-Reply-To: <1389277318.78.0.594676720592.issue20206@psf.upfronthosting.co.za> Message-ID: <1389278420.93.0.829201476978.issue20206@psf.upfronthosting.co.za> Milap Bhojak added the comment: hope it will fix that issue ---------- nosy: +milap.py versions: +Python 2.7 -Python 3.3 Added file: http://bugs.python.org/file33376/email.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 15:59:45 2014 From: report at bugs.python.org (=?utf-8?q?Martin_H=C3=A4cker?=) Date: Thu, 09 Jan 2014 14:59:45 +0000 Subject: [issue20190] dict() in dict(foo='bar').keys() raises In-Reply-To: <1389188100.33.0.555885401078.issue20190@psf.upfronthosting.co.za> Message-ID: <1389279585.14.0.691413197858.issue20190@psf.upfronthosting.co.za> Martin H?cker added the comment: Sorry, I got the title wrong on the first try. (Already corrected). I think the problem is that the API of dict.keys() is surprising. One gets back something that behaves like a list, the name 'keys' suggests that it is a list and for lists there is no requirement that their containing items need to be hasheable. Now of course it makes no sense to check if a dict (not washable because it's mutable) is a key in a dictionary - but, the fact that keys() returns something else than a list is surprising and shouldn't be so. (I suspect it's a performance enhancement). Why this shouldn't be so? I think it's because of composeability. If I expect something list like from an API I want to be able to hand it around in my application to everywhere where a list is allowed, and I certainly don't want to check beforehand if something I want to check is included in that list is hasheable for a specific subset of those lists. Thats why I think it's a really bad idea to change the behavior of dict.keys() _not_ to return a list or something that at least behaves the same way as a list. Should this have been done for performance reasons, it would be easy to say in that list that anything that is not hasheable cannot be in that list and therefore to return False in that case. Contract fulfilled. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 16:07:58 2014 From: report at bugs.python.org (Meador Inge) Date: Thu, 09 Jan 2014 15:07:58 +0000 Subject: [issue20178] Derby #9: Convert 52 sites to Argument Clinic across 11 files In-Reply-To: <1389140078.91.0.720761635456.issue20178@psf.upfronthosting.co.za> Message-ID: <1389280078.73.0.43901328693.issue20178@psf.upfronthosting.co.za> Meador Inge added the comment: I will pick this one up. ---------- assignee: -> meador.inge nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 16:32:24 2014 From: report at bugs.python.org (Alan Hourihane) Date: Thu, 09 Jan 2014 15:32:24 +0000 Subject: [issue19036] setlocale fails due to locale.h being wrapped up in LANGINFO check. In-Reply-To: <1379347357.79.0.813786173843.issue19036@psf.upfronthosting.co.za> Message-ID: <1389281544.95.0.531073128219.issue19036@psf.upfronthosting.co.za> Changes by Alan Hourihane : ---------- resolution: -> remind _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 16:33:09 2014 From: report at bugs.python.org (Alan Hourihane) Date: Thu, 09 Jan 2014 15:33:09 +0000 Subject: [issue19346] Build fails when there are no shared extensions to be built In-Reply-To: <1382442448.32.0.170952369524.issue19346@psf.upfronthosting.co.za> Message-ID: <1389281589.93.0.0342083640035.issue19346@psf.upfronthosting.co.za> Alan Hourihane added the comment: Anyone ? ---------- resolution: -> remind _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 16:34:11 2014 From: report at bugs.python.org (Alan Hourihane) Date: Thu, 09 Jan 2014 15:34:11 +0000 Subject: [issue19348] Building _testcapimodule as a builtin results in compile error In-Reply-To: <1382442846.46.0.759535198419.issue19348@psf.upfronthosting.co.za> Message-ID: <1389281651.19.0.972976161541.issue19348@psf.upfronthosting.co.za> Alan Hourihane added the comment: Anyone ? ---------- resolution: -> remind _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 16:37:10 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Jan 2014 15:37:10 +0000 Subject: [issue20205] inspect.getsource(), P302 loader and '<..>' filenames In-Reply-To: <1389273529.73.0.188399599981.issue20205@psf.upfronthosting.co.za> Message-ID: <1389281830.49.0.292640868412.issue20205@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 17:16:49 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 09 Jan 2014 16:16:49 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389284209.33.0.863694519031.issue20189@psf.upfronthosting.co.za> Stefan Krah added the comment: Thanks, this is working here for the parameters. Is there a way to specify the return annotation manually in the docstring? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 17:16:51 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Jan 2014 16:16:51 +0000 Subject: [issue20206] email quoted-printable encoding issue In-Reply-To: <1389277318.78.0.594676720592.issue20206@psf.upfronthosting.co.za> Message-ID: <1389284211.38.0.123413586003.issue20206@psf.upfronthosting.co.za> R. David Murray added the comment: This is a bug in quoprimime.body_encode. If you put a newline on the end of your string, it will work as expected. The patch in issue 5803 does not have the bug, so I'll probably just apply that to both 3.3 and 3.4. ---------- components: +email dependencies: +email/quoprimime: encode and decode are very slow on large messages nosy: +barry, r.david.murray versions: +Python 3.3, Python 3.4 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 17:24:39 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 09 Jan 2014 16:24:39 +0000 Subject: [issue19036] setlocale fails due to locale.h being wrapped up in LANGINFO check. In-Reply-To: <1379347357.79.0.813786173843.issue19036@psf.upfronthosting.co.za> Message-ID: <1389284679.85.0.904095226753.issue19036@psf.upfronthosting.co.za> Stefan Krah added the comment: The patch looks correct to me. locale.h is at least C99 (I don't have the earlier standards). ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 17:34:04 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jan 2014 16:34:04 +0000 Subject: [issue20190] dict() in dict(foo='bar').keys() raises In-Reply-To: <1389279585.14.0.691413197858.issue20190@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: dict.keys() has been changed 5 years ago, when Python 3 was created. dict.keys() is now a nice read-only view of dictionary keys. When the dictionary is updated, the view is also updated. See the documentation: http://docs.python.org/3/library/stdtypes.html#dict-views The view is not a sequence: isinstance({}.keys(), collections.Sequence) is False. If you want a list, you must write list(dict.keys()) > Now of course it makes no sense to check if a dict (not washable because it's mutable) is a key in a dictionary I still don't understand your problem. What is your usecase? Yes, Python 3 is a new language. It's a better language in my opinion, because it now has the good behaviour. > Should this have been done for performance reasons, Yes, avoiding a temporary list is more efficient in "for k in dict: ..." and "for k, v in dict.items(): ...". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 17:42:28 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Jan 2014 16:42:28 +0000 Subject: [issue18960] First line can be executed twice In-Reply-To: <1378559493.77.0.649785663787.issue18960@psf.upfronthosting.co.za> Message-ID: <3f0Y5b4Q3Fz7Ls7@mail.python.org> Roundup Robot added the comment: New changeset 1bdcaf6c0eb5 by Serhiy Storchaka in branch '3.3': Issue #18960: Fix bugs with Python source code encoding in the second line. http://hg.python.org/cpython/rev/1bdcaf6c0eb5 New changeset 04c05e408cbd by Serhiy Storchaka in branch 'default': Issue #18960: Fix bugs with Python source code encoding in the second line. http://hg.python.org/cpython/rev/04c05e408cbd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 17:48:05 2014 From: report at bugs.python.org (Alex Gaynor) Date: Thu, 09 Jan 2014 16:48:05 +0000 Subject: [issue20207] Disable SSLv2 in Python 2.x Message-ID: <1389286085.44.0.640334918111.issue20207@psf.upfronthosting.co.za> New submission from Alex Gaynor: SSLv2 has numerous security issues, and thus is in limited use on the web. Continuing to allow SSLv2 handshakes only serves to limit security. ---------- components: Library (Lib) messages: 207748 nosy: alex priority: normal severity: normal status: open title: Disable SSLv2 in Python 2.x versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 17:48:44 2014 From: report at bugs.python.org (Donald Stufft) Date: Thu, 09 Jan 2014 16:48:44 +0000 Subject: [issue20207] Disable SSLv2 in Python 2.x In-Reply-To: <1389286085.44.0.640334918111.issue20207@psf.upfronthosting.co.za> Message-ID: <1389286124.84.0.751001593404.issue20207@psf.upfronthosting.co.za> Donald Stufft added the comment: +1 ---------- nosy: +dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 17:51:09 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jan 2014 16:51:09 +0000 Subject: [issue20207] Disable SSLv2 in Python 2.x In-Reply-To: <1389286085.44.0.640334918111.issue20207@psf.upfronthosting.co.za> Message-ID: <1389286269.25.0.603010000254.issue20207@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Please qualify the request a bit: do you mean something should be done in the ssl module? One solution is to add OP_NO_SSLv2 when the user asks for a PROTOCOL_SSLv23 socket. Is it what you mean? ---------- nosy: +pitrou type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 17:51:42 2014 From: report at bugs.python.org (Alex Gaynor) Date: Thu, 09 Jan 2014 16:51:42 +0000 Subject: [issue20207] Disable SSLv2 in Python 2.x In-Reply-To: <1389286085.44.0.640334918111.issue20207@psf.upfronthosting.co.za> Message-ID: <1389286302.51.0.639880294541.issue20207@psf.upfronthosting.co.za> Alex Gaynor added the comment: Yes, OP_NO_SSLv2 should be used by default. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 18:00:07 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jan 2014 17:00:07 +0000 Subject: [issue20207] Disable SSLv2 in Python 2.x In-Reply-To: <1389286085.44.0.640334918111.issue20207@psf.upfronthosting.co.za> Message-ID: <1389286807.85.0.0723074221338.issue20207@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch. Can someone try it with a non-patched OpenSSL? (e.g. OS X) ---------- keywords: +patch Added file: http://bugs.python.org/file33377/no_sslv2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 18:00:52 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jan 2014 17:00:52 +0000 Subject: [issue20207] Disable SSLv2 in Python 2.x In-Reply-To: <1389286085.44.0.640334918111.issue20207@psf.upfronthosting.co.za> Message-ID: <1389286852.92.0.959882329338.issue20207@psf.upfronthosting.co.za> Antoine Pitrou added the comment: (by trying, I mean at least "./python -m test.regrtest -unetwork -v test_ssl") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 18:01:53 2014 From: report at bugs.python.org (Christian Heimes) Date: Thu, 09 Jan 2014 17:01:53 +0000 Subject: [issue20207] Disable SSLv2 in Python 2.x In-Reply-To: <1389286085.44.0.640334918111.issue20207@psf.upfronthosting.co.za> Message-ID: <1389286913.6.0.657020379126.issue20207@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 18:03:11 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jan 2014 17:03:11 +0000 Subject: [issue20207] Disable SSLv2 in Python 2.x In-Reply-To: <1389286085.44.0.640334918111.issue20207@psf.upfronthosting.co.za> Message-ID: <1389286991.9.0.639014867696.issue20207@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Note that this probably would have to be applied to 3.x too, for consistency. ---------- versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 18:07:54 2014 From: report at bugs.python.org (Alex Gaynor) Date: Thu, 09 Jan 2014 17:07:54 +0000 Subject: [issue20207] Disable SSLv2 in Python 2.x In-Reply-To: <1389286085.44.0.640334918111.issue20207@psf.upfronthosting.co.za> Message-ID: <1389287274.84.0.889105583709.issue20207@psf.upfronthosting.co.za> Alex Gaynor added the comment: I can confirm the tests pass on OS X and it's possible to open a connection to howsmyssl.com ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 18:10:37 2014 From: report at bugs.python.org (Brett Cannon) Date: Thu, 09 Jan 2014 17:10:37 +0000 Subject: [issue20208] Clarify some things in porting HOWTO Message-ID: <1389287437.04.0.882737818643.issue20208@psf.upfronthosting.co.za> New submission from Brett Cannon: Reported on my G+ share of the latest reworking: """ The only part I found confusing is when you first introduce "from _future_ import unicode_literals" --- it looks like you forgot to explain what it does. It turns out that you explain it somewhat two paragraphs below it, so maybe you can just move this down a bit? Maybe "bytes literals" section should be called "Bytes and unicode literals" or something and move the "unicode_literals" line in there. """ """ The only issue I noticed is that "Eliminate -3 Warnings" section still mentions 2to3 before it's even introduced.? """ ---------- assignee: brett.cannon components: Documentation messages: 207756 nosy: brett.cannon priority: normal severity: normal status: open title: Clarify some things in porting HOWTO versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 18:10:46 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jan 2014 17:10:46 +0000 Subject: [issue18960] First line can be executed twice In-Reply-To: <1378559493.77.0.649785663787.issue18960@psf.upfronthosting.co.za> Message-ID: <1389287446.85.0.145933343748.issue18960@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Now traceback test is failed. http://buildbot.python.org/all/builders/AMD64%20Ubuntu%20LTS%203.3/builds/1358/steps/test/logs/stdio ====================================================================== FAIL: test_encoded_file (test.test_traceback.SyntaxTracebackCases) ---------------------------------------------------------------------- Traceback (most recent call last): File "/opt/python/3.3.langa-ubuntu/build/Lib/test/test_traceback.py", line 146, in test_encoded_file text, charset, 4) File "/opt/python/3.3.langa-ubuntu/build/Lib/test/test_traceback.py", line 129, in do_test stdout[1], lineno)) AssertionError: 'line 4' not found in ' File "@test_6376_tmp", line 3, in ' : Invalid line number: ' File "@test_6376_tmp", line 3, in ' instead of 4 ---------------------------------------------------------------------- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 18:14:56 2014 From: report at bugs.python.org (Dmitry Shachnev) Date: Thu, 09 Jan 2014 17:14:56 +0000 Subject: [issue20208] Clarify some things in porting HOWTO In-Reply-To: <1389287437.04.0.882737818643.issue20208@psf.upfronthosting.co.za> Message-ID: <1389287696.85.0.867611158345.issue20208@psf.upfronthosting.co.za> Changes by Dmitry Shachnev : ---------- nosy: +mitya57 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 18:15:29 2014 From: report at bugs.python.org (Brian Morrow) Date: Thu, 09 Jan 2014 17:15:29 +0000 Subject: [issue20175] Derby #6: Convert 50 sites to Argument Clinic across 8 files In-Reply-To: <1389138499.96.0.517173661563.issue20175@psf.upfronthosting.co.za> Message-ID: <1389287729.61.0.595118247527.issue20175@psf.upfronthosting.co.za> Changes by Brian Morrow : ---------- nosy: +bmorrow92 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 18:15:41 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jan 2014 17:15:41 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389287741.2.0.818034235012.issue20189@psf.upfronthosting.co.za> Larry Hastings added the comment: Yes, it's just Python syntax, so you'd use "->". However, you are not permitted to according to PEP 8: "The Python standard library will not use function annotations as that would result in a premature commitment to a particular annotation style." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 18:21:13 2014 From: report at bugs.python.org (Alex Gaynor) Date: Thu, 09 Jan 2014 17:21:13 +0000 Subject: [issue20207] Disable SSLv2 in Python 2.x In-Reply-To: <1389286085.44.0.640334918111.issue20207@psf.upfronthosting.co.za> Message-ID: <1389288073.12.0.125266405441.issue20207@psf.upfronthosting.co.za> Alex Gaynor added the comment: I'm not sure this is needed on Python 3, it already has: http://hg.python.org/cpython/file/default/Lib/ssl.py#l388 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 18:22:04 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jan 2014 17:22:04 +0000 Subject: [issue20207] Disable SSLv2 in Python 2.x In-Reply-To: <1389288073.12.0.125266405441.issue20207@psf.upfronthosting.co.za> Message-ID: <1389288120.2278.5.camel@fsol> Antoine Pitrou added the comment: > I'm not sure this is needed on Python 3, it already has: > http://hg.python.org/cpython/file/default/Lib/ssl.py#l388 It doesn't get executed when you create a SSLContext directly, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 18:22:37 2014 From: report at bugs.python.org (Hynek Schlawack) Date: Thu, 09 Jan 2014 17:22:37 +0000 Subject: [issue20207] Disable SSLv2 in Python 2.x In-Reply-To: <1389286085.44.0.640334918111.issue20207@psf.upfronthosting.co.za> Message-ID: <1389288157.81.0.888984304547.issue20207@psf.upfronthosting.co.za> Hynek Schlawack added the comment: I?m +1 too since supporting it serves no other purpose then enabling downgrade attacks. Shipping a client with SSL 2 on is nothing short a security bug. ---------- nosy: +hynek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 18:23:59 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jan 2014 17:23:59 +0000 Subject: [issue20209] Deprecate PROTOCOL_SSLv2 Message-ID: <1389288239.29.0.63100261927.issue20209@psf.upfronthosting.co.za> New submission from Antoine Pitrou: It sounds like we may deprecate PROTOCOL_SSLv2 in 3.5. ---------- components: Library (Lib) messages: 207762 nosy: christian.heimes, giampaolo.rodola, janssen, pitrou priority: low severity: normal status: open title: Deprecate PROTOCOL_SSLv2 type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 18:34:20 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jan 2014 17:34:20 +0000 Subject: [issue20209] Deprecate PROTOCOL_SSLv2 In-Reply-To: <1389288239.29.0.63100261927.issue20209@psf.upfronthosting.co.za> Message-ID: <1389288860.74.0.577452022525.issue20209@psf.upfronthosting.co.za> STINNER Victor added the comment: See also issue #20207. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 18:54:45 2014 From: report at bugs.python.org (Brian Morrow) Date: Thu, 09 Jan 2014 17:54:45 +0000 Subject: [issue20175] Derby #6: Convert 50 sites to Argument Clinic across 8 files In-Reply-To: <1389138499.96.0.517173661563.issue20175@psf.upfronthosting.co.za> Message-ID: <1389290085.08.0.427492112994.issue20175@psf.upfronthosting.co.za> Brian Morrow added the comment: I'll gladly take this bundle. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 19:14:16 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Jan 2014 18:14:16 +0000 Subject: [issue18960] First line can be executed twice In-Reply-To: <1378559493.77.0.649785663787.issue18960@psf.upfronthosting.co.za> Message-ID: <3f0b7W3gFSz7Ljw@mail.python.org> Roundup Robot added the comment: New changeset 875a514671dd by Serhiy Storchaka in branch '3.3': Do not reset the line number because we already set file position to correct http://hg.python.org/cpython/rev/875a514671dd New changeset 2af308f79727 by Serhiy Storchaka in branch 'default': Do not reset the line number because we already set file position to correct http://hg.python.org/cpython/rev/2af308f79727 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 19:18:37 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jan 2014 18:18:37 +0000 Subject: [issue20205] inspect.getsource(), P302 loader and '<..>' filenames In-Reply-To: <1389273529.73.0.188399599981.issue20205@psf.upfronthosting.co.za> Message-ID: <1389291517.76.0.221925027939.issue20205@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There would be behavior change if file '' exists. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 19:20:51 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jan 2014 18:20:51 +0000 Subject: [issue20078] zipfile - ZipExtFile.read goes into 100% CPU infinite loop on maliciously binary edited zips In-Reply-To: <1388110280.6.0.508484621949.issue20078@psf.upfronthosting.co.za> Message-ID: <1389291651.71.0.437821909357.issue20078@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Nandiya for your report. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 19:25:17 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jan 2014 18:25:17 +0000 Subject: [issue20207] Disable SSLv2 in Python 2.x In-Reply-To: <1389286085.44.0.640334918111.issue20207@psf.upfronthosting.co.za> Message-ID: <1389291917.31.0.0184897566654.issue20207@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 19:26:32 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jan 2014 18:26:32 +0000 Subject: [issue20207] Disable SSLv2 in Python 2.x In-Reply-To: <1389286085.44.0.640334918111.issue20207@psf.upfronthosting.co.za> Message-ID: <1389291992.65.0.870228713997.issue20207@psf.upfronthosting.co.za> STINNER Victor added the comment: > Here is a patch. Can someone try it with a non-patched OpenSSL? (e.g. OS X) How can I test that SSLv2 is disabled? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 19:48:19 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 09 Jan 2014 18:48:19 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389287741.2.0.818034235012.issue20189@psf.upfronthosting.co.za> Message-ID: <20140109184818.GA24577@sleipnir.bytereef.org> Stefan Krah added the comment: > Yes, it's just Python syntax, so you'd use "->". I tried that, but it didn't filter through to inspect.signature(). > However, you are not permitted to according to PEP 8: Ah, too bad. Return annotations are nice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 19:50:06 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jan 2014 18:50:06 +0000 Subject: [issue19804] test_uuid.TestUUID.test_find_mac() fails In-Reply-To: <1385521168.13.0.486814911092.issue19804@psf.upfronthosting.co.za> Message-ID: <1389293406.41.0.963878235547.issue19804@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Perhaps it would be better just use other executable (it is not ran in this test, just checked that it exists). Bohuslav, what is a content of your /sbin and /usr/sbin? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 19:52:19 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Jan 2014 18:52:19 +0000 Subject: [issue20207] Disable SSLv2 in Python 2.x In-Reply-To: <1389286085.44.0.640334918111.issue20207@psf.upfronthosting.co.za> Message-ID: <3f0bzQ3Nntz7Lk6@mail.python.org> Roundup Robot added the comment: New changeset 163c09041280 by Antoine Pitrou in branch '2.7': Issue #20207: Always disable SSLv2 except when PROTOCOL_SSLv2 is explicitly asked for. http://hg.python.org/cpython/rev/163c09041280 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 19:58:35 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Jan 2014 18:58:35 +0000 Subject: [issue20205] inspect.getsource(), P302 loader and '<..>' filenames In-Reply-To: <1389273529.73.0.188399599981.issue20205@psf.upfronthosting.co.za> Message-ID: <1389293915.3.0.988927077542.issue20205@psf.upfronthosting.co.za> R. David Murray added the comment: Maybe the logic needs to be reordered: look for a loader first, before looking for a file on disk. It seems to me the current lookup order might itself be a bug. Note that the code is the same in python3, so the issue exists there as well. ---------- nosy: +brett.cannon, eric.snow versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 20:00:44 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Jan 2014 19:00:44 +0000 Subject: [issue20209] Deprecate PROTOCOL_SSLv2 In-Reply-To: <1389288239.29.0.63100261927.issue20209@psf.upfronthosting.co.za> Message-ID: <1389294044.55.0.955624698931.issue20209@psf.upfronthosting.co.za> R. David Murray added the comment: Why not in 3.4? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 20:01:16 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jan 2014 19:01:16 +0000 Subject: [issue20209] Deprecate PROTOCOL_SSLv2 In-Reply-To: <1389288239.29.0.63100261927.issue20209@psf.upfronthosting.co.za> Message-ID: <1389294076.41.0.650027953267.issue20209@psf.upfronthosting.co.za> Antoine Pitrou added the comment: It sounds a bit too late, although that would be Larry's call. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 20:02:43 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Jan 2014 19:02:43 +0000 Subject: [issue20209] Deprecate PROTOCOL_SSLv2 In-Reply-To: <1389288239.29.0.63100261927.issue20209@psf.upfronthosting.co.za> Message-ID: <1389294163.48.0.0158803419867.issue20209@psf.upfronthosting.co.za> R. David Murray added the comment: I don't see why a deprecation would be late, since we haven't hit RC yet. A deprecation doesn't change the API. But yes, it is Larry's call. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 20:09:12 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Jan 2014 19:09:12 +0000 Subject: [issue20207] Disable SSLv2 in Python 2.x In-Reply-To: <1389286085.44.0.640334918111.issue20207@psf.upfronthosting.co.za> Message-ID: <3f0cLv2Zrwz7LjR@mail.python.org> Roundup Robot added the comment: New changeset 613b403ca9f1 by Antoine Pitrou in branch '3.3': Issue #20207: Always disable SSLv2 except when PROTOCOL_SSLv2 is explicitly asked for. http://hg.python.org/cpython/rev/613b403ca9f1 New changeset e02288de43ed by Antoine Pitrou in branch 'default': Issue #20207: Always disable SSLv2 except when PROTOCOL_SSLv2 is explicitly asked for. http://hg.python.org/cpython/rev/e02288de43ed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 20:10:42 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jan 2014 19:10:42 +0000 Subject: [issue20207] Disable SSLv2 in Python 2.x In-Reply-To: <1389286085.44.0.640334918111.issue20207@psf.upfronthosting.co.za> Message-ID: <1389294642.29.0.0733737781077.issue20207@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This should be ok now. Let's hope no buildbots will complain... ---------- resolution: -> fixed stage: -> committed/rejected status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 20:11:59 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jan 2014 19:11:59 +0000 Subject: [issue19965] Non-atomic generation of Include/Python-ast.h and Python/Python-ast.c In-Reply-To: <1386868810.74.0.691786710751.issue19965@psf.upfronthosting.co.za> Message-ID: <1389294719.37.0.966165293697.issue19965@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 20:15:50 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jan 2014 19:15:50 +0000 Subject: [issue20209] Deprecate PROTOCOL_SSLv2 In-Reply-To: <1389288239.29.0.63100261927.issue20209@psf.upfronthosting.co.za> Message-ID: <1389294950.8.0.32130857511.issue20209@psf.upfronthosting.co.za> Larry Hastings added the comment: Would the patch be about as simple as the patch for 2.7 in #20207? Also, #20207 is also marked for 3.4. Either unmark 3.4/3.5 in #20207, or close this bug as a duplicate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 20:16:13 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jan 2014 19:16:13 +0000 Subject: [issue20209] Deprecate PROTOCOL_SSLv2 In-Reply-To: <1389288239.29.0.63100261927.issue20209@psf.upfronthosting.co.za> Message-ID: <1389294973.22.0.215099891313.issue20209@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Those bugs are orthogonal, Larry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 20:17:11 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jan 2014 19:17:11 +0000 Subject: [issue20209] Deprecate PROTOCOL_SSLv2 In-Reply-To: <1389288239.29.0.63100261927.issue20209@psf.upfronthosting.co.za> Message-ID: <1389295031.48.0.849507371009.issue20209@psf.upfronthosting.co.za> Larry Hastings added the comment: Okay, then, can you educate me on what you're proposing here? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 20:19:23 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jan 2014 19:19:23 +0000 Subject: [issue20209] Deprecate PROTOCOL_SSLv2 In-Reply-To: <1389288239.29.0.63100261927.issue20209@psf.upfronthosting.co.za> Message-ID: <1389295163.83.0.756763568713.issue20209@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The ssl module has an attribute named PROTOCOL_SSLv2 that I'm proposing to deprecate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 20:21:13 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jan 2014 19:21:13 +0000 Subject: [issue20209] Deprecate PROTOCOL_SSLv2 In-Reply-To: <1389288239.29.0.63100261927.issue20209@psf.upfronthosting.co.za> Message-ID: <1389295273.64.0.759888056556.issue20209@psf.upfronthosting.co.za> Larry Hastings added the comment: Is there any way to use SSLv2 in 3.4? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 20:22:20 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jan 2014 19:22:20 +0000 Subject: [issue20209] Deprecate PROTOCOL_SSLv2 In-Reply-To: <1389295273.64.0.759888056556.issue20209@psf.upfronthosting.co.za> Message-ID: <1389295338.2278.6.camel@fsol> Antoine Pitrou added the comment: > Is there any way to use SSLv2 in 3.4? Yes, by using PROTOCOL_SSLv2. (you're asking strange questions) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 20:26:06 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jan 2014 19:26:06 +0000 Subject: [issue20209] Deprecate PROTOCOL_SSLv2 In-Reply-To: <1389288239.29.0.63100261927.issue20209@psf.upfronthosting.co.za> Message-ID: <1389295566.51.0.00892024093816.issue20209@psf.upfronthosting.co.za> Larry Hastings added the comment: I don't have a lot of context for this. It sounds like #20207 proposes to remove the ability to use SSLv2 at all. And in the comments Alex Gaynor seems to say that SSLv2 is already disabled in Python 3. If #20207 happens for 3.4, would it still be possible to use SSLv2? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 20:27:26 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jan 2014 19:27:26 +0000 Subject: [issue20209] Deprecate PROTOCOL_SSLv2 In-Reply-To: <1389288239.29.0.63100261927.issue20209@psf.upfronthosting.co.za> Message-ID: <1389295646.17.0.254872638863.issue20209@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > If #20207 happens for 3.4, would it still be possible to use SSLv2? #20207 has already happened for 3.4 and, yes, it's still possible to use SSLv2 (except that many distros also disable SSLv2 in their OpenSSL build). The commit message is quite clear about that: """Issue #20207: Always disable SSLv2 except when PROTOCOL_SSLv2 is explicitly asked for.""" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 20:28:08 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jan 2014 19:28:08 +0000 Subject: [issue20209] Deprecate PROTOCOL_SSLv2 In-Reply-To: <1389288239.29.0.63100261927.issue20209@psf.upfronthosting.co.za> Message-ID: <1389295688.78.0.714386574143.issue20209@psf.upfronthosting.co.za> Antoine Pitrou added the comment: (FTR, Alex's comment mixes up the default settings used by urlopen() with what the ssl module allows to do when invoked directly) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 20:35:59 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jan 2014 19:35:59 +0000 Subject: [issue20209] Deprecate PROTOCOL_SSLv2 In-Reply-To: <1389288239.29.0.63100261927.issue20209@psf.upfronthosting.co.za> Message-ID: <1389296159.7.0.792924767181.issue20209@psf.upfronthosting.co.za> Larry Hastings added the comment: If we removed it completely (which I'm *not* proposing, just gathering data) how many people would it affect? Is there any legitimate reason why some people would want SSLv2? Like "we aren't allowed to upgrade this server" or something. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 20:39:08 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jan 2014 19:39:08 +0000 Subject: [issue19279] UTF-7 to UTF-8 decoding crash In-Reply-To: <1382003736.62.0.288611587107.issue19279@psf.upfronthosting.co.za> Message-ID: <1389296348.34.0.952640605719.issue19279@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Georg, is this issue wort to be fixed in 3.2? If yes, use the patch against 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 20:42:50 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jan 2014 19:42:50 +0000 Subject: [issue1776674] glob.glob inconsistent Message-ID: <1389296570.2.0.513220341472.issue1776674@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 20:47:08 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jan 2014 19:47:08 +0000 Subject: [issue16572] Bad multi-inheritance support in some libs like threading or multiprocessing In-Reply-To: <1354138508.41.0.9459136379.issue16572@psf.upfronthosting.co.za> Message-ID: <1389296828.05.0.568669077473.issue16572@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> patch review versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 20:50:06 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jan 2014 19:50:06 +0000 Subject: [issue15303] Minor revision to the method in Tkinter In-Reply-To: <1341822350.55.0.995662615633.issue15303@psf.upfronthosting.co.za> Message-ID: <1389297006.29.0.501352069118.issue15303@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 21:29:13 2014 From: report at bugs.python.org (Adam Tomjack) Date: Thu, 09 Jan 2014 20:29:13 +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: <1389299353.59.0.434979224272.issue10740@psf.upfronthosting.co.za> Adam Tomjack added the comment: The proposed patches don't fix the problem. They may well allow DDL in transactions, but that's not the real problem. A database library must *NEVER* implicitly commit or rollback. That's completely insane. >>> import this ... Explicit is better than implicit. If a statement can't be executed in a transaction, then trying to execute such a statement in a transaction is an error. Period. An exception *MUST* be raised. It is wrong to guess that the user really wanted to commit first. >>> import this ... Errors should never pass silently. ... In the face of ambiguity, refuse the temptation to guess. If such an exception is raised, you'll run into the problem exactly once before figuring out that you need to commit or rollback first. You can then change your code to safely and explicitly account for that limitation. This issue is not an enhancement, it's a bug. One might argue that fixing it will break existing code, but it won't. Any affected code is already broken. It's depending on a promised level of safety, and this bug is breaking that promise. It's better to fail noisily and consistently than to usually work, but sometimes silently corrupt data. As is, it's pretty much guaranteed that there is existing code that does DDL expecting to be in a transaction when it isn't. Even a well-tested schema upgrade can fail in production if the data is slightly different that in a testing database. Unique constraints can fail, etc. I frequently use the psycopg2 module and psql command, which get this issue right. They've saved me several times. The current behavior is buggy and should be changed to be correct. There should not merely be an option to enable the correct behavior. There should also be no option to enable the old buggy behavior. It's too dangerous. In general, it's a code-smell to inspect the SQL that's being executed before sending it to the database. The only reason I can think of to inspect SQL is to work around brokenness in the underlying database. Suppose, for example, that SQLite implicitly committed when it got DDL. (I don't know what it actually does. Just suppose.) In that case, it would be necessary to check for DDL and raise an exception before passing the statement to the database. If the database correctly errors in such a situation, then the python wrapper should just pass the DDL to the database and deal with the resulting error. That's way easier that trying to correctly detect what the statement type is. Parsing SQL correctly is hard. As evidence of that, note that the existing statement detection code is broken: it doesn't strip comments first! A simple SELECT statement preceeded by a comment will implicitly commit! But commenting is good. >>> import this ... Readability counts. So it's not even just an issue of DDL or PRAGMAs! Anything that causes the underlying database to implicitly commit must be avoided (yet the python module goes out of it's way to add *MORE* such buggy behavior!) Fixing brokenness in the underlying database is the only reason to inspect SQL as it passes through this module. If there are other ways to avoid such problems, they will likely be better than inspecting SQL. Anything which causes implicit rollbacks in the underlying database is a similar issue, but easier to handle without parsing SQL. It's not safe to implicitly rollback, even if a new transaction is begun. For example, you might be doing foreign key validation outside the database. If one INSERT were implicitly rolled back and a new transaction begun, a second INSERT may then succeed and be committed. Now you have a constraint violation, even though you correctly checked it before. If there is anything that triggers an implicit rollback in the underlying database connection, those rollbacks must be dectected all subsequent statements or actions on the python wrapper *should* raise exceptions until an explicit rollback is performed, except for commit() which *must* raise. For example: con.isolation_level = 'DEFERRED' try: # Nothing in here can implicitly commit or rollback safely. # Doing so risks data corruption. cur.execute("INSERT INTO foo ...") try: con.somehow_trigger_implicit_rollback() # must raise except: # Throw away the exception. pass try: # This *should* raise too, but isn't strictly necessary, # as long as commit() is implemented correctly. cur.execute("INSERT INTO bar ...") except: pass # The underlying database rolled back our transaction. # A successful commit here would not match reality. # This commit() must raise. con.commit() except: # This rollback() can succeed, because it puts the # "con" object back into correspondance with the underlying # database connection state. con.rollback() logger.error('something bad happened') raise If nothing in the database does implicit COMMITs or ROLLBACKs, then it's probably sufficient to leave all the error handling to the database and only raise exceptions when it indicates problems. Here is an example demonstrating that a SELECT can trigger an implicit commit. Python 2.7.3 (default, Sep 26 2013, 20:03:06) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> >>> # Create a connection. ... import sqlite3 >>> con = sqlite3.connect(":memory:", isolation_level='DEFERRED') >>> cur = con.cursor() >>> >>> # Create some state. ... cur.execute("CREATE TABLE foo (i int);") >>> cur.execute("INSERT INTO foo VALUES (0);") >>> con.commit() >>> >>> # Change the state, do a SELECT, then rollback. ... cur.execute("UPDATE foo SET i=1") >>> cur.execute("SELECT 1;") >>> con.rollback() >>> >>> # Verify that the rollback worked. ... cur.execute("SELECT i FROM foo") >>> i = cur.fetchone()[0] >>> print 'i is', i i is 0 >>> assert i == 0 >>> >>> # Change some state, do a different SELECT, then attempt to rollback. ... cur.execute("UPDATE foo SET i=2") >>> # This will incorrectly commit: ... cur.execute(""" ... /* ... * Comments are good for readability, but because of this bug, they can ... * cause incorrect implicit commits. ... */ ... SELECT 1; ... """) >>> con.rollback() >>> >>> >>> # The rollback succeeded and rolling back a different transaction than >>> # the one we expected. ... cur.execute("SELECT i FROM foo") >>> i = cur.fetchone()[0] >>> print 'i is', i i is 2 >>> assert i == 0 Traceback (most recent call last): File "", line 1, in AssertionError ---------- nosy: +adamtj title: sqlite3 module should allow DDL statements in transactions -> sqlite3 module breaks transactions and potentially corrupts data type: enhancement -> behavior versions: +Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 21:33:53 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jan 2014 20:33:53 +0000 Subject: [issue20209] Deprecate PROTOCOL_SSLv2 In-Reply-To: <1389296159.7.0.792924767181.issue20209@psf.upfronthosting.co.za> Message-ID: <1389299631.2278.8.camel@fsol> Antoine Pitrou added the comment: > If we removed it completely (which I'm *not* proposing, just gathering > data) how many people would it affect? What I'm proposing is to remove it after we deprecate it. I don't think it would affect many people, if any, but we still should have a deprecation period. > Is there any legitimate reason why some people would want SSLv2? Like > "we aren't allowed to upgrade this server" or something. The only reason I could think about is some embedded equipment or device with a built-in SSL-based server. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 21:37:40 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 09 Jan 2014 20:37:40 +0000 Subject: [issue20209] Deprecate PROTOCOL_SSLv2 In-Reply-To: <1389288239.29.0.63100261927.issue20209@psf.upfronthosting.co.za> Message-ID: <1389299860.28.0.607879694396.issue20209@psf.upfronthosting.co.za> Larry Hastings added the comment: Okay, you have my permission to mark it pending deprecated. > What I'm proposing is to remove it after we deprecate it. I understand the deprecation process. Like I said, I was just trying to get a sense of how many people would be affected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 21:37:47 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jan 2014 20:37:47 +0000 Subject: [issue13355] random.triangular error when low = high=mode In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za> Message-ID: <1389299867.37.0.417316202338.issue13355@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Raymond, could you please make a decision or delegate this issue to Mark, Terry, Andrew or me? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 21:41:21 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jan 2014 20:41:21 +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: <1389300081.03.0.829175119209.issue18787@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 21:41:33 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jan 2014 20:41:33 +0000 Subject: [issue10388] spwd returning different value depending on privileges In-Reply-To: <1289484192.53.0.424683719192.issue10388@psf.upfronthosting.co.za> Message-ID: <1389300093.27.0.679365621165.issue10388@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 21:54:14 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jan 2014 20:54:14 +0000 Subject: [issue20209] Deprecate PROTOCOL_SSLv2 In-Reply-To: <1389288239.29.0.63100261927.issue20209@psf.upfronthosting.co.za> Message-ID: <1389300854.57.0.593324170664.issue20209@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 22:06:50 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 09 Jan 2014 21:06:50 +0000 Subject: [issue10388] spwd returning different value depending on privileges In-Reply-To: <1289484192.53.0.424683719192.issue10388@psf.upfronthosting.co.za> Message-ID: <1389301610.6.0.818073715006.issue10388@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Looking back at this: considering we may get errors != EACCESS I think we better be as generic as possible as in: --- a/Modules/spwdmodule.c +++ b/Modules/spwdmodule.c @@ -153,6 +153,8 @@ if ((d = PyList_New(0)) == NULL) return NULL; setspent(); + if (errno != 0) + return PyErr_SetFromErrno(PyExc_OSError); while ((p = getspent()) != NULL) { PyObject *v = mkspent(p); if (v == NULL || PyList_Append(d, v) != 0) { As for 2.7 and 3.3 I have a little concern in terms of backward compatibility as the user will suddenly receive an exception instead of [] but I think that for the sake of correctness the cost is justified. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 22:13:42 2014 From: report at bugs.python.org (mike bayer) Date: Thu, 09 Jan 2014 21:13:42 +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: <1389302022.93.0.906616763809.issue9924@psf.upfronthosting.co.za> mike bayer added the comment: see also http://bugs.python.org/issue10740, which also relates to pysqlite attempting to make guesses as to when transactions should begin and end. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 22:19:16 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Jan 2014 21:19:16 +0000 Subject: [issue13107] Text width in optparse.py can become negative In-Reply-To: <1317812903.38.0.572106699519.issue13107@psf.upfronthosting.co.za> Message-ID: <3f0gDz3V0rz7LjW@mail.python.org> Roundup Robot added the comment: New changeset 779de7b4909b by Serhiy Storchaka in branch '2.7': Issue #13107: argparse and optparse no longer raises an exception when output http://hg.python.org/cpython/rev/779de7b4909b New changeset c6c30b682e14 by Serhiy Storchaka in branch '3.3': Issue #13107: argparse and optparse no longer raises an exception when output http://hg.python.org/cpython/rev/c6c30b682e14 New changeset 48bcd03cd29f by Serhiy Storchaka in branch 'default': Issue #13107: argparse and optparse no longer raises an exception when output http://hg.python.org/cpython/rev/48bcd03cd29f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 22:20:28 2014 From: report at bugs.python.org (mike bayer) Date: Thu, 09 Jan 2014 21:20:28 +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: <1389302428.5.0.254115362076.issue10740@psf.upfronthosting.co.za> mike bayer added the comment: well Adam, you might also be surprised to see pysqlite not doing very well on the *other* side of the equation either; that is, when it *begins* the transaction. Issue http://bugs.python.org/issue9924 refers to this and like this one, hasn't seen any activity since 2011. You might be interested in the rationale on that one, which is that python apps may wish to have some degree of concurrency against a sqlite file for an application that is doing all SELECTs. I am certainly in favor of a pure pep-249 approach that emits BEGIN on the first execute() call period, and never implicitly rolls back or commits. However, I disagree this should be enabled by default nor that there should not be any option for the old behavior. I also think the "delayed BEGIN" feature should still be available to counteract SQLite's particular difficulty with concurrency. If there is code that relies upon a bug in order to function, which would then fail to function in that way if the bug is fixed, then by definition fixing that bug is a backwards-incompatible change. Python std lib can't afford to roll out a change that blatantly backwards-incompatible. The issue regarding comments not being parsed unfortunately should also be a separate issue that needs to be fixed, as nasty as it is that pysqlite tries to parse SQL. I disagree that most users are expecting SQLite's DDL to be transactional; transactional DDL is a luxury feature to many, including the vast numbers of developers that use MySQL, not to mention Oracle, neither of which have any transactional DDL capabilities. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 22:27:18 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jan 2014 21:27:18 +0000 Subject: [issue13107] Text width in optparse.py can become negative In-Reply-To: <1317812903.38.0.572106699519.issue13107@psf.upfronthosting.co.za> Message-ID: <1389302838.31.0.328914055118.issue13107@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Adam for your report. Thank you Elazar for your patch. ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 22:52:52 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jan 2014 21:52:52 +0000 Subject: [issue19077] More robust TemporaryDirectory cleanup In-Reply-To: <1379948326.54.0.765934536043.issue19077@psf.upfronthosting.co.za> Message-ID: <1389304372.82.0.807205064791.issue19077@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file31848/tempfile_tempdir_cleanup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 22:54:50 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jan 2014 21:54:50 +0000 Subject: [issue19077] More robust TemporaryDirectory cleanup In-Reply-To: <1379948326.54.0.765934536043.issue19077@psf.upfronthosting.co.za> Message-ID: <1389304490.81.0.129451208578.issue19077@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated patch to tip. ---------- Added file: http://bugs.python.org/file33378/tempfile_tempdir_cleanup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 23:04:26 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jan 2014 22:04:26 +0000 Subject: [issue19077] More robust TemporaryDirectory cleanup In-Reply-To: <1379948326.54.0.765934536043.issue19077@psf.upfronthosting.co.za> Message-ID: <1389305066.19.0.709448984306.issue19077@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: An alternative with weakref.finalize() looks very attractive, but unfortunately tests are failed with it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 23:05:44 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Jan 2014 22:05:44 +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: <1389305144.46.0.978039902298.issue10740@psf.upfronthosting.co.za> R. David Murray added the comment: On Thu, 09 Jan 2014 20:29:15 +0000, Adam Tomjack wrote: > This issue is not an enhancement, it's a bug. One might argue that > fixing it will break existing code, but it won't. Any affected code > is already broken. It's depending on a promised level of safety, and > this bug is breaking that promise. It's better to fail noisily and > consistently than to usually work, but sometimes silently corrupt > data. That's not how our backward compatibility policy works. If a program runs correctly, a change in a maintenance release should not cause that program to fail, *even if the change is a bug fix*. Now, that said, silent data corruption can change that calculus, but in this case there are many many working programs out there that don't experience data corruption, so breaking them in a maintenance release is just not acceptable. It is possible that there are specific things that can be fixed without breaking backward compatibility, but they will have to be argued individually. > In general, it's a code-smell to inspect the SQL that's being executed > before sending it to the database. The only reason I can think of to There are reasons why the sqlite module was designed the way it was, having to do with an intersection between how sqlite works and the DB API 2 specification. I'm not saying the design (and implementation of that design) has no bugs, but there *are* reasons why the choices made were made, including the concurrency issue mentioned by Mike (which if I understand correctly was even more problematic in earlier versions of sqlite.) > inspect SQL is to work around brokenness in the underlying database. > Suppose, for example, that SQLite implicitly committed when it got > DDL. (I don't know what it actually does. Just suppose.) In that By default, SQLite starts a transaction when any command that changes the database is executed (the docs say, "basically, anything other than a SELECT), and "automatically started transactions are committed when the last query finishes". I'm not sure exactly what that means. Note that there is no way in sqlite to turn auto-transaction behavior off. > case, it would be necessary to check for DDL and raise an exception > before passing the statement to the database. If the database Like I said, this would need to be a new feature, due to our backward compatibility policy. > correctly errors in such a situation, then the python wrapper should > just pass the DDL to the database and deal with the resulting error. > That's way easier that trying to correctly detect what the statement > type is. Parsing SQL correctly is hard. If you want full control of transactions while using the sqlite module, you can set the isolation_level to None (sqlite's default autocommit mode) and then carefully control when you issue what kinds of statements, including BEGIN statements. Any exceptions produced by the database will in that situation be propagated to the application. That loses the (admittedly somewhat limited) DB-interoperability benefits of using the DB API 2, though. > As evidence of that, note that the existing statement detection code > is broken: it doesn't strip comments first! A simple SELECT statement > preceeded by a comment will implicitly commit! But commenting is > good. Yes, the fact that statement detection (and what statements are detected) is buggy is the essence of this issue. But note that in Python code it would be much more natural to put the comment in the python code, not the sql string. > Anything that causes the underlying database to implicitly commit must > be avoided (yet the python module goes out of it's way to add *MORE* > such buggy behavior!) Fixing brokenness in the underlying database is > the only reason to inspect SQL as it passes through this module. If Yep. > there are other ways to avoid such problems, they will likely be > better than inspecting SQL. Do you have a better way to suggest? > Anything which causes implicit rollbacks in the underlying database is > a similar issue, but easier to handle without parsing SQL. It's not There are no implicit rollbacks at issue anywhere here, that I can see. Do you have an example where the module does an implicit rollback? > Here is an example demonstrating that a SELECT can trigger an implicit > commit. Yes, the comment issue should be fixed. That's a different bug, though, and should be addressed in a separate issue. Unfortunately, since some people seem to be *depending* on the fact that putting in a comment disables statement detection, that, too will need to be a new feature. I'm sorry about that, but Python has a strong commitment to backward compatibility. ---------- type: behavior -> enhancement versions: +Python 3.5 -Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 23:19:41 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jan 2014 22:19:41 +0000 Subject: [issue19077] More robust TemporaryDirectory cleanup In-Reply-To: <1379948326.54.0.765934536043.issue19077@psf.upfronthosting.co.za> Message-ID: <1389305981.93.0.458786194167.issue19077@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which implements Richard's suggestion. test_del_on_shutdown and test_warnings_on_cleanup are failed, but perhaps they are wrong. ---------- Added file: http://bugs.python.org/file33379/tempfile_tempdir_cleanup_weakref_finalize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 23:52:42 2014 From: report at bugs.python.org (Thomas Petazzoni) Date: Thu, 09 Jan 2014 22:52:42 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions Message-ID: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za> New submission from Thomas Petazzoni: In the context of space-constrained embedded Linux systems, installing the entire set of Python modules and extensions is not necessarily desirable. For example, all the test modules, as well as certain extensions requiring third-parties libraries are often unnecessary, and uselessly consume precious storage on the embedded Linux system. While we could certainly remove these undesired modules and extensions manually, it is much more convenient to have configuration options to selectively enable and disable them. Another very strong benefit of having configuration options is that we can actually *disable* the build of these unneeded modules and extensions, therefore saving a lot of build time, which is very nice when you're repeatedly cross-compiling an entire embedded Linux system. The proposed set of patches add several --enable-/--disable- options to enable/disable certain Python modules and extensions. These patches have been part of Buildroot, an embedded Linux build system (used for example by Google, and many embedded processor vendors, as well as a huge number of embedded system makers) for a while, and are useful to all our users using Python on their embedded Linux systems. Instead of carrying them around, we would like to have them merged in upstream Python. Of course, we are definitely open to discussion on the approach to take to implement this configurability, and I'm ready to rework the patches according to the comments received here. Thanks! ---------- components: Build messages: 207802 nosy: thomas-petazzoni priority: normal severity: normal status: open title: Provide configure options to enable/disable Python modules and extensions versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 23:52:52 2014 From: report at bugs.python.org (Thomas Petazzoni) Date: Thu, 09 Jan 2014 22:52:52 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za> Message-ID: <1389307972.62.0.734001543383.issue20210@psf.upfronthosting.co.za> Changes by Thomas Petazzoni : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 23:53:04 2014 From: report at bugs.python.org (Thomas Petazzoni) Date: Thu, 09 Jan 2014 22:53:04 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za> Message-ID: <1389307984.67.0.71190472733.issue20210@psf.upfronthosting.co.za> Changes by Thomas Petazzoni : ---------- keywords: +patch Added file: http://bugs.python.org/file33380/0001-Add-infrastructure-to-disable-the-build-of-certain-e.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 23:53:16 2014 From: report at bugs.python.org (Thomas Petazzoni) Date: Thu, 09 Jan 2014 22:53:16 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za> Message-ID: <1389307996.42.0.928102544852.issue20210@psf.upfronthosting.co.za> Changes by Thomas Petazzoni : Added file: http://bugs.python.org/file33381/0002-Add-an-option-to-disable-installation-of-test-module.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 23:53:26 2014 From: report at bugs.python.org (Thomas Petazzoni) Date: Thu, 09 Jan 2014 22:53:26 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za> Message-ID: <1389308006.0.0.0879211459838.issue20210@psf.upfronthosting.co.za> Changes by Thomas Petazzoni : Added file: http://bugs.python.org/file33382/0003-Add-an-option-to-disable-pydoc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 23:53:33 2014 From: report at bugs.python.org (Thomas Petazzoni) Date: Thu, 09 Jan 2014 22:53:33 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za> Message-ID: <1389308013.31.0.321061735541.issue20210@psf.upfronthosting.co.za> Changes by Thomas Petazzoni : Added file: http://bugs.python.org/file33383/0004-Add-an-option-to-disable-lib2to3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 23:53:47 2014 From: report at bugs.python.org (Thomas Petazzoni) Date: Thu, 09 Jan 2014 22:53:47 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za> Message-ID: <1389308027.15.0.454520138973.issue20210@psf.upfronthosting.co.za> Changes by Thomas Petazzoni : Added file: http://bugs.python.org/file33384/0005-Add-option-to-disable-the-sqlite3-module.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 23:53:55 2014 From: report at bugs.python.org (Thomas Petazzoni) Date: Thu, 09 Jan 2014 22:53:55 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za> Message-ID: <1389308035.11.0.126115927971.issue20210@psf.upfronthosting.co.za> Changes by Thomas Petazzoni : Added file: http://bugs.python.org/file33385/0006-Add-an-option-to-disable-the-tk-module.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 23:54:04 2014 From: report at bugs.python.org (Thomas Petazzoni) Date: Thu, 09 Jan 2014 22:54:04 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za> Message-ID: <1389308044.02.0.456891916684.issue20210@psf.upfronthosting.co.za> Changes by Thomas Petazzoni : Added file: http://bugs.python.org/file33386/0007-Add-an-option-to-disable-the-curses-module.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 23:54:17 2014 From: report at bugs.python.org (Thomas Petazzoni) Date: Thu, 09 Jan 2014 22:54:17 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za> Message-ID: <1389308057.42.0.240318355368.issue20210@psf.upfronthosting.co.za> Changes by Thomas Petazzoni : Added file: http://bugs.python.org/file33387/0008-Add-an-option-to-disable-expat.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 23:54:28 2014 From: report at bugs.python.org (Thomas Petazzoni) Date: Thu, 09 Jan 2014 22:54:28 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za> Message-ID: <1389308068.98.0.914429845812.issue20210@psf.upfronthosting.co.za> Changes by Thomas Petazzoni : Added file: http://bugs.python.org/file33388/0009-Add-an-option-to-disable-CJK-codecs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 23:54:35 2014 From: report at bugs.python.org (Thomas Petazzoni) Date: Thu, 09 Jan 2014 22:54:35 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za> Message-ID: <1389308075.75.0.846139623688.issue20210@psf.upfronthosting.co.za> Changes by Thomas Petazzoni : Added file: http://bugs.python.org/file33389/0010-Add-an-option-to-disable-NIS.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 23:54:41 2014 From: report at bugs.python.org (Thomas Petazzoni) Date: Thu, 09 Jan 2014 22:54:41 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za> Message-ID: <1389308081.88.0.284127774276.issue20210@psf.upfronthosting.co.za> Changes by Thomas Petazzoni : Added file: http://bugs.python.org/file33390/0011-Add-an-option-to-disable-unicodedata.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 23:54:48 2014 From: report at bugs.python.org (Thomas Petazzoni) Date: Thu, 09 Jan 2014 22:54:48 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za> Message-ID: <1389308088.6.0.0881673761654.issue20210@psf.upfronthosting.co.za> Changes by Thomas Petazzoni : Added file: http://bugs.python.org/file33391/0012-Add-an-option-to-disable-IDLE.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 9 23:56:14 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jan 2014 22:56:14 +0000 Subject: [issue19077] More robust TemporaryDirectory cleanup In-Reply-To: <1379948326.54.0.765934536043.issue19077@psf.upfronthosting.co.za> Message-ID: <1389308174.07.0.0860165264653.issue19077@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Note the finalize-based patch can only work on 3.4. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 00:01:02 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jan 2014 23:01:02 +0000 Subject: [issue19077] More robust TemporaryDirectory cleanup In-Reply-To: <1379948326.54.0.765934536043.issue19077@psf.upfronthosting.co.za> Message-ID: <1389308462.04.0.185457441059.issue19077@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a working patch for the finalize-based approach. ---------- Added file: http://bugs.python.org/file33392/tempdir_finalize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 00:02:08 2014 From: report at bugs.python.org (Thomas Petazzoni) Date: Thu, 09 Jan 2014 23:02:08 +0000 Subject: [issue20211] setup.py: do not add invalid header locations Message-ID: <1389308528.92.0.403642458985.issue20211@psf.upfronthosting.co.za> New submission from Thomas Petazzoni: In the cross-compilation case, setup.py incorrectly adds /usr/include to self.compiler.include_dirs, and results in the following invalid compilation line: /home/thomas/projets/buildroot/output/host/usr/bin/arm-none-linux-gnueabi-gcc -fPIC -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -pipe -Os -I./Include -I/usr/include -I. -IInclude -I/home/thomas/projets/buildroot/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/include -I/home/thomas/projets/buildroot/output/build/python3-3.4.0b1/Include -I/home/thomas/projets/buildroot/output/build/python3-3.4.0b1 -c /home/thomas/projets/buildroot/output/build/python3-3.4.0b1/Modules/_struct.c -o build/temp.linux-arm-3.4/home/thomas/projets/buildroot/output/build/python3-3.4.0b1/Modules/_struct.o cc1: warning: include location "/usr/include" is unsafe for cross-compilation [-Wpoison-system-directories] The -I/usr/include is wrong when cross compiling, so we disable adding INCLUDEDIR and LIBDIR from the host when cross compiling. ---------- components: Cross-Build files: 0001-setup.py-do-not-add-invalid-header-locations.patch keywords: patch messages: 207805 nosy: thomas-petazzoni priority: normal severity: normal status: open title: setup.py: do not add invalid header locations type: compile error versions: Python 3.4 Added file: http://bugs.python.org/file33393/0001-setup.py-do-not-add-invalid-header-locations.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 00:03:07 2014 From: report at bugs.python.org (Thomas Petazzoni) Date: Thu, 09 Jan 2014 23:03:07 +0000 Subject: [issue20212] distutils: fix build_ext check to find whether we're building Python or not Message-ID: <1389308587.95.0.49928374838.issue20212@psf.upfronthosting.co.za> New submission from Thomas Petazzoni: The build_ext logic uses sys.executable.startswith(os.path.join(sys.exec_prefix, "bin")) to determine whether we're building a third-party Python extension, or a built-in Python extension. However, this check is wrong in cross-compilation mode, because the host Python interpreter might very well be installed in its prefix, when it is used to cross-compile the target modules and extensions. The current check would mis-detect this as we're building third-party Python modules, while we are in fact building the internal Python modules of the target Python. Therefore, use the existing sysconfig.python_build variable, which provides the information of whether we're building Python itself or not in a correct way. ---------- components: Cross-Build files: 0002-distutils-fix-build_ext-check-to-find-whether-we-re-.patch keywords: patch messages: 207806 nosy: thomas-petazzoni priority: normal severity: normal status: open title: distutils: fix build_ext check to find whether we're building Python or not type: compile error versions: Python 3.4 Added file: http://bugs.python.org/file33394/0002-distutils-fix-build_ext-check-to-find-whether-we-re-.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 00:03:48 2014 From: report at bugs.python.org (Thomas Petazzoni) Date: Thu, 09 Jan 2014 23:03:48 +0000 Subject: [issue20213] Change the install location of _sysconfigdata.py Message-ID: <1389308628.19.0.703903245548.issue20213@psf.upfronthosting.co.za> New submission from Thomas Petazzoni: The _sysconfigdata.py module contains definitions that are needed when building Python modules. In cross-compilation mode, when building Python extensions for the target, we need to use the _sysconfigdata.py of the target Python while executing the host Python. However until now, the _sysconfigdata.py module was installed in build/lib.- directory, together with a number of architecture-specific shared objects, which cannot be used with the host Python. To solve this problem, this patch moves _sysconfigdata.py to a separate location, build/sysconfigdata.-/, and only this directory gets added to the PYTHONPATH of the host Python interpreter when building Python modules for the target. ---------- components: Cross-Build files: 0003-Change-the-install-location-of-_sysconfigdata.py.patch keywords: patch messages: 207807 nosy: thomas-petazzoni priority: normal severity: normal status: open title: Change the install location of _sysconfigdata.py type: compile error versions: Python 3.4 Added file: http://bugs.python.org/file33395/0003-Change-the-install-location-of-_sysconfigdata.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 00:07:41 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jan 2014 23:07:41 +0000 Subject: [issue20207] Disable SSLv2 in Python 2.x In-Reply-To: <1389286085.44.0.640334918111.issue20207@psf.upfronthosting.co.za> Message-ID: <1389308861.9.0.13391309974.issue20207@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 00:18:02 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jan 2014 23:18:02 +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: <1389309482.28.0.240983538586.issue9924@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- versions: +Python 3.3, Python 3.4 -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 01:03:35 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Jan 2014 00:03:35 +0000 Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <3f0ktZ1vJfz7LjP@mail.python.org> Roundup Robot added the comment: New changeset 1f3242fb0c9c by Brett Cannon in branch 'default': Issue #20152: import.c now uses Argument Clinic. http://hg.python.org/cpython/rev/1f3242fb0c9c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 01:04:10 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Jan 2014 00:04:10 +0000 Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1389312250.82.0.0558518120242.issue20152@psf.upfronthosting.co.za> Brett Cannon added the comment: Now it's: Modules/cmathmodule.c: 8 sites Modules/cjkcodecs/multibytecodec.c: 8 sites Modules/arraymodule.c: 8 sites Modules/pyexpat.c: 7 sites Modules/fcntlmodule.c: 7 sites Modules/pwdmodule.c: 2 sites Modules/spwdmodule.c: 1 sites Modules/grpmodule.c: 1 sites ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 01:04:25 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Jan 2014 00:04:25 +0000 Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1389312265.24.0.958398202663.issue20152@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: larry -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 01:28:38 2014 From: report at bugs.python.org (Alexander Boyd) Date: Fri, 10 Jan 2014 00:28:38 +0000 Subject: [issue20012] Re: Allow Path.relative_to() to accept non-ancestor paths In-Reply-To: <1387347011.06.0.0464883312921.issue20012@psf.upfronthosting.co.za> Message-ID: <1389313718.07.0.222015451722.issue20012@psf.upfronthosting.co.za> Alexander Boyd added the comment: Then perhaps the docstring of relative_to could note this (like relpath does), or a separate method that's explicitly not symlink safe created. Or better yet, what about a function that does (or at least tries to) give the correct answer in the face of symlinks? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 02:25:39 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 10 Jan 2014 01:25:39 +0000 Subject: [issue20214] Argument Clinic rollup fixes Message-ID: <1389317138.57.0.101674386167.issue20214@psf.upfronthosting.co.za> New submission from Larry Hastings: Miscellaneous Argument Clinic fixes: * Added default value type verification for almost all return converters. * Added return converters for float, dobule, unsigned long, unsigned int, short, and unsigned short. * Py_buffer converter improvements: * Now allow exactly one value as a default value: None. * The default value in C only needs two fields initialized. * The cleanup call to PyBuffer_Release should be based on ".obj", not ".buf". As well as a bunch of documentation fixes. I'd love a review, but I'm pretty confident it's all okay so I may just check it in. (The only code changes are in clinic.py so it's not going to break the world.) ---------- assignee: larry files: larry.argument.clinic.misc.fixes.patch.1.txt messages: 207811 nosy: larry priority: normal severity: normal stage: patch review status: open title: Argument Clinic rollup fixes type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file33396/larry.argument.clinic.misc.fixes.patch.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 02:27:02 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 10 Jan 2014 01:27:02 +0000 Subject: [issue20200] Argument Clinic howto: custom self_converter example broken In-Reply-To: <1389233870.77.0.302352935939.issue20200@psf.upfronthosting.co.za> Message-ID: <1389317222.04.0.110079811375.issue20200@psf.upfronthosting.co.za> Larry Hastings added the comment: LGTM. Check it in please! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 02:28:40 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 10 Jan 2014 01:28:40 +0000 Subject: [issue20201] Argument Clinic: rwbuffer support broken In-Reply-To: <1389242396.52.0.166931579233.issue20201@psf.upfronthosting.co.za> Message-ID: <1389317320.4.0.00656697074732.issue20201@psf.upfronthosting.co.za> Larry Hastings added the comment: LGTM. To be honest I don't understand what the hell 'w*' is for. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 02:30:09 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 10 Jan 2014 01:30:09 +0000 Subject: [issue20202] ArgumentClinic howto: document change in Py_buffer lifecycle management In-Reply-To: <1389250062.45.0.978565094508.issue20202@psf.upfronthosting.co.za> Message-ID: <1389317409.84.0.406506733077.issue20202@psf.upfronthosting.co.za> Larry Hastings added the comment: I've got a bunch of doc improvements in the rollup patch in #20214. I invite you to give it a review. If that looks suitable please close this issue. As for a verb, I've been using "convert". "zlibmodule has already been converted to work with Argument Clinic". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 02:42:36 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 10 Jan 2014 01:42:36 +0000 Subject: [issue20203] ArgumentClinic: support middle optional argument In-Reply-To: <1389254600.21.0.692966775904.issue20203@psf.upfronthosting.co.za> Message-ID: <1389318156.18.0.0953983880513.issue20203@psf.upfronthosting.co.za> Larry Hastings added the comment: Oh . socket.sendto can't currently be converted to Argument Clinic. There's legacy, and then there's the cruelty that only 1993-style argument parsing can inflict. (socket.sendto's argument parsing was checked in in revision ac3c80abbf43 from 1993 by Guido.) I'll keep it in mind for the future, but it's really pretty twisted. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 02:45:10 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 Jan 2014 01:45:10 +0000 Subject: [issue20122] Move CallTips tests to idle_tests In-Reply-To: <1388852698.51.0.14863260737.issue20122@psf.upfronthosting.co.za> Message-ID: <1389318310.78.0.911028361013.issue20122@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The existing tests in CallTips.py, half of which I wrote based on the ones that existed, have one or two deficiencies that are copied in the patch. First, they are not proper unittests. They test get_argspec indirectly by calling .fetch_tip and get_entity. This lead to the new private parameter, which will not be needed for the existing tests when get_argspec is called directly with objects. Adding more tests for get_entity, beyond the one in test_calltips.py already, is a different issue. The function is mostly a wrapper for eval(), which we may assume works correctly. Second, the doubling resulting from putting expected output in docstrings seems a bit flakey. It certainly does not test cases with no docstring or multiple-line docstrings. I am working on a revised patch. (Also, the unittest call was added with test_calltip.py and I want it left.) In 2.7. get_argspec is get_arg_text, with a different implementation. Backporting to 2.7 will require some adjustments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 02:58:07 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 10 Jan 2014 01:58:07 +0000 Subject: [issue20196] Argument Clinic generates invalid code for optional parameter In-Reply-To: <1389215820.54.0.23969623905.issue20196@psf.upfronthosting.co.za> Message-ID: <1389319087.22.0.144380690463.issue20196@psf.upfronthosting.co.za> Larry Hastings added the comment: Here's a fix. Works for me, let me know if it works for you. ---------- Added file: http://bugs.python.org/file33397/larry.zero.positional.parameters.patch.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 02:58:16 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 10 Jan 2014 01:58:16 +0000 Subject: [issue20196] Argument Clinic generates invalid code for optional parameter In-Reply-To: <1389215820.54.0.23969623905.issue20196@psf.upfronthosting.co.za> Message-ID: <1389319096.31.0.871973116159.issue20196@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 03:00:58 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 10 Jan 2014 02:00:58 +0000 Subject: [issue19976] Argument Clinic: generate second arg for METH_NOARGS In-Reply-To: <1386945786.12.0.418187279765.issue19976@psf.upfronthosting.co.za> Message-ID: <1389319258.02.0.59190187053.issue19976@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- assignee: -> larry resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 03:03:02 2014 From: report at bugs.python.org (dzyu) Date: Fri, 10 Jan 2014 02:03:02 +0000 Subject: [issue20215] Python2.7 socketserver can not listen IPv6 address Message-ID: <1389319382.42.0.481013787618.issue20215@psf.upfronthosting.co.za> New submission from dzyu: I see, in python 2.7, in SocketServer.py the TCPServer implementation is hard-coded to use ipv4, can not handle IPv6 case. it hard-coded set address_family as socket.AF_INET. so when binding IPv6 host, it will throw "gaierror: [Errno -9] Address family for hostname not supported". The code should to judge the provided host is IPv4 or IPv6, and base on the host type to set address_family as socket.AF_INET or socket.AF_INET6 ---------- components: Library (Lib) messages: 207818 nosy: dazhaoyu priority: normal severity: normal status: open title: Python2.7 socketserver can not listen IPv6 address type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 03:03:15 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 10 Jan 2014 02:03:15 +0000 Subject: [issue20174] Derby #5: Convert 50 sites to Argument Clinic across 3 files In-Reply-To: <1389138461.92.0.709656306175.issue20174@psf.upfronthosting.co.za> Message-ID: <1389319395.53.0.60282225565.issue20174@psf.upfronthosting.co.za> Larry Hastings added the comment: While it's dandy to add docstrings, your patch doesn't have any Argument Clinic stuff in it. I don't mind if you add docstrings as part of the process of converting to Argument Clinic, but I'm not interested in this patch as it stands. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 03:08:08 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 Jan 2014 02:08:08 +0000 Subject: [issue16630] IDLE: Calltip fails if __getattr__ raises exception In-Reply-To: <1354844775.58.0.855877358898.issue16630@psf.upfronthosting.co.za> Message-ID: <1389319688.47.0.312616758639.issue16630@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Get_entity already has try-except to block exceptions propagating from eval failure, so wrapping it is redundant. We only need worry about get_argspec. I presume the failure is in get_argspec in the remote process: if hasattr(ob, '__call__'): This can be replaced by callable(ob) as it converts exceptions to False. The appropriate return for non-callables is the current default, '', which results in no tip. There are, however, other attribute accesses that could fail. I am reluctant to wrap get_argspec in its entirety, as that would mask bugs in Idle code as well as in user snippets. So I think each access should be protected. Since users will expect a tip for something that is a callable, I think a message might be appropriate. I checked that getattr(ob, name, default) does not convert exception to default. Their are rpc calls in several places in Idle code. Unless failure can be triggered here in particular by user error, I do not think we should add specific protection here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 03:16:18 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 Jan 2014 02:16:18 +0000 Subject: [issue7883] CallTips.py _find_constructor does not work In-Reply-To: <1265631103.87.0.399117397925.issue7883@psf.upfronthosting.co.za> Message-ID: <1389320178.37.0.457668782233.issue7883@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The 3.x changes will not affect 2.7, which currently still uses _find_constructor. I suspect the .__func__ is needed for old-style classes, but I will try to check. ---------- versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 03:21:30 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Fri, 10 Jan 2014 02:21:30 +0000 Subject: [issue20216] Misleading docs for sha1, sha256, sha512 modules Message-ID: <1389320490.58.0.128009418019.issue20216@psf.upfronthosting.co.za> New submission from Vajrasky Kok: Misleading doc number 1: >>> import _sha1 >>> _sha1.sha1.__doc__ 'Return a new SHA1 hash object; optionally initialized with a string.' >>> _sha1.sha1('cutecat') Traceback (most recent call last): File "", line 1, in TypeError: Unicode-objects must be encoded before hashing >>> _sha1.sha1(b'cutecat') <_sha1.sha1 object at 0x7f800f669e00> >>> _sha1.sha1(string=b'cutecat') <_sha1.sha1 object at 0x7f800f669e00> I don't think we can change the unfortunate keyword 'string'. But at least we must fix the doc. Misleading doc number 2: >>> import _sha1 >>> cutecat = _sha1.sha1(b'cutecat') >>> cutecat.update.__doc__ "Update this hash object's state with the provided string." >>> cutecat.update('bonobo') Traceback (most recent call last): File "", line 1, in TypeError: Unicode-objects must be encoded before hashing >>> cutecat.update(b'bonobo') Misleading doc number 3: >>> cutecat.hexdigest() 'a5fbd19140a72992224b2469c4f4d8d6d4aff3e7' >>> cutecat.hexdigest.__doc__ 'Return the digest value as a string of hexadecimal digits.' >>> cutecat.digest() b'\xa5\xfb\xd1\x91@\xa7)\x92"K$i\xc4\xf4\xd8\xd6\xd4\xaf\xf3\xe7' >>> cutecat.digest.__doc__ 'Return the digest value as a string of binary data.' "a string of binary data" in my mind is something like this: '\xa5\xfb\xd1\x91@\xa7)\x92"K$i\xc4\xf4\xd8\xd6\xd4\xaf\xf3\xe7' not b'\xa5\xfb\xd1\x91@\xa7)\x92"K$i\xc4\xf4\xd8\xd6\xd4\xaf\xf3\xe7'. Provided the patch to fix the doc. ---------- components: Extension Modules files: fix_doc_sha_module.patch keywords: patch messages: 207822 nosy: christian.heimes, vajrasky priority: normal severity: normal status: open title: Misleading docs for sha1, sha256, sha512 modules type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33398/fix_doc_sha_module.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 03:21:42 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 10 Jan 2014 02:21:42 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1389320502.54.0.0266224923331.issue20173@psf.upfronthosting.co.za> Larry Hastings added the comment: That METH_O is working perfectly. You seem to be confused by it. The original code was kind of dumb. The function only takes two parameters: self, and a second "obj" parameter which can be any kind of object. CPython has special support for exactly this kind of function, which is METH_O. This will actually be slightly faster. In any case, that part of your conversion was correct. Don't sweat it. http://docs.python.org/3.4/c-api/structures.html?highlight=meth_o#METH_O ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 03:22:38 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 10 Jan 2014 02:22:38 +0000 Subject: [issue20215] Python2.7 socketserver can not listen IPv6 address In-Reply-To: <1389319382.42.0.481013787618.issue20215@psf.upfronthosting.co.za> Message-ID: <1389320558.96.0.170313419042.issue20215@psf.upfronthosting.co.za> R. David Murray added the comment: The *default* is AF_INET. If you are requesting a more convenient API than subclassing (which for IPV6 support I think would be a reasonable request), that would be a new feature. ---------- nosy: +r.david.murray type: behavior -> enhancement versions: +Python 3.5 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 03:33:19 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 10 Jan 2014 02:33:19 +0000 Subject: [issue20175] Derby #6: Convert 50 sites to Argument Clinic across 8 files In-Reply-To: <1389138499.96.0.517173661563.issue20175@psf.upfronthosting.co.za> Message-ID: <1389321199.2.0.262236637264.issue20175@psf.upfronthosting.co.za> Larry Hastings added the comment: Go for it! That's weird. Why can't I assign it to you? Have you not signed and submitted a Python contributor agreement? ---------- assignee: -> kbk nosy: +kbk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 03:33:58 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 10 Jan 2014 02:33:58 +0000 Subject: [issue20175] Derby #6: Convert 50 sites to Argument Clinic across 8 files In-Reply-To: <1389138499.96.0.517173661563.issue20175@psf.upfronthosting.co.za> Message-ID: <1389321238.16.0.529101536491.issue20175@psf.upfronthosting.co.za> Larry Hastings added the comment: Oops, sorry kbk. ---------- assignee: kbk -> nosy: -kbk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 03:38:36 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 10 Jan 2014 02:38:36 +0000 Subject: [issue20190] dict() in dict(foo='bar').keys() raises In-Reply-To: <1389188100.33.0.555885401078.issue20190@psf.upfronthosting.co.za> Message-ID: <1389321516.19.0.55019167468.issue20190@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > I think the problem is that the API of dict.keys() is surprising. > One gets back something that behaves like a list, the name 'keys' > suggests that it is a list and for lists there is no requirement > that their containing items need to be hasheable. The keys() method returns a view with set-like behavior (it supports union, intersection, difference, fast membership testing using hashed lookups, and iteration). Guido modeled this behavior from a well established API in Java. FWIW, it is hard for us to do anything about comments like "I was surprised ..." The language behaviors are documented but that doesn't help if the docs aren't read. If you expected a list-like object but received a set-like object, then you would get surprised. There is not much that can be done about that. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 04:12:27 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Fri, 10 Jan 2014 03:12:27 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1389323547.56.0.938218113197.issue20173@psf.upfronthosting.co.za> Vajrasky Kok added the comment: But METH_O makes the update method does not work. >>> _sha1.sha1().update(b'a') Traceback (most recent call last): File "", line 1, in SystemError: new style getargs format but argument is not a tuple But if you change METH_O to METH_VARARGS, it works again. I'll chip Christian Heimes. Maybe he has something to say about this. Other than that, I need to update my patch because currently with my patch, the sha1 constructor accepts None value. The default behaviour is to reject None value. So I need to use advanced feature of clinic for this purpose. I think I can convert all sha modules (including md5) in this weekend. However, _codecsmodule is totally different beast. 43 sites.... >.< ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 04:14:12 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 10 Jan 2014 03:14:12 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1389323652.6.0.344256835142.issue20173@psf.upfronthosting.co.za> Larry Hastings added the comment: Right, it doesn't work because you left the PyArg_ParseTuple call in your impl function. Remove that and it should work. Rule 1: Argument Clinic handles all argument parsing for you. Your "impl" function should never call PyArg_ParseTuple or PyArg_ParseTupleAndKeywords. Rule 2: Never modify the output of Argument Clinic by hand. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 04:21:49 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Fri, 10 Jan 2014 03:21:49 +0000 Subject: [issue20216] Misleading docs for sha1, sha256, sha512, md5 modules In-Reply-To: <1389320490.58.0.128009418019.issue20216@psf.upfronthosting.co.za> Message-ID: <1389324109.73.0.633943013383.issue20216@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Added md5 module to this ticket. ---------- title: Misleading docs for sha1, sha256, sha512 modules -> Misleading docs for sha1, sha256, sha512, md5 modules Added file: http://bugs.python.org/file33399/fix_doc_sha_module_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 04:35:31 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Fri, 10 Jan 2014 03:35:31 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1389324931.23.0.825469168814.issue20173@psf.upfronthosting.co.za> Vajrasky Kok added the comment: This is the current behaviour of sha1 constructor. It rejects None value. >>> import _sha1 >>> _sha1.sha1() <_sha1.sha1 object at 0x7f7fa7f0dea0> >>> _sha1.sha1(None) Traceback (most recent call last): File "", line 1, in TypeError: object supporting the buffer API required >>> _sha1.sha1(string=None) Traceback (most recent call last): File "", line 1, in TypeError: object supporting the buffer API required Then when I clinic it, what about the doc? This doesn't seem right. +PyDoc_STRVAR(_sha1_SHA1_sha1__doc__, +"sha1(string=None)\n" "Return a new SHA1 hash object; optionally initialized with a string."); ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 04:41:44 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Jan 2014 03:41:44 +0000 Subject: [issue20200] Argument Clinic howto: custom self_converter example broken In-Reply-To: <1389233870.77.0.302352935939.issue20200@psf.upfronthosting.co.za> Message-ID: <3f0qkH6x7cz7Ljc@mail.python.org> Roundup Robot added the comment: New changeset 5a8301002f5a by Zachary Ware in branch 'default': Closes #20200: Argument Clinic custom converter example should be in a http://hg.python.org/cpython/rev/5a8301002f5a ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 05:06:56 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Fri, 10 Jan 2014 04:06:56 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1389326815.99.0.521362460365.issue20173@psf.upfronthosting.co.za> Vajrasky Kok added the comment: >Rule 1: Argument Clinic handles all argument parsing for you. Your "impl" function should never call PyArg_ParseTuple or PyArg_ParseTupleAndKeywords. Ah, got it. Here is the third patch. Everything works fine except for the issue whether sha1 constructor should accept None value or not. Right now, after clinic, it accepts it. So _sha1.sha1() is same as _sha1.sha1(string=None). ---------- Added file: http://bugs.python.org/file33400/clinic_sha1module_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 05:36:19 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 10 Jan 2014 04:36:19 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1389328579.75.0.950165155963.issue20172@psf.upfronthosting.co.za> Zachary Ware added the comment: Thanks, Larry. Conversion proceeds apace in winreg.c, but I have a couple questions. 1) Since the comment above CConverter.format_unit says all custom converters should use 'O&' instead of defining format_unit, there must be another way to do this: /*[python input] class REGSAM_converter(CConverter): type = 'REGSAM' format_unit = 'i' default = 0 def converter_init(self, *, key_name=""): if key_name == "": raise ValueError('must provide the key name') self.doc_default = self.py_default = self.c_default = key_name [python start generated code]*/ (see http://hg.python.org/sandbox/zware/rev/f0662bf33e65) I don't know what the 'other way' is though :). The above works, but I don't understand it completely and thus don't like it. Also, it causes help(winreg.CreateKeyEx) to show "access='KEY_WRITE'" in the signature, when it should have no quotes (being a name). 2) Is there an easy way to give a function multiple names? OpenKey and OpenKeyEx are the same function, OpenKeyEx has been just defined by an extra methoddef pointing at OpenKey; for now I've just modified that line to make things work. Neither of these is blocking progress, so not a huge deal other than getting a little bit of review done early. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 05:40:48 2014 From: report at bugs.python.org (Ethan Furman) Date: Fri, 10 Jan 2014 04:40:48 +0000 Subject: [issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za> Message-ID: <1389328848.1.0.683968413699.issue19995@psf.upfronthosting.co.za> Ethan Furman added the comment: Could somebody explain this? =============================================================================== ethan at media:~/source/python/issue19995_depr$ ./python -W error Python 3.4.0b1 (default:2f81f0e331f6+, Jan 9 2014, 20:30:18) [GCC 4.7.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> '%x' % 3.14 oxX no __index__ depracation is fatal oxX no __index__ depracation is fatal Traceback (most recent call last): File "", line 1, in DeprecationWarning: automatic int conversions have been deprecated >>> =============================================================================== ethan at media:~/source/python/issue19995_depr$ ./python -W message Invalid -W option ignored: invalid action: 'message' Python 3.4.0b1 (default:2f81f0e331f6+, Jan 9 2014, 20:30:18) [GCC 4.7.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> '%x' % 3.14 oxX no __index__ depracation not fatal, attempting __int__ conversion conversion with __int__ successful '3' >>> =============================================================================== ethan at media:~/source/python/issue19995_depr$ ./python -W once Python 3.4.0b1 (default:2f81f0e331f6+, Jan 9 2014, 20:30:18) [GCC 4.7.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> '%x' % 3.14 oxX no __index__ sys:1: DeprecationWarning: automatic int conversions have been deprecated depracation not fatal, attempting __int__ conversion conversion with __int__ successful '3' >>> =============================================================================== As you can see, with the -W error option it seems to go through the routine twice; does that mean the the '1' in 'line 1' is being specified as a float? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 08:29:10 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Fri, 10 Jan 2014 07:29:10 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1389338950.57.0.33149856625.issue20173@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the patch for sha256. It got the same issue as sha1. After being clinic-ed, the constructor accepts None value happily. ---------- Added file: http://bugs.python.org/file33401/clinic_sha256module.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 09:48:25 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Fri, 10 Jan 2014 08:48:25 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1389343705.69.0.207332882705.issue20173@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the patch for sha512. It got the same issue as sha1. After being clinic-ed, the constructor accepts None value happily. ---------- Added file: http://bugs.python.org/file33402/clinic_sha512module.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 10:29:47 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Fri, 10 Jan 2014 09:29:47 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1389346187.84.0.755520906346.issue20173@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the patch for md5. It got the same issue as sha1. After being clinic-ed, the constructor accepts None value happily. ---------- Added file: http://bugs.python.org/file33403/clinic_md5module.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 10:59:45 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Fri, 10 Jan 2014 09:59:45 +0000 Subject: [issue10388] spwd returning different value depending on privileges In-Reply-To: <1289484192.53.0.424683719192.issue10388@psf.upfronthosting.co.za> Message-ID: <1389347985.73.0.210266456941.issue10388@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the updated patch addressing Giampaolo's concern. ---------- Added file: http://bugs.python.org/file33404/fix_error_message_getspall_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 11:10:47 2014 From: report at bugs.python.org (Boris FELD) Date: Fri, 10 Jan 2014 10:10:47 +0000 Subject: =?utf-8?q?=5Bissue13943=5D_distutils=E2=80=99_build=5Fpy_fails_when_packa?= =?utf-8?q?ge_string_is_unicode?= In-Reply-To: <1328388068.27.0.743003863578.issue13943@psf.upfronthosting.co.za> Message-ID: <1389348647.44.0.140920108529.issue13943@psf.upfronthosting.co.za> Boris FELD added the comment: An issue has been opened in pip repository: https://github.com/pypa/pip/issues/1441 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 11:19:17 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 10 Jan 2014 10:19:17 +0000 Subject: [issue10388] spwd returning different value depending on privileges In-Reply-To: <1289484192.53.0.424683719192.issue10388@psf.upfronthosting.co.za> Message-ID: <1389349157.81.0.50131338643.issue10388@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: LGTM ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 11:21:35 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jan 2014 10:21:35 +0000 Subject: [issue19077] More robust TemporaryDirectory cleanup In-Reply-To: <1379948326.54.0.765934536043.issue19077@psf.upfronthosting.co.za> Message-ID: <1389349295.1.0.12421462312.issue19077@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Excellent, Antoine! Here is a patch for 3.3 with tests based on Antoine's patch. My changes to tests: * TemporaryDirectory instance is preserved as attributes of several modules. So some modules can be destroyed before cleaning up temporary directory. * Resource warning is not checked because the warning module can be destroyed at time of cleaning up temporary directory. ---------- Added file: http://bugs.python.org/file33405/tempfile_tempdir_cleanup_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 11:24:37 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jan 2014 10:24:37 +0000 Subject: [issue10388] spwd returning different value depending on privileges In-Reply-To: <1289484192.53.0.424683719192.issue10388@psf.upfronthosting.co.za> Message-ID: <1389349477.39.0.925161241897.issue10388@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I doubt that we can change behavior at this time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 11:25:22 2014 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Fri, 10 Jan 2014 10:25:22 +0000 Subject: [issue19527] Test failures with COUNT_ALLOCS In-Reply-To: <1383913813.74.0.198352256395.issue19527@psf.upfronthosting.co.za> Message-ID: <1389349522.61.0.395264670338.issue19527@psf.upfronthosting.co.za> Bohuslav "Slavek" Kabrda added the comment: Since 3.4.0.b2, this also causes failures in another tests: test_io, test_logging, test_threading, test_warnings. There are various cases testing that some types get collected when the interpreter shuts down. I'm attaching a new patch that covers all of these. ---------- Added file: http://bugs.python.org/file33406/00141-fix-tests_with_COUNT_ALLOCS-v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 11:28:02 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Jan 2014 10:28:02 +0000 Subject: [issue19527] Test failures with COUNT_ALLOCS In-Reply-To: <1383913813.74.0.198352256395.issue19527@psf.upfronthosting.co.za> Message-ID: <1389349682.18.0.299360995392.issue19527@psf.upfronthosting.co.za> STINNER Victor added the comment: What is COUNT_ALLOCS? Python 3.4 now has sys.getallocatedblocks() and a new tracemalloc module which are compiled by default. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 11:28:05 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 10 Jan 2014 10:28:05 +0000 Subject: [issue10388] spwd returning different value depending on privileges In-Reply-To: <1289484192.53.0.424683719192.issue10388@psf.upfronthosting.co.za> Message-ID: <1389349685.95.0.957483905853.issue10388@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: You mean this should be made in 3.4 only? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 11:29:25 2014 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Fri, 10 Jan 2014 10:29:25 +0000 Subject: [issue19804] test_uuid.TestUUID.test_find_mac() fails In-Reply-To: <1385521168.13.0.486814911092.issue19804@psf.upfronthosting.co.za> Message-ID: <1389349765.07.0.815425784831.issue19804@psf.upfronthosting.co.za> Bohuslav "Slavek" Kabrda added the comment: Attaching a list of files in /usr/sbin in Fedora's minimal buildroot. (Note, that in Fedora /sbin is a symlink to /usr/sbin.) FWIW I can workaround this issue by adding net-tools to BuildRequires, so this is no big pain for me. ---------- Added file: http://bugs.python.org/file33407/usr-sbin-contents _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 11:33:30 2014 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Fri, 10 Jan 2014 10:33:30 +0000 Subject: [issue19527] Test failures with COUNT_ALLOCS In-Reply-To: <1383913813.74.0.198352256395.issue19527@psf.upfronthosting.co.za> Message-ID: <1389350010.61.0.787957293986.issue19527@psf.upfronthosting.co.za> Bohuslav "Slavek" Kabrda added the comment: As noted in Misc/SpecialBuilds: COUNT_ALLOCS ------------ Each type object grows three new members: /* Number of times an object of this type was allocated. */ int tp_allocs; /* Number of times an object of this type was deallocated. */ int tp_frees; /* Highwater mark: the maximum value of tp_allocs - tp_frees so * far; or, IOW, the largest number of objects of this type alive at * the same time. */ int tp_maxalloc; ... We use this for Fedora's python debug build to get some interesting debugging info. (If you try to "grep -r" through Python 3.4 source code, you'll find quite a few ifdefs with COUNT_ALLOCS.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 12:12:48 2014 From: report at bugs.python.org (Philippe Fremy) Date: Fri, 10 Jan 2014 11:12:48 +0000 Subject: [issue19887] Path.resolve() fails on complex symlinks In-Reply-To: <1386190005.89.0.0350896340322.issue19887@psf.upfronthosting.co.za> Message-ID: <1389352368.47.0.576839255267.issue19887@psf.upfronthosting.co.za> Philippe Fremy added the comment: Hi, This precise set of tests fails on Windows 7 on a NTFS partition (on revision c0b0e7aef360+ tip ), see below. The problem is probably minor (drive letter case). I won't be able to develop a fix myself, but I'll be happy to test one. cheers, Philippe ====================================================================== FAIL: test_complex_symlinks_absolute (test.test_pathlib.PathTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "c:\Users\Morgane\Documents\000\Dev\CPython\cpython\lib\test\test_pathlib.py", line 1724, in test_complex_symlinks_absolute self._check_complex_symlinks(BASE) File "c:\Users\Morgane\Documents\000\Dev\CPython\cpython\lib\test\test_pathlib.py", line 1692, in _check_complex_symlinks self.assertEqual(str(p), BASE) AssertionError: 'C:\\Users\\Morgane\\Documents\\000\\Dev\\[53 chars]_tmp' != 'c:\\Users\\Morgane\\Documents\\000\\Dev\\[53 chars]_tmp' - C:\Users\Morgane\Documents\000\Dev\CPython\cpython\build\test_python_6060\@test_6060_tmp ? ^ + c:\Users\Morgane\Documents\000\Dev\CPython\cpython\build\test_python_6060\@test_6060_tmp ? ^ ====================================================================== FAIL: test_complex_symlinks_relative (test.test_pathlib.PathTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "c:\Users\Morgane\Documents\000\Dev\CPython\cpython\lib\test\test_pathlib.py", line 1728, in test_complex_symlinks_relative self._check_complex_symlinks('.') File "c:\Users\Morgane\Documents\000\Dev\CPython\cpython\lib\test\test_pathlib.py", line 1692, in _check_complex_symlinks self.assertEqual(str(p), BASE) AssertionError: 'C:\\Users\\Morgane\\Documents\\000\\Dev\\[53 chars]_tmp' != 'c:\\Users\\Morgane\\Documents\\000\\Dev\\[53 chars]_tmp' - C:\Users\Morgane\Documents\000\Dev\CPython\cpython\build\test_python_6060\@test_6060_tmp ? ^ + c:\Users\Morgane\Documents\000\Dev\CPython\cpython\build\test_python_6060\@test_6060_tmp ? ^ ====================================================================== FAIL: test_complex_symlinks_relative_dot_dot (test.test_pathlib.PathTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "c:\Users\Morgane\Documents\000\Dev\CPython\cpython\lib\test\test_pathlib.py", line 1732, in test_complex_symlinks_relative_dot_dot self._check_complex_symlinks(os.path.join('dirA', '..')) File "c:\Users\Morgane\Documents\000\Dev\CPython\cpython\lib\test\test_pathlib.py", line 1692, in _check_complex_symlinks self.assertEqual(str(p), BASE) AssertionError: 'C:\\Users\\Morgane\\Documents\\000\\Dev\\[53 chars]_tmp' != 'c:\\Users\\Morgane\\Documents\\000\\Dev\\[53 chars]_tmp' - C:\Users\Morgane\Documents\000\Dev\CPython\cpython\build\test_python_6060\@test_6060_tmp ? ^ + c:\Users\Morgane\Documents\000\Dev\CPython\cpython\build\test_python_6060\@test_6060_tmp ? ^ ====================================================================== FAIL: test_complex_symlinks_absolute (test.test_pathlib.WindowsPathTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "c:\Users\Morgane\Documents\000\Dev\CPython\cpython\lib\test\test_pathlib.py", line 1724, in test_complex_symlinks_absolute self._check_complex_symlinks(BASE) File "c:\Users\Morgane\Documents\000\Dev\CPython\cpython\lib\test\test_pathlib.py", line 1692, in _check_complex_symlinks self.assertEqual(str(p), BASE) AssertionError: 'C:\\Users\\Morgane\\Documents\\000\\Dev\\[53 chars]_tmp' != 'c:\\Users\\Morgane\\Documents\\000\\Dev\\[53 chars]_tmp' - C:\Users\Morgane\Documents\000\Dev\CPython\cpython\build\test_python_6060\@test_6060_tmp ? ^ + c:\Users\Morgane\Documents\000\Dev\CPython\cpython\build\test_python_6060\@test_6060_tmp ? ^ ====================================================================== FAIL: test_complex_symlinks_relative (test.test_pathlib.WindowsPathTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "c:\Users\Morgane\Documents\000\Dev\CPython\cpython\lib\test\test_pathlib.py", line 1728, in test_complex_symlinks_relative self._check_complex_symlinks('.') File "c:\Users\Morgane\Documents\000\Dev\CPython\cpython\lib\test\test_pathlib.py", line 1692, in _check_complex_symlinks self.assertEqual(str(p), BASE) AssertionError: 'C:\\Users\\Morgane\\Documents\\000\\Dev\\[53 chars]_tmp' != 'c:\\Users\\Morgane\\Documents\\000\\Dev\\[53 chars]_tmp' - C:\Users\Morgane\Documents\000\Dev\CPython\cpython\build\test_python_6060\@test_6060_tmp ? ^ + c:\Users\Morgane\Documents\000\Dev\CPython\cpython\build\test_python_6060\@test_6060_tmp ? ^ ====================================================================== FAIL: test_complex_symlinks_relative_dot_dot (test.test_pathlib.WindowsPathTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "c:\Users\Morgane\Documents\000\Dev\CPython\cpython\lib\test\test_pathlib.py", line 1732, in test_complex_symlinks_relative_dot_dot self._check_complex_symlinks(os.path.join('dirA', '..')) File "c:\Users\Morgane\Documents\000\Dev\CPython\cpython\lib\test\test_pathlib.py", line 1692, in _check_complex_symlinks self.assertEqual(str(p), BASE) AssertionError: 'C:\\Users\\Morgane\\Documents\\000\\Dev\\[53 chars]_tmp' != 'c:\\Users\\Morgane\\Documents\\000\\Dev\\[53 chars]_tmp' - C:\Users\Morgane\Documents\000\Dev\CPython\cpython\build\test_python_6060\@test_6060_tmp ? ^ + c:\Users\Morgane\Documents\000\Dev\CPython\cpython\build\test_python_6060\@test_6060_tmp ? ^ ---------------------------------------------------------------------- Ran 335 tests in 1.455s FAILED (failures=6, skipped=93) test test_pathlib failed 1 test failed: test_pathlib ---------- nosy: +Bluebird75 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 12:26:50 2014 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Fri, 10 Jan 2014 11:26: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: <1389353210.68.0.603563067958.issue20132@psf.upfronthosting.co.za> Walter D?rwald added the comment: The best solution IMHO would be to implement real incremental codecs for all of those. Maybe iterencode() with an empty iterator should never call encode()? (But IMHO it would be better to document that iterencode()/iterdecode() should only be used with "real" codecs.) Note that the comment before PyUnicode_DecodeUTF7Stateful() in unicodeobject.c reads: /* The decoder. The only state we preserve is our read position, * i.e. how many characters we have consumed. So if we end in the * middle of a shift sequence we have to back off the read position * and the output to the beginning of the sequence, otherwise we lose * all the shift state (seen bits, number of bits seen, high * surrogate). */ Changing that would have to introduce a state object that the codec updates and from which it can be restarted. Also the encoder does not buffer anything. To implement the suggested behaviour, the encoder might have to buffer unlimited data. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 12:41:58 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jan 2014 11:41:58 +0000 Subject: [issue19456] ntpath doesn't join paths correctly when a drive is present In-Reply-To: <1383174757.86.0.861423882665.issue19456@psf.upfronthosting.co.za> Message-ID: <1389354118.14.0.691520879702.issue19456@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If there are no objections, I'll commit this patch tomorrow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 12:42:00 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Jan 2014 11:42:00 +0000 Subject: [issue19886] Better estimated memory requirements for bigmem tests In-Reply-To: <1386185413.56.0.459107954756.issue19886@psf.upfronthosting.co.za> Message-ID: <3f12NR1pt3z7Lkr@mail.python.org> Roundup Robot added the comment: New changeset aee672ba9c38 by Serhiy Storchaka in branch '2.7': Issue #19886: Use better estimated memory requirements for bigmem tests. http://hg.python.org/cpython/rev/aee672ba9c38 New changeset 2ca26065fb00 by Serhiy Storchaka in branch '3.3': Issue #19886: Use better estimated memory requirements for bigmem tests. http://hg.python.org/cpython/rev/2ca26065fb00 New changeset fff1455e1147 by Serhiy Storchaka in branch 'default': Issue #19886: Use better estimated memory requirements for bigmem tests. http://hg.python.org/cpython/rev/fff1455e1147 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 12:44:24 2014 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Fri, 10 Jan 2014 11:44:24 +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: <1389354264.36.0.977488282601.issue13881@psf.upfronthosting.co.za> Walter D?rwald added the comment: The stream part of the codecs isn't used that much in Python 3 any more, so I'm not sure if this is worth fixing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 12:48:48 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 10 Jan 2014 11:48:48 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1389354528.5.0.508802313775.issue20172@psf.upfronthosting.co.za> Larry Hastings added the comment: 1) When I wrote that I hadn't considered that people would want custom subclasses of ints. I assumed they'd be using custom converter *functions*, which of course means they'd use 'O&'. I can think of how to reword the text but for now I assume your approach for REGSAM is fine; certainly I approve of using the correct type in the generated code. However, I doubt doc_default, py_default, and c_default should all be exactly the same. And the 'key_name' parameter seems a little awkward. Here's something you could consider: I don't think it's documented yet (I'm going as fast as I can over here, honest) but now you can use simple constants as Python defaults. So maybe you can use REGSAM like this: arg: REGSAM(c_default='KEY_READ') = winreg.KEY_READ and then REGSAM could simply be an empty ("pass") subclass of int_converter. 2) No convenient way yet. Let me think about it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 12:50:32 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jan 2014 11:50:32 +0000 Subject: [issue19886] Better estimated memory requirements for bigmem tests In-Reply-To: <1386185413.56.0.459107954756.issue19886@psf.upfronthosting.co.za> Message-ID: <1389354632.91.0.822249210941.issue19886@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I never decreased requirements, so these changes shouldn't cause regressions. ---------- assignee: -> serhiy.storchaka stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 13:00:57 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jan 2014 12:00:57 +0000 Subject: [issue10388] spwd returning different value depending on privileges In-Reply-To: <1389349685.95.0.957483905853.issue10388@psf.upfronthosting.co.za> Message-ID: <2152076.OPfdhHQAKs@raxxla> Serhiy Storchaka added the comment: Even for 3.4 it looks too late. But I afraid we can't change this behavior never. Users of spwd don't expect any exception, raising an exception will break any existing code. Only one safe way is design new API and deprecate old API. This will be great refactoring, it should also change APIs of the pwd and grp modules, perhaps these three modules should be merged, perhaps we should cross-platform API (available on Windows). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 13:59:29 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jan 2014 12:59:29 +0000 Subject: [issue19804] test_uuid.TestUUID.test_find_mac() fails In-Reply-To: <1385521168.13.0.486814911092.issue19804@psf.upfronthosting.co.za> Message-ID: <1389358769.4.0.0911073965876.issue19804@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Bohuslav. Unfortunately I don't see good replacement for ifconfig, any of these executables can be absent (e.g. chroot can be built in BusyBox). So I'll left ifconfig and adds checks for its accessibility. You can workaround this issue by adding an executable with name ifconfig to your PATH. For example: bin_for_test_uuid="$HOME/bin_for_test_uuid" mkdir "$bin_for_test_uuid" ln -s /bin/true "$bin_for_test_uuid/ifconfig" export PATH="$PATH:$bin_for_test_uuid" ./python -m test.regrtest test_uuid ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 14:11:38 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Jan 2014 13:11:38 +0000 Subject: [issue19804] test_uuid.TestUUID.test_find_mac() fails In-Reply-To: <1385521168.13.0.486814911092.issue19804@psf.upfronthosting.co.za> Message-ID: <3f14Ms3QHzz7LjN@mail.python.org> Roundup Robot added the comment: New changeset 34ae4333d3bf by Serhiy Storchaka in branch '2.7': Issue #19804: The test_find_mac test in test_uuid is now skipped if the http://hg.python.org/cpython/rev/34ae4333d3bf New changeset 201077b57fe0 by Serhiy Storchaka in branch '3.3': Issue #19804: The test_find_mac test in test_uuid is now skipped if the http://hg.python.org/cpython/rev/201077b57fe0 New changeset 51dc9b2a5b35 by Serhiy Storchaka in branch 'default': Issue #19804: The test_find_mac test in test_uuid is now skipped if the http://hg.python.org/cpython/rev/51dc9b2a5b35 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 14:35:34 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Jan 2014 13:35:34 +0000 Subject: [issue20086] test_locale fails on PPC64 PowerLinux In-Reply-To: <1388221219.09.0.925570468901.issue20086@psf.upfronthosting.co.za> Message-ID: <3f14vT44j5z7Ljg@mail.python.org> Roundup Robot added the comment: New changeset 3696b9ae6b17 by Serhiy Storchaka in branch '2.7': Issue #20086: Output more details when test_getsetlocale_issue1813 is failed. http://hg.python.org/cpython/rev/3696b9ae6b17 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 14:47:12 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 10 Jan 2014 13:47:12 +0000 Subject: [issue10388] spwd returning different value depending on privileges In-Reply-To: <1289484192.53.0.424683719192.issue10388@psf.upfronthosting.co.za> Message-ID: <1389361632.19.0.214114504823.issue10388@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: I can agree with you that it's probably better to avoid changing existent python versions to avoid breakage but I see no need to be that strict for newer ones. Current version should check errno but it doesn't. IMO that is clearly a bug. Same goes for returning an empty list when users actually exists and for *not* raising FileNotFoundError if the shadow file is not available. Also note that the doc does not mention that an empty list should be treated as an alias for "insufficient permissions" or "shadow file not available", therefore whoever made that assumption is someone who deliberately and erroneously decided to do so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 14:55:24 2014 From: report at bugs.python.org (Rodrigo Bernardo Pimentel) Date: Fri, 10 Jan 2014 13:55:24 +0000 Subject: [issue20208] Clarify some things in porting HOWTO In-Reply-To: <1389287437.04.0.882737818643.issue20208@psf.upfronthosting.co.za> Message-ID: <1389362124.86.0.710095596481.issue20208@psf.upfronthosting.co.za> Rodrigo Bernardo Pimentel added the comment: I've created a patch that addresses the first criticism (explaining unicode_literals), as well as the first mention of print_function. It also addresses a small concern regarding "map", which I've mentioned in my G+ comment: """ Also, a friend was confused by http://docs.python.org/dev/howto/pyporting.html#update-map-for-imbalanced-input-sequences , until I understood that he didn't know map can take several sequences. I assume a lot of less experienced Python programmers only use map with a single sequence, and might be confused as well. A sentence mentioning that might help. """ I see that the current version of the doc on hg already addresses the 2to3 mention. ---------- keywords: +patch nosy: +rbp Added file: http://bugs.python.org/file33408/pyporting.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 14:57:32 2014 From: report at bugs.python.org (Rodrigo Bernardo Pimentel) Date: Fri, 10 Jan 2014 13:57:32 +0000 Subject: [issue20208] Clarify some things in porting HOWTO In-Reply-To: <1389287437.04.0.882737818643.issue20208@psf.upfronthosting.co.za> Message-ID: <1389362252.24.0.393023919581.issue20208@psf.upfronthosting.co.za> Rodrigo Bernardo Pimentel added the comment: BTW, there remains another concern I mentioned on G+: """ A note on formatting: I found some of 4th- and 5th-level headings too subtle. For instance, http://docs.python.org/dev/howto/pyporting.html#from-future-import-absolute-import got me thinking for a second if it was part of the previous paragraph or a new heading. Maybe underlining, or a bullet-like marker, or some indentation could help there.? """ But I don't know enough of the formatting standards, so I haven't addressed this in the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 15:23:46 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 10 Jan 2014 14:23:46 +0000 Subject: [issue10388] spwd returning different value depending on privileges In-Reply-To: <1289484192.53.0.424683719192.issue10388@psf.upfronthosting.co.za> Message-ID: <1389363826.61.0.850194783001.issue10388@psf.upfronthosting.co.za> R. David Murray added the comment: I think that a new cross platform API would be great, but I don't think that fixing this bug should wait for that. It may be borderline for being changed in a feature release (and definitely should not be changed in a maintenance release), but I think it would be OK. Mostly likely a program that uses spwd will also be using other root-only functions and already be producing other errors if run as a non-privileged user. The file-doesn't-exist case is a little more concerning, but my guess is that anyone actually checking for an empty return (as opposed to their program just failing when it gets one) would actually welcome the change, since it will give a more specific error message. Or, to put it another way, I think the negative impact of this in a feature release will be low enough that we won't take much if any flak for it :) ---------- components: +Library (Lib) nosy: +r.david.murray type: -> behavior versions: +Python 3.5 -Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 15:24:29 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 10 Jan 2014 14:24:29 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1389363869.92.0.108132930531.issue20172@psf.upfronthosting.co.za> Zachary Ware added the comment: Ahhhh, much better. An empty subclass doesn't do quite the right thing, but `class REGSAM_converter(int_converter): type = 'REGSAM'` does the trick (see http://hg.python.org/sandbox/zware/rev/5af08aa49631). Thanks, Larry! (Next will probably be trying to get a proper HKEY converter to work, but I'm holding off on that until I have most everything else clinicized first.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 15:54:54 2014 From: report at bugs.python.org (Phil Connell) Date: Fri, 10 Jan 2014 14:54:54 +0000 Subject: [issue20217] Build failure in posixmodule.c with SCHED_SPORADIC available Message-ID: <1389365694.87.0.154432824669.issue20217@psf.upfronthosting.co.za> New submission from Phil Connell: Typo in revision 71704 that causes build failures on systems with SCHED_SPORADIC available. See attached patch. (Can reproduce by #defining SCHED_SPORADIC just above where it's used in posixmodule.c) ---------- components: Extension Modules files: sched_sporadic_build.diff keywords: patch messages: 207865 nosy: benjamin.peterson, isoschiz, pconnell priority: normal severity: normal status: open title: Build failure in posixmodule.c with SCHED_SPORADIC available versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33409/sched_sporadic_build.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 15:55:55 2014 From: report at bugs.python.org (Phil Connell) Date: Fri, 10 Jan 2014 14:55:55 +0000 Subject: [issue20217] Build failure in posixmodule.c with SCHED_SPORADIC available In-Reply-To: <1389365694.87.0.154432824669.issue20217@psf.upfronthosting.co.za> Message-ID: <1389365755.22.0.132243130908.issue20217@psf.upfronthosting.co.za> Phil Connell added the comment: Where I actually mean changeset 71704:89e92e684b37 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 16:20:34 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 10 Jan 2014 15:20:34 +0000 Subject: [issue20217] Build failure in posixmodule.c with SCHED_SPORADIC available In-Reply-To: <1389365694.87.0.154432824669.issue20217@psf.upfronthosting.co.za> Message-ID: <1389367234.22.0.337120370721.issue20217@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Congratulations on having a system with SCHED_SPORADIC defined. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 16:25:07 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 10 Jan 2014 15:25:07 +0000 Subject: [issue20217] Build failure in posixmodule.c with SCHED_SPORADIC available In-Reply-To: <1389365694.87.0.154432824669.issue20217@psf.upfronthosting.co.za> Message-ID: <1389367507.11.0.344463611694.issue20217@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 16:25:13 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Jan 2014 15:25:13 +0000 Subject: [issue20217] Build failure in posixmodule.c with SCHED_SPORADIC available In-Reply-To: <1389365694.87.0.154432824669.issue20217@psf.upfronthosting.co.za> Message-ID: <3f17L045ltz7LlX@mail.python.org> Roundup Robot added the comment: New changeset 4f74ea7eba03 by Benjamin Peterson in branch '3.3': fix build when SCHED_SPORADIC is defined (closes #20217) http://hg.python.org/cpython/rev/4f74ea7eba03 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 16:34:43 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 10 Jan 2014 15:34:43 +0000 Subject: [issue20208] Clarify some things in porting HOWTO In-Reply-To: <1389287437.04.0.882737818643.issue20208@psf.upfronthosting.co.za> Message-ID: <1389368083.89.0.370413782451.issue20208@psf.upfronthosting.co.za> Brett Cannon added the comment: There's actually no way to tweak that formatting as that is all done by Sphinx automatically. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 18:09:33 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jan 2014 17:09:33 +0000 Subject: [issue20086] test_locale fails on PPC64 PowerLinux In-Reply-To: <1388221219.09.0.925570468901.issue20086@psf.upfronthosting.co.za> Message-ID: <1389373773.69.0.512459410281.issue20086@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Detailed output: http://buildbot.python.org/all/builders/PPC64%20PowerLinux%202.7/builds/415/steps/test/logs/stdio ====================================================================== FAIL: test_getsetlocale_issue1813 (test.test_locale.TestMiscellaneous) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/shager/cpython-buildarea/2.7.edelsohn-powerlinux-ppc64/build/Lib/test/test_locale.py", line 484, in test_getsetlocale_issue1813 (loc, oldlocale, e)) AssertionError: Failed to set locale ('tr_TR', 'ISO8859-9') (default locale is (None, None)): Error('unsupported locale setting',) ---------------------------------------------------------------------- locale.getlocale() calls _parse_localename() which uses normalize() which maps 'tr_TR' to 'tr_TR.ISO8859-9' with according to locale_alias table. However on this platform tr_TR.ISO8859-9 doesn't not exist, only tr_TR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 18:16:05 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jan 2014 17:16:05 +0000 Subject: [issue17825] Indentation.offset and SyntaxError.offset mismatch In-Reply-To: <1366789582.23.0.0218552351895.issue17825@psf.upfronthosting.co.za> Message-ID: <1389374165.03.0.978924750335.issue17825@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Florent, can you commit your patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 18:51:03 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 10 Jan 2014 17:51:03 +0000 Subject: [issue20209] Deprecate PROTOCOL_SSLv2 In-Reply-To: <1389288239.29.0.63100261927.issue20209@psf.upfronthosting.co.za> Message-ID: <1389376263.63.0.146980331401.issue20209@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +hynek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 19:22:35 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 Jan 2014 18:22:35 +0000 Subject: [issue20115] NUL bytes in commented lines In-Reply-To: <1388771953.42.0.332804570753.issue20115@psf.upfronthosting.co.za> Message-ID: <1389378155.4.0.678381113068.issue20115@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Python should have a uniform definition of 'Python source' in both the doc and in practice in all source code processing functions. Currently, "2. Lexical analysis" in the Language Manual just says "Python reads program text as Unicode code points; the encoding of a source file can be given by an encoding declaration and defaults to UTF-8." UTF-8 encodes code point U+0000 as a null byte and this code point is nowhere excluded in the doc. (The definition of string literals uses 'source character' without any additional specification, so I take it to mean 'Unicode code point'.) If U+0000 is a legal 'source character', it, as with other control chars not given special meaning, should be a SyntaxError unless occurring in a comment or string literal. Eval and exec exclude even the latter with TypeError: source code string cannot contain null bytes If null bytes are legal, this is wrong. Simply truncating lines as done by the CPython parser is wrong whether not not U+0000 is legal. The simplest change would be to change the parser to match exec and add " other than U+000" after "Unicode code points" in the sentence quoted above. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 19:23:40 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 Jan 2014 18:23:40 +0000 Subject: [issue20115] NUL bytes in commented lines In-Reply-To: <1388771953.42.0.332804570753.issue20115@psf.upfronthosting.co.za> Message-ID: <1389378220.89.0.637459279615.issue20115@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Armin, what is the different behavior of PyPy? We should perhaps get Guido's opinion on this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 20:04:53 2014 From: report at bugs.python.org (Ram Rachum) Date: Fri, 10 Jan 2014 19:04:53 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` Message-ID: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> New submission from Ram Rachum: I'd really like to have methods `pathlib.Path.write` and `pathlib.Path.read`. Untested implementation: def read(self, binary=False): with self.open('br' is binary else 'r') as file: return file.read() def write(self, data. binary=False): with self.open('bw' is binary else 'w') as file: file.write(data) This will be super useful to me. Many files actions are one liners like that, and avoiding putting the `with` clause in user code would be wonderful. Antoine suggests that `binary` shouldn't be an argument, that there should be separate methods for reading/writing text and binary contents, and that the text one would require passing in encoding and other parameters. I'll be happy to add these to the implementation and create a patch, once people can define which parameters should be used. ---------- components: Library (Lib) messages: 207874 nosy: cool-RR priority: normal severity: normal status: open title: Add `pathlib.Path.write` and `pathlib.Path.read` type: enhancement versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 20:40:39 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jan 2014 19:40:39 +0000 Subject: [issue8260] When I use codecs.open(...) and f.readline() follow up by f.read() return bad result In-Reply-To: <1269875395.81.0.132261115225.issue8260@psf.upfronthosting.co.za> Message-ID: <1389382839.01.0.17646511657.issue8260@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is revised patch. * Behavior is changed less. read() is less greedy and uses characters from the buffer when read() is called with only one argument (size). It is now a little closer to io stream's read() than with previous patch. * Added tests for cases of issue12446 and issue16636. * Fixed read() for for the TransformCodecTest.test_read test added in 3.4. Actually the uu_codec and zlib_codec are broken. ---------- versions: -Python 3.2 Added file: http://bugs.python.org/file33410/codecs_read-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 20:42:02 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 10 Jan 2014 19:42:02 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1389382922.56.0.761008763965.issue20172@psf.upfronthosting.co.za> Changes by Zachary Ware : Added file: http://bugs.python.org/file33411/f2192566eefd.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 20:43:06 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 10 Jan 2014 19:43:06 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1389382986.24.0.846234174008.issue20172@psf.upfronthosting.co.za> Changes by Zachary Ware : Removed file: http://bugs.python.org/file33367/issue20172.partial.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 20:44:15 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jan 2014 19:44:15 +0000 Subject: [issue18960] First line can be executed twice In-Reply-To: <1378559493.77.0.649785663787.issue18960@psf.upfronthosting.co.za> Message-ID: <1389383055.77.0.751956440273.issue18960@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 20:55:24 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 10 Jan 2014 19:55:24 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1389383724.62.0.0959269080002.issue20172@psf.upfronthosting.co.za> Zachary Ware added the comment: Here's the complete patch for PC/winreg.c. One clinic/signature/pydoc issue I've noticed: >>> help(winreg.HKEYType.Close) Help on method_descriptor: Close(...) <--- No signature Close() <--- Extra Closes the underlying Windows handle. If the handle is already closed, no error is raised. >>> winreg.HKEYType.Close.__doc__ 'Close()\nCloses the underlying Windows handle.\n\nIf the handle is already clos ed, no error is raised.' >>> winreg.HKEYType.Close.__text_signature__ Traceback (most recent call last): File "", line 1, in AttributeError: 'method_descriptor' object has no attribute '__text_signature__' My gut feeling is that it's a Clinic issue; Clinic should be adding 'self' to the signature, which should then be picked up by the __text_signature__ parser, and used by inspect and pydoc. As far as the patch, one point I'd like some extra scrutiny on is the HKEY_converter (and C clinic_HKEY_converter). I don't understand how all of the C machinery there works properly, so I can't say with confidence that it is right. It compiles without errors and the tests pass, but beyond that, I can't guarantee anything. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 20:55:57 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 10 Jan 2014 19:55:57 +0000 Subject: [issue20219] ElementTree: allow passing XMLPullParser instance into iterparse() Message-ID: <1389383757.8.0.892188011748.issue20219@psf.upfronthosting.co.za> New submission from Stefan Behnel: in the XMLPullParser ticket http://bugs.python.org/issue17741 specifically here: http://bugs.python.org/msg196177 it says: """ * [The pull parser] will *not* accept a "parser" argument in the constructor. Rationale: the parser argument of iterparse is broken anyway. This will make it much easier to modify the implementation of EventParser in the future when the C internals are fixed w.r.t problems mentioned in this issue. * iterparse's "parser" argument will be deprecated, and the documentation will be more detailed w.r.t to the limitations on its current "parser" argument (the limitations are there in the code, but they're not fully documented). """ And the "parser" argument to iterparse is now deprecated, according to the docs: http://docs.python.org/3.4/library/xml.etree.elementtree.html#xml.etree.ElementTree.iterparse In lxml, however, I'm noticing that it would be really helpful to pass a pull parser into iterparse(). Essentially, iterparse() is now stripped down to a wrapper around the pull parser(s: XML/HTML in lxml) that simply serves the feeding side of the interface for the user's convenience. Note that lxml's iterparse() never had a "parser" argument. That's for historical reasons, because it originally *was* a parser itself, but it no longer is now. I'd like to allow passing pull parsers into iterparse(), so that users can configure them on their own. Currently, iterparse() must duplicate basically all of the parser configuration arguments. I'd like to deprecate that in lxml and replace it with the same simple interface as in ET, i.e. pass in *either* a set of events *or* a readily configured pull parser. Preferably raising an error if users pass both. Could we change the deprecation from "argument is deprecated" to "passing a normal (non-pull) parser into iterparse is deprecated", and then allow passing a pull parser in the future? ---------- components: Library (Lib), XML messages: 207877 nosy: eli.bendersky, scoder priority: normal severity: normal status: open title: ElementTree: allow passing XMLPullParser instance into iterparse() type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 21:04:33 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jan 2014 20:04:33 +0000 Subject: [issue20220] TarFile.list() outputs wrong time Message-ID: <1389384273.4.0.330615086279.issue20220@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: TarFile.list() outputs a time exactly 6 hours back from expected. http://buildbot.python.org/all/builders/System%20Z%20Linux%203.x/builds/1023/steps/test/logs/stdio ====================================================================== FAIL: test_list_command_verbose (test.test_tarfile.CommandLineTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dje/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/test/test_tarfile.py", line 1797, in test_list_command_verbose self.assertEqual(out, expected) AssertionError: b'?rw[36 chars]-22 12:34:43 tokenize_tests.txt \n?rw------- d[96 chars]t \n' != b'?rw[36 chars]-22 18:34:43 tokenize_tests.txt \n?rw------- d[96 chars]t \n' ---------------------------------------------------------------------- ---------- components: Library (Lib) messages: 207878 nosy: lars.gustaebel, serhiy.storchaka priority: normal severity: normal status: open title: TarFile.list() outputs wrong time type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 21:14:14 2014 From: report at bugs.python.org (Armin Rigo) Date: Fri, 10 Jan 2014 20:14:14 +0000 Subject: [issue20115] NUL bytes in commented lines In-Reply-To: <1388771953.42.0.332804570753.issue20115@psf.upfronthosting.co.za> Message-ID: <1389384854.01.0.164173368604.issue20115@psf.upfronthosting.co.za> Armin Rigo added the comment: PyPy 2.x accepts null characters in all of import, exec and eval, and complains if they occur in non-comment. PyPy 3.x refuses them in import, which is where this bug report originally comes from (someone complained that CPython 3.x "accepts" them but not PyPy 3.x, even thought this complain doesn't really make sense as CPython just gets very confused by them). I don't know about exec and eval. We need a consistent decision for 3.5. I suppose it's not really worth backporting it to CPython 2.7 - 3.3 - 3.4, but it's your choice. PyPy will just follow the lead (or keep its current behavior for 2.x if CPython 2.x is not modified). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 21:27:08 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Fri, 10 Jan 2014 20:27:08 +0000 Subject: [issue20201] Argument Clinic: rwbuffer support broken In-Reply-To: <1389242396.52.0.166931579233.issue20201@psf.upfronthosting.co.za> Message-ID: <1389385628.87.0.455743473337.issue20201@psf.upfronthosting.co.za> Ryan Smith-Roberts added the comment: Accepts only a writable bytearray, when the function needs to mutate-in-place. The rw_buffer support is for PyPy I guess. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 21:35:14 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 10 Jan 2014 20:35:14 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1389386114.12.0.48168235893.issue20172@psf.upfronthosting.co.za> Zachary Ware added the comment: PC/winsound.c went pretty quick and easy. ---------- Added file: http://bugs.python.org/file33412/issue20172.winsound.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 22:01:25 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jan 2014 21:01:25 +0000 Subject: [issue20086] test_locale fails on PPC64 PowerLinux In-Reply-To: <1388221219.09.0.925570468901.issue20086@psf.upfronthosting.co.za> Message-ID: <1389387685.4.0.848522954315.issue20086@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This bug is occured not only on PPC64 PowerLinux. See also: http://buildbot.python.org/all/builders/x86%20RHEL%206%202.7/builds/975/steps/test/logs/stdio http://buildbot.python.org/all/builders/AMD64%20Fedora%20without%20threads%202.7/builds/1644/steps/test/logs/stdio ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 22:02:47 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jan 2014 21:02:47 +0000 Subject: [issue20086] test_locale fails with Turkish locale In-Reply-To: <1388221219.09.0.925570468901.issue20086@psf.upfronthosting.co.za> Message-ID: <1389387767.51.0.64722376117.issue20086@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- title: test_locale fails on PPC64 PowerLinux -> test_locale fails with Turkish locale _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 22:19:58 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 10 Jan 2014 21:19:58 +0000 Subject: [issue20086] test_locale fails with Turkish locale In-Reply-To: <1388221219.09.0.925570468901.issue20086@psf.upfronthosting.co.za> Message-ID: <1389388798.76.0.66904098345.issue20086@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 22:21:40 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jan 2014 21:21:40 +0000 Subject: [issue19320] Tkinter tests ran with wantobjects is false In-Reply-To: <1382302056.06.0.500513298536.issue19320@psf.upfronthosting.co.za> Message-ID: <1389388900.48.0.317125006008.issue19320@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Unfortunately they are still red: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%202.7/builds/1020/steps/test/logs/stdio ====================================================================== FAIL: test_split (test.test_tcl.TclTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\buildbot.python.org\2.7.kloth-win64\build\lib\test\test_tcl.py", line 283, in test_split self.assertEqual(split(arg), res) AssertionError: Tuples differ: ('12', u'\u20ac', u'\u20ac', '... != (12, u'\u20ac', u'\u20ac', (3.... First differing element 0: 12 12 - ('12', u'\u20ac', u'\u20ac', '3.4') ? - - ^ ^ + (12, u'\u20ac', u'\u20ac', (3.4,)) ? ^ ^ + ====================================================================== FAIL: test_splitlist (test.test_tcl.TclTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\buildbot.python.org\2.7.kloth-win64\build\lib\test\test_tcl.py", line 243, in test_splitlist self.assertEqual(splitlist(arg), res) AssertionError: Tuples differ: ('1', u'\u20ac', u'\u20ac', '3... != (1, u'\u20ac', u'\u20ac', (3.4... First differing element 0: 1 1 - ('1', u'\u20ac', u'\u20ac', '3.4') ? - - ^ ^ + (1, u'\u20ac', u'\u20ac', (3.4,)) ? ^ ^ + ---------------------------------------------------------------------- http://buildbot.python.org/all/builders/x86%20Windows%20Server%202003%20%5BSB%5D%202.7/builds/787/steps/test/logs/stdio http://buildbot.python.org/all/builders/AMD64%20Windows%20Server%202008%20%5BSB%5D%202.7/builds/865/steps/test/logs/stdio All they are run with Tcl/Tk 8.5.2. ---------- resolution: fixed -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 22:21:54 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jan 2014 21:21:54 +0000 Subject: [issue19320] Tkinter tests ran with wantobjects is false In-Reply-To: <1382302056.06.0.500513298536.issue19320@psf.upfronthosting.co.za> Message-ID: <1389388914.31.0.440086512938.issue19320@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 22:56:30 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jan 2014 21:56:30 +0000 Subject: [issue20072] Ttk tests fail when wantobjects is false In-Reply-To: <1388082006.36.0.0879597768975.issue20072@psf.upfronthosting.co.za> Message-ID: <1389390990.63.0.298150228792.issue20072@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 23:29:14 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 10 Jan 2014 22:29:14 +0000 Subject: [issue20086] test_locale fails with Turkish locale In-Reply-To: <1388221219.09.0.925570468901.issue20086@psf.upfronthosting.co.za> Message-ID: <1389392954.8.0.281834103136.issue20086@psf.upfronthosting.co.za> Stefan Krah added the comment: 3d805bee06e2 uses str.lower(), which fails on the Turkish 'i' if the Turkish locale is set: Python 2.7.6+ (2.7:0e5df5b62488+, Jan 10 2014, 23:25:35) [GCC 4.6.3 20120306 (Red Hat 4.6.3-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.setlocale(locale.LC_CTYPE, ('tr_TR', 'ISO8859-9')) 'tr_TR.ISO8859-9' >>> 'tr_TR.ISO8859-9'.lower() 'tr_tr.\xfdso8859-9' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 23:42:37 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 Jan 2014 22:42:37 +0000 Subject: [issue20119] pdb c(ont(inue)) optional one-time-only breakpoint (like perl debugger) In-Reply-To: <1388808811.19.0.853662131976.issue20119@psf.upfronthosting.co.za> Message-ID: <1389393757.82.0.167825363829.issue20119@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: -> test needed versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 23:43:50 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 10 Jan 2014 22:43:50 +0000 Subject: [issue20086] test_locale fails with Turkish locale In-Reply-To: <1388221219.09.0.925570468901.issue20086@psf.upfronthosting.co.za> Message-ID: <1389393830.8.0.871698410053.issue20086@psf.upfronthosting.co.za> Stefan Krah added the comment: I'm not sure if str.lower() is supposed to use tolower() in stringobject.c. If tolower() is replaced by Py_TOLOWER(), the problem disappears. But maybe the locale dependent tolower() is used on purpose. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 23:44:06 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 Jan 2014 22:44:06 +0000 Subject: [issue20131] warnings module offers no documented, programmatic way to reset "seen-warning" flag In-Reply-To: <1388925569.4.0.616104920228.issue20131@psf.upfronthosting.co.za> Message-ID: <1389393846.21.0.13559333369.issue20131@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 23:46:19 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 Jan 2014 22:46:19 +0000 Subject: [issue20135] FAQ need list mutation answers In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za> Message-ID: <1389393979.32.0.201754368192.issue20135@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: -> needs patch title: mutate list -> FAQ need list mutation answers _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 23:49:08 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 10 Jan 2014 22:49:08 +0000 Subject: [issue20086] test_locale fails with Turkish locale In-Reply-To: <1389393830.8.0.871698410053.issue20086@psf.upfronthosting.co.za> Message-ID: <20140110224907.GA12589@sleipnir.bytereef.org> Stefan Krah added the comment: Ignore me, the fine manual says that "For 8-bit strings, this method is locale-dependent." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 23:53:36 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 Jan 2014 22:53:36 +0000 Subject: [issue20138] wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode In-Reply-To: <1389001619.16.0.909145148031.issue20138@psf.upfronthosting.co.za> Message-ID: <1389394416.53.0.289750631746.issue20138@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Which version and bugfix release are you using? What is werkzeug and what does it have to do with stdlib urllib? An stdlib test cannot depend on 3rd party code. ---------- nosy: +terry.reedy stage: -> test needed type: -> behavior versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 10 23:59:49 2014 From: report at bugs.python.org (Armin Ronacher) Date: Fri, 10 Jan 2014 22:59:49 +0000 Subject: [issue20138] wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode In-Reply-To: <1389001619.16.0.909145148031.issue20138@psf.upfronthosting.co.za> Message-ID: <1389394789.54.0.176269417167.issue20138@psf.upfronthosting.co.za> Armin Ronacher added the comment: > Which version and bugfix release are you using? You can reproduce it against the current development version of Python 3. > What is werkzeug and what does it have to do with stdlib urllib? Werkzeug is a WSGI implementation. > An stdlib test cannot depend on 3rd party code. That's why the output values are in the clear so you can remove the werkzeug specific parts. url_unquote can be replaced with urllib.parse.unquote. None of that is relevant to the issue here though. It was just to show that the standard library is currently in violation to PEP 3333. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 00:03:47 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jan 2014 23:03:47 +0000 Subject: [issue20086] test_locale fails with Turkish locale In-Reply-To: <1388221219.09.0.925570468901.issue20086@psf.upfronthosting.co.za> Message-ID: <1389395027.82.0.475102454268.issue20086@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Good catch, Stefan! Here is a patch which restores old behavior. It also changes test_locale to try several Turkish locale names. On some platforms (as Ubuntu) bare tr_TR is not exist, but only tr_TK.utf8. This will increase chance for this test to run. ---------- assignee: -> serhiy.storchaka keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file33413/locale_tr_TR.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 00:13:08 2014 From: report at bugs.python.org (Armin Ronacher) Date: Fri, 10 Jan 2014 23:13:08 +0000 Subject: [issue20138] wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode In-Reply-To: <1389001619.16.0.909145148031.issue20138@psf.upfronthosting.co.za> Message-ID: <1389395588.12.0.261537588672.issue20138@psf.upfronthosting.co.za> Armin Ronacher added the comment: What it currently returns: >>> from wsgiref.util import request_uri >>> request_uri({ ... 'wsgi.url_scheme': 'http', ... 'SCRIPT_NAME': '', ... 'PATH_INFO': '/\xe2\x98\x83', ... 'SERVER_PORT': '80', ... 'SERVER_NAME': 'localhost' ... }) 'http://localhost/%C3%A2%C2%98%C2%83' What it should return: 'http://localhost/%E2%98%83' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 00:31:43 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jan 2014 23:31:43 +0000 Subject: [issue20138] wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode In-Reply-To: <1389001619.16.0.909145148031.issue20138@psf.upfronthosting.co.za> Message-ID: <1389396703.74.0.294298759381.issue20138@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please show us the value of env? Perhaps it is werkzeug creates wrongly quoted URL. request_uri() just calls urllib.parse.quote() which works good. >>> from urllib.parse import quote, unquote >>> quote('/\N{SNOWMAN}') '/%E2%98%83' >>> unquote('/%E2%98%83') == '/\N{SNOWMAN}' True Your result looks as >>> quote('/\N{SNOWMAN}'.encode().decode('latin1')) '/%C3%A2%C2%98%C2%83' ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 00:49:46 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jan 2014 23:49:46 +0000 Subject: [issue20138] wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode In-Reply-To: <1389001619.16.0.909145148031.issue20138@psf.upfronthosting.co.za> Message-ID: <1389397786.0.0.0670834590335.issue20138@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: >>> from wsgiref.util import request_uri >>> request_uri({ ... 'wsgi.url_scheme': 'http', ... 'SCRIPT_NAME': '', ... 'PATH_INFO': '/\N{SNOWMAN}', ... 'SERVER_PORT': '80', ... 'SERVER_NAME': 'localhost' ... }) 'http://localhost/%E2%98%83' >>> request_uri({ ... 'wsgi.url_scheme': 'http', ... 'SCRIPT_NAME': '', ... 'PATH_INFO': b'/\xe2\x98\x83', ... 'SERVER_PORT': '80', ... 'SERVER_NAME': 'localhost' ... }) 'http://localhost/%E2%98%83' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 00:56:01 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Jan 2014 23:56:01 +0000 Subject: [issue20138] wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode In-Reply-To: <1389001619.16.0.909145148031.issue20138@psf.upfronthosting.co.za> Message-ID: <1389398161.24.0.467249911383.issue20138@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 01:43:38 2014 From: report at bugs.python.org (Brian Quinlan) Date: Sat, 11 Jan 2014 00:43:38 +0000 Subject: [issue14119] Ability to adjust queue size in Executors In-Reply-To: <1330129142.34.0.452763799677.issue14119@psf.upfronthosting.co.za> Message-ID: <1389401018.42.0.973153014165.issue14119@psf.upfronthosting.co.za> Brian Quinlan added the comment: Can't you accomplish what you want using add_done_callback? e.g. # Pseudocode class MyExecutor(ThreadPoolExecutor): def __init__(self): self._count = 0 def _decrement(self): with self._some_lock: self._count -= 1 def submit(self, fn, *args, **kwargs): f = super(self).submit(fn, *args, **kwargs) with self._some_lock: self._count += 1 f.add_done_callback(self._decrement) @property def num_pending_futures(self): return self._count ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 04:09:29 2014 From: report at bugs.python.org (Tabrez Mohammed) Date: Sat, 11 Jan 2014 03:09:29 +0000 Subject: [issue20221] #define hypot _hypot conflicts with existing definition Message-ID: <1389409768.81.0.962130999427.issue20221@psf.upfronthosting.co.za> New submission from Tabrez Mohammed: In pyconfig.h (line 216), there is this line: #define hypot _hypot This conflicts with the definition of _hypot that ships with VS2010 (math.h, line 161): static __inline double __CRTDECL hypot(_In_ double _X, _In_ double _Y) The result of the redefinition is that the following warning occurs during compilation: 1>c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\math.h(162): warning C4211: nonstandard extension used : redefined extern to static When compiling with warnings being treated as errors, this will obviously result in failed builds. The recommendation from Microsoft (see http://connect.microsoft.com/VisualStudio/feedback/details/633988/warning-in-math-h-line-162-re-nonstandard-extensions-used) is to change the definition to: #if _MSC_VER < 1600 #define hypot _hypot #endif ---------- components: Windows messages: 207894 nosy: tabrezm priority: normal severity: normal status: open title: #define hypot _hypot conflicts with existing definition type: compile error versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 05:18:32 2014 From: report at bugs.python.org (Ethan Furman) Date: Sat, 11 Jan 2014 04:18:32 +0000 Subject: [issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za> Message-ID: <1389413912.33.0.492875823296.issue19995@psf.upfronthosting.co.za> Ethan Furman added the comment: For anyone paying really close attention, I've already switched the assertEquals to assertEqual. ;) ---------- Added file: http://bugs.python.org/file33414/issue19995.stoneleaf.04.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 07:16:57 2014 From: report at bugs.python.org (Victor Varvariuc) Date: Sat, 11 Jan 2014 06:16:57 +0000 Subject: [issue14119] Ability to adjust queue size in Executors In-Reply-To: <1330129142.34.0.452763799677.issue14119@psf.upfronthosting.co.za> Message-ID: <1389421017.11.0.86042757136.issue14119@psf.upfronthosting.co.za> Victor Varvariuc added the comment: Hi! Looks like your pseudocode will work as a workaround instead of monkey-patching! Still the my suggestion to add the line to code stays. self._count should be always equal to the length of self._work_queue? If yes, why duplication. If no - which one to use, why duplication? Also there is an additional lock. http://docs.python.org/3.3/library/queue.html#queue.Queue.task_done - there is a special method, why not using it? Looks like you think that `work_queue.task_done()` should not be added. I don't understand why, but you decide what's better for Python. Thank you for your time! Victor ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 07:26:42 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 11 Jan 2014 06:26:42 +0000 Subject: [issue19619] Blacklist base64, hex, ... codecs from bytes.decode() and str.encode() In-Reply-To: <1384562829.72.0.617857672471.issue19619@psf.upfronthosting.co.za> Message-ID: <1389421602.68.0.874623562442.issue19619@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 07:33:18 2014 From: report at bugs.python.org (Zachary Ware) Date: Sat, 11 Jan 2014 06:33:18 +0000 Subject: [issue20221] #define hypot _hypot conflicts with existing definition In-Reply-To: <1389409768.81.0.962130999427.issue20221@psf.upfronthosting.co.za> Message-ID: <1389421998.87.0.47108438702.issue20221@psf.upfronthosting.co.za> Zachary Ware added the comment: How are you compiling to get that warning? I've never seen it, and none of the Windows buildbots do either. Also, which version of Python are you compiling on which version of Windows? ---------- nosy: +zach.ware stage: -> test needed versions: -Python 2.7, Python 3.1, Python 3.2, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 08:09:10 2014 From: report at bugs.python.org (Zachary Ware) Date: Sat, 11 Jan 2014 07:09:10 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1389424150.98.0.180580023251.issue20172@psf.upfronthosting.co.za> Zachary Ware added the comment: Here's msvcrt. ---------- Added file: http://bugs.python.org/file33415/issue20172.msvcrt.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 08:25:20 2014 From: report at bugs.python.org (Tabrez Mohammed) Date: Sat, 11 Jan 2014 07:25:20 +0000 Subject: [issue20221] #define hypot _hypot conflicts with existing definition In-Reply-To: <1389409768.81.0.962130999427.issue20221@psf.upfronthosting.co.za> Message-ID: <1389425120.42.0.443321296038.issue20221@psf.upfronthosting.co.za> Tabrez Mohammed added the comment: v100 toolset, with compiler setting /W4. Microsoft recommends W4 for all new C++ projects (see http://msdn.microsoft.com/en-us/library/thxezb7y(v=vs.100).aspx). I'm using 3.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 08:30:21 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 11 Jan 2014 07:30:21 +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: <1389425421.54.0.776848019246.issue20132@psf.upfronthosting.co.za> Martin Panter added the comment: I think calling iterencode() with an empty iterator is a side issue. Even with a non-empty iterator, it tries to encode an empty _text_ string to finalise the encoder: >>> bytes().join(codecs.iterencode(iter((b"data",)), "base64-codec")) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.3/codecs.py", line 1014, in iterencode output = encoder.encode("", True) File "/usr/lib/python3.3/encodings/base64_codec.py", line 31, in encode return base64.encodebytes(input) File "/usr/lib/python3.3/base64.py", line 343, in encodebytes raise TypeError("expected bytes, not %s" % s.__class__.__name__) TypeError: expected bytes, not str Similarly, iterdecode(encoding="rot-13") doesn?t work. I agree it would be good to document that iterencode() is limited to text encoders and iterdecode() is limited to byte decoders. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 09:06:30 2014 From: report at bugs.python.org (Armin Ronacher) Date: Sat, 11 Jan 2014 08:06:30 +0000 Subject: [issue20138] wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode In-Reply-To: <1389001619.16.0.909145148031.issue20138@psf.upfronthosting.co.za> Message-ID: <1389427590.57.0.787832702647.issue20138@psf.upfronthosting.co.za> Armin Ronacher added the comment: Two things wrong with your example: a) PATH_INFO on Python 3 must not be bytes b) PATH_INFO on Python 3 must be latin1 transfer encoded. See unicode_to_wsgi and wsgi_to_bytes functions in PEP 3333. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 09:18:30 2014 From: report at bugs.python.org (Tabrez Mohammed) Date: Sat, 11 Jan 2014 08:18:30 +0000 Subject: [issue20221] #define hypot _hypot conflicts with existing definition In-Reply-To: <1389409768.81.0.962130999427.issue20221@psf.upfronthosting.co.za> Message-ID: <1389428310.24.0.625759803978.issue20221@psf.upfronthosting.co.za> Tabrez Mohammed added the comment: Sorry, I realize I didn't mention this in the original post. I'm getting this compiler warning when building my Python extension, not when building Python itself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 09:23:10 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jan 2014 08:23:10 +0000 Subject: [issue20145] unittest.assert*Regex functions should verify that expected_regex has a valid type In-Reply-To: <1389018497.06.0.693451933582.issue20145@psf.upfronthosting.co.za> Message-ID: <1389428590.58.0.514810928818.issue20145@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +ezio.melotti, michael.foord stage: -> test needed type: behavior -> enhancement versions: -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 09:29:32 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 11 Jan 2014 08:29:32 +0000 Subject: [issue20138] wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode In-Reply-To: <1389001619.16.0.909145148031.issue20138@psf.upfronthosting.co.za> Message-ID: <1389428972.26.0.644247562292.issue20138@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 09:30:39 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jan 2014 08:30:39 +0000 Subject: [issue20138] wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode In-Reply-To: <1389001619.16.0.909145148031.issue20138@psf.upfronthosting.co.za> Message-ID: <1389429039.91.0.314205259487.issue20138@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 10:46:11 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jan 2014 09:46:11 +0000 Subject: [issue20138] wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode In-Reply-To: <1389427590.57.0.787832702647.issue20138@psf.upfronthosting.co.za> Message-ID: <3090171.b9H9uqNZdr@raxxla> Serhiy Storchaka added the comment: OK, now I understand the issue. Here is a patch which fixes wsgiref.application_uri() and wsgiref.request_uri(). ---------- keywords: +patch Added file: http://bugs.python.org/file33416/wsgiref_latin1.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 52fbc7bb78ad Lib/test/test_wsgiref.py --- a/Lib/test/test_wsgiref.py Sat Jan 11 00:16:50 2014 +0100 +++ b/Lib/test/test_wsgiref.py Sat Jan 11 11:42:06 2014 +0200 @@ -286,7 +286,7 @@ def testAppURIs(self): self.checkAppURI("http://127.0.0.1/") self.checkAppURI("http://127.0.0.1/spam", SCRIPT_NAME="/spam") - self.checkAppURI("http://127.0.0.1/sp%C3%A4m", SCRIPT_NAME="/sp??m") + self.checkAppURI("http://127.0.0.1/sp%E4m", SCRIPT_NAME="/sp??m") self.checkAppURI("http://spam.example.com:2071/", HTTP_HOST="spam.example.com:2071", SERVER_PORT="2071") self.checkAppURI("http://spam.example.com/", @@ -300,15 +300,19 @@ def testReqURIs(self): self.checkReqURI("http://127.0.0.1/") self.checkReqURI("http://127.0.0.1/spam", SCRIPT_NAME="/spam") - self.checkReqURI("http://127.0.0.1/sp%C3%A4m", SCRIPT_NAME="/sp??m") + self.checkReqURI("http://127.0.0.1/sp%E4m", SCRIPT_NAME="/sp??m") self.checkReqURI("http://127.0.0.1/spammity/spam", SCRIPT_NAME="/spammity", PATH_INFO="/spam") + self.checkReqURI("http://127.0.0.1/spammity/sp%E4m", + SCRIPT_NAME="/spammity", PATH_INFO="/sp??m") self.checkReqURI("http://127.0.0.1/spammity/spam;ham", SCRIPT_NAME="/spammity", PATH_INFO="/spam;ham") self.checkReqURI("http://127.0.0.1/spammity/spam;cookie=1234,5678", SCRIPT_NAME="/spammity", PATH_INFO="/spam;cookie=1234,5678") self.checkReqURI("http://127.0.0.1/spammity/spam?say=ni", SCRIPT_NAME="/spammity", PATH_INFO="/spam",QUERY_STRING="say=ni") + self.checkReqURI("http://127.0.0.1/spammity/spam?s%E4y=ni", + SCRIPT_NAME="/spammity", PATH_INFO="/spam",QUERY_STRING="s%E4y=ni") self.checkReqURI("http://127.0.0.1/spammity/spam", 0, SCRIPT_NAME="/spammity", PATH_INFO="/spam",QUERY_STRING="say=ni") diff -r 52fbc7bb78ad Lib/wsgiref/util.py --- a/Lib/wsgiref/util.py Sat Jan 11 00:16:50 2014 +0100 +++ b/Lib/wsgiref/util.py Sat Jan 11 11:42:06 2014 +0200 @@ -57,14 +57,14 @@ if environ['SERVER_PORT'] != '80': url += ':' + environ['SERVER_PORT'] - url += quote(environ.get('SCRIPT_NAME') or '/') + url += quote(environ.get('SCRIPT_NAME') or '/', encoding='latin1') return url def request_uri(environ, include_query=True): """Return the full request URI, optionally including the query string""" url = application_uri(environ) from urllib.parse import quote - path_info = quote(environ.get('PATH_INFO',''),safe='/;=,') + path_info = quote(environ.get('PATH_INFO',''), safe='/;=,', encoding='latin1') if not environ.get('SCRIPT_NAME'): url += path_info[1:] else: From report at bugs.python.org Sat Jan 11 11:03:29 2014 From: report at bugs.python.org (=?utf-8?q?Martin_H=C3=A4cker?=) Date: Sat, 11 Jan 2014 10:03:29 +0000 Subject: [issue20190] dict() in dict(foo='bar').keys() raises In-Reply-To: <1389188100.33.0.555885401078.issue20190@psf.upfronthosting.co.za> Message-ID: <1389434609.27.0.802659347235.issue20190@psf.upfronthosting.co.za> Martin H?cker added the comment: Well, if that's the case, then this bug indeed can be closed. You switched from list as the base type to set and that has to be dealt with on application side. Still this is surprising, but there's not much that can be done. :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 11:45:56 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jan 2014 10:45:56 +0000 Subject: [issue19886] Better estimated memory requirements for bigmem tests In-Reply-To: <1386185413.56.0.459107954756.issue19886@psf.upfronthosting.co.za> Message-ID: <1389437156.25.0.913084531142.issue19886@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 12:14:14 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 11 Jan 2014 11:14:14 +0000 Subject: [issue17814] Popen.stdin/stdout/stderr documentation should mention object type In-Reply-To: <1366586086.38.0.427506521088.issue17814@psf.upfronthosting.co.za> Message-ID: <1389438854.76.0.818199131881.issue17814@psf.upfronthosting.co.za> Martin Panter added the comment: The patch specifies the stream types are either BufferedReader/Writer, TextIOWrapper, or None. However they can also be plain FileIO in my experience (Python 3.3 with bufsize=0). Maybe it would be simpler to defer to the documentation for open(), which already mentions the three possible layers of file wrapping. Although, looking at the code just now, the TextIOWrapper is added separately by the ?subprocess? module, and uses write_through=True. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 12:16:00 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Jan 2014 11:16:00 +0000 Subject: [issue6157] Tkinter.Text: changes for bbox, debug, and edit methods. In-Reply-To: <1243800373.79.0.587066766962.issue6157@psf.upfronthosting.co.za> Message-ID: <3f1dlz2Ccbz7Ljl@mail.python.org> Roundup Robot added the comment: New changeset 7dab4feec126 by Serhiy Storchaka in branch '2.7': tkinter.Text.debug() now always returns 0/1. http://hg.python.org/cpython/rev/7dab4feec126 New changeset 05e84d3ecd1e by Serhiy Storchaka in branch '3.3': tkinter.Text.debug() now always returns 0/1. http://hg.python.org/cpython/rev/05e84d3ecd1e New changeset e7d922d8ee03 by Serhiy Storchaka in branch 'default': tkinter.Text.debug() now always returns 0/1. http://hg.python.org/cpython/rev/e7d922d8ee03 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 12:33:06 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jan 2014 11:33:06 +0000 Subject: [issue20138] wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode In-Reply-To: <1389001619.16.0.909145148031.issue20138@psf.upfronthosting.co.za> Message-ID: <1389439986.04.0.442029085285.issue20138@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 17:12:57 2014 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 11 Jan 2014 16:12:57 +0000 Subject: [issue2226] Small _abcoll Bugs / Oddities In-Reply-To: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za> Message-ID: <1389456777.18.0.248352870224.issue2226@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 17:17:45 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jan 2014 16:17:45 +0000 Subject: [issue19456] ntpath doesn't join paths correctly when a drive is present In-Reply-To: <1383174757.86.0.861423882665.issue19456@psf.upfronthosting.co.za> Message-ID: <1389457065.26.0.0670385958739.issue19456@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I just discovered that perhaps ntpath.join should be even more clever. Windows supports current directories for every drive separately, so perhaps ntpath.join('c:/x', 'd:/y', 'c:z') should return 'c:/x\\z', not 'c:/z'. Could anyone please check it? Create directory x/z on drive c: and directory y on drive d:, then execute following commands: cd c:/x cd d:/y cd c:z What is resulting current working directory? Here is a patch which implements this algorithm. ---------- Added file: http://bugs.python.org/file33417/ntpath_join_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 19:25:49 2014 From: report at bugs.python.org (INADA Naoki) Date: Sat, 11 Jan 2014 18:25:49 +0000 Subject: [issue20222] unittest.mock-examples doc uses builtin file which is removed in Python 3 Message-ID: <1389464749.27.0.908623013872.issue20222@psf.upfronthosting.co.za> New submission from INADA Naoki: http://docs.python.org/3.3/library/unittest.mock-examples.html#mocking-chained-calls > Let?s assume the object it returns is ?file-like?, so we?ll ensure that our response object uses the builtin file as its spec. and > >>> mock_response = Mock(spec=file) ---------- assignee: docs at python components: Documentation messages: 207908 nosy: docs at python, naoki priority: normal severity: normal status: open title: unittest.mock-examples doc uses builtin file which is removed in Python 3 versions: Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 20:42:08 2014 From: report at bugs.python.org (Merlijn van Deen) Date: Sat, 11 Jan 2014 19:42:08 +0000 Subject: [issue19456] ntpath doesn't join paths correctly when a drive is present In-Reply-To: <1383174757.86.0.861423882665.issue19456@psf.upfronthosting.co.za> Message-ID: <1389469328.82.0.733556236239.issue19456@psf.upfronthosting.co.za> Merlijn van Deen added the comment: > so perhaps ntpath.join('c:/x', 'd:/y', 'c:z') should return 'c:/x\\z', not 'c:/z'. 'c:z' is consistent with what .NET's System.IO.Path.Combine does: via http://ironpython.net/try/ : import System.IO.Path; print System.IO.Path.Combine('c:/x', 'd:/y', 'c:z') returns 'c:z' > Could anyone please check it? Create directory x/z on drive c: and directory y on drive d:, then execute following commands: > cd c:/x > cd d:/y > cd c:z > > What is resulting current working directory? c:\>cd c:/x c:\x>cd e:\y c:\x>cd c:z Het systeem kan het opgegeven pad niet vinden. # file not found, in Dutch c:\x>cd c:\z Yes, there is a seperate current directory for each drive, but cd does not switch drives. (cd e:\f does not mean you actually go to e:\f - it just changes the current directory on the e:-drive). I don't think those semantics are sensible for joining paths... ---------- nosy: +valhallasw _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 21:03:56 2014 From: report at bugs.python.org (Merlijn van Deen) Date: Sat, 11 Jan 2014 20:03:56 +0000 Subject: [issue19456] ntpath doesn't join paths correctly when a drive is present In-Reply-To: <1383174757.86.0.861423882665.issue19456@psf.upfronthosting.co.za> Message-ID: <1389470636.79.0.300590232779.issue19456@psf.upfronthosting.co.za> Merlijn van Deen added the comment: Sorry, I was a bit too quick - I forgot to create c:\x\z. Now this is the result: c:\x\z>cd c:/x c:\x>cd e:/y c:\x>cd c:z c:\x\z> However, the behavior does not work in, for example, a 'Save as...' window, where c:z will always return "illegal filename" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 21:04:53 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jan 2014 20:04:53 +0000 Subject: [issue20138] wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode In-Reply-To: <1389001619.16.0.909145148031.issue20138@psf.upfronthosting.co.za> Message-ID: <1389470693.79.0.433477135757.issue20138@psf.upfronthosting.co.za> Terry J. Reedy added the comment: > SCRIPT_NAME="/spammity", PATH_INFO="/sp??m") Has the policy of limiting stdlib code to ascii chars, including \ escapes, except where needed for tests, been changed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 21:09:58 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jan 2014 20:09:58 +0000 Subject: [issue20138] wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode In-Reply-To: <1389470693.79.0.433477135757.issue20138@psf.upfronthosting.co.za> Message-ID: <1658948.GVrYAyA41R@raxxla> Serhiy Storchaka added the comment: > > SCRIPT_NAME="/spammity", PATH_INFO="/sp??m") > Has the policy of limiting stdlib code to ascii chars, including \ escapes, > except where needed for tests, been changed? This character is already used in this file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 21:46:15 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 11 Jan 2014 20:46:15 +0000 Subject: [issue13355] random.triangular error when low = high=mode In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za> Message-ID: <1389473175.44.0.463263139155.issue13355@psf.upfronthosting.co.za> Raymond Hettinger added the comment: [Serhiy] > Raymond, could you please make a decision Yes, I will this week. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 22:02:17 2014 From: report at bugs.python.org (Georg Brandl) Date: Sat, 11 Jan 2014 21:02:17 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1389474137.81.0.630828473954.issue20186@psf.upfronthosting.co.za> Georg Brandl added the comment: Looking at _csv.c, I see a few functions using PyArg_UnpackTuple. They should be converted too, no? ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 22:22:59 2014 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 11 Jan 2014 21:22:59 +0000 Subject: [issue20223] inspect.signature does not support new functools.partialmethod Message-ID: <1389475379.56.0.443397984378.issue20223@psf.upfronthosting.co.za> New submission from Yury Selivanov: new and handy functools.partialmethod doesn't fully support inspect.signature. For instance, for the following code: class Spam: def say(self, a, b=1): print(a) hello = functools.partialmethod(say, 'hello') the 'signature(Spam.hello)' will always return '(*args, **keywords)' I'm attaching a patch that fixes that, so the signature for the above example will be '(self, b=1)'. ---------- components: Library (Lib) files: signature_partialmeth_01.patch keywords: patch messages: 207915 nosy: brett.cannon, larry, ncoghlan, yselivanov priority: normal severity: normal status: open title: inspect.signature does not support new functools.partialmethod type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file33418/signature_partialmeth_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 22:28:04 2014 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 11 Jan 2014 21:28:04 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389475684.88.0.236630286179.issue20189@psf.upfronthosting.co.za> Yury Selivanov added the comment: Larry, Congrats on the amazing job you did with the arguments clinic. And if you need any assistance with 'inspect.signature' I'd be glad to help. ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 22:56:24 2014 From: report at bugs.python.org (Georg Brandl) Date: Sat, 11 Jan 2014 21:56:24 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1389477384.28.0.19902027083.issue20186@psf.upfronthosting.co.za> Georg Brandl added the comment: Attached part 1 of mathmodule (17 functions). I'm looking forward to a suggestion for handling the rest (see FUNC1/1A/2 macros :) ---------- keywords: +patch Added file: http://bugs.python.org/file33419/mathmodule_part1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 23:13:58 2014 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 11 Jan 2014 22:13:58 +0000 Subject: [issue17373] Add inspect.Signature.from_callable() In-Reply-To: <1362642709.69.0.481380147826.issue17373@psf.upfronthosting.co.za> Message-ID: <1389478438.29.0.853107057278.issue17373@psf.upfronthosting.co.za> Yury Selivanov added the comment: Hi Eric, I'm not sure why do you want this. Having "Signature.from_callable" does not allow you to change behaviour of 'inspect.signature' function. More over, it creates a confusion about what API should be used - 'inspect.signature' or 'inspect.Signature.from_callable'. ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 23:24:56 2014 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 11 Jan 2014 22:24:56 +0000 Subject: [issue17481] inspect.getfullargspec could use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1389479096.33.0.749917877803.issue17481@psf.upfronthosting.co.za> Yury Selivanov added the comment: Please consider the attached patch (getargsspec_01.patch). It modifies 'getargspec' and 'getfullargspec' to use the 'inspect.signature' API. The entire test suite passes just fine. This also will address issue #16490. I can also update the docs, if it's necessary. ---------- keywords: +patch nosy: +yselivanov Added file: http://bugs.python.org/file33420/getargsspec_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 11 23:40:47 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Sat, 11 Jan 2014 22:40:47 +0000 Subject: [issue20138] wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode In-Reply-To: <1389001619.16.0.909145148031.issue20138@psf.upfronthosting.co.za> Message-ID: <1389480047.79.0.789715370976.issue20138@psf.upfronthosting.co.za> Senthil Kumaran added the comment: And those examples were only in test. Use of latin-1 to have a literal text for round trip is ok. The patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 00:04:23 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 11 Jan 2014 23:04:23 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389481463.34.0.737601373152.issue20189@psf.upfronthosting.co.za> Larry Hastings added the comment: Yury: Thanks! I don't need any help right now though--just a review on this patch ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 00:21:19 2014 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 11 Jan 2014 23:21:19 +0000 Subject: [issue16490] "inspect.getargspec()" and "inspect.getcallargs()" don't work for builtins In-Reply-To: <1353123389.46.0.245856363901.issue16490@psf.upfronthosting.co.za> Message-ID: <1389482479.09.0.710088772429.issue16490@psf.upfronthosting.co.za> Yury Selivanov added the comment: This is related to issue #17481 ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 00:23:32 2014 From: report at bugs.python.org (Ethan Furman) Date: Sat, 11 Jan 2014 23:23:32 +0000 Subject: [issue16508] include the "object" type in the lists of documented types In-Reply-To: <1353284081.12.0.684350303879.issue16508@psf.upfronthosting.co.za> Message-ID: <1389482612.03.0.764357972189.issue16508@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 00:32:59 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 11 Jan 2014 23:32:59 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1389483179.45.0.391886551562.issue20186@psf.upfronthosting.co.za> Larry Hastings added the comment: 1) Wow. I never knew about PyArg_UnpackTuple. You're right, those should be converted too. Hooray, more entry points to convert. I'll write something up for the howto about UnpackTuple. I just did a quick check, and there are 96 entry points (by my count) that use PyArg_UnpackTuple(). Shall I create Derby issues #19 and #20, or do you have a better idea? 2) For FUNC1 / 1A / 2 macros: right now you'd have to just copy and paste over and over. There might be something you could do with a [python] block where you automatedly reuse the existing sigantures. I was thinking about having Clinic support it directly, maybe with the syntax: /*[clinic input] func_name = existing_func_name docstring goes here [...]*/ You'd skip the parameters and the return annotation. You could only reuse functions from the current file. Would that be a big boon to you? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 00:38:06 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sat, 11 Jan 2014 23:38:06 +0000 Subject: [issue17481] inspect.getfullargspec could use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1389483486.55.0.0617224351896.issue17481@psf.upfronthosting.co.za> Changes by Claudiu.Popa : ---------- nosy: +Claudiu.Popa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 03:20:27 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sun, 12 Jan 2014 02:20:27 +0000 Subject: [issue17814] Popen.stdin/stdout/stderr documentation should mention object type In-Reply-To: <1366586086.38.0.427506521088.issue17814@psf.upfronthosting.co.za> Message-ID: <1389493227.84.0.739393588865.issue17814@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Thanks for looking at this Martin! I have attached an updated patch that includes a reference to open and slightly changed language. But please, let's not have the best be the enemy of the good here. There will probably always be room for further improvement, but if the patch as-is improves over the status quo - can't it just be applied? It's not as if this is the last and only chance to make changes... ---------- versions: +Python 3.1, Python 3.2, Python 3.5 Added file: http://bugs.python.org/file33421/issue17814.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 07:22:32 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jan 2014 06:22:32 +0000 Subject: [issue19092] ExitStack.__exit__ incorrectly suppresses exceptions in __exit__ callbacks of inner context managers In-Reply-To: <1380136187.37.0.729796109014.issue19092@psf.upfronthosting.co.za> Message-ID: <3f27Bv273bz7LjN@mail.python.org> Roundup Robot added the comment: New changeset a3e49868cfd0 by Senthil Kumaran in branch '3.3': Issue #19092 - Raise a correct exception when cgi.FieldStorage is given an http://hg.python.org/cpython/rev/a3e49868cfd0 New changeset 1638360eea41 by Senthil Kumaran in branch 'default': merge from 3.3 http://hg.python.org/cpython/rev/1638360eea41 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 07:22:31 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jan 2014 06:22:31 +0000 Subject: [issue19097] bool(cgi.FieldStorage(...)) may be False unexpectedly In-Reply-To: <1380239682.41.0.674159694258.issue19097@psf.upfronthosting.co.za> Message-ID: <3f27Bt3xKFz7LjN@mail.python.org> Roundup Robot added the comment: New changeset 2d6e7a5659f0 by Senthil Kumaran in branch '2.7': Adding test coverage for cgi.FieldStorage based on the scenario mentioned in issue #19097 http://hg.python.org/cpython/rev/2d6e7a5659f0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 07:25:11 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 Jan 2014 06:25:11 +0000 Subject: [issue20224] C API docs need a clear "defining custom extension types" section Message-ID: <1389507911.71.0.277009038491.issue20224@psf.upfronthosting.co.za> New submission from Nick Coghlan: The main C API docs don't clearly explain how to define new types, so people almost always cargo cult an existing legacy type definition instead (I know I do). The extending and embedding docs have a guide (http://docs.python.org/3/extending/newtypes.html), but that describes the old legacy method based on static type declarations. New code should instead use the dynamic mechanism defined in PEP 384 (http://www.python.org/dev/peps/pep-0384/#type-objects). See also http://docs.python.org/3/c-api/type.html#PyType_FromSpec Note that PyType_Spec isn't defined in the C API docs *at all*. ---------- assignee: docs at python components: Documentation messages: 207927 nosy: docs at python, ncoghlan priority: normal severity: normal stage: needs patch status: open title: C API docs need a clear "defining custom extension types" section type: enhancement versions: Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 07:30:56 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 12 Jan 2014 06:30:56 +0000 Subject: [issue19097] bool(cgi.FieldStorage(...)) may be False unexpectedly In-Reply-To: <1380239682.41.0.674159694258.issue19097@psf.upfronthosting.co.za> Message-ID: <1389508256.22.0.72952135236.issue19097@psf.upfronthosting.co.za> Senthil Kumaran added the comment: This is fixed in all active branches (2.7,3,3 and 3.4). I have addressed all review comments. Thanks. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 08:21:03 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jan 2014 07:21:03 +0000 Subject: [issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za> Message-ID: <3f28VQ0xmnz7LjQ@mail.python.org> Roundup Robot added the comment: New changeset 22e55bd5583c by Ethan Furman in branch 'default': Issue19995: issue deprecation warning for non-integer values to %c, %o, %x, %X http://hg.python.org/cpython/rev/22e55bd5583c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 08:40:51 2014 From: report at bugs.python.org (Cory Benfield) Date: Sun, 12 Jan 2014 07:40:51 +0000 Subject: [issue19996] httplib infinite read on invalid header In-Reply-To: <1387194945.4.0.440069571587.issue19996@psf.upfronthosting.co.za> Message-ID: <1389512451.52.0.973741655081.issue19996@psf.upfronthosting.co.za> Cory Benfield added the comment: Is there anything I can do to help move this forward? I appreciate you're all busy so I'm happy for this to take as long as it takes, I just wanted to make sure it's not blocked behind me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 08:56:58 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Jan 2014 07:56:58 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1389513418.11.0.106994377574.issue20186@psf.upfronthosting.co.za> Georg Brandl added the comment: > Wow. I never knew about PyArg_UnpackTuple. You're right, those > should be converted too. Hooray, more entry points to convert. > I'll write something up for the howto about UnpackTuple. One thing to note is that (at least in math) many instances of UnpackTuple could have been replaced by ParseTuple. See for example math_hypot: it uses UnpackTuple to get two objects, and then immediately calls PyFloat_AsDouble on them. I've converted these using 'd' and not 'O' specifiers. > I just did a quick check, and there are 96 entry points (by my count) > that use PyArg_UnpackTuple(). Shall I create Derby issues #19 and > #20, or do you have a better idea? Probably better to add them to the issues that cover their modules, otherwise people might get confused. > 2) For FUNC1 / 1A / 2 macros: right now you'd have to just copy and > paste over and over. There might be something you could do with a > [python] block where you automatedly reuse the existing sigantures. > I was thinking about having Clinic support it directly, maybe with > the syntax: > /*[clinic input] > func_name = existing_func_name > > docstring goes here > [...]*/ > > You'd skip the parameters and the return annotation. You could only > reuse functions from the current file. Would that be a big boon to you? That sounds good. On the other hand, if clinic expanded cpp macros we could... *:-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 09:10:26 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Jan 2014 08:10:26 +0000 Subject: [issue20158] Argument Clinic: add --clean option In-Reply-To: <1389085929.13.0.245678018197.issue20158@psf.upfronthosting.co.za> Message-ID: <1389514226.62.0.73341747327.issue20158@psf.upfronthosting.co.za> Georg Brandl added the comment: Another use case here is if you want to "check" the remaining call sites of (say) PyArg_ParseTuple that aren't generated by clinic. Call it '--remove' if you want, but the functionality should be useful. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 09:32:19 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Jan 2014 08:32:19 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1389515539.59.0.844289395303.issue20186@psf.upfronthosting.co.za> Georg Brandl added the comment: OK, here's a patch for _csv. Two problems here: First problem is the __new__ method of the Dialect class: * it has no docstring and no methoddef entry * it is a class method, but the first arg is conventionally called "type" I tried to hack something into clinic with a new decorator, but it may not be how you want it to look, take care. Second problem is the functions reader(), writer(), register_dialect(): they parse their *args but pass their **kwargs through to another class. Is there anything like a "**kwds" argument specifier? BTW, for a module like _csv that is exported through a Python module named csv, should we use the "real" or the "nice" module name? ---------- Added file: http://bugs.python.org/file33422/csv_module_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 09:35:21 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Jan 2014 08:35:21 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1389515721.27.0.898828060654.issue20186@psf.upfronthosting.co.za> Georg Brandl added the comment: Tried to tackle symtable -- it uses an O& converter. The clinic howto says ``'O&'`` ``object(converter='name_of_c_function')`` but Traceback (most recent call last): File "Tools/clinic/clinic.py", line 2817, in sys.exit(main(sys.argv[1:])) File "Tools/clinic/clinic.py", line 2813, in main parse_file(filename, output=ns.output, verify=not ns.force) File "Tools/clinic/clinic.py", line 1116, in parse_file cooked = clinic.parse(raw) File "Tools/clinic/clinic.py", line 1066, in parse parser.parse(block) File "Tools/clinic/clinic.py", line 2109, in parse self.state(line) File "Tools/clinic/clinic.py", line 2378, in state_parameter converter = dict[name](parameter_name, self.function, value, **kwargs) File "Tools/clinic/clinic.py", line 1403, in __init__ self.converter_init(**kwargs) TypeError: converter_init() got an unexpected keyword argument 'converter' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 09:46:13 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Jan 2014 08:46:13 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1389516373.98.0.667325196174.issue20186@psf.upfronthosting.co.za> Georg Brandl added the comment: _tracemalloc converted. Its existing docstrings did use the func(arg: argtype) -> rettype convention. Is there a way in clinic to retain that? ---------- Added file: http://bugs.python.org/file33423/tracemalloc_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 09:55:40 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Jan 2014 08:55:40 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1389516940.7.0.264554296277.issue20186@psf.upfronthosting.co.za> Georg Brandl added the comment: Here's _iomodule. _io.open has a whopping 100-line docstring, which is ... unfortunate ... to have duplicated in the file :) ---------- Added file: http://bugs.python.org/file33424/io_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 10:04:37 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Jan 2014 09:04:37 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1389517477.63.0.1911871613.issue20186@psf.upfronthosting.co.za> Georg Brandl added the comment: And _heapq. No problems there, except that it also used "->" return annotations in the docstring. ---------- Added file: http://bugs.python.org/file33425/heapq_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 10:16:05 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Jan 2014 09:16:05 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1389518165.78.0.44930999927.issue20186@psf.upfronthosting.co.za> Georg Brandl added the comment: And lsprof. ---------- Added file: http://bugs.python.org/file33426/lsprof_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 10:28:36 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Jan 2014 09:28:36 +0000 Subject: [issue20115] NUL bytes in commented lines In-Reply-To: <1388771953.42.0.332804570753.issue20115@psf.upfronthosting.co.za> Message-ID: <1389518916.88.0.579975703487.issue20115@psf.upfronthosting.co.za> Georg Brandl added the comment: I'm in favor of PyPy's behavior: null bytes anywhere in the source, even in comments, usually mean there's something weird or fishy going on with either the editor or (if downloaded/copied) the source of the code. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 10:41:37 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jan 2014 09:41:37 +0000 Subject: [issue20138] wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode In-Reply-To: <1389001619.16.0.909145148031.issue20138@psf.upfronthosting.co.za> Message-ID: <1389519697.18.0.178437623316.issue20138@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 10:48:36 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 12 Jan 2014 09:48:36 +0000 Subject: [issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception In-Reply-To: <3f28VQ0xmnz7LjQ@mail.python.org> Message-ID: STINNER Victor added the comment: Typo in the C code: depracation :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 11:11:49 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Jan 2014 10:11:49 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1389521509.46.0.726533967807.issue20182@psf.upfronthosting.co.za> Georg Brandl added the comment: Here's the signalmodule. ---------- keywords: +patch nosy: +georg.brandl Added file: http://bugs.python.org/file33427/signal_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 11:16:30 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jan 2014 10:16:30 +0000 Subject: [issue20138] wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode In-Reply-To: <1389001619.16.0.909145148031.issue20138@psf.upfronthosting.co.za> Message-ID: <3f2DNs2cLgz7LjX@mail.python.org> Roundup Robot added the comment: New changeset 29732b43ccf2 by Serhiy Storchaka in branch '3.3': Issue #20138: The wsgiref.application_uri() and wsgiref.request_uri() http://hg.python.org/cpython/rev/29732b43ccf2 New changeset 73781fe1daa2 by Serhiy Storchaka in branch 'default': Issue #20138: The wsgiref.application_uri() and wsgiref.request_uri() http://hg.python.org/cpython/rev/73781fe1daa2 New changeset 40fb60df4755 by Serhiy Storchaka in branch '2.7': Issue #20138: Backport tests for handling non-ASCII URLs in the http://hg.python.org/cpython/rev/40fb60df4755 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 11:20:28 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Jan 2014 10:20:28 +0000 Subject: [issue20225] Argument Clinic: simplify METH_NOARGS generated code Message-ID: <1389522028.26.0.505702329352.issue20225@psf.upfronthosting.co.za> New submission from Georg Brandl: For METH_NOARGS, you can get rid of the separate _impl function. This makes the generated code much smaller. ---------- messages: 207943 nosy: georg.brandl priority: normal severity: normal status: open title: Argument Clinic: simplify METH_NOARGS generated code _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 11:23:00 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jan 2014 10:23:00 +0000 Subject: [issue20225] Argument Clinic: simplify METH_NOARGS generated code In-Reply-To: <1389522028.26.0.505702329352.issue20225@psf.upfronthosting.co.za> Message-ID: <1389522180.64.0.841710654599.issue20225@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Seconded. But only if there are no self or result converters. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 11:27:42 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Jan 2014 10:27:42 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1389522462.05.0.54562221465.issue20182@psf.upfronthosting.co.za> Changes by Georg Brandl : Removed file: http://bugs.python.org/file33427/signal_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 11:27:51 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Jan 2014 10:27:51 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1389522471.23.0.932117933112.issue20182@psf.upfronthosting.co.za> Georg Brandl added the comment: Now without crap. ---------- Added file: http://bugs.python.org/file33428/signal_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 11:29:49 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Jan 2014 10:29:49 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? Message-ID: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> New submission from Georg Brandl: Take for example select.epoll.__new__(): static PyObject * pyepoll_new(PyTypeObject *type, PyObject *args, PyObject *kwds) { int flags = 0, sizehint = FD_SETSIZE - 1; static char *kwlist[] = {"sizehint", "flags", NULL}; if (!PyArg_ParseTupleAndKeywords(args, kwds, "|ii:epoll", kwlist, &sizehint, &flags)) return NULL; How should that be handled? Currently I can't specify ``FD_SETSIZE - 1`` as the default value, but I don't want a magic ``-909`` either :) ---------- messages: 207946 nosy: georg.brandl priority: normal severity: normal status: open title: Argument Clinic: support for simple expressions? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 11:29:54 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Jan 2014 10:29:54 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? In-Reply-To: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> Message-ID: <1389522594.63.0.64304972126.issue20226@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- assignee: -> larry nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 11:30:04 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Jan 2014 10:30:04 +0000 Subject: [issue20225] Argument Clinic: simplify METH_NOARGS generated code In-Reply-To: <1389522028.26.0.505702329352.issue20225@psf.upfronthosting.co.za> Message-ID: <1389522604.6.0.226925507034.issue20225@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- assignee: -> larry nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 11:37:41 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jan 2014 10:37:41 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? In-Reply-To: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> Message-ID: <1389523061.39.0.125559226149.issue20226@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also a discussion in issue20193. zlib needs this in many functions. ---------- nosy: +serhiy.storchaka versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 12:05:36 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Jan 2014 11:05:36 +0000 Subject: [issue20227] Argument Clinic: rename arguments in generated C? Message-ID: <1389524736.75.0.620647933805.issue20227@psf.upfronthosting.co.za> New submission from Georg Brandl: This is a request to be able to name C arguments differently from Python arguments. Two reasons: * like for function renaming, some Python argument names are reserved in C ("default" for example, used in sys.getsizeof()) * sometimes the function uses 'O' in PyArg_ParseTuple and then converts the object itself with a nontrivial process. Usually the converted variable has the name of the Python argument, while the temporary object is named "obj_foo" or "foo_obj". When converting to Argument Clinic, we have to name the object "foo" and find a new name for the converted "foo", which leads to code churn and less beautiful code. ---------- assignee: larry messages: 207948 nosy: georg.brandl, larry priority: normal severity: normal status: open title: Argument Clinic: rename arguments in generated C? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 12:06:47 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Jan 2014 11:06:47 +0000 Subject: [issue20227] Argument Clinic: rename arguments in generated C? In-Reply-To: <1389524736.75.0.620647933805.issue20227@psf.upfronthosting.co.za> Message-ID: <1389524807.28.0.460776010317.issue20227@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 12:07:38 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Jan 2014 11:07:38 +0000 Subject: [issue20227] Argument Clinic: rename arguments in generated C? In-Reply-To: <1389524736.75.0.620647933805.issue20227@psf.upfronthosting.co.za> Message-ID: <1389524858.23.0.193520269138.issue20227@psf.upfronthosting.co.za> Georg Brandl added the comment: OK, I see that AC automatically handles case 1, great! Still you have to decide if you like the code churn caused by case 2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 12:14:29 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Jan 2014 11:14:29 +0000 Subject: [issue20227] Argument Clinic: rename arguments in generated C? In-Reply-To: <1389524736.75.0.620647933805.issue20227@psf.upfronthosting.co.za> Message-ID: <1389525269.26.0.285686731508.issue20227@psf.upfronthosting.co.za> Georg Brandl added the comment: One more: I can't have an argument called "args". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 12:18:59 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Jan 2014 11:18:59 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1389525539.13.0.578136531267.issue20182@psf.upfronthosting.co.za> Georg Brandl added the comment: Here's sys. For it to generate the correct code you need to add "args" to c_keywords in clinic.py. ---------- Added file: http://bugs.python.org/file33429/sys_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 13:59:09 2014 From: report at bugs.python.org (Ram Rachum) Date: Sun, 12 Jan 2014 12:59:09 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1389531549.41.0.896621791013.issue20218@psf.upfronthosting.co.za> Ram Rachum added the comment: (Replace `is` with `if` in my code sample, typo.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 14:29:02 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 12 Jan 2014 13:29:02 +0000 Subject: [issue20158] Argument Clinic: add --clean option In-Reply-To: <1389085929.13.0.245678018197.issue20158@psf.upfronthosting.co.za> Message-ID: <1389533342.26.0.0325016113526.issue20158@psf.upfronthosting.co.za> Larry Hastings added the comment: You can accomplish that workflow by using the Clinic buffer prototype and moving all your output to the "side". Or by using the "buffer" approach, and stopping when you hit the generated code. One of these might actually happen in Clinic, too, so hang on to your hats. https://bitbucket.org/larry/python-clinic-buffer ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 14:42:30 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 12 Jan 2014 13:42:30 +0000 Subject: [issue20225] Argument Clinic: simplify METH_NOARGS generated code In-Reply-To: <1389522028.26.0.505702329352.issue20225@psf.upfronthosting.co.za> Message-ID: <1389534150.54.0.641718600465.issue20225@psf.upfronthosting.co.za> Larry Hastings added the comment: (Actually a self converter would be fine too. Those are only allowed to cast.) I'm not doing this; here's why. I want the call signature to the impl function to be the *idealized* signature of that function. And METH_NOARGS passes in a dumb stupid second argument that is always a NULL pointer. I just don't want that there. The long-term goal of Clinic is to let us speed up argument parsing. We'll do this by rewriting the whole approach to argument parsing. I suspect this will include not just PyArg_ParseTuple but even the whole callback mechanism, METH_O METH_NOARGS and all that. So I can live with the extra three-line function for now. Also, I assert that compilers are sufficiently smart today to fold the impl function back into the parsing function. Therefore this approach has no run-time cost. Finally, if you're trying to reduce the number of lines of generated code stomping on your poor tired eyes, consider playing with the Clinic buffer prototype: https://bitbucket.org/larry/python-clinic-buffer You can at least prototype with it before checking in for now. ---------- components: +Demos and Tools resolution: -> rejected stage: -> committed/rejected status: open -> closed type: -> enhancement versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 14:51:34 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Jan 2014 13:51:34 +0000 Subject: [issue20225] Argument Clinic: simplify METH_NOARGS generated code In-Reply-To: <1389522028.26.0.505702329352.issue20225@psf.upfronthosting.co.za> Message-ID: <1389534694.13.0.565939176578.issue20225@psf.upfronthosting.co.za> Georg Brandl added the comment: Sure, I wasn't concerned with compilation, only saving lines of code. But I agree that the buffer way sounds much more promising. Just seemed odd that METH_O was clean and METH_NOARGS less so :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 14:58:07 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 12 Jan 2014 13:58:07 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? In-Reply-To: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> Message-ID: <1389535087.78.0.641193244287.issue20226@psf.upfronthosting.co.za> Larry Hastings added the comment: Yes, this is supported, just undocumented (for now). The magic you want is, for example in Modules/_sre.c: endpos: Py_ssize_t(c_default="PY_SSIZE_T_MAX") = sys.maxsize ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 15:03:39 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 Jan 2014 14:03:39 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? In-Reply-To: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> Message-ID: <1389535419.59.0.252460550393.issue20226@psf.upfronthosting.co.za> Georg Brandl added the comment: Nice, thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 15:32:46 2014 From: report at bugs.python.org (Marcel Hellkamp) Date: Sun, 12 Jan 2014 14:32:46 +0000 Subject: [issue18394] cgi.FieldStorage triggers ResourceWarning sometimes In-Reply-To: <1373190601.25.0.575768158618.issue18394@psf.upfronthosting.co.za> Message-ID: <1389537166.72.0.555639373457.issue18394@psf.upfronthosting.co.za> Marcel Hellkamp added the comment: This change breaks existing applications. The cgi.FieldStorage.file attribute is public and mentioned in the documentation. It even states "You can then read the data at leisure from the file attribute". Consider this example:: form = cgi.FieldStorage() fileitem = form.getfirst("userfile") if fileitem and fileitem.file: executor.submit(store_file, fileitem.file, fileitem.filename) This code is no longer safe. The garbage collector might close the file handle while it is still referenced and accessed from the worker thread. Another example is the bottle web framework. It uses cgi.FieldStorage for parsing only, extracts the valuable information and stores the result in its own data structures. The cgi.FieldStorage instance is lost. Python 3.4 breaks every single bottle application that works with file uploads. How about implementing the context manager protocol for cgi.FieldStorage to resolve this issue? ---------- nosy: +Marcel.Hellkamp _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 16:02:48 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 12 Jan 2014 15:02:48 +0000 Subject: [issue19092] ExitStack.__exit__ incorrectly suppresses exceptions in __exit__ callbacks of inner context managers In-Reply-To: <1380136187.37.0.729796109014.issue19092@psf.upfronthosting.co.za> Message-ID: <1389538968.48.0.26133053944.issue19092@psf.upfronthosting.co.za> Senthil Kumaran added the comment: The last tracker message msg207926 is applicable to issue #19097 and not here. Sorry for the confusion. ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 16:05:04 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Sun, 12 Jan 2014 15:05:04 +0000 Subject: [issue19097] bool(cgi.FieldStorage(...)) may be False unexpectedly In-Reply-To: <1380239682.41.0.674159694258.issue19097@psf.upfronthosting.co.za> Message-ID: <1389539104.08.0.652321354388.issue19097@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Fixed in: New changeset a3e49868cfd0 by Senthil Kumaran in branch '3.3': Issue #19092 - Raise a correct exception when cgi.FieldStorage is given an http://hg.python.org/cpython/rev/a3e49868cfd0 New changeset 1638360eea41 by Senthil Kumaran in branch 'default': merge from 3.3 http://hg.python.org/cpython/rev/1638360eea41 (Thanks for correcting my bad merge Serhiy. I did fix :w and then did a hg resolve --mark, but still ended up with merge lines. I got to look more carefully next time). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 17:18:26 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 12 Jan 2014 16:18:26 +0000 Subject: [issue20214] Argument Clinic rollup fixes In-Reply-To: <1389317138.57.0.101674386167.issue20214@psf.upfronthosting.co.za> Message-ID: <1389543506.48.0.103422249345.issue20214@psf.upfronthosting.co.za> Larry Hastings added the comment: Freshened patch, ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 17:23:19 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 12 Jan 2014 16:23:19 +0000 Subject: [issue20201] Argument Clinic: rwbuffer support broken In-Reply-To: <1389242396.52.0.166931579233.issue20201@psf.upfronthosting.co.za> Message-ID: <1389543799.19.0.636243736442.issue20201@psf.upfronthosting.co.za> Larry Hastings added the comment: Do you have commit rights? I can commit this patch for you if you don't. Just wondering what (if anything) is holding this up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 17:24:55 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 12 Jan 2014 16:24:55 +0000 Subject: [issue20196] Argument Clinic generates invalid code for optional parameter In-Reply-To: <1389215820.54.0.23969623905.issue20196@psf.upfronthosting.co.za> Message-ID: <1389543895.79.0.770000910335.issue20196@psf.upfronthosting.co.za> Larry Hastings added the comment: Georg, you mind reviewing this too? Six line patch. Just trying to clean my plate a little before I fix a bug for you :D ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 17:26:52 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 12 Jan 2014 16:26:52 +0000 Subject: [issue20201] Argument Clinic: rwbuffer support broken In-Reply-To: <1389242396.52.0.166931579233.issue20201@psf.upfronthosting.co.za> Message-ID: <1389544012.58.0.47171625322.issue20201@psf.upfronthosting.co.za> Larry Hastings added the comment: Looks like you don't, so I'll commit this on your behalf. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 17:29:20 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 12 Jan 2014 16:29:20 +0000 Subject: [issue20214] Argument Clinic rollup fixes In-Reply-To: <1389317138.57.0.101674386167.issue20214@psf.upfronthosting.co.za> Message-ID: <1389544160.68.0.66015707557.issue20214@psf.upfronthosting.co.za> Larry Hastings added the comment: Also adding the one-byte fix from #20201 to the rollup patch here. (Not bothering to upload a fresh patch because it is literally one byte, fixing a misspelled variable name.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 17:42:30 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jan 2014 16:42:30 +0000 Subject: [issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za> Message-ID: <3f2NyF2Gvwz7LlD@mail.python.org> Roundup Robot added the comment: New changeset cc8b21988efb by Ethan Furman in branch 'default': Issue19995: fixed typo; switched from test.support.check_warnings to assertWarns http://hg.python.org/cpython/rev/cc8b21988efb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 17:46:01 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 12 Jan 2014 16:46:01 +0000 Subject: [issue20214] Argument Clinic rollup fixes In-Reply-To: <1389317138.57.0.101674386167.issue20214@psf.upfronthosting.co.za> Message-ID: <1389545161.61.0.671201040457.issue20214@psf.upfronthosting.co.za> Larry Hastings added the comment: I goofed, I do have some additional fixes. Here's everything. Changes since patch #1: * Added 'converter' argument to 'object' converter. * Fixed misspelled variable name (see #20201). * Several documentation updates. ---------- Added file: http://bugs.python.org/file33430/larry.argument.clinic.misc.fixes.patch.2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 17:49:49 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jan 2014 16:49:49 +0000 Subject: [issue20196] Argument Clinic generates invalid code for optional parameter In-Reply-To: <1389215820.54.0.23969623905.issue20196@psf.upfronthosting.co.za> Message-ID: <3f2P6h3jwjz7Lk1@mail.python.org> Roundup Robot added the comment: New changeset 250b481a0d28 by Larry Hastings in branch 'default': Issue #20196: Fixed a bug where Argument Clinic did not generate correct http://hg.python.org/cpython/rev/250b481a0d28 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 17:50:39 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 12 Jan 2014 16:50:39 +0000 Subject: [issue20196] Argument Clinic generates invalid code for optional parameter In-Reply-To: <1389215820.54.0.23969623905.issue20196@psf.upfronthosting.co.za> Message-ID: <1389545439.16.0.958253526894.issue20196@psf.upfronthosting.co.za> Larry Hastings added the comment: Easy fix. Thanks for the report! ---------- resolution: -> fixed stage: patch review -> commit review status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 18:21:55 2014 From: report at bugs.python.org (Brett Cannon) Date: Sun, 12 Jan 2014 17:21:55 +0000 Subject: [issue18394] cgi.FieldStorage triggers ResourceWarning sometimes In-Reply-To: <1373190601.25.0.575768158618.issue18394@psf.upfronthosting.co.za> Message-ID: <1389547315.7.0.926771941319.issue18394@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon keywords: +3.3regression -patch nosy: +larry priority: normal -> release blocker status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 18:32:50 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 12 Jan 2014 17:32:50 +0000 Subject: [issue17373] Add inspect.Signature.from_callable() In-Reply-To: <1389478438.29.0.853107057278.issue17373@psf.upfronthosting.co.za> Message-ID: Eric Snow added the comment: The difference is that inspect.signature is not friendly to Signature subclasses. Without from_callable you can't customize the behavior in inspect.signature easily. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 18:41:55 2014 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 12 Jan 2014 17:41:55 +0000 Subject: [issue17373] Add inspect.Signature.from_callable() In-Reply-To: <1362642709.69.0.481380147826.issue17373@psf.upfronthosting.co.za> Message-ID: <1389548515.19.0.242310312689.issue17373@psf.upfronthosting.co.za> Yury Selivanov added the comment: > The difference is that inspect.signature is not friendly to Signature > subclasses. Without from_callable you can't customize the behavior in > inspect.signature easily. OK, suppose you have "Signature.from_callable". You then create a subclass MySignature, and override it. How can you customize 'inspect.signature' to use the MySignature class? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 18:53:38 2014 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 12 Jan 2014 17:53:38 +0000 Subject: [issue17373] Add inspect.Signature.from_callable() In-Reply-To: <1362642709.69.0.481380147826.issue17373@psf.upfronthosting.co.za> Message-ID: <1389549218.28.0.609545013596.issue17373@psf.upfronthosting.co.za> Yury Selivanov added the comment: Eric, Moreover, 'Signature.from_function' and newly added 'Signature.from_builtin' are private API, or implementation detail (they are not part of PEP, not mentioned in the docs). If at some point it is needed to rewrite Signature in C, probably those two won't be a part of a new implementation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 18:58:42 2014 From: report at bugs.python.org (Eric Snow) Date: Sun, 12 Jan 2014 17:58:42 +0000 Subject: [issue17373] Add inspect.Signature.from_callable() In-Reply-To: <1389548515.19.0.242310312689.issue17373@psf.upfronthosting.co.za> Message-ID: Eric Snow added the comment: It's not about customizing inspect.signature. It's about customizing the nice behavior of that function, including what type it returns. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 19:09:44 2014 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 12 Jan 2014 18:09:44 +0000 Subject: [issue17373] Add inspect.Signature.from_callable() In-Reply-To: <1362642709.69.0.481380147826.issue17373@psf.upfronthosting.co.za> Message-ID: <1389550184.31.0.499633191175.issue17373@psf.upfronthosting.co.za> Yury Selivanov added the comment: OK, got it now. Green light from me. Looking through the code, I saw that 'from_builtin' doesn't use the 'Signature._parameter_cls' (as in from_function). That's probably needs to be fixed as well, maybe in a separate issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 19:13:40 2014 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 12 Jan 2014 18:13:40 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389550420.63.0.00915274797169.issue20189@psf.upfronthosting.co.za> Yury Selivanov added the comment: Larry, just a small thing.. Could you please add something like "Parameter = cls._parameter_cls" in the "from_builtin" method? (see the discussion in #17373) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 19:22:02 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sun, 12 Jan 2014 18:22:02 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1389550922.49.0.509051101052.issue7776@psf.upfronthosting.co.za> Nikolaus Rath added the comment: I've updated the patch again to fix a problem with HTTPSConnection. ---------- Added file: http://bugs.python.org/file33431/issue7776.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 19:22:41 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 12 Jan 2014 18:22:41 +0000 Subject: [issue20214] Argument Clinic rollup fixes In-Reply-To: <1389317138.57.0.101674386167.issue20214@psf.upfronthosting.co.za> Message-ID: <1389550961.51.0.242582181994.issue20214@psf.upfronthosting.co.za> Larry Hastings added the comment: Third patch, with these new features: * Relaxed rules regarding c_default and py_default; they can now be used even when no default value is supplied. * Added bool return converter. * Made one fail() call easier to read, through the power of str.format(). * More doc updates and fixes. ---------- Added file: http://bugs.python.org/file33432/larry.argument.clinic.misc.fixes.patch.3.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 20:10:15 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jan 2014 19:10:15 +0000 Subject: [issue20214] Argument Clinic rollup fixes In-Reply-To: <1389317138.57.0.101674386167.issue20214@psf.upfronthosting.co.za> Message-ID: <3f2SDl1nr8z7Ljk@mail.python.org> Roundup Robot added the comment: New changeset 3eee3967d03f by Larry Hastings in branch 'default': Issue #20214: Fixed a number of small issues and documentation errors in http://hg.python.org/cpython/rev/3eee3967d03f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 20:44:16 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 12 Jan 2014 19:44:16 +0000 Subject: [issue20201] Argument Clinic: rwbuffer support broken In-Reply-To: <1389242396.52.0.166931579233.issue20201@psf.upfronthosting.co.za> Message-ID: <1389555856.3.0.180933882111.issue20201@psf.upfronthosting.co.za> Larry Hastings added the comment: Fixed as part of the rollup patch in #20214. ---------- assignee: -> larry resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 22:11:48 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 12 Jan 2014 21:11:48 +0000 Subject: [issue20228] Argument Clinic should understand Python special methods Message-ID: <1389561108.74.0.0249800725928.issue20228@psf.upfronthosting.co.za> New submission from Larry Hastings: As per Georg's request (and hacks in other places), Argument Clinic should have support for special methods. To wit: __init__ should be required to be an instance method. Clinic should suppress its methoddef #define. __new__ should be required to be a class method. Its C function name should have the __new__ stripped off, and by convention its first argument should be "PyTypeObject *type". Clinic should suppress its methoddef #define. All other dunder-methods which have special slots in the PyTypeObject structure should be rejected by Argument Clinic. (Their arguments are pre-parsed, and they don't have docstrings... what would Clinic do for them?) Obviously generic dunder-methods ("__getstate__", "__sizeof__") are still fine. ---------- assignee: larry components: Demos and Tools files: larry.special.methods.support.patch.1.txt messages: 207980 nosy: georg.brandl, larry priority: normal severity: normal stage: patch review status: open title: Argument Clinic should understand Python special methods type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file33433/larry.special.methods.support.patch.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 22:26:50 2014 From: report at bugs.python.org (Fabian Kochem) Date: Sun, 12 Jan 2014 21:26:50 +0000 Subject: [issue8876] distutils should not assume that hardlinks will work In-Reply-To: <1275485916.86.0.44676570948.issue8876@psf.upfronthosting.co.za> Message-ID: <1389562010.18.0.686095874423.issue8876@psf.upfronthosting.co.za> Changes by Fabian Kochem : ---------- nosy: +Fabian.Kochem _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 22:31:51 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 12 Jan 2014 21:31:51 +0000 Subject: [issue20228] Argument Clinic should understand Python special methods In-Reply-To: <1389561108.74.0.0249800725928.issue20228@psf.upfronthosting.co.za> Message-ID: <1389562311.9.0.687911132117.issue20228@psf.upfronthosting.co.za> Larry Hastings added the comment: Updated patch incorporating changes from Georg Brandl. Thanks Georg! ---------- Added file: http://bugs.python.org/file33434/larry.special.methods.support.patch.2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 22:44:44 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Sun, 12 Jan 2014 21:44:44 +0000 Subject: [issue20202] ArgumentClinic howto: document change in Py_buffer lifecycle management In-Reply-To: <1389250062.45.0.978565094508.issue20202@psf.upfronthosting.co.za> Message-ID: <1389563084.23.0.897244922995.issue20202@psf.upfronthosting.co.za> Ryan Smith-Roberts added the comment: Thank you for including the doc change in your other patch. As the grammar was off, instead of just fixing it I naturally rewrote it. Use this patch or just remove the extraneous "for you" as you prefer. ---------- keywords: +patch Added file: http://bugs.python.org/file33435/argument_clinic_PyBuffer_release.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 23:00:14 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 12 Jan 2014 22:00:14 +0000 Subject: [issue20202] ArgumentClinic howto: document change in Py_buffer lifecycle management In-Reply-To: <1389250062.45.0.978565094508.issue20202@psf.upfronthosting.co.za> Message-ID: <1389564014.16.0.382801443208.issue20202@psf.upfronthosting.co.za> Larry Hastings added the comment: Fixed in revision 43e109ca9018. Well, changed anyway, maybe it's still not wonderful text. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 23:04:41 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Sun, 12 Jan 2014 22:04:41 +0000 Subject: [issue20174] Derby #5: Convert 50 sites to Argument Clinic across 3 files In-Reply-To: <1389138461.92.0.709656306175.issue20174@psf.upfronthosting.co.za> Message-ID: <1389564281.21.0.30069157401.issue20174@psf.upfronthosting.co.za> Ryan Smith-Roberts added the comment: Just discovered that the bugtracker mail was all going into my spam filter, yay. Didn't notice your reply until just now. The functools patch was just a quickie to get it out of my mental queue, and I'm still working on socketmodule. This is my first time using the Python bugtracker, I don't know if multipart patches are acceptable? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 23:07:14 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 12 Jan 2014 22:07:14 +0000 Subject: [issue20174] Derby #5: Convert 50 sites to Argument Clinic across 3 files In-Reply-To: <1389138461.92.0.709656306175.issue20174@psf.upfronthosting.co.za> Message-ID: <1389564434.15.0.604310362409.issue20174@psf.upfronthosting.co.za> Larry Hastings added the comment: I don't know what you mean by a "multipart patch", but the bug tracker has handled every patch I've thrown at it so far. (Assuming that the patch is based on a reasonably fresh checkout of trunk.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 23:13:18 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jan 2014 22:13:18 +0000 Subject: [issue20228] Argument Clinic should understand Python special methods In-Reply-To: <1389561108.74.0.0249800725928.issue20228@psf.upfronthosting.co.za> Message-ID: <3f2XHw1Qb1z7Lm2@mail.python.org> Roundup Robot added the comment: New changeset bc5f257f5cc1 by Larry Hastings in branch 'default': Issue #20228: Argument Clinic now has special support for class special http://hg.python.org/cpython/rev/bc5f257f5cc1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 12 23:13:55 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 12 Jan 2014 22:13:55 +0000 Subject: [issue20228] Argument Clinic should understand Python special methods In-Reply-To: <1389561108.74.0.0249800725928.issue20228@psf.upfronthosting.co.za> Message-ID: <1389564835.48.0.773004127442.issue20228@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 01:03:50 2014 From: report at bugs.python.org (Marc Tamlyn) Date: Mon, 13 Jan 2014 00:03:50 +0000 Subject: [issue20229] platform.py uses deprecated feature of plistlib Message-ID: <1389571430.72.0.704873561263.issue20229@psf.upfronthosting.co.za> New submission from Marc Tamlyn: platform.mac_ver() triggers the following deprecation warning: python3.4 -Wall Python 3.4.0b2 (v3.4.0b2:ba32913eb13e, Jan 5 2014, 11:02:52) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import platform >>> platform.mac_ver() /Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/platform.py:652: DeprecationWarning: The readPlist function is deprecated, use load() instead pl = plistlib.readPlist(fn) ('10.9.1', ('', '', ''), 'x86_64') ---------- assignee: ronaldoussoren components: Macintosh messages: 207987 nosy: Marc.Tamlyn, ronaldoussoren priority: normal severity: normal status: open title: platform.py uses deprecated feature of plistlib versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 01:08:13 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 13 Jan 2014 00:08:13 +0000 Subject: [issue19082] Lib/xmlrpc/client.py demo code points to the dead server In-Reply-To: <1380034126.83.0.318957814744.issue19082@psf.upfronthosting.co.za> Message-ID: <3f2ZrX4WmFz7Lkt@mail.python.org> Roundup Robot added the comment: New changeset 1730f4a97cbb by Senthil Kumaran in branch '2.7': Issue #19082: Working SimpleXMLRPCServer and xmlrpclib examples, both in modules and documentation. http://hg.python.org/cpython/rev/1730f4a97cbb New changeset 72560f9bb2a2 by Senthil Kumaran in branch '3.3': Issue #19082: Working xmlrpc.server and xmlrpc.client examples. Both in modules and in documentation. http://hg.python.org/cpython/rev/72560f9bb2a2 New changeset bdf6c0135d39 by Senthil Kumaran in branch 'default': merge from 3.3 http://hg.python.org/cpython/rev/bdf6c0135d39 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 01:08:57 2014 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 13 Jan 2014 00:08:57 +0000 Subject: [issue19082] Lib/xmlrpc/client.py demo code points to the dead server In-Reply-To: <1380034126.83.0.318957814744.issue19082@psf.upfronthosting.co.za> Message-ID: <1389571737.9.0.477386562289.issue19082@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Addressed this in all active branches (2.7, 3.3 and 3.4). Thanks! ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 02:01:56 2014 From: report at bugs.python.org (Julian Gindi) Date: Mon, 13 Jan 2014 01:01:56 +0000 Subject: [issue18983] Specify time unit for timeit CLI In-Reply-To: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za> Message-ID: <1389574916.82.0.645510964647.issue18983@psf.upfronthosting.co.za> Julian Gindi added the comment: What needs to be done to close this one out? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 02:12:54 2014 From: report at bugs.python.org (Andrew Barnert) Date: Mon, 13 Jan 2014 01:12:54 +0000 Subject: [issue20230] structseq types should expose _fields Message-ID: <1389575574.46.0.402404595733.issue20230@psf.upfronthosting.co.za> New submission from Andrew Barnert: A PyStructSequence type doesn't expose its field names in any way to Python code (except indirectly, via the repr, which you could parse if you really wanted to?). The docs claim that "Struct sequence objects are the C equivalent of namedtuple() objects", so it seems like the obvious way to expose them is the exact same way namedtuple types do?as a class attribute named "_fields". Also, in #7796, and in a recent thread on python-ideas, multiple people suggested that "named tuple" is a protocol, not a type, and duck typing on _fields is the obvious way to detect types matching that protocol. Only the "sequence fields" need to be exposed?fields that don't match up to sequence indices aren't named tuple fields, they're just extra instance attributes (that don't even show up in the repr). Patch included. For the tests, I tested the fields in struct_time and stat_result in effectively the same way test_repr tests their repr, so it should pass on all the same platforms/builds. ---------- files: structseq.diff keywords: patch messages: 207991 nosy: abarnert priority: normal severity: normal status: open title: structseq types should expose _fields type: enhancement Added file: http://bugs.python.org/file33436/structseq.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 02:14:13 2014 From: report at bugs.python.org (Meador Inge) Date: Mon, 13 Jan 2014 01:14:13 +0000 Subject: [issue20230] structseq types should expose _fields In-Reply-To: <1389575574.46.0.402404595733.issue20230@psf.upfronthosting.co.za> Message-ID: <1389575653.96.0.647887765353.issue20230@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 02:15:13 2014 From: report at bugs.python.org (Andrew Barnert) Date: Mon, 13 Jan 2014 01:15:13 +0000 Subject: [issue7796] No way to find out if an object is an instance of a namedtuple In-Reply-To: <1264608669.85.0.379125118171.issue7796@psf.upfronthosting.co.za> Message-ID: <1389575713.72.0.753931466236.issue7796@psf.upfronthosting.co.za> Andrew Barnert added the comment: I believe the structseq issues are a lot easier to solve than the appear. See #20230, which adds a _fields member to every structseq type. Having done that, a NamedTuple ABC works on them just fine. And of course duck typing them without an ABC does too. ---------- nosy: +abarnert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 02:26:53 2014 From: report at bugs.python.org (Andrew Barnert) Date: Mon, 13 Jan 2014 01:26:53 +0000 Subject: [issue20230] structseq types should expose _fields In-Reply-To: <1389575574.46.0.402404595733.issue20230@psf.upfronthosting.co.za> Message-ID: <1389576413.71.0.611201861267.issue20230@psf.upfronthosting.co.za> Andrew Barnert added the comment: After more searching (I should have searched on structseq instead of PyStructSequence?), this might be a dup of #1820. If so, apologies. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 02:31:59 2014 From: report at bugs.python.org (Andrew Barnert) Date: Mon, 13 Jan 2014 01:31:59 +0000 Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple api In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za> Message-ID: <1389576719.77.0.9314989552.issue1820@psf.upfronthosting.co.za> Andrew Barnert added the comment: See issue20230, which includes a patch implementing just the first part of part 2 (adding _fields, but not _asdict or _replace). Since this one has been open for 5+ years, if it's not going to be done soon, any chance of the easy (_fields) change being committed and putting off the harder parts until later? ---------- nosy: +abarnert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 02:32:52 2014 From: report at bugs.python.org (Ethan Furman) Date: Mon, 13 Jan 2014 01:32:52 +0000 Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple api In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za> Message-ID: <1389576772.72.0.297740562365.issue1820@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 02:33:04 2014 From: report at bugs.python.org (Ethan Furman) Date: Mon, 13 Jan 2014 01:33:04 +0000 Subject: [issue20230] structseq types should expose _fields In-Reply-To: <1389575574.46.0.402404595733.issue20230@psf.upfronthosting.co.za> Message-ID: <1389576784.85.0.341394600083.issue20230@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 02:41:22 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Mon, 13 Jan 2014 01:41:22 +0000 Subject: [issue18983] Specify time unit for timeit CLI In-Reply-To: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za> Message-ID: <1389577282.41.0.425708098761.issue18983@psf.upfronthosting.co.za> Vajrasky Kok added the comment: This feature is for Python 3.5. I think, we will not commit anything to Python 3.5 until Python 3.4 branch is created (in other world, released). So, be patient. :) ---------- nosy: +vajrasky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 02:51:57 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 13 Jan 2014 01:51:57 +0000 Subject: [issue20229] platform.py uses deprecated feature of plistlib In-Reply-To: <1389571430.72.0.704873561263.issue20229@psf.upfronthosting.co.za> Message-ID: <1389577917.34.0.907539814698.issue20229@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the report! Here's a patch. ---------- keywords: +needs review nosy: +ned.deily stage: -> patch review Added file: http://bugs.python.org/file33437/issue20229.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 03:31:55 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Mon, 13 Jan 2014 02:31:55 +0000 Subject: [issue20231] Argument Clinic accepts no-default args after default args Message-ID: <1389580315.91.0.810075963733.issue20231@psf.upfronthosting.co.za> New submission from Ryan Smith-Roberts: A signature of the form a: object = None b: object results in b being uninitialized in the generated C code prior to the PyArgs_ParseTuple call. If ParseTuple does not set a value for b (as it is an optional argument), b then contains a garbage pointer and the interpreter may segfault. AC should reject this configuration. ---------- components: Build messages: 207997 nosy: larry, rmsr priority: normal severity: normal status: open title: Argument Clinic accepts no-default args after default args versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 03:32:32 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Mon, 13 Jan 2014 02:32:32 +0000 Subject: [issue20231] Argument Clinic accepts no-default args after default args In-Reply-To: <1389580315.91.0.810075963733.issue20231@psf.upfronthosting.co.za> Message-ID: <1389580352.21.0.619728853554.issue20231@psf.upfronthosting.co.za> Changes by Ryan Smith-Roberts : ---------- type: -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 03:53:18 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Mon, 13 Jan 2014 02:53:18 +0000 Subject: [issue20232] Argument Clinic NULL default falsely implies None acceptability Message-ID: <1389581598.8.0.840632015553.issue20232@psf.upfronthosting.co.za> New submission from Ryan Smith-Roberts: When one specifies a default of NULL, the generated signature doc indicates a default of None. However, if the user actually supplies None, perhaps as a placeholder in a positional-only call, C code which only checks for NULL will fail inappropriately. The solution may be to convert a None object to a null pointer in the wrapper. ---------- components: Build messages: 207998 nosy: larry, rmsr priority: normal severity: normal status: open title: Argument Clinic NULL default falsely implies None acceptability type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 04:20:33 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Mon, 13 Jan 2014 03:20:33 +0000 Subject: [issue20232] Argument Clinic NULL default falsely implies None acceptability In-Reply-To: <1389581598.8.0.840632015553.issue20232@psf.upfronthosting.co.za> Message-ID: <1389583233.94.0.725076091291.issue20232@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Yes, this issue bothers me. Currently _sha1.sha1 constructor will use NULL (not None) value if used without parameters: _sha1.sha1() _sha1.sha1(None) will throw error while _sha1.sha1() won't. So for NULL (not None) default value, the generated signature _sha1.sha1(string=None) is kinda misleading. I am not sure what is the correct signature should be without changing behaviour. ---------- nosy: +vajrasky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 04:28:40 2014 From: report at bugs.python.org (Meador Inge) Date: Mon, 13 Jan 2014 03:28:40 +0000 Subject: [issue20178] Derby #9: Convert 52 sites to Argument Clinic across 11 files In-Reply-To: <1389140078.91.0.720761635456.issue20178@psf.upfronthosting.co.za> Message-ID: <1389583720.16.0.158547804292.issue20178@psf.upfronthosting.co.za> Meador Inge added the comment: Larry, the attached patch converts what is convertible of Modules/_ctypes/_ctypes. Although, I ran into an odd case with this conversion: the converted functions are each used in *multiple* PyMethodDef tables. So while clinic can generate equivalent code, the builtins are not all pinned to one type. The type I pinned it to is the same type that the methods are documented against: http://docs.python.org/2/library/ctypes.html#ctypes._CData Since clinic makes you explicitly specify the fully qualified method name, I assume sharing like this is not allowed. Thoughts? ---------- keywords: +patch Added file: http://bugs.python.org/file33438/issue20178-cyptes-01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 04:32:45 2014 From: report at bugs.python.org (Meador Inge) Date: Mon, 13 Jan 2014 03:32:45 +0000 Subject: [issue20178] Derby #9: Convert 52 sites to Argument Clinic across 11 files In-Reply-To: <1389140078.91.0.720761635456.issue20178@psf.upfronthosting.co.za> Message-ID: <1389583965.96.0.86328700972.issue20178@psf.upfronthosting.co.za> Meador Inge added the comment: None of the sites in Modules/_curses_panel.c look convertible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 04:46:55 2014 From: report at bugs.python.org (Benno Rice) Date: Mon, 13 Jan 2014 03:46:55 +0000 Subject: [issue20233] Re-enable buffer API slots for heap types Message-ID: <1389584815.64.0.0171986621456.issue20233@psf.upfronthosting.co.za> New submission from Benno Rice: The API slots for bf_getbuffer and bf_releasebuffer are still disabled despite the bug referenced (issue 10181) being marked as fixed. These should be re-enabled if the stable ABI is to be used for types that use buffers. ---------- components: Extension Modules messages: 208002 nosy: Benno.Rice priority: normal severity: normal status: open title: Re-enable buffer API slots for heap types type: enhancement versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 04:47:35 2014 From: report at bugs.python.org (Benno Rice) Date: Mon, 13 Jan 2014 03:47:35 +0000 Subject: [issue20233] Re-enable buffer API slots for heap types In-Reply-To: <1389584815.64.0.0171986621456.issue20233@psf.upfronthosting.co.za> Message-ID: <1389584855.35.0.564482708223.issue20233@psf.upfronthosting.co.za> Changes by Benno Rice : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 04:51:12 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 13 Jan 2014 03:51:12 +0000 Subject: [issue20227] Argument Clinic: rename arguments in generated C? In-Reply-To: <1389524736.75.0.620647933805.issue20227@psf.upfronthosting.co.za> Message-ID: <1389585072.15.0.10350224512.issue20227@psf.upfronthosting.co.za> Zachary Ware added the comment: I second this request. Every PyArg_ParseTupleAndKeywords-using function in _winapi has a keyword argument "overlapped" which is stuffed into a C variable "use_overlapped", while the local variable "overlapped" is used for an Overlapped object, which makes for a big hairy diff. There are also several PyArg_ParseTuple-using functions that have the same kind of name mismatch, but since the names don't really mean anything on the Python side when they're positional-only, I don't feel too bad about changing them to make them make sense (or to avoid churn). Although, for this: Georg Brandl wrote: > sometimes the function uses 'O' in PyArg_ParseTuple and then converts the object itself with a nontrivial process. This kind of case is a good candidate for considering a custom converter; posixmodule.c has a good example with a path_t converter that I used for a guide in writing one for HKEY in winreg.c. Of course, if that 'nontrivial process' is only done once in one function, a custom converter doesn't make a whole lot of sense, but a rename does. ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 05:26:48 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 13 Jan 2014 04:26:48 +0000 Subject: [issue20230] structseq types should expose _fields In-Reply-To: <1389575574.46.0.402404595733.issue20230@psf.upfronthosting.co.za> Message-ID: <1389587208.98.0.248520588541.issue20230@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- components: +Interpreter Core, Library (Lib) versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 05:27:12 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 13 Jan 2014 04:27:12 +0000 Subject: [issue20230] structseq types should expose _fields In-Reply-To: <1389575574.46.0.402404595733.issue20230@psf.upfronthosting.co.za> Message-ID: <1389587232.82.0.451056320301.issue20230@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 05:46:02 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 13 Jan 2014 04:46:02 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1389588362.01.0.558632159198.issue20172@psf.upfronthosting.co.za> Zachary Ware added the comment: And here is the patch to _winapi.c. ---------- Added file: http://bugs.python.org/file33439/issue20172._winapi.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 07:39:30 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 13 Jan 2014 06:39:30 +0000 Subject: [issue20227] Argument Clinic: rename arguments in generated C? In-Reply-To: <1389524736.75.0.620647933805.issue20227@psf.upfronthosting.co.za> Message-ID: <1389595170.4.0.344889344423.issue20227@psf.upfronthosting.co.za> Georg Brandl added the comment: > There are also several PyArg_ParseTuple-using functions that have the > same kind of name mismatch, but since the names don't really mean > anything on the Python side when they're positional-only, I don't feel > too bad about changing them to make them make sense (or to avoid churn). Although now is a good time to ensure sensible argument names (I usually look at the docs to find the documented ones), so that switching the function to keyword arg support is basically just a removal of '/'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 07:40:19 2014 From: report at bugs.python.org (Akira Kitada) Date: Mon, 13 Jan 2014 06:40:19 +0000 Subject: [issue6625] UnicodeEncodeError on pydoc's CLI In-Reply-To: <1249218048.23.0.0483172452601.issue6625@psf.upfronthosting.co.za> Message-ID: <1389595219.49.0.514645267973.issue6625@psf.upfronthosting.co.za> Akira Kitada added the comment: I suppose this is a duplicate of #1065986. ---------- nosy: +akitada _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 07:56:43 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 13 Jan 2014 06:56:43 +0000 Subject: [issue20234] Argument Clinic: use PyTuple_GET_SIZE? Message-ID: <1389596202.96.0.0154982234114.issue20234@psf.upfronthosting.co.za> New submission from Georg Brandl: In the presence of [ ] , clinic generates PyTuple_Size() calls. Since argument tuples always are tuples, you can use the macro form PyTuple_GET_SIZE() to speed it up. ---------- assignee: larry messages: 208007 nosy: georg.brandl, larry priority: normal severity: normal status: open title: Argument Clinic: use PyTuple_GET_SIZE? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 08:02:27 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 13 Jan 2014 07:02:27 +0000 Subject: [issue20235] Argument Clinic: recover a bit more gracefully from exceptions Message-ID: <1389596547.42.0.103155756972.issue20235@psf.upfronthosting.co.za> New submission from Georg Brandl: I had specified c_default=-1 (note missing quotes) somewhere, and it raises an exception during the clinic --make run; there was no indication which file/line this was on. Suggested patch attached. ---------- assignee: larry files: clinic_exception_reporting.patch keywords: patch messages: 208008 nosy: georg.brandl, larry priority: normal severity: normal status: open title: Argument Clinic: recover a bit more gracefully from exceptions Added file: http://bugs.python.org/file33440/clinic_exception_reporting.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 08:07:09 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 13 Jan 2014 07:07:09 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1389596829.89.0.85873692215.issue20186@psf.upfronthosting.co.za> Changes by Georg Brandl : Removed file: http://bugs.python.org/file33419/mathmodule_part1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 08:07:16 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 13 Jan 2014 07:07:16 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1389596836.08.0.307773406934.issue20186@psf.upfronthosting.co.za> Changes by Georg Brandl : Removed file: http://bugs.python.org/file33422/csv_module_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 08:07:19 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 13 Jan 2014 07:07:19 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1389596839.96.0.959638029649.issue20186@psf.upfronthosting.co.za> Changes by Georg Brandl : Removed file: http://bugs.python.org/file33423/tracemalloc_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 08:07:25 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 13 Jan 2014 07:07:25 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1389596845.15.0.269963642717.issue20186@psf.upfronthosting.co.za> Changes by Georg Brandl : Removed file: http://bugs.python.org/file33424/io_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 08:07:29 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 13 Jan 2014 07:07:29 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1389596849.41.0.266988419544.issue20186@psf.upfronthosting.co.za> Changes by Georg Brandl : Removed file: http://bugs.python.org/file33425/heapq_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 08:07:33 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 13 Jan 2014 07:07:33 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1389596853.57.0.551349095492.issue20186@psf.upfronthosting.co.za> Changes by Georg Brandl : Removed file: http://bugs.python.org/file33426/lsprof_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 08:07:43 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 13 Jan 2014 07:07:43 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1389596863.81.0.541552072273.issue20186@psf.upfronthosting.co.za> Georg Brandl added the comment: OK, new patches coming in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 08:11:30 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 13 Jan 2014 07:11:30 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1389597090.02.0.477824996322.issue20182@psf.upfronthosting.co.za> Changes by Georg Brandl : Removed file: http://bugs.python.org/file33428/signal_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 08:11:33 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 13 Jan 2014 07:11:33 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1389597093.77.0.574976686249.issue20182@psf.upfronthosting.co.za> Changes by Georg Brandl : Removed file: http://bugs.python.org/file33429/sys_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 08:13:11 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 13 Jan 2014 07:13:11 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1389597191.21.0.517117268691.issue20182@psf.upfronthosting.co.za> Georg Brandl added the comment: New patch. In selectmodule.c I haven't touched devpoll and kqueue, which I can't compile here. _hashopenssl does weird things with macros, I'm waiting with that. ---------- Added file: http://bugs.python.org/file33441/modules_issue20182.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 08:14:05 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 13 Jan 2014 07:14:05 +0000 Subject: [issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files In-Reply-To: <1389140586.13.0.921060348978.issue20186@psf.upfronthosting.co.za> Message-ID: <1389597245.02.0.367571920331.issue20186@psf.upfronthosting.co.za> Georg Brandl added the comment: Actually I put all I have in one. Rietveld doesn't care. The mathmodule still awaits some kind of solution for the macro atrocities. Objects will be attacked next. ---------- Added file: http://bugs.python.org/file33442/modules_issue20186.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 08:16:44 2014 From: report at bugs.python.org (INADA Naoki) Date: Mon, 13 Jan 2014 07:16:44 +0000 Subject: [issue20236] Invalid inline markup in xml document. Message-ID: <1389597404.75.0.92024373365.issue20236@psf.upfronthosting.co.za> New submission from INADA Naoki: http://docs.python.org/3.3/library/xml.html#xml-vulnerabilities > DTD retrieval > Some XML libraries like Python?s mod:?xml.dom.pulldom? retrieve document mod: should be :mod: ---------- assignee: docs at python components: Documentation messages: 208012 nosy: docs at python, naoki priority: normal severity: normal status: open title: Invalid inline markup in xml document. versions: Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 09:40:41 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 13 Jan 2014 08:40:41 +0000 Subject: [issue6625] UnicodeEncodeError on pydoc's CLI In-Reply-To: <1249218048.23.0.0483172452601.issue6625@psf.upfronthosting.co.za> Message-ID: <1389602441.82.0.863561868217.issue6625@psf.upfronthosting.co.za> Berker Peksag added the comment: > I suppose this is a duplicate of #1065986. Yes, it is. I created a test file from the tests in issue6625_pydoc.diff and ran it on the current 2.7 branch. def foo(): u"""fooo bar baz \xfcnicode\u2026""" return 42 def bar(): u"f\xfcr Elise" return 11 ---------- nosy: +berker.peksag resolution: -> out of date stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 10:20:09 2014 From: report at bugs.python.org (Akira Kitada) Date: Mon, 13 Jan 2014 09:20:09 +0000 Subject: [issue1185124] pydoc doesn't find all module doc strings Message-ID: <1389604809.4.0.992052938851.issue1185124@psf.upfronthosting.co.za> Akira Kitada added the comment: I tried pydoc_2.7.patch with the following test file and found source_synopsis returns \x escaped string instead of \u escaped one. # -*- coding: utf-8 -*- u"""?""" class Spam(object): u"""?""" >>> import utf8 >>> utf8.__doc__ u'\u30c4' >>> print(utf8.__doc__) ? >>> import pydoc >>> pydoc.source_synopsis(file('utf8.py')) u'\xe3\x83\x84' >>> print pydoc.source_synopsis(file('utf8.py')) ??? >>> print pydoc.source_synopsis(file('utf8.py')).encode('latin-1') ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 11:13:46 2014 From: report at bugs.python.org (INADA Naoki) Date: Mon, 13 Jan 2014 10:13:46 +0000 Subject: [issue20237] Ambiguous sentence in document of xml package. Message-ID: <1389608026.69.0.492339232238.issue20237@psf.upfronthosting.co.za> New submission from INADA Naoki: http://docs.python.org/3.3/library/xml.html#defused-packages "The courses of action are recommended for any server code that parses untrusted XML data." What this sentence means? What "The courses" is? ---------- assignee: docs at python components: Documentation messages: 208015 nosy: docs at python, naoki priority: normal severity: normal status: open title: Ambiguous sentence in document of xml package. versions: Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 11:18:03 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 13 Jan 2014 10:18:03 +0000 Subject: [issue20229] platform.py uses deprecated feature of plistlib In-Reply-To: <1389571430.72.0.704873561263.issue20229@psf.upfronthosting.co.za> Message-ID: <1389608283.78.0.22720526859.issue20229@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is no need to indent any except the "pl = plistlib.load(f)" line. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 11:24:43 2014 From: report at bugs.python.org (Martin Panter) Date: Mon, 13 Jan 2014 10:24:43 +0000 Subject: [issue20238] Incomplete gzip output with tarfile.open(fileobj=..., mode="w:gz") Message-ID: <1389608683.35.0.244495356969.issue20238@psf.upfronthosting.co.za> New submission from Martin Panter: I am trying to create a tar file after opening it as a temporary file, and it seems to be writing truncated output when I use mode="w:gz". My workaround looks like it will be to use mode="w|gz" instead. It?s not clear what the difference is: am I losing anything practical by disallowing ?random? seeking? Simplified demonstration: >>> from io import BytesIO; b = BytesIO() >>> import tarfile; t = tarfile.open(fileobj=b, mode="w:gz") >>> t._extfileobj True >>> type(t.fileobj) >>> t.close() >>> b.getvalue() b'\x1f\x8b\x08\x00]\xb8\xd3R\x02\xff' >>> del t >>> b.getvalue() b"\x1f\x8b\x08\x00]\xb8\xd3R\x02\xff\xed\xc1\x01\r\x00\x00\x00\xc2\xa0\xf7Om\x0e7\xa0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x807\x03\x9a\xde\x1d'\x00(\x00\x00" Looking at the code, the TarFile.close() method would not be closing the GzipFile object because of this condition: if not self._extfileobj: self.fileobj.close() Perhaps it needs to also check if file compression is being used or something; I?m not familiar with the internals. I did notice that the bug happens with Python 3.3.3 and 3.2.3, but not 2.7.5. Also, I do not see the issue when a file name is passed to tarfile.open() rather than a file object, nor do I see it with the bzip or XZ compressors, uncompressed tar creation, or the ?special purposes? w|gz mode. ---------- components: Library (Lib) messages: 208017 nosy: vadmium priority: normal severity: normal status: open title: Incomplete gzip output with tarfile.open(fileobj=..., mode="w:gz") type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 11:56:30 2014 From: report at bugs.python.org (Torsten Landschoff) Date: Mon, 13 Jan 2014 10:56:30 +0000 Subject: [issue6625] UnicodeEncodeError on pydoc's CLI In-Reply-To: <1249218048.23.0.0483172452601.issue6625@psf.upfronthosting.co.za> Message-ID: <1389610590.75.0.65016498828.issue6625@psf.upfronthosting.co.za> Torsten Landschoff added the comment: I tested this as well and it seems to work now. :-) Thanks for fixing it! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 12:15:01 2014 From: report at bugs.python.org (Michael Foord) Date: Mon, 13 Jan 2014 11:15:01 +0000 Subject: [issue20239] Allow repeated deletion of unittest.mock.Mock attributes Message-ID: <1389611701.97.0.048361560176.issue20239@psf.upfronthosting.co.za> New submission from Michael Foord: Reported as mock issue 221: http://code.google.com/p/mock/issues/detail?id=221 >>> from unittest.mock import Mock >>> m = Mock() >>> m.foo = 3 >>> del m.foo >>> m.foo = 4 >>> del m.foo Traceback (most recent call last): File "", line 1, in File "/compile/py3k-cpython/Lib/unittest/mock.py", line 687, in __delattr__ raise AttributeError(name) AttributeError: foo Suggested change: Previous: def __delattr__(self, name): if name in _all_magics and name in type(self).__dict__: delattr(type(self), name) if name not in self.__dict__: # for magic methods that are still MagicProxy objects and # not set on the instance itself return if name in self.__dict__: object.__delattr__(self, name) obj = self._mock_children.get(name, _missing) if obj is _deleted: raise AttributeError(name) if obj is not _missing: del self._mock_children[name] self._mock_children[name] = _deleted Change: def __delattr__(self, name): if name in _all_magics and name in type(self).__dict__: delattr(type(self), name) if name not in self.__dict__: # for magic methods that are still MagicProxy objects and # not set on the instance itself return obj = self._mock_children.get(name, _missing) if name in self.__dict__: object.__delattr__(self, name) elif obj is _deleted: raise AttributeError(name) if obj is not _missing: del self._mock_children[name] self._mock_children[name] = _deleted Incidentally the if ?obj is not _missing? line seems superfluous. ---------- assignee: michael.foord messages: 208019 nosy: michael.foord priority: normal severity: normal stage: needs patch status: open title: Allow repeated deletion of unittest.mock.Mock attributes type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 12:15:34 2014 From: report at bugs.python.org (Dima Tisnek) Date: Mon, 13 Jan 2014 11:15:34 +0000 Subject: [issue4356] Add "key" argument to "bisect" module functions In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za> Message-ID: <1389611734.44.0.673450607362.issue4356@psf.upfronthosting.co.za> Dima Tisnek added the comment: I've worked around this in 2.6/2.7 like this: class Arr: def __getitem__(self, i): return foo(i) # your key function def __len__(self): return 10000000 # your max index value bisect.bisect(Arr(), value, ...) ---------- nosy: +Dima.Tisnek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 12:29:36 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Mon, 13 Jan 2014 11:29:36 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1389612576.92.0.468574642555.issue20173@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the patch for _codecs module. ---------- Added file: http://bugs.python.org/file33443/clinic_codecsmodule.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 12:33:32 2014 From: report at bugs.python.org (Jacek Szpot) Date: Mon, 13 Jan 2014 11:33:32 +0000 Subject: [issue20240] Whitespace ignored in relative imports: from.package import something is valid syntax Message-ID: <1389612812.75.0.909355414267.issue20240@psf.upfronthosting.co.za> New submission from Jacek Szpot: Just wanted to let you know that missing whitespace between "from" and a dot-prefixed name is not considered invalid: from.foo import bar .. does not raise an error. Perhaps it should? ---------- messages: 208022 nosy: maligree priority: normal severity: normal status: open title: Whitespace ignored in relative imports: from.package import something is valid syntax type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 12:40:23 2014 From: report at bugs.python.org (A. Libotean) Date: Mon, 13 Jan 2014 11:40:23 +0000 Subject: [issue20137] Logging: RotatingFileHandler computes string length instead of byte representation length. In-Reply-To: <1388999971.66.0.938288838593.issue20137@psf.upfronthosting.co.za> Message-ID: <1389613223.13.0.750967490105.issue20137@psf.upfronthosting.co.za> A. Libotean added the comment: Sure, will come back shortly with a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 12:41:00 2014 From: report at bugs.python.org (A. Libotean) Date: Mon, 13 Jan 2014 11:41:00 +0000 Subject: [issue20136] Logging: StreamHandler does not use OS line separator. In-Reply-To: <1388998969.13.0.29066681056.issue20136@psf.upfronthosting.co.za> Message-ID: <1389613260.83.0.877412665538.issue20136@psf.upfronthosting.co.za> A. Libotean added the comment: Let me write also a test for this and come back with a reply. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 13:38:25 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 13 Jan 2014 12:38:25 +0000 Subject: [issue20238] Incomplete gzip output with tarfile.open(fileobj=..., mode="w:gz") In-Reply-To: <1389608683.35.0.244495356969.issue20238@psf.upfronthosting.co.za> Message-ID: <1389616705.48.0.853047689512.issue20238@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +lars.gustaebel, nadeem.vawda, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 14:34:24 2014 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 13 Jan 2014 13:34:24 +0000 Subject: [issue20240] Whitespace ignored in relative imports: from.package import something is valid syntax In-Reply-To: <1389612812.75.0.909355414267.issue20240@psf.upfronthosting.co.za> Message-ID: <1389620064.16.0.781314344848.issue20240@psf.upfronthosting.co.za> Eric V. Smith added the comment: This is no different from other places in python where white space is optional. As long as the parser can tell the end of a token, there need not be white space before the next token. For example: >>> 1+2 3 >>> 1 + 2 3 However, if the parser cannot tell the end of a token, white space is required: >>> 1.__add__ File "", line 1 1.__add__ ^ SyntaxError: invalid syntax >>> 1 .__add__ We're not likely to add "required white space" after the "from" token. [I realize that in a "whitespace required" language, this is a slightly odd statement!] ---------- nosy: +eric.smith resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 15:37:55 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 13 Jan 2014 14:37:55 +0000 Subject: [issue20238] Incomplete gzip output with tarfile.open(fileobj=..., mode="w:gz") In-Reply-To: <1389608683.35.0.244495356969.issue20238@psf.upfronthosting.co.za> Message-ID: <1389623875.63.0.4488336293.issue20238@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Martin for you report. Here is a patch which fixes this issue. ---------- assignee: -> serhiy.storchaka keywords: +patch stage: -> patch review versions: +Python 3.4 Added file: http://bugs.python.org/file33444/tarfile_fobj_gz_close.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 16:18:36 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Mon, 13 Jan 2014 15:18:36 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1389626316.82.0.0109547923775.issue20173@psf.upfronthosting.co.za> Changes by Vajrasky Kok : Removed file: http://bugs.python.org/file33443/clinic_codecsmodule.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 16:25:19 2014 From: report at bugs.python.org (INADA Naoki) Date: Mon, 13 Jan 2014 15:25:19 +0000 Subject: [issue20241] Bad reference to RFC in document of ipaddress? Message-ID: <1389626719.4.0.511378840941.issue20241@psf.upfronthosting.co.za> New submission from INADA Naoki: http://docs.python.org/3.3/library/ipaddress.html#ipaddress.IPv4Address.is_unspecified > True if the address is unspecified. See RFC 5375 (for IPv4) or RFC 2373 (for IPv6). RFC 5375 is "IPv6 Unicast Address Assignment Considerations". ---------- assignee: docs at python components: Documentation messages: 208027 nosy: docs at python, naoki priority: normal severity: normal status: open title: Bad reference to RFC in document of ipaddress? versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 16:28:23 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Mon, 13 Jan 2014 15:28:23 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1389626903.68.0.467025149798.issue20173@psf.upfronthosting.co.za> Changes by Vajrasky Kok : Added file: http://bugs.python.org/file33445/clinic_codecsmodule.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 16:30:55 2014 From: report at bugs.python.org (INADA Naoki) Date: Mon, 13 Jan 2014 15:30:55 +0000 Subject: [issue20241] Bad reference to RFC in document of ipaddress? In-Reply-To: <1389626719.4.0.511378840941.issue20241@psf.upfronthosting.co.za> Message-ID: <1389627055.88.0.249608553026.issue20241@psf.upfronthosting.co.za> INADA Naoki added the comment: Is it 5735 ? Next sentence may be wrong, too. > True if the address is otherwise IETF reserved. Is it "True if the address is IETF reserved." ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 16:52:23 2014 From: report at bugs.python.org (Laurent De Buyst) Date: Mon, 13 Jan 2014 15:52:23 +0000 Subject: [issue18622] reset_mock on mock created by mock_open causes infinite recursion In-Reply-To: <1375391057.28.0.108463427813.issue18622@psf.upfronthosting.co.za> Message-ID: <1389628343.54.0.333034006338.issue18622@psf.upfronthosting.co.za> Laurent De Buyst added the comment: The proposed patch does solve the infinite recursion bug, but a different problem appears when resetting the same mock multiple times: it only works the first time. Using the patch as it stands: >>> from unittest.mock import mock_open >>> mo = mock_open() >>> a = mo() >>> mo.call_count 1 >>> mo.reset_mock() >>> mo.call_count 0 >>> b = mo() >>> mo.call_count 1 >>> mo.reset_mock() >>> mo.call_count 1 And here from a version with an added print(visited) statement: >>> from unittest.mock import mock_open >>> mo = mock_open() >>> a = mo() >>> mo.call_count 1 >>> mo.reset_mock() [] [139803191795152] [139803191795152, 139803181189008] [139803191795152, 139803181189008, 139803213598416] [139803191795152, 139803181189008, 139803213598416, 139803213652048] [139803191795152, 139803181189008, 139803213598416, 139803213652048] >>> mo.call_count 0 >>> b = mo() >>> mo.call_count 1 >>> mo.reset_mock() [139803191795152, 139803181189008, 139803213598416, 139803213652048, 139803213598288] >>> mo.call_count 1 >>> mo.reset_mock(visited=[]) [] [139803191795152] [139803191795152, 139803181189008] [139803191795152, 139803181189008, 139803213598416] [139803191795152, 139803181189008, 139803213598416, 139803213652048] [139803191795152, 139803181189008, 139803213598416, 139803213652048] >>> mo.call_count 0 As you can see, for some reason I don't quite grasp, the 'visited' parameter persists across calls to reset_mock(), meaning that the very first call does indeed reset it but subsequent calls do not. As the last two calls show, one can force a reset by explicitly providing an empty list, but this is starting to become a change in API and not just a bugfix... ---------- nosy: +Laurent.De.Buyst _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 19:31:37 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 13 Jan 2014 18:31:37 +0000 Subject: [issue20206] email quoted-printable encoding issue In-Reply-To: <1389277318.78.0.594676720592.issue20206@psf.upfronthosting.co.za> Message-ID: <3f33Kj1LLLz7LjM@mail.python.org> Roundup Robot added the comment: New changeset 4c5b1932354b by R David Murray in branch '3.3': #20206, #5803: more efficient algorithm that doesn't truncate output. http://hg.python.org/cpython/rev/4c5b1932354b New changeset b6c3fc21286f by R David Murray in branch 'default': Merge #20206, #5803: more efficient algorithm that doesn't truncate output. http://hg.python.org/cpython/rev/b6c3fc21286f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 19:31:37 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 13 Jan 2014 18:31:37 +0000 Subject: [issue5803] email/quoprimime: encode and decode are very slow on large messages In-Reply-To: <1240254091.33.0.632025917195.issue5803@psf.upfronthosting.co.za> Message-ID: <3f33Kh2Pykz7LjM@mail.python.org> Roundup Robot added the comment: New changeset 4c5b1932354b by R David Murray in branch '3.3': #20206, #5803: more efficient algorithm that doesn't truncate output. http://hg.python.org/cpython/rev/4c5b1932354b New changeset b6c3fc21286f by R David Murray in branch 'default': Merge #20206, #5803: more efficient algorithm that doesn't truncate output. http://hg.python.org/cpython/rev/b6c3fc21286f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 19:33:56 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 13 Jan 2014 18:33:56 +0000 Subject: [issue5803] email/quoprimime: encode and decode are very slow on large messages In-Reply-To: <1240254091.33.0.632025917195.issue5803@psf.upfronthosting.co.za> Message-ID: <1389638036.62.0.323465981793.issue5803@psf.upfronthosting.co.za> R. David Murray added the comment: I've reviewed this and applied it to both 3.3 and 3.4 in order to fix issue 20206. Thanks, Serhiy. ---------- stage: patch review -> committed/rejected status: open -> closed versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 19:34:07 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 13 Jan 2014 18:34:07 +0000 Subject: [issue20206] email quoted-printable encoding issue In-Reply-To: <1389277318.78.0.594676720592.issue20206@psf.upfronthosting.co.za> Message-ID: <1389638047.86.0.6818871609.issue20206@psf.upfronthosting.co.za> R. David Murray added the comment: Fixed. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 19:41:50 2014 From: report at bugs.python.org (kespindler) Date: Mon, 13 Jan 2014 18:41:50 +0000 Subject: [issue20242] logging style parameter does not work correctly Message-ID: <1389638510.54.0.587733308543.issue20242@psf.upfronthosting.co.za> New submission from kespindler: In Python 3.3, 3.4beta2, and bleeding edge (88411:e7d922d8ee03), the following occurs >>> import logging >>> logging.basicConfig(style="{") >>> logging.error("hello") %(levelname)s:%(name)s:%(message)s Of course, I would expect ERROR:root:hello to be output instead. ---------- components: Library (Lib) messages: 208035 nosy: kespindler priority: normal severity: normal status: open title: logging style parameter does not work correctly type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 19:46:47 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 13 Jan 2014 18:46:47 +0000 Subject: [issue20237] Ambiguous sentence in document of xml package. In-Reply-To: <1389608026.69.0.492339232238.issue20237@psf.upfronthosting.co.za> Message-ID: <1389638807.73.0.0612632939363.issue20237@psf.upfronthosting.co.za> R. David Murray added the comment: It means that the package suggests what courses of action to take when parsing untrusted data. I don't know how it goes about doing that, though, so we'll have to ask Christian to clarify. ---------- assignee: docs at python -> nosy: +christian.heimes, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 19:47:29 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 13 Jan 2014 18:47:29 +0000 Subject: [issue20237] Ambiguous sentence in document of xml package. In-Reply-To: <1389608026.69.0.492339232238.issue20237@psf.upfronthosting.co.za> Message-ID: <1389638849.15.0.816183410938.issue20237@psf.upfronthosting.co.za> R. David Murray added the comment: s/courses of action/kinds of actions/ in my explanation, otherwise it might be just as confusing :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 19:48:07 2014 From: report at bugs.python.org (kespindler) Date: Mon, 13 Jan 2014 18:48:07 +0000 Subject: [issue20242] logging style parameter does not work correctly In-Reply-To: <1389638510.54.0.587733308543.issue20242@psf.upfronthosting.co.za> Message-ID: <1389638887.29.0.324393072251.issue20242@psf.upfronthosting.co.za> kespindler added the comment: I created a patch that fixes this behavior for both { and $ style formats. Previously, default format strings were not being set correctly for those styles. This patch ensures that the correct default_format string is used. There is a minor "weirdness" issue that, due to there previously being 2 different default format strings for % style formatting, some tests rely on one, and some tests rely on the other. My patch remains backwards compatible with both default styles of format strings. This patch also includes test cases for behavior with the style keyword, which was not being tested before. ---------- keywords: +patch Added file: http://bugs.python.org/file33446/Issue20242.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 19:57:46 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 13 Jan 2014 18:57:46 +0000 Subject: [issue20236] Invalid inline markup in xml document. In-Reply-To: <1389597404.75.0.92024373365.issue20236@psf.upfronthosting.co.za> Message-ID: <3f33vt0Z4RzQPC@mail.python.org> Roundup Robot added the comment: New changeset fb1dd44d1f76 by R David Murray in branch '3.3': #20236: Fix sphinx markup. http://hg.python.org/cpython/rev/fb1dd44d1f76 New changeset 60163fc72017 by R David Murray in branch 'default': Merge #20236: Fix sphinx markup. http://hg.python.org/cpython/rev/60163fc72017 New changeset 3481c6f36e55 by R David Murray in branch '2.7': #20236: Fix sphinx markup. http://hg.python.org/cpython/rev/3481c6f36e55 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 20:00:46 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 13 Jan 2014 19:00:46 +0000 Subject: [issue20236] Invalid inline markup in xml document. In-Reply-To: <1389597404.75.0.92024373365.issue20236@psf.upfronthosting.co.za> Message-ID: <1389639646.91.0.00390162099259.issue20236@psf.upfronthosting.co.za> R. David Murray added the comment: Fixed, thanks. ---------- nosy: +r.david.murray resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 20:07:44 2014 From: report at bugs.python.org (Tabrez Mohammed) Date: Mon, 13 Jan 2014 19:07:44 +0000 Subject: [issue20221] #define hypot _hypot conflicts with existing definition In-Reply-To: <1389409768.81.0.962130999427.issue20221@psf.upfronthosting.co.za> Message-ID: <1389640064.22.0.429800520792.issue20221@psf.upfronthosting.co.za> Changes by Tabrez Mohammed : ---------- keywords: +patch Added file: http://bugs.python.org/file33447/fix20221.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 20:09:45 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 13 Jan 2014 19:09:45 +0000 Subject: [issue20242] logging style parameter does not work correctly In-Reply-To: <1389638510.54.0.587733308543.issue20242@psf.upfronthosting.co.za> Message-ID: <1389640185.72.0.395125888568.issue20242@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 20:35:00 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 13 Jan 2014 19:35:00 +0000 Subject: [issue20229] platform.py uses deprecated feature of plistlib In-Reply-To: <1389571430.72.0.704873561263.issue20229@psf.upfronthosting.co.za> Message-ID: <3f34kq21lKz7Ll3@mail.python.org> Roundup Robot added the comment: New changeset cd728dc893c9 by Ned Deily in branch 'default': Issue #20229: Avoid plistlib deprecation warning in platform.mac_ver(). http://hg.python.org/cpython/rev/cd728dc893c9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 20:36:20 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 13 Jan 2014 19:36:20 +0000 Subject: [issue20229] platform.py uses deprecated feature of plistlib In-Reply-To: <1389571430.72.0.704873561263.issue20229@psf.upfronthosting.co.za> Message-ID: <1389641780.6.0.490469077054.issue20229@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 20:37:01 2014 From: report at bugs.python.org (kespindler) Date: Mon, 13 Jan 2014 19:37:01 +0000 Subject: [issue14031] logging module cannot format str.format log messages In-Reply-To: <1329405649.45.0.0231002086589.issue14031@psf.upfronthosting.co.za> Message-ID: <1389641821.23.0.948690837882.issue14031@psf.upfronthosting.co.za> kespindler added the comment: I came across this issue while fixing issue20242. This issue (14031) still exists and is a major source of annoyance and confusion, and I suggest re-opening it. Specifying the "{" style, while still being forced to use % formatting in log statements is backward and incredibly confusing for a number of key reasons: - The `style` keyword accomplishes a single thing only, and that is changing the format specification of the output, which is specified once and never touched again. For the myriad log statements littered throughout a codebase, it has *absolutely* no effect. - This is incredibly misleading to users. Why would there be this parameter to basicConfig that does (next to) nothing? Furthermore, if I've specified the { style, **why** would I write my log statements using the % style. - It forces the user to keep using % style formatting. The documentation explicitly states that this is "old style" formatting, and "new style" should be used, (due to its many advantages). Why force the user to know two formatting styles? I created a patch (with test cases) that allows for this functionality. The whole idea of this feature is giving users the choice, if their environment allows it, to use the new-style formatting. Users should not have to rely on the hack linked in the blog in order to achieve *exected* behavior! ---------- keywords: +patch nosy: +kespindler Added file: http://bugs.python.org/file33448/issue14031.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 20:48:13 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 13 Jan 2014 19:48:13 +0000 Subject: [issue14031] logging module cannot format str.format log messages In-Reply-To: <1329405649.45.0.0231002086589.issue14031@psf.upfronthosting.co.za> Message-ID: <1389642493.14.0.286036145924.issue14031@psf.upfronthosting.co.za> R. David Murray added the comment: The reason is simple: in the general case you do not control all of the statements that produce log messages. Some of them come from 3rd party library code. Perhaps the documentation needs to be clarified on this point, and document the technique mentioned in the blog post Vinay linked to? Or perhaps some pre-built wrappers can be provided in 3.5? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 20:59:44 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 13 Jan 2014 19:59:44 +0000 Subject: [issue20243] ReadError when open a tarfile for writing Message-ID: <1389643184.53.0.894735644102.issue20243@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: ReadError can be raised when open a tarfile in write mode (e.g. 'w:gz'). Here is a patch wish a test. In additional it rewrites the handling errors in gzopen() which is too complicated now. This complication is possible the cause of bugs #11513 and #20238. ---------- assignee: serhiy.storchaka components: Library (Lib) files: tarfile_readerror_write_mode.patch keywords: patch messages: 208044 nosy: georg.brandl, lars.gustaebel, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: ReadError when open a tarfile for writing type: behavior versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33449/tarfile_readerror_write_mode.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 21:01:41 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 13 Jan 2014 20:01:41 +0000 Subject: [issue20243] ReadError when open a tarfile for writing In-Reply-To: <1389643184.53.0.894735644102.issue20243@psf.upfronthosting.co.za> Message-ID: <1389643301.23.0.891557967009.issue20243@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Incomplete gzip output with tarfile.open(fileobj=..., mode="w:gz") _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 21:03:43 2014 From: report at bugs.python.org (kespindler) Date: Mon, 13 Jan 2014 20:03:43 +0000 Subject: [issue14031] logging module cannot format str.format log messages In-Reply-To: <1389642493.14.0.286036145924.issue14031@psf.upfronthosting.co.za> Message-ID: kespindler added the comment: I definitely do recognize that important case. I think the proper solution, however, to that is make a very clear warning in the documentation that changing the style might affect the logging of 3rd party tools. Those users would probably have to use the % style formatting, which continues to work exactly as always. I'd also note, this issue is largely related to the `basicConfig` command. Anybody using significant 3rd party tools is likely using a more complicated solution. In that case, this patch gives them the flexibility to specify both LogRecords and the Formatter in whichever way they desire. The problem with leaving the behavior as is is that currently the style keyword is effectively useless and grossly misleading to users. Furthermore, the documentation makes reference to the ability to use new style formats. From Logging HOWTO: > As you can see, merging of variable data into the event description message uses the old, %-style of string formatting. This is for backwards compatibility: the logging package pre-dates newer formatting options such as str.format() and string.Template. **These newer formatting options are supported, but exploring them is outside the scope of this tutorial.** This interpretation is the most logical interpretation of the style keyword. Again, the format string is used once and is of comparative little consequence - there's no real need for changing its format. Log messages are written many, many times, and so it makes sense to allow the user to write them in the modern format. If the behavior really cannot be changed, this patch does provide subclasses to LogRecord that give the desired behavior. Technically these can be used independently of the style keyword. On Mon, Jan 13, 2014 at 11:48 AM, R. David Murray wrote: > > R. David Murray added the comment: > > The reason is simple: in the general case you do not control all of the > statements that produce log messages. Some of them come from 3rd party > library code. > > Perhaps the documentation needs to be clarified on this point, and > document the technique mentioned in the blog post Vinay linked to? Or > perhaps some pre-built wrappers can be provided in 3.5? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 21:26:34 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 13 Jan 2014 20:26:34 +0000 Subject: [issue20244] Possible resources leak in tarfile.open() Message-ID: <1389644794.57.0.468405626854.issue20244@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: There are possible opened file leaks when unexpected error is occurred in tarfile.open for bzip2- or xz-compressed files (and gzip2-compressed in 2.7). Here is a patch. Unfortunately I have no tests. ---------- assignee: serhiy.storchaka components: Library (Lib) files: tarfile_file_leak.patch keywords: patch messages: 208046 nosy: lars.gustaebel, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Possible resources leak in tarfile.open() type: behavior versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33450/tarfile_file_leak.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 21:27:08 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 13 Jan 2014 20:27:08 +0000 Subject: [issue20244] Possible resources leak in tarfile.open() In-Reply-To: <1389644794.57.0.468405626854.issue20244@psf.upfronthosting.co.za> Message-ID: <1389644828.85.0.969557685656.issue20244@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +ReadError when open a tarfile for writing _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 22:18:50 2014 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 13 Jan 2014 21:18:50 +0000 Subject: [issue14031] logging module cannot format str.format log messages In-Reply-To: <1329405649.45.0.0231002086589.issue14031@psf.upfronthosting.co.za> Message-ID: <1389647930.3.0.058544066547.issue14031@psf.upfronthosting.co.za> Vinay Sajip added the comment: > The problem with leaving the behavior as is is that currently the > style keyword is effectively useless and grossly misleading to users. If you are referring to the style keyword in basicConfig, it merely sets the style of the Formatter used. That can certainly be made more explicit in the documentation. There is a danger in assuming that you can associate a style with a LogRecord via a Logger, because there may be cases where a named logger is used by many different libraries (e.g. 'django.request' might be used by a number of Django middleware libraries). It may not be very common practice, but there is nothing preventing it. The approach suggested also conflates the functionality of Formatters and Loggers, which could also be confusing. > Users should not have to rely on the hack linked in the blog I don't see what makes it a hack. Logging has allowed the usage of arbitrary objects (rather than just strings) for messages, from day one, by design, for this type of eventuality (amongst others). > **These newer formatting options are supported, but exploring them > is outside the scope of this tutorial.** I will change this slightly by adding a cookbook recipe (based on the technique outlined in my blog post) and updating the above text to link to the cookbook recipe. I can also provide links from other parts of the documentation, where formatting is discussed, to point to the cookbook entry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 22:20:30 2014 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 13 Jan 2014 21:20:30 +0000 Subject: [issue20242] logging style parameter does not work correctly In-Reply-To: <1389638510.54.0.587733308543.issue20242@psf.upfronthosting.co.za> Message-ID: <1389648030.76.0.529779905812.issue20242@psf.upfronthosting.co.za> Vinay Sajip added the comment: Thanks for this. The patch looks good, and I expect to implement it shortly. ---------- assignee: -> vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 22:54:55 2014 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 13 Jan 2014 21:54:55 +0000 Subject: [issue20242] logging style parameter does not work correctly In-Reply-To: <1389638510.54.0.587733308543.issue20242@psf.upfronthosting.co.za> Message-ID: <1389650095.87.0.0817896189664.issue20242@psf.upfronthosting.co.za> Vinay Sajip added the comment: On further reflection, I will implement this slightly differently. The tests I will commit as is, except for stripping newlines before the comparison (to avoid worrying about differences in line separators across different platforms). However, the correct fix IMO is to add the default format strings to the _STYLES dict values: the effect should be the same. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 23:01:29 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 13 Jan 2014 22:01:29 +0000 Subject: [issue20242] logging style parameter does not work correctly In-Reply-To: <1389638510.54.0.587733308543.issue20242@psf.upfronthosting.co.za> Message-ID: <3f37zr5BFGz7LjY@mail.python.org> Roundup Robot added the comment: New changeset e7fcf0d8008f by Vinay Sajip in branch '3.3': Issue #20242: Fixed basicConfig() format strings for the alternative formatting styles. http://hg.python.org/cpython/rev/e7fcf0d8008f New changeset c1605d24fb35 by Vinay Sajip in branch 'default': Closes #20242: Merged fix from 3.3. http://hg.python.org/cpython/rev/c1605d24fb35 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 23:02:34 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 13 Jan 2014 22:02:34 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389650554.92.0.64674664256.issue20189@psf.upfronthosting.co.za> Larry Hastings added the comment: Okay, life has gotten even more complicated. In another issue (#20172) Zachary Ware pointed out that Argument Clinic needs to generate "self" parameters in the text string. But this complicates life for inspect.Signature, which needs to not publish the "self" parameter when it's been bound. I'm busy hacking up clinic.py to fix this right now and hope to have a patch later today. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 23:02:55 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 13 Jan 2014 22:02:55 +0000 Subject: [issue20214] Argument Clinic rollup fixes In-Reply-To: <1389317138.57.0.101674386167.issue20214@psf.upfronthosting.co.za> Message-ID: <1389650575.88.0.446581763052.issue20214@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 23:03:28 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 13 Jan 2014 22:03:28 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1389650608.92.0.554869582661.issue20172@psf.upfronthosting.co.za> Larry Hastings added the comment: > Clinic should be adding 'self' to the signature, > which should then be picked up by the __text_signature__ > parser, and used by inspect and pydoc. This innocent little comment has derailed my whole day. You're right, 'self' should be in the signature. But not always! And then in inspect.Signature we need to strip it off for bound methods. In case you're curious, this work is happening in a separate branch, and tracked in a different issue (#20189). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 23:06:27 2014 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 13 Jan 2014 22:06:27 +0000 Subject: [issue20136] Logging: StreamHandler does not use OS line separator. In-Reply-To: <1388998969.13.0.29066681056.issue20136@psf.upfronthosting.co.za> Message-ID: <1389650787.82.0.00328734389073.issue20136@psf.upfronthosting.co.za> Vinay Sajip added the comment: Can you please attach a short test script which shows what you consider to be the failure case / incorrect behaviour? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 23:08:20 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 13 Jan 2014 22:08:20 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389650900.28.0.643270610621.issue20189@psf.upfronthosting.co.za> Yury Selivanov added the comment: > But this complicates life for inspect.Signature, which needs to not publish the "self" parameter when it's been bound. That's already supported, isn't it? >>> str(inspect.signature(F.a)) '(self, a)' >>> str(inspect.signature(F().a)) '(a)' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 23:08:47 2014 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 13 Jan 2014 22:08:47 +0000 Subject: [issue20137] Logging: RotatingFileHandler computes string length instead of byte representation length. In-Reply-To: <1388999971.66.0.938288838593.issue20137@psf.upfronthosting.co.za> Message-ID: <1389650927.14.0.82924793734.issue20137@psf.upfronthosting.co.za> Vinay Sajip added the comment: Which encoding are you using, such that the difference in length between encoded and decoded messages is significant? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 23:17:48 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 13 Jan 2014 22:17:48 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389651468.72.0.777759957964.issue20189@psf.upfronthosting.co.za> Larry Hastings added the comment: Not for builtins. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 23:18:44 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 13 Jan 2014 22:18:44 +0000 Subject: [issue20245] Check empty mode in TarFile.*open() Message-ID: <1389651524.31.0.708867421732.issue20245@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: TarFile's *open() class methods checks the mode argument to raise helpful error: >>> t = tarfile.TarFile.taropen('xxx.tar', 'q') Traceback (most recent call last): File "", line 1, in File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1589, in taropen raise ValueError("mode must be 'r', 'a' or 'w'") ValueError: mode must be 'r', 'a' or 'w' But often this check doesn't catch empty mode. >>> t = tarfile.TarFile.taropen('xxx.tar', '') Traceback (most recent call last): File "", line 1, in File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1590, in taropen return cls(name, mode, fileobj, **kwargs) File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1411, in __init__ self._mode = {"r": "rb", "a": "r+b", "w": "wb"}[mode] KeyError: '' >>> t = tarfile.TarFile.gzopen('xxx.tar', '') Traceback (most recent call last): File "", line 1, in File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1608, in gzopen fileobj = gzip.GzipFile(name, mode + "b", compresslevel, fileobj) File "/home/serhiy/py/cpython/Lib/gzip.py", line 181, in __init__ fileobj = self.myfileobj = builtins.open(filename, mode or 'rb') ValueError: Must have exactly one of create/read/write/append mode and at most one plus >>> t = tarfile.TarFile.bz2open('xxx.tar', '') Traceback (most recent call last): File "", line 1, in File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1640, in bz2open t = cls.taropen(name, mode, fileobj, **kwargs) File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1590, in taropen return cls(name, mode, fileobj, **kwargs) File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1411, in __init__ self._mode = {"r": "rb", "a": "r+b", "w": "wb"}[mode] KeyError: '' Only xzopen() works correctly. >>> t = tarfile.TarFile.xzopen('xxx.tar', '') Traceback (most recent call last): File "", line 1, in File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1653, in xzopen raise ValueError("mode must be 'r' or 'w'") ValueError: mode must be 'r' or 'w' Here is a patch which fixes the mode argument checking. ---------- assignee: serhiy.storchaka components: Library (Lib) files: tarfile_empty_mode.patch keywords: patch messages: 208057 nosy: lars.gustaebel, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Check empty mode in TarFile.*open() type: behavior versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33451/tarfile_empty_mode.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 13 23:28:47 2014 From: report at bugs.python.org (Stefan Krah) Date: Mon, 13 Jan 2014 22:28:47 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389651468.72.0.777759957964.issue20189@psf.upfronthosting.co.za> Message-ID: <20140113222846.GA12670@sleipnir.bytereef.org> Stefan Krah added the comment: Another issue is that with the patch applied help() is broken for certain forms of docstrings: from decimal import * >>> print(setcontext.__doc__) setcontext(c) - Set a new default context. >>> help(setcontext) Traceback (most recent call last): File "", line 1, in File "/home/stefan/hg/cpython/Lib/_sitebuiltins.py", line 99, in __call__ return pydoc.help(*args, **kwds) File "/home/stefan/hg/cpython/Lib/pydoc.py", line 1792, in __call__ self.help(request) File "/home/stefan/hg/cpython/Lib/pydoc.py", line 1842, in help else: doc(request, 'Help on %s:', output=self._output) File "/home/stefan/hg/cpython/Lib/pydoc.py", line 1578, in doc pager(render_doc(thing, title, forceload)) File "/home/stefan/hg/cpython/Lib/pydoc.py", line 1571, in render_doc return title % desc + '\n\n' + renderer.document(object, name) File "/home/stefan/hg/cpython/Lib/pydoc.py", line 358, in document if inspect.isroutine(object): return self.docroutine(*args) File "/home/stefan/hg/cpython/Lib/pydoc.py", line 1323, in docroutine signature = inspect.signature(object) File "/home/stefan/hg/cpython/Lib/inspect.py", line 1551, in signature raise ValueError(msg) ValueError: no signature found for builtin function Perhaps this form of docstrings is discouraged (I used it because it looks nice in pydoc), but nevertheless it might be present in third party modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 00:47:32 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 13 Jan 2014 23:47:32 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389656852.26.0.113142790828.issue20189@psf.upfronthosting.co.za> Larry Hastings added the comment: Here's an updated patch. I tried to "do it right" which wound up being a huge amount of work in Clinic. The actual change to inspect.Signature was really easy, once I understood everything. The churn in the .c files is because Clinic now uses the self converter's type for the parsing function, and (obviously) because it's now generating "self" in the signatures as appropriate. Fun trivia: the "self" parameter to a builtin is always a positional-only parameter, even if all other argument processing for the function is PyArg_ParseTupleAndKeywords. I think this patch marks the first time inspect.Signature will ever mark a parameter as positional-only! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 00:55:48 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 13 Jan 2014 23:55:48 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389657348.22.0.58873629004.issue20189@psf.upfronthosting.co.za> Larry Hastings added the comment: > Another issue is that with the patch applied help() is broken for > certain forms of docstrings: Yeah. We discussed this briefly in #19674. I wanted to use a marker that wasn't The Convention That People Have Used For Decades but I felt overruled. I want to revisit it for precisely the reason you cite. (I just realized, Sphinx autodoc is irrelevant, as if the string is legitimate it be stripped off the docstring anyway.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 01:12:39 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Tue, 14 Jan 2014 00:12:39 +0000 Subject: [issue20202] ArgumentClinic howto: document change in Py_buffer lifecycle management In-Reply-To: <1389250062.45.0.978565094508.issue20202@psf.upfronthosting.co.za> Message-ID: <1389658359.97.0.787644251974.issue20202@psf.upfronthosting.co.za> Ryan Smith-Roberts added the comment: Even more imperative than my version. Excellent! ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 01:19:03 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Tue, 14 Jan 2014 00:19:03 +0000 Subject: [issue20227] Argument Clinic: rename arguments in generated C? In-Reply-To: <1389524736.75.0.620647933805.issue20227@psf.upfronthosting.co.za> Message-ID: <1389658743.4.0.755100266624.issue20227@psf.upfronthosting.co.za> Changes by Ryan Smith-Roberts : ---------- nosy: +rmsr _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 01:43:59 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Tue, 14 Jan 2014 00:43:59 +0000 Subject: [issue20246] buffer overflow in socket.recvfrom_into Message-ID: <1389660239.25.0.341393063834.issue20246@psf.upfronthosting.co.za> New submission from Ryan Smith-Roberts: recvfrom_into fails to check that the supplied buffer object is big enough for the requested read and so will happily write off the end. I will attach patches for 3.4 and 2.7, I'm not familiar with the backporting procedure to go further but all versions since 2.5 have this bug and while very highly unlikely it's technically remotely exploitable. Quickie trigger script, crash on interpreter exit: --------- BEGIN SEGFAULT --------- import socket r, w = socket.socketpair() w.send(b'X' * 1024) r.recvfrom_into(bytearray(), 1024) ---------- components: Extension Modules messages: 208062 nosy: rmsr priority: normal severity: normal status: open title: buffer overflow in socket.recvfrom_into type: crash versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 01:44:23 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Tue, 14 Jan 2014 00:44:23 +0000 Subject: [issue20246] buffer overflow in socket.recvfrom_into In-Reply-To: <1389660239.25.0.341393063834.issue20246@psf.upfronthosting.co.za> Message-ID: <1389660263.98.0.164575753948.issue20246@psf.upfronthosting.co.za> Changes by Ryan Smith-Roberts : ---------- keywords: +patch Added file: http://bugs.python.org/file33452/recvfrom_into_buffer_overflow_3.4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 01:44:34 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Tue, 14 Jan 2014 00:44:34 +0000 Subject: [issue20246] buffer overflow in socket.recvfrom_into In-Reply-To: <1389660239.25.0.341393063834.issue20246@psf.upfronthosting.co.za> Message-ID: <1389660274.17.0.6432825687.issue20246@psf.upfronthosting.co.za> Changes by Ryan Smith-Roberts : Added file: http://bugs.python.org/file33453/recvfrom_into_buffer_overflow_2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 01:55:21 2014 From: report at bugs.python.org (Antony Lee) Date: Tue, 14 Jan 2014 00:55:21 +0000 Subject: [issue20247] Condition._is_owned is wrong Message-ID: <1389660921.49.0.651163897864.issue20247@psf.upfronthosting.co.za> New submission from Antony Lee: I believe that the implementation of Condition._is_owned is wrong, as mentioned here: https://mail.python.org/pipermail/python-list/2012-October/632682.html. Specifically, the two return values (True and False) should be inverted. I guess this slipped through as this private function would only be called if one passed to a Condition object a (R)Lock-like object that doesn't define _is_owned. (I noticed this when I tried to pass a custom-written reader-writer lock to a Condition object.) Technically, the docs says that "If the lock argument is given and not None, it must be a Lock or RLock object", but in practice anything that defines acquire(), release() (and possibly _is_owned()) should work. ---------- components: Library (Lib) messages: 208063 nosy: Antony.Lee priority: normal severity: normal status: open title: Condition._is_owned is wrong _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 02:51:39 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 14 Jan 2014 01:51:39 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1389664299.08.0.429289152818.issue20172@psf.upfronthosting.co.za> Larry Hastings added the comment: Filed comments on everything. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 03:22:42 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Tue, 14 Jan 2014 02:22:42 +0000 Subject: [issue20227] Argument Clinic: rename arguments in generated C? In-Reply-To: <1389524736.75.0.620647933805.issue20227@psf.upfronthosting.co.za> Message-ID: <1389666162.43.0.104243332546.issue20227@psf.upfronthosting.co.za> Ryan Smith-Roberts added the comment: Georg Brandl wrote: > Although now is a good time to ensure sensible argument names (I > usually look at the docs to find the documented ones), so that > switching the function to keyword arg support is basically just a > removal of '/' I started doing this almost without thinking while converting the socket module. I think matching argument names against the online docs is an important part of AC conversion that has gone unaddressed. I am working on an email to python-dev about making it explicit policy. A way to avoid code churn that just occurred to me is to retain existing variable declarations (for users of PyArgs_ParseTuple) and initialize them using the new function arguments. For the self argument and METH_O users one can introduce a new declaration similarly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 03:35:35 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 14 Jan 2014 02:35:35 +0000 Subject: [issue20246] buffer overflow in socket.recvfrom_into In-Reply-To: <1389660239.25.0.341393063834.issue20246@psf.upfronthosting.co.za> Message-ID: <1389666935.15.0.359385378632.issue20246@psf.upfronthosting.co.za> R. David Murray added the comment: Everything before 2.7 is already out of even security maintenance, so you've already checked off everything it will get fixed in. ---------- nosy: +r.david.murray type: crash -> security _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 04:14:05 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Tue, 14 Jan 2014 03:14:05 +0000 Subject: [issue20248] docs: socket.recvmsg{,_into} are keword-compatible Message-ID: <1389669245.17.0.020040143215.issue20248@psf.upfronthosting.co.za> New submission from Ryan Smith-Roberts: The docs indicate their arguments are positional-only. Trivial patch attached. ---------- assignee: docs at python components: Documentation files: docs_socket_recvmsg_args.patch keywords: patch messages: 208067 nosy: docs at python, rmsr priority: normal severity: normal status: open title: docs: socket.recvmsg{,_into} are keword-compatible type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file33454/docs_socket_recvmsg_args.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 04:16:45 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Tue, 14 Jan 2014 03:16:45 +0000 Subject: [issue20248] docs: socket.recvmsg{,_into} are keword-compatible In-Reply-To: <1389669245.17.0.020040143215.issue20248@psf.upfronthosting.co.za> Message-ID: <1389669405.98.0.219451564681.issue20248@psf.upfronthosting.co.za> Ryan Smith-Roberts added the comment: Never mind, it's actually recvfrom{,_into}. Sigh. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 04:45:11 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 14 Jan 2014 03:45:11 +0000 Subject: [issue20248] docs: socket.recvmsg{,_into} are keword-compatible In-Reply-To: <1389669245.17.0.020040143215.issue20248@psf.upfronthosting.co.za> Message-ID: <1389671111.1.0.893758539555.issue20248@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> invalid _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 05:07:37 2014 From: report at bugs.python.org (Chris Angelico) Date: Tue, 14 Jan 2014 04:07:37 +0000 Subject: [issue20249] test_posix.test_initgroups fails when running with no supplementary groups Message-ID: <1389672457.74.0.34815423536.issue20249@psf.upfronthosting.co.za> New submission from Chris Angelico: When tests are run from an Upstart job in a minimal environment, test_posix.test_initgroups fails as it attempts to find the max() of an empty list of supplementary groups. Problem sighted with 2.7, 3.3, and 3.x branches. Patch derived from 3.x (default branch), applies cleanly to 2.7 and 3.3 as well. ---------- components: Tests files: test_posix.patch keywords: patch messages: 208069 nosy: Rosuav priority: normal severity: normal status: open title: test_posix.test_initgroups fails when running with no supplementary groups versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33455/test_posix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 05:15:07 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jan 2014 04:15:07 +0000 Subject: [issue20246] buffer overflow in socket.recvfrom_into In-Reply-To: <1389660239.25.0.341393063834.issue20246@psf.upfronthosting.co.za> Message-ID: <3f3JGy3RKkz7LkL@mail.python.org> Roundup Robot added the comment: New changeset 87673659d8f7 by Benjamin Peterson in branch '2.7': complain when nbytes > buflen to fix possible buffer overflow (closes #20246) http://hg.python.org/cpython/rev/87673659d8f7 New changeset 715fd3d8ac93 by Benjamin Peterson in branch '3.1': complain when nbytes > buflen to fix possible buffer overflow (closes #20246) http://hg.python.org/cpython/rev/715fd3d8ac93 New changeset 9c56217e5c79 by Benjamin Peterson in branch '3.2': complain when nbytes > buflen to fix possible buffer overflow (closes #20246) http://hg.python.org/cpython/rev/9c56217e5c79 New changeset 7f176a45211f by Benjamin Peterson in branch '3.3': merge 3.2 (#20246) http://hg.python.org/cpython/rev/7f176a45211f New changeset ead74e54d68f by Benjamin Peterson in branch 'default': merge 3.3 (#20246) http://hg.python.org/cpython/rev/ead74e54d68f New changeset 37ed85008f51 by Benjamin Peterson in branch 'default': merge 3.3 (#20246) http://hg.python.org/cpython/rev/37ed85008f51 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 05:27:43 2014 From: report at bugs.python.org (Andrew Barnert) Date: Tue, 14 Jan 2014 04:27:43 +0000 Subject: [issue20250] defaultdict docstring neglects the *args Message-ID: <1389673663.73.0.267088084088.issue20250@psf.upfronthosting.co.za> New submission from Andrew Barnert: The docstring for defaultdict shows only a single argument, default_factory, and gives no clue that you can pass additional arguments: | defaultdict(default_factory) --> dict with default factory | | The default factory is called without arguments to produce | a new value when a key is not present, in __getitem__ only. | A defaultdict compares equal to a dict with the same items. The docs, by contrast, say: > class collections.defaultdict([default_factory[, ...]]) > ? The first argument provides the initial value for the default_factory attribute; it defaults to None. All remaining arguments are treated the same as if they were passed to the dict constructor, including keyword arguments. I think the docstring should have the same information?or at least have the correct signature, which would hopefully be enough to prompt people to look at the docs. I'm not sure whether the correct signature is (default_factory, *args, **kwargs), like OrderedDict, or (default_factory[, ...]), like deque, but I don't think either one would confuse anyone. ---------- components: Library (Lib) files: collectionsmodule.diff keywords: patch messages: 208071 nosy: abarnert priority: normal severity: normal status: open title: defaultdict docstring neglects the *args type: enhancement Added file: http://bugs.python.org/file33456/collectionsmodule.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 05:56:42 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jan 2014 04:56:42 +0000 Subject: [issue20250] defaultdict docstring neglects the *args In-Reply-To: <1389673663.73.0.267088084088.issue20250@psf.upfronthosting.co.za> Message-ID: <3f3KBy0NfCz7Lk8@mail.python.org> Roundup Robot added the comment: New changeset d46bf7835b45 by Benjamin Peterson in branch '3.3': correct defaultdict signature in docstring (closes #20250) http://hg.python.org/cpython/rev/d46bf7835b45 New changeset 950f1e83bb56 by Benjamin Peterson in branch '2.7': correct defaultdict signature in docstring (closes #20250) http://hg.python.org/cpython/rev/950f1e83bb56 New changeset 49ae53150ee0 by Benjamin Peterson in branch 'default': merge 3.3 (#20250) http://hg.python.org/cpython/rev/49ae53150ee0 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 06:18:58 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Tue, 14 Jan 2014 05:18:58 +0000 Subject: [issue20251] socket.recvfrom_into crash with empty buffer Message-ID: <1389676738.57.0.767136106555.issue20251@psf.upfronthosting.co.za> New submission from Vajrasky Kok: >>> import socket >>> r, w = socket.socketpair() >>> w.send(b'X' * 1024) 1024 >>> buffer = bytearray() >>> r.recvfrom_into(buffer) python: /home/sky/Code/python/cpython3.4/Modules/socketmodule.c:2867: sock_recvfrom_into: Assertion `buf != 0 && buflen > 0' failed. Aborted (core dumped) Attached the fix to handle the empty bytearray gracefully. The fix is for Python 3.4. ---------- components: Extension Modules files: recv_from_into_empty_byte_array.patch keywords: patch messages: 208073 nosy: benjamin.peterson, vajrasky priority: normal severity: normal status: open title: socket.recvfrom_into crash with empty buffer type: crash versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33457/recv_from_into_empty_byte_array.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 06:22:58 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jan 2014 05:22:58 +0000 Subject: [issue20251] socket.recvfrom_into crash with empty buffer In-Reply-To: <1389676738.57.0.767136106555.issue20251@psf.upfronthosting.co.za> Message-ID: <3f3KnF3S0Bz7Lk8@mail.python.org> Roundup Robot added the comment: New changeset 8712efe02dcc by Benjamin Peterson in branch '3.3': remove overly strict assertion (closes #20251) http://hg.python.org/cpython/rev/8712efe02dcc New changeset ab9556830560 by Benjamin Peterson in branch 'default': merge 3.3 (#20251) http://hg.python.org/cpython/rev/ab9556830560 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 06:29:13 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jan 2014 05:29:13 +0000 Subject: [issue20251] socket.recvfrom_into crash with empty buffer In-Reply-To: <1389676738.57.0.767136106555.issue20251@psf.upfronthosting.co.za> Message-ID: <3f3KwS4SFQz7Lln@mail.python.org> Roundup Robot added the comment: New changeset 3881211cbb19 by Benjamin Peterson in branch '2.7': remove overly strict assertion (closes #20251) http://hg.python.org/cpython/rev/3881211cbb19 New changeset 1885e1768ff9 by Benjamin Peterson in branch '2.7': add test for #20251 http://hg.python.org/cpython/rev/1885e1768ff9 New changeset 6ea64dcfb5e2 by Benjamin Peterson in branch '3.3': add test for #20251 http://hg.python.org/cpython/rev/6ea64dcfb5e2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 06:45:29 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Tue, 14 Jan 2014 05:45:29 +0000 Subject: [issue20252] Argument Clinic howto: small typo in y# translation Message-ID: <1389678329.15.0.528814981218.issue20252@psf.upfronthosting.co.za> New submission from Ryan Smith-Roberts: type -> types ---------- assignee: docs at python components: Documentation files: argument_clinic_howto_y-hash.patch keywords: patch messages: 208076 nosy: docs at python, larry, rmsr priority: normal severity: normal status: open title: Argument Clinic howto: small typo in y# translation type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file33458/argument_clinic_howto_y-hash.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 06:59:52 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 14 Jan 2014 05:59:52 +0000 Subject: [issue20252] Argument Clinic howto: small typo in y# translation In-Reply-To: <1389678329.15.0.528814981218.issue20252@psf.upfronthosting.co.za> Message-ID: <1389679192.11.0.34195521538.issue20252@psf.upfronthosting.co.za> Larry Hastings added the comment: Same bug for 'y' too. Will fix in a patch probably Tuesday. Thanks for pointing it out! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 07:29:21 2014 From: report at bugs.python.org (INADA Naoki) Date: Tue, 14 Jan 2014 06:29:21 +0000 Subject: [issue20253] Typo in ipaddress document Message-ID: <1389680961.29.0.254286053987.issue20253@psf.upfronthosting.co.za> New submission from INADA Naoki: > http://docs.python.org/3.3/library/ipaddress.html#ipaddress.IPv4Network.broadcast_address Wrong attribute name: s/host mask/hostmask/ ---------- assignee: docs at python components: Documentation messages: 208078 nosy: docs at python, naoki priority: normal severity: normal status: open title: Typo in ipaddress document versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 07:31:26 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 14 Jan 2014 06:31:26 +0000 Subject: [issue20253] Typo in ipaddress document In-Reply-To: <1389680961.29.0.254286053987.issue20253@psf.upfronthosting.co.za> Message-ID: <1389681086.66.0.726461572155.issue20253@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 08:30:47 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Tue, 14 Jan 2014 07:30:47 +0000 Subject: [issue20254] Duplicate bytearray test on test_socket.py Message-ID: <1389684647.88.0.881886101386.issue20254@psf.upfronthosting.co.za> New submission from Vajrasky Kok: testRecvIntoArray is same as testRecvIntoBytearray. testRecvFromIntoArray is same as testRecvFromIntoBytearray. Attached the patch to fix the tests. ---------- components: Tests files: fix_recv_from_into_array_test_socket.patch keywords: patch messages: 208079 nosy: vajrasky priority: normal severity: normal status: open title: Duplicate bytearray test on test_socket.py type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33459/fix_recv_from_into_array_test_socket.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 08:32:32 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 14 Jan 2014 07:32:32 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1389684752.73.0.619849094928.issue20172@psf.upfronthosting.co.za> Zachary Ware added the comment: Sandbox repo updated. It is currently using an older version of clinic; running current clinic on the winreg.c in the tip of the sandbox produces this traceback: Traceback (most recent call last): File "Tools\clinic\clinic.py", line 2981, in sys.exit(main(sys.argv[1:])) File "Tools\clinic\clinic.py", line 2977, in main parse_file(filename, output=ns.output, verify=not ns.force) File "Tools\clinic\clinic.py", line 1132, in parse_file cooked = clinic.parse(raw) File "Tools\clinic\clinic.py", line 1082, in parse parser.parse(block) File "Tools\clinic\clinic.py", line 2259, in parse self.state(line) File "Tools\clinic\clinic.py", line 2633, in state_parameter_docstring return self.next(self.state_parameter, line) File "Tools\clinic\clinic.py", line 2287, in next self.state(line) File "Tools\clinic\clinic.py", line 2531, in state_parameter value = eval(py_default) File "", line 1, in NameError: name 'winreg' is not defined I'm not terribly sure about the error handling with the return converters, that will need some extra scrutiny. I may have it completely wrong :). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 08:59:47 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 14 Jan 2014 07:59:47 +0000 Subject: [issue20255] Doc/about: update a bit Message-ID: <1389686387.52.0.386182355157.issue20255@psf.upfronthosting.co.za> New submission from Georg Brandl: What do you think about this patch? ---------- assignee: zach.ware components: Documentation files: about.diff keywords: patch messages: 208081 nosy: georg.brandl, zach.ware priority: normal severity: normal status: open title: Doc/about: update a bit Added file: http://bugs.python.org/file33460/about.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 09:05:16 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 14 Jan 2014 08:05:16 +0000 Subject: [issue20241] Bad reference to RFC in document of ipaddress? In-Reply-To: <1389626719.4.0.511378840941.issue20241@psf.upfronthosting.co.za> Message-ID: <1389686716.19.0.301186867571.issue20241@psf.upfronthosting.co.za> Georg Brandl added the comment: 5735 seems to be correct (see docstring of is_unspecified), although it doesn't talk about "unspecified". ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 09:35:49 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jan 2014 08:35:49 +0000 Subject: [issue20256] Argument Clinic: compare signed and unsigned ints Message-ID: <1389688549.54.0.106907827652.issue20256@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: For unsigned_int, unsigned_long and size_t return converters Argument Clinic generates a code which compares unsigned integer return_value with signed -1. ---------- components: Demos and Tools messages: 208083 nosy: larry, serhiy.storchaka priority: normal severity: normal status: open title: Argument Clinic: compare signed and unsigned ints type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 09:59:12 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jan 2014 08:59:12 +0000 Subject: [issue20133] Derby: Convert the audioop module to use Argument Clinic In-Reply-To: <1388956864.17.0.114751586443.issue20133@psf.upfronthosting.co.za> Message-ID: <1389689952.16.0.76641639964.issue20133@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Patch updated to tip (a little different generated code for Py_buffer). I don't want to use return converters here because I want to add support for float32 and float64 in 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 09:59:38 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jan 2014 08:59:38 +0000 Subject: [issue20133] Derby: Convert the audioop module to use Argument Clinic In-Reply-To: <1388956864.17.0.114751586443.issue20133@psf.upfronthosting.co.za> Message-ID: <1389689978.89.0.315610638242.issue20133@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file33461/audioop_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 10:02:25 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jan 2014 09:02:25 +0000 Subject: [issue20138] wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode In-Reply-To: <1389001619.16.0.909145148031.issue20138@psf.upfronthosting.co.za> Message-ID: <1389690145.65.0.900844504358.issue20138@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Armin for your report. ---------- components: +Library (Lib) resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 10:12:21 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jan 2014 09:12:21 +0000 Subject: [issue20115] NUL bytes in commented lines In-Reply-To: <1388771953.42.0.332804570753.issue20115@psf.upfronthosting.co.za> Message-ID: <1389690741.93.0.160438337914.issue20115@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'll try, but I'm not sure this is possible. Some used C functions (e.g. fgets()) returns char* and doesn't work with string containing null bytes. Some public API (e.g. PyParser_SimpleParseString()) work with null-terminated C strings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 10:14:36 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jan 2014 09:14:36 +0000 Subject: [issue20115] NUL bytes in commented lines In-Reply-To: <1388771953.42.0.332804570753.issue20115@psf.upfronthosting.co.za> Message-ID: <1389690876.75.0.644909514063.issue20115@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue13617. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 10:22:42 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jan 2014 09:22:42 +0000 Subject: [issue18373] implement sys.get/setbyteswarningflag() In-Reply-To: <1373065124.82.0.249288626652.issue18373@psf.upfronthosting.co.za> Message-ID: <1389691362.91.0.99423538304.issue18373@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Interpreter Core stage: -> patch review type: -> enhancement versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 10:39:22 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Tue, 14 Jan 2014 09:39:22 +0000 Subject: [issue20257] test_socket fails if using tipc module and SELinux enabled Message-ID: <1389692362.24.0.80510230142.issue20257@psf.upfronthosting.co.za> New submission from Vajrasky Kok: Enable SELinux (by default it is already enabled). Then load tipc module. # modprobe tipc Then using whatever account, execute Lib/test/test_socket.py. You'll get: FAILED (errors=1, skipped=4) Traceback (most recent call last): File "Lib/test/test_socket.py", line 1740, in test_main() File "Lib/test/test_socket.py", line 1736, in test_main test_support.run_unittest(*tests) File "/home/sky/Code/python/cpython2.7/Lib/test/test_support.py", line 1251, in run_unittest _run_suite(suite) File "/home/sky/Code/python/cpython2.7/Lib/test/test_support.py", line 1234, in _run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_socket.py", line 1705, in testStream msg = self.conn.recv(1024) error: [Errno 13] Permission denied Attached the patch to skip the test if we don't have sufficient permission to execute the test. ---------- components: Tests files: skip_test_if_selinux_tipc.patch keywords: patch messages: 208088 nosy: vajrasky priority: normal severity: normal status: open title: test_socket fails if using tipc module and SELinux enabled type: behavior versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33462/skip_test_if_selinux_tipc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 11:05:13 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 14 Jan 2014 10:05:13 +0000 Subject: [issue20258] Python documentation build fails with "markupsafe module cannot be found" Message-ID: <1389693913.29.0.73084450646.issue20258@psf.upfronthosting.co.za> New submission from Ned Deily: With the updates to the Sphinx toolchain for 3.3 (05e84d3ecd1e) and 3.4 (90cd87f64632), the documentation build for the OS X installer now fails with: Error: The markupsafe module cannot be found. Did you install Sphinx and its dependencies correctly? It appears that the updated version of jinja2 now requires MarkupSafe. Also, the updated version of jinja2 now requires at least Python 2.6. Prior to these toolchain updates it was possible to build the Python documentation (and all of Python 2.x or 3.x) with Python 2.5. Perhaps this change should be documented somewhere since it does cause some breakage. For example, the current Python 32-bit-only installers are built on OS X 10.5; up until now, the Apple-supplied system Python 2.5 could be used to bootstrap the build and build the documentation. Now we'll have to supply a newer local Python to do that. ---------- assignee: georg.brandl components: Build, Documentation messages: 208089 nosy: georg.brandl, larry, ned.deily priority: release blocker severity: normal stage: needs patch status: open title: Python documentation build fails with "markupsafe module cannot be found" versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 11:57:55 2014 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 14 Jan 2014 10:57:55 +0000 Subject: [issue20247] Condition._is_owned is wrong In-Reply-To: <1389660921.49.0.651163897864.issue20247@psf.upfronthosting.co.za> Message-ID: <1389697075.02.0.429256430783.issue20247@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +mark.dickinson, tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 11:59:00 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 14 Jan 2014 10:59:00 +0000 Subject: [issue20258] Python documentation build fails with "markupsafe module cannot be found" In-Reply-To: <1389693913.29.0.73084450646.issue20258@psf.upfronthosting.co.za> Message-ID: <1389697140.78.0.4982696347.issue20258@psf.upfronthosting.co.za> Georg Brandl added the comment: That's unfortunate, thanks for catching that. Of course I had markupsafe installed for my system Python. One more reason to switch to virtualenv at some point. I think we can go back to the old Jinja version -- there haven't been bugs to my knowledge and Sphinx doesn't require any advanced features there may be. But just as a heads up -- Sphinx 1.3 will also require Python 2.6 :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 12:27:25 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jan 2014 11:27:25 +0000 Subject: [issue20258] Python documentation build fails with "markupsafe module cannot be found" In-Reply-To: <1389693913.29.0.73084450646.issue20258@psf.upfronthosting.co.za> Message-ID: <3f3Tsm38pmzPFQ@mail.python.org> Roundup Robot added the comment: New changeset 92fe1cd256f1 by Georg Brandl in branch '3.3': Closes #20258: Sphinx toolchain: move back to Jinja2 2.3.1 with support for Py2.5. http://hg.python.org/cpython/rev/92fe1cd256f1 ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 13:56:48 2014 From: report at bugs.python.org (Laurent De Buyst) Date: Tue, 14 Jan 2014 12:56:48 +0000 Subject: [issue18622] reset_mock on mock created by mock_open causes infinite recursion In-Reply-To: <1375391057.28.0.108463427813.issue18622@psf.upfronthosting.co.za> Message-ID: <1389704208.9.0.558617591712.issue18622@psf.upfronthosting.co.za> Laurent De Buyst added the comment: Sorry Michael, I should have read your second comment more closely since you already pointed out that using a list as default argument is bad. It is, however, easily fixed by changing to this: def reset_mock(self, visited=None): "Restore the mock object to its initial state." if visited is None: visited = [] if id(self) in visited: return ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 14:21:46 2014 From: report at bugs.python.org (Nicola Palumbo) Date: Tue, 14 Jan 2014 13:21:46 +0000 Subject: [issue18622] reset_mock on mock created by mock_open causes infinite recursion In-Reply-To: <1375391057.28.0.108463427813.issue18622@psf.upfronthosting.co.za> Message-ID: <1389705706.25.0.347660130544.issue18622@psf.upfronthosting.co.za> Nicola Palumbo added the comment: I should have read more carefully, too! Thanks to both. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 14:23:05 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 14 Jan 2014 13:23:05 +0000 Subject: [issue20255] Doc/about: update a bit In-Reply-To: <1389686387.52.0.386182355157.issue20255@psf.upfronthosting.co.za> Message-ID: <1389705785.29.0.59972941294.issue20255@psf.upfronthosting.co.za> R. David Murray added the comment: It seems fine to me, if docs@ is no longer the best place to start. It might be better if the tracker link read "documentation bugs on the bug tracker". Also, you could link to the devguide as well as core-mentorship. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 14:23:25 2014 From: report at bugs.python.org (Laurent De Buyst) Date: Tue, 14 Jan 2014 13:23:25 +0000 Subject: [issue18622] reset_mock on mock created by mock_open causes infinite recursion In-Reply-To: <1375391057.28.0.108463427813.issue18622@psf.upfronthosting.co.za> Message-ID: <1389705805.84.0.339449300409.issue18622@psf.upfronthosting.co.za> Laurent De Buyst added the comment: And here's an actual patch with the corrected code ---------- Added file: http://bugs.python.org/file33463/issue18622_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 14:44:20 2014 From: report at bugs.python.org (Sebastian Rodriguez) Date: Tue, 14 Jan 2014 13:44:20 +0000 Subject: [issue17140] Provide a more obvious public ThreadPool API In-Reply-To: <1360116485.64.0.452267246232.issue17140@psf.upfronthosting.co.za> Message-ID: <1389707060.95.0.0974408270321.issue17140@psf.upfronthosting.co.za> Changes by Sebastian Rodriguez : ---------- nosy: +srodriguez _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 14:57:13 2014 From: report at bugs.python.org (Daniel Holth) Date: Tue, 14 Jan 2014 13:57:13 +0000 Subject: [issue18373] implement sys.get/setbyteswarningflag() In-Reply-To: <1373065124.82.0.249288626652.issue18373@psf.upfronthosting.co.za> Message-ID: <1389707833.06.0.239458769722.issue18373@psf.upfronthosting.co.za> Daniel Holth added the comment: Just mitigating the bug that -bb is not the default... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 16:10:58 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jan 2014 15:10:58 +0000 Subject: [issue20253] Typo in ipaddress document In-Reply-To: <1389680961.29.0.254286053987.issue20253@psf.upfronthosting.co.za> Message-ID: <3f3Zqk0N57z7LnS@mail.python.org> Roundup Robot added the comment: New changeset 4f8ad9a4193f by Zachary Ware in branch '3.3': Issue #20253: Fixed a typo in the ipaddress docs that advertised an http://hg.python.org/cpython/rev/4f8ad9a4193f New changeset 2f54b55fcbfa by Zachary Ware in branch 'default': Closes #20253: Merge typo fix http://hg.python.org/cpython/rev/2f54b55fcbfa ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 16:11:27 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 14 Jan 2014 15:11:27 +0000 Subject: [issue20253] Typo in ipaddress document In-Reply-To: <1389680961.29.0.254286053987.issue20253@psf.upfronthosting.co.za> Message-ID: <1389712287.03.0.126220797208.issue20253@psf.upfronthosting.co.za> Zachary Ware added the comment: Thanks for the report! ---------- assignee: docs at python -> zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 16:35:04 2014 From: report at bugs.python.org (Ethan Furman) Date: Tue, 14 Jan 2014 15:35:04 +0000 Subject: [issue19995] %c, %o, %x, %X accept non-integer values instead of raising an exception In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za> Message-ID: <1389713704.41.0.369511672949.issue19995@psf.upfronthosting.co.za> Ethan Furman added the comment: Depracation warning is in place for 3.4. When 3.5 is tagged I'll switch it an error. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 16:57:58 2014 From: report at bugs.python.org (Shelby Spencer) Date: Tue, 14 Jan 2014 15:57:58 +0000 Subject: [issue20259] os.walk conflicts with os.listdir Message-ID: <1389715078.64.0.968291006177.issue20259@psf.upfronthosting.co.za> New submission from Shelby Spencer: The problem occurs when you attempt to perform an os.listdir on a directory that you don't have access to. You should get an exception thrown. Normally this occurs, however, if you run the following code: folder = for currentDir, subDirs, files = os.walk(folder): temp = os.listdir(currentDir) temp will hold an empty list on the subdirectory you don't have access to and no exception is thrown. This appears to be some sort of conflict between os.walk and os.listdir. Near as I can tell python is caching the subdirectory listing for subDirs (os.walk doesn't throw an error on attempting to read a directory is doesn't have access to, obviously) and returning those results when os.listdir is called. ---------- components: IO messages: 208100 nosy: shellster priority: normal severity: normal status: open title: os.walk conflicts with os.listdir type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 17:11:13 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 14 Jan 2014 16:11:13 +0000 Subject: [issue20259] os.walk conflicts with os.listdir In-Reply-To: <1389715078.64.0.968291006177.issue20259@psf.upfronthosting.co.za> Message-ID: <1389715873.31.0.150651452045.issue20259@psf.upfronthosting.co.za> R. David Murray added the comment: That's not how Python works. If you print out currentDir, you will see that os.listdir is never called on the folder for which you do not have permission. That is, os.walk does indeed catch the listdir error, when *it* does the listdir, does not try to descend into that subdirectory. If you want to do something with the error (such as raise it), use the 'onerror' argument of walk. ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 18:31:58 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jan 2014 17:31:58 +0000 Subject: [issue20260] Argument Clinic: add unsigned integers converters Message-ID: <1389720718.78.0.860738296491.issue20260@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch adds support for non-bitwise unsigned integer arguments in Argument Clinic. I.e. now unsigned_int(bitwise=False) (or just unsigned_int) converts Python int in range from 0 to UINT_MAX to C unsigned int. Added support for unsigned_short, unsigned_int, unsigned_long, unsigned_PY_LONG_LONG, and size_t. Also added global private functions _Py_UnsignedShort_Converter(), _Py_UnsignedInt_Converter(), _Py_UnsignedLong_Converter(), _Py_UnsignedLongLong_Converter(), and _Py_Size_t_Converter(), which are used by Argument Clinic and in C code still not converted to Argument Clinic. ---------- components: Demos and Tools, Interpreter Core files: clinic_unsigned_converters.patch keywords: patch messages: 208102 nosy: georg.brandl, larry, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Argument Clinic: add unsigned integers converters type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file33464/clinic_unsigned_converters.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 18:34:46 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 14 Jan 2014 17:34:46 +0000 Subject: [issue20260] Argument Clinic: add unsigned integers converters In-Reply-To: <1389720718.78.0.860738296491.issue20260@psf.upfronthosting.co.za> Message-ID: <1389720886.25.0.793963942178.issue20260@psf.upfronthosting.co.za> Larry Hastings added the comment: Very nice! I had an idea to do this in the back of my head too. But my plate is already full. I haven't reviewed the patch yet--and I have a huge backlog of reviews already. But I can give this higher priority if you need it for other patches. When do you need this reviewed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 19:03:49 2014 From: report at bugs.python.org (Fran Bull) Date: Tue, 14 Jan 2014 18:03:49 +0000 Subject: [issue20237] Ambiguous sentence in document of xml package. In-Reply-To: <1389608026.69.0.492339232238.issue20237@psf.upfronthosting.co.za> Message-ID: <1389722629.17.0.990673059099.issue20237@psf.upfronthosting.co.za> Fran Bull added the comment: I think the sentence either means: 1) The courses of action that defusedxml implements are those recommended for any server code that parses untrusted XML data. or 2) Using defused XML is recommended for any server code that parses untrusted XML data. And I think 2 is more likely. So the attached patch reflects that. ---------- keywords: +patch nosy: +Fran.Bull Added file: http://bugs.python.org/file33465/20237.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 19:18:56 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 14 Jan 2014 18:18:56 +0000 Subject: [issue20255] Doc/about: update a bit In-Reply-To: <1389686387.52.0.386182355157.issue20255@psf.upfronthosting.co.za> Message-ID: <1389723536.45.0.881706453008.issue20255@psf.upfronthosting.co.za> Georg Brandl added the comment: Both your and Berker's (on rietveld) comments sound good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 19:29:15 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 14 Jan 2014 18:29:15 +0000 Subject: [issue20237] Ambiguous sentence in document of xml package. In-Reply-To: <1389608026.69.0.492339232238.issue20237@psf.upfronthosting.co.za> Message-ID: <1389724155.93.0.268474650338.issue20237@psf.upfronthosting.co.za> R. David Murray added the comment: Actually, I think it means that the defusedxml documentation tells you what to do to protect yourself from various attack vectors, which pretty much amounts to importing certain functions from defusedxml and using them instead of the stdlib versions. Your patch may be sufficient, but let's see what Christian has to say. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 19:29:33 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jan 2014 18:29:33 +0000 Subject: [issue20260] Argument Clinic: add unsigned integers converters In-Reply-To: <1389720718.78.0.860738296491.issue20260@psf.upfronthosting.co.za> Message-ID: <1389724173.94.0.000384686650006.issue20260@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Currently these converters are used only in zlib (unsigned int) and select (unsigned short). But perhaps during conversion to Argument Clinic we will discover that they are more appropriate than bitwise converters in other places. So there is no hurry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 20:46:07 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 14 Jan 2014 19:46:07 +0000 Subject: [issue20261] Cannot pickle some objects that have a __getattr__() Message-ID: <1389728767.16.0.141259686696.issue20261@psf.upfronthosting.co.za> New submission from Barry A. Warsaw: I've been debugging a crash in nose 1.3.0, the root cause of which turned out to be an instance containing an attribute which itself was an instance of the following class (boiled down): class Picky: def __getstate__(self): return {} def __getattr__(self, attr): return None This crashes with a TypeError in Python 2.7 and Python 3 (albeit with slightly different tracebacks; and Python 3 is more difficult to debug because the TypeError doesn't include any useful information). TypeError: 'NoneType' object is not callable The culprit is __getattr__() returning None. In Python 3 for example, pickle tries to get the object's __reduce_ex__() function and then call it. The problem is the (IMHO) bogus __getattr__() and I'm not sure why nose has this. But I wonder if the pickle documentation should warn against this kind of thing. This isn't a bug in Python - the crash makes sense when you understand the implications, but perhaps a warning in the docs would have helped prevent this nose bug in the first place. I suppose I could also see improving _pickle.c to provide some additional feedback on the offending attribute, but that's probably more difficult. It's okay to close this as won't fix if we can't think of appropriate wording. It's enough that there's a record of this issue for search engines now. ---------- assignee: docs at python components: Documentation messages: 208108 nosy: barry, docs at python priority: normal severity: normal status: open title: Cannot pickle some objects that have a __getattr__() versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 20:54:44 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 14 Jan 2014 19:54:44 +0000 Subject: [issue20261] Cannot pickle some objects that have a __getattr__() In-Reply-To: <1389728767.16.0.141259686696.issue20261@psf.upfronthosting.co.za> Message-ID: <1389729284.21.0.174760794096.issue20261@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Hmm, actually, this is a regression in Python 3.4. Let's amend the test class to include a __getnewargs__(): class Picky(object): """Options container that returns None for all options. """ def __getstate__(self): return {} def __getnewargs__(self): return () def __getattr__(self, attr): return None This class is picklable in Python 2.7 - 3.3, but not in 3.4. ---------- components: +Library (Lib) keywords: +3.4regression _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 21:08:30 2014 From: report at bugs.python.org (Jakub Wilk) Date: Tue, 14 Jan 2014 20:08:30 +0000 Subject: [issue1652] subprocess should have an option to restore SIGPIPE to default action In-Reply-To: <1197992466.47.0.0612439954222.issue1652@psf.upfronthosting.co.za> Message-ID: <1389730110.21.0.365993917333.issue1652@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 21:15:54 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 14 Jan 2014 20:15:54 +0000 Subject: [issue20255] Doc/about: update a bit In-Reply-To: <1389686387.52.0.386182355157.issue20255@psf.upfronthosting.co.za> Message-ID: <1389730554.49.0.284244938107.issue20255@psf.upfronthosting.co.za> Zachary Ware added the comment: Looks good to me, with Berker and David's comments addressed. Here's an alternate approach I came up with, since about.rst already links to bugs.rst, which already contains most of what I think we want to get across here. I'm good with either route, really. ---------- Added file: http://bugs.python.org/file33466/issue20255.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 21:46:42 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 14 Jan 2014 20:46:42 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389732402.74.0.671046905583.issue20189@psf.upfronthosting.co.za> Larry Hastings added the comment: Dang it, I forgot to add the second patch. Here it is. ---------- Added file: http://bugs.python.org/file33467/larry.support.text_signature.on.more.types.diff.2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 21:56:35 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jan 2014 20:56:35 +0000 Subject: [issue20262] Convert some debugging prints in zipfile to warnings Message-ID: <1389732995.51.0.822070396354.issue20262@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: When ZipFile.debug is not zero, some debugging messages are printed to stdout. Some of them are for debugging the zipfile module itself. But some are warnings about user's operation which perhaps make not what the user is expected -- truncating long archive comment or adding a file with duplicated name. These cases cases can be considered as logic error, they can be prevented by external checks (check that comment's length does not excite the limit and that specified name is not in the ZIP file). So it will be sane and helpful to convert these prints to regular warnings, which are controlled in same way as all other warnings. See also issue2824. It have a patch which looks too excessive to me. Here is a patch. I don't sure to which version it should be targeted. ---------- components: Library (Lib) files: zipfile_warnings.patch keywords: patch messages: 208112 nosy: alanmcintyre, georg.brandl, larry, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Convert some debugging prints in zipfile to warnings Added file: http://bugs.python.org/file33468/zipfile_warnings.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 22:09:27 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 14 Jan 2014 21:09:27 +0000 Subject: [issue20255] Doc/about: update a bit In-Reply-To: <1389686387.52.0.386182355157.issue20255@psf.upfronthosting.co.za> Message-ID: <1389733767.02.0.893448082431.issue20255@psf.upfronthosting.co.za> Georg Brandl added the comment: Very nice. Go ahead and commit your version! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 22:17:58 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jan 2014 21:17:58 +0000 Subject: [issue18695] os.statvfs() not working well with unicode paths In-Reply-To: <1376050003.6.0.904056390722.issue18695@psf.upfronthosting.co.za> Message-ID: <1389734278.87.0.184844371385.issue18695@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Giampaolo, do you want to provide a test? ---------- stage: -> test needed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 22:20:45 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jan 2014 21:20:45 +0000 Subject: [issue2382] [Py3k] SyntaxError cursor shifted if multibyte character is in line. In-Reply-To: <1205817752.04.0.892564898323.issue2382@psf.upfronthosting.co.za> Message-ID: <1389734445.92.0.074266778484.issue2382@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If no one complain I'll commit last patch tomorrow. ---------- assignee: -> serhiy.storchaka stage: -> patch review type: -> behavior versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 22:38:10 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jan 2014 21:38:10 +0000 Subject: [issue19534] normalize() in locale.py fails for sr_RS.UTF-8@latin In-Reply-To: <1383984179.72.0.86841867315.issue19534@psf.upfronthosting.co.za> Message-ID: <1389735490.63.0.994402534767.issue19534@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: locale.normalize() was fixed in issue5815 (and new entry for 'sr_RS.UTF-8 at latin' is not needed anymore). Devanagari entries were fixed in issue20027. In any case thank you Mike for your report and proposed patch. ---------- resolution: -> duplicate stage: -> committed/rejected status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 23:04:05 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jan 2014 22:04:05 +0000 Subject: [issue20255] Doc/about: update a bit In-Reply-To: <1389686387.52.0.386182355157.issue20255@psf.upfronthosting.co.za> Message-ID: <3f3m0N6s6Nz7Lnk@mail.python.org> Roundup Robot added the comment: New changeset 74d138cfe564 by Zachary Ware in branch '2.7': Issue #20255: Update the about and bugs pages. http://hg.python.org/cpython/rev/74d138cfe564 New changeset 956b8afdaa3e by Zachary Ware in branch '3.3': Issue #20255: Update the about and bugs pages. http://hg.python.org/cpython/rev/956b8afdaa3e New changeset 26236308d58b by Zachary Ware in branch 'default': Issue #20255: Update the about and bugs pages. http://hg.python.org/cpython/rev/26236308d58b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 23:04:58 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 14 Jan 2014 22:04:58 +0000 Subject: [issue20255] Doc/about: update a bit In-Reply-To: <1389686387.52.0.386182355157.issue20255@psf.upfronthosting.co.za> Message-ID: <1389737098.04.0.481770635734.issue20255@psf.upfronthosting.co.za> Zachary Ware added the comment: Done, thanks Georg! ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> enhancement versions: +Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 23:32:29 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 14 Jan 2014 22:32:29 +0000 Subject: [issue20261] Cannot pickle some objects that have a __getattr__() In-Reply-To: <1389728767.16.0.141259686696.issue20261@psf.upfronthosting.co.za> Message-ID: <1389738749.62.0.844133897567.issue20261@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 23:49:03 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jan 2014 22:49:03 +0000 Subject: [issue16612] Integrate "Argument Clinic" into CPython trunk In-Reply-To: <1354659537.54.0.587753848221.issue16612@psf.upfronthosting.co.za> Message-ID: <3f3n0G6Cn8z7Lqk@mail.python.org> Roundup Robot added the comment: New changeset f35b3a86ade3 by Meador Inge in branch 'default': Fix minor bug in dict.__contains__ docstring. http://hg.python.org/cpython/rev/f35b3a86ade3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 23:50:06 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 14 Jan 2014 22:50:06 +0000 Subject: [issue16612] Integrate "Argument Clinic" into CPython trunk In-Reply-To: <1354659537.54.0.587753848221.issue16612@psf.upfronthosting.co.za> Message-ID: <1389739806.17.0.962308913965.issue16612@psf.upfronthosting.co.za> Larry Hastings added the comment: Meador Inge: In the future, please create new issues for these sorts of fixes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 23:51:17 2014 From: report at bugs.python.org (Meador Inge) Date: Tue, 14 Jan 2014 22:51:17 +0000 Subject: [issue16612] Integrate "Argument Clinic" into CPython trunk In-Reply-To: <1354659537.54.0.587753848221.issue16612@psf.upfronthosting.co.za> Message-ID: <1389739877.02.0.669796516704.issue16612@psf.upfronthosting.co.za> Meador Inge added the comment: Will do, but in this case I didn't think a one character diff was worth it. ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 14 23:56:39 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 14 Jan 2014 22:56:39 +0000 Subject: [issue16612] Integrate "Argument Clinic" into CPython trunk In-Reply-To: <1354659537.54.0.587753848221.issue16612@psf.upfronthosting.co.za> Message-ID: <1389740199.42.0.769493824781.issue16612@psf.upfronthosting.co.za> Larry Hastings added the comment: If it's not worth a new issue, then you can check it in without citing an issue at all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 00:06:49 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jan 2014 23:06:49 +0000 Subject: [issue20261] Cannot pickle some objects that have a __getattr__() In-Reply-To: <1389728767.16.0.141259686696.issue20261@psf.upfronthosting.co.za> Message-ID: <1389740809.94.0.413405839436.issue20261@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +alexandre.vassalotti, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 00:23:44 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 14 Jan 2014 23:23:44 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389741824.85.0.964322394075.issue20189@psf.upfronthosting.co.za> Larry Hastings added the comment: Updated the patch. (Diff #2 apparently didn't apply cleanly, so we didn't get a review link.) Old-guard core devs: I'm *really* desperate for a review of this patch. You don't have to review everything thing, just these files: * Include/object.h * Objects/descrobject.c * Objects/methodobject.c * Objects/typeobject.c I can get a different reviewer for the other files. But I worry about touching these tender bits of the type system and I want to make sure that a) I haven't done something awful, and b) I haven't missed something important. Just that part of the diff is 345 lines, and it's pretty regular. I'd be surprised if it took you a whole hour. If you have any questions email me, I'd be thrilled to answer 'em if it means I can get this patch checked in. Maintaining the patch is overhead that I just don't need during the Derby. ---------- nosy: +barry Added file: http://bugs.python.org/file33469/larry.support.text_signature.on.more.types.diff.3.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 00:35:28 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 14 Jan 2014 23:35:28 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1389742528.39.0.184274023914.issue20185@psf.upfronthosting.co.za> Larry Hastings added the comment: Antoine Pitrou took care of cryptmodule.c. ---------- title: Derby #17: Convert 50 sites to Argument Clinic across 14 files -> Derby #17: Convert 49 sites to Argument Clinic across 13 files _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 01:04:42 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 15 Jan 2014 00:04:42 +0000 Subject: [issue20247] Condition._is_owned is wrong In-Reply-To: <1389660921.49.0.651163897864.issue20247@psf.upfronthosting.co.za> Message-ID: <1389744282.1.0.168336784858.issue20247@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +neologix versions: +Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 01:40:07 2014 From: report at bugs.python.org (Ozy) Date: Wed, 15 Jan 2014 00:40:07 +0000 Subject: [issue20263] Function print definable as variables? Message-ID: <1389746407.11.0.333794410769.issue20263@psf.upfronthosting.co.za> New submission from Ozy: Not sure if this is a bug. We're experiencing it in v3.3.2 and was discovered by accident. It seems to be possible to define python functions (like print or input) as variables, as if they're not reserved. If you do that, the command functionality is lost until Python is reseted. For example try this in IDLE: >>> print = 10 >>> print 10 >>> print(print) TypeError: int object is not callable >>> print(10) TypeError: int object is not callable Here is a screenshot > http://imgur.com/IpjELhp We tested it, and this doesn't happen in v2. Sorry if this has been reported previously. Best regards. ---------- messages: 208125 nosy: ozy priority: normal severity: normal status: open title: Function print definable as variables? type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 01:46:15 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 15 Jan 2014 00:46:15 +0000 Subject: [issue20263] Function print definable as variables? In-Reply-To: <1389746407.11.0.333794410769.issue20263@psf.upfronthosting.co.za> Message-ID: <1389746775.44.0.470846282711.issue20263@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, that's the way Python works. In Python3, print became a function and is no longer a keyword, so yes, it can be shadowed in the local namespace just like any other Python function. ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 01:53:20 2014 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 15 Jan 2014 00:53:20 +0000 Subject: [issue20263] Function print definable as variables? In-Reply-To: <1389746407.11.0.333794410769.issue20263@psf.upfronthosting.co.za> Message-ID: <1389747200.43.0.231121814319.issue20263@psf.upfronthosting.co.za> Ezio Melotti added the comment: FTR you can always get it back from builtins.print: >>> print('test') test >>> print = 10 >>> print('test') Traceback (most recent call last): File "", line 1, in TypeError: 'int' object is not callable >>> import builtins >>> print = builtins.print >>> print('test') test ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 02:08:01 2014 From: report at bugs.python.org (Ozy) Date: Wed, 15 Jan 2014 01:08:01 +0000 Subject: [issue20263] Function print definable as variables? In-Reply-To: <1389746407.11.0.333794410769.issue20263@psf.upfronthosting.co.za> Message-ID: <1389748081.72.0.913652808402.issue20263@psf.upfronthosting.co.za> Ozy added the comment: Great, thanks. Didn't know that. All the best. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 02:23:16 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 15 Jan 2014 01:23:16 +0000 Subject: [issue19855] uuid._find_mac fails if an executable not in /sbin or /usr/sbin In-Reply-To: <1385910768.71.0.356029979861.issue19855@psf.upfronthosting.co.za> Message-ID: <1389748996.54.0.0597076030192.issue19855@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: When LC_ALL is already set in environment, LC_MESSAGES will not override it. I suggest to restore LC_ALL=C in place of LC_MESSAGES=C. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 03:20:06 2014 From: report at bugs.python.org (Meador Inge) Date: Wed, 15 Jan 2014 02:20:06 +0000 Subject: [issue20178] Derby #9: Convert 52 sites to Argument Clinic across 11 files In-Reply-To: <1389140078.91.0.720761635456.issue20178@psf.upfronthosting.co.za> Message-ID: <1389752406.65.0.862603230886.issue20178@psf.upfronthosting.co.za> Meador Inge added the comment: Attached is a first cut for sqlite3. It is generally OK, but I have the following nits: * As is probably expected, __init__ and __call__ procs can't be converted. * sqlite3.Connection.{execute, executemany, executescript} don't use PyArg_Parse*. * The clinic version of 'sqlite3.adapt' has an argument string of "O|OO". The first optional parameter defaults to 'pysqlite_PrepareProtocolType' in C and 'sqlite3.ProtocolType' in Python. However, I don't know how to represent the Python value because Python default values are 'eval'd by clinic *and* the 'sqlite3' module is not imported for the eval. * The clinic version of 'sqlite3.Cursor.fetchmany' has an arguments string of "|i". The first parameter defaults to '((pysqlite_Cursor *)self)->arraysize' in C and 'self.arraysize' in Python. I don't know how to express the Python initialization. * 'sqlite3.complete' uses 'as module_complete' because 'sqlite3_complete' is a public SQLite API function: http://www.sqlite.org/c3ref/complete.html. I used 'as' on all the other functions in 'module.c' as well. Mainly for local consistency. * '_pysqlite_query_execute' required a little refactoring due to the fact that it is a utility function used to implement 'sqlite3.Cursor.execute' and 'sqlite3.Cursor.executemany'. 'PyArg_ParseTuple' was being called in different way depending on a control parameter. * I didn't convert 'sqlite3.Cursor.setinputsizes' and 'sqlite3.Cursor.setoutputsize' because they share a docstring and simple no-op method def. * I didn't convert 'sqlite.connect' because it would have required packaing the arguments back up to pass to 'PyObject_Call'. ---------- Added file: http://bugs.python.org/file33470/issue20178-sqlite-01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 03:56:20 2014 From: report at bugs.python.org (Tim Peters) Date: Wed, 15 Jan 2014 02:56:20 +0000 Subject: [issue20247] Condition._is_owned is wrong In-Reply-To: <1389660921.49.0.651163897864.issue20247@psf.upfronthosting.co.za> Message-ID: <1389754580.56.0.0310826975401.issue20247@psf.upfronthosting.co.za> Tim Peters added the comment: They certainly should _not_ be swapped, as explained clearly in the message following the one you referenced. For the first half: if self._lock.acquire(0): succeeds if and only if the lock is not held by _any_ thread at the time. In that case, the lock is _acquired_ as a side-effect of performing the test, and the code goes on to restore the lock again to its initially unacquired state, and (correctly) return False: self._lock.release() return False The second half of the code is certainly wrong: else: return True The docs state: # Return True if lock is owned by current_thread. but the code actually returns True if the lock is currently owned by _any_ thread. All that is also explained in the thread you pointed at. However, I don't see any possibility of fixing that. There is simply no way to know, for an arbitrary "lock-like" object, which thread owns it. Indeed, on Windows it's not even possible for a threading.Lock. For example (here under Python3, but I'm sure it's the same under Python2): >>> import threading as th >>> lock = th.Lock() >>> c = th.Condition(lock) >>> def hmm(): ... print("is_owned:", c._is_owned()) ... >>> t = th.Thread(target=hmm) >>> t.start() is_owned: False >>> lock.acquire() True >>> t = th.Thread(target=hmm) >>> t.start() is_owned: True Note that the last line showed True despite that the lock is _not_ owned by the thread doing the print - it's owned by the main program thread. That's because threading.Lock._is_owned doesn't exist under Windows, so it's falling into the second case of the Condition._is_owned() implementation at issue here. Also note that if the True and False cases were swapped, _none_ of the output would make any sense at all ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 04:12:39 2014 From: report at bugs.python.org (Meador Inge) Date: Wed, 15 Jan 2014 03:12:39 +0000 Subject: [issue20264] Update patchcheck to looks for files with clinic comments Message-ID: <1389755559.69.0.925028805372.issue20264@psf.upfronthosting.co.za> New submission from Meador Inge: It has been noted a few times that someone might forget to re-run clinic.py after updating the argument clinic comments. The attached patch adds a new check to patchcheck.py to note when files containing argument clinic comments have been changed. You could take it a step further and deduce if the lines ranges within the comments were actually changed, but let's start out simple. ---------- assignee: meador.inge components: Build files: patchcheck-clinic.patch keywords: patch messages: 208132 nosy: larry, meador.inge priority: normal severity: normal stage: patch review status: open title: Update patchcheck to looks for files with clinic comments type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file33471/patchcheck-clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 04:30:35 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 15 Jan 2014 03:30:35 +0000 Subject: [issue20264] Update patchcheck to looks for files with clinic comments In-Reply-To: <1389755559.69.0.925028805372.issue20264@psf.upfronthosting.co.za> Message-ID: <1389756635.62.0.201415053915.issue20264@psf.upfronthosting.co.za> Zachary Ware added the comment: This could be taken a step further, following the lead of the whitespace fixing checks and just run clinic on files that need it. ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 04:36:13 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Wed, 15 Jan 2014 03:36:13 +0000 Subject: [issue20174] Derby #5: Convert 50 sites to Argument Clinic across 3 files In-Reply-To: <1389138461.92.0.709656306175.issue20174@psf.upfronthosting.co.za> Message-ID: <1389756973.27.0.346799823887.issue20174@psf.upfronthosting.co.za> Ryan Smith-Roberts added the comment: Here's the socketmodule patch. I aggressively imported text from the docs for the docstrings, along with matching parameter names, given how far the old docstrings have drifted over time. The Windows-specific code is untested, but otherwise the tests pass. I tagged functions which can't be converted or whose argument handling is esoteric. These comments can be removed prior to commit. I am not sure if one should convert a C-level class's init method. ---------- Added file: http://bugs.python.org/file33472/argument_clinic_socketmodule.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 04:40:43 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 15 Jan 2014 03:40:43 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? In-Reply-To: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> Message-ID: <1389757243.15.0.949282322723.issue20226@psf.upfronthosting.co.za> Larry Hastings added the comment: The attached patch extends Argument Clinic and the inspect module: now you may use simple (!) expressions as default values. So for example "sys.maxsize - 1" should now work fine. * Names may be in the current module; as a backup they will also be looked up in sys.modules. * You may look up attributes of names. * You may subscript into names. * You may use math operators, both unary and binary. * int/float/string literals are (still) fine. * You may not use: function calls, list/set/dict/tuple/bytes literals, generator expressions or comprehensions, if expressions, anything fun. Other changes in this diff: * "doc_default" is gone, it no longer makes sense. * "py_default" and "c_default" handling is simpler and more predictable. * Minor doc fix suggested on tracker. The docs still need work. More tests would be good too but I'm already overwhelmed by work--could one of you guys contribute some tests? ---------- stage: -> patch review type: -> enhancement Added file: http://bugs.python.org/file33473/larry.clinic.rollup.patch.two.diff.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 04:41:05 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 15 Jan 2014 03:41:05 +0000 Subject: [issue20265] Bring Doc/using/windows up to date Message-ID: <1389757265.26.0.116885263001.issue20265@psf.upfronthosting.co.za> New submission from Zachary Ware: Doc/using/windows still mentions DOS, Windows 3.x, and Python 2.1, and that's just in the first short section. This is a catch-all issue for making sure that page is up to date. ---------- assignee: docs at python components: Documentation, Windows keywords: easy messages: 208136 nosy: docs at python, zach.ware priority: normal severity: normal stage: needs patch status: open title: Bring Doc/using/windows up to date type: enhancement versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 04:49:55 2014 From: report at bugs.python.org (Meador Inge) Date: Wed, 15 Jan 2014 03:49:55 +0000 Subject: [issue20262] Convert some debugging prints in zipfile to warnings In-Reply-To: <1389732995.51.0.822070396354.issue20262@psf.upfronthosting.co.za> Message-ID: <1389757795.25.0.906114669686.issue20262@psf.upfronthosting.co.za> Meador Inge added the comment: LGTM. I audited the other 'ZipFile.debug' uses and agree that the others are mainly useful in debugging the zipfile implementation itself. Since it isn't that critical of a change, the default branch should be sufficient. ---------- nosy: +meador.inge type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 05:00:49 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 15 Jan 2014 04:00:49 +0000 Subject: [issue20266] Bring Doc/faq/windows up to date Message-ID: <1389758449.02.0.48240700444.issue20266@psf.upfronthosting.co.za> New submission from Zachary Ware: The Python on Windows faq could use some TLC. For instance, cx_Freeze should be mentioned in the faq about creating an executable (and py2exe should either mention that it doesn't quite support 3.x yet, or just be removed until it does), and the embedding faq should be cleaned up with proper voice and formatting (and the "undocumented facts" should be documented). ---------- assignee: docs at python components: Documentation, Windows keywords: easy messages: 208138 nosy: docs at python, zach.ware priority: normal severity: normal stage: needs patch status: open title: Bring Doc/faq/windows up to date type: enhancement versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 05:11:23 2014 From: report at bugs.python.org (Meador Inge) Date: Wed, 15 Jan 2014 04:11:23 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? In-Reply-To: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> Message-ID: <1389759083.18.0.277966533128.issue20226@psf.upfronthosting.co.za> Meador Inge added the comment: Larry, nice. I am verified that your latest patch fixes my third sqlite3 nit from issue20178. ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 05:26:00 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Wed, 15 Jan 2014 04:26:00 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1389759960.06.0.180222960478.issue20185@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the patch for Modules/resource.c. However, I can not convert this method signature: if (!PyArg_ParseTuple(args, _Py_PARSE_PID "i|(OO):prlimit", &pid, &resource, &curobj, &maxobj)) _Py_PARSE_PID can be 'i' or 'l' or 'L'. ---------- keywords: +patch nosy: +vajrasky Added file: http://bugs.python.org/file33474/clinic_codecsmodule.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 05:26:08 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Wed, 15 Jan 2014 04:26:08 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1389759968.48.0.146980915363.issue20185@psf.upfronthosting.co.za> Changes by Vajrasky Kok : Removed file: http://bugs.python.org/file33474/clinic_codecsmodule.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 05:26:25 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Wed, 15 Jan 2014 04:26:25 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1389759985.24.0.769382041274.issue20185@psf.upfronthosting.co.za> Changes by Vajrasky Kok : Added file: http://bugs.python.org/file33475/clinic_resource.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 05:48:28 2014 From: report at bugs.python.org (Antony Lee) Date: Wed, 15 Jan 2014 04:48:28 +0000 Subject: [issue20267] TemporaryDirectory does not resolve path when created using a relative path Message-ID: <1389761308.4.0.00958902784577.issue20267@psf.upfronthosting.co.za> New submission from Antony Lee: Essentially, the following fails: t = tempfile.TemporaryDirectory(dir=".") os.chdir(some_other_dir) t.cleanup() because t.name is a relative path. Resolving the "dir" argument when the directory is created should(?) fix the issue. ---------- components: Library (Lib) messages: 208141 nosy: Antony.Lee priority: normal severity: normal status: open title: TemporaryDirectory does not resolve path when created using a relative path versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 06:24:04 2014 From: report at bugs.python.org (Eric Snow) Date: Wed, 15 Jan 2014 05:24:04 +0000 Subject: [issue20261] Cannot pickle some objects that have a __getattr__() In-Reply-To: <1389728767.16.0.141259686696.issue20261@psf.upfronthosting.co.za> Message-ID: <1389763444.37.0.322002027451.issue20261@psf.upfronthosting.co.za> Eric Snow added the comment: This is a duplicate of #16251, no? Pickle looks up dunder ;) methods on instances rather than on classes, so __getattr__() gets triggered unexpectedly. I had to work around this in some code of mine by special-casing in __getattr__() names that start with '_'. I've said my peace over in #16251. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 06:49:19 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 15 Jan 2014 05:49:19 +0000 Subject: [issue20268] Argument Clinic: support cloning existing functions Message-ID: <1389764959.28.0.222102740928.issue20268@psf.upfronthosting.co.za> New submission from Larry Hastings: It was a quick hack: Clinic now has a syntax for cloning an existing function! The first line of the function block should be module.class.new_function [as c_basename] = module.class.existing_fn Hurry up and give me a LGTM so you can use it everywhere! :D ---------- assignee: larry files: larry.clinic.clone.functions.diff.1.txt messages: 208143 nosy: georg.brandl, larry, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Argument Clinic: support cloning existing functions type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file33476/larry.clinic.clone.functions.diff.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 07:04:34 2014 From: report at bugs.python.org (Georg Brandl) Date: Wed, 15 Jan 2014 06:04:34 +0000 Subject: [issue20268] Argument Clinic: support cloning existing functions In-Reply-To: <1389764959.28.0.222102740928.issue20268@psf.upfronthosting.co.za> Message-ID: <1389765874.94.0.25714206545.issue20268@psf.upfronthosting.co.za> Georg Brandl added the comment: Functionality looks good. Implementation I can't say. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 07:14:50 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 15 Jan 2014 06:14:50 +0000 Subject: [issue20268] Argument Clinic: support cloning existing functions In-Reply-To: <1389764959.28.0.222102740928.issue20268@psf.upfronthosting.co.za> Message-ID: <1389766490.58.0.171653743646.issue20268@psf.upfronthosting.co.za> Larry Hastings added the comment: Shall I just check it in and fix it if it breaks? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 07:18:39 2014 From: report at bugs.python.org (Georg Brandl) Date: Wed, 15 Jan 2014 06:18:39 +0000 Subject: [issue20268] Argument Clinic: support cloning existing functions In-Reply-To: <1389764959.28.0.222102740928.issue20268@psf.upfronthosting.co.za> Message-ID: <1389766719.73.0.636985391467.issue20268@psf.upfronthosting.co.za> Georg Brandl added the comment: Sure! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 07:22:42 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 15 Jan 2014 06:22:42 +0000 Subject: [issue16251] pickle special methods are looked up on the instance rather than the type In-Reply-To: <1350411894.01.0.763638555345.issue16251@psf.upfronthosting.co.za> Message-ID: <1389766962.74.0.852039216775.issue16251@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 07:23:09 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 15 Jan 2014 06:23:09 +0000 Subject: [issue20268] Argument Clinic: support cloning existing functions In-Reply-To: <1389764959.28.0.222102740928.issue20268@psf.upfronthosting.co.za> Message-ID: <3f3z4D63KRz7LjT@mail.python.org> Roundup Robot added the comment: New changeset 565773aabafb by Larry Hastings in branch 'default': Issue #20268: Argument Clinic now supports cloning the parameters http://hg.python.org/cpython/rev/565773aabafb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 07:23:50 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 15 Jan 2014 06:23:50 +0000 Subject: [issue20268] Argument Clinic: support cloning existing functions In-Reply-To: <1389764959.28.0.222102740928.issue20268@psf.upfronthosting.co.za> Message-ID: <1389767030.84.0.76057863579.issue20268@psf.upfronthosting.co.za> Larry Hastings added the comment: Begun, the clone war has. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 07:25:14 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 15 Jan 2014 06:25:14 +0000 Subject: [issue18695] os.statvfs() not working well with unicode paths In-Reply-To: <1376050003.6.0.904056390722.issue18695@psf.upfronthosting.co.za> Message-ID: <1389767114.95.0.884900425358.issue18695@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 07:38:40 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 15 Jan 2014 06:38:40 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1389767920.82.0.0420123523394.issue20172@psf.upfronthosting.co.za> Larry Hastings added the comment: Zachary: If you refresh your copy of trunk, you can now "clone" functions. See the howto for the syntax. The failure you were seeing was in some code that I just rewrote (see #20226). I'd be interested if you could apply that patch and try your code again. Or just wait maybe twelve hours, hopefully I'll have landed the patch by then. (Yeah, it's kind of a moving target. I'm trying to keep the pace up during the Derby.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 08:11:42 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Wed, 15 Jan 2014 07:11:42 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1389769902.29.0.461450556485.issue20185@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the patch for Modules/gcmodule.c. ---------- Added file: http://bugs.python.org/file33477/clinic_gc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 09:17:50 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 15 Jan 2014 08:17:50 +0000 Subject: [issue18373] implement sys.get/setbyteswarningflag() In-Reply-To: <1373065124.82.0.249288626652.issue18373@psf.upfronthosting.co.za> Message-ID: <1389773870.58.0.141231560087.issue18373@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 10:28:52 2014 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 15 Jan 2014 09:28:52 +0000 Subject: [issue20269] Inconsistent behavior in pdb when pressing Ctrl-C Message-ID: <1389778132.96.0.0363637857633.issue20269@psf.upfronthosting.co.za> New submission from Xavier de Gaye: With this script: # START def foo(): while 1: pass import pdb; pdb.set_trace() foo() # END The following sequence of pdb commands aborts the script with a KeyboardInterrupt exception: next Ctrl-C continue While the equivalent following sequence of commands allows the debugging session to continue as expected: continue Ctrl-C continue The first sequence of commands should behave as the second one. A related problem is that the original SIGINT handler (named _previous_sigint_handler in the code) is not restored when the program being debugged is stopped at a breakpoint that has been reached after 'continue'. _previous_sigint_handler is lost forever in this case when the user hits 'continue' after stopping at that breakpoint, which is quite common. This is annoying. For example, trying to extend pdb with a 'detach' command that enables the debuggee to run freely after the debugging session is terminated: the program cannot be killed anymore with SIGINT when the above case occurs. The attached patch attempts to fix these problems. After applying the attached patch, the behavior of the 'next, Ctrl-C, continue' sequence of commands is still wrong: this is another bug logged at issue 14788 with a patch and a test. Applying patch 14788 fixes this. ---------- components: Library (Lib) files: sigint.patch keywords: patch messages: 208151 nosy: georg.brandl, xdegaye priority: normal severity: normal status: open title: Inconsistent behavior in pdb when pressing Ctrl-C type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file33478/sigint.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 11:27:54 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jan 2014 10:27:54 +0000 Subject: [issue20187] The Great Argument Clinic Conversion Derby Meta-Issue In-Reply-To: <1389141105.5.0.459903580868.issue20187@psf.upfronthosting.co.za> Message-ID: <1389781674.91.0.354901974167.issue20187@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I want to warn against the converting of base objects (whose sources lie in Objects/). Their performance is critical and the converting can worsen it. Often they even don't use PyArg_ParseTuple due to performance reasons or because argument parsing is too special for PyArg_ParseTuple. I would suggest to postpone it until Argument Clinic will generate optimized parsing code. The same is true for some modules. The performance of struct and operator is important. In any case these modules almost not use PyArg_ParseTuple and can be omitted. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 11:32:58 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 15 Jan 2014 10:32:58 +0000 Subject: [issue14455] plistlib unable to read json and binary plist files In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za> Message-ID: <3f44cT6TyjzRVl@mail.python.org> Roundup Robot added the comment: New changeset 1a8149ba3000 by Ronald Oussoren in branch 'default': Issue #14455: Fix some issues with plistlib http://hg.python.org/cpython/rev/1a8149ba3000 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 11:51:14 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Wed, 15 Jan 2014 10:51:14 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1389783074.37.0.252135427802.issue20185@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the patch for Python/marshal.c. A couple of issues: 1. I can not have bytes as argument. bytes: Py_buffer -> not possible So I changed it to byte. 2. I can not give default value, marshal.version, to argument. version: int(c_default="Py_MARSHAL_VERSION") = marshal.version -> not possible (unless I put "import marshal" in Tools/clinic/clinic.py). So I gave it a raw value, 2. version: int(c_default="Py_MARSHAL_VERSION") = 2 ---------- Added file: http://bugs.python.org/file33479/clinic_marshal.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 12:25:34 2014 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 15 Jan 2014 11:25:34 +0000 Subject: [issue14455] plistlib unable to read json and binary plist files In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za> Message-ID: <1389785134.82.0.268061212064.issue14455@psf.upfronthosting.co.za> Changes by Ronald Oussoren : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 13:26:25 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jan 2014 12:26:25 +0000 Subject: [issue20270] urllib.parse doesn't work with empty port Message-ID: <1389788785.56.0.178405230158.issue20270@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: According to RFC 3986 the port subcomponent is defined as zero or more decimal digits delimited from the host by a single colon. I.e. 'python.org:' is valid (but not normalized) form. Empty port is equivalent to absent port. >>> import urllib.parse >>> p = urllib.parse.urlparse('http://python.org:') >>> p.hostname 'python.org' >>> p.port # should return None Traceback (most recent call last): File "", line 1, in File "/home/serhiy/py/cpython-3.3/Lib/urllib/parse.py", line 156, in port port = int(port, 10) ValueError: invalid literal for int() with base 10: '' >>> urllib.parse.splitport('python.org:') # should return ('python.org', None) ('python.org:', None) >>> urllib.parse.splitnport('python.org:') # should return ('python.org', -1) ('python.org', None) >>> urllib.parse.splitnport('python.org:', 80) # should return ('python.org', 80) ('python.org', None) Proposed patch fixes this. It also adds tests for urllib.parse.splitport(). ---------- components: Library (Lib) files: urllib_parse_empty_port.patch keywords: patch messages: 208155 nosy: orsenthil, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: urllib.parse doesn't work with empty port type: behavior versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33480/urllib_parse_empty_port.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 13:32:09 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jan 2014 12:32:09 +0000 Subject: [issue20271] urllib.parse.urlparse() accepts wrong URLs Message-ID: <1389789129.93.0.775761654638.issue20271@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: >>> import urllib.parse >>> p = urllib.parse.urlparse('http://[::1]spam:80') >>> p ParseResult(scheme='http', netloc='[::1]spam:80', path='', params='', query='', fragment='') >>> p.hostname '::1' >>> p.port 80 'http://[::1]spam:80' is invalid URL, but urllib.parse.urlparse() accepts it and just ignore the spam part. ---------- components: Library (Lib) messages: 208156 nosy: orsenthil, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: urllib.parse.urlparse() accepts wrong URLs type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 13:32:52 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jan 2014 12:32:52 +0000 Subject: [issue20271] urllib.parse.urlparse() accepts wrong URLs In-Reply-To: <1389789129.93.0.775761654638.issue20271@psf.upfronthosting.co.za> Message-ID: <1389789172.03.0.508871136979.issue20271@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +urllib.parse doesn't work with empty port _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 13:37:09 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jan 2014 12:37:09 +0000 Subject: [issue18191] urllib2/urllib.parse.splitport does not handle IPv6 correctly In-Reply-To: <1370961879.5.0.532150427937.issue18191@psf.upfronthosting.co.za> Message-ID: <1389789429.37.0.258566894608.issue18191@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Julien's patch is subject to bugs described in issue20270 and issue20271. As far as OpenStack Oslo library. ---------- dependencies: +urllib.parse doesn't work with empty port, urllib.parse.urlparse() accepts wrong URLs type: -> behavior versions: +Python 3.4 -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 14:08:18 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jan 2014 13:08:18 +0000 Subject: [issue14455] plistlib unable to read json and binary plist files In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za> Message-ID: <1389791298.52.0.319656964495.issue14455@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I see that plistlib incorrectly writes large ints from 2**63 to 2**64-1 as negative values. >>> d = plistlib.dumps({'a': 18446744073709551615}, fmt=plistlib.FMT_BINARY) >>> plistlib.loads(d) {'a': -1} My patch did this correct (as 128-bit integer), and as you can see the produced file is accepted by Apple's plutil. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 14:21:01 2014 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 15 Jan 2014 13:21:01 +0000 Subject: [issue14455] plistlib unable to read json and binary plist files In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za> Message-ID: <1389792061.85.0.772622569527.issue14455@psf.upfronthosting.co.za> Ronald Oussoren added the comment: However, I have no idea how to write that file using Apple's APIs. I'd prefer to either be compatible with Apple's API (current behavior), or just outright reject values that cannot be represented as a 64-bit signed integer. The file you generated happens to work, but as there is no way to create such as file using a public API there is little reason to expect that this will keep functioning in the future. The CFBinaryPlist code appears to be shared between support for binary plists and keyed archiving (more or less Cocoa's equivalent for pickle) and supports other values that cannot be put in plist files, such as sets. The original patch supported sets in the binary plist reader and writer, I ripped that out because such objects cannot be serialised using Apple's plist APIs. Keep in mind that this module is intended for interop with Apple's data format. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 14:36:07 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 15 Jan 2014 13:36:07 +0000 Subject: [issue20009] Property should expose wrapped function. In-Reply-To: <1387316995.02.0.931185950843.issue20009@psf.upfronthosting.co.za> Message-ID: <1389792967.5.0.655269341454.issue20009@psf.upfronthosting.co.za> Nick Coghlan added the comment: __wrapped__ is specifically for the case where the outer function is a relatively straightforward wrapper around the inner one (i.e. those cases where it would be appropriate to use functools.wraps or Graham Dumpleton's more sophisticated wrapt module). More complex decorators and descriptors (like property) will define their own mechanism for accessing the internal details. ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 14:41:07 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jan 2014 13:41:07 +0000 Subject: [issue14455] plistlib unable to read json and binary plist files In-Reply-To: <1389792061.85.0.772622569527.issue14455@psf.upfronthosting.co.za> Message-ID: <10968208.iVZtreeuru@raxxla> Serhiy Storchaka added the comment: > However, I have no idea how to write that file using Apple's APIs. Look in CFBinaryPList.c. It have a code for creating 128-bit integers: CFSInt128Struct val; val.high = 0; val.low = bigint; *plist = CFNumberCreate(allocator, kCFNumberSInt128Type, &val); And I suppose that you have at least one way to create such file -- just convert plist file in XML format to binary format. > Keep in mind that this module is intended for interop with Apple's data > format. Apple's tool can read and write integers from 2**63 to 2**64-1. Here is a patch against current sources. ---------- Added file: http://bugs.python.org/file33481/plistlib_big_ints.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 1a8149ba3000 Doc/library/plistlib.rst --- a/Doc/library/plistlib.rst Wed Jan 15 11:32:35 2014 +0100 +++ b/Doc/library/plistlib.rst Wed Jan 15 15:22:29 2014 +0200 @@ -107,13 +107,6 @@ An :exc:`OverflowError` will be raised for integer values that cannot be represented in (binary) plist files. - .. warning:: - - For compatibility with Apple's libraries it is possible to write - an integer in the range from 2 ** 63 upto (and including) 2 ** 64 - to binary plists, even though these will be read back as negative - values. - .. versionadded: 3.4 diff -r 1a8149ba3000 Lib/plistlib.py --- a/Lib/plistlib.py Wed Jan 15 11:32:35 2014 +0100 +++ b/Lib/plistlib.py Wed Jan 15 15:22:29 2014 +0200 @@ -879,18 +879,19 @@ try: self._fp.write(struct.pack('>Bq', 0x13, value)) except struct.error: - raise OverflowError(value) + raise OverflowError(value) from None elif value < 1 << 8: self._fp.write(struct.pack('>BB', 0x10, value)) elif value < 1 << 16: self._fp.write(struct.pack('>BH', 0x11, value)) elif value < 1 << 32: self._fp.write(struct.pack('>BL', 0x12, value)) + elif value < 1 << 63: + self._fp.write(struct.pack('>Bq', 0x13, value)) + elif value < 1 << 64: + self._fp.write(b'\x14' + value.to_bytes(16, 'big', signed=True)) else: - try: - self._fp.write(struct.pack('>BQ', 0x13, value)) - except struct.error: - raise OverflowError(value) + raise OverflowError(value) elif isinstance(value, float): self._fp.write(struct.pack('>Bd', 0x23, value)) diff -r 1a8149ba3000 Lib/test/test_plistlib.py --- a/Lib/test/test_plistlib.py Wed Jan 15 11:32:35 2014 +0100 +++ b/Lib/test/test_plistlib.py Wed Jan 15 15:22:29 2014 +0200 @@ -152,7 +152,7 @@ def test_int(self): for pl in [0, 2**8-1, 2**8, 2**16-1, 2**16, 2**32-1, 2**32, - 2**63-1, 1, -2**63]: + 2**63-1, 2**64-1, 1, -2**63]: for fmt in ALL_FORMATS: with self.subTest(pl=pl, fmt=fmt): data = plistlib.dumps(pl, fmt=fmt) @@ -163,7 +163,7 @@ self.assertEqual(data, data2) for fmt in ALL_FORMATS: - for pl in (2 ** 64 + 1, 2 ** 127-1, -2**64, -2 ** 127): + for pl in (2**64, 2**127-1, -2**63-1, -2**127): with self.subTest(pl=pl, fmt=fmt): self.assertRaises(OverflowError, plistlib.dumps, pl, fmt=fmt) From report at bugs.python.org Wed Jan 15 14:46:40 2014 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 15 Jan 2014 13:46:40 +0000 Subject: [issue14455] plistlib unable to read json and binary plist files In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za> Message-ID: <1389793600.52.0.115055419439.issue14455@psf.upfronthosting.co.za> Ronald Oussoren added the comment: kCFNumberSInt128Type is not public API, see the list of number types in . I agree that CFBinaryPlist.c contains support for those, and for writing binary plists that contain sets, but you cannot create a 128 bit CFNumber object using a public API, and the public API for writing plists won't accept data structures containing sets. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 15:12:25 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jan 2014 14:12:25 +0000 Subject: [issue14455] plistlib unable to read json and binary plist files In-Reply-To: <1389793600.52.0.115055419439.issue14455@psf.upfronthosting.co.za> Message-ID: <2217060.ESc1ZQ1PCd@raxxla> Serhiy Storchaka added the comment: You have at least one way to create a 128 bit CFNumber. Read plist file (and you can create plist in XML format with big integers in any text editor). In any case it is not good to produce incorrect plist for big integers. If you don't want to support integers over 2**63, just reject them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 15:40:36 2014 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 15 Jan 2014 14:40:36 +0000 Subject: [issue14455] plistlib unable to read json and binary plist files In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za> Message-ID: <1389796836.79.0.0324549758779.issue14455@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Reopening because Cocoa behaves differently that I had noticed earlier... The (Objective-C) code below serialises an NSDictionary with an unsigned long of value ULLONG_MAX and then reads it back. I had expected that restored value contained a negative number, but it actually reads back the correct value. I'm going to do some more spelunking to find out what's going on here, and will adjust the plistlib code to fully represent all values of unsigned 64-bit integers (likely based on your code for supporting 128-bit integers) Output (on a 64-bit system running OSX 10.9): $ ./demo 2014-01-15 15:34:18.196 demo[77580:507] input dictionary: { key = 18446744073709551615; } value 18446744073709551615 2014-01-15 15:34:18.198 demo[77580:507] as binary plist: <62706c69 73743030 d1010253 6b657914 00000000 00000000 ffffffff ffffffff 080b0f00 00000000 00010100 00000000 00000300 00000000 00000000 00000000 000020> 2014-01-15 15:34:18.198 demo[77580:507] Restored as { key = 18446744073709551615; } Code: /* * To use: * $ cc -o demo demo.c -framework Cocoa * $ ./demo */ #import int main(void) { NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init]; NSNumber* value = [NSNumber numberWithUnsignedLongLong:ULLONG_MAX]; NSDictionary* dict = [NSDictionary dictionaryWithObjectsAndKeys:value, @"key", nil]; NSLog(@"input dictionary: %@ value %llu", dict, ULLONG_MAX); NSData* serialized = [NSPropertyListSerialization dataWithPropertyList:dict format: NSPropertyListBinaryFormat_v1_0 options: 0 error: nil]; NSLog(@"as binary plist: %@", serialized); NSDictionary* restored = [NSPropertyListSerialization propertyListWithData:serialized options:0 format:nil error:nil]; NSLog(@"Restored as %@", restored); return 0; } ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 16:00:59 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 15 Jan 2014 15:00:59 +0000 Subject: [issue16251] pickle special methods are looked up on the instance rather than the type In-Reply-To: <1350411894.01.0.763638555345.issue16251@psf.upfronthosting.co.za> Message-ID: <1389798059.79.0.213814810325.issue16251@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 16:05:33 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jan 2014 15:05:33 +0000 Subject: [issue14455] plistlib unable to read json and binary plist files In-Reply-To: <1389796836.79.0.0324549758779.issue14455@psf.upfronthosting.co.za> Message-ID: <3212565.CkgezbnLi5@raxxla> Serhiy Storchaka added the comment: > I'm going to do some more spelunking to find out what's going on here, and > will adjust the plistlib code to fully represent all values of unsigned > 64-bit integers (likely based on your code for supporting 128-bit integers) My last patch supports only values up to 2**64-1. Perhaps you will want to add new test case in Mac/Tools/plistlib_generate_testdata.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 16:06:37 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 15 Jan 2014 15:06:37 +0000 Subject: [issue20261] Cannot pickle some objects that have a __getattr__() In-Reply-To: <1389728767.16.0.141259686696.issue20261@psf.upfronthosting.co.za> Message-ID: <1389798397.81.0.549939592011.issue20261@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I'll go ahead and dupe this to 16251, but will note the __getnewargs__() regression in 3.4. ---------- superseder: -> pickle special methods are looked up on the instance rather than the type _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 16:08:05 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 15 Jan 2014 15:08:05 +0000 Subject: [issue16251] pickle special methods are looked up on the instance rather than the type In-Reply-To: <1350411894.01.0.763638555345.issue16251@psf.upfronthosting.co.za> Message-ID: <1389798485.04.0.459619340257.issue16251@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I ran into this recently while porting nose to 3.4. I duped http://bugs.python.org/issue20261 to this issue, but note that in http://bugs.python.org/issue20261#msg208109 I notice that the presence or absence of __getnewargs__() regresses the specific behavior in Python 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 16:08:57 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jan 2014 15:08:57 +0000 Subject: [issue19804] test_uuid.TestUUID.test_find_mac() fails In-Reply-To: <1385521168.13.0.486814911092.issue19804@psf.upfronthosting.co.za> Message-ID: <1389798537.62.0.622571792839.issue19804@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 16:12:29 2014 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 15 Jan 2014 15:12:29 +0000 Subject: [issue14031] logging module cannot format str.format log messages In-Reply-To: <1329405649.45.0.0231002086589.issue14031@psf.upfronthosting.co.za> Message-ID: <1389798749.89.0.0622898806788.issue14031@psf.upfronthosting.co.za> Vinay Sajip added the comment: Cookbook updated. See changesets 7c4f0c3dedaf and 0056aaf42bf7 for more information - docs.python.org should update within a day. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 16:24:43 2014 From: report at bugs.python.org (Laurento Frittella) Date: Wed, 15 Jan 2014 15:24:43 +0000 Subject: [issue14044] IncompleteRead error with urllib2 or urllib.request -- fine with urllib, wget, or curl In-Reply-To: <1329500177.48.0.42118882394.issue14044@psf.upfronthosting.co.za> Message-ID: <1389799483.26.0.101973293532.issue14044@psf.upfronthosting.co.za> Laurento Frittella added the comment: I had the same problem using urllib2 and the following trick worked for me import httplib httplib.HTTPConnection._http_vsn = 10 httplib.HTTPConnection._http_vsn_str = 'HTTP/1.0' Source: http://stackoverflow.com/a/20645845 ---------- nosy: +laurento.frittella _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 16:28:34 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jan 2014 15:28:34 +0000 Subject: [issue14044] IncompleteRead error with urllib2 or urllib.request -- fine with urllib, wget, or curl In-Reply-To: <1329500177.48.0.42118882394.issue14044@psf.upfronthosting.co.za> Message-ID: <1389799714.35.0.971683717707.issue14044@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka type: -> behavior versions: +Python 3.3, Python 3.4 -Python 2.6, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 16:42:54 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 15 Jan 2014 15:42:54 +0000 Subject: [issue20187] The Great Argument Clinic Conversion Derby Meta-Issue In-Reply-To: <1389141105.5.0.459903580868.issue20187@psf.upfronthosting.co.za> Message-ID: <1389800574.67.0.877955257761.issue20187@psf.upfronthosting.co.za> Larry Hastings added the comment: Can you give me an example of performance degradation due to Argument Clinic? What percentage slowdown is common? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 17:07:32 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jan 2014 16:07:32 +0000 Subject: [issue20187] The Great Argument Clinic Conversion Derby Meta-Issue In-Reply-To: <1389800574.67.0.877955257761.issue20187@psf.upfronthosting.co.za> Message-ID: <69515055.61AGj1rDs4@raxxla> Serhiy Storchaka added the comment: I have no any numbers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 17:10:14 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 15 Jan 2014 16:10:14 +0000 Subject: [issue20187] The Great Argument Clinic Conversion Derby Meta-Issue In-Reply-To: <1389141105.5.0.459903580868.issue20187@psf.upfronthosting.co.za> Message-ID: <1389802214.38.0.177775338443.issue20187@psf.upfronthosting.co.za> Larry Hastings added the comment: Until you have some numbers, your assertion has no weight and should be ignored. (As Carl Sagan once wrote: "That which can be asserted without evidence can be dismissed without evidence." And as Donald Knuth wrote: "Premature optimization is the root of all evil.") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 17:10:36 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jan 2014 16:10:36 +0000 Subject: [issue20262] Convert some debugging prints in zipfile to warnings In-Reply-To: <1389732995.51.0.822070396354.issue20262@psf.upfronthosting.co.za> Message-ID: <1389802236.79.0.328839844742.issue20262@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm not sure. This is why I had added Larry and Georg to nosy list. This issue looks in a half-way between fixing a bug and adding new feature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 17:51:27 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 15 Jan 2014 16:51:27 +0000 Subject: [issue20260] Argument Clinic: add unsigned integers converters In-Reply-To: <1389720718.78.0.860738296491.issue20260@psf.upfronthosting.co.za> Message-ID: <1389804687.54.0.308646681348.issue20260@psf.upfronthosting.co.za> Larry Hastings added the comment: We can use this now. So I bumped it to the top of my queue and reviewed it. I had only minor feedback--thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 17:52:12 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 15 Jan 2014 16:52:12 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? In-Reply-To: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> Message-ID: <1389804732.43.0.1804770681.issue20226@psf.upfronthosting.co.za> Zachary Ware added the comment: Just confirmed that this patch fixes the traceback I was getting from winreg in #20172, but this has a new oddity: >>> help(winreg) ... ConnectRegistry(computer_name=, key=) ... Every param of every function has this kind of thing, positional or keyword, default or no. I'll try to look into it, but my hopes aren't high (much of clinic's inner workings are still mysterious to me). ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 17:53:23 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 15 Jan 2014 16:53:23 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? In-Reply-To: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> Message-ID: <1389804803.94.0.74999918644.issue20226@psf.upfronthosting.co.za> Larry Hastings added the comment: That's okay, email me a sample at larry at hastings dot org and I'll take a look at it. Be sure to tell me which patch(es) were applied at the time. (Note: all you need to send is the Clinic block.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 17:56:49 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jan 2014 16:56:49 +0000 Subject: [issue15858] tarfile missing entries due to omitted uid/gid fields In-Reply-To: <1346701660.86.0.976031645545.issue15858@psf.upfronthosting.co.za> Message-ID: <1389805009.26.0.538981230154.issue15858@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> test needed versions: +Python 2.7, Python 3.3, Python 3.4 -3rd party, Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 17:57:52 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jan 2014 16:57:52 +0000 Subject: [issue19974] tarfile doesn't overwrite symlink by directory In-Reply-To: <1386935948.7.0.893963676407.issue19974@psf.upfronthosting.co.za> Message-ID: <1389805072.57.0.960881060759.issue19974@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 17:59:18 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jan 2014 16:59:18 +0000 Subject: [issue19974] tarfile doesn't overwrite symlink by directory In-Reply-To: <1386935948.7.0.893963676407.issue19974@psf.upfronthosting.co.za> Message-ID: <1389805158.86.0.618164465608.issue19974@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 18:00:28 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 15 Jan 2014 17:00:28 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? In-Reply-To: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> Message-ID: <1389805228.4.0.0145700013954.issue20226@psf.upfronthosting.co.za> Zachary Ware added the comment: Actually, I can reproduce on tip with just this patch applied; os.chmod shows it. And I was wrong, params that have a default are correct, it's just ones without. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 18:02:51 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 15 Jan 2014 17:02:51 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? In-Reply-To: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> Message-ID: <1389805371.15.0.00851616779313.issue20226@psf.upfronthosting.co.za> Larry Hastings added the comment: I'd prefer it if you emailed me as I asked. That will help me get to it a lot quicker. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 19:07:09 2014 From: report at bugs.python.org (Fran Bull) Date: Wed, 15 Jan 2014 18:07:09 +0000 Subject: [issue20241] Bad reference to RFC in document of ipaddress? In-Reply-To: <1389626719.4.0.511378840941.issue20241@psf.upfronthosting.co.za> Message-ID: <1389809229.03.0.641144594368.issue20241@psf.upfronthosting.co.za> Fran Bull added the comment: http://tools.ietf.org/html/rfc5735.html Special Use IPv4 Addresses does indeed agree with the docstring @property def is_unspecified(self): """Test if the address is unspecified. Returns: A boolean, True if this is the unspecified address as defined in RFC 5735 3. """ unspecified_address = IPv4Address('0.0.0.0') return self == unspecified_address and makes more sense than http://tools.ietf.org/html/rfc5375.html IPv6 Unicast Address Assignment Considerations and so the attached patch will bring them into line. However it's worth noting that the RFC doesn't say anything about 0.0.0.0 being the 'unspecified' address, (the RFC linked for the IPv6 is_unspecified http://tools.ietf.org/html/rfc2373.html#section-2.5.2 does specifically call it the 'unspecified' address). 5735 3 just says: 3. Global and Other Specialized Address Blocks 0.0.0.0/8 - Addresses in this block refer to source hosts on "this" network. Address 0.0.0.0/32 may be used as a source address for this host on this network; other addresses within 0.0.0.0/8 may be used to refer to specified hosts on this network ([RFC1122], Section 3.2.1.3). googling it you can find eg this: http://en.wikipedia.org/wiki/IPv6_address says: ::/128 ? The address with all zero bits is called the unspecified address (corresponding to 0.0.0.0/32 in IPv4). so perhaps this bit of the docs could be a bit clearer, although I don't know what it should say, perhaps something like: 'Checks if the address is 0.0.0.0 which corresponds to the unspecified address in IPv6' someone with better networking knowledge than me could say. ---------- keywords: +patch nosy: +Fran.Bull Added file: http://bugs.python.org/file33482/20241.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 19:59:40 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jan 2014 18:59:40 +0000 Subject: [issue20260] Argument Clinic: add unsigned integers converters In-Reply-To: <1389720718.78.0.860738296491.issue20260@psf.upfronthosting.co.za> Message-ID: <1389812380.95.0.952496699363.issue20260@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Unfortunately I have discovered that there is significant difference between uint_converter in Modules/zlibmodule.c and proposed _PyLong_UnsignedInt_Converter. And there are tests in Lib/test/test_zlib.py which fail when _PyLong_UnsignedInt_Converter is used instead of uint_converter. uint_converter raises ValueError for negative integers, and _PyLong_UnsignedInt_Converter raises OverflowError. Possible solutions: 1. Change tests. I don't like this, ValueError looks reasonable for these cases. 2. Continue to use uint_converter in Modules/zlibmodule.c. Then new converters become less useful. 3. Raise ValueError in new converters for negative integers. ValueError looks reasonable in many cases. 4. Raise ValueError in PyLong_AsUnsignedLong etc for negative integers. Here is a patch which incorporates Larry's suggestions and implements option #3. ---------- nosy: +mark.dickinson, skrah Added file: http://bugs.python.org/file33483/clinic_unsigned_converters.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 20:00:43 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jan 2014 19:00:43 +0000 Subject: [issue20260] Argument Clinic: add unsigned integers converters In-Reply-To: <1389720718.78.0.860738296491.issue20260@psf.upfronthosting.co.za> Message-ID: <1389812443.79.0.827701569872.issue20260@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, and of course 5th option: do nothing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 20:00:46 2014 From: report at bugs.python.org (Georg Brandl) Date: Wed, 15 Jan 2014 19:00:46 +0000 Subject: [issue20262] Convert some debugging prints in zipfile to warnings In-Reply-To: <1389732995.51.0.822070396354.issue20262@psf.upfronthosting.co.za> Message-ID: <1389812446.79.0.613632369191.issue20262@psf.upfronthosting.co.za> Georg Brandl added the comment: I'm actually more on the "fixing a bug" side. For me this is fine for 3.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 20:58:37 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 15 Jan 2014 19:58:37 +0000 Subject: [issue20232] Argument Clinic NULL default falsely implies None acceptability In-Reply-To: <1389581598.8.0.840632015553.issue20232@psf.upfronthosting.co.za> Message-ID: <1389815917.36.0.457158166891.issue20232@psf.upfronthosting.co.za> Larry Hastings added the comment: One mandate I've given myself for this project: When a function provides a signature, it must be 100% accurate. A specific corollary of this: If you call a function, and for every optional parameter you explicitly pass it in with its default value from the signature, the result will be identical with calling the function and not providing that optional parameter. So we can't lie here. You're right that this is a general problem. It's possible for a C function to accept a parameter that is * positional-or-keyword, * has a default value, and * the default value is not publishable as a Python value. This is impossible in Python. But Clinic only allows you to represent Python-compatible signatures. In this *specific* case we can dodge the bullet: /*[clinic input] SHA1.SHA1 string: object(c_default='NULL') = b'' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 20:59:37 2014 From: report at bugs.python.org (SilentGhost) Date: Wed, 15 Jan 2014 19:59:37 +0000 Subject: [issue20272] chain.from_iterable in the overview table not linking to the function Message-ID: <1389815977.04.0.427053880301.issue20272@psf.upfronthosting.co.za> New submission from SilentGhost: chain.from_iterable is not linkified in the overview table at the top of the itertools docs. The patch requires reformat of the table. ---------- assignee: docs at python components: Documentation files: linkify.diff keywords: patch messages: 208184 nosy: SilentGhost, docs at python, rhettinger priority: normal severity: normal stage: patch review status: open title: chain.from_iterable in the overview table not linking to the function versions: Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file33484/linkify.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 21:00:45 2014 From: report at bugs.python.org (SilentGhost) Date: Wed, 15 Jan 2014 20:00:45 +0000 Subject: [issue20272] chain.from_iterable in the overview table not linking to the function In-Reply-To: <1389815977.04.0.427053880301.issue20272@psf.upfronthosting.co.za> Message-ID: <1389816045.91.0.233960490723.issue20272@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 21:06:01 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 15 Jan 2014 20:06:01 +0000 Subject: [issue20231] Argument Clinic accepts no-default args after default args In-Reply-To: <1389580315.91.0.810075963733.issue20231@psf.upfronthosting.co.za> Message-ID: <1389816361.61.0.391377030037.issue20231@psf.upfronthosting.co.za> Larry Hastings added the comment: I'll fix this, but it's lower priority than the new features for Clinic that people need in order to get unblocked. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 21:08:51 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 15 Jan 2014 20:08:51 +0000 Subject: [issue20178] Derby #9: Convert 52 sites to Argument Clinic across 11 files In-Reply-To: <1389140078.91.0.720761635456.issue20178@psf.upfronthosting.co.za> Message-ID: <1389816531.89.0.233634306249.issue20178@psf.upfronthosting.co.za> Larry Hastings added the comment: In the past few days I added "cloning" functions, which lets you reuse the parameters and return converter from an existing function. That might help with Modules/_ctypes/_ctypes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 21:10:56 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 15 Jan 2014 20:10:56 +0000 Subject: [issue20178] Derby #9: Convert 52 sites to Argument Clinic across 11 files In-Reply-To: <1389140078.91.0.720761635456.issue20178@psf.upfronthosting.co.za> Message-ID: <1389816656.71.0.352496302857.issue20178@psf.upfronthosting.co.za> Larry Hastings added the comment: All the functions in curses_panel are convertable. The threeMETH_NOARGS functions simply get no arguments. And here's new_panel: new_panel window: object(subclass_of='&PyCursesWindow_Type') / ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 21:17:32 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jan 2014 20:17:32 +0000 Subject: [issue20273] Argument Clinic: unhelpful crashes Message-ID: <1389817052.38.0.962470958288.issue20273@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Sometimes when Argument Clinic see something wrong, it raises exception and exit with printed traceback, instead of output helpful error message which points on line with illegal syntax. I open this issue to report about such problems. $ ./python Tools/clinic/clinic.py -f Modules/zlibmodule.c Traceback (most recent call last): File "Tools/clinic/clinic.py", line 3032, in sys.exit(main(sys.argv[1:])) File "Tools/clinic/clinic.py", line 3028, in main parse_file(filename, output=ns.output, verify=not ns.force) File "Tools/clinic/clinic.py", line 1135, in parse_file cooked = clinic.parse(raw) File "Tools/clinic/clinic.py", line 1085, in parse parser.parse(block) File "Tools/clinic/clinic.py", line 2262, in parse self.state(line) File "Tools/clinic/clinic.py", line 2582, in state_parameter value = eval(py_default) File "", line 1, in NameError: name 'zlib' is not defined zlibmodule.c is almost same as after applying patch from issue20193 (with several clinic bugs already fixed). ---------- components: Demos and Tools messages: 208188 nosy: larry, serhiy.storchaka priority: normal severity: normal status: open title: Argument Clinic: unhelpful crashes type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 21:24:43 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 15 Jan 2014 20:24:43 +0000 Subject: [issue20274] sqlite module has bad argument parsing code, including undefined behavior in C Message-ID: <1389817483.8.0.407525727046.issue20274@psf.upfronthosting.co.za> New submission from Larry Hastings: The code in Modules/_sqlite/connection.c is sloppy. The functions pysqlite_connection_execute, pysqlite_connection_executemany, and pysqlite_connection_executescript accept a third "PyObject *kwargs". However none of these functions are marked METH_KEYWORD. This only works because the kwargs parameter is actually ignored--the functions only support positional-only arguments. Obviously the "PyObject *kwargs" parameters should be removed for these three functions. A slightly more advanced problem: pysqlite_connection_call, which implements sqlite3.Connection.__call__(), ignores its kwargs parameter completely. If it doesn't accept keyword parameters it should at least complain if any are passed in. Georg: you want this fixed in 3.3? 3.2? Benjamin: you want this fixed in 2.7? ---------- messages: 208189 nosy: benjamin.peterson, georg.brandl, larry priority: normal severity: normal stage: needs patch status: open title: sqlite module has bad argument parsing code, including undefined behavior in C type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 21:25:43 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jan 2014 20:25:43 +0000 Subject: [issue20273] Argument Clinic: unhelpful crashes In-Reply-To: <1389817052.38.0.962470958288.issue20273@psf.upfronthosting.co.za> Message-ID: <1389817543.06.0.138209349927.issue20273@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I suppose this crash is caused by this code: /*[clinic input] zlib.Compress.flush self: self(type="compobject *") mode: int(c_default="Z_FINISH") = zlib.Z_FINISH One of the constants Z_SYNC_FLUSH, Z_FULL_FLUSH, Z_FINISH. If mode == Z_FINISH, the compressor object can no longer be used after calling the flush() method. Otherwise, more data can still be compressed. / Return a bytes object containing any remaining compressed data. [clinic start generated code]*/ It was valid several days ago. Therefore here are two bugs: 1. Argument Clinic should output a line number where it has encountered illegal expression. 2. It should accept zlib.Z_FINISH (Z_FINISH is exported constant in the zlib module). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 21:26:18 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jan 2014 20:26:18 +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: <1389817578.93.0.624206967087.issue20274@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 21:35:18 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 15 Jan 2014 20:35:18 +0000 Subject: [issue8876] distutils should not assume that hardlinks will work In-Reply-To: <1275485916.86.0.44676570948.issue8876@psf.upfronthosting.co.za> Message-ID: <1389818118.75.0.72202595969.issue8876@psf.upfronthosting.co.za> Larry Hastings added the comment: Has this been fixed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 21:40:13 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 15 Jan 2014 20:40:13 +0000 Subject: [issue20273] Argument Clinic: unhelpful crashes In-Reply-To: <1389817052.38.0.962470958288.issue20273@psf.upfronthosting.co.za> Message-ID: <1389818413.98.0.885220099425.issue20273@psf.upfronthosting.co.za> Larry Hastings added the comment: I'm marking this as a duplicate of #20226, the "add general-purpose expressions" issue, because that will fix the behavior you're seeing. As for "in general Argument Clinic should have better error reporting", this is too general for an issue right now. In the future feel free to file issues for specific badly-phrased errors. ---------- assignee: -> larry resolution: -> duplicate stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 21:44:48 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 15 Jan 2014 20:44:48 +0000 Subject: [issue20273] Argument Clinic: unhelpful crashes In-Reply-To: <1389817052.38.0.962470958288.issue20273@psf.upfronthosting.co.za> Message-ID: <1389818688.11.0.418394066226.issue20273@psf.upfronthosting.co.za> Zachary Ware added the comment: Georg already opened an issue with a patch about providing a little more information in unexpected exceptions, see issue20235. ---------- nosy: +zach.ware superseder: -> Argument Clinic: support for simple expressions? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 21:47:31 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jan 2014 20:47:31 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1389818851.2.0.877313709318.issue20193@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Argument Clinic: support for simple expressions? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 21:49:50 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jan 2014 20:49:50 +0000 Subject: [issue20235] Argument Clinic: recover a bit more gracefully from exceptions In-Reply-To: <1389596547.42.0.103155756972.issue20235@psf.upfronthosting.co.za> Message-ID: <1389818990.91.0.712605151342.issue20235@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 21:50:16 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jan 2014 20:50:16 +0000 Subject: [issue20273] Argument Clinic: unhelpful crashes In-Reply-To: <1389817052.38.0.962470958288.issue20273@psf.upfronthosting.co.za> Message-ID: <1389819015.99.0.224858930284.issue20273@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Zachary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 21:54:02 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jan 2014 20:54:02 +0000 Subject: [issue20235] Argument Clinic: recover a bit more gracefully from exceptions In-Reply-To: <1389596547.42.0.103155756972.issue20235@psf.upfronthosting.co.za> Message-ID: <1389819242.12.0.199268138823.issue20235@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. This patch helps me (issue20273). Thank you. ---------- components: +Demos and Tools stage: -> commit review type: -> enhancement versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 22:18:36 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 15 Jan 2014 21:18:36 +0000 Subject: [issue20235] Argument Clinic: recover a bit more gracefully from exceptions In-Reply-To: <1389596547.42.0.103155756972.issue20235@psf.upfronthosting.co.za> Message-ID: <1389820716.11.0.0806793304038.issue20235@psf.upfronthosting.co.za> Larry Hastings added the comment: LGTM, please commit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 22:50:46 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 15 Jan 2014 21:50:46 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1389822646.38.0.628186561967.issue20172@psf.upfronthosting.co.za> Zachary Ware added the comment: About cloning: Cloned functions still expect their own impl function. In current winreg, OpenKey and OpenKeyEx literally are the same function by two names; is the best approach for this to define winreg_OpenKeyEx_impl as `return winreg_OpenKey_impl(module, key, sub_key, reserved, access);`? As stated in #20226, that patch works fine with my conversions. Once the 20226 patch lands, I'll get a comprehensive patch for this issue posted. Until then, I've branched the sandbox repo yet again; future_clinic_20172 contains the 20226 patch, along with the necessary updates to these files and further changes using the new features that aren't in trunk yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 23:11:04 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 15 Jan 2014 22:11:04 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop Message-ID: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> New submission from Yury Selivanov: Can we remove debug timing around "self._selector.select(timeout)" (or at least make it configurable) from BaseEventLoop? Right now the code is: # TODO: Instrumentation only in debug mode? t0 = self.time() event_list = self._selector.select(timeout) t1 = self.time() argstr = '' if timeout is None else ' {:.3f}'.format(timeout) if t1-t0 >= 1: level = logging.INFO else: level = logging.DEBUG logger.log(level, 'poll%s took %.3f seconds', argstr, t1-t0) So it makes two 'time.time()' calls per loop iteration, plus one "logging.log" call. The only non-intrusive solution that I can suggest is to add a class attribute '_debug' to BaseEventLoop, set to False by default (unittests can set it to True in their setUp methods). ---------- components: Library (Lib) messages: 208199 nosy: gvanrossum, pitrou, yselivanov priority: normal severity: normal status: open title: asyncio: remove debug code from BaseEventLoop type: performance versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 23:11:33 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 15 Jan 2014 22:11:33 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389823893.67.0.436685678736.issue20275@psf.upfronthosting.co.za> Yury Selivanov added the comment: And I'd be happy to help with the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 23:12:20 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 15 Jan 2014 22:12:20 +0000 Subject: [issue20260] Argument Clinic: add unsigned integers converters In-Reply-To: <1389812380.95.0.952496699363.issue20260@psf.upfronthosting.co.za> Message-ID: <20140115221219.GA26181@sleipnir.bytereef.org> Stefan Krah added the comment: I think we cannot change PyLong_AsUnsignedLong() without a deprecation period, if at all. That leaves the option of changing the converters. My preference is to raise either OverflowError or ValueError for *both* out-of-range conditions. People may me used to OverflowError by now -- the usage in PyLong_AsUnsignedLong() dates back to very early revisions -- but there are equally good reasons to use ValueError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 23:17:40 2014 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 15 Jan 2014 22:17:40 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389824260.92.0.939798153436.issue20275@psf.upfronthosting.co.za> Guido van Rossum added the comment: What part of the debug timing is more expensive than the select call itself? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 23:19:24 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Jan 2014 22:19:24 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389824364.6.0.420823504568.issue20275@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm also in favor of removing this code, or a debug flag to enable it. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 23:21:25 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 15 Jan 2014 22:21:25 +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: <1389824485.05.0.203113848398.issue20274@psf.upfronthosting.co.za> R. David Murray added the comment: Why do you want to fix it in order versions? Can it lead to a crash? For __call__, it seems to me we should do a deprecation and remove it in 3.5. Otherwise we'll risk breaking working code for no good reason (working code with useless parameters, but still working code :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 23:23:17 2014 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 15 Jan 2014 22:23:17 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389824364.6.0.420823504568.issue20275@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Can you check for the level of the logger? That would work for me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 23:24:03 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 15 Jan 2014 22:24:03 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389824643.19.0.865228854473.issue20275@psf.upfronthosting.co.za> Yury Selivanov added the comment: > What part of the debug timing is more expensive than the select call itself? Well, there is nothing really expensive there, but: - time.monotonic() is still a syscall - logging.log executes a fair amount of code too ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 23:29:22 2014 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 15 Jan 2014 22:29:22 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389824643.19.0.865228854473.issue20275@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: So you admit you just want to optimize prematurely? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 23:38:17 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Jan 2014 22:38:17 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389825497.14.0.755858836795.issue20275@psf.upfronthosting.co.za> STINNER Victor added the comment: > So you admit you just want to optimize prematurely? I don't understand the purpose of these timing information, I don't use them. I would be more interested to know which functions take longer than XXX ms and so hangs the event loop. By the way, it's not documentation how to enable asyncio logs: http://docs.python.org/dev/library/asyncio.html The asyncio logger is not documented. I would like to add a section listing development tools like asyncio.tasks._DEBUG=True and the "Future/Task exception was never retrieved" log. Hum, it looks like asyncio.futures.STACK_DEBUG is not used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 23:39:04 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 15 Jan 2014 22:39:04 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389825544.78.0.646968517061.issue20275@psf.upfronthosting.co.za> Yury Selivanov added the comment: I wrote a small micro-benchmark, that creates 100K tasks and executes them. With debug code the execution time is around 2.8-3.1s, with debug comment commented out it's around 2.3-2.4s. Again, it's a micro-benchmark, and in a real application the impact is going to be much smaller. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 15 23:40:12 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 15 Jan 2014 22:40:12 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389825612.2.0.207055867586.issue20275@psf.upfronthosting.co.za> Yury Selivanov added the comment: The micro-benchmark i used is here: https://gist.github.com/1st1/8446175 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 00:00:24 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Jan 2014 23:00:24 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389826824.65.0.0105889429075.issue20275@psf.upfronthosting.co.za> STINNER Victor added the comment: > With debug code the execution time is around 2.8-3.1s, with debug comment commented out it's around 2.3-2.4s. Wow, that's impressive that such minor syscalls can take so much times! I modified your script to repeat the test 5 times and take the minimum timing: * Python 3.4 original: 3.83 seconds * asyncio without timing log: 2.79 seconds (27% faster) 27% faster is not a "premature" optimisation :-) By the way, Linux provides faster clocks like CLOCK_MONOTONIC_COARSE: A faster but less precise version of CLOCK_MONOTONIC. Use when you need very fast, but not fine-grained time? stamps. Python doesn't expose these clock identifiers yet: #14555. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 00:03:24 2014 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 15 Jan 2014 23:03:24 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389827004.44.0.44499717919.issue20275@psf.upfronthosting.co.za> Guido van Rossum added the comment: I have definitely used this log message. It typically tells me that something is responding too slow. Regarding the microbench, please count and report how many times it actually calls select(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 00:09:16 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 15 Jan 2014 23:09:16 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389827356.33.0.0293250005561.issue20275@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Wow, that's impressive that such minor syscalls can take so much times! Apparently, it's not syscalls, it's logging. Actually, with commented out "logging.log" code I can't see a difference wether there are calls to monotonic or not. So we can keep the code as is, let's just log something when select takes longer than 1 second (and log nothing when it's faster) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 00:12:53 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Jan 2014 23:12:53 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389827573.52.0.935682627478.issue20275@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- keywords: +patch Added file: http://bugs.python.org/file33485/debug_flag.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 00:16:06 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Jan 2014 23:16:06 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389827766.09.0.239508574665.issue20275@psf.upfronthosting.co.za> STINNER Victor added the comment: Here are two patches: - logger_is_enabled_for.patch: use logger.isEnabledFor(INFO) to avoid the call - add a _debug flag to BaseEventLoop Benchmark: - original: 3.90 - logger: 3.04 - _debug: 2.81 I like the _debug flag because it's faster, but I'm not sure that an attribute is the best place for the flag. asyncio needs maybe one global debug flag (ex: asyncio._DEBUG=True) replacing the existing asyncio.tasks._DEBUG flag. ---------- Added file: http://bugs.python.org/file33486/logger_is_enabled_for.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 00:16:59 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 15 Jan 2014 23:16:59 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389827819.49.0.991291842812.issue20275@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Regarding the microbench, please count and report how many times it actually calls select(). I'm on MacOS X, so it's KqueueSelector. It's 'select' method (and self._kqueue.control respectively) is called twice more times. So for 100K tasks, select gets called 200K. But that's just the way my benchmark is written. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 00:18:22 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 15 Jan 2014 23:18:22 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389827902.43.0.365914155397.issue20275@psf.upfronthosting.co.za> Yury Selivanov added the comment: Victor, Re your patch: since it's not really time syscalls, and Guido said he's using this debug code, how about we just have something like: t0 = self.time() event_list = self._selector.select(timeout) t1 = self.time() if t1 - t0 >= 1: argstr = '' if timeout is None else ' {:.3f}'.format(timeout) level = logging.INFO logger.log(level, 'poll%s took %.3f seconds', argstr, t1-t0) ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 00:18:35 2014 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 15 Jan 2014 23:18:35 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389827915.07.0.098474798691.issue20275@psf.upfronthosting.co.za> Guido van Rossum added the comment: I like logger_is_enabled_for.patch. If you want to add other debug features please propose something on the Tulip tracker: http://code.google.com/p/tulip/issues/list . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 00:20:11 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 15 Jan 2014 23:20:11 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389828011.09.0.737718352798.issue20275@psf.upfronthosting.co.za> Yury Selivanov added the comment: And, I think that "asyncio._DEBUG" or even "asyncio.DEBUG" would be a great idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 00:22:29 2014 From: report at bugs.python.org (Jakub Wilk) Date: Wed, 15 Jan 2014 23:22:29 +0000 Subject: [issue18373] implement sys.get/setbyteswarningflag() In-Reply-To: <1373065124.82.0.249288626652.issue18373@psf.upfronthosting.co.za> Message-ID: <1389828149.7.0.481518838001.issue18373@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 00:24:02 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 15 Jan 2014 23:24:02 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389828242.28.0.949974592006.issue20275@psf.upfronthosting.co.za> Yury Selivanov added the comment: Victor, Guido, Please take a look at the attached one. I believe it's slightly better, than the "logger_is_enabled_for.patch", since it doesn't log stuff that was faster than 1 second, and is simpler too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 00:24:53 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 15 Jan 2014 23:24:53 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389828293.0.0.427318840314.issue20275@psf.upfronthosting.co.za> Changes by Yury Selivanov : Added file: http://bugs.python.org/file33487/greater_than_1sec_logging.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 00:25:36 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 15 Jan 2014 23:25:36 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389828336.78.0.790239409734.issue20275@psf.upfronthosting.co.za> Changes by Yury Selivanov : Removed file: http://bugs.python.org/file33487/greater_than_1sec_logging.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 00:25:49 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 15 Jan 2014 23:25:49 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389828349.93.0.835893959401.issue20275@psf.upfronthosting.co.za> Changes by Yury Selivanov : Added file: http://bugs.python.org/file33488/greater_than_1sec_logging.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 00:30:25 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Jan 2014 23:30:25 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389828625.67.0.392428710811.issue20275@psf.upfronthosting.co.za> STINNER Victor added the comment: I opened an issue to propose asyncio.DEBUG: BaseEventLoop._run_once() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 00:30:37 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 15 Jan 2014 23:30:37 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389828637.71.0.555205503094.issue20275@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: -pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 00:31:11 2014 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 15 Jan 2014 23:31:11 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389828671.09.0.503354526599.issue20275@psf.upfronthosting.co.za> Guido van Rossum added the comment: I really want to log the time every time if level == DEBUG and only if > 1 sec for other levels, so maybe all you need to do is remove the comment? :-) (Or maybe logger.isEnabledFor(logging.INFO) is faster than logger.log() when nothing gets logged? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 00:33:12 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Jan 2014 23:33:12 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389828792.22.0.512151456383.issue20275@psf.upfronthosting.co.za> STINNER Victor added the comment: I opened an issue to propose asyncio.DEBUG: http://code.google.com/p/tulip/issues/detail?id=104 (woops, copy/paste failure :-)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 00:36:35 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 15 Jan 2014 23:36:35 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389828995.26.0.0552530182187.issue20275@psf.upfronthosting.co.za> Yury Selivanov added the comment: > I really want to log the time every time if level == DEBUG and only if > 1 sec for other levels, so maybe all you need to do is remove the comment? :-) (Or maybe logger.isEnabledFor(logging.INFO) is faster than logger.log() when nothing gets logged? Well, in this case, I think if async.DEBUG is accepted, than Victor can apply his "debug_flag.patch" (with some modifications), and if not, then his "logger_is_enabled_for.patch" would work for you too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 01:06:57 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 16 Jan 2014 00:06:57 +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: <1389830817.33.0.648583550131.issue20274@psf.upfronthosting.co.za> Larry Hastings added the comment: You're right, deprecation sounds best. If Georg or Benjamin want the fix in earlier releases I'll split the pysqlite_connection_call into another issue, otherwise I won't bother. As for fixing the undefined behavior in older versions: since its behavior is undefined, yes, it *could* cause a crash. But by that token it *could* teleport you to Mars and give you a funny-looking nose. In practice it *should* be utterly harmless, as I believe every platform supported by Python 3.4 uses the caller-pops-stack calling convention. And we've lived with it for this long, so it doesn't seem to be hurting anything. But like all undefined behavior I can make no guarantee. MvL in particular comes down like a ton of bricks whenever someone proposes checking in code that's technically undefined behavior. I've had the relevant chapter and verse of the C standard quoted at me for this exact thing (calling a function pointer using a sliiiightly different signature than the actual function). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 01:21:47 2014 From: report at bugs.python.org (Tom Lynn) Date: Thu, 16 Jan 2014 00:21:47 +0000 Subject: [issue15858] tarfile missing entries due to omitted uid/gid fields In-Reply-To: <1346701660.86.0.976031645545.issue15858@psf.upfronthosting.co.za> Message-ID: <1389831707.05.0.214010486944.issue15858@psf.upfronthosting.co.za> Tom Lynn added the comment: The secondary issue, which the patch doesn't address, is that TarFile.next() seems unpythonic; it treats any {Invalid,Empty,Truncated}HeaderError after offset 0 as EOF rather than propagating the exception. It looks deliberate, but I'm not sure why it would be done like that or if it should be changed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 02:20:50 2014 From: report at bugs.python.org (Albert Zeyer) Date: Thu, 16 Jan 2014 01:20:50 +0000 Subject: [issue20276] ctypes._dlopen should not force RTLD_NOW Message-ID: <1389835250.18.0.994187095124.issue20276@psf.upfronthosting.co.za> New submission from Albert Zeyer: On MacOSX, when you build an ARC-enabled Dylib with backward compatibility for e.g. MacOSX 10.6, some unresolved functions like `_objc_retainAutoreleaseReturnValue` might end up in your Dylib. Some reference about the issue: 1. http://stackoverflow.com/q/21119425/133374>. 2. http://osdir.com/ml/python.ctypes/2006-10/msg00029.html 3. https://groups.google.com/forum/#!topic/comp.lang.python/DKmNGwyLl3w Thus, RTLD_NOW is often not an option for MacOSX. This affects mostly `py_dl_open()` from ctypes. But it is also related how you set `dlopenflags` in `PyInterpreterState_New()`. I suggest to make RTLD_LAZY the default on MacOSX (or is there a good reason not to do?). Also, ctypes should have options for both RTLD_NOW and RTLD_LAZY so that both can be used. This is also consistent with the behavior of the [dl module](http://docs.python.org/2/library/dl.html). ---------- components: ctypes messages: 208226 nosy: Albert.Zeyer priority: normal severity: normal status: open title: ctypes._dlopen should not force RTLD_NOW versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 02:28:56 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Jan 2014 01:28:56 +0000 Subject: [issue20276] ctypes._dlopen should not force RTLD_NOW In-Reply-To: <1389835250.18.0.994187095124.issue20276@psf.upfronthosting.co.za> Message-ID: <1389835736.04.0.883496232659.issue20276@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 02:40:20 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Thu, 16 Jan 2014 01:40:20 +0000 Subject: [issue20174] Derby #5: Convert 50 sites to Argument Clinic across 3 files In-Reply-To: <1389138461.92.0.709656306175.issue20174@psf.upfronthosting.co.za> Message-ID: <1389836420.03.0.406642220443.issue20174@psf.upfronthosting.co.za> Ryan Smith-Roberts added the comment: Forgot to linewrap a paragraph. ---------- Added file: http://bugs.python.org/file33489/argument_clinic_socketmodule_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 03:25:15 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 16 Jan 2014 02:25:15 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389839115.89.0.620849283614.issue20189@psf.upfronthosting.co.za> Larry Hastings added the comment: Nick, could you maybe review this? ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 03:36:07 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 16 Jan 2014 02:36:07 +0000 Subject: [issue20260] Argument Clinic: add unsigned integers converters In-Reply-To: <1389720718.78.0.860738296491.issue20260@psf.upfronthosting.co.za> Message-ID: <1389839767.37.0.7190810646.issue20260@psf.upfronthosting.co.za> Larry Hastings added the comment: I'm glad you caught that! First things first: the converted code should behave identically to the existing code, including raising the same exceptions. If you examine the exception hierarchy: http://docs.python.org/3.4/library/exceptions.html#exception-hierarchy you'll see that "OverflowError" is a subclass of "ArithmeticError". In other words, it represents when you perform an arithmetic operation that overflows the result type. Using it to also represent "you specified a value that is out of range for this conversion" seems wrong. So I like #3 as well. Could _PyLong_UnsignedInt_Converter catch the OverflowError raised by PyLong_AsUnsignedLong and reraise it as ValueError? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 03:46:37 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 16 Jan 2014 02:46:37 +0000 Subject: [issue20276] ctypes._dlopen should not force RTLD_NOW In-Reply-To: <1389835250.18.0.994187095124.issue20276@psf.upfronthosting.co.za> Message-ID: <1389840397.61.0.518939906264.issue20276@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 04:16:19 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 16 Jan 2014 03:16:19 +0000 Subject: [issue20227] Argument Clinic: rename arguments in generated C? In-Reply-To: <1389524736.75.0.620647933805.issue20227@psf.upfronthosting.co.za> Message-ID: <1389842179.42.0.409009879855.issue20227@psf.upfronthosting.co.za> Larry Hastings added the comment: I don't see the big win from this. You can rename variables in C any way you like. "functionname as c_basename" is to fix otherwise unavoidable collisions; this seems like a nice-to-have. And I already have a lot on my plate. I could consider it later but the priority for this is below converting functions. Georg: I remind you that nearly every parsing function already has a variable called "args". To allow you to have a parameter called "args" would mean I'd have to have really complicated internal structure, where the variable I declare in the parsing function would have a different name from the parameter to the impl function. Do you really have a burning, nearly incandescent need for this feature? Zachary: You could minimize the size of the diff by using nested scopes: _impl(...) /*[clinic end generated code: checksum=...]*/ { int use_overlapped = overlapped; { LP_OVERLAPPED overlapped; ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 04:17:41 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 16 Jan 2014 03:17:41 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1389842261.79.0.393960975198.issue20172@psf.upfronthosting.co.za> Larry Hastings added the comment: > is the best approach for this to define winreg_OpenKeyEx_impl > as `return winreg_OpenKey_impl(module, key, sub_key, reserved, > access);`? Sounds good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 05:01:36 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Thu, 16 Jan 2014 04:01:36 +0000 Subject: [issue20232] Argument Clinic NULL default falsely implies None acceptability In-Reply-To: <1389581598.8.0.840632015553.issue20232@psf.upfronthosting.co.za> Message-ID: <1389844896.52.0.684178403647.issue20232@psf.upfronthosting.co.za> Ryan Smith-Roberts added the comment: I've realized this is basically insoluble without PEP 457, because any other solution involves changing behavior (None being silently accepted where it would previously raise an exception). If that's OK, then per-function defensive programming is probably the best idea (just emailed python-dev about this). I didn't like the look of the ways I came up with for adding it to AC (inserting arbitrary crazycode between ParseTuple and _impl), so please close this 'wont fix' unless you really do want to do that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 05:29:39 2014 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 16 Jan 2014 04:29:39 +0000 Subject: [issue19585] Frame annotation In-Reply-To: <1384448970.46.0.460613881183.issue19585@psf.upfronthosting.co.za> Message-ID: <1389846579.69.0.88060507915.issue19585@psf.upfronthosting.co.za> Nick Coghlan added the comment: Another use case from frame annotations: allowing greenlets and threads to indicate which greenlet or thread a traceback is from whenever it is printed (this is similar to the way the runtime indicates which thread a traceback occurred in when it terminates the the thread, but would apply whenever the uppermost frame is displayed in a thread that isn't the main thread, or in the case of greenlets, the uppermost frame in the greenlet, always) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 05:36:23 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 16 Jan 2014 04:36:23 +0000 Subject: [issue20232] Argument Clinic NULL default falsely implies None acceptability In-Reply-To: <1389581598.8.0.840632015553.issue20232@psf.upfronthosting.co.za> Message-ID: <1389846983.08.0.444900748038.issue20232@psf.upfronthosting.co.za> Larry Hastings added the comment: Why wouldn't my suggestion work? _sha1.sha1(b'').hexdigest() == _sha1.sha1().hexdigest(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 05:46:32 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 16 Jan 2014 04:46:32 +0000 Subject: [issue20232] Argument Clinic NULL default falsely implies None acceptability In-Reply-To: <1389581598.8.0.840632015553.issue20232@psf.upfronthosting.co.za> Message-ID: <1389847592.26.0.125164625653.issue20232@psf.upfronthosting.co.za> Larry Hastings added the comment: Also: how would PEP 457 help? PEP 457 only addresses extensions to support positional-only parameters, and the parameter in question (the "string" parameter to _sha1.sha1) is positional-or-keyword. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 06:19:07 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Thu, 16 Jan 2014 05:19:07 +0000 Subject: [issue20232] Argument Clinic NULL default falsely implies None acceptability In-Reply-To: <1389581598.8.0.840632015553.issue20232@psf.upfronthosting.co.za> Message-ID: <1389849547.86.0.935961665494.issue20232@psf.upfronthosting.co.za> Ryan Smith-Roberts added the comment: sha1 is Vajrasky's module. I have a much more complicated example (and Vajrasky and I just both posted on python-dev separately about this issue): sockobj.sendmsg(buffers[, ancdata[, flags[, address]]]) -> sockobj.sendmsg(buffers, ancdata=None, flags=0, address=None) Here ancdata wants an iterator and address a tuple, and the existing function expects NULL when these are absent. This is what we've been indirectly discussing via email as well. Aaand I just realized that I should set py_default to []? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 06:36:38 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Thu, 16 Jan 2014 05:36:38 +0000 Subject: [issue20232] Argument Clinic NULL default falsely implies None acceptability In-Reply-To: <1389581598.8.0.840632015553.issue20232@psf.upfronthosting.co.za> Message-ID: <1389850598.88.0.858234012679.issue20232@psf.upfronthosting.co.za> Ryan Smith-Roberts added the comment: No, that still leaves address broken since neither None nor an empty tuple are acceptable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 06:39:34 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 16 Jan 2014 05:39:34 +0000 Subject: [issue20232] Argument Clinic NULL default falsely implies None acceptability In-Reply-To: <1389581598.8.0.840632015553.issue20232@psf.upfronthosting.co.za> Message-ID: <1389850774.18.0.483586316013.issue20232@psf.upfronthosting.co.za> Larry Hastings added the comment: Definitely not []. At the very least (). I'd appreciate it if you'd stop abruptly changing the subject. I thought we were talking about SHA1_new, but now you're talking about "address" and "sockobj.sendmsg". If you have specific cases you'd like to discuss, post them and maybe we can find a workaround. If you want to discuss the general problem, I guess now we want to have that discussion on python-dev. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 06:40:28 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Thu, 16 Jan 2014 05:40:28 +0000 Subject: [issue20174] Derby #5: Convert 50 sites to Argument Clinic across 3 files In-Reply-To: <1389138461.92.0.709656306175.issue20174@psf.upfronthosting.co.za> Message-ID: <1389850828.56.0.565329187432.issue20174@psf.upfronthosting.co.za> Ryan Smith-Roberts added the comment: Tweaked the argument list for functions using a NULL default. Kludgy but doesn't lie to the user. ---------- Added file: http://bugs.python.org/file33490/argument_clinic_socketmodule_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 06:51:23 2014 From: report at bugs.python.org (Georg Brandl) Date: Thu, 16 Jan 2014 05:51:23 +0000 Subject: [issue20227] Argument Clinic: rename arguments in generated C? In-Reply-To: <1389524736.75.0.620647933805.issue20227@psf.upfronthosting.co.za> Message-ID: <1389851483.83.0.835251582608.issue20227@psf.upfronthosting.co.za> Georg Brandl added the comment: I guess custom converters are the answer here. BTW, the "args" argument already works fine since adding it to c_keywords. No need for a complicated structure :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 06:53:43 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 16 Jan 2014 05:53:43 +0000 Subject: [issue20235] Argument Clinic: recover a bit more gracefully from exceptions In-Reply-To: <1389596547.42.0.103155756972.issue20235@psf.upfronthosting.co.za> Message-ID: <3f4ZMl6PbHzSjK@mail.python.org> Roundup Robot added the comment: New changeset acd31653e3b4 by Georg Brandl in branch 'default': Closes #20235: Report file and line on unexpected exceptions in Argument Clinic. http://hg.python.org/cpython/rev/acd31653e3b4 ---------- nosy: +python-dev resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 08:06:40 2014 From: report at bugs.python.org (Ronald Oussoren) Date: Thu, 16 Jan 2014 07:06:40 +0000 Subject: [issue20276] ctypes._dlopen should not force RTLD_NOW In-Reply-To: <1389835250.18.0.994187095124.issue20276@psf.upfronthosting.co.za> Message-ID: <1389856000.58.0.324352089602.issue20276@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The big question is why ctypes uses RTLD_NOW in the first place. There's probably a good reason for it because it's added unconditionally to the user provided flags. BTW. I'd prefer to keep the dlopen flags on OSX the same as on other platforms (that is, either keep the current behavior, or drop RTLD_NOW everywhere) because RTLD_NOW has an impact on the functionality and now using the same flags everywhere could cause subtle changes in functionality between platforms. BTW2. The workaround mentioned in message 2 would be new functionality (adding new symbols) and as such could probably not be added to 2.7. I've added 3.3 and 3.4 to the list of versions because those also use RTLD_NOW and hence behave the same as 2.7 in this respect. ---------- nosy: +amaury.forgeotdarc, belopolsky, meador.inge versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 08:17:47 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 16 Jan 2014 07:17:47 +0000 Subject: [issue20234] Argument Clinic: use PyTuple_GET_SIZE? In-Reply-To: <1389596202.96.0.0154982234114.issue20234@psf.upfronthosting.co.za> Message-ID: <1389856667.0.0.801480187843.issue20234@psf.upfronthosting.co.za> Larry Hastings added the comment: I suppose so. It would be hard to measure the resulting speedup. But I guess we get it for free. I made the change in my "simple expressions" branch. So it'll go in when that does. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 08:20:24 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 16 Jan 2014 07:20:24 +0000 Subject: [issue20256] Argument Clinic: compare signed and unsigned ints In-Reply-To: <1389688549.54.0.106907827652.issue20256@psf.upfronthosting.co.za> Message-ID: <1389856824.22.0.862772844391.issue20256@psf.upfronthosting.co.za> Larry Hastings added the comment: Good point. My brain is dead. What would be a better "magic cookie" value? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 08:24:15 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 16 Jan 2014 07:24:15 +0000 Subject: [issue20133] Derby: Convert the audioop module to use Argument Clinic In-Reply-To: <1388956864.17.0.114751586443.issue20133@psf.upfronthosting.co.za> Message-ID: <1389857055.91.0.367043801948.issue20133@psf.upfronthosting.co.za> Larry Hastings added the comment: I don't understand. Python already has "double" which is float64. Why would Python need a second floating-point type which isn't as good? In any case, if somehow you get float32 in, we could just change the return converters then. So I would still prefer float return converters for now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 08:37:38 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 16 Jan 2014 07:37:38 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1389857858.0.0.673553252878.issue20185@psf.upfronthosting.co.za> Larry Hastings added the comment: Someone else came up with this hack using a custom converter: class PID_converter(int_converter): format_unit = '" _Py_PARSE_PID "' Also, for marshal.version, soon you will be able to. This syntax won't work now but it will soon: version: int(c_default="Py_MARSHAL_VERSION") = version ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 08:41:02 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 16 Jan 2014 07:41:02 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1389858062.62.0.725022984844.issue20185@psf.upfronthosting.co.za> Larry Hastings added the comment: Keep track of #20226, that's the issue where I'm adding improved support for simple expressions like "version". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 08:53:03 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Thu, 16 Jan 2014 07:53:03 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1389858783.31.0.133116851558.issue20173@psf.upfronthosting.co.za> Vajrasky Kok added the comment: So, as Guide said in https://mail.python.org/pipermail/python-dev/2014-January/131675.html: "In the sha1 example, however, accepting None and converting it to NULL (without a reference leak, please :-) seems fine though." I let the patches as they are. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 08:53:19 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Thu, 16 Jan 2014 07:53:19 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1389858799.77.0.550763922564.issue20173@psf.upfronthosting.co.za> Vajrasky Kok added the comment: s/Guide/Guido. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 08:59:28 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 16 Jan 2014 07:59:28 +0000 Subject: [issue20262] Convert some debugging prints in zipfile to warnings In-Reply-To: <1389732995.51.0.822070396354.issue20262@psf.upfronthosting.co.za> Message-ID: <1389859168.9.0.75633234995.issue20262@psf.upfronthosting.co.za> Larry Hastings added the comment: I will bow to the wisdom of my predecessor and accept this patch for beta 3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 08:59:31 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Jan 2014 07:59:31 +0000 Subject: [issue20256] Argument Clinic: compare signed and unsigned ints In-Reply-To: <1389688549.54.0.106907827652.issue20256@psf.upfronthosting.co.za> Message-ID: <1389859171.29.0.277061688007.issue20256@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: (unsigned int)-1 etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 09:03:13 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Jan 2014 08:03:13 +0000 Subject: [issue20133] Derby: Convert the audioop module to use Argument Clinic In-Reply-To: <1388956864.17.0.114751586443.issue20133@psf.upfronthosting.co.za> Message-ID: <1389859393.97.0.453592530219.issue20133@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I mean I want to add support for float32 and float64 in audioop functions. In that case return value of getsample(), max(), ets will be no longer integer for float format. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 09:08:10 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 16 Jan 2014 08:08:10 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? In-Reply-To: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> Message-ID: <1389859690.34.0.418038783434.issue20226@psf.upfronthosting.co.za> Larry Hastings added the comment: Okay, I have a fix for the help(os.chmod) problem, that'll be in the next refreshed patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 09:11:41 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Jan 2014 08:11:41 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? In-Reply-To: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> Message-ID: <1389859901.77.0.298278855547.issue20226@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Why not allow arbitrary string as py_default? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 09:12:53 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 16 Jan 2014 08:12:53 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? In-Reply-To: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> Message-ID: <1389859973.25.0.935055049877.issue20226@psf.upfronthosting.co.za> Larry Hastings added the comment: Isn't that what it does? I may actually remove py_default. Nobody uses it, and I don't think you need it--you just specify what you want as the real default value. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 09:23:25 2014 From: report at bugs.python.org (xwild) Date: Thu, 16 Jan 2014 08:23:25 +0000 Subject: [issue20277] default __debug__ value and asserts Message-ID: <1389860605.32.0.0951203390882.issue20277@psf.upfronthosting.co.za> New submission from xwild: Why the python sets the "__debug__" builtin = True by default? It causes that people never use the "assert" construction by their programms in a regular way. it's too hard to explain everyone that "-O" is required by a script. It's very usefull instruction and actually it's blocked by default. ---------- components: Interpreter Core, Tests messages: 208256 nosy: xwild priority: normal severity: normal status: open title: default __debug__ value and asserts type: behavior versions: 3rd party, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 09:24:46 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Jan 2014 08:24:46 +0000 Subject: [issue20276] ctypes._dlopen should not force RTLD_NOW In-Reply-To: <1389835250.18.0.994187095124.issue20276@psf.upfronthosting.co.za> Message-ID: <1389860686.0.0.655478020075.issue20276@psf.upfronthosting.co.za> STINNER Victor added the comment: FYI, dlopen() flags are configurable: - sys.setdlopenflags(n): default=RTLD_NOW (if available, or RTLD_LAZY otherwise) - mode parameter of dl.dlopen(): default=RTLD_LAZY - mode parameter of ctypes.CDLL: default=RTLD_LOCAL (but RTLD_GLOBAL on Mac OS X <= 10.3); but RTLD_NOW is always added See also: "How to disable RTLD_NOW for Python 2.7.x dlopen() in Mac OS X Mavericks?" https://groups.google.com/forum/#!msg/comp.lang.python/DKmNGwyLl3w/1tuxcnwBAw8J "how to handle library interdependencies" http://osdir.com/ml/python.ctypes/2006-10/msg00022.html "Need RTLD_GLOBAL for linux?" http://code.google.com/p/ctypesgen/issues/detail?id=3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 09:29:57 2014 From: report at bugs.python.org (Georg Brandl) Date: Thu, 16 Jan 2014 08:29:57 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1389860997.9.0.714885420807.issue20182@psf.upfronthosting.co.za> Changes by Georg Brandl : Added file: http://bugs.python.org/file33491/modules_issue20182_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 09:30:19 2014 From: report at bugs.python.org (Georg Brandl) Date: Thu, 16 Jan 2014 08:30:19 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1389861019.46.0.120594071323.issue20182@psf.upfronthosting.co.za> Georg Brandl added the comment: New patch addressing comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 09:41:32 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 16 Jan 2014 08:41:32 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? In-Reply-To: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> Message-ID: <1389861692.6.0.599517487466.issue20226@psf.upfronthosting.co.za> Larry Hastings added the comment: Second rollup patch. More small fixes, many suggested by other folks. ---------- Added file: http://bugs.python.org/file33492/larry.clinic.rollup.patch.two.diff.2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 09:47:32 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Jan 2014 08:47:32 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? In-Reply-To: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> Message-ID: <1389862052.37.0.584248968402.issue20226@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It would be better if you commit a patch which changes PyTuple_Size to PyTuple_GET_SIZE in separate commit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 10:05:29 2014 From: report at bugs.python.org (xwild) Date: Thu, 16 Jan 2014 09:05:29 +0000 Subject: [issue20277] default __debug__ value and asserts In-Reply-To: <1389860605.32.0.0951203390882.issue20277@psf.upfronthosting.co.za> Message-ID: <1389863129.46.0.581217783423.issue20277@psf.upfronthosting.co.za> Changes by xwild : ---------- versions: -3rd party _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 10:11:32 2014 From: report at bugs.python.org (Richard Philips) Date: Thu, 16 Jan 2014 09:11:32 +0000 Subject: [issue20278] Wrong URL to the pysqlite web page Message-ID: <1389863492.56.0.743244372152.issue20278@psf.upfronthosting.co.za> New submission from Richard Philips: The reference to the pysqlite web page on: http://docs.python.org/3.4/library/sqlite3.html should be: https://github.com/ghaering/pysqlite ---------- assignee: docs at python components: Documentation messages: 208261 nosy: Richard.Philips, docs at python priority: normal severity: normal status: open title: Wrong URL to the pysqlite web page versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 10:14:56 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Thu, 16 Jan 2014 09:14:56 +0000 Subject: [issue20227] Argument Clinic: rename arguments in generated C? In-Reply-To: <1389524736.75.0.620647933805.issue20227@psf.upfronthosting.co.za> Message-ID: <1389863696.59.0.456127219339.issue20227@psf.upfronthosting.co.za> Ryan Smith-Roberts added the comment: The use case is primarily to minimize code churn for the derby, but since you're the one (heroically) doing the code review it's really your call. I whipped up a quick patch for this feature, and even if you remove c_name from __init__ I think it's still a small cleanup. ---------- keywords: +patch Added file: http://bugs.python.org/file33493/argument_clinic_rename_c_variable.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 10:16:36 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Thu, 16 Jan 2014 09:16:36 +0000 Subject: [issue20227] Argument Clinic: rename arguments in generated C? In-Reply-To: <1389524736.75.0.620647933805.issue20227@psf.upfronthosting.co.za> Message-ID: <1389863796.5.0.711320528815.issue20227@psf.upfronthosting.co.za> Changes by Ryan Smith-Roberts : Added file: http://bugs.python.org/file33494/argument_clinic_ensure_legal_cleanup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 10:18:42 2014 From: report at bugs.python.org (xwild) Date: Thu, 16 Jan 2014 09:18:42 +0000 Subject: [issue20277] default __debug__ value and asserts In-Reply-To: <1389860605.32.0.0951203390882.issue20277@psf.upfronthosting.co.za> Message-ID: <1389863922.22.0.56611360809.issue20277@psf.upfronthosting.co.za> Changes by xwild : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 10:20:50 2014 From: report at bugs.python.org (xwild) Date: Thu, 16 Jan 2014 09:20:50 +0000 Subject: [issue20277] default __debug__ value and asserts In-Reply-To: <1389860605.32.0.0951203390882.issue20277@psf.upfronthosting.co.za> Message-ID: <1389864050.93.0.538246195064.issue20277@psf.upfronthosting.co.za> Changes by xwild : ---------- nosy: +ezio.melotti, michael.foord, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 10:21:41 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Jan 2014 09:21:41 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389864101.93.0.127805548268.issue20275@psf.upfronthosting.co.za> STINNER Victor added the comment: > I like logger_is_enabled_for.patch. I prefer debug_flag.patch because it is faster than logger_is_enabled_for.patch (see msg208214). I would like to write the most efficient code for BaseEventLoop._run_once() because this function is the real core of asyncio and it is called very frequently. Test attached event_loop_run_once.py script. On such dummy example, _run_once() is called 4 times. Note: Thanks to the nice design of yield from, wrapper() doesn't add an extra call to _run_once()! Please think also to Trollius (port of asyncio on Python 2) which uses yield instead of yield-from. The same example calls _run_once() 10 times! The wrapper itself uses 2 calls. I don't know yet if Trollius can be modified to call _run_once() less frequently. It may be hard to keep the scheduling fair between concurrent running tasks. ---------- Added file: http://bugs.python.org/file33495/event_loop_run_once.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 10:22:30 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Thu, 16 Jan 2014 09:22:30 +0000 Subject: [issue20174] Derby #5: Convert 50 sites to Argument Clinic across 3 files In-Reply-To: <1389138461.92.0.709656306175.issue20174@psf.upfronthosting.co.za> Message-ID: <1389864150.7.0.889892084343.issue20174@psf.upfronthosting.co.za> Ryan Smith-Roberts added the comment: Here's sendmsg with only nested bracket optional args. If Rietveld doesn't like this patch I may cry. ---------- Added file: http://bugs.python.org/file33496/argument_clinic_socketmodule_v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 10:26:17 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Thu, 16 Jan 2014 09:26:17 +0000 Subject: [issue20232] Argument Clinic NULL default falsely implies None acceptability In-Reply-To: <1389581598.8.0.840632015553.issue20232@psf.upfronthosting.co.za> Message-ID: <1389864377.49.0.189391607604.issue20232@psf.upfronthosting.co.za> Ryan Smith-Roberts added the comment: After all our discussions I'm closing this with resolution "don't do that then". ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 10:29:17 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Jan 2014 09:29:17 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? In-Reply-To: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> Message-ID: <1389864557.68.0.508939093801.issue20226@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Excellent! I'm rewriting the zlib module and the code becomes much cleaner with this patch. There is one problem left -- Py_buffer doesn't support default value at all. Such code /*[clinic input] zlib.compressobj zdict: Py_buffer = unspecified [clinic start generated code]*/ produces error: When you specify a named constant ('unspecified') as your default value, you MUST specify a valid c_default. But this code /*[clinic input] zlib.compressobj zdict: Py_buffer(c_default="{NULL, NULL}") = unspecified [clinic start generated code]*/ produces error too: The only legal default value for Py_buffer is None. And specifying c_default=None returns first error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 10:32:52 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Jan 2014 09:32:52 +0000 Subject: [issue20277] default __debug__ value and asserts In-Reply-To: <1389860605.32.0.0951203390882.issue20277@psf.upfronthosting.co.za> Message-ID: <1389864772.01.0.0978394013826.issue20277@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Specify the -O option in she-bang: #!/usr/bin/env python3 -O ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 10:42:48 2014 From: report at bugs.python.org (xwild) Date: Thu, 16 Jan 2014 09:42:48 +0000 Subject: [issue20277] default __debug__ value and asserts In-Reply-To: <1389860605.32.0.0951203390882.issue20277@psf.upfronthosting.co.za> Message-ID: <1389865368.2.0.98955625159.issue20277@psf.upfronthosting.co.za> xwild added the comment: Yes it's acceptable, but why the debug mode is enabled by default? It's a not expected behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 10:44:25 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Thu, 16 Jan 2014 09:44:25 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1389865465.93.0.0203195307893.issue20185@psf.upfronthosting.co.za> Vajrasky Kok added the comment: With little modification: class PID_converter(int_converter): type = 'pid_t' format_unit = '" _Py_PARSE_PID "' It works. Thanks! But I got unnecessary empty string: if (!PyArg_ParseTuple(args, "" _Py_PARSE_PID "i:prlimit", &pid, &resource)) It should be: if (!PyArg_ParseTuple(args, _Py_PARSE_PID "i:prlimit", &pid, &resource)) Anyway, that is trivial problem. Now I hit a hard one. How do you convert this signature? - if (!PyArg_ParseTuple(args, _Py_PARSE_PID "i|(OO):prlimit", - &pid, &resource, &curobj, &maxobj)) I create custom converters: +class TupleOpen_converter(object_converter): + format_unit = '(O' +class TupleClose_converter(object_converter): + format_unit = 'O)' and +/*[clinic input] +resource.prlimit + + pid: PID + resource: int + [ + curobj: TupleOpen + maxobj: TupleClose + ] + / +[clinic start generated code]*/ But I got invalid argument size in the generated code. + case 2: + if (!PyArg_ParseTuple(args, "" _Py_PARSE_PID "i:prlimit", &pid, &resource)) + return NULL; + break; + case 4: ========> should be "case 3:" + if (!PyArg_ParseTuple(args, "" _Py_PARSE_PID "i(OO):prlimit", &pid, &resource, &curobj, &maxobj)) + return NULL; + group_right_1 = 1; + break; + default: + PyErr_SetString(PyExc_TypeError, "resource.prlimit requires 2 to 4 arguments"); =======> should be "2 to 3 arguments" + return NULL; Any idea, Larry? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 11:43:13 2014 From: report at bugs.python.org (Michael Foord) Date: Thu, 16 Jan 2014 10:43:13 +0000 Subject: [issue20277] default __debug__ value and asserts In-Reply-To: <1389860605.32.0.0951203390882.issue20277@psf.upfronthosting.co.za> Message-ID: <1389868993.89.0.800865022132.issue20277@psf.upfronthosting.co.za> Michael Foord added the comment: Having __debug__ True by default is unintuitive and not particularly useful. However it is relatively well known, so although it is "rarely" used that probably only means hundreds of thousands of piece of code. So it isn't going to change I'm afraid. ---------- resolution: -> wont fix stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 11:55:05 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Jan 2014 10:55:05 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1389869705.35.0.217898734829.issue20185@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is known bug in prlimit (issue20191). ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 11:55:32 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Jan 2014 10:55:32 +0000 Subject: [issue20191] resource.prlimit(int, int, str) crashs In-Reply-To: <1389191622.9.0.0763750909735.issue20191@psf.upfronthosting.co.za> Message-ID: <1389869731.99.0.411078446929.issue20191@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- priority: normal -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 12:06:38 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Jan 2014 11:06:38 +0000 Subject: [issue20191] resource.prlimit(int, int, str) crashs In-Reply-To: <1389191622.9.0.0763750909735.issue20191@psf.upfronthosting.co.za> Message-ID: <1389870398.52.0.990641963555.issue20191@psf.upfronthosting.co.za> STINNER Victor added the comment: There is another option: modify the function to use argument clinic and implement something in argument clinic to hold a reference on borrowed references "O" and hold a reference on "(...)" sequence. Holding a reference on borrowed references "O" would make Python more safer against a whole class of bugs. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 12:33:15 2014 From: report at bugs.python.org (Anatoly Belikov) Date: Thu, 16 Jan 2014 11:33:15 +0000 Subject: [issue20279] bytearray.fromhex does not work with some hexes generated by hex Message-ID: <1389871995.67.0.0459502890615.issue20279@psf.upfronthosting.co.za> New submission from Anatoly Belikov: bytearray.fromhex(hex(434)[2:]) throws ValueError: non-hexadecimal number found in fromhex() arg at position 2 Strangely it works with leading zero: bytearray.fromhex('0' + hex(438)[2:]) ---------- components: Library (Lib) messages: 208273 nosy: Anatoly Belikov priority: normal severity: normal status: open title: bytearray.fromhex does not work with some hexes generated by hex type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 12:48:26 2014 From: report at bugs.python.org (Anatoly Belikov) Date: Thu, 16 Jan 2014 11:48:26 +0000 Subject: [issue20279] bytearray.fromhex does not work with some hexes generated by hex In-Reply-To: <1389871995.67.0.0459502890615.issue20279@psf.upfronthosting.co.za> Message-ID: <1389872906.2.0.940903133657.issue20279@psf.upfronthosting.co.za> Anatoly Belikov added the comment: ok i gave it half byte ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 13:10:45 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Jan 2014 12:10:45 +0000 Subject: [issue20262] Convert some debugging prints in zipfile to warnings In-Reply-To: <1389732995.51.0.822070396354.issue20262@psf.upfronthosting.co.za> Message-ID: <1389874245.69.0.661189669615.issue20262@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Well, then I should only ask Benjamin. ---------- nosy: +benjamin.peterson versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 13:33:28 2014 From: report at bugs.python.org (Matthias Klose) Date: Thu, 16 Jan 2014 12:33:28 +0000 Subject: [issue19936] Executable permissions of Python source files In-Reply-To: <1386588201.39.0.841678145847.issue19936@psf.upfronthosting.co.za> Message-ID: <1389875608.56.0.770745533223.issue19936@psf.upfronthosting.co.za> Matthias Klose added the comment: I like this, and I'm doing this in the Debian/Ubuntu packaging anyway. But I would like to see some check script which maybe can be run before a release, that points out regressions or wrong permissions for newly introduced files. ---------- nosy: +doko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 14:25:50 2014 From: report at bugs.python.org (Florent Xicluna) Date: Thu, 16 Jan 2014 13:25:50 +0000 Subject: [issue20280] add "predicate" to the glossary Message-ID: <1389878750.92.0.454847187289.issue20280@psf.upfronthosting.co.za> New submission from Florent Xicluna: This term is used in various places in the documentation. http://docs.python.org/dev/search.html?q=predicate Probably it deserves an entry in the glossary, even if it is not specific to Python: http://en.wikipedia.org/wiki/Predicate_%28mathematical_logic%29 ---------- assignee: docs at python components: Documentation messages: 208277 nosy: docs at python, flox priority: low severity: normal status: open title: add "predicate" to the glossary type: enhancement versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 14:44:47 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 16 Jan 2014 13:44:47 +0000 Subject: [issue19936] Executable permissions of Python source files In-Reply-To: <1386588201.39.0.841678145847.issue19936@psf.upfronthosting.co.za> Message-ID: <3f4mqL4SVRz7Lk8@mail.python.org> Roundup Robot added the comment: New changeset 9062a8695c89 by Stefan Krah in branch '3.3': Issue #19936: Disable shebang lines in order to prevent using a random http://hg.python.org/cpython/rev/9062a8695c89 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 15:53:30 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 16 Jan 2014 14:53:30 +0000 Subject: [issue20278] Wrong URL to the pysqlite web page In-Reply-To: <1389863492.56.0.743244372152.issue20278@psf.upfronthosting.co.za> Message-ID: <3f4pLd2M52z7Lk1@mail.python.org> Roundup Robot added the comment: New changeset b73b35d1c58d by Benjamin Peterson in branch '3.3': update pysqlite website (closes #20278) http://hg.python.org/cpython/rev/b73b35d1c58d New changeset 40289a03569f by Benjamin Peterson in branch '2.7': update pysqlite website (closes #20278) http://hg.python.org/cpython/rev/40289a03569f New changeset e6ecbdb794a9 by Benjamin Peterson in branch 'default': merge 3.3 (#20278) http://hg.python.org/cpython/rev/e6ecbdb794a9 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 15:54:28 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 16 Jan 2014 14:54:28 +0000 Subject: [issue20278] Wrong URL to the pysqlite web page In-Reply-To: <1389863492.56.0.743244372152.issue20278@psf.upfronthosting.co.za> Message-ID: <1389884068.37.0.967071729437.issue20278@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Done. Of course, the Python version of sqlite hasn't been updated in ages (and has probably diverged!), so it might not be that relevant anymore. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 16:10:35 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 16 Jan 2014 15:10:35 +0000 Subject: [issue20272] chain.from_iterable in the overview table not linking to the function In-Reply-To: <1389815977.04.0.427053880301.issue20272@psf.upfronthosting.co.za> Message-ID: <3f4pkM089Fz7Ln5@mail.python.org> Roundup Robot added the comment: New changeset aa88c8265e94 by Benjamin Peterson in branch '3.3': linkify chain.from_iterable (closes #20272) http://hg.python.org/cpython/rev/aa88c8265e94 New changeset 58cac9967cf0 by Benjamin Peterson in branch 'default': merge 3.3 (#20272) http://hg.python.org/cpython/rev/58cac9967cf0 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 16:37:37 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 16 Jan 2014 15:37:37 +0000 Subject: [issue19936] Executable permissions of Python source files In-Reply-To: <1386588201.39.0.841678145847.issue19936@psf.upfronthosting.co.za> Message-ID: <3f4qKY0c9Lz7LjW@mail.python.org> Roundup Robot added the comment: New changeset 92fd0df03823 by Serhiy Storchaka in branch '3.3': Issue #19936: Added executable bits or shebang lines to Python scripts which http://hg.python.org/cpython/rev/92fd0df03823 New changeset 83009d70bc9c by Serhiy Storchaka in branch 'default': Issue #19936: Added executable bits or shebang lines to Python scripts which http://hg.python.org/cpython/rev/83009d70bc9c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 16:44:12 2014 From: report at bugs.python.org (Christian Aichinger) Date: Thu, 16 Jan 2014 15:44:12 +0000 Subject: [issue6128] Consequences of using Py_TPFLAGS_HAVE_GC are incompletely explained In-Reply-To: <1243457336.14.0.579311647458.issue6128@psf.upfronthosting.co.za> Message-ID: <1389887052.13.0.301820792404.issue6128@psf.upfronthosting.co.za> Christian Aichinger added the comment: I concur that this aspect of writing Python types in C/C++ needs better documentation. For a new extension writer (like me), it is not obvious when PyObject_GC_Track/PyObject_GC_UnTrack must be called or not. Similarly, it is not clear from the current documentation how to ensure that memory is allocated with PyObject_GC_New. The gcsupport documentation suffers from being written from the perspective of the GC, instead of the perspective of extension writers. Thus, I've attached a patch that tries to shed some light on how to correctly write types implementing cyclic GC support. I'd appreciate comments/editing suggestions/advice and would welcome the patch to go into Python in some form. I myself consider the change to be trivial, but if necessary I can sign the contributor agreement. -- PS: Informal explanation about what's really going on: The Python GC code deals with memory allocation, not with initialization in any way. For most extension types, allocation is handled by tp_alloc which is called typically called from tp_new (either the default tp_new or your own tp_new handler). The default tp_alloc (PyType_GenericAlloc()) looks at tp_flags, and if Py_TPFLAGS_HAVE_GC is specified, it uses the appropriate GC malloc function and calls _PyObject_GC_TRACK when finished). Thus, if you allocate your memory via tp_alloc, and don't override the tp_alloc handler, you've just fulfilled the GC's constructor requirements. Similarly, the GC doesn't care about object destruction. It cares about freeing memory, that is tp_free, NOT tp_dealloc! Again, if you don't intentionally provide a custom tp_free handler, the default one will take care to obey the GC rules. Thus, most extension writers can get away with 4 simple rules: * Set Py_TPFLAGS_HAVE_GC in tp_flags. * Do not specify tp_alloc or tp_free. * Make sure your object actually allocates it's memory via tp_alloc. Three possibilities to achieve this: + Do not add a tp_new handler, or + Call tp_alloc from your tp_new handler, or + Call a base class's tp_new from your own tp_new handler * Implement tp_traverse and tp_clear. They are usually straight-forward. And if you really do want a custom allocator, you're screwed anyway, as the last part of my patch hints at. Custom memory management is just not compatible with the GC at this point. ---------- keywords: +patch nosy: +Greek0 versions: +Python 3.5 Added file: http://bugs.python.org/file33497/gcsupport-doc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 16:44:57 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Jan 2014 15:44:57 +0000 Subject: [issue19936] Executable permissions of Python source files In-Reply-To: <1386588201.39.0.841678145847.issue19936@psf.upfronthosting.co.za> Message-ID: <1389887097.23.0.735259217365.issue19936@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a script. It lists text files with executable bits and without shebangs and files with .py, .pyw, or .sh suffix which have shebang but have not with executable bits. As far as it searches not only Python files, now it found such files: - ./python-gdb.py - ./Doc/includes/email-unpack.py - ./Doc/includes/email-alternative.py - ./Doc/includes/email-dir.py - ./Misc/python-config.sh x ./Mac/PythonLauncher/MyDocument.m x ./Mac/PythonLauncher/MyDocument.h x ./Mac/PythonLauncher/FileSettings.m x ./Mac/PythonLauncher/main.m x ./Mac/PythonLauncher/FileSettings.h - ./Tools/test2to3/maintest.py x ./Tools/scripts/pydocgui.pyw x ./Lib/idlelib/idle.bat - ./Modules/_ctypes/libffi/build-ios.sh x ./Modules/_ctypes/libffi/ltmain.sh - ./Modules/_ctypes/libffi/msvcc.sh - ./Modules/_ctypes/libffi/src/arm/gentramp.sh x ./Modules/_decimal/tests/deccheck.py x ./Modules/_decimal/tests/runall.bat x ./Modules/_decimal/tests/bench.py x ./PC/msvcrtmodule.c ---------- Added file: http://bugs.python.org/file33498/findnoshebang.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 16:49:46 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 16 Jan 2014 15:49:46 +0000 Subject: [issue19936] Executable permissions of Python source files In-Reply-To: <1386588201.39.0.841678145847.issue19936@psf.upfronthosting.co.za> Message-ID: <1389887386.23.0.00795837912596.issue19936@psf.upfronthosting.co.za> Stefan Krah added the comment: Somehow Modules/_decimal/tests/bench.py and Modules/_decimal/tests/deccheck.py are now executable, which (I think) they should not be. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 17:19:34 2014 From: report at bugs.python.org (Zachary Ware) Date: Thu, 16 Jan 2014 16:19:34 +0000 Subject: [issue20227] Argument Clinic: rename arguments in generated C? In-Reply-To: <1389524736.75.0.620647933805.issue20227@psf.upfronthosting.co.za> Message-ID: <1389889174.66.0.708554087804.issue20227@psf.upfronthosting.co.za> Zachary Ware added the comment: The nested scope trick makes me happy. There are still a lot of cases in the conversions I've worked on where a variable had to be renamed due to having documented a different name for the parameter, but in the vast majority of those cases the new name makes more sense anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 17:51:36 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 16 Jan 2014 16:51:36 +0000 Subject: [issue19936] Executable permissions of Python source files In-Reply-To: <1386588201.39.0.841678145847.issue19936@psf.upfronthosting.co.za> Message-ID: <3f4ryw0JCsz7Ll1@mail.python.org> Roundup Robot added the comment: New changeset 085a0ea2015f by Serhiy Storchaka in branch '3.3': Issue #19936: Remove executable bits from C source files and several forgotten http://hg.python.org/cpython/rev/085a0ea2015f New changeset 6baeee39195b by Serhiy Storchaka in branch 'default': Issue #19936: Remove executable bits from C source files and several forgotten http://hg.python.org/cpython/rev/6baeee39195b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 17:56:30 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 16 Jan 2014 16:56:30 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? In-Reply-To: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> Message-ID: <1389891390.85.0.473901599041.issue20226@psf.upfronthosting.co.za> Larry Hastings added the comment: Py_buffer is currently inflexible. The only default value it accepts is None. If you want it to be required, give it no default value. If you want it to be optional, give it a default value of None. Do you have a use case for any other default value? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 18:00:11 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 16 Jan 2014 17:00:11 +0000 Subject: [issue19936] Executable permissions of Python source files In-Reply-To: <1386588201.39.0.841678145847.issue19936@psf.upfronthosting.co.za> Message-ID: <3f4s8p4Wyjz7Ll4@mail.python.org> Roundup Robot added the comment: New changeset 334116bb2939 by Serhiy Storchaka in branch '2.7': Issue #19936: Added executable bits or shebang lines to Python scripts which http://hg.python.org/cpython/rev/334116bb2939 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 18:12:56 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 16 Jan 2014 17:12:56 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? In-Reply-To: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> Message-ID: <1389892376.83.0.312563236297.issue20226@psf.upfronthosting.co.za> Larry Hastings added the comment: Third patch, changes based on Georg's review. Thanks, Georg! ---------- Added file: http://bugs.python.org/file33499/larry.clinic.rollup.patch.two.diff.3.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 18:22:43 2014 From: report at bugs.python.org (Georg Brandl) Date: Thu, 16 Jan 2014 17:22:43 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? In-Reply-To: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> Message-ID: <1389892963.81.0.315466061503.issue20226@psf.upfronthosting.co.za> Georg Brandl added the comment: Rietveld doesn't like your new patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 18:23:58 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 16 Jan 2014 17:23:58 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? In-Reply-To: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> Message-ID: <1389893038.18.0.248556491116.issue20226@psf.upfronthosting.co.za> Larry Hastings added the comment: Sorry, forgot to update trunk, here you go. ---------- Added file: http://bugs.python.org/file33500/larry.clinic.rollup.patch.two.diff.4.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 18:25:41 2014 From: report at bugs.python.org (Georg Brandl) Date: Thu, 16 Jan 2014 17:25:41 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? In-Reply-To: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> Message-ID: <1389893141.04.0.427394700023.issue20226@psf.upfronthosting.co.za> Georg Brandl added the comment: Thx! (without soundcheck) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 19:04:06 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Jan 2014 18:04:06 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <1389895446.48.0.567469421076.issue20275@psf.upfronthosting.co.za> STINNER Victor added the comment: > I don't understand the purpose of these timing information, (...) > By the way, it's not documentation how to enable asyncio logs I added a new page in the asyncio documentation to start documenting common traps with asynchronous programming and to document debug tools. I didn't document this specific log discussed in this issue. It may be documented in the "Handle correctly blocking functions" section or it may deserve a new section. Don't hesitate to improve the asyncio documentation! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 19:35:42 2014 From: report at bugs.python.org (Mike Owens) Date: Thu, 16 Jan 2014 18:35:42 +0000 Subject: [issue20281] time.strftime %z format specifier is the same as %Z Message-ID: <1389897342.88.0.737767593135.issue20281@psf.upfronthosting.co.za> New submission from Mike Owens: When using strftime from the time module on 64bit Python for Windows the format specifier %z gives the time zone name instead of the time zone offset as stated in the documentation. eg >>> strftime("%z") 'US Mountain Standard Time' >>> strftime("%Z") 'US Mountain Standard Time' The expected output for my time zone is -7:00. ---------- components: Library (Lib) messages: 208295 nosy: Mike.Owens priority: normal severity: normal status: open title: time.strftime %z format specifier is the same as %Z type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 19:39:50 2014 From: report at bugs.python.org (Mike Owens) Date: Thu, 16 Jan 2014 18:39:50 +0000 Subject: [issue20281] time.strftime %z format specifier is the same as %Z In-Reply-To: <1389897342.88.0.737767593135.issue20281@psf.upfronthosting.co.za> Message-ID: <1389897590.37.0.3583677786.issue20281@psf.upfronthosting.co.za> Mike Owens added the comment: Expected output should be -0700. I checked Python 3.3.1 and 2.7.4 on Linux and the output is as expected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 19:45:03 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Jan 2014 18:45:03 +0000 Subject: [issue19936] Executable permissions of Python source files In-Reply-To: <1386588201.39.0.841678145847.issue19936@psf.upfronthosting.co.za> Message-ID: <1389897903.83.0.436916000732.issue19936@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 19:46:55 2014 From: report at bugs.python.org (Fran Bull) Date: Thu, 16 Jan 2014 18:46:55 +0000 Subject: [issue20135] FAQ need list mutation answers In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za> Message-ID: <1389898015.91.0.299532701045.issue20135@psf.upfronthosting.co.za> Fran Bull added the comment: I read the FAQ last night and I couldn't see these answered there either. I would like to try submitting a patch for this one, probably this evening. It will likely be two FAQs in the programming section that go something like: Why does changing one list change another different list? This happens: >>> a = [1, 2, 3] >>> b = a >>> b.append(4) >>> print a [1, 2, 3, 4] because variables are just names for things, in this case 'a' is the list we first defined and then b = a says that 'b' is also a name for that list. They are both the same list. Why are my default args wrong? This happens: >>> from datetime import datetime >>> class A(object): ... def __init__(self, created_time=datetime.now()): ... self.created_time = created_time ... >>> an_a = A() >>> another_a = A() >>> an_a.created_time datetime.datetime(2014, 1, 16, 10, 40, 54, 33283) >>> another_a.created_time datetime.datetime(2014, 1, 16, 10, 40, 54, 33283) because default arguments are evaluated when they're read for the first time by the interpreter. Usually when the class is imported. A good way to get the above to do what you want is to use a default argument of None and check for it, like: >>> class B(object): ... def __init__(self, created_time=None): ... if created_time is None: ... created_time=datetime.now() ... self.created_time = created_time ... >>> a_b = B() >>> another_b = B() >>> a_b.created_time datetime.datetime(2014, 1, 16, 10, 44, 44, 956710) >>> another_b.created_time datetime.datetime(2014, 1, 16, 10, 44, 51, 71311) Feedback appreciated, particularly I'm not sure if this: 'default arguments are evaluated when they're read for the first time by the interpreter' is exactly the right language. I guess I'll look it up. ---------- nosy: +Fran.Bull _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 20:06:21 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 16 Jan 2014 19:06:21 +0000 Subject: [issue20281] time.strftime %z format specifier is the same as %Z In-Reply-To: <1389897342.88.0.737767593135.issue20281@psf.upfronthosting.co.za> Message-ID: <1389899181.72.0.33025317289.issue20281@psf.upfronthosting.co.za> R. David Murray added the comment: Please see the footnote on the 'time' documentation page. It sounds like Windows is treating %z as if was %Z. There should be a reference to that footnote from the %z table entry, so that's a doc bug. Might also be worth explicitly mentioning this weird Windows behavior. FYI, you can use the strftime functionality of the datetime module to get cross platform %z support. ---------- assignee: -> docs at python components: +Documentation -Library (Lib) nosy: +docs at python, r.david.murray stage: -> needs patch versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 20:14:18 2014 From: report at bugs.python.org (Mike Owens) Date: Thu, 16 Jan 2014 19:14:18 +0000 Subject: [issue20281] time.strftime %z format specifier is the same as %Z In-Reply-To: <1389897342.88.0.737767593135.issue20281@psf.upfronthosting.co.za> Message-ID: <1389899658.98.0.657381766289.issue20281@psf.upfronthosting.co.za> Mike Owens added the comment: Documentation doesn't have a foot note for either %z or %Z but there is generic footnote talking about C lib behavior and that %z is deprecated. I guess if there were a foot note in the table for %z that would save some time for everyone. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 20:25:59 2014 From: report at bugs.python.org (Mike Owens) Date: Thu, 16 Jan 2014 19:25:59 +0000 Subject: [issue20281] time.strftime %z format specifier is the same as %Z In-Reply-To: <1389897342.88.0.737767593135.issue20281@psf.upfronthosting.co.za> Message-ID: <1389900359.98.0.413085356483.issue20281@psf.upfronthosting.co.za> Mike Owens added the comment: The datetime.strftime function produces no output for %z or %Z. Very irritating. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 20:29:50 2014 From: report at bugs.python.org (SilentGhost) Date: Thu, 16 Jan 2014 19:29:50 +0000 Subject: [issue20281] time.strftime %z format specifier is the same as %Z In-Reply-To: <1389897342.88.0.737767593135.issue20281@psf.upfronthosting.co.za> Message-ID: <1389900590.87.0.451756829383.issue20281@psf.upfronthosting.co.za> SilentGhost added the comment: Mike, the note is at the very bottom of the page. datetime.strftime produces empty strings with this specifiers for na?ve objects, are the object you're testing timezone-aware? ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 20:32:14 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 16 Jan 2014 19:32:14 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? In-Reply-To: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> Message-ID: <3f4wXF6q6Vz7LjN@mail.python.org> Roundup Robot added the comment: New changeset abf87e1fbc62 by Larry Hastings in branch 'default': Issue #20226: Major improvements to Argument Clinic. http://hg.python.org/cpython/rev/abf87e1fbc62 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 20:33:31 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 16 Jan 2014 19:33:31 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? In-Reply-To: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> Message-ID: <1389900811.93.0.466247584048.issue20226@psf.upfronthosting.co.za> Larry Hastings added the comment: Done! Georg: Thanks for the suggestion, and for the reviews! Argument Clinic is improved this day. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 20:33:41 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 16 Jan 2014 19:33:41 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? In-Reply-To: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> Message-ID: <1389900821.9.0.946536999754.issue20226@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- resolution: -> fixed stage: patch review -> commit review status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 21:18:38 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Jan 2014 20:18:38 +0000 Subject: [issue20282] Argument Clinic: int with boolean default Message-ID: <1389903518.09.0.378571732154.issue20282@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Currently in many functions boolean argument parsed as int, with 'i' code. When converting this to Argument Clinic we can't write just interactive: int = False because C default becomes "Py_False". Instead we need explicitly specify c_default. interactive: int(c_default="0") = False It would be good if True/False default values be converted to 1/0 C default values for the int type. I think this is enough common situation. ---------- components: Demos and Tools messages: 208304 nosy: georg.brandl, larry, serhiy.storchaka priority: normal severity: normal status: open title: Argument Clinic: int with boolean default type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 21:25:43 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 16 Jan 2014 20:25:43 +0000 Subject: [issue20135] FAQ need list mutation answers In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za> Message-ID: <1389903943.79.0.34105734447.issue20135@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for working on this. Technically, defaults are evaluated when the 'def' statement is executed, which is normally, but not always, at the time that the module is first imported (counterexample: nested function definitions). The answer should also explicitly cover the more common mistake made with default keyword values of passing a mutable object and having it get persistently modified,and the question phrasing should reflect that. The datetime example is a great first example before getting to the more common one, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 21:29:08 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 16 Jan 2014 20:29:08 +0000 Subject: [issue19145] Inconsistent behaviour in itertools.repeat when using negative times In-Reply-To: <1380727396.47.0.412229295257.issue19145@psf.upfronthosting.co.za> Message-ID: <1389904148.36.0.629755921567.issue19145@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Current behaviors 3.4b2 >>> itertools.repeat('a', -1) repeat('a', 0) >>> itertools.repeat('a', times=-1) repeat('a') # forever >>> itertools.repeat('a', times=-2) repeat('a', -2) My opinions (same as what Raymond says -- negative == 0) The first line is correct in both behavior and representation. The second line behavior (and corresponding repr) are wrong. The third line repr is wrong but the behavior is like the first. Guido's response on pydev, in context about having a signature that can be captured by C and Python. The main different is comment about adding None to the C signature in addition to the Python 'equivalent, which has 'times=None'. "If I had complete freedom in redefining the spec I would treat positional and keyword the same, interpret absent or None to mean "forever" and explicit negative integers to mean the same as zero, and make repr show a positional integer >= 0 if the repeat isn't None. But I don't know if that's too much of a change." I think the only thing different is comment about None. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 21:31:56 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 16 Jan 2014 20:31:56 +0000 Subject: [issue20280] add "predicate" to the glossary In-Reply-To: <1389878750.92.0.454847187289.issue20280@psf.upfronthosting.co.za> Message-ID: <1389904316.24.0.163318112486.issue20280@psf.upfronthosting.co.za> Raymond Hettinger added the comment: -0 To me, this seems like unnecessary noise. The more random entries we add to the glossary, the less usable it becomes. There are many computing terms that could be added such as "recursion", "stack overflow", "buffer", "header", "packet", "basic block", "token", "sentinel", "codec", "callback", etc. We could add all of those but it wouldn't make the glossary better; it would just make it bigger. The current glossary strikes pretty good balance but could stand a little pruning here and there (i.e. remove the entry for "complex number" and trim the "parameter" entry back to a sentence or two). ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 21:36:08 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 16 Jan 2014 20:36:08 +0000 Subject: [issue20281] time.strftime %z format specifier is the same as %Z In-Reply-To: <1389897342.88.0.737767593135.issue20281@psf.upfronthosting.co.za> Message-ID: <1389904568.95.0.743121185601.issue20281@psf.upfronthosting.co.za> R. David Murray added the comment: The %z table entry exists only in the 3.4 (dev) docs, not the 3.3 docs. There is no doc change needed for 3.3, since it doesn't mention %z except in the footnote. And yes, I should have mentioned that the datetime versions only work with aware timezones. You can get an aware local time from email.utils.localtime(). (This localtime function may eventually move to the datetime module if it can be made more reliable, but it works fine for the use cases the email package needs.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 21:39:15 2014 From: report at bugs.python.org (Mike Owens) Date: Thu, 16 Jan 2014 20:39:15 +0000 Subject: [issue20281] time.strftime %z format specifier is the same as %Z In-Reply-To: <1389897342.88.0.737767593135.issue20281@psf.upfronthosting.co.za> Message-ID: <1389904755.1.0.2126216458.issue20281@psf.upfronthosting.co.za> Mike Owens added the comment: I'm looking right at the 3.3 docs right now. %z is in the table. 8.1.8. strftime() and strptime() Behavior ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 21:41:26 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 16 Jan 2014 20:41:26 +0000 Subject: [issue20281] time.strftime %z format specifier is the same as %Z In-Reply-To: <1389897342.88.0.737767593135.issue20281@psf.upfronthosting.co.za> Message-ID: <1389904886.46.0.900374419219.issue20281@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, you are correct. I'm not sure what page I was looking at before. Maybe I hadn't switched away from the python2 page. ---------- versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 21:44:27 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Jan 2014 20:44:27 +0000 Subject: [issue20283] Wrong keyword parameter name in regex pattern methods Message-ID: <1389905067.44.0.489524795145.issue20283@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Documented (in docstring and in ReST documentation) signatures of the match, search and (since 3.4) fullmatch methods of regex pattern object are: match(string[, pos[, endpos]]) search(string[, pos[, endpos]]) fullmatch(string[, pos[, endpos]]) However in implementation the first keyword argument by mistake named "pattern". This looks as nonsense. The pattern is object itself, and first argument is a string. First arguments in other methods (split, findall, etc) named "string", and module-level functions have both "pattern" and "string" parameters: match(pattern, string, flags=0) search(pattern, string, flags=0) I think we should fix this mistake. The "pattern" name is obviously wrong and is not match the documentation. ---------- components: Library (Lib) messages: 208311 nosy: ezio.melotti, pitrou, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Wrong keyword parameter name in regex pattern methods type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 22:09:24 2014 From: report at bugs.python.org (Fran Bull) Date: Thu, 16 Jan 2014 21:09:24 +0000 Subject: [issue20135] FAQ need list mutation answers In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za> Message-ID: <1389906564.87.0.386392793936.issue20135@psf.upfronthosting.co.za> Fran Bull added the comment: Perhaps a 3rd FAQ something like this?: Why is changing a list in one instance of a class also changing it in another instance of the same class? This happens: >>> class A(object): ... def __init__(self, fruit=[]): ... self.fruit = fruit ... >>> an_A = A() >>> an_A.fruit.append('apple') >>> another_A = A() >>> print another_A.fruit ['apple'] >>> another_A.fruit.append('banana') >>> print another_A.fruit ['apple', 'banana'] >>> print an_A.fruit ['apple', 'banana'] >>> print an_A.fruit is another_A.fruit True >>> print an_A.fruit is A().fruit True because of a combination of the above two FAQs, first the default argument is evaluated when the 'def' statement is executed and creates an instance of list. After that new instances of A have a variable 'fruit' that is the name for that instance of list. I'm not sure whether I should be using as general terms as possible for the Q, i.e. 'mutable object' instead of 'list'. I'll reread http://docs.python.org/devguide/documenting.html and the FAQs before writing the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 22:33:09 2014 From: report at bugs.python.org (Neil Schemenauer) Date: Thu, 16 Jan 2014 21:33:09 +0000 Subject: [issue20284] proof for concept patch for bytes formatting methods Message-ID: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> New submission from Neil Schemenauer: This is a very rough, proof of concept patch that implements %-style formatting for bytes objects. Currently it calls __format__ with a bytes argument and expects a bytes result. I've only implemented support for bytes formatting for the 'long' object. Expected behavior: >>> b'%s' % b'hello' b'hello' >>> b'%s' % 'hello' TypeError is raised >>> b'%s' % 123 b'123' >>> b'%d' % 123 b'123' Some issues: - %s support is incomplete, needs to handle width and padding. I think it should be done in formatbytes(). - PyBytes_Format function very likely has bugs, I copied it mostly from Python 2 and quickly made it run, I did very little testing. - long__format__ with a bytes argument is inefficient. It creates temporary Python objects that could be avoided. %-style formatting on bytes will be much less efficient than str in Python 2. We could inline the handling of certain types in PyBytes_Format, maybe longs only would be sufficent. - I'm not sure overloading __format__ is the best approach. Maybe we should introduce a new method, say __ascii__ instead and have PyBytes_Format call that. ---------- components: Interpreter Core files: bytes_mod.patch keywords: patch messages: 208313 nosy: nascheme priority: normal severity: normal stage: patch review status: open title: proof for concept patch for bytes formatting methods type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file33501/bytes_mod.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 16 23:15:19 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 16 Jan 2014 22:15:19 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? In-Reply-To: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> Message-ID: <3f508Q4RcVz7LjW@mail.python.org> Roundup Robot added the comment: New changeset cd3fdf21a6e4 by Larry Hastings in branch 'default': Issue #20226: Added tests for new features and regressions. http://hg.python.org/cpython/rev/cd3fdf21a6e4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 01:14:40 2014 From: report at bugs.python.org (Chris Morgan) Date: Fri, 17 Jan 2014 00:14:40 +0000 Subject: [issue19974] tarfile doesn't overwrite symlink by directory In-Reply-To: <1386935948.7.0.893963676407.issue19974@psf.upfronthosting.co.za> Message-ID: <1389917680.12.0.403574286187.issue19974@psf.upfronthosting.co.za> Chris Morgan added the comment: Testing passed on OSX Mavericks. ---------- nosy: +drpotato _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 01:26:38 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 17 Jan 2014 00:26:38 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389918398.3.0.142472810868.issue20189@psf.upfronthosting.co.za> Larry Hastings added the comment: Whoever does the review, could you post here? I feel bad enough asking y'all, maybe we don't need multiple people doing it ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 01:57:04 2014 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 17 Jan 2014 00:57:04 +0000 Subject: [issue20284] proof for concept patch for bytes formatting methods In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <1389920224.05.0.964684090662.issue20284@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 01:59:11 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 17 Jan 2014 00:59:11 +0000 Subject: [issue20285] Improve object.__doc__ and help(object) output Message-ID: <1389920351.63.0.12805701843.issue20285@psf.upfronthosting.co.za> New submission from Terry J. Reedy: >>> object.__doc__ 'The most base type' Since 'most base' can be interpreted as 'least desireable', several people on Python list (2013 Dec, "interactive help on the base object") agree that this should be improved. Even is 'most base' is interpreted as a value-free 'bottommost', there is the direction issue. Whether the root of a tree or DAG is at top or bottom or side depends on how the graph is drawn. I suggest "The superclass for all Python classes." === >>> help(object) Help on class object in module builtins: class object | The most base type === I think help(object) should display the methods defined on the object class just as it does on all the other classes. The apparent problem is that help(subclass) supresses the object methods, but it should not for object itself. ---------- messages: 208317 nosy: terry.reedy priority: normal severity: normal stage: test needed status: open title: Improve object.__doc__ and help(object) output type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 02:35:19 2014 From: report at bugs.python.org (Ali Ebrahim) Date: Fri, 17 Jan 2014 01:35:19 +0000 Subject: [issue20286] Segfault when using internal DictProxy Message-ID: <1389922519.38.0.20276094539.issue20286@psf.upfronthosting.co.za> New submission from Ali Ebrahim: Demonstration in this gist: https://gist.github.com/aebrahim/8466660 Crash info in this gist: https://gist.github.com/aebrahim/8466749 The code runs without issue on Ubuntu 12.04 (Python 2.7.3), and Windows 7 (Python 2.7.6). It also ran fine on MacOS X 10.8 (Python 2.7.2). However, it failed with MacOX X 10.9 for both 2.7.5 (version shipped by Apple) and 2.7.6 Python version information details: 2.7.2 Python 2.7.2 (default, Oct 11 2012, 20:14:37) [GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin 2.7.5 Python 2.7.5 (default, Aug 25 2013, 00:04:04) [GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin 2.7.6 Python 2.7.6 (v2.7.6:3a1db0d2747e, Nov 10 2013, 00:42:54) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin ---------- assignee: ronaldoussoren components: Macintosh messages: 208318 nosy: Ali.Ebrahim, ronaldoussoren priority: normal severity: normal status: open title: Segfault when using internal DictProxy versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 02:37:30 2014 From: report at bugs.python.org (Ali Ebrahim) Date: Fri, 17 Jan 2014 01:37:30 +0000 Subject: [issue20286] Segfault when using internal DictProxy In-Reply-To: <1389922519.38.0.20276094539.issue20286@psf.upfronthosting.co.za> Message-ID: <1389922650.93.0.896678191086.issue20286@psf.upfronthosting.co.za> Changes by Ali Ebrahim : ---------- type: -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 02:58:55 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Fri, 17 Jan 2014 01:58:55 +0000 Subject: [issue20286] Segfault when using internal DictProxy In-Reply-To: <1389922519.38.0.20276094539.issue20286@psf.upfronthosting.co.za> Message-ID: <1389923935.51.0.0728954777948.issue20286@psf.upfronthosting.co.za> Vajrasky Kok added the comment: It happens on Python 3.3 and 3.4 as well. Tested on Fedora 20. ---------- nosy: +vajrasky versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 03:18:43 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 17 Jan 2014 02:18:43 +0000 Subject: [issue20286] Segfault when using internal DictProxy In-Reply-To: <1389922519.38.0.20276094539.issue20286@psf.upfronthosting.co.za> Message-ID: <1389925123.43.0.14878848271.issue20286@psf.upfronthosting.co.za> Benjamin Peterson added the comment: s/rettype/restype/ and don't use the internal function _PyObj_FromPointer. ---------- nosy: +benjamin.peterson resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 03:29:07 2014 From: report at bugs.python.org (Reuben Garrett) Date: Fri, 17 Jan 2014 02:29:07 +0000 Subject: [issue8557] subprocess PATH semantics and portability In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za> Message-ID: <1389925747.23.0.968757528583.issue8557@psf.upfronthosting.co.za> Changes by Reuben Garrett : ---------- nosy: +RubyTuesdayDONO _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 03:35:25 2014 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 17 Jan 2014 02:35:25 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389926125.77.0.937986921815.issue20189@psf.upfronthosting.co.za> Nick Coghlan added the comment: Looking now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 06:26:13 2014 From: report at bugs.python.org (Fran Bull) Date: Fri, 17 Jan 2014 05:26:13 +0000 Subject: [issue20135] FAQ need list mutation answers In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za> Message-ID: <1389936373.94.0.0664504847093.issue20135@psf.upfronthosting.co.za> Changes by Fran Bull : ---------- keywords: +patch Added file: http://bugs.python.org/file33502/20135.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 06:48:57 2014 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 17 Jan 2014 05:48:57 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389937737.45.0.0728037063065.issue20189@psf.upfronthosting.co.za> Nick Coghlan added the comment: Larry clarified that the signature(min) change in this patch was actually restoring the Python 3.3 behaviour, so I think with the addition of some relevant test cases to the test suite, go for it :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 08:28:58 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 Jan 2014 07:28:58 +0000 Subject: [issue20086] test_locale fails with Turkish locale In-Reply-To: <1388221219.09.0.925570468901.issue20086@psf.upfronthosting.co.za> Message-ID: <3f5DRF2H9gz7LjW@mail.python.org> Roundup Robot added the comment: New changeset bac50f54d357 by Serhiy Storchaka in branch '2.7': Issue #20086: Restored the use of locale-independing mapping instead of http://hg.python.org/cpython/rev/bac50f54d357 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 08:33:51 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jan 2014 07:33:51 +0000 Subject: [issue1776674] glob.glob inconsistent Message-ID: <1389944031.71.0.744417430211.issue1776674@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Amaury, could you provide corrected patch? ---------- components: -Windows versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 08:36:00 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 17 Jan 2014 07:36:00 +0000 Subject: [issue20287] Argument Clinic: support diverting output to buffer, external file, etc Message-ID: <1389944158.18.0.307156648296.issue20287@psf.upfronthosting.co.za> New submission from Larry Hastings: The long-awaited, highly desirable "buffer" patch is here! With features I figured would never see the light of day. Changes in this patch: * New directive "output": output redirects a "field" (subsection of Clinic's generated code) to an alternate "destination" (someplace besides the output block) predefined destinations: block buffer file two-pass suppress * Alternate use of "output": output preset redirects all destinations en mass based on a precreated scenario predefined presets: original file buffer partial-buffer two-pass * New directive "destination": destination [] creates new destinations for use with "output" valid types: buffer file two-pass suppress * New directive "dump": dump dumps the contents of a destination into the current file * New directive "preserve": preserve preserves the current output in an output block (used by "file" destinations) * New directive "set": set line_prefix set line_suffix * New output template, uses PyArg_UnpackTuple * New compact output template, for simple METH_O, only one line * "args" and "kwargs" variables in C renamed to "_args" and "_kwargs" Patch is not ready for checkin, as it still needs documentation. But it's ready for code review! There's a lot of churn in the C files. That's due to the following changes, in order of frequency: * "args" -> "_args" * "kwargs" -> "_kwargs" * new concise METH_O template * PyArg_UnpackTuple generator ---------- assignee: larry files: larry.clinic.buffer.patch.1.txt messages: 208325 nosy: georg.brandl, larry, pitrou, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Argument Clinic: support diverting output to buffer, external file, etc type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file33503/larry.clinic.buffer.patch.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 08:46:47 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 17 Jan 2014 07:46:47 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1389944807.93.0.337930307094.issue20172@psf.upfronthosting.co.za> Changes by Zachary Ware : Added file: http://bugs.python.org/file33504/8cf882d09d3f.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 08:49:09 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 17 Jan 2014 07:49:09 +0000 Subject: [issue20287] Argument Clinic: support diverting output to buffer, external file, etc In-Reply-To: <1389944158.18.0.307156648296.issue20287@psf.upfronthosting.co.za> Message-ID: <1389944949.49.0.402925611022.issue20287@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 08:49:46 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 17 Jan 2014 07:49:46 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1389944986.68.0.251895677757.issue20172@psf.upfronthosting.co.za> Changes by Zachary Ware : Removed file: http://bugs.python.org/file33411/issue20172.winreg.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 08:49:54 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 17 Jan 2014 07:49:54 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1389944994.15.0.26536203752.issue20172@psf.upfronthosting.co.za> Changes by Zachary Ware : Removed file: http://bugs.python.org/file33412/issue20172.winsound.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 08:50:01 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 17 Jan 2014 07:50:01 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1389945001.02.0.522059810644.issue20172@psf.upfronthosting.co.za> Changes by Zachary Ware : Removed file: http://bugs.python.org/file33415/issue20172.msvcrt.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 08:50:07 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 17 Jan 2014 07:50:07 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1389945007.1.0.521639268707.issue20172@psf.upfronthosting.co.za> Changes by Zachary Ware : Removed file: http://bugs.python.org/file33439/issue20172._winapi.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 09:17:43 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jan 2014 08:17:43 +0000 Subject: [issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64 In-Reply-To: <1389100955.98.0.880527340764.issue20162@psf.upfronthosting.co.za> Message-ID: <1389946663.56.0.63219503183.issue20162@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Well, then it LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 09:18:30 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jan 2014 08:18:30 +0000 Subject: [issue20086] test_locale fails with Turkish locale In-Reply-To: <1388221219.09.0.925570468901.issue20086@psf.upfronthosting.co.za> Message-ID: <1389946710.59.0.50416800681.issue20086@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 09:22:00 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jan 2014 08:22:00 +0000 Subject: [issue16572] Bad multi-inheritance support in some libs like threading or multiprocessing In-Reply-To: <1354138508.41.0.9459136379.issue16572@psf.upfronthosting.co.za> Message-ID: <1389946920.13.0.0330392651573.issue16572@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Raymond, what do you think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 09:40:26 2014 From: report at bugs.python.org (Neil Schemenauer) Date: Fri, 17 Jan 2014 08:40:26 +0000 Subject: [issue20284] proof for concept patch for bytes formatting methods In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <1389948026.83.0.452131241252.issue20284@psf.upfronthosting.co.za> Neil Schemenauer added the comment: I'm attaching v2 of my proposed patch. This one is quite a bit better, IMHO. - Introduce __ascii__ as a special method, like __str__ but required to exist only if an ASCII-only format exists. - Extract PyString_Format from Python 2.7 and update it for PyBytes. - %c only accepts integers, not single character strs, maybe should accept length one byte objects. - add %a, should be useful for debugging - %s calls __bytes__ or __ascii__, otherwise gives a TypeError, should eventually support buffer API - number formats work as they do in Python 2. ---------- keywords: +needs review -patch Added file: http://bugs.python.org/file33505/bytes_mod_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 10:06:22 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 17 Jan 2014 09:06:22 +0000 Subject: [issue20284] proof for concept patch for bytes formatting methods In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <1389949582.57.0.610356686229.issue20284@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 10:06:35 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 17 Jan 2014 09:06:35 +0000 Subject: [issue20284] proof for concept patch for bytes formatting methods In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <1389949595.97.0.564041690654.issue20284@psf.upfronthosting.co.za> STINNER Victor added the comment: I reviewed your second patch on Rietveld. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 10:16:41 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 17 Jan 2014 09:16:41 +0000 Subject: [issue20162] Test test_hash_distribution fails on RHEL 6.5 / ppc64 In-Reply-To: <1389100955.98.0.880527340764.issue20162@psf.upfronthosting.co.za> Message-ID: <1389950201.05.0.829339468103.issue20162@psf.upfronthosting.co.za> STINNER Victor added the comment: @Christian: Are you ok with siphash_ppc64.patch? I'm going to push the fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 10:40:05 2014 From: report at bugs.python.org (Neil Schemenauer) Date: Fri, 17 Jan 2014 09:40:05 +0000 Subject: [issue20284] proof for concept patch for bytes formatting methods In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <1389951605.68.0.80001353972.issue20284@psf.upfronthosting.co.za> Neil Schemenauer added the comment: Uploading new patch with the following changes: - Allow length 1 bytes object as argument to %c. - Make %r an alias for %a. I will upload a draft PEP (proposed as a replacement for 461). Victor, thanks for the review. My reply is: - regarding duplicated code: almost all of the code I added came directly from Python 2.7. If it can but shared with unicode object, great. However, note that the Python 2.7 code is well tested and well optimized. - regarding the introduction of __ascii__, see my draft PEP. PEP 461 cannot be implemented, adding __bytes__ to number objects breaks backwards compatibility. - regarding the change to _datetime, I don't mind if it gets discarded but I think its useful behavior. Mostly I made it as a proof-of-concept. ---------- keywords: +patch Added file: http://bugs.python.org/file33506/bytes_mod_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 10:40:42 2014 From: report at bugs.python.org (Neil Schemenauer) Date: Fri, 17 Jan 2014 09:40:42 +0000 Subject: [issue20284] proof for concept patch for bytes formatting methods In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <1389951642.52.0.363218908001.issue20284@psf.upfronthosting.co.za> Changes by Neil Schemenauer : Added file: http://bugs.python.org/file33507/pep-draft.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 11:08:05 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jan 2014 10:08:05 +0000 Subject: [issue20283] Wrong keyword parameter name in regex pattern methods In-Reply-To: <1389905067.44.0.489524795145.issue20283@psf.upfronthosting.co.za> Message-ID: <1389953285.66.0.596498271678.issue20283@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch Added file: http://bugs.python.org/file33508/sre_pattern_string_keyword.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 11:09:08 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jan 2014 10:09:08 +0000 Subject: [issue20283] Wrong keyword parameter name in regex pattern methods In-Reply-To: <1389905067.44.0.489524795145.issue20283@psf.upfronthosting.co.za> Message-ID: <1389953348.22.0.389137597902.issue20283@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file33508/sre_pattern_string_keyword.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 11:11:21 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jan 2014 10:11:21 +0000 Subject: [issue20283] Wrong keyword parameter name in regex pattern methods In-Reply-To: <1389905067.44.0.489524795145.issue20283@psf.upfronthosting.co.za> Message-ID: <1389953481.85.0.505344652194.issue20283@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file33509/sre_pattern_string_keyword.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 11:44:14 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jan 2014 10:44:14 +0000 Subject: [issue19936] Executable permissions of Python source files In-Reply-To: <1386588201.39.0.841678145847.issue19936@psf.upfronthosting.co.za> Message-ID: <1389955454.94.0.482978907895.issue19936@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Left files with mismatched executable bits and shebangs: Python 3.4: - ./Doc/includes/email-unpack.py - ./Doc/includes/email-alternative.py - ./Doc/includes/email-dir.py x ./Tools/scripts/pydocgui.pyw x ./Lib/idlelib/idle.bat - ./Modules/_ctypes/libffi/build-ios.sh x ./Modules/_ctypes/libffi/ltmain.sh - ./Modules/_ctypes/libffi/msvcc.sh - ./Modules/_ctypes/libffi/src/arm/gentramp.sh x ./Modules/_decimal/tests/runall.bat Python 3.3: - ./Doc/includes/email-unpack.py - ./Doc/includes/email-alternative.py - ./Doc/includes/email-dir.py x ./Lib/idlelib/idle.bat - ./Modules/_ctypes/libffi/build-ios.sh x ./Modules/_ctypes/libffi/ltmain.sh - ./Modules/_ctypes/libffi/msvcc.sh - ./Modules/_ctypes/libffi/src/arm/gentramp.sh x ./Modules/_decimal/tests/runall.bat x ./PC/VS7.1/rt.bat x ./PC/VC6/rt.bat Python 2.7: - ./Doc/includes/email-unpack.py - ./Doc/includes/email-alternative.py - ./Doc/includes/email-dir.py x ./Demo/rpc/test x ./Lib/idlelib/idle.bat x ./PC/VS7.1/rt.bat x ./PC/VC6/rt.bat ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 11:59:36 2014 From: report at bugs.python.org (Steve) Date: Fri, 17 Jan 2014 10:59:36 +0000 Subject: [issue17849] Missing size argument in readline() method for httplib's class LineAndFileWrapper In-Reply-To: <1366979224.14.0.876475494511.issue17849@psf.upfronthosting.co.za> Message-ID: <1389956376.07.0.558541168382.issue17849@psf.upfronthosting.co.za> Steve added the comment: I just noticed that this is reporducible consistently with the python requests[1] module, if you route your request through a proxy. I was wondering whether I should report this as a 'requests' bug or would this be the right place to add a 'me too' ? Here's the reporducer: [steve at localhost ~/venvs]$ mkdir requests_bug [steve at localhost ~/venvs]$ cd requests_bug/ [steve at localhost ~/venvs/requests_bug]$ virtualenv . New python executable in ./bin/python Installing Setuptools..............................................................................................................................................................................................................................done. Installing Pip.....................................................................................................................................................................................................................................................................................................................................done. [steve at localhost ~/venvs/requests_bug]$ . bin/activate (requests_bug)[steve at localhost ~/venvs/requests_bug]$ pip install requests Downloading/unpacking requests Downloading requests-2.2.0.tar.gz (421kB): 421kB downloaded Running setup.py egg_info for package requests Installing collected packages: requests Running setup.py install for requests Successfully installed requests Cleaning up... (requests_bug)[steve at localhost ~/venvs/requests_bug]$ python Python 2.7.5 (default, Nov 12 2013, 16:18:42) [GCC 4.8.2 20131017 (Red Hat 4.8.2-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. You've got color, tab completion and pretty-printing. History will be saved in /home/steve/.pyhistory when you exit. Typing '\e' will open your $EDITOR with the last executed statement >>> import requests >>> requests.get('https://www.google.com/', verify=False) >>> requests.get('https://www.google.com/', verify=False, proxies={'https':'https://192.168.117.157:443'}) Traceback (most recent call last): File "", line 1, in File "/home/steve/venvs/requests_bug/lib/python2.7/site-packages/requests/api.py", line 55, in get return request('get', url, **kwargs) File "/home/steve/venvs/requests_bug/lib/python2.7/site-packages/requests/api.py", line 44, in request return session.request(method=method, url=url, **kwargs) File "/home/steve/venvs/requests_bug/lib/python2.7/site-packages/requests/sessions.py", line 383, in request resp = self.send(prep, **send_kwargs) File "/home/steve/venvs/requests_bug/lib/python2.7/site-packages/requests/sessions.py", line 486, in send r = adapter.send(request, **kwargs) File "/home/steve/venvs/requests_bug/lib/python2.7/site-packages/requests/adapters.py", line 334, in send timeout=timeout File "/home/steve/venvs/requests_bug/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py", line 475, in urlopen conn = self._get_conn(timeout=pool_timeout) File "/home/steve/venvs/requests_bug/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py", line 217, in _get_conn return conn or self._new_conn() File "/home/steve/venvs/requests_bug/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py", line 656, in _new_conn return self._prepare_conn(conn) File "/home/steve/venvs/requests_bug/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py", line 625, in _prepare_conn conn.connect() File "/home/steve/venvs/requests_bug/lib/python2.7/site-packages/requests/packages/urllib3/connection.py", line 90, in connect self._tunnel() File "/usr/lib64/python2.7/httplib.py", line 759, in _tunnel line = response.fp.readline(_MAXLINE + 1) TypeError: readline() takes exactly 1 argument (2 given) >>> cheers, - steve [1] requests-2.2.0 ---------- nosy: +lonetwin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 12:53:48 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jan 2014 11:53:48 +0000 Subject: [issue20287] Argument Clinic: support diverting output to buffer, external file, etc In-Reply-To: <1389944158.18.0.307156648296.issue20287@psf.upfronthosting.co.za> Message-ID: <1389959628.67.0.441076561049.issue20287@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Can Argument Clinic be simplified when drop support for all alternative outputs besides a side file? > * "args" and "kwargs" variables in C renamed to "_args" and "_kwargs" Why this is needed? If buildin function has "args" or "kwargs" keyword arguments, C variables can be renamed to args_value and kwargs_value, as for any reserved keywords (e.g. "default", "int"). Other changes look very good, but these are just add code churn. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 14:50:40 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 17 Jan 2014 13:50:40 +0000 Subject: [issue19936] Executable permissions of Python source files In-Reply-To: <1389955454.94.0.482978907895.issue19936@psf.upfronthosting.co.za> Message-ID: <20140117135039.GA18903@sleipnir.bytereef.org> Stefan Krah added the comment: IMO the .bat files should have the executable bit as a reminder that they're executable on Windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 15:06:13 2014 From: report at bugs.python.org (Anders Hammarquist) Date: Fri, 17 Jan 2014 14:06:13 +0000 Subject: [issue20288] HTMLParse handing of non-numeric charrefs broken Message-ID: <1389967573.45.0.115549710544.issue20288@psf.upfronthosting.co.za> New submission from Anders Hammarquist: Python 2.7 HTMLParse.py lines 185-199 (similar lines still exist in Python 3.4) match = charref.match(rawdata, i) if match: ... else: if ";" in rawdata[i:]: #bail by consuming &# self.handle_data(rawdata[0:2]) i = self.updatepos(i, 2) break if you feed a broken charref, that is non-numeric, it will pass whatever random string that happened to be at the start of rawdata to handle_data(). Eg: p = HTMLParser() p.handle_data = lambda x: sys.stdout.write(x) p.feed('

&#foo;

') will print ' _______________________________________ From report at bugs.python.org Fri Jan 17 15:18:41 2014 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 17 Jan 2014 14:18:41 +0000 Subject: [issue20288] HTMLParse handing of non-numeric charrefs broken In-Reply-To: <1389967573.45.0.115549710544.issue20288@psf.upfronthosting.co.za> Message-ID: <1389968321.0.0.215943043291.issue20288@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> ezio.melotti nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 15:27:45 2014 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 17 Jan 2014 14:27:45 +0000 Subject: [issue20135] FAQ need list mutation answers In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za> Message-ID: <1389968865.84.0.272449944373.issue20135@psf.upfronthosting.co.za> Ezio Melotti added the comment: http://docs.python.org/3/faq/design.html#why-are-default-values-shared-between-objects ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 15:47:25 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 17 Jan 2014 14:47:25 +0000 Subject: [issue20289] Make cgi.FieldStorage a context manager Message-ID: <1389970045.35.0.547540590752.issue20289@psf.upfronthosting.co.za> New submission from Brett Cannon: It has a file attribute which contains a file, so making it so it can be closed faster than cgi.FieldStorage.__del__ would be good. ---------- components: Library (Lib) messages: 208338 nosy: brett.cannon priority: normal severity: normal stage: test needed status: open title: Make cgi.FieldStorage a context manager type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 15:49:14 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 17 Jan 2014 14:49:14 +0000 Subject: [issue18394] cgi.FieldStorage triggers ResourceWarning sometimes In-Reply-To: <1373190601.25.0.575768158618.issue18394@psf.upfronthosting.co.za> Message-ID: <1389970154.97.0.411150420901.issue18394@psf.upfronthosting.co.za> Brett Cannon added the comment: While you're right, Marcel, that code which pulls out the file object form FieldStorage would probably have the file closed from underneath it, I don't know if I agree that it's a bad thing. The FieldStorage object created that file, implicitly putting it in charge of managing it. Having it guarantee that it gets closed seems to me totally reasonable and a bug not to do so. And having Bottle break as-is doesn't sway me as this is a bug fix and so updating Bottle as part of the process to support Python 3.4 is reasonable. That use of the term "leisure" is definitely a problem, though. So I'm going to make this a bug report for updating the docs to no longer use the term "leisure" and add a versionchanged note that FieldStorage will close the 'file' attribute upon deletion. I'll also opened http://bugs.python.org/issue20289 to add context manager support to FieldStorage. But since leaving files randomly open is not good I can't bring myself to revert this change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 16:00:46 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 Jan 2014 15:00:46 +0000 Subject: [issue20266] Bring Doc/faq/windows up to date In-Reply-To: <1389758449.02.0.48240700444.issue20266@psf.upfronthosting.co.za> Message-ID: <3f5QSY6Mnvz7Lkb@mail.python.org> Roundup Robot added the comment: New changeset c9706c13a005 by Zachary Ware in branch '3.3': Issue #20266: Update parts of the Windows FAQ http://hg.python.org/cpython/rev/c9706c13a005 New changeset 3cb048463ea7 by Zachary Ware in branch 'default': Issue #20266: Merge with 3.3 http://hg.python.org/cpython/rev/3cb048463ea7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 16:27:45 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 17 Jan 2014 15:27:45 +0000 Subject: [issue17849] Missing size argument in readline() method for httplib's class LineAndFileWrapper In-Reply-To: <1366979224.14.0.876475494511.issue17849@psf.upfronthosting.co.za> Message-ID: <1389972465.67.0.632682929188.issue17849@psf.upfronthosting.co.za> R. David Murray added the comment: Requests may well want to put a workaround in place. To fix it in 2.7, we need a patch that actually respects the size argument, and a unit test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 16:36:16 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 17 Jan 2014 15:36:16 +0000 Subject: [issue20135] FAQ need list mutation answers In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za> Message-ID: <1389972976.48.0.497244613063.issue20135@psf.upfronthosting.co.za> R. David Murray added the comment: I *thought* there was a FAQ entry for that. Didn't think to look for it in the design section though :(. Nor is the title likely to catch the eye of someone wondering why their default argument modifications are being unexpectedly persistent. Also, the fact that it starts out with the sentence "This type of bug commonly bites neophyte programmers" is, IMO, a clue it should be in the programming section. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 17:03:27 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 Jan 2014 16:03:27 +0000 Subject: [issue18394] cgi.FieldStorage triggers ResourceWarning sometimes In-Reply-To: <1373190601.25.0.575768158618.issue18394@psf.upfronthosting.co.za> Message-ID: <3f5Rrt5K5Rz7Lnh@mail.python.org> Roundup Robot added the comment: New changeset 13d04a8713ad by Brett Cannon in branch 'default': Issue #18394: Document that cgi.FieldStorage now cleans up after its http://hg.python.org/cpython/rev/13d04a8713ad ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 17:04:56 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 17 Jan 2014 16:04:56 +0000 Subject: [issue18394] cgi.FieldStorage triggers ResourceWarning sometimes In-Reply-To: <1373190601.25.0.575768158618.issue18394@psf.upfronthosting.co.za> Message-ID: <1389974696.39.0.989592483792.issue18394@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 17:45:10 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 Jan 2014 16:45:10 +0000 Subject: [issue20208] Clarify some things in porting HOWTO In-Reply-To: <1389287437.04.0.882737818643.issue20208@psf.upfronthosting.co.za> Message-ID: <3f5Sn20tk3z7LjS@mail.python.org> Roundup Robot added the comment: New changeset 863b8e71cfee by Brett Cannon in branch 'default': Issue #20208: Clarify some things in the Python porting HOWTO. http://hg.python.org/cpython/rev/863b8e71cfee ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 17:45:49 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 17 Jan 2014 16:45:49 +0000 Subject: [issue20208] Clarify some things in porting HOWTO In-Reply-To: <1389287437.04.0.882737818643.issue20208@psf.upfronthosting.co.za> Message-ID: <1389977149.71.0.826063355343.issue20208@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 18:06:37 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 Jan 2014 17:06:37 +0000 Subject: [issue20194] Add :deprecated: marker to formatter module docs Message-ID: <3f5TFm5dDRz7LnJ@mail.python.org> New submission from Roundup Robot: New changeset 30013dbb5bc2 by Brett Cannon in branch 'default': Issues #20194,20195: Add missing :deprecated: markers to some module http://hg.python.org/cpython/rev/30013dbb5bc2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 18:07:05 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 17 Jan 2014 17:07:05 +0000 Subject: [issue20194] Add :deprecated: marker to formatter module docs In-Reply-To: <3f5TFm5dDRz7LnJ@mail.python.org> Message-ID: <1389978425.45.0.76011281262.issue20194@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 18:07:17 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 17 Jan 2014 17:07:17 +0000 Subject: [issue20195] Add :deprecated: marker to imp docs Message-ID: <1389978437.16.0.410359334088.issue20195@psf.upfronthosting.co.za> New submission from Brett Cannon: Fixed by changeset 30013dbb5bc2 ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 18:09:16 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 17 Jan 2014 17:09:16 +0000 Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1389978556.32.0.674686287482.issue20152@psf.upfronthosting.co.za> Brett Cannon added the comment: I'm going to start tackling some of these today and checking them in directly. If I don't finish I will update the bug with what I didn't get to. ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 18:09:57 2014 From: report at bugs.python.org (kespindler) Date: Fri, 17 Jan 2014 17:09:57 +0000 Subject: [issue14031] logging module cannot format str.format log messages In-Reply-To: <1389798749.89.0.0622898806788.issue14031@psf.upfronthosting.co.za> Message-ID: kespindler added the comment: Those new examples look good. I appreciate your revisiting the issue. On Wed, Jan 15, 2014 at 7:12 AM, Vinay Sajip wrote: > > Vinay Sajip added the comment: > > Cookbook updated. See changesets 7c4f0c3dedaf and 0056aaf42bf7 for more > information - docs.python.org should update within a day. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 18:24:30 2014 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 17 Jan 2014 17:24:30 +0000 Subject: [issue20266] Bring Doc/faq/windows up to date In-Reply-To: <1389758449.02.0.48240700444.issue20266@psf.upfronthosting.co.za> Message-ID: <1389979470.08.0.639734284329.issue20266@psf.upfronthosting.co.za> Mark Lawrence added the comment: The faq doesn't mention the new launcher for Windows. Rather than write too much I'd simply cross reference this http://docs.python.org/3/using/windows.html#python-launcher-for-windows. I think this also impacts on the section "How do I make Python scripts executable?". ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 19:35:24 2014 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 17 Jan 2014 18:35:24 +0000 Subject: [issue20288] HTMLParse handing of non-numeric charrefs broken In-Reply-To: <1389967573.45.0.115549710544.issue20288@psf.upfronthosting.co.za> Message-ID: <1389983724.84.0.451305962633.issue20288@psf.upfronthosting.co.za> Ezio Melotti added the comment: Thanks for the report, this is indeed a bug. This behavior was covered by a test (see Lib/test/test_htmlparser.py:164), but _run_check feeds the chars one by one to the parser, and in that case it works correctly. While feeding the parser a whole chunk I was able to reproduce the bug. This should be fixed, and the behavior of _run_check should probably be changed too -- maybe it could test both the char-by-char and the regular feeding. ---------- nosy: +r.david.murray stage: -> needs patch versions: +Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 19:38:26 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 17 Jan 2014 18:38:26 +0000 Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1389983906.93.0.36743701662.issue20152@psf.upfronthosting.co.za> Brett Cannon added the comment: Patch for multibytecodec.c. Not sure how you calculated locations, Larry, but this file had 11 things to change, so some other work divisions might be off. ---------- Added file: http://bugs.python.org/file33510/multibytecodec_derby.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 19:42:43 2014 From: report at bugs.python.org (Cory Benfield) Date: Fri, 17 Jan 2014 18:42:43 +0000 Subject: [issue17849] Missing size argument in readline() method for httplib's class LineAndFileWrapper In-Reply-To: <1366979224.14.0.876475494511.issue17849@psf.upfronthosting.co.za> Message-ID: <1389984163.53.0.409471696395.issue17849@psf.upfronthosting.co.za> Cory Benfield added the comment: I've been messing around trying to write a test for this, and it looks like genuinely the only place this can be hit is in _tunnel(). None of the other readline() calls can be hit with the LineAndFileWrapper() wrapping the file descriptor. ---------- nosy: +Lukasa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 19:55:22 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 17 Jan 2014 18:55:22 +0000 Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1389984922.49.0.490669828725.issue20152@psf.upfronthosting.co.za> Brett Cannon added the comment: After finding out that the initial site counts were off I went through and manually counted each file in this Derby group to get a more accurate idea of how much work each file would be. Modules/cmathmodule.c: 8 sites Modules/arraymodule.c: 27 sites Modules/pyexpat.c: 11 sites Modules/fcntlmodule.c: 4 sites Modules/pwdmodule.c: 3 sites Modules/spwdmodule.c: 2 sites Modules/grpmodule.c: 3 sites ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 20:05:21 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 17 Jan 2014 19:05:21 +0000 Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1389985521.28.0.0541728460152.issue20152@psf.upfronthosting.co.za> Changes by Brett Cannon : Added file: http://bugs.python.org/file33511/grp_derby.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 20:11:42 2014 From: report at bugs.python.org (Cory Benfield) Date: Fri, 17 Jan 2014 19:11:42 +0000 Subject: [issue17849] Missing size argument in readline() method for httplib's class LineAndFileWrapper In-Reply-To: <1366979224.14.0.876475494511.issue17849@psf.upfronthosting.co.za> Message-ID: <1389985902.8.0.370954615456.issue17849@psf.upfronthosting.co.za> Cory Benfield added the comment: Alright, here's a patch. I'm not ecstatic about this test: it's utterly contrived, but it also seems to be the least bad way to reproduce this bug. Let me know if you strongly object and I'll take another swing at it (it'll probably involve extending the FakeSocket quite extensively). ---------- keywords: +patch Added file: http://bugs.python.org/file33512/readline.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 20:13:08 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 17 Jan 2014 19:13:08 +0000 Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1389985988.59.0.610058806609.issue20152@psf.upfronthosting.co.za> Changes by Brett Cannon : Added file: http://bugs.python.org/file33513/spwd_derby.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 20:13:37 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 17 Jan 2014 19:13:37 +0000 Subject: [issue20287] Argument Clinic: support diverting output to buffer, external file, etc In-Reply-To: <1389944158.18.0.307156648296.issue20287@psf.upfronthosting.co.za> Message-ID: <1389986017.73.0.680992011967.issue20287@psf.upfronthosting.co.za> Larry Hastings added the comment: If I removed support for all destinations except files, I might be able to remove fifty lines or so. However, I'm not planning on doing that. Does cryptmodule.c, which has exactly one function, really need a 20-line separate file? Also, the "file" approach often requires rearranging the file before it will work, like moving struct declarations (or at least making forward declarations) before the #include of the generated file. The change of "args" to "_args" is me planning ahead a little; I plan to add the ability to get "args" and "kwargs" passed in to the impl function, both visibly to the signature, or silently (for bizarre functions like module_connect() in Modules/sqlite/connect.c). It would be possible to do this without renaming them, but then a) it would slightly complicate the approach I plan to take, and b) it would mean adding those ugly "_value" suffixes where they aren't strictly necessary. So I elected to bite the bullet and have the code churn now, in the middle of this patch that already has some code churn. However, I've been thinking about it all morning, and maybe I should just bite the bullet and make the code generator understand values whose name is different in the parsing and impl functions. (By the way, my next major patch, enabling signatures to work for all the other builtin types besides simple functions, will have lots of unavoidable code churn. You are forewarned!) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 20:21:00 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 17 Jan 2014 19:21:00 +0000 Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1389986460.97.0.725316058504.issue20152@psf.upfronthosting.co.za> Changes by Brett Cannon : Added file: http://bugs.python.org/file33514/multibytecodec_derby.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 20:21:18 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 17 Jan 2014 19:21:18 +0000 Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1389986478.99.0.391407533084.issue20152@psf.upfronthosting.co.za> Changes by Brett Cannon : Removed file: http://bugs.python.org/file33510/multibytecodec_derby.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 20:29:28 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 17 Jan 2014 19:29:28 +0000 Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1389986968.66.0.398786184657.issue20152@psf.upfronthosting.co.za> Changes by Brett Cannon : Added file: http://bugs.python.org/file33515/pwd_derby.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 20:33:06 2014 From: report at bugs.python.org (Neil Schemenauer) Date: Fri, 17 Jan 2014 19:33:06 +0000 Subject: [issue20284] patch to implement %-interpolation for bytes (roughly PEP 461) In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <1389987186.49.0.722386532499.issue20284@psf.upfronthosting.co.za> Neil Schemenauer added the comment: Another revision of the patch, now quite close to PEP 461 as proposed. Changes from PEP 461: - include %a - add -2 command-line flag. When enabled have %s fallback to calling PyObject_Str() and encoding to ASCII and also enable %r as alias for %a. Changes from previous patch: - remove __ascii__ special method, %s will only accept objects that implement __bytes__ or the buffer API, unless -2 command line is used - use buffer API if available - add -2 command-line option - Add prototypes for PyBytes_Format and _PyUnicode_FormatLong - improve some exception messages Reference counting in PyBytes_Format is quite hairy, could use some review. The code is nearly the same as Python 2.x stringobject.c. ---------- title: proof for concept patch for bytes formatting methods -> patch to implement %-interpolation for bytes (roughly PEP 461) Added file: http://bugs.python.org/file33516/bytes_mod_v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 20:36:15 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 17 Jan 2014 19:36:15 +0000 Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1389987375.4.0.20821304284.issue20152@psf.upfronthosting.co.za> Brett Cannon added the comment: Might pick this up later today (or never), but taking a break for now. Larry, I have patches for grp, spwd, _multibytecodec, and pwd I'd like you to give a once-over to make sure I didn't miss anything. The only one that I think has an obvious improvement is in pwd where there is custom logic to deal with a PyArg_ParseTuple() failure. Does Argument Clinic have a way to specify custom logic in that instance? With these patches the TODO for this derby group is: Modules/cmathmodule.c: 8 sites Modules/arraymodule.c: 27 sites Modules/pyexpat.c: 11 sites Modules/fcntlmodule.c: 4 sites cmath might not be worth doing, though, for 3.4 as it already has custom macros to create function definitions. ---------- assignee: brett.cannon -> larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 21:30:33 2014 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 17 Jan 2014 20:30:33 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389990633.78.0.360092700002.issue20189@psf.upfronthosting.co.za> Guido van Rossum added the comment: Now looking. Note that a few parts of the patch no longer cleanly apply: hg import --no-c http://bugs.python.org/review/download/issue20189_10572.diff applying http://bugs.python.org/review/download/issue20189_10572.diff patching file Modules/_cursesmodule.c Hunk #2 FAILED at 649 1 out of 2 hunks FAILED -- saving rejects to file Modules/_cursesmodule.c.rej patching file Modules/_dbmmodule.c Hunk #3 FAILED at 310 1 out of 5 hunks FAILED -- saving rejects to file Modules/_dbmmodule.c.rej patching file Modules/_opcode.c Hunk #2 FAILED at 63 1 out of 2 hunks FAILED -- saving rejects to file Modules/_opcode.c.rej patching file Modules/zlibmodule.c Hunk #2 FAILED at 226 1 out of 8 hunks FAILED -- saving rejects to file Modules/zlibmodule.c.rej patching file Tools/clinic/clinic.py Hunk #6 FAILED at 1482 Hunk #7 succeeded at 1502 with fuzz 2 (offset -14 lines). Hunk #12 FAILED at 2393 2 out of 22 hunks FAILED -- saving rejects to file Tools/clinic/clinic.py.rej abort: patch failed to apply ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 21:37:50 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 17 Jan 2014 20:37:50 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389991070.47.0.598755826679.issue20189@psf.upfronthosting.co.za> Larry Hastings added the comment: Updating / merging / resolving now, but it will take me a few minutes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 21:50:19 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 17 Jan 2014 20:50:19 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389991819.12.0.592849432142.issue20189@psf.upfronthosting.co.za> Larry Hastings added the comment: Here's a fresh patch against trunk. It applies cleanly against current tip (725bc24f5492). ---------- Added file: http://bugs.python.org/file33517/larry.support.text_signature.on.more.types.diff.4.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 21:58:48 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 17 Jan 2014 20:58:48 +0000 Subject: [issue20287] Argument Clinic: support diverting output to buffer, external file, etc In-Reply-To: <1389944158.18.0.307156648296.issue20287@psf.upfronthosting.co.za> Message-ID: <1389992328.25.0.496961461221.issue20287@psf.upfronthosting.co.za> Larry Hastings added the comment: I have backed out the "args" -> "_args" change. Not because I'm giving up on it, or that I necessarily think it's a bad idea, but because there are some changes happening in #20189 that will make it easier / that would conflict if I attacked it now. The resulting patch is smaller than the first iteration. And since you said it was fine except for that, I assume this patch is fine and can go in? ---------- Added file: http://bugs.python.org/file33518/larry.clinic.buffer.patch.2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 22:07:49 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 17 Jan 2014 21:07:49 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389992869.08.0.16527246703.issue20189@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 22:08:16 2014 From: report at bugs.python.org (cqxz) Date: Fri, 17 Jan 2014 21:08:16 +0000 Subject: [issue20290] inspect module bug for modules with same filename Message-ID: <1389992896.56.0.367733971337.issue20290@psf.upfronthosting.co.za> New submission from cqxz: When two files have the same name and the first changes directory to the second, the inspect module can retrieve the source code for the latter incorrectly, so a simple call to inspect.stack() can be incorrect, and will fail if there are less lines in the nested module (foo/bar/mod.py) than in the calling module (foo/mod.py) foo/mod.py foo/bar/mod.py (the foo/bar/mod.py need only contain a single line, e.g. print "hello") ---------- components: Extension Modules files: mod.py messages: 208362 nosy: Nick.Rhinehart priority: normal severity: normal status: open title: inspect module bug for modules with same filename type: crash versions: Python 2.7 Added file: http://bugs.python.org/file33519/mod.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 22:17:49 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 17 Jan 2014 21:17:49 +0000 Subject: [issue20285] Improve object.__doc__ and help(object) output In-Reply-To: <1389920351.63.0.12805701843.issue20285@psf.upfronthosting.co.za> Message-ID: <1389993469.64.0.526697701508.issue20285@psf.upfronthosting.co.za> Terry J. Reedy added the comment: On python-list, Jean-Michel Pichavant pointed out that the status of object is different in 2.7. 'for new-style classes' would have to be added. 2.7 currently has the same output, but the meaning is slightly different as type and class are slightly different there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 22:21:25 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 17 Jan 2014 21:21:25 +0000 Subject: [issue20285] Improve object.__doc__ and help(object) output In-Reply-To: <1389920351.63.0.12805701843.issue20285@psf.upfronthosting.co.za> Message-ID: <1389993685.15.0.342465098512.issue20285@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Rather, 'all classes' should be 'all new-style classes'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 22:24:25 2014 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 17 Jan 2014 21:24:25 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389993865.48.0.0655914476142.issue20189@psf.upfronthosting.co.za> Guido van Rossum added the comment: I limited myself to the four files you mentioned, and they look totally fine. Together with Nick's view you should have enough core review now, right? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 22:24:52 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 Jan 2014 21:24:52 +0000 Subject: [issue20265] Bring Doc/using/windows up to date In-Reply-To: <1389757265.26.0.116885263001.issue20265@psf.upfronthosting.co.za> Message-ID: <3f5Zzm0bKgz7LjN@mail.python.org> Roundup Robot added the comment: New changeset fc52b657bcd9 by Zachary Ware in branch '3.3': Issue #20265: Updated some parts of the Using Windows document. http://hg.python.org/cpython/rev/fc52b657bcd9 New changeset 5a9171e70573 by Zachary Ware in branch 'default': Issue #20265: Merge with 3.3 http://hg.python.org/cpython/rev/5a9171e70573 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 22:25:10 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 17 Jan 2014 21:25:10 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389993910.49.0.679785531271.issue20189@psf.upfronthosting.co.za> Larry Hastings added the comment: I do. Thanks for your time! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 23:12:01 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 17 Jan 2014 22:12:01 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1389996721.21.0.785131494091.issue20189@psf.upfronthosting.co.za> Zachary Ware added the comment: A few issues with this patch: 1) help(os) raises ValueError """ Traceback (most recent call last): File "", line 1, in File "P:\ath\to\cpython\lib\_sitebuiltins.py", line 99, in __call__ return pydoc.help(*args, **kwds) File "P:\ath\to\cpython\lib\pydoc.py", line 1792, in __call__ self.help(request) File "P:\ath\to\cpython\lib\pydoc.py", line 1842, in help else: doc(request, 'Help on %s:', output=self._output) File "P:\ath\to\cpython\lib\pydoc.py", line 1578, in doc pager(render_doc(thing, title, forceload)) File "P:\ath\to\cpython\lib\pydoc.py", line 1571, in render_doc return title % desc + '\n\n' + renderer.document(object, name) File "P:\ath\to\cpython\lib\pydoc.py", line 356, in document if inspect.ismodule(object): return self.docmodule(*args) File "P:\ath\to\cpython\lib\pydoc.py", line 1142, in docmodule contents.append(self.document(value, key, name)) File "P:\ath\to\cpython\lib\pydoc.py", line 358, in document if inspect.isroutine(object): return self.docroutine(*args) File "P:\ath\to\cpython\lib\pydoc.py", line 1323, in docroutine signature = inspect.signature(object) File "P:\ath\to\cpython\lib\inspect.py", line 1551, in signature raise ValueError(msg) ValueError: no signature found for builtin function """ 2) help(pickle.dump) shows "module" as the first argument. Of course, that's true in C, but not in Python. This is the same for all module-level builtins. """ >>> help(pickle.dump) Help on built-in function dump in module _pickle: dump(module, obj, file, protocol=None, *, fix_imports=True) Write a pickled representation of obj to the open file object file. >>> pickle.dump.__text_signature__ '(module, obj, file, protocol=None, *, fix_imports=True)' """ 3) A module-level function with a positional-only parameter named 'module' in the first position causes an assertion error: Clinic block: """ /*[clinic input] _winapi.GetModuleFileName module: HMODULE / Return the fully-qualified path for the file that contains module. [clinic start generated code]*/ """ Traceback: """ P:\ath\to\cpython>PCbuild\python_d.exe Tools\clinic\clinic.py Modules\_winapi.c Error in file "Modules\_winapi.c" on line 1299: Exception raised during parsing: Traceback (most recent call last): File "Tools\clinic\clinic.py", line 1099, in parse parser.parse(block) File "Tools\clinic\clinic.py", line 2283, in parse self.state(None) File "Tools\clinic\clinic.py", line 3022, in state_terminal self.function.docstring = self.format_docstring() File "Tools\clinic\clinic.py", line 2847, in format_docstring assert isinstance(parameters[0].converter, self_converter) AssertionError """ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 17 23:46:20 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 17 Jan 2014 22:46:20 +0000 Subject: [issue17481] inspect.getfullargspec could use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1389998780.22.0.334792894005.issue17481@psf.upfronthosting.co.za> Yury Selivanov added the comment: Can somebody review the patch? I'd be cool if this lands in 3.4. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 00:39:13 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 17 Jan 2014 23:39:13 +0000 Subject: [issue20222] unittest.mock-examples doc uses builtin file which is removed in Python 3 In-Reply-To: <1389464749.27.0.908623013872.issue20222@psf.upfronthosting.co.za> Message-ID: <1390001953.19.0.318394413741.issue20222@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I think /file/open/ would work. ---------- nosy: +michael.foord, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 00:49:11 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 17 Jan 2014 23:49:11 +0000 Subject: [issue20223] inspect.signature does not support new functools.partialmethod In-Reply-To: <1389475379.56.0.443397984378.issue20223@psf.upfronthosting.co.za> Message-ID: <1390002551.74.0.0802351354186.issue20223@psf.upfronthosting.co.za> Terry J. Reedy added the comment: This strikes me as a bug introduced with the new 3.4 feature and thus a Type: behavior issue eligible for 3.4. inspect.signature should work correctly with any python-coded callable and not return a wrong answer. (And we are trying to get inspect to work with C-coded callables also in 3.4.) ---------- nosy: +terry.reedy type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 00:49:22 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 17 Jan 2014 23:49:22 +0000 Subject: [issue20223] inspect.signature does not support new functools.partialmethod In-Reply-To: <1389475379.56.0.443397984378.issue20223@psf.upfronthosting.co.za> Message-ID: <1390002562.9.0.352039211967.issue20223@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 00:51:25 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jan 2014 23:51:25 +0000 Subject: [issue20287] Argument Clinic: support diverting output to buffer, external file, etc In-Reply-To: <1389944158.18.0.307156648296.issue20287@psf.upfronthosting.co.za> Message-ID: <1390002685.56.0.794480495091.issue20287@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch is too large and I don't very conversant with this code, so I just left several minor comments on Rietveld. At first glance all looks good. All works with my patches, results are good. But I see that side fail names have extension .clinic.c. The .c.clinic extension would be better. For now clinic_test is failed: Error: Destination does not exist: 'file' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 00:56:41 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 17 Jan 2014 23:56:41 +0000 Subject: [issue20237] Ambiguous sentence in document of xml package. In-Reply-To: <1389608026.69.0.492339232238.issue20237@psf.upfronthosting.co.za> Message-ID: <1390003001.7.0.756185941286.issue20237@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I took the sentence to mean 1) more that 2). I agree that it should be revised. ---------- nosy: +terry.reedy versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 00:59:07 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 17 Jan 2014 23:59:07 +0000 Subject: [issue20254] Duplicate bytearray test on test_socket.py In-Reply-To: <1389684647.88.0.881886101386.issue20254@psf.upfronthosting.co.za> Message-ID: <1390003147.93.0.325184688789.issue20254@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +pitrou, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 01:12:21 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 18 Jan 2014 00:12:21 +0000 Subject: [issue20287] Argument Clinic: support diverting output to buffer, external file, etc In-Reply-To: <1389944158.18.0.307156648296.issue20287@psf.upfronthosting.co.za> Message-ID: <1390003941.47.0.626822316865.issue20287@psf.upfronthosting.co.za> Larry Hastings added the comment: I have a fix already in place for the clinic_test.py problem. I disagree with your proposed "foo.c.clinic" nomenclature, and there are advantages to "foo.clinic.c": double-clicking on them will launch the correct editor, and editors will automatically color them correctly. We've had this discussion before, and you weren't able to change my mind then, so please give the bikeshedding a rest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 01:17:28 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 18 Jan 2014 00:17:28 +0000 Subject: [issue20283] Wrong keyword parameter name in regex pattern methods In-Reply-To: <1389905067.44.0.489524795145.issue20283@psf.upfronthosting.co.za> Message-ID: <1390004248.1.0.263745704603.issue20283@psf.upfronthosting.co.za> Terry J. Reedy added the comment: How nasty. I agree that this is a code bug. Unfortunately in this case, the C code does keyword matching of arguments and 'corrects' the doc for anyone who tries 'string='. >>> pat.search(string='xabc', pos=1) Traceback (most recent call last): File "", line 1, in pat.search(string='xabc', pos=1) TypeError: Required argument 'pattern' (pos 1) not found >>> pat.search(pattern='xabc', pos=1) <_sre.SRE_Match object; span=(1, 4), match='abc'> I think we should only change this in 3.4 (and should do so in 3.4). ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 01:28:44 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Sat, 18 Jan 2014 00:28:44 +0000 Subject: [issue20260] Argument Clinic: add unsigned integers converters In-Reply-To: <1389720718.78.0.860738296491.issue20260@psf.upfronthosting.co.za> Message-ID: <1390004924.87.0.403430981663.issue20260@psf.upfronthosting.co.za> Ryan Smith-Roberts added the comment: socketmodule has three builtins which use PyLong_AsUnsignedLong on their arguments and would benefit from these converters, but only if they raise OverflowError. So I vote for #2. I don't think it's unreasonable to continue to have locally-defined argument converters. ---------- nosy: +rmsr _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 01:34:50 2014 From: report at bugs.python.org (=?utf-8?q?Bj=C3=B6rn_Lindqvist?=) Date: Sat, 18 Jan 2014 00:34:50 +0000 Subject: [issue4434] Embedding into a shared library fails In-Reply-To: <1227690819.98.0.0359225476492.issue4434@psf.upfronthosting.co.za> Message-ID: <1390005290.66.0.975167335551.issue4434@psf.upfronthosting.co.za> Bj?rn Lindqvist added the comment: The bug is still present on the default build which many distros uses which produces an invalid build. That means ./configure && make && make install is broken! --enable-shared should be turned on by default because many (most?) distros build with the default settings. ---------- components: +Build -Library (Lib) nosy: +Bj?rn.Lindqvist versions: +Python 2.7 -Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 02:16:28 2014 From: report at bugs.python.org (Ethan Furman) Date: Sat, 18 Jan 2014 01:16:28 +0000 Subject: [issue20284] patch to implement %-interpolation for bytes (roughly PEP 461) In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <1390007788.22.0.420471007204.issue20284@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 02:43:59 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 18 Jan 2014 01:43:59 +0000 Subject: [issue14480] os.kill on Windows should accept zero as signal In-Reply-To: <1333437794.42.0.926195578505.issue14480@psf.upfronthosting.co.za> Message-ID: <1390009439.53.0.779704159048.issue14480@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 02:47:56 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jan 2014 01:47:56 +0000 Subject: [issue20287] Argument Clinic: support diverting output to buffer, external file, etc In-Reply-To: <1389944158.18.0.307156648296.issue20287@psf.upfronthosting.co.za> Message-ID: <3f5hqG282sz7Lm0@mail.python.org> Roundup Robot added the comment: New changeset 7f6712954d5d by Larry Hastings in branch 'default': Issue #20287: Argument Clinic's output is now configurable, allowing http://hg.python.org/cpython/rev/7f6712954d5d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 02:48:31 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 18 Jan 2014 01:48:31 +0000 Subject: [issue20287] Argument Clinic: support diverting output to buffer, external file, etc In-Reply-To: <1389944158.18.0.307156648296.issue20287@psf.upfronthosting.co.za> Message-ID: <1390009711.23.0.329049063485.issue20287@psf.upfronthosting.co.za> Larry Hastings added the comment: Done! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 02:55:25 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 18 Jan 2014 01:55:25 +0000 Subject: [issue20291] Argument Clinic should understand *args and **kwargs parameters Message-ID: <1390010125.91.0.58212727704.issue20291@psf.upfronthosting.co.za> New submission from Larry Hastings: Argument Clinic currently prevents the "impl" function from ever seeing the "args" tuple or the "kwargs" dict. There should be a way to ask it to pass those values in to the "impl" function. ---------- assignee: larry messages: 208380 nosy: larry, meador.inge priority: normal severity: normal stage: needs patch status: open title: Argument Clinic should understand *args and **kwargs parameters type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 02:58:28 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 18 Jan 2014 01:58:28 +0000 Subject: [issue20178] Derby #9: Convert 52 sites to Argument Clinic across 11 files In-Reply-To: <1389140078.91.0.720761635456.issue20178@psf.upfronthosting.co.za> Message-ID: <1390010308.33.0.00512063410864.issue20178@psf.upfronthosting.co.za> Larry Hastings added the comment: Meador: I'm going to change Argument Clinic so you can get the "args" and "kwargs" values passed in to the impl. That's issue #20291; I already added you to it "nosy" list. With that change in you'll be able to convert "sqlite3.connect". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 03:43:54 2014 From: report at bugs.python.org (Ethan Furman) Date: Sat, 18 Jan 2014 02:43:54 +0000 Subject: [issue18574] BaseHTTPRequestHandler.handle_expect_100() sends invalid response In-Reply-To: <1374971787.85.0.837580893432.issue18574@psf.upfronthosting.co.za> Message-ID: <1390013034.02.0.569751442819.issue18574@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 03:46:15 2014 From: report at bugs.python.org (Ethan Furman) Date: Sat, 18 Jan 2014 02:46:15 +0000 Subject: [issue12704] Language Reference: Clarify behaviour of yield when generator is not resumed In-Reply-To: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za> Message-ID: <1390013175.35.0.09854408345.issue12704@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 03:46:49 2014 From: report at bugs.python.org (Ethan Furman) Date: Sat, 18 Jan 2014 02:46:49 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1390013209.78.0.107899754139.issue7776@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 03:48:24 2014 From: report at bugs.python.org (Ethan Furman) Date: Sat, 18 Jan 2014 02:48:24 +0000 Subject: [issue17814] Popen.stdin/stdout/stderr documentation should mention object type In-Reply-To: <1366586086.38.0.427506521088.issue17814@psf.upfronthosting.co.za> Message-ID: <1390013304.65.0.692527184642.issue17814@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 03:50:03 2014 From: report at bugs.python.org (Ethan Furman) Date: Sat, 18 Jan 2014 02:50:03 +0000 Subject: [issue17811] Improve os.readv() and os.writev() documentation and docstring In-Reply-To: <1366579468.26.0.0312151391842.issue17811@psf.upfronthosting.co.za> Message-ID: <1390013403.27.0.0179145786867.issue17811@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 05:12:36 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sat, 18 Jan 2014 04:12:36 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1390018356.18.0.922330176713.issue7776@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Rebased patch on current tip. ---------- Added file: http://bugs.python.org/file33520/issue7776.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 05:37:03 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 18 Jan 2014 04:37:03 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1390019823.54.0.56714583396.issue7776@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: -Python 2.6, Python 3.1, Python 3.2, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 05:37:32 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 18 Jan 2014 04:37:32 +0000 Subject: [issue17814] Popen.stdin/stdout/stderr documentation should mention object type In-Reply-To: <1366586086.38.0.427506521088.issue17814@psf.upfronthosting.co.za> Message-ID: <1390019852.2.0.323715143349.issue17814@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: -Python 3.1, Python 3.2, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 05:47:16 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sat, 18 Jan 2014 04:47:16 +0000 Subject: [issue20177] Derby #8: Convert 28 sites to Argument Clinic across 2 files In-Reply-To: <1389138574.32.0.892814928986.issue20177@psf.upfronthosting.co.za> Message-ID: <1390020436.5.0.285025233842.issue20177@psf.upfronthosting.co.za> Nikolaus Rath added the comment: I have started working on this (partial patch attached), but I am unsure how to handle cases where the docstring definition utilizes a macro. For example: PyDoc_STRVAR(strftime_doc, "strftime(format[, tuple]) -> string\n\ \n\ Convert a time tuple to a string according to a format specification.\n\ See the library reference manual for formatting codes. When the time tuple\n\ is not present, current time as returned by localtime() is used.\n\ \n" STRFTIME_FORMAT_CODES); I don't think STRFTIME_FORMAT_CODES will be expanded if I put it into the [clinic] comment section. Should I include the contents verbatim? Or do not convert these functions to argument clinic? ---------- keywords: +patch nosy: +Nikratio Added file: http://bugs.python.org/file33521/issue20177.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 05:50:51 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Sat, 18 Jan 2014 04:50:51 +0000 Subject: [issue20292] clinic.py str_converter with encoding throws exception Message-ID: <1390020651.69.0.606009700331.issue20292@psf.upfronthosting.co.za> New submission from Ryan Smith-Roberts: Find test file attached. The exception: Exception raised during parsing: Traceback (most recent call last): ... File "proj/python/trunk.hg/Tools/clinic/clinic.py", line 1535, in render self.parse_argument(data.parse_arguments) File "proj/python/trunk.hg/Tools/clinic/clinic.py", line 1563, in parse_argument list.append(c_repr(self.encoding)) NameError: global name 'c_repr' is not defined ---------- components: Build files: clinic_encoding_exception.c messages: 208384 nosy: larry, rmsr priority: normal severity: normal status: open title: clinic.py str_converter with encoding throws exception type: crash versions: Python 3.4 Added file: http://bugs.python.org/file33522/clinic_encoding_exception.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 06:09:21 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 18 Jan 2014 05:09:21 +0000 Subject: [issue18574] BaseHTTPRequestHandler.handle_expect_100() sends invalid response In-Reply-To: <1374971787.85.0.837580893432.issue18574@psf.upfronthosting.co.za> Message-ID: <1390021761.64.0.0873041671688.issue18574@psf.upfronthosting.co.za> Benjamin Peterson added the comment: A test would be good. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 06:21:04 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 18 Jan 2014 05:21:04 +0000 Subject: [issue17811] Improve os.readv() and os.writev() documentation and docstring In-Reply-To: <1366579468.26.0.0312151391842.issue17811@psf.upfronthosting.co.za> Message-ID: <1390022464.87.0.925584097126.issue17811@psf.upfronthosting.co.za> Benjamin Peterson added the comment: IMO, it should just refer to the glossary entry for "bytes-like object". ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 06:49:38 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jan 2014 05:49:38 +0000 Subject: [issue17814] Popen.stdin/stdout/stderr documentation should mention object type In-Reply-To: <1366586086.38.0.427506521088.issue17814@psf.upfronthosting.co.za> Message-ID: <3f5pB925yRz7LjW@mail.python.org> Roundup Robot added the comment: New changeset 946257d3c648 by Benjamin Peterson in branch '3.3': describe type of Popen streams (closes #17814) http://hg.python.org/cpython/rev/946257d3c648 New changeset 1a7d416c57ff by Benjamin Peterson in branch 'default': merge 3.3 (#17814) http://hg.python.org/cpython/rev/1a7d416c57ff ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 09:26:46 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jan 2014 08:26:46 +0000 Subject: [issue20292] clinic.py str_converter with encoding throws exception In-Reply-To: <1390020651.69.0.606009700331.issue20292@psf.upfronthosting.co.za> Message-ID: <3f5sgV2hmmz7LjW@mail.python.org> Roundup Robot added the comment: New changeset 949acdd43b45 by Larry Hastings in branch 'default': Issue #20292: Small bug fix for Argument Clinic supporting format units http://hg.python.org/cpython/rev/949acdd43b45 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 09:27:58 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 18 Jan 2014 08:27:58 +0000 Subject: [issue20292] clinic.py str_converter with encoding throws exception In-Reply-To: <1390020651.69.0.606009700331.issue20292@psf.upfronthosting.co.za> Message-ID: <1390033678.81.0.957526232012.issue20292@psf.upfronthosting.co.za> Larry Hastings added the comment: Thanks for the report! It's fixed now. Sorry about that! ---------- assignee: -> larry components: +Demos and Tools -Build resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 10:12:52 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 18 Jan 2014 09:12:52 +0000 Subject: [issue20177] Derby #8: Convert 28 sites to Argument Clinic across 2 files In-Reply-To: <1389138574.32.0.892814928986.issue20177@psf.upfronthosting.co.za> Message-ID: <1390036371.99.0.413681112914.issue20177@psf.upfronthosting.co.za> Larry Hastings added the comment: That macro, STRFTIME_FORMAT_CODES, is only used in two functions. If it were me I'd just copy and paste the text into both functions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 10:42:49 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 18 Jan 2014 09:42:49 +0000 Subject: [issue20282] Argument Clinic: int with boolean default In-Reply-To: <1389903518.09.0.378571732154.issue20282@psf.upfronthosting.co.za> Message-ID: <1390038169.27.0.791683243589.issue20282@psf.upfronthosting.co.za> Larry Hastings added the comment: I think these shouldn't be "int", they should be "bool". "bool" will allow you to use a default of False. It maps to the "p" format unit, which was new in 3.3. Back before 3.3, when someone wanted a boolean they just used "i", and relied on the fact that True turned into 1 and False turned into 0. (Even more so before 2.2, when we didn't even have True and False.) In theory it's a semantic change, because "i" only accepts ints (and True/False), whereas "p" will accept floats, lists, tuples, dicts, sets... anything with a __bool__. But the intent of code like this is clear, it's only interested in true/false. And Python has well-established rules for what is considered a true and false. So I feel like this change is an improvement. ---------- resolution: -> wont fix stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 10:54:45 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 18 Jan 2014 09:54:45 +0000 Subject: [issue20227] Argument Clinic: rename arguments in generated C? In-Reply-To: <1389524736.75.0.620647933805.issue20227@psf.upfronthosting.co.za> Message-ID: <1390038885.07.0.823923360544.issue20227@psf.upfronthosting.co.za> Larry Hastings added the comment: I have a couple big patches incoming, over the next couple of days. Here's a sneak-peek of my todo list: * buffer support just went in (#20287) * all builtins support landing maybe tomorrow (#20260) * suppress the "self" parameter on impl for METH_STATIC * allow variables to be renamed between parsing and impl functions *** * allow passing in args and kwargs into impl (#20291) The one I triple-starred is going to change the code you hacked up a *lot*. I'm not going to look at this patch before then, because that change will break the patch completely. But I'll make you a deal. If you try again *after* all of the above lands, I'll look at it, and if it's fine it can probably go in. I don't know if I said, but the obvious syntax is "foo as bar". "as" should bind more tightly than the colon for the converter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 12:43:18 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 11:43:18 +0000 Subject: [issue20293] pydoc fails with the "unspecified" default value Message-ID: <1390045398.5.0.236293557583.issue20293@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: With patch for the zlib module (issue20193) which uses the "unspecified" default value: $ ./python -m pydoc zlib Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/inspect.py", line 1997, in wrap_value value = eval(s, module_dict) File "", line 1, in NameError: name 'unspecified' is not defined During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/inspect.py", line 2000, in wrap_value value = eval(s, sys_module_dict) File "", line 1, in NameError: name 'unspecified' is not defined During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/runpy.py", line 189, in _run_module_as_main "__main__", mod_spec) File "/home/serhiy/py/cpython/Lib/runpy.py", line 87, in _run_code exec(code, run_globals) File "/home/serhiy/py/cpython/Lib/pydoc.py", line 2593, in cli() File "/home/serhiy/py/cpython/Lib/pydoc.py", line 2558, in cli help.help(arg) File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1840, in help elif request: doc(request, 'Help on %s:', output=self._output) File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1578, in doc pager(render_doc(thing, title, forceload)) File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1571, in render_doc return title % desc + '\n\n' + renderer.document(object, name) File "/home/serhiy/py/cpython/Lib/pydoc.py", line 356, in document if inspect.ismodule(object): return self.docmodule(*args) File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1142, in docmodule contents.append(self.document(value, key, name)) File "/home/serhiy/py/cpython/Lib/pydoc.py", line 358, in document if inspect.isroutine(object): return self.docroutine(*args) File "/home/serhiy/py/cpython/Lib/pydoc.py", line 1323, in docroutine signature = inspect.signature(object) File "/home/serhiy/py/cpython/Lib/inspect.py", line 1468, in signature return Signature.from_builtin(obj) File "/home/serhiy/py/cpython/Lib/inspect.py", line 2052, in from_builtin p(name, default) File "/home/serhiy/py/cpython/Lib/inspect.py", line 2038, in p default_node = RewriteSymbolics().visit(default_node) File "/home/serhiy/py/cpython/Lib/ast.py", line 245, in visit return visitor(node) File "/home/serhiy/py/cpython/Lib/inspect.py", line 2030, in visit_Name return wrap_value(node.id) File "/home/serhiy/py/cpython/Lib/inspect.py", line 2002, in wrap_value raise RuntimeError() RuntimeError ---------- messages: 208394 nosy: larry, serhiy.storchaka priority: normal severity: normal status: open title: pydoc fails with the "unspecified" default value type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 12:43:26 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 11:43:26 +0000 Subject: [issue20294] Argument Clinic: add support for __init__ Message-ID: <1390045406.06.0.938757132567.issue20294@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Currently Argument Clinic doesn't support the __init__ methods, mainly because the C implementation of this method should return int, not PyObject *. In some cases it is possible to wrap a function generated by Argument Clinic (as in Modules/_pickle.c). But not always, because the __init__ method is called with the self, args, and kwargs arguments, while Argument Clinic can generate function without kwargs. ---------- components: Demos and Tools messages: 208395 nosy: larry, serhiy.storchaka priority: normal severity: normal status: open title: Argument Clinic: add support for __init__ type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 12:47:48 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 11:47:48 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1390045668.63.0.475184120466.issue20193@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Argument Clinic: add support for __init__, pydoc fails with the "unspecified" default value _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 12:48:04 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 11:48:04 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1390045684.93.0.0709296743533.issue20193@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file33368/bz2_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 12:48:16 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 11:48:16 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1390045696.11.0.967835916076.issue20193@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file33369/lzma_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 12:48:24 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 11:48:24 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1390045704.83.0.808473800753.issue20193@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file33370/zlib_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 12:49:34 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 11:49:34 +0000 Subject: [issue20159] Derby #7: Convert 51 sites to Argument Clinic across 3 files -> Derby: Convert the ElementTree module to use Argument Clinic In-Reply-To: <1389086966.47.0.33615845784.issue20159@psf.upfronthosting.co.za> Message-ID: <1390045774.76.0.0151111580191.issue20159@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file33338/etree_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 12:49:42 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 11:49:42 +0000 Subject: [issue20159] Derby #7: Convert 51 sites to Argument Clinic across 3 files -> Derby: Convert the ElementTree module to use Argument Clinic In-Reply-To: <1389086966.47.0.33615845784.issue20159@psf.upfronthosting.co.za> Message-ID: <1390045782.9.0.91530926465.issue20159@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file33355/etree_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 12:51:18 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 11:51:18 +0000 Subject: [issue20159] Derby #7: Convert 51 sites to Argument Clinic across 3 files -> Derby: Convert the ElementTree module to use Argument Clinic In-Reply-To: <1389086966.47.0.33615845784.issue20159@psf.upfronthosting.co.za> Message-ID: <1390045878.03.0.23032647845.issue20159@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file33526/etree_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 12:47:03 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 11:47:03 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389818851.24.0.659989234035.issue20193@psf.upfronthosting.co.za> Message-ID: <1777838.vj9TRNSH4C@raxxla> Serhiy Storchaka added the comment: Updated patches use many new Argument Clinic features. The only issues left: * pydoc fails with zlib due to the "unspecified" default values (issue20293). * Constructors for compressor and decompressor objects in the bz2 and lzma modules don't use Argument Clinic. ---------- Added file: http://bugs.python.org/file33523/zlib_clinic.patch Added file: http://bugs.python.org/file33524/bz2_clinic.patch Added file: http://bugs.python.org/file33525/lzma_clinic.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r da8e8e28a616 Modules/zlibmodule.c --- a/Modules/zlibmodule.c Sat Jan 18 00:49:30 2014 -0500 +++ b/Modules/zlibmodule.c Sat Jan 18 13:29:43 2014 +0200 @@ -82,42 +82,13 @@ } /*[clinic input] +output preset file module zlib class zlib.Compress class zlib.Decompress [clinic start generated code]*/ /*[clinic end generated code: checksum=da39a3ee5e6b4b0d3255bfef95601890afd80709]*/ -PyDoc_STRVAR(compressobj__doc__, -"compressobj(level=-1, method=DEFLATED, wbits=15, memlevel=8,\n" -" strategy=Z_DEFAULT_STRATEGY[, zdict])\n" -" -- Return a compressor object.\n" -"\n" -"level is the compression level (an integer in the range 0-9; default is 6).\n" -"Higher compression levels are slower, but produce smaller results.\n" -"\n" -"method is the compression algorithm. If given, this must be DEFLATED.\n" -"\n" -"wbits is the base two logarithm of the window size (range: 8..15).\n" -"\n" -"memlevel controls the amount of memory used for internal compression state.\n" -"Valid values range from 1 to 9. Higher values result in higher memory usage,\n" -"faster compression, and smaller output.\n" -"\n" -"strategy is used to tune the compression algorithm. Possible values are\n" -"Z_DEFAULT_STRATEGY, Z_FILTERED, and Z_HUFFMAN_ONLY.\n" -"\n" -"zdict is the predefined compression dictionary - a sequence of bytes\n" -"containing subsequences that are likely to occur in the input data."); - -PyDoc_STRVAR(decompressobj__doc__, -"decompressobj([wbits[, zdict]]) -- Return a decompressor object.\n" -"\n" -"Optional arg wbits is the window buffer size.\n" -"\n" -"Optional arg zdict is the predefined compression dictionary. This must be\n" -"the same dictionary as used by the compressor that produced the input data."); - static compobject * newcompobject(PyTypeObject *type) { @@ -165,69 +136,20 @@ } /*[clinic input] +zlib.compress -zlib.compress bytes: Py_buffer Binary data to be compressed. - [ - level: int + level: int(c_default="Z_DEFAULT_COMPRESSION") = unspecified Compression level, in 0-9. - ] / -Returns compressed string. - +Returns a bytes object containing compressed data. [clinic start generated code]*/ -PyDoc_STRVAR(zlib_compress__doc__, -"compress(bytes, [level])\n" -"Returns compressed string.\n" -"\n" -" bytes\n" -" Binary data to be compressed.\n" -" level\n" -" Compression level, in 0-9."); - -#define ZLIB_COMPRESS_METHODDEF \ - {"compress", (PyCFunction)zlib_compress, METH_VARARGS, zlib_compress__doc__}, - static PyObject * -zlib_compress_impl(PyModuleDef *module, Py_buffer *bytes, int group_right_1, int level); - -static PyObject * -zlib_compress(PyModuleDef *module, PyObject *args) -{ - PyObject *return_value = NULL; - Py_buffer bytes = {NULL, NULL}; - int group_right_1 = 0; - int level = 0; - - switch (PyTuple_GET_SIZE(args)) { - case 1: - if (!PyArg_ParseTuple(args, "y*:compress", &bytes)) - return NULL; - break; - case 2: - if (!PyArg_ParseTuple(args, "y*i:compress", &bytes, &level)) - return NULL; - group_right_1 = 1; - break; - default: - PyErr_SetString(PyExc_TypeError, "zlib.compress requires 1 to 2 arguments"); - return NULL; - } - return_value = zlib_compress_impl(module, &bytes, group_right_1, level); - - /* Cleanup for bytes */ - if (bytes.obj) - PyBuffer_Release(&bytes); - - return return_value; -} - -static PyObject * -zlib_compress_impl(PyModuleDef *module, Py_buffer *bytes, int group_right_1, int level) -/*[clinic end generated code: checksum=66c4d16d0b8b9dd423648d9ef00d6a89d3363665]*/ +zlib_compress_impl(PyModuleDef *module, Py_buffer *bytes, int level) +/*[clinic end generated code: checksum=5d7dd4588788efd3516e5f4225050d6413632601]*/ { PyObject *ReturnVal = NULL; Byte *input, *output = NULL; @@ -235,9 +157,6 @@ int err; z_stream zst; - if (!group_right_1) - level = Z_DEFAULT_COMPRESSION; - if ((size_t)bytes->len > UINT_MAX) { PyErr_SetString(PyExc_OverflowError, "Size does not fit in an unsigned int"); @@ -311,6 +230,7 @@ class uint_converter(CConverter): type = 'unsigned int' converter = 'uint_converter' + c_ignored_default = "0" [python start generated code]*/ /*[python end generated code: checksum=da39a3ee5e6b4b0d3255bfef95601890afd80709]*/ @@ -346,35 +266,38 @@ return 1; } -PyDoc_STRVAR(decompress__doc__, -"decompress(string[, wbits[, bufsize]]) -- Return decompressed string.\n" -"\n" -"Optional arg wbits is the window buffer size. Optional arg bufsize is\n" -"the initial output buffer size."); +/*[clinic input] +zlib.decompress + + data: Py_buffer + Compressed data. + wbits: int(c_default="DEF_WBITS") = unspecified + The window buffer size. + bufsize: uint(c_default="DEFAULTALLOC") = unspecified + The initial output buffer size. + / + +Returns a bytes object containing the uncompressed data. +[clinic start generated code]*/ static PyObject * -PyZlib_decompress(PyObject *self, PyObject *args) +zlib_decompress_impl(PyModuleDef *module, Py_buffer *data, int wbits, unsigned int bufsize) +/*[clinic end generated code: checksum=9e5464e72df9cb5fee73df662dbcaed867e01d32]*/ { PyObject *result_str = NULL; - Py_buffer pinput; Byte *input; unsigned int length; int err; - int wsize=DEF_WBITS; - unsigned int bufsize = DEFAULTALLOC, new_bufsize; + unsigned int new_bufsize; z_stream zst; - if (!PyArg_ParseTuple(args, "y*|iO&:decompress", - &pinput, &wsize, uint_converter, &bufsize)) - return NULL; - - if ((size_t)pinput.len > UINT_MAX) { + if ((size_t)data->len > UINT_MAX) { PyErr_SetString(PyExc_OverflowError, "Size does not fit in an unsigned int"); goto error; } - input = pinput.buf; - length = (unsigned int)pinput.len; + input = data->buf; + length = (unsigned int)data->len; if (bufsize == 0) bufsize = 1; @@ -390,7 +313,7 @@ zst.zfree = PyZlib_Free; zst.next_out = (Byte *)PyBytes_AS_STRING(result_str); zst.next_in = (Byte *)input; - err = inflateInit2(&zst, wsize); + err = inflateInit2(&zst, wbits); switch(err) { case(Z_OK): @@ -456,32 +379,45 @@ if (_PyBytes_Resize(&result_str, zst.total_out) < 0) goto error; - PyBuffer_Release(&pinput); return result_str; error: - PyBuffer_Release(&pinput); Py_XDECREF(result_str); return NULL; } +/*[clinic input] +zlib.compressobj + + level: int(c_default="Z_DEFAULT_COMPRESSION") = Z_DEFAULT_COMPRESSION + The compression level (an integer in the range 0-9; default is 6). + Higher compression levels are slower, but produce smaller results. + method: int(c_default="DEFLATED") = DEFLATED + The compression algorithm. If given, this must be DEFLATED. + wbits: int(c_default="MAX_WBITS") = MAX_WBITS + The base two logarithm of the window size (range: 8..15). + memLevel: int(c_default="DEF_MEM_LEVEL") = DEF_MEM_LEVEL + Controls the amount of memory used for internal compression state. + Valid values range from 1 to 9. Higher values result in higher memory + usage, faster compression, and smaller output. + strategy: int(c_default="Z_DEFAULT_STRATEGY") = Z_DEFAULT_STRATEGY + Used to tune the compression algorithm. Possible values are + Z_DEFAULT_STRATEGY, Z_FILTERED, and Z_HUFFMAN_ONLY. + zdict: Py_buffer = None + The predefined compression dictionary - a sequence of bytes + containing subsequences that are likely to occur in the input data. + +Return a compressor object. +[clinic start generated code]*/ + static PyObject * -PyZlib_compressobj(PyObject *selfptr, PyObject *args, PyObject *kwargs) +zlib_compressobj_impl(PyModuleDef *module, int level, int method, int wbits, int memLevel, int strategy, Py_buffer *zdict) +/*[clinic end generated code: checksum=89e5a6c1449caa9ed76f1baad066600e985151a9]*/ { compobject *self = NULL; - int level=Z_DEFAULT_COMPRESSION, method=DEFLATED; - int wbits=MAX_WBITS, memLevel=DEF_MEM_LEVEL, strategy=0, err; - Py_buffer zdict; - static char *kwlist[] = {"level", "method", "wbits", - "memLevel", "strategy", "zdict", NULL}; + int err; - zdict.buf = NULL; /* Sentinel, so we can tell whether zdict was supplied. */ - if (!PyArg_ParseTupleAndKeywords(args, kwargs, "|iiiiiy*:compressobj", - kwlist, &level, &method, &wbits, - &memLevel, &strategy, &zdict)) - return NULL; - - if (zdict.buf != NULL && (size_t)zdict.len > UINT_MAX) { + if (zdict->buf != NULL && (size_t)zdict->len > UINT_MAX) { PyErr_SetString(PyExc_OverflowError, "zdict length does not fit in an unsigned int"); goto error; @@ -499,11 +435,11 @@ switch(err) { case (Z_OK): self->is_initialised = 1; - if (zdict.buf == NULL) { + if (zdict->buf == NULL) { goto success; } else { err = deflateSetDictionary(&self->zst, - zdict.buf, (unsigned int)zdict.len); + zdict->buf, (unsigned int)zdict->len); switch (err) { case (Z_OK): goto success; @@ -531,22 +467,28 @@ Py_XDECREF(self); self = NULL; success: - if (zdict.buf != NULL) - PyBuffer_Release(&zdict); return (PyObject*)self; } +/*[clinic input] +zlib.decompressobj + + wbits: int(c_default="DEF_WBITS") = unspecified + The window buffer size. + zdict: object(c_default="NULL") = unspecified + The predefined compression dictionary. This must be the same + dictionary as used by the compressor that produced the input data. + +Return a decompressor object. +[clinic start generated code]*/ + static PyObject * -PyZlib_decompressobj(PyObject *selfptr, PyObject *args, PyObject *kwargs) +zlib_decompressobj_impl(PyModuleDef *module, int wbits, PyObject *zdict) +/*[clinic end generated code: checksum=8ccd583fbd631798566d415933cd44440c8a74b5]*/ { - static char *kwlist[] = {"wbits", "zdict", NULL}; - int wbits=DEF_WBITS, err; + int err; compobject *self; - PyObject *zdict=NULL; - if (!PyArg_ParseTupleAndKeywords(args, kwargs, "|iO:decompressobj", - kwlist, &wbits, &zdict)) - return NULL; if (zdict != NULL && !PyObject_CheckBuffer(zdict)) { PyErr_SetString(PyExc_TypeError, "zdict argument must support the buffer protocol"); @@ -614,37 +556,43 @@ Dealloc(self); } -PyDoc_STRVAR(comp_compress__doc__, -"compress(data) -- Return a string containing data compressed.\n" -"\n" -"After calling this function, some of the input data may still\n" -"be stored in internal buffers for later processing.\n" -"Call the flush() method to clear these buffers."); +/*[clinic input] +zlib.Compress.compress + self: self(type="compobject *") + data: Py_buffer + Binary data to be compressed. + / + +Returns a bytes object containing compressed data. + +After calling this function, some of the input data may still +be stored in internal buffers for later processing. +Call the flush() method to clear these buffers. +[clinic start generated code]*/ static PyObject * -PyZlib_objcompress(compobject *self, PyObject *args) +zlib_Compress_compress_impl(compobject *self, Py_buffer *data) +/*[clinic end generated code: checksum=5d5cd791cbc6a7f4b6de4ec12c085c88d4d3e31c]*/ { int err; unsigned int inplen; unsigned int length = DEFAULTALLOC, new_length; - PyObject *RetVal = NULL; + PyObject *RetVal; Py_buffer pinput; Byte *input; unsigned long start_total_out; - if (!PyArg_ParseTuple(args, "y*:compress", &pinput)) - return NULL; if ((size_t)pinput.len > UINT_MAX) { PyErr_SetString(PyExc_OverflowError, "Size does not fit in an unsigned int"); - goto error_outer; + return NULL; } - input = pinput.buf; - inplen = (unsigned int)pinput.len; + input = data->buf; + inplen = (unsigned int)data->len; if (!(RetVal = PyBytes_FromStringAndSize(NULL, length))) - goto error_outer; + return NULL; ENTER_ZLIB(self); @@ -667,7 +615,7 @@ new_length = UINT_MAX; if (_PyBytes_Resize(&RetVal, new_length) < 0) { Py_CLEAR(RetVal); - goto error; + goto done; } self->zst.next_out = (unsigned char *)PyBytes_AS_STRING(RetVal) + length; @@ -685,18 +633,15 @@ if (err != Z_OK && err != Z_BUF_ERROR) { zlib_error(self->zst, err, "while compressing data"); - Py_DECREF(RetVal); - RetVal = NULL; - goto error; + Py_CLEAR(RetVal); + goto done; } if (_PyBytes_Resize(&RetVal, self->zst.total_out - start_total_out) < 0) { Py_CLEAR(RetVal); } - error: + done: LEAVE_ZLIB(self); - error_outer: - PyBuffer_Release(&pinput); return RetVal; } @@ -744,11 +689,9 @@ } /*[clinic input] - zlib.Decompress.decompress self: self(type="compobject *") - data: Py_buffer The binary data to decompress. max_length: uint = 0 @@ -757,58 +700,16 @@ the unconsumed_tail attribute. / -Return a string containing the decompressed version of the data. +Return a bytes object containing the decompressed version of the data. After calling this function, some of the input data may still be stored in internal buffers for later processing. Call the flush() method to clear these buffers. [clinic start generated code]*/ -PyDoc_STRVAR(zlib_Decompress_decompress__doc__, -"decompress(data, max_length=0)\n" -"Return a string containing the decompressed version of the data.\n" -"\n" -" data\n" -" The binary data to decompress.\n" -" max_length\n" -" The maximum allowable length of the decompressed data.\n" -" Unconsumed input data will be stored in\n" -" the unconsumed_tail attribute.\n" -"\n" -"After calling this function, some of the input data may still be stored in\n" -"internal buffers for later processing.\n" -"Call the flush() method to clear these buffers."); - -#define ZLIB_DECOMPRESS_DECOMPRESS_METHODDEF \ - {"decompress", (PyCFunction)zlib_Decompress_decompress, METH_VARARGS, zlib_Decompress_decompress__doc__}, - -static PyObject * -zlib_Decompress_decompress_impl(compobject *self, Py_buffer *data, unsigned int max_length); - -static PyObject * -zlib_Decompress_decompress(PyObject *self, PyObject *args) -{ - PyObject *return_value = NULL; - Py_buffer data = {NULL, NULL}; - unsigned int max_length = 0; - - if (!PyArg_ParseTuple(args, - "y*|O&:decompress", - &data, uint_converter, &max_length)) - goto exit; - return_value = zlib_Decompress_decompress_impl((compobject *)self, &data, max_length); - -exit: - /* Cleanup for data */ - if (data.obj) - PyBuffer_Release(&data); - - return return_value; -} - static PyObject * zlib_Decompress_decompress_impl(compobject *self, Py_buffer *data, unsigned int max_length) -/*[clinic end generated code: checksum=e0058024c4a97b411d2e2197791b89fde175f76f]*/ +/*[clinic end generated code: checksum=755cccc9087bfe55486b7e15fa7e2ab60b4c86d6]*/ { int err; unsigned int old_length, length = DEFAULTALLOC; @@ -928,29 +829,31 @@ return RetVal; } -PyDoc_STRVAR(comp_flush__doc__, -"flush( [mode] ) -- Return a string containing any remaining compressed data.\n" -"\n" -"mode can be one of the constants Z_SYNC_FLUSH, Z_FULL_FLUSH, Z_FINISH; the\n" -"default value used when mode is not specified is Z_FINISH.\n" -"If mode == Z_FINISH, the compressor object can no longer be used after\n" -"calling the flush() method. Otherwise, more data can still be compressed."); +/*[clinic input] +zlib.Compress.flush + + self: self(type="compobject *") + mode: int(c_default="Z_FINISH") = Z_FINISH + One of the constants Z_SYNC_FLUSH, Z_FULL_FLUSH, Z_FINISH. + If mode == Z_FINISH, the compressor object can no longer be used after + calling the flush() method. Otherwise, more data can still be compressed. + / + +Return a bytes object containing any remaining compressed data. +[clinic start generated code]*/ static PyObject * -PyZlib_flush(compobject *self, PyObject *args) +zlib_Compress_flush_impl(compobject *self, int mode) +/*[clinic end generated code: checksum=a203f4cefc9de727aa1d2ea39d11c0a16c32041a]*/ { int err; unsigned int length = DEFAULTALLOC, new_length; PyObject *RetVal; - int flushmode = Z_FINISH; unsigned long start_total_out; - if (!PyArg_ParseTuple(args, "|i:flush", &flushmode)) - return NULL; - /* Flushing with Z_NO_FLUSH is a no-op, so there's no point in doing any work at all; just return an empty string. */ - if (flushmode == Z_NO_FLUSH) { + if (mode == Z_NO_FLUSH) { return PyBytes_FromStringAndSize(NULL, 0); } @@ -965,7 +868,7 @@ self->zst.next_out = (unsigned char *)PyBytes_AS_STRING(RetVal); Py_BEGIN_ALLOW_THREADS - err = deflate(&(self->zst), flushmode); + err = deflate(&(self->zst), mode); Py_END_ALLOW_THREADS /* while Z_OK and the output buffer is full, there might be more output, @@ -985,14 +888,14 @@ length = new_length; Py_BEGIN_ALLOW_THREADS - err = deflate(&(self->zst), flushmode); + err = deflate(&(self->zst), mode); Py_END_ALLOW_THREADS } - /* If flushmode is Z_FINISH, we also have to call deflateEnd() to free + /* If mode is Z_FINISH, we also have to call deflateEnd() to free various data structures. Note we should only get Z_STREAM_END when - flushmode is Z_FINISH, but checking both for safety*/ - if (err == Z_STREAM_END && flushmode == Z_FINISH) { + mode is Z_FINISH, but checking both for safety*/ + if (err == Z_STREAM_END && mode == Z_FINISH) { err = deflateEnd(&(self->zst)); if (err != Z_OK) { zlib_error(self->zst, err, "while finishing compression"); @@ -1034,25 +937,9 @@ Return a copy of the compression object. [clinic start generated code]*/ -PyDoc_STRVAR(zlib_Compress_copy__doc__, -"copy()\n" -"Return a copy of the compression object."); - -#define ZLIB_COMPRESS_COPY_METHODDEF \ - {"copy", (PyCFunction)zlib_Compress_copy, METH_NOARGS, zlib_Compress_copy__doc__}, - -static PyObject * -zlib_Compress_copy_impl(compobject *self); - -static PyObject * -zlib_Compress_copy(PyObject *self, PyObject *Py_UNUSED(ignored)) -{ - return zlib_Compress_copy_impl((compobject *)self); -} - static PyObject * zlib_Compress_copy_impl(compobject *self) -/*[clinic end generated code: checksum=d57a7911deb7940e85a8d7e65af20b6e2df69000]*/ +/*[clinic end generated code: checksum=5144aa153c21e805afa5c19e5b48cf8e6480b5da]*/ { compobject *retval = NULL; int err; @@ -1102,11 +989,17 @@ return NULL; } -PyDoc_STRVAR(decomp_copy__doc__, -"copy() -- Return a copy of the decompression object."); +/*[clinic input] +zlib.Decompress.copy + + self: self(type="compobject *") + +Return a copy of the decompression object. +[clinic start generated code]*/ static PyObject * -PyZlib_uncopy(compobject *self) +zlib_Decompress_copy_impl(compobject *self) +/*[clinic end generated code: checksum=02a883a2a510c8ccfeef3f89e317a275bfe8c094]*/ { compobject *retval = NULL; int err; @@ -1158,24 +1051,27 @@ } #endif -PyDoc_STRVAR(decomp_flush__doc__, -"flush( [length] ) -- Return a string containing any remaining\n" -"decompressed data. length, if given, is the initial size of the\n" -"output buffer.\n" -"\n" -"The decompressor object can no longer be used after this call."); +/*[clinic input] +zlib.Decompress.flush + + self: self(type="compobject *") + length: uint(c_default="DEFAULTALLOC") = unspecified + the initial size of the output buffer. + / + +Return a bytes object containing any remaining decompressed data. +[clinic start generated code]*/ static PyObject * -PyZlib_unflush(compobject *self, PyObject *args) +zlib_Decompress_flush_impl(compobject *self, unsigned int length) +/*[clinic end generated code: checksum=db6fb753ab698e22afe3957c9da9e5e77f4bfc08]*/ { int err; - unsigned int length = DEFAULTALLOC, new_length; + unsigned int new_length; PyObject * retval = NULL; unsigned long start_total_out; Py_ssize_t size; - if (!PyArg_ParseTuple(args, "|O&:flush", uint_converter, &length)) - return NULL; if (length == 0) { PyErr_SetString(PyExc_ValueError, "length must be greater than zero"); return NULL; @@ -1251,12 +1147,12 @@ return retval; } +#include "zlibmodule.clinic.c" + static PyMethodDef comp_methods[] = { - {"compress", (binaryfunc)PyZlib_objcompress, METH_VARARGS, - comp_compress__doc__}, - {"flush", (binaryfunc)PyZlib_flush, METH_VARARGS, - comp_flush__doc__}, + ZLIB_COMPRESS_COMPRESS_METHODDEF + ZLIB_COMPRESS_FLUSH_METHODDEF #ifdef HAVE_ZLIB_COPY ZLIB_COMPRESS_COPY_METHODDEF #endif @@ -1266,11 +1162,9 @@ static PyMethodDef Decomp_methods[] = { ZLIB_DECOMPRESS_DECOMPRESS_METHODDEF - {"flush", (binaryfunc)PyZlib_unflush, METH_VARARGS, - decomp_flush__doc__}, + ZLIB_DECOMPRESS_FLUSH_METHODDEF #ifdef HAVE_ZLIB_COPY - {"copy", (PyCFunction)PyZlib_uncopy, METH_NOARGS, - decomp_copy__doc__}, + ZLIB_DECOMPRESS_COPY_METHODDEF #endif {NULL, NULL} }; @@ -1283,95 +1177,95 @@ {NULL}, }; -PyDoc_STRVAR(adler32__doc__, -"adler32(string[, start]) -- Compute an Adler-32 checksum of string.\n" -"\n" -"An optional starting value can be specified. The returned checksum is\n" -"an integer."); +/*[clinic input] +zlib.adler32 + + data: Py_buffer + value: unsigned_int(bitwise=True) = 1 + Starting value of the checksum. + / + +Compute an Adler-32 checksum of data. + +The returned checksum is an integer. +[clinic start generated code]*/ static PyObject * -PyZlib_adler32(PyObject *self, PyObject *args) +zlib_adler32_impl(PyModuleDef *module, Py_buffer *data, unsigned int value) +/*[clinic end generated code: checksum=51d6d75ee655c78af8c968fdb4c11d97e62c67d5]*/ { - unsigned int adler32val = 1; /* adler32(0L, Z_NULL, 0) */ - Py_buffer pbuf; - - if (!PyArg_ParseTuple(args, "y*|I:adler32", &pbuf, &adler32val)) - return NULL; /* Releasing the GIL for very small buffers is inefficient and may lower performance */ - if (pbuf.len > 1024*5) { - unsigned char *buf = pbuf.buf; - Py_ssize_t len = pbuf.len; + if (data->len > 1024*5) { + unsigned char *buf = data->buf; + Py_ssize_t len = data->len; Py_BEGIN_ALLOW_THREADS /* Avoid truncation of length for very large buffers. adler32() takes length as an unsigned int, which may be narrower than Py_ssize_t. */ while ((size_t)len > UINT_MAX) { - adler32val = adler32(adler32val, buf, UINT_MAX); + value = adler32(value, buf, UINT_MAX); buf += (size_t) UINT_MAX; len -= (size_t) UINT_MAX; } - adler32val = adler32(adler32val, buf, (unsigned int)len); + value = adler32(value, buf, (unsigned int)len); Py_END_ALLOW_THREADS } else { - adler32val = adler32(adler32val, pbuf.buf, (unsigned int)pbuf.len); + value = adler32(value, data->buf, (unsigned int)data->len); } - PyBuffer_Release(&pbuf); - return PyLong_FromUnsignedLong(adler32val & 0xffffffffU); + return PyLong_FromUnsignedLong(value & 0xffffffffU); } -PyDoc_STRVAR(crc32__doc__, -"crc32(string[, start]) -- Compute a CRC-32 checksum of string.\n" -"\n" -"An optional starting value can be specified. The returned checksum is\n" -"an integer."); +/*[clinic input] +zlib.crc32 + + data: Py_buffer + value: unsigned_int(bitwise=True) = 0 + Starting value of the checksum. + / + +Compute a CRC-32 checksum of data. + +The returned checksum is an integer. +[clinic start generated code]*/ static PyObject * -PyZlib_crc32(PyObject *self, PyObject *args) +zlib_crc32_impl(PyModuleDef *module, Py_buffer *data, unsigned int value) +/*[clinic end generated code: checksum=c1e986e74fe7b62369998a71a81ebeb9b73e8d4c]*/ { - unsigned int crc32val = 0; /* crc32(0L, Z_NULL, 0) */ - Py_buffer pbuf; int signed_val; - if (!PyArg_ParseTuple(args, "y*|I:crc32", &pbuf, &crc32val)) - return NULL; /* Releasing the GIL for very small buffers is inefficient and may lower performance */ - if (pbuf.len > 1024*5) { - unsigned char *buf = pbuf.buf; - Py_ssize_t len = pbuf.len; + if (data->len > 1024*5) { + unsigned char *buf = data->buf; + Py_ssize_t len = data->len; Py_BEGIN_ALLOW_THREADS /* Avoid truncation of length for very large buffers. crc32() takes length as an unsigned int, which may be narrower than Py_ssize_t. */ while ((size_t)len > UINT_MAX) { - crc32val = crc32(crc32val, buf, UINT_MAX); + value = crc32(value, buf, UINT_MAX); buf += (size_t) UINT_MAX; len -= (size_t) UINT_MAX; } - signed_val = crc32(crc32val, buf, (unsigned int)len); + signed_val = crc32(value, buf, (unsigned int)len); Py_END_ALLOW_THREADS } else { - signed_val = crc32(crc32val, pbuf.buf, (unsigned int)pbuf.len); + signed_val = crc32(value, data->buf, (unsigned int)data->len); } - PyBuffer_Release(&pbuf); return PyLong_FromUnsignedLong(signed_val & 0xffffffffU); } static PyMethodDef zlib_methods[] = { - {"adler32", (PyCFunction)PyZlib_adler32, METH_VARARGS, - adler32__doc__}, + ZLIB_ADLER32_METHODDEF ZLIB_COMPRESS_METHODDEF - {"compressobj", (PyCFunction)PyZlib_compressobj, METH_VARARGS|METH_KEYWORDS, - compressobj__doc__}, - {"crc32", (PyCFunction)PyZlib_crc32, METH_VARARGS, - crc32__doc__}, - {"decompress", (PyCFunction)PyZlib_decompress, METH_VARARGS, - decompress__doc__}, - {"decompressobj", (PyCFunction)PyZlib_decompressobj, METH_VARARGS|METH_KEYWORDS, - decompressobj__doc__}, + ZLIB_COMPRESSOBJ_METHODDEF + ZLIB_CRC32_METHODDEF + ZLIB_DECOMPRESS_METHODDEF + ZLIB_DECOMPRESSOBJ_METHODDEF {NULL, NULL} }; diff -r da8e8e28a616 Modules/zlibmodule.clinic.c --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Modules/zlibmodule.clinic.c Sat Jan 18 13:29:43 2014 +0200 @@ -0,0 +1,410 @@ +/*[clinic input] +preserve +[clinic start generated code]*/ + +PyDoc_STRVAR(zlib_compress__doc__, +"compress(bytes, level=unspecified)\n" +"Returns a bytes object containing compressed data.\n" +"\n" +" bytes\n" +" Binary data to be compressed.\n" +" level\n" +" Compression level, in 0-9."); + +#define ZLIB_COMPRESS_METHODDEF \ + {"compress", (PyCFunction)zlib_compress, METH_VARARGS, zlib_compress__doc__}, + +static PyObject * +zlib_compress_impl(PyModuleDef *module, Py_buffer *bytes, int level); + +static PyObject * +zlib_compress(PyModuleDef *module, PyObject *args) +{ + PyObject *return_value = NULL; + Py_buffer bytes = {NULL, NULL}; + int level = Z_DEFAULT_COMPRESSION; + + if (!PyArg_ParseTuple(args, + "y*|i:compress", + &bytes, &level)) + goto exit; + return_value = zlib_compress_impl(module, &bytes, level); + +exit: + /* Cleanup for bytes */ + if (bytes.obj) + PyBuffer_Release(&bytes); + + return return_value; +} + +PyDoc_STRVAR(zlib_decompress__doc__, +"decompress(data, wbits=unspecified, bufsize=unspecified)\n" +"Returns a bytes object containing the uncompressed data.\n" +"\n" +" data\n" +" Compressed data.\n" +" wbits\n" +" The window buffer size.\n" +" bufsize\n" +" The initial output buffer size."); + +#define ZLIB_DECOMPRESS_METHODDEF \ + {"decompress", (PyCFunction)zlib_decompress, METH_VARARGS, zlib_decompress__doc__}, + +static PyObject * +zlib_decompress_impl(PyModuleDef *module, Py_buffer *data, int wbits, unsigned int bufsize); + +static PyObject * +zlib_decompress(PyModuleDef *module, PyObject *args) +{ + PyObject *return_value = NULL; + Py_buffer data = {NULL, NULL}; + int wbits = DEF_WBITS; + unsigned int bufsize = DEFAULTALLOC; + + if (!PyArg_ParseTuple(args, + "y*|iO&:decompress", + &data, &wbits, uint_converter, &bufsize)) + goto exit; + return_value = zlib_decompress_impl(module, &data, wbits, bufsize); + +exit: + /* Cleanup for data */ + if (data.obj) + PyBuffer_Release(&data); + + return return_value; +} + +PyDoc_STRVAR(zlib_compressobj__doc__, +"compressobj(level=Z_DEFAULT_COMPRESSION, method=DEFLATED, wbits=MAX_WBITS, memLevel=DEF_MEM_LEVEL, strategy=Z_DEFAULT_STRATEGY, zdict=None)\n" +"Return a compressor object.\n" +"\n" +" level\n" +" The compression level (an integer in the range 0-9; default is 6).\n" +" Higher compression levels are slower, but produce smaller results.\n" +" method\n" +" The compression algorithm. If given, this must be DEFLATED.\n" +" wbits\n" +" The base two logarithm of the window size (range: 8..15).\n" +" memLevel\n" +" Controls the amount of memory used for internal compression state.\n" +" Valid values range from 1 to 9. Higher values result in higher memory\n" +" usage, faster compression, and smaller output.\n" +" strategy\n" +" Used to tune the compression algorithm. Possible values are\n" +" Z_DEFAULT_STRATEGY, Z_FILTERED, and Z_HUFFMAN_ONLY.\n" +" zdict\n" +" The predefined compression dictionary - a sequence of bytes\n" +" containing subsequences that are likely to occur in the input data."); + +#define ZLIB_COMPRESSOBJ_METHODDEF \ + {"compressobj", (PyCFunction)zlib_compressobj, METH_VARARGS|METH_KEYWORDS, zlib_compressobj__doc__}, + +static PyObject * +zlib_compressobj_impl(PyModuleDef *module, int level, int method, int wbits, int memLevel, int strategy, Py_buffer *zdict); + +static PyObject * +zlib_compressobj(PyModuleDef *module, PyObject *args, PyObject *kwargs) +{ + PyObject *return_value = NULL; + static char *_keywords[] = {"level", "method", "wbits", "memLevel", "strategy", "zdict", NULL}; + int level = Z_DEFAULT_COMPRESSION; + int method = DEFLATED; + int wbits = MAX_WBITS; + int memLevel = DEF_MEM_LEVEL; + int strategy = Z_DEFAULT_STRATEGY; + Py_buffer zdict = {NULL, NULL}; + + if (!PyArg_ParseTupleAndKeywords(args, kwargs, + "|iiiiiy*:compressobj", _keywords, + &level, &method, &wbits, &memLevel, &strategy, &zdict)) + goto exit; + return_value = zlib_compressobj_impl(module, level, method, wbits, memLevel, strategy, &zdict); + +exit: + /* Cleanup for zdict */ + if (zdict.obj) + PyBuffer_Release(&zdict); + + return return_value; +} + +PyDoc_STRVAR(zlib_decompressobj__doc__, +"decompressobj(wbits=unspecified, zdict=unspecified)\n" +"Return a decompressor object.\n" +"\n" +" wbits\n" +" The window buffer size.\n" +" zdict\n" +" The predefined compression dictionary. This must be the same\n" +" dictionary as used by the compressor that produced the input data."); + +#define ZLIB_DECOMPRESSOBJ_METHODDEF \ + {"decompressobj", (PyCFunction)zlib_decompressobj, METH_VARARGS|METH_KEYWORDS, zlib_decompressobj__doc__}, + +static PyObject * +zlib_decompressobj_impl(PyModuleDef *module, int wbits, PyObject *zdict); + +static PyObject * +zlib_decompressobj(PyModuleDef *module, PyObject *args, PyObject *kwargs) +{ + PyObject *return_value = NULL; + static char *_keywords[] = {"wbits", "zdict", NULL}; + int wbits = DEF_WBITS; + PyObject *zdict = NULL; + + if (!PyArg_ParseTupleAndKeywords(args, kwargs, + "|iO:decompressobj", _keywords, + &wbits, &zdict)) + goto exit; + return_value = zlib_decompressobj_impl(module, wbits, zdict); + +exit: + return return_value; +} + +PyDoc_STRVAR(zlib_Compress_compress__doc__, +"compress(data)\n" +"Returns a bytes object containing compressed data.\n" +"\n" +" data\n" +" Binary data to be compressed.\n" +"\n" +"After calling this function, some of the input data may still\n" +"be stored in internal buffers for later processing.\n" +"Call the flush() method to clear these buffers."); + +#define ZLIB_COMPRESS_COMPRESS_METHODDEF \ + {"compress", (PyCFunction)zlib_Compress_compress, METH_VARARGS, zlib_Compress_compress__doc__}, + +static PyObject * +zlib_Compress_compress_impl(compobject *self, Py_buffer *data); + +static PyObject * +zlib_Compress_compress(PyObject *self, PyObject *args) +{ + PyObject *return_value = NULL; + Py_buffer data = {NULL, NULL}; + + if (!PyArg_ParseTuple(args, + "y*:compress", + &data)) + goto exit; + return_value = zlib_Compress_compress_impl((compobject *)self, &data); + +exit: + /* Cleanup for data */ + if (data.obj) + PyBuffer_Release(&data); + + return return_value; +} + +PyDoc_STRVAR(zlib_Decompress_decompress__doc__, +"decompress(data, max_length=0)\n" +"Return a bytes object containing the decompressed version of the data.\n" +"\n" +" data\n" +" The binary data to decompress.\n" +" max_length\n" +" The maximum allowable length of the decompressed data.\n" +" Unconsumed input data will be stored in\n" +" the unconsumed_tail attribute.\n" +"\n" +"After calling this function, some of the input data may still be stored in\n" +"internal buffers for later processing.\n" +"Call the flush() method to clear these buffers."); + +#define ZLIB_DECOMPRESS_DECOMPRESS_METHODDEF \ + {"decompress", (PyCFunction)zlib_Decompress_decompress, METH_VARARGS, zlib_Decompress_decompress__doc__}, + +static PyObject * +zlib_Decompress_decompress_impl(compobject *self, Py_buffer *data, unsigned int max_length); + +static PyObject * +zlib_Decompress_decompress(PyObject *self, PyObject *args) +{ + PyObject *return_value = NULL; + Py_buffer data = {NULL, NULL}; + unsigned int max_length = 0; + + if (!PyArg_ParseTuple(args, + "y*|O&:decompress", + &data, uint_converter, &max_length)) + goto exit; + return_value = zlib_Decompress_decompress_impl((compobject *)self, &data, max_length); + +exit: + /* Cleanup for data */ + if (data.obj) + PyBuffer_Release(&data); + + return return_value; +} + +PyDoc_STRVAR(zlib_Compress_flush__doc__, +"flush(mode=Z_FINISH)\n" +"Return a bytes object containing any remaining compressed data.\n" +"\n" +" mode\n" +" One of the constants Z_SYNC_FLUSH, Z_FULL_FLUSH, Z_FINISH.\n" +" If mode == Z_FINISH, the compressor object can no longer be used after\n" +" calling the flush() method. Otherwise, more data can still be compressed."); + +#define ZLIB_COMPRESS_FLUSH_METHODDEF \ + {"flush", (PyCFunction)zlib_Compress_flush, METH_VARARGS, zlib_Compress_flush__doc__}, + +static PyObject * +zlib_Compress_flush_impl(compobject *self, int mode); + +static PyObject * +zlib_Compress_flush(PyObject *self, PyObject *args) +{ + PyObject *return_value = NULL; + int mode = Z_FINISH; + + if (!PyArg_ParseTuple(args, + "|i:flush", + &mode)) + goto exit; + return_value = zlib_Compress_flush_impl((compobject *)self, mode); + +exit: + return return_value; +} + +PyDoc_STRVAR(zlib_Compress_copy__doc__, +"copy()\n" +"Return a copy of the compression object."); + +#define ZLIB_COMPRESS_COPY_METHODDEF \ + {"copy", (PyCFunction)zlib_Compress_copy, METH_NOARGS, zlib_Compress_copy__doc__}, + +static PyObject * +zlib_Compress_copy_impl(compobject *self); + +static PyObject * +zlib_Compress_copy(PyObject *self, PyObject *Py_UNUSED(ignored)) +{ + return zlib_Compress_copy_impl((compobject *)self); +} + +PyDoc_STRVAR(zlib_Decompress_copy__doc__, +"copy()\n" +"Return a copy of the decompression object."); + +#define ZLIB_DECOMPRESS_COPY_METHODDEF \ + {"copy", (PyCFunction)zlib_Decompress_copy, METH_NOARGS, zlib_Decompress_copy__doc__}, + +static PyObject * +zlib_Decompress_copy_impl(compobject *self); + +static PyObject * +zlib_Decompress_copy(PyObject *self, PyObject *Py_UNUSED(ignored)) +{ + return zlib_Decompress_copy_impl((compobject *)self); +} + +PyDoc_STRVAR(zlib_Decompress_flush__doc__, +"flush(length=unspecified)\n" +"Return a bytes object containing any remaining decompressed data.\n" +"\n" +" length\n" +" the initial size of the output buffer."); + +#define ZLIB_DECOMPRESS_FLUSH_METHODDEF \ + {"flush", (PyCFunction)zlib_Decompress_flush, METH_VARARGS, zlib_Decompress_flush__doc__}, + +static PyObject * +zlib_Decompress_flush_impl(compobject *self, unsigned int length); + +static PyObject * +zlib_Decompress_flush(PyObject *self, PyObject *args) +{ + PyObject *return_value = NULL; + unsigned int length = DEFAULTALLOC; + + if (!PyArg_ParseTuple(args, + "|O&:flush", + uint_converter, &length)) + goto exit; + return_value = zlib_Decompress_flush_impl((compobject *)self, length); + +exit: + return return_value; +} + +PyDoc_STRVAR(zlib_adler32__doc__, +"adler32(data, value=1)\n" +"Compute an Adler-32 checksum of data.\n" +"\n" +" value\n" +" Starting value of the checksum.\n" +"\n" +"The returned checksum is an integer."); + +#define ZLIB_ADLER32_METHODDEF \ + {"adler32", (PyCFunction)zlib_adler32, METH_VARARGS, zlib_adler32__doc__}, + +static PyObject * +zlib_adler32_impl(PyModuleDef *module, Py_buffer *data, unsigned int value); + +static PyObject * +zlib_adler32(PyModuleDef *module, PyObject *args) +{ + PyObject *return_value = NULL; + Py_buffer data = {NULL, NULL}; + unsigned int value = 1; + + if (!PyArg_ParseTuple(args, + "y*|I:adler32", + &data, &value)) + goto exit; + return_value = zlib_adler32_impl(module, &data, value); + +exit: + /* Cleanup for data */ + if (data.obj) + PyBuffer_Release(&data); + + return return_value; +} + +PyDoc_STRVAR(zlib_crc32__doc__, +"crc32(data, value=0)\n" +"Compute a CRC-32 checksum of data.\n" +"\n" +" value\n" +" Starting value of the checksum.\n" +"\n" +"The returned checksum is an integer."); + +#define ZLIB_CRC32_METHODDEF \ + {"crc32", (PyCFunction)zlib_crc32, METH_VARARGS, zlib_crc32__doc__}, + +static PyObject * +zlib_crc32_impl(PyModuleDef *module, Py_buffer *data, unsigned int value); + +static PyObject * +zlib_crc32(PyModuleDef *module, PyObject *args) +{ + PyObject *return_value = NULL; + Py_buffer data = {NULL, NULL}; + unsigned int value = 0; + + if (!PyArg_ParseTuple(args, + "y*|I:crc32", + &data, &value)) + goto exit; + return_value = zlib_crc32_impl(module, &data, value); + +exit: + /* Cleanup for data */ + if (data.obj) + PyBuffer_Release(&data); + + return return_value; +} +/*[clinic end generated code: checksum=a3e6ec63e5450da1c0f4feb0b959a8e53b1196a5]*/ -------------- next part -------------- diff -r da8e8e28a616 Modules/_bz2module.c --- a/Modules/_bz2module.c Sat Jan 18 00:49:30 2014 -0500 +++ b/Modules/_bz2module.c Sat Jan 18 13:29:28 2014 +0200 @@ -196,44 +196,59 @@ return NULL; } -PyDoc_STRVAR(BZ2Compressor_compress__doc__, -"compress(data) -> bytes\n" -"\n" -"Provide data to the compressor object. Returns a chunk of\n" -"compressed data if possible, or b'' otherwise.\n" -"\n" -"When you have finished providing data to the compressor, call the\n" -"flush() method to finish the compression process.\n"); +/*[clinic input] +output preset file +module bz2 +class bz2.BZ2Compressor +class bz2.BZ2Decompressor +[clinic start generated code]*/ +/*[clinic end generated code: checksum=da39a3ee5e6b4b0d3255bfef95601890afd80709]*/ + +/*[clinic input] +bz2.BZ2Compressor.compress + + self: self(type="BZ2Compressor *") + data: Py_buffer + / + +Provide data to the compressor object. + +Returns a chunk of compressed data if possible, or b'' otherwise. + +When you have finished providing data to the compressor, call the +flush() method to finish the compression process. +[clinic start generated code]*/ static PyObject * -BZ2Compressor_compress(BZ2Compressor *self, PyObject *args) +bz2_BZ2Compressor_compress_impl(BZ2Compressor *self, Py_buffer *data) +/*[clinic end generated code: checksum=ee7e32540a3194b61bf10a81e214057760f366e2]*/ { - Py_buffer buffer; PyObject *result = NULL; - if (!PyArg_ParseTuple(args, "y*:compress", &buffer)) - return NULL; - ACQUIRE_LOCK(self); if (self->flushed) PyErr_SetString(PyExc_ValueError, "Compressor has been flushed"); else - result = compress(self, buffer.buf, buffer.len, BZ_RUN); + result = compress(self, data->buf, data->len, BZ_RUN); RELEASE_LOCK(self); - PyBuffer_Release(&buffer); return result; } -PyDoc_STRVAR(BZ2Compressor_flush__doc__, -"flush() -> bytes\n" -"\n" -"Finish the compression process. Returns the compressed data left\n" -"in internal buffers.\n" -"\n" -"The compressor object may not be used after this method is called.\n"); +/*[clinic input] +bz2.BZ2Compressor.flush + + self: self(type="BZ2Compressor *") + +Finish the compression process. + +Returns the compressed data left in internal buffers. + +The compressor object may not be used after this method is called. +[clinic start generated code]*/ static PyObject * -BZ2Compressor_flush(BZ2Compressor *self, PyObject *noargs) +bz2_BZ2Compressor_flush_impl(BZ2Compressor *self) +/*[clinic end generated code: checksum=174aede133d77dccb63a6a15d5ecdc5de77a03e9]*/ { PyObject *result = NULL; @@ -324,14 +339,7 @@ Py_TYPE(self)->tp_free((PyObject *)self); } -static PyMethodDef BZ2Compressor_methods[] = { - {"compress", (PyCFunction)BZ2Compressor_compress, METH_VARARGS, - BZ2Compressor_compress__doc__}, - {"flush", (PyCFunction)BZ2Compressor_flush, METH_NOARGS, - BZ2Compressor_flush__doc__}, - {"__getstate__", (PyCFunction)BZ2Compressor_getstate, METH_NOARGS}, - {NULL} -}; +static PyMethodDef BZ2Compressor_methods[]; PyDoc_STRVAR(BZ2Compressor__doc__, "BZ2Compressor(compresslevel=9)\n" @@ -451,32 +459,34 @@ return NULL; } -PyDoc_STRVAR(BZ2Decompressor_decompress__doc__, -"decompress(data) -> bytes\n" -"\n" -"Provide data to the decompressor object. Returns a chunk of\n" -"decompressed data if possible, or b'' otherwise.\n" -"\n" -"Attempting to decompress data after the end of stream is reached\n" -"raises an EOFError. Any data found after the end of the stream\n" -"is ignored and saved in the unused_data attribute.\n"); +/*[clinic input] +bz2.BZ2Decompressor.decompress + + self: self(type="BZ2Decompressor *") + data: Py_buffer + / + +Provide data to the decompressor object. + +Returns a chunk of decompressed data if possible, or b'' otherwise. + +Attempting to decompress data after the end of stream is reached +raises an EOFError. Any data found after the end of the stream +is ignored and saved in the unused_data attribute. +[clinic start generated code]*/ static PyObject * -BZ2Decompressor_decompress(BZ2Decompressor *self, PyObject *args) +bz2_BZ2Decompressor_decompress_impl(BZ2Decompressor *self, Py_buffer *data) +/*[clinic end generated code: checksum=39f4c8064d9219f2bfd709fd9004487617588b32]*/ { - Py_buffer buffer; PyObject *result = NULL; - if (!PyArg_ParseTuple(args, "y*:decompress", &buffer)) - return NULL; - ACQUIRE_LOCK(self); if (self->eof) PyErr_SetString(PyExc_EOFError, "End of stream already reached"); else - result = decompress(self, buffer.buf, buffer.len); + result = decompress(self, data->buf, data->len); RELEASE_LOCK(self); - PyBuffer_Release(&buffer); return result; } @@ -535,9 +545,17 @@ Py_TYPE(self)->tp_free((PyObject *)self); } +#include "_bz2module.clinic.c" + +static PyMethodDef BZ2Compressor_methods[] = { + BZ2_BZ2COMPRESSOR_COMPRESS_METHODDEF + BZ2_BZ2COMPRESSOR_FLUSH_METHODDEF + {"__getstate__", (PyCFunction)BZ2Compressor_getstate, METH_NOARGS}, + {NULL} +}; + static PyMethodDef BZ2Decompressor_methods[] = { - {"decompress", (PyCFunction)BZ2Decompressor_decompress, METH_VARARGS, - BZ2Decompressor_decompress__doc__}, + BZ2_BZ2DECOMPRESSOR_DECOMPRESS_METHODDEF {"__getstate__", (PyCFunction)BZ2Decompressor_getstate, METH_NOARGS}, {NULL} }; diff -r da8e8e28a616 Modules/_bz2module.clinic.c --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Modules/_bz2module.clinic.c Sat Jan 18 13:29:28 2014 +0200 @@ -0,0 +1,95 @@ +/*[clinic input] +preserve +[clinic start generated code]*/ + +PyDoc_STRVAR(bz2_BZ2Compressor_compress__doc__, +"compress(data)\n" +"Provide data to the compressor object.\n" +"\n" +"Returns a chunk of compressed data if possible, or b\'\' otherwise.\n" +"\n" +"When you have finished providing data to the compressor, call the\n" +"flush() method to finish the compression process."); + +#define BZ2_BZ2COMPRESSOR_COMPRESS_METHODDEF \ + {"compress", (PyCFunction)bz2_BZ2Compressor_compress, METH_VARARGS, bz2_BZ2Compressor_compress__doc__}, + +static PyObject * +bz2_BZ2Compressor_compress_impl(BZ2Compressor *self, Py_buffer *data); + +static PyObject * +bz2_BZ2Compressor_compress(PyObject *self, PyObject *args) +{ + PyObject *return_value = NULL; + Py_buffer data = {NULL, NULL}; + + if (!PyArg_ParseTuple(args, + "y*:compress", + &data)) + goto exit; + return_value = bz2_BZ2Compressor_compress_impl((BZ2Compressor *)self, &data); + +exit: + /* Cleanup for data */ + if (data.obj) + PyBuffer_Release(&data); + + return return_value; +} + +PyDoc_STRVAR(bz2_BZ2Compressor_flush__doc__, +"flush()\n" +"Finish the compression process.\n" +"\n" +"Returns the compressed data left in internal buffers.\n" +"\n" +"The compressor object may not be used after this method is called."); + +#define BZ2_BZ2COMPRESSOR_FLUSH_METHODDEF \ + {"flush", (PyCFunction)bz2_BZ2Compressor_flush, METH_NOARGS, bz2_BZ2Compressor_flush__doc__}, + +static PyObject * +bz2_BZ2Compressor_flush_impl(BZ2Compressor *self); + +static PyObject * +bz2_BZ2Compressor_flush(PyObject *self, PyObject *Py_UNUSED(ignored)) +{ + return bz2_BZ2Compressor_flush_impl((BZ2Compressor *)self); +} + +PyDoc_STRVAR(bz2_BZ2Decompressor_decompress__doc__, +"decompress(data)\n" +"Provide data to the decompressor object.\n" +"\n" +"Returns a chunk of decompressed data if possible, or b\'\' otherwise.\n" +"\n" +"Attempting to decompress data after the end of stream is reached\n" +"raises an EOFError. Any data found after the end of the stream\n" +"is ignored and saved in the unused_data attribute."); + +#define BZ2_BZ2DECOMPRESSOR_DECOMPRESS_METHODDEF \ + {"decompress", (PyCFunction)bz2_BZ2Decompressor_decompress, METH_VARARGS, bz2_BZ2Decompressor_decompress__doc__}, + +static PyObject * +bz2_BZ2Decompressor_decompress_impl(BZ2Decompressor *self, Py_buffer *data); + +static PyObject * +bz2_BZ2Decompressor_decompress(PyObject *self, PyObject *args) +{ + PyObject *return_value = NULL; + Py_buffer data = {NULL, NULL}; + + if (!PyArg_ParseTuple(args, + "y*:decompress", + &data)) + goto exit; + return_value = bz2_BZ2Decompressor_decompress_impl((BZ2Decompressor *)self, &data); + +exit: + /* Cleanup for data */ + if (data.obj) + PyBuffer_Release(&data); + + return return_value; +} +/*[clinic end generated code: checksum=6a5a32ee8b92560800074ba0e1b40954494d3a60]*/ -------------- next part -------------- diff -r da8e8e28a616 Modules/_lzmamodule.c --- a/Modules/_lzmamodule.c Sat Jan 18 00:49:30 2014 -0500 +++ b/Modules/_lzmamodule.c Sat Jan 18 13:28:47 2014 +0200 @@ -298,36 +298,37 @@ return options; } -static void * -parse_filter_spec(lzma_filter *f, PyObject *spec) +static int +lzma_filter_converter(PyObject *spec, void *ptr) { + lzma_filter *f = (lzma_filter *)ptr; PyObject *id_obj; if (!PyMapping_Check(spec)) { PyErr_SetString(PyExc_TypeError, "Filter specifier must be a dict or dict-like object"); - return NULL; + return 0; } id_obj = PyMapping_GetItemString(spec, "id"); if (id_obj == NULL) { if (PyErr_ExceptionMatches(PyExc_KeyError)) PyErr_SetString(PyExc_ValueError, "Filter specifier must have an \"id\" entry"); - return NULL; + return 0; } f->id = PyLong_AsUnsignedLongLong(id_obj); Py_DECREF(id_obj); if (PyErr_Occurred()) - return NULL; + return 0; switch (f->id) { case LZMA_FILTER_LZMA1: case LZMA_FILTER_LZMA2: f->options = parse_filter_spec_lzma(spec); - return f->options; + return f->options != NULL; case LZMA_FILTER_DELTA: f->options = parse_filter_spec_delta(spec); - return f->options; + return f->options != NULL; case LZMA_FILTER_X86: case LZMA_FILTER_POWERPC: case LZMA_FILTER_IA64: @@ -335,10 +336,10 @@ case LZMA_FILTER_ARMTHUMB: case LZMA_FILTER_SPARC: f->options = parse_filter_spec_bcj(spec); - return f->options; + return f->options != NULL; default: PyErr_Format(PyExc_ValueError, "Invalid filter ID: %llu", f->id); - return NULL; + return 0; } } @@ -369,7 +370,7 @@ for (i = 0; i < num_filters; i++) { int ok = 1; PyObject *spec = PySequence_GetItem(filterspecs, i); - if (spec == NULL || parse_filter_spec(&filters[i], spec) == NULL) + if (spec == NULL || !lzma_filter_converter(spec, &filters[i])) ok = 0; Py_XDECREF(spec); if (!ok) { @@ -468,6 +469,34 @@ } +/*[clinic input] +output preset file +module lzma +class lzma.LZMACompressor +class lzma.LZMADecompressor +[clinic start generated code]*/ +/*[clinic end generated code: checksum=da39a3ee5e6b4b0d3255bfef95601890afd80709]*/ + +/*[python input] + +class lzma_vli_converter(CConverter): + type = 'lzma_vli' + converter = 'lzma_vli_converter' + +class lzma_filter_converter(CConverter): + type = 'lzma_filter' + converter = 'lzma_filter_converter' + c_default = c_ignored_default = "{LZMA_VLI_UNKNOWN, NULL}" + + def cleanup(self): + name = ensure_legal_c_identifier(self.name) + return "".join(["if (", name, ".id != LZMA_VLI_UNKNOWN)\n", + " PyMem_Free(", name, ".options);\n"]) + +[python start generated code]*/ +/*[python end generated code: checksum=da39a3ee5e6b4b0d3255bfef95601890afd80709]*/ + + /* LZMACompressor class. */ static PyObject * @@ -512,44 +541,51 @@ return NULL; } -PyDoc_STRVAR(Compressor_compress_doc, -"compress(data) -> bytes\n" -"\n" -"Provide data to the compressor object. Returns a chunk of\n" -"compressed data if possible, or b\"\" otherwise.\n" -"\n" -"When you have finished providing data to the compressor, call the\n" -"flush() method to finish the conversion process.\n"); +/*[clinic input] +lzma.LZMACompressor.compress + + self: self(type="Compressor *") + data: Py_buffer + / + +Provide data to the compressor object. + +Returns a chunk of compressed data if possible, or b'' otherwise. + +When you have finished providing data to the compressor, call the +flush() method to finish the compression process. +[clinic start generated code]*/ static PyObject * -Compressor_compress(Compressor *self, PyObject *args) +lzma_LZMACompressor_compress_impl(Compressor *self, Py_buffer *data) +/*[clinic end generated code: checksum=a6c82b0b3892e151f9fc04f1b6a56566754de6b5]*/ { - Py_buffer buffer; PyObject *result = NULL; - if (!PyArg_ParseTuple(args, "y*:compress", &buffer)) - return NULL; - ACQUIRE_LOCK(self); if (self->flushed) PyErr_SetString(PyExc_ValueError, "Compressor has been flushed"); else - result = compress(self, buffer.buf, buffer.len, LZMA_RUN); + result = compress(self, data->buf, data->len, LZMA_RUN); RELEASE_LOCK(self); - PyBuffer_Release(&buffer); return result; } -PyDoc_STRVAR(Compressor_flush_doc, -"flush() -> bytes\n" -"\n" -"Finish the compression process. Returns the compressed data left\n" -"in internal buffers.\n" -"\n" -"The compressor object cannot be used after this method is called.\n"); +/*[clinic input] +lzma.LZMACompressor.flush + + self: self(type="Compressor *") + +Finish the compression process. + +Returns the compressed data left in internal buffers. + +The compressor object may not be used after this method is called. +[clinic start generated code]*/ static PyObject * -Compressor_flush(Compressor *self, PyObject *noargs) +lzma_LZMACompressor_flush_impl(Compressor *self) +/*[clinic end generated code: checksum=418006f2533b8ca25a3e2d7949769e05bb593cc9]*/ { PyObject *result = NULL; @@ -738,14 +774,7 @@ Py_TYPE(self)->tp_free((PyObject *)self); } -static PyMethodDef Compressor_methods[] = { - {"compress", (PyCFunction)Compressor_compress, METH_VARARGS, - Compressor_compress_doc}, - {"flush", (PyCFunction)Compressor_flush, METH_NOARGS, - Compressor_flush_doc}, - {"__getstate__", (PyCFunction)Compressor_getstate, METH_NOARGS}, - {NULL} -}; +static PyMethodDef Compressor_methods[]; PyDoc_STRVAR(Compressor_doc, "LZMACompressor(format=FORMAT_XZ, check=-1, preset=None, filters=None)\n" @@ -872,32 +901,34 @@ return NULL; } -PyDoc_STRVAR(Decompressor_decompress_doc, -"decompress(data) -> bytes\n" -"\n" -"Provide data to the decompressor object. Returns a chunk of\n" -"decompressed data if possible, or b\"\" otherwise.\n" -"\n" -"Attempting to decompress data after the end of the stream is\n" -"reached raises an EOFError. Any data found after the end of the\n" -"stream is ignored, and saved in the unused_data attribute.\n"); +/*[clinic input] +lzma.LZMADecompressor.decompress + + self: self(type="Decompressor *") + data: Py_buffer + / + +Provide data to the decompressor object. + +Returns a chunk of decompressed data if possible, or b'' otherwise. + +Attempting to decompress data after the end of stream is reached +raises an EOFError. Any data found after the end of the stream +is ignored and saved in the unused_data attribute. +[clinic start generated code]*/ static PyObject * -Decompressor_decompress(Decompressor *self, PyObject *args) +lzma_LZMADecompressor_decompress_impl(Decompressor *self, Py_buffer *data) +/*[clinic end generated code: checksum=24be3317e1ba0ef15cfa4aa0bf2d6f4dccc697b0]*/ { - Py_buffer buffer; PyObject *result = NULL; - if (!PyArg_ParseTuple(args, "y*:decompress", &buffer)) - return NULL; - ACQUIRE_LOCK(self); if (self->eof) PyErr_SetString(PyExc_EOFError, "Already at end of stream"); else - result = decompress(self, buffer.buf, buffer.len); + result = decompress(self, data->buf, data->len); RELEASE_LOCK(self); - PyBuffer_Release(&buffer); return result; } @@ -1033,12 +1064,7 @@ Py_TYPE(self)->tp_free((PyObject *)self); } -static PyMethodDef Decompressor_methods[] = { - {"decompress", (PyCFunction)Decompressor_decompress, METH_VARARGS, - Decompressor_decompress_doc}, - {"__getstate__", (PyCFunction)Decompressor_getstate, METH_NOARGS}, - {NULL} -}; +static PyMethodDef Decompressor_methods[]; PyDoc_STRVAR(Decompressor_check_doc, "ID of the integrity check used by the input stream."); @@ -1124,48 +1150,42 @@ /* Module-level functions. */ -PyDoc_STRVAR(is_check_supported_doc, -"is_check_supported(check_id) -> bool\n" -"\n" -"Test whether the given integrity check is supported.\n" -"\n" -"Always returns True for CHECK_NONE and CHECK_CRC32.\n"); +/*[clinic input] +lzma.is_check_supported + check_id: int + / + +Test whether the given integrity check is supported. + +Always returns True for CHECK_NONE and CHECK_CRC32. +[clinic start generated code]*/ static PyObject * -is_check_supported(PyObject *self, PyObject *args) +lzma_is_check_supported_impl(PyModuleDef *module, int check_id) +/*[clinic end generated code: checksum=66986a6983dff2315fbe4e8b4ea79c8ed25c6406]*/ { - int check_id; - - if (!PyArg_ParseTuple(args, "i:is_check_supported", &check_id)) - return NULL; - return PyBool_FromLong(lzma_check_is_supported(check_id)); } -PyDoc_STRVAR(_encode_filter_properties_doc, -"_encode_filter_properties(filter) -> bytes\n" -"\n" -"Return a bytes object encoding the options (properties) of the filter\n" -"specified by *filter* (a dict).\n" -"\n" -"The result does not include the filter ID itself, only the options.\n"); +/*[clinic input] +lzma._encode_filter_properties + filter: lzma_filter(c_default="{LZMA_VLI_UNKNOWN, NULL}") + / + +Return a bytes object encoding the options (properties) of the filter specified by *filter* (a dict). + +The result does not include the filter ID itself, only the options. +[clinic start generated code]*/ static PyObject * -_encode_filter_properties(PyObject *self, PyObject *args) +lzma__encode_filter_properties_impl(PyModuleDef *module, lzma_filter filter) +/*[clinic end generated code: checksum=1c3f9391ea615088d00c0a855a7a02eca63890d4]*/ { - PyObject *filterspec; - lzma_filter filter; lzma_ret lzret; uint32_t encoded_size; PyObject *result = NULL; - if (!PyArg_ParseTuple(args, "O:_encode_filter_properties", &filterspec)) - return NULL; - - if (parse_filter_spec(&filter, filterspec) == NULL) - return NULL; - lzret = lzma_properties_size(&encoded_size, &filter); if (catch_lzma_error(lzret)) goto error; @@ -1179,37 +1199,36 @@ if (catch_lzma_error(lzret)) goto error; - PyMem_Free(filter.options); return result; error: Py_XDECREF(result); - PyMem_Free(filter.options); return NULL; } -PyDoc_STRVAR(_decode_filter_properties_doc, -"_decode_filter_properties(filter_id, encoded_props) -> dict\n" -"\n" -"Return a dict describing a filter with ID *filter_id*, and options\n" -"(properties) decoded from the bytes object *encoded_props*.\n"); +/*[clinic input] +lzma._decode_filter_properties + filter_id: lzma_vli + encoded_props: Py_buffer + / + +Return a bytes object encoding the options (properties) of the filter specified by *filter* (a dict). + +The result does not include the filter ID itself, only the options. +[clinic start generated code]*/ static PyObject * -_decode_filter_properties(PyObject *self, PyObject *args) +lzma__decode_filter_properties_impl(PyModuleDef *module, lzma_vli filter_id, Py_buffer *encoded_props) +/*[clinic end generated code: checksum=2ffdb2520c442a566fb814013370a58327040f84]*/ { - Py_buffer encoded_props; lzma_filter filter; lzma_ret lzret; PyObject *result = NULL; - - if (!PyArg_ParseTuple(args, "O&y*:_decode_filter_properties", - lzma_vli_converter, &filter.id, &encoded_props)) - return NULL; + filter.id = filter_id; lzret = lzma_properties_decode( - &filter, NULL, encoded_props.buf, encoded_props.len); - PyBuffer_Release(&encoded_props); + &filter, NULL, encoded_props->buf, encoded_props->len); if (catch_lzma_error(lzret)) return NULL; @@ -1224,13 +1243,25 @@ /* Module initialization. */ +#include "_lzmamodule.clinic.c" + +static PyMethodDef Decompressor_methods[] = { + LZMA_LZMADECOMPRESSOR_DECOMPRESS_METHODDEF + {"__getstate__", (PyCFunction)Decompressor_getstate, METH_NOARGS}, + {NULL} +}; + +static PyMethodDef Compressor_methods[] = { + LZMA_LZMACOMPRESSOR_COMPRESS_METHODDEF + LZMA_LZMACOMPRESSOR_FLUSH_METHODDEF + {"__getstate__", (PyCFunction)Compressor_getstate, METH_NOARGS}, + {NULL} +}; + static PyMethodDef module_methods[] = { - {"is_check_supported", (PyCFunction)is_check_supported, - METH_VARARGS, is_check_supported_doc}, - {"_encode_filter_properties", (PyCFunction)_encode_filter_properties, - METH_VARARGS, _encode_filter_properties_doc}, - {"_decode_filter_properties", (PyCFunction)_decode_filter_properties, - METH_VARARGS, _decode_filter_properties_doc}, + LZMA_IS_CHECK_SUPPORTED_METHODDEF + LZMA__ENCODE_FILTER_PROPERTIES_METHODDEF + LZMA__DECODE_FILTER_PROPERTIES_METHODDEF {NULL} }; diff -r da8e8e28a616 Modules/_lzmamodule.clinic.c --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Modules/_lzmamodule.clinic.c Sat Jan 18 13:28:47 2014 +0200 @@ -0,0 +1,188 @@ +/*[clinic input] +preserve +[clinic start generated code]*/ + +PyDoc_STRVAR(lzma_LZMACompressor_compress__doc__, +"compress(data)\n" +"Provide data to the compressor object.\n" +"\n" +"Returns a chunk of compressed data if possible, or b\'\' otherwise.\n" +"\n" +"When you have finished providing data to the compressor, call the\n" +"flush() method to finish the compression process."); + +#define LZMA_LZMACOMPRESSOR_COMPRESS_METHODDEF \ + {"compress", (PyCFunction)lzma_LZMACompressor_compress, METH_VARARGS, lzma_LZMACompressor_compress__doc__}, + +static PyObject * +lzma_LZMACompressor_compress_impl(Compressor *self, Py_buffer *data); + +static PyObject * +lzma_LZMACompressor_compress(PyObject *self, PyObject *args) +{ + PyObject *return_value = NULL; + Py_buffer data = {NULL, NULL}; + + if (!PyArg_ParseTuple(args, + "y*:compress", + &data)) + goto exit; + return_value = lzma_LZMACompressor_compress_impl((Compressor *)self, &data); + +exit: + /* Cleanup for data */ + if (data.obj) + PyBuffer_Release(&data); + + return return_value; +} + +PyDoc_STRVAR(lzma_LZMACompressor_flush__doc__, +"flush()\n" +"Finish the compression process.\n" +"\n" +"Returns the compressed data left in internal buffers.\n" +"\n" +"The compressor object may not be used after this method is called."); + +#define LZMA_LZMACOMPRESSOR_FLUSH_METHODDEF \ + {"flush", (PyCFunction)lzma_LZMACompressor_flush, METH_NOARGS, lzma_LZMACompressor_flush__doc__}, + +static PyObject * +lzma_LZMACompressor_flush_impl(Compressor *self); + +static PyObject * +lzma_LZMACompressor_flush(PyObject *self, PyObject *Py_UNUSED(ignored)) +{ + return lzma_LZMACompressor_flush_impl((Compressor *)self); +} + +PyDoc_STRVAR(lzma_LZMADecompressor_decompress__doc__, +"decompress(data)\n" +"Provide data to the decompressor object.\n" +"\n" +"Returns a chunk of decompressed data if possible, or b\'\' otherwise.\n" +"\n" +"Attempting to decompress data after the end of stream is reached\n" +"raises an EOFError. Any data found after the end of the stream\n" +"is ignored and saved in the unused_data attribute."); + +#define LZMA_LZMADECOMPRESSOR_DECOMPRESS_METHODDEF \ + {"decompress", (PyCFunction)lzma_LZMADecompressor_decompress, METH_VARARGS, lzma_LZMADecompressor_decompress__doc__}, + +static PyObject * +lzma_LZMADecompressor_decompress_impl(Decompressor *self, Py_buffer *data); + +static PyObject * +lzma_LZMADecompressor_decompress(PyObject *self, PyObject *args) +{ + PyObject *return_value = NULL; + Py_buffer data = {NULL, NULL}; + + if (!PyArg_ParseTuple(args, + "y*:decompress", + &data)) + goto exit; + return_value = lzma_LZMADecompressor_decompress_impl((Decompressor *)self, &data); + +exit: + /* Cleanup for data */ + if (data.obj) + PyBuffer_Release(&data); + + return return_value; +} + +PyDoc_STRVAR(lzma_is_check_supported__doc__, +"is_check_supported(check_id)\n" +"Test whether the given integrity check is supported.\n" +"\n" +"Always returns True for CHECK_NONE and CHECK_CRC32."); + +#define LZMA_IS_CHECK_SUPPORTED_METHODDEF \ + {"is_check_supported", (PyCFunction)lzma_is_check_supported, METH_VARARGS, lzma_is_check_supported__doc__}, + +static PyObject * +lzma_is_check_supported_impl(PyModuleDef *module, int check_id); + +static PyObject * +lzma_is_check_supported(PyModuleDef *module, PyObject *args) +{ + PyObject *return_value = NULL; + int check_id; + + if (!PyArg_ParseTuple(args, + "i:is_check_supported", + &check_id)) + goto exit; + return_value = lzma_is_check_supported_impl(module, check_id); + +exit: + return return_value; +} + +PyDoc_STRVAR(lzma__encode_filter_properties__doc__, +"_encode_filter_properties(filter)\n" +"Return a bytes object encoding the options (properties) of the filter specified by *filter* (a dict).\n" +"\n" +"The result does not include the filter ID itself, only the options."); + +#define LZMA__ENCODE_FILTER_PROPERTIES_METHODDEF \ + {"_encode_filter_properties", (PyCFunction)lzma__encode_filter_properties, METH_VARARGS, lzma__encode_filter_properties__doc__}, + +static PyObject * +lzma__encode_filter_properties_impl(PyModuleDef *module, lzma_filter filter); + +static PyObject * +lzma__encode_filter_properties(PyModuleDef *module, PyObject *args) +{ + PyObject *return_value = NULL; + lzma_filter filter = {LZMA_VLI_UNKNOWN, NULL}; + + if (!PyArg_ParseTuple(args, + "O&:_encode_filter_properties", + lzma_filter_converter, &filter)) + goto exit; + return_value = lzma__encode_filter_properties_impl(module, filter); + +exit: + /* Cleanup for filter */ + if (filter.id != LZMA_VLI_UNKNOWN) + PyMem_Free(filter.options); + + return return_value; +} + +PyDoc_STRVAR(lzma__decode_filter_properties__doc__, +"_decode_filter_properties(filter_id, encoded_props)\n" +"Return a bytes object encoding the options (properties) of the filter specified by *filter* (a dict).\n" +"\n" +"The result does not include the filter ID itself, only the options."); + +#define LZMA__DECODE_FILTER_PROPERTIES_METHODDEF \ + {"_decode_filter_properties", (PyCFunction)lzma__decode_filter_properties, METH_VARARGS, lzma__decode_filter_properties__doc__}, + +static PyObject * +lzma__decode_filter_properties_impl(PyModuleDef *module, lzma_vli filter_id, Py_buffer *encoded_props); + +static PyObject * +lzma__decode_filter_properties(PyModuleDef *module, PyObject *args) +{ + PyObject *return_value = NULL; + lzma_vli filter_id; + Py_buffer encoded_props = {NULL, NULL}; + + if (!PyArg_ParseTuple(args, + "O&y*:_decode_filter_properties", + lzma_vli_converter, &filter_id, &encoded_props)) + goto exit; + return_value = lzma__decode_filter_properties_impl(module, filter_id, &encoded_props); + +exit: + /* Cleanup for encoded_props */ + if (encoded_props.obj) + PyBuffer_Release(&encoded_props); + + return return_value; +} +/*[clinic end generated code: checksum=2263a9ea9a89fdebd97faf3c9ae614947865fa14]*/ From report at bugs.python.org Sat Jan 18 13:08:44 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 12:08:44 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1390046924.67.0.115221519429.issue20148@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file33329/sre_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 13:09:21 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 12:09:21 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1390046961.54.0.658830484373.issue20148@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file33353/sre_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 13:23:33 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 12:23:33 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1390047813.8.0.62231408228.issue20148@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Now all methods except Match.group() (which needs *args) use Argument Clinic. Most important change is that first parameters of some Pattern methods are renamed from "pattern" or "source" to "string". This was obvious bug (issue20283). "string" conforms to the documentation and to the name of the Match.string attribute. ---------- Added file: http://bugs.python.org/file33527/sre_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 13:23:59 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 12:23:59 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1390047839.74.0.956018577042.issue20148@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 13:26:29 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 12:26:29 +0000 Subject: [issue20168] Derby: Convert the _tkinter module to use Argument Clinic In-Reply-To: <1389128639.57.0.613370502446.issue20168@psf.upfronthosting.co.za> Message-ID: <1390047989.97.0.820841436909.issue20168@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch. ---------- keywords: +patch nosy: +gpolo stage: -> patch review Added file: http://bugs.python.org/file33528/tkinter_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 13:28:17 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 12:28:17 +0000 Subject: [issue20151] Derby: Convert the binascii module to use Argument Clinic In-Reply-To: <1389037748.15.0.70999359123.issue20151@psf.upfronthosting.co.za> Message-ID: <1390048097.35.0.0122368039014.issue20151@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file33332/binascii_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 13:28:57 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 12:28:57 +0000 Subject: [issue20151] Derby: Convert the binascii module to use Argument Clinic In-Reply-To: <1389037748.15.0.70999359123.issue20151@psf.upfronthosting.co.za> Message-ID: <1390048137.38.0.89928010989.issue20151@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file33354/binascii_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 13:29:49 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 12:29:49 +0000 Subject: [issue20151] Derby: Convert the binascii module to use Argument Clinic In-Reply-To: <1389037748.15.0.70999359123.issue20151@psf.upfronthosting.co.za> Message-ID: <1390048189.64.0.171298270039.issue20151@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file33529/binascii_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 13:47:09 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 12:47:09 +0000 Subject: [issue20133] Derby: Convert the audioop module to use Argument Clinic In-Reply-To: <1388956864.17.0.114751586443.issue20133@psf.upfronthosting.co.za> Message-ID: <1390049229.97.0.151972489176.issue20133@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file33320/audioop_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 13:48:04 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 12:48:04 +0000 Subject: [issue20133] Derby: Convert the audioop module to use Argument Clinic In-Reply-To: <1388956864.17.0.114751586443.issue20133@psf.upfronthosting.co.za> Message-ID: <1390049284.81.0.505997369896.issue20133@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file33352/audioop_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 13:48:37 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 12:48:37 +0000 Subject: [issue20133] Derby: Convert the audioop module to use Argument Clinic In-Reply-To: <1388956864.17.0.114751586443.issue20133@psf.upfronthosting.co.za> Message-ID: <1390049317.36.0.389952245676.issue20133@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file33461/audioop_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 13:49:53 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 12:49:53 +0000 Subject: [issue20133] Derby: Convert the audioop module to use Argument Clinic In-Reply-To: <1388956864.17.0.114751586443.issue20133@psf.upfronthosting.co.za> Message-ID: <1390049393.05.0.650975335313.issue20133@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file33530/audioop_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 14:43:40 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jan 2014 13:43:40 +0000 Subject: [issue20245] Check empty mode in TarFile.*open() In-Reply-To: <1389651524.31.0.708867421732.issue20245@psf.upfronthosting.co.za> Message-ID: <3f60j75ZRgzQQk@mail.python.org> Roundup Robot added the comment: New changeset 8edb892f4d69 by Serhiy Storchaka in branch '2.7': Issue #20245: The open functions in the tarfile module now correctly handle empty mode. http://hg.python.org/cpython/rev/8edb892f4d69 New changeset 8ef1fd952410 by Serhiy Storchaka in branch '3.3': Issue #20245: The open functions in the tarfile module now correctly handle empty mode. http://hg.python.org/cpython/rev/8ef1fd952410 New changeset 7a2db897a1b6 by Serhiy Storchaka in branch 'default': Issue #20245: The open functions in the tarfile module now correctly handle empty mode. http://hg.python.org/cpython/rev/7a2db897a1b6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 14:56:27 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jan 2014 13:56:27 +0000 Subject: [issue20238] Incomplete gzip output with tarfile.open(fileobj=..., mode="w:gz") In-Reply-To: <1389608683.35.0.244495356969.issue20238@psf.upfronthosting.co.za> Message-ID: <3f60zt4gDbz7LjM@mail.python.org> Roundup Robot added the comment: New changeset 5c69332dc3b0 by Serhiy Storchaka in branch '3.3': Issue #20238: TarFile opened with external fileobj and "w:gz" mode didn't http://hg.python.org/cpython/rev/5c69332dc3b0 New changeset e154b93f3857 by Serhiy Storchaka in branch 'default': Issue #20238: TarFile opened with external fileobj and "w:gz" mode didn't http://hg.python.org/cpython/rev/e154b93f3857 New changeset f7381f1bf1ec by Serhiy Storchaka in branch '2.7': Backported test for issue #20238. http://hg.python.org/cpython/rev/f7381f1bf1ec ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 15:31:41 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jan 2014 14:31:41 +0000 Subject: [issue20243] ReadError when open a tarfile for writing In-Reply-To: <1389643184.53.0.894735644102.issue20243@psf.upfronthosting.co.za> Message-ID: <3f61mY1FNZz7Ljg@mail.python.org> Roundup Robot added the comment: New changeset 61b6accbca9f by Serhiy Storchaka in branch '2.7': Issue #20243: TarFile no longer raise ReadError when opened in write mode. http://hg.python.org/cpython/rev/61b6accbca9f New changeset 2f3b47b63f91 by Serhiy Storchaka in branch '3.3': Issue #20243: TarFile no longer raise ReadError when opened in write mode. http://hg.python.org/cpython/rev/2f3b47b63f91 New changeset 40a5c7547c3d by Serhiy Storchaka in branch 'default': Issue #20243: TarFile no longer raise ReadError when opened in write mode. http://hg.python.org/cpython/rev/40a5c7547c3d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 15:31:42 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jan 2014 14:31:42 +0000 Subject: [issue20244] Possible resources leak in tarfile.open() In-Reply-To: <1389644794.57.0.468405626854.issue20244@psf.upfronthosting.co.za> Message-ID: <3f61mY6h1zz7Ljg@mail.python.org> Roundup Robot added the comment: New changeset 05d186a1a367 by Serhiy Storchaka in branch '3.3': Issue #20244: Fixed possible file leaks when unexpected error raised in http://hg.python.org/cpython/rev/05d186a1a367 New changeset 0386cde12657 by Serhiy Storchaka in branch 'default': Issue #20244: Fixed possible file leaks when unexpected error raised in http://hg.python.org/cpython/rev/0386cde12657 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 15:35:13 2014 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 18 Jan 2014 14:35:13 +0000 Subject: [issue17481] inspect.getfullargspec could use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1390055713.71.0.667706464592.issue17481@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 16:17:45 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 15:17:45 +0000 Subject: [issue20245] Check empty mode in TarFile.*open() In-Reply-To: <1389651524.31.0.708867421732.issue20245@psf.upfronthosting.co.za> Message-ID: <1390058265.73.0.760394222537.issue20245@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 16:18:49 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 15:18:49 +0000 Subject: [issue20238] Incomplete gzip output with tarfile.open(fileobj=..., mode="w:gz") In-Reply-To: <1389608683.35.0.244495356969.issue20238@psf.upfronthosting.co.za> Message-ID: <1390058329.14.0.612081986321.issue20238@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 16:19:15 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 15:19:15 +0000 Subject: [issue20243] ReadError when open a tarfile for writing In-Reply-To: <1389643184.53.0.894735644102.issue20243@psf.upfronthosting.co.za> Message-ID: <1390058355.88.0.567664474129.issue20243@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 16:22:14 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 15:22:14 +0000 Subject: [issue20244] Possible resources leak in tarfile.open() In-Reply-To: <1389644794.57.0.468405626854.issue20244@psf.upfronthosting.co.za> Message-ID: <1390058534.37.0.0551743112183.issue20244@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: As for 2.7, I suppose it have file leaks even when expected exception is raised. 2.7 needs more tests and perhaps changes for GzipFile. This was not fixed in issue11513 and is not fixed here. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 17:32:10 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jan 2014 16:32:10 +0000 Subject: [issue20270] urllib.parse doesn't work with empty port In-Reply-To: <1389788785.56.0.178405230158.issue20270@psf.upfronthosting.co.za> Message-ID: <3f64RY2jQ5zSV0@mail.python.org> Roundup Robot added the comment: New changeset a4a51a0d4575 by Serhiy Storchaka in branch '2.7': Issue #20270: urllib and urlparse now support empty ports. http://hg.python.org/cpython/rev/a4a51a0d4575 New changeset 52edc7087c81 by Serhiy Storchaka in branch '3.3': Issue #20270: urllib.urlparse now supports empty ports. http://hg.python.org/cpython/rev/52edc7087c81 New changeset 1469c4fde8cd by Serhiy Storchaka in branch 'default': Issue #20270: urllib.urlparse now supports empty ports. http://hg.python.org/cpython/rev/1469c4fde8cd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 17:33:04 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 16:33:04 +0000 Subject: [issue20270] urllib.parse doesn't work with empty port In-Reply-To: <1389788785.56.0.178405230158.issue20270@psf.upfronthosting.co.za> Message-ID: <1390062784.87.0.556312313077.issue20270@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 18:40:34 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 18 Jan 2014 17:40:34 +0000 Subject: [issue20293] pydoc fails with the "unspecified" default value In-Reply-To: <1390045398.5.0.236293557583.issue20293@psf.upfronthosting.co.za> Message-ID: <1390066834.28.0.903474577618.issue20293@psf.upfronthosting.co.za> Larry Hastings added the comment: Just checking--that happens with current trunk? Revision 32f9e0ae23f7 or newer? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 18:41:45 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 18 Jan 2014 17:41:45 +0000 Subject: [issue20294] Argument Clinic: add support for __init__ In-Reply-To: <1390045406.06.0.938757132567.issue20294@psf.upfronthosting.co.za> Message-ID: <1390066905.49.0.254180190747.issue20294@psf.upfronthosting.co.za> Larry Hastings added the comment: Oh! I thought it worked fine, because I've seen people convert both an __init__ and a __new__. But I guess they wrapped them. It's an easy change, I can try to do that today. ---------- assignee: -> larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 18:49:16 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 17:49:16 +0000 Subject: [issue20293] pydoc fails with the "unspecified" default value In-Reply-To: <1390045398.5.0.236293557583.issue20293@psf.upfronthosting.co.za> Message-ID: <1390067356.4.0.457935815638.issue20293@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: That happens with current trunk (revision 1469c4fde8cd) and a patch for zlib from issue20193 [1]. [1] http://bugs.python.org/file33523/zlib_clinic.patch ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 19:23:41 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 18:23:41 +0000 Subject: [issue20171] Derby #2: Convert 115 sites to Argument Clinic in Modules/_cursesmodule.c In-Reply-To: <1389138236.79.0.916600121015.issue20171@psf.upfronthosting.co.za> Message-ID: <1390069421.1.0.159759124408.issue20171@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I take it. ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 19:45:46 2014 From: report at bugs.python.org (Martin Vignali) Date: Sat, 18 Jan 2014 18:45:46 +0000 Subject: [issue20295] imghdr add openexr support Message-ID: <1390070746.18.0.632580086157.issue20295@psf.upfronthosting.co.za> New submission from Martin Vignali: Add support for detect openexr file (http://www.openexr.com/) Based on information provided by : http://www.openexr.com/ReadingAndWritingImageFiles.pdf I make some tests, on different kind of exr file, to check, the new function. ---------- components: Library (Lib) files: img_hdr_exr.patch keywords: patch messages: 208409 nosy: mvignali priority: normal severity: normal status: open title: imghdr add openexr support type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file33531/img_hdr_exr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 20:22:50 2014 From: report at bugs.python.org (Rob Browning) Date: Sat, 18 Jan 2014 19:22:50 +0000 Subject: [issue20296] PyArg_ParseTuple 2.X docs mention int for "t#", but "Py_ssize_t" for "w#", etc. Message-ID: <1390072970.58.0.165278841581.issue20296@psf.upfronthosting.co.za> New submission from Rob Browning: Here (http://docs.python.org/2/c-api/arg.html), the documentation for "t#" says: t# (read-only character buffer) [char *, int]... while the documentation for "w#" says: w# (read-write character buffer) [char *, Py_ssize_t]... However, from getargs.c, it looks like they're handled the same with respect to the size type. At a minimum, it seems like it might make sense to change these docs to match, and if "w#" and "t#" are actually handled similarly to "s#", it would be even better to just change their docs to match (or refer to) "s#"'s which are more detailed, i.e. they mention the PY_SSIZE_T_CLEAN issues, etc. Thanks ---------- assignee: docs at python components: Documentation messages: 208410 nosy: docs at python, rlb priority: normal severity: normal status: open title: PyArg_ParseTuple 2.X docs mention int for "t#", but "Py_ssize_t" for "w#", etc. versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 20:30:03 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 18 Jan 2014 19:30:03 +0000 Subject: [issue20293] pydoc fails with the "unspecified" default value In-Reply-To: <1390045398.5.0.236293557583.issue20293@psf.upfronthosting.co.za> Message-ID: <1390073403.33.0.887349160971.issue20293@psf.upfronthosting.co.za> Larry Hastings added the comment: I just built from a new clone of trunk, and it works fine for me. I didn't see the exception you report--I get the documentation for zlib. Do you still get the error if you build from a new clone of the current trunk? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 20:36:52 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 18 Jan 2014 19:36:52 +0000 Subject: [issue20294] Argument Clinic: add support for __init__ In-Reply-To: <1390045406.06.0.938757132567.issue20294@psf.upfronthosting.co.za> Message-ID: <1390073812.04.0.395007918373.issue20294@psf.upfronthosting.co.za> Larry Hastings added the comment: > * As is probably expected, __init__ and __call__ procs > can't be converted. I should have a fix in for __init__ and __call__ later today. (Issue #20294.) For the record, you could convert them, you just had to wrap the parsing function to deal with the return type difference, and *args / **kwargs might be tricky too. > * sqlite3.Connection.{execute, executemany, executescript} don't use > PyArg_Parse*. In the next few days I'm going to add support for "*args" and "**kwargs", and then you'll be able to convert these functions. (Issue #20291.) Again, even if Argument Clinic doesn't do any parsing, it's still helpful to have it generate signatures. > * The clinic version of 'sqlite3.adapt' has an argument string of "O|OO". > The first optional parameter defaults to 'pysqlite_PrepareProtocolType' > in C and 'sqlite3.ProtocolType' in Python. However, I don't know how to > represent the Python value because Python default values are 'eval'd by > clinic *and* the 'sqlite3' module is not imported for the eval. You'll be able to do this soon: parameter: object(c_default='pysqlite_PrepareProtocolType') = ProtocolType This feature isn't checked in yet, I'm waiting for a review. It's part of #20226, which I guess you already noticed. > * The clinic version of 'sqlite3.Cursor.fetchmany' has an arguments string > of "|i". The first parameter defaults to > '((pysqlite_Cursor *)self)->arraysize' in C and 'self.arraysize' in > Python. I don't know how to express the Python initialization. You can't. How about you use a default of -1 and then: if (maxrows == -1) maxrows = self->arraysize > * I didn't convert 'sqlite3.Cursor.setinputsizes' and > 'sqlite3.Cursor.setoutputsize' because they share a docstring and > simple no-op method def. I'd prefer it if you converted them anyway. Converting them means they'll have signature information which is an unconditional good. > * I didn't convert 'sqlite.connect' because it would have required > packaing the arguments back up to pass to 'PyObject_Call'. Once I add the ability to pass in *args and **kwargs, you'll be able to convert sqlite.connect. I think I responded to all your other comments when I reviewed the patch. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 20:37:55 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 18 Jan 2014 19:37:55 +0000 Subject: [issue20294] Argument Clinic: add support for __init__ In-Reply-To: <1390045406.06.0.938757132567.issue20294@psf.upfronthosting.co.za> Message-ID: <1390073875.01.0.70822484448.issue20294@psf.upfronthosting.co.za> Larry Hastings added the comment: Oops, sorry, that last comment was intended for a different issue. Please ignore, and sorry for the spam! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 20:38:21 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 18 Jan 2014 19:38:21 +0000 Subject: [issue20178] Derby #9: Convert 52 sites to Argument Clinic across 11 files In-Reply-To: <1389140078.91.0.720761635456.issue20178@psf.upfronthosting.co.za> Message-ID: <1390073901.17.0.171006115986.issue20178@psf.upfronthosting.co.za> Larry Hastings added the comment: Larry Hastings added the comment: > * As is probably expected, __init__ and __call__ procs > can't be converted. I should have a fix in for __init__ and __call__ later today. (Issue #20294.) For the record, you could convert them, you just had to wrap the parsing function to deal with the return type difference, and *args / **kwargs might be tricky too. > * sqlite3.Connection.{execute, executemany, executescript} don't use > PyArg_Parse*. In the next few days I'm going to add support for "*args" and "**kwargs", and then you'll be able to convert these functions. (Issue #20291.) Again, even if Argument Clinic doesn't do any parsing, it's still helpful to have it generate signatures. > * The clinic version of 'sqlite3.adapt' has an argument string of "O|OO". > The first optional parameter defaults to 'pysqlite_PrepareProtocolType' > in C and 'sqlite3.ProtocolType' in Python. However, I don't know how to > represent the Python value because Python default values are 'eval'd by > clinic *and* the 'sqlite3' module is not imported for the eval. You'll be able to do this soon: parameter: object(c_default='pysqlite_PrepareProtocolType') = ProtocolType This feature isn't checked in yet, I'm waiting for a review. It's part of #20226, which I guess you already noticed. > * The clinic version of 'sqlite3.Cursor.fetchmany' has an arguments string > of "|i". The first parameter defaults to > '((pysqlite_Cursor *)self)->arraysize' in C and 'self.arraysize' in > Python. I don't know how to express the Python initialization. You can't. How about you use a default of -1 and then: if (maxrows == -1) maxrows = self->arraysize > * I didn't convert 'sqlite3.Cursor.setinputsizes' and > 'sqlite3.Cursor.setoutputsize' because they share a docstring and > simple no-op method def. I'd prefer it if you converted them anyway. Converting them means they'll have signature information which is an unconditional good. > * I didn't convert 'sqlite.connect' because it would have required > packaing the arguments back up to pass to 'PyObject_Call'. Once I add the ability to pass in *args and **kwargs, you'll be able to convert sqlite.connect. I think I responded to all your other comments when I reviewed the patch. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 21:02:57 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jan 2014 20:02:57 +0000 Subject: [issue19855] uuid._find_mac fails if an executable not in /sbin or /usr/sbin In-Reply-To: <1385910768.71.0.356029979861.issue19855@psf.upfronthosting.co.za> Message-ID: <3f696m4PVmz7LjW@mail.python.org> Roundup Robot added the comment: New changeset 9fe32328a573 by R David Murray in branch '2.7': #19855: restore use of LC_ALL, not LC_MESSAGES http://hg.python.org/cpython/rev/9fe32328a573 New changeset 706354c4d8f5 by R David Murray in branch '3.3': #19855: restore use of LC_ALL, not LC_MESSAGES http://hg.python.org/cpython/rev/706354c4d8f5 New changeset 418212180bf1 by R David Murray in branch 'default': Merge #19855: restore use of LC_ALL, not LC_MESSAGES http://hg.python.org/cpython/rev/418212180bf1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 21:26:24 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 18 Jan 2014 20:26:24 +0000 Subject: [issue17481] inspect.getfullargspec could use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1390076784.93.0.364891173553.issue17481@psf.upfronthosting.co.za> Terry J. Reedy added the comment: While I plan to change Idle code to use signature directly, instead of getfullargspec, I agree that changing inspect also, and in 3.4, is a good idea. It may, however, affect tests other than Idle's, if there are any other stdlib consumers. I will try to look at the patch after changing Idle. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 22:12:12 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Sat, 18 Jan 2014 21:12:12 +0000 Subject: [issue20227] Argument Clinic: rename arguments in generated C? In-Reply-To: <1389524736.75.0.620647933805.issue20227@psf.upfronthosting.co.za> Message-ID: <1390079532.94.0.781627791967.issue20227@psf.upfronthosting.co.za> Ryan Smith-Roberts added the comment: I believe the feature you starred resolves this enhancement issue, in which case my patches are obsolete. And yes, the 'as' syntax makes a lot more sense. Here's how I hope it works (the arg parsing wrapper remains unchanged): foo: int ... _impl(..., int foo) can become foo: int as bar ... _impl(..., int bar) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 22:19:35 2014 From: report at bugs.python.org (Glenn Langford) Date: Sat, 18 Jan 2014 21:19:35 +0000 Subject: [issue20297] concurrent.futures.as_completed() installs waiters for already completed Futures Message-ID: <1390079975.89.0.167689725202.issue20297@psf.upfronthosting.co.za> New submission from Glenn Langford: as_completed() calls _create_and_install_waiters() over all given Futures, even if some (or all) of the Futures have already completed. The following fragment of the as_completed code (from 3.3.3): with _AcquireFutures(fs): finished = set( f for f in fs if f._state in [CANCELLED_AND_NOTIFIED, FINISHED]) pending = set(fs) - finished waiter = _create_and_install_waiters(fs, _AS_COMPLETED) installs waiters into Futures contained in fs, rather than pending. A more efficient approach might be to only install waiters on the pending subset if necessary. This would be faster and would also result in less dwell time with all of the Future conditions locked via the _AcquireFutures context manager. Also: waiters are appended with the Future condition lock acquired, but are removed (at the conclusion of as_completed) without the _AcquireFutures condition lock. Is this correct? ---------- components: Library (Lib) messages: 208418 nosy: glangford priority: normal severity: normal status: open title: concurrent.futures.as_completed() installs waiters for already completed Futures type: performance versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 23:14:33 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 18 Jan 2014 22:14:33 +0000 Subject: [issue20227] Argument Clinic: rename arguments in generated C? In-Reply-To: <1390079532.94.0.781627791967.issue20227@psf.upfronthosting.co.za> Message-ID: <52DAFCBB.8070101@hastings.org> Larry Hastings added the comment: On 01/18/2014 01:12 PM, Ryan Smith-Roberts wrote: > Ryan Smith-Roberts added the comment: > > I believe the feature you starred resolves this enhancement issue, in which case my patches are obsolete. And yes, the 'as' syntax makes a lot more sense. Here's how I hope it works (the arg parsing wrapper remains unchanged): > > foo: int > ... > _impl(..., int foo) > > can become > > foo: int as bar > ... > _impl(..., int bar) Nope, not what I wanted. I said "as" binds more tightly than ":": foo as bar: int But if you're dropping the patch I guess it's irrelevant. //arry/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 23:34:59 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sat, 18 Jan 2014 22:34:59 +0000 Subject: [issue18574] BaseHTTPRequestHandler.handle_expect_100() sends invalid response In-Reply-To: <1374971787.85.0.837580893432.issue18574@psf.upfronthosting.co.za> Message-ID: <1390084499.79.0.966941296537.issue18574@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Thanks for looking at this! Attached is an updated patch with testcase (sorry, I thought I had included testcases everywhere). ---------- Added file: http://bugs.python.org/file33532/issue18574_rev2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 18 23:44:54 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Sat, 18 Jan 2014 22:44:54 +0000 Subject: [issue20227] Argument Clinic: rename arguments in generated C? In-Reply-To: <1389524736.75.0.620647933805.issue20227@psf.upfronthosting.co.za> Message-ID: <1390085094.44.0.607286538102.issue20227@psf.upfronthosting.co.za> Ryan Smith-Roberts added the comment: Yes, that makes more sense. The specific syntax is nearly irrelevant compared to the feature existing at all. You still haven't indicated whether your starred feature matches the *result* that I outlined. Does it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 00:05:23 2014 From: report at bugs.python.org (Stefan Krah) Date: Sat, 18 Jan 2014 23:05:23 +0000 Subject: [issue20246] buffer overflow in socket.recvfrom_into In-Reply-To: <1389660239.25.0.341393063834.issue20246@psf.upfronthosting.co.za> Message-ID: <1390086323.5.0.172058426671.issue20246@psf.upfronthosting.co.za> Stefan Krah added the comment: One test fails on FreeBSD 9.0 and 6.4: ====================================================================== ERROR: testRecvFromIntoSmallBuffer (test.test_socket.BufferIOTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_socket.py", line 259, in _tearDown raise exc File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_socket.py", line 271, in clientRun test_func() File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_socket.py", line 4690, in _testRecvFromIntoSmallBuffer self.serv_conn.send(MSG*2048) BrokenPipeError: [Errno 32] Broken pipe ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 00:06:06 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sat, 18 Jan 2014 23:06:06 +0000 Subject: [issue17811] Improve os.readv() and os.writev() documentation and docstring In-Reply-To: <1366579468.26.0.0312151391842.issue17811@psf.upfronthosting.co.za> Message-ID: <1390086366.02.0.988735478802.issue17811@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Indeed, this makes most sense. I didn't know that glossary entry existed. I have attached an updated patch. Thanks for reviewing! ---------- Added file: http://bugs.python.org/file33533/issue17811_rev2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 00:06:23 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sat, 18 Jan 2014 23:06:23 +0000 Subject: [issue17811] Improve os.readv() and os.writev() documentation and docstring In-Reply-To: <1366579468.26.0.0312151391842.issue17811@psf.upfronthosting.co.za> Message-ID: <1390086383.16.0.126004288426.issue17811@psf.upfronthosting.co.za> Changes by Nikolaus Rath : ---------- versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 00:17:48 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sat, 18 Jan 2014 23:17:48 +0000 Subject: [issue20177] Derby #8: Convert 28 sites to Argument Clinic across 2 files In-Reply-To: <1389138574.32.0.892814928986.issue20177@psf.upfronthosting.co.za> Message-ID: <1390087068.13.0.662270402359.issue20177@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Will do. Another question: what should I do with return annotations, e.g. the "-> dict" part in "get_clock_info(name: str) -> dict\n Should I drop that part? In the clinic howto, I couldn't find anything about return annotations (only that parameter annotations are unsupported). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 00:21:05 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jan 2014 23:21:05 +0000 Subject: [issue20227] Argument Clinic: rename arguments in generated C? In-Reply-To: <1389524736.75.0.620647933805.issue20227@psf.upfronthosting.co.za> Message-ID: <1390087265.73.0.0946552937865.issue20227@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: -serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 00:29:36 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sat, 18 Jan 2014 23:29:36 +0000 Subject: [issue20177] Derby #8: Convert 28 sites to Argument Clinic across 2 files In-Reply-To: <1389138574.32.0.892814928986.issue20177@psf.upfronthosting.co.za> Message-ID: <1390087776.7.0.00293925088469.issue20177@psf.upfronthosting.co.za> Nikolaus Rath added the comment: One more question: what's a good way to find sites that need changes? Searching for "PyArg_" finds both converted and unconverted functions... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 00:54:46 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 18 Jan 2014 23:54:46 +0000 Subject: [issue20177] Derby #8: Convert 28 sites to Argument Clinic across 2 files In-Reply-To: <1389138574.32.0.892814928986.issue20177@psf.upfronthosting.co.za> Message-ID: <1390089286.7.0.930198072776.issue20177@psf.upfronthosting.co.za> Larry Hastings added the comment: Yes, you should drop things that look like return annotations in the original docstring. I don't have a magic formula for finding unchanged functions, sorry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 01:37:11 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Sun, 19 Jan 2014 00:37:11 +0000 Subject: [issue20252] Argument Clinic howto: small typo in y# translation In-Reply-To: <1389678329.15.0.528814981218.issue20252@psf.upfronthosting.co.za> Message-ID: <1390091831.71.0.341262091467.issue20252@psf.upfronthosting.co.za> Ryan Smith-Roberts added the comment: I saw the fix for this in the commit stream. Closing. ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 01:37:36 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Sun, 19 Jan 2014 00:37:36 +0000 Subject: [issue20252] Argument Clinic howto: small typo in y# translation In-Reply-To: <1389678329.15.0.528814981218.issue20252@psf.upfronthosting.co.za> Message-ID: <1390091856.43.0.332184038319.issue20252@psf.upfronthosting.co.za> Changes by Ryan Smith-Roberts : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 01:55:11 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Sun, 19 Jan 2014 00:55:11 +0000 Subject: [issue20246] buffer overflow in socket.recvfrom_into In-Reply-To: <1389660239.25.0.341393063834.issue20246@psf.upfronthosting.co.za> Message-ID: <1390092911.12.0.503833450412.issue20246@psf.upfronthosting.co.za> Ryan Smith-Roberts added the comment: Perhaps the test is sending an infeasibly large message. If you remove the '*2048' does it pass? (I set up a FreeBSD 9.2 amd64 VM but all tests are passing here). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 02:03:17 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sun, 19 Jan 2014 01:03:17 +0000 Subject: [issue20177] Derby #8: Convert 28 sites to Argument Clinic across 2 files In-Reply-To: <1389138574.32.0.892814928986.issue20177@psf.upfronthosting.co.za> Message-ID: <1390093397.49.0.813178482883.issue20177@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Here is a patch for timemodule.c. I have converted everything except: * ctime() uses the gettmarg() function. Converting gettmarg() itself doesn't seem possible to me (because it's not Python callable), and duplicating the functionality in a single complicated clinic section just for ctime() did not seem reasonable either. * gmtime(), localtime(), ctime() use a the parse_time_t_args() utility function. I have not yet figured out how to replace this with argument clinic (sent a mail to python-dev about that). ---------- Added file: http://bugs.python.org/file33534/timemodule.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 02:03:29 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sun, 19 Jan 2014 01:03:29 +0000 Subject: [issue20177] Derby #8: Convert 28 sites to Argument Clinic across 2 files In-Reply-To: <1389138574.32.0.892814928986.issue20177@psf.upfronthosting.co.za> Message-ID: <1390093409.65.0.826978110891.issue20177@psf.upfronthosting.co.za> Changes by Nikolaus Rath : Removed file: http://bugs.python.org/file33521/issue20177.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 03:19:14 2014 From: report at bugs.python.org (David Barnett) Date: Sun, 19 Jan 2014 02:19:14 +0000 Subject: [issue20298] json library needs a non-strict option to decode single-quoted strings Message-ID: <1390097954.47.0.6743273993.issue20298@psf.upfronthosting.co.za> New submission from David Barnett: Many sloppy JSON APIs return data with poorly-encoded strings, either with single-quotes as delimiters: {'foo': 'bar'} or with no delimiters at all on keys: {foo: 'bar'} The json library is useless for making sense of this data, because all it will tell you is "No JSON object could be decoded". It would be incredibly helpful if the json library had some special non-strict decoding mode that could interpret these common misspellings of JSON strings. Or, more generally, it could accept another decoder hook to reformat the remaining string, something like: def malformed_hook(remaining, parent): if remaining.startswith("'"): # We know this is a string, regex it to find the end. m = re.match(pyparsing.quotedString.reString, remaining) if m is not None: # Use json.dumps to add quotes around string literal. return json.dumps(eval(m.group(0))) + remaining[m.end():] # If we're inside an object, this could be a naked object key. if isinstance(parent, dict): m = re.match(r'([a-zA-Z_]\w*):', remaining) if m is not None: return json.dumps(m.group(1)) + remaining[len(m.group(1)):] print(json.loads("['foo', null, {a: 'b'}]", malformed_hook=malformed_hook)) ['foo', None, {'a': 'b'}] This would at least save you having to write a parser/tokenizer from scratch. ---------- components: Library (Lib) messages: 208430 nosy: mu_mind priority: normal severity: normal status: open title: json library needs a non-strict option to decode single-quoted strings type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 03:21:01 2014 From: report at bugs.python.org (Tal Einat) Date: Sun, 19 Jan 2014 02:21:01 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za> Message-ID: <1390098061.54.0.0838502985227.issue20180@psf.upfronthosting.co.za> Tal Einat added the comment: I'm attaching my conversion of deque.rotate and _count_elements in Modules/_collectionsmodule.c. There remain 3 other functions in that module to be converted. One is deque_init which returns int; Larry said (on IRC) to hold off with that for now. The other two are dequeiter_new and dequereviter_new, which use the O! format, which I am unsure how to handle. ---------- keywords: +patch nosy: +taleinat Added file: http://bugs.python.org/file33535/_collectionsmodule.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 03:51:21 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 19 Jan 2014 02:51:21 +0000 Subject: [issue18574] BaseHTTPRequestHandler.handle_expect_100() sends invalid response In-Reply-To: <1374971787.85.0.837580893432.issue18574@psf.upfronthosting.co.za> Message-ID: <3f6LB04tfmz7LjY@mail.python.org> Roundup Robot added the comment: New changeset 093ab6c02ff4 by Benjamin Peterson in branch '3.3': fix handling of 100-continue status code (closes #18574) http://hg.python.org/cpython/rev/093ab6c02ff4 New changeset 20a2597d6653 by Benjamin Peterson in branch 'default': merge 3.3 (#18574) http://hg.python.org/cpython/rev/20a2597d6653 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 04:06:59 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 19 Jan 2014 03:06:59 +0000 Subject: [issue20122] Move CallTips tests to idle_tests In-Reply-To: <1388852698.51.0.14863260737.issue20122@psf.upfronthosting.co.za> Message-ID: <1390100819.54.0.296800600469.issue20122@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Attached patch moves all tests, changed (and simplified) to call get_argspec directly. I will apply after I get tk 8.6 to test with 3.4. ---------- Added file: http://bugs.python.org/file33536/test_calltips-33.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 04:25:17 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sun, 19 Jan 2014 03:25:17 +0000 Subject: [issue18574] BaseHTTPRequestHandler.handle_expect_100() sends invalid response In-Reply-To: <1374971787.85.0.837580893432.issue18574@psf.upfronthosting.co.za> Message-ID: <1390101917.46.0.513956335294.issue18574@psf.upfronthosting.co.za> Nikolaus Rath added the comment: I just realized that the Misc/NEWS entry is just utterly wrong (it is talking abou the client, even though the bug is in the server), my apologies. Here's a fixed one: - Issue #18574: Added missing newline in 100-Continue reply from http.server.BaseHTTPRequestHandler. Patch by Nikolaus Rath. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 04:30:53 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Jan 2014 03:30:53 +0000 Subject: [issue20223] inspect.signature does not support new functools.partialmethod In-Reply-To: <1389475379.56.0.443397984378.issue20223@psf.upfronthosting.co.za> Message-ID: <1390102253.54.0.474194415048.issue20223@psf.upfronthosting.co.za> Nick Coghlan added the comment: Aye, I agree with Terry that this is a behavioural bug introduced with the new partialmethod feature - we missed adding a new test case to check that inspect.signature handled it properly. Reviewing the patch now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 04:32:12 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 19 Jan 2014 03:32:12 +0000 Subject: [issue18574] BaseHTTPRequestHandler.handle_expect_100() sends invalid response In-Reply-To: <1374971787.85.0.837580893432.issue18574@psf.upfronthosting.co.za> Message-ID: <3f6M5768WGz7LjT@mail.python.org> Roundup Robot added the comment: New changeset d00ed6e7a823 by Benjamin Peterson in branch '3.3': correct news entry for #18574 http://hg.python.org/cpython/rev/d00ed6e7a823 New changeset cf0678c3b735 by Benjamin Peterson in branch 'default': merge 3.3 (#18574) http://hg.python.org/cpython/rev/cf0678c3b735 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 04:54:37 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Jan 2014 03:54:37 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1390103677.89.0.794830446244.issue17481@psf.upfronthosting.co.za> Nick Coghlan added the comment: I upgraded the description to a "should". Argument Clinic and other changes in Python 3.4 greatly improve introspection support for various aspects of the runtime and standard library (for example, issue 20223 will handle the new functools.partialmethod support). By also making those enhancements available via getfullargpsec, we should significantly increase the amount of existing code which benefits automatically for those enhancements, as it will no longer require explicit migration to the new PEP 362 APIs at the application/library level. Reviewing the patch now. ---------- title: inspect.getfullargspec could use __signature__ -> inspect.getfullargspec should use __signature__ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 04:57:55 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 19 Jan 2014 03:57:55 +0000 Subject: [issue17811] Improve os.readv() and os.writev() documentation and docstring In-Reply-To: <1366579468.26.0.0312151391842.issue17811@psf.upfronthosting.co.za> Message-ID: <3f6Mfp5jJ7z7LjT@mail.python.org> Roundup Robot added the comment: New changeset 8b413f813a13 by Benjamin Peterson in branch '3.3': improve description of buffers argument for readv/writev (closes #17811) http://hg.python.org/cpython/rev/8b413f813a13 New changeset 4d56006133f1 by Benjamin Peterson in branch 'default': merge 3.3 (#17811) http://hg.python.org/cpython/rev/4d56006133f1 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 04:58:19 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sun, 19 Jan 2014 03:58:19 +0000 Subject: [issue20177] Derby #8: Convert 28 sites to Argument Clinic across 2 files In-Reply-To: <1389138574.32.0.892814928986.issue20177@psf.upfronthosting.co.za> Message-ID: <1390103899.02.0.265654491174.issue20177@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Hmm. After reading some of the threads on python-dev, I'm now confused if I did the conversion of optional arguments correctly. Should something like "strftime(format[, tuple])" be converted using optional groups, or should tuple become a parameter with a default value? (so far, I have done the latter). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 04:59:02 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Jan 2014 03:59:02 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1390103942.65.0.750008939044.issue17481@psf.upfronthosting.co.za> Larry Hastings added the comment: If we modify inspect.getfullargspec, shouldn't we modify inspect.getargspec too? "deprecated" doesn't mean "unsupported", it means "not recommended for new code, please stop using it". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 05:14:29 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Jan 2014 04:14:29 +0000 Subject: [issue20177] Derby #8: Convert 28 sites to Argument Clinic across 2 files In-Reply-To: <1389138574.32.0.892814928986.issue20177@psf.upfronthosting.co.za> Message-ID: <1390104869.4.0.224924196002.issue20177@psf.upfronthosting.co.za> Larry Hastings added the comment: Optional groups really are only for cases when that's the behavior of the original code. If the original function used a switch statement examining the size of the tuple, then had different parsing functions based on that size, use optional groups. But if the function can be expressed with normal positional parameters and default values, that's best. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 05:28:28 2014 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 19 Jan 2014 04:28:28 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1390105708.67.0.0268366455866.issue17481@psf.upfronthosting.co.za> Yury Selivanov added the comment: Larry, getargspec uses getfullargspec, so it's covered. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 05:36:06 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Jan 2014 04:36:06 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1390106166.02.0.167808185855.issue17481@psf.upfronthosting.co.za> Nick Coghlan added the comment: getargspec() is just a thin wrapper around getfullargspec(), so we get that for free. Similarly, getcallargs() is also implicitly updated to full PEP 362 support by changing the implementation of getfullargspec(). The other two standard library consumers appear to be IDLE (as Terry noted above) and xmlrpc.server.ServerHTMLDoc.docroutine (the self-documenting XML-RPC server API, which sadly appears to be lacking test cases). Reviewing those cases (especially the XML-RPC one) have convinced me we need a backwards compatibility fallback in the updated getfullargspec implementation. Specifically, if the new API throws ValueError (because it can't find a way to build a coherent signature object), we should fall back to the old approach. Otherwise we run the risk of introducing unexpected exceptions into introspection code. That is, the new call to signature in getfullargspec should look something like: try: sig = signature(func) except ValueError: if not hasattr(func, "__code__"): raise # The legacy fallback doesn't support this input type # The callable signature appears to be incoherent, so we fall # back to the legacy implementation to preserve compatibility args, varargs, kwonlyargs, varkw = _getfullargs(func.__code__) return FullArgSpec(args, varargs, varkw, func.__defaults__, kwonlyargs, func.__kwdefaults__, func.__annotations__) I suspect this may actually be a better solution for IDLE rather than updating it to call inspect.signature directly (since IDLE probably *wants* the more graceful fallback to the old behaviour). The way I would document all this in What's New is to update the current argument clinic section to also explain that we've taken advantage of PEP 362 to improve introspection in multiple areas, including for code that is using the introspection APIs that predate PEP 362. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 05:40:03 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Jan 2014 04:40:03 +0000 Subject: [issue20294] Argument Clinic: add support for __init__ In-Reply-To: <1390045406.06.0.938757132567.issue20294@psf.upfronthosting.co.za> Message-ID: <1390106403.12.0.602072346214.issue20294@psf.upfronthosting.co.za> Larry Hastings added the comment: Here's a patch. Wasn't as easy as I thought, it kind of took all day. Changes include: * __init__ and __new__ always take kwargs. * if the function signature doesn't accept keyword arguments, it calls _PyArg_NoKeywords(). * __init__ returns int, not PyObject *. * __init__ and __new__ should support all argument parsing scenarios (unpack tuple, positional only, etc). Pre-exiting behavior: * The C function basename chosen for __new__ is just the name of the class, it doesn't end in __new__. * The methoddef #define is suppressed. ---------- Added file: http://bugs.python.org/file33537/larry.argument.clinic.init.and.new.patch.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 05:52:22 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sun, 19 Jan 2014 04:52:22 +0000 Subject: [issue9521] xml.etree.ElementTree strips XML declaration and procesing instructions In-Reply-To: <1281000343.34.0.102578281876.issue9521@psf.upfronthosting.co.za> Message-ID: <1390107142.04.0.93645433408.issue9521@psf.upfronthosting.co.za> Nikolaus Rath added the comment: I can confirm this. The actual problem is that neither XML nor SGML PIs in the input make it into the etree, and no events are generated for them during incremental parsing. XML PIs that are added into the tree using Python functions are correctly written out. SGML PIs currently cannot be represented at all (there's no ElementTree.SGMLProcessingInstruction analogous to ElementTree.ProcessingInstruction) There is special cased support for the DOCTYPE element in the TreeBuilder class to allow retrieving the doctype when not parsing incrementally, but it needs to be retrieved manually and written out manually. I have attached a testcase for XML PIs. For proper SGML PI handling, ElementTree first needs to learn about them. Recommended stage for this issue: needs patch ---------- keywords: +patch nosy: +Nikratio versions: +Python 3.3, Python 3.4 -Python 3.1 Added file: http://bugs.python.org/file33538/testcase.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 05:53:36 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sun, 19 Jan 2014 04:53:36 +0000 Subject: [issue9521] xml.etree.ElementTree skips processing instructions when parsing In-Reply-To: <1281000343.34.0.102578281876.issue9521@psf.upfronthosting.co.za> Message-ID: <1390107216.64.0.943404094614.issue9521@psf.upfronthosting.co.za> Changes by Nikolaus Rath : ---------- title: xml.etree.ElementTree strips XML declaration and procesing instructions -> xml.etree.ElementTree skips processing instructions when parsing _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 06:23:40 2014 From: report at bugs.python.org (Zachary Ware) Date: Sun, 19 Jan 2014 05:23:40 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1390109020.9.0.269975077151.issue20189@psf.upfronthosting.co.za> Zachary Ware added the comment: Problems 1 (ValueError from help(os)) and 2 ('module' as first param) were simple fixes: The attached patch fixes problem 1 (and is probably worth doing anyway, since inspect.signature has the ability to raise ValueError, and (IMO) help() should never raise an exception. Problem 2 is just a matter of adding self.show_in_signature = False to the first param of module-level functions. I've left a review comment at the right line. Problem 3 would also be fixed by re-adding 'module' to c_keywords, but since you want it to work without that, that's out, and I'm not sure what the proper fix would be otherwise. The current patch no longer applies cleanly after #20287; I would just post an updated version of the entire patch with my changes as well, but the merge is not trivial and I don't want to screw it up :) ---------- keywords: +patch Added file: http://bugs.python.org/file33539/issue20189.pydoc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 06:39:40 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Sun, 19 Jan 2014 05:39:40 +0000 Subject: [issue20299] Argument Clinic CConverter.__init__() overrides c_default and py_default Message-ID: <1390109980.95.0.0734854690372.issue20299@psf.upfronthosting.co.za> New submission from Ryan Smith-Roberts: The docs indicate that you can do: class foo_converter(CConverter): ... c_default = 'bar()' py_default = 'Bar' except that CConverter.__init__() unconditionally overwrites these values. Patch attached. ---------- components: Build files: ac_overwritten_defaults.patch keywords: patch messages: 208447 nosy: larry, rmsr priority: normal severity: normal status: open title: Argument Clinic CConverter.__init__() overrides c_default and py_default type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file33540/ac_overwritten_defaults.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 06:46:48 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Sun, 19 Jan 2014 05:46:48 +0000 Subject: [issue20300] Argument Clinic raises exception for custom converter with default Message-ID: <1390110408.19.0.159719739162.issue20300@psf.upfronthosting.co.za> New submission from Ryan Smith-Roberts: If a custom converter declares both default and converter class attributes, you get this exception (test file attached): Exception raised during parsing: Traceback (most recent call last): File "Tools/clinic/clinic.py", line 1445, in parse parser.parse(block) File "Tools/clinic/clinic.py", line 2738, in parse self.state(None) File "Tools/clinic/clinic.py", line 3468, in state_terminal self.function.docstring = self.format_docstring() File "Tools/clinic/clinic.py", line 3344, in format_docstring s += "".join(a) TypeError: sequence item 2: expected str instance, NoneType found ---------- files: ac_converter_test.c messages: 208448 nosy: Nikratio, larry, rmsr priority: normal severity: normal status: open title: Argument Clinic raises exception for custom converter with default Added file: http://bugs.python.org/file33541/ac_converter_test.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 06:47:38 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Sun, 19 Jan 2014 05:47:38 +0000 Subject: [issue20300] Argument Clinic raises exception for custom converter with default In-Reply-To: <1390110408.19.0.159719739162.issue20300@psf.upfronthosting.co.za> Message-ID: <1390110458.31.0.564421217884.issue20300@psf.upfronthosting.co.za> Changes by Ryan Smith-Roberts : ---------- components: +Build type: -> crash versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 06:47:48 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Sun, 19 Jan 2014 05:47:48 +0000 Subject: [issue20299] Argument Clinic CConverter.__init__() overrides c_default and py_default In-Reply-To: <1390109980.95.0.0734854690372.issue20299@psf.upfronthosting.co.za> Message-ID: <1390110468.93.0.480999825356.issue20299@psf.upfronthosting.co.za> Changes by Ryan Smith-Roberts : ---------- nosy: +Nikratio _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 06:54:38 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 19 Jan 2014 05:54:38 +0000 Subject: [issue20299] Argument Clinic CConverter.__init__() overrides c_default and py_default In-Reply-To: <1390109980.95.0.0734854690372.issue20299@psf.upfronthosting.co.za> Message-ID: <3f6QFT3sNszSVp@mail.python.org> Roundup Robot added the comment: New changeset 8f11493cf727 by Larry Hastings in branch 'default': Issue #20299: Argument Clinic custom converters may now change the default http://hg.python.org/cpython/rev/8f11493cf727 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 06:55:23 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Jan 2014 05:55:23 +0000 Subject: [issue20299] Argument Clinic CConverter.__init__() overrides c_default and py_default In-Reply-To: <1390109980.95.0.0734854690372.issue20299@psf.upfronthosting.co.za> Message-ID: <1390110923.51.0.452802994959.issue20299@psf.upfronthosting.co.za> Larry Hastings added the comment: Checked in. Thanks for the report, and the patch! I worked so quickly, I just realized, I didn't credit you in the NEWS file for the fix. Do you want me to fix that? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 06:55:35 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Jan 2014 05:55:35 +0000 Subject: [issue20299] Argument Clinic CConverter.__init__() overrides c_default and py_default In-Reply-To: <1390109980.95.0.0734854690372.issue20299@psf.upfronthosting.co.za> Message-ID: <1390110935.64.0.929609070344.issue20299@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- assignee: -> larry resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 06:59:29 2014 From: report at bugs.python.org (Zachary Ware) Date: Sun, 19 Jan 2014 05:59:29 +0000 Subject: [issue20294] Argument Clinic: add support for __init__ In-Reply-To: <1390045406.06.0.938757132567.issue20294@psf.upfronthosting.co.za> Message-ID: <1390111169.92.0.470006955972.issue20294@psf.upfronthosting.co.za> Zachary Ware added the comment: Rietveld doesn't like the patch and I'm having a hard time finding a changeset on which I can get it to apply cleanly. May I suggest avoiding `--git` on `hg diff` unless copying/moving/renaming a file? ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 06:59:46 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Sun, 19 Jan 2014 05:59:46 +0000 Subject: [issue20299] Argument Clinic CConverter.__init__() overrides c_default and py_default In-Reply-To: <1390109980.95.0.0734854690372.issue20299@psf.upfronthosting.co.za> Message-ID: <1390111186.76.0.643225220157.issue20299@psf.upfronthosting.co.za> Ryan Smith-Roberts added the comment: No, I'm happy. It isn't really news anyway, since the patch just brings reality inline with the docs :). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 07:10:46 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Jan 2014 06:10:46 +0000 Subject: [issue20294] Argument Clinic: add support for __init__ In-Reply-To: <1390045406.06.0.938757132567.issue20294@psf.upfronthosting.co.za> Message-ID: <1390111846.75.0.859603351031.issue20294@psf.upfronthosting.co.za> Larry Hastings added the comment: Whoops, that doesn't apply cleanly. Here's an updated patch. ---------- Added file: http://bugs.python.org/file33542/larry.argument.clinic.init.and.new.patch.2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 07:19:34 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 19 Jan 2014 06:19:34 +0000 Subject: [issue20295] imghdr add openexr support In-Reply-To: <1390070746.18.0.632580086157.issue20295@psf.upfronthosting.co.za> Message-ID: <1390112374.47.0.35823358502.issue20295@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 Sun Jan 19 07:21:50 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 19 Jan 2014 06:21:50 +0000 Subject: [issue20122] Move CallTips tests to idle_tests In-Reply-To: <1388852698.51.0.14863260737.issue20122@psf.upfronthosting.co.za> Message-ID: <1390112510.57.0.145795706239.issue20122@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Attached is patch for 2.7 with all tests passing. 3.x get_argspec cannot replace 2.x get_arg_text because it uses inspect.getfullargspec, which does not exist in 2.7. (Its use made the code simpler.) Besides minor changes in test_calltips.py, I made 3 changes to get_arg_text() to get tests to pass. 1. Stop deleting first parameter for unbound methods (bugfix). 2. Replace class instances with __call__ methods (bugfix). 3. Change tip for def f(*some_name, **other_name) from '(..., ***)' to '(*args, **kwds)'. 2.7 either does not keep the dummy names, which anyway cannot be used when calling , or the current code makes no effort to retrieve them. My reasons for 3. are that the replacement is a) the current convention everywhere else, b) more like the corresponding 3.x tip (which has the exact names), and c) more indicative of what one actually writes in a call. ---------- Added file: http://bugs.python.org/file33543/test_calltips-27.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 07:40:29 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Jan 2014 06:40:29 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1390113629.63.0.973627376607.issue20189@psf.upfronthosting.co.za> Larry Hastings added the comment: Your fixes for #1 and #2 were fine, I've incorporated them into the patch. I'll update the diff after I've added the tests Nick suggested. The assertion failure in #3 will also be gone, replaced with a failure: You can't have two parameters named module! The problem is that we silently inserted a self converter for the first argument, and because this is a module-level function, that "self" parameter is naturally named "module". I have a fix in mind for this: basically to teach Argument Clinic that the parser function and impl function have different namespaces, and to map names in the first to the second. So, you could have a parameter named "args", and Clinic would notice, and rename the variable in the parser function "args_value" or something, and then pass it in in the right spot. Once I've done that, it'd be easy to make it also rename the secret self converter name to "_module" or something. Anyway, long story short, let's not try to fix #3 in this patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 07:46:41 2014 From: report at bugs.python.org (Zachary Ware) Date: Sun, 19 Jan 2014 06:46:41 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1390113629.63.0.973627376607.issue20189@psf.upfronthosting.co.za> Message-ID: Zachary Ware added the comment: Larry Hastings added the comment: > Once I've done that, it'd be easy to make it also rename the secret self converter name to "_module" or something. Anyway, long story short, let's not try to fix #3 in this patch. That sounds fine. _winapi is the only place I've seen that has a 'module' parameter and it's not finished yet anyway, so it can wait a bit more (less than a week, though ;-). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 08:06:37 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 19 Jan 2014 07:06:37 +0000 Subject: [issue20293] pydoc fails with the "unspecified" default value In-Reply-To: <1390045398.5.0.236293557583.issue20293@psf.upfronthosting.co.za> Message-ID: <1390115197.55.0.680988090434.issue20293@psf.upfronthosting.co.za> Berker Peksag added the comment: > I just built from a new clone of trunk, and it works fine for me. It works fine for me, too (revision 8f11493cf727). ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 08:20:34 2014 From: report at bugs.python.org (Zachary Ware) Date: Sun, 19 Jan 2014 07:20:34 +0000 Subject: [issue20294] Argument Clinic: add support for __init__ In-Reply-To: <1390045406.06.0.938757132567.issue20294@psf.upfronthosting.co.za> Message-ID: <1390116034.23.0.13730590972.issue20294@psf.upfronthosting.co.za> Zachary Ware added the comment: Output looks good and I didn't see anything that scared me in the patch, though I can't pretend to fully understand 100% of it. Builds on Windows, pickle tests pass, and nothing else is affected (that's checked in so far). Looks good to me, as far as I can see. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 08:23:07 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Sun, 19 Jan 2014 07:23:07 +0000 Subject: [issue20294] Argument Clinic: add support for __init__ In-Reply-To: <1390045406.06.0.938757132567.issue20294@psf.upfronthosting.co.za> Message-ID: <1390116187.15.0.825078287966.issue20294@psf.upfronthosting.co.za> Ryan Smith-Roberts added the comment: I have reviewed this as best I am able. I'll be honest that a lot of clinic.py makes my eyes cross; I'm used to webdev templating, which is inverted from AC (flow control inside the template). Not complaining, it's a complicated subject. I do like the centralization of the templates. I didn't see anything that jumped out at me. I tried out the new conversions on socketmodule and like the output, and none of the existing conversions mutated. So LGTM! It took me a while to figure out how to make __new__ a class method though, decorator support should probably be documented (or else a hint like '__new__ must be a @classmethod!') ---------- nosy: +rmsr _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 08:50:47 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 19 Jan 2014 07:50:47 +0000 Subject: [issue20294] Argument Clinic: add support for __init__ In-Reply-To: <1390045406.06.0.938757132567.issue20294@psf.upfronthosting.co.za> Message-ID: <3f6SqV342pzSYt@mail.python.org> Roundup Robot added the comment: New changeset 2e32462e4832 by Larry Hastings in branch 'default': Issue #20294: Argument Clinic now supports argument parsing for __new__ and http://hg.python.org/cpython/rev/2e32462e4832 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 08:51:59 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Jan 2014 07:51:59 +0000 Subject: [issue20294] Argument Clinic: add support for __init__ In-Reply-To: <1390045406.06.0.938757132567.issue20294@psf.upfronthosting.co.za> Message-ID: <1390117919.8.0.244088289479.issue20294@psf.upfronthosting.co.za> Larry Hastings added the comment: Checked in. Thanks for bringing the problem to my attention, Serhiy, and thanks for the reviews you two! rmsr: If I had a stronger background in templating, maybe Argument Clinic would be cleaner inside. As it is I'm beating the problem to death with sheer force of will. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 09:06:03 2014 From: report at bugs.python.org (Justin Foo) Date: Sun, 19 Jan 2014 08:06:03 +0000 Subject: [issue20301] Correct docs for default access argument for DeleteKeyEx Message-ID: <1390118763.24.0.151649669148.issue20301@psf.upfronthosting.co.za> New submission from Justin Foo: The default access for winreg.DeleteKeyEx is winreg.KEY_WOW64_64KEY (as per the function signature). This the documentation for Python 2.7 has this correct. Reference: http://hg.python.org/cpython/file/2e32462e4832/PC/winreg.c#l1089 ---------- assignee: docs at python components: Documentation files: winreg.DeleteKeyEx.docs.patch keywords: patch messages: 208462 nosy: docs at python, jfoo priority: normal severity: normal status: open title: Correct docs for default access argument for DeleteKeyEx versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33544/winreg.DeleteKeyEx.docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 09:08:26 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 19 Jan 2014 08:08:26 +0000 Subject: [issue20301] Correct docs for default access argument for DeleteKeyEx In-Reply-To: <1390118763.24.0.151649669148.issue20301@psf.upfronthosting.co.za> Message-ID: <1390118906.38.0.983270600165.issue20301@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +brian.curtin, tim.golden stage: -> patch review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 09:23:11 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 19 Jan 2014 08:23:11 +0000 Subject: [issue19906] Typo in urllib documentation In-Reply-To: <1386326764.33.0.520291465102.issue19906@psf.upfronthosting.co.za> Message-ID: <1390119791.52.0.205795143197.issue19906@psf.upfronthosting.co.za> Ezio Melotti added the comment: I think that what the note was trying to say is that urlopen in Python 3 is equivalent to urllib2.urlopen in Python 2, so before switching to Python 3, people might want to move from urllib.urlopen to urllib2.urlopen. Does the attached patch sound better? ---------- Added file: http://bugs.python.org/file33545/issue19906.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 09:40:05 2014 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 19 Jan 2014 08:40:05 +0000 Subject: [issue9521] xml.etree.ElementTree skips processing instructions when parsing In-Reply-To: <1281000343.34.0.102578281876.issue9521@psf.upfronthosting.co.za> Message-ID: <1390120805.03.0.584395154493.issue9521@psf.upfronthosting.co.za> Changes by Stefan Behnel : ---------- nosy: +eli.bendersky, scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 10:01:29 2014 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 19 Jan 2014 09:01:29 +0000 Subject: [issue9521] xml.etree.ElementTree skips processing instructions when parsing In-Reply-To: <1281000343.34.0.102578281876.issue9521@psf.upfronthosting.co.za> Message-ID: <1390122089.49.0.406288540494.issue9521@psf.upfronthosting.co.za> Stefan Behnel added the comment: When you write "XML PI", do you mean the XML declaration? At least that's what Mark used in his original example. ET avoids writing them out when they are not necessary, i.e. for UTF-8 compatible encodings. IMHO that's perfectly ok and definitely not an incorrect behaviour. As for processing instructions (what you used in your test case patch), making them appear in the tree by default would be a behavioural change that might break existing ET code. Note that lxml keeps PIs in the tree by default, unless you configure its parser explicitly with "remove_pis=True". There is also a "remove_comments=True" in lxml. ET simply discards comments when parsing IIRC. http://lxml.de/parsing.html#parser-options IMHO, both behaviours are ok, which lxml having a tendency towards keeping the data as it came in rather than trying to find the easiest possible way for the user to work with the tree. PIs and comments are a bit 'special' to work with. A fix could be to add the two keyword arguments also to ET's parser, but make them default to True (as opposed to False in lxml), so that users can enable them at need. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 10:01:48 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Jan 2014 09:01:48 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1390122108.9.0.890472100995.issue20189@psf.upfronthosting.co.za> Larry Hastings added the comment: Here is the hopefully-final patch for this issue. I incorporated the suggested changes from Zachary Ware. Also I fixed some "cls" parameters that were leaking into the signatures. I think this is ready for checkin! ---------- Added file: http://bugs.python.org/file33546/larry.support.text_signature.on.more.types.diff.5.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 10:12:30 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Jan 2014 09:12:30 +0000 Subject: [issue20293] pydoc fails with the "unspecified" default value In-Reply-To: <1390045398.5.0.236293557583.issue20293@psf.upfronthosting.co.za> Message-ID: <1390122750.78.0.195868812234.issue20293@psf.upfronthosting.co.za> Larry Hastings added the comment: Closing. Reopen it if you get a reproducible test case with a fresh checkout of trunk. ---------- resolution: -> works for me stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 11:21:16 2014 From: report at bugs.python.org (Martin Vignali) Date: Sun, 19 Jan 2014 10:21:16 +0000 Subject: [issue20295] imghdr add openexr support In-Reply-To: <1390070746.18.0.632580086157.issue20295@psf.upfronthosting.co.za> Message-ID: <1390126876.88.0.659827005587.issue20295@psf.upfronthosting.co.za> Martin Vignali added the comment: New patch with formatting correction and documentation update. I'm not sure about the place of the versionadded directive in the documentation. ---------- Added file: http://bugs.python.org/file33547/img_hdr_exr_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 11:28:00 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 19 Jan 2014 10:28:00 +0000 Subject: [issue20300] Argument Clinic raises exception for custom converter with default In-Reply-To: <1390110408.19.0.159719739162.issue20300@psf.upfronthosting.co.za> Message-ID: <3f6XJv1X4Kz7LjM@mail.python.org> Roundup Robot added the comment: New changeset cc53c49d38c8 by Larry Hastings in branch 'default': Issue #20300: Fix exception when setting conversion class member "default" http://hg.python.org/cpython/rev/cc53c49d38c8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 11:28:56 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Jan 2014 10:28:56 +0000 Subject: [issue20300] Argument Clinic raises exception for custom converter with default In-Reply-To: <1390110408.19.0.159719739162.issue20300@psf.upfronthosting.co.za> Message-ID: <1390127336.13.0.212316832829.issue20300@psf.upfronthosting.co.za> Larry Hastings added the comment: Thanks for the report. It was an easy fix. That said, I can't say I'm excited by the idea of a custom converter with a built-in default value. I hope you know what you're doing! ---------- assignee: -> larry components: +Demos and Tools -Build resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 11:33:46 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 19 Jan 2014 10:33:46 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1390127626.55.0.213916480383.issue17481@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The relevant code in CallTips.py is argspec = "" if hasattr(ob, '__call__'): ... if isinstance(fob, (types.FunctionType, types.MethodType)): argspec = inspect.formatargspec(*inspect.getfullargspec(fob)) So I want to broaden the second condition (or remove it), but if it returns something .formatargspec cannot digest, the outer call will have to be conditioned. My impression is that str(signature object) returns pretty much what .formatargspec does, but I have not experimented yet. My #20122 patch moves currently commented out tests in CallTips.py that use the above to test_calltips.py. I will commit as soon as I test on 3.4. Until then, getfullargspec is not being used in the Idle test suite. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 11:44:43 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Jan 2014 10:44:43 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1390128283.34.0.158345143237.issue17481@psf.upfronthosting.co.za> Larry Hastings added the comment: I just want to mention, while we're all thinking about this stuff: I plan to enhance the Signature object to reflect "optional groups". Right now Signature objects cannot express parameters that are optional but don't have a published default. (e.g. a string parameter for a builtin having a default of NULL). A lot of these are being converted using optional groups, and I want to make it at least possible for user code to introspect those functions and understand that those are optional parameters. My original plan was to add a "group" member, containing an arbitrary identifier of the "group" this parameter belongs to. I'm not sure that's sufficient; I may also need a "parent_group" parameter, or something like that, to represent the group that this group is nested in. I'm still thinking about it. But I'm hoping to get to this in the next two or three days. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 11:52:06 2014 From: report at bugs.python.org (SilentGhost) Date: Sun, 19 Jan 2014 10:52:06 +0000 Subject: [issue20295] imghdr add openexr support In-Reply-To: <1390070746.18.0.632580086157.issue20295@psf.upfronthosting.co.za> Message-ID: <1390128725.99.0.797783874814.issue20295@psf.upfronthosting.co.za> SilentGhost added the comment: Martin, it would be better if you do the check the way it's done in test_rast: h.startswith(b'\x76\x2f\x31\x01') Otherwise, you need to check that that h has at least 4 elements (if it doesn't you'll get an IndexError). ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 12:01:51 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 19 Jan 2014 11:01:51 +0000 Subject: [issue20300] Argument Clinic raises exception for custom converter with default In-Reply-To: <1390110408.19.0.159719739162.issue20300@psf.upfronthosting.co.za> Message-ID: <3f6Y3y6qTJz7Ljg@mail.python.org> Roundup Robot added the comment: New changeset d0e2437136f5 by Larry Hastings in branch 'default': Improve fix for issue #20300. http://hg.python.org/cpython/rev/d0e2437136f5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 12:44:27 2014 From: report at bugs.python.org (Francis Moreau) Date: Sun, 19 Jan 2014 11:44:27 +0000 Subject: [issue3907] "for line in file" doesn't work for pipes In-Reply-To: <1221793104.87.0.563162519119.issue3907@psf.upfronthosting.co.za> Message-ID: <1390131867.76.0.248784628032.issue3907@psf.upfronthosting.co.za> Francis Moreau added the comment: Sorry for reopening this bug, but I agree with the OP, and I can still see the exact same behaviour on python 2.7.6 (archlinux). At least, the documentation should clarify that doing "for line in file" is not strictly equivalent to the "readline" way regarding to the buffering policy used with pipes. I'm also dubious about the buffering optimisation for the pipe case but readline() documentation should state that it will never use such buffering mechanism so we can safely use it when dealing with pipe. Thanks ---------- nosy: +fmoreau _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 13:15:03 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Jan 2014 12:15:03 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1390128283.34.0.158345143237.issue17481@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: Sounds reasonable - we'll need that to convert range() and slice() anyway (I totally failed at finding time to look at the builtins this weekend, but I'd still like to handle those before the 3rd beta). An alternative would be to actually add "ParameterGroup" as a new class that contains parameters (assuming tuple isn't sufficient), so the structure of the parameters more directly matches the underlying signature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 14:11:53 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Jan 2014 13:11:53 +0000 Subject: [issue20302] Argument Clinic: meaningful names for group flags Message-ID: <1390137113.2.0.816137026514.issue20302@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Currently flags for optional groups are named as group_left_N and group_right_N. It will be better if they have names use_param, use_param1_param2, etc. E.g. following declaration: /*[clinic input] curses.window.addstr self: self(type="PyCursesWindowObject *") [ y: int Y-coordinate. x: int X-coordinate. ] str: object String to add. [ attr: long Attributes for the character. ] / [clinic start generated code]*/ Should produce signature: static PyObject * curses_window_addstr_impl(PyCursesWindowObject *self, int use_x_y, int y, int x, PyObject *str, int use_attr, long attr) (Existing non-clinicalized code use use_xy and use_attr flags). This will make the code a little cleaner. ---------- components: Build, Demos and Tools messages: 208476 nosy: larry, serhiy.storchaka priority: low severity: normal stage: needs patch status: open title: Argument Clinic: meaningful names for group flags type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 14:23:08 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Jan 2014 13:23:08 +0000 Subject: [issue20293] pydoc fails with the "unspecified" default value In-Reply-To: <1390045398.5.0.236293557583.issue20293@psf.upfronthosting.co.za> Message-ID: <1390137788.75.0.126015742018.issue20293@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I just built from a new clone of trunk (last revision is d0e2437136f5), and I still get the error. ---------- resolution: works for me -> stage: committed/rejected -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 14:29:40 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Jan 2014 13:29:40 +0000 Subject: [issue20303] Argument Clinic: optional groups Message-ID: <1390138180.16.0.400473002032.issue20303@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: This is very very low priority issue. Currently Argument Clinic can't process following declaration: /*[clinic input] curses.window.chgat self: self(type="PyCursesWindowObject *") [ y: int Y-coordinate. x: int X-coordinate. ] [ num: int Number of characters. ] attr: long Attributes for the character. / [clinic start generated code]*/ This stops three methods in the curse module to be converted to Argument Clinic. ---------- components: Build, Demos and Tools messages: 208478 nosy: larry, serhiy.storchaka priority: low severity: normal status: open title: Argument Clinic: optional groups type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 14:31:53 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Jan 2014 13:31:53 +0000 Subject: [issue20298] json library needs a non-strict option to decode single-quoted strings In-Reply-To: <1390097954.47.0.6743273993.issue20298@psf.upfronthosting.co.za> Message-ID: <1390138313.21.0.180219320255.issue20298@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +ezio.melotti, pitrou, rhettinger versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 14:53:13 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Jan 2014 13:53:13 +0000 Subject: [issue20298] json library needs a non-strict option to decode single-quoted strings In-Reply-To: <1390097954.47.0.6743273993.issue20298@psf.upfronthosting.co.za> Message-ID: <1390139593.86.0.0300068485728.issue20298@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think this is just not JSON. Try to use YAML parsers. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 15:39:23 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Sun, 19 Jan 2014 14:39:23 +0000 Subject: [issue19974] tarfile doesn't overwrite symlink by directory In-Reply-To: <1386935948.7.0.893963676407.issue19974@psf.upfronthosting.co.za> Message-ID: <1390142363.45.0.660809337171.issue19974@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Ah, thanks for the review, Serhiy. My bad. There is no underlying bug of tar. I was confused by the behaviour of tar which is converting the absolute path to relative path. So, adding '/home/user/dir/file' to tar when you are in '/home/user/dir' then extracting it in the same place, you'll get: '/home/user/dir/home/user/dir/file'. I thought it was a bug. But this is what it is supposed to be. I see that tarfile module is mimicking GNU tar behaviour. This is the updated patch. ---------- Added file: http://bugs.python.org/file33548/fix_tarfile_overwrites_symlink_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 16:51:05 2014 From: report at bugs.python.org (Tal Einat) Date: Sun, 19 Jan 2014 15:51:05 +0000 Subject: [issue20304] Argument Clinic: char convertor should use default values of type bytes Message-ID: <1390146665.62.0.375243979235.issue20304@psf.upfronthosting.co.za> New submission from Tal Einat: For example, in `Object/stringlib/transmogrify.h`, the methods `ljust` and `rjust` have an argument named `fillchar` of type char. It's Python default value should be b' ', but the only way I've found to do that is by setting `py_default = b' '`. ---------- components: Build, Demos and Tools messages: 208481 nosy: larry, taleinat priority: normal severity: normal status: open title: Argument Clinic: char convertor should use default values of type bytes type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 16:53:37 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Sun, 19 Jan 2014 15:53:37 +0000 Subject: [issue19974] tarfile doesn't overwrite symlink by directory In-Reply-To: <1386935948.7.0.893963676407.issue19974@psf.upfronthosting.co.za> Message-ID: <1390146817.57.0.773431649817.issue19974@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Serhiy commented, "I think we should remove targetpath in all cases. Not only when softlink is extracted." I already did that in my latest patch but I am a little bit wary of this behaviour. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 17:05:52 2014 From: report at bugs.python.org (Tal Einat) Date: Sun, 19 Jan 2014 16:05:52 +0000 Subject: [issue20304] Argument Clinic: char convertor should use default values of type bytes In-Reply-To: <1390146665.62.0.375243979235.issue20304@psf.upfronthosting.co.za> Message-ID: <1390147552.3.0.578579941463.issue20304@psf.upfronthosting.co.za> Tal Einat added the comment: Additionally, the char converter doesn't create valid c defaults. For example, I got " " instead of ' ' for fillchar, which has type char, so I had to manually set c_default = "' '". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 18:16:57 2014 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 19 Jan 2014 17:16:57 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1390128283.34.0.158345143237.issue17481@psf.upfronthosting.co.za> Message-ID: <16C1C4279A984CAF85EB4779CAB9913C@gmail.com> Yury Selivanov added the comment: Larry, I saw your message on the tracker regarding adding support for parameters groups to the signature object. Would you mind if I join the discussion with my ideas of how this feature might be implemented? Yury On Sunday, January 19, 2014 at 5:44 AM, Larry Hastings wrote: > > Larry Hastings added the comment: > > I just want to mention, while we're all thinking about this stuff: I plan to enhance the Signature object to reflect "optional groups". Right now Signature objects cannot express parameters that are optional but don't have a published default. (e.g. a string parameter for a builtin having a default of NULL). A lot of these are being converted using optional groups, and I want to make it at least possible for user code to introspect those functions and understand that those are optional parameters. > > My original plan was to add a "group" member, containing an arbitrary identifier of the "group" this parameter belongs to. I'm not sure that's sufficient; I may also need a "parent_group" parameter, or something like that, to represent the group that this group is nested in. I'm still thinking about it. But I'm hoping to get to this in the next two or three days. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- nosy: +Yury.Selivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 18:23:38 2014 From: report at bugs.python.org (Nadeem Vawda) Date: Sun, 19 Jan 2014 17:23:38 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1390152218.17.0.812801868121.issue20193@psf.upfronthosting.co.za> Nadeem Vawda added the comment: The patches for bz2 and lzma look good to me, aside from one nit for lzma. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 19:13:22 2014 From: report at bugs.python.org (Shiz) Date: Sun, 19 Jan 2014 18:13:22 +0000 Subject: [issue20305] Android's incomplete locale.h implementation prevents compilation Message-ID: <1390155202.76.0.360148898057.issue20305@psf.upfronthosting.co.za> New submission from Shiz: As a result of Android's relatively incomplete locale.h implementation[1], some functions are not defined and some standard structs are lacking fields (e.g. decimal_point, thousand_sep). This prevents proper cross-compilation using the Android NDK[2] from succeeding. Attached is a patch which works around the various issues posed by Android's locale.h implementation, mainly involving falling back to default locale values, causing compilation in that department for the author to succeed. [1]: https://groups.google.com/forum/#!topic/android-ndk/PBK4KkRpDoU [2]: https://developer.android.com/tools/sdk/ndk/index.html ---------- components: Cross-Build files: Python-3.4.0tip-workaround-android-locale-issues.patch keywords: patch messages: 208486 nosy: shiz priority: normal severity: normal status: open title: Android's incomplete locale.h implementation prevents compilation type: compile error versions: Python 3.4 Added file: http://bugs.python.org/file33549/Python-3.4.0tip-workaround-android-locale-issues.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 19:13:49 2014 From: report at bugs.python.org (Shiz) Date: Sun, 19 Jan 2014 18:13:49 +0000 Subject: [issue20305] Android's incomplete locale.h implementation prevents cross-compilation In-Reply-To: <1390155202.76.0.360148898057.issue20305@psf.upfronthosting.co.za> Message-ID: <1390155229.77.0.0340580770156.issue20305@psf.upfronthosting.co.za> Changes by Shiz : ---------- title: Android's incomplete locale.h implementation prevents compilation -> Android's incomplete locale.h implementation prevents cross-compilation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 19:19:09 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Jan 2014 18:19:09 +0000 Subject: [issue20305] Android's incomplete locale.h implementation prevents cross-compilation In-Reply-To: <1390155202.76.0.360148898057.issue20305@psf.upfronthosting.co.za> Message-ID: <1390155549.12.0.392657816593.issue20305@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +lemburg, loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 19:23:41 2014 From: report at bugs.python.org (Shiz) Date: Sun, 19 Jan 2014 18:23:41 +0000 Subject: [issue20306] Lack of pw_gecos field in Android's struct passwd causes cross-compilation for the pwd module to fail Message-ID: <1390155821.88.0.335321844624.issue20306@psf.upfronthosting.co.za> New submission from Shiz: As the title states, mkpwent() in pwdmodule.c accesses `pw_gecos`, which is not defined for struct passwd in Bionic, Android's C library. Attached is a patch that works around the issue by setting the field to None on Android. ---------- components: Cross-Build files: Python-3.4.0tip-workaround-android-missing-pw_gecos-field.patch keywords: patch messages: 208487 nosy: shiz priority: normal severity: normal status: open title: Lack of pw_gecos field in Android's struct passwd causes cross-compilation for the pwd module to fail type: compile error versions: Python 3.4 Added file: http://bugs.python.org/file33550/Python-3.4.0tip-workaround-android-missing-pw_gecos-field.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 19:27:50 2014 From: report at bugs.python.org (Shiz) Date: Sun, 19 Jan 2014 18:27:50 +0000 Subject: [issue20307] Android's failure to expose SYS_* system call constants causes _posixsubprocess cross-compilation to fail Message-ID: <1390156070.61.0.536992358716.issue20307@psf.upfronthosting.co.za> New submission from Shiz: Bionic, Android's C library, fails to expose the SYS_* constants used for the syscall(1) interface, which causes compilation of the _posixsubprocess module to fail as it directly attempts to call SYS_getdents64. Attached is an experimental patch that manually defines SYS_getdents64 from Bionic's internals. ---------- components: Cross-Build files: Python-3.4.0tip-expose-SYS_getdents64-on-android.patch keywords: patch messages: 208488 nosy: shiz priority: normal severity: normal status: open title: Android's failure to expose SYS_* system call constants causes _posixsubprocess cross-compilation to fail type: compile error versions: Python 3.4 Added file: http://bugs.python.org/file33551/Python-3.4.0tip-expose-SYS_getdents64-on-android.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 19:29:22 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sun, 19 Jan 2014 18:29:22 +0000 Subject: [issue20305] Android's incomplete locale.h implementation prevents cross-compilation In-Reply-To: <1390155202.76.0.360148898057.issue20305@psf.upfronthosting.co.za> Message-ID: <1390156162.07.0.392968226817.issue20305@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: I'd be +1 on such a patch if we were to officially support Android, but we'd need a volunteer to champion for this (which would be a good thing, IMO). Otherwise, such changes need to be maintained externally. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 19:41:40 2014 From: report at bugs.python.org (Shiz) Date: Sun, 19 Jan 2014 18:41:40 +0000 Subject: [issue20307] Android's failure to expose SYS_* system call constants causes _posixsubprocess cross-compilation to fail In-Reply-To: <1390156070.61.0.536992358716.issue20307@psf.upfronthosting.co.za> Message-ID: <1390156900.2.0.355129799036.issue20307@psf.upfronthosting.co.za> Shiz added the comment: I of course meant the syscall(2) interface, not syscall(1). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 19:43:51 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 19 Jan 2014 18:43:51 +0000 Subject: [issue19990] Add unittests for imghdr module In-Reply-To: <1387146470.57.0.419345603545.issue19990@psf.upfronthosting.co.za> Message-ID: <1390157031.0.0.47115761728.issue19990@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Hello. Here's a new version which uses real image files as testing data. ---------- Added file: http://bugs.python.org/file33552/test_imghdr_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 20:09:59 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 19 Jan 2014 19:09:59 +0000 Subject: [issue19997] imghdr.what doesn't accept bytes paths In-Reply-To: <1387198093.92.0.388328564702.issue19997@psf.upfronthosting.co.za> Message-ID: <1390158599.23.0.665390701261.issue19997@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Updated patch to use real image files from issue #19990. ---------- Added file: http://bugs.python.org/file33553/imghdr_bytes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 20:13:27 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 19 Jan 2014 19:13:27 +0000 Subject: [issue19906] Typo in urllib documentation In-Reply-To: <1386326764.33.0.520291465102.issue19906@psf.upfronthosting.co.za> Message-ID: <1390158807.7.0.693271851403.issue19906@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Yep, it sounds better. There's an additional warning in urllib.urlopen which states a similar thing: warnpy3k("urllib.urlopen() has been removed in Python 3.0 in " "favor of urllib2.urlopen()", stacklevel=2) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 20:20:05 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 19 Jan 2014 19:20:05 +0000 Subject: [issue19776] Provide expanduser() on Path objects In-Reply-To: <1385409778.55.0.842571848249.issue19776@psf.upfronthosting.co.za> Message-ID: <1390159205.46.0.0100377770644.issue19776@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Antoine, is this feature still wanted? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 21:07:36 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 19 Jan 2014 20:07:36 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1390162056.83.0.363556658017.issue17481@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Yuri, I am sure your ideas for enhancing signature objects would be welcome. Either a new issue or a thread on pydev or python-ideas lists would be best. When responding by email, please snip the quotation and footer, except possibly a line of the quoted message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 21:11:36 2014 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 19 Jan 2014 20:11:36 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1390162296.45.0.0393003995566.issue17481@psf.upfronthosting.co.za> Yury Selivanov added the comment: Terry, Thanks. > When responding by email, please snip the quotation and footer, except possibly a line of the quoted message. My email client played an evil (and a bit embarrassing) trick with me, showing Larry's name without an actual email address, which was "report at bugs.python.org". Won't happen again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 21:13:31 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Jan 2014 20:13:31 +0000 Subject: [issue20294] Argument Clinic: add support for __init__ In-Reply-To: <1390045406.06.0.938757132567.issue20294@psf.upfronthosting.co.za> Message-ID: <1390162411.54.0.311982287018.issue20294@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Larry, now I can use Argument Clinic in the __init__ methods. But there is one problem. Docstring generated for the __init__ method contains the "__init__" name in the signature. Therefore it can't be used as class docstring. On other hand, the compiler complains of not used __init__ docstring. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 21:18:51 2014 From: report at bugs.python.org (Martin Vignali) Date: Sun, 19 Jan 2014 20:18:51 +0000 Subject: [issue20295] imghdr add openexr support In-Reply-To: <1390070746.18.0.632580086157.issue20295@psf.upfronthosting.co.za> Message-ID: <1390162731.42.0.947367689238.issue20295@psf.upfronthosting.co.za> Martin Vignali added the comment: You're right, i make the correction, in a new patch. I make other tests, with official sample files : http://download.savannah.nongnu.org/releases/openexr/openexr-images-1.4.0.tar.gz ---------- Added file: http://bugs.python.org/file33554/img_hdr_exr_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 21:23:14 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 19 Jan 2014 20:23:14 +0000 Subject: [issue20295] imghdr add openexr support In-Reply-To: <1390070746.18.0.632580086157.issue20295@psf.upfronthosting.co.za> Message-ID: <1390162994.6.0.966039909695.issue20295@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Hi, Martin. Please see issue19990, which tries to add unit tests for imghdr module. It would be nice if you could expand on it with an exr file, for your use case. ---------- nosy: +Claudiu.Popa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 22:25:52 2014 From: report at bugs.python.org (=?utf-8?q?Kim_Gr=C3=A4sman?=) Date: Sun, 19 Jan 2014 21:25:52 +0000 Subject: [issue18314] Have os.unlink remove junction points In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za> Message-ID: <1390166752.54.0.201379723006.issue18314@psf.upfronthosting.co.za> Kim Gr?sman added the comment: Thanks! There's another thing I would appreciate having somebody else test: creating and removing junctions in a non-elevated prompt. I haven't been able to, my IT department has trouble understanding the value of least-privilege. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 22:33:26 2014 From: report at bugs.python.org (Stefan Krah) Date: Sun, 19 Jan 2014 21:33:26 +0000 Subject: [issue20246] buffer overflow in socket.recvfrom_into In-Reply-To: <1390092911.12.0.503833450412.issue20246@psf.upfronthosting.co.za> Message-ID: <20140119213325.GA18666@sleipnir.bytereef.org> Stefan Krah added the comment: MSG*1024 passes. I did not look at this issue: Would changing the value to 1024 invalidate the test? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 22:52:39 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Jan 2014 21:52:39 +0000 Subject: [issue20308] inspect.Signature doesn't support user classes without __init__ or __new__ Message-ID: <1390168359.82.0.306015564457.issue20308@psf.upfronthosting.co.za> New submission from Larry Hastings: Boy was I surprised by this: >>> class C: pass ... >>> import inspect >>> inspect.signature(C) Traceback (most recent call last): File "", line 1, in File "/home/larry/src/python/clinic_c_types_hacking/Lib/inspect.py", line 1557, in signature raise ValueError('callable {!r} is not supported by signature'.format(obj)) ValueError: callable is not supported by signature Why not? C is a callable object. If you can't find a __new__ or an __init__ in the class, its signature should be pretty predictable. (It returns a signature if you add either a __new__, an __init__, or both.) ---------- components: Library (Lib) messages: 208502 nosy: brett.cannon, larry, ncoghlan, yselivanov priority: normal severity: normal stage: needs patch status: open title: inspect.Signature doesn't support user classes without __init__ or __new__ type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 23:04:01 2014 From: report at bugs.python.org (Martin Vignali) Date: Sun, 19 Jan 2014 22:04:01 +0000 Subject: [issue19990] Add unittests for imghdr module In-Reply-To: <1387146470.57.0.419345603545.issue19990@psf.upfronthosting.co.za> Message-ID: <1390169041.76.0.626077572625.issue19990@psf.upfronthosting.co.za> Martin Vignali added the comment: I made a simple exr file with the lib Exr (it's a half float ZIP16 RGBA file), in order to add real exr file to the unit test. When use with the patch i made here http://bugs.python.org/issue20295 , this sample file return 'exr'. Sorry, i don't know how to create an update version of your patch (i just start to use mercurial), so i just upload the sample. ---------- nosy: +mvignali Added file: http://bugs.python.org/file33555/python.exr _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 23:06:12 2014 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 19 Jan 2014 22:06:12 +0000 Subject: [issue20308] inspect.Signature doesn't support user classes without __init__ or __new__ In-Reply-To: <1390168359.82.0.306015564457.issue20308@psf.upfronthosting.co.za> Message-ID: <1390169172.47.0.198547425817.issue20308@psf.upfronthosting.co.za> Yury Selivanov added the comment: Well, the current code looks for __init__ or __new__. The only ones it can find is the 'object.__init__' which are blacklisted, because they are in C. The question is do (or will) 'object.__new__' or '__init__' have a signature defined with the clinic? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 23:18:39 2014 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 19 Jan 2014 22:18:39 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1390169919.95.0.234634920403.issue17481@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Otherwise we run the risk of introducing unexpected exceptions into introspection code. That's a good catch. I'll make a new patch, keeping the old implementation of getfullargsspec intact, and falling back to it if no signature can be found. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 23:22:52 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Jan 2014 22:22:52 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1390170172.8.0.0178913215284.issue17481@psf.upfronthosting.co.za> Larry Hastings added the comment: Yury: fire away, either here or in a new issue as is best. (Sorry, brain mildly fried, not sure what would be best issue-tracker hygiene.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 23:42:53 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Jan 2014 22:42:53 +0000 Subject: [issue20308] inspect.Signature doesn't support user classes without __init__ or __new__ In-Reply-To: <1390168359.82.0.306015564457.issue20308@psf.upfronthosting.co.za> Message-ID: <1390171373.75.0.753120726654.issue20308@psf.upfronthosting.co.za> Larry Hastings added the comment: __new__ and __init__ methods are very special. They can't have signatures, because the mechanism we use to store the signatures won't work. (We hide them as a special first line of the docstring, and __new__ and __init__ can't have custom docstrings.) In my next patch for #20189, inspect.signature(object) will return a valid signature object. But class C: pass inspect.signature(C) still fails in that branch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 23:48:26 2014 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 19 Jan 2014 22:48:26 +0000 Subject: [issue20308] inspect.Signature doesn't support user classes without __init__ or __new__ In-Reply-To: <1390168359.82.0.306015564457.issue20308@psf.upfronthosting.co.za> Message-ID: <1390171706.26.0.335128153661.issue20308@psf.upfronthosting.co.za> Yury Selivanov added the comment: In this case it would probably be best to just special case classes that don't have __init__ or __new__ defined to return an empty signature without parameters. I can also make a special case for object.__init__ and object.__new__ functions, if someone would want to introspect them directly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 23:56:42 2014 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 19 Jan 2014 22:56:42 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1390172202.76.0.681162095542.issue17481@psf.upfronthosting.co.za> Yury Selivanov added the comment: >> Otherwise we run the risk of introducing unexpected exceptions into introspection code. > That's a good catch. I'll make a new patch, keeping the old implementation of getfullargsspec intact, and falling back to it if no signature can be found. Nick, while I was working on the second patch (writing a new unittest for it specifically), I realized, that it's not that easy to make the old version of "getfullargsspec" to spit out any exception that it doesn't currently do with the proposed 'getargsspec_01.patch'. See, the old "getfullargsspec" does the following: 1. Check if the passed object is a function, with 'inspect.isfunction'. If not - throw a TypeError. That behaviour is duplicated in the patch, so we are safe here. 2. Call on the object's __code__ '_getfullargs', which validates that the passed code object is a valid code object, and simply returns its attributes rearranged a bit. Now, to have any exception in (2), we need: either a broken __code__ object, or something that is an instance of "types.FunctionType" (hence, defined in python) but doesn't have the "__code__" attribute. And that's kind of hard to achieve. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 19 23:57:51 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Jan 2014 22:57:51 +0000 Subject: [issue20308] inspect.Signature doesn't support user classes without __init__ or __new__ In-Reply-To: <1390168359.82.0.306015564457.issue20308@psf.upfronthosting.co.za> Message-ID: <1390172271.38.0.930514520364.issue20308@psf.upfronthosting.co.za> Larry Hastings added the comment: If we need a special case for user classes without __new__ or __init__, then do that. But I wouldn't say we should special case object.__new__ and object.__init__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 00:32:07 2014 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 19 Jan 2014 23:32:07 +0000 Subject: [issue20308] inspect.Signature doesn't support user classes without __init__ or __new__ In-Reply-To: <1390168359.82.0.306015564457.issue20308@psf.upfronthosting.co.za> Message-ID: <1390174327.31.0.677247455002.issue20308@psf.upfronthosting.co.za> Yury Selivanov added the comment: Please take a look at the attached patch (signature_plain_cls_01.patch) Now, the patch addresses two kind of classes: class C: pass and class C(type): pass For metaclasses, signature will return a signature with three positional-only parameters - (name, bases, dct). [let's discuss this] The patch doesn't address 'object' or 'type' objects directly, though, so 'signature(object)' and 'signature(type)' are still a ValueError. ---------- keywords: +patch Added file: http://bugs.python.org/file33556/signature_plain_cls_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 00:36:58 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Jan 2014 23:36:58 +0000 Subject: [issue20308] inspect.Signature doesn't support user classes without __init__ or __new__ In-Reply-To: <1390168359.82.0.306015564457.issue20308@psf.upfronthosting.co.za> Message-ID: <1390174618.67.0.286966058482.issue20308@psf.upfronthosting.co.za> Larry Hastings added the comment: inspect.signature(object) works fine in my (not yet posted) latest #20189 patch. inspect.signature(type) doesn't work, because it's not clear what the signature for type should be. There's the one-argument and three-argument approaches. This is technically true: "(object_or_name, [bases, dict])" However, a) it's painful to look at, b) I can't communicate the idea of an "optional group" in an inspect.Signature object right now (although I guess we're going to hash that out somewhere, which is good). If we can agree on a good signature for inspect.signature(type), I can make it happen. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 00:44:22 2014 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 19 Jan 2014 23:44:22 +0000 Subject: [issue20308] inspect.Signature doesn't support user classes without __init__ or __new__ In-Reply-To: <1390168359.82.0.306015564457.issue20308@psf.upfronthosting.co.za> Message-ID: <1390175062.05.0.856103873372.issue20308@psf.upfronthosting.co.za> Yury Selivanov added the comment: Couple of thoughts: 1. "(object_or_name, [bases, dict])" is a signature for the "type" function, and yes, on that we need to agree how it looks like. Maybe exactly as you proposed, as it is what it is after all. 2. For user-defined metaclasses without __init__ or __new__ (such as "class C(type)"), we can just return, IMO, "(name, bases, dict)", as, although, it is possible to call "C" with only one argument, it's hardly a good practice, and I doubt it very much that someone does such things. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 00:47:22 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Jan 2014 23:47:22 +0000 Subject: [issue20308] inspect.Signature doesn't support user classes without __init__ or __new__ In-Reply-To: <1390168359.82.0.306015564457.issue20308@psf.upfronthosting.co.za> Message-ID: <1390175242.47.0.409553825673.issue20308@psf.upfronthosting.co.za> Larry Hastings added the comment: Special cases aren't special enough to break the rules. If the signature of a metaclass is "(object_or_name, [bases, dict])", then we must not special-case it to pretend that "(object)" works. I agree it's a bad idea to actually *do* that, but there are best-practice principles at stake here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 00:50:20 2014 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 19 Jan 2014 23:50:20 +0000 Subject: [issue20308] inspect.Signature doesn't support user classes without __init__ or __new__ In-Reply-To: <1390168359.82.0.306015564457.issue20308@psf.upfronthosting.co.za> Message-ID: <1390175420.53.0.898496961192.issue20308@psf.upfronthosting.co.za> Yury Selivanov added the comment: When in doubt, import this ;) Agree. So the best course would be: make a patch for plain classes (not metaclasses). Fix signatures for metaclasses without __init__/__new__ when we have groups support for parameters, so that we can have (obj_or_name, [bases, dict]) kind of signatures. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 00:58:00 2014 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 19 Jan 2014 23:58:00 +0000 Subject: [issue20308] inspect.Signature doesn't support user classes without __init__ or __new__ In-Reply-To: <1390168359.82.0.306015564457.issue20308@psf.upfronthosting.co.za> Message-ID: <1390175880.79.0.948462703434.issue20308@psf.upfronthosting.co.za> Yury Selivanov added the comment: Attached is a stripped down patch that special-cases classes without __init__/__new__. Not metaclasses, for that we can start a new issue. ---------- Added file: http://bugs.python.org/file33557/signature_plain_cls_02.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 03:45:50 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 20 Jan 2014 02:45:50 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1390185950.52.0.652843088662.issue17481@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Yury: fire away, either here or in a new issue as is best. (Sorry, brain mildly fried, not sure what would be best issue-tracker hygiene.) Larry, I ended up with a relatively big core dump of my thoughts, so I decided to post it on python-dev. Let's discuss it there, and we can create an issue here once we decide something. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 04:13:40 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Mon, 20 Jan 2014 03:13:40 +0000 Subject: [issue9521] xml.etree.ElementTree skips processing instructions when parsing In-Reply-To: <1281000343.34.0.102578281876.issue9521@psf.upfronthosting.co.za> Message-ID: <1390187620.54.0.0638135824874.issue9521@psf.upfronthosting.co.za> Nikolaus Rath added the comment: No, I really mean XML processing instruction. I agree with you that the XML declaration is a non-issue, because there is no information lost: you know that you're going to write XML, and you manually specify the encoding. Thus it's trivial to add the correct XML declaration if desired. The fact that PIs are not read, however, is a real problem. The XML spec requires that PIs MUST be passed trough (http://www.w3.org/TR/REC-xml/#sec-pi). Furthermore, ElementTree is designed to represent XML data, so writing out an ElementTree as XML and reading it back in must (in my opinionn not result in information loss. But currently it does: >>> import xml.etree.ElementTree as ET >>> import tempfile >>> root = ET.Element('body', {'text': 'some text for the body'}) >>> root.insert(1, ET.ProcessingInstruction('do-something')) >>> tree = ET.ElementTree(root) >>> tmp = tempfile.NamedTemporaryFile() >>> tree.write(tmp.name) >>> tmp.seek(0) 0 >>> tree_copy = ET.parse(tmp.name) >>> ET.dump(tree) >>> ET.dump(tree_copy) I think tree and tree_copy not having the some contents is a bug. Regarding comments: personally I think that throwing away is not a good idea either. But this is allowed by the XML spec (http://www.w3.org/TR/REC-xml/#dt-comment). This should probably go in a separate bug report if someone is interested in it. As for backwards compatibility: yes, this is a concern. The keyword argument would be a solution. On the other hand, I'm not sure that the default should be something that causes dataloss...? lxml sounds like it's doing the right things. Is there some connection between lxml and etree that I'm not aware of, or did you just give it as an example of how a different library behaves? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 05:21:39 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Mon, 20 Jan 2014 04:21:39 +0000 Subject: [issue19871] json module won't parse a float that starts with a decimal point In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za> Message-ID: <1390191699.67.0.985425454931.issue19871@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Attached the patch to address Ezio Melotti's concern. Thanks for the review! ---------- Added file: http://bugs.python.org/file33558/parse_non_valid_json_float_with_unit_test_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 05:43:05 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Mon, 20 Jan 2014 04:43:05 +0000 Subject: [issue12704] Language Reference: Clarify behaviour of yield when generator is not resumed In-Reply-To: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za> Message-ID: <1390192985.01.0.189309797368.issue12704@psf.upfronthosting.co.za> Nikolaus Rath added the comment: (adding the documentation experts from http://docs.python.org/devguide/experts.html to noisy in the hope to push this forward) ---------- nosy: +eric.araujo, ezio.melotti, georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 05:44:54 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Mon, 20 Jan 2014 04:44:54 +0000 Subject: [issue6627] threading.local() does not work with C-created threads In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za> Message-ID: <1390193094.07.0.586493776646.issue6627@psf.upfronthosting.co.za> Nikolaus Rath added the comment: (adding the documentation and ctypes experts from http://docs.python.org/devguide/experts.html to noisy list in the hope to get this moving again.) ---------- nosy: +belopolsky, eric.araujo, ezio.melotti, georg.brandl, meador.inge versions: -Python 2.6, Python 3.1, Python 3.2, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 05:53:49 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Mon, 20 Jan 2014 04:53:49 +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: <1390193629.82.0.187438079671.issue15955@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Nadeem, did you have a chance to look at this again, or do you have any partial patch already? If not, I'd like to try working on a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 06:12:33 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Jan 2014 05:12:33 +0000 Subject: [issue6627] threading.local() does not work with C-created threads In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za> Message-ID: <3f71GS2mSNzRbX@mail.python.org> Roundup Robot added the comment: New changeset f4eade5df217 by Benjamin Peterson in branch '3.3': document that a new Python thread context is created in ctypes callbacks (closes #6627) http://hg.python.org/cpython/rev/f4eade5df217 New changeset 9cd2d7a3f9f2 by Benjamin Peterson in branch '2.7': document that a new Python thread context is created in ctypes callbacks (closes #6627) http://hg.python.org/cpython/rev/9cd2d7a3f9f2 New changeset fd647825475a by Benjamin Peterson in branch 'default': merge 3.3 (#6627) http://hg.python.org/cpython/rev/fd647825475a ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 07:43:38 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 20 Jan 2014 06:43:38 +0000 Subject: [issue20309] Class method descriptors are different between builtin and user classes Message-ID: <1390200218.06.0.45732778516.issue20309@psf.upfronthosting.co.za> New submission from Larry Hastings: I found something curious while experimenting with types tonight. Everybody knows, if you access a descriptor in a class through the normal attribute-getting methods, you actually get the result of calling its '__get__' method. If you want to get your hands on the descriptor itself, you can be sneaky and pull it out through the class's __dict__. I did an experiment tonight, accessing a bunch of methods in a bunch of different ways. The methods I tried were * an instance method, * a class method, and * a static method. I accessed them * as an instance attribute, * as a class attribute, and * through the class __dict__. And for each of the above, I tried * one user method and * one built-in method. That's a total of eighteen methods tried (3x3x2). For each one, I printed out whether or not it was callable. I found the results startling: fifteen were, but three (!) were not. All three that weren't were accessed through the class dict. They were: * Class method, from builtin class ( dict.__dict__['fromkeys'] ) * Static method, from user class * Static method, from builtin class ( str.__dict__['maketrans'] ) I find it strange that the static method descriptors aren't callable. I find it *even stranger* that *one* of the class method descriptors isn't callable, but the other one is. I guess a foolish consistency is the hobgoblin of my small mind, but... shouldn't all eighteen of these objects be callable? Attached is the test harness I wrote. (p.s. I attached you guys as nosy because I thought you might be interested.) ---------- components: Interpreter Core files: curious.py messages: 208524 nosy: arigo, larry, ncoghlan, pitrou priority: low severity: normal stage: needs patch status: open title: Class method descriptors are different between builtin and user classes type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file33559/curious.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 07:44:32 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 20 Jan 2014 06:44:32 +0000 Subject: [issue20309] Class method descriptors are different between builtin and user classes In-Reply-To: <1390200218.06.0.45732778516.issue20309@psf.upfronthosting.co.za> Message-ID: <1390200272.19.0.495781009925.issue20309@psf.upfronthosting.co.za> Larry Hastings added the comment: I should add, I see the same results with current trunk and with my handy Python 3 (currently 3.3.1rc1, huh guess I'm behind). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 07:53:35 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 20 Jan 2014 06:53:35 +0000 Subject: [issue20309] Not all descriptors are callable In-Reply-To: <1390200218.06.0.45732778516.issue20309@psf.upfronthosting.co.za> Message-ID: <1390200815.42.0.369022661159.issue20309@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- title: Class method descriptors are different between builtin and user classes -> Not all descriptors are callable _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 08:19:58 2014 From: report at bugs.python.org (Charles-Axel Dein) Date: Mon, 20 Jan 2014 07:19:58 +0000 Subject: [issue20310] Recommend using pprint for deterministic doctest Message-ID: <1390202398.87.0.516795026978.issue20310@psf.upfronthosting.co.za> New submission from Charles-Axel Dein: I just thought that using pprint.pprint was an elegant solution to the non-deterministic order of repr(dict) in doctest. See for instance http://bugs.python.org/issue3332 Contrary to sorted(foo().items()): - It provides a nice output that is exactly like a dict. - It supports any number of nested dicts. - It can be used in other cases as well to make doctests elegant. ---------- assignee: docs at python components: Documentation files: pprint_doctest.patch keywords: patch messages: 208526 nosy: charlax, docs at python priority: normal severity: normal status: open title: Recommend using pprint for deterministic doctest type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file33560/pprint_doctest.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 08:45:30 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 20 Jan 2014 07:45:30 +0000 Subject: [issue12704] Language Reference: Clarify behaviour of yield when generator is not resumed In-Reply-To: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za> Message-ID: <1390203930.72.0.77077812032.issue12704@psf.upfronthosting.co.za> Georg Brandl added the comment: Hmm, the yield statement is now basically the same as any expression statement -- just like a function call. The only reason it's a separate grammar symbol is that otherwise yield expressions would have to be parenthesized. Can the patch be updated to make this a bit clearer? Otherwise I like the approach of moving the info to the expressions page. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 09:02:36 2014 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 20 Jan 2014 08:02:36 +0000 Subject: [issue9521] xml.etree.ElementTree skips processing instructions when parsing In-Reply-To: <1281000343.34.0.102578281876.issue9521@psf.upfronthosting.co.za> Message-ID: <1390204956.09.0.451964216453.issue9521@psf.upfronthosting.co.za> Stefan Behnel added the comment: > As for backwards compatibility: yes, this is a concern. The keyword argument would be a solution. On the other hand, I'm not sure that the default should be something that causes dataloss...? It's a matter of use cases. How often do people care? My experience tells me that it's much more common to parse XML in and extract information from it, than to do round trips. And when extracting information, both comments and processing instructions usually get in the way. So I would say that this default behaviour isn't wrong. In fact, I'd even say that both lxml and ET behave as expected (or at least as intended) in their own ways. Also, I can't really remember spotting a processing instruction anywhere *inside* of a root element in real world XML. For those living next to it, ET currently lacks support in its tree model. > lxml sounds like it's doing the right things. Is there some connection between lxml and etree that I'm not aware of, or did you just give it as an example of how a different library behaves? Both implement (essentially) the same API, so I consider compatibility and look-alikes important. The general idea is that lxml extends what's there, but otherwise tries to stay compatible as good as it can. BTW, lxml also allows parser target objects to have "pi(self, target, data)" and "comment(text)" methods, through which it can pass comments and PIs through to user provided tree builders. I think ET lacks those, too. Changing target version from 3.3/3.4 to 3.5 as this is a new feature that is unlikely to make it into a currently released (or close to release) Python version. Also changing the ticket type to enhancement as the current behaviour isn't "wrong". It's rather a matter of supporting an additional use case. ---------- type: behavior -> enhancement versions: +Python 3.5 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 09:47:53 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Mon, 20 Jan 2014 08:47:53 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1390207673.47.0.68688092526.issue20185@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the patch for typeobject. I didn't convert the new method. It's so complicated. It counts whether how many arguments or keywords you pass. It asserts the args before parsing the args. I don't think clinic supports this. This is the code: assert(args != NULL && PyTuple_Check(args)); assert(kwds == NULL || PyDict_Check(kwds)); /* Special case: type(x) should return x->ob_type */ { const Py_ssize_t nargs = PyTuple_GET_SIZE(args); const Py_ssize_t nkwds = kwds == NULL ? 0 : PyDict_Size(kwds); if (PyType_CheckExact(metatype) && nargs == 1 && nkwds == 0) { PyObject *x = PyTuple_GET_ITEM(args, 0); Py_INCREF(Py_TYPE(x)); return (PyObject *) Py_TYPE(x); } /* SF bug 475327 -- if that didn't trigger, we need 3 arguments. but PyArg_ParseTupleAndKeywords below may give a msg saying type() needs exactly 3. */ if (nargs + nkwds != 3) { PyErr_SetString(PyExc_TypeError, "type() takes 1 or 3 arguments"); return NULL; } } /* Check arguments: (name, bases, dict) */ if (!PyArg_ParseTupleAndKeywords(args, kwds, "UO!O!:type", kwlist, &name, &PyTuple_Type, &bases, &PyDict_Type, &orig_dict)) return NULL; ---------- Added file: http://bugs.python.org/file33561/clinic_typeobject.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 10:11:28 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Jan 2014 09:11:28 +0000 Subject: [issue20165] unittest TestResult wasSuccessful returns True when there are unexpected successes In-Reply-To: <1389122721.74.0.155844601606.issue20165@psf.upfronthosting.co.za> Message-ID: <3f76Z73lWdz7LjX@mail.python.org> Roundup Robot added the comment: New changeset 1e75ab9fd760 by Gregory P. Smith in branch 'default': Fixes Issue #20165: The unittest module no longer considers tests marked with http://hg.python.org/cpython/rev/1e75ab9fd760 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 10:13:00 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 20 Jan 2014 09:13:00 +0000 Subject: [issue20165] unittest TestResult wasSuccessful returns True when there are unexpected successes In-Reply-To: <1389122721.74.0.155844601606.issue20165@psf.upfronthosting.co.za> Message-ID: <1390209180.13.0.20687914466.issue20165@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 10:13:14 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Mon, 20 Jan 2014 09:13:14 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1390209194.34.0.493469088338.issue20185@psf.upfronthosting.co.za> Changes by Vajrasky Kok : Removed file: http://bugs.python.org/file33561/clinic_typeobject.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 10:13:24 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Mon, 20 Jan 2014 09:13:24 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1390209204.59.0.959979063789.issue20185@psf.upfronthosting.co.za> Changes by Vajrasky Kok : Added file: http://bugs.python.org/file33562/clinic_typeobject.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 10:41:54 2014 From: report at bugs.python.org (Armin Rigo) Date: Mon, 20 Jan 2014 09:41:54 +0000 Subject: [issue20309] Not all descriptors are callable In-Reply-To: <1390200218.06.0.45732778516.issue20309@psf.upfronthosting.co.za> Message-ID: <1390210914.97.0.710585599107.issue20309@psf.upfronthosting.co.za> Armin Rigo added the comment: Instances of 'staticmethod' or 'classmethod' are not callable. I'm unsure why not, but it's good enough, as you need to go through various unexpected hops in order to try to call one. 'dict.fromkeys' is not a classmethod, as seen by "dict.__dict__['fromkeys']". It's an internal object usually never seen by Python code. I believe this is only because implementing a regular classmethod in C would be rather messy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 11:33:28 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 20 Jan 2014 10:33:28 +0000 Subject: [issue20311] epoll.poll(timeout) must round the timeout to the upper bound Message-ID: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> New submission from STINNER Victor: Hi, while comparing performances of Tulip and Trollius projects (asyncio module), I found a bug. The event loop is called too many times when a callback is scheduled with a timeout and the epoll selector is used, especially for timeout close to one millisecond. In my opinion, it's a bug in epoll.poll(): it should wait *at least* timeout seconds if no event is received, not shorter. Pseudo-code of Tulip: --- timeout = scheduled[0].when - time.monotonic() events = selector.select(timeout) process_events(events) while scheduled: if scheduled[0].when > time.monotonic(): break ... --- The problem is that "scheduled[0].when > time.monotonic()" test fails because epoll.poll() returns in less than timeout seconds. The difference between the timeout and elapsed time is very small, less than 1 millisecond. Attached patch fixes this issue by rounding the timeout to the upper bound. The rounding is different than datetime.timedelta constructor for example, because the usecase is different. epoll.poll(0.0001) calls epoll_wait() with a timemout of 1 millisecond (1e-4 rounded to 1e-3). epoll.poll(0.0) still calls epoll_wait() with a timeout of 0 millisecond. I don't think that it's possible to write a reliable unit test for that on our slow buildbots. ---------- files: epoll_timeout.patch keywords: patch messages: 208532 nosy: gvanrossum, haypo, neologix, pitrou, serhiy.storchaka priority: normal severity: normal status: open title: epoll.poll(timeout) must round the timeout to the upper bound versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33563/epoll_timeout.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 11:54:17 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 20 Jan 2014 10:54:17 +0000 Subject: [issue20311] epoll.poll(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <1390215257.8.0.387689788138.issue20311@psf.upfronthosting.co.za> STINNER Victor added the comment: Bug report in Tulip project, the bug affects also the new asyncio module of Python 3.4: http://code.google.com/p/tulip/issues/detail?id=106 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 11:58:56 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 20 Jan 2014 10:58:56 +0000 Subject: [issue20311] epoll.poll(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <1390215536.0.0.413281534245.issue20311@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Looks good to me on the principle. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 13:10:19 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 20 Jan 2014 12:10:19 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1390219819.23.0.810903444983.issue17481@psf.upfronthosting.co.za> Nick Coghlan added the comment: Ah, I had indeed missed the fact that getfullargspec() was still calling isfunction(). In that case, is the patch currently actually buying us anything much beyond handling __signature__ attributes? Most of the new types that inspect.signature() supports will still fail that preliminary check, so code will need to use the new API explicitly in order to benefit from it. By contrast, if we remove the check, then there's a wider range of exceptions that may be thrown, but also a much wider variety of inputs supported. Instead of keeping the check, we could just unconditionally convert exceptions from the signature call to a TypeError in order to maintain compatibility with the old external behaviour. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 13:32:13 2014 From: report at bugs.python.org (Michael Foord) Date: Mon, 20 Jan 2014 12:32:13 +0000 Subject: [issue20222] unittest.mock-examples doc uses builtin file which is removed in Python 3 In-Reply-To: <1389464749.27.0.908623013872.issue20222@psf.upfronthosting.co.za> Message-ID: <1390221133.64.0.904071353814.issue20222@psf.upfronthosting.co.za> Michael Foord added the comment: Thanks for picking this up. /file/open/ should be fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 13:32:24 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 20 Jan 2014 12:32:24 +0000 Subject: [issue20309] Class method descriptors are different between builtin and user classes In-Reply-To: <1390200272.19.0.495781009925.issue20309@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: I believe it's just a matter of pattern of use - applying staticmethod outside a class (or retrieving the descriptor directly from the dict, bypassing the descriptor protocol), so nobody every noticed. Ditto for the C wrapper vs the Python wrapper for a classmethod - it's really rare to access those without going through the descriptor machinery, so it's likely just an accident of implementation that one of them isn't callable. I don't see any specific reason for them to be non-callable - I suspect it's just a case of never adding the code to make it happen. ---------- title: Not all descriptors are callable -> Class method descriptors are different between builtin and user classes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 13:34:35 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 20 Jan 2014 12:34:35 +0000 Subject: [issue20309] Not all method descriptors are callable In-Reply-To: <1390200218.06.0.45732778516.issue20309@psf.upfronthosting.co.za> Message-ID: <1390221275.9.0.888441353837.issue20309@psf.upfronthosting.co.za> Nick Coghlan added the comment: Oh, so that's how that happens :) (the title reverted because I replied via email from a part of the thread before Larry changed the issue name) ---------- title: Class method descriptors are different between builtin and user classes -> Not all method descriptors are callable _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 14:11:35 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 20 Jan 2014 13:11:35 +0000 Subject: [issue20311] epoll.poll(timeout) must round the timeout to the upper bound In-Reply-To: <1390215536.0.0.413281534245.issue20311@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: AFAICT, this also affects poll(). Although it's supposed to be passed an integer, passing a float will result in a truncation towards 0: """ $ strace -e poll python -c "import select; p = select.poll(); p.poll(0.9)" poll(0x23321b0, 0, 0) = 0 (Timeout) """ See also this line in PollSelector: """ def select(self, timeout=None): timeout = None if timeout is None else max(int(1000 * timeout), 0) """ This will round timeout=1e-4 to 0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 14:42:01 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 20 Jan 2014 13:42:01 +0000 Subject: [issue20307] Android's failure to expose SYS_* system call constants causes _posixsubprocess cross-compilation to fail In-Reply-To: <1390156070.61.0.536992358716.issue20307@psf.upfronthosting.co.za> Message-ID: <1390225321.41.0.499941191894.issue20307@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 14:42:33 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 20 Jan 2014 13:42:33 +0000 Subject: [issue20305] Android's incomplete locale.h implementation prevents cross-compilation In-Reply-To: <1390155202.76.0.360148898057.issue20305@psf.upfronthosting.co.za> Message-ID: <1390225353.43.0.716686356999.issue20305@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +haypo, skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 15:08:26 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 20 Jan 2014 14:08:26 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <1390226906.03.0.302972172255.issue20311@psf.upfronthosting.co.za> STINNER Victor added the comment: select.select(), selectors.PollSelector.select(), select.epoll.poll(), select.kqueue.control() have the bug. OS multiplexers: - select: microsecond resolution (10^-6), timeout converted by _PyTime_ObjectToTimeval() which converts 1e-7 to zero => BUG! - poll: millisecond resolution (10^-3) but expects int type, select is ok, selectors uses int(1000 * timeout) which converts 1e-4 to zero => BUG! - epoll: millisecond resolution (10^-3), select uses (int)(dtimeout * 1000.0) which converts 1e-4 to zero => BUG! - devpoll: millisecond resolution (10^-3) but expects int type, select is ok, selectors doesn't support it yet => ok - kqueue: nanosecond resolution (10^-9), timeout converted by _PyTime_ObjectToTimespec() which converts 1e-10 to zero => BUG! _PyTime_ObjectToTimeval() is used in various places: - datetime.datetime.fromtimestamp(), datetime.datetime.utcfromtimestamp() - select.select(), _PyTime_ObjectToTimespec() is used in various places: - posix.utime() - signal.sigtimedwait() - select.kqueue.control() - time.clock_settime() A new parameter should be added to _PyTime_ObjectToTimeval() and _PyTime_ObjectToTimespec() to choose the rounding method. -- I saw the bug with poll and epoll because these functions have the worst resolution (millisecond). Attached patch fixes poll and epoll, and add a generic test on all selectors: select_round_timeout.patch. According to my test, select.select() has an effective resolution of 0.1 ms (10^4) on my Fedora 19 (Linux kernel 3.12), so I don't think that the select rounding issue is important. Tell me if you consider that _PyTime_ObjectToTime*() (select, kqueue) should be fixed. If yes, I will open a separated issue (because the implementation is different and it may impact other unrelated functions). ---------- title: epoll.poll(timeout) must round the timeout to the upper bound -> epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound Added file: http://bugs.python.org/file33564/select_round_timeout.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 15:12:14 2014 From: report at bugs.python.org (Stefan Krah) Date: Mon, 20 Jan 2014 14:12:14 +0000 Subject: [issue20305] Android's incomplete locale.h implementation prevents cross-compilation In-Reply-To: <1390155202.76.0.360148898057.issue20305@psf.upfronthosting.co.za> Message-ID: <1390227134.52.0.847090811977.issue20305@psf.upfronthosting.co.za> Stefan Krah added the comment: I agree with Marc-Andre. Also, we should have an Android buildbot. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 15:22:10 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 20 Jan 2014 14:22:10 +0000 Subject: [issue20305] Android's incomplete locale.h implementation prevents cross-compilation In-Reply-To: <1390155202.76.0.360148898057.issue20305@psf.upfronthosting.co.za> Message-ID: <1390227730.8.0.0190935016866.issue20305@psf.upfronthosting.co.za> STINNER Victor added the comment: Is there the only patch required to compile Python 3.4 on Android? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 15:36:47 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Jan 2014 14:36:47 +0000 Subject: [issue19036] setlocale fails due to locale.h being wrapped up in LANGINFO check. In-Reply-To: <1379347357.79.0.813786173843.issue19036@psf.upfronthosting.co.za> Message-ID: <3f7FnV1Nk3z7LjM@mail.python.org> Roundup Robot added the comment: New changeset f82b6ec1ae6e by Stefan Krah in branch '3.3': Issue #19036: Including locale.h should not depend on HAVE_LANGINFO_H. http://hg.python.org/cpython/rev/f82b6ec1ae6e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 15:37:56 2014 From: report at bugs.python.org (Stefan Krah) Date: Mon, 20 Jan 2014 14:37:56 +0000 Subject: [issue19036] setlocale fails due to locale.h being wrapped up in LANGINFO check. In-Reply-To: <1379347357.79.0.813786173843.issue19036@psf.upfronthosting.co.za> Message-ID: <1390228676.56.0.91475582166.issue19036@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- resolution: remind -> fixed stage: -> committed/rejected status: open -> closed type: -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 16:35:54 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 20 Jan 2014 15:35:54 +0000 Subject: [issue20301] Correct docs for default access argument for DeleteKeyEx In-Reply-To: <1390118763.24.0.151649669148.issue20301@psf.upfronthosting.co.za> Message-ID: <1390232154.36.0.962248561338.issue20301@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 16:47:29 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 20 Jan 2014 15:47:29 +0000 Subject: [issue20309] Not all method descriptors are callable In-Reply-To: <1390200218.06.0.45732778516.issue20309@psf.upfronthosting.co.za> Message-ID: <1390232849.81.0.991798958787.issue20309@psf.upfronthosting.co.za> R. David Murray added the comment: See also issue 19072 for previous report of the classmethod problem. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 16:51:41 2014 From: report at bugs.python.org (Marco Buttu) Date: Mon, 20 Jan 2014 15:51:41 +0000 Subject: [issue20312] A missing link to Python-3.4.0b2.tar.bz2 in the download page. Message-ID: <1390233101.81.0.508449799289.issue20312@psf.upfronthosting.co.za> New submission from Marco Buttu: At the page: http://www.python.org/getit/releases/3.4.0/ the link: http://www.python.org/ftp/python/3.4.0/Python-3.4.0b2.tar.bz2 does not work. ---------- assignee: docs at python components: Documentation messages: 208545 nosy: docs at python, marco.buttu priority: normal severity: normal status: open title: A missing link to Python-3.4.0b2.tar.bz2 in the download page. versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 16:52:53 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 20 Jan 2014 15:52:53 +0000 Subject: [issue20310] Recommend using pprint for deterministic doctest In-Reply-To: <1390202398.87.0.516795026978.issue20310@psf.upfronthosting.co.za> Message-ID: <1390233173.03.0.439984315498.issue20310@psf.upfronthosting.co.za> R. David Murray added the comment: I think suggesting pprint is a great idea. It also has another advantage in 3.4: in many cases it should produce output that is line wrapped such that NORMALIZE_WHITESPACE isn't needed. However, I'd make it as an *additional* suggestion. Pedagogically, sort makes it clear that you *must* resolve the problem of the ordering of dict items...then you can suggest pprint as something that also sorts, and has some additional nice properties as well. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 17:02:06 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 20 Jan 2014 16:02:06 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1390233726.64.0.230633441081.issue17481@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Instead of keeping the check, we could just unconditionally convert exceptions from the signature call to a TypeError in order to maintain compatibility with the old external behaviour. Agreed. See the new patch (getargsspec_02.patch) Unfortunately, we have to keep the old 'ismethod' check in place for backwards compatibility purposes. Larry, The attached patch contains one failing unit-test: 'inspect.signature' returns 'None' for '_testapi.docstring_no_signature'. It should instead raise a ValueError. ---------- Added file: http://bugs.python.org/file33565/getargsspec_02.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 17:56:33 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 20 Jan 2014 16:56:33 +0000 Subject: [issue20313] inspect.signature should raise ValueError for builtins with no signature info Message-ID: <1390236993.79.0.241444273763.issue20313@psf.upfronthosting.co.za> New submission from Yury Selivanov: 'inspect.signature' currently returns 'None' for builtins with no signature information. However, the protocol is that it raises a "ValueError(callable is not supported by signature)" if object is callable, but a signature can not be provided. Attached patch fixes this, as well as updates the relevant section in the inspect.signature documentation. ---------- components: Library (Lib) files: sig_builtin_01.patch keywords: patch messages: 208548 nosy: brett.cannon, larry, ncoghlan, yselivanov priority: normal severity: normal status: open title: inspect.signature should raise ValueError for builtins with no signature info versions: Python 3.4 Added file: http://bugs.python.org/file33566/sig_builtin_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 17:57:15 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 20 Jan 2014 16:57:15 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1390237035.5.0.00620125394543.issue17481@psf.upfronthosting.co.za> Yury Selivanov added the comment: Larry, I created a separate issue for that: http://bugs.python.org/issue20313 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 17:59:59 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 20 Jan 2014 16:59:59 +0000 Subject: [issue20313] inspect.signature should raise ValueError for builtins with no signature info In-Reply-To: <1390236993.79.0.241444273763.issue20313@psf.upfronthosting.co.za> Message-ID: <1390237199.52.0.77859596661.issue20313@psf.upfronthosting.co.za> Zachary Ware added the comment: This is already a part of issue20189 (except the doc fix). ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 18:02:33 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 20 Jan 2014 17:02:33 +0000 Subject: [issue20313] inspect.signature should raise ValueError for builtins with no signature info In-Reply-To: <1390236993.79.0.241444273763.issue20313@psf.upfronthosting.co.za> Message-ID: <1390237353.23.0.315948209754.issue20313@psf.upfronthosting.co.za> Yury Selivanov added the comment: I see. Could you please incorporate the doc change and unittests into the patch for #20189? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 18:02:49 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 20 Jan 2014 17:02:49 +0000 Subject: [issue20075] help(open) eats first line In-Reply-To: <1388090120.87.0.478863756961.issue20075@psf.upfronthosting.co.za> Message-ID: <1390237369.26.0.308950401281.issue20075@psf.upfronthosting.co.za> Zachary Ware added the comment: Gennadiy, sorry this stalled out like it did. The patched function will be moving as part of issue20189. Larry, if you want to incorporate this patch into that patch, please do so; otherwise I'll get this one updated and committed as soon after you commit that one as I can. Gennadiy, if you beat me to updating this patch after Larry commits #20189, please do so. (Setting priority as 'critical' since it would be quite embarrassing to release 3.4.0 with broken "help(open)".) ---------- dependencies: +inspect.Signature doesn't recognize all builtin types priority: normal -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 18:10:54 2014 From: report at bugs.python.org (Gerrit Holl) Date: Mon, 20 Jan 2014 17:10:54 +0000 Subject: [issue20314] Potentially confusing formulation in 6.1.4. Template strings Message-ID: <1390237853.97.0.751678212058.issue20314@psf.upfronthosting.co.za> New submission from Gerrit Holl: The standard library documentation ?6.1. string ? Common string operations? describes string formatting through the `.format` method and the corresponding mini-language, and the `Template` class. In the part describing the `Template` class (6.1.4) is the text: > Instead of the normal %-based substitutions, Templates support $-based substitutions, using the following rules: This is potentially confusing. The documentation in this section has not made any mention of %-based substitutions. Rather, a novel reader may, at this point, think that {}-based substitution is normal. I would suggest to resolve this issue by simply not mentioning %-based substitutions, replacing the sentence above by: > Templates support $-based substitutions, using the following rules: ---------- assignee: docs at python components: Documentation messages: 208553 nosy: Gerrit.Holl, docs at python priority: normal severity: normal status: open title: Potentially confusing formulation in 6.1.4. Template strings type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 18:18:18 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 20 Jan 2014 17:18:18 +0000 Subject: [issue20314] Potentially confusing formulation in 6.1.4. Template strings In-Reply-To: <1390237853.97.0.751678212058.issue20314@psf.upfronthosting.co.za> Message-ID: <1390238298.77.0.20778699417.issue20314@psf.upfronthosting.co.za> Georg Brandl added the comment: +1. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 18:19:53 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 20 Jan 2014 17:19:53 +0000 Subject: [issue20312] A missing link to Python-3.4.0b2.tar.bz2 in the download page. In-Reply-To: <1390233101.81.0.508449799289.issue20312@psf.upfronthosting.co.za> Message-ID: <1390238393.85.0.0891202458194.issue20312@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- assignee: docs at python -> larry nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 18:22:35 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 20 Jan 2014 17:22:35 +0000 Subject: [issue20314] Potentially confusing formulation in 6.1.4. Template strings In-Reply-To: <1390237853.97.0.751678212058.issue20314@psf.upfronthosting.co.za> Message-ID: <20140120121548.0927bb96@anarchist.wooz.org> Barry A. Warsaw added the comment: On Jan 20, 2014, at 05:10 PM, Gerrit Holl wrote: >This is potentially confusing. The documentation in this section has not >made any mention of %-based substitutions. Rather, a novel reader may, at >this point, think that {}-based substitution is normal. I would suggest to >resolve this issue by simply not mentioning %-based substitutions, replacing >the sentence above by: > >> Templates support $-based substitutions, using the following rules: +1 PEP 292 templates predate .format(). ---------- nosy: +barry title: Potentially confusing formulation in 6.1.4. Template strings -> Potentially confusing formulation in 6.1.4. Template strings _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 18:22:35 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Jan 2014 17:22:35 +0000 Subject: [issue20171] Derby #2: Convert 115 sites to Argument Clinic in Modules/_cursesmodule.c In-Reply-To: <1389138236.79.0.916600121015.issue20171@psf.upfronthosting.co.za> Message-ID: <1390238555.02.0.0379903860655.issue20171@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is half-baked (just for demonstration) patch for the _curses and _curses_panel modules. Known issues: * The chgat, getstr, and instr methods have signatures which can't be processed by current Argument Clinic (issue20303). * Signatures of the noutrefresh and refresh methods depends on compile-time options. * Many other functions are defined optionally. But the #ifdef trick doesn't work with side file destination. * A lot of functions are generated by preprocessor. We can't use Argument Clinic for them (if not increase the volume of code too much). I think preprocessor should be used to generate docstrings with signature (done in the _curses_panel module). * Functions in these modules have not docstrings at all. I try to add docstrings (simplified descriptions from the documentation file), but may be we should do this in separate issue. I have temporary added the window class to the _curses module and the panel classes to the _curses_panel modules. Now you can examine docstrings of _curses.window and _curses_panel.panel with pydoc. ---------- keywords: +patch Added file: http://bugs.python.org/file33567/curses_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 18:34:44 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 20 Jan 2014 17:34:44 +0000 Subject: [issue20314] Potentially confusing formulation in 6.1.4. Template strings In-Reply-To: <1390237853.97.0.751678212058.issue20314@psf.upfronthosting.co.za> Message-ID: <1390239284.35.0.828903006004.issue20314@psf.upfronthosting.co.za> Zachary Ware added the comment: I would suggest moving the section "4.7.2. printf-style String Formatting" from stdtypes to string, alongside the other two formatting specifications, or otherwise moving %-formatting and {}-formatting into the same page that is not stdtypes. 4.7.2 is a pretty long section, and it seems odd to me that it is still in that page instead of with the other string formatting specs, though it is the only place that would have made sense in a pre-{}-and-$-formatting world. On the other hand, Gerrit's proposed solution is a *lot* simpler :) ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 18:35:57 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 20 Jan 2014 17:35:57 +0000 Subject: [issue20314] Potentially confusing formulation in 6.1.4. Template strings In-Reply-To: <1390237853.97.0.751678212058.issue20314@psf.upfronthosting.co.za> Message-ID: <1390239357.76.0.725427371898.issue20314@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 18:43:54 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 20 Jan 2014 17:43:54 +0000 Subject: [issue20314] Potentially confusing formulation in 6.1.4. Template strings In-Reply-To: <1390237853.97.0.751678212058.issue20314@psf.upfronthosting.co.za> Message-ID: <1390239834.53.0.893535568313.issue20314@psf.upfronthosting.co.za> Georg Brandl added the comment: > I would suggest moving the section "4.7.2. printf-style String > Formatting" from stdtypes to string That's something I wanted to do for a long time. Problem is that non-Intersphinx external links will break (and I guess quite a few people have a bookmark on that section)... so it might be good to keep 4.7.2 with a pointer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 20:01:13 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Jan 2014 19:01:13 +0000 Subject: [issue20315] Remove old compatibility code Message-ID: <1390244473.81.0.0418963805033.issue20315@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch removes the code which supports compatibility with old Python 2.x versions. As far as these files are never used with Python 2.x (and the compatibility was broken by other differences between 2.x and 3.x), this code can be removed from 3.x. ---------- files: py2_compat.patch keywords: patch messages: 208559 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Remove old compatibility code versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33568/py2_compat.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 20:05:22 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 20 Jan 2014 19:05:22 +0000 Subject: [issue20315] Remove old compatibility code In-Reply-To: <1390244473.81.0.0418963805033.issue20315@psf.upfronthosting.co.za> Message-ID: <1390244722.02.0.981267898249.issue20315@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Seems good to me. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 20:05:43 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 20 Jan 2014 19:05:43 +0000 Subject: [issue19966] Wrong mtimes of files in 3.3.3 tarballs In-Reply-To: <1386869822.97.0.610221510269.issue19966@psf.upfronthosting.co.za> Message-ID: <1390244743.23.0.553840585297.issue19966@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 20:08:09 2014 From: report at bugs.python.org (Shiz) Date: Mon, 20 Jan 2014 19:08:09 +0000 Subject: [issue20305] Android's incomplete locale.h implementation prevents cross-compilation In-Reply-To: <1390155202.76.0.360148898057.issue20305@psf.upfronthosting.co.za> Message-ID: <1390244889.25.0.657707851949.issue20305@psf.upfronthosting.co.za> Shiz added the comment: I managed to cross-compile Python 3.3.3 for arm-linux-androideabi (using the Android NDK r9c) with the patches in this issue, issue 20306 and issue 20307. It did require a small additional patch which addressed the fact that the host system can't run the generated parser generator, which I'll make an issue for as soon as I refactored the patch. The patch allows the user to specify a host parser generator that points to a compiled version of pgen that is runnable on the host through the HOSTPGEN environment variable in ./configure. Compiling the tip proved somewhat harder as the cross-compilation requires a host Python of the same version, which I didn't have. I formatted a patch which allows the user to supply a special host python path using the HOSTPYTHON environment variable to ./configure. I'll make an issue for that soon, and will bundle it with the HOSTPGEN patch if it's seen as a sufficient approach. As far as maintaining an Android port for CPython goes; I may be interested in this as I'd need to regularly use it anyway. Can anyone tell me what the possibilities are here? Since in the meanwhile the tip was updated to unconditionally include locale.h in Python/fileutils.c according to issue 19036, here's an updated patch for this issue that applies cleanly against the tip. ---------- Added file: http://bugs.python.org/file33569/Python-3.4-d51d6f1f9db8-workaround-android-locale-issues.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 20:13:21 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 20 Jan 2014 19:13:21 +0000 Subject: [issue20316] Byte-compiled files should be absent in tarballs Message-ID: <1390245201.82.0.892939520121.issue20316@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis: Tarballs of 3.3.2 (and all previous versions tested by me) do not contain any *.py[co] files. Tarballs of 3.3.3 contain 1 .pyc file, which is even generated for wrong Python version: $ find -name "*.py[co]" ./Tools/hg/hgtouch.pyc $ file Tools/hg/hgtouch.pyc Tools/hg/hgtouch.pyc: python 2.7 byte-compiled Please ensure that this problem will not occur with future tarballs. ---------- messages: 208562 nosy: Arfrever, georg.brandl priority: normal severity: normal status: open title: Byte-compiled files should be absent in tarballs versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 20:14:27 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 20 Jan 2014 19:14:27 +0000 Subject: [issue20316] Byte-compiled files should be absent in tarballs In-Reply-To: <1390245201.82.0.892939520121.issue20316@psf.upfronthosting.co.za> Message-ID: <1390245267.56.0.154885330905.issue20316@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- nosy: +larry priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 20:17:43 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 20 Jan 2014 19:17:43 +0000 Subject: [issue20309] Not all method descriptors are callable In-Reply-To: <1390200218.06.0.45732778516.issue20309@psf.upfronthosting.co.za> Message-ID: <1390245463.42.0.640046295264.issue20309@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 20:23:25 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 20 Jan 2014 19:23:25 +0000 Subject: [issue20316] Byte-compiled files should be absent in tarballs In-Reply-To: <1390245201.82.0.892939520121.issue20316@psf.upfronthosting.co.za> Message-ID: <1390245805.02.0.20094048786.issue20316@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: Potential fix: --- Makefile.pre.in +++ Makefile.pre.in @@ -1487,4 +1487,4 @@ # Touch generated files touch: - hg --config extensions.touch=Tools/hg/hgtouch.py touch -v + PYTHONDONTWRITEBYTECODE=1 hg --config extensions.touch=Tools/hg/hgtouch.py touch -v ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 20:27:55 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 20 Jan 2014 19:27:55 +0000 Subject: [issue20316] Byte-compiled files should be absent in tarballs In-Reply-To: <1390245201.82.0.892939520121.issue20316@psf.upfronthosting.co.za> Message-ID: <1390246075.23.0.695407114275.issue20316@psf.upfronthosting.co.za> Larry Hastings added the comment: Your fix won't work, because release managers call hgtouch from a different spot, from a private tool called "release.py". You'll notice that all the 3.4 releases have that hgtouch.pyc file--up until 3.4b2. I already found that bug. I added "Tools/hg/hgtouch.pyc" to the tuple of "files we don't want in tarballs" in export() in release.py. Didn't push it because I was doing other hacking and it wasn't ready, but I could push just that change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 20:33:42 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 20 Jan 2014 19:33:42 +0000 Subject: [issue20316] Byte-compiled files should be absent in tarballs In-Reply-To: <1390245201.82.0.892939520121.issue20316@psf.upfronthosting.co.za> Message-ID: <1390246422.19.0.924496680734.issue20316@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: When Mercurial is ported to Python 3 somewhen in the future, then e.g. Tools/hg/__pycache__/hgtouch.cpython-34.pyc could be generated, so PYTHONDONTWRITEBYTECODE=1 might still be useful in release.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 20:35:16 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 20 Jan 2014 19:35:16 +0000 Subject: [issue20316] Byte-compiled files should be absent in tarballs In-Reply-To: <1390245201.82.0.892939520121.issue20316@psf.upfronthosting.co.za> Message-ID: <1390246516.35.0.0779885996407.issue20316@psf.upfronthosting.co.za> Larry Hastings added the comment: The construction of release.py would make it easy to just always pass it in when running Python (and hg, and any program). Maybe that's a better choice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 20:35:40 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Jan 2014 19:35:40 +0000 Subject: [issue20315] Remove old compatibility code In-Reply-To: <1390244473.81.0.0418963805033.issue20315@psf.upfronthosting.co.za> Message-ID: <3f7NQM6R3Gz7LkV@mail.python.org> Roundup Robot added the comment: New changeset 5f754f1e3194 by Serhiy Storchaka in branch '3.3': Issue #20315: Removed support for backward compatibility with early 2.x versions. http://hg.python.org/cpython/rev/5f754f1e3194 New changeset ede054eb3dc1 by Serhiy Storchaka in branch 'default': Issue #20315: Removed support for backward compatibility with early 2.x versions. http://hg.python.org/cpython/rev/ede054eb3dc1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 20:36:53 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Jan 2014 19:36:53 +0000 Subject: [issue20315] Remove old compatibility code In-Reply-To: <1390244473.81.0.0418963805033.issue20315@psf.upfronthosting.co.za> Message-ID: <1390246613.07.0.00485881546838.issue20315@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks for your review Benjamin. ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 20:40:13 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Jan 2014 19:40:13 +0000 Subject: [issue20262] Convert some debugging prints in zipfile to warnings In-Reply-To: <1389732995.51.0.822070396354.issue20262@psf.upfronthosting.co.za> Message-ID: <1390246813.74.0.635463368791.issue20262@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Benjamin just have approved it for 2.7. ---------- assignee: -> serhiy.storchaka versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 20:40:52 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 20 Jan 2014 19:40:52 +0000 Subject: [issue19966] Wrong mtimes of Include/Python-ast.h and Python/Python-ast.c in tarballs In-Reply-To: <1386869822.97.0.610221510269.issue19966@psf.upfronthosting.co.za> Message-ID: <1390246852.28.0.185213487311.issue19966@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: Apparently at least 3.4.0b2 tarballs are also affected. ---------- nosy: +larry title: Wrong mtimes of files in 3.3.3 tarballs -> Wrong mtimes of Include/Python-ast.h and Python/Python-ast.c in tarballs versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 20:47:51 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 20 Jan 2014 19:47:51 +0000 Subject: [issue20267] TemporaryDirectory does not resolve path when created using a relative path In-Reply-To: <1389761308.4.0.00958902784577.issue20267@psf.upfronthosting.co.za> Message-ID: <1390247271.59.0.651729858782.issue20267@psf.upfronthosting.co.za> Yury Selivanov added the comment: This looks like a bug to me (or we should complain if a relative 'dir' was passed). I'm attaching a patch that fixes this, although I'm not sure if the unittest I wrote will work on windows. Moreover, 'mkstemp' and 'mktemp' have the same bug (separate issue for them?) ---------- keywords: +patch nosy: +yselivanov Added file: http://bugs.python.org/file33570/tempfile_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 20:48:23 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 20 Jan 2014 19:48:23 +0000 Subject: [issue20267] TemporaryDirectory does not resolve path when created using a relative path In-Reply-To: <1389761308.4.0.00958902784577.issue20267@psf.upfronthosting.co.za> Message-ID: <1390247303.84.0.674652208952.issue20267@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +georg.brandl, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 20:50:46 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 20 Jan 2014 19:50:46 +0000 Subject: [issue20316] Byte-compiled files should be absent in tarballs In-Reply-To: <1390245201.82.0.892939520121.issue20316@psf.upfronthosting.co.za> Message-ID: <1390247446.33.0.606204982458.issue20316@psf.upfronthosting.co.za> Benjamin Peterson added the comment: http://hg.python.org/release/rev/9272f4fd7689 ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 21:06:35 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 20 Jan 2014 20:06:35 +0000 Subject: [issue20316] Byte-compiled files should be absent in tarballs In-Reply-To: <1390245201.82.0.892939520121.issue20316@psf.upfronthosting.co.za> Message-ID: <1390248395.19.0.993184662557.issue20316@psf.upfronthosting.co.za> Georg Brandl added the comment: > When Mercurial is ported to Python 3 somewhen in the future Good one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 21:08:09 2014 From: report at bugs.python.org (jcflack) Date: Mon, 20 Jan 2014 20:08:09 +0000 Subject: [issue20317] ExitStack hang if enough nested exceptions Message-ID: <1390248489.02.0.0980821300277.issue20317@psf.upfronthosting.co.za> New submission from jcflack: Python 3.3.2 (default, Dec 4 2013, 20:19:27) [GCC 4.7.3] on linux (gentoo) Suppose we create a context manager that will fail during exit because of a simple coding error: @contextmanager def f(): try: yield 6 finally: throdbog() # woops, forgot to define this Now let's stack up a few of these: with ExitStack() as stack: i = stack.enter_context(f()) i = stack.enter_context(f()) i = stack.enter_context(f()) print(i) ... prints 6, then hangs, won't respond to ^C, can be killed. Three levels on the stack seems to be the magic number. With one or two it works as expected ("During handling of the above exception, another exception occurred", etc.). Is the ExitStack code somehow creating a circularly-linked exception structure when there are three levels? ---------- components: Library (Lib) messages: 208574 nosy: jcflack priority: normal severity: normal status: open title: ExitStack hang if enough nested exceptions type: crash versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 21:13:11 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 20 Jan 2014 20:13:11 +0000 Subject: [issue20317] ExitStack hang if enough nested exceptions In-Reply-To: <1390248489.02.0.0980821300277.issue20317@psf.upfronthosting.co.za> Message-ID: <1390248791.21.0.316782049241.issue20317@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 21:14:05 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Jan 2014 20:14:05 +0000 Subject: [issue20262] Convert some debugging prints in zipfile to warnings In-Reply-To: <1389732995.51.0.822070396354.issue20262@psf.upfronthosting.co.za> Message-ID: <3f7PGh4dHwz7LlM@mail.python.org> Roundup Robot added the comment: New changeset 208fa45672c2 by Serhiy Storchaka in branch '2.7': Issue #20262: Warnings are raised now when duplicate names are added in the http://hg.python.org/cpython/rev/208fa45672c2 New changeset 9fda6658c01a by Serhiy Storchaka in branch '3.3': Issue #20262: Warnings are raised now when duplicate names are added in the http://hg.python.org/cpython/rev/9fda6658c01a New changeset f7cebf727bc6 by Serhiy Storchaka in branch 'default': Issue #20262: Warnings are raised now when duplicate names are added in the http://hg.python.org/cpython/rev/f7cebf727bc6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 21:15:39 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 20 Jan 2014 20:15:39 +0000 Subject: [issue20312] A missing link to Python-3.4.0b2.tar.bz2 in the download page. In-Reply-To: <1390233101.81.0.508449799289.issue20312@psf.upfronthosting.co.za> Message-ID: <1390248939.21.0.599675899702.issue20312@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed. ---------- nosy: +georg.brandl resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 21:22:28 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Jan 2014 20:22:28 +0000 Subject: [issue20262] Convert some debugging prints in zipfile to warnings In-Reply-To: <1389732995.51.0.822070396354.issue20262@psf.upfronthosting.co.za> Message-ID: <1390249348.45.0.225180804557.issue20262@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 21:30:19 2014 From: report at bugs.python.org (Andrew Lutomirski) Date: Mon, 20 Jan 2014 20:30:19 +0000 Subject: [issue20318] subprocess.Popen can hang in threaded applications Message-ID: <1390249819.03.0.991344131396.issue20318@psf.upfronthosting.co.za> New submission from Andrew Lutomirski: Running python python_thread_bug.py -j4 often results in one of the threads failing to start until another thread finishes. The bug appears to be that subprocess's pipe_cloexec function is racy: if another thread forks between os.pipe() and _set_cloexec_flag, then the resulting process could hang on to the write end of the pipe. That will cause the Popen call that got rudely interrupted to wait until the whole resulting process tree dies. ---------- components: Library (Lib) files: python_thread_bug.py messages: 208577 nosy: Andrew.Lutomirski priority: normal severity: normal status: open title: subprocess.Popen can hang in threaded applications type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file33571/python_thread_bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 21:35:09 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 20 Jan 2014 20:35:09 +0000 Subject: [issue20318] subprocess.Popen can hang in threaded applications In-Reply-To: <1390249819.03.0.991344131396.issue20318@psf.upfronthosting.co.za> Message-ID: <1390250109.49.0.808216668442.issue20318@psf.upfronthosting.co.za> R. David Murray added the comment: Hmm. I thought someone had already reported this, but I can't find an issue. I suspect it is fixed in 3.4 and it may not be practical to fix it in earlier versions. ---------- nosy: +gps, haypo, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 21:38:34 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 20 Jan 2014 20:38:34 +0000 Subject: [issue20289] Make cgi.FieldStorage a context manager In-Reply-To: <1389970045.35.0.547540590752.issue20289@psf.upfronthosting.co.za> Message-ID: <1390250314.5.0.0443321485891.issue20289@psf.upfronthosting.co.za> Berker Peksag added the comment: Here's a patch with a test and documentation update. ---------- nosy: +berker.peksag stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 21:38:50 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 20 Jan 2014 20:38:50 +0000 Subject: [issue20289] Make cgi.FieldStorage a context manager In-Reply-To: <1389970045.35.0.547540590752.issue20289@psf.upfronthosting.co.za> Message-ID: <1390250330.14.0.139636536103.issue20289@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +patch Added file: http://bugs.python.org/file33572/issue20289.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 21:46:56 2014 From: report at bugs.python.org (Ryan Smith-Roberts) Date: Mon, 20 Jan 2014 20:46:56 +0000 Subject: [issue20246] buffer overflow in socket.recvfrom_into In-Reply-To: <1389660239.25.0.341393063834.issue20246@psf.upfronthosting.co.za> Message-ID: <1390250816.14.0.119302266238.issue20246@psf.upfronthosting.co.za> Ryan Smith-Roberts added the comment: The send part of the test doesn't matter, since what's being tested happens before any reads. The MSG multiplier should be removed completely, since none of the other tests do that. Patch attached. ---------- Added file: http://bugs.python.org/file33573/recvfrom_into_small_buffer_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 22:59:36 2014 From: report at bugs.python.org (Neil Schemenauer) Date: Mon, 20 Jan 2014 21:59:36 +0000 Subject: [issue20284] patch to implement %-interpolation for bytes (roughly PEP 461) In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <1390255176.04.0.95166289405.issue20284@psf.upfronthosting.co.za> Changes by Neil Schemenauer : Removed file: http://bugs.python.org/file33501/bytes_mod.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 22:59:45 2014 From: report at bugs.python.org (Neil Schemenauer) Date: Mon, 20 Jan 2014 21:59:45 +0000 Subject: [issue20284] patch to implement %-interpolation for bytes (roughly PEP 461) In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <1390255185.95.0.5434480261.issue20284@psf.upfronthosting.co.za> Changes by Neil Schemenauer : Removed file: http://bugs.python.org/file33505/bytes_mod_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 22:59:56 2014 From: report at bugs.python.org (Neil Schemenauer) Date: Mon, 20 Jan 2014 21:59:56 +0000 Subject: [issue20284] patch to implement %-interpolation for bytes (roughly PEP 461) In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <1390255196.01.0.557084269614.issue20284@psf.upfronthosting.co.za> Changes by Neil Schemenauer : Removed file: http://bugs.python.org/file33506/bytes_mod_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 23:00:04 2014 From: report at bugs.python.org (Neil Schemenauer) Date: Mon, 20 Jan 2014 22:00:04 +0000 Subject: [issue20284] patch to implement %-interpolation for bytes (roughly PEP 461) In-Reply-To: <1389907989.35.0.952766608541.issue20284@psf.upfronthosting.co.za> Message-ID: <1390255204.55.0.704419077722.issue20284@psf.upfronthosting.co.za> Changes by Neil Schemenauer : Removed file: http://bugs.python.org/file33516/bytes_mod_v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 23:03:22 2014 From: report at bugs.python.org (Neil Schemenauer) Date: Mon, 20 Jan 2014 22:03:22 +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: <1390255402.82.0.0235151712606.issue20284@psf.upfronthosting.co.za> Neil Schemenauer added the comment: I've updated my patch into a sequence, the first of which implements PEP 461. 02-code-a.patch adds support for %a (ascii() on arg) 03-py2-flag.patch makes %s and %r behave similar to Python 2 if a command line flag is provided to the interpreter 04-py-eq.patch makes the command line flag also enable comparision between bytes() and str() (warning is generated). ---------- title: patch to implement %-interpolation for bytes (roughly PEP 461) -> patch to implement PEP 461 (%-interpolation for bytes) Added file: http://bugs.python.org/file33574/01-pep461.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 23:03:37 2014 From: report at bugs.python.org (Neil Schemenauer) Date: Mon, 20 Jan 2014 22:03:37 +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: <1390255417.23.0.904538587538.issue20284@psf.upfronthosting.co.za> Changes by Neil Schemenauer : Added file: http://bugs.python.org/file33575/02-code-a.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 23:03:51 2014 From: report at bugs.python.org (Neil Schemenauer) Date: Mon, 20 Jan 2014 22:03:51 +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: <1390255431.69.0.0327586346489.issue20284@psf.upfronthosting.co.za> Changes by Neil Schemenauer : Added file: http://bugs.python.org/file33576/03-py2-flag.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 23:04:04 2014 From: report at bugs.python.org (Neil Schemenauer) Date: Mon, 20 Jan 2014 22:04: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: <1390255444.66.0.391162275527.issue20284@psf.upfronthosting.co.za> Changes by Neil Schemenauer : Added file: http://bugs.python.org/file33577/04-py2-eq.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 23:07:40 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 20 Jan 2014 22:07:40 +0000 Subject: [issue20318] subprocess.Popen can hang in threaded applications In-Reply-To: <1390249819.03.0.991344131396.issue20318@psf.upfronthosting.co.za> Message-ID: <1390255660.84.0.241096270781.issue20318@psf.upfronthosting.co.za> Gregory P. Smith added the comment: 2.7 subprocess is fundamentally flawed and cannot be fixed. Install subprocess32 from PyPI. It's fixed in 3.2 and later. ---------- nosy: +gregory.p.smith resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 23:17:09 2014 From: report at bugs.python.org (Stefan Krah) Date: Mon, 20 Jan 2014 22:17:09 +0000 Subject: [issue20305] Android's incomplete locale.h implementation prevents cross-compilation In-Reply-To: <1390244889.25.0.657707851949.issue20305@psf.upfronthosting.co.za> Message-ID: <20140120221707.GA31831@sleipnir.bytereef.org> Stefan Krah added the comment: Shiz wrote: > As far as maintaining an Android port for CPython goes; I may be interested > in this as I'd need to regularly use it anyway. Can anyone tell me what the > possibilities are here? There seem to be some external ports already. -- On the other hand, if we integrate your patches, we'd sort of make Android officially supported. The problems with this are: a) In the past proponents of non-mainstream platforms have not been very active after an initial enthusiasm. b) There were no build slaves (See http://www.python.org/dev/buildbot/) for these platforms. c) Many (or all) core committers did not have access to the platform in question. Wikipedia claims that "QEMU also powers the Android emulator which is part of the Android SDK." Can you run a build slave with network access and also run the test suite in this emulator? Running a build slave is rather easy, see: https://wiki.python.org/moin/BuildBot http://bugs.python.org/file24399/buildslave_install.txt ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 23:19:39 2014 From: report at bugs.python.org (Andrew Lutomirski) Date: Mon, 20 Jan 2014 22:19:39 +0000 Subject: [issue20318] subprocess.Popen can hang in threaded applications In-Reply-To: <1390249819.03.0.991344131396.issue20318@psf.upfronthosting.co.za> Message-ID: <1390256379.96.0.795440513861.issue20318@psf.upfronthosting.co.za> Andrew Lutomirski added the comment: Would it be worth adding something to the Python 2.7 subprocess docs indicating that subprocess is known to be broken? ---------- resolution: wont fix -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 23:26:31 2014 From: report at bugs.python.org (Andrew Lutomirski) Date: Mon, 20 Jan 2014 22:26:31 +0000 Subject: [issue20318] subprocess.Popen can hang in threaded applications In-Reply-To: <1390249819.03.0.991344131396.issue20318@psf.upfronthosting.co.za> Message-ID: <1390256791.62.0.385690755684.issue20318@psf.upfronthosting.co.za> Andrew Lutomirski added the comment: FWIW, sticking a mutex in Popen.__init__ (wrapping the whole thing) seems to work around this issue (for programs that aren't using multiprocessing or fork, for example). This might be a good-enough fix and be safe enough to stick in the standard library. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 23:37:32 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 20 Jan 2014 22:37:32 +0000 Subject: [issue20197] Support WebP image format detection in imghdr module In-Reply-To: <1389217099.41.0.299916311184.issue20197@psf.upfronthosting.co.za> Message-ID: <1390257452.28.0.594239791469.issue20197@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag versions: +Python 3.5 -Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 20 23:56:56 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Jan 2014 22:56:56 +0000 Subject: [issue20275] asyncio: remove debug code from BaseEventLoop In-Reply-To: <1389823864.53.0.805751036513.issue20275@psf.upfronthosting.co.za> Message-ID: <3f7Stc07pqz7LkZ@mail.python.org> Roundup Robot added the comment: New changeset 8bb2c3ae9402 by Victor Stinner in branch 'default': Close #20275: Optimize BaseEventLoop._run_once() http://hg.python.org/cpython/rev/8bb2c3ae9402 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 00:05:18 2014 From: report at bugs.python.org (Tal Einat) Date: Mon, 20 Jan 2014 23:05:18 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za> Message-ID: <1390259118.31.0.53021531858.issue20180@psf.upfronthosting.co.za> Tal Einat added the comment: Attaching patch for complete conversion of Objects/unicodeobject.c. Notes: * maketrans() was already converted * converting the lstrip, rstrip and strip methods required a small, non-trivial change to the code, since they used a common function for argument parsing * the documentation for replace() now correctly reflects the actual function signature * I rephrased some doc-strings where it was required, and in several places moved some of the text into parameter descriptions ---------- Added file: http://bugs.python.org/file33578/unicodeobject.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 00:14:13 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 20 Jan 2014 23:14:13 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <1390259653.6.0.864249490633.issue20311@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > A new parameter should be added to _PyTime_ObjectToTimeval() and > _PyTime_ObjectToTimespec() to choose the rounding method. That doesn't sound necessary. Just fix the select and selectors module so that the final (OS-level) timeout is always > 0 when the user timeout is > 0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 00:17:07 2014 From: report at bugs.python.org (Tal Einat) Date: Mon, 20 Jan 2014 23:17:07 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za> Message-ID: <1390259827.65.0.453383769552.issue20180@psf.upfronthosting.co.za> Tal Einat added the comment: Attached patch for AC conversion of Objects/stringlib/transmogrify.h. Converting the functions in this file required changes to Objects/bytesobject.c and Objects/bytearrayobject.c. Those changes are in the patch as well. The conversion of those files is part of issue20179 (Derby #10). I'm adding a comment on that issue as well with a reference to this. ---------- Added file: http://bugs.python.org/file33579/transmogrify.h.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 00:19:32 2014 From: report at bugs.python.org (Tal Einat) Date: Mon, 20 Jan 2014 23:19:32 +0000 Subject: [issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4 files In-Reply-To: <1389140120.63.0.492860390436.issue20179@psf.upfronthosting.co.za> Message-ID: <1390259972.8.0.462526876588.issue20179@psf.upfronthosting.co.za> Tal Einat added the comment: While converting Objects/stringlib/transmogrify.h as part of issue20180 (Derby #11), some changes to Objects/bytesobject.c and Objects/bytearrayobject.c were required. Those changes are included in the relevant patch attached to that issue. ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 00:51:18 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 20 Jan 2014 23:51:18 +0000 Subject: [issue20267] TemporaryDirectory does not resolve path when created using a relative path In-Reply-To: <1389761308.4.0.00958902784577.issue20267@psf.upfronthosting.co.za> Message-ID: <1390261878.98.0.684730312469.issue20267@psf.upfronthosting.co.za> Yury Selivanov added the comment: The patch is ok for windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 01:18:39 2014 From: report at bugs.python.org (Glenn Langford) Date: Tue, 21 Jan 2014 00:18:39 +0000 Subject: [issue20319] concurrent.futures.wait() can block forever even if Futures have completed Message-ID: <1390263519.32.0.357208079457.issue20319@psf.upfronthosting.co.za> New submission from Glenn Langford: concurrent.futures.wait() can get into a state where it blocks forever on waiter.event.wait(), even when the underlying Futures have completed. This is demonstrated in a stress test where a large number of wait() calls are run in multiple threads, contending for the same Futures. The cause is believed to be waiter removal, which is done without locking the Future. A suggested fix which appears to work is to change the following code in wait(): for f in fs: f._waiters.remove(waiter) to: for f in fs: with f._condition: f._waiters.remove(waiter) ---------- components: Library (Lib) files: stress_wait.py messages: 208592 nosy: glangford priority: normal severity: normal status: open title: concurrent.futures.wait() can block forever even if Futures have completed type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33580/stress_wait.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 01:21:14 2014 From: report at bugs.python.org (Glenn Langford) Date: Tue, 21 Jan 2014 00:21:14 +0000 Subject: [issue20297] concurrent.futures.as_completed() installs waiters for already completed Futures In-Reply-To: <1390079975.89.0.167689725202.issue20297@psf.upfronthosting.co.za> Message-ID: <1390263674.68.0.615428489481.issue20297@psf.upfronthosting.co.za> Glenn Langford added the comment: See also http://bugs.python.org/issue20319 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 01:34:16 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 21 Jan 2014 00:34:16 +0000 Subject: [issue20320] select.select(timeout) and select.kqueue.control(timeout) must round the timeout to the upper bound Message-ID: <1390264456.23.0.80941463403.issue20320@psf.upfronthosting.co.za> New submission from STINNER Victor: Rounding issue causes performance bug in asyncio, see issue #20311 for the rationale. This issue address bugs for select and kqueue because their implementation is different. OS multiplexer: - select: microsecond resolution (10^-6), timeout converted by _PyTime_ObjectToTimeval() which converts 1e-7 to zero => BUG! - kqueue: nanosecond resolution (10^-9), timeout converted by _PyTime_ObjectToTimespec() which converts 1e-10 to zero => BUG! _PyTime_ObjectToTimeval() is used in various places: - datetime.datetime.fromtimestamp(), datetime.datetime.utcfromtimestamp() - select.select(), _PyTime_ObjectToTimespec() is used in various places: - posix.utime() - signal.sigtimedwait() - select.kqueue.control() - time.clock_settime() Attached patch adds a new round parameter to _PyTime_ObjectToTimeval() and _PyTime_ObjectToTimespec() to choose the rounding method: * _PyTime_ROUND_DOWN: Round towards zero. (current implementation) * _PyTime_ROUND_UP: Round away from zero. (new rounding method) The patch changes the rounding method for select, kqueue but also for sigtimedwait(). ---------- files: time_rouding.patch keywords: patch messages: 208594 nosy: belopolsky, haypo, neologix, pitrou, serhiy.storchaka, skrah priority: normal severity: normal status: open title: select.select(timeout) and select.kqueue.control(timeout) must round the timeout to the upper bound versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33581/time_rouding.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 01:37:55 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 21 Jan 2014 00:37:55 +0000 Subject: [issue20309] Not all method descriptors are callable In-Reply-To: <1390200218.06.0.45732778516.issue20309@psf.upfronthosting.co.za> Message-ID: <1390264675.07.0.773963872322.issue20309@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 01:43:09 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 Jan 2014 00:43:09 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <3f7WF90Yqqz7Ljk@mail.python.org> Roundup Robot added the comment: New changeset 033137c12d88 by Victor Stinner in branch '3.3': Issue #20311: select.epoll.poll() now rounds the timeout away from zero, http://hg.python.org/cpython/rev/033137c12d88 New changeset 02f9db3e684e by Victor Stinner in branch 'default': (Merge 3.3) Issue #20311: select.epoll.poll() now rounds the timeout away from http://hg.python.org/cpython/rev/02f9db3e684e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 01:49:19 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 Jan 2014 00:49:19 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <3f7WNH0974z7LjQ@mail.python.org> Roundup Robot added the comment: New changeset e042ea77a152 by Victor Stinner in branch 'default': Issue #20311: selector.PollSelector.select() now rounds the timeout away from http://hg.python.org/cpython/rev/e042ea77a152 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 01:51:06 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 21 Jan 2014 00:51:06 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <1390265466.3.0.970975081174.issue20311@psf.upfronthosting.co.za> STINNER Victor added the comment: Rounding issues with poll() and epoll() have been fixed in Python 3.3 and 3.4. I'm now waiting for buildbots before closing the issue. I created a new issue #20320 to address the rounding issue with select() and kqueue (and signal.sigtimedwait). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 02:03:57 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 21 Jan 2014 01:03:57 +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: <1390266237.83.0.920214904913.issue20284@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 02:07:29 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 21 Jan 2014 01:07:29 +0000 Subject: [issue20310] Recommend using pprint for deterministic doctest In-Reply-To: <1390202398.87.0.516795026978.issue20310@psf.upfronthosting.co.za> Message-ID: <1390266449.69.0.230252805613.issue20310@psf.upfronthosting.co.za> Antoine Pitrou added the comment: That's a rather bad idea. pprint output isn't supposed to be identical accross versions; actually, it has recently changed in some cases. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 02:16:57 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 21 Jan 2014 01:16:57 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <1390267017.16.0.0421912682413.issue20311@psf.upfronthosting.co.za> STINNER Victor added the comment: The epoll test failed on a buildbot. The test uses a short delay (10 milliseconds) and compare two different clocks: time.perf_counter() and select.epoll.poll(). I didn't expect a failure very the greatest delay, the test uses even shorter delay (the shortest is 0.1 ms). The best would be to trace syscalls to check if epoll_wait() is called with a non-zero timeout, but tracing syscalls is overkill and too low level for such test. It's maybe better to drop this unstable test? Unstable on our slow buildbots. http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%203.3/builds/1392/steps/test/logs/stdio ====================================================================== FAIL: test_timeout_rounding (test.test_epoll.TestEPoll) ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/lib/buildslave/3.3.murray-gentoo-wide/build/Lib/test/test_epoll.py", line 58, in test_timeout_rounding self.assertGreaterEqual(dt, timeout) AssertionError: 0.008995789801701903 not greater than or equal to 0.01 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 02:18:51 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Tue, 21 Jan 2014 01:18:51 +0000 Subject: [issue9521] xml.etree.ElementTree skips processing instructions when parsing In-Reply-To: <1281000343.34.0.102578281876.issue9521@psf.upfronthosting.co.za> Message-ID: <1390267131.01.0.0190368160824.issue9521@psf.upfronthosting.co.za> Nikolaus Rath added the comment: For the record: I disagree that this is an enhancement. ElementTree supports PIs as first-class tree elements. They can be added, inspected, removed, and written out when serializing into XML. Only when reading in XML, they are silently dropped. I think this is a bug, no matter how rarely people might stumble upon it in practice. If there was no support for PIs at all (i.e., they couldn't be created as tree objects) I'd agree with you that this is an enhancement. Unless there are objections, I'll try to work on a patch that either documents that PIs are lost, or optionally adds them to the tree when parsing (depending on how difficult that turns out to be). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 02:28:06 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 21 Jan 2014 01:28:06 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <1390267686.04.0.350406111507.issue20311@psf.upfronthosting.co.za> STINNER Victor added the comment: Another failure: http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.3/builds/1360/steps/test/logs/stdio ====================================================================== FAIL: test_timeout_rounding (test.test_epoll.TestEPoll) ---------------------------------------------------------------------- Traceback (most recent call last): File "/srv/buildbot/buildarea/3.3.bolen-ubuntu/build/Lib/test/test_epoll.py", line 58, in test_timeout_rounding self.assertGreaterEqual(dt, timeout) AssertionError: 0.009388947859406471 not greater than or equal to 0.01 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 02:38:50 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 Jan 2014 01:38:50 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <3f7XTP371Xz7LjW@mail.python.org> Roundup Robot added the comment: New changeset e1619465c49d by Victor Stinner in branch '3.3': Issue #20311: Try to fix the unit test, use time.monotonic() instead of http://hg.python.org/cpython/rev/e1619465c49d New changeset 26c54e9a933b by Victor Stinner in branch 'default': (Merge 3.3) Issue #20311: Try to fix the unit test, use time.monotonic() http://hg.python.org/cpython/rev/26c54e9a933b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 03:16:45 2014 From: report at bugs.python.org (Shiz) Date: Tue, 21 Jan 2014 02:16:45 +0000 Subject: [issue20305] Android's incomplete locale.h implementation prevents cross-compilation In-Reply-To: <1390155202.76.0.360148898057.issue20305@psf.upfronthosting.co.za> Message-ID: <1390270605.06.0.3355259803.issue20305@psf.upfronthosting.co.za> Shiz added the comment: > c) Many (or all) core committers did not have access to the platform > in question. I'd say Android is quite a common platform these days, although I'd concur that it's not particularly easy to run Python OOTB on. :) >Wikipedia claims that "QEMU also powers the Android emulator which is part of >the Android SDK." Can you run a build slave with network access and also run >the test suite in this emulator? I've been looking into this, and the only option provided by the Android NDK involves cross-compiling Python on a regular machine. This would require some custom commands before and in between the builds, to build a host Python first, then cross-compile the Android Python, and then start the emulator, transfer the binaries there and run the tests over adb. Can buildbot provide functionality so this can be configured on-slave, or would it require setting up a seperate master? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 03:16:46 2014 From: report at bugs.python.org (Christopher Welborn) Date: Tue, 21 Jan 2014 02:16:46 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390270606.9.0.696572043385.issue20218@psf.upfronthosting.co.za> Christopher Welborn added the comment: Isn't this something you could do yourself? import pathlib def pathread(self, binary=False): with self.open('br'if binary else 'r') as fread: return fread.read() def pathwrite(self, data, mode='w'): with self.open(mode) as fwrite: fwrite.write(data) pathlib.Path.read = pathread pathlib.Path.write = pathwrite p = pathlib.Path('/mydir/example.txt') p.read() # 'Content from path.\n' p.write('I am appending.\n', mode='a') p.read() # 'Content from path.\nI am appending.\n' ...and what about: "There should be one-- and preferably only one --obvious way to do it." ---------- nosy: +cjwelborn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 03:39:30 2014 From: report at bugs.python.org (Christopher Welborn) Date: Tue, 21 Jan 2014 02:39:30 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390271970.66.0.362492336036.issue20218@psf.upfronthosting.co.za> Christopher Welborn added the comment: I was referring to writing helper functions like pathread(mypath), though the monkeypatch version (p.read()) does work (it did when I tested it). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 04:55:13 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 21 Jan 2014 03:55:13 +0000 Subject: [issue20318] subprocess.Popen can hang in threaded applications In-Reply-To: <1390249819.03.0.991344131396.issue20318@psf.upfronthosting.co.za> Message-ID: <1390276513.5.0.347822709914.issue20318@psf.upfronthosting.co.za> Gregory P. Smith added the comment: A pointer in the 2.7 subprocess docs to subprocess32 does seem like a good idea, its what i tell everyone to do anyways. :) If you've got a patch for this in 2.7 feel free to add it here and I can take a look. leaving this open as a reminder to me to update the docs at the very least. ---------- assignee: -> gregory.p.smith status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 04:57:26 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 21 Jan 2014 03:57:26 +0000 Subject: [issue20307] Android's failure to expose SYS_* system call constants causes _posixsubprocess cross-compilation to fail In-Reply-To: <1390156070.61.0.536992358716.issue20307@psf.upfronthosting.co.za> Message-ID: <1390276646.67.0.545061419114.issue20307@psf.upfronthosting.co.za> Gregory P. Smith added the comment: The patch seems reasonable. i'd modify it slightly to include a check the SYS_getdents64 is not already defined before doing the #define. ---------- assignee: -> gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 05:03:08 2014 From: report at bugs.python.org (berdario) Date: Tue, 21 Jan 2014 04:03:08 +0000 Subject: [issue20321] ImportError when a module is created after a catched ImportError Message-ID: <1390276988.86.0.176640087742.issue20321@psf.upfronthosting.co.za> New submission from berdario: This small script errors on both Python2.7, Python3.3 and Pypy2.0 (I just reduced the test case supplied to me by ezio) ---------- components: Interpreter Core files: bbug.py messages: 208608 nosy: berdario, ezio.melotti priority: normal severity: normal status: open title: ImportError when a module is created after a catched ImportError versions: 3rd party, Python 2.7, Python 3.3 Added file: http://bugs.python.org/file33582/bbug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 05:05:26 2014 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 21 Jan 2014 04:05:26 +0000 Subject: [issue20321] ImportError when a module is created after a catched ImportError In-Reply-To: <1390276988.86.0.176640087742.issue20321@psf.upfronthosting.co.za> Message-ID: <1390277126.75.0.544062920312.issue20321@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +brett.cannon, eric.snow, ncoghlan stage: -> test needed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 05:11:40 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Tue, 21 Jan 2014 04:11:40 +0000 Subject: [issue12704] Language Reference: Clarify behaviour of yield when generator is not resumed In-Reply-To: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za> Message-ID: <1390277500.54.0.613447451787.issue12704@psf.upfronthosting.co.za> Nikolaus Rath added the comment: That makes sense. Attached is an updated patch. It removes most of the duplication, and clearly says that there is no semantic difference between the yield statement and the yield expression at all. I also moved the "see also" block to follow the description of the yield expression. At least for me, it was rather easy to miss in its current position (at the end of the second example subsection). The rest of the code churn in that section is just removing all the (presumably accidental) links to the yield statement when referring to a yield expression. ---------- Added file: http://bugs.python.org/file33583/yield-docpatch-rev3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 05:23:01 2014 From: report at bugs.python.org (Donald Stufft) Date: Tue, 21 Jan 2014 04:23:01 +0000 Subject: [issue20322] Upgrade ensurepip's pip and setuptools Message-ID: <1390278181.02.0.46118340261.issue20322@psf.upfronthosting.co.za> New submission from Donald Stufft: Pip 1.5.1 and setuptools 2.1 are out which both fix some bugs that are likely to affect some people. They both should be fairly innocuous as far as issues go so there shouldn't be any harm in upgrading in 3.4. ---------- assignee: dstufft messages: 208610 nosy: dstufft, larry priority: release blocker severity: normal status: open title: Upgrade ensurepip's pip and setuptools versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 05:25:18 2014 From: report at bugs.python.org (Shiz) Date: Tue, 21 Jan 2014 04:25:18 +0000 Subject: [issue20307] Android's failure to expose SYS_* system call constants causes _posixsubprocess cross-compilation to fail In-Reply-To: <1390156070.61.0.536992358716.issue20307@psf.upfronthosting.co.za> Message-ID: <1390278318.25.0.557788130153.issue20307@psf.upfronthosting.co.za> Shiz added the comment: That's probably a good idea. Fixed patch attached. ---------- Added file: http://bugs.python.org/file33584/Python-3.4.0tip-expose-SYS_getdents64-on-android-v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 05:26:48 2014 From: report at bugs.python.org (Shiz) Date: Tue, 21 Jan 2014 04:26:48 +0000 Subject: [issue20307] Android's failure to expose SYS_* system call constants causes _posixsubprocess cross-compilation to fail In-Reply-To: <1390156070.61.0.536992358716.issue20307@psf.upfronthosting.co.za> Message-ID: <1390278408.84.0.965899972013.issue20307@psf.upfronthosting.co.za> Shiz added the comment: Please take note of the discussion in issue 20305 if you were planning to merge this, by the way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 05:56:07 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 21 Jan 2014 04:56:07 +0000 Subject: [issue20222] unittest.mock-examples doc uses builtin file which is removed in Python 3 In-Reply-To: <1389464749.27.0.908623013872.issue20222@psf.upfronthosting.co.za> Message-ID: <1390280167.85.0.476780533898.issue20222@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- assignee: docs at python -> terry.reedy versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 06:02:38 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 Jan 2014 05:02:38 +0000 Subject: [issue20222] unittest.mock-examples doc uses builtin file which is removed in Python 3 In-Reply-To: <1389464749.27.0.908623013872.issue20222@psf.upfronthosting.co.za> Message-ID: <3f7d0Y1vYDz7LjR@mail.python.org> Roundup Robot added the comment: New changeset 36c9a233ebf0 by Terry Jan Reedy in branch '3.3': Issue #20222: file is no longer a builtin in 3.x. http://hg.python.org/cpython/rev/36c9a233ebf0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 06:03:23 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 21 Jan 2014 05:03:23 +0000 Subject: [issue20222] unittest.mock-examples doc uses builtin file which is removed in Python 3 In-Reply-To: <1389464749.27.0.908623013872.issue20222@psf.upfronthosting.co.za> Message-ID: <1390280603.28.0.923520282683.issue20222@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 06:14:38 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 21 Jan 2014 05:14:38 +0000 Subject: [issue20298] json library needs a non-strict option to decode single-quoted strings In-Reply-To: <1390097954.47.0.6743273993.issue20298@psf.upfronthosting.co.za> Message-ID: <1390281278.03.0.910628027627.issue20298@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Serhiy is correct. We're trying to stick close to the JSON spec. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 06:31:30 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 Jan 2014 05:31:30 +0000 Subject: [issue20122] Move CallTips tests to idle_tests In-Reply-To: <1388852698.51.0.14863260737.issue20122@psf.upfronthosting.co.za> Message-ID: <3f7dds3VNSz7Ljk@mail.python.org> Roundup Robot added the comment: New changeset f6f2d9d04cd0 by Terry Jan Reedy in branch '2.7': Issue #20122: Idlelib: Move tests in 3.x CallTips.py to test_calltips.py. http://hg.python.org/cpython/rev/f6f2d9d04cd0 New changeset 7befcc353d40 by Terry Jan Reedy in branch '3.3': Issue #20122: Idlelib: Move tests in CallTips.py to test_calltips.py. http://hg.python.org/cpython/rev/7befcc353d40 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 06:32:33 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 21 Jan 2014 05:32:33 +0000 Subject: [issue20122] Move CallTips tests to idle_tests In-Reply-To: <1388852698.51.0.14863260737.issue20122@psf.upfronthosting.co.za> Message-ID: <1390282353.85.0.616776331841.issue20122@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 07:05:43 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 21 Jan 2014 06:05:43 +0000 Subject: [issue20323] Argument Clinic: docstring_prototype output causes build failure on Windows Message-ID: <1390284343.93.0.69163024688.issue20323@psf.upfronthosting.co.za> New submission from Zachary Ware: The current two-pass output for the two-pass preset causes compile errors on Windows. A sample: ..\PC\winsound.c(71): error C2133: 'winsound_PlaySound__doc__' : unknown size Line 71 (clinic-generated docstring_prototype): PyDoc_VAR(winsound_PlaySound__doc__); Here's a bit more info on the error: http://msdn.microsoft.com/en-us/library/c13wk277%28v=vs.100%29.aspx There are a few viable alternatives that I can see. 1) Give PyDoc_VAR a reasonable default size. I don't like this; it seems fragile. 2) Remove docstring_prototype as an outputtable entity. I don't like this much either, it should be a reasonable thing to do. 3) Add a new PyDoc_SIZEDVAR macro, taking name and size. Argument Clinic will know the needed size and can fill it in, but it would be largely useless for manual usage. I think this is my preferred route. 4) Instead of reusing PyDoc_VAR (or a new PyDoc_SIZEDVAR), just have Clinic output the whole expanded macro, with size; e.g. "static char winsound_PlaySound__doc__[195]". This does have the downside that any future change to docstrings that would have been a simple change to the macro would have to be done in Argument Clinic, with lots of churn in every clinicized file. Here's a patch that implements option 3. ---------- files: pydoc_sizedvar.diff keywords: patch messages: 208616 nosy: larry, zach.ware priority: normal severity: normal status: open title: Argument Clinic: docstring_prototype output causes build failure on Windows type: compile error Added file: http://bugs.python.org/file33585/pydoc_sizedvar.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 07:06:37 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 21 Jan 2014 06:06:37 +0000 Subject: [issue20323] Argument Clinic: docstring_prototype output causes build failure on Windows In-Reply-To: <1390284343.93.0.69163024688.issue20323@psf.upfronthosting.co.za> Message-ID: <1390284397.11.0.518925941647.issue20323@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- components: +Build, Demos and Tools, Windows versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 07:08:53 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 21 Jan 2014 06:08:53 +0000 Subject: [issue20323] Argument Clinic: docstring_prototype output causes build failure on Windows In-Reply-To: <1390284343.93.0.69163024688.issue20323@psf.upfronthosting.co.za> Message-ID: <1390284532.99.0.400692586093.issue20323@psf.upfronthosting.co.za> Larry Hastings added the comment: I don't understand the problem--you didn't give me enough context. Can you attach a file that demonstrates the problem? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 07:19:51 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 21 Jan 2014 06:19:51 +0000 Subject: [issue20323] Argument Clinic: docstring_prototype output causes build failure on Windows In-Reply-To: <1390284343.93.0.69163024688.issue20323@psf.upfronthosting.co.za> Message-ID: <1390285191.37.0.964187196645.issue20323@psf.upfronthosting.co.za> Zachary Ware added the comment: Attached is PC/winsound.c, as converted in issue20172, but using the two-pass preset output scheme. Compiling with this file produces these errors: ..\PC\winsound.c(71): error C2133: 'winsound_PlaySound__doc__' : unknown size [P:\ath\to\cpython\PCbuild\winsound.vcxproj] ..\PC\winsound.c(79): error C2133: 'winsound_Beep__doc__' : unknown size [P:\ath\to\cpython\PCbuild\winsound.vcxproj] ..\PC\winsound.c(87): error C2133: 'winsound_MessageBeep__doc__' : unknown size [P:\ath\to\cpython\PCbuild\winsound.vcxproj] MSVC doesn't like declaring the unsized array without an asignment. ---------- Added file: http://bugs.python.org/file33586/winsound.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 07:23:30 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 21 Jan 2014 06:23:30 +0000 Subject: [issue20310] Recommend using pprint for deterministic doctest In-Reply-To: <1390202398.87.0.516795026978.issue20310@psf.upfronthosting.co.za> Message-ID: <1390285410.14.0.737288522537.issue20310@psf.upfronthosting.co.za> R. David Murray added the comment: That's a very good point. You'd think I'd have thought of it since I mentioned that it had changed in 3.4. And it will most likely change more in future versions. ---------- resolution: -> rejected stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 07:54:01 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 21 Jan 2014 06:54:01 +0000 Subject: [issue20323] Argument Clinic: docstring_prototype output causes build failure on Windows In-Reply-To: <1390284343.93.0.69163024688.issue20323@psf.upfronthosting.co.za> Message-ID: <1390287241.21.0.501394818371.issue20323@psf.upfronthosting.co.za> Larry Hastings added the comment: Does your proposed solution work properly when docstrings are turned off? Try undefining WITH_DOC_STRINGS. I bet you need to make the size 1 in that case. Also, the length must be len(f.docstring) + 1, to account for the trailing \0. Also, error C2133 doesn't look like it's applicable. On line 71 it's not being stored in a structure. Dumb MSVC. Also PyDoc_SIZEDVAR is a bad name. PyDoc_SIZED_VAR would be an improvement, but I think PyDoc_VAR_WITH_SIZE is the name you want there. And, I'm still not a +1 on this approach. Can you propose something else? Finally, I will note that the "buffer" preset would work just fine in this file, if you dumped the buffer just above the PyMethodDef array. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 08:40:09 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jan 2014 07:40:09 +0000 Subject: [issue20323] Argument Clinic: docstring_prototype output causes build failure on Windows In-Reply-To: <1390284343.93.0.69163024688.issue20323@psf.upfronthosting.co.za> Message-ID: <1390290009.3.0.608284281697.issue20323@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Why PyDoc_VAR prototype is used at all? There are only two occurrences of PyDoc_VAR in current code, and one of them actually can be replaced by PyDoc_STRVAR. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 08:49:29 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 21 Jan 2014 07:49:29 +0000 Subject: [issue20320] select.select(timeout) and select.kqueue.control(timeout) must round the timeout to the upper bound In-Reply-To: <1390264456.23.0.80941463403.issue20320@psf.upfronthosting.co.za> Message-ID: <1390290569.21.0.282095154939.issue20320@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Just so it's clear, those bugs are theoretical: whether you pass 1e-7/1e-10 or 0 to select/kqueue is exactly the same (entering/leaving the syscall takes some time)... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 08:49:51 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 21 Jan 2014 07:49:51 +0000 Subject: [issue20323] Argument Clinic: docstring_prototype output causes build failure on Windows In-Reply-To: <1390284343.93.0.69163024688.issue20323@psf.upfronthosting.co.za> Message-ID: <1390290591.48.0.853575335004.issue20323@psf.upfronthosting.co.za> Larry Hastings added the comment: Serhiy: PyDoc_VAR is used in the "two-pass" approach as a forward declaration for docstrings. Imagine if, in winsound.c, sound_methods was defined above the "dump buffer" block. The expansion of WINSOUND_PLAYSOUND_METHODDEF would include a reference to winsound_PlaySound__doc__, which hadn't been defined yet. winsound.c is simple enough, it doesn't need the two-pass approach. But two-pass would work well for _pickle.c, where there are four or five PyMethodDef structures in the middle of the file. Part of this is just Zachary experimenting with two-pass. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 08:51:39 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 21 Jan 2014 07:51:39 +0000 Subject: [issue20313] inspect.signature should raise ValueError for builtins with no signature info In-Reply-To: <1390236993.79.0.241444273763.issue20313@psf.upfronthosting.co.za> Message-ID: <1390290699.68.0.949851084611.issue20313@psf.upfronthosting.co.za> Larry Hastings added the comment: If you want to make sure that happens, please review my next patch for #20189, or fix it after that patch goes in if I forget. (Honestly it's hard for me to keep track of everything right now.) ---------- resolution: -> duplicate stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 08:58:03 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jan 2014 07:58:03 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390291083.63.0.0232769584887.issue20218@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Not every two line function are worth to be added to the stdlib. ---------- nosy: +pitrou, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 09:01:50 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 21 Jan 2014 08:01:50 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1390291310.4.0.326461804804.issue20189@psf.upfronthosting.co.za> Larry Hastings added the comment: Argh. I lost 1.5 day's worth of work on revision 6 of this patch last night, due to me being tired and over-aggressively cleaning my working directories. I will have to reconstruct it from memory, hopefully Tuesday. (I basically know what I did, and going through the process again should be much quicker.) I have more C fixes by the way: * PyTypeObject needs to also expose __text_signature__. Otherwise builtin classes can't have signatures. * There are a bunch of default docstrings for tp_ etc. slots (__add__, __call__) that live in typeobject.c. I'll hand-convert them to have signatures and reasonable docstrings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 09:10:24 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 Jan 2014 08:10:24 +0000 Subject: [issue16655] IDLE list.append calltips test failures In-Reply-To: <1355106680.63.0.980843765647.issue16655@psf.upfronthosting.co.za> Message-ID: <3f7j9C6LLQz7Ljk@mail.python.org> Roundup Robot added the comment: New changeset 779e5511d803 by Terry Jan Reedy in branch '2.7': Issue #16655: Explain why Idle's test_calltips has 'fragile' tests of builtins. http://hg.python.org/cpython/rev/779e5511d803 New changeset 4a505a901b2e by Terry Jan Reedy in branch '3.3': Issue #16655: Explain why Idle's test_calltips has 'fragile' tests of builtins. http://hg.python.org/cpython/rev/4a505a901b2e New changeset c4a2d0538441 by Terry Jan Reedy in branch 'default': Issue #16655: Explain why Idle's test_calltips has 'fragile' tests of builtins. http://hg.python.org/cpython/rev/c4a2d0538441 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 09:12:41 2014 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 21 Jan 2014 08:12:41 +0000 Subject: [issue9521] xml.etree.ElementTree skips processing instructions when parsing In-Reply-To: <1281000343.34.0.102578281876.issue9521@psf.upfronthosting.co.za> Message-ID: <1390291961.32.0.272206230655.issue9521@psf.upfronthosting.co.za> Stefan Behnel added the comment: > Unless there are objections, I'll try to work on a patch that either documents that PIs are lost, or optionally adds them to the tree when parsing (depending on how difficult that turns out to be). Please do. It should not be difficult at all to make the parser create PI objects (or comments). Note, however, that this needs to be done in both the Python implementation and the parser of celementtree. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 09:17:52 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 21 Jan 2014 08:17:52 +0000 Subject: [issue16655] IDLE list.append calltips test failures In-Reply-To: <1355106680.63.0.980843765647.issue16655@psf.upfronthosting.co.za> Message-ID: <1390292272.24.0.605795008647.issue16655@psf.upfronthosting.co.za> Terry J. Reedy added the comment: When I moved tests from CallTips.py to test_calltips.py, I reduced but did not eliminate the use of builtins. I decided instead to explain in the file why there is no substitute for the real thing, and how to fix a simple mismatch like that reported here. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 09:21:24 2014 From: report at bugs.python.org (Dirkjan Ochtman) Date: Tue, 21 Jan 2014 08:21:24 +0000 Subject: [issue20324] gcc-4.3 support on python-3.3 (libmpdec) Message-ID: <1390292484.35.0.247229309669.issue20324@psf.upfronthosting.co.za> New submission from Dirkjan Ochtman: See https://bugs.gentoo.org/show_bug.cgi?id=498640: What compiler versions are supported for 3.3? We noticed an issue when compiling 3.3.3 with gcc 4.3: /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../x86_64-pc-linux-gnu/bin/ld: build/temp.linux-x86_64-3.3/var/tmp/portage/dev-lang/python-3.3.3/work/Python-3.3.3/Modules/_decimal/libmpdec/mpdecimal.o: warning: relocation against `mprime_rdx' in readonly section `.text'. /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../x86_64-pc-linux-gnu/bin/ld: build/temp.linux-x86_64-3.3/var/tmp/portage/dev-lang/python-3.3.3/work/Python-3.3.3/Modules/_decimal/libmpdec/basearith.o: relocation R_X86_64_PC32 against symbol `mprime_rdx' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value Ruud Koolen came up with a patch: diff -r f7cebf727bc6 Modules/_decimal/libmpdec/constants.c --- a/Modules/_decimal/libmpdec/constants.c Mon Jan 20 21:59:33 2014 +0200 +++ b/Modules/_decimal/libmpdec/constants.c Mon Jan 20 22:12:50 2014 +0100 @@ -71,6 +71,9 @@ }; /* magic number for constant division by MPD_RADIX */ +#if defined(__GNUC__) && (__GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 3)) + __attribute__((visibility("hidden"))) +#endif const mpd_uint_t mprime_rdx = 15581492618384294730ULL; #elif defined(CONFIG_32) ---------- components: Library (Lib) keywords: 3.3regression messages: 208630 nosy: djc, skrah priority: normal severity: normal status: open title: gcc-4.3 support on python-3.3 (libmpdec) versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 09:42:48 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 21 Jan 2014 08:42:48 +0000 Subject: [issue20324] gcc-4.3 support on python-3.3 (libmpdec) In-Reply-To: <1390292484.35.0.247229309669.issue20324@psf.upfronthosting.co.za> Message-ID: <1390293768.03.0.906141354258.issue20324@psf.upfronthosting.co.za> Georg Brandl added the comment: Should be figured out for 3.3.4 ---------- nosy: +georg.brandl priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 09:52:13 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Tue, 21 Jan 2014 08:52:13 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1390294333.95.0.794126571802.issue20185@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the patch for longobject. There are two sites which I couldn't convert. The first is the constructor which is complicated. The other one is __round__ which clinic explicitly does not support. ---------- Added file: http://bugs.python.org/file33587/clinic_longobject.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 11:01:26 2014 From: report at bugs.python.org (Tal Einat) Date: Tue, 21 Jan 2014 10:01:26 +0000 Subject: [issue20325] Argument Clinic: self converters are not preserved when clonig functions Message-ID: <1390298486.22.0.452185457734.issue20325@psf.upfronthosting.co.za> New submission from Tal Einat: In Objects/bytes.c, the strip methods need a "self converter" so that they get a PyBytesObject* instead of PyObject*. However, having set this in bytes.strip and "cloning" that clinic definition for bytes.lstrip and bytes.rstrip, it appears that the self converter wasn't set on lstrip and rstrip. Removing the cloning and copying the argument definitions resolved the issue. Is this a bug? ---------- components: Build, Demos and Tools messages: 208633 nosy: larry, taleinat priority: normal severity: normal status: open title: Argument Clinic: self converters are not preserved when clonig functions type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 11:05:49 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 21 Jan 2014 10:05:49 +0000 Subject: [issue20326] Argument Clinic should use a non-error-prone syntax to mark text signatures Message-ID: <1390298749.1.0.12762219489.issue20326@psf.upfronthosting.co.za> New submission from Larry Hastings: Sorry this is so long--but I wanted to make my point. Here's the tl;dr summary. The problem: The syntax used for Argument-Clinic-generated text signatures for builtins means CPython mistakenly identifies hand-written, unparsable pseudo-signatures as legitimate signatures. This causes real, non-hypothetical problems. I think we should change the syntax to something people would never write by accident. Here are some suggestions: "*(" "*clinic*(" "\01 clinic(" -- A quick recap on how signature information for builtins works. The builtin's docstring contains the signature, encoded as text using a special syntax on the first line. CPython callables always have getters for their __doc__ member; the doc getter function examines the first line, and if it detects a signature it skips past it and returns the rest. CPython's new getter on callables __text_signature__ also look at the internal docstring. If it detects a signature it returns it, otherwise it returns None. inspect.signature then retrieves __text_signature__, and if ast.parse() parses it, it populates the appropriate Signature and returns that. And then pydoc uses the Signature object to print the first line of help(). In #19674 there was some discussion on what this syntax should be. Guido suggested they look like this: functionname(args, etc)\n He felt it was a good choice, and pointed out that Sphinx autodoc uses this syntax. (Not because using this syntax would help Sphinx--it won't. Just as a "here's how someone else solved the problem" data point.) __doc__ and __text_signature_ aren't very smart about detecting signatures. Here's their test in pseudo-code: if the first N bytes match the name of the function, and the N+1th byte is a left parenthesis, then it's assumed to be a valid signature. -- First, consider: this signature syntax is the convention docstrings already use. Nearly every builtin callable in Python has a hand-written docstring that starts with "functionname(". Great!, you might think, we get signatures for free, even on functions that haven't been converted to Argument Clinic! The problem is, many of these pseudo-signatures aren't proper Python. Consider the first line of the docstring for os.lstat(): "lstat(path, *, dir_fd=None) -> stat result\n" This line passes the "is it a text signature test?", so __doc__ skips past it and __text_signature__ returns it. But it isn't valid actually valid. ast.parse() rejects it, so inspect.signature returns nothing. pydoc doesn't get a valid signature, so it prints "lstat(...)", and the user is deprived of the helpful line handwritten by lstat's author. That's bad enough. Now consider the first *two* lines of the docstring for builtin open(): "open(file, mode='r', buffering=-1, encoding=None,\n" " errors=None, newline=None, closefd=True, opener=None) -> file object\n" __doc__ clips the first line but retains the second. pydoc prints "open(...)", followed by the second line! Now we have the problem reported in #20075: "help(open) eats first line". Both of these problems go away if I add one more check to the signature-detecting code: does the line end with ')'? But that's only a band-aid on the problem. Consider socket.accept's docstring: "_accept() -> (integer, address info)\n" Okay, so __doc__ and __text_signature__ could count parentheses and require them to balance. But then they'd have to handle strings that contain parentheses, which means they'd also have to understand string quoting. And there would *still* be handwritten docstrings that would pass that test but wouldn't parse properly. Consider bisect.insort_right: "insort_right(a, x[, lo[, hi]])\n" We could only be *certain* if we gave up on having two parsers. Write the signature-recognizer code only once, in C, then call that in __doc__ and __text_signature__ and inspect.signature(). But that seems unreasonable. Okay, so we could attack the problem from the other end. Clean up all the docstrings in CPython, either by converting to Argument Clinic or just fixing them by hand. But that means that *third-party modules* will still have the mysterious problem. Therefore I strongly suggest we switch to a syntax that nobody will ever use by accident. Have I convinced you? ---------- assignee: larry messages: 208634 nosy: barry, brett.cannon, gennad, gvanrossum, larry, ncoghlan, skrah, zach.ware priority: normal severity: normal stage: needs patch status: open title: Argument Clinic should use a non-error-prone syntax to mark text signatures type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 11:23:27 2014 From: report at bugs.python.org (Ram Rachum) Date: Tue, 21 Jan 2014 10:23:27 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390299807.65.0.71297848528.issue20218@psf.upfronthosting.co.za> Ram Rachum added the comment: Christopher and Serhiy, I would appreciate if you could kindly explain why your arguments, while applying to my suggestions, do not apply to the following functions: - `Path.stat` - `Path.owner` - `Path.group` - `Path.open` - `Path.chmod` - `Path.lchmod` - `Path.unlink` - `Path.rmdir` - `Path.lstat` - `Path.rename` - `Path.replace` - `Path.symlink_to` I am quite sick of all those lofty principles being quoted when I want to add something to Python, yet I see Python features that break them all the time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 11:27:26 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 21 Jan 2014 10:27:26 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390300046.0.0.087496100789.issue20218@psf.upfronthosting.co.za> Antoine Pitrou added the comment: FWIW, I agree that shortcuts to easily create or read entire files are useful. Other path classes (such as Twisted's) often have them. ---------- versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 11:28:14 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 21 Jan 2014 10:28:14 +0000 Subject: [issue20197] Support WebP image format detection in imghdr module In-Reply-To: <1389217099.41.0.299916311184.issue20197@psf.upfronthosting.co.za> Message-ID: <1390300094.33.0.897633292986.issue20197@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 11:28:48 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Tue, 21 Jan 2014 10:28:48 +0000 Subject: [issue20325] Argument Clinic: self converters are not preserved when cloning functions In-Reply-To: <1390298486.22.0.452185457734.issue20325@psf.upfronthosting.co.za> Message-ID: <1390300128.71.0.948255770243.issue20325@psf.upfronthosting.co.za> Changes by Vajrasky Kok : ---------- title: Argument Clinic: self converters are not preserved when clonig functions -> Argument Clinic: self converters are not preserved when cloning functions _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 11:37:00 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 21 Jan 2014 10:37:00 +0000 Subject: [issue20303] Argument Clinic: optional groups In-Reply-To: <1390138180.16.0.400473002032.issue20303@psf.upfronthosting.co.za> Message-ID: <1390300620.5.0.348408382052.issue20303@psf.upfronthosting.co.za> Larry Hastings added the comment: Confirmed, and yes it's low priority. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 11:40:09 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 21 Jan 2014 10:40:09 +0000 Subject: [issue20320] select.select(timeout) and select.kqueue.control(timeout) must round the timeout to the upper bound In-Reply-To: <1390264456.23.0.80941463403.issue20320@psf.upfronthosting.co.za> Message-ID: <1390300809.44.0.873320334506.issue20320@psf.upfronthosting.co.za> STINNER Victor added the comment: Timings on my laptop: >>> import time, select >>> t0=time.perf_counter(); select.select([], [], [], 1e-6); dt=time.perf_counter()-t0; dt ([], [], []) 0.00012494399561546743 >>> t0=time.perf_counter(); select.select([], [], [], 0); dt=time.perf_counter()-t0; dt ([], [], []) 4.965400148648769e-05 A call to select.select() with a timeout of 1 microsecond (10^-6) takes 124 microesconds. A non-blocking call to select.select() (timeout of 0 microsecond) takes 50 microseconds. > Just so it's clear, those bugs are theoretical: whether you pass 1e-7/1e-10 or 0 to select/kqueue is exactly the same (entering/leaving the syscall takes some time)... Yes, the problem of asyncio (explained in issue #20311) is that selector.select(timeout) took *less* than timeout seconds even when no new event was found, and so the loop restarted again and again. According to the timings above, selector.select(1e-7) (which calls currently select.select() in non blocking mode, with a timeout of 0 second) takes longer than 1e-7 second: at least 500e-7 seconds. So yes, the problem cannot be reproduced on my current hardware. It may be fine to only fix these bugs in Python 3.5. ---------- versions: +Python 3.5 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 12:06:32 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jan 2014 11:06:32 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390302392.77.0.739022633767.issue20218@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Christopher and Serhiy, I would appreciate if you could kindly explain why your arguments, while applying to my suggestions, do not apply to the following functions: 1. Path.stat() wraps only one function, while Path.read() wraps two functions. It's signature should be a sum of open() and read() signatures: Path.read(encoding, errors, newline, size) (I have omitted some open's parameters). This is a little cumbersome. 2. os.stat() requires `import os`, while open() is builtin. 3. If add Path.read(), what about Path.readlines() and Path.readline()? 4. I believe Path.stat() will be used much more often than Path.read(). 5. Path.stat() corresponds to low-level os.stat(), but for low-level os.read() the high-level corresponding is FileIO.read(). And this corresponding is much more universal and useful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 12:21:26 2014 From: report at bugs.python.org (Ram Rachum) Date: Tue, 21 Jan 2014 11:21:26 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390303286.21.0.939759817013.issue20218@psf.upfronthosting.co.za> Ram Rachum added the comment: Serhiy: Your arguments 1 and 2 are pretty weak. (So what if an import is required? It's still 2 lines. I thought that "Not every two line function are worth to be added to the stdlib.") Regarding stat being used much more often than read: I disagree. I've done whole-file reads much more often than I've done stat. Different people might have different habits, but I definitely think that reading an entire file is a common operation with files. And we can all agree that other trivial Path method like `lstat` are much less common than both stat and whole-file read, yet they've earned their place in the stdlib, while we are still arguing whether `Path.read` and `path.write` should have a place too. Regarding `Path.readline` and `Path.readlines`: I don't have an opinion on whether they should be implemented or not, since I rarely use them. But I definitely think that they have no bearing on the decision of whether to include `Path.read` and `Path.write` or not. Your argument 5 also looks weak to me. It looks to me like you're looking for arguments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 12:28:15 2014 From: report at bugs.python.org (Tal Einat) Date: Tue, 21 Jan 2014 11:28:15 +0000 Subject: [issue20327] Argument Clinic: setting internal variable names for parsed arguments Message-ID: <1390303694.96.0.387244097814.issue20327@psf.upfronthosting.co.za> New submission from Tal Einat: It would be useful for conversion of existing function to be able to set the name of the C variable for arguments which is different than the Python argument name. For example, not being able to do so makes converting bytes.translate much harder. In the existing code, the first argument is called 'table' in the docs but 'tableobj' in the code. Furthermore, a different variable named 'table' is used rather extensively in the function. If clinic could be told to name the C variable 'tableobj', then that would be that. Otherwise renaming two variables in the code is unaviodable. ---------- components: Build, Demos and Tools messages: 208641 nosy: taleinat priority: normal severity: normal status: open title: Argument Clinic: setting internal variable names for parsed arguments type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 12:40:58 2014 From: report at bugs.python.org (Jonathan Dowland) Date: Tue, 21 Jan 2014 11:40:58 +0000 Subject: [issue20328] mailbox: Message-ID: <1390304458.71.0.378928457479.issue20328@psf.upfronthosting.co.za> New submission from Jonathan Dowland: It would be great if the 'mailbox' library supported a 'remove' or 'delete' operation for the mailbox itself as part of its abstract interface. It does support removing messages, and the sub-classes for Maildir, MH etc. support removing sub-folders (their interface is common but they don't inherit a common interface); but removing the actual parent mailbox itself is not yet supported. ---------- components: Library (Lib) messages: 208642 nosy: jmtd priority: normal severity: normal status: open title: mailbox: versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 12:41:14 2014 From: report at bugs.python.org (Jonathan Dowland) Date: Tue, 21 Jan 2014 11:41:14 +0000 Subject: [issue20328] mailbox: In-Reply-To: <1390304458.71.0.378928457479.issue20328@psf.upfronthosting.co.za> Message-ID: <1390304474.93.0.325130852397.issue20328@psf.upfronthosting.co.za> Changes by Jonathan Dowland : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 13:02:37 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 21 Jan 2014 12:02:37 +0000 Subject: [issue20324] gcc-4.3 support on python-3.3 (libmpdec) In-Reply-To: <1390292484.35.0.247229309669.issue20324@psf.upfronthosting.co.za> Message-ID: <1390305757.04.0.703921242068.issue20324@psf.upfronthosting.co.za> Stefan Krah added the comment: Do you mean gcc-4.2? The patch uses __GNUC_MINOR__ < 3. On the FreeBSD build slave gcc-4.2 works: gcc (GCC) 4.2.1 20070831 patched [FreeBSD] Are you sure that there aren't any gcc patches for this version? It looks like a gcc/binutils issue to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 13:09:07 2014 From: report at bugs.python.org (Tal Einat) Date: Tue, 21 Jan 2014 12:09:07 +0000 Subject: [issue20327] Argument Clinic: setting internal variable names for parsed arguments In-Reply-To: <1390303694.96.0.387244097814.issue20327@psf.upfronthosting.co.za> Message-ID: <1390306147.32.0.236601922818.issue20327@psf.upfronthosting.co.za> Tal Einat added the comment: Attaching a straight-forward patch, adding an optional 'c_name' parameter to CConvertor. When given it is used for the name of the C variable. It is also used for the '_length' variable names (when used). This works for my use case (bytes.translate). All existing clinic tests pass. This patch doesn't include new tests. If this feature request and implementation approach are accepted, I'd be happy to add tests. ---------- keywords: +patch nosy: +larry Added file: http://bugs.python.org/file33588/clinic_allow_setting_c_variable_name.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 14:07:48 2014 From: report at bugs.python.org (Daniel Szoska) Date: Tue, 21 Jan 2014 13:07:48 +0000 Subject: [issue9291] mimetypes initialization fails on Windows because of non-Latin characters in registry In-Reply-To: <1279454095.41.0.733053669611.issue9291@psf.upfronthosting.co.za> Message-ID: <1390309668.74.0.941711333635.issue9291@psf.upfronthosting.co.za> Changes by Daniel Szoska : ---------- nosy: +Daniel.Szoska _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 14:45:38 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 21 Jan 2014 13:45:38 +0000 Subject: [issue20321] ImportError when a module is created after a catched ImportError In-Reply-To: <1390276988.86.0.176640087742.issue20321@psf.upfronthosting.co.za> Message-ID: <1390311938.21.0.930266476803.issue20321@psf.upfronthosting.co.za> Brett Cannon added the comment: I'm not sure why you think the example code as-is should work. The first entry on sys.path is the current directory ('' or the absolute path, depending if you are running from the interpreter prompt or specifying a file on the command-line). Stripping off sys.path[0] guarantees the example code will not work. And as for why adding in '.' works on PyPy and not Python 3.3, it's because you didn't call importlib.invalidate_caches() to clear out the directory modification, so Python didn't notice that the file was added because the mtime granularity for directories it larger than the time it took to have the import for it_does_not_exist fail, write the impfile.py file, and to try importing again. ---------- assignee: -> brett.cannon resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 15:33:04 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jan 2014 14:33:04 +0000 Subject: [issue20197] Support WebP image format detection in imghdr module In-Reply-To: <1389217099.41.0.299916311184.issue20197@psf.upfronthosting.co.za> Message-ID: <1390314784.07.0.81221502753.issue20197@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. Detecting function matches the WebP specification [1]. [1] https://developers.google.com/speed/webp/docs/riff_container#webp-file-header ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 15:34:46 2014 From: report at bugs.python.org (Laurent Mazuel) Date: Tue, 21 Jan 2014 14:34:46 +0000 Subject: [issue10614] ZipFile: add a filename_encoding argument In-Reply-To: <1291362121.18.0.976785403189.issue10614@psf.upfronthosting.co.za> Message-ID: <1390314886.12.0.0192996623397.issue10614@psf.upfronthosting.co.za> Changes by Laurent Mazuel : ---------- nosy: +Laurent.Mazuel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 15:36:19 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 21 Jan 2014 14:36:19 +0000 Subject: [issue20324] gcc-4.2.4 support on python-3.3 (libmpdec) In-Reply-To: <1390292484.35.0.247229309669.issue20324@psf.upfronthosting.co.za> Message-ID: <1390314979.48.0.195618548711.issue20324@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- title: gcc-4.3 support on python-3.3 (libmpdec) -> gcc-4.2.4 support on python-3.3 (libmpdec) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 15:44:05 2014 From: report at bugs.python.org (Paul Moore) Date: Tue, 21 Jan 2014 14:44:05 +0000 Subject: [issue19643] shutil rmtree fails on readonly files in Windows In-Reply-To: <1384776671.66.0.696428447361.issue19643@psf.upfronthosting.co.za> Message-ID: <1390315445.94.0.513711693854.issue19643@psf.upfronthosting.co.za> Paul Moore added the comment: The most obvious solution would be if the onerror argument allowed for retries. At the moment, all it can do is report issues, not recover. Suppose that returning True from onerror meant "retry the operation". Then you could do def set_rw(operation, name, exc): os.chmod(name, stat.S_IWRITE) return True shutil.rmtree('path', onerror=set_rw) ---------- nosy: +pmoore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 15:46:30 2014 From: report at bugs.python.org (Jeremy Kloth) Date: Tue, 21 Jan 2014 14:46:30 +0000 Subject: [issue20326] Argument Clinic should use a non-error-prone syntax to mark text signatures In-Reply-To: <1390298749.1.0.12762219489.issue20326@psf.upfronthosting.co.za> Message-ID: <1390315590.39.0.260849136743.issue20326@psf.upfronthosting.co.za> Changes by Jeremy Kloth : ---------- nosy: +jkloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 16:05:53 2014 From: report at bugs.python.org (Laurent Mazuel) Date: Tue, 21 Jan 2014 15:05:53 +0000 Subject: [issue20329] zipfile.extractall fails in Posix shell with utf-8 filename Message-ID: <1390316753.93.0.767122614569.issue20329@psf.upfronthosting.co.za> New submission from Laurent Mazuel: Hello, Considering a zip file which contains utf-8 filenames (as uploaded zip file), the following code fails if launched in a Posix shell. >>> with zipfile.ZipFile("test_ut8.zip") as fd: ... fd.extractall() ... Traceback (most recent call last): File "", line 2, in File "/opt/python/3.3/lib/python3.3/zipfile.py", line 1225, in extractall self.extract(zipinfo, path, pwd) File "/opt/python/3.3/lib/python3.3/zipfile.py", line 1213, in extract return self._extract_member(member, path, pwd) File "/opt/python/3.3/lib/python3.3/zipfile.py", line 1276, in _extract_member open(targetpath, "wb") as target: UnicodeEncodeError: 'ascii' codec can't encode characters in position 10-14: ordinal not in range(128) With shell: $ locale LANG=POSIX ... But filesystem is not encoding dependant. On a Unix system, filename are only bytes, there is no reason to refuse to unzip a zip file (in fact, "unzip" command line don't fail to unzip the file in a Posix shell). Since "open" can take "bytes" filename, changing the line 1276 from > open(targetpath) to: > open(targetpath.encode("utf-8")) fixes the problem. zipfile should not care about the encoding of the filename and should use the bytes sequence filename extracted directly from the bytes sequence of the zipfile. Having "ZipInfo.filename" as a string (and not bytes) is great for an API, but is not needed to open/write a file on the disk. Then, ZipInfo should store the direct bytes sequences of filename as a "bytes_filename" field and use it in the "open" of "extract". In addition, considering the patch of bug 10614, the right patch could use the new "ZipInfo.encoding" field: > open(targetpath.encode(member.encoding)) ---------- components: Extension Modules files: test_ut8.zip messages: 208648 nosy: Laurent.Mazuel priority: normal severity: normal status: open title: zipfile.extractall fails in Posix shell with utf-8 filename type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file33589/test_ut8.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 16:07:19 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 21 Jan 2014 15:07:19 +0000 Subject: [issue20295] imghdr add openexr support In-Reply-To: <1390070746.18.0.632580086157.issue20295@psf.upfronthosting.co.za> Message-ID: <1390316839.51.0.521690486678.issue20295@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 16:08:04 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 21 Jan 2014 15:08:04 +0000 Subject: [issue20328] mailbox: In-Reply-To: <1390304458.71.0.378928457479.issue20328@psf.upfronthosting.co.za> Message-ID: <1390316884.16.0.778919240064.issue20328@psf.upfronthosting.co.za> R. David Murray added the comment: Conceptually the problem with this is that if you use the object to delete the folder, you now have an object with no folder...that is, an invalid object. Do we have any other stdlib examples of objects with a 'delete()' method...looks like bdb has a deleteMe on breakpoint objects, but it isn't clear that it tries to deal with what happens if a breakpoint object that has been deleted is accessed again. There are also some in idlelib/tk, which I haven't looked at. So, I guess the issue is to work out what the semantics of the object would be if delete has been called, and make sure it actually makes sense to have a delete method. ---------- components: +email nosy: +barry, r.david.murray versions: +Python 3.5 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 16:08:12 2014 From: report at bugs.python.org (Masami HIRATA) Date: Tue, 21 Jan 2014 15:08:12 +0000 Subject: [issue20330] PEP 342 is outdated Message-ID: <1390316892.04.0.132074086139.issue20330@psf.upfronthosting.co.za> New submission from Masami HIRATA: Although PEP 342 says foo(yield 42) is legal, Lib/test/test_grammar.py says: > # Requires parentheses as call argument > def g(): f((yield 1)) > check_syntax_error(self, "def g(): f(yield 1)") BTW, It seems that foo(yield 42) written in ECMAScript 6 is OK. ---------- assignee: docs at python components: Documentation messages: 208650 nosy: docs at python, msmhrt priority: normal severity: normal status: open title: PEP 342 is outdated versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 16:17:43 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 21 Jan 2014 15:17:43 +0000 Subject: [issue19643] shutil rmtree fails on readonly files in Windows In-Reply-To: <1384776671.66.0.696428447361.issue19643@psf.upfronthosting.co.za> Message-ID: <1390317463.1.0.235596233823.issue19643@psf.upfronthosting.co.za> R. David Murray added the comment: See issue 8523 for a discussion of changing the way onerror behaves. I think it is addressing this same use case, but I didn't reread it in detail. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 16:19:29 2014 From: report at bugs.python.org (Glenn Langford) Date: Tue, 21 Jan 2014 15:19:29 +0000 Subject: [issue20297] concurrent.futures.as_completed() installs waiters for already completed Futures In-Reply-To: <1390079975.89.0.167689725202.issue20297@psf.upfronthosting.co.za> Message-ID: <1390317569.22.0.768608483069.issue20297@psf.upfronthosting.co.za> Glenn Langford added the comment: Uploading proposed new version of as_completed() for review. Note the following changes: - does not install waiters for Futures which are completed - locks only one Future at a time to improve concurrency (rather than locking all Futures at once); traverses Futures in the order given, as no need to sort into a canonical order - immediately yields each completed Future, without waiting to lock and examine other Futures - fixes locking bug in waiter removal ---------- Added file: http://bugs.python.org/file33590/as_completed_proposed.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 16:19:54 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 21 Jan 2014 15:19:54 +0000 Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1390317594.41.0.495523762555.issue20152@psf.upfronthosting.co.za> Brett Cannon added the comment: Here is fcntl converted. I didn't do fcntl.ioctl as it has a crazy set of possible signatures which I simply didn't want to deal with. ---------- Added file: http://bugs.python.org/file33591/fcntl_derby.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 16:29:44 2014 From: report at bugs.python.org (Paul Moore) Date: Tue, 21 Jan 2014 15:29:44 +0000 Subject: [issue19643] shutil rmtree fails on readonly files in Windows In-Reply-To: <1384776671.66.0.696428447361.issue19643@psf.upfronthosting.co.za> Message-ID: <1390318184.98.0.281913775098.issue19643@psf.upfronthosting.co.za> Paul Moore added the comment: It's similar. But the problem is that it only returns a list of errors, it doesn't let you address the error *while the rmtree is in progress*. The key thing is that if you can fix the problem in onerror, you can avoid needing to restart the whole tree walk, which is the key aspect of rmtree. As things stand, you can use the set_rw function I showed above, and run the rmtree twice: shutil.rmtree('path', onerror=set_rw) shutil.rmtree('path') The first run fixes the error and then the second one deletes the remaining files. But this is clearly inefficient, and makes the limitations of "report errors to the user who can then address them" fairly obvious. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 16:33:31 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 21 Jan 2014 15:33:31 +0000 Subject: [issue20329] zipfile.extractall fails in Posix shell with utf-8 filename In-Reply-To: <1390316753.93.0.767122614569.issue20329@psf.upfronthosting.co.za> Message-ID: <1390318411.18.0.548313596381.issue20329@psf.upfronthosting.co.za> R. David Murray added the comment: If you live in a current-posix world, this might make sense. However, one can also argue that the filename should be *transcoded* from the tarfile encoding to the local FS filename encoding, which I believe is what we are currently doing. Which, if you are using POSIX as the locale, will fail a lot. If you use a sensible modern locale that includes utf-8, you wouldn't have a problem. Unfortunately, the reality is probably that sometimes you want one behavior and sometimes you want the other :( Encoding using member.encoding is probably wrong, though. If you are trying to preserve the original bytes, is is probably best do so, and not assume that the tarfile encoding field is valid. I'm adding Victor Stinner to nosy: he's thought about these issues much more deeply than I have. The answer may be that we will only support transcoding filenames in our tarfile module...and certainly it looks like doing anything else, even if we want to, would be a new feature. ---------- nosy: +haypo, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 16:40:42 2014 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 21 Jan 2014 15:40:42 +0000 Subject: [issue20326] Argument Clinic should use a non-error-prone syntax to mark text signatures In-Reply-To: <1390298749.1.0.12762219489.issue20326@psf.upfronthosting.co.za> Message-ID: <1390318842.34.0.977421494139.issue20326@psf.upfronthosting.co.za> Guido van Rossum added the comment: You have convinced me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 16:50:16 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 21 Jan 2014 15:50:16 +0000 Subject: [issue19643] shutil rmtree fails on readonly files in Windows In-Reply-To: <1384776671.66.0.696428447361.issue19643@psf.upfronthosting.co.za> Message-ID: <1390319416.18.0.141385394841.issue19643@psf.upfronthosting.co.za> R. David Murray added the comment: OK, rereading that issue, I disagree with Tarek and I think that the patch on that issue is ill-advised as it looks like it changes behavior in a non-backward-compatible way. If you changed your set_rw onerror handler to a rm_ro_file error handler, would things work? That is, have the handler delete the file? Adding a 'retry' capability is interesting, but would be a non-trivial change in logic, and should be addressed in a new issue, not this one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 16:53:39 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 21 Jan 2014 15:53:39 +0000 Subject: [issue20330] PEP 342 is outdated In-Reply-To: <1390316892.04.0.132074086139.issue20330@psf.upfronthosting.co.za> Message-ID: <1390319619.56.0.645959046113.issue20330@psf.upfronthosting.co.za> R. David Murray added the comment: Most PEPs are historical documents once they are final, so I don't think there is actually anything to fix here. But I could be wrong. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 16:59:07 2014 From: report at bugs.python.org (Martin d'Anjou) Date: Tue, 21 Jan 2014 15:59:07 +0000 Subject: [issue9694] argparse required arguments displayed under "optional arguments" In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za> Message-ID: <1390319947.6.0.397055766653.issue9694@psf.upfronthosting.co.za> Martin d'Anjou added the comment: How about calling required arguments "required arguments"? required arguments: --reqarg REQARG, -r REQARG This is required optional arguments: -h, --help show this help message and exit --optarg OPTARG, -o OPTARG This is optional Clear and unambiguous. With this approach the user does not have to bloat the help to state "This is required". We're having the same discussion over at github regarding argparse4j: https://github.com/tatsuhiro-t/argparse4j/issues/26#issuecomment-32894297 ---------- nosy: +Martin.d'Anjou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 17:01:21 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 21 Jan 2014 16:01:21 +0000 Subject: [issue20305] Android's incomplete locale.h implementation prevents cross-compilation In-Reply-To: <1390155202.76.0.360148898057.issue20305@psf.upfronthosting.co.za> Message-ID: <1390320081.32.0.236275801066.issue20305@psf.upfronthosting.co.za> Stefan Krah added the comment: "I've been looking into this, and the only option provided by the Android NDK involves cross-compiling Python on a regular machine. This would require some custom commands before and in between the builds, to build a host Python first, then cross-compile the Android Python, and then start the emulator, transfer the binaries there and run the tests over adb. Can buildbot provide functionality so this can be configured on-slave, or would it require setting up a seperate master?" I'm not sure. Antoine, do you think this is possible? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 17:10:16 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 21 Jan 2014 16:10:16 +0000 Subject: [issue20305] Android's incomplete locale.h implementation prevents cross-compilation In-Reply-To: <1390320081.32.0.236275801066.issue20305@psf.upfronthosting.co.za> Message-ID: <1390320612.2304.1.camel@fsol> Antoine Pitrou added the comment: > "I've been looking into this, and the only option provided by the > Android NDK involves cross-compiling Python on a regular machine. This > would require some custom commands before and in between the builds, > to build a host Python first, then cross-compile the Android Python, > and then start the emulator, transfer the binaries there and run the > tests over adb. Can buildbot provide functionality so this can be > configured on-slave, or would it require setting up a seperate > master?" The master can ask the slave to execute arbitrary commands. So, as long as you implement the necessary steps as well-known commands executable by the slave, you can then tell me how to insert them inside the build process. However, the only point of setting up an Android buildbot would be if: 1) Python actually builds correctly on Android 2) someone monitors the buildbot for failures and tries to act on them ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 17:12:02 2014 From: report at bugs.python.org (berdario) Date: Tue, 21 Jan 2014 16:12:02 +0000 Subject: [issue20321] ImportError when a module is created after a catched ImportError In-Reply-To: <1390276988.86.0.176640087742.issue20321@psf.upfronthosting.co.za> Message-ID: <1390320722.0.0.790274163044.issue20321@psf.upfronthosting.co.za> Changes by berdario : Removed file: http://bugs.python.org/file33582/bbug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 17:13:26 2014 From: report at bugs.python.org (Paul Moore) Date: Tue, 21 Jan 2014 16:13:26 +0000 Subject: [issue19643] shutil rmtree fails on readonly files in Windows In-Reply-To: <1384776671.66.0.696428447361.issue19643@psf.upfronthosting.co.za> Message-ID: <1390320806.71.0.519218710769.issue19643@psf.upfronthosting.co.za> Paul Moore added the comment: Looks like that works. At least in my case - I just did def del_rw(action, name, exc): os.chmod(name, stat.S_IWRITE) os.remove(name) shutil.rmtree(path, onerror=del_rw) Something more robust might check if name is a directory and os.rmdir that - I didn't need it for my case though. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 17:13:30 2014 From: report at bugs.python.org (berdario) Date: Tue, 21 Jan 2014 16:13:30 +0000 Subject: [issue20321] ImportError when a module is created after a catched ImportError In-Reply-To: <1390276988.86.0.176640087742.issue20321@psf.upfronthosting.co.za> Message-ID: <1390320810.34.0.633314384866.issue20321@psf.upfronthosting.co.za> berdario added the comment: yes, sorry... I tried to "simplify" and generalize it too much (I tried to avoid creating a new directory in the test, assuming that the same behavior could make sense by only creating a new module in the current directory) I'll reupload the correct version of the failing code, and I'll try to understand importlib.invalid_caches before eventually reopening it ---------- Added file: http://bugs.python.org/file33592/bbug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 17:17:55 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jan 2014 16:17:55 +0000 Subject: [issue20331] Fix various fd leaks Message-ID: <1390321074.97.0.506126100474.issue20331@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: The proposed patch fixes potential fd leaks in various modules. ---------- components: Library (Lib) files: fd_leaks.patch keywords: patch messages: 208664 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Fix various fd leaks type: behavior versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33593/fd_leaks.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 17:19:13 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 21 Jan 2014 16:19:13 +0000 Subject: [issue20324] gcc-4.2.4 support on python-3.3 (libmpdec) In-Reply-To: <1390292484.35.0.247229309669.issue20324@psf.upfronthosting.co.za> Message-ID: <1390321153.3.0.430272722932.issue20324@psf.upfronthosting.co.za> Stefan Krah added the comment: This is the gcc bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46861 I rather agree with this comment: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46861#c3 If a distro still maintains 4.2.x, the toolchain should be fixed (like FreeBSD apparently did). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 17:25:47 2014 From: report at bugs.python.org (berdario) Date: Tue, 21 Jan 2014 16:25:47 +0000 Subject: [issue20321] ImportError when a module is created after a catched ImportError In-Reply-To: <1390276988.86.0.176640087742.issue20321@psf.upfronthosting.co.za> Message-ID: <1390321547.05.0.11974346056.issue20321@psf.upfronthosting.co.za> berdario added the comment: Ok, the bug is unrelated with timings and the finder caches apparently ---------- resolution: invalid -> status: closed -> open versions: -3rd party, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 17:32:04 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 21 Jan 2014 16:32:04 +0000 Subject: [issue20332] Argument Clinic does not support the 'l' format Message-ID: <1390321924.51.0.108900260665.issue20332@psf.upfronthosting.co.za> New submission from Brett Cannon: 'l' is long for PyArg_ParseTuple(). ---------- assignee: larry components: Build messages: 208667 nosy: brett.cannon, larry priority: normal severity: normal status: open title: Argument Clinic does not support the 'l' format versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 17:36:23 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 21 Jan 2014 16:36:23 +0000 Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1390322183.69.0.271572714481.issue20152@psf.upfronthosting.co.za> Brett Cannon added the comment: Here is pyexpat converted. Couldn't do ErrorString as the 'l' format isn't supported; issue #20332. ---------- Added file: http://bugs.python.org/file33594/pyexpat_derby.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 17:44:48 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jan 2014 16:44:48 +0000 Subject: [issue19990] Add unittests for imghdr module In-Reply-To: <1387146470.57.0.419345603545.issue19990@psf.upfronthosting.co.za> Message-ID: <1390322688.18.0.294445065859.issue19990@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In general the patch LGTM, but additional tests can be added. Needed various tests for imghdr.what() arguments: * First argument is bytes, int or None. * First argument is a name of non-existent file. * First argument is text stream. * First argument is output stream. * First argument is closed stream. * First argument is non-seekable stream. * Second argument is bytearray. * Second argument is str. * Second argument is None. Try to insert test function which handles one of already supported format at the front of imghdr.test. ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka stage: -> patch review versions: +Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 17:46:08 2014 From: report at bugs.python.org (Martin d'Anjou) Date: Tue, 21 Jan 2014 16:46:08 +0000 Subject: [issue20333] argparse subparser usage message hides main parser usage Message-ID: <1390322768.82.0.0490461606421.issue20333@psf.upfronthosting.co.za> New submission from Martin d'Anjou: Consider the following code: #!/usr/bin/env python3 import argparse # create the top-level parser parser = argparse.ArgumentParser(prog='PROG') parser.add_argument('--file', help='A filename', required=True) subparsers = parser.add_subparsers(help='sub-command help') # create the parser for the "a" command parser_a = subparsers.add_parser('a', help='a help') parser_a.add_argument('bar', type=int, help='bar help') # create the parser for the "b" command parser_b = subparsers.add_parser('b', help='b help') parser_b.add_argument('--baz', choices='XYZ', help='baz help') The help for subparser a is obtained with: parser.parse_args(["a","--help"]) usage: PROG a [-h] bar positional arguments: bar bar help optional arguments: -h, --help show this help message and exit When the user follows the help, the user gets it wrong: parser.parse_args(["a","10"]) usage: PROG [-h] --file FILE {a,b} ... PROG: error: argument --file is required The correct way to use the subparser is: parser.parse_args(["--file","file","a","10"]) But the problem is that the original help message is not telling the user that this is the correct way. When asking for the "a" subparser help, the usage message should also reveal the main parser arguments. Continuing with the example, something like this should be appropriate: usage: PROG [-h] --file FILE a [-h] bar This is how the argparse Java port works. ---------- components: Library (Lib) messages: 208670 nosy: Martin.d'Anjou priority: normal severity: normal status: open title: argparse subparser usage message hides main parser usage type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 17:50:25 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 21 Jan 2014 16:50:25 +0000 Subject: [issue20334] make inspect Signature hashable Message-ID: <1390323024.99.0.45103178025.issue20334@psf.upfronthosting.co.za> New submission from Yury Selivanov: inspect.Signature and inspect.Parameter are immutable structures, and it makes sense to make them hashable too. Patch is attached. ---------- components: Library (Lib) files: hashable_signature_01.patch keywords: patch messages: 208671 nosy: brett.cannon, larry, ncoghlan, yselivanov priority: normal severity: normal status: open title: make inspect Signature hashable type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file33595/hashable_signature_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 17:53:25 2014 From: report at bugs.python.org (berdario) Date: Tue, 21 Jan 2014 16:53:25 +0000 Subject: [issue20321] ImportError when a module is created after a catched ImportError In-Reply-To: <1390276988.86.0.176640087742.issue20321@psf.upfronthosting.co.za> Message-ID: <1390323205.67.0.434136751263.issue20321@psf.upfronthosting.co.za> Changes by berdario : Added file: http://bugs.python.org/file33596/bug_with_invalidatecaches.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 17:57:25 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 21 Jan 2014 16:57:25 +0000 Subject: [issue20321] ImportError when a module is created after a catched ImportError In-Reply-To: <1390276988.86.0.176640087742.issue20321@psf.upfronthosting.co.za> Message-ID: <1390323445.16.0.852298569371.issue20321@psf.upfronthosting.co.za> Brett Cannon added the comment: It actually is a caching issue, but not with the caches in the finder but the cache *of* finders. Because you inserted LIBDIR before it existed, import noticed it didn't exist and so put None into sys.path_importer_cache[LIBDIR] (or imp.NullImporter prior to Python 3.3). If you del sys.path_importer_cache[LIBDIR] just before trying to import impfile then it works. If you leave the directory around but clear out its contents then importlib.invalidate_caches() would have been needed. As you have noticed, dynamically mucking around import is rather delicate. There are various caches and tricks used in order to speed it up since it is such a common operation. If you are trying to just load a single file that you dynamically wrote you can load the file directly using http://docs.python.org/3/library/importlib.html#importlib.machinery.SourceFileLoader (or if you need to support Python 2.7 as well, http://docs.python.org/2.7/library/imp.html#imp.load_module). Do let me know if you are trying to just load a single file. I'm contemplating adding a utility function to help with that use-case in importlib. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 17:59:10 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 21 Jan 2014 16:59:10 +0000 Subject: [issue20334] make inspect Signature hashable In-Reply-To: <1390323024.99.0.45103178025.issue20334@psf.upfronthosting.co.za> Message-ID: <1390323550.88.0.425018927885.issue20334@psf.upfronthosting.co.za> Brett Cannon added the comment: This is a new feature so it can't go into Python 3.4. ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 18:00:41 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 21 Jan 2014 17:00:41 +0000 Subject: [issue20334] make inspect Signature hashable In-Reply-To: <1390323024.99.0.45103178025.issue20334@psf.upfronthosting.co.za> Message-ID: <1390323641.63.0.943620337562.issue20334@psf.upfronthosting.co.za> Yury Selivanov added the comment: Fair enough. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 18:09:38 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jan 2014 17:09:38 +0000 Subject: [issue20329] zipfile.extractall fails in Posix shell with utf-8 filename In-Reply-To: <1390316753.93.0.767122614569.issue20329@psf.upfronthosting.co.za> Message-ID: <1390324178.41.0.703746828788.issue20329@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 18:14:26 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jan 2014 17:14:26 +0000 Subject: [issue20271] urllib.parse.urlparse() accepts wrong URLs In-Reply-To: <1389789129.93.0.775761654638.issue20271@psf.upfronthosting.co.za> Message-ID: <1390324466.48.0.836796351766.issue20271@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What should be correct behavior? Raise an exception, return '[::1]spam' as hostname, or left all as is? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 18:23:00 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 21 Jan 2014 17:23:00 +0000 Subject: [issue3073] Cookie.Morsel breaks in parsing cookie values with whitespace In-Reply-To: <1213092703.97.0.622811170151.issue3073@psf.upfronthosting.co.za> Message-ID: <1390324980.67.0.617864668064.issue3073@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 18:34:12 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 21 Jan 2014 17:34:12 +0000 Subject: [issue19870] Backport Cookie fix to 2.7 (httponly / secure flag) In-Reply-To: <1386055628.27.0.222770059818.issue19870@psf.upfronthosting.co.za> Message-ID: <1390325652.73.0.724121674465.issue19870@psf.upfronthosting.co.za> Berker Peksag added the comment: Here's a backport of issue 16611 for 2.7. ---------- keywords: +patch nosy: +berker.peksag stage: -> patch review versions: -Python 3.3 Added file: http://bugs.python.org/file33597/issue19870.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 18:38:33 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 21 Jan 2014 17:38:33 +0000 Subject: [issue20333] argparse subparser usage message hides main parser usage In-Reply-To: <1390322768.82.0.0490461606421.issue20333@psf.upfronthosting.co.za> Message-ID: <1390325913.12.0.506343984123.issue20333@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +bethard, paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 18:39:02 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 21 Jan 2014 17:39:02 +0000 Subject: [issue20324] gcc-4.2.4 support on python-3.3 (libmpdec) In-Reply-To: <1390292484.35.0.247229309669.issue20324@psf.upfronthosting.co.za> Message-ID: <1390325942.48.0.24752919488.issue20324@psf.upfronthosting.co.za> Georg Brandl added the comment: OK, thanks for the quick response. Relaxing to normal priority, please close as required. ---------- priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 18:53:22 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jan 2014 17:53:22 +0000 Subject: [issue19863] Missing function attributes in 2.7 docs. In-Reply-To: <1386010673.68.0.260580445507.issue19863@psf.upfronthosting.co.za> Message-ID: <1390326802.45.0.623342842592.issue19863@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM, but may be write Py3k compatible names at first place? ---------- stage: -> commit review type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 18:56:48 2014 From: report at bugs.python.org (Dirkjan Ochtman) Date: Tue, 21 Jan 2014 17:56:48 +0000 Subject: [issue20324] gcc-4.2.4 support on python-3.3 (libmpdec) In-Reply-To: <1390292484.35.0.247229309669.issue20324@psf.upfronthosting.co.za> Message-ID: <1390327008.04.0.676845410354.issue20324@psf.upfronthosting.co.za> Dirkjan Ochtman added the comment: Given this, WONTFIXing this seems reasonable to me, FWIW. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 19:04:10 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 21 Jan 2014 18:04:10 +0000 Subject: [issue20324] gcc-4.2.4 support on python-3.3 (libmpdec) In-Reply-To: <1390292484.35.0.247229309669.issue20324@psf.upfronthosting.co.za> Message-ID: <1390327450.14.0.819949479079.issue20324@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 19:08:29 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 21 Jan 2014 18:08:29 +0000 Subject: [issue20323] Argument Clinic: docstring_prototype output causes build failure on Windows In-Reply-To: <1390284343.93.0.69163024688.issue20323@psf.upfronthosting.co.za> Message-ID: <1390327709.54.0.923265073295.issue20323@psf.upfronthosting.co.za> Zachary Ware added the comment: Larry Hastings wrote: > Does your proposed solution work properly when docstrings are turned > off? Try undefining WITH_DOC_STRINGS. I bet you need to make the > size 1 in that case. For certain values of "properly", yes. It builds with no warnings or errors on Windows, but I don't know how it does on memory usage. It's easy enough to define PyDoc_VAR_WITH_SIZE alongside PyDoc_STR and use '1' instead of 'size' when WITH_DOC_STRINGS is undefined, though. > Also, the length must be len(f.docstring) + 1, to account for the > trailing \0. I thought so as well, but testing both ways showed no difference. To provoke a difference, I defined length as len(f.docstring) - 1, which threw a compiler warning about an overflow. Adding 1 is probably safer, though. > Also, error C2133 doesn't look like it's applicable. On line 71 it's > not being stored in a structure. Dumb MSVC. I can't argue that one :) > Also PyDoc_SIZEDVAR is a bad name. PyDoc_SIZED_VAR would be an > improvement, but I think PyDoc_VAR_WITH_SIZE is the name you want >there. Fair enough. > And, I'm still not a +1 on this approach. Can you propose something > else? I gave the 4 alternatives I could think of; I'll keep thinking and throw out anything else I come up with. > Finally, I will note that the "buffer" preset would work just fine in > this file, if you dumped the buffer just above the PyMethodDef array. Indeed; winsound is just a convenient testbed since it's such a small module, but the problem will affect any module that can really benefit from the two-pass output system. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 19:21:53 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jan 2014 18:21:53 +0000 Subject: [issue20024] Py_BuildValue() can call Python code with an exception set In-Reply-To: <1387451611.0.0.792673049242.issue20024@psf.upfronthosting.co.za> Message-ID: <1390328513.11.0.426621597362.issue20024@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. I have searched the sources and have not found any use of Py_BuildValue() which can be used for test. Py_BuildValue() can fail only due to memory error. It can also can fail with non-UTF8 string, but all uses of Py_BuildValue() with a string in a tuple proceeds only ASCII strings. ---------- stage: test needed -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 19:22:40 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jan 2014 18:22:40 +0000 Subject: [issue19863] Missing function attributes in 2.7 docs. In-Reply-To: <1386010673.68.0.260580445507.issue19863@psf.upfronthosting.co.za> Message-ID: <1390328560.36.0.182954784352.issue19863@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: docs at python -> mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 19:33:27 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 21 Jan 2014 18:33:27 +0000 Subject: [issue20326] Argument Clinic should use a non-error-prone syntax to mark text signatures In-Reply-To: <1390298749.1.0.12762219489.issue20326@psf.upfronthosting.co.za> Message-ID: <20140121183327.GA27187@sleipnir.bytereef.org> Stefan Krah added the comment: Larry Hastings wrote: > I think we should change the syntax to something people would > never write by accident. Here are some suggestions: > > "*(" > "*clinic*(" > "\01 clinic(" I like the original "def (...)\n" approach from #19674. If that is not possible for some reason, "*(" is fine, too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 19:46:07 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jan 2014 18:46:07 +0000 Subject: [issue20075] help(open) eats first line In-Reply-To: <1388090120.87.0.478863756961.issue20075@psf.upfronthosting.co.za> Message-ID: <1390329967.77.0.862979708548.issue20075@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 19:52:31 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 21 Jan 2014 18:52:31 +0000 Subject: [issue20075] help(open) eats first line In-Reply-To: <1388090120.87.0.478863756961.issue20075@psf.upfronthosting.co.za> Message-ID: <1390330351.23.0.709841087507.issue20075@psf.upfronthosting.co.za> Stefan Krah added the comment: See also #20326. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 19:57:34 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jan 2014 18:57:34 +0000 Subject: [issue20326] Argument Clinic should use a non-error-prone syntax to mark text signatures In-Reply-To: <1390298749.1.0.12762219489.issue20326@psf.upfronthosting.co.za> Message-ID: <1390330654.94.0.746067029557.issue20326@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What if the __text_signature__ and __doc__ getter will call ast.parse() (actually compile()) on signature candidate? If it fails, then builtin has no signature, the __text_signature__ getter returns '', and the __doc__ getter returns all original docstring. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 20:15:55 2014 From: report at bugs.python.org (Tal Einat) Date: Tue, 21 Jan 2014 19:15:55 +0000 Subject: [issue20187] The Great Argument Clinic Conversion Derby Meta-Issue In-Reply-To: <1389141105.5.0.459903580868.issue20187@psf.upfronthosting.co.za> Message-ID: <1390331755.86.0.781827672827.issue20187@psf.upfronthosting.co.za> Tal Einat added the comment: I've been working on converting unicode, bytes and bytearray, but their files are separated into Derby groups #10, #11 and #12. Could we create a new issue and move the relevant files to it? The files I'd like to move: >From Derby #10 (issue20179): Objects/bytes_methods.c Objects/bytesobject.c >From Derby #11 (issue20180): Objects/unicodeobject.c Objects/stringlib/find.h Objects/stringlib/transmogrify.h >From Derby #12 (issue 20181): Objects/bytearrayobject.c: 13 sites ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 20:20:44 2014 From: report at bugs.python.org (Tal Einat) Date: Tue, 21 Jan 2014 19:20:44 +0000 Subject: [issue20187] The Great Argument Clinic Conversion Derby Meta-Issue In-Reply-To: <1389141105.5.0.459903580868.issue20187@psf.upfronthosting.co.za> Message-ID: <1390332044.45.0.528549864905.issue20187@psf.upfronthosting.co.za> Tal Einat added the comment: Never mind my previous comment; I realize it would create to much of a mess. Sorry for the noise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 20:23:25 2014 From: report at bugs.python.org (Tal Einat) Date: Tue, 21 Jan 2014 19:23:25 +0000 Subject: [issue20181] Derby #12: Convert 50 sites to Argument Clinic across 4 files In-Reply-To: <1389140203.53.0.198441160626.issue20181@psf.upfronthosting.co.za> Message-ID: <1390332205.4.0.953679946699.issue20181@psf.upfronthosting.co.za> Tal Einat added the comment: While converting Objects/stringlib/transmogrify.h as part of issue20180 (Derby #11), some changes to Objects/bytesobject.c and Objects/bytearrayobject.c were required. Those changes are included in the relevant patch attached to that issue. ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 20:23:41 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jan 2014 19:23:41 +0000 Subject: [issue20283] Wrong keyword parameter name in regex pattern methods In-Reply-To: <1389905067.44.0.489524795145.issue20283@psf.upfronthosting.co.za> Message-ID: <1390332221.15.0.613615323471.issue20283@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Actually, several other methods also have wrong parameter name, "source" instead of "string". ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file33598/sre_pattern_string_keyword.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 20:24:08 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jan 2014 19:24:08 +0000 Subject: [issue20283] Wrong keyword parameter name in regex pattern methods In-Reply-To: <1389905067.44.0.489524795145.issue20283@psf.upfronthosting.co.za> Message-ID: <1390332248.88.0.424450464872.issue20283@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file33509/sre_pattern_string_keyword.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 20:24:51 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jan 2014 19:24:51 +0000 Subject: [issue20283] Wrong keyword parameter name in regex pattern methods In-Reply-To: <1389905067.44.0.489524795145.issue20283@psf.upfronthosting.co.za> Message-ID: <1390332291.81.0.978617209524.issue20283@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +mrabarnett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 20:50:24 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 Jan 2014 19:50:24 +0000 Subject: [issue20301] Correct docs for default access argument for DeleteKeyEx In-Reply-To: <1390118763.24.0.151649669148.issue20301@psf.upfronthosting.co.za> Message-ID: <3f80hv1w5yz7Ljk@mail.python.org> Roundup Robot added the comment: New changeset da35a4e724e5 by Zachary Ware in branch '3.3': Issue #20301: Mention the correct KEY_* value as the default http://hg.python.org/cpython/rev/da35a4e724e5 New changeset 3baee069c5ff by Zachary Ware in branch 'default': Issue #20301: Merge with 3.3 http://hg.python.org/cpython/rev/3baee069c5ff ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 20:51:05 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 21 Jan 2014 19:51:05 +0000 Subject: [issue20301] Correct docs for default access argument for DeleteKeyEx In-Reply-To: <1390118763.24.0.151649669148.issue20301@psf.upfronthosting.co.za> Message-ID: <1390333865.41.0.88757984543.issue20301@psf.upfronthosting.co.za> Zachary Ware added the comment: Fixed, thanks for the report! ---------- assignee: docs at python -> zach.ware resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 20:53:57 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 21 Jan 2014 19:53:57 +0000 Subject: [issue20024] Py_BuildValue() can call Python code with an exception set In-Reply-To: <1387451611.0.0.792673049242.issue20024@psf.upfronthosting.co.za> Message-ID: <1390334037.16.0.874554344559.issue20024@psf.upfronthosting.co.za> STINNER Victor added the comment: parsermodule.patch was applied as 91cb83f895cf (Python 3.3) and cd952e92c180 (3.4). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 20:55:50 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 Jan 2014 19:55:50 +0000 Subject: [issue20024] Py_BuildValue() can call Python code with an exception set In-Reply-To: <1387451611.0.0.792673049242.issue20024@psf.upfronthosting.co.za> Message-ID: <3f80q91573z7Lm6@mail.python.org> Roundup Robot added the comment: New changeset 29b4eb47f65e by Victor Stinner in branch 'default': Issue #20024: Py_BuildValue() now saves/restores the current exception before http://hg.python.org/cpython/rev/29b4eb47f65e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 20:56:08 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jan 2014 19:56:08 +0000 Subject: [issue19936] Executable permissions of Python source files In-Reply-To: <1386588201.39.0.841678145847.issue19936@psf.upfronthosting.co.za> Message-ID: <1390334168.28.0.260527951149.issue19936@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Gregory, is it intentional that Modules/_ctypes/libffi/build-ios.sh, Modules/_ctypes/libffi/libtool-ldflags, Modules/_ctypes/libffi/msvcc.sh and Modules/_ctypes/libffi/src/arm/gentramp.sh have no executable bits? They all have executable bits in mainstream libffi-3.0.13 distribution. ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 20:56:19 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 21 Jan 2014 19:56:19 +0000 Subject: [issue20024] Py_BuildValue() can call Python code with an exception set In-Reply-To: <1387451611.0.0.792673049242.issue20024@psf.upfronthosting.co.za> Message-ID: <1390334179.59.0.555928175788.issue20024@psf.upfronthosting.co.za> STINNER Victor added the comment: Thanks for the review Serhiy. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 21:01:05 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 Jan 2014 20:01:05 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <3f80xD3st2z7Ljk@mail.python.org> Roundup Robot added the comment: New changeset 7ce7295393c2 by Victor Stinner in branch 'default': Issue #20311: EpollSelector now also rounds the timeout towards zero, as http://hg.python.org/cpython/rev/7ce7295393c2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 21:30:33 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 Jan 2014 20:30:33 +0000 Subject: [issue2382] [Py3k] SyntaxError cursor shifted if multibyte character is in line. In-Reply-To: <1205817752.04.0.892564898323.issue2382@psf.upfronthosting.co.za> Message-ID: <3f81bD2xBgz7Ljk@mail.python.org> Roundup Robot added the comment: New changeset eb7565c212f1 by Serhiy Storchaka in branch '3.3': Issue #2382: SyntaxError cursor "^" now is written at correct position in most http://hg.python.org/cpython/rev/eb7565c212f1 New changeset ea34b2b0b8ae by Serhiy Storchaka in branch 'default': Issue #2382: SyntaxError cursor "^" now is written at correct position in most http://hg.python.org/cpython/rev/ea34b2b0b8ae ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 21:30:44 2014 From: report at bugs.python.org (Tal Einat) Date: Tue, 21 Jan 2014 20:30:44 +0000 Subject: [issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4 files In-Reply-To: <1389140120.63.0.492860390436.issue20179@psf.upfronthosting.co.za> Message-ID: <1390336244.83.0.454787963605.issue20179@psf.upfronthosting.co.za> Tal Einat added the comment: Attached patch for AC conversion of Objects/bytesobject.c and Objects/bytearrayobject.c. This is one patch because there are changes that must be done in bytes_methods.h and bytes_methods.c that affect both of bytesobject.c and bytearrayobject.c. Those changes are in this patch as well. All methods were converted except for two groups: 1) the various find methods which use the common argument parsing function 'stringlib_parse_args_finds_byte' 2) 'new' and 'init' methods Also note that both of these classes use some common function implementations found under 'stringlib'. However, since that code is in separate files, I'll upload the conversion patches to the relevant issue (and write an appropriate comment here). ---------- keywords: +patch Added file: http://bugs.python.org/file33599/bytes_and_bytearray.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 21:30:46 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 21 Jan 2014 20:30:46 +0000 Subject: [issue20227] Argument Clinic: rename arguments in generated C? In-Reply-To: <1389524736.75.0.620647933805.issue20227@psf.upfronthosting.co.za> Message-ID: <1390336246.0.0.637229329295.issue20227@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 21:30:57 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 21 Jan 2014 20:30:57 +0000 Subject: [issue20327] Argument Clinic: setting internal variable names for parsed arguments In-Reply-To: <1390303694.96.0.387244097814.issue20327@psf.upfronthosting.co.za> Message-ID: <1390336257.54.0.946251923488.issue20327@psf.upfronthosting.co.za> Zachary Ware added the comment: This is a duplicate of issue20227; I'm adding you to the nosy of that one, Tal. ---------- nosy: +zach.ware resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> Argument Clinic: rename arguments in generated C? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 21:31:40 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jan 2014 20:31:40 +0000 Subject: [issue2382] [Py3k] SyntaxError cursor shifted if multibyte character is in line. In-Reply-To: <1205817752.04.0.892564898323.issue2382@psf.upfronthosting.co.za> Message-ID: <1390336300.39.0.547681212799.issue2382@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: serhiy.storchaka -> stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 21:32:16 2014 From: report at bugs.python.org (Tal Einat) Date: Tue, 21 Jan 2014 20:32:16 +0000 Subject: [issue20181] Derby #12: Convert 50 sites to Argument Clinic across 4 files In-Reply-To: <1389140203.53.0.198441160626.issue20181@psf.upfronthosting.co.za> Message-ID: <1390336336.57.0.382442855764.issue20181@psf.upfronthosting.co.za> Tal Einat added the comment: See nearly complete conversion of Objects/bytearrayobject.c in patch attached to issue20179. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 21:34:58 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jan 2014 20:34:58 +0000 Subject: [issue8260] When I use codecs.open(...) and f.readline() follow up by f.read() return bad result In-Reply-To: <1269875395.81.0.132261115225.issue8260@psf.upfronthosting.co.za> Message-ID: <1390336498.87.0.416302101817.issue8260@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 21:37:36 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 Jan 2014 20:37:36 +0000 Subject: [issue16630] IDLE: Calltip fails if __getattr__ raises exception In-Reply-To: <1354844775.58.0.855877358898.issue16630@psf.upfronthosting.co.za> Message-ID: <3f81lN099Dz7Lk1@mail.python.org> Roundup Robot added the comment: New changeset d55d1cbf5f9a by Terry Jan Reedy in branch '2.7': Issue #16630: Make Idle calltips work even when __getattr__ raises. http://hg.python.org/cpython/rev/d55d1cbf5f9a New changeset 2fe0b2dcc98c by Terry Jan Reedy in branch '3.3': Issue #16630: Make Idle calltips work even when __getattr__ raises. http://hg.python.org/cpython/rev/2fe0b2dcc98c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 21:41:38 2014 From: report at bugs.python.org (Tal Einat) Date: Tue, 21 Jan 2014 20:41:38 +0000 Subject: [issue20227] Argument Clinic: rename arguments in generated C? In-Reply-To: <1389524736.75.0.620647933805.issue20227@psf.upfronthosting.co.za> Message-ID: <1390336898.41.0.848046308793.issue20227@psf.upfronthosting.co.za> Tal Einat added the comment: +1 for this. It would save a bit of manual conversion work, and would significantly reduce the size and complexity of the resulting patches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 21:48:10 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 21 Jan 2014 20:48:10 +0000 Subject: [issue16630] IDLE: Calltip fails if __getattr__ raises exception In-Reply-To: <1354844775.58.0.855877358898.issue16630@psf.upfronthosting.co.za> Message-ID: <1390337290.84.0.621001426808.issue16630@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I added test_attribute_exception with two subtests for each of two nasty classes. The resulting failures were fixed in CallTips.py by replacing all ob.__call__ references with one reference inside try_except that saved the method for possible later use. ---------- assignee: serhiy.storchaka -> terry.reedy resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 21:59:50 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 21 Jan 2014 20:59:50 +0000 Subject: [issue20323] Argument Clinic: docstring_prototype output causes build failure on Windows In-Reply-To: <1390284343.93.0.69163024688.issue20323@psf.upfronthosting.co.za> Message-ID: <1390337989.99.0.559630502369.issue20323@psf.upfronthosting.co.za> Larry Hastings added the comment: If in C you define static char a[5] = "abcde" C suppresses the trailing '\0'. That it continued to work okay was a lucky break--you must not have looked in many docstrings, or you lucked out and they happened to be padded with zeroes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 22:01:46 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 21 Jan 2014 21:01:46 +0000 Subject: [issue7883] CallTips.py _find_constructor does not work In-Reply-To: <1265631103.87.0.399117397925.issue7883@psf.upfronthosting.co.za> Message-ID: <1390338106.92.0.172330015823.issue7883@psf.upfronthosting.co.za> Terry J. Reedy added the comment: THanks for reporting this. #12520 tripled the number of tests in CallTips.py and #20122 moved them to test_calltips.py. I think they cover this case and the tests proposed. #16630 added a few more tests and patched CallTips.py to make them pass. If you find any other cases that fail with the current bugfix releases, report them on a new issue. ---------- assignee: -> terry.reedy resolution: fixed -> out of date stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 22:08:02 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 21 Jan 2014 21:08:02 +0000 Subject: [issue20323] Argument Clinic: docstring_prototype output causes build failure on Windows In-Reply-To: <1390284343.93.0.69163024688.issue20323@psf.upfronthosting.co.za> Message-ID: <1390338482.84.0.559478122768.issue20323@psf.upfronthosting.co.za> Larry Hastings added the comment: I had to throw it in a struct to prevent gcc from rearranging the variables. But this demonstrates the problem--when it prints the string, it doesn't stop at the end. ----- #include typedef struct { int a; char b[8]; int c; } abc_t; int main(int argc, char *argv[]) { abc_t abc = {-1, "abcdefgh", -1}; printf("abc %i%s%i\n", abc.a, abc.b, abc.c); return 0; } ----- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 22:23:20 2014 From: report at bugs.python.org (Glenn Langford) Date: Tue, 21 Jan 2014 21:23:20 +0000 Subject: [issue20297] concurrent.futures.as_completed() installs waiters for already completed Futures In-Reply-To: <1390079975.89.0.167689725202.issue20297@psf.upfronthosting.co.za> Message-ID: <1390339400.64.0.334077309094.issue20297@psf.upfronthosting.co.za> Changes by Glenn Langford : ---------- nosy: +bquinlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 22:24:11 2014 From: report at bugs.python.org (Glenn Langford) Date: Tue, 21 Jan 2014 21:24:11 +0000 Subject: [issue20319] concurrent.futures.wait() can block forever even if Futures have completed In-Reply-To: <1390263519.32.0.357208079457.issue20319@psf.upfronthosting.co.za> Message-ID: <1390339451.93.0.843807771581.issue20319@psf.upfronthosting.co.za> Changes by Glenn Langford : ---------- nosy: +bquinlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 22:32:26 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Jan 2014 21:32:26 +0000 Subject: [issue19920] TarFile.list() fails on some files In-Reply-To: <1386437860.38.0.0478693655005.issue19920@psf.upfronthosting.co.za> Message-ID: <1390339946.79.0.981094063264.issue19920@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 22:45:37 2014 From: report at bugs.python.org (Renaud Blanch) Date: Tue, 21 Jan 2014 21:45:37 +0000 Subject: [issue20335] bytes constructor accepts more than one argument even of the first one is not a string Message-ID: <1390340737.95.0.677221459573.issue20335@psf.upfronthosting.co.za> New submission from Renaud Blanch: % python3 Python 3.3.2 (v3.3.2:d047928ae3f6, May 13 2013, 13:52:24) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> help(bytes) bytes constructor accepts more than one argument even of the first one is not a string (and then the other arguments are checked to be strings): >>> bytes(2, "foo", "bar") b'\x00\x00' >>> bytes(2, "foo") b'\x00\x00' but: >>> bytes(2, 1) Traceback (most recent call last): File "", line 1, in TypeError: bytes() argument 2 must be str, not int ---------- components: Interpreter Core messages: 208707 nosy: rndblnch priority: normal severity: normal status: open title: bytes constructor accepts more than one argument even of the first one is not a string versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 22:49:45 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 21 Jan 2014 21:49:45 +0000 Subject: [issue20326] Argument Clinic should use a non-error-prone syntax to mark text signatures In-Reply-To: <1390298749.1.0.12762219489.issue20326@psf.upfronthosting.co.za> Message-ID: <1390340985.38.0.657863843683.issue20326@psf.upfronthosting.co.za> Larry Hastings added the comment: Serhiy: I'm going to add PEP 457 features to the text signature, because without them the inspect.Signature objects will be wrong. So __doc__ and __text_signature__ would have to remove those first before handing the string to ast.parse. I wasn't seriously proposing that __doc__ and __text_signature__ parse the string. That would obviously be a waste of CPU. I was simply taking the argument to its logical extreme. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 22:50:09 2014 From: report at bugs.python.org (Florent Xicluna) Date: Tue, 21 Jan 2014 21:50:09 +0000 Subject: [issue20280] add "predicate" to the glossary In-Reply-To: <1389878750.92.0.454847187289.issue20280@psf.upfronthosting.co.za> Message-ID: <1390341009.35.0.566166411089.issue20280@psf.upfronthosting.co.za> Florent Xicluna added the comment: Then we can forget it. Thank you for your input. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 23:04:02 2014 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 21 Jan 2014 22:04:02 +0000 Subject: [issue20335] bytes constructor accepts more than one argument even of the first one is not a string In-Reply-To: <1390340737.95.0.677221459573.issue20335@psf.upfronthosting.co.za> Message-ID: <1390341842.09.0.782181045024.issue20335@psf.upfronthosting.co.za> Mark Lawrence added the comment: This shows the report to be wrong, you either have to pass an iterable of ints or a single int. Even the title is wrong, it doesn't accept more than one argument if the first one isn't a string, it raises a TypeError. Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:18:40) [MSC v.1600 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> help(bytes) Help on class bytes in module builtins: class bytes(object) | bytes(iterable_of_ints) -> bytes | bytes(string, encoding[, errors]) -> bytes | bytes(bytes_or_buffer) -> immutable copy of bytes_or_buffer | bytes(int) -> bytes object of size given by the parameter initialized with null bytes | bytes() -> empty bytes object ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 23:07:02 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 Jan 2014 22:07:02 +0000 Subject: [issue20246] buffer overflow in socket.recvfrom_into In-Reply-To: <1389660239.25.0.341393063834.issue20246@psf.upfronthosting.co.za> Message-ID: <3f83kY2VRjz7Lm1@mail.python.org> Roundup Robot added the comment: New changeset 5c4f4db8107c by Stefan Krah in branch '3.3': Issue #20246: Fix test failures on FreeBSD. Patch by Ryan Smith-Roberts. http://hg.python.org/cpython/rev/5c4f4db8107c New changeset 9bbc3cc8ff4c by Stefan Krah in branch 'default': Issue #20246: Fix test failures on FreeBSD. Patch by Ryan Smith-Roberts. http://hg.python.org/cpython/rev/9bbc3cc8ff4c New changeset b6c5a37b221f by Stefan Krah in branch '2.7': Issue #20246: Fix test failures on FreeBSD. Patch by Ryan Smith-Roberts. http://hg.python.org/cpython/rev/b6c5a37b221f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 23:11:36 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 21 Jan 2014 22:11:36 +0000 Subject: [issue20246] buffer overflow in socket.recvfrom_into In-Reply-To: <1390250816.14.0.119302266238.issue20246@psf.upfronthosting.co.za> Message-ID: <20140121221136.GA3957@sleipnir.bytereef.org> Stefan Krah added the comment: Thanks Ryan. As you say, the original segfault is also triggered with the shortened message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 23:13:04 2014 From: report at bugs.python.org (Renaud Blanch) Date: Tue, 21 Jan 2014 22:13:04 +0000 Subject: [issue20335] bytes constructor accepts more than one argument even of the first one is not a string In-Reply-To: <1390340737.95.0.677221459573.issue20335@psf.upfronthosting.co.za> Message-ID: <1390342384.07.0.286455978782.issue20335@psf.upfronthosting.co.za> Changes by Renaud Blanch : ---------- keywords: +patch Added file: http://bugs.python.org/file33600/bytesobject.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 23:15:28 2014 From: report at bugs.python.org (Renaud Blanch) Date: Tue, 21 Jan 2014 22:15:28 +0000 Subject: [issue20335] bytes constructor accepts more than one argument even if the first one is not a string In-Reply-To: <1390340737.95.0.677221459573.issue20335@psf.upfronthosting.co.za> Message-ID: <1390342528.9.0.518277055495.issue20335@psf.upfronthosting.co.za> Changes by Renaud Blanch : ---------- title: bytes constructor accepts more than one argument even of the first one is not a string -> bytes constructor accepts more than one argument even if the first one is not a string _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 23:17:12 2014 From: report at bugs.python.org (Tal Einat) Date: Tue, 21 Jan 2014 22:17:12 +0000 Subject: [issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4 files In-Reply-To: <1389140120.63.0.492860390436.issue20179@psf.upfronthosting.co.za> Message-ID: <1390342632.59.0.373892177308.issue20179@psf.upfronthosting.co.za> Tal Einat added the comment: Attached updated patch for bytes and bytearray. In the previous patch I missed the 'clear' and 'copy' bytearray methods. This patch is a replacement for the previous one, with the additional conversion of these two methods. ---------- Added file: http://bugs.python.org/file33601/bytes_and_bytearray_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 23:29:51 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 21 Jan 2014 22:29:51 +0000 Subject: [issue20336] test_asyncio: relax timings even more Message-ID: <1390343391.65.0.626852689754.issue20336@psf.upfronthosting.co.za> New submission from Stefan Krah: It seems that the relaxed timings in some tests are still not sufficient: http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/7417/steps/test/logs/stdio ====================================================================== FAIL: test_time_and_call_at (test.test_asyncio.test_base_events.BaseEventLoopTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_asyncio/test_base_events.py", line 127, in test_time_and_call_at self.assertTrue(0.09 <= t1-t0 <= 0.9, t1-t0) AssertionError: False is not true : 2.06036564335227 ---------- components: Tests keywords: buildbot messages: 208714 nosy: gvanrossum, skrah priority: normal severity: normal stage: needs patch status: open title: test_asyncio: relax timings even more type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 23:36:53 2014 From: report at bugs.python.org (KV) Date: Tue, 21 Jan 2014 22:36:53 +0000 Subject: [issue20337] bdist_rpm should support %config(noreplace) Message-ID: <1390343812.97.0.521102464448.issue20337@psf.upfronthosting.co.za> New submission from KV: bdist_rpm should support handling %config(noreplace) to help with packaging. Patch attached. ---------- components: Build files: bdist_rpm-add-config-file.diff keywords: patch messages: 208715 nosy: kv priority: normal severity: normal status: open title: bdist_rpm should support %config(noreplace) versions: Python 2.7 Added file: http://bugs.python.org/file33602/bdist_rpm-add-config-file.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 21 23:41:42 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 21 Jan 2014 22:41:42 +0000 Subject: [issue20338] Idle: increase max calltip width Message-ID: <1390344102.42.0.241411598779.issue20338@psf.upfronthosting.co.za> New submission from Terry J. Reedy: Idle calltips are currently limited to 75 (signature) or 70 (doc line) chars. This is insufficient for some stdlib signatures. Example: >>> from http.client import HTTPConnection >>> import inspect >>> fob=HTTPConnection.__init__ >>> line=inspect.formatargspec(*inspect.getfullargspec(fob)) >>> line, len(line) ('(self, host, port=None, strict=, timeout=, source_address=None)', 121) The truncated tip displayed is "(self, host, port=None, strict=, timeout= _______________________________________ From report at bugs.python.org Tue Jan 21 23:46:53 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 21 Jan 2014 22:46:53 +0000 Subject: [issue20338] Idle: increase max calltip width In-Reply-To: <1390344102.42.0.241411598779.issue20338@psf.upfronthosting.co.za> Message-ID: <1390344413.28.0.272874185364.issue20338@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Meant to mention that wrapping is a possible alternative to truncation, although a limit of say, 200, would make either alternative rare. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 00:23:18 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 21 Jan 2014 23:23:18 +0000 Subject: [issue20338] Idle: increase max calltip width In-Reply-To: <1390344102.42.0.241411598779.issue20338@psf.upfronthosting.co.za> Message-ID: <1390346598.1.0.326491536195.issue20338@psf.upfronthosting.co.za> Terry J. Reedy added the comment: On further thought, I think the best place to truncate lines is in get_argspec, after being split from the docstring and before rejoined. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 00:27:13 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 21 Jan 2014 23:27:13 +0000 Subject: [issue16638] support multi-line docstring signatures in IDLE calltips In-Reply-To: <1354909776.12.0.96265352257.issue16638@psf.upfronthosting.co.za> Message-ID: <1390346833.35.0.0271880393885.issue16638@psf.upfronthosting.co.za> Terry J. Reedy added the comment: See #20338 for why I think 70 (or even 79, the limit in CallTipWindow) is too low a limit. The purpose of grabbing multiple lines is to get the signature lines of builtins. I believe the max number of lines needed is 5, for bytes. however, identifying likely builtins by the absence of a signature from inspect, which works now, will not work when Clinic and inspect start giving us such. Even when if Clinic produces a signature string for bytes, it will probably be opaque and the doc lines would still be helpful. So I think we can try up to 5 lines from the docstring for any object. I am working on a revision of the patch. ---------- assignee: serhiy.storchaka -> terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 00:29:16 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 21 Jan 2014 23:29:16 +0000 Subject: [issue18147] SSL: diagnostic functions to list loaded CA certs In-Reply-To: <1370513969.26.0.776855011912.issue18147@psf.upfronthosting.co.za> Message-ID: <1390346956.29.0.982461118098.issue18147@psf.upfronthosting.co.za> R. David Murray added the comment: It looks like the doc for get_ca_certs wasn't missing, so now it appears twice in the docs. I'm not sure which is the preferred wording, so I'll leave it to Christian to fix it. ---------- nosy: +r.david.murray status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 00:30:03 2014 From: report at bugs.python.org (Nikolay Bogoychev) Date: Tue, 21 Jan 2014 23:30:03 +0000 Subject: [issue16099] robotparser doesn't support request rate and crawl delay parameters In-Reply-To: <1349096305.17.0.983395980337.issue16099@psf.upfronthosting.co.za> Message-ID: <1390347003.33.0.784085068793.issue16099@psf.upfronthosting.co.za> Nikolay Bogoychev added the comment: Hey, Just a reminder friendly reminder that there hasn't been any activity for a month and I have released a v2, pending for review (: ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 01:12:07 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 Jan 2014 00:12:07 +0000 Subject: [issue17825] Indentation.offset and SyntaxError.offset mismatch In-Reply-To: <1366789582.23.0.0218552351895.issue17825@psf.upfronthosting.co.za> Message-ID: <3f86Vt3sgfz7LpR@mail.python.org> Roundup Robot added the comment: New changeset 6d1372237607 by Florent Xicluna in branch '3.3': Issue #17825: Cursor ^ is correctly positioned for SyntaxError and IndentationError. http://hg.python.org/cpython/rev/6d1372237607 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 01:17:10 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 Jan 2014 00:17:10 +0000 Subject: [issue17825] Indentation.offset and SyntaxError.offset mismatch In-Reply-To: <1366789582.23.0.0218552351895.issue17825@psf.upfronthosting.co.za> Message-ID: <3f86cj2TBgz7LjR@mail.python.org> Roundup Robot added the comment: New changeset aeb204b8f6c4 by Florent Xicluna in branch 'default': Issue #17825: Cursor ^ is correctly positioned for SyntaxError and IndentationError. http://hg.python.org/cpython/rev/aeb204b8f6c4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 01:19:26 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 22 Jan 2014 00:19:26 +0000 Subject: [issue19936] Executable permissions of Python source files In-Reply-To: <1386588201.39.0.841678145847.issue19936@psf.upfronthosting.co.za> Message-ID: <1390349966.71.0.0423485421567.issue19936@psf.upfronthosting.co.za> Gregory P. Smith added the comment: For those four libffi files in msg208964, do what you want with them. I ignored executable bits entirely (didn't set or unset) when importing the code as there is zero need to execute any of them. IMNSHO, I think executable bits should _not_ be set on most files in the Python source tree. *Especially* not on things under Lib and Lib/test/. Afterall, any #! on those is *guaranteed* to not refer to the Python interpreter the source tree represents. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 01:34:13 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 Jan 2014 00:34:13 +0000 Subject: [issue17825] Indentation.offset and SyntaxError.offset mismatch In-Reply-To: <1366789582.23.0.0218552351895.issue17825@psf.upfronthosting.co.za> Message-ID: <3f870N70YNz7LjR@mail.python.org> Roundup Robot added the comment: New changeset 0041be34edbf by Florent Xicluna in branch '2.7': Issue #17825: Cursor ^ is correctly positioned for SyntaxError and IndentationError. http://hg.python.org/cpython/rev/0041be34edbf ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 01:40:29 2014 From: report at bugs.python.org (Neil Schemenauer) Date: Wed, 22 Jan 2014 00:40:29 +0000 Subject: [issue20339] Make bytes() use tp_as_buffer for cmp Message-ID: <1390351229.22.0.995411790956.issue20339@psf.upfronthosting.co.za> New submission from Neil Schemenauer: While poking around at bytes() related things, I noticed that the tp_richcompare method for bytes does not use the tp_as_buffer interface. Making it use it is quite easy, probably even makes the code simpler and faster. However, using it would mean that you could compare by bytes() and bytearray() to any object that implemented tp_as_buffer. I'm not sure about the whole implications of that. I tried changing it and found that a test failed for memoryview. The unit test expects TypeError from memoryview if you try to order them, e.g. >>> memoryview(b'a') < b'b' ... TypeError: unorderable types: memoryview() > bytes() >>> memoryview(b'a') < memoryview(b'b') ... TypeError: unorderable types: memoryview() > memoryview() That's inconsistent though, since bytearray does use tp_as_buffer: >>> memoryview(b'a') < bytearray(b'b') True I think we should make bytes() use tp_as_buffer. Attached is a patch that implements the idea. Needs some thought and review yet. ---------- files: cmp_buffer.patch keywords: patch messages: 208726 nosy: nascheme priority: low severity: normal stage: patch review status: open title: Make bytes() use tp_as_buffer for cmp type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file33603/cmp_buffer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 02:01:41 2014 From: report at bugs.python.org (Florent Xicluna) Date: Wed, 22 Jan 2014 01:01:41 +0000 Subject: [issue17825] Indentation.offset and SyntaxError.offset mismatch In-Reply-To: <1366789582.23.0.0218552351895.issue17825@psf.upfronthosting.co.za> Message-ID: <1390352501.12.0.682251770269.issue17825@psf.upfronthosting.co.za> Florent Xicluna added the comment: Done. The alignment error with non-ASCII chars should be fixed too, thanks to the work of Serhiy on issue #2382. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 02:12:34 2014 From: report at bugs.python.org (Florent Xicluna) Date: Wed, 22 Jan 2014 01:12:34 +0000 Subject: [issue20339] Make bytes() use tp_as_buffer for cmp In-Reply-To: <1390351229.22.0.995411790956.issue20339@psf.upfronthosting.co.za> Message-ID: <1390353154.59.0.515671594725.issue20339@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- components: +Interpreter Core nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 02:30:06 2014 From: report at bugs.python.org (Tal Einat) Date: Wed, 22 Jan 2014 01:30:06 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za> Message-ID: <1390354206.08.0.647338642845.issue20180@psf.upfronthosting.co.za> Tal Einat added the comment: Attaching a new patch for complete conversion of Objects/unicodeobject.c. This is to replace the previous patch for this file. This new patch also converts all other possible unicode methods, including those not using PyArg_* functions. This includes various methods with no arguments or with one PyObject* argument. Unicode methods still not converted, probably impossible to convert: 1) The various find methods (index, count, startswith, rfind, etc.), because they use a special function 'stringlib_parse_args_finds_unicode' to parse their arguments 2) format and format_map, since they are defined elsewhere 3) _decimal2ascii, since it is just for debugging ---------- Added file: http://bugs.python.org/file33604/unicodeobject.c_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 02:36:24 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Jan 2014 01:36:24 +0000 Subject: [issue20332] Argument Clinic does not support the 'l' format In-Reply-To: <1390321924.51.0.108900260665.issue20332@psf.upfronthosting.co.za> Message-ID: <1390354584.65.0.028557349727.issue20332@psf.upfronthosting.co.za> Larry Hastings added the comment: /*[clinic input] brett_is_stinky_and_wrong l: long [clinic start generated code]*/ PyDoc_STRVAR(brett_is_stinky_and_wrong__doc__, "brett_is_stinky_and_wrong(l)"); #define BRETT_IS_STINKY_AND_WRONG_METHODDEF \ {"brett_is_stinky_and_wrong", (PyCFunction)brett_is_stinky_and_wrong, METH_VARARGS|METH_KEYWORDS, brett_is_stinky_and_wrong__doc__}, static PyObject * brett_is_stinky_and_wrong_impl(PyModuleDef *module, long l); static PyObject * brett_is_stinky_and_wrong(PyModuleDef *module, PyObject *args, PyObject *kwargs) { PyObject *return_value = NULL; static char *_keywords[] = {"l", NULL}; long l; if (!PyArg_ParseTupleAndKeywords(args, kwargs, "l:brett_is_stinky_and_wrong", _keywords, &l)) goto exit; return_value = brett_is_stinky_and_wrong_impl(module, l); exit: return return_value; } static PyObject * brett_is_stinky_and_wrong_impl(PyModuleDef *module, long l) /*[clinic end generated code: checksum=d16330187341a0ecea0bf7ab70ba5551200ceb3c]*/ ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 02:40:20 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Jan 2014 01:40:20 +0000 Subject: [issue20260] Argument Clinic: add unsigned integers converters In-Reply-To: <1389720718.78.0.860738296491.issue20260@psf.upfronthosting.co.za> Message-ID: <1390354820.52.0.906715590666.issue20260@psf.upfronthosting.co.za> Larry Hastings added the comment: Is this waiting on something? I agree that we can't change the behavior of existing functions. But your new converters should raise ValueError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 02:43:29 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Jan 2014 01:43:29 +0000 Subject: [issue20260] Argument Clinic: add unsigned integers converters In-Reply-To: <1389720718.78.0.860738296491.issue20260@psf.upfronthosting.co.za> Message-ID: <1390355009.98.0.96694564766.issue20260@psf.upfronthosting.co.za> Larry Hastings added the comment: Also, you didn't remove the _ in front of "Converter" in the names, e.g "_PyLong_UnsignedShort_Converter" should be "_PyLong_UnsignedShortConverter". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 02:46:00 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 Jan 2014 01:46:00 +0000 Subject: [issue16638] support multi-line docstring signatures in IDLE calltips In-Reply-To: <1354909776.12.0.96265352257.issue16638@psf.upfronthosting.co.za> Message-ID: <3f88bB2YNJz7Lmk@mail.python.org> Roundup Robot added the comment: New changeset 6b62c923c0ef by Terry Jan Reedy in branch '2.7': Issue #16638: Include up to 5 docstring header lines (before first blank) in http://hg.python.org/cpython/rev/6b62c923c0ef New changeset 5b6c3760714e by Terry Jan Reedy in branch '3.3': Issue #16638: Include up to 5 docstring header lines (before first blank) in http://hg.python.org/cpython/rev/5b6c3760714e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 02:48:43 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jan 2014 01:48:43 +0000 Subject: [issue16638] support multi-line docstring signatures in IDLE calltips In-Reply-To: <1354909776.12.0.96265352257.issue16638@psf.upfronthosting.co.za> Message-ID: <1390355323.05.0.454409187889.issue16638@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Main change is using a custom function (2.7) or bytes instead of int for test and using maxsplit parameter to not needlessly split a 100-line docstring into 100 pieces. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 03:00:08 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Jan 2014 02:00:08 +0000 Subject: [issue20260] Argument Clinic: add unsigned integers converters In-Reply-To: <1389720718.78.0.860738296491.issue20260@psf.upfronthosting.co.za> Message-ID: <1390356008.75.0.734895671888.issue20260@psf.upfronthosting.co.za> Larry Hastings added the comment: Actually, here's another data point to consider. The underlying implementation of PyArg_Parse* is the function convertsimple() in Python/getargs.c. For all the non-bitwise integer format units ('bhi'), if they overflow or underflow the native integer they raise OverflowError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 03:22:49 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jan 2014 02:22:49 +0000 Subject: [issue20338] Idle: increase max calltip width In-Reply-To: <1390344102.42.0.241411598779.issue20338@psf.upfronthosting.co.za> Message-ID: <1390357369.68.0.739777659197.issue20338@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I deleted truncation code in CallTipWindow.py, all three versions, but messed up issue number. 2.7 http://hg.python.org/cpython/rev/c28e07377b03 changeset: 88630:c28e07377b03 3.3 (same) http://hg.python.org/cpython/rev/1b89fd73c625 changeset: 88631:1b89fd73c625 Issue still open for changing CallTips._MAX_COLS. ---------- stage: test needed -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 03:41:59 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 22 Jan 2014 02:41:59 +0000 Subject: [issue20340] -bb option does not have different behavior than -b option Message-ID: <1390358519.86.0.0114384663119.issue20340@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis: -bb option does not have different behavior than -b option since Python 3.2. http://docs.python.org/3.4/using/cmdline.html#cmdoption-b says: "Issue a warning when comparing str and bytes. Issue an error when the option is given twice (-bb)." (http://docs.python.org/3.4/howto/pyporting.html#deal-with-the-bytes-string-dichotomy also documents behavior present in Python 3.1.) $ python3.1 -b -c 'print("" == b""); print("Program still running")' -c:1: BytesWarning: Comparison between bytes and string False Program still running $ python3.1 -bb -c 'print("" == b""); print("Program still running")' Traceback (most recent call last): File "", line 1, in BytesWarning: Comparison between bytes and string $ python3.2 -b -c 'print("" == b""); print("Program still running")' -c:1: BytesWarning: Comparison between bytes and string False Program still running $ python3.2 -bb -c 'print("" == b""); print("Program still running")' -c:1: BytesWarning: Comparison between bytes and string False Program still running $ python3.3 -b -c 'print("" == b""); print("Program still running")' -c:1: BytesWarning: Comparison between bytes and string False Program still running $ python3.3 -bb -c 'print("" == b""); print("Program still running")' -c:1: BytesWarning: Comparison between bytes and string False Program still running $ python3.4 -b -c 'print("" == b""); print("Program still running")' -c:1: BytesWarning: Comparison between bytes and string False Program still running $ python3.4 -bb -c 'print("" == b""); print("Program still running")' -c:1: BytesWarning: Comparison between bytes and string False Program still running $ ---------- components: Interpreter Core keywords: 3.2regression messages: 208736 nosy: Arfrever priority: normal severity: normal status: open title: -bb option does not have different behavior than -b option type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 04:05:59 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Jan 2014 03:05:59 +0000 Subject: [issue20302] Argument Clinic: meaningful names for group flags In-Reply-To: <1390137113.2.0.816137026514.issue20302@psf.upfronthosting.co.za> Message-ID: <1390359959.07.0.0705927587844.issue20302@psf.upfronthosting.co.za> Larry Hastings added the comment: Well, they're going to have to change somehow, because the concepts of "left" and "right" are going away (see #20303). However, your suggested new name for these functions would be awful for large groups. Consider curses.window.overlay: window.overlay(destwin[, sminrow, smincol, dminrow, dmincol, dmaxrow, dmaxcol]) Your algorithm would generate the name "use_destwin_sminrow_smincol_dminrow_dmincol_dmaxrow_dmaxcol". I suggest instead: remap the names to less-confusing names in your impl function. Compiler optimization will make the redundant name disappear, so it will have no run-time cost. ---------- resolution: -> wont fix stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 04:08:24 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Jan 2014 03:08:24 +0000 Subject: [issue20303] Argument Clinic: optional groups In-Reply-To: <1390138180.16.0.400473002032.issue20303@psf.upfronthosting.co.za> Message-ID: <1390360104.38.0.723726587193.issue20303@psf.upfronthosting.co.za> Larry Hastings added the comment: When I fix #20303, the new rules will be: * You can have top-level optional groups anywhere. * You may nest up to one nested group in a group. * Whenever you nest a group in another group, all nested groups in that stack must favor the same side (left or right). Here's are example of nesting. This is permitted: [ a, [b, [c,]]] This is not: [a, [[b,] c,]] because the nested group adjoining "a" is on the right, but the nested group adjoining "c" is on the left. The generated names for group variables will probably change to "group_{n}", where n starts at 1 and is assigned going straight across to the right, ignoring nesting, like groups in regular expressions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 04:13:07 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Jan 2014 03:13:07 +0000 Subject: [issue20294] Argument Clinic: add support for __init__ In-Reply-To: <1390045406.06.0.938757132567.issue20294@psf.upfronthosting.co.za> Message-ID: <1390360387.6.0.305353141864.issue20294@psf.upfronthosting.co.za> Larry Hastings added the comment: That problem will be irrelevant, once builtin classes support signatures (#20189). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 04:18:02 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Jan 2014 03:18:02 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" Message-ID: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> New submission from Larry Hastings: Attached is a *preliminary* patch for Argument Clinic that adds nullable ints. If you use the converter "int(nullable=True), then: * The type you get back is not int but "nullable_int_t", a structure containing three fields: "error", "is_null", and "i". "error" is 1 if there was an error in parsing, else 0. "is_null" is 1 if None was passed in, else 0. "i" is the integer value if an integer was passed in, else undefined. * You may now use a default value of None. If you do, "is_null" is 1. * You may still use a default integer. If you do, "i" will be set to that. * If you use neither then obviously it's a required argument. I'd appreciate just a preliminary review, saying something like "this is a good idea, keep going," or "you should change your approach," or "this is a bad idea and should not be committed," or "you look very handsome today Larry". I don't remember who specifically needed the nullable ints, so I just added a bunch of Derby contestants. Serhiy: I also added a fix for the bug you mentioned in #20294 after it was closed: the docstring for __new__ and __init__ methods now uses the class name instead of the name of the method. Note that this fix doesn't matter much; once I commit a fix for #20189, that signature will always be hidden. ---------- assignee: larry components: Extension Modules files: larry.nullable.ints.draft messages: 208740 nosy: Yury.Selivanov, brett.cannon, georg.brandl, larry, serhiy.storchaka, vajrasky, zach.ware priority: normal severity: normal stage: patch review status: open title: Argument Clinic: add "nullable ints" type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file33605/larry.nullable.ints.draft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 04:21:17 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Jan 2014 03:21:17 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> Message-ID: <1390360877.81.0.459765866737.issue20341@psf.upfronthosting.co.za> Larry Hastings added the comment: I should have mentioned--a sample using nullable ints is in itertoolsmodule.c. longobject.{ch} changed to add the converters, and obviously clinic.py changed to add support for the converters. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 04:35:59 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 22 Jan 2014 03:35:59 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1390361759.33.0.585329362827.issue20172@psf.upfronthosting.co.za> Changes by Zachary Ware : Added file: http://bugs.python.org/file33606/088095387caf.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 04:47:47 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 22 Jan 2014 03:47:47 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1390362467.47.0.0823694190286.issue20172@psf.upfronthosting.co.za> Zachary Ware added the comment: Ok, new conglomerate patch is posted; includes a few more return conversions (particularly in msvcrt) and a few other minor changes compared to the previous conglomerate. I would call this one a commit candidate, pending your review. I don't plan to commit this one, though; I want to switch each of them to some manner of buffered output first, but I figured this form would be easier to review. I'll post the buffered patch as soon as it's ready, you can review whichever one you actually prefer :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 05:09:19 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jan 2014 04:09:19 +0000 Subject: [issue20283] Wrong keyword parameter name in regex pattern methods In-Reply-To: <1389905067.44.0.489524795145.issue20283@psf.upfronthosting.co.za> Message-ID: <1390363759.45.0.428185045372.issue20283@psf.upfronthosting.co.za> Terry J. Reedy added the comment: If no one else pipes up here, perhaps ask on pydef about changing C names to match documented names. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 05:17:10 2014 From: report at bugs.python.org (Christopher Welborn) Date: Wed, 22 Jan 2014 04:17:10 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390364230.5.0.649534930276.issue20218@psf.upfronthosting.co.za> Christopher Welborn added the comment: Ram Rachum: If I actually had a say in the matter, I wouldn't be totally against it. (so far I only lurk the lists/tracker looking for things to work on.) I was just offering you a solution that you can use _today_. I do think that if something like this was added, then you would have to go ahead and add the other read/write functions because the next question would be 'how come pathlib has no readlines()?'. Also, it would definitely need more than 'mode' or 'binary' for args. The encoding option needs to be taken into account. People need to have a choice in what encoding to use even with a little read()/write(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 05:31:32 2014 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 22 Jan 2014 04:31:32 +0000 Subject: [issue20336] test_asyncio: relax timings even more In-Reply-To: <1390343391.65.0.626852689754.issue20336@psf.upfronthosting.co.za> Message-ID: <1390365092.24.0.552092309323.issue20336@psf.upfronthosting.co.za> Guido van Rossum added the comment: I won't have time to fix this (and bardly to even review a fix) but this seems a straightforward fix and you can go ahead without me -- maybe you can get someone else with some asyncio experience to review your patch (e.g. Antoine or Victor). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 05:39:38 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Wed, 22 Jan 2014 04:39:38 +0000 Subject: [issue20177] Derby #8: Convert 28 sites to Argument Clinic across 2 files In-Reply-To: <1389138574.32.0.892814928986.issue20177@psf.upfronthosting.co.za> Message-ID: <1390365578.48.0.715708996501.issue20177@psf.upfronthosting.co.za> Nikolaus Rath added the comment: As discussed on devel, here's an updated patch for timemodule.c that uses a custom C converter to handle the parse_time_t_args() utility function. The only function I did not convert is mktime, because I did not find a way to do so without duplicating the gettmarg() utility function (which cannot be converted because it is also called by other C functions). You probably want to take a close look at what I did to the strptime function. I didn't see a way to include the actual default value (rather than None) in the signature without reconstructing the argument tuple for calling the Python implementation. As far as I can see, this completes the conversion for timemodule.c. I'll work on _datetimemodule.c next, but I'm not sure I'll have time before next weekend. This is probably already planned, but since I haven't seen it in Misc/NEWS yet: I think it would be a good idea to entry informing the user about the conversion from strictly optional parameters to parameters with default values. Eg.: * Issues xxx, yyy, zzz: many functions in the standard library now accept `None` for optional arguments. Previously, specifying `None` mostly resulted in a `TypeError`. Starting with this version, passing `None` is equivalent to not specfying the parameter. ---------- Added file: http://bugs.python.org/file33607/timemodule_rev2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 05:47:58 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Wed, 22 Jan 2014 04:47:58 +0000 Subject: [issue19920] TarFile.list() fails on some files In-Reply-To: <1386437860.38.0.0478693655005.issue19920@psf.upfronthosting.co.za> Message-ID: <1390366078.53.0.380056126365.issue19920@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the patch addressing some of Serhiys concerns. Thanks for the review. There are some things that I could not make it up: 1. The test for unencodable tarinfo.linkname is not done yet, because maybe it is better to be done in a separate ticket. To make the test simple, we need to modify the testtar.tar file. We need to add file with unencodable linkname. Is it too much to do it in this ticket? 2. "should exist separate test (not in CommandLineTest) for the TarFile.list() method itself." -> I haven't got the inspiration yet how to create this test to add additional value. ---------- Added file: http://bugs.python.org/file33608/fix_tarfile_list_print_lone_surrogate_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 05:49:16 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Wed, 22 Jan 2014 04:49:16 +0000 Subject: [issue11448] docs for HTTPConnection.set_tunnel are ambiguous In-Reply-To: <1299636529.48.0.302129596868.issue11448@psf.upfronthosting.co.za> Message-ID: <1390366156.65.0.813373347499.issue11448@psf.upfronthosting.co.za> Nikolaus Rath added the comment: The patches look fine to me. They are only docpatches, so no testcase is needed. I have rebased them on current hg tip to avoid fuzz, but otherwise left them unchanged. I think this is ready to be committed. ---------- nosy: +ezio.melotti, georg.brandl versions: -Python 3.5 Added file: http://bugs.python.org/file33609/issue11448_r2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 05:51:02 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Wed, 22 Jan 2014 04:51:02 +0000 Subject: [issue19920] TarFile.list() fails on some files In-Reply-To: <1386437860.38.0.0478693655005.issue19920@psf.upfronthosting.co.za> Message-ID: <1390366262.6.0.32001004243.issue19920@psf.upfronthosting.co.za> Changes by Vajrasky Kok : Removed file: http://bugs.python.org/file33608/fix_tarfile_list_print_lone_surrogate_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 06:07:18 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Wed, 22 Jan 2014 05:07:18 +0000 Subject: [issue19920] TarFile.list() fails on some files In-Reply-To: <1386437860.38.0.0478693655005.issue19920@psf.upfronthosting.co.za> Message-ID: <1390367238.21.0.176753147097.issue19920@psf.upfronthosting.co.za> Changes by Vajrasky Kok : Added file: http://bugs.python.org/file33610/fix_tarfile_list_print_lone_surrogate_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 07:07:30 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 22 Jan 2014 06:07:30 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1390370850.73.0.845360131939.issue20172@psf.upfronthosting.co.za> Zachary Ware added the comment: Marking #20189 as a dependency; winreg.HKEYType and _winapi.Overlapped need the signature fixes provided by #20189 before commit. ---------- dependencies: +inspect.Signature doesn't recognize all builtin types _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 07:18:13 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 22 Jan 2014 06:18:13 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1390371493.72.0.232826080802.issue20172@psf.upfronthosting.co.za> Zachary Ware added the comment: And scratch v3 being commit-candidate. I forgot to add an HKEY return converter to winreg (could have sworn I had done that, but I have no record of it), and my return converters in msvcrt are messy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 07:37:58 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Wed, 22 Jan 2014 06:37:58 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> Message-ID: <1390372678.69.0.48744596011.issue20341@psf.upfronthosting.co.za> Vajrasky Kok added the comment: >>> itertools.repeat.__doc__ 'repeat(object, times=None)\nReturns an iterator which returns the object the specified number of times.\n\nIf times is None, returns the object endlessly.' >>> itertools.repeat('a', times=None) Traceback (most recent call last): File "", line 1, in TypeError: __new__() argument 2 must be (unspecified), not None Also, maybe it's a good idea to add case for None and negative times in itertools.repeat unit test. You can get inspiration from http://bugs.python.org/issue19145 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 07:39:43 2014 From: report at bugs.python.org (Georg Brandl) Date: Wed, 22 Jan 2014 06:39:43 +0000 Subject: [issue11448] docs for HTTPConnection.set_tunnel are ambiguous In-Reply-To: <1299636529.48.0.302129596868.issue11448@psf.upfronthosting.co.za> Message-ID: <1390372783.63.0.869731500191.issue11448@psf.upfronthosting.co.za> Georg Brandl added the comment: The first sentence of the second new paragraph is a bit ungrammatical, right? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 08:26:11 2014 From: report at bugs.python.org (karl) Date: Wed, 22 Jan 2014 07:26:11 +0000 Subject: [issue11448] docs for HTTPConnection.set_tunnel are ambiguous In-Reply-To: <1299636529.48.0.302129596868.issue11448@psf.upfronthosting.co.za> Message-ID: <1390375571.72.0.146416296291.issue11448@psf.upfronthosting.co.za> karl added the comment: ooops right, my bad. s/on port 8080. We first/on port 8080, we first/ better? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 08:38:29 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 22 Jan 2014 07:38:29 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <1390376309.44.0.288467089111.issue19081@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Not all cases of this were fixed by the existing patch. subimports still trigger the bug via a different code path. attaching an updated unittest that demonstrates that. ---------- resolution: fixed -> status: closed -> open Added file: http://bugs.python.org/file33611/issue19081-subimport-test-gps01.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 08:39:33 2014 From: report at bugs.python.org (Laurent Mazuel) Date: Wed, 22 Jan 2014 07:39:33 +0000 Subject: [issue20329] zipfile.extractall fails in Posix shell with utf-8 filename In-Reply-To: <1390316753.93.0.767122614569.issue20329@psf.upfronthosting.co.za> Message-ID: <1390376373.04.0.990904120739.issue20329@psf.upfronthosting.co.za> Laurent Mazuel added the comment: Thanks for your answer. I think you can't transcode internal zip filenames to FS encoding. Actually, in Unix the FS only stores bytes for filename, there is no "FS encoding". Then, if you change your locale, the filename printed will change too in your console. If you transcode filename using the current locale, unzipping twice the same file with two different locales will lead to two different files, which is not (I think) you are intending for. The problem will not arise in Windows (NTFS is UTF-16) nor MAC OSX (UTF-8) Moreover, a simple "unzip" works like a charm. It doesn't care about encoding or current locale and extract the file using the initial bytes in the zip. Unzipping twice with the two different locales creates only one file. An interesting link (even if it is not an official reference): http://unix.stackexchange.com/questions/2089/what-charset-encoding-is-used-for-filenames-and-paths-on-linux ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 09:13:25 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 22 Jan 2014 08:13:25 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <1390378405.91.0.30067917103.issue19081@psf.upfronthosting.co.za> Gregory P. Smith added the comment: The call stack for that code path failing is: #0 get_data (fp=0xf64920, archive=0xe77ecc "/home/greg/sandbox/python/cpython/2.7/junk95142.zip", toc_entry=('/home/greg/sandbox/python/cpython/2.7/junk95142.zip/ziptestpackage/ziptestmodule.py', 0, 16, 16, 0, 344, 17462, -1268077639)) at ./Modules/zipimport.c:1038 #1 0x00000000005401b3 in get_code_from_data (archive=0xe77ecc "/home/greg/sandbox/python/cpython/2.7/junk95142.zip", fp=0xf64920, ispackage=0, isbytecode=0, mtime=0, toc_entry=('/home/greg/sandbox/python/cpython/2.7/junk95142.zip/ziptestpackage/ziptestmodule.py', 0, 16, 16, 0, 344, 17462, -1268077639)) at ./Modules/zipimport.c:1267 #2 0x00000000005404a9 in get_module_code (self=0xe6b6f0, fullname=0xe6f0ec "ziptestpackage.ziptestmodule", p_ispackage=0x7fffffff98d8, p_modpath=0x7fffffff98e8) at ./Modules/zipimport.c:1325 #3 0x000000000053dd77 in zipimporter_load_module (obj=, args=('ziptestpackage.ziptestmodule',)) at ./Modules/zipimport.c:352 #4 0x00000000005646b8 in PyCFunction_Call ( func=, arg=('ziptestpackage.ziptestmodule',), kw=0x0) at Objects/methodobject.c:81 #5 0x0000000000420f97 in PyObject_Call ( func=, arg=('ziptestpackage.ziptestmodule',), kw=0x0) at Objects/abstract.c:2529 #6 0x00000000004210ed in call_function_tail ( callable=, args=('ziptestpackage.ziptestmodule',)) at Objects/abstract.c:2561 #7 0x00000000004214f2 in PyObject_CallMethod (o=, name=0x5a6c7d "load_module", format=0x5a6b67 "s") at Objects/abstract.c:2638 #8 0x00000000004f3aa0 in load_module (name=0xf67630 "ziptestpackage.ziptestmodule", fp=0x0, pathname=0xf68660 "/home/greg/sandbox/python/cpython/2.7/junk95142.zip/ziptestpackage", type=9, loader=) at Python/import.c:1961 #9 0x00000000004f5a67 in import_submodule (mod=, subname=0xf6763f "ziptestmodule", fullname=0xf67630 "ziptestpackage.ziptestmodule") at Python/import.c:2700 #10 0x00000000004f5037 in load_next (mod=, altmod=, p_name=0x7fffffff9c88, buf=0xf67630 "ziptestpackage.ziptestmodule", p_buflen=0x7fffffff9ca0) at Python/import.c:2515 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 09:32:31 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jan 2014 08:32:31 +0000 Subject: [issue19903] Idle: Use inspect.signature for calltips In-Reply-To: <1386289306.22.0.0855188637089.issue19903@psf.upfronthosting.co.za> Message-ID: <1390379551.45.0.666979913329.issue19903@psf.upfronthosting.co.za> Terry J. Reedy added the comment: *17481 is about changing getargspec to use signature, at least as a backup. But that would not fix the example here. The calltips have been moved in 20122. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 09:35:53 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jan 2014 08:35:53 +0000 Subject: [issue19020] Regression: Windows-tkinter-idle, unicode, and 0xxx filename In-Reply-To: <1379196682.03.0.147663616291.issue19020@psf.upfronthosting.co.za> Message-ID: <1390379753.25.0.960567241309.issue19020@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am assuming that Serhiy meant to close this. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 09:43:40 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jan 2014 08:43:40 +0000 Subject: [issue19584] IDLE fails - Python V2.7.6 - 64b on Win7 64b In-Reply-To: <1384446600.97.0.293760172402.issue19584@psf.upfronthosting.co.za> Message-ID: <1390380220.41.0.146559255456.issue19584@psf.upfronthosting.co.za> Terry J. Reedy added the comment: There is insufficient info for any action on our part. ---------- resolution: -> works for me stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 09:44:31 2014 From: report at bugs.python.org (Yury V. Zaytsev) Date: Wed, 22 Jan 2014 08:44:31 +0000 Subject: [issue20342] Float rounding issues on Red Hat 6.4 / PPC64 / GCC 4.4.6 Message-ID: <1390380271.48.0.67555288445.issue20342@psf.upfronthosting.co.za> New submission from Yury V. Zaytsev: Hi, I've managed to get the test suite of Python to run on Python 3.4.0b2 version cross-compiled for a specialized POWER chip. I get a number of failures that seem to have the same nature. I'm under impression, that actually the tests might need to be adjusted, but I'm not sure about it. I'm happy to provide any additional information to diagnose this issue. Please let me know if I've grouped them wrong and have to file a different issue for some tests. Thanks! == CPython 3.4.0b2 (default, Jan 7 2014, 10:01:53) [GCC 4.4.6] == Linux-2.6.32-358.11.1.bgq.el6.bgas_20131217.ppc64-ppc64-with-redhat-6.4-Santiago big-endian == hash algorithm: fnv 64bit == /tmp/test_python_11312 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) ====================================================================== FAIL: fromhex (builtins.float) Doctest: builtins.float.fromhex ---------------------------------------------------------------------- Traceback (most recent call last): File "/XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/doctest.py", line 2187, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for builtins.float.fromhex File "builtins", line unknown line number, in fromhex ---------------------------------------------------------------------- File "builtins", line ?, in builtins.float.fromhex Failed example: float.fromhex('-0x1p-1074') Expected: -5e-324 Got: -4.9406564584124654e-324 ---------------------------------------------------------------------- ====================================================================== FAIL: test_float__format__ (test.test_types.TypesTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/test/test_types.py", line 467, in test_float__format__ test(1e200, '+', '+1e+200') File "/XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/test/test_types.py", line 403, in test self.assertEqual(f.__format__(format_spec), result) AssertionError: '+9.9999999999999997e+199' != '+1e+200' - +9.9999999999999997e+199 + +1e+200 ---------------------------------------------------------------------- ====================================================================== FAIL: SequenceMatcher (difflib) Doctest: difflib.SequenceMatcher ---------------------------------------------------------------------- Traceback (most recent call last): File "/XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/doctest.py", line 2187, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for difflib.SequenceMatcher File "/XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/difflib.py", line 47, in SequenceMatcher ---------------------------------------------------------------------- File "/XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/difflib.py", line 83, in difflib.SequenceMatcher Failed example: print(round(s.ratio(), 3)) Expected: 0.866 Got: 0.86599999999999999 ---------------------------------------------------------------------- ====================================================================== FAIL: test_format_testfile (test.test_float.FormatTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/test/test_float.py", line 592, in test_format_testfile self.assertEqual(fmt % float(arg), rhs) AssertionError: '0.029999999999999999' != '0.03' - 0.029999999999999999 + 0.03 ---------------------------------------------------------------------- ====================================================================== FAIL: test_non_ascii (test.test_format.FormatTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/test/test_format.py", line 272, in test_non_ascii self.assertEqual(format(12.3, "\u2007<6"), "12.3\u2007\u2007") AssertionError: '12.300000000000001' != '12.3\u2007\u2007' - 12.300000000000001 + 12.3\u2007\u2007 ---------------------------------------------------------------------- ====================================================================== FAIL: test_float_default (test.test_optparse.TestExpandDefaults) ---------------------------------------------------------------------- Traceback (most recent call last): File "/XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/test/test_optparse.py", line 619, in test_float_default self.assertHelp(self.parser, expected_help) File "/XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/test/test_optparse.py", line 189, in assertHelp actual_help + '"\n') AssertionError: help text failure; expected: "Usage: test [options] Options: -h, --help show this help message and exit -p PROB, --prob=PROB blow up with probability PROB [default: 0.43] "; got: "Usage: test [options] Options: -h, --help show this help message and exit -p PROB, --prob=PROB blow up with probability PROB [default: 0.42999999999999999] " ---------------------------------------------------------------------- test_doc_tests (test.test_statistics.DocTests) ... ********************************************************************** File "/XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/statistics.py", line 290, in statistics.mean Failed example: mean([1, 2, 3, 4, 4]) Expected: 2.8 Got: 2.7999999999999998 ********************************************************************** File "/XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/statistics.py", line 380, in statistics.median_grouped Failed example: median_grouped([1, 2, 2, 3, 4, 4, 4, 4, 4, 5]) Expected: 3.7 Got: 3.7000000000000002 ********************************************************************** File "/XXX/opt/python-3.4.0b2-gcc-cnk/lib/python3.4/statistics.py", line 602, in statistics.pstdev Failed example: pstdev([1.5, 2.5, 2.5, 2.75, 3.25, 4.75]) Expected: 0.986893273527251 Got: 0.98689327352725098 ********************************************************************** 3 items had failures: 1 of 5 in statistics.mean 1 of 4 in statistics.median_grouped 1 of 1 in statistics.pstdev ***Test Failed*** 3 failures. ---------- components: Interpreter Core messages: 208760 nosy: zaytsev priority: normal severity: normal status: open title: Float rounding issues on Red Hat 6.4 / PPC64 / GCC 4.4.6 type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 10:12:07 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 22 Jan 2014 09:12:07 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <1390381927.48.0.0909700246276.issue19081@psf.upfronthosting.co.za> Gregory P. Smith added the comment: The problem appears to be that every zipimporter instance keeps its own reference to the zip files table of contents (self->files) instead of continually using the module wide zip_directory_cache but the zip_stat_cache is being maintained externally to that in a module wide fashion. "import foo.bar" causes an "import foo" followed by an "import foo.bar" which uses a different zipimporter instance. if it already exists, it's own self->files reference will be out of date despite the module global zip_stat_cache having been updated to say the TOC has been reread. One solution to this would be to get rid of struct _zipimporter.files entirely and always use zip_directory_cache[self->archive] as the canonical single source for that. "pro-tip" for anyone working on Python importers: You don't know how import works. Multiple instances of your importers will exist. If you think you know how import works, see the first statement again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 10:23:51 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 22 Jan 2014 09:23:51 +0000 Subject: [issue20342] Float rounding issues on Red Hat 6.4 / PPC64 / GCC 4.4.6 In-Reply-To: <1390380271.48.0.67555288445.issue20342@psf.upfronthosting.co.za> Message-ID: <1390382631.91.0.636745004325.issue20342@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 10:32:31 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Wed, 22 Jan 2014 09:32:31 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1390383151.47.0.638083504181.issue20185@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the patch for listobject. A couple of thoughts: 1. I can not convert this signature: if (!PyArg_ParseTuple(args, "O|O&O&:index", &v, _PyEval_SliceIndex, &start, _PyEval_SliceIndex, &stop)) return NULL; It's bloody difficult. If I make start (and stop) as PyObject, I get a lot of pointer warning conversion. The closest I can get is making start (and stop) as Py_ssize_t but it changes the behaviour. a.index(0, -4*sys.maxsize, 4*sys.maxsize) will throw OverflowError. 2. for tp_init, it forces me to give wrong return signature. "__init__([sequence=None])\n" This is the clinic input: list.__init__ self: PyListObject [ sequence: object(c_default="NULL") = None ] / Without None, it will be an error in clinic process. 3. The init function returns integer but in error case, it returns NULL which will throws pointer warning conversion. static int list___init__(PyObject *self, PyObject *args, PyObject *kwargs) { int return_value = -1; int group_right_1 = 0; PyObject *sequence = NULL; if (!_PyArg_NoKeywords("__init__", kwargs)) goto exit; switch (PyTuple_GET_SIZE(args)) { case 0: break; case 1: if (!PyArg_ParseTuple(args, "O:__init__", &sequence)) return NULL; group_right_1 = 1; break; .... ---------- Added file: http://bugs.python.org/file33612/clinic_listobject.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 10:46:47 2014 From: report at bugs.python.org (Nadeem Vawda) Date: Wed, 22 Jan 2014 09:46:47 +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: <1390384007.36.0.751109456119.issue15955@psf.upfronthosting.co.za> Nadeem Vawda added the comment: No, I'm afraid I haven't had a chance to do any work on this issue since my last message. I would be happy to review a patch for this, but before you start writing one, we should settle on how the API will look. I'll review the existing discussion in detail over the weekend and come up with something that avoids the potential problems raised by Serhiy. ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 10:49:16 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Jan 2014 09:49:16 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> Message-ID: <1390384156.64.0.919544714774.issue20341@psf.upfronthosting.co.za> Larry Hastings added the comment: The bug you saw was an easy fix; the converter function needs to return 1 (success) from the "== Py_None" branch. And yes, more unit tests would be good, fixing the documentation would be good too. I did say the patch was nowhere near ready. I will assume unless I hear otherwise that I should proceed with the patch and flesh out all the different and float types. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 10:53:27 2014 From: report at bugs.python.org (Yury V. Zaytsev) Date: Wed, 22 Jan 2014 09:53:27 +0000 Subject: [issue20342] Float rounding issues on Red Hat 6.4 / PPC64 / GCC 4.4.6 In-Reply-To: <1390380271.48.0.67555288445.issue20342@psf.upfronthosting.co.za> Message-ID: <1390384407.03.0.788172462155.issue20342@psf.upfronthosting.co.za> Yury V. Zaytsev added the comment: The CPU model is IBM PowerPC A2, the information about the cross-compiler is as follows: $ /bgsys/drivers/ppcfloor/gnu-linux/bin/powerpc64-bgq-linux-gcc -v Reading specs from /bgsys/drivers/toolchain/V1R2M1_base/gnu-linux/lib/gcc/powerpc64-bgq-linux/4.4.6/specs Target: powerpc64-bgq-linux Configured with: /bgsys/drivers/V1R2M1/ppc64/toolchain/gnu/gcc-4.4.6/configure --prefix=/bgsys/drivers/toolchain/V1R2M1_base/gnu-linux --target=powerpc64-bgq-linux --with-pkgversion=BGQ-V1R2M1-130820 --host=powerpc64-linux-gnu --build=powerpc64-linux-gnu --disable-multilib --enable-shared --enable-secureplt --disable-libmudflap --disable-libspp --with-headers=/bgsys/drivers/V1R2M1/ppc64/toolchain/gnu/build-powerpc64-bgq-linux/tempglibc-4.4.6-install/include --with-libs=/bgsys/drivers/V1R2M1/ppc64/toolchain/gnu/build-powerpc64-bgq-linux/tempglibc-4.4.6-install/lib --with-bin=/bgsys/drivers/V1R2M1/ppc64/toolchain/gnu/build-powerpc64-bgq-linux/tempglibc-4.4.6-install/bin --with-sbin=/bgsys/drivers/V1R2M1/ppc64/toolchain/gnu/build-powerpc64-bgq-linux/tempglibc-4.4.6-install/sbin --with-long-double-128 --enable-threads=posix --enable-languages=c,c++,fortran Thread model: posix gcc version 4.4.6 (BGQ-V1R2M1-130820) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 10:56:51 2014 From: report at bugs.python.org (Tal Einat) Date: Wed, 22 Jan 2014 09:56:51 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> Message-ID: <1390384611.4.0.637016569723.issue20341@psf.upfronthosting.co.za> Tal Einat added the comment: You look very handsome today Larry :) Regardless, I do think this is a good idea. I've converted several functions that have -1 as a default value for ints where they ideally should have None. Having None as the default will be much clearer and less error prone for users. ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 11:06:22 2014 From: report at bugs.python.org (Tal Einat) Date: Wed, 22 Jan 2014 10:06:22 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> Message-ID: <1390385182.94.0.773039222946.issue20341@psf.upfronthosting.co.za> Tal Einat added the comment: My only comment from reviewing the patch is that you seem to have used NULLABLE_PY_SSIZE_T_INITIALIZE by accident one time in int_converter (in clinic.py). Other than that, as you already know, make sure to return 1 in both converters in the "if (arg == Py_None)" branches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 11:13:59 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Jan 2014 10:13:59 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1390385639.26.0.160269636019.issue20185@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: 1. In list.index use custom converter. /*[python input] class slice_index_converter(CConverter): type = 'Py_ssize_t' converter = '_PyEval_SliceIndex' [python start generated code]*/ 2. In list.__init__ use either "unspecified" default value or optional group without default value. 3. This looks as Argument Clinic bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 11:27:31 2014 From: report at bugs.python.org (Yury V. Zaytsev) Date: Wed, 22 Jan 2014 10:27:31 +0000 Subject: [issue20342] Float rounding issues on Red Hat 6.4 / PPC64 / GCC 4.4.6 In-Reply-To: <1390380271.48.0.67555288445.issue20342@psf.upfronthosting.co.za> Message-ID: <1390386451.95.0.905712124182.issue20342@psf.upfronthosting.co.za> Changes by Yury V. Zaytsev : Added file: http://bugs.python.org/file33613/pyconfig.h _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 11:28:13 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 22 Jan 2014 10:28:13 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <1390386493.4.0.981462062851.issue19081@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Here's a fix that I believe works with one TODO in there that needs investigation due to a question about the current historical zipimport code. ---------- Added file: http://bugs.python.org/file33614/issue19081-subimport-fix-gps02.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 11:31:29 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Jan 2014 10:31:29 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> Message-ID: <1390386689.04.0.659366003511.issue20341@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > I don't remember who specifically needed the nullable ints, so I just added a bunch of Derby contestants. There are no much need in nullable ints, if they are needed, different use cases require different semantic. I don't think we can now write general converters which will cover different use cases. May be in 3.5, when behavior changes will be possible. I know only one use case for nullable Py_ssize_t converter (and mmap_convert_ssize_t is much simpler). itertolls.repeat doesn't need it, because it shouldn't accept None. Let defer this issue until most of code will be converted. Then we can accumulate statistic about nullable in converters. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 11:35:08 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Jan 2014 10:35:08 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> Message-ID: <1390386908.54.0.152255626115.issue20341@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And thank you for the fix for the __init__ methods. Could you please commit it? The I'll update patches for bz2 and lzma modules. Looks as Vajrasky Kok has encountered with yet one bug in generated __init__ wrapper(issue20185). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 11:39:16 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 22 Jan 2014 10:39:16 +0000 Subject: [issue20342] Float rounding issues on Red Hat 6.4 / PPC64 / GCC 4.4.6 In-Reply-To: <1390380271.48.0.67555288445.issue20342@psf.upfronthosting.co.za> Message-ID: <1390387156.44.0.358982470137.issue20342@psf.upfronthosting.co.za> STINNER Victor added the comment: According to what Yury told me on IRC, it's a cross-compilation issue. He wrote me that the following commands returns b'C?\xff\x01\x02\x03\x04\x05' which is the double big endian version, but DOUBLE_IS_BIG_ENDIAN_IEEE754 is not defined from pyconfig.h ./python -c 'import struct; print(ascii(struct.pack("d", 9006104071832581.0)))' ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 11:47:06 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Jan 2014 10:47:06 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> Message-ID: <1390387626.67.0.631958940789.issue20341@psf.upfronthosting.co.za> Larry Hastings added the comment: Then you disagree with Guido, who says that optional integer arguments without a viable publishable default value should accept None to mean "use the default value": https://mail.python.org/pipermail/python-dev/2014-January/131673.html https://mail.python.org/pipermail/python-dev/2014-January/131711.html There are a fair number of places where people are abusing positional parameters because they can't specify a good default. I plan to put a stop to that, but first I need to give them a viable alternative. In the specific case of itertools.repeat, I'm going to talk to the maintainer about what he wants to do. The current behavior is too magic for Python and iiuc Guido regards it as a bug. My guess is a default of None, as the author was deliberately preventing you from passing in -1. But we shall see. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 11:51:16 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Jan 2014 10:51:16 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1390387876.41.0.153209812011.issue20185@psf.upfronthosting.co.za> Larry Hastings added the comment: I'll fix the "return NULL" problem. However, you are using optional groups in the list __init__. The original doesn't use them. Please stop using optional groups in functions that don't require them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 11:55:13 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Jan 2014 10:55:13 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390387626.67.0.631958940789.issue20341@psf.upfronthosting.co.za> Message-ID: <1609931.lSv2fzWur0@raxxla> Serhiy Storchaka added the comment: I thought it was too late for 3.4, and the conversion should not change the behavior (we can change the behavior later in 3.5). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 11:58:40 2014 From: report at bugs.python.org (Fabian Kochem) Date: Wed, 22 Jan 2014 10:58:40 +0000 Subject: [issue8876] distutils should not assume that hardlinks will work In-Reply-To: <1275485916.86.0.44676570948.issue8876@psf.upfronthosting.co.za> Message-ID: <1390388320.89.0.819371148229.issue8876@psf.upfronthosting.co.za> Fabian Kochem added the comment: ?ric said that he should be able to get to it soon.: https://twitter.com/merwok_/status/425596183176704002 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 11:58:41 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Jan 2014 10:58:41 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> Message-ID: <1390388321.12.0.121154173076.issue20341@psf.upfronthosting.co.za> Larry Hastings added the comment: I guess we should ask Guido for clarification. But I got the impression that we could *gently* tweak the signatures of functions if they were not representable in Python syntax. He thought that giving the parameter of _sha1.sha1() a default value of b'' was fine for example, and in the case of itertools.repeat he considered the behavior so odd he was guessing it was a bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 12:04:40 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Jan 2014 11:04:40 +0000 Subject: [issue20260] Argument Clinic: add unsigned integers converters In-Reply-To: <1389720718.78.0.860738296491.issue20260@psf.upfronthosting.co.za> Message-ID: <1390388680.24.0.741652097756.issue20260@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think that we do not yet have enough data. Too little cases are known for which unsigned integer converters are needed, and different cases require a different behavior. I prefer to defer until we convert the majority of the code. Then we will see what behavior is most prevalent. We even can change and unify behavior in 3.5. There is no hurry. We can use in each module its own Converter (if needed). There should not be many such places. ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 12:05:09 2014 From: report at bugs.python.org (=?utf-8?q?Christian_P=C3=A9rez?=) Date: Wed, 22 Jan 2014 11:05:09 +0000 Subject: [issue20343] zipfile truncates extracted files Message-ID: <1390388709.51.0.241436659403.issue20343@psf.upfronthosting.co.za> New submission from Christian P?rez: To reproduce the error: $ wget http://dbnsfp.houstonbioinformatics.org/dbNSFPzip/dbNSFP2.0.zip $ python Python 2.7.4 (default, Sep 26 2013, 03:20:26) [GCC 4.7.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from zipfile import ZipFile >>> >>> with ZipFile("dbNSFP2.0.zip", "r") as zf: ... with zf.open("dbNSFP2.0_variant.chr20", "U") as f: ... count = 0 ... for line in f: ... count += 1 ... >>> print count 964352 $ unzip -p dbNSFP2.0.zip dbNSFP2.0_variant.chr20 | wc -l 2161277 may it be related to issue 6759 ? ---------- components: Library (Lib) messages: 208779 nosy: Christian.P?rez priority: normal severity: normal status: open title: zipfile truncates extracted files type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 12:06:36 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Jan 2014 11:06:36 +0000 Subject: [issue20343] zipfile truncates extracted files In-Reply-To: <1390388709.51.0.241436659403.issue20343@psf.upfronthosting.co.za> Message-ID: <1390388796.49.0.949437085476.issue20343@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 12:07:54 2014 From: report at bugs.python.org (Yury V. Zaytsev) Date: Wed, 22 Jan 2014 11:07:54 +0000 Subject: [issue20342] Endianness not detected correctly due to AC_RUN_IFELSE macros In-Reply-To: <1390380271.48.0.67555288445.issue20342@psf.upfronthosting.co.za> Message-ID: <1390388874.62.0.00177606861019.issue20342@psf.upfronthosting.co.za> Yury V. Zaytsev added the comment: I've re-named the issue to reflect the problem. One possible solution that I can see is to use AC_C_BIGENDIAN macro, either exclusively, or only when cross-compiling. In the latest autoconf sources, this macro seems to try to detect the endianness from various macros, and then by grepping the produced object files, so it's safe to use during cross-compilation. Additionally, it allows to set the endianness by hand, if it can't be detected automatically. Any thoughts? ---------- nosy: +doko title: Float rounding issues on Red Hat 6.4 / PPC64 / GCC 4.4.6 -> Endianness not detected correctly due to AC_RUN_IFELSE macros _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 12:14:04 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Jan 2014 11:14:04 +0000 Subject: [issue20343] zipfile truncates extracted files In-Reply-To: <1390388709.51.0.241436659403.issue20343@psf.upfronthosting.co.za> Message-ID: <1390389244.63.0.296921876441.issue20343@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please test with in-development version Python 2.7.6+? Unlikely it is related to issue6759, but perhaps it is related to issue20048. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 12:25:25 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Jan 2014 11:25:25 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> Message-ID: <1390389925.15.0.150038436459.issue20341@psf.upfronthosting.co.za> Larry Hastings added the comment: Actually, the documented behavior of itertools.repeat() is that the "times" argument takes a default of None. Equivalent to: def repeat(object, times=None): ... http://docs.python.org/3/library/itertools.html#itertools.repeat ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 12:29:16 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Jan 2014 11:29:16 +0000 Subject: [issue20338] Idle: increase max calltip width In-Reply-To: <1390344102.42.0.241411598779.issue20338@psf.upfronthosting.co.za> Message-ID: <1390390156.11.0.149517057123.issue20338@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is no problem on Linux. I think wrapping will be more preferable. 200 columns looks to wide for tips. Perhaps in 3.4 we can use textwrap.wrap() with the max_lines argument. And left simple truncating in earlier versions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 12:43:54 2014 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 22 Jan 2014 11:43:54 +0000 Subject: [issue20321] ImportError when a module is created after a catched ImportError In-Reply-To: <1390276988.86.0.176640087742.issue20321@psf.upfronthosting.co.za> Message-ID: <1390391034.07.0.842945011463.issue20321@psf.upfronthosting.co.za> Ezio Melotti added the comment: > Because you inserted LIBDIR before it existed, import noticed it didn't > exist and so put None into sys.path_importer_cache[LIBDIR] I'm not familiar with sys.path_importer_cache, but what happens if instead of putting None, sys.path_importer_cache[LIBDIR] is not created at all? Will it check for LIBDIR next time an import is performed (possibly finding it if the dir has been created in the meanwhile)? If this check happens every time, I guess it will defeat the purpose of the cache in case of missing dirs (especially if the dir is never created -- but maybe this is an uncommon case and the optimization can be removed?). Another option could be to recheck empty dirs in the cache in case of ImportError, and then update the cache entry and retry the import if a new dir that didn't exist before is found. This would still have an overhead, but even in this case the slow down might be acceptable. If we can't find a compromise I guess we could add a note to the documentation, even though I'm not sure where. FTR in the original report the user was adding a dir to sys.path before extracting the content of a tar file (thus creating the added dir), and adding the dir after the extraction fixes the problem. I'm also attaching my version of the test case, that shows two possible "fixes" to the problem and is closer to the original report. ---------- Added file: http://bugs.python.org/file33615/issue20321.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 12:49:42 2014 From: report at bugs.python.org (Ram Rachum) Date: Wed, 22 Jan 2014 11:49:42 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390391382.21.0.0364637003384.issue20218@psf.upfronthosting.co.za> Ram Rachum added the comment: Patch attached. Is this good? ---------- keywords: +patch Added file: http://bugs.python.org/file33616/patch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 12:52:15 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 22 Jan 2014 11:52:15 +0000 Subject: [issue20342] Endianness not detected correctly due to AC_RUN_IFELSE macros In-Reply-To: <1390388874.62.0.00177606861019.issue20342@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: doko> One possible solution that I can see is to use AC_C_BIGENDIAN macro, either exclusively, or only when cross-compiling. This is wrong. The macro is not used to check the endian but to check the IEEE 754 implementation. The check is important to decide if David M. Gay's algorithm for "short float representation" can be used. See pyport.h: /* If we can't guarantee 53-bit precision, don't use the code in Python/dtoa.c, but fall back to standard code. This means that repr of a float will be long (17 sig digits). Realistically, there are two things that could go wrong: (1) doubles aren't IEEE 754 doubles, or (2) we're on x86 with the rounding precision set to 64-bits (extended precision), and we don't know how to change the rounding precision. */ #if !defined(DOUBLE_IS_LITTLE_ENDIAN_IEEE754) && \ !defined(DOUBLE_IS_BIG_ENDIAN_IEEE754) && \ !defined(DOUBLE_IS_ARM_MIXED_ENDIAN_IEEE754) #define PY_NO_SHORT_FLOAT_REPR #endif /* double rounding is symptomatic of use of extended precision on x86. If we're seeing double rounding, and we don't have any mechanism available for changing the FPU rounding precision, then don't use Python/dtoa.c. */ #if defined(X87_DOUBLE_ROUNDING) && !defined(HAVE_PY_SET_53BIT_PRECISION) #define PY_NO_SHORT_FLOAT_REPR #endif -- Python 3.4 already uses AC_C_BIGENDIAN in configure.ac, see how it is used in pyport.h. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 13:03:46 2014 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 22 Jan 2014 12:03:46 +0000 Subject: [issue17390] display python version on idle title bar In-Reply-To: <1362920194.83.0.464215113749.issue17390@psf.upfronthosting.co.za> Message-ID: <1390392226.42.0.902616528667.issue17390@psf.upfronthosting.co.za> Ezio Melotti added the comment: Why this issue has been closed even though people were still discussing it and submitting patches? Terry, can you check if the new patches should be applied? ---------- stage: needs patch -> patch review status: closed -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 13:08:02 2014 From: report at bugs.python.org (Jeremy Kloth) Date: Wed, 22 Jan 2014 12:08:02 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> Message-ID: <1390392482.54.0.938844565308.issue20341@psf.upfronthosting.co.za> Changes by Jeremy Kloth : ---------- nosy: +jkloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 13:08:28 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 22 Jan 2014 12:08:28 +0000 Subject: [issue20326] Argument Clinic should use a non-error-prone syntax to mark text signatures In-Reply-To: <1390298749.1.0.12762219489.issue20326@psf.upfronthosting.co.za> Message-ID: <1390392508.34.0.675800834502.issue20326@psf.upfronthosting.co.za> Nick Coghlan added the comment: Right, at the very least we want to handle positional only arguments (since PEP 362 also handles those). My one concern with using "def " as the prefix is the fact it's not actually Python syntax. How do you feel about using "sig: " as the prefix? That would still read sensibly even if you somehow got hold of the unaltered C level docstring rather than going through the properties. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 13:13:00 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 22 Jan 2014 12:13:00 +0000 Subject: [issue20326] Argument Clinic should use a non-error-prone syntax to mark text signatures In-Reply-To: <1390392508.34.0.675800834502.issue20326@psf.upfronthosting.co.za> Message-ID: <20140122121300.GA16826@sleipnir.bytereef.org> Stefan Krah added the comment: +1 for "sig: ". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 13:14:15 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Jan 2014 12:14:15 +0000 Subject: [issue20326] Argument Clinic should use a non-error-prone syntax to mark text signatures In-Reply-To: <1390298749.1.0.12762219489.issue20326@psf.upfronthosting.co.za> Message-ID: <1390392855.61.0.625055861338.issue20326@psf.upfronthosting.co.za> Larry Hastings added the comment: The fact that "def " isn't Python syntax is, if anything, a mild point in its favor. I don't want anyone hitting on this by accident. "sig:" isn't Python syntax either, and yet you yourself propose it ;-) How about "sig="? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 13:20:12 2014 From: report at bugs.python.org (=?utf-8?q?Christian_P=C3=A9rez?=) Date: Wed, 22 Jan 2014 12:20:12 +0000 Subject: [issue20343] zipfile truncates extracted files In-Reply-To: <1390388709.51.0.241436659403.issue20343@psf.upfronthosting.co.za> Message-ID: <1390393212.88.0.36083566531.issue20343@psf.upfronthosting.co.za> Christian P?rez added the comment: With 2.7.6+ works fine. Python 2.7.6+ (2.7:c28e07377b03, Jan 22 2014, 12:56:14) [GCC 4.7.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from zipfile import ZipFile [54979 refs] >>> [54979 refs] >>> with ZipFile("dbNSFP2.0.zip", "r") as zf: ... with zf.open("dbNSFP2.0_variant.chr20", "U") as f: ... count = 0 ... for line in f: ... count += 1 ... [55930 refs] >>> print count 2161277 [55930 refs] I tested it with Python 3.3 and works fine too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 13:23:48 2014 From: report at bugs.python.org (Fabian Kochem) Date: Wed, 22 Jan 2014 12:23:48 +0000 Subject: [issue8876] distutils should not assume that hardlinks will work In-Reply-To: <1275485916.86.0.44676570948.issue8876@psf.upfronthosting.co.za> Message-ID: <1390393428.65.0.99572463397.issue8876@psf.upfronthosting.co.za> Fabian Kochem added the comment: A dirty hack is to include this line at the top of your setup.py: del os.link ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 13:33:31 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 Jan 2014 12:33:31 +0000 Subject: [issue20317] ExitStack hang if enough nested exceptions In-Reply-To: <1390248489.02.0.0980821300277.issue20317@psf.upfronthosting.co.za> Message-ID: <3f8QyL2MYgz7LjM@mail.python.org> Roundup Robot added the comment: New changeset b3c2472c12a1 by Nick Coghlan in branch '3.3': Issue #20317: Don't create a reference loop in ExitStack http://hg.python.org/cpython/rev/b3c2472c12a1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 13:39:05 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 22 Jan 2014 12:39:05 +0000 Subject: [issue20317] ExitStack hang if enough nested exceptions In-Reply-To: <1390248489.02.0.0980821300277.issue20317@psf.upfronthosting.co.za> Message-ID: <1390394345.05.0.362448176368.issue20317@psf.upfronthosting.co.za> Nick Coghlan added the comment: Oh, that's quite neat. Because of the way _GeneratorContextManager works, the context is actually already set correctly on the thrown exceptions, but ExitStack is assuming it will be wrong. This means _fix_exception (part of ExitStack.__exit__) ends up setting the first exception's context to itself while handling the second exception, which then creates an infinite loop when attempting to handle the third exception. Hence why three is the magic number :) The existing tests didn't pick this up, because they just used callbacks for simplicity, and hence the context was wrong as expected. Commit incoming. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 13:50:12 2014 From: report at bugs.python.org (Tal Einat) Date: Wed, 22 Jan 2014 12:50:12 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> Message-ID: <1390395012.1.0.786365802308.issue20341@psf.upfronthosting.co.za> Tal Einat added the comment: Found two bugs in the draft patch in Objects/longobject.c: 1) In _PyLong_NullableIntConverter, there is no index variable, so the Py_DECREF and Py_XDECREF need to be removed from the end of the function. 2) In _PyLong_NullablePy_ssize_tConverter, the index variable will point to a Python object only when both if blocks are skipped. Therefore, the Py_XDECREF after "fail:" at the end of the function needs to be removed. With these two changes, I successfully used this patch to convert deque_init in Modules/_collectionsmodule.c, simplifying the input validation code considerably. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 13:57:44 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 22 Jan 2014 12:57:44 +0000 Subject: [issue20326] Argument Clinic should use a non-error-prone syntax to mark text signatures In-Reply-To: <1390298749.1.0.12762219489.issue20326@psf.upfronthosting.co.za> Message-ID: <1390395464.18.0.24134589934.issue20326@psf.upfronthosting.co.za> Nick Coghlan added the comment: That wasn't quite what I meant. "def (a, b, c)" *looks* like Python syntax (aside from the missing function name), but "def (a, b, c, /)" does not. So I consider "def " a misleading prefix. By contrast, neither of these looks like it is trying to be a valid function header, while still hinting strongly that it is signature related: "sig: (a, b, c)" "sig: (a, b, c, /)" I would also be fine with "sig=" (since humans shouldn't be reading this regardless): "sig=(a, b, c)" "sig=(a, b, c, /)" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 14:05:03 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 Jan 2014 13:05:03 +0000 Subject: [issue20317] ExitStack hang if enough nested exceptions In-Reply-To: <1390248489.02.0.0980821300277.issue20317@psf.upfronthosting.co.za> Message-ID: <3f8Rfk69jBz7LjV@mail.python.org> Roundup Robot added the comment: New changeset 46c3ea358784 by Nick Coghlan in branch 'default': Merge #20317 from 3.3 http://hg.python.org/cpython/rev/46c3ea358784 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 14:05:06 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Jan 2014 13:05:06 +0000 Subject: [issue20293] pydoc fails with the "unspecified" default value In-Reply-To: <1390045398.5.0.236293557583.issue20293@psf.upfronthosting.co.za> Message-ID: <1390395906.62.0.702778275737.issue20293@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Seems this is related issue: >>> import zlib, inspect >>> zlib.compressobj.__text_signature__ '(level=Z_DEFAULT_COMPRESSION, method=DEFLATED, wbits=MAX_WBITS, memLevel=DEF_MEM_LEVEL, strategy=Z_DEFAULT_STRATEGY, zdict=None)' >>> str(inspect.signature(zlib.compressobj)) '(level=-1, method=8, wbits=15, memLevel=8, strategy=0, zdict=None)' help(zlib.compress) shows the '(bytes, level=-1)' signature. inspect.signature() evaluates default values and instead of expected named constant it outputs numeric value which is often implementation detail. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 14:07:00 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Jan 2014 13:07:00 +0000 Subject: [issue20343] zipfile truncates extracted files In-Reply-To: <1390388709.51.0.241436659403.issue20343@psf.upfronthosting.co.za> Message-ID: <1390396020.83.0.25628961139.issue20343@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> out of date stage: -> committed/rejected status: open -> closed superseder: -> zipfile's readline() drops data in universal newline mode _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 14:10:17 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Jan 2014 13:10:17 +0000 Subject: [issue20343] zipfile truncates extracted files In-Reply-To: <1390388709.51.0.241436659403.issue20343@psf.upfronthosting.co.za> Message-ID: <1390396217.84.0.718726858425.issue20343@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your report Christian. This bug already fixed in issue20048. Wait for Python 2.7.7 bugfix release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 13:59:10 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Jan 2014 12:59:10 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1390152218.17.0.812801868121.issue20193@psf.upfronthosting.co.za> Message-ID: <3221044.rNR48axy1s@raxxla> Serhiy Storchaka added the comment: Thank you Nadeem for the review. Here are updated patches. Addressed Nadeem's comments. Compress and decompress objects in bz2 and lzma modules now use Argument Clinic for __init__ and to generate class docstring. I think these patches are ready to commit (except that the name of clinic file will be changed soon). The zlib module still suffer from a bug #20293. ---------- Added file: http://bugs.python.org/file33617/zlib_clinic.patch Added file: http://bugs.python.org/file33618/bz2_clinic.patch Added file: http://bugs.python.org/file33619/lzma_clinic.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r a62072cf50a2 Modules/zlibmodule.c --- a/Modules/zlibmodule.c Wed Jan 22 12:26:01 2014 +0100 +++ b/Modules/zlibmodule.c Wed Jan 22 14:49:18 2014 +0200 @@ -82,42 +82,13 @@ } /*[clinic input] +output preset file module zlib class zlib.Compress class zlib.Decompress [clinic start generated code]*/ /*[clinic end generated code: checksum=da39a3ee5e6b4b0d3255bfef95601890afd80709]*/ -PyDoc_STRVAR(compressobj__doc__, -"compressobj(level=-1, method=DEFLATED, wbits=15, memlevel=8,\n" -" strategy=Z_DEFAULT_STRATEGY[, zdict])\n" -" -- Return a compressor object.\n" -"\n" -"level is the compression level (an integer in the range 0-9; default is 6).\n" -"Higher compression levels are slower, but produce smaller results.\n" -"\n" -"method is the compression algorithm. If given, this must be DEFLATED.\n" -"\n" -"wbits is the base two logarithm of the window size (range: 8..15).\n" -"\n" -"memlevel controls the amount of memory used for internal compression state.\n" -"Valid values range from 1 to 9. Higher values result in higher memory usage,\n" -"faster compression, and smaller output.\n" -"\n" -"strategy is used to tune the compression algorithm. Possible values are\n" -"Z_DEFAULT_STRATEGY, Z_FILTERED, and Z_HUFFMAN_ONLY.\n" -"\n" -"zdict is the predefined compression dictionary - a sequence of bytes\n" -"containing subsequences that are likely to occur in the input data."); - -PyDoc_STRVAR(decompressobj__doc__, -"decompressobj([wbits[, zdict]]) -- Return a decompressor object.\n" -"\n" -"Optional arg wbits is the window buffer size.\n" -"\n" -"Optional arg zdict is the predefined compression dictionary. This must be\n" -"the same dictionary as used by the compressor that produced the input data."); - static compobject * newcompobject(PyTypeObject *type) { @@ -165,70 +136,20 @@ } /*[clinic input] +zlib.compress -zlib.compress bytes: Py_buffer Binary data to be compressed. - [ - level: int + level: int(c_default="Z_DEFAULT_COMPRESSION") = Z_DEFAULT_COMPRESSION Compression level, in 0-9. - ] / -Returns compressed string. - +Returns a bytes object containing compressed data. [clinic start generated code]*/ -PyDoc_STRVAR(zlib_compress__doc__, -"compress(bytes, [level])\n" -"Returns compressed string.\n" -"\n" -" bytes\n" -" Binary data to be compressed.\n" -" level\n" -" Compression level, in 0-9."); - -#define ZLIB_COMPRESS_METHODDEF \ - {"compress", (PyCFunction)zlib_compress, METH_VARARGS, zlib_compress__doc__}, - static PyObject * -zlib_compress_impl(PyModuleDef *module, Py_buffer *bytes, int group_right_1, int level); - -static PyObject * -zlib_compress(PyModuleDef *module, PyObject *args) -{ - PyObject *return_value = NULL; - Py_buffer bytes = {NULL, NULL}; - int group_right_1 = 0; - int level = 0; - - switch (PyTuple_GET_SIZE(args)) { - case 1: - if (!PyArg_ParseTuple(args, "y*:compress", &bytes)) - goto exit; - break; - case 2: - if (!PyArg_ParseTuple(args, "y*i:compress", &bytes, &level)) - goto exit; - group_right_1 = 1; - break; - default: - PyErr_SetString(PyExc_TypeError, "zlib.compress requires 1 to 2 arguments"); - goto exit; - } - return_value = zlib_compress_impl(module, &bytes, group_right_1, level); - -exit: - /* Cleanup for bytes */ - if (bytes.obj) - PyBuffer_Release(&bytes); - - return return_value; -} - -static PyObject * -zlib_compress_impl(PyModuleDef *module, Py_buffer *bytes, int group_right_1, int level) -/*[clinic end generated code: checksum=74648f97e6b9d3cc9cd568d47262d462bded7ed0]*/ +zlib_compress_impl(PyModuleDef *module, Py_buffer *bytes, int level) +/*[clinic end generated code: checksum=5d7dd4588788efd3516e5f4225050d6413632601]*/ { PyObject *ReturnVal = NULL; Byte *input, *output = NULL; @@ -236,9 +157,6 @@ int err; z_stream zst; - if (!group_right_1) - level = Z_DEFAULT_COMPRESSION; - if ((size_t)bytes->len > UINT_MAX) { PyErr_SetString(PyExc_OverflowError, "Size does not fit in an unsigned int"); @@ -312,6 +230,7 @@ class uint_converter(CConverter): type = 'unsigned int' converter = 'uint_converter' + c_ignored_default = "0" [python start generated code]*/ /*[python end generated code: checksum=da39a3ee5e6b4b0d3255bfef95601890afd80709]*/ @@ -347,35 +266,38 @@ return 1; } -PyDoc_STRVAR(decompress__doc__, -"decompress(string[, wbits[, bufsize]]) -- Return decompressed string.\n" -"\n" -"Optional arg wbits is the window buffer size. Optional arg bufsize is\n" -"the initial output buffer size."); +/*[clinic input] +zlib.decompress + + data: Py_buffer + Compressed data. + wbits: int(c_default="DEF_WBITS") = unspecified + The window buffer size. + bufsize: uint(c_default="DEFAULTALLOC") = unspecified + The initial output buffer size. + / + +Returns a bytes object containing the uncompressed data. +[clinic start generated code]*/ static PyObject * -PyZlib_decompress(PyObject *self, PyObject *args) +zlib_decompress_impl(PyModuleDef *module, Py_buffer *data, int wbits, unsigned int bufsize) +/*[clinic end generated code: checksum=9e5464e72df9cb5fee73df662dbcaed867e01d32]*/ { PyObject *result_str = NULL; - Py_buffer pinput; Byte *input; unsigned int length; int err; - int wsize=DEF_WBITS; - unsigned int bufsize = DEFAULTALLOC, new_bufsize; + unsigned int new_bufsize; z_stream zst; - if (!PyArg_ParseTuple(args, "y*|iO&:decompress", - &pinput, &wsize, uint_converter, &bufsize)) - return NULL; - - if ((size_t)pinput.len > UINT_MAX) { + if ((size_t)data->len > UINT_MAX) { PyErr_SetString(PyExc_OverflowError, "Size does not fit in an unsigned int"); goto error; } - input = pinput.buf; - length = (unsigned int)pinput.len; + input = data->buf; + length = (unsigned int)data->len; if (bufsize == 0) bufsize = 1; @@ -391,7 +313,7 @@ zst.zfree = PyZlib_Free; zst.next_out = (Byte *)PyBytes_AS_STRING(result_str); zst.next_in = (Byte *)input; - err = inflateInit2(&zst, wsize); + err = inflateInit2(&zst, wbits); switch(err) { case(Z_OK): @@ -457,32 +379,45 @@ if (_PyBytes_Resize(&result_str, zst.total_out) < 0) goto error; - PyBuffer_Release(&pinput); return result_str; error: - PyBuffer_Release(&pinput); Py_XDECREF(result_str); return NULL; } +/*[clinic input] +zlib.compressobj + + level: int(c_default="Z_DEFAULT_COMPRESSION") = Z_DEFAULT_COMPRESSION + The compression level (an integer in the range 0-9; default is 6). + Higher compression levels are slower, but produce smaller results. + method: int(c_default="DEFLATED") = DEFLATED + The compression algorithm. If given, this must be DEFLATED. + wbits: int(c_default="MAX_WBITS") = MAX_WBITS + The base two logarithm of the window size (range: 8..15). + memLevel: int(c_default="DEF_MEM_LEVEL") = DEF_MEM_LEVEL + Controls the amount of memory used for internal compression state. + Valid values range from 1 to 9. Higher values result in higher memory + usage, faster compression, and smaller output. + strategy: int(c_default="Z_DEFAULT_STRATEGY") = Z_DEFAULT_STRATEGY + Used to tune the compression algorithm. Possible values are + Z_DEFAULT_STRATEGY, Z_FILTERED, and Z_HUFFMAN_ONLY. + zdict: Py_buffer = None + The predefined compression dictionary - a sequence of bytes + containing subsequences that are likely to occur in the input data. + +Return a compressor object. +[clinic start generated code]*/ + static PyObject * -PyZlib_compressobj(PyObject *selfptr, PyObject *args, PyObject *kwargs) +zlib_compressobj_impl(PyModuleDef *module, int level, int method, int wbits, int memLevel, int strategy, Py_buffer *zdict) +/*[clinic end generated code: checksum=89e5a6c1449caa9ed76f1baad066600e985151a9]*/ { compobject *self = NULL; - int level=Z_DEFAULT_COMPRESSION, method=DEFLATED; - int wbits=MAX_WBITS, memLevel=DEF_MEM_LEVEL, strategy=0, err; - Py_buffer zdict; - static char *kwlist[] = {"level", "method", "wbits", - "memLevel", "strategy", "zdict", NULL}; + int err; - zdict.buf = NULL; /* Sentinel, so we can tell whether zdict was supplied. */ - if (!PyArg_ParseTupleAndKeywords(args, kwargs, "|iiiiiy*:compressobj", - kwlist, &level, &method, &wbits, - &memLevel, &strategy, &zdict)) - return NULL; - - if (zdict.buf != NULL && (size_t)zdict.len > UINT_MAX) { + if (zdict->buf != NULL && (size_t)zdict->len > UINT_MAX) { PyErr_SetString(PyExc_OverflowError, "zdict length does not fit in an unsigned int"); goto error; @@ -500,11 +435,11 @@ switch(err) { case (Z_OK): self->is_initialised = 1; - if (zdict.buf == NULL) { + if (zdict->buf == NULL) { goto success; } else { err = deflateSetDictionary(&self->zst, - zdict.buf, (unsigned int)zdict.len); + zdict->buf, (unsigned int)zdict->len); switch (err) { case (Z_OK): goto success; @@ -532,22 +467,28 @@ Py_XDECREF(self); self = NULL; success: - if (zdict.buf != NULL) - PyBuffer_Release(&zdict); return (PyObject*)self; } +/*[clinic input] +zlib.decompressobj + + wbits: int(c_default="DEF_WBITS") = unspecified + The window buffer size. + zdict: object(c_default="NULL") = unspecified + The predefined compression dictionary. This must be the same + dictionary as used by the compressor that produced the input data. + +Return a decompressor object. +[clinic start generated code]*/ + static PyObject * -PyZlib_decompressobj(PyObject *selfptr, PyObject *args, PyObject *kwargs) +zlib_decompressobj_impl(PyModuleDef *module, int wbits, PyObject *zdict) +/*[clinic end generated code: checksum=8ccd583fbd631798566d415933cd44440c8a74b5]*/ { - static char *kwlist[] = {"wbits", "zdict", NULL}; - int wbits=DEF_WBITS, err; + int err; compobject *self; - PyObject *zdict=NULL; - if (!PyArg_ParseTupleAndKeywords(args, kwargs, "|iO:decompressobj", - kwlist, &wbits, &zdict)) - return NULL; if (zdict != NULL && !PyObject_CheckBuffer(zdict)) { PyErr_SetString(PyExc_TypeError, "zdict argument must support the buffer protocol"); @@ -615,37 +556,42 @@ Dealloc(self); } -PyDoc_STRVAR(comp_compress__doc__, -"compress(data) -- Return a string containing data compressed.\n" -"\n" -"After calling this function, some of the input data may still\n" -"be stored in internal buffers for later processing.\n" -"Call the flush() method to clear these buffers."); +/*[clinic input] +zlib.Compress.compress + self: self(type="compobject *") + data: Py_buffer + Binary data to be compressed. + / + +Returns a bytes object containing compressed data. + +After calling this function, some of the input data may still +be stored in internal buffers for later processing. +Call the flush() method to clear these buffers. +[clinic start generated code]*/ static PyObject * -PyZlib_objcompress(compobject *self, PyObject *args) +zlib_Compress_compress_impl(compobject *self, Py_buffer *data) +/*[clinic end generated code: checksum=5d5cd791cbc6a7f4b6de4ec12c085c88d4d3e31c]*/ { int err; unsigned int inplen; unsigned int length = DEFAULTALLOC, new_length; - PyObject *RetVal = NULL; - Py_buffer pinput; + PyObject *RetVal; Byte *input; unsigned long start_total_out; - if (!PyArg_ParseTuple(args, "y*:compress", &pinput)) - return NULL; - if ((size_t)pinput.len > UINT_MAX) { + if ((size_t)data->len > UINT_MAX) { PyErr_SetString(PyExc_OverflowError, "Size does not fit in an unsigned int"); - goto error_outer; + return NULL; } - input = pinput.buf; - inplen = (unsigned int)pinput.len; + input = data->buf; + inplen = (unsigned int)data->len; if (!(RetVal = PyBytes_FromStringAndSize(NULL, length))) - goto error_outer; + return NULL; ENTER_ZLIB(self); @@ -668,7 +614,7 @@ new_length = UINT_MAX; if (_PyBytes_Resize(&RetVal, new_length) < 0) { Py_CLEAR(RetVal); - goto error; + goto done; } self->zst.next_out = (unsigned char *)PyBytes_AS_STRING(RetVal) + length; @@ -686,18 +632,15 @@ if (err != Z_OK && err != Z_BUF_ERROR) { zlib_error(self->zst, err, "while compressing data"); - Py_DECREF(RetVal); - RetVal = NULL; - goto error; + Py_CLEAR(RetVal); + goto done; } if (_PyBytes_Resize(&RetVal, self->zst.total_out - start_total_out) < 0) { Py_CLEAR(RetVal); } - error: + done: LEAVE_ZLIB(self); - error_outer: - PyBuffer_Release(&pinput); return RetVal; } @@ -745,11 +688,9 @@ } /*[clinic input] - zlib.Decompress.decompress self: self(type="compobject *") - data: Py_buffer The binary data to decompress. max_length: uint = 0 @@ -758,58 +699,16 @@ the unconsumed_tail attribute. / -Return a string containing the decompressed version of the data. +Return a bytes object containing the decompressed version of the data. After calling this function, some of the input data may still be stored in internal buffers for later processing. Call the flush() method to clear these buffers. [clinic start generated code]*/ -PyDoc_STRVAR(zlib_Decompress_decompress__doc__, -"decompress(data, max_length=0)\n" -"Return a string containing the decompressed version of the data.\n" -"\n" -" data\n" -" The binary data to decompress.\n" -" max_length\n" -" The maximum allowable length of the decompressed data.\n" -" Unconsumed input data will be stored in\n" -" the unconsumed_tail attribute.\n" -"\n" -"After calling this function, some of the input data may still be stored in\n" -"internal buffers for later processing.\n" -"Call the flush() method to clear these buffers."); - -#define ZLIB_DECOMPRESS_DECOMPRESS_METHODDEF \ - {"decompress", (PyCFunction)zlib_Decompress_decompress, METH_VARARGS, zlib_Decompress_decompress__doc__}, - -static PyObject * -zlib_Decompress_decompress_impl(compobject *self, Py_buffer *data, unsigned int max_length); - -static PyObject * -zlib_Decompress_decompress(PyObject *self, PyObject *args) -{ - PyObject *return_value = NULL; - Py_buffer data = {NULL, NULL}; - unsigned int max_length = 0; - - if (!PyArg_ParseTuple(args, - "y*|O&:decompress", - &data, uint_converter, &max_length)) - goto exit; - return_value = zlib_Decompress_decompress_impl((compobject *)self, &data, max_length); - -exit: - /* Cleanup for data */ - if (data.obj) - PyBuffer_Release(&data); - - return return_value; -} - static PyObject * zlib_Decompress_decompress_impl(compobject *self, Py_buffer *data, unsigned int max_length) -/*[clinic end generated code: checksum=e0058024c4a97b411d2e2197791b89fde175f76f]*/ +/*[clinic end generated code: checksum=755cccc9087bfe55486b7e15fa7e2ab60b4c86d6]*/ { int err; unsigned int old_length, length = DEFAULTALLOC; @@ -929,29 +828,31 @@ return RetVal; } -PyDoc_STRVAR(comp_flush__doc__, -"flush( [mode] ) -- Return a string containing any remaining compressed data.\n" -"\n" -"mode can be one of the constants Z_SYNC_FLUSH, Z_FULL_FLUSH, Z_FINISH; the\n" -"default value used when mode is not specified is Z_FINISH.\n" -"If mode == Z_FINISH, the compressor object can no longer be used after\n" -"calling the flush() method. Otherwise, more data can still be compressed."); +/*[clinic input] +zlib.Compress.flush + + self: self(type="compobject *") + mode: int(c_default="Z_FINISH") = Z_FINISH + One of the constants Z_SYNC_FLUSH, Z_FULL_FLUSH, Z_FINISH. + If mode == Z_FINISH, the compressor object can no longer be used after + calling the flush() method. Otherwise, more data can still be compressed. + / + +Return a bytes object containing any remaining compressed data. +[clinic start generated code]*/ static PyObject * -PyZlib_flush(compobject *self, PyObject *args) +zlib_Compress_flush_impl(compobject *self, int mode) +/*[clinic end generated code: checksum=a203f4cefc9de727aa1d2ea39d11c0a16c32041a]*/ { int err; unsigned int length = DEFAULTALLOC, new_length; PyObject *RetVal; - int flushmode = Z_FINISH; unsigned long start_total_out; - if (!PyArg_ParseTuple(args, "|i:flush", &flushmode)) - return NULL; - /* Flushing with Z_NO_FLUSH is a no-op, so there's no point in doing any work at all; just return an empty string. */ - if (flushmode == Z_NO_FLUSH) { + if (mode == Z_NO_FLUSH) { return PyBytes_FromStringAndSize(NULL, 0); } @@ -966,7 +867,7 @@ self->zst.next_out = (unsigned char *)PyBytes_AS_STRING(RetVal); Py_BEGIN_ALLOW_THREADS - err = deflate(&(self->zst), flushmode); + err = deflate(&(self->zst), mode); Py_END_ALLOW_THREADS /* while Z_OK and the output buffer is full, there might be more output, @@ -986,14 +887,14 @@ length = new_length; Py_BEGIN_ALLOW_THREADS - err = deflate(&(self->zst), flushmode); + err = deflate(&(self->zst), mode); Py_END_ALLOW_THREADS } - /* If flushmode is Z_FINISH, we also have to call deflateEnd() to free + /* If mode is Z_FINISH, we also have to call deflateEnd() to free various data structures. Note we should only get Z_STREAM_END when - flushmode is Z_FINISH, but checking both for safety*/ - if (err == Z_STREAM_END && flushmode == Z_FINISH) { + mode is Z_FINISH, but checking both for safety*/ + if (err == Z_STREAM_END && mode == Z_FINISH) { err = deflateEnd(&(self->zst)); if (err != Z_OK) { zlib_error(self->zst, err, "while finishing compression"); @@ -1035,25 +936,9 @@ Return a copy of the compression object. [clinic start generated code]*/ -PyDoc_STRVAR(zlib_Compress_copy__doc__, -"copy()\n" -"Return a copy of the compression object."); - -#define ZLIB_COMPRESS_COPY_METHODDEF \ - {"copy", (PyCFunction)zlib_Compress_copy, METH_NOARGS, zlib_Compress_copy__doc__}, - -static PyObject * -zlib_Compress_copy_impl(compobject *self); - -static PyObject * -zlib_Compress_copy(PyObject *self, PyObject *Py_UNUSED(ignored)) -{ - return zlib_Compress_copy_impl((compobject *)self); -} - static PyObject * zlib_Compress_copy_impl(compobject *self) -/*[clinic end generated code: checksum=d57a7911deb7940e85a8d7e65af20b6e2df69000]*/ +/*[clinic end generated code: checksum=5144aa153c21e805afa5c19e5b48cf8e6480b5da]*/ { compobject *retval = NULL; int err; @@ -1103,11 +988,17 @@ return NULL; } -PyDoc_STRVAR(decomp_copy__doc__, -"copy() -- Return a copy of the decompression object."); +/*[clinic input] +zlib.Decompress.copy + + self: self(type="compobject *") + +Return a copy of the decompression object. +[clinic start generated code]*/ static PyObject * -PyZlib_uncopy(compobject *self) +zlib_Decompress_copy_impl(compobject *self) +/*[clinic end generated code: checksum=02a883a2a510c8ccfeef3f89e317a275bfe8c094]*/ { compobject *retval = NULL; int err; @@ -1159,24 +1050,27 @@ } #endif -PyDoc_STRVAR(decomp_flush__doc__, -"flush( [length] ) -- Return a string containing any remaining\n" -"decompressed data. length, if given, is the initial size of the\n" -"output buffer.\n" -"\n" -"The decompressor object can no longer be used after this call."); +/*[clinic input] +zlib.Decompress.flush + + self: self(type="compobject *") + length: uint(c_default="DEFAULTALLOC") = unspecified + the initial size of the output buffer. + / + +Return a bytes object containing any remaining decompressed data. +[clinic start generated code]*/ static PyObject * -PyZlib_unflush(compobject *self, PyObject *args) +zlib_Decompress_flush_impl(compobject *self, unsigned int length) +/*[clinic end generated code: checksum=db6fb753ab698e22afe3957c9da9e5e77f4bfc08]*/ { int err; - unsigned int length = DEFAULTALLOC, new_length; + unsigned int new_length; PyObject * retval = NULL; unsigned long start_total_out; Py_ssize_t size; - if (!PyArg_ParseTuple(args, "|O&:flush", uint_converter, &length)) - return NULL; if (length == 0) { PyErr_SetString(PyExc_ValueError, "length must be greater than zero"); return NULL; @@ -1252,12 +1146,12 @@ return retval; } +#include "zlibmodule.clinic.c" + static PyMethodDef comp_methods[] = { - {"compress", (binaryfunc)PyZlib_objcompress, METH_VARARGS, - comp_compress__doc__}, - {"flush", (binaryfunc)PyZlib_flush, METH_VARARGS, - comp_flush__doc__}, + ZLIB_COMPRESS_COMPRESS_METHODDEF + ZLIB_COMPRESS_FLUSH_METHODDEF #ifdef HAVE_ZLIB_COPY ZLIB_COMPRESS_COPY_METHODDEF #endif @@ -1267,11 +1161,9 @@ static PyMethodDef Decomp_methods[] = { ZLIB_DECOMPRESS_DECOMPRESS_METHODDEF - {"flush", (binaryfunc)PyZlib_unflush, METH_VARARGS, - decomp_flush__doc__}, + ZLIB_DECOMPRESS_FLUSH_METHODDEF #ifdef HAVE_ZLIB_COPY - {"copy", (PyCFunction)PyZlib_uncopy, METH_NOARGS, - decomp_copy__doc__}, + ZLIB_DECOMPRESS_COPY_METHODDEF #endif {NULL, NULL} }; @@ -1284,95 +1176,95 @@ {NULL}, }; -PyDoc_STRVAR(adler32__doc__, -"adler32(string[, start]) -- Compute an Adler-32 checksum of string.\n" -"\n" -"An optional starting value can be specified. The returned checksum is\n" -"an integer."); +/*[clinic input] +zlib.adler32 + + data: Py_buffer + value: unsigned_int(bitwise=True) = 1 + Starting value of the checksum. + / + +Compute an Adler-32 checksum of data. + +The returned checksum is an integer. +[clinic start generated code]*/ static PyObject * -PyZlib_adler32(PyObject *self, PyObject *args) +zlib_adler32_impl(PyModuleDef *module, Py_buffer *data, unsigned int value) +/*[clinic end generated code: checksum=51d6d75ee655c78af8c968fdb4c11d97e62c67d5]*/ { - unsigned int adler32val = 1; /* adler32(0L, Z_NULL, 0) */ - Py_buffer pbuf; - - if (!PyArg_ParseTuple(args, "y*|I:adler32", &pbuf, &adler32val)) - return NULL; /* Releasing the GIL for very small buffers is inefficient and may lower performance */ - if (pbuf.len > 1024*5) { - unsigned char *buf = pbuf.buf; - Py_ssize_t len = pbuf.len; + if (data->len > 1024*5) { + unsigned char *buf = data->buf; + Py_ssize_t len = data->len; Py_BEGIN_ALLOW_THREADS /* Avoid truncation of length for very large buffers. adler32() takes length as an unsigned int, which may be narrower than Py_ssize_t. */ while ((size_t)len > UINT_MAX) { - adler32val = adler32(adler32val, buf, UINT_MAX); + value = adler32(value, buf, UINT_MAX); buf += (size_t) UINT_MAX; len -= (size_t) UINT_MAX; } - adler32val = adler32(adler32val, buf, (unsigned int)len); + value = adler32(value, buf, (unsigned int)len); Py_END_ALLOW_THREADS } else { - adler32val = adler32(adler32val, pbuf.buf, (unsigned int)pbuf.len); + value = adler32(value, data->buf, (unsigned int)data->len); } - PyBuffer_Release(&pbuf); - return PyLong_FromUnsignedLong(adler32val & 0xffffffffU); + return PyLong_FromUnsignedLong(value & 0xffffffffU); } -PyDoc_STRVAR(crc32__doc__, -"crc32(string[, start]) -- Compute a CRC-32 checksum of string.\n" -"\n" -"An optional starting value can be specified. The returned checksum is\n" -"an integer."); +/*[clinic input] +zlib.crc32 + + data: Py_buffer + value: unsigned_int(bitwise=True) = 0 + Starting value of the checksum. + / + +Compute a CRC-32 checksum of data. + +The returned checksum is an integer. +[clinic start generated code]*/ static PyObject * -PyZlib_crc32(PyObject *self, PyObject *args) +zlib_crc32_impl(PyModuleDef *module, Py_buffer *data, unsigned int value) +/*[clinic end generated code: checksum=c1e986e74fe7b62369998a71a81ebeb9b73e8d4c]*/ { - unsigned int crc32val = 0; /* crc32(0L, Z_NULL, 0) */ - Py_buffer pbuf; int signed_val; - if (!PyArg_ParseTuple(args, "y*|I:crc32", &pbuf, &crc32val)) - return NULL; /* Releasing the GIL for very small buffers is inefficient and may lower performance */ - if (pbuf.len > 1024*5) { - unsigned char *buf = pbuf.buf; - Py_ssize_t len = pbuf.len; + if (data->len > 1024*5) { + unsigned char *buf = data->buf; + Py_ssize_t len = data->len; Py_BEGIN_ALLOW_THREADS /* Avoid truncation of length for very large buffers. crc32() takes length as an unsigned int, which may be narrower than Py_ssize_t. */ while ((size_t)len > UINT_MAX) { - crc32val = crc32(crc32val, buf, UINT_MAX); + value = crc32(value, buf, UINT_MAX); buf += (size_t) UINT_MAX; len -= (size_t) UINT_MAX; } - signed_val = crc32(crc32val, buf, (unsigned int)len); + signed_val = crc32(value, buf, (unsigned int)len); Py_END_ALLOW_THREADS } else { - signed_val = crc32(crc32val, pbuf.buf, (unsigned int)pbuf.len); + signed_val = crc32(value, data->buf, (unsigned int)data->len); } - PyBuffer_Release(&pbuf); return PyLong_FromUnsignedLong(signed_val & 0xffffffffU); } static PyMethodDef zlib_methods[] = { - {"adler32", (PyCFunction)PyZlib_adler32, METH_VARARGS, - adler32__doc__}, + ZLIB_ADLER32_METHODDEF ZLIB_COMPRESS_METHODDEF - {"compressobj", (PyCFunction)PyZlib_compressobj, METH_VARARGS|METH_KEYWORDS, - compressobj__doc__}, - {"crc32", (PyCFunction)PyZlib_crc32, METH_VARARGS, - crc32__doc__}, - {"decompress", (PyCFunction)PyZlib_decompress, METH_VARARGS, - decompress__doc__}, - {"decompressobj", (PyCFunction)PyZlib_decompressobj, METH_VARARGS|METH_KEYWORDS, - decompressobj__doc__}, + ZLIB_COMPRESSOBJ_METHODDEF + ZLIB_CRC32_METHODDEF + ZLIB_DECOMPRESS_METHODDEF + ZLIB_DECOMPRESSOBJ_METHODDEF {NULL, NULL} }; diff -r a62072cf50a2 Modules/zlibmodule.clinic.c --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Modules/zlibmodule.clinic.c Wed Jan 22 14:49:18 2014 +0200 @@ -0,0 +1,410 @@ +/*[clinic input] +preserve +[clinic start generated code]*/ + +PyDoc_STRVAR(zlib_compress__doc__, +"compress(bytes, level=Z_DEFAULT_COMPRESSION)\n" +"Returns a bytes object containing compressed data.\n" +"\n" +" bytes\n" +" Binary data to be compressed.\n" +" level\n" +" Compression level, in 0-9."); + +#define ZLIB_COMPRESS_METHODDEF \ + {"compress", (PyCFunction)zlib_compress, METH_VARARGS, zlib_compress__doc__}, + +static PyObject * +zlib_compress_impl(PyModuleDef *module, Py_buffer *bytes, int level); + +static PyObject * +zlib_compress(PyModuleDef *module, PyObject *args) +{ + PyObject *return_value = NULL; + Py_buffer bytes = {NULL, NULL}; + int level = Z_DEFAULT_COMPRESSION; + + if (!PyArg_ParseTuple(args, + "y*|i:compress", + &bytes, &level)) + goto exit; + return_value = zlib_compress_impl(module, &bytes, level); + +exit: + /* Cleanup for bytes */ + if (bytes.obj) + PyBuffer_Release(&bytes); + + return return_value; +} + +PyDoc_STRVAR(zlib_decompress__doc__, +"decompress(data, wbits=unspecified, bufsize=unspecified)\n" +"Returns a bytes object containing the uncompressed data.\n" +"\n" +" data\n" +" Compressed data.\n" +" wbits\n" +" The window buffer size.\n" +" bufsize\n" +" The initial output buffer size."); + +#define ZLIB_DECOMPRESS_METHODDEF \ + {"decompress", (PyCFunction)zlib_decompress, METH_VARARGS, zlib_decompress__doc__}, + +static PyObject * +zlib_decompress_impl(PyModuleDef *module, Py_buffer *data, int wbits, unsigned int bufsize); + +static PyObject * +zlib_decompress(PyModuleDef *module, PyObject *args) +{ + PyObject *return_value = NULL; + Py_buffer data = {NULL, NULL}; + int wbits = DEF_WBITS; + unsigned int bufsize = DEFAULTALLOC; + + if (!PyArg_ParseTuple(args, + "y*|iO&:decompress", + &data, &wbits, uint_converter, &bufsize)) + goto exit; + return_value = zlib_decompress_impl(module, &data, wbits, bufsize); + +exit: + /* Cleanup for data */ + if (data.obj) + PyBuffer_Release(&data); + + return return_value; +} + +PyDoc_STRVAR(zlib_compressobj__doc__, +"compressobj(level=Z_DEFAULT_COMPRESSION, method=DEFLATED, wbits=MAX_WBITS, memLevel=DEF_MEM_LEVEL, strategy=Z_DEFAULT_STRATEGY, zdict=None)\n" +"Return a compressor object.\n" +"\n" +" level\n" +" The compression level (an integer in the range 0-9; default is 6).\n" +" Higher compression levels are slower, but produce smaller results.\n" +" method\n" +" The compression algorithm. If given, this must be DEFLATED.\n" +" wbits\n" +" The base two logarithm of the window size (range: 8..15).\n" +" memLevel\n" +" Controls the amount of memory used for internal compression state.\n" +" Valid values range from 1 to 9. Higher values result in higher memory\n" +" usage, faster compression, and smaller output.\n" +" strategy\n" +" Used to tune the compression algorithm. Possible values are\n" +" Z_DEFAULT_STRATEGY, Z_FILTERED, and Z_HUFFMAN_ONLY.\n" +" zdict\n" +" The predefined compression dictionary - a sequence of bytes\n" +" containing subsequences that are likely to occur in the input data."); + +#define ZLIB_COMPRESSOBJ_METHODDEF \ + {"compressobj", (PyCFunction)zlib_compressobj, METH_VARARGS|METH_KEYWORDS, zlib_compressobj__doc__}, + +static PyObject * +zlib_compressobj_impl(PyModuleDef *module, int level, int method, int wbits, int memLevel, int strategy, Py_buffer *zdict); + +static PyObject * +zlib_compressobj(PyModuleDef *module, PyObject *args, PyObject *kwargs) +{ + PyObject *return_value = NULL; + static char *_keywords[] = {"level", "method", "wbits", "memLevel", "strategy", "zdict", NULL}; + int level = Z_DEFAULT_COMPRESSION; + int method = DEFLATED; + int wbits = MAX_WBITS; + int memLevel = DEF_MEM_LEVEL; + int strategy = Z_DEFAULT_STRATEGY; + Py_buffer zdict = {NULL, NULL}; + + if (!PyArg_ParseTupleAndKeywords(args, kwargs, + "|iiiiiy*:compressobj", _keywords, + &level, &method, &wbits, &memLevel, &strategy, &zdict)) + goto exit; + return_value = zlib_compressobj_impl(module, level, method, wbits, memLevel, strategy, &zdict); + +exit: + /* Cleanup for zdict */ + if (zdict.obj) + PyBuffer_Release(&zdict); + + return return_value; +} + +PyDoc_STRVAR(zlib_decompressobj__doc__, +"decompressobj(wbits=unspecified, zdict=unspecified)\n" +"Return a decompressor object.\n" +"\n" +" wbits\n" +" The window buffer size.\n" +" zdict\n" +" The predefined compression dictionary. This must be the same\n" +" dictionary as used by the compressor that produced the input data."); + +#define ZLIB_DECOMPRESSOBJ_METHODDEF \ + {"decompressobj", (PyCFunction)zlib_decompressobj, METH_VARARGS|METH_KEYWORDS, zlib_decompressobj__doc__}, + +static PyObject * +zlib_decompressobj_impl(PyModuleDef *module, int wbits, PyObject *zdict); + +static PyObject * +zlib_decompressobj(PyModuleDef *module, PyObject *args, PyObject *kwargs) +{ + PyObject *return_value = NULL; + static char *_keywords[] = {"wbits", "zdict", NULL}; + int wbits = DEF_WBITS; + PyObject *zdict = NULL; + + if (!PyArg_ParseTupleAndKeywords(args, kwargs, + "|iO:decompressobj", _keywords, + &wbits, &zdict)) + goto exit; + return_value = zlib_decompressobj_impl(module, wbits, zdict); + +exit: + return return_value; +} + +PyDoc_STRVAR(zlib_Compress_compress__doc__, +"compress(data)\n" +"Returns a bytes object containing compressed data.\n" +"\n" +" data\n" +" Binary data to be compressed.\n" +"\n" +"After calling this function, some of the input data may still\n" +"be stored in internal buffers for later processing.\n" +"Call the flush() method to clear these buffers."); + +#define ZLIB_COMPRESS_COMPRESS_METHODDEF \ + {"compress", (PyCFunction)zlib_Compress_compress, METH_VARARGS, zlib_Compress_compress__doc__}, + +static PyObject * +zlib_Compress_compress_impl(compobject *self, Py_buffer *data); + +static PyObject * +zlib_Compress_compress(PyObject *self, PyObject *args) +{ + PyObject *return_value = NULL; + Py_buffer data = {NULL, NULL}; + + if (!PyArg_ParseTuple(args, + "y*:compress", + &data)) + goto exit; + return_value = zlib_Compress_compress_impl((compobject *)self, &data); + +exit: + /* Cleanup for data */ + if (data.obj) + PyBuffer_Release(&data); + + return return_value; +} + +PyDoc_STRVAR(zlib_Decompress_decompress__doc__, +"decompress(data, max_length=0)\n" +"Return a bytes object containing the decompressed version of the data.\n" +"\n" +" data\n" +" The binary data to decompress.\n" +" max_length\n" +" The maximum allowable length of the decompressed data.\n" +" Unconsumed input data will be stored in\n" +" the unconsumed_tail attribute.\n" +"\n" +"After calling this function, some of the input data may still be stored in\n" +"internal buffers for later processing.\n" +"Call the flush() method to clear these buffers."); + +#define ZLIB_DECOMPRESS_DECOMPRESS_METHODDEF \ + {"decompress", (PyCFunction)zlib_Decompress_decompress, METH_VARARGS, zlib_Decompress_decompress__doc__}, + +static PyObject * +zlib_Decompress_decompress_impl(compobject *self, Py_buffer *data, unsigned int max_length); + +static PyObject * +zlib_Decompress_decompress(PyObject *self, PyObject *args) +{ + PyObject *return_value = NULL; + Py_buffer data = {NULL, NULL}; + unsigned int max_length = 0; + + if (!PyArg_ParseTuple(args, + "y*|O&:decompress", + &data, uint_converter, &max_length)) + goto exit; + return_value = zlib_Decompress_decompress_impl((compobject *)self, &data, max_length); + +exit: + /* Cleanup for data */ + if (data.obj) + PyBuffer_Release(&data); + + return return_value; +} + +PyDoc_STRVAR(zlib_Compress_flush__doc__, +"flush(mode=Z_FINISH)\n" +"Return a bytes object containing any remaining compressed data.\n" +"\n" +" mode\n" +" One of the constants Z_SYNC_FLUSH, Z_FULL_FLUSH, Z_FINISH.\n" +" If mode == Z_FINISH, the compressor object can no longer be used after\n" +" calling the flush() method. Otherwise, more data can still be compressed."); + +#define ZLIB_COMPRESS_FLUSH_METHODDEF \ + {"flush", (PyCFunction)zlib_Compress_flush, METH_VARARGS, zlib_Compress_flush__doc__}, + +static PyObject * +zlib_Compress_flush_impl(compobject *self, int mode); + +static PyObject * +zlib_Compress_flush(PyObject *self, PyObject *args) +{ + PyObject *return_value = NULL; + int mode = Z_FINISH; + + if (!PyArg_ParseTuple(args, + "|i:flush", + &mode)) + goto exit; + return_value = zlib_Compress_flush_impl((compobject *)self, mode); + +exit: + return return_value; +} + +PyDoc_STRVAR(zlib_Compress_copy__doc__, +"copy()\n" +"Return a copy of the compression object."); + +#define ZLIB_COMPRESS_COPY_METHODDEF \ + {"copy", (PyCFunction)zlib_Compress_copy, METH_NOARGS, zlib_Compress_copy__doc__}, + +static PyObject * +zlib_Compress_copy_impl(compobject *self); + +static PyObject * +zlib_Compress_copy(PyObject *self, PyObject *Py_UNUSED(ignored)) +{ + return zlib_Compress_copy_impl((compobject *)self); +} + +PyDoc_STRVAR(zlib_Decompress_copy__doc__, +"copy()\n" +"Return a copy of the decompression object."); + +#define ZLIB_DECOMPRESS_COPY_METHODDEF \ + {"copy", (PyCFunction)zlib_Decompress_copy, METH_NOARGS, zlib_Decompress_copy__doc__}, + +static PyObject * +zlib_Decompress_copy_impl(compobject *self); + +static PyObject * +zlib_Decompress_copy(PyObject *self, PyObject *Py_UNUSED(ignored)) +{ + return zlib_Decompress_copy_impl((compobject *)self); +} + +PyDoc_STRVAR(zlib_Decompress_flush__doc__, +"flush(length=unspecified)\n" +"Return a bytes object containing any remaining decompressed data.\n" +"\n" +" length\n" +" the initial size of the output buffer."); + +#define ZLIB_DECOMPRESS_FLUSH_METHODDEF \ + {"flush", (PyCFunction)zlib_Decompress_flush, METH_VARARGS, zlib_Decompress_flush__doc__}, + +static PyObject * +zlib_Decompress_flush_impl(compobject *self, unsigned int length); + +static PyObject * +zlib_Decompress_flush(PyObject *self, PyObject *args) +{ + PyObject *return_value = NULL; + unsigned int length = DEFAULTALLOC; + + if (!PyArg_ParseTuple(args, + "|O&:flush", + uint_converter, &length)) + goto exit; + return_value = zlib_Decompress_flush_impl((compobject *)self, length); + +exit: + return return_value; +} + +PyDoc_STRVAR(zlib_adler32__doc__, +"adler32(data, value=1)\n" +"Compute an Adler-32 checksum of data.\n" +"\n" +" value\n" +" Starting value of the checksum.\n" +"\n" +"The returned checksum is an integer."); + +#define ZLIB_ADLER32_METHODDEF \ + {"adler32", (PyCFunction)zlib_adler32, METH_VARARGS, zlib_adler32__doc__}, + +static PyObject * +zlib_adler32_impl(PyModuleDef *module, Py_buffer *data, unsigned int value); + +static PyObject * +zlib_adler32(PyModuleDef *module, PyObject *args) +{ + PyObject *return_value = NULL; + Py_buffer data = {NULL, NULL}; + unsigned int value = 1; + + if (!PyArg_ParseTuple(args, + "y*|I:adler32", + &data, &value)) + goto exit; + return_value = zlib_adler32_impl(module, &data, value); + +exit: + /* Cleanup for data */ + if (data.obj) + PyBuffer_Release(&data); + + return return_value; +} + +PyDoc_STRVAR(zlib_crc32__doc__, +"crc32(data, value=0)\n" +"Compute a CRC-32 checksum of data.\n" +"\n" +" value\n" +" Starting value of the checksum.\n" +"\n" +"The returned checksum is an integer."); + +#define ZLIB_CRC32_METHODDEF \ + {"crc32", (PyCFunction)zlib_crc32, METH_VARARGS, zlib_crc32__doc__}, + +static PyObject * +zlib_crc32_impl(PyModuleDef *module, Py_buffer *data, unsigned int value); + +static PyObject * +zlib_crc32(PyModuleDef *module, PyObject *args) +{ + PyObject *return_value = NULL; + Py_buffer data = {NULL, NULL}; + unsigned int value = 0; + + if (!PyArg_ParseTuple(args, + "y*|I:crc32", + &data, &value)) + goto exit; + return_value = zlib_crc32_impl(module, &data, value); + +exit: + /* Cleanup for data */ + if (data.obj) + PyBuffer_Release(&data); + + return return_value; +} +/*[clinic end generated code: checksum=cee24603deddbfd9966a9cf37adc73a6e7aef634]*/ -------------- next part -------------- diff -r a62072cf50a2 Modules/_bz2module.c --- a/Modules/_bz2module.c Wed Jan 22 12:26:01 2014 +0100 +++ b/Modules/_bz2module.c Wed Jan 22 14:49:47 2014 +0200 @@ -196,44 +196,61 @@ return NULL; } -PyDoc_STRVAR(BZ2Compressor_compress__doc__, -"compress(data) -> bytes\n" -"\n" -"Provide data to the compressor object. Returns a chunk of\n" -"compressed data if possible, or b'' otherwise.\n" -"\n" -"When you have finished providing data to the compressor, call the\n" -"flush() method to finish the compression process.\n"); +/*[clinic input] +output preset file +module bz2 +class bz2.BZ2Compressor +class bz2.BZ2Decompressor +[clinic start generated code]*/ +/*[clinic end generated code: checksum=da39a3ee5e6b4b0d3255bfef95601890afd80709]*/ + +#include "_bz2module.clinic.c" + +/*[clinic input] +bz2.BZ2Compressor.compress + + self: self(type="BZ2Compressor *") + data: Py_buffer + / + +Provide data to the compressor object. + +Returns a chunk of compressed data if possible, or b'' otherwise. + +When you have finished providing data to the compressor, call the +flush() method to finish the compression process. +[clinic start generated code]*/ static PyObject * -BZ2Compressor_compress(BZ2Compressor *self, PyObject *args) +bz2_BZ2Compressor_compress_impl(BZ2Compressor *self, Py_buffer *data) +/*[clinic end generated code: checksum=ee7e32540a3194b61bf10a81e214057760f366e2]*/ { - Py_buffer buffer; PyObject *result = NULL; - if (!PyArg_ParseTuple(args, "y*:compress", &buffer)) - return NULL; - ACQUIRE_LOCK(self); if (self->flushed) PyErr_SetString(PyExc_ValueError, "Compressor has been flushed"); else - result = compress(self, buffer.buf, buffer.len, BZ_RUN); + result = compress(self, data->buf, data->len, BZ_RUN); RELEASE_LOCK(self); - PyBuffer_Release(&buffer); return result; } -PyDoc_STRVAR(BZ2Compressor_flush__doc__, -"flush() -> bytes\n" -"\n" -"Finish the compression process. Returns the compressed data left\n" -"in internal buffers.\n" -"\n" -"The compressor object may not be used after this method is called.\n"); +/*[clinic input] +bz2.BZ2Compressor.flush + + self: self(type="BZ2Compressor *") + +Finish the compression process. + +Returns the compressed data left in internal buffers. + +The compressor object may not be used after this method is called. +[clinic start generated code]*/ static PyObject * -BZ2Compressor_flush(BZ2Compressor *self, PyObject *noargs) +bz2_BZ2Compressor_flush_impl(BZ2Compressor *self) +/*[clinic end generated code: checksum=174aede133d77dccb63a6a15d5ecdc5de77a03e9]*/ { PyObject *result = NULL; @@ -274,14 +291,25 @@ PyMem_RawFree(ptr); } +/*[clinic input] +bz2.BZ2Compressor.__init__ + + self: self(type="BZ2Compressor *") + compresslevel: int = 9 + Compression level, in 0-9. + / + +Create a compressor object for compressing data incrementally. + +For one-shot compression, use the compress() function instead. +[clinic start generated code]*/ + static int -BZ2Compressor_init(BZ2Compressor *self, PyObject *args, PyObject *kwargs) +bz2_BZ2Compressor___init___impl(BZ2Compressor *self, int compresslevel) +/*[clinic end generated code: checksum=423b8a96f6a06f68ddc45b2ab9dd60c792de9d25]*/ { - int compresslevel = 9; int bzerror; - if (!PyArg_ParseTuple(args, "|i:BZ2Compressor", &compresslevel)) - return -1; if (!(1 <= compresslevel && compresslevel <= 9)) { PyErr_SetString(PyExc_ValueError, "compresslevel must be between 1 and 9"); @@ -324,23 +352,7 @@ Py_TYPE(self)->tp_free((PyObject *)self); } -static PyMethodDef BZ2Compressor_methods[] = { - {"compress", (PyCFunction)BZ2Compressor_compress, METH_VARARGS, - BZ2Compressor_compress__doc__}, - {"flush", (PyCFunction)BZ2Compressor_flush, METH_NOARGS, - BZ2Compressor_flush__doc__}, - {"__getstate__", (PyCFunction)BZ2Compressor_getstate, METH_NOARGS}, - {NULL} -}; - -PyDoc_STRVAR(BZ2Compressor__doc__, -"BZ2Compressor(compresslevel=9)\n" -"\n" -"Create a compressor object for compressing data incrementally.\n" -"\n" -"compresslevel, if given, must be a number between 1 and 9.\n" -"\n" -"For one-shot compression, use the compress() function instead.\n"); +static PyMethodDef BZ2Compressor_methods[]; static PyTypeObject BZ2Compressor_Type = { PyVarObject_HEAD_INIT(NULL, 0) @@ -363,7 +375,7 @@ 0, /* tp_setattro */ 0, /* tp_as_buffer */ Py_TPFLAGS_DEFAULT, /* tp_flags */ - BZ2Compressor__doc__, /* tp_doc */ + bz2_BZ2Compressor___init____doc__, /* tp_doc */ 0, /* tp_traverse */ 0, /* tp_clear */ 0, /* tp_richcompare */ @@ -378,7 +390,7 @@ 0, /* tp_descr_get */ 0, /* tp_descr_set */ 0, /* tp_dictoffset */ - (initproc)BZ2Compressor_init, /* tp_init */ + bz2_BZ2Compressor___init__, /* tp_init */ 0, /* tp_alloc */ PyType_GenericNew, /* tp_new */ }; @@ -451,32 +463,34 @@ return NULL; } -PyDoc_STRVAR(BZ2Decompressor_decompress__doc__, -"decompress(data) -> bytes\n" -"\n" -"Provide data to the decompressor object. Returns a chunk of\n" -"decompressed data if possible, or b'' otherwise.\n" -"\n" -"Attempting to decompress data after the end of stream is reached\n" -"raises an EOFError. Any data found after the end of the stream\n" -"is ignored and saved in the unused_data attribute.\n"); +/*[clinic input] +bz2.BZ2Decompressor.decompress + + self: self(type="BZ2Decompressor *") + data: Py_buffer + / + +Provide data to the decompressor object. + +Returns a chunk of decompressed data if possible, or b'' otherwise. + +Attempting to decompress data after the end of stream is reached +raises an EOFError. Any data found after the end of the stream +is ignored and saved in the unused_data attribute. +[clinic start generated code]*/ static PyObject * -BZ2Decompressor_decompress(BZ2Decompressor *self, PyObject *args) +bz2_BZ2Decompressor_decompress_impl(BZ2Decompressor *self, Py_buffer *data) +/*[clinic end generated code: checksum=39f4c8064d9219f2bfd709fd9004487617588b32]*/ { - Py_buffer buffer; PyObject *result = NULL; - if (!PyArg_ParseTuple(args, "y*:decompress", &buffer)) - return NULL; - ACQUIRE_LOCK(self); if (self->eof) PyErr_SetString(PyExc_EOFError, "End of stream already reached"); else - result = decompress(self, buffer.buf, buffer.len); + result = decompress(self, data->buf, data->len); RELEASE_LOCK(self); - PyBuffer_Release(&buffer); return result; } @@ -488,14 +502,22 @@ return NULL; } +/*[clinic input] +bz2.BZ2Decompressor.__init__ + + self: self(type="BZ2Decompressor *") + +Create a decompressor object for decompressing data incrementally. + +For one-shot decompression, use the decompress() function instead. +[clinic start generated code]*/ + static int -BZ2Decompressor_init(BZ2Decompressor *self, PyObject *args, PyObject *kwargs) +bz2_BZ2Decompressor___init___impl(BZ2Decompressor *self) +/*[clinic end generated code: checksum=4d700522a687319e6afff0df15c8270d2a734d3f]*/ { int bzerror; - if (!PyArg_ParseTuple(args, ":BZ2Decompressor")) - return -1; - #ifdef WITH_THREAD self->lock = PyThread_allocate_lock(); if (self->lock == NULL) { @@ -535,9 +557,15 @@ Py_TYPE(self)->tp_free((PyObject *)self); } +static PyMethodDef BZ2Compressor_methods[] = { + BZ2_BZ2COMPRESSOR_COMPRESS_METHODDEF + BZ2_BZ2COMPRESSOR_FLUSH_METHODDEF + {"__getstate__", (PyCFunction)BZ2Compressor_getstate, METH_NOARGS}, + {NULL} +}; + static PyMethodDef BZ2Decompressor_methods[] = { - {"decompress", (PyCFunction)BZ2Decompressor_decompress, METH_VARARGS, - BZ2Decompressor_decompress__doc__}, + BZ2_BZ2DECOMPRESSOR_DECOMPRESS_METHODDEF {"__getstate__", (PyCFunction)BZ2Decompressor_getstate, METH_NOARGS}, {NULL} }; @@ -556,13 +584,6 @@ {NULL} }; -PyDoc_STRVAR(BZ2Decompressor__doc__, -"BZ2Decompressor()\n" -"\n" -"Create a decompressor object for decompressing data incrementally.\n" -"\n" -"For one-shot decompression, use the decompress() function instead.\n"); - static PyTypeObject BZ2Decompressor_Type = { PyVarObject_HEAD_INIT(NULL, 0) "_bz2.BZ2Decompressor", /* tp_name */ @@ -584,7 +605,7 @@ 0, /* tp_setattro */ 0, /* tp_as_buffer */ Py_TPFLAGS_DEFAULT, /* tp_flags */ - BZ2Decompressor__doc__, /* tp_doc */ + bz2_BZ2Decompressor___init____doc__, /* tp_doc */ 0, /* tp_traverse */ 0, /* tp_clear */ 0, /* tp_richcompare */ @@ -599,7 +620,7 @@ 0, /* tp_descr_get */ 0, /* tp_descr_set */ 0, /* tp_dictoffset */ - (initproc)BZ2Decompressor_init, /* tp_init */ + bz2_BZ2Decompressor___init__, /* tp_init */ 0, /* tp_alloc */ PyType_GenericNew, /* tp_new */ }; diff -r a62072cf50a2 Modules/_bz2module.clinic.c --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Modules/_bz2module.clinic.c Wed Jan 22 14:49:47 2014 +0200 @@ -0,0 +1,149 @@ +/*[clinic input] +preserve +[clinic start generated code]*/ + +PyDoc_STRVAR(bz2_BZ2Compressor_compress__doc__, +"compress(data)\n" +"Provide data to the compressor object.\n" +"\n" +"Returns a chunk of compressed data if possible, or b\'\' otherwise.\n" +"\n" +"When you have finished providing data to the compressor, call the\n" +"flush() method to finish the compression process."); + +#define BZ2_BZ2COMPRESSOR_COMPRESS_METHODDEF \ + {"compress", (PyCFunction)bz2_BZ2Compressor_compress, METH_VARARGS, bz2_BZ2Compressor_compress__doc__}, + +static PyObject * +bz2_BZ2Compressor_compress_impl(BZ2Compressor *self, Py_buffer *data); + +static PyObject * +bz2_BZ2Compressor_compress(PyObject *self, PyObject *args) +{ + PyObject *return_value = NULL; + Py_buffer data = {NULL, NULL}; + + if (!PyArg_ParseTuple(args, + "y*:compress", + &data)) + goto exit; + return_value = bz2_BZ2Compressor_compress_impl((BZ2Compressor *)self, &data); + +exit: + /* Cleanup for data */ + if (data.obj) + PyBuffer_Release(&data); + + return return_value; +} + +PyDoc_STRVAR(bz2_BZ2Compressor_flush__doc__, +"flush()\n" +"Finish the compression process.\n" +"\n" +"Returns the compressed data left in internal buffers.\n" +"\n" +"The compressor object may not be used after this method is called."); + +#define BZ2_BZ2COMPRESSOR_FLUSH_METHODDEF \ + {"flush", (PyCFunction)bz2_BZ2Compressor_flush, METH_NOARGS, bz2_BZ2Compressor_flush__doc__}, + +static PyObject * +bz2_BZ2Compressor_flush_impl(BZ2Compressor *self); + +static PyObject * +bz2_BZ2Compressor_flush(PyObject *self, PyObject *Py_UNUSED(ignored)) +{ + return bz2_BZ2Compressor_flush_impl((BZ2Compressor *)self); +} + +PyDoc_STRVAR(bz2_BZ2Compressor___init____doc__, +"BZ2Compressor(compresslevel=9)\n" +"Create a compressor object for compressing data incrementally.\n" +"\n" +" compresslevel\n" +" Compression level, in 0-9.\n" +"\n" +"For one-shot compression, use the compress() function instead."); + +static int +bz2_BZ2Compressor___init___impl(BZ2Compressor *self, int compresslevel); + +static int +bz2_BZ2Compressor___init__(PyObject *self, PyObject *args, PyObject *kwargs) +{ + int return_value = -1; + int compresslevel = 9; + + if (!_PyArg_NoKeywords("__init__", kwargs)) + goto exit; + if (!PyArg_ParseTuple(args, + "|i:__init__", + &compresslevel)) + goto exit; + return_value = bz2_BZ2Compressor___init___impl((BZ2Compressor *)self, compresslevel); + +exit: + return return_value; +} + +PyDoc_STRVAR(bz2_BZ2Decompressor_decompress__doc__, +"decompress(data)\n" +"Provide data to the decompressor object.\n" +"\n" +"Returns a chunk of decompressed data if possible, or b\'\' otherwise.\n" +"\n" +"Attempting to decompress data after the end of stream is reached\n" +"raises an EOFError. Any data found after the end of the stream\n" +"is ignored and saved in the unused_data attribute."); + +#define BZ2_BZ2DECOMPRESSOR_DECOMPRESS_METHODDEF \ + {"decompress", (PyCFunction)bz2_BZ2Decompressor_decompress, METH_VARARGS, bz2_BZ2Decompressor_decompress__doc__}, + +static PyObject * +bz2_BZ2Decompressor_decompress_impl(BZ2Decompressor *self, Py_buffer *data); + +static PyObject * +bz2_BZ2Decompressor_decompress(PyObject *self, PyObject *args) +{ + PyObject *return_value = NULL; + Py_buffer data = {NULL, NULL}; + + if (!PyArg_ParseTuple(args, + "y*:decompress", + &data)) + goto exit; + return_value = bz2_BZ2Decompressor_decompress_impl((BZ2Decompressor *)self, &data); + +exit: + /* Cleanup for data */ + if (data.obj) + PyBuffer_Release(&data); + + return return_value; +} + +PyDoc_STRVAR(bz2_BZ2Decompressor___init____doc__, +"BZ2Decompressor()\n" +"Create a decompressor object for decompressing data incrementally.\n" +"\n" +"For one-shot decompression, use the decompress() function instead."); + +static int +bz2_BZ2Decompressor___init___impl(BZ2Decompressor *self); + +static int +bz2_BZ2Decompressor___init__(PyObject *self, PyObject *args, PyObject *kwargs) +{ + int return_value = -1; + + if (!_PyArg_NoPositional("__init__", args)) + goto exit; + if (!_PyArg_NoKeywords("__init__", kwargs)) + goto exit; + return_value = bz2_BZ2Decompressor___init___impl((BZ2Decompressor *)self); + +exit: + return return_value; +} +/*[clinic end generated code: checksum=58449f6f9085faa460f2999f95f11b4f00b4871a]*/ -------------- next part -------------- diff -r a62072cf50a2 Modules/_lzmamodule.c --- a/Modules/_lzmamodule.c Wed Jan 22 12:26:01 2014 +0100 +++ b/Modules/_lzmamodule.c Wed Jan 22 14:49:43 2014 +0200 @@ -298,36 +298,37 @@ return options; } -static void * -parse_filter_spec(lzma_filter *f, PyObject *spec) +static int +lzma_filter_converter(PyObject *spec, void *ptr) { + lzma_filter *f = (lzma_filter *)ptr; PyObject *id_obj; if (!PyMapping_Check(spec)) { PyErr_SetString(PyExc_TypeError, "Filter specifier must be a dict or dict-like object"); - return NULL; + return 0; } id_obj = PyMapping_GetItemString(spec, "id"); if (id_obj == NULL) { if (PyErr_ExceptionMatches(PyExc_KeyError)) PyErr_SetString(PyExc_ValueError, "Filter specifier must have an \"id\" entry"); - return NULL; + return 0; } f->id = PyLong_AsUnsignedLongLong(id_obj); Py_DECREF(id_obj); if (PyErr_Occurred()) - return NULL; + return 0; switch (f->id) { case LZMA_FILTER_LZMA1: case LZMA_FILTER_LZMA2: f->options = parse_filter_spec_lzma(spec); - return f->options; + return f->options != NULL; case LZMA_FILTER_DELTA: f->options = parse_filter_spec_delta(spec); - return f->options; + return f->options != NULL; case LZMA_FILTER_X86: case LZMA_FILTER_POWERPC: case LZMA_FILTER_IA64: @@ -335,10 +336,10 @@ case LZMA_FILTER_ARMTHUMB: case LZMA_FILTER_SPARC: f->options = parse_filter_spec_bcj(spec); - return f->options; + return f->options != NULL; default: PyErr_Format(PyExc_ValueError, "Invalid filter ID: %llu", f->id); - return NULL; + return 0; } } @@ -369,7 +370,7 @@ for (i = 0; i < num_filters; i++) { int ok = 1; PyObject *spec = PySequence_GetItem(filterspecs, i); - if (spec == NULL || parse_filter_spec(&filters[i], spec) == NULL) + if (spec == NULL || !lzma_filter_converter(spec, &filters[i])) ok = 0; Py_XDECREF(spec); if (!ok) { @@ -468,6 +469,36 @@ } +/*[clinic input] +output preset file +module lzma +class lzma.LZMACompressor +class lzma.LZMADecompressor +[clinic start generated code]*/ +/*[clinic end generated code: checksum=da39a3ee5e6b4b0d3255bfef95601890afd80709]*/ + +#include "_lzmamodule.clinic.c" + +/*[python input] + +class lzma_vli_converter(CConverter): + type = 'lzma_vli' + converter = 'lzma_vli_converter' + +class lzma_filter_converter(CConverter): + type = 'lzma_filter' + converter = 'lzma_filter_converter' + c_default = c_ignored_default = "{LZMA_VLI_UNKNOWN, NULL}" + + def cleanup(self): + name = ensure_legal_c_identifier(self.name) + return ('if (%(name)s.id != LZMA_VLI_UNKNOWN)\n' + ' PyMem_Free(%(name)s.options);\n') % {'name': name} + +[python start generated code]*/ +/*[python end generated code: checksum=da39a3ee5e6b4b0d3255bfef95601890afd80709]*/ + + /* LZMACompressor class. */ static PyObject * @@ -512,44 +543,51 @@ return NULL; } -PyDoc_STRVAR(Compressor_compress_doc, -"compress(data) -> bytes\n" -"\n" -"Provide data to the compressor object. Returns a chunk of\n" -"compressed data if possible, or b\"\" otherwise.\n" -"\n" -"When you have finished providing data to the compressor, call the\n" -"flush() method to finish the conversion process.\n"); +/*[clinic input] +lzma.LZMACompressor.compress + + self: self(type="Compressor *") + data: Py_buffer + / + +Provide data to the compressor object. + +Returns a chunk of compressed data if possible, or b'' otherwise. + +When you have finished providing data to the compressor, call the +flush() method to finish the compression process. +[clinic start generated code]*/ static PyObject * -Compressor_compress(Compressor *self, PyObject *args) +lzma_LZMACompressor_compress_impl(Compressor *self, Py_buffer *data) +/*[clinic end generated code: checksum=a6c82b0b3892e151f9fc04f1b6a56566754de6b5]*/ { - Py_buffer buffer; PyObject *result = NULL; - if (!PyArg_ParseTuple(args, "y*:compress", &buffer)) - return NULL; - ACQUIRE_LOCK(self); if (self->flushed) PyErr_SetString(PyExc_ValueError, "Compressor has been flushed"); else - result = compress(self, buffer.buf, buffer.len, LZMA_RUN); + result = compress(self, data->buf, data->len, LZMA_RUN); RELEASE_LOCK(self); - PyBuffer_Release(&buffer); return result; } -PyDoc_STRVAR(Compressor_flush_doc, -"flush() -> bytes\n" -"\n" -"Finish the compression process. Returns the compressed data left\n" -"in internal buffers.\n" -"\n" -"The compressor object cannot be used after this method is called.\n"); +/*[clinic input] +lzma.LZMACompressor.flush + + self: self(type="Compressor *") + +Finish the compression process. + +Returns the compressed data left in internal buffers. + +The compressor object may not be used after this method is called. +[clinic start generated code]*/ static PyObject * -Compressor_flush(Compressor *self, PyObject *noargs) +lzma_LZMACompressor_flush_impl(Compressor *self) +/*[clinic end generated code: checksum=418006f2533b8ca25a3e2d7949769e05bb593cc9]*/ { PyObject *result = NULL; @@ -650,21 +688,47 @@ return 0; } +/*[clinic input] +lzma.LZMACompressor.__init__ + + self: self(type="Compressor *") + format: int(c_default="FORMAT_XZ") = FORMAT_XZ + The container format to use for the output. This can + be FORMAT_XZ (default), FORMAT_ALONE, or FORMAT_RAW. + + check: int(c_default="-1") = unspecified + The integrity check to use. For FORMAT_XZ, the default + is CHECK_CRC64. FORMAT_ALONE and FORMAT_RAW do not suport integrity + checks; for these formats, check must be omitted, or be CHECK_NONE. + + preset: object = None + If provided should be an integer in the range 0-9, optionally + OR-ed with the constant PRESET_EXTREME. + + filters: object = None + If provided should be a sequence of dicts. Each dict should + have an entry for "id" indicating the ID of the filter, plus + additional entries for options to the filter. + + / + +Create a compressor object for compressing data incrementally. + +The settings used by the compressor can be specified either as a +preset compression level (with the 'preset' argument), or in detail +as a custom filter chain (with the 'filters' argument). For FORMAT_XZ +and FORMAT_ALONE, the default is to use the PRESET_DEFAULT preset +level. For FORMAT_RAW, the caller must always specify a filter chain; +the raw compressor does not support preset compression levels. + +For one-shot compression, use the compress() function instead. +[clinic start generated code]*/ + static int -Compressor_init(Compressor *self, PyObject *args, PyObject *kwargs) +lzma_LZMACompressor___init___impl(Compressor *self, int format, int check, PyObject *preset, PyObject *filters) +/*[clinic end generated code: checksum=667dce31976a26146d9a2ab0212ffe52e5c5df32]*/ { - static char *arg_names[] = {"format", "check", "preset", "filters", NULL}; - int format = FORMAT_XZ; - int check = -1; - uint32_t preset = LZMA_PRESET_DEFAULT; - PyObject *preset_obj = Py_None; - PyObject *filterspecs = Py_None; - - if (!PyArg_ParseTupleAndKeywords(args, kwargs, - "|iiOO:LZMACompressor", arg_names, - &format, &check, &preset_obj, - &filterspecs)) - return -1; + uint32_t preset_ = LZMA_PRESET_DEFAULT; if (format != FORMAT_XZ && check != -1 && check != LZMA_CHECK_NONE) { PyErr_SetString(PyExc_ValueError, @@ -672,14 +736,14 @@ return -1; } - if (preset_obj != Py_None && filterspecs != Py_None) { + if (preset != Py_None && filters != Py_None) { PyErr_SetString(PyExc_ValueError, "Cannot specify both preset and filter chain"); return -1; } - if (preset_obj != Py_None) - if (!uint32_converter(preset_obj, &preset)) + if (preset != Py_None) + if (!uint32_converter(preset, &preset_)) return -1; self->alloc.opaque = NULL; @@ -700,17 +764,17 @@ case FORMAT_XZ: if (check == -1) check = LZMA_CHECK_CRC64; - if (Compressor_init_xz(&self->lzs, check, preset, filterspecs) != 0) + if (Compressor_init_xz(&self->lzs, check, preset_, filters) != 0) break; return 0; case FORMAT_ALONE: - if (Compressor_init_alone(&self->lzs, preset, filterspecs) != 0) + if (Compressor_init_alone(&self->lzs, preset_, filters) != 0) break; return 0; case FORMAT_RAW: - if (Compressor_init_raw(&self->lzs, filterspecs) != 0) + if (Compressor_init_raw(&self->lzs, filters) != 0) break; return 0; @@ -739,42 +803,12 @@ } static PyMethodDef Compressor_methods[] = { - {"compress", (PyCFunction)Compressor_compress, METH_VARARGS, - Compressor_compress_doc}, - {"flush", (PyCFunction)Compressor_flush, METH_NOARGS, - Compressor_flush_doc}, + LZMA_LZMACOMPRESSOR_COMPRESS_METHODDEF + LZMA_LZMACOMPRESSOR_FLUSH_METHODDEF {"__getstate__", (PyCFunction)Compressor_getstate, METH_NOARGS}, {NULL} }; -PyDoc_STRVAR(Compressor_doc, -"LZMACompressor(format=FORMAT_XZ, check=-1, preset=None, filters=None)\n" -"\n" -"Create a compressor object for compressing data incrementally.\n" -"\n" -"format specifies the container format to use for the output. This can\n" -"be FORMAT_XZ (default), FORMAT_ALONE, or FORMAT_RAW.\n" -"\n" -"check specifies the integrity check to use. For FORMAT_XZ, the default\n" -"is CHECK_CRC64. FORMAT_ALONE and FORMAT_RAW do not suport integrity\n" -"checks; for these formats, check must be omitted, or be CHECK_NONE.\n" -"\n" -"The settings used by the compressor can be specified either as a\n" -"preset compression level (with the 'preset' argument), or in detail\n" -"as a custom filter chain (with the 'filters' argument). For FORMAT_XZ\n" -"and FORMAT_ALONE, the default is to use the PRESET_DEFAULT preset\n" -"level. For FORMAT_RAW, the caller must always specify a filter chain;\n" -"the raw compressor does not support preset compression levels.\n" -"\n" -"preset (if provided) should be an integer in the range 0-9, optionally\n" -"OR-ed with the constant PRESET_EXTREME.\n" -"\n" -"filters (if provided) should be a sequence of dicts. Each dict should\n" -"have an entry for \"id\" indicating the ID of the filter, plus\n" -"additional entries for options to the filter.\n" -"\n" -"For one-shot compression, use the compress() function instead.\n"); - static PyTypeObject Compressor_type = { PyVarObject_HEAD_INIT(NULL, 0) "_lzma.LZMACompressor", /* tp_name */ @@ -796,7 +830,7 @@ 0, /* tp_setattro */ 0, /* tp_as_buffer */ Py_TPFLAGS_DEFAULT, /* tp_flags */ - Compressor_doc, /* tp_doc */ + lzma_LZMACompressor___init____doc__, /* tp_doc */ 0, /* tp_traverse */ 0, /* tp_clear */ 0, /* tp_richcompare */ @@ -811,7 +845,7 @@ 0, /* tp_descr_get */ 0, /* tp_descr_set */ 0, /* tp_dictoffset */ - (initproc)Compressor_init, /* tp_init */ + lzma_LZMACompressor___init__, /* tp_init */ 0, /* tp_alloc */ PyType_GenericNew, /* tp_new */ }; @@ -872,32 +906,34 @@ return NULL; } -PyDoc_STRVAR(Decompressor_decompress_doc, -"decompress(data) -> bytes\n" -"\n" -"Provide data to the decompressor object. Returns a chunk of\n" -"decompressed data if possible, or b\"\" otherwise.\n" -"\n" -"Attempting to decompress data after the end of the stream is\n" -"reached raises an EOFError. Any data found after the end of the\n" -"stream is ignored, and saved in the unused_data attribute.\n"); +/*[clinic input] +lzma.LZMADecompressor.decompress + + self: self(type="Decompressor *") + data: Py_buffer + / + +Provide data to the decompressor object. + +Returns a chunk of decompressed data if possible, or b'' otherwise. + +Attempting to decompress data after the end of stream is reached +raises an EOFError. Any data found after the end of the stream +is ignored and saved in the unused_data attribute. +[clinic start generated code]*/ static PyObject * -Decompressor_decompress(Decompressor *self, PyObject *args) +lzma_LZMADecompressor_decompress_impl(Decompressor *self, Py_buffer *data) +/*[clinic end generated code: checksum=24be3317e1ba0ef15cfa4aa0bf2d6f4dccc697b0]*/ { - Py_buffer buffer; PyObject *result = NULL; - if (!PyArg_ParseTuple(args, "y*:decompress", &buffer)) - return NULL; - ACQUIRE_LOCK(self); if (self->eof) PyErr_SetString(PyExc_EOFError, "Already at end of stream"); else - result = decompress(self, buffer.buf, buffer.len); + result = decompress(self, data->buf, data->len); RELEASE_LOCK(self); - PyBuffer_Release(&buffer); return result; } @@ -925,38 +961,58 @@ return 0; } +/*[clinic input] +lzma.LZMADecompressor.__init__ + + self: self(type="Decompressor *") + format: int(c_default="FORMAT_AUTO") = FORMAT_AUTO + Specifies the container format of the input stream. If this is + FORMAT_AUTO (the default), the decompressor will automatically detect + whether the input is FORMAT_XZ or FORMAT_ALONE. Streams created with + FORMAT_RAW cannot be autodetected. + + memlimit: object = None + Limit the amount of memory used by the decompressor. This will cause + decompression to fail if the input cannot be decompressed within the + given limit. + + filters: object = None + A custom filter chain. This argument is required for FORMAT_RAW, and + not accepted with any other format. When provided, this should be a + sequence of dicts, each indicating the ID and options for a single + filter. + + / + +Create a decompressor object for decompressing data incrementally. + +For one-shot decompression, use the decompress() function instead. +[clinic start generated code]*/ + static int -Decompressor_init(Decompressor *self, PyObject *args, PyObject *kwargs) +lzma_LZMADecompressor___init___impl(Decompressor *self, int format, PyObject *memlimit, PyObject *filters) +/*[clinic end generated code: checksum=19b6b5806ded26326e496f7fc193c53db24b0c9a]*/ { - static char *arg_names[] = {"format", "memlimit", "filters", NULL}; const uint32_t decoder_flags = LZMA_TELL_ANY_CHECK | LZMA_TELL_NO_CHECK; - int format = FORMAT_AUTO; - uint64_t memlimit = UINT64_MAX; - PyObject *memlimit_obj = Py_None; - PyObject *filterspecs = Py_None; + uint64_t memlimit_ = UINT64_MAX; lzma_ret lzret; - if (!PyArg_ParseTupleAndKeywords(args, kwargs, - "|iOO:LZMADecompressor", arg_names, - &format, &memlimit_obj, &filterspecs)) - return -1; - - if (memlimit_obj != Py_None) { + if (memlimit != Py_None) { if (format == FORMAT_RAW) { PyErr_SetString(PyExc_ValueError, "Cannot specify memory limit with FORMAT_RAW"); return -1; } - memlimit = PyLong_AsUnsignedLongLong(memlimit_obj); + memlimit_ = PyLong_AsUnsignedLongLong(memlimit); if (PyErr_Occurred()) return -1; } - if (format == FORMAT_RAW && filterspecs == Py_None) { + if (format == FORMAT_RAW && filters == Py_None) { PyErr_SetString(PyExc_ValueError, "Must specify filters for FORMAT_RAW"); return -1; - } else if (format != FORMAT_RAW && filterspecs != Py_None) { + } else if (format != FORMAT_RAW && filters != Py_None) { PyErr_SetString(PyExc_ValueError, "Cannot specify filters except with FORMAT_RAW"); return -1; @@ -982,27 +1038,27 @@ switch (format) { case FORMAT_AUTO: - lzret = lzma_auto_decoder(&self->lzs, memlimit, decoder_flags); + lzret = lzma_auto_decoder(&self->lzs, memlimit_, decoder_flags); if (catch_lzma_error(lzret)) break; return 0; case FORMAT_XZ: - lzret = lzma_stream_decoder(&self->lzs, memlimit, decoder_flags); + lzret = lzma_stream_decoder(&self->lzs, memlimit_, decoder_flags); if (catch_lzma_error(lzret)) break; return 0; case FORMAT_ALONE: self->check = LZMA_CHECK_NONE; - lzret = lzma_alone_decoder(&self->lzs, memlimit); + lzret = lzma_alone_decoder(&self->lzs, memlimit_); if (catch_lzma_error(lzret)) break; return 0; case FORMAT_RAW: self->check = LZMA_CHECK_NONE; - if (Decompressor_init_raw(&self->lzs, filterspecs) == -1) + if (Decompressor_init_raw(&self->lzs, filters) == -1) break; return 0; @@ -1034,8 +1090,7 @@ } static PyMethodDef Decompressor_methods[] = { - {"decompress", (PyCFunction)Decompressor_decompress, METH_VARARGS, - Decompressor_decompress_doc}, + LZMA_LZMADECOMPRESSOR_DECOMPRESS_METHODDEF {"__getstate__", (PyCFunction)Decompressor_getstate, METH_NOARGS}, {NULL} }; @@ -1059,27 +1114,6 @@ {NULL} }; -PyDoc_STRVAR(Decompressor_doc, -"LZMADecompressor(format=FORMAT_AUTO, memlimit=None, filters=None)\n" -"\n" -"Create a decompressor object for decompressing data incrementally.\n" -"\n" -"format specifies the container format of the input stream. If this is\n" -"FORMAT_AUTO (the default), the decompressor will automatically detect\n" -"whether the input is FORMAT_XZ or FORMAT_ALONE. Streams created with\n" -"FORMAT_RAW cannot be autodetected.\n" -"\n" -"memlimit can be specified to limit the amount of memory used by the\n" -"decompressor. This will cause decompression to fail if the input\n" -"cannot be decompressed within the given limit.\n" -"\n" -"filters specifies a custom filter chain. This argument is required for\n" -"FORMAT_RAW, and not accepted with any other format. When provided,\n" -"this should be a sequence of dicts, each indicating the ID and options\n" -"for a single filter.\n" -"\n" -"For one-shot decompression, use the decompress() function instead.\n"); - static PyTypeObject Decompressor_type = { PyVarObject_HEAD_INIT(NULL, 0) "_lzma.LZMADecompressor", /* tp_name */ @@ -1101,7 +1135,7 @@ 0, /* tp_setattro */ 0, /* tp_as_buffer */ Py_TPFLAGS_DEFAULT, /* tp_flags */ - Decompressor_doc, /* tp_doc */ + lzma_LZMADecompressor___init____doc__, /* tp_doc */ 0, /* tp_traverse */ 0, /* tp_clear */ 0, /* tp_richcompare */ @@ -1116,7 +1150,7 @@ 0, /* tp_descr_get */ 0, /* tp_descr_set */ 0, /* tp_dictoffset */ - (initproc)Decompressor_init, /* tp_init */ + lzma_LZMADecompressor___init__, /* tp_init */ 0, /* tp_alloc */ PyType_GenericNew, /* tp_new */ }; @@ -1124,48 +1158,42 @@ /* Module-level functions. */ -PyDoc_STRVAR(is_check_supported_doc, -"is_check_supported(check_id) -> bool\n" -"\n" -"Test whether the given integrity check is supported.\n" -"\n" -"Always returns True for CHECK_NONE and CHECK_CRC32.\n"); +/*[clinic input] +lzma.is_check_supported + check_id: int + / + +Test whether the given integrity check is supported. + +Always returns True for CHECK_NONE and CHECK_CRC32. +[clinic start generated code]*/ static PyObject * -is_check_supported(PyObject *self, PyObject *args) +lzma_is_check_supported_impl(PyModuleDef *module, int check_id) +/*[clinic end generated code: checksum=66986a6983dff2315fbe4e8b4ea79c8ed25c6406]*/ { - int check_id; - - if (!PyArg_ParseTuple(args, "i:is_check_supported", &check_id)) - return NULL; - return PyBool_FromLong(lzma_check_is_supported(check_id)); } -PyDoc_STRVAR(_encode_filter_properties_doc, -"_encode_filter_properties(filter) -> bytes\n" -"\n" -"Return a bytes object encoding the options (properties) of the filter\n" -"specified by *filter* (a dict).\n" -"\n" -"The result does not include the filter ID itself, only the options.\n"); +/*[clinic input] +lzma._encode_filter_properties + filter: lzma_filter(c_default="{LZMA_VLI_UNKNOWN, NULL}") + / + +Return a bytes object encoding the options (properties) of the filter specified by *filter* (a dict). + +The result does not include the filter ID itself, only the options. +[clinic start generated code]*/ static PyObject * -_encode_filter_properties(PyObject *self, PyObject *args) +lzma__encode_filter_properties_impl(PyModuleDef *module, lzma_filter filter) +/*[clinic end generated code: checksum=1c3f9391ea615088d00c0a855a7a02eca63890d4]*/ { - PyObject *filterspec; - lzma_filter filter; lzma_ret lzret; uint32_t encoded_size; PyObject *result = NULL; - if (!PyArg_ParseTuple(args, "O:_encode_filter_properties", &filterspec)) - return NULL; - - if (parse_filter_spec(&filter, filterspec) == NULL) - return NULL; - lzret = lzma_properties_size(&encoded_size, &filter); if (catch_lzma_error(lzret)) goto error; @@ -1179,37 +1207,36 @@ if (catch_lzma_error(lzret)) goto error; - PyMem_Free(filter.options); return result; error: Py_XDECREF(result); - PyMem_Free(filter.options); return NULL; } -PyDoc_STRVAR(_decode_filter_properties_doc, -"_decode_filter_properties(filter_id, encoded_props) -> dict\n" -"\n" -"Return a dict describing a filter with ID *filter_id*, and options\n" -"(properties) decoded from the bytes object *encoded_props*.\n"); +/*[clinic input] +lzma._decode_filter_properties + filter_id: lzma_vli + encoded_props: Py_buffer + / + +Return a bytes object encoding the options (properties) of the filter specified by *filter* (a dict). + +The result does not include the filter ID itself, only the options. +[clinic start generated code]*/ static PyObject * -_decode_filter_properties(PyObject *self, PyObject *args) +lzma__decode_filter_properties_impl(PyModuleDef *module, lzma_vli filter_id, Py_buffer *encoded_props) +/*[clinic end generated code: checksum=2ffdb2520c442a566fb814013370a58327040f84]*/ { - Py_buffer encoded_props; lzma_filter filter; lzma_ret lzret; PyObject *result = NULL; - - if (!PyArg_ParseTuple(args, "O&y*:_decode_filter_properties", - lzma_vli_converter, &filter.id, &encoded_props)) - return NULL; + filter.id = filter_id; lzret = lzma_properties_decode( - &filter, NULL, encoded_props.buf, encoded_props.len); - PyBuffer_Release(&encoded_props); + &filter, NULL, encoded_props->buf, encoded_props->len); if (catch_lzma_error(lzret)) return NULL; @@ -1225,12 +1252,9 @@ /* Module initialization. */ static PyMethodDef module_methods[] = { - {"is_check_supported", (PyCFunction)is_check_supported, - METH_VARARGS, is_check_supported_doc}, - {"_encode_filter_properties", (PyCFunction)_encode_filter_properties, - METH_VARARGS, _encode_filter_properties_doc}, - {"_decode_filter_properties", (PyCFunction)_decode_filter_properties, - METH_VARARGS, _decode_filter_properties_doc}, + LZMA_IS_CHECK_SUPPORTED_METHODDEF + LZMA__ENCODE_FILTER_PROPERTIES_METHODDEF + LZMA__DECODE_FILTER_PROPERTIES_METHODDEF {NULL} }; diff -r a62072cf50a2 Modules/_lzmamodule.clinic.c --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Modules/_lzmamodule.clinic.c Wed Jan 22 14:49:43 2014 +0200 @@ -0,0 +1,284 @@ +/*[clinic input] +preserve +[clinic start generated code]*/ + +PyDoc_STRVAR(lzma_LZMACompressor_compress__doc__, +"compress(data)\n" +"Provide data to the compressor object.\n" +"\n" +"Returns a chunk of compressed data if possible, or b\'\' otherwise.\n" +"\n" +"When you have finished providing data to the compressor, call the\n" +"flush() method to finish the compression process."); + +#define LZMA_LZMACOMPRESSOR_COMPRESS_METHODDEF \ + {"compress", (PyCFunction)lzma_LZMACompressor_compress, METH_VARARGS, lzma_LZMACompressor_compress__doc__}, + +static PyObject * +lzma_LZMACompressor_compress_impl(Compressor *self, Py_buffer *data); + +static PyObject * +lzma_LZMACompressor_compress(PyObject *self, PyObject *args) +{ + PyObject *return_value = NULL; + Py_buffer data = {NULL, NULL}; + + if (!PyArg_ParseTuple(args, + "y*:compress", + &data)) + goto exit; + return_value = lzma_LZMACompressor_compress_impl((Compressor *)self, &data); + +exit: + /* Cleanup for data */ + if (data.obj) + PyBuffer_Release(&data); + + return return_value; +} + +PyDoc_STRVAR(lzma_LZMACompressor_flush__doc__, +"flush()\n" +"Finish the compression process.\n" +"\n" +"Returns the compressed data left in internal buffers.\n" +"\n" +"The compressor object may not be used after this method is called."); + +#define LZMA_LZMACOMPRESSOR_FLUSH_METHODDEF \ + {"flush", (PyCFunction)lzma_LZMACompressor_flush, METH_NOARGS, lzma_LZMACompressor_flush__doc__}, + +static PyObject * +lzma_LZMACompressor_flush_impl(Compressor *self); + +static PyObject * +lzma_LZMACompressor_flush(PyObject *self, PyObject *Py_UNUSED(ignored)) +{ + return lzma_LZMACompressor_flush_impl((Compressor *)self); +} + +PyDoc_STRVAR(lzma_LZMACompressor___init____doc__, +"LZMACompressor(format=FORMAT_XZ, check=unspecified, preset=None, filters=None)\n" +"Create a compressor object for compressing data incrementally.\n" +"\n" +" format\n" +" The container format to use for the output. This can\n" +" be FORMAT_XZ (default), FORMAT_ALONE, or FORMAT_RAW.\n" +" check\n" +" The integrity check to use. For FORMAT_XZ, the default\n" +" is CHECK_CRC64. FORMAT_ALONE and FORMAT_RAW do not suport integrity\n" +" checks; for these formats, check must be omitted, or be CHECK_NONE.\n" +" preset\n" +" If provided should be an integer in the range 0-9, optionally\n" +" OR-ed with the constant PRESET_EXTREME.\n" +" filters\n" +" If provided should be a sequence of dicts. Each dict should\n" +" have an entry for \"id\" indicating the ID of the filter, plus\n" +" additional entries for options to the filter.\n" +"\n" +"The settings used by the compressor can be specified either as a\n" +"preset compression level (with the \'preset\' argument), or in detail\n" +"as a custom filter chain (with the \'filters\' argument). For FORMAT_XZ\n" +"and FORMAT_ALONE, the default is to use the PRESET_DEFAULT preset\n" +"level. For FORMAT_RAW, the caller must always specify a filter chain;\n" +"the raw compressor does not support preset compression levels.\n" +"\n" +"For one-shot compression, use the compress() function instead."); + +static int +lzma_LZMACompressor___init___impl(Compressor *self, int format, int check, PyObject *preset, PyObject *filters); + +static int +lzma_LZMACompressor___init__(PyObject *self, PyObject *args, PyObject *kwargs) +{ + int return_value = -1; + int format = FORMAT_XZ; + int check = -1; + PyObject *preset = Py_None; + PyObject *filters = Py_None; + + if (!_PyArg_NoKeywords("__init__", kwargs)) + goto exit; + if (!PyArg_ParseTuple(args, + "|iiOO:__init__", + &format, &check, &preset, &filters)) + goto exit; + return_value = lzma_LZMACompressor___init___impl((Compressor *)self, format, check, preset, filters); + +exit: + return return_value; +} + +PyDoc_STRVAR(lzma_LZMADecompressor_decompress__doc__, +"decompress(data)\n" +"Provide data to the decompressor object.\n" +"\n" +"Returns a chunk of decompressed data if possible, or b\'\' otherwise.\n" +"\n" +"Attempting to decompress data after the end of stream is reached\n" +"raises an EOFError. Any data found after the end of the stream\n" +"is ignored and saved in the unused_data attribute."); + +#define LZMA_LZMADECOMPRESSOR_DECOMPRESS_METHODDEF \ + {"decompress", (PyCFunction)lzma_LZMADecompressor_decompress, METH_VARARGS, lzma_LZMADecompressor_decompress__doc__}, + +static PyObject * +lzma_LZMADecompressor_decompress_impl(Decompressor *self, Py_buffer *data); + +static PyObject * +lzma_LZMADecompressor_decompress(PyObject *self, PyObject *args) +{ + PyObject *return_value = NULL; + Py_buffer data = {NULL, NULL}; + + if (!PyArg_ParseTuple(args, + "y*:decompress", + &data)) + goto exit; + return_value = lzma_LZMADecompressor_decompress_impl((Decompressor *)self, &data); + +exit: + /* Cleanup for data */ + if (data.obj) + PyBuffer_Release(&data); + + return return_value; +} + +PyDoc_STRVAR(lzma_LZMADecompressor___init____doc__, +"LZMADecompressor(format=FORMAT_AUTO, memlimit=None, filters=None)\n" +"Create a decompressor object for decompressing data incrementally.\n" +"\n" +" format\n" +" Specifies the container format of the input stream. If this is\n" +" FORMAT_AUTO (the default), the decompressor will automatically detect\n" +" whether the input is FORMAT_XZ or FORMAT_ALONE. Streams created with\n" +" FORMAT_RAW cannot be autodetected.\n" +" memlimit\n" +" Limit the amount of memory used by the decompressor. This will cause\n" +" decompression to fail if the input cannot be decompressed within the\n" +" given limit.\n" +" filters\n" +" A custom filter chain. This argument is required for FORMAT_RAW, and\n" +" not accepted with any other format. When provided, this should be a\n" +" sequence of dicts, each indicating the ID and options for a single\n" +" filter.\n" +"\n" +"For one-shot decompression, use the decompress() function instead."); + +static int +lzma_LZMADecompressor___init___impl(Decompressor *self, int format, PyObject *memlimit, PyObject *filters); + +static int +lzma_LZMADecompressor___init__(PyObject *self, PyObject *args, PyObject *kwargs) +{ + int return_value = -1; + int format = FORMAT_AUTO; + PyObject *memlimit = Py_None; + PyObject *filters = Py_None; + + if (!_PyArg_NoKeywords("__init__", kwargs)) + goto exit; + if (!PyArg_ParseTuple(args, + "|iOO:__init__", + &format, &memlimit, &filters)) + goto exit; + return_value = lzma_LZMADecompressor___init___impl((Decompressor *)self, format, memlimit, filters); + +exit: + return return_value; +} + +PyDoc_STRVAR(lzma_is_check_supported__doc__, +"is_check_supported(check_id)\n" +"Test whether the given integrity check is supported.\n" +"\n" +"Always returns True for CHECK_NONE and CHECK_CRC32."); + +#define LZMA_IS_CHECK_SUPPORTED_METHODDEF \ + {"is_check_supported", (PyCFunction)lzma_is_check_supported, METH_VARARGS, lzma_is_check_supported__doc__}, + +static PyObject * +lzma_is_check_supported_impl(PyModuleDef *module, int check_id); + +static PyObject * +lzma_is_check_supported(PyModuleDef *module, PyObject *args) +{ + PyObject *return_value = NULL; + int check_id; + + if (!PyArg_ParseTuple(args, + "i:is_check_supported", + &check_id)) + goto exit; + return_value = lzma_is_check_supported_impl(module, check_id); + +exit: + return return_value; +} + +PyDoc_STRVAR(lzma__encode_filter_properties__doc__, +"_encode_filter_properties(filter)\n" +"Return a bytes object encoding the options (properties) of the filter specified by *filter* (a dict).\n" +"\n" +"The result does not include the filter ID itself, only the options."); + +#define LZMA__ENCODE_FILTER_PROPERTIES_METHODDEF \ + {"_encode_filter_properties", (PyCFunction)lzma__encode_filter_properties, METH_VARARGS, lzma__encode_filter_properties__doc__}, + +static PyObject * +lzma__encode_filter_properties_impl(PyModuleDef *module, lzma_filter filter); + +static PyObject * +lzma__encode_filter_properties(PyModuleDef *module, PyObject *args) +{ + PyObject *return_value = NULL; + lzma_filter filter = {LZMA_VLI_UNKNOWN, NULL}; + + if (!PyArg_ParseTuple(args, + "O&:_encode_filter_properties", + lzma_filter_converter, &filter)) + goto exit; + return_value = lzma__encode_filter_properties_impl(module, filter); + +exit: + /* Cleanup for filter */ + if (filter.id != LZMA_VLI_UNKNOWN) + PyMem_Free(filter.options); + + return return_value; +} + +PyDoc_STRVAR(lzma__decode_filter_properties__doc__, +"_decode_filter_properties(filter_id, encoded_props)\n" +"Return a bytes object encoding the options (properties) of the filter specified by *filter* (a dict).\n" +"\n" +"The result does not include the filter ID itself, only the options."); + +#define LZMA__DECODE_FILTER_PROPERTIES_METHODDEF \ + {"_decode_filter_properties", (PyCFunction)lzma__decode_filter_properties, METH_VARARGS, lzma__decode_filter_properties__doc__}, + +static PyObject * +lzma__decode_filter_properties_impl(PyModuleDef *module, lzma_vli filter_id, Py_buffer *encoded_props); + +static PyObject * +lzma__decode_filter_properties(PyModuleDef *module, PyObject *args) +{ + PyObject *return_value = NULL; + lzma_vli filter_id; + Py_buffer encoded_props = {NULL, NULL}; + + if (!PyArg_ParseTuple(args, + "O&y*:_decode_filter_properties", + lzma_vli_converter, &filter_id, &encoded_props)) + goto exit; + return_value = lzma__decode_filter_properties_impl(module, filter_id, &encoded_props); + +exit: + /* Cleanup for encoded_props */ + if (encoded_props.obj) + PyBuffer_Release(&encoded_props); + + return return_value; +} +/*[clinic end generated code: checksum=66ee0c0b69a0f8b713dca135aa291cb0bfd4afb8]*/ From report at bugs.python.org Wed Jan 22 14:11:10 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Jan 2014 13:11:10 +0000 Subject: [issue20293] pydoc fails with the "unspecified" default value In-Reply-To: <1390045398.5.0.236293557583.issue20293@psf.upfronthosting.co.za> Message-ID: <1390396270.76.0.363099640794.issue20293@psf.upfronthosting.co.za> Larry Hastings added the comment: Yes, that is how it must work. This is symmetric with pure Python functions: >>> import inspect >>> import zlib >>> def foo(a=zlib.Z_DEFAULT_COMPRESSION): pass ... >>> str(inspect.signature(foo)) '(a=-1)' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 14:13:21 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Jan 2014 13:13:21 +0000 Subject: [issue20293] pydoc fails with the "unspecified" default value In-Reply-To: <1390045398.5.0.236293557583.issue20293@psf.upfronthosting.co.za> Message-ID: <1390396401.05.0.850423754007.issue20293@psf.upfronthosting.co.za> Larry Hastings added the comment: I missed the detail that you were working with a patch applied. I suspect the problem is, you misspelled one of the expressions you provided as a default value. Try str(inspect.signature(x)) on every function you converted. I bet one of them will throw an exception. Yes this is error-prone. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 14:14:57 2014 From: report at bugs.python.org (Tal Einat) Date: Wed, 22 Jan 2014 13:14:57 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za> Message-ID: <1390396497.76.0.00302872677693.issue20180@psf.upfronthosting.co.za> Tal Einat added the comment: Attached nearly complete conversion of Modules/_collectionsmodule.c. I've converted all functions using PyArg_* functions, including __new__ methods, but not deque.__init__. I'm attaching a separate patch for deque.__init__. ---------- Added file: http://bugs.python.org/file33620/_collectionsmodule.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 14:24:45 2014 From: report at bugs.python.org (Tal Einat) Date: Wed, 22 Jan 2014 13:24:45 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za> Message-ID: <1390397085.89.0.588953113369.issue20180@psf.upfronthosting.co.za> Tal Einat added the comment: Attached a patch converting deque.__init__ in Modules/_collectionsmodule.c, which completes the conversion of this file. This patch depends Larry's first patch in issue20341 (Argument Clinic: add "nullable ints"). This functionality is used to simplify the existing code for accepting None for the 'maxlen' argument to deque.__init__. If needed I can supply a patch which does not depend on Larry's patch. ---------- Added file: http://bugs.python.org/file33621/deque_init_with_nullable_Py_ssize_t.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 14:26:03 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Jan 2014 13:26:03 +0000 Subject: [issue20293] pydoc fails with the "unspecified" default value In-Reply-To: <1390396401.05.0.850423754007.issue20293@psf.upfronthosting.co.za> Message-ID: <3941338.dHdhqzGdmB@raxxla> Serhiy Storchaka added the comment: > Yes, that is how it must work. This is symmetric with pure Python functions: This is because in pure Python functions we have no enough information. I believe than origin expression is more useful in the help. Compare: >>> import re, inspect >>> p = re.compile('') >>> p.match.__text_signature__ '(string, pos=0, endpos=sys.maxsize)' >>> str(inspect.signature(p.match)) '(string, pos=0, endpos=2147483647)' > I suspect the problem is, you misspelled one of the expressions you provided > as a default value. >>> import zlib, inspect >>> zlib.decompress.__text_signature__ '(data, wbits=unspecified, bufsize=unspecified)' >>> str(inspect.signature(zlib.decompress)) Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/inspect.py", line 1997, in wrap_value value = eval(s, module_dict) File "", line 1, in NameError: name 'unspecified' is not defined During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/inspect.py", line 2000, in wrap_value value = eval(s, sys_module_dict) File "", line 1, in NameError: name 'unspecified' is not defined During handling of the above exception, another exception occurred: Traceback (most recent call last): File "", line 1, in File "/home/serhiy/py/cpython/Lib/inspect.py", line 1468, in signature return Signature.from_builtin(obj) File "/home/serhiy/py/cpython/Lib/inspect.py", line 2052, in from_builtin p(name, default) File "/home/serhiy/py/cpython/Lib/inspect.py", line 2038, in p default_node = RewriteSymbolics().visit(default_node) File "/home/serhiy/py/cpython/Lib/ast.py", line 245, in visit return visitor(node) File "/home/serhiy/py/cpython/Lib/inspect.py", line 2030, in visit_Name return wrap_value(node.id) File "/home/serhiy/py/cpython/Lib/inspect.py", line 2002, in wrap_value raise RuntimeError() RuntimeError ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 14:41:49 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Jan 2014 13:41:49 +0000 Subject: [issue20293] pydoc fails with the "unspecified" default value In-Reply-To: <1390045398.5.0.236293557583.issue20293@psf.upfronthosting.co.za> Message-ID: <1390398109.43.0.0864967963851.issue20293@psf.upfronthosting.co.za> Larry Hastings added the comment: > This is because in pure Python functions we have no enough > information. I believe than origin expression is more useful > in the help. That doesn't matter. inspect.Signature would have to change in order to provide the original expression, and it's not going to for 3.4. In zlib.decompress, remove the "= unspecified". You can have a c_default without a default value now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 14:44:43 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 22 Jan 2014 13:44:43 +0000 Subject: [issue20339] Make bytes() use tp_as_buffer for cmp In-Reply-To: <1390351229.22.0.995411790956.issue20339@psf.upfronthosting.co.za> Message-ID: <1390398283.21.0.873258635017.issue20339@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +ncoghlan, skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 14:52:34 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Jan 2014 13:52:34 +0000 Subject: [issue20293] pydoc fails with the "unspecified" default value In-Reply-To: <1390398109.43.0.0864967963851.issue20293@psf.upfronthosting.co.za> Message-ID: <2371188.jp80EuCQI9@raxxla> Serhiy Storchaka added the comment: Without the "= unspecified" parameters will be non-optional. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 14:53:08 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 22 Jan 2014 13:53:08 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> Message-ID: <1390398788.66.0.218654770118.issue20341@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Some things: - the concept of a nullable thing in Python doesn't exist; why not "optional"? - why is there a "error" field in the new structs? - the fact that the structs are defined in longobject.h looks bonkers - boolean fields can be "char" instead of "int" (and moved at the end to pack the structure more efficiently) - PyLong_AsSsize_t can't fail? - does this change have a performance impact? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 15:14:42 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Jan 2014 14:14:42 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> Message-ID: <1390400082.43.0.438750101478.issue20341@psf.upfronthosting.co.za> Larry Hastings added the comment: - the concept of a nullable thing in Python doesn't exist; why not "optional"? That's not what it means. Python parameters are "optional" if they have a default value. These parameters are "nullable", in the sense that they can be either of a specific type or "None". (But "Noneable" seemed like a bad name). They are not necessarily optional. My inspiration for the name was Nullable in C#: http://msdn.microsoft.com/en-us/library/1t3y8s4s.aspx Argument Clinic already has converters that support "nullable": str, UNICODE, and Py_buffer. These map to the semantics of 'z', 'S*', etc. I guess we could change it if it were a terrible name, but it isn't. > - why is there a "error" field in the new structs? It seemed like a good idea at the time. Maybe it's redundant. Can I get back to you? > - the fact that the structs are defined in longobject.h looks bonkers Okay. What would be better? modsupport.h? > - boolean fields can be "char" instead of "int" (and moved at the > end to pack the structure more efficiently) Is Python really compiled with packed structures? I assumed -O3 turned on dword alignment in structures. Aligned accesses are faster, and the additional memory use would be negligible. These will only ever be declared as stack variables in parsing functions. > - PyLong_AsSsize_t can't fail? Not on an object returned by PyNumber_Index(). And by the way I literally copied and pasted the code that implements 'n'--it does that too. > - does this change have a performance impact? Compared to just using "i", it adds the converter call and the "== Py_None" check. The performance impact should be so small as to be difficult to measure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 15:23:07 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 22 Jan 2014 14:23:07 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390400082.43.0.438750101478.issue20341@psf.upfronthosting.co.za> Message-ID: <1390400584.2306.4.camel@fsol> Antoine Pitrou added the comment: > That's not what it means. Python parameters are "optional" if they > have a default value. These parameters are "nullable", in the sense > that they can be either of a specific type or "None". (But "Noneable" > seemed like a bad name). They are not necessarily optional. int(or_none=True) ? > > - the fact that the structs are defined in longobject.h looks bonkers > > Okay. What would be better? modsupport.h? Hmm, do we have a getargs.h ? > > - boolean fields can be "char" instead of "int" (and moved at the > > end to pack the structure more efficiently) > > Is Python really compiled with packed structures? You don't understand me. If you write: struct X { int A; char B; char C; } the structure will be packed *by definition* (IIRC). > > - PyLong_AsSsize_t can't fail? > > Not on an object returned by PyNumber_Index(). And what if the long is too long to fit in a Py_ssize_t? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 15:25:05 2014 From: report at bugs.python.org (Tobias Klausmann) Date: Wed, 22 Jan 2014 14:25:05 +0000 Subject: [issue20344] subprocess.check_output() docs misrepresent what shell=True does Message-ID: <1390400705.04.0.503333173013.issue20344@psf.upfronthosting.co.za> New submission from Tobias Klausmann: The subprocess docs state that the first argument can be either a string or an iterable that contains the program and arguments to run. It also points out that using shell=True allows for shell constructs. It does not mention a subtlety that is introduced by Python's use of sh -c (on Unix): Using a string that contains the full command line with args and shell=False breaks as expected: >>> subprocess.check_output("ls foo", shell=False) Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.3/subprocess.py", line 576, in check_output with Popen(*popenargs, stdout=PIPE, **kwargs) as process: File "/usr/lib64/python3.3/subprocess.py", line 824, in __init__ restore_signals, start_new_session) File "/usr/lib64/python3.3/subprocess.py", line 1448, in _execute_child raise child_exception_type(errno_num, err_msg) FileNotFoundError: [Errno 2] No such file or directory: 'ls foo' Using shell=True instead works as expected (since foo does not exist, ls exits with non-0 and a different Exception is raised. This, too is to spec and exactly what the docs describe. >>> subprocess.check_output("ls foo", shell=True) ls: cannot access foo: No such file or directory Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.3/subprocess.py", line 589, in check_output raise CalledProcessError(retcode, process.args, output=output) subprocess.CalledProcessError: Command 'ls foo' returned non-zero exit status 2 Using shell=False and making the command a list of command and args does the same thing: >>> subprocess.check_output(["ls", "foo"], shell=False) ls: cannot access foo: No such file or directory Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.3/subprocess.py", line 589, in check_output raise CalledProcessError(retcode, process.args, output=output) subprocess.CalledProcessError: Command '['ls', 'foo']' returned non-zero exit status 2 But using an iterable _and_ requesting a shell results in something very broken: >>> subprocess.check_output(["ls", "foo"], shell=True) [contents of my homedir are returned] >>> Note that the argument "foo" completely disappears, apparently. strace() reveals that "foo" is never added to the call to "ls". Instead, it becomes $0 in the shell that ls runs in. This is exactly to spec (i.e. bash is not broken). "bash -c foo bar baz" will start a shell that sets $0 to "bar", $1 to "baz" and then executes "foo". Whereas "bash -c 'foo bar baz'" will run 'foo bar baz'. I think there are three possible fixes here: 1- Make check_output(list, shell=True) run something like "bash -c '%s'" % " ".join(list) 2- Change the docs to warn of the unintended consequences of combining lists with shell=True 3- Make check_output() throw an Exception if the first argument is a list and shell=True The first option would make it easiest for people to "just use it", but I fear the string manipulation may become the source of bugs with security implications in the future. The second option keeps the status quo, but people tend to not read docs, so it may not be as effective as one would like, especially since shell-True already has warnings and people tend to go "yeah I know about unverified input, but it's not a problem for me" and then ignore both warnings. Option 3 has the disadvantage that existing scripts that _expect_ the behavior may break. ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 208811 nosy: docs at python, klausman priority: normal severity: normal status: open title: subprocess.check_output() docs misrepresent what shell=True does type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 15:25:20 2014 From: report at bugs.python.org (Arne Babenhauserheide) Date: Wed, 22 Jan 2014 14:25:20 +0000 Subject: [issue20345] Better logging defaults Message-ID: <1390400720.32.0.906733284392.issue20345@psf.upfronthosting.co.za> New submission from Arne Babenhauserheide: Currently the default operation of logging prints messages like the following: INFO:root: Milk found. This is close to a print-call, but not much more useful - especially not in small scripts. To make the default settings more useful to quick scripts, I would suggest adding the filename and linenumber by default. This would be equivalent to the following setup: logging.basicConfig( level=logging.INFO, format="%(levelname)s (%(filename)s::%(lineno)s): %(message)s") With that setup, the above message would look like this: INFO (move.py::23): Milk found. ---------- components: Library (Lib) messages: 208812 nosy: ArneBab priority: normal severity: normal status: open title: Better logging defaults _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 15:39:32 2014 From: report at bugs.python.org (Tal Einat) Date: Wed, 22 Jan 2014 14:39:32 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> Message-ID: <1390401572.08.0.18573685471.issue20341@psf.upfronthosting.co.za> Tal Einat added the comment: Another bug in the patch: In int_converter.__init__ in clinic.py, the patch adds: if not isinstance(self.default, int): fail("Illegal default value for int_converter") This fails if no default is specified, e.g. for positional only argument. The condition should be: if not (self.default is unspecified or isinstance(self.default, int)): Ditto for Py_ssize_t_converter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 15:47:52 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 Jan 2014 14:47:52 +0000 Subject: [issue20344] subprocess.check_output() docs misrepresent what shell=True does In-Reply-To: <1390400705.04.0.503333173013.issue20344@psf.upfronthosting.co.za> Message-ID: <1390402072.1.0.289425520631.issue20344@psf.upfronthosting.co.za> R. David Murray added the comment: This was discussed in issue 6760. There I advocated (and still advocate) option (3). Unfortunately it looks like our doc update in that issue actually *lost* the documentation for your option (2) that used to be there, though it wasn't exactly clear what it meant when it was there. So IMO we should do a doc update to add that info back in a clearer form, and also do a deprecation cycle to disallow shell=True with a sequence. I haven't ever gotten consensus from the other devs on the latter, though. ---------- nosy: +r.david.murray stage: -> needs patch versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 15:49:16 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Jan 2014 14:49:16 +0000 Subject: [issue18300] script_helper._assert_python should set TERM='' by default. In-Reply-To: <1372164040.52.0.568545505593.issue18300@psf.upfronthosting.co.za> Message-ID: <1390402156.43.0.422485055908.issue18300@psf.upfronthosting.co.za> Berker Peksag added the comment: Attached patch to set TERM='' by default in test.script_helper._assert_python. ---------- keywords: +patch nosy: +berker.peksag stage: needs patch -> patch review title: script_helper._asert_python should set TERM='' by default. -> script_helper._assert_python should set TERM='' by default. Added file: http://bugs.python.org/file33622/issue18300.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 15:49:36 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Jan 2014 14:49:36 +0000 Subject: [issue18300] script_helper._assert_python should set TERM='' by default. In-Reply-To: <1372164040.52.0.568545505593.issue18300@psf.upfronthosting.co.za> Message-ID: <1390402176.07.0.41917334265.issue18300@psf.upfronthosting.co.za> Changes by Berker Peksag : Added file: http://bugs.python.org/file33623/issue18300_test_doctest.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 15:52:46 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 Jan 2014 14:52:46 +0000 Subject: [issue20345] Better logging defaults In-Reply-To: <1390400720.32.0.906733284392.issue20345@psf.upfronthosting.co.za> Message-ID: <1390402366.74.0.906471360334.issue20345@psf.upfronthosting.co.za> R. David Murray added the comment: Well, you can always call basicConfig yourself...that's kind of the point of it. I'm guessing the current output was chosen exactly because it is pretty much just a print of the input to the log method. But I don't have strong feelings about it. On the other hand, I would imagine that there are backward compatibility concerns: there may well be people who parse the logging output of their programs whose parsers would be broken if the default logging format changes. I'm not saying that is an overriding concern, just that it is a concern. ---------- nosy: +r.david.murray, vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 15:56:59 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 Jan 2014 14:56:59 +0000 Subject: [issue20329] zipfile.extractall fails in Posix shell with utf-8 filename In-Reply-To: <1390316753.93.0.767122614569.issue20329@psf.upfronthosting.co.za> Message-ID: <1390402619.3.0.599921653274.issue20329@psf.upfronthosting.co.za> R. David Murray added the comment: Believe me, we are *well* aware of the issue that linux stores filenames as bytes. I agree that the inability to always transcode is an issue. That's why I'd like the opinion of someone who has studied this problem in more depth. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 16:47:01 2014 From: report at bugs.python.org (Tal Einat) Date: Wed, 22 Jan 2014 15:47:01 +0000 Subject: [issue20346] Argument Clinic: missing entry in table mapping legacy convertors to real AC converters Message-ID: <1390405621.79.0.727900748758.issue20346@psf.upfronthosting.co.za> New submission from Tal Einat: There is no entry for 'l', which maps to 'long' according to 'long_converter' in clinic.py. Patch attached for Doc/howto/clinic.rst. ---------- files: missing_long_legacy_converter.clinic.rst.patch keywords: patch messages: 208818 nosy: larry, taleinat priority: normal severity: normal status: open title: Argument Clinic: missing entry in table mapping legacy convertors to real AC converters Added file: http://bugs.python.org/file33624/missing_long_legacy_converter.clinic.rst.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 16:47:29 2014 From: report at bugs.python.org (Tal Einat) Date: Wed, 22 Jan 2014 15:47:29 +0000 Subject: [issue20346] Argument Clinic: missing entry in table mapping legacy convertors to real AC converters In-Reply-To: <1390405621.79.0.727900748758.issue20346@psf.upfronthosting.co.za> Message-ID: <1390405649.52.0.0319862205876.issue20346@psf.upfronthosting.co.za> Changes by Tal Einat : ---------- assignee: -> docs at python components: +Build, Demos and Tools, Documentation nosy: +docs at python type: -> enhancement versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 16:51:44 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Jan 2014 15:51:44 +0000 Subject: [issue20346] Argument Clinic: missing entry in table mapping legacy convertors to real AC converters In-Reply-To: <1390405621.79.0.727900748758.issue20346@psf.upfronthosting.co.za> Message-ID: <1390405904.66.0.91423551902.issue20346@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> duplicate superseder: -> Argument Clinic does not support the 'l' format _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 16:57:30 2014 From: report at bugs.python.org (Christopher the Magnificent) Date: Wed, 22 Jan 2014 15:57:30 +0000 Subject: [issue20347] dir(__future__) gives segfault on OS X in 3.2 and 3.3 Message-ID: <1390406250.64.0.787562266918.issue20347@psf.upfronthosting.co.za> New submission from Christopher the Magnificent: On OS X 10.9.1 This works: Python 2.7.5 (default, Aug 25 2013, 00:04:04) [GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import __future__ >>> dir(__future__) ['CO_FUTURE_ABSOLUTE_IMPORT', 'CO_FUTURE_DIVISION', 'CO_FUTURE_PRINT_FUNCTION', 'CO_FUTURE_UNICODE_LITERALS', 'CO_FUTURE_WITH_STATEMENT', 'CO_GENERATOR_ALLOWED', 'CO_NESTED', '_Feature', '__all__', '__builtins__', '__doc__', '__file__', '__name__', '__package__', 'absolute_import', 'all_feature_names', 'division', 'generators', 'nested_scopes', 'print_function', 'unicode_literals', 'with_statement'] This also works: Python 3.1 (r31:73578, Jun 27 2009, 21:49:46) [GCC 4.0.1 (Apple Inc. build 5493)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import __future__ >>> dir(__future__) ['CO_FUTURE_ABSOLUTE_IMPORT', 'CO_FUTURE_BARRY_AS_BDFL', 'CO_FUTURE_DIVISION', 'CO_FUTURE_PRINT_FUNCTION', 'CO_FUTURE_UNICODE_LITERALS', 'CO_FUTURE_WITH_STATEMENT', 'CO_GENERATOR_ALLOWED', 'CO_NESTED', '_Feature', '__all__', '__builtins__', '__doc__', '__file__', '__name__', '__package__', 'absolute_import', 'all_feature_names', 'barry_as_FLUFL', 'division', 'generators', 'nested_scopes', 'print_function', 'unicode_literals', 'with_statement'] In Python 3.2 and 3.3 it appears broken. Python 3.2.2 (v3.2.2:137e45f15c0b, Sep 3 2011, 17:28:59) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import __future__ >>> dir(__future__) Segmentation fault: 11 also Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 01:25:11) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import __future__ >>> dir(__future__) Segmentation fault: 11 ---------- assignee: ronaldoussoren components: Macintosh messages: 208819 nosy: christopherthemagnificent, ronaldoussoren priority: normal severity: normal status: open title: dir(__future__) gives segfault on OS X in 3.2 and 3.3 type: crash versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 17:00:05 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 22 Jan 2014 16:00:05 +0000 Subject: [issue20347] dir(__future__) gives segfault on OS X in 3.2 and 3.3 In-Reply-To: <1390406250.64.0.787562266918.issue20347@psf.upfronthosting.co.za> Message-ID: <1390406405.51.0.173129800745.issue20347@psf.upfronthosting.co.za> STINNER Victor added the comment: > Python 2.7.5 (default, Aug 25 2013, 00:04:04) You should try the version 2.7.6 which contains a fix for OS X 10.9: http://www.python.org/download/releases/2.7.6/ ---------- nosy: +haypo, hynek, ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 17:29:34 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 Jan 2014 16:29:34 +0000 Subject: [issue20347] dir(__future__) gives segfault on OS X in 3.2 and 3.3 In-Reply-To: <1390406250.64.0.787562266918.issue20347@psf.upfronthosting.co.za> Message-ID: <1390408174.42.0.866985034667.issue20347@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- assignee: ronaldoussoren -> resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> python.org Interactive interpreter linked with libedit can segfault on future OS X _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 17:29:40 2014 From: report at bugs.python.org (Tal Einat) Date: Wed, 22 Jan 2014 16:29:40 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za> Message-ID: <1390408180.72.0.200923723244.issue20180@psf.upfronthosting.co.za> Tal Einat added the comment: Attached is a complete conversion of Modules/_randommodule.c. Three _random.Random methods were converted: seed, getrandbits and __new__. There's was an problem converting _random.Random.__new__. I overcame it cleanly and think this patch is good. Details about the problem follow. issue1486663 made various __new__ methods of built-in classes only do a '_PyArg_NoKeywords' check if the type is the class itself, i.e. not for sub-classes. This is to allow sub-classes to accept keyword arguments. This means that for classes that do this, like _random.Random, converting using AC makes it so subclasses can't accept keyword arguments (unless the subclasses implement __new__ properly). Still, it is possible to convert _random.Random.__new__ and also override __new__ in random.Random (random != _random, and random.Random subclasses _random.Random). This way subclasses of the latter can accept keyword arguments. Since anyone sub-classing _random.Random instead of random.Random can be expected to know to override __new__ or switch to random.Random, I think this is a good solution for this case. The attached patch does as I suggest above and passes all tests in test_random, including 'test_random_subclass_with_kwargs' which checks this issue. Just to be sure, I also ran the entire test suite, and all tests pass. ---------- Added file: http://bugs.python.org/file33625/_randommodule.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 17:30:17 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 22 Jan 2014 16:30:17 +0000 Subject: [issue20347] dir(__future__) gives segfault on OS X in 3.2 and 3.3 In-Reply-To: <1390406250.64.0.787562266918.issue20347@psf.upfronthosting.co.za> Message-ID: <1390408217.54.0.702431686512.issue20347@psf.upfronthosting.co.za> Ned Deily added the comment: This is a duplicate of Issue18458. The crash is caused by an incompatible change introduced in OS X 10.9 to the Apple-supplied version of libedit's readline compatibility layer and can affect Python versions that dynamically link with the system libedit (not all do). Fixes for the problem were released with Python 2.7.6 and 3.3.3, and found in the latest binary installers for OS X on python.org. Bug fixes for Python 3.2.x are no longer being produced, only security fixes. However, it *might* be possible to workaround the issue for 3.2 by installing the third-party deadline package from PyPI (https://pypi.python.org/pypi/readline). ---------- assignee: -> ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 17:37:18 2014 From: report at bugs.python.org (Brett Cannon) Date: Wed, 22 Jan 2014 16:37:18 +0000 Subject: [issue20332] Argument Clinic docs do not list support for the 'l' format In-Reply-To: <1390321924.51.0.108900260665.issue20332@psf.upfronthosting.co.za> Message-ID: <1390408638.65.0.522523461152.issue20332@psf.upfronthosting.co.za> Brett Cannon added the comment: So the docs don't mention this support anywhere. The 'l' format isn't listed in the table of legacy to Argument Clinic converters, nor is there a list of converters that only exist in Argument Clinic. So unless I read the section on return converters and inferred that if a return converter exists for long it exists as a argument converter I had no way of knowing the existence of long as a converter without reading the code. So this is at least a doc bug. ---------- components: +Documentation -Build resolution: invalid -> stage: committed/rejected -> needs patch status: closed -> open title: Argument Clinic does not support the 'l' format -> Argument Clinic docs do not list support for the 'l' format type: behavior -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 17:39:07 2014 From: report at bugs.python.org (Brett Cannon) Date: Wed, 22 Jan 2014 16:39:07 +0000 Subject: [issue20348] Argument Clinic HOWTO listed multiple times in HOWTO index Message-ID: <1390408747.92.0.288062862329.issue20348@psf.upfronthosting.co.za> New submission from Brett Cannon: http://docs.python.org/3.4/howto/ Seems several sections are listed on their own in the index. ---------- assignee: larry components: Documentation messages: 208824 nosy: brett.cannon, larry priority: normal severity: normal status: open title: Argument Clinic HOWTO listed multiple times in HOWTO index versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 17:41:00 2014 From: report at bugs.python.org (Brett Cannon) Date: Wed, 22 Jan 2014 16:41:00 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <1390408860.18.0.740794181784.issue19081@psf.upfronthosting.co.za> Brett Cannon added the comment: Can't you at least say "you don't know how import works unless you're Canadian"? =) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 17:42:02 2014 From: report at bugs.python.org (Tal Einat) Date: Wed, 22 Jan 2014 16:42:02 +0000 Subject: [issue20349] Argument Clinic: error on __new__ or __init__ with no arguments Message-ID: <1390408922.24.0.609938123562.issue20349@psf.upfronthosting.co.za> New submission from Tal Einat: This is caused by the code "fields = list(parser_body_fields)" under "if new_or_init:" in CLanguage.output_templates(). 'parser_body_fields' is initialized to None and may not be set before the above mentioned code. Attached is a patch which replaces the line with: fields = list(parser_body_fields) if parser_body_fields is not None else [] ---------- components: Build, Demos and Tools files: fix_new_or_init_without_arguments.clinic.py.patch keywords: patch messages: 208826 nosy: larry, taleinat priority: normal severity: normal status: open title: Argument Clinic: error on __new__ or __init__ with no arguments type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file33626/fix_new_or_init_without_arguments.clinic.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 17:42:53 2014 From: report at bugs.python.org (Tal Einat) Date: Wed, 22 Jan 2014 16:42:53 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za> Message-ID: <1390408973.97.0.581188050738.issue20180@psf.upfronthosting.co.za> Tal Einat added the comment: Attached complete conversion of Modules/xxlimited.c, Modules/xxmodule.c and Modules/xxsubtype.c. There are no tests for these and the code is not used by anything AFAIK, so I was extra careful and went over the diffs manually once everything was done. ---------- Added file: http://bugs.python.org/file33627/xxlimited_xxmodule_xxsubtype_AC_conversion.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 17:55:08 2014 From: report at bugs.python.org (Brett Cannon) Date: Wed, 22 Jan 2014 16:55:08 +0000 Subject: [issue20321] ImportError when a module is created after a catched ImportError In-Reply-To: <1390276988.86.0.176640087742.issue20321@psf.upfronthosting.co.za> Message-ID: <1390409708.8.0.0176437692969.issue20321@psf.upfronthosting.co.za> Brett Cannon added the comment: So those semantics have existed as long as PEP 302 has been around, which is Python 2.3 (that PEP itself is over a decade old), so changing them now would break code. And honestly I wouldn't change it anyway. On some filesystems, stat calls are extremely costly (e.g. NFS). Even if it was only on failed imports it would still have a cost. And considering a way to stay compatible between Python 2 and 3 is to catch ImportError and then import a module whose named changed, it would still be a costly change. Now if you personally really want the semantics you are after you could have a sys.meta_path importer which cleared out sys.path_importer_cache and tried the import again. As for documentation, it's explained in the language reference: http://docs.python.org/3/reference/import.html#path-entry-finders . But otherwise there isn't another place unless someone writes a HOWTO on this, but that probably isn't a good thing as import is something you really should be weary of mucking with. For someone trying to import the contents of a tarfile, they would be better served by a tarfile importer than unpacking the tarfile and then adding a path to sys.path. But someone has to write that tarfile importer first. =) Maybe some day: issue #17630. ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 18:06:39 2014 From: report at bugs.python.org (Brett Cannon) Date: Wed, 22 Jan 2014 17:06:39 +0000 Subject: [issue17630] Create a pure Python zipfile/tarfile importer In-Reply-To: <1365026756.4.0.0705755124355.issue17630@psf.upfronthosting.co.za> Message-ID: <1390410399.92.0.345881967866.issue17630@psf.upfronthosting.co.za> Brett Cannon added the comment: Re-positioning to work with both tarfile and zipfile since tarfile's 'r' will transparently decompress as necessary. Might need to scale back some functionality to make it easily work with both formats. But since are both alternative storage solutions then some generic base classes should be possible (which might require some refactoring anyway to make it all abstract in comparison to the storage mechanism. ---------- title: Create a pure Python zipfile importer -> Create a pure Python zipfile/tarfile importer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 18:12:42 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 22 Jan 2014 17:12:42 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za> Message-ID: <1390410762.45.0.72507015118.issue20180@psf.upfronthosting.co.za> Stefan Krah added the comment: I think we should probably not convert xx*.c. They are for newcomers who will likely be confused by the additional information overload. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 18:25:22 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Jan 2014 17:25:22 +0000 Subject: [issue20350] Replace tkapp.split() to tkapp.splitlist() Message-ID: <1390411522.89.0.349086871577.issue20350@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch replaces errorprone uses of tkapp.split() to tkapp.splitlist(). * Variable.trace_vinfo(). Actually there are no difference between split() and splitlist(), because "trace vinfo" always returns a list of 2-element tuple of strings and none of these can't contain spaces, '\\', or '{' (at least this can't be created from Tkinter). * Misc.winfo_visualsavailable() already has a workaround for split() peculiarity. With splitlist() the code is more straightforward. * tix.ListNoteBook.pages() and tix.NoteBook.pages() with split() can fail when there is only one page or when page names contain spaces or special characters. * tix.CheckList.getselection() already has a workaround for split() peculiarity. It calls splitlist() for result of split(). split() call is redundant. * In tix.Grid.size_column() and tix.Grid.size_row() there are no significant differences in behavior between split() and splitlist(). After these changes tkapp.split() no longer be used in the stdlib and can be deprecated. ---------- components: Library (Lib), Tkinter files: tkinter_use_splitlist.patch keywords: patch messages: 208831 nosy: gpolo, serhiy.storchaka, terry.reedy priority: normal severity: normal stage: patch review status: open title: Replace tkapp.split() to tkapp.splitlist() type: behavior versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33628/tkinter_use_splitlist.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 18:42:17 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jan 2014 17:42:17 +0000 Subject: [issue20338] Idle: increase max calltip width In-Reply-To: <1390344102.42.0.241411598779.issue20338@psf.upfronthosting.co.za> Message-ID: <1390412537.02.0.995443904419.issue20338@psf.upfronthosting.co.za> Terry J. Reedy added the comment: How about we extend the limit from 79 to say 120, to accommodate people who use longer docstring lines, and only wrap the signature line, when present, like the one for HTTPConnection, as the signature is the important information to include. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 19:01:30 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Jan 2014 18:01:30 +0000 Subject: [issue20338] Idle: increase max calltip width In-Reply-To: <1390344102.42.0.241411598779.issue20338@psf.upfronthosting.co.za> Message-ID: <1390413690.28.0.716937346278.issue20338@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, I think we can extend the limit (until implement wrapping). On my narrow monitor there is a room only for 120 character tip (when it starts right from left side of the screen), so I prefer to wrap long lines. In any case too long lines are not comfortable to read. >>> len(str(inspect.signature(textwrap.TextWrapper))) 242 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 19:05:31 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Jan 2014 18:05:31 +0000 Subject: [issue17390] display python version on idle title bar In-Reply-To: <1362920194.83.0.464215113749.issue17390@psf.upfronthosting.co.za> Message-ID: <1390413931.08.0.0125961530772.issue17390@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I presume the OP only cared about the Shell Window, and that was fixed. I agree that submitted patches should not be ignored. I have decided I really want editor windows labelled as sometimes run the *same* file with more than one version, and it can be difficult to remember which x.py window will run with which version. My only question is whether 'Python x.y Editor' will be too much to add in addition to the short and long file name, but after being undecided for months, I think the best thing is to add it and see. ---------- resolution: fixed -> status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 19:07:57 2014 From: report at bugs.python.org (Charles-Axel Dein) Date: Wed, 22 Jan 2014 18:07:57 +0000 Subject: [issue20351] Add doc examples for DictReader and DictWriter Message-ID: <1390414077.91.0.281809568509.issue20351@psf.upfronthosting.co.za> New submission from Charles-Axel Dein: IMO csv.DictWriter and csv.DictReader provides a nicer interface for complex CSV file. I see some people reinventing the DictReader and DictWriter pretty frequently, because when they rapidly scan the documentation all examples are about csv.reader and csv.writer. This patch adds examples. ---------- assignee: docs at python components: Documentation files: add_csvdict_examples.patch keywords: patch messages: 208835 nosy: charlax, docs at python priority: normal severity: normal status: open title: Add doc examples for DictReader and DictWriter Added file: http://bugs.python.org/file33629/add_csvdict_examples.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 19:15:29 2014 From: report at bugs.python.org (Moritz Neeb) Date: Wed, 22 Jan 2014 18:15:29 +0000 Subject: [issue20348] Argument Clinic HOWTO listed multiple times in HOWTO index In-Reply-To: <1390408747.92.0.288062862329.issue20348@psf.upfronthosting.co.za> Message-ID: <1390414529.74.0.628911089475.issue20348@psf.upfronthosting.co.za> Moritz Neeb added the comment: Here's a patch that changes the headings in clinic.rst, such that only the first appears in the HOWTO listing. I also adapted the first according to the convention in http://docs.python.org/devguide/documenting.html#sections ---------- keywords: +patch nosy: +zormit Added file: http://bugs.python.org/file33630/Doc-clinic.rst.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 19:17:39 2014 From: report at bugs.python.org (=?utf-8?q?Dani=C3=ABl_van_Eeden?=) Date: Wed, 22 Jan 2014 18:17:39 +0000 Subject: [issue20352] Add support for AUTH command to poplib Message-ID: <1390414659.94.0.817881856376.issue20352@psf.upfronthosting.co.za> New submission from Dani?l van Eeden: I use 'AUTH PLAIN ' to login to a POP3 server with a proxy user. I can't use 'pass_()' as I need to supply a admin user and the user to proxy into. class adminpopserver(poplib.POP3): def auth(self, method, secret): return self._shortcmd('AUTH %s %s' % (method, secret)) secret = "{user}\0{adminuser}\0{password}".format( user=user, adminuser=adminuser, password=password) secret = secret.encode('base64').strip('\n') ---------- components: Library (Lib) messages: 208837 nosy: dveeden priority: normal severity: normal status: open title: Add support for AUTH command to poplib versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 19:24:27 2014 From: report at bugs.python.org (Craig Silverstein) Date: Wed, 22 Jan 2014 18:24:27 +0000 Subject: [issue20353] Hanging bug with multiprocessing + sqlite3 + tkinter (OS X 10.9 only) Message-ID: <1390415067.55.0.719190169135.issue20353@psf.upfronthosting.co.za> New submission from Craig Silverstein: Don't ask me how, but our code managed to combine multiprocessing, sqlite, and tkinter all in one app, and got a hanging behavior, though only on a particular OS. Removing any of these removes the hang. I filed this under tkinter, but the fault could well be elsewhere. This happens for us only when run under OS X 10.9 (Mavericks). We are using python 2.7.5; I don't know if other versions are affected. ---------- components: Tkinter files: hang.py messages: 208838 nosy: Craig.Silverstein priority: normal severity: normal status: open title: Hanging bug with multiprocessing + sqlite3 + tkinter (OS X 10.9 only) type: crash versions: Python 2.7 Added file: http://bugs.python.org/file33631/hang.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 19:50:47 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Jan 2014 18:50:47 +0000 Subject: [issue20338] Idle: increase max calltip width In-Reply-To: <1390344102.42.0.241411598779.issue20338@psf.upfronthosting.co.za> Message-ID: <1390416647.84.0.0198073315907.issue20338@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch (for 3.4) which wraps long lines. Now you can display a tip for textwrap.TextWrapper. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file33632/idle_calltips_wrap.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 19:54:39 2014 From: report at bugs.python.org (Glenn Langford) Date: Wed, 22 Jan 2014 18:54:39 +0000 Subject: [issue20319] concurrent.futures.wait() can block forever even if Futures have completed In-Reply-To: <1390263519.32.0.357208079457.issue20319@psf.upfronthosting.co.za> Message-ID: <1390416879.31.0.511972678195.issue20319@psf.upfronthosting.co.za> Glenn Langford added the comment: The same bug also exists in concurrent.futures.as_completed(). The minimal fix suggested here also works, but the bigger fix suggested in issue #20297 is recommended for as_completed(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 19:55:55 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 Jan 2014 18:55:55 +0000 Subject: [issue20352] Add support for AUTH command to poplib In-Reply-To: <1390414659.94.0.817881856376.issue20352@psf.upfronthosting.co.za> Message-ID: <1390416955.37.0.583724998097.issue20352@psf.upfronthosting.co.za> R. David Murray added the comment: This is basically rfc 5034 support? Sounds like a good idea. I'm going to mark this issue as 'easy' because it isn't a whole lot of code, but for anyone who wants to tackle it, know that understanding the RFC and getting it *right* is not necessarily trivial, because: rfc :) ---------- components: +email keywords: +easy nosy: +barry, r.david.murray stage: -> needs patch type: -> enhancement versions: +Python 3.5 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 19:59:07 2014 From: report at bugs.python.org (jan matejek) Date: Wed, 22 Jan 2014 18:59:07 +0000 Subject: [issue20354] tracemalloc causes segfault in "make profile-opt" Message-ID: <1390417147.04.0.258721573187.issue20354@psf.upfronthosting.co.za> New submission from jan matejek: When compiling "make profile-opt", the instrumented python executable segfaults upon exit, even though it appears to run fine. This breaks the build process, because make evaluates the segfault as if the respective compilation step failed. GDB yields the following backtrace for the crash: #0 gcov_exit () at ../../../libgcc/libgcov.c:397 #1 0x00007ffff69b875f in __cxa_finalize (d=0x7ffff7c38a60) at cxa_finalize.c:56 #2 0x00007ffff771b983 in __do_global_dtors_aux () from ./libpython3.4m.so.1.0 #3 0x00007fffffffdd60 in ?? () #4 0x00007ffff7debe6a in _dl_fini () at dl-fini.c:252 Backtrace stopped: frame did not save the PC This problem first appears with changeset 6e2089dbc5ad [1] that introduced tracemalloc. It is still reproducible on today's tip. AFAICT, the mere presence of tracemalloc in the compiled executable causes this crash; I tried commenting out _PyTraceMalloc_Init from pythonrun.c and it did not help. To reproduce: ./configure --enable-shared make profile-opt i'm on x86_64 SUSE Linux, gcc version is 4.8.1 [1] hg.python.org/cpython/rev/6e2089dbc5ad ---------- messages: 208842 nosy: matejcik priority: normal severity: normal status: open title: tracemalloc causes segfault in "make profile-opt" type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 19:59:32 2014 From: report at bugs.python.org (Moritz Neeb) Date: Wed, 22 Jan 2014 18:59:32 +0000 Subject: [issue20351] Add doc examples for DictReader and DictWriter In-Reply-To: <1390414077.91.0.281809568509.issue20351@psf.upfronthosting.co.za> Message-ID: <1390417172.35.0.777262769569.issue20351@psf.upfronthosting.co.za> Changes by Moritz Neeb : ---------- nosy: +zormit _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 20:43:03 2014 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 22 Jan 2014 19:43:03 +0000 Subject: [issue20345] Better logging defaults In-Reply-To: <1390400720.32.0.906733284392.issue20345@psf.upfronthosting.co.za> Message-ID: <1390419783.44.0.136803381988.issue20345@psf.upfronthosting.co.za> Vinay Sajip added the comment: I don't think it is necessary or advisable to change the default, as it is very easy to provide your own format. As RDM has noted, this could affect backward compatibility. Furthermore, there are bound to be differing views of what an ideal default should be, so we might as well leave this bikeshed un-repainted ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 20:43:38 2014 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 22 Jan 2014 19:43:38 +0000 Subject: [issue20345] Better logging defaults In-Reply-To: <1390400720.32.0.906733284392.issue20345@psf.upfronthosting.co.za> Message-ID: <1390419818.71.0.0398963614702.issue20345@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- resolution: -> wont fix status: open -> pending type: -> enhancement versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 20:47:42 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 22 Jan 2014 19:47:42 +0000 Subject: [issue18695] os.statvfs() not working well with unicode paths In-Reply-To: <1376050003.6.0.904056390722.issue18695@psf.upfronthosting.co.za> Message-ID: <1390420062.33.0.359928022013.issue18695@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Attached patch includes tests. I took test_sax.py as an example. ---------- Added file: http://bugs.python.org/file33633/issue18695-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 21:03:17 2014 From: report at bugs.python.org (Tal Einat) Date: Wed, 22 Jan 2014 20:03:17 +0000 Subject: [issue20332] Argument Clinic docs do not list support for the 'l' format In-Reply-To: <1390321924.51.0.108900260665.issue20332@psf.upfronthosting.co.za> Message-ID: <1390420997.77.0.586620435332.issue20332@psf.upfronthosting.co.za> Tal Einat added the comment: See documentation patch for this issue attached to issue20346 (a duplicate of this). ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 21:06:07 2014 From: report at bugs.python.org (Tal Einat) Date: Wed, 22 Jan 2014 20:06:07 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za> Message-ID: <1390421167.15.0.940244192939.issue20180@psf.upfronthosting.co.za> Tal Einat added the comment: I thought AC was how all new modules were supposed to be written. If so, the example modules should definitely use AC! Also note that once the generated code is in separate files, the code in the origin files will be simpler and clearer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 21:19:14 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 22 Jan 2014 20:19:14 +0000 Subject: [issue18695] os.statvfs() not working well with unicode paths In-Reply-To: <1376050003.6.0.904056390722.issue18695@psf.upfronthosting.co.za> Message-ID: <1390421954.55.0.223569057329.issue18695@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: While I'm at it I'm going to fix also mkfifo(), mknod() and others. Hold on a bit more. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 21:36:02 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Jan 2014 20:36:02 +0000 Subject: [issue19145] Inconsistent behaviour in itertools.repeat when using negative times In-Reply-To: <1380727396.47.0.412229295257.issue19145@psf.upfronthosting.co.za> Message-ID: <1390422962.57.0.34893926064.issue19145@psf.upfronthosting.co.za> Larry Hastings added the comment: This problem been independently rediscovered by people converting code to Argument Clinic. A Python signature can't express these semantics, where a parameter behaves differently depending on whether it's passed in by keyword or by reference. So Argument Clinic can't either. I think it would be best if itertools.repeat behaved like a pure Python function--that is, that it behaved the same whether "times" was passed in by position or by keyword. What's I find curious: the documentation is wildly out of sync with the implementation. It says: itertools.repeat(object[, times]) .... def repeat(object, times=None): .... http://docs.python.org/3.4/library/itertools.html#itertools.repeat But repeat() doesn't support passing in None for the times parameter, if indeed it ever has. I see two possible choices here. 1) Honor the existing behavior. Change the signature to simply def repeat(object, times=-1): and document it that way. 2) Honor the documentation. Change the implementation to def repeat(object, times=None): This change could break code. So we'd have to go through a deprecation cycle. Breaking "times=-1" without a deprecation cycle is simply not viable at this point. I could live with either. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 21:48:10 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 22 Jan 2014 20:48:10 +0000 Subject: [issue18695] os.statvfs() not working well with unicode paths In-Reply-To: <1376050003.6.0.904056390722.issue18695@psf.upfronthosting.co.za> Message-ID: <1390423690.43.0.675407461222.issue18695@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Ok, patch in attachment fixes mkfifo(), mknod() and statvfs() and also includes Unicode tests for all os module's path-related functions. ---------- Added file: http://bugs.python.org/file33634/issue18695-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 21:48:39 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 Jan 2014 20:48:39 +0000 Subject: [issue20354] tracemalloc causes segfault in "make profile-opt" In-Reply-To: <1390417147.04.0.258721573187.issue20354@psf.upfronthosting.co.za> Message-ID: <1390423719.75.0.709724770417.issue20354@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 21:58:18 2014 From: report at bugs.python.org (Nadeem Vawda) Date: Wed, 22 Jan 2014 20:58:18 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1390424298.35.0.557979403542.issue20193@psf.upfronthosting.co.za> Nadeem Vawda added the comment: The bz2 patch looks good to me, aside from a nit with the docstring for BZ2Compressor.__init__. The lzma patch produces a bunch of test failures for me. It looks like the __init__ methods for LZMACompressor and LZMADecompressor aren't accepting keyword args: ? ./python -c 'import lzma; lzma.LZMACompressor(format=lzma.FORMAT_XZ)' Traceback (most recent call last): File "", line 1, in TypeError: __init__ does not take keyword arguments ? ./python -c 'import lzma; lzma.LZMADecompressor(format=lzma.FORMAT_AUTO)' Traceback (most recent call last): File "", line 1, in TypeError: __init__ does not take keyword arguments ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 22:05:15 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Jan 2014 21:05:15 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> Message-ID: <1390424715.11.0.790443777608.issue20341@psf.upfronthosting.co.za> Larry Hastings added the comment: > int(or_none=True) ? Yes, that is a different name that seems to mean much the same thing. > Hmm, do we have a getargs.h ? No. Would it help if I attached the output of "ls Include" to this issue? > > > - boolean fields can be "char" instead of "int" (and moved at the > > > end to pack the structure more efficiently) > > > > Is Python really compiled with packed structures? > > You don't understand me. If you write: > struct X { int A; char B; char C; } > the structure will be packed *by definition* (IIRC). I understand you fine. That's not guaranteed by the C standard, and I've used compilers that didn't pack structures by default. More to the point, unaligned accesses on Intel are more expensive than aligned accesses, and on other architectures I've written C code using packed structures with unaligned accesses that produced a bus error. http://en.wikipedia.org/wiki/Data_structure_alignment#Data_structure_padding And finally: I removed "error"--you were right, it was unnecessary for the nullable ints. So now it's just { int error; i; } Changing error to an char and moving it to the end would save exactly zero bytes, because the compiler *will* align stack variables to 4 byte boundaries. I can give you a sample C program if you want proof. > > > - PyLong_AsSsize_t can't fail? > > Not on an object returned by PyNumber_Index(). > And what if the long is too long to fit in a Py_ssize_t? Ah. I thought PyNumber_Index guaranteed it would fit, but I was mistaken. Code is fixed. New patch posted. I believe this fixes all the bugs cited so far. Also, I don't know what the right thing to do about itertools.repeat is. The current signature is a bug, it should not behave differently between repeat(o, -1) and repeat(o, times=-1). If we go by the documentation, repeat(o, None) and repeat(o, times=None) are what we want. But I bet code out there relies on repeat(o, times=-1), so we may be stuck supporting that. You should consider my signature for itertools.repeat in these "draft" patches as a proof of concept, not as code that should be checked in. The issue is being discussed on #19145. ---------- Added file: http://bugs.python.org/file33635/larry.nullable.ints.draft.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 22:19:31 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 22 Jan 2014 21:19:31 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390424715.11.0.790443777608.issue20341@psf.upfronthosting.co.za> Message-ID: <1390425567.2306.7.camel@fsol> Antoine Pitrou added the comment: > > int(or_none=True) ? > > Yes, that is a different name that seems to mean much the same thing. and which is much more understandable by a Python developer. > Changing error to an char and moving it to the end would > save exactly zero bytes, because the compiler *will* align > stack variables to 4 byte boundaries. Except if other stack variables happen to be shorter than an int, perhaps. But regardless, it doesn't cost anything to do so, so why not do it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 22:25:03 2014 From: report at bugs.python.org (Brett Cannon) Date: Wed, 22 Jan 2014 21:25:03 +0000 Subject: [issue20332] Argument Clinic docs do not list support for the 'l' format In-Reply-To: <1390321924.51.0.108900260665.issue20332@psf.upfronthosting.co.za> Message-ID: <1390425903.08.0.00860391402729.issue20332@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- superseder: -> Argument Clinic docs do not list support for the 'l' format _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 22:25:39 2014 From: report at bugs.python.org (Brett Cannon) Date: Wed, 22 Jan 2014 21:25:39 +0000 Subject: [issue20332] Argument Clinic docs do not list support for the 'l' format In-Reply-To: <1390321924.51.0.108900260665.issue20332@psf.upfronthosting.co.za> Message-ID: <1390425939.48.0.329212411459.issue20332@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 22:26:04 2014 From: report at bugs.python.org (Brett Cannon) Date: Wed, 22 Jan 2014 21:26:04 +0000 Subject: [issue20332] Argument Clinic docs do not list support for the 'l' format In-Reply-To: <1390321924.51.0.108900260665.issue20332@psf.upfronthosting.co.za> Message-ID: <1390425964.79.0.569895794679.issue20332@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- superseder: Argument Clinic docs do not list support for the 'l' format -> Argument Clinic: missing entry in table mapping legacy convertors to real AC converters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 22:26:10 2014 From: report at bugs.python.org (Brett Cannon) Date: Wed, 22 Jan 2014 21:26:10 +0000 Subject: [issue20346] Argument Clinic: missing entry in table mapping legacy convertors to real AC converters In-Reply-To: <1390405621.79.0.727900748758.issue20346@psf.upfronthosting.co.za> Message-ID: <1390425970.69.0.0677080406056.issue20346@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 22:38:38 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Jan 2014 21:38:38 +0000 Subject: [issue18695] os.statvfs() not working well with unicode paths In-Reply-To: <1376050003.6.0.904056390722.issue18695@psf.upfronthosting.co.za> Message-ID: <1390426718.55.0.00709298175321.issue18695@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: You have eaten "return NULL;" in posix_mkfifo. "from test.test_support import TESTFN_UNICODE, TESTFN_ENCODING" can fail. The simplest solution is just initialize them to None by default in test_support. If TESTFN_UNICODE.encode(TESTFN_ENCODING) fails (on POSIX locale), it will be better to run tests with unicode(TESTFN, 'ascii') than skip them. Tests should check that results for unicode filename is same as for str filename. As far as Victor have doubts, we should ask Benjamin. ---------- assignee: -> giampaolo.rodola nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 22:41:46 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 22 Jan 2014 21:41:46 +0000 Subject: [issue20355] -W command line options should have higher priority than PYTHONWARNINGS environmental variable Message-ID: <1390426906.93.0.692922610327.issue20355@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis: Currently Python has non-intuitive behavior such that PYTHONWARNINGS environmental variable has higher priority than -W command line options. $ python3.4 -c '__import__("warnings").warn("xxx", DeprecationWarning)' $ python3.4 -Wd -c '__import__("warnings").warn("xxx", DeprecationWarning)' -c:1: DeprecationWarning: xxx $ python3.4 -We -c '__import__("warnings").warn("xxx", DeprecationWarning)' Traceback (most recent call last): File "", line 1, in DeprecationWarning: xxx $ PYTHONWARNINGS="e" python3.4 -Wd -c '__import__("warnings").warn("xxx", DeprecationWarning)' Traceback (most recent call last): File "", line 1, in DeprecationWarning: xxx $ PYTHONWARNINGS="d" python3.4 -We -c '__import__("warnings").warn("xxx", DeprecationWarning)' -c:1: DeprecationWarning: xxx $ I think that settings from -W command line options should have higher priority than PYTHONWARNINGS environmental variable. (Adding people from issue #7301 to nosy list.) ---------- components: Interpreter Core messages: 208854 nosy: Arfrever, barry, brian.curtin, eric.araujo, pitrou, pjenvey, skrah priority: normal severity: normal status: open title: -W command line options should have higher priority than PYTHONWARNINGS environmental variable type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 22:42:41 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 22 Jan 2014 21:42:41 +0000 Subject: [issue20340] -bb option does not have different behavior than -b option In-Reply-To: <1390358519.86.0.0114384663119.issue20340@psf.upfronthosting.co.za> Message-ID: <1390426961.65.0.483162017464.issue20340@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 22:43:03 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 22 Jan 2014 21:43:03 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1390421167.15.0.940244192939.issue20180@psf.upfronthosting.co.za> Message-ID: <20140122214302.GA20669@sleipnir.bytereef.org> Stefan Krah added the comment: The vast majority of C modules are in third-party packages. I doubt that external modules will all use AC. xxmodule.c is about explaining the basic structure of a C extension. AC adds nothing to this and obfuscates (IMO) what is going on. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 23:07:46 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 22 Jan 2014 22:07:46 +0000 Subject: [issue20355] -W command line options should have higher priority than PYTHONWARNINGS environmental variable In-Reply-To: <1390426906.93.0.692922610327.issue20355@psf.upfronthosting.co.za> Message-ID: <1390428466.74.0.579880465934.issue20355@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Agreed. ---------- nosy: +brett.cannon stage: -> needs patch type: behavior -> enhancement versions: +Python 3.5 -Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 23:24:22 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 22 Jan 2014 22:24:22 +0000 Subject: [issue18695] os.statvfs() not working well with unicode paths In-Reply-To: <1376050003.6.0.904056390722.issue18695@psf.upfronthosting.co.za> Message-ID: <1390429462.72.0.750599993739.issue18695@psf.upfronthosting.co.za> STINNER Victor added the comment: > As far as Victor have doubts, we should ask Benjamin. Well, if you begin to patch some os functions, we will find much functions which don't support Unicode path. I prefer to consider that Python 2 doesn't support Unicode filenames to avoid bugs. If you want to support Unicode filename, we will have to modify a lot of code. What's the point since Python 3 has a very good support of Unicode? Much better than Python 2? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 23:36:58 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 22 Jan 2014 22:36:58 +0000 Subject: [issue20329] zipfile.extractall fails in Posix shell with utf-8 filename In-Reply-To: <1390316753.93.0.767122614569.issue20329@psf.upfronthosting.co.za> Message-ID: <1390430218.35.0.26129679706.issue20329@psf.upfronthosting.co.za> Nick Coghlan added the comment: The POSIX locale tells Python 3 to use ASCII for all operating system interfaces, including the standard streams. This is an antiquated behaviour in the POSIX spec that Python 3 doesn't currently work around. Issue 19977 is a proposal to work around this limitation by default. As an immediate workaround, it's possible to either set PYTHONIOENCODING explicitly so Python ignores the incorrect encoding claims from the OS, or else to do your own encoding and write directly to the sys.stdout.buffer binary interface. Python 3.4 also allows setting *just* the default error handler for the streams, while still getting the encoding from the OS. ---------- resolution: -> duplicate status: open -> closed superseder: -> Use "surrogateescape" error handler for sys.stdin and sys.stdout on UNIX for the C locale _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 23:41:18 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 22 Jan 2014 22:41:18 +0000 Subject: [issue20329] zipfile.extractall fails in Posix shell with utf-8 filename In-Reply-To: <1390316753.93.0.767122614569.issue20329@psf.upfronthosting.co.za> Message-ID: <1390430478.29.0.295482612467.issue20329@psf.upfronthosting.co.za> Nick Coghlan added the comment: My apologies, I completely misread the issue and thought it was related to displaying file names, rather than opening them. I believe Python 3.4 includes some changes in this area - are you in a position to retry this on the latest 3.4 beta release? ---------- resolution: duplicate -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 23:41:50 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 22 Jan 2014 22:41:50 +0000 Subject: [issue20329] zipfile.extractall fails in Posix shell with utf-8 filename In-Reply-To: <1390316753.93.0.767122614569.issue20329@psf.upfronthosting.co.za> Message-ID: <1390430510.12.0.861961839525.issue20329@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- superseder: Use "surrogateescape" error handler for sys.stdin and sys.stdout on UNIX for the C locale -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 22 23:52:06 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 22 Jan 2014 22:52:06 +0000 Subject: [issue20356] fix formatting of positional-only parameters in inspect.Signature Message-ID: <1390431126.48.0.863526301324.issue20356@psf.upfronthosting.co.za> New submission from Yury Selivanov: Fix formatting of positional-only parameters to use '/' as a separator for them from other kinds. This patch also makes 'Parameter.name' required, as well as being a valid identifier (as per discussion with Larry, Nick and Brett). ---------- components: Library (Lib) files: pos_only_format_01.patch keywords: patch messages: 208860 nosy: brett.cannon, larry, ncoghlan, yselivanov priority: normal severity: normal status: open title: fix formatting of positional-only parameters in inspect.Signature type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file33636/pos_only_format_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 00:13:00 2014 From: report at bugs.python.org (Tal Einat) Date: Wed, 22 Jan 2014 23:13:00 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za> Message-ID: <1390432380.19.0.00905849135612.issue20180@psf.upfronthosting.co.za> Tal Einat added the comment: Thanks, Stefan. I hadn't realized that the xx files were targeted mainly a third-party developers. In this case, I can see the sense in not converting them. I only wish someone had said something *before* I went ahead and converted them... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 00:13:48 2014 From: report at bugs.python.org (Keith Bannister) Date: Wed, 22 Jan 2014 23:13:48 +0000 Subject: [issue11077] Tkinter is not thread safe In-Reply-To: <1296488432.58.0.0945320697853.issue11077@psf.upfronthosting.co.za> Message-ID: <1390432428.82.0.356437513074.issue11077@psf.upfronthosting.co.za> Keith Bannister added the comment: Hi, I'm trying to make an application with GNU readline support, and some plots. But it seems that tkInter and raw_input don't play nicely. The attached script (18 lines) crashes immediately on my Mac with SIGABRT and outputs the following: $ python tk_v_raw.py Yes? > Tcl_WaitForEvent: Notifier not initialized Abort trap: 6 Is this related to this issue? ---------- nosy: +Keith.Bannister Added file: http://bugs.python.org/file33637/tk_v_raw.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 00:14:20 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 22 Jan 2014 23:14:20 +0000 Subject: [issue20354] tracemalloc causes segfault in "make profile-opt" In-Reply-To: <1390417147.04.0.258721573187.issue20354@psf.upfronthosting.co.za> Message-ID: <1390432460.84.0.143875044467.issue20354@psf.upfronthosting.co.za> STINNER Victor added the comment: > This problem first appears with changeset 6e2089dbc5ad [1] that introduced tracemalloc. It is still reproducible on today's tip. It looks like the bug doesn't come from the code of tracemalloc. I removed all functions, Python does still crash. No. The problem just comes from the line "#pragma pack(4)" of: #pragma pack(4) typedef struct { PyObject *filename; int lineno; } frame_t; ---------- nosy: +neologix, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 00:18:57 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 22 Jan 2014 23:18:57 +0000 Subject: [issue20354] tracemalloc causes segfault in "make profile-opt" In-Reply-To: <1390417147.04.0.258721573187.issue20354@psf.upfronthosting.co.za> Message-ID: <1390432737.3.0.600719054837.issue20354@psf.upfronthosting.co.za> STINNER Victor added the comment: Oops, the original code is: --- /* Pack the frame_t structure to reduce the memory footprint on 64-bit architectures: 12 bytes instead of 16. This optimization might produce SIGBUS on architectures not supporting unaligned memory accesses (64-bit IPS CPU?): on such architecture, the structure must not be packed. */ #pragma pack(4) typedef struct #ifdef __GNUC__ __attribute__((packed)) #endif { PyObject *filename; int lineno; } frame_t; --- "#pragma pack(4)" is for Microsoft Visual Studio. For GCC, there is already the "__attribute__((packed))" line. See attached workaround tracemalloc_gcov.patch. But I would interested to understand why it does crash. It might be a GCC or gcov bug. ---------- keywords: +patch Added file: http://bugs.python.org/file33638/tracemalloc_gcov.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 00:25:58 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 22 Jan 2014 23:25:58 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1390432380.19.0.00905849135612.issue20180@psf.upfronthosting.co.za> Message-ID: <20140122232557.GA8496@sleipnir.bytereef.org> Stefan Krah added the comment: > I only wish someone had said something *before* I went ahead and converted them... Yeah, sorry. It's also just my personal opinion. BTW, xxmodule did not compile and there was a warning for xxsubtype. I just mention it in case these are AC issues. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 00:39:19 2014 From: report at bugs.python.org (Tal Einat) Date: Wed, 22 Jan 2014 23:39:19 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> Message-ID: <1390433959.29.0.485914256032.issue20341@psf.upfronthosting.co.za> Tal Einat added the comment: The new patch still uses NULLABLE_PY_SSIZE_T_INITIALIZE instead of NULLABLE_INT_T_INITIALIZE in one place in int_converter.converter_init. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 00:48:34 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Jan 2014 23:48:34 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> Message-ID: <1390434514.48.0.142076122508.issue20341@psf.upfronthosting.co.za> Larry Hastings added the comment: Fix attached. Might as well. ---------- Added file: http://bugs.python.org/file33639/larry.nullable.ints.draft.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 01:13:24 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 23 Jan 2014 00:13:24 +0000 Subject: [issue14548] garbage collection just after multiprocessing's fork causes exceptions In-Reply-To: <1334161952.16.0.996503370024.issue14548@psf.upfronthosting.co.za> Message-ID: <3f8kTw0S9kz7LjP@mail.python.org> Roundup Robot added the comment: New changeset 751371dd4d1c by Richard Oudkerk in branch '2.7': Issue #14548: Make multiprocessing finalizers check pid before http://hg.python.org/cpython/rev/751371dd4d1c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 01:18:16 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 23 Jan 2014 00:18:16 +0000 Subject: [issue20354] tracemalloc causes segfault in "make profile-opt" In-Reply-To: <1390417147.04.0.258721573187.issue20354@psf.upfronthosting.co.za> Message-ID: <1390436296.39.0.109388440411.issue20354@psf.upfronthosting.co.za> Stefan Krah added the comment: For gcc, #pragma pack(n) apparently sets the new aligment for the entire compilation unit: http://gcc.gnu.org/onlinedocs/gcc/Structure-Packing-Pragmas.html ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 01:46:13 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 23 Jan 2014 00:46:13 +0000 Subject: [issue11077] Tkinter is not thread safe In-Reply-To: <1296488432.58.0.0945320697853.issue11077@psf.upfronthosting.co.za> Message-ID: <1390437973.56.0.643337331777.issue11077@psf.upfronthosting.co.za> Terry J. Reedy added the comment: tk_v_raw.py is not obviously related to this issue. First, you only use tkinter in the main thread. Second, it works on Windows 7-64, 3.4 Idle. >>> Yes? > abc Got cmd abc Yes? > def Got cmd def Yes? > It also runs in the console on 2.7, 3.3, 3.4. The main problem is that closing the Label window does not stop while True: in the thread, making a graceful stop difficult. The loop needs if cmd == 'q': break Keith, did you install the appropriate ActiveState tcl/tk, as described here: http://www.python.org/download/mac/tcltk/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 01:53:47 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 23 Jan 2014 00:53:47 +0000 Subject: [issue11077] Tkinter is not thread safe In-Reply-To: <1296488432.58.0.0945320697853.issue11077@psf.upfronthosting.co.za> Message-ID: <1390438427.67.0.595749579623.issue11077@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Is this still a problem with 2.7.6, which has a few hundred bug fixes since 2.7.1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 02:19:41 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 23 Jan 2014 01:19:41 +0000 Subject: [issue20353] Hanging bug with multiprocessing + sqlite3 + tkinter (OS X 10.9 only) In-Reply-To: <1390415067.55.0.719190169135.issue20353@psf.upfronthosting.co.za> Message-ID: <1390439981.86.0.547315157487.issue20353@psf.upfronthosting.co.za> Ned Deily added the comment: I can reproduce a hang (but not a crash) when using a Python 2.7.x or 3.4.x built from source and linking with the OS X 10.9 system libsqlite3. Using the Apple-supplied Python 2.7 on 10.9 causes a crash in libdispatch. Using Python 2.7.6 or 3.4.0 from the current python.org 64-bit installers, the test does not hang; these Pythons are linked with a static local version of libsqlite3, not the system-supplied one. If I modify the test to include a call to sqlite3.connect() in the top-level code before calling multiprocessing apply_async, the test also does not hang anymore. Perhaps you can use that as a workaround. I'm not sure why the combination of sqlite and _tkinter are necessary to hang. I'm not going to have time to look further into this right away. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 02:25:37 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 23 Jan 2014 01:25:37 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za> Message-ID: <1390440337.7.0.518645677218.issue20180@psf.upfronthosting.co.za> Larry Hastings added the comment: When AC moves from internal-only tool to supported tool we'll want to convert the xx stuff. But yeah I reckon it makes sense to not convert them yet. The list of files is really more "here's the list of stuff to check out and convert if necessary". best judgement is always called for. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 02:37:32 2014 From: report at bugs.python.org (Craig Silverstein) Date: Thu, 23 Jan 2014 01:37:32 +0000 Subject: [issue20353] Hanging bug with multiprocessing + sqlite3 + tkinter (OS X 10.9 only) In-Reply-To: <1390415067.55.0.719190169135.issue20353@psf.upfronthosting.co.za> Message-ID: <1390441052.24.0.492875431514.issue20353@psf.upfronthosting.co.za> Craig Silverstein added the comment: Thanks -- we managed to work around it by removing the tkinter dependency, so this isn't time-critical for us. It is curious, though. One thing I forgot to mention before is that playing around with the hung process in gdb, it seems like sqlite was waiting on a lock. I don't know what lock it might be though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 03:42:56 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 23 Jan 2014 02:42:56 +0000 Subject: [issue20356] fix formatting of positional-only parameters in inspect.Signature In-Reply-To: <1390431126.48.0.863526301324.issue20356@psf.upfronthosting.co.za> Message-ID: <1390444976.56.0.313035538993.issue20356@psf.upfronthosting.co.za> Yury Selivanov added the comment: One more patch revision: added versionchanged directive for the inspect.Parameter class docs. ---------- Added file: http://bugs.python.org/file33640/pos_only_format_02.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 04:18:17 2014 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 23 Jan 2014 03:18:17 +0000 Subject: [issue20357] Mention buildbots in the core dev section of the devguide Message-ID: <1390447097.09.0.000203036921559.issue20357@psf.upfronthosting.co.za> New submission from Nick Coghlan: Just a note to myself to fix this omission :) ---------- assignee: ncoghlan messages: 208876 nosy: ncoghlan priority: normal severity: normal status: open title: Mention buildbots in the core dev section of the devguide _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 04:25:55 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Thu, 23 Jan 2014 03:25:55 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1390447555.29.0.339868893083.issue20185@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Thanks, Serhiy, for the pointer. Now, I am able to convert the method using _PyEval_SliceIndex function. Sorry, Larry. I used optional groups in __init__ because I didn't know about unspecified. Here is the updated patch for listobject. One thought, for list.index method, I use this: stop: slice_index(c_default="Py_SIZE(self)") = unspecified Then the signature will be: "index(value, [start=0, [stop=unspecified]])\n" Somehow I prefer more explanatory signature: "index(value, [start=0, [stop=size of list]])\n" Anyway, this is a trivial thing. ---------- Added file: http://bugs.python.org/file33641/clinic_listobject_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 05:29:43 2014 From: report at bugs.python.org (Christopher Welborn) Date: Thu, 23 Jan 2014 04:29:43 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390451383.6.0.345361951556.issue20218@psf.upfronthosting.co.za> Christopher Welborn added the comment: Ram Rachum (and to whom it may concern): This patch was missing the size argument for readlines(), and it did not match the overall style of pathlib.py. (using ''' instead of """, and other docstring style). It also clobbered the builtin 'file'. I've attached another patch that tries very hard to match that 'style', and wrote tests that try to match what the original 'io' functions test for. This is my first patch for python-dev, I am attaching it in the hope it will help resolve the issue, or generate more discussion about it. I ran both the individual test_pathlib tests, and the entire test suite. Also, the patchcheck sanity test. ---------- Added file: http://bugs.python.org/file33642/pathlib.readwrite.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 05:42:07 2014 From: report at bugs.python.org (Christopher Welborn) Date: Thu, 23 Jan 2014 04:42:07 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390452127.66.0.153880308107.issue20218@psf.upfronthosting.co.za> Christopher Welborn added the comment: Sorry Antoine, I should've done my homework. I didn't realize 'to whom it may concern' is actually you. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 06:40:11 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 23 Jan 2014 05:40:11 +0000 Subject: [issue17390] display python version on idle title bar In-Reply-To: <1362920194.83.0.464215113749.issue17390@psf.upfronthosting.co.za> Message-ID: <3f8sky5Qdpz7LkN@mail.python.org> Roundup Robot added the comment: New changeset bcfbab86f49a by Terry Jan Reedy in branch '2.7': Issue #17390: Add Python version to Idle editor window title bar. http://hg.python.org/cpython/rev/bcfbab86f49a New changeset b26db63bb931 by Terry Jan Reedy in branch '3.3': Issue #17390: Add Python version to Idle editor window title bar. http://hg.python.org/cpython/rev/b26db63bb931 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 07:29:56 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 23 Jan 2014 06:29:56 +0000 Subject: [issue17390] display python version on idle title bar In-Reply-To: <1362920194.83.0.464215113749.issue17390@psf.upfronthosting.co.za> Message-ID: <1390458596.75.0.0345174099626.issue17390@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Edmond and Kent, thanks for the patch. Ezio, thanks for re-opening. After testing the patch with and without 'Editor', I preferred without. It is slightly redundant and noisy, especially when editing EditorWindow.py ;-). Also, Windows 7 stacks icons for windows belonging to a program under the program icon on the task bar. When the mouse is over the program icon, it pop up a window of *limited* width listing the window titles. The popup is narrow enough that paths to Idle test files in my repository clone get truncated when 'Editor' is added. I suspect that adding '''else: filename = "Untitled"''' to short_title() makes the corresponding '''else: title = "Untitled"''' in saved_change_hook() useless. I will check later for possible removal. Since I sometimes have multiple Find in File Output windows, I would like to expand their titles also. Since the Python version is irrelevant. I am thinking of Python: Matches for "" But I think their may be other uses of Output windows (easily found by searching for "Output" ;-). In any case, extensions and new features should be free to use use OutputWindow. So we cannot generically modify OutputWindow.short_title . If the self parameter of short_title does not somehow indicate that the output is for Find in Files, we can subclass and over-ride. class FiFWindow(OutputWindow): def short_title(self): return ---------- stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 07:41:42 2014 From: report at bugs.python.org (Ben Alpert) Date: Thu, 23 Jan 2014 06:41:42 +0000 Subject: [issue20353] Hanging bug with multiprocessing + sqlite3 + tkinter (OS X 10.9 only) In-Reply-To: <1390415067.55.0.719190169135.issue20353@psf.upfronthosting.co.za> Message-ID: <1390459302.24.0.637042692456.issue20353@psf.upfronthosting.co.za> Changes by Ben Alpert : ---------- nosy: +spicyj _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 08:37:40 2014 From: report at bugs.python.org (Arne Babenhauserheide) Date: Thu, 23 Jan 2014 07:37:40 +0000 Subject: [issue20345] Better logging defaults In-Reply-To: <1390400720.32.0.906733284392.issue20345@psf.upfronthosting.co.za> Message-ID: <1390462660.76.0.877367516195.issue20345@psf.upfronthosting.co.za> Arne Babenhauserheide added the comment: I do not think it is necessary to change the defaults, but I do think that it would help users of python. In the usecase of bigger applications, the default logging format does not matter: the overhead of logging.basicConfig() only happens once while the advantages help for the whole time. In the usecase of small programs and quick scripts, the overhead of having to use logging.basicConfig() is big, though: It requires reading up on the different formatting options and actually thinking about a good format. But the results only help that small script, and for the next script the programmer will likely have to read the documentation again. If logging would have a better default, the programmer would just have to remember ?import logging, then call logging.LEVEL()?. In the python console, logging. will autocomplete the level, so programmers do not actually have to read up anything: It actually goes down to ?log with logging?. And that?s a very different level of usability than having to call logging.basicConfig(). And I think that the filename and the line number is the minimum information necessary for any debug message - though the format could be matched to `grep -n` by replacing the double colon with a single colon. To stay with your analogy: It?s not about the color of the bikeshed. It?s about providing the basic bycycle stands in the shed, so people who have no strong feelings about bikesheds can simply go there, leave the bike and move on - instead of having to adjust the stand every time to keep their bike from falling over. I agree, though, that backwards compatibility could be an issue. Can you give me a hint, how I could investigate that? ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 08:50:30 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Thu, 23 Jan 2014 07:50:30 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1390463430.83.0.499391951747.issue20185@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the patch for floatobject. I did not convert 2 sites. The first is the round method which clinic explicitly does not support. The second one is the new method. This is the snippet of new method: float_new(PyTypeObject *type, PyObject *args, PyObject *kwds) { PyObject *x = Py_False; /* Integer zero */ static char *kwlist[] = {"x", 0}; if (type != &PyFloat_Type) return float_subtype_new(type, args, kwds); /* Wimp out */ if (!PyArg_ParseTupleAndKeywords(args, kwds, "|O:float", kwlist, &x)) return NULL; /* If it's a string, but not a string subclass, use PyFloat_FromString. */ if (PyUnicode_CheckExact(x)) return PyFloat_FromString(x); .... If I clinic this method, I could not put custom code before parsing arguments code anymore. This could affect the performance or may not be correct at all. ---------- Added file: http://bugs.python.org/file33643/clinic_floatobject.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 09:15:41 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Thu, 23 Jan 2014 08:15:41 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1390464941.58.0.221100340245.issue20185@psf.upfronthosting.co.za> Vajrasky Kok added the comment: This is updated patch for marshal incorporating the fixes from clinic. Now, I can use 'bytes' named argument and default value of marshal.version instead of hardcoded number. ---------- Added file: http://bugs.python.org/file33644/clinic_marshal_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 09:29:45 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 23 Jan 2014 08:29:45 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> Message-ID: <1390465785.83.0.938930089859.issue20341@psf.upfronthosting.co.za> Larry Hastings added the comment: > > Yes, that is a different name that seems to mean much the same > > thing. > and which is much more understandable by a Python developer. Thanks for your opinion. > > Changing error to an char and moving it to the end would > > save exactly zero bytes, because the compiler *will* align > > stack variables to 4 byte boundaries. > > Except if other stack variables happen to be shorter than an int, > perhaps. Do we use a lot of those? > But regardless, it doesn't cost anything to do so, so why not do it? I thought I just got through explaining how it is slightly slower. There is no benefit in changing them to "char", so why do it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 09:59:42 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 23 Jan 2014 08:59:42 +0000 Subject: [issue20355] -W command line options should have higher priority than PYTHONWARNINGS environmental variable In-Reply-To: <1390426906.93.0.692922610327.issue20355@psf.upfronthosting.co.za> Message-ID: <1390467582.21.0.50031537161.issue20355@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: The attached patch moves calls to PySys_AddWarnOption* for -W options to after parsing PYTHONWARNINGS. I think that this bug fix could be applied in Python 3.4. The patch does not introduce any failures in full test suite. ---------- keywords: +patch nosy: +larry Added file: http://bugs.python.org/file33645/python-warnings.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 10:00:19 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 23 Jan 2014 09:00:19 +0000 Subject: [issue20358] test_curses is failing Message-ID: <1390467619.0.0.459315516203.issue20358@psf.upfronthosting.co.za> New submission from Larry Hastings: If I build current trunk on my workstation (Linux 64-bit, Ubuntu 13.10) then run % ./python -m test -u all test_curses I get a traceback. Here's the interesting part: File "/home/larry/src/python/buildtrunk/Lib/test/test_curses.py", line 118, in window_funcs win2.overlay(win, 1, 2, 3, 3, 2, 1) _curses.error: copywin() returned ERR Zach: I just saw you had a patch specifically against test_curses.py, can you take a look? ---------- components: Library (Lib) messages: 208887 nosy: larry, zach.ware priority: high severity: normal stage: needs patch status: open title: test_curses is failing type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 10:03:49 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Thu, 23 Jan 2014 09:03:49 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1390467829.6.0.3861340737.issue20173@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the updated patch of sha1module, based on Larry's review. Thanks! ---------- Added file: http://bugs.python.org/file33646/clinic_sha1module_v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 10:06:05 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 23 Jan 2014 09:06:05 +0000 Subject: [issue20355] -W command line options should have higher priority than PYTHONWARNINGS environmental variable In-Reply-To: <1390426906.93.0.692922610327.issue20355@psf.upfronthosting.co.za> Message-ID: <1390467965.66.0.762014773348.issue20355@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 10:06:38 2014 From: report at bugs.python.org (Ram Rachum) Date: Thu, 23 Jan 2014 09:06:38 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390467998.88.0.0899969257631.issue20218@psf.upfronthosting.co.za> Ram Rachum added the comment: Hi Christopher, I like your patch. One thing I modified is returning to use `file` as the variable instead of `f`, since `file` is no longer a builtin in Python 3, and descriptive variable names are important. Attached as `pathlib.readwrite2.patch`. ---------- Added file: http://bugs.python.org/file33647/pathlib.readwrite2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 10:09:10 2014 From: report at bugs.python.org (Steve) Date: Thu, 23 Jan 2014 09:09:10 +0000 Subject: [issue20359] Having escape sequences (like color codes) in the sys.ps1 messes up readline's input line calculations Message-ID: <1390468150.14.0.430221265473.issue20359@psf.upfronthosting.co.za> New submission from Steve: If you change the sys.ps1 to have some color, you end up messing up readline's input line calculations and the characters in the line you are typing might not get displayed properly. This behaviour is easier to demonstrate/reporduce than explain ...: On a python promt with readline enabled (for instance, on any linux box): [steve at localhost ~]$ python Python 2.7.5 (default, Nov 12 2013, 16:18:42) [GCC 4.8.2 20131017 (Red Hat 4.8.2-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.ps1 = '\033[31m>>> \033[0m' >>> # doing a reverse-i-search (Ctrl+r) on the next line will mess up the prompt display ... >>> h)`sys': sys.ps1 = '\033[31m>>> \033[0m' (...press Ctrl-L to clear...) (reverse-i-search)`': (press enter) >>> arch)`': I did some (amateur) investigation and the root cause might be similar to what's reported at: http://trac.haskell.org/haskeline/ticket/78 https://groups.google.com/forum/#!topic/gnu.bash.bug/5P0gWzzLVOU FWIW, I bumped into this issue while customizing my .pythonrc[1] and although it might be a silly small annoyance, it would be really nice if this bug could be fixed. [1] https://gist.github.com/lonetwin/5902720 ---------- components: Library (Lib) messages: 208890 nosy: lonetwin priority: normal severity: normal status: open title: Having escape sequences (like color codes) in the sys.ps1 messes up readline's input line calculations type: behavior versions: Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 10:10:33 2014 From: report at bugs.python.org (Nadeem Vawda) Date: Thu, 23 Jan 2014 09:10:33 +0000 Subject: [issue20358] test_curses is failing In-Reply-To: <1390467619.0.0.459315516203.issue20358@psf.upfronthosting.co.za> Message-ID: <1390468233.25.0.418964957436.issue20358@psf.upfronthosting.co.za> Changes by Nadeem Vawda : ---------- nosy: +nadeem.vawda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 10:11:24 2014 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Jan 2014 09:11:24 +0000 Subject: [issue20359] Having escape sequences (like color codes) in the sys.ps1 messes up readline's input line calculations In-Reply-To: <1390468150.14.0.430221265473.issue20359@psf.upfronthosting.co.za> Message-ID: <1390468284.83.0.980596425847.issue20359@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks for the report. I think it's your obligation to surround nonprinting escape sequences with \x01 and \x02, with that change it works for me. ---------- nosy: +georg.brandl resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 10:12:36 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 23 Jan 2014 09:12:36 +0000 Subject: [issue20360] inspect.Signature could provide readable expressions for default values for builtins Message-ID: <1390468356.52.0.474182438326.issue20360@psf.upfronthosting.co.za> New submission from Larry Hastings: The signatures for builtins are stored as text and interpreted at runtime on demand. inspect.Signature gets the default value for a parameter as a text string, which it evaluates (by hand, in a highly constrained way) to produce the parameter's value member. Serhiy cleverly suggested that it'd be nice if Signature objects could also make this string available, as it's often more readable than the value. For example, there's a parameter in zlib with the default "MAX_DECOMPRESSION - 1"; that turns into 7 I think. Which would you prefer? Right now there's no place to store this in the parameter object, so it can't happen for 3.4. But perhaps in 3.5 we could add it, and figure out how to present it to the user. For example __str__ could use it. Thinking a little laterally: we *could* hide it in a *private* member on the Parameter object, then only use it for calculating __str__. That would look so fancy! Should we consider doing that for 3.4? ---------- messages: 208892 nosy: brett.cannon, larry, ncoghlan, serhiy.storchaka, yselivanov priority: normal severity: normal stage: needs patch status: open title: inspect.Signature could provide readable expressions for default values for builtins type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 10:12:55 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Jan 2014 09:12:55 +0000 Subject: [issue20358] test_curses is failing In-Reply-To: <1390467619.0.0.459315516203.issue20358@psf.upfronthosting.co.za> Message-ID: <1390468375.89.0.221139922636.issue20358@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 10:15:02 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 23 Jan 2014 09:15:02 +0000 Subject: [issue20338] Idle: increase max calltip width In-Reply-To: <1390344102.42.0.241411598779.issue20338@psf.upfronthosting.co.za> Message-ID: <1390468502.63.0.217243057506.issue20338@psf.upfronthosting.co.za> Terry J. Reedy added the comment: 1. For multiple reasons, I want to at least start with only wrapping the signature string. I want to keep the code as simple and fast as possible, and not worry much about rare oddball or PEP8-violating cases. I want to only do what is needed for the purpose of calltips, which is to remind one of the call sequence. Adding more detracts from that purpose. Tips are not intended to replace using the doc or help(f) to learn about f. As it is, I am not happy about possibly including more than 1 or 2 lines of a docstring for Python-coded functions. I intend to revisit that when the dust settles with Clinic and inspect. That fact that another patch *will* be needed, almost certainly, is another reason to not do too much now. Wrapping overly long docstrings should not needed. Even if the initial _MAX_COL slice of the first line of the docstring of a Python-coded function fails to say enough about the return value, there is help(f) to get full details. I reread PEP 8 and, contrary to what I (mis) remembered, it says that docstrings should remain limited to 72 (or 79) chars *even if* a project increases the limit for *code* lines up to say, 100. The reason for this is precisely because other software, like help, Idle, and others, read, process, and display docstrings. If docstrings violate this, I think they should be changed, and not accomadated (except as suggested below). So I want to add, before the docstring fetch, only this: if len(argspec) > _MAX_COLS: argspec = textwrap.wrap(argspec, _MAX_COLS, subsequent_indent=' ') dict is definitely an oddball and I do not want to include it in a test at this time. I do not mind suggesting help(dict), though the current docstring is incomplete. Here is the real signature and description, which I verified from the examples below. The multiple example lines should follow a condensed summary. def dict([map_or_it,] **kwds) '''Return new dictionary initialized from pairs of positional-only map_or_it, if present, and updated with kwds, if present. ''' >>> dict({'a':1}, b=2) {'b': 2, 'a': 1} >>> dict({'a':1}, a=2) {'a': 2} 2. For two reasons, I want to increase _MAX_COLS a bit, say to 85. First, when wrapping a signature, the 'words' after the first few typically have the form 'name=value'. They will average much longer than the average English word (4, I think). The average wrapped line length will be _MAX_COLS - half the average 'word' length. For example (one which should become a test): >>> for line in textwrap.wrap(str(signature(textwrap.TextWrapper)), width = 85, subsequent_indent=' '): print(line) (width=70, initial_indent='', subsequent_indent='', expand_tabs=True, replace_whitespace=True, fix_sentence_endings=False, break_long_words=True, drop_whitespace=True, break_on_hyphens=True, tabsize=8, *, max_lines=None, placeholder=' [...]') The lengths, including indents, are 69, 78, 77, and 24, all <= 79. Very few signature lines, wrapped or not, will fall in [80-85]. Second, PEP 8 allows initial summary lines to be 79 chars, as they are not "flowing long blocks of text". (I verified this with Guido.) Some docstrings in the stdlib 'cheat' a few chars, and 85 will accommodate those without ever being excessively long. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 10:19:49 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 23 Jan 2014 09:19:49 +0000 Subject: [issue20361] -W command line options and PYTHONWARNINGS environmental variable should not override -b / -bb command line options Message-ID: <1390468789.64.0.236388970509.issue20361@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis: Currently -W command line options and PYTHONWARNINGS environmental variable non-intuitively override settings specified by -b / -bb command line options. $ python3.4 -c 'print("" == b"")' False $ python3.4 -b -c 'print("" == b"")' -c:1: BytesWarning: Comparison between bytes and string False $ python3.4 -bb -c 'print("" == b"")' Traceback (most recent call last): File "", line 1, in BytesWarning: Comparison between bytes and string $ python3.4 -We -b -c 'print("" == b"")' Traceback (most recent call last): File "", line 1, in BytesWarning: Comparison between bytes and string $ python3.4 -Wd -bb -c 'print("" == b"")' -c:1: BytesWarning: Comparison between bytes and string False $ python3.4 -Wi -b -c 'print("" == b"")' False $ python3.4 -Wi -bb -c 'print("" == b"")' False $ I suggest to increase priority of -b / -bb command line options. The attached patch should be applied after patch from issue #20355. (Test suite of Python triggers some BytesWarnings, so firstly they will have to be fixed.) ---------- components: Interpreter Core files: python-bytes_warnings.patch keywords: patch messages: 208894 nosy: Arfrever, barry, brett.cannon, brian.curtin, eric.araujo, larry, pitrou, pjenvey, skrah priority: normal severity: normal status: open title: -W command line options and PYTHONWARNINGS environmental variable should not override -b / -bb command line options type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file33648/python-bytes_warnings.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 10:20:26 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 23 Jan 2014 09:20:26 +0000 Subject: [issue20361] -W command line options and PYTHONWARNINGS environmental variable should not override -b / -bb command line options In-Reply-To: <1390468789.64.0.236388970509.issue20361@psf.upfronthosting.co.za> Message-ID: <1390468826.94.0.767991856942.issue20361@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 10:24:07 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Thu, 23 Jan 2014 09:24:07 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1390469047.83.0.470224764154.issue20173@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the updated patch of sha256module, based on Larry's review. Thanks! ---------- Added file: http://bugs.python.org/file33649/clinic_sha256module_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 10:25:49 2014 From: report at bugs.python.org (Steve) Date: Thu, 23 Jan 2014 09:25:49 +0000 Subject: [issue20359] Having escape sequences (like color codes) in the sys.ps1 messes up readline's input line calculations In-Reply-To: <1390468150.14.0.430221265473.issue20359@psf.upfronthosting.co.za> Message-ID: <1390469149.76.0.391857798425.issue20359@psf.upfronthosting.co.za> Steve added the comment: wow, that was super quick ! Yes, indeed. Surrounding the escape sequences with '\0x1' & '\0x2' fixes this issue. Thanks ! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 10:26:54 2014 From: report at bugs.python.org (Steve) Date: Thu, 23 Jan 2014 09:26:54 +0000 Subject: [issue20359] Having escape sequences (like color codes) in the sys.ps1 messes up readline's input line calculations In-Reply-To: <1390468150.14.0.430221265473.issue20359@psf.upfronthosting.co.za> Message-ID: <1390469214.31.0.125873753684.issue20359@psf.upfronthosting.co.za> Steve added the comment: ...of course I meant \x01 and \x02, like you suggested ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 10:34:42 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 23 Jan 2014 09:34:42 +0000 Subject: [issue20361] -W command line options and PYTHONWARNINGS environmental variable should not override -b / -bb command line options In-Reply-To: <1390468789.64.0.236388970509.issue20361@psf.upfronthosting.co.za> Message-ID: <1390469682.37.0.984194854298.issue20361@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: By the way, Tools/scripts/run_tests.py (used by 'test' target in Makefile) passes '-W default -bb', which currently fails work as intended (i.e. treating BytesWarnings as errors). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 10:39:37 2014 From: report at bugs.python.org (Dhara) Date: Thu, 23 Jan 2014 09:39:37 +0000 Subject: [issue20362] longMessage attribute is ignored in unittest.TestCase.assertRegexpMatches etc Message-ID: <1390469977.33.0.983072297482.issue20362@psf.upfronthosting.co.za> New submission from Dhara: Various assert methods added in version 2.7 ignore the longMessage attribute: http://docs.python.org/2.7/library/unittest.html#unittest.TestCase.longMessage For example when matching regular expressions using unittest.TestCase.assertRegexpMatches, the following error is generated: AssertionError: : '' not found in '' Since longMessage is ignored, and the text to be matched can be pages long, the error messages are impossibly long. [See also: http://stackoverflow.com/questions/21157905/suppress-supplementary-error-message-from-unit-test] ---------- components: Library (Lib) messages: 208899 nosy: Dhara priority: normal severity: normal status: open title: longMessage attribute is ignored in unittest.TestCase.assertRegexpMatches etc type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 10:41:34 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Jan 2014 09:41:34 +0000 Subject: [issue20338] Idle: increase max calltip width In-Reply-To: <1390344102.42.0.241411598779.issue20338@psf.upfronthosting.co.za> Message-ID: <1390470094.71.0.995993492577.issue20338@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Well, do this. I think we should add several test functions with too long signatures and/or docstrings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 10:43:06 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Jan 2014 09:43:06 +0000 Subject: [issue20338] Idle: increase max calltip width In-Reply-To: <1390344102.42.0.241411598779.issue20338@psf.upfronthosting.co.za> Message-ID: <1390470186.56.0.456909510264.issue20338@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And note that currently there is a bug in doc.split('\n', 5)[:_MAX_LINES]. An argument of split() should be _MAX_LINES. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 10:46:29 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Thu, 23 Jan 2014 09:46:29 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1390470389.75.0.289989386122.issue20173@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the updated patch of sha512module, based on Larry's review. Thanks! ---------- Added file: http://bugs.python.org/file33650/clinic_sha512module_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 10:47:31 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 23 Jan 2014 09:47:31 +0000 Subject: [issue20363] BytesWarnings triggerred by test suite Message-ID: <1390470451.71.0.00122717133798.issue20363@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis: [194/388] test_base64 /tmp/cpython/Lib/base64.py:365: BytesWarning: str() on a bytes instance "by {} and {}".format(_A85START, _A85END)) ... [204/388] test_hash /tmp/cpython/Lib/test/test_hash.py:175: BytesWarning: str() on a bytes instance return 'print(hash(eval(%s.decode("utf-8"))))' % repr_.encode("utf-8") ... [234/388] test_configparser /tmp/cpython/Lib/configparser.py:289: BytesWarning: str() on a bytes instance Error.__init__(self, 'Source contains parsing errors: %s' % source) /tmp/cpython/Lib/configparser.py:326: BytesWarning: str() on a bytes instance (filename, lineno, line)) ... [332/388/1] test_distutils /tmp/cpython/Lib/distutils/command/register.py:303: BytesWarning: str() on a bytes instance self.announce('%s%s%s' % (dashes, data, dashes)) ---------- components: Library (Lib) messages: 208903 nosy: Arfrever, eric.araujo, lukasz.langa, tarek priority: normal severity: normal status: open title: BytesWarnings triggerred by test suite versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 10:48:19 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 23 Jan 2014 09:48:19 +0000 Subject: [issue20361] -W command line options and PYTHONWARNINGS environmental variable should not override -b / -bb command line options In-Reply-To: <1390468789.64.0.236388970509.issue20361@psf.upfronthosting.co.za> Message-ID: <1390470499.1.0.412622524193.issue20361@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- dependencies: +BytesWarnings triggerred by test suite _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 11:06:47 2014 From: report at bugs.python.org (=?utf-8?q?Dani=C3=ABl_van_Eeden?=) Date: Thu, 23 Jan 2014 10:06:47 +0000 Subject: [issue20352] Add support for AUTH command to poplib In-Reply-To: <1390414659.94.0.817881856376.issue20352@psf.upfronthosting.co.za> Message-ID: <1390471607.54.0.823911326419.issue20352@psf.upfronthosting.co.za> Dani?l van Eeden added the comment: As far as I understood the RFC: A client should send CAPA and check if there is a SASL tag in the response (e.g. "SASL PLAIN"). =============================== +OK Dovecot ready. AUTH PLAIN base64_encoded_info +OK Logged in. LIST =============================== I've replace the base64 encoded authentication info with 'base64_encoded_info' For other authentication mechanisms the response can be longer (it may contain a challenge) and the request may only contain the mechanim. I don't have a server which supports anything else than AUTH PLAIN, so I could verify/test this. ---------- keywords: +patch Added file: http://bugs.python.org/file33651/poplib_auth.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 11:10:17 2014 From: report at bugs.python.org (Steve) Date: Thu, 23 Jan 2014 10:10:17 +0000 Subject: [issue20359] Having escape sequences (like color codes) in the sys.ps1 messes up readline's input line calculations In-Reply-To: <1390468150.14.0.430221265473.issue20359@psf.upfronthosting.co.za> Message-ID: <1390471817.65.0.0410014717018.issue20359@psf.upfronthosting.co.za> Steve added the comment: Although surrounding the escapes with \x01 and \x02 worked to correctly remove the message while doing a reverse-i-search (thus preserving the original line), the input line measurement still appears to be incorrect as demonstated with the following actions: [steve at localhost ~]$ python Python 2.7.5 (default, Nov 12 2013, 16:18:42) [GCC 4.8.2 20131017 (Red Hat 4.8.2-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.ps1 = '\x01\033[32m>>> \033[0m\x02' >>> # on the next line, press the up arrow to get this line and then backspace, over the entire prompt ... #<-- backspaced up until here ... ...again, not a big deal, just annoying when deleting word with a repeated 'alt+backspace' or ctrl+w ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 11:33:42 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 23 Jan 2014 10:33:42 +0000 Subject: [issue20336] test_asyncio: relax timings even more In-Reply-To: <1390343391.65.0.626852689754.issue20336@psf.upfronthosting.co.za> Message-ID: <1390473222.46.0.546593078242.issue20336@psf.upfronthosting.co.za> Stefan Krah added the comment: I'm seeing other unrelated timeouts on the OpenIndiana machines. Jes?s, are the machines perhaps operating under an unusually high load? ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 11:38:37 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Thu, 23 Jan 2014 10:38:37 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1390473517.01.0.26028883728.issue20173@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the updated patch of md5module, based on Larry's review. Thanks! ---------- Added file: http://bugs.python.org/file33652/clinic_md5module_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 11:42:59 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 23 Jan 2014 10:42:59 +0000 Subject: [issue20364] Rename & explain sqlite3.Cursor.execute 'parameters' param Message-ID: <1390473779.26.0.463818219743.issue20364@psf.upfronthosting.co.za> New submission from Terry J. Reedy: "execute(sql[, parameters]) Executes an SQL statement. The SQL statement may be parametrized (i. e. placeholders instead of SQL literals). The sqlite3 module supports two kinds of placeholders: question marks (qmark style) and named placeholders (named style)." Experimental facts based on experiments with the code example in the doc, using 3.4.b2: 'parameters' is a single subscriptable collection parameter, sequence or dict, that might be called seq_dict. It is positional only, so whatever name is used is a dummy. Only one placeholder style can be used in a given SQL statement string. If question marks are used, seq_dict must be a sequence. If names are used, seq_dict can be either a sequence or dict or subclass thereof. A UserDict is treated as a sequence and raises KeyError(0). Possible text that encompasses the above, replacing the last sentence: "A statement may use one of two kinds of placeholders: question marks (qmark style) or named placeholders (named style). For qmark style, seq_dict must be a sequence. For named style, it can be either a sequence or dict instance. Len(seq_dict) must match the number of placeholders." After cleaning up the test file, I will verify on 2.7 and upload. ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 208908 nosy: docs at python, terry.reedy priority: normal severity: normal stage: patch review status: open title: Rename & explain sqlite3.Cursor.execute 'parameters' param type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 11:43:20 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 23 Jan 2014 10:43:20 +0000 Subject: [issue20336] test_asyncio: relax timings even more In-Reply-To: <1390343391.65.0.626852689754.issue20336@psf.upfronthosting.co.za> Message-ID: <1390473800.59.0.372360582115.issue20336@psf.upfronthosting.co.za> STINNER Victor added the comment: > I'm seeing other unrelated timeouts on the OpenIndiana machines. I read somewhere that the host of these virtual machines is *highly* loaded (load > 6). It's more a buildbot configuration issue than a test_asyncio issue. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 11:43:45 2014 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Jan 2014 10:43:45 +0000 Subject: [issue20359] Having escape sequences (like color codes) in the sys.ps1 messes up readline's input line calculations In-Reply-To: <1390468150.14.0.430221265473.issue20359@psf.upfronthosting.co.za> Message-ID: <1390473825.12.0.819542797307.issue20359@psf.upfronthosting.co.za> Georg Brandl added the comment: I think you're using the escapes correctly: you must only escape nonprinting characters. Try >>> sys.ps1 = '\x01\033[32m\x02>>> \x01\033[0m\x02' ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 11:46:30 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 23 Jan 2014 10:46:30 +0000 Subject: [issue20336] test_asyncio: relax timings even more In-Reply-To: <1390343391.65.0.626852689754.issue20336@psf.upfronthosting.co.za> Message-ID: <1390473990.57.0.812530883857.issue20336@psf.upfronthosting.co.za> Stefan Krah added the comment: I see. That's astonishing, because usually the builds are ultra-fast on those machines. ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 11:53:01 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 23 Jan 2014 10:53:01 +0000 Subject: [issue20336] test_asyncio: relax timings even more In-Reply-To: <1390343391.65.0.626852689754.issue20336@psf.upfronthosting.co.za> Message-ID: <1390474381.79.0.751112290109.issue20336@psf.upfronthosting.co.za> STINNER Victor added the comment: Tests failing because of timings is really annoying. It would be nice to add something in test.support to configure timings. A function can maybe wait until the system load is lower than a threshold, or we should add a parameter to configure a tolerance between the perfect timing and the expected timing. The tolerance can be a simple factor, a floating point number >= 1.0. For example, replace: 0.09 <= t1-t0 <= 0.9, t1-t0 with 0.1 - 0.01 * factor <= t1-t0 <= 0.1 + 0.8 * factor or a new test function: check_timing(t1-t0, 0.1, 0.01, 0.8) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 11:59:32 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 23 Jan 2014 10:59:32 +0000 Subject: [issue20336] test_asyncio: relax timings even more In-Reply-To: <1390343391.65.0.626852689754.issue20336@psf.upfronthosting.co.za> Message-ID: <1390474772.43.0.957360410242.issue20336@psf.upfronthosting.co.za> Stefan Krah added the comment: +1 for doing something about timing failures. Perhaps also a decorator @skip_if_load_higher_than(x). [Nick, I'm adding you because our current test suite could lead to "commit impossible" situations with Zuul.] ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 12:38:26 2014 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 23 Jan 2014 11:38:26 +0000 Subject: [issue20345] Better logging defaults In-Reply-To: <1390400720.32.0.906733284392.issue20345@psf.upfronthosting.co.za> Message-ID: <1390477106.22.0.802796370662.issue20345@psf.upfronthosting.co.za> Vinay Sajip added the comment: > Can you give me a hint, how I could investigate that? There's no easy way - a lot of Python source is not available for public view, so there's no telling what the impact would be. While the use of the module-level functions is provided as a convenience, I don't feel that the need to call basicConfig () is problematic, even for short scripts. ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 13:29:56 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 23 Jan 2014 12:29:56 +0000 Subject: [issue20319] concurrent.futures.wait() can block forever even if Futures have completed In-Reply-To: <1390263519.32.0.357208079457.issue20319@psf.upfronthosting.co.za> Message-ID: <1390480196.57.0.457321379693.issue20319@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 13:31:25 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 23 Jan 2014 12:31:25 +0000 Subject: [issue20319] concurrent.futures.wait() can block forever even if Futures have completed In-Reply-To: <1390263519.32.0.357208079457.issue20319@psf.upfronthosting.co.za> Message-ID: <1390480285.75.0.455650764202.issue20319@psf.upfronthosting.co.za> Mark Dickinson added the comment: Adding Tim Peters to the nosy, since I suspect he has a general interest in this kind of issue. As far as I know Brian Quinlan isn't actively maintaining concurrent.futures at the moment (Brian: please correct me if I'm wrong). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 13:31:42 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 23 Jan 2014 12:31:42 +0000 Subject: [issue20319] concurrent.futures.wait() can block forever even if Futures have completed In-Reply-To: <1390263519.32.0.357208079457.issue20319@psf.upfronthosting.co.za> Message-ID: <1390480302.37.0.482587669409.issue20319@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 13:33:04 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 23 Jan 2014 12:33:04 +0000 Subject: [issue19863] Missing function attributes in 2.7 docs. In-Reply-To: <1386010673.68.0.260580445507.issue19863@psf.upfronthosting.co.za> Message-ID: <1390480384.94.0.438696036374.issue19863@psf.upfronthosting.co.za> Mark Dickinson added the comment: > LGTM, but may be write Py3k compatible names at first place? Sure; I don't have strong opinions either way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 13:45:20 2014 From: report at bugs.python.org (Glenn Langford) Date: Thu, 23 Jan 2014 12:45:20 +0000 Subject: [issue20297] concurrent.futures.as_completed() installs waiters for already completed Futures In-Reply-To: <1390079975.89.0.167689725202.issue20297@psf.upfronthosting.co.za> Message-ID: <1390481120.03.0.164516270054.issue20297@psf.upfronthosting.co.za> Changes by Glenn Langford : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 14:12:51 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 23 Jan 2014 13:12:51 +0000 Subject: [issue20319] concurrent.futures.wait() can block forever even if Futures have completed In-Reply-To: <1390263519.32.0.357208079457.issue20319@psf.upfronthosting.co.za> Message-ID: <1390482771.0.0.168384597344.issue20319@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 14:13:15 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 23 Jan 2014 13:13:15 +0000 Subject: [issue20319] concurrent.futures.wait() can block forever even if Futures have completed In-Reply-To: <1390263519.32.0.357208079457.issue20319@psf.upfronthosting.co.za> Message-ID: <1390482795.2.0.61631946493.issue20319@psf.upfronthosting.co.za> STINNER Victor added the comment: @Glenn: Can you maybe suggest a patch fixing the issue? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 14:20:39 2014 From: report at bugs.python.org (Glenn Langford) Date: Thu, 23 Jan 2014 13:20:39 +0000 Subject: [issue20319] concurrent.futures.wait() can block forever even if Futures have completed In-Reply-To: <1390263519.32.0.357208079457.issue20319@psf.upfronthosting.co.za> Message-ID: <1390483239.79.0.903763318288.issue20319@psf.upfronthosting.co.za> Glenn Langford added the comment: @Victor: Would like to give a patch but I am not a core developer, and I don't version control set up yet. The proposed fix is based on reading the distribution source code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 14:22:49 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 23 Jan 2014 13:22:49 +0000 Subject: [issue20362] longMessage attribute is ignored in unittest.TestCase.assertRegexpMatches etc In-Reply-To: <1390469977.33.0.983072297482.issue20362@psf.upfronthosting.co.za> Message-ID: <1390483369.17.0.0475153222244.issue20362@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +ezio.melotti, michael.foord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 14:25:39 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 23 Jan 2014 13:25:39 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390465785.83.0.938930089859.issue20341@psf.upfronthosting.co.za> Message-ID: <1390483535.2293.1.camel@fsol> Antoine Pitrou added the comment: I insist that "nullable" is a very bad name. It also suggests that somehow we'll get a NULL pointer (in C) when the parameter is absent or None, which is not the case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 14:31:37 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 23 Jan 2014 13:31:37 +0000 Subject: [issue20319] concurrent.futures.wait() can block forever even if Futures have completed In-Reply-To: <1390263519.32.0.357208079457.issue20319@psf.upfronthosting.co.za> Message-ID: <1390483897.82.0.871008828394.issue20319@psf.upfronthosting.co.za> STINNER Victor added the comment: futures.patch: reuse _AcquireFutures context manager to protect the list of futures against concurrent access. Without the patch, stress_wait.py hangs. With the patch, it works correctly. ---------- keywords: +patch Added file: http://bugs.python.org/file33653/futures.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 14:48:03 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 23 Jan 2014 13:48:03 +0000 Subject: [issue20297] concurrent.futures.as_completed() installs waiters for already completed Futures In-Reply-To: <1390079975.89.0.167689725202.issue20297@psf.upfronthosting.co.za> Message-ID: <1390484883.11.0.423030776975.issue20297@psf.upfronthosting.co.za> STINNER Victor added the comment: I attached Glenn's function as a patch. Comments on as_completed_proposed.patch: - _create_and_install_waiters() doesn't remove duplicates using set(), so you change the behaving of as_completed(). I don't think that it is correct. as_completed([f, f]) should yield f twice, but I didn't check the current behaviour. Future._waiters is a list and so accept duplicated waiters. - you replaced the _AcquireFutures context manager on all futures with an individual lock. In my opinion, it should be changed in a different patch. I don't know which option is better, but if it is changed, it should be changed in the whole file. @Glenn: You should take a look at the Python Developer's Guide to learn how to write a patch and how to contribute to Python ;-) http://docs.python.org/devguide/ ---------- keywords: +patch nosy: +haypo Added file: http://bugs.python.org/file33654/as_completed_proposed.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 14:49:23 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 23 Jan 2014 13:49:23 +0000 Subject: [issue19291] Add docs for asyncio package (Tulip, PEP 3156) In-Reply-To: <1382137119.85.0.0934203099722.issue19291@psf.upfronthosting.co.za> Message-ID: <1390484963.52.0.9333758237.issue19291@psf.upfronthosting.co.za> STINNER Victor added the comment: > I've done a bit of it now, I'll let other people continue. I continued the work on the documentation. Even if it's not complete, I consider that the initial issue "Add docs for asyncio package (Tulip, PEP 3156)" is done, and so I close the issue. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 14:55:51 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 23 Jan 2014 13:55:51 +0000 Subject: [issue20352] Add support for AUTH command to poplib In-Reply-To: <1390414659.94.0.817881856376.issue20352@psf.upfronthosting.co.za> Message-ID: <1390485351.4.0.290589167287.issue20352@psf.upfronthosting.co.za> R. David Murray added the comment: imaplib has an API for handling that kind of thing. Maybe we can model the poplib support off of that API. It would be nice to be consistent, assuming it in fact makes sense for poplib as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:00:43 2014 From: report at bugs.python.org (Christopher Welborn) Date: Thu, 23 Jan 2014 14:00:43 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390485643.43.0.507106704156.issue20218@psf.upfronthosting.co.za> Christopher Welborn added the comment: Ram Rachum: Have you look at the source for pathlib? f and fd are common names for file descriptors, especially when using the open() function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:01:18 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 23 Jan 2014 14:01:18 +0000 Subject: [issue20313] inspect.signature should raise ValueError for builtins with no signature info In-Reply-To: <1390236993.79.0.241444273763.issue20313@psf.upfronthosting.co.za> Message-ID: <1390485678.27.0.935943443538.issue20313@psf.upfronthosting.co.za> Larry Hastings added the comment: I've worked your changes into the patch for #20189. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:04:45 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 23 Jan 2014 14:04:45 +0000 Subject: [issue20364] Rename & explain sqlite3.Cursor.execute 'parameters' param In-Reply-To: <1390473779.26.0.463818219743.issue20364@psf.upfronthosting.co.za> Message-ID: <1390485885.1.0.810604341533.issue20364@psf.upfronthosting.co.za> R. David Murray added the comment: I wonder if the fact that a sequence is accepted in named mode should actually be considered a bug and not documented. Also, is it really true that the number of items must match even in named mode? I think I remember passing a dict with extra elements, but I don't have that code handy to check. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:06:47 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 23 Jan 2014 14:06:47 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <1390486007.57.0.823072031506.issue20311@psf.upfronthosting.co.za> STINNER Victor added the comment: http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/9552 ====================================================================== FAIL: test_timeout_rounding (test.test_epoll.TestEPoll) ---------------------------------------------------------------------- Traceback (most recent call last): File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_epoll.py", line 59, in test_timeout_rounding self.assertGreaterEqual(dt, timeout) AssertionError: 0.009316698648035526 not greater than or equal to 0.01 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:07:36 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 23 Jan 2014 14:07:36 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <3f950Q5Xjkz7Ljf@mail.python.org> Roundup Robot added the comment: New changeset 3637ccf9516a by Victor Stinner in branch 'default': Issue #20311: add debug help in test_selectors http://hg.python.org/cpython/rev/3637ccf9516a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:10:12 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 23 Jan 2014 14:10:12 +0000 Subject: [issue19334] test_asyncio hanging for 1 hour (non-AIX version) In-Reply-To: <1382366717.5.0.644107908192.issue19334@psf.upfronthosting.co.za> Message-ID: <1390486212.62.0.0164914764736.issue19334@psf.upfronthosting.co.za> STINNER Victor added the comment: I looked at last tests of "FreeBSD 6.4 3.x" between builds 4400 and 4432. The builds 4401, 4408, 4416 and 4421 hanged but because of check_interrupted_write_retry() of test_io, but none hanged because of test_asyncio. I also checked builds 3620..3643 of "x86 RHEL 6 3.x": all succeeded. Same on "x86 Ubuntu Shared 3.x": no hang between builds 9560 and 9568. So I consider this issue as fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:12:37 2014 From: report at bugs.python.org (Ram Rachum) Date: Thu, 23 Jan 2014 14:12:37 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390486357.54.0.516687365623.issue20218@psf.upfronthosting.co.za> Changes by Ram Rachum : Removed file: http://bugs.python.org/file33647/pathlib.readwrite2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:13:10 2014 From: report at bugs.python.org (Ram Rachum) Date: Thu, 23 Jan 2014 14:13:10 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390486390.63.0.292515226194.issue20218@psf.upfronthosting.co.za> Ram Rachum added the comment: You're right. I deleted my 2 patches, so `pathlib.readwrite.patch` is now the best patch for this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:13:17 2014 From: report at bugs.python.org (Ram Rachum) Date: Thu, 23 Jan 2014 14:13:17 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390486397.56.0.0354272825992.issue20218@psf.upfronthosting.co.za> Changes by Ram Rachum : Removed file: http://bugs.python.org/file33616/patch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:18:19 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 23 Jan 2014 14:18:19 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390486699.23.0.481693309547.issue20218@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the patches, but please let's not hurry this up. We first need to decide on an API (which should be minimal). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:21:31 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 23 Jan 2014 14:21:31 +0000 Subject: [issue19334] test_asyncio hanging for 1 hour (non-AIX version) In-Reply-To: <1390486212.62.0.0164914764736.issue19334@psf.upfronthosting.co.za> Message-ID: <20140123142130.GA16472@sleipnir.bytereef.org> Stefan Krah added the comment: It was hanging on FreeBSD 7.2 recently: http://buildbot.python.org/all/builders/x86%20FreeBSD%207.2%203.x/builds/4917/steps/test/logs/stdio The older FreeBSD systems have broken threading though, so we could just disable the offending tests. I would not waste time debugging anything threading related before FreeBSD 9.0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:24:46 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 23 Jan 2014 14:24:46 +0000 Subject: [issue19936] Executable permissions of Python source files In-Reply-To: <1386588201.39.0.841678145847.issue19936@psf.upfronthosting.co.za> Message-ID: <3f95NF3GWDz7Ljf@mail.python.org> Roundup Robot added the comment: New changeset 1cfce469642d by Serhiy Storchaka in branch '3.3': Issue #19936: Restored executable bits for several libffi files. http://hg.python.org/cpython/rev/1cfce469642d New changeset 9adce4e25bdb by Serhiy Storchaka in branch 'default': Issue #19936: Restored executable bits for several libffi files. http://hg.python.org/cpython/rev/9adce4e25bdb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:25:59 2014 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 23 Jan 2014 14:25:59 +0000 Subject: [issue20360] inspect.Signature could provide readable expressions for default values for builtins In-Reply-To: <1390468356.52.0.474182438326.issue20360@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: It wouldn't be the first time I've used a private variable to fix a problem while still abiding by the no-new-features rule, but I think in this particular case we're better off waiting :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:28:16 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 23 Jan 2014 14:28:16 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1390487296.18.0.206093110411.issue20189@psf.upfronthosting.co.za> Larry Hastings added the comment: At last, my refreshed patch. Changes from the previous patch: * Had another mildly bright idea. The name "PyTypeObject *cls" is a holdover from < Python 2.2 days, before the merging of classes and types. Now they're both the same thing and the official name in Python is "type". So the self_converter uses the word "type". * Added __text_signature__ to PyType_Type. * Removed __text_signature__ from PyMemberDescr_Type, as it's not callable. (What was I thinking!) * Hand-coded signatures for default docstrings for slots. * Hand-coded signature for type and object. (The one for type isn't correct, I know, we'll get there.) * clinic.py now generates self/module/type parameters for most text signatures; these are then stripped off if the function is bound. * Ensured that inspect.signature raises ValueError if it can't generate a signature for a callable object. * Added unit tests. * Suppress the null "self" parameter for METH_STATIC calls in the impl. * If you have an empty docstring for __new__ or __init__, it suppresses the static variables completely. * Functions with a self converter use the type of self for the parsing function. (Except __new__ and __init__, which must conform to using PyObject *.) Boy am I emotionally ready to check this thing in. ---------- Added file: http://bugs.python.org/file33655/larry.support.text_signature.on.more.types.6.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:30:14 2014 From: report at bugs.python.org (Arne Babenhauserheide) Date: Thu, 23 Jan 2014 14:30:14 +0000 Subject: [issue20345] Better logging defaults In-Reply-To: <1390400720.32.0.906733284392.issue20345@psf.upfronthosting.co.za> Message-ID: <1390487414.79.0.200252286917.issue20345@psf.upfronthosting.co.za> Arne Babenhauserheide added the comment: Just calling basicConfig() is not problematic. Specifying the format is what requires mental investment (because for that I need to read up on the config options). Would it be possible to add a simple way to select a certain logging style? In Mercurial I can for example call `hg log --style changelog` to get GNU-style changelog output. This is easy to remember. On the other hand, getting --template "string" right for somewhat complex log styles is a small task in itself. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:31:49 2014 From: report at bugs.python.org (Arne Babenhauserheide) Date: Thu, 23 Jan 2014 14:31:49 +0000 Subject: [issue20345] Better logging defaults In-Reply-To: <1390400720.32.0.906733284392.issue20345@psf.upfronthosting.co.za> Message-ID: <1390487509.0.0.478034386911.issue20345@psf.upfronthosting.co.za> Arne Babenhauserheide added the comment: (though calling logging.basicConfig() still produces some overhead, it does not pull me away from the task I?m currently doing) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:32:09 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 23 Jan 2014 14:32:09 +0000 Subject: [issue19334] test_asyncio hanging for 1 hour (non-AIX version) In-Reply-To: <1382366717.5.0.644107908192.issue19334@psf.upfronthosting.co.za> Message-ID: <1390487529.81.0.672312179327.issue19334@psf.upfronthosting.co.za> STINNER Victor added the comment: > It was hanging on FreeBSD 7.2 recently: > http://buildbot.python.org/all/builders/x86%20FreeBSD%207.2%203.x/builds/4917/steps/test/logs/stdio This is a new issue, test_read_pty_output() is a recent feature which came with a new test. The previous blocking test was test_signal_handling_while_selecting(). Please open a new issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:32:42 2014 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 23 Jan 2014 14:32:42 +0000 Subject: [issue20336] test_asyncio: relax timings even more In-Reply-To: <1390343391.65.0.626852689754.issue20336@psf.upfronthosting.co.za> Message-ID: <1390487562.44.0.565617379043.issue20336@psf.upfronthosting.co.za> Nick Coghlan added the comment: I have a draft PEP for the Zuul idea, and yes, it notes the increased consequences of declaring a buildbot stable when it sometimes isn't. There's a reason OpenStack treats third party test results as advisory only rather than as gating criteria :P ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:33:18 2014 From: report at bugs.python.org (Ram Rachum) Date: Thu, 23 Jan 2014 14:33:18 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390487598.23.0.747192030995.issue20218@psf.upfronthosting.co.za> Ram Rachum added the comment: Antoine: Which parts of the API merit discussion? The method names? Whether to include readlines/writelines? The arguments? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:33:19 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 23 Jan 2014 14:33:19 +0000 Subject: [issue20365] test_asyncio.test_read_pty_output() fails on "AMD64 Snow Leop 3.x" buildbot Message-ID: <1390487599.93.0.989391561311.issue20365@psf.upfronthosting.co.za> New submission from STINNER Victor: kqueue doesn't support character devices like PTY before Mac OS 10.9. This issue is discussion on Tulip mailing list, no decision was taken yet how to fix this issue. http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/1071/steps/test/logs/stdio ====================================================================== ERROR: test_read_pty_output (test.test_asyncio.test_events.KqueueEventLoopTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/asyncio/selector_events.py", line 135, in add_reader key = self._selector.get_key(fd) File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/selectors.py", line 181, in get_key raise KeyError("{!r} is not registered".format(fileobj)) from None KeyError: '7 is not registered' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_asyncio/test_events.py", line 980, in test_read_pty_output self.loop.run_until_complete(connect()) File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/asyncio/base_events.py", line 177, in run_until_complete return future.result() File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/asyncio/futures.py", line 236, in result raise self._exception File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/asyncio/tasks.py", line 281, in _step result = next(coro) File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_asyncio/test_events.py", line 974, in connect master_read_obj) File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/asyncio/base_events.py", line 537, in connect_read_pipe transport = self._make_read_pipe_transport(pipe, protocol, waiter) File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/asyncio/unix_events.py", line 149, in _make_read_pipe_transport return _UnixReadPipeTransport(self, pipe, protocol, waiter, extra) File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/asyncio/unix_events.py", line 200, in __init__ self._loop.add_reader(self._fileno, self._read_ready) File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/asyncio/selector_events.py", line 138, in add_reader (handle, None)) File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/selectors.py", line 462, in register self._kqueue.control([kev], 0, 0) OSError: [Errno 22] Invalid argument ---------- components: Tests keywords: buildbot messages: 208941 nosy: gvanrossum, haypo priority: normal severity: normal status: open title: test_asyncio.test_read_pty_output() fails on "AMD64 Snow Leop 3.x" buildbot versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:33:33 2014 From: report at bugs.python.org (Glenn Langford) Date: Thu, 23 Jan 2014 14:33:33 +0000 Subject: [issue20297] concurrent.futures.as_completed() installs waiters for already completed Futures In-Reply-To: <1390079975.89.0.167689725202.issue20297@psf.upfronthosting.co.za> Message-ID: <1390487613.45.0.0243300012157.issue20297@psf.upfronthosting.co.za> Glenn Langford added the comment: Comments on @Victor's comments - I will have a look at the dev guide. :-) I think you have identified another bug in the current code. "Future._waiters is a list and so accept duplicated waiters." What this means is that the following code is broken, because it attempts to remove the Future twice from the pending set. for future in finished: yield future pending.remove(future) ## KeyError triggered on as_completed( [f,f] ) See attached test which demonstrates the breakage. Also, the behaviour of as_completed([f,f]) and wait([f,f], return_when=ALL_COMPLETED) is currently different. wait will only yield f once. ---------- Added file: http://bugs.python.org/file33656/test_dupfuture.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:36:16 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 23 Jan 2014 14:36:16 +0000 Subject: [issue20297] concurrent.futures.as_completed() installs waiters for already completed Futures In-Reply-To: <1390079975.89.0.167689725202.issue20297@psf.upfronthosting.co.za> Message-ID: <1390487776.3.0.577334263918.issue20297@psf.upfronthosting.co.za> STINNER Victor added the comment: > I think you have identified another bug in the current code. Please open a separated issue in this case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:37:44 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Jan 2014 14:37:44 +0000 Subject: [issue19936] Executable permissions of Python source files In-Reply-To: <1386588201.39.0.841678145847.issue19936@psf.upfronthosting.co.za> Message-ID: <1390487864.1.0.654406272607.issue19936@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Now findnoshebang.py shows only example files in the documentation, Windows-specific bat and pyw files, generated files, and the Modules/_ctypes/libffi/ltmain.sh file. I have not touched ltmain.sh file which have no shebang nor executable bits in the libffi distribution, because I'm not sure this is safe. Thanks all for reviews. ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:38:59 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 23 Jan 2014 14:38:59 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> Message-ID: <1390487939.8.0.692379294423.issue20341@psf.upfronthosting.co.za> Larry Hastings added the comment: I think it's a fine name, otherwise I would not have chosen it in the first place. Your high-spirited bikeshedding has been noted and not acted upon. I have no plans to change the name. Please drop it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:39:10 2014 From: report at bugs.python.org (Mark Summerfield) Date: Thu, 23 Jan 2014 14:39:10 +0000 Subject: [issue20366] SQLite FTS (full text search) Message-ID: <1390487950.26.0.724740577433.issue20366@psf.upfronthosting.co.za> New submission from Mark Summerfield: This is a feature request that future versions of SQLite 3 that are bundled with Python 3 in the Windows binary packages (.msi files) has been build with the FTS4 (full text search version 4) enabled. ---------- components: Extension Modules messages: 208946 nosy: mark priority: normal severity: normal status: open title: SQLite FTS (full text search) type: enhancement versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:41:37 2014 From: report at bugs.python.org (Glenn Langford) Date: Thu, 23 Jan 2014 14:41:37 +0000 Subject: [issue20297] concurrent.futures.as_completed() installs waiters for already completed Futures In-Reply-To: <1390079975.89.0.167689725202.issue20297@psf.upfronthosting.co.za> Message-ID: <1390488097.16.0.17471614551.issue20297@psf.upfronthosting.co.za> Changes by Glenn Langford : Removed file: http://bugs.python.org/file33656/test_dupfuture.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:43:21 2014 From: report at bugs.python.org (Glenn Langford) Date: Thu, 23 Jan 2014 14:43:21 +0000 Subject: [issue20297] concurrent.futures.as_completed() installs waiters for already completed Futures In-Reply-To: <1390079975.89.0.167689725202.issue20297@psf.upfronthosting.co.za> Message-ID: <1390488201.56.0.861899567845.issue20297@psf.upfronthosting.co.za> Changes by Glenn Langford : Added file: http://bugs.python.org/file33657/test_dupfuture.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:43:39 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 23 Jan 2014 14:43:39 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1390487598.23.0.747192030995.issue20218@psf.upfronthosting.co.za> Message-ID: <1390488216.2293.2.camel@fsol> Antoine Pitrou added the comment: > Which parts of the API merit discussion? The method names? Whether to > include readlines/writelines? The arguments? I think the readlines/writelines methods, as well as the size argument, should be dropped. Furthermore, there also should be distinct text/binary variants. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:43:56 2014 From: report at bugs.python.org (Steve) Date: Thu, 23 Jan 2014 14:43:56 +0000 Subject: [issue20359] Having escape sequences (like color codes) in the sys.ps1 messes up readline's input line calculations In-Reply-To: <1390468150.14.0.430221265473.issue20359@psf.upfronthosting.co.za> Message-ID: <1390488236.82.0.616068777711.issue20359@psf.upfronthosting.co.za> Steve added the comment: Hi Georg, Thanks again for the responses and your help. After a bit of research, I discovered the /reasons/ behind needing the \001 and \002 escapes. Thought I'd log the links here for posterity sake: - To color something in on a color capable terminal console you just need to use the "\033[m" escape sequence. This would be sufficient[1] - However readline messes up the line width calculation because it measures the escape sequences as a characters too. To avoid this you have to wrap the escape sequences within \001 and \002.[2] - On some terminal applications (like the one I am using - terminator[3]), if you add the \001 and \002 escapes to color text which is *not* interpreted by readline, (for instance if you have a single function to color text and you want to use it to color both your sys.ps1 and output text), the \001 and \002 codes will get printed out using a representation (like a unicode 'box'[4]). So, one would have to workaround that in the text coloring function. [1] http://en.wikipedia.org/wiki/ANSI_escape_code#Colors [2] bugs.python.org/issue17337/ and http://stackoverflow.com/questions/9468435/look-how-to-fix-column-calculation-in-python-readline-if-use-color-prompt [3] http://gnometerminator.blogspot.sg/p/introduction.html [4] http://en.wikipedia.org/wiki/Control_character#Display ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:46:58 2014 From: report at bugs.python.org (Ram Rachum) Date: Thu, 23 Jan 2014 14:46:58 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390488418.14.0.219843228615.issue20218@psf.upfronthosting.co.za> Ram Rachum added the comment: I see. I don't have an opinion about these 3 issues (readlines/writelines, size and binary separation.) So I'm cool with making these changes. If we do separate out the binary versions, what do you have in mind for the method names and signatures? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:52:14 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 23 Jan 2014 14:52:14 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> Message-ID: <1390488734.6.0.150347962051.issue20341@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The only place where "nullable" appears in the doc tree is... clinic.rst (in reference to places where a C pointer can be NULL, which *is* a reasonable use of the term). There's another problem in the patch: if you define "nullable_int_t" and "nullable_Py_ssize_t" in a public header (longobject.h), then you probably need to prefix them with "_Py" (so: "_Py_nullable_int_t" and "_Py_nullable_ssize_t", for example). Same for the #define's. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 15:55:51 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 23 Jan 2014 14:55:51 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1390488418.14.0.219843228615.issue20218@psf.upfronthosting.co.za> Message-ID: <1390488948.2293.4.camel@fsol> Antoine Pitrou added the comment: > If we do separate out the binary versions, what do you have in mind > for the method names and signatures? Perhaps we should look at what other Path APIs do here, and how they name it. Realistically, we need at least read_bytes() and read_text() methods. The write() method may stay unique if it's polymorphic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 16:00:48 2014 From: report at bugs.python.org (Glenn Langford) Date: Thu, 23 Jan 2014 15:00:48 +0000 Subject: [issue20367] concurrent.futures.as_completed() fails when given duplicate Futures Message-ID: <1390489248.24.0.751917808957.issue20367@psf.upfronthosting.co.za> New submission from Glenn Langford: concurrent.futures.as_completed([f,f]) will yield f twice, then fail with a KeyError for a Future f which is not completed. If the Future has already completed, as_completed([f,f]) will yield f once and does not trigger an exception. What is the correct behaviour? as_completed( [f,f] ) -> yield f twice ? wait( [f,f], return_when=ALL_COMPLETED ) -> yield f twice ? ---------- components: Library (Lib) files: test_dupfuture.py messages: 208952 nosy: glangford priority: normal severity: normal status: open title: concurrent.futures.as_completed() fails when given duplicate Futures type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33658/test_dupfuture.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 16:01:43 2014 From: report at bugs.python.org (Glenn Langford) Date: Thu, 23 Jan 2014 15:01:43 +0000 Subject: [issue20367] concurrent.futures.as_completed() fails when given duplicate Futures In-Reply-To: <1390489248.24.0.751917808957.issue20367@psf.upfronthosting.co.za> Message-ID: <1390489303.34.0.269314645805.issue20367@psf.upfronthosting.co.za> Changes by Glenn Langford : ---------- nosy: +haypo, mark.dickinson, tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 16:10:26 2014 From: report at bugs.python.org (Chris Angelico) Date: Thu, 23 Jan 2014 15:10:26 +0000 Subject: [issue20364] Rename & explain sqlite3.Cursor.execute 'parameters' param In-Reply-To: <1390473779.26.0.463818219743.issue20364@psf.upfronthosting.co.za> Message-ID: <1390489826.63.0.894151097145.issue20364@psf.upfronthosting.co.za> Chris Angelico added the comment: Small quibble: The last sentence capitalizes a Python built-in, which is confusing ("Len(seq_dict) must match..."). Tweak of grammar to have it not at the beginning of the sentence: "Either way, len(seq_dict) must match...". ---------- nosy: +Rosuav _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 16:15:02 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Jan 2014 15:15:02 +0000 Subject: [issue20368] Tkinter: handle the null character Message-ID: <1390490102.86.0.0317755498486.issue20368@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Tcl/Tk uses modified UTF-8 encoding to represent strings as C strings (char*). Because C strings are NUL-terminated, the null character represented as illegal UTF-8 sequence \xc0\x80. Current Tkinter code is not very aware about this. It has special handling the "\xc0\x80" string (i.e. encoded single null character) in one place, but doesn't handle encoded null character contained in larger string. As result Tkinter may truncate strings contained the null character, or return wrong result. The proposed patch fixes many issues with the null character (converting from Tcl to Python strings). NUL is still forbidden in string arguments of many methods. Also the patch enhances error handling for variable-related commands. ---------- components: Extension Modules, Tkinter files: tkinter_null_character.patch keywords: patch messages: 208954 nosy: gpolo, kbk, loewis, roger.serwy, serhiy.storchaka, terry.reedy priority: normal severity: normal stage: patch review status: open title: Tkinter: handle the null character type: behavior versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33659/tkinter_null_character.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 16:15:13 2014 From: report at bugs.python.org (Zachary Ware) Date: Thu, 23 Jan 2014 15:15:13 +0000 Subject: [issue20358] test_curses is failing In-Reply-To: <1390467619.0.0.459315516203.issue20358@psf.upfronthosting.co.za> Message-ID: <1390490113.98.0.813270754794.issue20358@psf.upfronthosting.co.za> Zachary Ware added the comment: I'm on Windows until this evening; I'll see what I can see when I'm on a machine that can actually build _curses. I don't see any failures on any of the buildbots, so I'm not sure how likely it is I'll be able to reproduce your failure. (And btw, that patch I have against test_curses is just a mechanical conversion to unittest, the only curses I'm an expert at are ones directed at problems...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 16:15:43 2014 From: report at bugs.python.org (Glenn Langford) Date: Thu, 23 Jan 2014 15:15:43 +0000 Subject: [issue20367] concurrent.futures.as_completed() fails when given duplicate Futures In-Reply-To: <1390489248.24.0.751917808957.issue20367@psf.upfronthosting.co.za> Message-ID: <1390490143.8.0.306027327566.issue20367@psf.upfronthosting.co.za> Glenn Langford added the comment: There is a subtlety in the as_completed() code which explains a lot - note that "finished" starts off as a set in the _AcquireFutures block. So if a Future f has already completed, as_completed( [f,f] ) will only yield f once, because f appears once in the finished set. Later on when waiter events are processed, "finished" turns into a list because of the line: finished = waiter.finished_futures So any duplicates in that list will cause problems in pending.remove(Future). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 16:22:40 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 23 Jan 2014 15:22:40 +0000 Subject: [issue20367] concurrent.futures.as_completed() fails when given duplicate Futures In-Reply-To: <1390489248.24.0.751917808957.issue20367@psf.upfronthosting.co.za> Message-ID: <1390490560.93.0.615545941758.issue20367@psf.upfronthosting.co.za> STINNER Victor added the comment: Since the new asyncio module has also a Future class and functions like as_completed(), this issue concerns also asyncio. concurrent.futures and asyncio should have the same behaviour. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 16:23:32 2014 From: report at bugs.python.org (Stefan Krah) Date: Thu, 23 Jan 2014 15:23:32 +0000 Subject: [issue19334] test_asyncio hanging for 1 hour (non-AIX version) In-Reply-To: <1382366717.5.0.644107908192.issue19334@psf.upfronthosting.co.za> Message-ID: <1390490612.0.0.970277863415.issue19334@psf.upfronthosting.co.za> Stefan Krah added the comment: OK, I have not seen the original issue in any recent builds either. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 16:25:11 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 23 Jan 2014 15:25:11 +0000 Subject: [issue18695] os.statvfs() not working well with unicode paths In-Reply-To: <1376050003.6.0.904056390722.issue18695@psf.upfronthosting.co.za> Message-ID: <1390490711.27.0.535874365201.issue18695@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Either way it's fine with me. Regardless I think these tests have some value because all those os functions are not currently tested so it might makes sense to apply Serhiy's suggestions and port them to Python 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 16:33:51 2014 From: report at bugs.python.org (Glenn Langford) Date: Thu, 23 Jan 2014 15:33:51 +0000 Subject: [issue20369] concurrent.futures.wait() blocks forever when given duplicate Futures Message-ID: <1390491231.67.0.503348563079.issue20369@psf.upfronthosting.co.za> New submission from Glenn Langford: For a Future f which has already completed, wait( [f,f], return_when=ALL_COMPLETED ) blocks forever. This is because the test in wait(): if len(done) == len(fs) is comparing the length of a set to the length of a list. If f has not completed, wait( [f,f] ) will yield f once. The behaviour should be consistent with as_completed() - see issue #20367. ---------- files: test_dupfuture_wait.py messages: 208960 nosy: glangford, haypo, mark.dickinson, tim.peters priority: normal severity: normal status: open title: concurrent.futures.wait() blocks forever when given duplicate Futures versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33660/test_dupfuture_wait.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 16:47:38 2014 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 23 Jan 2014 15:47:38 +0000 Subject: [issue20367] concurrent.futures.as_completed() fails when given duplicate Futures In-Reply-To: <1390489248.24.0.751917808957.issue20367@psf.upfronthosting.co.za> Message-ID: <1390492058.14.0.607884476759.issue20367@psf.upfronthosting.co.za> Guido van Rossum added the comment: I think you the caller was wrong to pass in [f, f] in the first place. In asyncio, the argument is converted into a set before using it, but there's still a bug if you pass it a list containing two references to the same coroutine -- it gets wrapped in two separate Futures. I think the better behavior is to convert to a set first and then map coroutines to Futures. So concurrent.futures should also convert to a set first. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 16:55:03 2014 From: report at bugs.python.org (July) Date: Thu, 23 Jan 2014 15:55:03 +0000 Subject: [issue20370] Docs error in Library reference-17.1.3 threading.Lock.acquire() Message-ID: <1390492503.52.0.179791157222.issue20370@psf.upfronthosting.co.za> New submission from July: In docs of Library reference-17.1.3 : threading.Lock.acquire(blocking=True,timeout=-1): line3 said: If a call with blocking set to True would block, return False immediately Here I suspect the blocking argument ought to be False as described subsequently. If it's set to True,it would block but return False immediately. P.S. first try of a non-native English speaker,do not care if any syntax error was made up there,please ---------- assignee: docs at python components: Documentation messages: 208962 nosy: docs at python, yonoho priority: normal severity: normal status: open title: Docs error in Library reference-17.1.3 threading.Lock.acquire() type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 16:57:24 2014 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 23 Jan 2014 15:57:24 +0000 Subject: [issue20345] Better logging defaults In-Reply-To: <1390400720.32.0.906733284392.issue20345@psf.upfronthosting.co.za> Message-ID: <1390492644.66.0.860665477754.issue20345@psf.upfronthosting.co.za> Vinay Sajip added the comment: > Specifying the format is what requires mental investment (because for that I need to read up on the config options). Not sure what you mean by config options. Is it too much to remember the format= parameter in your first post? I'm not planning to change the default because of already stated backward compatibility concerns, as it's easy enough to specify what you want, and it's not as if this type of request has come from lots of people over the years that logging has been in use (basicConfig has been there in its present form since Python 2.4). ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 17:00:04 2014 From: report at bugs.python.org (July) Date: Thu, 23 Jan 2014 16:00:04 +0000 Subject: [issue20370] Docs error in Library reference-17.1.3 threading.Lock.acquire() In-Reply-To: <1390492503.52.0.179791157222.issue20370@psf.upfronthosting.co.za> Message-ID: <1390492804.57.0.647796071342.issue20370@psf.upfronthosting.co.za> July added the comment: a sad story of a non-native English speaker,I just realized that it's me misunderstanding the sentence. well, close it. ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 17:16:43 2014 From: report at bugs.python.org (Zachary Ware) Date: Thu, 23 Jan 2014 16:16:43 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1390493803.97.0.675751409131.issue20172@psf.upfronthosting.co.za> Changes by Zachary Ware : Added file: http://bugs.python.org/file33661/8eb334d4f4a2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 17:24:39 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 23 Jan 2014 16:24:39 +0000 Subject: [issue20365] test_asyncio.test_read_pty_output() fails on "AMD64 Snow Leop 3.x" buildbot In-Reply-To: <1390487599.93.0.989391561311.issue20365@psf.upfronthosting.co.za> Message-ID: <1390494279.43.0.818954741673.issue20365@psf.upfronthosting.co.za> STINNER Victor added the comment: The issue was discussed here: https://groups.google.com/d/msg/python-tulip/I8oJ65Ww2Zw/tVL2ppXiU54J The decision is to skip the test on Mac OS X < 10.9. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 17:29:21 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 23 Jan 2014 16:29:21 +0000 Subject: [issue20365] test_asyncio.test_read_pty_output() fails on "AMD64 Snow Leop 3.x" buildbot In-Reply-To: <1390487599.93.0.989391561311.issue20365@psf.upfronthosting.co.za> Message-ID: <3f98804J3Mz7Lly@mail.python.org> Roundup Robot added the comment: New changeset 424564cffad0 by Victor Stinner in branch 'default': Close #20365: Skip test_asyncio.test_events.test_read_pty_output() on Mac OS X http://hg.python.org/cpython/rev/424564cffad0 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 17:41:02 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Jan 2014 16:41:02 +0000 Subject: [issue19920] TarFile.list() fails on some files In-Reply-To: <1386437860.38.0.0478693655005.issue19920@psf.upfronthosting.co.za> Message-ID: <1390495262.42.0.786688744323.issue19920@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I have added new portion of nitpicks on Rietveld. For you questions: 1. Yes, we can add unencodable tarinfo.linkname later. Just add tests for external tar files. 2. Use support.captured_stdout() (see test_list_command_verbose). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 17:45:32 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 23 Jan 2014 16:45:32 +0000 Subject: [issue20356] fix formatting of positional-only parameters in inspect.Signature In-Reply-To: <1390431126.48.0.863526301324.issue20356@psf.upfronthosting.co.za> Message-ID: <1390495532.72.0.119595857301.issue20356@psf.upfronthosting.co.za> Yury Selivanov added the comment: I'd like to commit this one later today, so please take a look at the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 17:46:39 2014 From: report at bugs.python.org (Zachary Ware) Date: Thu, 23 Jan 2014 16:46:39 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1390495599.33.0.262175430553.issue20172@psf.upfronthosting.co.za> Zachary Ware added the comment: Ok, here's a new patch. This one fixes the issues I found in my last patch (HKEY return converter in winreg, mess from previous return converter attempts in msvcrt), and switches all four modules to a two-pass output scheme. This should be basically what I want to commit, once 20189 is committed. If you'd like a non-two-pass patch for review, let me know. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 18:25:04 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 23 Jan 2014 17:25:04 +0000 Subject: [issue20366] SQLite FTS (full text search) In-Reply-To: <1390487950.26.0.724740577433.issue20366@psf.upfronthosting.co.za> Message-ID: <1390497904.28.0.859909894617.issue20366@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +loewis, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 18:25:34 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 23 Jan 2014 17:25:34 +0000 Subject: [issue20366] SQLite FTS (full text search) In-Reply-To: <1390487950.26.0.724740577433.issue20366@psf.upfronthosting.co.za> Message-ID: <1390497934.46.0.224438462352.issue20366@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- components: +Build, Windows -Extension Modules _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 18:36:53 2014 From: report at bugs.python.org (Tal Einat) Date: Thu, 23 Jan 2014 17:36:53 +0000 Subject: [issue20283] Wrong keyword parameter name in regex pattern methods In-Reply-To: <1389905067.44.0.489524795145.issue20283@psf.upfronthosting.co.za> Message-ID: <1390498613.36.0.287458577372.issue20283@psf.upfronthosting.co.za> Changes by Tal Einat : ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 18:37:39 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Thu, 23 Jan 2014 17:37:39 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1390498659.41.0.391130818681.issue6839@psf.upfronthosting.co.za> Changes by Adam Polkosnik : Removed file: http://bugs.python.org/file32160/zipfile.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 18:59:11 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Thu, 23 Jan 2014 17:59:11 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1390499951.8.0.741239910213.issue6839@psf.upfronthosting.co.za> Adam Polkosnik added the comment: I'm in a similar situation, my test file raises this: File name in directory "windows\TEMP\\test123.txt" and header "C:\windows\TEMP\\test123.txt" differ. It turns out that I can't find any cross platform procedures for processing the paths between the different platforms. And there are other things like doing it in portable way; os.path.split() nor os.path.basename() won't touch windows paths on un*x, etc... So, I'd like to propose an easy way, just allow the process to extract the files (and print a warning message) rather that just raising an exception (raise BadZipfile,...) and stopping the extraction altogether. ---------- versions: +Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file33662/zipfile_stupid.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 19:07:46 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 23 Jan 2014 18:07:46 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1390500466.05.0.770871336234.issue17481@psf.upfronthosting.co.za> Yury Selivanov added the comment: Larry, Nick, So what's the resolution on this one? Do I have a green light? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 19:11:12 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 23 Jan 2014 18:11:12 +0000 Subject: [issue20223] inspect.signature does not support new functools.partialmethod In-Reply-To: <1389475379.56.0.443397984378.issue20223@psf.upfronthosting.co.za> Message-ID: <1390500672.1.0.00997552229173.issue20223@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Reviewing the patch now. Nick, can I push this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 19:13:25 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Jan 2014 18:13:25 +0000 Subject: [issue20293] pydoc fails with the "unspecified" default value In-Reply-To: <1390045398.5.0.236293557583.issue20293@psf.upfronthosting.co.za> Message-ID: <1390500805.78.0.527421066378.issue20293@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 19:13:52 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Jan 2014 18:13:52 +0000 Subject: [issue20075] help(open) eats first line In-Reply-To: <1388090120.87.0.478863756961.issue20075@psf.upfronthosting.co.za> Message-ID: <1390500832.56.0.422714298097.issue20075@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 19:18:33 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 23 Jan 2014 18:18:33 +0000 Subject: [issue20326] Argument Clinic should use a non-error-prone syntax to mark text signatures In-Reply-To: <1390298749.1.0.12762219489.issue20326@psf.upfronthosting.co.za> Message-ID: <1390501113.12.0.435828671501.issue20326@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 19:20:51 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Thu, 23 Jan 2014 18:20:51 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1390501251.72.0.906268759865.issue6839@psf.upfronthosting.co.za> Adam Polkosnik added the comment: This one has the parentheses for print, so that it works in python 3.x. Also, the default fallback behavior in this case is to use the filename from the zips' directory (the first path in the warning). ---------- Added file: http://bugs.python.org/file33663/zipfile_stupid2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 19:26:14 2014 From: report at bugs.python.org (Glenn Langford) Date: Thu, 23 Jan 2014 18:26:14 +0000 Subject: [issue20297] concurrent.futures.as_completed() installs waiters for already completed Futures In-Reply-To: <1390079975.89.0.167689725202.issue20297@psf.upfronthosting.co.za> Message-ID: <1390501574.92.0.253419196403.issue20297@psf.upfronthosting.co.za> Glenn Langford added the comment: > - you replaced the _AcquireFutures context manager on all futures with an >individual lock. In my opinion, it should be changed in a different patch. I >don't know which option is better, but if it is changed, it should be changed >in the whole file. I can pursue the replacement of _AcquireFutures in a different patch, however I don't necessarily agree that it should be changed in the whole file. as_completed() is different than wait(), since wait() is obligated to return done and notdone Futures, which might require a different implementation. Initially, it may be better to only change as_completed(), where there is a clear concurrency win. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 19:34:28 2014 From: report at bugs.python.org (Ronald Oussoren) Date: Thu, 23 Jan 2014 18:34:28 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1390502068.81.0.433260931394.issue6839@psf.upfronthosting.co.za> Ronald Oussoren added the comment: As I wrote in msg116385 I'd prefer to drop the consistency check completely because updating data like the filename in the central directory is a cheap way to rename files without completely rewriting the zip file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 19:42:03 2014 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Thu, 23 Jan 2014 18:42:03 +0000 Subject: [issue20363] BytesWarnings triggerred by test suite In-Reply-To: <1390470451.71.0.00122717133798.issue20363@psf.upfronthosting.co.za> Message-ID: <1390502523.18.0.335063851295.issue20363@psf.upfronthosting.co.za> Changes by ?ukasz Langa : ---------- assignee: -> lukasz.langa stage: -> needs patch type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 19:42:47 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 23 Jan 2014 18:42:47 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390486007.57.0.823072031506.issue20311@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: ====================================================================== > FAIL: test_timeout_rounding (test.test_epoll.TestEPoll) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_epoll.py", line 59, in test_timeout_rounding > self.assertGreaterEqual(dt, timeout) > AssertionError: 0.009316698648035526 not greater than or equal to 0.01 Those failures are "expected", nothing guarantees that the syscall will take at least the amount of time specified. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 19:54:15 2014 From: report at bugs.python.org (Brian Quinlan) Date: Thu, 23 Jan 2014 18:54:15 +0000 Subject: [issue20319] concurrent.futures.wait() can block forever even if Futures have completed In-Reply-To: <1390263519.32.0.357208079457.issue20319@psf.upfronthosting.co.za> Message-ID: <1390503255.47.0.712919574127.issue20319@psf.upfronthosting.co.za> Brian Quinlan added the comment: I'm not currently working on concurrent.futures but I do look at patches and bug reports. I'll take a look at this and Issue20297 sometime this week. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 19:56:19 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 23 Jan 2014 18:56:19 +0000 Subject: [issue20065] Python-3.3.3/Modules/socketmodule.c:1660:14: error: 'CAN_RAW' undeclared (first use in this function) In-Reply-To: <1388619474.08.0.191162946311.issue20065@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: Sorry for the delay, I had completely forgotten this issue. Igor, could you try the patch attached? ---------- keywords: +patch Added file: http://bugs.python.org/file33664/af_can_define.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r b3c2472c12a1 Modules/socketmodule.c --- a/Modules/socketmodule.c Wed Jan 22 22:24:46 2014 +1000 +++ b/Modules/socketmodule.c Thu Jan 23 19:53:23 2014 +0100 @@ -1226,7 +1226,7 @@ } #endif -#ifdef AF_CAN +#ifdef HAVE_LINUX_CAN_H case AF_CAN: { struct sockaddr_can *a = (struct sockaddr_can *)addr; @@ -1654,7 +1654,7 @@ } #endif -#ifdef AF_CAN +#ifdef HAVE_LINUX_CAN_H case AF_CAN: switch (s->sock_proto) { case CAN_RAW: @@ -1859,7 +1859,7 @@ } #endif -#ifdef AF_CAN +#ifdef HAVE_LINUX_CAN_H case AF_CAN: { *len_ret = sizeof (struct sockaddr_can); From report at bugs.python.org Thu Jan 23 20:20:56 2014 From: report at bugs.python.org (Glenn Langford) Date: Thu, 23 Jan 2014 19:20:56 +0000 Subject: [issue20369] concurrent.futures.wait() blocks forever when given duplicate Futures In-Reply-To: <1390491231.67.0.503348563079.issue20369@psf.upfronthosting.co.za> Message-ID: <1390504856.79.0.698981484221.issue20369@psf.upfronthosting.co.za> Glenn Langford added the comment: Proposed patch...please treat with an appropriate level of suspicion since this is my first patch submission. :-) A corresponding change will be made to as_completed() for #20367. Suggestions welcome. ---------- keywords: +patch Added file: http://bugs.python.org/file33665/issue20369.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 20:40:09 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 23 Jan 2014 19:40:09 +0000 Subject: [issue17373] Add inspect.Signature.from_callable() In-Reply-To: <1362642709.69.0.481380147826.issue17373@psf.upfronthosting.co.za> Message-ID: <1390506009.36.0.962948650369.issue17373@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 20:47:24 2014 From: report at bugs.python.org (Andrew Lutomirski) Date: Thu, 23 Jan 2014 19:47:24 +0000 Subject: [issue20371] datetime.datetime.replace bypasses a subclass's __new__ Message-ID: <1390506444.15.0.286575412745.issue20371@psf.upfronthosting.co.za> New submission from Andrew Lutomirski: I'll admit that what I'm doing is possibly unhealthy. Nonetheless, I find this behavior *extremely* surprising. This code: --- start code --- import datetime class my_dt(datetime.datetime): def __new__(cls, *args, **kwargs): print('In my_dt.__new__') return datetime.datetime.__new__(cls, *args, **kwargs) def __init__(self, *args, **kwargs): print('In my_dt.__init__') super(my_dt, self).__init__() dt = datetime.datetime.now() print('Create a my_dt') t = my_dt(dt.year, dt.month, dt.day, dt.hour, dt.minute, dt.second, dt.microsecond, dt.tzinfo) print('Calling replace') t2 = t.replace(tzinfo=None) print('Got a %r' % type(t2)) --- end code --- results in: Create a my_dt In my_dt.__new__ In my_dt.__init__ Calling replace Got a So datetime.datetime.replace will create an object of type my_dt *without calling __new__ or __init__*. This should (AFAIK) be impossible. I think that datetime.datetime.replace should either return an actual datetime object or that it should invoke __new__ and probably __init__. ---------- components: Library (Lib) messages: 208980 nosy: Andrew.Lutomirski priority: normal severity: normal status: open title: datetime.datetime.replace bypasses a subclass's __new__ versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 20:52:22 2014 From: report at bugs.python.org (Brecht Van Lommel) Date: Thu, 23 Jan 2014 19:52:22 +0000 Subject: [issue20221] #define hypot _hypot conflicts with existing definition In-Reply-To: <1389409768.81.0.962130999427.issue20221@psf.upfronthosting.co.za> Message-ID: <1390506742.81.0.586522270914.issue20221@psf.upfronthosting.co.za> Brecht Van Lommel added the comment: We have a similar issue in Blender (where Python is embedded), but it's actually causing a crash instead of only a compiler warning: https://developer.blender.org/T38256 The code in the Visual Studio 2013 math.h looks like this: __inline double __CRTDECL hypot(_In_ double _X, _In_ double _Y) { return _hypot(_X, _Y); } With the #define hypot _hypot that becomes: __inline double __CRTDECL _hypot(_In_ double _X, _In_ double _Y) { return _hypot(_X, _Y); } So you get infinite recursive calls when using hypot and the application crashes. The patch fix20221.patch that was attach here solves the issue. ---------- nosy: +Brecht.Van.Lommel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 20:54:50 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Jan 2014 19:54:50 +0000 Subject: [issue20221] #define hypot _hypot conflicts with existing definition In-Reply-To: <1389409768.81.0.962130999427.issue20221@psf.upfronthosting.co.za> Message-ID: <1390506889.99.0.26799275972.issue20221@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 20:58:12 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Jan 2014 19:58:12 +0000 Subject: [issue20204] pydocs fails for some C implemented classes In-Reply-To: <1389271655.86.0.224685657695.issue20204@psf.upfronthosting.co.za> Message-ID: <1390507092.18.0.829581361071.issue20204@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 21:04:03 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 23 Jan 2014 20:04:03 +0000 Subject: [issue20371] datetime.datetime.replace bypasses a subclass's __new__ In-Reply-To: <1390506444.15.0.286575412745.issue20371@psf.upfronthosting.co.za> Message-ID: <1390507443.15.0.989332608556.issue20371@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +belopolsky, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 21:04:33 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Thu, 23 Jan 2014 20:04:33 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1390507473.25.0.747275819406.issue6839@psf.upfronthosting.co.za> Adam Polkosnik added the comment: Can we get this simple "fix" implemented in time for the next 2.7.x release?! Thank you! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 21:09:18 2014 From: report at bugs.python.org (Georg Brandl) Date: Thu, 23 Jan 2014 20:09:18 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1390507758.4.0.04769100147.issue6839@psf.upfronthosting.co.za> Georg Brandl added the comment: print() is not a good way to emit the warning; please use the warnings module. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 21:10:19 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 23 Jan 2014 20:10:19 +0000 Subject: [issue20371] datetime.datetime.replace bypasses a subclass's __new__ In-Reply-To: <1390506444.15.0.286575412745.issue20371@psf.upfronthosting.co.za> Message-ID: <1390507819.46.0.426667413047.issue20371@psf.upfronthosting.co.za> Yury Selivanov added the comment: I've just quickly looked the issue: 1. There is an inconsistency between python & c implementations: datetime.replace always returns "datetime(...)" object, but should return "self.__class__()" 2. "new_datetime_ex" in c implementation does not call constructors ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 21:12:46 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Jan 2014 20:12:46 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1390502068.81.0.433260931394.issue6839@psf.upfronthosting.co.za> Message-ID: <2967378.NpWXRFC1I9@raxxla> Serhiy Storchaka added the comment: > As I wrote in msg116385 I'd prefer to drop the consistency check completely > because updating data like the filename in the central directory is a cheap > way to rename files without completely rewriting the zip file. It should at least left as debugging print. It can't be a warning, because it depends not on user's actions, but on external data. But user still should be able to investigate uncommon zipfiles by setting the debug attribute. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 21:12:59 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 23 Jan 2014 20:12:59 +0000 Subject: [issue20371] datetime.datetime.replace bypasses a subclass's __new__ In-Reply-To: <1390506444.15.0.286575412745.issue20371@psf.upfronthosting.co.za> Message-ID: <1390507979.17.0.316863491817.issue20371@psf.upfronthosting.co.za> R. David Murray added the comment: It is actually not surprising if you are familiar with the copy/pickle protocol. Presumably that should be mentioned in the replace docs, though (assuming I'm right and that is why the behavior occurs). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 21:22:51 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Thu, 23 Jan 2014 20:22:51 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1390508571.18.0.452814118312.issue6839@psf.upfronthosting.co.za> Adam Polkosnik added the comment: Excellent, please see my third attempt. ---------- Added file: http://bugs.python.org/file33666/zipfile_stupid3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 21:23:23 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Thu, 23 Jan 2014 20:23:23 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1390508603.08.0.269694137621.issue6839@psf.upfronthosting.co.za> Changes by Adam Polkosnik : Removed file: http://bugs.python.org/file33663/zipfile_stupid2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 21:23:28 2014 From: report at bugs.python.org (Adam Polkosnik) Date: Thu, 23 Jan 2014 20:23:28 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1390508608.23.0.778297915581.issue6839@psf.upfronthosting.co.za> Changes by Adam Polkosnik : Removed file: http://bugs.python.org/file33662/zipfile_stupid.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 21:26:09 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 23 Jan 2014 20:26:09 +0000 Subject: [issue20372] inspect.getfile should raise a TypeError if C object does not have __module__ Message-ID: <1390508769.95.0.155655534379.issue20372@psf.upfronthosting.co.za> New submission from Yury Selivanov: I'm not sure if it is right to fix the inspect module, instead of making all C objects to have the '__module__' attribute (is it even possible?), but if it is, the patch is attached. ---------- files: getfile_patch_01.patch keywords: patch messages: 208988 nosy: ncoghlan, serhiy.storchaka, yselivanov priority: high severity: normal status: open title: inspect.getfile should raise a TypeError if C object does not have __module__ Added file: http://bugs.python.org/file33667/getfile_patch_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 21:26:51 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 23 Jan 2014 20:26:51 +0000 Subject: [issue20204] pydocs fails for some C implemented classes In-Reply-To: <1389271655.86.0.224685657695.issue20204@psf.upfronthosting.co.za> Message-ID: <1390508811.57.0.678067735871.issue20204@psf.upfronthosting.co.za> Yury Selivanov added the comment: See issue #20372 -- fix for the 'inspect.getfile' function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 21:36:08 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 23 Jan 2014 20:36:08 +0000 Subject: [issue20363] BytesWarnings triggerred by test suite In-Reply-To: <1390470451.71.0.00122717133798.issue20363@psf.upfronthosting.co.za> Message-ID: <1390509368.62.0.251702330245.issue20363@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: I think that repr could be used: str(bytes_instance) -> repr(bytes_instance) "%s" % bytes_instance -> "%r" % bytes_instance Any opinions? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 21:37:24 2014 From: report at bugs.python.org (Christopher Welborn) Date: Thu, 23 Jan 2014 20:37:24 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390509444.93.0.679704875938.issue20218@psf.upfronthosting.co.za> Christopher Welborn added the comment: Django: https://docs.djangoproject.com/en/dev/ref/files/file/#django.core.files.File It looks like Django has a File object that wraps around Python's built-in file object. It offers a 'mode' attribute, and a read(num_bytes=None) / write([content]) function. It also offers __iter__ functionality. You must open the file, and then wrap it with File() like: myfile = File(open('myfile.txt', 'r')) Twisted: http://twistedmatrix.com/documents/current/api/twisted.python.filepath.FilePath.html Looking at twisted.python.filepath.FilePath, it looks like there is no read/write. These are two very popular frameworks/libraries, but I'll see if I can't find other sources for inspiration. I think read_bytes/read_text would offer a good alternative method for reading files, instead of trying to create a full-on replacement like the previous patches attempt to do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 21:42:38 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 23 Jan 2014 20:42:38 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1390509444.93.0.679704875938.issue20218@psf.upfronthosting.co.za> Message-ID: <1390509755.2293.10.camel@fsol> Antoine Pitrou added the comment: > Twisted: > http://twistedmatrix.com/documents/current/api/twisted.python.filepath.FilePath.html > > Looking at twisted.python.filepath.FilePath, it looks like there is no > read/write. You overlooked the getContent and setContent methods. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 21:58:55 2014 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Thu, 23 Jan 2014 20:58:55 +0000 Subject: [issue20363] BytesWarnings triggerred by test suite In-Reply-To: <1390470451.71.0.00122717133798.issue20363@psf.upfronthosting.co.za> Message-ID: <1390510735.55.0.705097340711.issue20363@psf.upfronthosting.co.za> ?ukasz Langa added the comment: `repr(bytestr)[1:-1]` ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 22:00:03 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 23 Jan 2014 21:00:03 +0000 Subject: [issue16382] Better warnings exception for bad category In-Reply-To: <1351779406.35.0.0813926106632.issue16382@psf.upfronthosting.co.za> Message-ID: <1390510803.51.0.155371798507.issue16382@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 22:05:46 2014 From: report at bugs.python.org (Zachary Ware) Date: Thu, 23 Jan 2014 21:05:46 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1390511146.46.0.606616982768.issue20189@psf.upfronthosting.co.za> Zachary Ware added the comment: Ok, I found the source of the real issue alluded to in the misguided comment about the 'cls' -> 'type' change that I left on Rietveld. I was under the impression that with that change, 'help(datetime.datetime.now)' would show a signature of 'now(type, tz=None)'. In actual fact, 'str(inspect.signature(datetime.datetime.now))' (correctly) returns (tz=None), and that's what help (incorrectly) displays. To properly match the help output of Python-implemented methods, pydoc will need to add in the 'self' or 'cls' parameter somehow. However, I think that situation can be resolved in another issue in favor of getting this in, with the few issues I pointed out on Rietveld fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 22:11:40 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 23 Jan 2014 21:11:40 +0000 Subject: [issue20363] BytesWarnings triggerred by test suite In-Reply-To: <1390470451.71.0.00122717133798.issue20363@psf.upfronthosting.co.za> Message-ID: <1390511500.1.0.622143355364.issue20363@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: You rather meant [2:-1] instead of [1:-1], but if initial "b'" and final "'" are not needed in result string, then maybe just call .decode() on an instance of bytes. >>> str(b"xxx") "b'xxx'" >>> repr(b"xxx") "b'xxx'" >>> repr(b"xxx")[1:-1] "'xxx" >>> repr(b"xxx")[2:-1] 'xxx' >>> b"xxx".decode() 'xxx' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 22:16:42 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Jan 2014 21:16:42 +0000 Subject: [issue17671] io.BufferedRWPair can use uninitialized members In-Reply-To: <1365465332.23.0.700317324795.issue17671@psf.upfronthosting.co.za> Message-ID: <1390511802.27.0.634832451078.issue17671@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Python implementation raises AttributeError, C implementations of other streams raise ValueError on uninitialized read/write. Therefore I think ValueError is more appropriate for BufferedRWPair too. Revised patch changes exception type and message to conform with other streams, updates test for uninitialized BufferedRWPair and adds tests for other streams. ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file33668/bufferedio_uninitialized.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 22:28:28 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Jan 2014 21:28:28 +0000 Subject: [issue20363] BytesWarnings triggerred by test suite In-Reply-To: <1390470451.71.0.00122717133798.issue20363@psf.upfronthosting.co.za> Message-ID: <1390512508.01.0.300378697373.issue20363@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > I think that repr could be used: Agree. "{}".format(bytestr) -> "{!r}".format(bytestr) ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 22:28:58 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 23 Jan 2014 21:28:58 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> Message-ID: <1390512538.36.0.583005066241.issue20341@psf.upfronthosting.co.za> Larry Hastings added the comment: How many existing occurrences of "or_none" did you find in the CPython tree? Perhaps we can turn our attention to other languages like SQL and C# and borrow their term for "value that is allowed to be of a specific type (or types) as well as the null value". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 22:32:49 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Jan 2014 21:32:49 +0000 Subject: [issue1243730] Big speedup in email message parsing Message-ID: <1390512769.8.0.394742632826.issue1243730@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 22:33:18 2014 From: report at bugs.python.org (Christopher Welborn) Date: Thu, 23 Jan 2014 21:33:18 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390512798.7.0.597197950615.issue20218@psf.upfronthosting.co.za> Christopher Welborn added the comment: Oops, I did. Thanks for that. So setContent overwrites the file like open('myfile', 'w').write() would, except it has an option to give the temporary file a different extension (in case of a crash while writing). That's understandable for Twisted. getContent returns a file-like object, which is more like Path's open(). One thing I am not seeing is a readlines/writelines in these two libaries. I still think they would be useful, even without the size argument for readlines. So this is what I am seeing now: read_text(encoding=None) readlines_text(encoding=None) ..(or read_textlines?) read_bytes() readlines_bytes() write(data, append=False) ..(mode is decided based on data type) writelines(lines, append=False) ..determining the mode for writelines looks at the first item's type? The regular writelines fails with 'must be str, not [insert wrong type]' when opened with 'w', and '[insert wrong type] does not support the buffer interface' when opened with 'wb'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 22:37:24 2014 From: report at bugs.python.org (Nadeem Vawda) Date: Thu, 23 Jan 2014 21:37:24 +0000 Subject: [issue20358] test_curses is failing In-Reply-To: <1390467619.0.0.459315516203.issue20358@psf.upfronthosting.co.za> Message-ID: <1390513044.25.0.412817521727.issue20358@psf.upfronthosting.co.za> Nadeem Vawda added the comment: I can reproduce this (also on Ubuntu 13.10 64-bit). Maybe there's a bug in the version of curses distributed with the latest Ubuntu release? It looks like our only Ubuntu buildbot is using 8.04 (almost 6 years old!). Also note that you won't be able to reproduce this with "make test" or "make testall" (see issue 12669). "make buildbottest" does catch the bug, though (which also rules out the possibility that the buildbots are just skipping the test). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 22:39:53 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 23 Jan 2014 21:39:53 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <1390513193.08.0.534894544523.issue20311@psf.upfronthosting.co.za> STINNER Victor added the comment: > Those failures are "expected", nothing guarantees that the syscall > will take at least the amount of time specified. Ah? The manual page of epoll_wait() says: "The timeout argument specifies the minimum number of milliseconds that epoll_wait() will block. (This interval will be rounded up to the system clock granularity, and kernel scheduling delays mean that the blocking interval may overrun by a small amount.)" I read minimum, not maximum here :-) If epoll_wait(timeout_ms) may wait less than timeout_ms seconds, asyncio algorithm is wrong, or at least inefficient. It should loop until the time delta is at least total_timeout seconds. See the original issue: http://code.google.com/p/tulip/issues/detail?id=106 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 22:43:09 2014 From: report at bugs.python.org (Christopher Welborn) Date: Thu, 23 Jan 2014 21:43:09 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390513389.1.0.560754400665.issue20218@psf.upfronthosting.co.za> Christopher Welborn added the comment: I should clarify that last sentence, I was trying to say that the type is determined by the first item. If the user tries to mix bytes/text they will receive the proper error from io's writelines when the mismatched type is written. If the first item is neither str nor bytes, then raise a ValueError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 22:47:19 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Jan 2014 21:47:19 +0000 Subject: [issue20204] pydocs fails for some C implemented classes In-Reply-To: <1389271655.86.0.224685657695.issue20204@psf.upfronthosting.co.za> Message-ID: <1390513639.1.0.449692492314.issue20204@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: With issue #20372 patch pydoc no longer raise an exception, but it also doesn't produce useful output. In 3.3 it prints more details. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 22:58:12 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 23 Jan 2014 21:58:12 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390512538.36.0.583005066241.issue20341@psf.upfronthosting.co.za> Message-ID: <1390514289.2293.19.camel@fsol> Antoine Pitrou added the comment: > How many existing occurrences of "or_none" did you find in the CPython > tree? If I split that into the individual words "or" and "None", quite a lot. Looking for "or None" turns quite a bunch of matches too. "or_none" simply applies the PEP 8 convention for variable names made of multiple words. Of course, you can propose another name that involves "none", too. > Perhaps we can turn our attention to other languages like SQL and C# > and borrow their term for "value that is allowed to be of a specific > type (or types) as well as the null value". It is quite well-known and obvious that Python was inspired by C# and SQL, so why not indeed? Perhaps you should start by asking Guido if he wants to rename None to "NULL". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 23:00:21 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 23 Jan 2014 22:00:21 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390513193.08.0.534894544523.issue20311@psf.upfronthosting.co.za> Message-ID: <1390514419.2293.20.camel@fsol> Antoine Pitrou added the comment: > "The timeout argument specifies the minimum number of milliseconds > that epoll_wait() will block. (This interval will be rounded up to > the system clock granularity, and kernel scheduling delays mean that > the blocking interval may overrun by a small amount.)" > > I read minimum, not maximum here :-) Aren't you using different clocks, though? The excerpt above says "system clock" (which admittedly sounds a bit vague :-)). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 23:01:41 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Jan 2014 22:01:41 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390513193.08.0.534894544523.issue20311@psf.upfronthosting.co.za> Message-ID: <10302650.ExZj802hcT@raxxla> Serhiy Storchaka added the comment: Isn't any blocked syscall with a timeout can be interrupted by a signal? epoll_wait() can return EINTR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 23:16:24 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 23 Jan 2014 22:16:24 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1390515384.68.0.723546110491.issue20189@psf.upfronthosting.co.za> Larry Hastings added the comment: I'm happy to resolve it before checking in the patch. A small delta like that doesn't need a full-on review. If people said "eww" then I'll back it out. Nobody said "eww" to the "PyModuleDef *module" change (see below), and I'm not here to pick a fight. But let's talk about it a little! -- First, the name *is* visible in Python, if you examine the unbound version. >>> str(inspect.signature(_datetime.datetime.__dict__['now'])) `(, tz=None)` >>> help(_datetime.datetime.__dict__['now']) # ... shows help, including parameter in the signature The angle-brackets are Signature's way of denoting a positional-only parameter, which it is. That parameter isn't addressable by name. (The ugly angle brackets are being addressed in another issue.) -- Second, I'm surprised at the behavior of help. I hadn't realized that it showed you bound parameters for callables you passed in. >>> class C: ... @classmethod ... def wife(cls, a, b): ... print(cls, a, b) ... >>> help(C.wife) That shows "cls" as part of the signature. But inspect.signature does not: >>> str(inspect.signature(C.wife)) '(a, b)' FWIW help on a callable bound using functools.partial shows you help on the functools.partial class, so no guidance there. (help() only goes one level deep on this by the way. If you have a types.MethodType which binds another types.MethodType, help only peeks in the first one. But now I'm just showing off.) Anyway, I think it's odd, but I'm not here to change the behavior of help. I'll work on fixing help so it shows the already-bound parameters. -- Third, it's inconvenient to use "type" as an identifier in Python code, because "type" is a Python builtin. And it's impossible to use "class" because it's a keyword. So people use "cls" or "klass" according to personal taste. We don't have these restrictions in C. So actually "class" would work--except C++ uses "class" as a keyword. Let's not go there. But "type" works fine. -- Fourth, I already called the first parameter "type" for __new__ calls, as that seemed to be the convention there. It was just class methods where I called it "cls". But... __new__ *is* a class method. This is an artificial distinction. At the very least, I want Argument Clinic to use one name consistently. If everyone would prefer "cls" I don't care all that much. But I think "type" is a better name. (For one, it's not misspelled.) -- Fifth, up until Argument Clinic, most callables had "PyObject *self" as their first parameter. But module-level callables never actually get a "self", there's no "self" to call them with. They actually take the module object. Everybody called the first parameter "self" because they copied-and-pasted it from other code, and everyone ignores that parameter anyway. I proposed generating "PyModuleDef *module" there instead, Guido said "good idea!" I see this as similar, though the degree of error is not as large. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 23:21:08 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 23 Jan 2014 22:21:08 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390513193.08.0.534894544523.issue20311@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Ah? The manual page of epoll_wait() says: > > "The timeout argument specifies the minimum number of milliseconds that epoll_wait() will block. (This interval will be rounded up to the system clock granularity, and kernel scheduling delays mean that the blocking interval may overrun by a small amount.)" > > I read minimum, not maximum here :-) Yes, but we're talking about a 1e-4 accuracy here: I really doubt all hardware supports high-resolution timers. epoll() returning 1e-4s before the passed delay doesn't surprise me. > If epoll_wait(timeout_ms) may wait less than timeout_ms seconds, asyncio algorithm is wrong, or at least inefficient. It should loop until the time delta is at least total_timeout seconds. See the original issue: > http://code.google.com/p/tulip/issues/detail?id=106 Not really: sure, an early wakeup can cause spurious loops, but this should be really rare: how often is the main event loop called with sub-millisecond timeouts? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 23:22:20 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 23 Jan 2014 22:22:20 +0000 Subject: [issue20363] BytesWarnings triggerred by test suite In-Reply-To: <1390470451.71.0.00122717133798.issue20363@psf.upfronthosting.co.za> Message-ID: <1390515740.22.0.383460312679.issue20363@psf.upfronthosting.co.za> Berker Peksag added the comment: Here's a patch to silence BytesWarnings. ---------- assignee: lukasz.langa -> keywords: +patch nosy: +berker.peksag stage: needs patch -> type: behavior -> Added file: http://bugs.python.org/file33669/issue20363.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 23:22:58 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 23 Jan 2014 22:22:58 +0000 Subject: [issue20363] BytesWarnings triggerred by test suite In-Reply-To: <1390470451.71.0.00122717133798.issue20363@psf.upfronthosting.co.za> Message-ID: <1390515778.44.0.451597491322.issue20363@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- assignee: -> lukasz.langa stage: -> patch review type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 23:26:10 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 23 Jan 2014 22:26:10 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> Message-ID: <1390515970.76.0.648974825401.issue20341@psf.upfronthosting.co.za> Larry Hastings added the comment: Drop. It. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 23:31:23 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 23 Jan 2014 22:31:23 +0000 Subject: [issue20363] BytesWarnings triggerred by test suite In-Reply-To: <1390470451.71.0.00122717133798.issue20363@psf.upfronthosting.co.za> Message-ID: <1390516283.87.0.327906025545.issue20363@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: I think that %s is better for 'dashes' variable (which is always str) in Lib/distutils/command/register.py: self.announce('%s%r%s' % (dashes, data, dashes)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 23:38:25 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 23 Jan 2014 22:38:25 +0000 Subject: [issue20223] inspect.signature does not support new functools.partialmethod In-Reply-To: <1389475379.56.0.443397984378.issue20223@psf.upfronthosting.co.za> Message-ID: <1390516705.71.0.904137155609.issue20223@psf.upfronthosting.co.za> Larry Hastings added the comment: I'm not sure why you're asking Nick. Is he the release manager for 3.4? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 23:40:12 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 23 Jan 2014 22:40:12 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390515970.76.0.648974825401.issue20341@psf.upfronthosting.co.za> Message-ID: <1390516808.2293.30.camel@fsol> Antoine Pitrou added the comment: > Drop. It. Seriously? Why exactly did you ask for comments if your only response is to be snarky and dismissive? This is not your toy project. It is perfectly legitimate for us to question API and naming decisions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 23 23:49:26 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 23 Jan 2014 22:49:26 +0000 Subject: [issue20223] inspect.signature does not support new functools.partialmethod In-Reply-To: <1389475379.56.0.443397984378.issue20223@psf.upfronthosting.co.za> Message-ID: <1390517366.71.0.267764768653.issue20223@psf.upfronthosting.co.za> Yury Selivanov added the comment: > I'm not sure why you're asking Nick. Is he the release manager for 3.4? I'm asking him because he wrote "Reviewing the patch now.", and I thought that he might have actually seen the patch already. I'm more than fine if anyone else reviews the patch, really. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 00:04:38 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 23 Jan 2014 23:04:38 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: Message-ID: STINNER Victor added the comment: Le 23 janv. 2014 23:21, e me. > > If epoll_wait(timeout_ms) may wait less than timeout_ms seconds, asyncio > algorithm is wrong, or at least inefficient. It should loop until the time > delta is at least total_timeout seconds. See the original issue: > > http://code.google.com/p/tulip/issues/detail?id=106 > > Not really: sure, an early wakeup can cause spurious loops, but this should > be really rare: how often is the main event loop called with > sub-millisecond timeouts? Did you read my Tulip? Maybe I didn't explain correctly. Usually, the shorter delay in an application is 10 ms. The problem is that because of the rounding issue (which should now be fixed), the event loop computed a delay smaller than 1 ms. And this delay was rounded to 0 ms by epoll.poll(). Then the deadline was still not reached, the loop was called again... The number of call depends on the performance of your cpu. The high load should be short, probably less than 5 ms, but it occured regulary and was 2totally inefficient. Now asyncio should no more call epoll_wait() in non blocking mode (timeout of 0 ms) if a task is scheduled. So the major inefficient bug is fixed. But it would be nice to ensure that asyncio doesn't loop if nothing happens whereas the deadline is known. For example, it may call again epoll_wait() if it took less than timeout seconds and returned no event, *and* the ready list is empty. For the selector unit test: why does it fail whereas test_epoll has the same test and test_epoll doesn't fail? I fixed the rounding issue in selectmodule.c, but later I made a different fix in selectors which should only be needed for unpatched selectmodule.c. I did that to keep Tulip and Python code identical (including selectors, as asked by Guido). Maybe my rounding formula in selectors.py is wrong? 1e-3 number isn't IEEE 754 friendly, it cannot be stored exactly in binary (in a C double of 64 bits). Maybe the code should be skipped depending on the python version? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 00:08:13 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 23 Jan 2014 23:08:13 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: Message-ID: <1390518490.2293.32.camel@fsol> Antoine Pitrou added the comment: > For example, it may call again epoll_wait() if it took less than timeout > seconds and returned no event, *and* the ready list is empty. Easy solution: add 1 ms. to the timeout before calling epoll_wait(). Perhaps we need the same kind of thing for select() and poll() too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 00:16:41 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 23 Jan 2014 23:16:41 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1390512798.7.0.597197950615.issue20218@psf.upfronthosting.co.za> Message-ID: <1390518995.2293.37.camel@fsol> Antoine Pitrou added the comment: > One thing I am not seeing is a readlines/writelines in these two > libaries. I still think they would be useful, even without the size > argument for readlines. readlines() and writelines() aren't used a lot in my experience. > So this is what I am seeing now: > read_text(encoding=None) > readlines_text(encoding=None) ..(or read_textlines?) > read_bytes() > readlines_bytes() > write(data, append=False) ..(mode is decided based on data type) > writelines(lines, append=False) > > ..determining the mode for writelines looks at the first item's type? I would suggest differently: - read_text(encoding, errors, newline) - read_bytes() - write_text(data, encoding, errors, newline) - write_bytes(data) Strictly speaking, write() could be polymorphic, but I think it's nice to have distinct methods 1) out of symmetry with read*() 2) to avoid silently accepting the wrong type. As a reference, https://github.com/mikeorr/Unipath (which is quite popular) has read_file() and write_file() methods. https://github.com/jaraco/path.py has bytes(), text(), write_bytes() and write_text(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 00:19:14 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 23 Jan 2014 23:19:14 +0000 Subject: [issue20355] -W command line options should have higher priority than PYTHONWARNINGS environmental variable In-Reply-To: <1390426906.93.0.692922610327.issue20355@psf.upfronthosting.co.za> Message-ID: <1390519154.48.0.817901927221.issue20355@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, 3.4 isn't supposed to receive behaviour changes anymore, unless Larry says it's ok. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 00:25:57 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 23 Jan 2014 23:25:57 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390518490.2293.32.camel@fsol> Message-ID: STINNER Victor added the comment: Le 24 janv. 2014 00:08, "Antoine Pitrou" a ?crit : > > For example, it may call again epoll_wait() if it took less than timeout > > seconds and returned no event, *and* the ready list is empty. > > Easy solution: add 1 ms. to the timeout before calling epoll_wait(). > Perhaps we need the same kind of thing for select() and poll() too. It doesn't fix the case when EpollSelector.select() got an InterruptedError. Adding 1 ms works around the (now fixed) timeout rounding issue but I prefered to round differently to not sleep longer than requested (try to respect deadline). About the "system clock", it's possibke than Linux uses a different clock for epoll_wait() than CLOCK_MONOTONIC, and than clocks have a different resolution. I didn't test the rounding issue on Windows where time.monotonic() has a resolution between... 1 and 16 ms! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 00:26:58 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 23 Jan 2014 23:26:58 +0000 Subject: [issue20364] Rename & explain sqlite3.Cursor.execute 'parameters' param In-Reply-To: <1390473779.26.0.463818219743.issue20364@psf.upfronthosting.co.za> Message-ID: <1390519618.77.0.20915598882.issue20364@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I do not know what the intention was for sequences and named placeholders. Thinking of named tuples made me think it ok. The code might have a hint. Is sqlite3 code maintained here or elsewhere? The current docstring is just 'Executes a SQL statement.', and help gives no signature. .executemany is similar. I suspect the whole module needs better docstrings. You are correct about dicts and extra key:value pairs. I tried a UserDict with an extra pair and when I got sqlite3.ProgrammingError: Incorrect number of bindings supplied. The current statement uses 2, and there are 3 supplied I had not yet realized that they were treated as sequences, not dicts. So replace "Len(seq_dict)" with "The length of sequences". This solves Chris's point also. ---------- nosy: +ghaering _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 00:27:14 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 23 Jan 2014 23:27:14 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: Message-ID: <1390519631.2293.38.camel@fsol> Antoine Pitrou added the comment: > It doesn't fix the case when EpollSelector.select() got an InterruptedError. That should be very rare. I don't see a problem with retrying on EINTR. > Adding 1 ms works around the (now fixed) timeout rounding issue but I > prefered to round differently to not sleep longer than requested (try to > respect deadline). What are you going to round exactly? The epoll timeout? The deadline? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 00:30:24 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 23 Jan 2014 23:30:24 +0000 Subject: [issue20355] -W command line options should have higher priority than PYTHONWARNINGS environmental variable In-Reply-To: <1390426906.93.0.692922610327.issue20355@psf.upfronthosting.co.za> Message-ID: <1390519824.55.0.0736397499148.issue20355@psf.upfronthosting.co.za> Antoine Pitrou added the comment: About the patch (note the code review tool hasn't accepted it, so I'm commenting here): - in the tests, I think comparing stderr as-is will fail under Windows, where the line separator is b"\r\n"; better call splitlines() first - in the tests, I think it would be better to use test.script_helper.assert_python_ok() (it will automate some stuff for you), even though other tests don't in that file - in main.c, you need to Py_DECREF warning_options when you are done with it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 00:52:27 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 23 Jan 2014 23:52:27 +0000 Subject: [issue6839] zipfile can't extract file In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za> Message-ID: <1390521147.4.0.318015165436.issue6839@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Adam this is not a security issue (2.6, 3.1, 3.2), nor a future issue that must wait for 3.5. ---------- versions: -Python 2.6, Python 3.1, Python 3.2, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 00:55:16 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 23 Jan 2014 23:55:16 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> Message-ID: <1390521316.84.0.225328534565.issue20341@psf.upfronthosting.co.za> Larry Hastings added the comment: I don't think it's fair to call my responses "snarky". On the other hand, your suggestion that I view Argument Clinic as "my toy project" is obviously meant as an insult. It is fair to call my responses "dismissive", because I find nothing compelling about your arguments. I would color your final sentence slightly. Yes, there are plenty of legitimate discussions about API semantics and nomenclature. But there are infinitely many pointless and time-wasting discussions. Therefore not every question about API and naming decisions is de facto legitimate. I don't mean to say that your bringing it up originally was unreasonable, that was entirely appropriate. But surely I've made it clear by now: I find no strength to your arguments, and I'm not changing the name based on them. At this point all you're accomplishing is making me angry. The name "nullable" has been in continuous in Argument Clinic since very early on. It has always been in the PEP, and was in the original prototype published Dec 3 2012. Nobody has said anything about it, until you, just now, on this issue. I suggest the reason nobody has said anything before is because the name is fine. A clarification over something you said previously: you suggested that the name would "confuse Python developers". Just to be crystal clear: the name is not exposed to Python *users*. Right now it's solely visible to CPython core developers. If at some point Argument Clinic is deemed a public tool, it would also be visible to people writing third-party extension modules. I am not proposing we use the term "nullable" in user-facing documentation or APIs. (I happen to think it would be fine for users too, but there's utterly no point in having that debate now.) For what it's worth, I like to think CPython core developers are not so easily confused as you suggest. Also: Python draws inspiration from lots of places. The syntax for decorators was borrowed from Java autodoc comments (and Java annotations, though I think it actually slightly predates those). I'm not aware of any existing Python precedent we can draw on, so drawing inspiration from C# and SQL strikes me as perfectly appropriate. On the other hand, I see no precedent bolstering your suggestion. You yourself told someone in IRC, when they were pestering me about some Argument Clinic bikeshedding, "let's leave Larry alone". I appreciated it at the time. I'd appreciate it if you'd follow that advice now too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 00:56:37 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 23 Jan 2014 23:56:37 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1390521397.89.0.616588724718.issue17481@psf.upfronthosting.co.za> Larry Hastings added the comment: My solution for pydoc was to call isroutine() instead of isfunction(), and yes handle it throwing an exception. (I just checked, and I wasn't catching TypeError, only ValueError. I'll fix that in my next patch for #20189.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 01:02:41 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 00:02:41 +0000 Subject: [issue20355] -W command line options should have higher priority than PYTHONWARNINGS environmental variable In-Reply-To: <1390426906.93.0.692922610327.issue20355@psf.upfronthosting.co.za> Message-ID: <1390521761.38.0.0587763398976.issue20355@psf.upfronthosting.co.za> Larry Hastings added the comment: Is this behavior causing problems? How bad is it? Can I get more opinions about this than just Arfrever and Antoine? Not that I don't trust their opinions, I just want to see a larger sample size. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 01:04:29 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 24 Jan 2014 00:04:29 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390521316.84.0.225328534565.issue20341@psf.upfronthosting.co.za> Message-ID: <1390521867.2293.40.camel@fsol> Antoine Pitrou added the comment: > I would color your final sentence slightly. Yes, there are plenty of > legitimate discussions about API semantics and nomenclature. But > there are infinitely many pointless and time-wasting discussions. > Therefore not every question about API and naming decisions is de > facto legitimate. This is a fair position, thanks. > At this point all you're accomplishing is making me angry. Argument Clinic discussions and activity seem to annoy me more than they bring me anything, so I'll avoid involving myself in it any further. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 01:04:50 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 24 Jan 2014 00:04:50 +0000 Subject: [issue20341] Argument Clinic: add "nullable ints" In-Reply-To: <1390360681.97.0.808723930218.issue20341@psf.upfronthosting.co.za> Message-ID: <1390521890.05.0.376683248808.issue20341@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: -pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 01:05:35 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 24 Jan 2014 00:05:35 +0000 Subject: [issue20355] -W command line options should have higher priority than PYTHONWARNINGS environmental variable In-Reply-To: <1390521761.38.0.0587763398976.issue20355@psf.upfronthosting.co.za> Message-ID: <1390521932.2293.41.camel@fsol> Antoine Pitrou added the comment: > Is this behavior causing problems? How bad is it? Not really. It's just a bit suboptimal and counter-intuitive (local settings should trump global settings). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 02:15:33 2014 From: report at bugs.python.org (Christopher Welborn) Date: Fri, 24 Jan 2014 01:15:33 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390526133.85.0.414172521235.issue20218@psf.upfronthosting.co.za> Christopher Welborn added the comment: Antoine said: > I would suggest differently: > - read_text(encoding, errors, newline) > - read_bytes() > - write_text(data, encoding, errors, newline) > - write_bytes(data) > > Strictly speaking, write() could be polymorphic, but I think it's nice > to have distinct methods 1) out of symmetry with read*() 2) to avoid > silently accepting the wrong type. I am starting to see where you are going with this, and I agree with your latest points. I dropped readlines/writelines. I guess pathlib doesn't have to do *exactly* everything you can do through normal io. They are easy to implement anyway with .split() and .join(). I realize this would not make it into Python for a while (3.5 possibly, if at all), but I went ahead and made a patch anyway because I have time to do so at the moment. I updated the tests to reflect the latest changes, and made sure all of them still pass. Any criticism/wisdom would be appreciated, as this is my first time dealing with the Python patch process. The api is what you have, except I put an 'append' option: read_bytes() read_text(encoding=None, errors=None, newline=None) write_bytes(data, append=False) write_text(data, encoding=None, errors=None, newline=None, append=False) ---------- Added file: http://bugs.python.org/file33670/pathlib.readwrite3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 03:49:19 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 24 Jan 2014 02:49:19 +0000 Subject: [issue20373] Use test.script_helper.assert_python_ok() instead of subprocess.* in test.test_warnings Message-ID: <1390531759.42.0.533556896595.issue20373@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis: These patches make test.test_warnings use test.script_helper.assert_python_ok() instead of subprocess.*, as suggested by Antoine in msg209022. ---------- assignee: pitrou components: Tests files: python-2.7-test_warnings.py_use_assert_python_ok.patch keywords: patch messages: 209030 nosy: Arfrever, pitrou priority: normal severity: normal stage: patch review status: open title: Use test.script_helper.assert_python_ok() instead of subprocess.* in test.test_warnings type: enhancement versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33671/python-2.7-test_warnings.py_use_assert_python_ok.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 03:50:36 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 24 Jan 2014 02:50:36 +0000 Subject: [issue20373] Use test.script_helper.assert_python_ok() instead of subprocess.* in test.test_warnings In-Reply-To: <1390531759.42.0.533556896595.issue20373@psf.upfronthosting.co.za> Message-ID: <1390531836.7.0.977776598923.issue20373@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : Added file: http://bugs.python.org/file33672/python-3.3-test_warnings.py_use_assert_python_ok.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 03:50:54 2014 From: report at bugs.python.org (Christopher Welborn) Date: Fri, 24 Jan 2014 02:50:54 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390531854.71.0.836801965167.issue20218@psf.upfronthosting.co.za> Changes by Christopher Welborn : Removed file: http://bugs.python.org/file33642/pathlib.readwrite.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 03:52:24 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 24 Jan 2014 02:52:24 +0000 Subject: [issue20355] -W command line options should have higher priority than PYTHONWARNINGS environmental variable In-Reply-To: <1390426906.93.0.692922610327.issue20355@psf.upfronthosting.co.za> Message-ID: <1390531944.11.0.57814870783.issue20355@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- dependencies: +Use test.script_helper.assert_python_ok() instead of subprocess.* in test.test_warnings _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 04:17:50 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 24 Jan 2014 03:17:50 +0000 Subject: [issue20355] -W command line options should have higher priority than PYTHONWARNINGS environmental variable In-Reply-To: <1390426906.93.0.692922610327.issue20355@psf.upfronthosting.co.za> Message-ID: <1390533470.01.0.382149691169.issue20355@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: The new patch includes changes suggested by Antoine. (This patch should be applied after patch from issue #20373.) ---------- Added file: http://bugs.python.org/file33673/python-warnings.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 04:19:05 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 24 Jan 2014 03:19:05 +0000 Subject: [issue20355] -W command line options should have higher priority than PYTHONWARNINGS environmental variable In-Reply-To: <1390426906.93.0.692922610327.issue20355@psf.upfronthosting.co.za> Message-ID: <1390533545.51.0.392859475732.issue20355@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : Removed file: http://bugs.python.org/file33645/python-warnings.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 04:56:18 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 03:56:18 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1390535778.41.0.852746525675.issue20189@psf.upfronthosting.co.za> Larry Hastings added the comment: A little more on consistency and inconsistency. I count 109 tp_new callback functions in CPython, and they overwhelmingly call the first parameter "PyTypeObject *type" (93 instances). In second place is "PyObject *self" (9 instances), which is flat-out wrong. I count 21 METH_CLASS callback functions in CPython; they prefer calling the first parameter "PyObject *cls" (16 instances). In second place is "PyTypeObject *type" (3 instances). Both callbacks are class methods. And both callbacks are passed the *exact same object* for their first parameter, the PyTypeObject * representing that type. I can see no good reason why they should have different names in different callbacks. There's no practical or semantic difference between the two. I suspect it's something silly like legacy code / copying and pasting / force of habit, perhaps carried over from the days before type/class unification. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 05:09:05 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Fri, 24 Jan 2014 04:09:05 +0000 Subject: [issue11448] docs for HTTPConnection.set_tunnel are ambiguous In-Reply-To: <1299636529.48.0.302129596868.issue11448@psf.upfronthosting.co.za> Message-ID: <1390536545.34.0.23710737216.issue11448@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Apologies, I missed that. I'll be more careful in the future. I've attached an updated patch that also adds some extra Sphinx markup, but should IMO still be credited to Ryan and Karl. ---------- Added file: http://bugs.python.org/file33674/issue11448_r3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 05:18:42 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 24 Jan 2014 04:18:42 +0000 Subject: [issue20364] Rename & explain sqlite3.Cursor.execute 'parameters' param In-Reply-To: <1390473779.26.0.463818219743.issue20364@psf.upfronthosting.co.za> Message-ID: <1390537122.05.0.294140927275.issue20364@psf.upfronthosting.co.za> R. David Murray added the comment: I don't know anything about the current relationship between the external project and the stdlib version. In the (small) changes I've been part of, we have maintained what is in the stdlib without reference to the external project. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 05:26:50 2014 From: report at bugs.python.org (jhl) Date: Fri, 24 Jan 2014 04:26:50 +0000 Subject: [issue20374] Failure to compile with readline-6.3-rc1 Message-ID: <1390537610.1.0.747015129006.issue20374@psf.upfronthosting.co.za> New submission from jhl: Python 2.7.6 does not compile with readline 6.3 (rc1). It looks like the RL_FUNCTION_TYPEDEF support in Modules/readline.c is not quite complete. The following patch works for me, both for 2.7.6 and 3.3.3. --- a/Modules/readline.c 2013-11-10 18:36:41.000000000 +1100 +++ b/Modules/readline.c 2014-01-24 15:11:04.182417214 +1100 @@ -911,12 +911,27 @@ rl_bind_key_in_map ('\t', rl_complete, emacs_meta_keymap); rl_bind_key_in_map ('\033', rl_complete, emacs_meta_keymap); /* Set our hook functions */ - rl_startup_hook = (Function *)on_startup_hook; + rl_startup_hook = +#if defined(_RL_FUNCTION_TYPEDEF) + (rl_hook_func_t *)on_startup_hook; +#else + (Function *)on_startup_hook; +#endif #ifdef HAVE_RL_PRE_INPUT_HOOK - rl_pre_input_hook = (Function *)on_pre_input_hook; + rl_pre_input_hook = +#if defined(_RL_FUNCTION_TYPEDEF) + (rl_hook_func_t *)on_pre_input_hook; +#else + (Function *)on_pre_input_hook; +#endif #endif /* Set our completion function */ - rl_attempted_completion_function = (CPPFunction *)flex_complete; + rl_attempted_completion_function = +#if defined(_RL_FUNCTION_TYPEDEF) + (rl_completion_func_t *)flex_complete; +#else + (CPPFunction *)flex_complete; +#endif /* Set Python word break characters */ completer_word_break_characters = rl_completer_word_break_characters = ---------- components: Extension Modules messages: 209035 nosy: jhl priority: normal severity: normal status: open title: Failure to compile with readline-6.3-rc1 versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 05:27:04 2014 From: report at bugs.python.org (jhl) Date: Fri, 24 Jan 2014 04:27:04 +0000 Subject: [issue20374] Failure to compile with readline-6.3-rc1 In-Reply-To: <1390537610.1.0.747015129006.issue20374@psf.upfronthosting.co.za> Message-ID: <1390537624.39.0.76637316576.issue20374@psf.upfronthosting.co.za> Changes by jhl : ---------- type: -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 05:27:22 2014 From: report at bugs.python.org (jhl) Date: Fri, 24 Jan 2014 04:27:22 +0000 Subject: [issue20374] Failure to compile with readline-6.3-rc1 In-Reply-To: <1390537610.1.0.747015129006.issue20374@psf.upfronthosting.co.za> Message-ID: <1390537642.25.0.864318567643.issue20374@psf.upfronthosting.co.za> Changes by jhl : ---------- versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 05:35:07 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 24 Jan 2014 04:35:07 +0000 Subject: [issue20374] Failure to compile with readline-6.3-rc1 In-Reply-To: <1390537610.1.0.747015129006.issue20374@psf.upfronthosting.co.za> Message-ID: <1390538107.79.0.9171015419.issue20374@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever, benjamin.peterson, georg.brandl, larry priority: normal -> release blocker versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 05:53:36 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Fri, 24 Jan 2014 04:53:36 +0000 Subject: [issue20375] ElementTree: Document handling processing instructions Message-ID: <1390539216.23.0.0362813865609.issue20375@psf.upfronthosting.co.za> New submission from Nikolaus Rath: (This issue was branched of from #9521). When parsing XML, etree currently skips over all processing instructions and comments. However, both can be represented in the tree and are also written out when generating XML. The attached patch documents this (IMO surprising) behavior. ---------- assignee: docs at python components: Documentation files: xml.etree_r1.patch keywords: patch messages: 209036 nosy: docs at python, eli.bendersky, eric.araujo, ezio.melotti, georg.brandl, nikolaus.rath, scoder priority: normal severity: normal status: open title: ElementTree: Document handling processing instructions type: enhancement versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33675/xml.etree_r1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 05:54:12 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Fri, 24 Jan 2014 04:54:12 +0000 Subject: [issue9521] xml.etree.ElementTree skips processing instructions when parsing In-Reply-To: <1281000343.34.0.102578281876.issue9521@psf.upfronthosting.co.za> Message-ID: <1390539252.96.0.347014311716.issue9521@psf.upfronthosting.co.za> Nikolaus Rath added the comment: I have created issue 20375 with a patch to document the current behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 06:23:00 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Fri, 24 Jan 2014 05:23:00 +0000 Subject: [issue17681] Work with an extra field of gzip and zip files In-Reply-To: <1365519781.38.0.309194725625.issue17681@psf.upfronthosting.co.za> Message-ID: <1390540980.29.0.113095090221.issue17681@psf.upfronthosting.co.za> Changes by Nikolaus Rath : ---------- nosy: +nikolaus.rath _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 06:33:39 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Jan 2014 05:33:39 +0000 Subject: [issue20374] Failure to compile with readline-6.3-rc1 In-Reply-To: <1390537610.1.0.747015129006.issue20374@psf.upfronthosting.co.za> Message-ID: <3f9TXx1Qyhz7LjQ@mail.python.org> Roundup Robot added the comment: New changeset 79b82ebc4fd1 by Benjamin Peterson in branch '2.7': use new readline function types (closes #20374) http://hg.python.org/cpython/rev/79b82ebc4fd1 New changeset fb2259d9f6b4 by Benjamin Peterson in branch '3.3': use new readline function types (closes #20374) http://hg.python.org/cpython/rev/fb2259d9f6b4 New changeset eb251e3624df by Benjamin Peterson in branch 'default': merge 3.3 (#20374) http://hg.python.org/cpython/rev/eb251e3624df ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 06:36:57 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 24 Jan 2014 05:36:57 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: Message-ID: Charles-Fran?ois Natali added the comment: > Did you read my Tulip? Maybe I didn't explain correctly. No, it was quite clear, and I think I understand the original issue: calling epoll_wait(0) when passed a timeout of 0.9ms was bad, because it led to busy-loop during 0.9ms. But here, that's another story: once in a blue moon, depending on the platform, epoll_wait(1ms) might return after e.g. 0.931ms as above. In this case, we'll just call epoll once more with another extra 1ms timeout: this doesn't yield excessive CPU usage, only a slight latency, but this extra latency is completely normal, since we have to round the delay somehow (e.g. if someone passes 0.001ms it will be rounded to 1ms). Someone needing high-resolution wakeups shouldn't rely on epoll/select timeouts, but use timerfd_create or something similar. Furthermore, in practice this shouldn't occur often: if someone passes a 1.001 ms timeout, we'll round it to 2ms, so we won't have the problem. If someone passes a 0.9ms timeout, it will be rounded to 1ms, so even if epoll wakes up a little before 1ms, let's say 0.931ms as in the above buildbot failure, it will still be greater than 0.9ms, so no problem either. So IMO it's not a problem, and even if it is, there's no reason to complicate the code. In your test, just restrict the rounding check for delays which are strictly less than the underlying syscall resolutuion, e.g. for epoll 1-6, 1-5, 1-4. That's enough to check the correct rounding. > Maybe my rounding formula in selectors.py is wrong? 1e-3 number isn't IEEE > 754 friendly, it cannot be stored exactly in binary (in a C double of 64 > bits). Regardless of IEEE754 representation, in the end, epoll_wait() is passed an integer (a C long). So it's either passed 0, 1 or 2. Given the 0.009316698648035526 value, the only integer that was possibly passed is 1 (ms), so I don't think rounding is the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 08:07:22 2014 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 24 Jan 2014 07:07:22 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: Message-ID: Guido van Rossum added the comment: I've lost some context, but perhaps we should have the notion of "granularity" of the poll/select timeout (e.g. 1 msec), and consider events that are in the future by less than that granularity as ready? Then we can round the timeout down: if someone passes a timeout of 1.1 msec, poll would wait for approximately 1 msec, and when it returns the event would be considered "due now" as long as the balance (about 0.1 msec) was under 1 msec. On Thu, Jan 23, 2014 at 9:36 PM, Charles-Fran?ois Natali wrote: > > Charles-Fran?ois Natali added the comment: > >> Did you read my Tulip? Maybe I didn't explain correctly. > > No, it was quite clear, and I think I understand the original issue: > calling epoll_wait(0) when passed a timeout of 0.9ms was bad, because it > led to busy-loop during 0.9ms. > > But here, that's another story: once in a blue moon, depending on the > platform, epoll_wait(1ms) might return after e.g. 0.931ms as above. > In this case, we'll just call epoll once more with another extra 1ms > timeout: this doesn't yield excessive CPU usage, only a slight latency, but > this extra latency is completely normal, since we have to round the delay > somehow (e.g. if someone passes 0.001ms it will be rounded to 1ms). > > Someone needing high-resolution wakeups shouldn't rely on epoll/select > timeouts, but use timerfd_create or something similar. > > Furthermore, in practice this shouldn't occur often: if someone passes a > 1.001 ms timeout, we'll round it to 2ms, so we won't have the problem. > If someone passes a 0.9ms timeout, it will be rounded to 1ms, so even if > epoll wakes up a little before 1ms, let's say 0.931ms as in the above > buildbot failure, it will still be greater than 0.9ms, so no problem either. > > So IMO it's not a problem, and even if it is, there's no reason to > complicate the code. > > In your test, just restrict the rounding check for delays which are > strictly less than the underlying syscall resolutuion, e.g. for epoll 1-6, > 1-5, 1-4. That's enough to check the correct rounding. > >> Maybe my rounding formula in selectors.py is wrong? 1e-3 number isn't IEEE >> 754 friendly, it cannot be stored exactly in binary (in a C double of 64 >> bits). > > Regardless of IEEE754 representation, in the end, epoll_wait() is passed an > integer (a C long). > So it's either passed 0, 1 or 2. Given the 0.009316698648035526 value, the > only integer that was possibly passed is 1 (ms), so I don't think rounding > is the issue. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 08:09:07 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 24 Jan 2014 07:09:07 +0000 Subject: [issue20338] Idle: increase max calltip width In-Reply-To: <1390344102.42.0.241411598779.issue20338@psf.upfronthosting.co.za> Message-ID: <1390547347.91.0.357419293453.issue20338@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I changed 5 to _MAX_LINES. Other than trivial duplication, I think each test example should be added for a reason, because there is something different about it that might conceivably cause a failure. For example, there should be a case with more than _MAX_LINES in the docstring. But I think one is enough to make sure we split with maxsplit. And I think one text wrap is enough. The many 't#' test functions were needed for 2.x because it has 12 lines of complicated code that were replaced here by 1. argspec = inspect.formatargspec(*inspect.getfullargspec(fob)) For 3.x, we would not need as many tests if the inspect methods were adequately tested and debugged. However, they were not fixed to handle keyword only args until 3.4 and they are still in flux. The attached patch will need adjustment for 2.7 (I believe) and 3.4 (because *,... is handled better). I plan to do so when fresher. ---------- stage: patch review -> commit review Added file: http://bugs.python.org/file33676/20338-3.3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 08:51:31 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Jan 2014 07:51:31 +0000 Subject: [issue20338] Idle: increase max calltip width In-Reply-To: <1390344102.42.0.241411598779.issue20338@psf.upfronthosting.co.za> Message-ID: <1390549891.58.0.67403050228.issue20338@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: textwrap.TextWrapper in 3.3 doesn't have '*' and following parameters. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 09:06:05 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Jan 2014 08:06:05 +0000 Subject: [issue20363] BytesWarnings triggerred by test suite In-Reply-To: <1390470451.71.0.00122717133798.issue20363@psf.upfronthosting.co.za> Message-ID: <1390550765.08.0.738889376409.issue20363@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And 'print(hash(eval(%s.decode("utf-8"))))' % repr_.encode("utf-8") can be simplified to 'print(hash(eval(%a)))' % repr_ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 09:21:59 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Jan 2014 08:21:59 +0000 Subject: [issue20376] Argument Clinic: backslashes in docstrings are not escaped Message-ID: <1390551719.55.0.676646267319.issue20376@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Argument Clinic copies backslashes in docstrings as is. This can produce wrong or even invalid C string. Either backslashes should be escaped, or current behavior should be documented. ---------- components: Demos and Tools messages: 209044 nosy: larry, serhiy.storchaka priority: normal severity: normal status: open title: Argument Clinic: backslashes in docstrings are not escaped type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 09:30:37 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Jan 2014 08:30:37 +0000 Subject: [issue20377] Argument Clinic: get rid of the "_impl" suffix Message-ID: <1390552237.96.0.0267615751895.issue20377@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: For now most hand-written functions which use Argument Clinic have the "_impl" suffix and generated wrapper functions without the "_impl" suffix are less interested and visible to developer (generated *_METHODDEF macros are used in method list). I propose to revert things and name implementation functions without the "_impl" suffix, but add the "_wrapper" (or "_method"?) suffix to generated wrapper functions. ---------- components: Demos and Tools messages: 209045 nosy: larry, serhiy.storchaka priority: normal severity: normal status: open title: Argument Clinic: get rid of the "_impl" suffix type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 09:43:50 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Fri, 24 Jan 2014 08:43:50 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1390553030.53.0.495442169021.issue20173@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the updated patch of codecsmodule, based on Larry's review. Thanks! I didn't realize clinic releases pybuffer implicitly. I also turned _codecs.Codecs to _codecs since all of these methods are module methods. ---------- Added file: http://bugs.python.org/file33677/clinic_codecsmodule_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 09:53:01 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 08:53:01 +0000 Subject: [issue20377] Argument Clinic: get rid of the "_impl" suffix In-Reply-To: <1390552237.96.0.0267615751895.issue20377@psf.upfronthosting.co.za> Message-ID: <1390553581.79.0.680554107024.issue20377@psf.upfronthosting.co.za> Larry Hastings added the comment: We had this discussion already, some months ago. The consensus was to leave it the way it is. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 09:53:28 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Fri, 24 Jan 2014 08:53:28 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1390553608.34.0.100214148119.issue20185@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Updated marshal patch. I just learned we don't need to release pybuffer (y*) manually. ---------- Added file: http://bugs.python.org/file33678/clinic_marshal_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 09:53:39 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 08:53:39 +0000 Subject: [issue20376] Argument Clinic: backslashes in docstrings are not escaped In-Reply-To: <1390551719.55.0.676646267319.issue20376@psf.upfronthosting.co.za> Message-ID: <1390553619.07.0.0156887110159.issue20376@psf.upfronthosting.co.za> Larry Hastings added the comment: Oops! They should be escaped. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 10:00:00 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 09:00:00 +0000 Subject: [issue20377] Argument Clinic: get rid of the "_impl" suffix In-Reply-To: <1390552237.96.0.0267615751895.issue20377@psf.upfronthosting.co.za> Message-ID: <1390554000.24.0.47165654658.issue20377@psf.upfronthosting.co.za> Larry Hastings added the comment: For the record, I was actually in favor of swapping them. You can try bringing it up again on python-dev if you like, but I'm not sure there's anything really new to say. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 10:14:27 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Fri, 24 Jan 2014 09:14:27 +0000 Subject: [issue19145] Inconsistent behaviour in itertools.repeat when using negative times In-Reply-To: <1380727396.47.0.412229295257.issue19145@psf.upfronthosting.co.za> Message-ID: <1390554867.96.0.337549690518.issue19145@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Serhiy said, "Why do you cast PyDict_Size(kwds) to int?" Sorry, Serhiy! Today I just realized there is your review for this ticket. I couldn't really remember but I think I got conversion warning if I did not downcast it. Something about I shouldn't not have operation involving ssize_t and int in one statement. Strangely when I tested it again, it did not complain. Perhaps I used different distro back then. Well, since Larry has a patch intersecting with this ticket, I guess we should let him does this work. Thanks, Serhiy! I tried to reply you in the rietveld but I got an error page. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 10:17:41 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 09:17:41 +0000 Subject: [issue19145] Inconsistent behaviour in itertools.repeat when using negative times In-Reply-To: <1380727396.47.0.412229295257.issue19145@psf.upfronthosting.co.za> Message-ID: <1390555061.83.0.605343695201.issue19145@psf.upfronthosting.co.za> Larry Hastings added the comment: I don't have a patch for this issue. If you're thinking of my "nullable ints" patch, that was just an experiment. I'd prefer we figure out what we're going to do on this issue, and we can talk abut conversion to Argument Clinic later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 10:19:52 2014 From: report at bugs.python.org (Ram Rachum) Date: Fri, 24 Jan 2014 09:19:52 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390555192.24.0.30055904708.issue20218@psf.upfronthosting.co.za> Ram Rachum added the comment: I like the patch. Except I'd like to have support for the 'x' flag in the `write_text` and `write_bytes` methods. I suggest an argument `exclusive`, which defaults to `False`. When `exclusive=True`, the mode will be 'x' or 'xb'. The first lines after each method definition should be: if append and exclusive: raise Exception("Can't use both `append` and `exclusive` modes together; `append` implies that the file exists, while `exclusive` implies it does not.") If you don't like long exception texts, you can shorten it to just the first sentence. Also, you may want to choose a different exception class than `Exception`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 10:32:43 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Fri, 24 Jan 2014 09:32:43 +0000 Subject: [issue18670] Using read_mime_types function from mimetypes module gives resource warning In-Reply-To: <1375803104.23.0.740839065527.issue18670@psf.upfronthosting.co.za> Message-ID: <1390555963.56.0.907587073256.issue18670@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the updated patch based on Ezio's review. Sorry, for a long time, I didn't notice you had reviewed my code, Ezio. Thanks for the review! ---------- Added file: http://bugs.python.org/file33679/fix_resource_warning_read_mime_types_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 10:40:59 2014 From: report at bugs.python.org (Ned Deily) Date: Fri, 24 Jan 2014 09:40:59 +0000 Subject: [issue20374] Failure to compile with readline-6.3-rc1 In-Reply-To: <1390537610.1.0.747015129006.issue20374@psf.upfronthosting.co.za> Message-ID: <1390556459.73.0.426437481702.issue20374@psf.upfronthosting.co.za> Ned Deily added the comment: The checked-in fixes break builds on OS X that use the Apple-supplied libedit readline compatibility layer. See, for example: http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/1077/steps/compile/logs/stdio gcc -fno-strict-aliasing -Werror=declaration-after-statement -g -O0 -Wall -Wstrict-prototypes -I./Include -I. -IInclude -I/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Include -I/Users/buildbot/buildarea/3.x.murray-snowleopard/build -c /Users/buildbot/buildarea/3.x.murray-snowleopard/build/Modules/readline.c -o build/temp.macosx-10.6-x86_64-3.4-pydebug/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Modules/readline.o /Users/buildbot/buildarea/3.x.murray-snowleopard/build/Modules/readline.c: In function ?setup_readline?: /Users/buildbot/buildarea/3.x.murray-snowleopard/build/Modules/readline.c:1001: error: ?rl_hook_func_t? undeclared (first use in this function) /Users/buildbot/buildarea/3.x.murray-snowleopard/build/Modules/readline.c:1001: error: (Each undeclared identifier is reported only once /Users/buildbot/buildarea/3.x.murray-snowleopard/build/Modules/readline.c:1001: error: for each function it appears in.) /Users/buildbot/buildarea/3.x.murray-snowleopard/build/Modules/readline.c:1001: error: expected expression before ?)? token /Users/buildbot/buildarea/3.x.murray-snowleopard/build/Modules/readline.c:1003: error: expected expression before ?)? token /Users/buildbot/buildarea/3.x.murray-snowleopard/build/Modules/readline.c:1006: error: ?rl_completion_func_t? undeclared (first use in this function) /Users/buildbot/buildarea/3.x.murray-snowleopard/build/Modules/readline.c:1006: error: expected expression before ?)? token ---------- assignee: -> benjamin.peterson nosy: +ned.deily resolution: fixed -> stage: committed/rejected -> needs patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 11:04:49 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 24 Jan 2014 10:04:49 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <1390557889.63.0.375947112319.issue20311@psf.upfronthosting.co.za> STINNER Victor added the comment: Guido van Rossum added the comment: > I've lost some context, but perhaps we should have the notion of > "granularity" of the poll/select timeout (e.g. 1 msec), and consider > events that are in the future by less than that granularity as ready? > Then we can round the timeout down: if someone passes a timeout of 1.1 > msec, poll would wait for approximately 1 msec, and when it returns > the event would be considered "due now" as long as the balance (about > 0.1 msec) was under 1 msec. Well, it sounds like a good compromise according to my experimentation in my last commits on epoll and selectors. New attached asyncio_granularity.patch: - Restore the previous rounding method for poll and epoll (in select and selectors modules), remove unit tests which were designed to test the rounding the timeout away from zero - Add a new resolution attribute to selectors.BaseSelector (select: 1e-6, poll and epoll: 1e-3, kqueue: 1e-9) - Add a new granularity attribute to asyncio.BaseEventLoop: maximum of time resolution and selector resolution - Add a unit test for asyncio counting the number of calls to _run_once(), independent of the selector and the platform - BaseEventLoop._run_once() rounds the deadline and current time using granularity I tested the patch on Linux, FreeBSD and Windows (select, selectors and asyncio tests pass). Granularity: - Linux. poll, epoll: 1 ms, select: 1 us (resolution of time.monotonic: 1 ns) - FreeBSD. poll: 1 ms, select: 1 us, kqueue: 11 ns (resolution of time.monotonic: 11 ns) - Windows (tested on my Windows 7 VM): select, proactor: 15.6 ms (resolution of time.monotonic(): 15.6 ms) BaseProactorEventLoop doesn't use the resolution of IocpProactor because I don't know the resolution :-) Anyway, time.monotonic() has a low resolution (15.6 ms) and so it should be fine. If the patch is accepted, my changes on Python 3.3 should also be reverted. ---------- Added file: http://bugs.python.org/file33680/asyncio_granularity.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 11:16:39 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Fri, 24 Jan 2014 10:16:39 +0000 Subject: [issue19145] Inconsistent behaviour in itertools.repeat when using negative times In-Reply-To: <1380727396.47.0.412229295257.issue19145@psf.upfronthosting.co.za> Message-ID: <1390558599.89.0.900666038054.issue19145@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the updated patch. I try to be conservative here, preserving the current behaviour. Negative times is same as zero. Default value (which can be passed by omitting times) means unlimited. I did not change the signature "repeat(object [,times])" because the only suitable default value, in my opinion, is "repeat(object [,times=])" which is impossible at the moment. Well, let see what Raymond has anything to say about this. ---------- Added file: http://bugs.python.org/file33681/fix_itertools_repeat_negative_number_means_0_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 11:21:51 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Fri, 24 Jan 2014 10:21:51 +0000 Subject: [issue19145] Inconsistent behaviour in itertools.repeat when using negative times In-Reply-To: <1380727396.47.0.412229295257.issue19145@psf.upfronthosting.co.za> Message-ID: <1390558911.51.0.851410351932.issue19145@psf.upfronthosting.co.za> Vajrasky Kok added the comment: def repeat(object, times=-1): => it could break the code in the wild. Current behaviour: repeat(object) -> unlimited, repeat(object, -1) -> 0 repetitions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 11:30:42 2014 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 Jan 2014 10:30:42 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1390535778.41.0.852746525675.issue20189@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: Note that tp_new is a static method, not a class method (the type creation machinery takes care of passing in the right class rather than the descriptor machinery) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 11:34:09 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 10:34:09 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1390559649.29.0.300272436162.issue20189@psf.upfronthosting.co.za> Larry Hastings added the comment: > Note that tp_new is a static method, not a class method (the type > creation machinery takes care of passing in the right class rather > than the descriptor machinery) I admit I didn't know that. But from a practical perspective, surely you agree that tp_new walks and quacks like a class method? That I, as an author of an extension type, should think of it as such? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 11:55:24 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Jan 2014 10:55:24 +0000 Subject: [issue20377] Argument Clinic: get rid of the "_impl" suffix In-Reply-To: <1390553581.79.0.680554107024.issue20377@psf.upfronthosting.co.za> Message-ID: <1430223.CJ6DLoQFPb@raxxla> Serhiy Storchaka added the comment: Could you please provide a link on this discussion? There were too many discussions and I had quickly lost them. Argument Clinic was changed too much for last weeks, so perhaps consensus is changed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 11:57:23 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 10:57:23 +0000 Subject: [issue20377] Argument Clinic: get rid of the "_impl" suffix In-Reply-To: <1390552237.96.0.0267615751895.issue20377@psf.upfronthosting.co.za> Message-ID: <1390561043.52.0.95509905261.issue20377@psf.upfronthosting.co.za> Larry Hastings added the comment: I'm sorry, but I simply don't have the time to spend to dig it up right now. It was a while ago and I'm not sure exactly where to look. I dimly recall it was last year, probably during September-December, and that both Nick and I were in it. It was probably in python-dev but it might have been on the tracker. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 11:59:48 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 10:59:48 +0000 Subject: [issue19145] Inconsistent behaviour in itertools.repeat when using negative times In-Reply-To: <1380727396.47.0.412229295257.issue19145@psf.upfronthosting.co.za> Message-ID: <1390561188.59.0.955200572614.issue19145@psf.upfronthosting.co.za> Larry Hastings added the comment: Your patch does not address my concern. My concern is that itertools.repeat doesn't parse its arguments like other Python functions. It behaves differently depending on whether "times" is passed by position or by keyword. Therefore its actual calling signature cannot be represented accurately with an inspect.Signature object. Let me state this precisely. Currently, inspect.signature doesn't produce a Signature object for itertools.repeat. But let's assume for the moment that it did, and that the default value for the "times" parameter was -1. Then, for this code: sig = inspect.signature(itertools.repeat) a = itertools.repeat('a') b = itertools.repeat('a', sig.parameters['times'].default) c = itertools.repeat('a', times=sig.parameters['times'].default) I'd expect the a, b, and c objects to behave identically and be interchangeable. Passing in the default value for an optional parameter should always produce the same result as not passing in a value for that parameter, and for positional-or-keyword parameters it shouldn't matter whether that's done by position or by keyword. However, b is different from a and c: a and c yields infinitely-many 'a's, whereas b never yields anything. I want to see a patch where, after applying the patch, a b and c would be interchangeable. Such a patch should be *simpler* than the existing code, as it would remove all the special-case code that examines the length of the args tuple. "Special cases aren't special enough to break the rules." I think itertools.repeat's argument parsing should stop breaking the rules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 12:10:44 2014 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 Jan 2014 11:10:44 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1390561844.33.0.405488784056.issue20189@psf.upfronthosting.co.za> Nick Coghlan added the comment: It doesn't act like a class method, though, it acts like a static method: >>> int.__new__() Traceback (most recent call last): File "", line 1, in TypeError: int.__new__(): not enough arguments >>> int.__new__(int) 0 You have to *write* __new__ and tp_new as if they were class methods (because the type machinery expects you to do so), but you have to *call* them like static methods if you're invoking them directly for some reason. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 12:12:35 2014 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 Jan 2014 11:12:35 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1390561955.33.0.560861299939.issue20189@psf.upfronthosting.co.za> Nick Coghlan added the comment: (Also, I can't give you a solid reason for *why* it's like that - Guido just wrote it that way, and the type machinery is hairy enough that I have no intentions of second guessing him on that one) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 12:13:13 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Jan 2014 11:13:13 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390561993.45.0.383200165383.issue20218@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: -serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 12:16:38 2014 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 Jan 2014 11:16:38 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1390562198.03.0.437108903454.issue20189@psf.upfronthosting.co.za> Nick Coghlan added the comment: Oh, yes, now I remember - it *has* to be that way, otherwise upcalls from subclass __new__ methods don't do the right thing (int.__new__(MyInt), etc), just as you need to pass the current type in explicitly for cooperative super calls. This is perhaps *the* most obscure design detail of the type system that I'm aware of - I have to go scratching around in my brain for the reason every time it comes up, which is fortunately almost never :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 12:30:27 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Jan 2014 11:30:27 +0000 Subject: [issue20374] Failure to compile with readline-6.3-rc1 In-Reply-To: <1390537610.1.0.747015129006.issue20374@psf.upfronthosting.co.za> Message-ID: <1390563027.03.0.414943701002.issue20374@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What if remove casts at all? Ned, is it compiled with libedit? ---------- keywords: +patch nosy: +serhiy.storchaka Added file: http://bugs.python.org/file33682/readline_func_cast.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 14:07:29 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Jan 2014 13:07:29 +0000 Subject: [issue20317] ExitStack hang if enough nested exceptions In-Reply-To: <1390248489.02.0.0980821300277.issue20317@psf.upfronthosting.co.za> Message-ID: <3f9gcb6YtKz7LjM@mail.python.org> Roundup Robot added the comment: New changeset b3eaeb4bdf84 by Nick Coghlan in branch '3.3': Issue 20317: Remove debugging code from contextlib http://hg.python.org/cpython/rev/b3eaeb4bdf84 New changeset a0bf53afedfa by Nick Coghlan in branch 'default': Merge removal of issue 20317 debugging code from 3.3 http://hg.python.org/cpython/rev/a0bf53afedfa ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 14:21:39 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 13:21:39 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1390569699.09.0.65967231142.issue20189@psf.upfronthosting.co.za> Larry Hastings added the comment: Okay, one more diff. I have high hopes for this, but then I had high hopes yesterday. Nick, could you review the PyTypeObject changes in this patch? Obviously I'd love a review of the whole thing, but if you can only make a little time, the crucial part is the "delta from patch set" 5 for typeobject.c. First thing: I must never have run the unit test suite before cutting the diff yesterday, because I did today and there were a bunch of problems. That's clowny and I apologize. But it's fixed now, and I assure you, there's no way I would have actually checked this in without running the test suite immediately before. Here's what changed today: Core: * Modified typeobject.c so that when creating an object, if it copies the type's "__doc__", it skips past the signature, because type objects are callable and have signatures now. * Default value for dict.fromkeys parameter is now None. (Previously it was NULL, which was simply wrong.) Lib and tests: * pydoc now catches both ValueError and TypeError when it tries inspect.signature. * Added a fix for unittest.mock courtesy of Michael Foord. It previously assumed that anything it could get an inspect.Signature for was written in Python. Now that that's no longer true, it broke some other code. Michael's pretty confident that's the right fix, and in any case it makes the tests pass again. * Bashed up some IDLE unit tests that depend on docstrings. These are accurate for now, but look wrong because of the __text_signature__ grabbing the first line when it shouldn't. When I get to put in the new signature syntax, these will break again and I'll put them back. * General unit test fixes, to live in this modern world. Tools: * Argument Clinic now makes sure that parser functions for __new__ are always of type newfunc, the type of the tp_new slot. Similarly, parser functions for __init__ are now always of type initproc, the type of tp_init. ---------- Added file: http://bugs.python.org/file33683/larry.support.text_signature.on.more.types.7.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 14:36:14 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 13:36:14 +0000 Subject: [issue20264] Update patchcheck to looks for files with clinic comments In-Reply-To: <1389755559.69.0.925028805372.issue20264@psf.upfronthosting.co.za> Message-ID: <1390570574.47.0.257916025866.issue20264@psf.upfronthosting.co.za> Larry Hastings added the comment: Maybe I'm not reading this correctly. It looks like the function returns True if it finds any .c or .h file that contains the string '[clinic input]'. It doesn't seem to only check files that have changed. I was considering adding a checkum for the *input* to the third comment (what I call the "output line"). That would let this checker compute the checksum for the input and output sections and confirm that they match. If the input had changed, the checksum would fail, and you'd know they hadn't run clinic recently. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 14:50:26 2014 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 Jan 2014 13:50:26 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1390571426.62.0.89189566021.issue20189@psf.upfronthosting.co.za> Nick Coghlan added the comment: Scanned the whole patch, especially the type changes. This looks like a solid approach to me. For 3.5, PEP 457 might want to consider proposing a tp_sig slot and splitting the signature out at type creation time rather than on attribute lookup. The current dynamic approach is fine for 3.4, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 14:54:13 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 13:54:13 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1390571653.84.0.838637196905.issue20189@psf.upfronthosting.co.za> Larry Hastings added the comment: Okay, I'm checking this beast in. Hooray! Thanks for your reviews, everybody! -- I thought it was still possible to introduce objects into Python at runtime without calling PyType_Ready on their type. If that's true, then there wouldn't necessarily *be* a type creation time at which we could do the signature splitting. Is that no longer allowed as of 3.4? Are all types required to be registered with PyType_Ready before objects of that type are introduced into the Python runtime? If so, hooplah! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 14:56:36 2014 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 Jan 2014 13:56:36 +0000 Subject: [issue20223] inspect.signature does not support new functools.partialmethod In-Reply-To: <1389475379.56.0.443397984378.issue20223@psf.upfronthosting.co.za> Message-ID: <1390571796.12.0.822702743478.issue20223@psf.upfronthosting.co.za> Nick Coghlan added the comment: Yury, I believe the review comments from Rietveld go to the address you have registered as primary in the tracker, so that's currently your address with the ".ml" suffix rather than your main one. My only suggestion was to use ._partialmethod for the attribute name, rather than __partialmethod__, since this feels a bit more like an ordinary private attribute, rather than a new protocol. Lots of introspection tools deliberately *display* dunder names, and that doesn't really feel appropriate here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 14:58:13 2014 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 Jan 2014 13:58:13 +0000 Subject: [issue20223] inspect.signature does not support new functools.partialmethod In-Reply-To: <1389475379.56.0.443397984378.issue20223@psf.upfronthosting.co.za> Message-ID: <1390571893.6.0.481932304743.issue20223@psf.upfronthosting.co.za> Nick Coghlan added the comment: As far as pushing goes, I'd wait until Larry lands issue 20189 - I suspect there's a risk of conflict between these patches in the inspect module, and that one is key to getting builtin signatures supported properly :) ---------- dependencies: +inspect.Signature doesn't recognize all builtin types _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 15:00:30 2014 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 Jan 2014 14:00:30 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1390572030.41.0.208993953632.issue20189@psf.upfronthosting.co.za> Nick Coghlan added the comment: There are probably still ways to do it, but we don't *support* doing it (and I'm pretty sure we've fixed them all in the builtins and stdlib). However, yes, that's another good reason to be conservative in only doing the split into signature+doc at attribute lookup time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 15:01:48 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 14:01:48 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1390572108.39.0.738129088198.issue20189@psf.upfronthosting.co.za> Larry Hastings added the comment: I just realized, I forgot to fix the bug Zach reported, where help(bound_thing) should still show the class or self parameter. I'm going to check this in anyway, and file a fresh bug on myself to address that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 15:03:29 2014 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 Jan 2014 14:03:29 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1390572209.03.0.525171162097.issue17481@psf.upfronthosting.co.za> Nick Coghlan added the comment: Another case of "don't land it until Larry has dealt with the builtins". The patch itself looks fine, though :) ---------- dependencies: +inspect.Signature doesn't recognize all builtin types _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 15:05:52 2014 From: report at bugs.python.org (Ram Rachum) Date: Fri, 24 Jan 2014 14:05:52 +0000 Subject: [issue20378] Implement `Signature.__repr__` Message-ID: <1390572352.73.0.323073863277.issue20378@psf.upfronthosting.co.za> Changes by Ram Rachum : ---------- components: Library (Lib) nosy: cool-RR priority: normal severity: normal status: open title: Implement `Signature.__repr__` versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 15:06:42 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 14:06:42 +0000 Subject: [issue20379] help(bound_builtin_class) does not display self Message-ID: <1390572402.09.0.311482588548.issue20379@psf.upfronthosting.co.za> New submission from Larry Hastings: For an object O that are bound to something (either a class or an instance), help(O) traditionally shows the bound argument. For this code: class C: def foo(self, a): pass c = C() help(c.foo) would show the signature as "(self, a)", even though self has been bound. My recent changes to Python's type system (#20189), to add inspect.Signature support for builtins, broke this. The previous behavior should be restored. ---------- assignee: larry messages: 209078 nosy: larry, zach.ware priority: deferred blocker severity: normal stage: needs patch status: open title: help(bound_builtin_class) does not display self type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 15:17:45 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Jan 2014 14:17:45 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <3f9j9h1yk1z7Ljt@mail.python.org> Roundup Robot added the comment: New changeset 85710aa396ef by Larry Hastings in branch 'default': Issue #20189: Four additional builtin types (PyTypeObject, http://hg.python.org/cpython/rev/85710aa396ef ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 15:18:26 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 14:18:26 +0000 Subject: [issue20189] inspect.Signature doesn't recognize all builtin types In-Reply-To: <1389185260.07.0.0528548763931.issue20189@psf.upfronthosting.co.za> Message-ID: <1390573106.08.0.956271154365.issue20189@psf.upfronthosting.co.za> Larry Hastings added the comment: Phew! Thanks again, everybody! ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 15:25:13 2014 From: report at bugs.python.org (Glenn Langford) Date: Fri, 24 Jan 2014 14:25:13 +0000 Subject: [issue20367] concurrent.futures.as_completed() fails when given duplicate Futures In-Reply-To: <1390489248.24.0.751917808957.issue20367@psf.upfronthosting.co.za> Message-ID: <1390573513.18.0.791049090442.issue20367@psf.upfronthosting.co.za> Glenn Langford added the comment: Proposed patch for as_completed(). #20369 fixes wait(), and behaviour is consistent between the two. ---------- keywords: +patch Added file: http://bugs.python.org/file33684/issue20367.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 15:25:39 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 14:25:39 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1390573539.29.0.461203072502.issue17481@psf.upfronthosting.co.za> Larry Hastings added the comment: The patch from #20189 has landed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 15:25:47 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 14:25:47 +0000 Subject: [issue20223] inspect.signature does not support new functools.partialmethod In-Reply-To: <1389475379.56.0.443397984378.issue20223@psf.upfronthosting.co.za> Message-ID: <1390573547.75.0.00599398910622.issue20223@psf.upfronthosting.co.za> Larry Hastings added the comment: The patch from #20189 has landed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 15:28:54 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 24 Jan 2014 14:28:54 +0000 Subject: [issue20367] concurrent.futures.as_completed() fails when given duplicate Futures In-Reply-To: <1390489248.24.0.751917808957.issue20367@psf.upfronthosting.co.za> Message-ID: <1390573734.3.0.250519296499.issue20367@psf.upfronthosting.co.za> STINNER Victor added the comment: > Proposed patch for as_completed(). Could you please try to write a unit test. The unit test should fail without the patch, and fail with the patch. Then create a new patch including the patch. If it's tricky to write a reliable test reproducing the race condition, you can use unittest.mock to mock some objects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 15:32:59 2014 From: report at bugs.python.org (Ram Rachum) Date: Fri, 24 Jan 2014 14:32:59 +0000 Subject: [issue20380] __defaults__ changed by *args Message-ID: <1390573979.83.0.371857256149.issue20380@psf.upfronthosting.co.za> New submission from Ram Rachum: Check the following example out. Putting *args in a function makes its __defaults__ be empty. Python 3.4.0b2 (v3.4.0b2:ba32913eb13e, Jan 5 2014, 16:13:26) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> def f(x, *args, y='meow'): pass ... >>> f.__defaults__ >>> def g(x, y='meow'): pass ... >>> g.__defaults__ ('meow',) > ---------- components: Interpreter Core messages: 209085 nosy: cool-RR priority: normal severity: normal status: open title: __defaults__ changed by *args type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 15:34:53 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 14:34:53 +0000 Subject: [issue20380] __defaults__ changed by *args In-Reply-To: <1390573979.83.0.371857256149.issue20380@psf.upfronthosting.co.za> Message-ID: <1390574093.05.0.960382756701.issue20380@psf.upfronthosting.co.za> Larry Hastings added the comment: That's because in f, y is after *args, so it is a keyword-only parameter. Its default value is in __kwdefaults__. If you move y to before *args, its default will be in __defaults__. This is working as designed. ---------- nosy: +larry resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 15:35:40 2014 From: report at bugs.python.org (Ram Rachum) Date: Fri, 24 Jan 2014 14:35:40 +0000 Subject: [issue20380] __defaults__ changed by *args In-Reply-To: <1390573979.83.0.371857256149.issue20380@psf.upfronthosting.co.za> Message-ID: <1390574140.54.0.797446389041.issue20380@psf.upfronthosting.co.za> Ram Rachum added the comment: My mistake. Thanks for the clarification. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 15:35:55 2014 From: report at bugs.python.org (Ram Rachum) Date: Fri, 24 Jan 2014 14:35:55 +0000 Subject: [issue20380] __defaults__ changed by *args In-Reply-To: <1390573979.83.0.371857256149.issue20380@psf.upfronthosting.co.za> Message-ID: <1390574155.33.0.371184359783.issue20380@psf.upfronthosting.co.za> Ram Rachum added the comment: Though perhaps a note in the documentation would be helpful for future confused people. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 15:51:45 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 24 Jan 2014 14:51:45 +0000 Subject: [issue20355] -W command line options should have higher priority than PYTHONWARNINGS environmental variable In-Reply-To: <1390426906.93.0.692922610327.issue20355@psf.upfronthosting.co.za> Message-ID: <1390575105.97.0.195463627609.issue20355@psf.upfronthosting.co.za> Brett Cannon added the comment: I agree with Antoine; this can wait for Python 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 16:03:27 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 15:03:27 +0000 Subject: [issue20355] -W command line options should have higher priority than PYTHONWARNINGS environmental variable In-Reply-To: <1390426906.93.0.692922610327.issue20355@psf.upfronthosting.co.za> Message-ID: <1390575807.78.0.177541737855.issue20355@psf.upfronthosting.co.za> Larry Hastings added the comment: Okay, then yes, let's save this for 3.5. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 16:34:04 2014 From: report at bugs.python.org (Glenn Langford) Date: Fri, 24 Jan 2014 15:34:04 +0000 Subject: [issue20367] concurrent.futures.as_completed() fails when given duplicate Futures In-Reply-To: <1390489248.24.0.751917808957.issue20367@psf.upfronthosting.co.za> Message-ID: <1390577644.58.0.626127590885.issue20367@psf.upfronthosting.co.za> Glenn Langford added the comment: > Could you please try to write a unit test. Revised patch with unit test for as_completed(). ---------- Added file: http://bugs.python.org/file33685/issue20367.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 16:37:32 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 15:37:32 +0000 Subject: [issue20260] Argument Clinic: add unsigned integers converters In-Reply-To: <1389720718.78.0.860738296491.issue20260@psf.upfronthosting.co.za> Message-ID: <1390577852.08.0.619785255283.issue20260@psf.upfronthosting.co.za> Larry Hastings added the comment: I can start citing data points if you like. socket.if_indextoname just calls PyLong_AsUnsignedLong(). Not sure what that throws. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 16:55:05 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 24 Jan 2014 15:55:05 +0000 Subject: [issue20367] concurrent.futures.as_completed() fails when given duplicate Futures In-Reply-To: <1390577644.58.0.626127590885.issue20367@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Hum, you should also modify the documentation to explicit the behaviour. Example: "Duplicates futures are only yielded once". You may add the same sentence in the asyncio.as_completed() documentation. It looks like asyncio tests doesn't test as_completed() with duplicated future. You may write a new patch to modify asyncio doc and tests. It should be very similar. + completed = [f for f in futures.as_completed( [f1,f1] ) ] You can just use list(futures.as_completed([f1,f1])). Please no space around parenthesis (see the PEP 8). + self.assertEqual( len(completed), 1 ) No space around parenthesis (see the PEP 8): self.assertEqual(len(completed), 1). You may check the list value instead: self.assertEqual(completed, [f1]) (Why "f1" name? There is no f2, maybe rename to f?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 17:02:57 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 24 Jan 2014 16:02:57 +0000 Subject: [issue20381] Argument Clinic: expression default arguments broken Message-ID: <1390579377.01.0.888294922653.issue20381@psf.upfronthosting.co.za> New submission from Zachary Ware: The fix for #20189 broke simple expression defaults. Specifically, with the latest #20172 patch applied, Clinic fails on winreg.c at winreg line 1351 with this traceback: Error in file "PC\winreg.c" on line 1351: Exception raised during parsing: Traceback (most recent call last): File "Tools\clinic\clinic.py", line 1541, in parse parser.parse(block) File "Tools\clinic\clinic.py", line 2942, in parse self.state(line) File "Tools\clinic\clinic.py", line 3482, in state_parameter_docstring return self.next(self.state_parameter, line) File "Tools\clinic\clinic.py", line 2975, in next self.state(line) File "Tools\clinic\clinic.py", line 3321, in state_parameter bad = default != repr(eval(default)) File "", line 1, in NameError: name 'winreg' is not defined In this case, 'default' is 'winreg.KEY_WRITE'. The 'default != repr(eval(default))' check cannot succeed with such a default even if winreg were defined, as it will return an int, 131078. ---------- assignee: larry components: Demos and Tools messages: 209094 nosy: larry, zach.ware priority: normal severity: normal stage: needs patch status: open title: Argument Clinic: expression default arguments broken type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 17:20:30 2014 From: report at bugs.python.org (Ned Deily) Date: Fri, 24 Jan 2014 16:20:30 +0000 Subject: [issue20374] Failure to compile with readline-6.3-rc1 In-Reply-To: <1390537610.1.0.747015129006.issue20374@psf.upfronthosting.co.za> Message-ID: <1390580430.38.0.951027645755.issue20374@psf.upfronthosting.co.za> Ned Deily added the comment: Serhiy, I'm not sure I understand your question. libedit includes a GNU readline compatibility layer and that is what _readline.so builds and links with on OS X systems (with an ABI of 10.5 and later) since OS X does not ship with GNU readline. This is also the case on some BSD systems. With your patch, _readline.so again builds correctly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 17:41:14 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Jan 2014 16:41:14 +0000 Subject: [issue20374] Failure to compile with readline-6.3-rc1 In-Reply-To: <1390580430.38.0.951027645755.issue20374@psf.upfronthosting.co.za> Message-ID: <19051613.JWRRCAtWoe@raxxla> Serhiy Storchaka added the comment: > With your patch, _readline.so again builds correctly. Yes, this is what I wanted to know. Sorry for the awkward formulation. Type casting is dangerous because it may hide the signature mismatch, which can cause problems later in run time. It is better to rely on static type checking if possible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 17:41:17 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 24 Jan 2014 16:41:17 +0000 Subject: [issue20374] Failure to compile with readline-6.3-rc1 In-Reply-To: <1390537610.1.0.747015129006.issue20374@psf.upfronthosting.co.za> Message-ID: <1390581677.04.0.383018728752.issue20374@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Okay then. Off we go. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 17:44:49 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Jan 2014 16:44:49 +0000 Subject: [issue20374] Failure to compile with readline-6.3-rc1 In-Reply-To: <1390537610.1.0.747015129006.issue20374@psf.upfronthosting.co.za> Message-ID: <3f9mRN1nzbz7LjM@mail.python.org> Roundup Robot added the comment: New changeset 5e42e5764ac6 by Benjamin Peterson in branch '2.7': new plan: just remove typecasts (closes #20374) http://hg.python.org/cpython/rev/5e42e5764ac6 New changeset fc62fcd8e990 by Benjamin Peterson in branch '3.3': new plan: just remove typecasts (closes #20374) http://hg.python.org/cpython/rev/fc62fcd8e990 New changeset 3c3624fec6c8 by Benjamin Peterson in branch 'default': merge 3.3 (#20374) http://hg.python.org/cpython/rev/3c3624fec6c8 ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 18:11:01 2014 From: report at bugs.python.org (mailination) Date: Fri, 24 Jan 2014 17:11:01 +0000 Subject: [issue20382] Typo in cStringIO tp_name Message-ID: <1390583461.72.0.218990367859.issue20382@psf.upfronthosting.co.za> New submission from mailination: python/Modules/cStringIO.c:648 "cStringIO.StringI", /*tp_name*/ maybe Should be "cStringIO.StringIO", /*tp_name*/ ---------- components: Library (Lib) messages: 209099 nosy: mailination priority: normal severity: normal status: open title: Typo in cStringIO tp_name type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 18:11:48 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 24 Jan 2014 17:11:48 +0000 Subject: [issue20383] Add a keyword-only spec argument to types.ModuleType Message-ID: <1390583507.98.0.199737689187.issue20383@psf.upfronthosting.co.za> New submission from Brett Cannon: Would allow for the name attribute to be optional since it can be grabbed from the spec. Since having module.__spec__ set is now expected we should help ensure that by supporting it in the constructor. ---------- components: Library (Lib) messages: 209100 nosy: brett.cannon, eric.snow, ncoghlan priority: low severity: normal stage: test needed status: open title: Add a keyword-only spec argument to types.ModuleType versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 18:17:37 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 24 Jan 2014 17:17:37 +0000 Subject: [issue20382] Typo in cStringIO tp_name In-Reply-To: <1390583461.72.0.218990367859.issue20382@psf.upfronthosting.co.za> Message-ID: <1390583857.03.0.626385374225.issue20382@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't think that it is a typo. cStringIO.StringIO(str) returns a "StringI" object, whereas cStringIO.StringIO() returns a "StringO" object. $ python Python 2.7.5 (default, Nov 12 2013, 16:45:54) [GCC 4.8.2 20131017 (Red Hat 4.8.2-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import cStringIO >>> cStringIO.StringIO('abc') >>> cStringIO.StringIO() ---------- nosy: +haypo resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 18:21:45 2014 From: report at bugs.python.org (Glenn Langford) Date: Fri, 24 Jan 2014 17:21:45 +0000 Subject: [issue20367] concurrent.futures.as_completed() fails when given duplicate Futures In-Reply-To: <1390489248.24.0.751917808957.issue20367@psf.upfronthosting.co.za> Message-ID: <1390584105.0.0.652818653087.issue20367@psf.upfronthosting.co.za> Glenn Langford added the comment: Thanks for the feedback. The new patch is modified for PEP8 with naming consistent with other concurrent tests. assertEqual I think is clearer by checking list length, so it is not changed. The docstring is updated. I suggest asyncio be handled separately. ---------- Added file: http://bugs.python.org/file33686/issue20367.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 18:35:27 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 24 Jan 2014 17:35:27 +0000 Subject: [issue20381] Argument Clinic: expression default arguments broken In-Reply-To: <1390579377.01.0.888294922653.issue20381@psf.upfronthosting.co.za> Message-ID: <1390584927.54.0.487331702342.issue20381@psf.upfronthosting.co.za> Zachary Ware added the comment: This also prevents a vanilla trunk build (as of 85710aa396ef) from succeeding at 'Tools/clinic/clinic.py --make': Error in file ".\Modules\_sre.c" on line 574: Unsupported expression as default value: 'sys.maxsize' I think the only reasonable check we can do is to make sure there aren't any syntax errors in the default value (see patch), but there may well be something I'm missing here. ---------- keywords: +patch Added file: http://bugs.python.org/file33687/issue20381.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 18:54:15 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 24 Jan 2014 17:54:15 +0000 Subject: [issue20376] Argument Clinic: backslashes in docstrings are not escaped In-Reply-To: <1390551719.55.0.676646267319.issue20376@psf.upfronthosting.co.za> Message-ID: <1390586055.2.0.735246859915.issue20376@psf.upfronthosting.co.za> Zachary Ware added the comment: This should do it, correct? ---------- keywords: +patch nosy: +zach.ware Added file: http://bugs.python.org/file33688/issue20376.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 18:58:10 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Jan 2014 17:58:10 +0000 Subject: [issue19077] More robust TemporaryDirectory cleanup In-Reply-To: <1389349295.1.0.12421462312.issue19077@psf.upfronthosting.co.za> Message-ID: <2148515.ZNB7pLonG3@raxxla> Serhiy Storchaka added the comment: Here are updated patches for 3.3 and 3.4. Changed tests for 3.4, a patch for 3.3 is changed more. Unfortunately in 3.3 exceptions still can be raised when try to emit a warning during shutdown. Is there any way to determine the shutdown mode? ---------- Added file: http://bugs.python.org/file33689/tempdir_cleanup-3.3.patch Added file: http://bugs.python.org/file33690/tempdir_finalize-3.4.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r fc62fcd8e990 Lib/tempfile.py --- a/Lib/tempfile.py Fri Jan 24 11:44:16 2014 -0500 +++ b/Lib/tempfile.py Fri Jan 24 19:52:38 2014 +0200 @@ -29,9 +29,9 @@ import functools as _functools import warnings as _warnings -import sys as _sys import io as _io import os as _os +import shutil as _shutil import errno as _errno from random import Random as _Random @@ -355,10 +355,13 @@ underlying file object, without adding a __del__ method to the temporary file.""" + # Set here since __del__ checks it + file = None + close_called = False + def __init__(self, file, name, delete=True): self.file = file self.name = name - self.close_called = False self.delete = delete # NT provides delete-on-close as a primitive, so we don't need @@ -370,14 +373,13 @@ # that this must be referenced as self.unlink, because the # name TemporaryFileWrapper may also get None'd out before # __del__ is called. - unlink = _os.unlink - def close(self): - if not self.close_called: + def close(self, unlink=_os.unlink): + if not self.close_called and self.file is not None: self.close_called = True self.file.close() if self.delete: - self.unlink(self.name) + unlink(self.name) # Need to ensure the file is deleted on __del__ def __del__(self): @@ -677,9 +679,11 @@ in it are removed. """ + # Handle mkdtemp raising an exception + name = None + _closed = False + def __init__(self, suffix="", prefix=template, dir=None): - self._closed = False - self.name = None # Handle mkdtemp raising an exception self.name = mkdtemp(suffix, prefix, dir) def __repr__(self): @@ -688,23 +692,18 @@ def __enter__(self): return self.name - def cleanup(self, _warn=False): + def cleanup(self, _warn=False, _warnings=_warnings): if self.name and not self._closed: try: + _shutil.rmtree(self.name) + except (TypeError, AttributeError) as ex: + if "None" not in '%s' % (ex,): + raise self._rmtree(self.name) - except (TypeError, AttributeError) as ex: - # Issue #10188: Emit a warning on stderr - # if the directory could not be cleaned - # up due to missing globals - if "None" not in str(ex): - raise - print("ERROR: {!r} while cleaning up {!r}".format(ex, self,), - file=_sys.stderr) - return self._closed = True - if _warn: - self._warn("Implicitly cleaning up {!r}".format(self), - ResourceWarning) + if _warn and _warnings.warn: + _warnings.warn("Implicitly cleaning up {!r}".format(self), + ResourceWarning) def __exit__(self, exc, value, tb): self.cleanup() @@ -713,36 +712,19 @@ # Issue a ResourceWarning if implicit cleanup needed self.cleanup(_warn=True) - # XXX (ncoghlan): The following code attempts to make - # this class tolerant of the module nulling out process - # that happens during CPython interpreter shutdown - # Alas, it doesn't actually manage it. See issue #10188 - _listdir = staticmethod(_os.listdir) - _path_join = staticmethod(_os.path.join) - _isdir = staticmethod(_os.path.isdir) - _islink = staticmethod(_os.path.islink) - _remove = staticmethod(_os.remove) - _rmdir = staticmethod(_os.rmdir) - _os_error = OSError - _warn = _warnings.warn - - def _rmtree(self, path): + def _rmtree(self, path, _OSError=OSError, _sep=_os.path.sep, + _listdir=_os.listdir, _remove=_os.remove, _rmdir=_os.rmdir): # Essentially a stripped down version of shutil.rmtree. We can't # use globals because they may be None'ed out at shutdown. - for name in self._listdir(path): - fullname = self._path_join(path, name) - try: - isdir = self._isdir(fullname) and not self._islink(fullname) - except self._os_error: - isdir = False - if isdir: - self._rmtree(fullname) - else: + if not isinstance(path, str): + _sep = _sep.encode() + try: + for name in _listdir(path): + fullname = path + _sep + name try: - self._remove(fullname) - except self._os_error: - pass - try: - self._rmdir(path) - except self._os_error: + _remove(fullname) + except _OSError: + self._rmtree(fullname) + _rmdir(path) + except _OSError: pass diff -r fc62fcd8e990 Lib/test/test_tempfile.py --- a/Lib/test/test_tempfile.py Fri Jan 24 11:44:16 2014 -0500 +++ b/Lib/test/test_tempfile.py Fri Jan 24 19:52:38 2014 +0200 @@ -11,7 +11,7 @@ import weakref import unittest -from test import support +from test import support, script_helper if hasattr(os, 'stat'): @@ -1073,7 +1073,8 @@ self.nameCheck(tmp.name, dir, pre, suf) # Create a subdirectory and some files if recurse: - self.do_create(tmp.name, pre, suf, recurse-1) + d1 = self.do_create(tmp.name, pre, suf, recurse-1) + d1.name = None with open(os.path.join(tmp.name, "test.txt"), "wb") as f: f.write(b"Hello world!") return tmp @@ -1105,7 +1106,7 @@ def test_cleanup_with_symlink_to_a_directory(self): # cleanup() should not follow symlinks to directories (issue #12464) d1 = self.do_create() - d2 = self.do_create() + d2 = self.do_create(recurse=0) # Symlink d1/foo -> d2 os.symlink(d2.name, os.path.join(d1.name, "foo")) @@ -1135,60 +1136,50 @@ finally: os.rmdir(dir) - @unittest.expectedFailure # See issue #10188 def test_del_on_shutdown(self): # A TemporaryDirectory may be cleaned up during shutdown - # Make sure it works with the relevant modules nulled out with self.do_create() as dir: - d = self.do_create(dir=dir) - # Mimic the nulling out of modules that - # occurs during system shutdown - modules = [os, os.path] - if has_stat: - modules.append(stat) - # Currently broken, so suppress the warning - # that is otherwise emitted on stdout - with support.captured_stderr() as err: - with NulledModules(*modules): - d.cleanup() - # Currently broken, so stop spurious exception by - # indicating the object has already been closed - d._closed = True - # And this assert will fail, as expected by the - # unittest decorator... - self.assertFalse(os.path.exists(d.name), - "TemporaryDirectory %s exists after cleanup" % d.name) + for mod in ('os', 'shutil', 'sys', 'tempfile', 'warnings'): + code = """if True: + import os + import shutil + import sys + import tempfile + import warnings + + tmp = tempfile.TemporaryDirectory(dir={dir!r}) + sys.stdout.buffer.write(tmp.name.encode()) + + tmp2 = os.path.join(tmp.name, 'test_dir') + os.mkdir(tmp2) + with open(os.path.join(tmp2, "test.txt"), "w") as f: + f.write("Hello world!") + + {mod}.tmp = tmp + + warnings.filterwarnings("always", category=ResourceWarning) + """.format(dir=dir, mod=mod) + rc, out, err = script_helper.assert_python_ok("-c", code) + tmp_name = out.decode().strip() + self.assertFalse(os.path.exists(tmp_name), + "TemporaryDirectory %s exists after cleanup" % tmp_name) + # Two kinds of warning on shutdown + # Issue 10188: may write to stderr if modules are nulled out + # ResourceWarning will be triggered by __del__ def test_warnings_on_cleanup(self): - # Two kinds of warning on shutdown - # Issue 10888: may write to stderr if modules are nulled out - # ResourceWarning will be triggered by __del__ + # ResourceWarning will be triggered by __del__ with self.do_create() as dir: - if os.sep != '\\': - # Embed a backslash in order to make sure string escaping - # in the displayed error message is dealt with correctly - suffix = '\\check_backslash_handling' - else: - suffix = '' - d = self.do_create(dir=dir, suf=suffix) - - #Check for the Issue 10888 message - modules = [os, os.path] - if has_stat: - modules.append(stat) - with support.captured_stderr() as err: - with NulledModules(*modules): - d.cleanup() - message = err.getvalue().replace('\\\\', '\\') - self.assertIn("while cleaning up", message) - self.assertIn(d.name, message) + d = self.do_create(dir=dir, recurse=3) + name = d.name # Check for the resource warning with support.check_warnings(('Implicitly', ResourceWarning), quiet=False): warnings.filterwarnings("always", category=ResourceWarning) - d.__del__() - self.assertFalse(os.path.exists(d.name), - "TemporaryDirectory %s exists after __del__" % d.name) + del d + support.gc_collect() + self.assertFalse(os.path.exists(name), + "TemporaryDirectory %s exists after __del__" % name) def test_multiple_close(self): # Can be cleaned-up many times without error diff -r fc62fcd8e990 Misc/NEWS --- a/Misc/NEWS Fri Jan 24 11:44:16 2014 -0500 +++ b/Misc/NEWS Fri Jan 24 19:52:38 2014 +0200 @@ -50,6 +50,11 @@ Library ------- +- Issue #19077: tempfile.TemporaryDirectory cleanup is now most likely + successful when called during nulling out of modules during shutdown. + Howere it still can throw a misleading exception if emitting a warning + fails. + - Issue #20317: ExitStack.__exit__ could create a self-referential loop if an exception raised by a cleanup operation already had its context set correctly (for example, by the @contextmanager decorator). The infinite -------------- next part -------------- diff -r 3c3624fec6c8 Lib/tempfile.py --- a/Lib/tempfile.py Fri Jan 24 11:44:40 2014 -0500 +++ b/Lib/tempfile.py Fri Jan 24 19:52:30 2014 +0200 @@ -29,11 +29,12 @@ import functools as _functools import warnings as _warnings -import sys as _sys import io as _io import os as _os +import shutil as _shutil import errno as _errno from random import Random as _Random +import weakref as _weakref try: import _thread @@ -335,10 +336,12 @@ underlying file object, without adding a __del__ method to the temporary file.""" + file = None # Set here since __del__ checks it + close_called = False + def __init__(self, file, name, delete=True): self.file = file self.name = name - self.close_called = False self.delete = delete # NT provides delete-on-close as a primitive, so we don't need @@ -350,14 +353,13 @@ # that this must be referenced as self.unlink, because the # name TemporaryFileWrapper may also get None'd out before # __del__ is called. - unlink = _os.unlink - def close(self): - if not self.close_called: + def close(self, unlink=_os.unlink): + if not self.close_called and self.file is not None: self.close_called = True self.file.close() if self.delete: - self.unlink(self.name) + unlink(self.name) # Need to ensure the file is deleted on __del__ def __del__(self): @@ -657,10 +659,23 @@ in it are removed. """ + # Handle mkdtemp raising an exception + name = None + _finalizer = None + _closed = False + def __init__(self, suffix="", prefix=template, dir=None): - self._closed = False - self.name = None # Handle mkdtemp raising an exception self.name = mkdtemp(suffix, prefix, dir) + self._finalizer = _weakref.finalize( + self, self._cleanup, self.name, + warn_message="Implicitly cleaning up {!r}".format(self)) + + @classmethod + def _cleanup(cls, name, warn_message=None): + _shutil.rmtree(name) + if warn_message is not None: + _warnings.warn(warn_message, ResourceWarning) + def __repr__(self): return "<{} {!r}>".format(self.__class__.__name__, self.name) @@ -668,60 +683,13 @@ def __enter__(self): return self.name - def cleanup(self, _warn=False): - if self.name and not self._closed: - try: - self._rmtree(self.name) - except (TypeError, AttributeError) as ex: - # Issue #10188: Emit a warning on stderr - # if the directory could not be cleaned - # up due to missing globals - if "None" not in str(ex): - raise - print("ERROR: {!r} while cleaning up {!r}".format(ex, self,), - file=_sys.stderr) - return - self._closed = True - if _warn: - self._warn("Implicitly cleaning up {!r}".format(self), - ResourceWarning) - def __exit__(self, exc, value, tb): self.cleanup() - def __del__(self): - # Issue a ResourceWarning if implicit cleanup needed - self.cleanup(_warn=True) + def cleanup(self): + if self._finalizer is not None: + self._finalizer.detach() + if self.name is not None and not self._closed: + _shutil.rmtree(self.name) + self._closed = True - # XXX (ncoghlan): The following code attempts to make - # this class tolerant of the module nulling out process - # that happens during CPython interpreter shutdown - # Alas, it doesn't actually manage it. See issue #10188 - _listdir = staticmethod(_os.listdir) - _path_join = staticmethod(_os.path.join) - _isdir = staticmethod(_os.path.isdir) - _islink = staticmethod(_os.path.islink) - _remove = staticmethod(_os.remove) - _rmdir = staticmethod(_os.rmdir) - _warn = _warnings.warn - - def _rmtree(self, path): - # Essentially a stripped down version of shutil.rmtree. We can't - # use globals because they may be None'ed out at shutdown. - for name in self._listdir(path): - fullname = self._path_join(path, name) - try: - isdir = self._isdir(fullname) and not self._islink(fullname) - except OSError: - isdir = False - if isdir: - self._rmtree(fullname) - else: - try: - self._remove(fullname) - except OSError: - pass - try: - self._rmdir(path) - except OSError: - pass diff -r 3c3624fec6c8 Lib/test/test_tempfile.py --- a/Lib/test/test_tempfile.py Fri Jan 24 11:44:40 2014 -0500 +++ b/Lib/test/test_tempfile.py Fri Jan 24 19:52:30 2014 +0200 @@ -11,7 +11,7 @@ import weakref import unittest -from test import support +from test import support, script_helper if hasattr(os, 'stat'): @@ -1088,7 +1088,8 @@ self.nameCheck(tmp.name, dir, pre, suf) # Create a subdirectory and some files if recurse: - self.do_create(tmp.name, pre, suf, recurse-1) + d1 = self.do_create(tmp.name, pre, suf, recurse-1) + d1.name = None with open(os.path.join(tmp.name, "test.txt"), "wb") as f: f.write(b"Hello world!") return tmp @@ -1120,7 +1121,7 @@ def test_cleanup_with_symlink_to_a_directory(self): # cleanup() should not follow symlinks to directories (issue #12464) d1 = self.do_create() - d2 = self.do_create() + d2 = self.do_create(recurse=0) # Symlink d1/foo -> d2 os.symlink(d2.name, os.path.join(d1.name, "foo")) @@ -1150,60 +1151,51 @@ finally: os.rmdir(dir) - @unittest.expectedFailure # See issue #10188 def test_del_on_shutdown(self): # A TemporaryDirectory may be cleaned up during shutdown - # Make sure it works with the relevant modules nulled out with self.do_create() as dir: - d = self.do_create(dir=dir) - # Mimic the nulling out of modules that - # occurs during system shutdown - modules = [os, os.path] - if has_stat: - modules.append(stat) - # Currently broken, so suppress the warning - # that is otherwise emitted on stdout - with support.captured_stderr() as err: - with NulledModules(*modules): - d.cleanup() - # Currently broken, so stop spurious exception by - # indicating the object has already been closed - d._closed = True - # And this assert will fail, as expected by the - # unittest decorator... - self.assertFalse(os.path.exists(d.name), - "TemporaryDirectory %s exists after cleanup" % d.name) + for mod in ('builtins', 'os', 'shutil', 'sys', 'tempfile', 'warnings'): + code = """if True: + import builtins + import os + import shutil + import sys + import tempfile + import warnings + + tmp = tempfile.TemporaryDirectory(dir={dir!r}) + sys.stdout.buffer.write(tmp.name.encode()) + + tmp2 = os.path.join(tmp.name, 'test_dir') + os.mkdir(tmp2) + with open(os.path.join(tmp2, "test.txt"), "w") as f: + f.write("Hello world!") + + {mod}.tmp = tmp + + warnings.filterwarnings("always", category=ResourceWarning) + """.format(dir=dir, mod=mod) + rc, out, err = script_helper.assert_python_ok("-c", code) + tmp_name = out.decode().strip() + self.assertFalse(os.path.exists(tmp_name), + "TemporaryDirectory %s exists after cleanup" % tmp_name) + err = err.decode('utf-8', 'backslashreplace') + self.assertNotIn("Exception ", err) + self.assertIn("ResourceWarning: Implicitly cleaning up", err) def test_warnings_on_cleanup(self): - # Two kinds of warning on shutdown - # Issue 10888: may write to stderr if modules are nulled out - # ResourceWarning will be triggered by __del__ + # ResourceWarning will be triggered by __del__ with self.do_create() as dir: - if os.sep != '\\': - # Embed a backslash in order to make sure string escaping - # in the displayed error message is dealt with correctly - suffix = '\\check_backslash_handling' - else: - suffix = '' - d = self.do_create(dir=dir, suf=suffix) - - #Check for the Issue 10888 message - modules = [os, os.path] - if has_stat: - modules.append(stat) - with support.captured_stderr() as err: - with NulledModules(*modules): - d.cleanup() - message = err.getvalue().replace('\\\\', '\\') - self.assertIn("while cleaning up", message) - self.assertIn(d.name, message) + d = self.do_create(dir=dir, recurse=3) + name = d.name # Check for the resource warning with support.check_warnings(('Implicitly', ResourceWarning), quiet=False): warnings.filterwarnings("always", category=ResourceWarning) - d.__del__() - self.assertFalse(os.path.exists(d.name), - "TemporaryDirectory %s exists after __del__" % d.name) + del d + support.gc_collect() + self.assertFalse(os.path.exists(name), + "TemporaryDirectory %s exists after __del__" % name) def test_multiple_close(self): # Can be cleaned-up many times without error diff -r 3c3624fec6c8 Misc/NEWS --- a/Misc/NEWS Fri Jan 24 11:44:40 2014 -0500 +++ b/Misc/NEWS Fri Jan 24 19:52:30 2014 +0200 @@ -36,6 +36,10 @@ Library ------- +- Issue #19077: tempfile.TemporaryDirectory cleanup no longer fails when + called during shutdown. Emitting resource warning in __del__ no longer fails. + Original patch by Antoine Pitrou. + - Issue #20189: unittest.mock now no longer assumes that any object for which it could get an inspect.Signature is a callable written in Python. Fix courtesy of Michael Foord. From report at bugs.python.org Fri Jan 24 19:52:56 2014 From: report at bugs.python.org (Derek Wilson) Date: Fri, 24 Jan 2014 18:52:56 +0000 Subject: [issue20209] Deprecate PROTOCOL_SSLv2 In-Reply-To: <1389288239.29.0.63100261927.issue20209@psf.upfronthosting.co.za> Message-ID: <1390589576.65.0.875630460963.issue20209@psf.upfronthosting.co.za> Derek Wilson added the comment: sslv2 should not be deprecated yet. in the field of security research it is highly valuable to locate servers that are still using sslv2 because it is a security risk. i'm fine with making it not used by default, but there is no reason to remove the capability from the language itself. thats way overkill. once sslv2 is no longer in the wild i have no problem with deprecation but the fact is that there is still a strong reason to keep the capability around. ---------- nosy: +underrun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 19:56:01 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 24 Jan 2014 18:56:01 +0000 Subject: [issue20209] Deprecate PROTOCOL_SSLv2 In-Reply-To: <1389288239.29.0.63100261927.issue20209@psf.upfronthosting.co.za> Message-ID: <1390589761.28.0.911881557843.issue20209@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the insight. Then I suggest to close this issue as postponed or rejected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 20:33:01 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 24 Jan 2014 19:33:01 +0000 Subject: [issue20379] help(bound_builtin_class) does not display self In-Reply-To: <1390572402.09.0.311482588548.issue20379@psf.upfronthosting.co.za> Message-ID: <1390591981.41.0.1572607341.issue20379@psf.upfronthosting.co.za> Terry J. Reedy added the comment: What matters to other programs is what the inspect functions return, not what help() does or does not do to the returned string before displaying it. So I see the issue as the discrepancy in this. class C: def foo(self, a): pass c = C() import inspect print('garg - C.foo ', inspect.formatargspec(*inspect.getfullargspec(C.foo))) print('garg - c.foo', inspect.formatargspec(*inspect.getfullargspec(c.foo))) print('sig - C.foo ', str(inspect.signature(C.foo))) print('sig - c.foo', str(inspect.signature(c.foo))) >>> garg - C.foo (self, a) garg - c.foo (self, a) sig - C.foo (self, a) sig - c.foo (a) Idle calltips attempt to remind the user what they must and might enter after '('. For this, the sig output correct and the garg output is buggy. Idle currently works around the garg bug by selectively deleting the first param name with if (isinstance(ob, (type, types.MethodType)) or isinstance(ob_call, types.MethodType)): argspec = _first_param.sub("", argspec) If signatures for bound builtins are similarly buggy, by including 'self' when it should be omitted, calltips would need a means to detect when to omit. Perhaps >>> type([].append) will work, but the name implies otherwise. In any case, I would prefer that inspect.signature give correct results instead of being made bug-compatible with .getfullargspec. In other words, it should include the 'delete self' code that is correct for the implementation. Then I could omit the yet-to-be-written expanded workaround. I regard this help output as buggy. >>> help(c.foo) Help on method foo in module __main__: foo(self, a) method of __main__.C instance It identifies foo as a bound method, but gives the wrong signature for a bound method. So in my view, your changes fix a bug rather than breaking correct behavior. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 20:34:39 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Jan 2014 19:34:39 +0000 Subject: [issue20384] open() exception doesn't contain file name on Windows Message-ID: <1390592079.62.0.820816905232.issue20384@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: On Linux for 2.7, 3.3 and 3.4 the open of non-existing file raises an exception which contains file name. Python 2.7: >>> open('non-existing', 'rb') Traceback (most recent call last): File "", line 1, in IOError: [Errno 2] No such file or directory: 'non-existing' >>> import io >>> io.open('non-existing', 'rb') Traceback (most recent call last): File "", line 1, in IOError: [Errno 2] No such file or directory: 'non-existing' Python 3.3 and 3.4: >>> open('non-existing', 'rb') Traceback (most recent call last): File "", line 1, in FileNotFoundError: [Errno 2] No such file or directory: 'non-existing' On Windows for 2.7 and 3.4 raised exception also contains file name. But on 3.3 error message is only "[Errno 2] No such file or directory" and doesn't contains file name. This change affects tests. test_tarfile failed on all Windows buildbots for 3.3. http://buildbot.python.org/all/builders/x86%20Windows7%203.3/builds/1252/steps/test/logs/stdio I suppose this is 3.3 bug. ---------- components: IO messages: 209109 nosy: benjamin.peterson, hynek, pitrou, serhiy.storchaka, stutzbach priority: normal severity: normal status: open title: open() exception doesn't contain file name on Windows type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 20:39:27 2014 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 24 Jan 2014 19:39:27 +0000 Subject: [issue20384] open() exception doesn't contain file name on Windows In-Reply-To: <1390592079.62.0.820816905232.issue20384@psf.upfronthosting.co.za> Message-ID: <1390592367.05.0.594327183337.issue20384@psf.upfronthosting.co.za> Mark Lawrence added the comment: Not on my system, so what's changed? Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:18:40) [MSC v.1600 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> open('non-existing', 'rb') Traceback (most recent call last): File "", line 1, in FileNotFoundError: [Errno 2] No such file or directory: 'non-existing' ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 20:45:57 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Jan 2014 19:45:57 +0000 Subject: [issue20384] open() exception doesn't contain file name on Windows In-Reply-To: <1390592079.62.0.820816905232.issue20384@psf.upfronthosting.co.za> Message-ID: <1390592757.45.0.145632499419.issue20384@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Mark, could you please try following commands? import tarfile; tarfile.open('non-existing', 'r|') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 20:47:30 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Jan 2014 19:47:30 +0000 Subject: [issue20384] open() exception doesn't contain file name on Windows In-Reply-To: <1390592079.62.0.820816905232.issue20384@psf.upfronthosting.co.za> Message-ID: <1390592850.32.0.231893769144.issue20384@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 20:47:45 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Jan 2014 19:47:45 +0000 Subject: [issue20384] open() exception doesn't contain file name on Windows In-Reply-To: <1390592079.62.0.820816905232.issue20384@psf.upfronthosting.co.za> Message-ID: <1390592865.5.0.549726443267.issue20384@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +brian.curtin, tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 20:48:49 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 24 Jan 2014 19:48:49 +0000 Subject: [issue20378] Implement `Signature.__repr__` Message-ID: <1390592929.28.0.358636885148.issue20378@psf.upfronthosting.co.za> New submission from Terry J. Reedy: Signature.__repr__ already exits. It is inherited from object. So you must be proposing to override the inherited method. For what purpose? With what outcome? Without reading the signature PEP, I believe the current difference between str and repr is intentional, not accidental. Example: >>> repr(s) '' >>> str(s) '(self, a)' If so, this issue should be closed unless you can provide an excellent reason to break code the expects the current behavior. ---------- nosy: +terry.reedy, yselivanov stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 20:51:43 2014 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 24 Jan 2014 19:51:43 +0000 Subject: [issue20384] open() exception doesn't contain file name on Windows In-Reply-To: <1390592079.62.0.820816905232.issue20384@psf.upfronthosting.co.za> Message-ID: <1390593103.18.0.488553115308.issue20384@psf.upfronthosting.co.za> Mark Lawrence added the comment: Two attempts, one with the pipe "|" symbol in the mode, one without. >>> import tarfile; tarfile.open('non-existing', 'r|') Traceback (most recent call last): File "", line 1, in File "C:\Python33\lib\tarfile.py", line 1594, in open stream = _Stream(name, filemode, comptype, fileobj, bufsize) File "C:\Python33\lib\tarfile.py", line 362, in __init__ fileobj = _LowLevelFile(name, mode) File "C:\Python33\lib\tarfile.py", line 335, in __init__ self.fd = os.open(name, mode, 0o666) FileNotFoundError: [Errno 2] No such file or directory >>> import tarfile; tarfile.open('non-existing', 'r') Traceback (most recent call last): File "", line 1, in File "C:\Python33\lib\tarfile.py", line 1566, in open return func(name, "r", fileobj, **kwargs) File "C:\Python33\lib\tarfile.py", line 1614, in taropen return cls(name, mode, fileobj, **kwargs) File "C:\Python33\lib\tarfile.py", line 1442, in __init__ fileobj = bltn_open(name, self._mode) FileNotFoundError: [Errno 2] No such file or directory: 'non-existing' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 20:55:33 2014 From: report at bugs.python.org (Ram Rachum) Date: Fri, 24 Jan 2014 19:55:33 +0000 Subject: [issue20378] Implement `Signature.__repr__` In-Reply-To: <1390592929.28.0.358636885148.issue20378@psf.upfronthosting.co.za> Message-ID: <1390593333.35.0.81078754301.issue20378@psf.upfronthosting.co.za> Ram Rachum added the comment: My impression is that the `__repr__` method of any object is intended to describe that object, hopefully in a succinct way, possibly in a REPL-friendly way (like `list.__repr__` for example) but if not then at least human-friendly. This is for easy introspection. When I come across a Signature object in the shell, I want to immediately get a good feel for what it contains without exploring `vars(sig)` manully. If you have a `Signature` object, why not have its `__repr__` return something like '`? This would do an awesome job at helping me understand what kind of signature object I'm looking at. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 21:05:32 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Jan 2014 20:05:32 +0000 Subject: [issue20384] open() exception doesn't contain file name on Windows In-Reply-To: <1390592079.62.0.820816905232.issue20384@psf.upfronthosting.co.za> Message-ID: <1390593932.04.0.0721391248072.issue20384@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ah, here is os.open() raises an exception. Thank you Mark. On Linux it raises an exception with file name. >>> import os; os.open('non-existing', os.O_RDONLY | getattr(os, 'O_BINARY', 0), 0x666) Traceback (most recent call last): File "", line 1, in FileNotFoundError: [Errno 2] No such file or directory: 'non-existing' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 21:20:27 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Jan 2014 20:20:27 +0000 Subject: [issue20384] open() exception doesn't contain file name on Windows In-Reply-To: <1390592079.62.0.820816905232.issue20384@psf.upfronthosting.co.za> Message-ID: <3f9sD61bqZzQ1T@mail.python.org> Roundup Robot added the comment: New changeset 69d885ac042d by Serhiy Storchaka in branch '3.3': Issue #20384: Fix the test_tarfile test on Windows. http://hg.python.org/cpython/rev/69d885ac042d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 21:32:38 2014 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 24 Jan 2014 20:32:38 +0000 Subject: [issue20384] open() exception doesn't contain file name on Windows In-Reply-To: <1390592079.62.0.820816905232.issue20384@psf.upfronthosting.co.za> Message-ID: <1390595558.0.0.917732207076.issue20384@psf.upfronthosting.co.za> Mark Lawrence added the comment: I think there's a typo in the patch, test = 'xxx' but after the check for platform and mode, text = ''. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 21:41:48 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Jan 2014 20:41:48 +0000 Subject: [issue20384] open() exception doesn't contain file name on Windows In-Reply-To: <1390592079.62.0.820816905232.issue20384@psf.upfronthosting.co.za> Message-ID: <1390596108.76.0.970985671678.issue20384@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, thank you. It is alredy fixed in 38a50d8102be (thanks Arfrever). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 21:49:47 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Jan 2014 20:49:47 +0000 Subject: [issue20384] os.open() exception doesn't contain file name on Windows In-Reply-To: <1390592079.62.0.820816905232.issue20384@psf.upfronthosting.co.za> Message-ID: <1390596587.22.0.83872763987.issue20384@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- title: open() exception doesn't contain file name on Windows -> os.open() exception doesn't contain file name on Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 21:55:34 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 24 Jan 2014 20:55:34 +0000 Subject: [issue20379] help(bound_builtin_class) does not display self In-Reply-To: <1390572402.09.0.311482588548.issue20379@psf.upfronthosting.co.za> Message-ID: <1390596934.91.0.59339567409.issue20379@psf.upfronthosting.co.za> Zachary Ware added the comment: I don't think there's any danger of changing inspect.Signature's behavior here; it's doing the right thing. What we're concerned with here is just making sure that the output of 'help(some_kind_of_method)' is equivalent to the output of 'help(some_kind_of_method_in_C)', which should just mean changes to pydoc. pydoc currently shows the 'self' parameter because before trying to find the signature, it replaces the object it is looking at with that object's __func__ attribute (see Lib/pydoc.py:1315). To get rid of that behavior for Python-implemented methods is as simple as removing that line. Is that the route we want to go, though? It makes sense and it does make Python and C methods (mostly) match so I'd be happy with it, but it does change the help output for every Python-implemented method. There is still the issue that the help output for C-implemented methods don't say anything about whether they're bound or not, but that issue is just a sibling to this one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 22:26:19 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 21:26:19 +0000 Subject: [issue20381] Argument Clinic: expression default arguments broken In-Reply-To: <1390579377.01.0.888294922653.issue20381@psf.upfronthosting.co.za> Message-ID: <52e2da77.2597420a.3347.ffffdb2f@mx.google.com> Larry Hastings added the comment: Remove the winreg. On Jan 24, 2014 8:02 AM, Zachary Ware wrote: > > > New submission from Zachary Ware: > > The fix for #20189 broke simple expression defaults.? Specifically, with the latest #20172 patch applied, Clinic fails on winreg.c at winreg line 1351 with this traceback: > > Error in file "PC\winreg.c" on line 1351: > Exception raised during parsing: > Traceback (most recent call last): > ? File "Tools\clinic\clinic.py", line 1541, in parse > ??? parser.parse(block) > ? File "Tools\clinic\clinic.py", line 2942, in parse > ??? self.state(line) > ? File "Tools\clinic\clinic.py", line 3482, in state_parameter_docstring > ??? return self.next(self.state_parameter, line) > ? File "Tools\clinic\clinic.py", line 2975, in next > ??? self.state(line) > ? File "Tools\clinic\clinic.py", line 3321, in state_parameter > ??? bad = default != repr(eval(default)) > ? File "", line 1, in > NameError: name 'winreg' is not defined > > In this case, 'default' is 'winreg.KEY_WRITE'.? The 'default != repr(eval(default))' check cannot succeed with such a default even if winreg were defined, as it will return an int, 131078. > > ---------- > assignee: larry > components: Demos and Tools > messages: 209094 > nosy: larry, zach.ware > priority: normal > severity: normal > stage: needs patch > status: open > title: Argument Clinic: expression default arguments broken > type: behavior > versions: Python 3.4 > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 22:31:14 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 24 Jan 2014 21:31:14 +0000 Subject: [issue20381] Argument Clinic: expression default arguments broken In-Reply-To: <1390579377.01.0.888294922653.issue20381@psf.upfronthosting.co.za> Message-ID: <1390599073.99.0.324097560847.issue20381@psf.upfronthosting.co.za> Zachary Ware added the comment: Removing 'winreg.' gives the very similar traceback: Error in file "PC\winreg.c" on line 1351: Exception raised during parsing: Traceback (most recent call last): File "Tools\clinic\clinic.py", line 1541, in parse parser.parse(block) File "Tools\clinic\clinic.py", line 2942, in parse self.state(line) File "Tools\clinic\clinic.py", line 3482, in state_parameter_docstring return self.next(self.state_parameter, line) File "Tools\clinic\clinic.py", line 2975, in next self.state(line) File "Tools\clinic\clinic.py", line 3321, in state_parameter bad = default != repr(eval(default)) File "", line 1, in NameError: name 'KEY_WRITE' is not defined ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 22:35:41 2014 From: report at bugs.python.org (Tal Einat) Date: Fri, 24 Jan 2014 21:35:41 +0000 Subject: [issue20385] Argument Clinic: Support for __new__ not checking _PyArg_NoKeywords for sub-classes Message-ID: <1390599341.47.0.747419262521.issue20385@psf.upfronthosting.co.za> New submission from Tal Einat: To quote issue20294 where Larry Hastings added AC support for __new__ and __init__: " * __init__ and __new__ always take kwargs. * if the function signature doesn't accept keyword arguments, it calls _PyArg_NoKeywords(). " However, due to issue1486663, many classes only do a _PyArg_NoKeywords if the type is the original class, but not for sub-classses. Examples are _random.Random (in which case I found a workaround) and many itertools classes, for which there are also tests that check this. One possibility is to simply allow these classes to also accept keyword arguments. It doesn't break backwards compatibility, and once there are proper argument names and doc-strings, why not? Otherwise, currently I have to make generated __new__ functions accept keyword arguments, and then wrap them with a function that checks _PyArg_NoKeywords only if the the type is the original class. ---------- components: Build, Demos and Tools messages: 209122 nosy: larry, taleinat priority: normal severity: normal status: open title: Argument Clinic: Support for __new__ not checking _PyArg_NoKeywords for sub-classes type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 22:41:47 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 21:41:47 +0000 Subject: [issue20381] Argument Clinic: expression default arguments broken In-Reply-To: <1390579377.01.0.888294922653.issue20381@psf.upfronthosting.co.za> Message-ID: <1390599707.77.0.416937781201.issue20381@psf.upfronthosting.co.za> Larry Hastings added the comment: Let's not catch Exception there. Does catching NameError make the problem go away? And, #20189 changed the rules for simple expressions. Now names you want from the local module should not have the name of the module in front. You wouldn't have to do this in foo.py: IMPORTANT_SYMBOLIC_CONSTANT=83 def fn(a=foo.IMPORTANT_SYMBOLIC_CONSTANT): ... So it was always a dumb idea to require it for Argument Clinic code too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 22:44:42 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 21:44:42 +0000 Subject: [issue20385] Argument Clinic: Support for __new__ not checking _PyArg_NoKeywords for sub-classes In-Reply-To: <1390599341.47.0.747419262521.issue20385@psf.upfronthosting.co.za> Message-ID: <1390599882.21.0.479636897752.issue20385@psf.upfronthosting.co.za> Larry Hastings added the comment: How about I add the "if type == " checks as per #1486663? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 22:45:52 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 21:45:52 +0000 Subject: [issue20209] Deprecate PROTOCOL_SSLv2 In-Reply-To: <1389288239.29.0.63100261927.issue20209@psf.upfronthosting.co.za> Message-ID: <1390599952.94.0.538263972756.issue20209@psf.upfronthosting.co.za> Larry Hastings added the comment: I agree. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 22:49:46 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 24 Jan 2014 21:49:46 +0000 Subject: [issue20209] Deprecate PROTOCOL_SSLv2 In-Reply-To: <1389288239.29.0.63100261927.issue20209@psf.upfronthosting.co.za> Message-ID: <1390600186.22.0.349691175976.issue20209@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 22:54:08 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 21:54:08 +0000 Subject: [issue20379] help(bound_builtin_class) does not display self In-Reply-To: <1390572402.09.0.311482588548.issue20379@psf.upfronthosting.co.za> Message-ID: <1390600448.02.0.0300552230164.issue20379@psf.upfronthosting.co.za> Larry Hastings added the comment: Huh. So inspect.getfullargspec is the code ignoring whether or not a function is bound. Well, help(x) should be consistent, whether x is a bound builtin class instance or a bound Python class instance. Right now it isn't; it displays the "self" for the Python one but not for the builtin one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 23:05:15 2014 From: report at bugs.python.org (Tal Einat) Date: Fri, 24 Jan 2014 22:05:15 +0000 Subject: [issue20385] Argument Clinic: Support for __new__ not checking _PyArg_NoKeywords for sub-classes In-Reply-To: <1390599341.47.0.747419262521.issue20385@psf.upfronthosting.co.za> Message-ID: <1390601115.12.0.944934769846.issue20385@psf.upfronthosting.co.za> Tal Einat added the comment: In general, that sounds like a reasonable suggestion to me. A quick search shows that most classes that call _PyArg_NoKeywords check the type first. I think we should strive for uniformity in this respect, so I'm +1 for your suggestion. I do see some classes which accept only positional arguments but where that check isn't in place. Examples: * itertools.tee just calls PyArg_ParseTuple without checking _PyArg_NoKeywords (is this a bug?) (this is fairly common, I think) * range always calls _PyArg_NoKeywords, without checking the type (is this a bug?) (this is rare) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 23:14:43 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 22:14:43 +0000 Subject: [issue20385] Argument Clinic: Support for __new__ not checking _PyArg_NoKeywords for sub-classes In-Reply-To: <1390599341.47.0.747419262521.issue20385@psf.upfronthosting.co.za> Message-ID: <1390601683.45.0.930422069451.issue20385@psf.upfronthosting.co.za> Larry Hastings added the comment: I think it's a bug that they don't do the subclass check. In practice, nobody subclasses range and itertools.tee. But they should probably still be fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 23:24:06 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 24 Jan 2014 22:24:06 +0000 Subject: [issue20381] Argument Clinic: expression default arguments broken In-Reply-To: <1390579377.01.0.888294922653.issue20381@psf.upfronthosting.co.za> Message-ID: <1390602246.58.0.937433743618.issue20381@psf.upfronthosting.co.za> Zachary Ware added the comment: How does this one strike you? Somewhat reversed logic compared to the first patch, but with this one we get either success or a nicely formatted fail message, no more tracebacks. ---------- Added file: http://bugs.python.org/file33691/issue20381.v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 23:28:00 2014 From: report at bugs.python.org (Tal Einat) Date: Fri, 24 Jan 2014 22:28:00 +0000 Subject: [issue20385] Argument Clinic: Support for __new__ not checking _PyArg_NoKeywords for sub-classes In-Reply-To: <1390599341.47.0.747419262521.issue20385@psf.upfronthosting.co.za> Message-ID: <1390602480.99.0.141540965831.issue20385@psf.upfronthosting.co.za> Tal Einat added the comment: Great. Most of the classes in itertools could use this. BTW, you'll need to supply a way to supply the C name of the type, to use in the type check. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 23:30:13 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 22:30:13 +0000 Subject: [issue20385] Argument Clinic: Support for __new__ not checking _PyArg_NoKeywords for sub-classes In-Reply-To: <1390599341.47.0.747419262521.issue20385@psf.upfronthosting.co.za> Message-ID: <1390602613.82.0.394835449266.issue20385@psf.upfronthosting.co.za> Larry Hastings added the comment: Way ahead of you. The "class" directive will have to change: class name typedef type_object On the other hand, this means that Argument Clinic can automatically give the right type to the default self converter. So most people won't have to write custom self converter classes anymore. Argument Clinic giveth, and it taketh away. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 23:35:18 2014 From: report at bugs.python.org (Tal Einat) Date: Fri, 24 Jan 2014 22:35:18 +0000 Subject: [issue20385] Argument Clinic: Support for __new__ not checking _PyArg_NoKeywords for sub-classes In-Reply-To: <1390599341.47.0.747419262521.issue20385@psf.upfronthosting.co.za> Message-ID: <1390602918.85.0.911958938006.issue20385@psf.upfronthosting.co.za> Tal Einat added the comment: +1 for that as well, I've written quite a few self converters for that reason. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 23:41:54 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 22:41:54 +0000 Subject: [issue20381] Argument Clinic: expression default arguments broken In-Reply-To: <1390579377.01.0.888294922653.issue20381@psf.upfronthosting.co.za> Message-ID: <1390603314.89.0.445507180634.issue20381@psf.upfronthosting.co.za> Larry Hastings added the comment: It's considered bad form to catch Exception. We should catch the minimum necessary. If there are exceptions we forgot, people will complain and then we'll add those. Also, I want to make sure (if possible) that the value round-trips correctly through eval and repr. We need to repr the value, and if it doesn't round-trip properly the user needs to know. On the other hand, I'm okay with starting with bad=False and going from there. The previous block (with DetectBadNodes()) already does that. Hang on for a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 23:48:21 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 24 Jan 2014 22:48:21 +0000 Subject: [issue20386] socket.SocketType is different in Python 3.4 Message-ID: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za> New submission from Giampaolo Rodola': Python 2.7 >>> import socket >>> socket.SocketType >>> s = socket.socket() >>> isinstance(s, socket.SocketType) True >>> Python 3.4 >>> socket.SocketType >>> s = socket.socket() >>> isinstance(s, socket.SocketType) False >>> SocketType was already present and documented in Python 2 so it should be preserved: http://docs.python.org/2/library/socket.html#socket.SocketType Also, socket.SocketType and socket.AddressFamily names suggest they should be public but they're not mentioned in the doc. I think they should just be private though (frankly I fail to understand why a set of constants such as AF_* and SOCK_* should be grouped in a common "container" in the first place). ---------- messages: 209134 nosy: giampaolo.rodola priority: normal severity: normal status: open title: socket.SocketType is different in Python 3.4 versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 23:49:12 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 22:49:12 +0000 Subject: [issue20381] Argument Clinic: expression default arguments broken In-Reply-To: <1390579377.01.0.888294922653.issue20381@psf.upfronthosting.co.za> Message-ID: <1390603752.16.0.821456690948.issue20381@psf.upfronthosting.co.za> Larry Hastings added the comment: How about this? I'm going to do a rollup patch today with three fixes: this, #20385, and changing the default filename for the "file" destination. ---------- Added file: http://bugs.python.org/file33692/larry.clinic.rollup.jan.24.diff.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 23:49:30 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 24 Jan 2014 22:49:30 +0000 Subject: [issue20385] Argument Clinic: Support for __new__ not checking _PyArg_NoKeywords for sub-classes In-Reply-To: <1390599341.47.0.747419262521.issue20385@psf.upfronthosting.co.za> Message-ID: <1390603770.26.0.912369230941.issue20385@psf.upfronthosting.co.za> Larry Hastings added the comment: How about this? I'm going to do a rollup patch today with three fixes: this, #20381, and changing the default filename for the "file" destination. ---------- Added file: http://bugs.python.org/file33693/larry.clinic.rollup.jan.24.diff.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 24 23:51:15 2014 From: report at bugs.python.org (Jason R. Coombs) Date: Fri, 24 Jan 2014 22:51:15 +0000 Subject: [issue20387] tokenize/untokenize roundtrip fails with tabs Message-ID: <1390603875.19.0.598751073352.issue20387@psf.upfronthosting.co.za> New submission from Jason R. Coombs: Consider this simple unit test: def test_tokenize(): input = "if False:\n\tx=3\n\ty=3\n" g = list(generate_tokens(io.StringIO(input).readline)) assert untokenize(g) == input According to the docs, untokenize guarantees the output equals the input to tokenize: http://docs.python.org/2/library/tokenize.html#tokenize.untokenize As this test fails on Python 2 and Python 3 (use io.BytesIO on Python 2), I believe the test illustrates a violation of this guarantee. The second line in the if block gets its tab replaced by a space. As the input is valid Python Syntax, this behavior is particularly surprising. ---------- messages: 209137 nosy: jason.coombs priority: normal severity: normal status: open title: tokenize/untokenize roundtrip fails with tabs versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 00:08:28 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 24 Jan 2014 23:08:28 +0000 Subject: [issue20387] tokenize/untokenize roundtrip fails with tabs In-Reply-To: <1390603875.19.0.598751073352.issue20387@psf.upfronthosting.co.za> Message-ID: <1390604908.55.0.292696534405.issue20387@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 01:29:01 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 25 Jan 2014 00:29:01 +0000 Subject: [issue20379] help(bound_builtin_class) does not display self In-Reply-To: <1390572402.09.0.311482588548.issue20379@psf.upfronthosting.co.za> Message-ID: <1390609741.47.0.133091142815.issue20379@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I fully agree that help(bound method) should be consistent. I just feel that it should be consistently correct ;-). Help(ob) is intended for interactive use (Guido has said, but feel free to ask again), and indeed, is an optional interactive feature, and not a built-in. So I believe we are free to change the output to something better (as with Exception messages). For some things (classes), it prints out too much and Guido would like a bit less printed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 01:51:49 2014 From: report at bugs.python.org (Buck Golemon) Date: Sat, 25 Jan 2014 00:51:49 +0000 Subject: [issue1243678] httplib gzip support Message-ID: <1390611109.67.0.12673739609.issue1243678@psf.upfronthosting.co.za> Buck Golemon added the comment: I believe this issue is still extant. The tip httplib client neither sends accept-encoding gzip nor supports content-encoding gzip. http://hg.python.org/cpython/file/tip/Lib/http/client.py#l1012 There is a diff to httplib in this attached patch, where there was none in #1675951. ---------- nosy: +Buck.Golemon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 04:41:52 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Jan 2014 03:41:52 +0000 Subject: [issue6626] show Python mimetypes module some love In-Reply-To: <1249240763.95.0.402656374782.issue6626@psf.upfronthosting.co.za> Message-ID: <1390621312.61.0.143592228175.issue6626@psf.upfronthosting.co.za> Nick Coghlan added the comment: Note that I still believe there are substantial improvements that could be made without a wholesale rewrite of the module that poses significant backwards compatibility risks (just improving the documentation regarding how the list of types is populated could likely help some users, as would updating the default list we use if we can't retrieve one from the environment). Alternatively, even if we can't get anyone interested in such a refactoring task, it may be feasible to introduce an improved mimetypes handling interface that is easier to maintain and keep up to date, again without risking backwards compatibility issues for users of the current module. Some potentially relevant links for anyone wanting to investigate improving the standard library's MIME type support: The discussions with Jacob in Rietveld regarding his original approach: https://codereview.appspot.com/107042 PyPI libraries: https://pypi.python.org/pypi/mimeparse/ https://pypi.python.org/pypi/mime https://pypi.python.org/pypi/zope.mimetype https://pypi.python.org/pypi/Products.MimetypesRegistry (Jacob pointed this one out above) The various PyPI wrappers around libmagic and the *nix "file" utility are also of potential interest for research purposes (but aren't especially useful on Windows, where those tools are significantly less likely to be available). ---------- versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 04:56:06 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 25 Jan 2014 03:56:06 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1390622166.01.0.183307451664.issue17481@psf.upfronthosting.co.za> Larry Hastings added the comment: There's a major difference between getfullargspec/getargspec and inspect.signature: getfullargspec shows you the "self" parameter for bound methods, and inspect.signature does not. >>> class C: ... def foo(self, a): pass ... >>> c = C() >>> >>> import inspect >>> str(inspect.signature(c.foo)) '(a)' >>> inspect.getfullargspec(c.foo) FullArgSpec(args=['self', 'a'], varargs=None, varkw=None, defaults=None, kwonlyargs=[], kwonlydefaults=None, annotations={}) >>> inspect.getargspec(c.foo) ArgSpec(args=['self', 'a'], varargs=None, keywords=None, defaults=None) This is why help() (currently) shows bound parameters for methods implemented in Python, but doesn't show them for methods implemented in C. pydoc uses inspect.getfullargspec for pure Python functions and inspect.signature for builtins. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 05:06:07 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 25 Jan 2014 04:06:07 +0000 Subject: [issue20379] help(instance_of_builtin_class.method) does not display self In-Reply-To: <1390572402.09.0.311482588548.issue20379@psf.upfronthosting.co.za> Message-ID: <1390622767.29.0.688528128851.issue20379@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- title: help(bound_builtin_class) does not display self -> help(instance_of_builtin_class.method) does not display self _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 05:12:53 2014 From: report at bugs.python.org (Zachary Ware) Date: Sat, 25 Jan 2014 04:12:53 +0000 Subject: [issue20381] Argument Clinic: expression default arguments broken In-Reply-To: <1390579377.01.0.888294922653.issue20381@psf.upfronthosting.co.za> Message-ID: <1390623173.26.0.698416437664.issue20381@psf.upfronthosting.co.za> Zachary Ware added the comment: This will still cause issue in _sre.c; repr(sys.maxsize) == '9223372036854775807' != 'sys.maxsize'. Yes, it's bad form to throw the net too wide, but for anything other than NameError, we fail out in the next block anyway. My (second) patch just makes for nicer output from the failure, though it does fail to say what the exception was. What about something more along these lines? bad = False try: eval(default) except NameError: pass # probably a named constant except Exception as e: fail("Malformed expression given as default value\n" "{!r} raised {!r}".format(default, e)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 05:18:49 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 25 Jan 2014 04:18:49 +0000 Subject: [issue20379] help(instance_of_builtin_class.method) does not display self In-Reply-To: <1390572402.09.0.311482588548.issue20379@psf.upfronthosting.co.za> Message-ID: <1390623529.65.0.885233873165.issue20379@psf.upfronthosting.co.za> Larry Hastings added the comment: Yeah, that's a good approach. By the way, I'm definitely going to check for "unspecified" there. Serhiy was using that to try and trick Argument Clinic into having optional parameters without default values. It didn't actually work--and indeed it would never have worked properly--but I feel like I need some defensive programming anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 05:24:02 2014 From: report at bugs.python.org (Zachary Ware) Date: Sat, 25 Jan 2014 04:24:02 +0000 Subject: [issue20379] help(instance_of_builtin_class.method) does not display self In-Reply-To: <1390572402.09.0.311482588548.issue20379@psf.upfronthosting.co.za> Message-ID: <1390623842.38.0.416832608158.issue20379@psf.upfronthosting.co.za> Zachary Ware added the comment: Larry, was that message meant for #20381? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 05:24:36 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 25 Jan 2014 04:24:36 +0000 Subject: [issue20379] help(instance_of_builtin_class.method) does not display self In-Reply-To: <1390572402.09.0.311482588548.issue20379@psf.upfronthosting.co.za> Message-ID: <1390623876.82.0.631239040347.issue20379@psf.upfronthosting.co.za> Larry Hastings added the comment: Yup! Second time I've done that this week! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 05:24:40 2014 From: report at bugs.python.org (Zachary Ware) Date: Sat, 25 Jan 2014 04:24:40 +0000 Subject: [issue20381] Argument Clinic: expression default arguments broken In-Reply-To: <1390579377.01.0.888294922653.issue20381@psf.upfronthosting.co.za> Message-ID: <1390623880.83.0.817237731806.issue20381@psf.upfronthosting.co.za> Zachary Ware added the comment: Here's a patch with my last suggestion, and the check for unspecified. ---------- Added file: http://bugs.python.org/file33694/issue20381.v3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 05:24:58 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 25 Jan 2014 04:24:58 +0000 Subject: [issue20381] Argument Clinic: expression default arguments broken In-Reply-To: <1390579377.01.0.888294922653.issue20381@psf.upfronthosting.co.za> Message-ID: <1390623898.67.0.717172448265.issue20381@psf.upfronthosting.co.za> Larry Hastings added the comment: Yeah, that's a good approach. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 05:51:40 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Jan 2014 04:51:40 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <1390625500.48.0.490464238684.issue19081@psf.upfronthosting.co.za> Nick Coghlan added the comment: I dunno Brett - have you read the extension module import code and the zipimport code lately? I don't think I'll be willing to claim to fully understand even the default importers until we've rewritten those as PEP 451 compliant Python code with a couple of essential C level helper functions, just like the rest of the import system :) As far as this particular issue goes, removing the extra level of caching sounds like a good idea, and http://bugs.python.org/file33614/issue19081-subimport-fix-gps02.diff looks right to me. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 05:52:47 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 Jan 2014 04:52:47 +0000 Subject: [issue20381] Argument Clinic: expression default arguments broken In-Reply-To: <1390579377.01.0.888294922653.issue20381@psf.upfronthosting.co.za> Message-ID: <3fB4bK4lDmz7Lk1@mail.python.org> Roundup Robot added the comment: New changeset 93afa651e074 by Zachary Ware in branch 'default': Issue #20381: Fix sanity checking on default arguments when c_default is http://hg.python.org/cpython/rev/93afa651e074 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 05:53:35 2014 From: report at bugs.python.org (Zachary Ware) Date: Sat, 25 Jan 2014 04:53:35 +0000 Subject: [issue20381] Argument Clinic: expression default arguments broken In-Reply-To: <1390579377.01.0.888294922653.issue20381@psf.upfronthosting.co.za> Message-ID: <1390625615.58.0.979633493346.issue20381@psf.upfronthosting.co.za> Zachary Ware added the comment: Done, thanks for the review! ---------- assignee: larry -> zach.ware resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 05:54:31 2014 From: report at bugs.python.org (Zachary Ware) Date: Sat, 25 Jan 2014 04:54:31 +0000 Subject: [issue20379] help(instance_of_builtin_class.method) does not display self In-Reply-To: <1390572402.09.0.311482588548.issue20379@psf.upfronthosting.co.za> Message-ID: <1390625671.15.0.500047675975.issue20379@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- Removed message: http://bugs.python.org/msg209143 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 05:54:33 2014 From: report at bugs.python.org (Zachary Ware) Date: Sat, 25 Jan 2014 04:54:33 +0000 Subject: [issue20379] help(instance_of_builtin_class.method) does not display self In-Reply-To: <1390572402.09.0.311482588548.issue20379@psf.upfronthosting.co.za> Message-ID: <1390625673.25.0.904498846802.issue20379@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- Removed message: http://bugs.python.org/msg209144 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 05:54:36 2014 From: report at bugs.python.org (Zachary Ware) Date: Sat, 25 Jan 2014 04:54:36 +0000 Subject: [issue20379] help(instance_of_builtin_class.method) does not display self In-Reply-To: <1390572402.09.0.311482588548.issue20379@psf.upfronthosting.co.za> Message-ID: <1390625676.02.0.208766684643.issue20379@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- Removed message: http://bugs.python.org/msg209145 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 05:56:53 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sat, 25 Jan 2014 04:56:53 +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: <1390625813.48.0.0129741881093.issue15955@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Is there any reason why unconsumed_tail needs to be exposted? I would suggest to instead introduce a boolean attribute data_ready than indicates that more decompressed data can be provided without additional compressed input. Example: # decomp = decompressor object # infh = compressed input stream # outfh = decompressed output stream while not decomp.eof: if decomp.data_ready: buf = decomp.decompress(max_size=BUFSIZE) # or maybe: #buf = decomp.decompress(b'', max_size=BUFSIZE) else: buf = infh.read(BUFSIZE) if not buf: raise RuntimeError('Unexpected end of compressed stream') buf = decomp.decompress(buf, max_size=BUFSIZE) assert len(buf) > 0 outfh.write(buf) This is short, easily readable (in my opinion) and also avoids the problem where the decompressor blocks because it needs more data even though there still is an unconsumed tail. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 06:11:06 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Sat, 25 Jan 2014 05:11:06 +0000 Subject: [issue19145] Inconsistent behaviour in itertools.repeat when using negative times In-Reply-To: <1380727396.47.0.412229295257.issue19145@psf.upfronthosting.co.za> Message-ID: <1390626666.72.0.504897695989.issue19145@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Larry said, "It behaves differently depending on whether "times" is passed by position or by keyword." And that is the bug. It should be the same no matter whether we send times through positional or keyword. As Raymond has said earlier in this thread, "The preferred behavior is that a negative number always means 0." So negative times through keyword must mean zero repetitions. So it means we cannot set -1 as a default value for times because it will upset many people. I am not sure at the moment in itertools.repeat, sig = inspect.signature(itertools.repeat) a = itertools.repeat('a') b = itertools.repeat('a', sig.parameters['times'].default) c = itertools.repeat('a', times=sig.parameters['times'].default) a & b & c can and should be interchangebly. b & c, yeah, should be interchangeably. But not a. a is a special case. Of course, if we were to design this function from scratch again, we should make a & b & c interchangeably. That is the ideal case. We should be able to send default value explicitly and manually. But we are in beta phase. Can we alter the behaviour in this phase? But if we have to make a & b & c interchangeably in Python 3.4 (for philosophical or pragmatic reason), I think None is sensible default value, and your nullable-int patch works in this case. And I think we need to get approval from Raymond Hettinger. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 07:07:20 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sat, 25 Jan 2014 06:07:20 +0000 Subject: [issue20177] Derby #8: Convert 28 sites to Argument Clinic across 2 files In-Reply-To: <1389138574.32.0.892814928986.issue20177@psf.upfronthosting.co.za> Message-ID: <1390630040.59.0.00516212719455.issue20177@psf.upfronthosting.co.za> Nikolaus Rath added the comment: (I already sent this to python-dev, but maybe it makes more sense to have these thoughts together with the patch) After looking at the conversion of parse_time_t_args again, I think I lost track of what we're actually gaining with this procedure. If all we need is a type that can distinguish between a valid time_t value and a default value, why don't we simply use PyObject? In other words, what's the advantage of the extra custom strict, plus the custom C converter function, plus the custom converter python class over: static int PyObject_to_time_t(PyObject *obj, time_t *when) { if (obj == NULL || obj == Py_None) *when = time(NULL); else if (_PyTime_ObjectToTime_t(obj, when) == -1) return 0; return 1; } /*[clinic input] time.gmtime seconds: object=NULL / [...] static PyObject * time_gmtime_impl(PyModuleDef *module, PyObject *seconds) { PyObject *return_value = NULL; time_t when; if(!PyObj_to_time_t(seconds, &when)) return NULL; [...] To me this version looks shorter and clearer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 07:20:05 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jan 2014 06:20:05 +0000 Subject: [issue20381] Argument Clinic: expression default arguments broken In-Reply-To: <1390579377.01.0.888294922653.issue20381@psf.upfronthosting.co.za> Message-ID: <1390630805.61.0.359861999127.issue20381@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think we should specify globals (=sys.modules) and locals (=module.__dict__) arguments to eval. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 07:23:31 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jan 2014 06:23:31 +0000 Subject: [issue20381] Argument Clinic: expression default arguments broken In-Reply-To: <1390579377.01.0.888294922653.issue20381@psf.upfronthosting.co.za> Message-ID: <1390631011.44.0.467641530029.issue20381@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Hmm, no, we shouldn't use sys.modules, it's content is depended on modules used in Argument Clinic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 07:25:14 2014 From: report at bugs.python.org (Zachary Ware) Date: Sat, 25 Jan 2014 06:25:14 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1390631114.51.0.133782086789.issue20172@psf.upfronthosting.co.za> Changes by Zachary Ware : Added file: http://bugs.python.org/file33695/24b1121e7d48.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 07:26:53 2014 From: report at bugs.python.org (Zachary Ware) Date: Sat, 25 Jan 2014 06:26:53 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1390631213.26.0.969982965729.issue20172@psf.upfronthosting.co.za> Zachary Ware added the comment: Ok, v5 should be ready to go in, so long as you don't see anything scary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 07:43:51 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jan 2014 06:43:51 +0000 Subject: [issue19145] Inconsistent behaviour in itertools.repeat when using negative times In-Reply-To: <1380727396.47.0.412229295257.issue19145@psf.upfronthosting.co.za> Message-ID: <1390632231.01.0.709634510022.issue19145@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Vajrasky's last patch (v3) in general LGTM. I'm not sure about documentation changes, sample Python implementation is only a demonstration, it shouldn't be exact equivalent. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 08:01:22 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Jan 2014 07:01:22 +0000 Subject: [issue20386] Missing docs for SocketType and AddressFamily in socket module In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za> Message-ID: <1390633282.14.0.710655330852.issue20386@psf.upfronthosting.co.za> Nick Coghlan added the comment: Because that's the way enums work (http://docs.python.org/dev/library/enum): >>> import socket >>> list(socket.SocketType) [, , , , , , ] >>> list(socket.AddressFamily) [, , , , , , , , , , , , , , , , , , , , , , , , , , , ] Marking as a docs issue, since the fact that these are now enums should be covered in the socket module docs. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, ethan.furman, ncoghlan stage: -> needs patch title: socket.SocketType is different in Python 3.4 -> Missing docs for SocketType and AddressFamily in socket module type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 08:08:58 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Jan 2014 07:08:58 +0000 Subject: [issue20184] Derby #16: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140504.71.0.617730511292.issue20184@psf.upfronthosting.co.za> Message-ID: <1390633738.56.0.937115321525.issue20184@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'm going to specifically tackle the "bltinmodule" side of things using a test driven approach: adding a new test to test_inspect that checks all the builtin names have signatures (I'll explicitly exclude ones that are known not to be handled, like range and slice). ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 08:12:49 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 25 Jan 2014 07:12:49 +0000 Subject: [issue20381] Argument Clinic: expression default arguments broken In-Reply-To: <1390579377.01.0.888294922653.issue20381@psf.upfronthosting.co.za> Message-ID: <1390633969.69.0.460910482177.issue20381@psf.upfronthosting.co.za> Larry Hastings added the comment: Right. So my advice is: only use local symbols and symbols in preloaded modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 08:45:36 2014 From: report at bugs.python.org (Georg Brandl) Date: Sat, 25 Jan 2014 07:45:36 +0000 Subject: [issue20386] Missing docs for SocketType and AddressFamily in socket module In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za> Message-ID: <1390635936.18.0.0737642178757.issue20386@psf.upfronthosting.co.za> Georg Brandl added the comment: Um... changing the name "socket.SocketType" from type(socket) to an enum of SOCK_ constants is not a docs issue, but a regression. Eli, you introduced this change (inadvertently, I think, which can easily happen since SocketType is imported by "*" from _socket). Please find a better name for the type enum and document the new enums. ---------- assignee: docs at python -> eli.bendersky nosy: +eli.bendersky, georg.brandl priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 08:49:18 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Jan 2014 07:49:18 +0000 Subject: [issue20386] Missing docs for SocketType and AddressFamily in socket module In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za> Message-ID: <1390636158.8.0.990095342557.issue20386@psf.upfronthosting.co.za> Nick Coghlan added the comment: Sorry, I misread Giampaolo's example as indicating that socket.SocketType wasn't there at all in Python 3.3. However, it's there, and with the same name as in Python 2, so I agree this is a regression. I suggest socket.SocketKind as an alternate name for the enumeration that avoids the name clash, but we also need a test case that ensures that socket.SocketType has the correct value. ---------- components: +Library (Lib) -Documentation keywords: +3.4regression stage: needs patch -> test needed type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 08:52:28 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Jan 2014 07:52:28 +0000 Subject: [issue20386] socket.SocketType enum overwrites import of _socket.SocketType In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za> Message-ID: <1390636348.19.0.615618299207.issue20386@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- title: Missing docs for SocketType and AddressFamily in socket module -> socket.SocketType enum overwrites import of _socket.SocketType _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 09:03:40 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Jan 2014 08:03:40 +0000 Subject: [issue20330] PEP 342 is outdated In-Reply-To: <1390316892.04.0.132074086139.issue20330@psf.upfronthosting.co.za> Message-ID: <1390637020.22.0.200302460896.issue20330@psf.upfronthosting.co.za> Nick Coghlan added the comment: David is correct, most PEPs are historical records of design decisions that cease to be updated once completed. The language reference is the normative guide for current behaviour. The exception is "informational" and "process" PEPs, which cover things that are not covered in the language reference, as well the occasional Standards Track PEP which ends up not being incorporated into the language reference properly (for example, until the import section was added to the language reference in Python 3.3, PEP 302 was the best available reference documentation). ---------- nosy: +ncoghlan resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 09:06:40 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Jan 2014 08:06:40 +0000 Subject: [issue20317] ExitStack hang if enough nested exceptions In-Reply-To: <1390248489.02.0.0980821300277.issue20317@psf.upfronthosting.co.za> Message-ID: <1390637200.98.0.696734959721.issue20317@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 09:09:08 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Jan 2014 08:09:08 +0000 Subject: [issue20075] help(open) eats first line In-Reply-To: <1388090120.87.0.478863756961.issue20075@psf.upfronthosting.co.za> Message-ID: <1390637348.1.0.739224085097.issue20075@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- dependencies: +Argument Clinic should use a non-error-prone syntax to mark text signatures _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 09:10:34 2014 From: report at bugs.python.org (Georg Brandl) Date: Sat, 25 Jan 2014 08:10:34 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <1390637434.81.0.770456878996.issue20311@psf.upfronthosting.co.za> Georg Brandl added the comment: Since the test is still failing on at least 3 stable buildbots, I've reverted the 3.3 changes for 3.3.4rc1. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 09:30:02 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Jan 2014 08:30:02 +0000 Subject: [issue20264] Update patchcheck to looks for files with clinic comments In-Reply-To: <1389755559.69.0.925028805372.issue20264@psf.upfronthosting.co.za> Message-ID: <1390638602.24.0.942418240365.issue20264@psf.upfronthosting.co.za> Nick Coghlan added the comment: Having clinic work like reindent on "make patchcheck" would be very nice. As a second line of defence, we should also have a server side equivalent of the whitespace check as a repo hook in Mercurial (i.e. don't allow a push when clinic output is out of date). ---------- nosy: +ncoghlan, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 09:53:27 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jan 2014 08:53:27 +0000 Subject: [issue20388] Argument Clinic generates wrong signature for module level functions Message-ID: <1390640007.07.0.491459956475.issue20388@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Argument Clinic generates wrong signature for module level functions. For example for the following declaration /*[clinic input] binascii.a2b_uu ascii: ascii_buffer / Decode a line of uuencoded data. [clinic start generated code]*/ Argument Clinic generates PyDoc_STRVAR(binascii_a2b_uu__doc__, "a2b_uu(module, ascii)\n" "Decode a line of uuencoded data."); ---------- components: Demos and Tools messages: 209166 nosy: larry, serhiy.storchaka priority: normal severity: normal status: open title: Argument Clinic generates wrong signature for module level functions type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 09:53:48 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jan 2014 08:53:48 +0000 Subject: [issue20151] Derby: Convert the binascii module to use Argument Clinic In-Reply-To: <1389037748.15.0.70999359123.issue20151@psf.upfronthosting.co.za> Message-ID: <1390640028.2.0.767479834062.issue20151@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Argument Clinic generates wrong signature for module level functions _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 09:55:27 2014 From: report at bugs.python.org (Zachary Ware) Date: Sat, 25 Jan 2014 08:55:27 +0000 Subject: [issue20388] Argument Clinic generates wrong signature for module level functions In-Reply-To: <1390640007.07.0.491459956475.issue20388@psf.upfronthosting.co.za> Message-ID: <1390640127.61.0.762888199184.issue20388@psf.upfronthosting.co.za> Zachary Ware added the comment: That's by design (of #20189); inspect.Signature.from_builtin strips out the 'module' param. ---------- nosy: +zach.ware resolution: -> invalid status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 09:55:57 2014 From: report at bugs.python.org (Tal Einat) Date: Sat, 25 Jan 2014 08:55:57 +0000 Subject: [issue20385] Argument Clinic: Support for __new__ not checking _PyArg_NoKeywords for sub-classes In-Reply-To: <1390599341.47.0.747419262521.issue20385@psf.upfronthosting.co.za> Message-ID: <1390640157.66.0.483500345002.issue20385@psf.upfronthosting.co.za> Tal Einat added the comment: I've found two bugs: 1) In the type check, a '&' needs to be added before the type name. 2) Setting template_dict['self_type_object'] fails for module functions ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 10:00:17 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jan 2014 09:00:17 +0000 Subject: [issue20388] Argument Clinic generates wrong signature for module level functions In-Reply-To: <1390640007.07.0.491459956475.issue20388@psf.upfronthosting.co.za> Message-ID: <1390640417.22.0.351069500418.issue20388@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What if function already has the "module" parameter? E.g. _warnings.warn_explicit. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 10:01:38 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jan 2014 09:01:38 +0000 Subject: [issue20151] Derby: Convert the binascii module to use Argument Clinic In-Reply-To: <1389037748.15.0.70999359123.issue20151@psf.upfronthosting.co.za> Message-ID: <1390640498.93.0.254937384024.issue20151@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Argument Clinic: backslashes in docstrings are not escaped _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 10:03:23 2014 From: report at bugs.python.org (Tal Einat) Date: Sat, 25 Jan 2014 09:03:23 +0000 Subject: [issue20385] Argument Clinic: Support for __new__ not checking _PyArg_NoKeywords for sub-classes In-Reply-To: <1390599341.47.0.747419262521.issue20385@psf.upfronthosting.co.za> Message-ID: <1390640603.21.0.718159189654.issue20385@psf.upfronthosting.co.za> Tal Einat added the comment: Also, I believe the the type of the first argument passed to a method is a pointer to the typedef object, so a '*' needs to be added after the typedef name wherever it is used in such functions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 10:03:32 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jan 2014 09:03:32 +0000 Subject: [issue6083] Reference counting bug in PyArg_ParseTuple and PyArg_ParseTupleAndKeywords In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za> Message-ID: <1390640612.2.0.158062701172.issue6083@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 10:06:56 2014 From: report at bugs.python.org (Zachary Ware) Date: Sat, 25 Jan 2014 09:06:56 +0000 Subject: [issue20388] Argument Clinic doesn't handle module level functions with module parameter well In-Reply-To: <1390640007.07.0.491459956475.issue20388@psf.upfronthosting.co.za> Message-ID: <1390640816.07.0.0758296487036.issue20388@psf.upfronthosting.co.za> Zachary Ware added the comment: Ahh, that is a good point, though the real problem with that is in compilation rather than the Python signature. I believe there's a fix in the works, somewhere in Larry's to-do list. _winapi also has a function that takes a 'module' parameter, though being undocumented (and referring to a handle, not a Python module), I was able to just name that one 'module_handle'. ---------- resolution: invalid -> title: Argument Clinic generates wrong signature for module level functions -> Argument Clinic doesn't handle module level functions with module parameter well _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 10:14:10 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jan 2014 09:14:10 +0000 Subject: [issue20376] Argument Clinic: backslashes in docstrings are not escaped In-Reply-To: <1390551719.55.0.676646267319.issue20376@psf.upfronthosting.co.za> Message-ID: <1390641250.93.0.796505672353.issue20376@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- assignee: -> zach.ware stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 10:22:14 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 Jan 2014 09:22:14 +0000 Subject: [issue20151] Derby: Convert the binascii module to use Argument Clinic In-Reply-To: <1389037748.15.0.70999359123.issue20151@psf.upfronthosting.co.za> Message-ID: <3fBBZF6h85zSSJ@mail.python.org> Roundup Robot added the comment: New changeset 21f8abfe459a by Serhiy Storchaka in branch 'default': Issue #20151: The binascii module now uses Argument Clinic. http://hg.python.org/cpython/rev/21f8abfe459a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 10:26:33 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 Jan 2014 09:26:33 +0000 Subject: [issue20376] Argument Clinic: backslashes in docstrings are not escaped In-Reply-To: <1390551719.55.0.676646267319.issue20376@psf.upfronthosting.co.za> Message-ID: <3fBBgF1thZz7Lmb@mail.python.org> Roundup Robot added the comment: New changeset 381c9d592cc8 by Zachary Ware in branch 'default': Issue #20376: Argument Clinic now escapes backslashes in docstrings. http://hg.python.org/cpython/rev/381c9d592cc8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 10:27:02 2014 From: report at bugs.python.org (Zachary Ware) Date: Sat, 25 Jan 2014 09:27:02 +0000 Subject: [issue20376] Argument Clinic: backslashes in docstrings are not escaped In-Reply-To: <1390551719.55.0.676646267319.issue20376@psf.upfronthosting.co.za> Message-ID: <1390642022.85.0.339865394839.issue20376@psf.upfronthosting.co.za> Zachary Ware added the comment: Done! ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 10:36:03 2014 From: report at bugs.python.org (Tal Einat) Date: Sat, 25 Jan 2014 09:36:03 +0000 Subject: [issue20385] Argument Clinic: Support for __new__ not checking _PyArg_NoKeywords for sub-classes In-Reply-To: <1390599341.47.0.747419262521.issue20385@psf.upfronthosting.co.za> Message-ID: <1390642563.4.0.0184765631924.issue20385@psf.upfronthosting.co.za> Tal Einat added the comment: My last comment was wrong. There is a bug regarding the first argument to new methods; It should just remain a PyTypeObject*. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 10:38:44 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 25 Jan 2014 09:38:44 +0000 Subject: [issue20385] Argument Clinic: Support for __new__ not checking _PyArg_NoKeywords for sub-classes In-Reply-To: <1390599341.47.0.747419262521.issue20385@psf.upfronthosting.co.za> Message-ID: <1390642724.1.0.436928888111.issue20385@psf.upfronthosting.co.za> Larry Hastings added the comment: 1) That's not a bug, that's the API. If you used the dynamic API to create a type it wouldn't take the &. So I can't guess in advance what type it is, nor can I assume I always add the &. 2) Will fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 10:40:10 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 25 Jan 2014 09:40:10 +0000 Subject: [issue20388] Argument Clinic doesn't handle module level functions with module parameter well In-Reply-To: <1390640007.07.0.491459956475.issue20388@psf.upfronthosting.co.za> Message-ID: <1390642810.0.0.132527738117.issue20388@psf.upfronthosting.co.za> Larry Hastings added the comment: If you use a self converter you can name your first parameter anything you like. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 10:44:24 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Jan 2014 09:44:24 +0000 Subject: [issue20184] Derby #16: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140504.71.0.617730511292.issue20184@psf.upfronthosting.co.za> Message-ID: <1390643064.29.0.168674179186.issue20184@psf.upfronthosting.co.za> Nick Coghlan added the comment: Attached patch shows the new test case I'm using to ensure that all callable builtins have signatures, and once we get it that way, it stays that way. Preliminary goal is signatures for all the non-type objects, and once I get to that point, I'll propose it for review. ---------- keywords: +patch Added file: http://bugs.python.org/file33696/issue20184_builtin_conversion.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 10:49:56 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 Jan 2014 09:49:56 +0000 Subject: [issue20151] Derby: Convert the binascii module to use Argument Clinic In-Reply-To: <1389037748.15.0.70999359123.issue20151@psf.upfronthosting.co.za> Message-ID: <3fBCBC4Zl9zS9B@mail.python.org> Roundup Robot added the comment: New changeset 76a3cc6f3aca by Serhiy Storchaka in branch 'default': Fixed converting errors in the binascii module (issue20151). http://hg.python.org/cpython/rev/76a3cc6f3aca ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 10:58:14 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 Jan 2014 09:58:14 +0000 Subject: [issue20133] Derby: Convert the audioop module to use Argument Clinic In-Reply-To: <1388956864.17.0.114751586443.issue20133@psf.upfronthosting.co.za> Message-ID: <3fBCMp0rt6z7LjP@mail.python.org> Roundup Robot added the comment: New changeset d4099b8a7d0f by Serhiy Storchaka in branch 'default': Issue #20133: The audioop module now uses Argument Clinic. http://hg.python.org/cpython/rev/d4099b8a7d0f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 11:00:29 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jan 2014 10:00:29 +0000 Subject: [issue20151] Derby: Convert the binascii module to use Argument Clinic In-Reply-To: <1389037748.15.0.70999359123.issue20151@psf.upfronthosting.co.za> Message-ID: <1390644029.38.0.110569100412.issue20151@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: -Argument Clinic doesn't handle module level functions with module parameter well resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 11:01:08 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jan 2014 10:01:08 +0000 Subject: [issue20133] Derby: Convert the audioop module to use Argument Clinic In-Reply-To: <1388956864.17.0.114751586443.issue20133@psf.upfronthosting.co.za> Message-ID: <1390644068.36.0.829042800076.issue20133@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 11:06:31 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 25 Jan 2014 10:06:31 +0000 Subject: [issue20388] Argument Clinic doesn't handle module level functions with module parameter well In-Reply-To: <1390640007.07.0.491459956475.issue20388@psf.upfronthosting.co.za> Message-ID: <1390644391.47.0.799426563178.issue20388@psf.upfronthosting.co.za> Larry Hastings added the comment: So, are you still claiming there's a bug here? Or can we close this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 11:08:02 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 Jan 2014 10:08:02 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <3fBCb50mCrzMfZ@mail.python.org> Roundup Robot added the comment: New changeset 0a3e02251bd6 by Serhiy Storchaka in branch 'default': Issue #20193: The _bz2 module now uses Argument Clinic. http://hg.python.org/cpython/rev/0a3e02251bd6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 11:17:35 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jan 2014 10:17:35 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1390645055.46.0.45543670342.issue20193@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Nadeem. In committed patch fixed the docstring for BZ2Compressor.__init__, and renamed module name "bz2" in clinic declaration is renamed to "_bz2". Here is updated patch for the _lzma module which addresses Nadeem's comment and renames the "lzma" module name to "_lzma". Unfortunately this patch is incompatible with current Argument Clinic because it uses "unspecified" default value. Default value of the "check" parameter in LZMACompressor.__init__ depends on the value of other parameter. """For FORMAT_XZ, the default is CHECK_CRC64. FORMAT_ALONE and FORMAT_RAW do not suport integrity checks; for these formats, check must be omitted, or be CHECK_NONE.""" ---------- Added file: http://bugs.python.org/file33697/lzma_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 11:37:24 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 25 Jan 2014 10:37:24 +0000 Subject: [issue19145] Inconsistent behaviour in itertools.repeat when using negative times In-Reply-To: <1380727396.47.0.412229295257.issue19145@psf.upfronthosting.co.za> Message-ID: <1390646244.77.0.923236761437.issue19145@psf.upfronthosting.co.za> Larry Hastings added the comment: The logic of the patch is hard to follow. However, it's still examining the size of args, and now it's examining the size of kwargs, and behaving differently based on these sizes is exactly what I don't want. I've attached an example patch of how I would change itertools.repeat if I were doing it today, without the benefit of Argument Clinic. If that approach seems reasonable, maybe we can redo it with Argument Clinic and get a signature too. ---------- Added file: http://bugs.python.org/file33698/larry.sample.itertools.repeat.patch.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 11:45:10 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 25 Jan 2014 10:45:10 +0000 Subject: [issue20348] Argument Clinic HOWTO listed multiple times in HOWTO index In-Reply-To: <1390408747.92.0.288062862329.issue20348@psf.upfronthosting.co.za> Message-ID: <1390646710.56.0.377184907044.issue20348@psf.upfronthosting.co.za> Larry Hastings added the comment: You should only put one line of equals signs? I'll try to remember that in the future. LGTM. Shall I commit it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 11:46:46 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 25 Jan 2014 10:46:46 +0000 Subject: [issue20346] Argument Clinic: missing entry in table mapping legacy convertors to real AC converters In-Reply-To: <1390405621.79.0.727900748758.issue20346@psf.upfronthosting.co.za> Message-ID: <1390646806.81.0.0530981359629.issue20346@psf.upfronthosting.co.za> Larry Hastings added the comment: If two issues are created on the tracker for the same issue, surely it's the *older* issue that is preserved, and the new one marked as duplicate and closed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 11:51:59 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jan 2014 10:51:59 +0000 Subject: [issue20388] Argument Clinic doesn't handle module level functions with module parameter well In-Reply-To: <1390640007.07.0.491459956475.issue20388@psf.upfronthosting.co.za> Message-ID: <1390647119.53.0.946520506541.issue20388@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Well, if originally reported behavior is by design, and there is other open issue for the "module" parameter, we can close this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 11:53:17 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 25 Jan 2014 10:53:17 +0000 Subject: [issue20388] Argument Clinic doesn't handle module level functions with module parameter well In-Reply-To: <1390640007.07.0.491459956475.issue20388@psf.upfronthosting.co.za> Message-ID: <1390647197.27.0.92858917095.issue20388@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 13:02:36 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 Jan 2014 12:02:36 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <3fBG7H4ZMXz7LkF@mail.python.org> Roundup Robot added the comment: New changeset 7ba9642fc800 by Serhiy Storchaka in branch 'default': Issue #20193: The _lzma module now uses Argument Clinic. http://hg.python.org/cpython/rev/7ba9642fc800 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 13:12:49 2014 From: report at bugs.python.org (Georg Brandl) Date: Sat, 25 Jan 2014 12:12:49 +0000 Subject: [issue20346] Argument Clinic: missing entry in table mapping legacy convertors to real AC converters In-Reply-To: <1390405621.79.0.727900748758.issue20346@psf.upfronthosting.co.za> Message-ID: <1390651969.9.0.270038457577.issue20346@psf.upfronthosting.co.za> Georg Brandl added the comment: Only if the older issue actually has more relevant content, which is not always the case. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 13:34:04 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jan 2014 12:34:04 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1390653244.07.0.284140389967.issue20193@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Patch for _lzma was applied without converting LZMACompressor.__init__. Here is a patch for zlib, which doesn't use neither optional groups, nor "unspecified" defaults. Three builtins, decompress(), decompressobj() and Decompress.flush() are left not converted. ---------- stage: -> patch review Added file: http://bugs.python.org/file33699/zlib_clinic_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 13:37:20 2014 From: report at bugs.python.org (Julian Taylor) Date: Sat, 25 Jan 2014 12:37:20 +0000 Subject: [issue20389] clarify meaning of xbar and mu in pvariance/variance of statistics module Message-ID: <1390653440.27.0.247965137131.issue20389@psf.upfronthosting.co.za> New submission from Julian Taylor: the pvariance and variance functions take the argument mu and xbar to pass the population and sample mean to avoid some recomputation. I assume the keyword arguments are different because the two means accepted are different, but the docstring does not indicate this directly. It just says mu or xbar is the mean of the data. The module documentation is a little clearer but only in the grey box right at the end. I would propose to change the docstring and module documentation to explicitly state that mu is the population mean and xbar is the population mean. E.g. - The optional argument mu, if given, should be the mean of the data. + The optional argument mu, if given, should be the population mean of the data. etc. ---------- messages: 209192 nosy: jtaylor priority: normal severity: normal status: open title: clarify meaning of xbar and mu in pvariance/variance of statistics module versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 13:39:05 2014 From: report at bugs.python.org (Julian Taylor) Date: Sat, 25 Jan 2014 12:39:05 +0000 Subject: [issue20389] clarify meaning of xbar and mu in pvariance/variance of statistics module In-Reply-To: <1390653440.27.0.247965137131.issue20389@psf.upfronthosting.co.za> Message-ID: <1390653545.67.0.711247987856.issue20389@psf.upfronthosting.co.za> Julian Taylor added the comment: xbar is the *sample* mean of course maybe with proper docstrings the two functions could also use the same keyword argument? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 13:48:44 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jan 2014 12:48:44 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1390654124.43.0.382157049213.issue20193@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file33699/zlib_clinic_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 13:49:34 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jan 2014 12:49:34 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1390654174.68.0.293726477273.issue20193@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry, previous patch didn't contain generated file. ---------- Added file: http://bugs.python.org/file33700/zlib_clinic_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 13:58:03 2014 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 25 Jan 2014 12:58:03 +0000 Subject: [issue19145] Inconsistent behaviour in itertools.repeat when using negative times In-Reply-To: <1380727396.47.0.412229295257.issue19145@psf.upfronthosting.co.za> Message-ID: <1390654683.42.0.00151306754647.issue19145@psf.upfronthosting.co.za> Mark Lawrence added the comment: msg209063 from Larry states "My concern is that itertools.repeat doesn't parse its arguments like other Python functions." From my viewpoint the only long term option is to bring repeat (and other functions that you may have found exhibiting this behaviour during the AC process) into line with other Python functions. If that means a deprecation period and not being able to use AC in the short term so be it, or have I again misunderstood the technical aspects that you've already discussed, in which case you can all give me a good kicking? :) ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 14:20:23 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 25 Jan 2014 13:20:23 +0000 Subject: [issue19145] Inconsistent behaviour in itertools.repeat when using negative times In-Reply-To: <1380727396.47.0.412229295257.issue19145@psf.upfronthosting.co.za> Message-ID: <1390656023.12.0.169481425398.issue19145@psf.upfronthosting.co.za> Larry Hastings added the comment: I think you've understood it. The problem is, in order to deprecate the behavior, we first must provide the new behavior. (That's official policy, in PEP 5.) It's untenable to say "you'll have to stop using 'times=-1' in the future, but you can't use 'times=None' yet". And right now I'm pretty sure we shouldn't add "times=None" for 3.4. Therefore, we can't even deprecate the old behavior yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 14:40:46 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 Jan 2014 13:40:46 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <3fBJJX6r1cz7LjS@mail.python.org> Roundup Robot added the comment: New changeset 900a1ff323bb by Victor Stinner in branch '3.3': Issue #20311: Revert 033137c12d88, select.epoll.poll() rounds again the timeout http://hg.python.org/cpython/rev/900a1ff323bb New changeset caab3e191485 by Victor Stinner in branch 'default': (Merge 3.3) Issue #20311: Revert 033137c12d88 (02f9db3e684e), http://hg.python.org/cpython/rev/caab3e191485 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 14:44:31 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 Jan 2014 13:44:31 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <3fBJNt3FWFz7LlV@mail.python.org> Roundup Robot added the comment: New changeset 90354a4c9dde by Victor Stinner in branch 'default': Issue #20311: Revert e042ea77a152 and 7ce7295393c2, PollSelector.select() and http://hg.python.org/cpython/rev/90354a4c9dde ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 15:02:55 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 Jan 2014 14:02:55 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <3fBJp53r28z7LjP@mail.python.org> Roundup Robot added the comment: New changeset 3b8a2281d323 by Victor Stinner in branch 'default': Issue #20311: selectors: Add a resolution attribute to BaseSelector. http://hg.python.org/cpython/rev/3b8a2281d323 New changeset 4bc550c66228 by Victor Stinner in branch 'default': Issue #20311: asyncio: Add a granularity attribute to BaseEventLoop: maximum http://hg.python.org/cpython/rev/4bc550c66228 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 15:42:16 2014 From: report at bugs.python.org (STINNER Victor) Date: Sat, 25 Jan 2014 14:42:16 +0000 Subject: [issue20320] select.select(timeout) and select.kqueue.control(timeout) must round the timeout to the upper bound In-Reply-To: <1390264456.23.0.80941463403.issue20320@psf.upfronthosting.co.za> Message-ID: <1390660936.73.0.836825238422.issue20320@psf.upfronthosting.co.za> STINNER Victor added the comment: I reverted my changes on poll and epoll: the kernel may "round" the timeout differently because it uses a different clock, so Python cannot guarantee that it will wait "at least" timeout seconds. My initial concern was a performance issue in asyncio, I fixed the issue differently: see issue #20311. ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 15:44:28 2014 From: report at bugs.python.org (STINNER Victor) Date: Sat, 25 Jan 2014 14:44:28 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <1390661068.01.0.584579425498.issue20311@psf.upfronthosting.co.za> STINNER Victor added the comment: I revert all changes in select an selectors, the timeout is rounded again towards zero, as it was before. I applied my asyncio_granularity.patch: - selectors.BaseSelector has a new abstract "resolution" property - asyncio.BaseEventLoop has a new granularity attribute which is used in _run_once() to round timings I don't like hurry to push changes without review, but I wanted to revert my changes on select and selectors and fix the issue in asyncio issue before Python 3.4 beta 3. I'm now waiting for buildbots. Don't hesitate to review my changes on selectors (new resolution attribute) and asyncio (new granularity attribute). For selectors, I chose an abstract attribute to ensure that the resolution is defined in subclasses of BaseSelector and because it does not make sense to modify the resolution. For asyncio, it's a classic attribute because a subclass may want to adjust the granularity if it overrides the time() method, or for other reasons. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 16:07:55 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 25 Jan 2014 15:07:55 +0000 Subject: [issue20325] Argument Clinic: self converters are not preserved when cloning functions In-Reply-To: <1390298486.22.0.452185457734.issue20325@psf.upfronthosting.co.za> Message-ID: <1390662475.77.0.0688105156547.issue20325@psf.upfronthosting.co.za> Larry Hastings added the comment: You didn't give me a test case, and I can't reproduce this. Either it was accidentally fixed already, or there's something else going on in your test case. I'm closing this for now as unreproducable. If you see the problem again, please reopen this issue. ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 16:12:40 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Jan 2014 15:12:40 +0000 Subject: [issue20184] Derby #16: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140504.71.0.617730511292.issue20184@psf.upfronthosting.co.za> Message-ID: <1390662760.28.0.808455899531.issue20184@psf.upfronthosting.co.za> Nick Coghlan added the comment: More comprehensive patch uploaded - all the non-type callables implemented in bltinmodule.c have been converted or classified with a reason for not being converted yet (see the new test in test_inspect.py for details, as well as the AC 3.4 and AC 3.5 comments in the module itself). I also cleaned up the docstrings for the builtins I actually changed in the patch. There were a few that had never been properly updated for the Py3k transition. There are still a couple of test failures with this version - the doctest tests get confused by the fact ord and chr now have a doctest in their docstrings, and test_gdb is definitely not in a happy place (that has always been temperamental, though). I also just realised the Unicode character in the new ord and chr docstrings could pose a compatibility problem at the C compiler source encoding level, so we may have to reconsider that (even though I was rather happy to sneak that obscure Monty Python reference in there). ---------- Added file: http://bugs.python.org/file33701/issue20184_builtin_conversion_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 16:28:28 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 Jan 2014 15:28:28 +0000 Subject: [issue20348] Argument Clinic HOWTO listed multiple times in HOWTO index In-Reply-To: <1390408747.92.0.288062862329.issue20348@psf.upfronthosting.co.za> Message-ID: <3fBLhp1t0Dz7Llg@mail.python.org> Roundup Robot added the comment: New changeset 1eec62cf3675 by Ezio Melotti in branch 'default': #20348: fix headers markup in Argument Clinic howto. Patch by Moritz Neeb. http://hg.python.org/cpython/rev/1eec62cf3675 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 16:28:47 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 25 Jan 2014 15:28:47 +0000 Subject: [issue20390] Argument Clinic rollup patch, 2014/01/25 Message-ID: <1390663726.3.0.8274031742.issue20390@psf.upfronthosting.co.za> New submission from Larry Hastings: Rollup patch with a bunch of small fixes in it. Can I get a quick turnaround review on this? I'd like it to go in before today's beta is cut. Definitely the core change has to go in, but that's uncontroversial. Core: * _PyType_GetDocFromInternalDoc() and _PyType_GetTextSignatureFromInternalDoc() are now marked Py_LIMITED_API. Tools: * The default filename for the "file" preset is now: "clinic/{filename}.h". * The "class" directive syntax has been extended with two new required arguments: "typedef" and "type_object". "typedef" should be the equivalent C type for this Python class, presented as a pointer-to-type. "type_object" should be an expression that evaluates to a PyTypeObject * for this Python type. Example: class dict "PyDictObject *" "&PyDict_Type" This was necessary for the next item. * If __new__ or __init__ functions did not use kwargs (or args), the PyArg_NoKeywords (or PyArg_NoPositional) calls generated are only run if the type object is an exact match. (Otherwise subclasses will not be allowed to start accepting those kinds of arguments.) * Argument Clinic now fails if you have required parameters after optional parameters. * Converters now have a new template they can inject code into: it's called "modifiers", and code put there is run in the parsing function after argument parsing but before the call to the impl. "modifiers" is intended for converters that may want dynamic default values. An example string you might add: "if ({name} == NULL)\n name = time(NULL);" ---------- assignee: larry components: Demos and Tools files: larry.clinic.rollup.jan.25.diff.1.txt messages: 209205 nosy: larry, ncoghlan, serhiy.storchaka, zach.ware priority: normal severity: normal stage: patch review status: open title: Argument Clinic rollup patch, 2014/01/25 type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file33702/larry.clinic.rollup.jan.25.diff.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 16:29:04 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 25 Jan 2014 15:29:04 +0000 Subject: [issue20348] Argument Clinic HOWTO listed multiple times in HOWTO index In-Reply-To: <1390408747.92.0.288062862329.issue20348@psf.upfronthosting.co.za> Message-ID: <1390663744.14.0.949510750226.issue20348@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! ---------- assignee: larry -> ezio.melotti nosy: +ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 16:30:47 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 25 Jan 2014 15:30:47 +0000 Subject: [issue20385] Argument Clinic: Support for __new__ not checking _PyArg_NoKeywords for sub-classes In-Reply-To: <1390599341.47.0.747419262521.issue20385@psf.upfronthosting.co.za> Message-ID: <1390663847.44.0.491331142961.issue20385@psf.upfronthosting.co.za> Larry Hastings added the comment: The bug you cited is fixed in today's rollup patch, #20390. (I don't know how to denote the dependency between the two issues, maybe someone else can do that for me?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 16:31:26 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 25 Jan 2014 15:31:26 +0000 Subject: [issue20231] Argument Clinic accepts no-default args after default args In-Reply-To: <1389580315.91.0.810075963733.issue20231@psf.upfronthosting.co.za> Message-ID: <1390663886.45.0.259432656776.issue20231@psf.upfronthosting.co.za> Larry Hastings added the comment: The bug you cited is fixed in today's rollup patch, #20390. (I don't know how to denote the dependency between the two issues, maybe someone else can do that for me?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 16:39:17 2014 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 25 Jan 2014 15:39:17 +0000 Subject: [issue19145] Inconsistent behaviour in itertools.repeat when using negative times In-Reply-To: <1380727396.47.0.412229295257.issue19145@psf.upfronthosting.co.za> Message-ID: <1390664357.76.0.203531465324.issue19145@psf.upfronthosting.co.za> Mark Lawrence added the comment: >From a user perspective the docs say this "itertools.repeat(object[, times]) - Make an iterator that returns object over and over again. Runs indefinitely unless the times argument is specified." So to me the use of "Times=None" in the "equivalent to" section is simply a red herring, as the user often won't bother reading this and certainly won't see it from interactive help. As for negative times values I'd say leave it as is, although it someone was to suggest deprecating this behaviour and raising a ValueError instead I'd have no objections. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 16:47:33 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Jan 2014 15:47:33 +0000 Subject: [issue20390] Argument Clinic rollup patch, 2014/01/25 In-Reply-To: <1390663726.3.0.8274031742.issue20390@psf.upfronthosting.co.za> Message-ID: <1390664853.26.0.784314421789.issue20390@psf.upfronthosting.co.za> Nick Coghlan added the comment: LGTM, but I'm not familiar with Clinic's own code... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 16:52:55 2014 From: report at bugs.python.org (Adam Knight) Date: Sat, 25 Jan 2014 15:52:55 +0000 Subject: [issue19023] ctypes docs: Unimplemented and undocumented features In-Reply-To: <1379246270.23.0.998338553474.issue19023@psf.upfronthosting.co.za> Message-ID: <1390665175.39.0.611287740261.issue19023@psf.upfronthosting.co.za> Adam Knight added the comment: Can someone add this in? What needs to be done to make it happen? Kind of need this for a project I'm working on... ---------- nosy: +ahknight _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 17:03:20 2014 From: report at bugs.python.org (Tal Einat) Date: Sat, 25 Jan 2014 16:03:20 +0000 Subject: [issue20325] Argument Clinic: self converters are not preserved when cloning functions In-Reply-To: <1390298486.22.0.452185457734.issue20325@psf.upfronthosting.co.za> Message-ID: <1390665800.56.0.714677718524.issue20325@psf.upfronthosting.co.za> Tal Einat added the comment: You're right, this issue does indeed seem to have been resolved since I created this issue. I just checked this on Objects/bytesobject.c with the latest version and get the desired output. So you've done right to close this issue. I'd like to note that I most certainly did supply a way to reproduce this issue! I described it precisely and concisely. Consider, also, that I was only asking if this is a bug since I wasn't sure. If someone had replied "this sounds like a bug, please supply code for which reproduces this" then I would have supplied such code. Just to be sure, I just checked this again with clinic.py from revision 88635:fbc31e0b0c77 (Tue Jan 21, the day I reported this issue) and I get precisely the behavior I described. So the issue did exist at the time when I reported it and the test case I supplied is sound. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 17:04:04 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 25 Jan 2014 16:04:04 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390557889.63.0.375947112319.issue20311@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > If the patch is accepted, my changes on Python 3.3 should also be reverted. I'm sorry, but I'm not convinced. The selector's granularity is an implementation detail, and I don't think it should be exposed. Furthermore, it's not a mere function of the C type used to represent the timeout to the underlying syscall (long, timeval): it also depends on the operating system, the hardware, etc. Once again, what's wrong with your initial approach of ceiling the timeout? It does seem reasonable to round away from zero, to ensure - not taking OS bugs/limitations - that select() will wait at least the passed timeout. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 17:05:51 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 25 Jan 2014 16:05:51 +0000 Subject: [issue20325] Argument Clinic: self converters are not preserved when cloning functions In-Reply-To: <1390298486.22.0.452185457734.issue20325@psf.upfronthosting.co.za> Message-ID: <1390665951.6.0.909488883561.issue20325@psf.upfronthosting.co.za> Larry Hastings added the comment: You didn't supply a test case, nor is there any code checked in that reproduced the issue. I had to make a test case by hand. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 17:18:17 2014 From: report at bugs.python.org (Thomas Heller) Date: Sat, 25 Jan 2014 16:18:17 +0000 Subject: [issue20391] windows python launcher should support explicit 64-bit version Message-ID: <1390666697.34.0.8179359034.issue20391@psf.upfronthosting.co.za> New submission from Thomas Heller: The windows python launcher supports the '-3.3' resp. '-3.3-32' command line switches to ask for 'the best 3.3' version resp. 'the 32-bit 3.3' version, but does not support a '-3.3-64' switch to explicitely request the 64-bit version of Python. I suggest that this support should be added. ---------- messages: 209215 nosy: theller priority: normal severity: normal status: open title: windows python launcher should support explicit 64-bit version type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 17:29:00 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jan 2014 16:29:00 +0000 Subject: [issue20390] Argument Clinic rollup patch, 2014/01/25 In-Reply-To: <1390663726.3.0.8274031742.issue20390@psf.upfronthosting.co.za> Message-ID: <1390667340.53.0.494069245989.issue20390@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Don't forget to use "hg mv" to rename existing side files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 17:29:28 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 25 Jan 2014 16:29:28 +0000 Subject: [issue20331] Fix various fd leaks In-Reply-To: <1390321074.97.0.506126100474.issue20331@psf.upfronthosting.co.za> Message-ID: <1390667368.18.0.12013447289.issue20331@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: LGTM. ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 17:30:13 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jan 2014 16:30:13 +0000 Subject: [issue20331] Fix various fd leaks In-Reply-To: <1390321074.97.0.506126100474.issue20331@psf.upfronthosting.co.za> Message-ID: <1390667413.81.0.120195029969.issue20331@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 18:17:48 2014 From: report at bugs.python.org (Rodrigo Parra) Date: Sat, 25 Jan 2014 17:17:48 +0000 Subject: [issue20392] Inconsistency with uppercase file extensions in MimeTypes.guess_type Message-ID: <1390670268.05.0.579524422182.issue20392@psf.upfronthosting.co.za> New submission from Rodrigo Parra: The functions looks up for the file extension in three maps: types_map, suffix_map and encodings_map. Lookup in types_map is case insensitive (by calling lower() first). Lookup in both suffix_map and encodings_map is case sensitive. These can lead to some seemingly counterintuitive results, like: a) guess_type("foo.tar") == ("application/x-tar", None) guess_type("foo.TAR") == ("application/x-tar", None) b) guess_type("foo.tgz") == ("application/x-tar", "gzip") guess_type("foo.TGZ") == (None, None) c) guess_type("foo.tar.gz") == ("application/x-tar", "gzip") guess_type("foo.TAR.GZ") == (None, None) Lookup should be case insensitive at least for the suffix_map, in which case (b) would be solved. The submitted patch implements this change. As for the encodings_map, I am not so sure, in particular because of the tar.Z extension. I found that the compress command expects the uppercase 'Z'. If someone is relying in the results of guess_type to call compress, errors could occur. ---------- components: Library (Lib) files: case_guess_type.patch keywords: patch messages: 209218 nosy: Rodrigo.Parra, tim.golden priority: normal severity: normal status: open title: Inconsistency with uppercase file extensions in MimeTypes.guess_type type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file33703/case_guess_type.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 18:26:50 2014 From: report at bugs.python.org (Tal Einat) Date: Sat, 25 Jan 2014 17:26:50 +0000 Subject: [issue20385] Argument Clinic: Support for __new__ not checking _PyArg_NoKeywords for sub-classes In-Reply-To: <1390599341.47.0.747419262521.issue20385@psf.upfronthosting.co.za> Message-ID: <1390670810.31.0.965855407394.issue20385@psf.upfronthosting.co.za> Tal Einat added the comment: I'm still seeing the first argument to a __new__ function as "groupbyobject *" instead of "PyTypeObject *". This causes the following error (for example): ./Modules/itertoolsmodule.c:112:34: error: no member named 'tp_alloc' in 'groupbyobject' gbo = (groupbyobject *)type->tp_alloc(type, 0); ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 18:28:44 2014 From: report at bugs.python.org (Tal Einat) Date: Sat, 25 Jan 2014 17:28:44 +0000 Subject: [issue20385] Argument Clinic: Support for __new__ not checking _PyArg_NoKeywords for sub-classes In-Reply-To: <1390599341.47.0.747419262521.issue20385@psf.upfronthosting.co.za> Message-ID: <1390670924.67.0.645626118338.issue20385@psf.upfronthosting.co.za> Tal Einat added the comment: To clarify my previous comment, I was referring to the first argument passed to the generated 'impl' function. Context: I'm attempting to convert 'itertools.groupby' in Modules/itertoolsmodule.c. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 18:33:08 2014 From: report at bugs.python.org (Tal Einat) Date: Sat, 25 Jan 2014 17:33:08 +0000 Subject: [issue20385] Argument Clinic: Support for __new__ not checking _PyArg_NoKeywords for sub-classes In-Reply-To: <1390599341.47.0.747419262521.issue20385@psf.upfronthosting.co.za> Message-ID: <1390671188.97.0.43476891684.issue20385@psf.upfronthosting.co.za> Tal Einat added the comment: Also, I'm seeing this in the generated code for __new__ methods: if (({self_name} == {self_type_object}) && ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 18:43:00 2014 From: report at bugs.python.org (Tal Einat) Date: Sat, 25 Jan 2014 17:43:00 +0000 Subject: [issue20385] Argument Clinic: Support for __new__ not checking _PyArg_NoKeywords for sub-classes In-Reply-To: <1390599341.47.0.747419262521.issue20385@psf.upfronthosting.co.za> Message-ID: <1390671780.19.0.0981830157752.issue20385@psf.upfronthosting.co.za> Tal Einat added the comment: To make reproducing these bugs easier, I'm attaching my partially converted version of Modules/itertoolsmodules.c, which has the buggy generated code inside. "Partially converted" means that I've only converted some of the functions requiring conversion. This file should be in a working state. ---------- Added file: http://bugs.python.org/file33704/itertoolsmodule.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 18:44:09 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 Jan 2014 17:44:09 +0000 Subject: [issue20331] Fix various fd leaks In-Reply-To: <1390321074.97.0.506126100474.issue20331@psf.upfronthosting.co.za> Message-ID: <3fBPjN2WDQzSxD@mail.python.org> Roundup Robot added the comment: New changeset 6548f894b590 by Serhiy Storchaka in branch '2.7': Issue #20331: Fixed possible FD leaks in various modules: http://hg.python.org/cpython/rev/6548f894b590 New changeset 2766320bdb10 by Serhiy Storchaka in branch '3.3': Issue #20331: Fixed possible FD leaks in various modules: http://hg.python.org/cpython/rev/2766320bdb10 New changeset b30e57756686 by Serhiy Storchaka in branch 'default': Issue #20331: Fixed possible FD leaks in various modules: http://hg.python.org/cpython/rev/b30e57756686 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 18:55:15 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jan 2014 17:55:15 +0000 Subject: [issue20331] Fix various fd leaks In-Reply-To: <1390321074.97.0.506126100474.issue20331@psf.upfronthosting.co.za> Message-ID: <1390672515.22.0.533039930284.issue20331@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Charles-Fran?ois. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 19:05:56 2014 From: report at bugs.python.org (Ned Deily) Date: Sat, 25 Jan 2014 18:05:56 +0000 Subject: [issue20374] Failure to compile with readline-6.3-rc1 In-Reply-To: <1390537610.1.0.747015129006.issue20374@psf.upfronthosting.co.za> Message-ID: <1390673156.04.0.571295987764.issue20374@psf.upfronthosting.co.za> Ned Deily added the comment: FYI, removing the cast causes the following new warnings when compiling 3.3 with gcc-4.2 on OS X 10.5 and 10.6 (haven't checked elsewhere): Modules/readline.c: In function 'setup_readline': Modules/readline.c:939: warning: assignment from incompatible pointer type Modules/readline.c:941: warning: assignment from incompatible pointer type ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 19:17:14 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 25 Jan 2014 18:17:14 +0000 Subject: [issue20374] Failure to compile with readline-6.3-rc1 In-Reply-To: <1390537610.1.0.747015129006.issue20374@psf.upfronthosting.co.za> Message-ID: <1390673834.34.0.30575530417.issue20374@psf.upfronthosting.co.za> Benjamin Peterson added the comment: It doesn't complain on Linux. I suppose if we don't want any warnings, we'd have to do something like the originally proposed patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 19:29:38 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jan 2014 18:29:38 +0000 Subject: [issue20374] Failure to compile with readline-6.3-rc1 In-Reply-To: <1390537610.1.0.747015129006.issue20374@psf.upfronthosting.co.za> Message-ID: <1390674578.2.0.972731443445.issue20374@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm surprised that warnings are emitted at lines 939 and 941, but not 944. I think that instead type casting, the more robust way is to change hook functions signatures for on_startup_hook and on_pre_input_hook. static int #ifdef _RL_FUNCTION_TYPEDEF /* or may be test libedit macro? */ on_startup_hook(void) #else on_startup_hook() #endif ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 19:46:13 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sat, 25 Jan 2014 18:46:13 +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: <1390675573.21.0.203845624694.issue15955@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Let me be more precise: My suggestion is not to remove `unconsumed_tail` entirely, but I think its value needs to be defined only when the end of the compressed stream has been reached. In other words, you could still do: while not decomp.eof # ... if decomp.unconsumed_tail: raise RuntimeError('unexpected data after end of compressed stream') but as long as decomp.eof is True, decomp.unconsumed_tail could (as far as I can tell) be None, no matter if there is uncompressed data in the internal buffer or not. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 20:02:13 2014 From: report at bugs.python.org (Jon Parise) Date: Sat, 25 Jan 2014 19:02:13 +0000 Subject: [issue5755] "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++" In-Reply-To: <1239729771.84.0.97828652099.issue5755@psf.upfronthosting.co.za> Message-ID: <1390676533.13.0.789830986889.issue5755@psf.upfronthosting.co.za> Changes by Jon Parise : ---------- nosy: -jon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 20:19:35 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jan 2014 19:19:35 +0000 Subject: [issue20283] Wrong keyword parameter name in regex pattern methods In-Reply-To: <1389905067.44.0.489524795145.issue20283@psf.upfronthosting.co.za> Message-ID: <1390677575.43.0.25754418539.issue20283@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is patch for 3.3 which adds alternative parameter name. Now both keyword names are allowed, but deprecation warning is emitted if old keyword name is used. >>> import re >>> p = re.compile('') >>> p.match() Traceback (most recent call last): File "", line 1, in TypeError: Required argument 'string' (pos 1) not found >>> p.match('') <_sre.SRE_Match object at 0xb705c598> >>> p.match(string='') <_sre.SRE_Match object at 0xb705c720> >>> p.match(pattern='') __main__:1: DeprecationWarning: The 'pattern' keyword parameter name is deprecated. Use 'string' instead. <_sre.SRE_Match object at 0xb705c758> >>> p.match('', string='') Traceback (most recent call last): File "", line 1, in TypeError: Argument given by name ('string') and position (1) >>> p.match('', pattern='') Traceback (most recent call last): File "", line 1, in TypeError: Argument given by name ('pattern') and position (1) ---------- Added file: http://bugs.python.org/file33705/sre_deprecate_pattern_keyword.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 20:50:03 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jan 2014 19:50:03 +0000 Subject: [issue20390] Argument Clinic rollup patch, 2014/01/25 In-Reply-To: <1390663726.3.0.8274031742.issue20390@psf.upfronthosting.co.za> Message-ID: <1390679403.47.0.124637482587.issue20390@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: _PyType_GetDocFromInternalDoc and _PyType_GetTextSignatureFromInternalDoc declarations are too long. could you please wrap them around? First parameter of class methods (e.g. dict.fromkeys) now has a type of object (PyDictObject *) instead of PyTypeObject * (or PyDict_Type *). There is redundant cast in dict___contains__: register PyDictObject *mp = (PyDictObject *)self; First parameter of static methods (e.g. str.maketrans) now has a type of object (PyUnicodeObject *) instead of void *. There is redundant cast in unicodedata_UCD_decimal_impl: PyUnicodeObject *v = (PyUnicodeObject *)unichr; Perhaps here should be os.path.dirname() instead of os.path.basename(): dirname = os.path.basename(destination.filename) The 'fail("Can't write to destination "' line is too long. And I think it will look better if use string formatting. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 20:50:10 2014 From: report at bugs.python.org (Ethan Furman) Date: Sat, 25 Jan 2014 19:50:10 +0000 Subject: [issue20386] socket.SocketType enum overwrites import of _socket.SocketType In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za> Message-ID: <1390679410.32.0.719957939868.issue20386@psf.upfronthosting.co.za> Ethan Furman added the comment: Here's a patch for the test. ---------- Added file: http://bugs.python.org/file33706/issue20386.stoneleaf.test.patch.01 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 21:00:29 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 25 Jan 2014 20:00:29 +0000 Subject: [issue20386] socket.SocketType enum overwrites import of _socket.SocketType In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za> Message-ID: <1390680029.01.0.141914739739.issue20386@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: > Please find a better name for the type enum and document the new enums. Why should new enums be documented and how are they useful? IMO socket module adopted enum module only to provide a better representation of AF_* and SOCK_* constants on repr(), which is fine. The fact that in order to do that enum module forces you to create a container is incidental and should not result in polluting socket module API (which is already pretty crowded). In summary I'd be for renaming those enums to _SocketType and _AddressFamily. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 21:10:54 2014 From: report at bugs.python.org (Georg Brandl) Date: Sat, 25 Jan 2014 20:10:54 +0000 Subject: [issue20386] socket.SocketType enum overwrites import of _socket.SocketType In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za> Message-ID: <1390680654.04.0.963888580695.issue20386@psf.upfronthosting.co.za> Georg Brandl added the comment: > Why should new enums be documented and how are they useful? Because they are a new public class(-like object) in the module. When renaming them to a non-public name, as you suggest, that could be left out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 21:20:33 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Sat, 25 Jan 2014 20:20:33 +0000 Subject: [issue20386] socket.SocketType enum overwrites import of _socket.SocketType In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za> Message-ID: <1390681233.6.0.937206804167.issue20386@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: But as a user when are you gonna need to use AddressFamily container? Before enum we didn't have something like: AddressFamily = (AF_INET, AF_INET6, ...) Basically because we didn't need it. Sorry if I'm missing something here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 21:33:59 2014 From: report at bugs.python.org (Georg Brandl) Date: Sat, 25 Jan 2014 20:33:59 +0000 Subject: [issue20386] socket.SocketType enum overwrites import of _socket.SocketType In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za> Message-ID: <1390682039.15.0.270359419012.issue20386@psf.upfronthosting.co.za> Georg Brandl added the comment: I'm not saying the enums are necessary (argue about that with Eli), but that if they *are* in the module as a public attribute, they *have* to be documented, period. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 21:35:23 2014 From: report at bugs.python.org (Ethan Furman) Date: Sat, 25 Jan 2014 20:35:23 +0000 Subject: [issue20386] socket.SocketType enum overwrites import of _socket.SocketType In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za> Message-ID: <1390682123.28.0.573975010712.issue20386@psf.upfronthosting.co.za> Ethan Furman added the comment: Complete patch with new test, fixed tests, and regression fix. Doc patch still needed. ---------- stage: test needed -> patch review Added file: http://bugs.python.org/file33707/issue20386.stoneleaf.patch.02 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 21:40:35 2014 From: report at bugs.python.org (Ethan Furman) Date: Sat, 25 Jan 2014 20:40:35 +0000 Subject: [issue20386] socket.SocketType enum overwrites import of _socket.SocketType In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za> Message-ID: <1390682435.27.0.757209818983.issue20386@psf.upfronthosting.co.za> Ethan Furman added the comment: The containers are there to help with discoverability. If you want to know what all the (common) AF values are you can either do [name for name in dir(socket) if name.isupper() and name.startswith('AF_')] or list(socket.AddressFamily) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 22:24:17 2014 From: report at bugs.python.org (STINNER Victor) Date: Sat, 25 Jan 2014 21:24:17 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: Message-ID: STINNER Victor added the comment: Hi, 2014-01-25 Charles-Fran?ois Natali : > I'm sorry, but I'm not convinced. > The selector's granularity is an implementation detail, and I don't think > it should be exposed. I disagre, it's not a detail because it causes bugs, knowing the resolution matters. > Furthermore, it's not a mere function of the C type used to represent the > timeout to the underlying syscall (long, timeval): it also depends on the > operating system, the hardware, etc. I exposed the resolution of the underlying C structure, I know that it doesn't guarantee anything. But we did the same thing for clocks with time.get_clock_info(name).resolution. At least, if the C structure has a resolution of 1 ms, don't expect to have a resolution better than 1 ms in practice. It's better than not knowing it. The OS limitations can be documented. > Once again, what's wrong with your initial approach of ceiling the timeout? It looks like changing the rounding method doesn't solve anything. selector.select(timeout) may still take less than timeout, so it doesn't give any guarantee. IMO adding a granularity to asyncio is a better approach. asyncio can for example adjusts its granularity at runtime if it see that the announced selector resolution is wrong. And the granularity also uses the clock resolution. Victor ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 22:29:29 2014 From: report at bugs.python.org (Zearin) Date: Sat, 25 Jan 2014 21:29:29 +0000 Subject: [issue20393] Docs: mark deprecated items in the TOC Message-ID: <1390685369.63.0.965002484298.issue20393@psf.upfronthosting.co.za> New submission from Zearin: When exploring the docs for the standard library, it?s frustrating to have an idea and look for the answer only to find out that an entire module (or package) has been deprecated _after_ I click on it. Can we have links to deprecated items on the Standard Library?s TOC page flagged? I see you?re using multiple CSS classes on some links. I propose: - add a CSS class to flag links to deprecated items - use something like the following CSS ---- /* * Example 1: color */ .toctree-wrapper a.deprecated { color: #933; } /* * Example 2: "badge" */ .toctree-wrapper a.deprecated:after { display: inline-block; content: "deprecated"; margin: 0 1em; padding: 0 1ex !important; border-radius: 1ex !important; font-size: x-small; background-color: #f66; color: #933; } ---- Of course, since the CSS class '.deprecated' already exists, there's 2 options: 1. the examples above are rewritten to use a different classname, or 2. add the following CSS: ---- /* "Reset" .deprecated in a toctree context */ .toctree-wrapper a.deprecated { background: none; border: none; padding: 0; } /* << insert above example CSS here >> */ ---- ---------- assignee: docs at python components: Documentation messages: 209239 nosy: docs at python, zearin priority: normal severity: normal status: open title: Docs: mark deprecated items in the TOC type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 22:33:59 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jan 2014 21:33:59 +0000 Subject: [issue20393] Docs: mark deprecated items in the TOC In-Reply-To: <1390685369.63.0.965002484298.issue20393@psf.upfronthosting.co.za> Message-ID: <1390685639.1.0.360935160691.issue20393@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 22:42:46 2014 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 25 Jan 2014 21:42:46 +0000 Subject: [issue20386] socket.SocketType enum overwrites import of _socket.SocketType In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za> Message-ID: <1390686166.9.0.801461378858.issue20386@psf.upfronthosting.co.za> Eli Bendersky added the comment: Yep, the overriding of the type name was inadvertent. Nothing sacred about it, so Ethan's SocketKind is just as good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 22:46:30 2014 From: report at bugs.python.org (Glenn Langford) Date: Sat, 25 Jan 2014 21:46:30 +0000 Subject: [issue20369] concurrent.futures.wait() blocks forever when given duplicate Futures In-Reply-To: <1390491231.67.0.503348563079.issue20369@psf.upfronthosting.co.za> Message-ID: <1390686390.34.0.0432865351219.issue20369@psf.upfronthosting.co.za> Glenn Langford added the comment: Updated patch with a test case, and added a minor note to the docstring to clarify behaviour. The use of sleep() in the test is not great, but it is the most obvious way to test and it is consistent with the approach used in other concurrent test cases. ---------- Added file: http://bugs.python.org/file33708/issue20369.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 22:57:04 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jan 2014 21:57:04 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1390687024.42.0.437433433869.issue20193@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated patch for zlib reverts reverted decompress(), decompressobj() and Decompress.flush(). It get rids from DEF_WBITS and use MAX_WBITS instead, exposes DEF_BUF_SIZE (former DEFAULTALLOC) to Python level. ---------- Added file: http://bugs.python.org/file33709/zlib_clinic_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 22:59:06 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Jan 2014 21:59:06 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1390687146.81.0.788016629158.issue20193@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I suppose that zdict=b'' have same effect as not specifying zdict. Am I right? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 23:07:28 2014 From: report at bugs.python.org (Ethan Furman) Date: Sat, 25 Jan 2014 22:07:28 +0000 Subject: [issue20386] socket.SocketType enum overwrites import of _socket.SocketType In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za> Message-ID: <1390687648.56.0.457457740849.issue20386@psf.upfronthosting.co.za> Ethan Furman added the comment: How do we feel about SockType instead? (Just a short round of bike-shedding, promise! ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 23:11:54 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 25 Jan 2014 22:11:54 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: Message-ID: Charles-Fran?ois Natali added the comment: > > Once again, what's wrong with your initial approach of ceiling the timeout? > > It looks like changing the rounding method doesn't solve anything. > selector.select(timeout) may still take less than timeout, so it > doesn't give any guarantee. But what problem does it cause if, once in a while, the call takes less than the passed timeout? If that's the case, you'll simply perform another loop, an wake up 1ms later, that's all. There's a lot of call written this way, and this has never been a problem: so far, you still didn't give an example of problematic behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 23:37:48 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 Jan 2014 22:37:48 +0000 Subject: [issue19944] Make importlib.find_spec load packages as needed In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za> Message-ID: <3fBXDC313Qz7LjS@mail.python.org> Roundup Robot added the comment: New changeset 665f1ba77b57 by Eric Snow in branch 'default': Issue 19944: Fix importlib.find_spec() so it imports parents as needed. http://hg.python.org/cpython/rev/665f1ba77b57 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 23:39:44 2014 From: report at bugs.python.org (Eric Snow) Date: Sat, 25 Jan 2014 22:39:44 +0000 Subject: [issue19944] Make importlib.find_spec load packages as needed In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za> Message-ID: <1390689584.52.0.937573939075.issue19944@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> pending type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 23:45:58 2014 From: report at bugs.python.org (Eric Snow) Date: Sat, 25 Jan 2014 22:45:58 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <1390689958.07.0.0604157556821.issue20311@psf.upfronthosting.co.za> Eric Snow added the comment: Looks like 3b8a2281d323aa9abf497192b01cf906b98ed3d8 broke the buildbots. e.g. http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x/builds/1533 ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 23:48:19 2014 From: report at bugs.python.org (Eric Snow) Date: Sat, 25 Jan 2014 22:48:19 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <1390690099.41.0.400976898692.issue20311@psf.upfronthosting.co.za> Eric Snow added the comment: FYI: on my local box I saw only the 2 failed tests in test_telnetlib. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 23:49:47 2014 From: report at bugs.python.org (Eric Snow) Date: Sat, 25 Jan 2014 22:49:47 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <1390690187.58.0.925428623647.issue20311@psf.upfronthosting.co.za> Eric Snow added the comment: A better example: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x/builds/1538 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 23:50:44 2014 From: report at bugs.python.org (Eric Snow) Date: Sat, 25 Jan 2014 22:50:44 +0000 Subject: [issue19944] Make importlib.find_spec load packages as needed In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za> Message-ID: <1390690244.87.0.270019978743.issue19944@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 23:52:20 2014 From: report at bugs.python.org (STINNER Victor) Date: Sat, 25 Jan 2014 22:52:20 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: Message-ID: STINNER Victor added the comment: 2014-01-25 Charles-Fran?ois Natali : >> It looks like changing the rounding method doesn't solve anything. >> selector.select(timeout) may still take less than timeout, so it >> doesn't give any guarantee. > > But what problem does it cause if, once in a while, the call takes less > than the passed timeout? > If that's the case, you'll simply perform another loop, an wake up 1ms > later, that's all. "perform another loop" is my problem. If possible, I would like useless calls to the loop. With my latest patch to asyncio, there is no more useless calls to the loop (at least, not because of a time rounding issue). Oh, I forgot to mention that I'm also concerned by the backward compatibility. Changing how poll and epoll round the timeout changes the behaviour. It may break applications or maybe change performances of applications (efficiency or reactivity). Changing the rounding method in Python 3.3 was not a good idea. @Charles-Fran?ois: I'm not sure that we are talking about the same thing. If you still want to change poll and epoll, go ahead. Since the performance issue has been fixed directly in asyncio, I don't feel the need of changing the poll or epoll anymore in Python 3.4. Or maybe you disagree with my change in the asyncio module? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 23:53:41 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 Jan 2014 22:53:41 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <3fBXZX5xQBz7LjS@mail.python.org> Roundup Robot added the comment: New changeset f453443c96e4 by Victor Stinner in branch 'default': Issue #20311: Fix test_telnetlib, set the resolution of the MockSelector http://hg.python.org/cpython/rev/f453443c96e4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 23:56:04 2014 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 25 Jan 2014 22:56:04 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <1390690564.05.0.915998793255.issue20311@psf.upfronthosting.co.za> Guido van Rossum added the comment: I don't have the energy to read all the debate here, but over on python-tulip we continue to discuss this. Victor and I have currently agreed to drop the math.ceil() calls from the event loop and instead simply consider any event scheduled within "granularity" from the current clock value to be "ready". Victor will check it in. Regarding the buildbot failures, Victor will have to review those. They are in the telnet tests: ====================================================================== ERROR: test_read_until (test.test_telnetlib.ReadTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/test_telnetlib.py", line 179, in test_read_until data = telnet.read_until(b'match') File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/telnetlib.py", line 312, in read_until with _TelnetSelector() as selector: TypeError: Can't instantiate abstract class MockSelector with abstract methods resolution ====================================================================== ERROR: test_expect (test.test_telnetlib.ExpectTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/test_telnetlib.py", line 388, in test_expect (_,_,data) = telnet.expect([b'match']) File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/telnetlib.py", line 617, in expect with _TelnetSelector() as selector: TypeError: Can't instantiate abstract class MockSelector with abstract methods resolution ---------------------------------------------------------------------- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jan 25 23:57:48 2014 From: report at bugs.python.org (STINNER Victor) Date: Sat, 25 Jan 2014 22:57:48 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: Message-ID: STINNER Victor added the comment: > Looks like 3b8a2281d323aa9abf497192b01cf9 06b98ed3d8 broke the buildbots. Oh, I didn't watch buildbots, sorry. It should be fixed by f453443c96e4. My first attempt used an attribute using a default value of None, but it was harder to use: I had to check if the value is None or not. I prefer to enforce an implementation to define the resolution. Or do you know a selector which has no resolution? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 00:49:06 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 25 Jan 2014 23:49:06 +0000 Subject: [issue20390] Argument Clinic rollup patch, 2014/01/25 In-Reply-To: <1390663726.3.0.8274031742.issue20390@psf.upfronthosting.co.za> Message-ID: <1390693746.21.0.914968638794.issue20390@psf.upfronthosting.co.za> Larry Hastings added the comment: Thanks for the reviews, Nick and Serhiy, especially considering that the Rietveld link didn't work! Serhiy: I believe I fixed everything. There are no side files checked in yet. Can you give me another review? ---------- Added file: http://bugs.python.org/file33710/larry.clinic.rollup.jan.25.diff.2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 00:49:22 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 25 Jan 2014 23:49:22 +0000 Subject: [issue20390] Argument Clinic rollup patch, 2014/01/25 In-Reply-To: <1390663726.3.0.8274031742.issue20390@psf.upfronthosting.co.za> Message-ID: <1390693762.38.0.389557557998.issue20390@psf.upfronthosting.co.za> Changes by Larry Hastings : Removed file: http://bugs.python.org/file33710/larry.clinic.rollup.jan.25.diff.2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 00:51:21 2014 From: report at bugs.python.org (Larry Hastings) Date: Sat, 25 Jan 2014 23:51:21 +0000 Subject: [issue20390] Argument Clinic rollup patch, 2014/01/25 In-Reply-To: <1390663726.3.0.8274031742.issue20390@psf.upfronthosting.co.za> Message-ID: <1390693881.04.0.905805699704.issue20390@psf.upfronthosting.co.za> Larry Hastings added the comment: Hang on, my tree was out of date. Which is why I didn't get a review link, duh. And if side files have appeared I'll fix 'em. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 00:51:29 2014 From: report at bugs.python.org (Zachary Ware) Date: Sat, 25 Jan 2014 23:51:29 +0000 Subject: [issue20358] test_curses is failing on Ubuntu 13.10 In-Reply-To: <1390467619.0.0.459315516203.issue20358@psf.upfronthosting.co.za> Message-ID: <1390693889.01.0.597169098191.issue20358@psf.upfronthosting.co.za> Zachary Ware added the comment: Ok, I've tracked down where the error is happening, but I don't know enough about curses to suggest where it should go from here. It does appear to be the version of ncurses that Ubuntu 13.10 uses that's causing problems, version 5.9+20130608. The issue stems from a change in ncurses/base/lib_overlay.c, here's the relevant part of the diff to copywin (left is vanilla ncurses-5.9 from http://ftp.gnu.org/pub/gnu/ncurses/, right is ncurses-5.9+20130608 obtained by 'sudo apt-get source ncurses'): --- ncurses-5.9/ncurses/base/lib_overlay.c 2009-10-24 18:21:31.000000000 -0500 +++ ncurses-5.9+20130608/ncurses/base/lib_overlay.c 2014-01-25 17:13:08.461548012 -0600 @@ -151,7 +151,10 @@ dminrow, dmincol, dmaxrow, dmaxcol, over)); - if (src && dst) { + if (src != 0 + && dst != 0 + && dmaxrow >= dminrow + && dmaxcol >= dmincol) { _nc_lock_global(curses); bk = AttrOf(dst->_nc_bkgd); The failing test passes 1, 2, 3, 3, 2, 1 for sminrow, smincol, dminrow, dmincol, dmaxrow, dmaxcol, which fails the dmaxrow >= dminrow check and copywin returns -1 (ERR). Changing the test to call with 1, 1, 2, 2, 3, 3 prevents the failure, but does ugly things to the tty when the process ends. ---------- title: test_curses is failing -> test_curses is failing on Ubuntu 13.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 01:11:18 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 26 Jan 2014 00:11:18 +0000 Subject: [issue20390] Argument Clinic rollup patch, 2014/01/25 In-Reply-To: <1390663726.3.0.8274031742.issue20390@psf.upfronthosting.co.za> Message-ID: <1390695078.04.0.59687047143.issue20390@psf.upfronthosting.co.za> Larry Hastings added the comment: Okay, here's my revised patch, for real this time, with "hg mv" for the side files and everything. ---------- Added file: http://bugs.python.org/file33711/larry.clinic.rollup.jan.25.diff.2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 01:18:31 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 26 Jan 2014 00:18:31 +0000 Subject: [issue20385] Argument Clinic: Support for __new__ not checking _PyArg_NoKeywords for sub-classes In-Reply-To: <1390599341.47.0.747419262521.issue20385@psf.upfronthosting.co.za> Message-ID: <1390695511.06.0.00065595724738.issue20385@psf.upfronthosting.co.za> Larry Hastings added the comment: Can you try locally applying my patch for #20390 and seeing if you still have the problem? I tried applying it to the itertoolmodule.c you attached to the issue and it seemed to fix the problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 01:21:31 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 26 Jan 2014 00:21:31 +0000 Subject: [issue20390] Argument Clinic rollup patch, 2014/01/25 In-Reply-To: <1390663726.3.0.8274031742.issue20390@psf.upfronthosting.co.za> Message-ID: <1390695691.02.0.0268468096463.issue20390@psf.upfronthosting.co.za> Larry Hastings added the comment: Oops, I goofed up moving _lzamodule.clinic.c.h. I'll fix that locally, won't regenerate the patch just for that (unless you ask me to). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 01:22:25 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 26 Jan 2014 00:22:25 +0000 Subject: [issue20390] Argument Clinic rollup patch, 2014/01/25 In-Reply-To: <1390663726.3.0.8274031742.issue20390@psf.upfronthosting.co.za> Message-ID: <1390695745.51.0.175282815853.issue20390@psf.upfronthosting.co.za> Larry Hastings added the comment: No, wait, I think it's fine, it was just some detritus in my directory throwing me off. But "hg stat" looks correct. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 01:24:43 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 26 Jan 2014 00:24:43 +0000 Subject: [issue20133] Derby: Convert the audioop module to use Argument Clinic In-Reply-To: <1388956864.17.0.114751586443.issue20133@psf.upfronthosting.co.za> Message-ID: <1390695883.21.0.497704215988.issue20133@psf.upfronthosting.co.za> Larry Hastings added the comment: Christian Heimes just posted this to python-dev: ____________________________________________________________ Coverity has detected an issue in this commit: ** CID 1164423: Division or modulo by zero (DIVIDE_BY_ZERO) /Modules/audioop.c: 1375 in audioop_ratecv_impl() ________________________________________________________________________________________________________ *** CID 1164423: Division or modulo by zero (DIVIDE_BY_ZERO) /Modules/audioop.c: 1375 in audioop_ratecv_impl() 1369 without spurious overflow is the challenge; we can 1370 settle for a reasonable upper bound, though, in this 1371 case ceiling(len/inrate) * outrate. */ 1372 1373 /* compute ceiling(len/inrate) without overflow */ 1374 Py_ssize_t q = len > 0 ? 1 + (len - 1) / inrate : 0; >>> CID 1164423: Division or modulo by zero (DIVIDE_BY_ZERO) >>> In expression "9223372036854775807L / q", division by expression "q" which may be zero has undefined behavior. 1375 if (outrate > PY_SSIZE_T_MAX / q / bytes_per_frame) 1376 str = NULL; 1377 else 1378 str = PyBytes_FromStringAndSize(NULL, 1379 q * outrate * bytes_per_frame); 1380 } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 01:43:25 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 26 Jan 2014 00:43:25 +0000 Subject: [issue20386] socket.SocketType enum overwrites import of _socket.SocketType In-Reply-To: <1390687648.56.0.457457740849.issue20386@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: I strongly prefer SocketKind - SockType is far too close to SocketType and "type" is too closely associated with the type system in general. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 02:09:06 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 26 Jan 2014 01:09:06 +0000 Subject: [issue20363] BytesWarnings triggerred by test suite In-Reply-To: <1390470451.71.0.00122717133798.issue20363@psf.upfronthosting.co.za> Message-ID: <1390698546.06.0.466225427314.issue20363@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the review, Arfrever and Serhiy. Here's a new patch. ---------- Added file: http://bugs.python.org/file33712/issue20363_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 02:13:37 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 26 Jan 2014 01:13:37 +0000 Subject: [issue20283] Wrong keyword parameter name in regex pattern methods In-Reply-To: <1389905067.44.0.489524795145.issue20283@psf.upfronthosting.co.za> Message-ID: <1390698817.6.0.1979720022.issue20283@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Great. Old and new both in at least one release, when possible, is best. I should have thought of asking if that would be possible. In this case, I think the (undocumented) old should disappear in 3.5. Since the mistaken 'pattern' name is not documented now, I would not add anything to the doc. I would augment the the warning "The 'pattern' keyword parameter name is deprecated." to briefly explain the deprecation and its timing by saying "The erroneous and undocumented 'pattern' keyword parameter name is deprecated and will be removed in version 3.5." The patch did not upload correctly. I just see "Modules/_sre.c | 64 +++++++++++++++++++++++++++++++++++++++!!!!!!!!!!!!!!!!!! 1 file changed, 44 insertions(+), 20 modifications(!)" when I open it in a new Firefox tab. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 02:33:09 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sun, 26 Jan 2014 01:33:09 +0000 Subject: [issue20375] ElementTree: Document handling processing instructions In-Reply-To: <1390539216.23.0.0362813865609.issue20375@psf.upfronthosting.co.za> Message-ID: <1390699989.14.0.137266145646.issue20375@psf.upfronthosting.co.za> Nikolaus Rath added the comment: I've also attached a testcase to confirm that the docpatch reflects current behavior, and to make sure that anticipated enhancements in Python 3.5 behave in a backwards compatible way. ---------- Added file: http://bugs.python.org/file33713/etree-testcases.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 02:37:36 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 26 Jan 2014 01:37:36 +0000 Subject: [issue20363] BytesWarnings triggerred by test suite In-Reply-To: <1390470451.71.0.00122717133798.issue20363@psf.upfronthosting.co.za> Message-ID: <1390700256.91.0.60763606799.issue20363@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: The new patch has %s and %r reversed in Lib/distutils/command/register.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 02:55:28 2014 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 26 Jan 2014 01:55:28 +0000 Subject: [issue20367] concurrent.futures.as_completed() fails when given duplicate Futures In-Reply-To: <1390489248.24.0.751917808957.issue20367@psf.upfronthosting.co.za> Message-ID: <1390701328.4.0.60119618727.issue20367@psf.upfronthosting.co.za> Guido van Rossum added the comment: LGTM. But you also need to update Doc/library/concurrent.futures.rst I see this as a bugfix so it's not necessary to get this in before the beta 3 release tonight. I will work on an asyncio patch and test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 02:55:57 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sun, 26 Jan 2014 01:55:57 +0000 Subject: [issue20177] Derby #8: Convert 28 sites to Argument Clinic across 2 files In-Reply-To: <1389138574.32.0.892814928986.issue20177@psf.upfronthosting.co.za> Message-ID: <1390701357.37.0.360088644374.issue20177@psf.upfronthosting.co.za> Nikolaus Rath added the comment: I've attached updated patches to reflect the recent changes in the derby policy. part1 is the part of the patch that is suitable for 3.4. part2 are the changes that have to wait for 3.5 (mostly because of default values). ---------- Added file: http://bugs.python.org/file33714/timemodule_part1_rev3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 02:57:01 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 26 Jan 2014 01:57:01 +0000 Subject: [issue20363] BytesWarnings triggerred by test suite In-Reply-To: <1390470451.71.0.00122717133798.issue20363@psf.upfronthosting.co.za> Message-ID: <1390701421.98.0.574169608463.issue20363@psf.upfronthosting.co.za> Berker Peksag added the comment: Ah, my bad. Thanks Arfrever. ---------- Added file: http://bugs.python.org/file33715/issue20363_v3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 02:57:21 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 26 Jan 2014 01:57:21 +0000 Subject: [issue20363] BytesWarnings triggerred by test suite In-Reply-To: <1390470451.71.0.00122717133798.issue20363@psf.upfronthosting.co.za> Message-ID: <1390701441.56.0.0458288091681.issue20363@psf.upfronthosting.co.za> Changes by Berker Peksag : Removed file: http://bugs.python.org/file33669/issue20363.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 02:58:41 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 26 Jan 2014 01:58:41 +0000 Subject: [issue20363] BytesWarnings triggerred by test suite In-Reply-To: <1390470451.71.0.00122717133798.issue20363@psf.upfronthosting.co.za> Message-ID: <1390701521.52.0.171939172758.issue20363@psf.upfronthosting.co.za> Changes by Berker Peksag : Removed file: http://bugs.python.org/file33712/issue20363_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 03:08:53 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sun, 26 Jan 2014 02:08:53 +0000 Subject: [issue20177] Derby #8: Convert 28 sites to Argument Clinic across 2 files In-Reply-To: <1389138574.32.0.892814928986.issue20177@psf.upfronthosting.co.za> Message-ID: <1390702133.14.0.444498463212.issue20177@psf.upfronthosting.co.za> Changes by Nikolaus Rath : Removed file: http://bugs.python.org/file33714/timemodule_part1_rev3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 03:08:59 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sun, 26 Jan 2014 02:08:59 +0000 Subject: [issue20177] Derby #8: Convert 28 sites to Argument Clinic across 2 files In-Reply-To: <1389138574.32.0.892814928986.issue20177@psf.upfronthosting.co.za> Message-ID: <1390702139.89.0.636786749794.issue20177@psf.upfronthosting.co.za> Changes by Nikolaus Rath : Added file: http://bugs.python.org/file33716/timemodule_part1_rev3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 03:14:48 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sun, 26 Jan 2014 02:14:48 +0000 Subject: [issue20177] Derby #8: Convert 28 sites to Argument Clinic across 2 files In-Reply-To: <1389138574.32.0.892814928986.issue20177@psf.upfronthosting.co.za> Message-ID: <1390702488.99.0.764026166328.issue20177@psf.upfronthosting.co.za> Changes by Nikolaus Rath : Added file: http://bugs.python.org/file33717/timemodule_part2_rev3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 03:27:05 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sun, 26 Jan 2014 02:27:05 +0000 Subject: [issue20177] Derby #8: Convert 28 sites to Argument Clinic across 2 files In-Reply-To: <1389138574.32.0.892814928986.issue20177@psf.upfronthosting.co.za> Message-ID: <1390703225.16.0.48845337575.issue20177@psf.upfronthosting.co.za> Nikolaus Rath added the comment: I'll wait with working on _datetimemodule.c until someone had a chance to look over my _timemodule.c patch. (I want to make sure I'm following the right procedure). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 04:18:54 2014 From: report at bugs.python.org (Brian Quinlan) Date: Sun, 26 Jan 2014 03:18:54 +0000 Subject: [issue20319] concurrent.futures.wait() can block forever even if Futures have completed In-Reply-To: <1390263519.32.0.357208079457.issue20319@psf.upfronthosting.co.za> Message-ID: <1390706334.66.0.653487429173.issue20319@psf.upfronthosting.co.za> Brian Quinlan added the comment: I'm looking at "futures.patch". I don't understand why these blocks are helpful -"_create_and_install_waiters" has two call sites and both ("as_completed" and "wait") call "_create_and_install_waiters" from within an _AcquireFutures context manager: - pending_count = sum( - f._state not in [CANCELLED_AND_NOTIFIED, FINISHED] for f in fs) + with _AcquireFutures(fs): + pending_count = sum( + f._state not in [CANCELLED_AND_NOTIFIED, FINISHED] + for f in fs) - for f in fs: - f._waiters.append(waiter) + with _AcquireFutures(fs): + for f in fs: + f._waiters.append(waiter) It seems more plausible that the locks around the removals are fixing the bug but I don't see how. I'll look into it some more. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 04:35:39 2014 From: report at bugs.python.org (Glenn Langford) Date: Sun, 26 Jan 2014 03:35:39 +0000 Subject: [issue20319] concurrent.futures.wait() can block forever even if Futures have completed In-Reply-To: <1390263519.32.0.357208079457.issue20319@psf.upfronthosting.co.za> Message-ID: <1390707339.85.0.651219051405.issue20319@psf.upfronthosting.co.za> Glenn Langford added the comment: > It seems more plausible that the locks around the removals are fixing the bug but I don't see how. I'll look into it some more. It is the locks around the waiter removals that matter; I think there are only formatting changes elsewhere in the patch. The reason the locks make a difference is that there can be a race condition if multiple wait() calls compete to modify the f._waiters list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 04:49:09 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 26 Jan 2014 03:49:09 +0000 Subject: [issue13355] random.triangular error when low = high=mode In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za> Message-ID: <1390708149.24.0.679397759345.issue13355@psf.upfronthosting.co.za> Larry Hastings added the comment: I haven't looked at this in depth but it sounds like this is a legitimate concern. I'd like it fixed for 3.4, preferably before rc1. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 04:57:36 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 26 Jan 2014 03:57:36 +0000 Subject: [issue20322] Upgrade ensurepip's pip and setuptools In-Reply-To: <1390278181.02.0.46118340261.issue20322@psf.upfronthosting.co.za> Message-ID: <1390708656.47.0.911937082467.issue20322@psf.upfronthosting.co.za> Larry Hastings added the comment: You can check those in for 3.4. Do it right now and you can get them in for beta 3. Sorry for the tardy reply! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 05:22:46 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 26 Jan 2014 04:22:46 +0000 Subject: [issue20390] Argument Clinic rollup patch, 2014/01/25 In-Reply-To: <1390663726.3.0.8274031742.issue20390@psf.upfronthosting.co.za> Message-ID: <1390710166.09.0.112236383977.issue20390@psf.upfronthosting.co.za> Larry Hastings added the comment: I don't know why it's refusing to generate the review link. The patch applies cleanly to trunk, even now, hours later. Maybe it doesn't like file moves? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 05:44:02 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 26 Jan 2014 04:44:02 +0000 Subject: [issue20390] Argument Clinic rollup patch, 2014/01/25 In-Reply-To: <1390663726.3.0.8274031742.issue20390@psf.upfronthosting.co.za> Message-ID: <3fBhLm46Pbz7LjS@mail.python.org> Roundup Robot added the comment: New changeset 9c5b421cc7de by Larry Hastings in branch 'default': Issue #20390: Small fixes and improvements for Argument Clinic. http://hg.python.org/cpython/rev/9c5b421cc7de ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 05:45:25 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 26 Jan 2014 04:45:25 +0000 Subject: [issue20390] Argument Clinic rollup patch, 2014/01/25 In-Reply-To: <1390663726.3.0.8274031742.issue20390@psf.upfronthosting.co.za> Message-ID: <1390711525.81.0.348262453331.issue20390@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 05:48:06 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 26 Jan 2014 04:48:06 +0000 Subject: [issue20226] Argument Clinic: support for simple expressions? In-Reply-To: <1389522589.48.0.984332793667.issue20226@psf.upfronthosting.co.za> Message-ID: <1390711686.18.0.433353252229.issue20226@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- stage: commit review -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 06:00:44 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Sun, 26 Jan 2014 05:00:44 +0000 Subject: [issue19145] Inconsistent behaviour in itertools.repeat when using negative times In-Reply-To: <1380727396.47.0.412229295257.issue19145@psf.upfronthosting.co.za> Message-ID: <1390712444.65.0.982152465462.issue19145@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Larry said, "A proper fix for the "bug" will require changing the semantics of the function. It's inappropriate to do that in 2.7, 3.3, and (now that we're in beta) 3.4." I think we can not have it all and need to be pragmatic in this ticket. While we can not fix the default value quirk in 2.7, 3.3, and 3.4, at least we can make the negative times consistent whether it is sent through positional or keyword. Otherwise, we have to fix the doc: repeat(object [,times]) create an iterator which returns the object for the specified number of times. If not specified, returns the object endlessly.If times is negative and is sent via positional, it means zero repetitions. But if times is negative and is sent via keyword, it means endless repetition. And it doesn't feel right, does it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 06:02:40 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 26 Jan 2014 05:02:40 +0000 Subject: [issue19145] Inconsistent behaviour in itertools.repeat when using negative times In-Reply-To: <1380727396.47.0.412229295257.issue19145@psf.upfronthosting.co.za> Message-ID: <1390712560.79.0.0254583720763.issue19145@psf.upfronthosting.co.za> Larry Hastings added the comment: Raymond said "The preferred behavior is that a negative number always means 0." My proposal honors that. We certainly aren't changing this in 3.3 and 2.7, and as release manager for 3.4 I'm pretty sure we aren't changing it there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 06:53:35 2014 From: report at bugs.python.org (Donald Stufft) Date: Sun, 26 Jan 2014 05:53:35 +0000 Subject: [issue20322] Upgrade ensurepip's pip and setuptools In-Reply-To: <1390278181.02.0.46118340261.issue20322@psf.upfronthosting.co.za> Message-ID: <1390715615.42.0.528472494222.issue20322@psf.upfronthosting.co.za> Changes by Donald Stufft : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 07:01:38 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 26 Jan 2014 06:01:38 +0000 Subject: [issue20390] Argument Clinic rollup patch, 2014/01/25 In-Reply-To: <1390663726.3.0.8274031742.issue20390@psf.upfronthosting.co.za> Message-ID: <3fBk4K4dNDz7LkR@mail.python.org> Roundup Robot added the comment: New changeset 1435d2fe8e34 by Larry Hastings in branch 'default': Issue #20390: Final fix, for generating NoPositional/NoKeyword for __init__ calls. http://hg.python.org/cpython/rev/1435d2fe8e34 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 07:20:17 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 26 Jan 2014 06:20:17 +0000 Subject: [issue20358] test_curses is failing on Ubuntu 13.10 In-Reply-To: <1390467619.0.0.459315516203.issue20358@psf.upfronthosting.co.za> Message-ID: <3fBkTr4sFjzMfZ@mail.python.org> Roundup Robot added the comment: New changeset 0ae768637a07 by Larry Hastings in branch 'default': Issue #20358: Tests for curses.window.overlay and curses.window.overwrite http://hg.python.org/cpython/rev/0ae768637a07 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 07:22:34 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 26 Jan 2014 06:22:34 +0000 Subject: [issue20358] test_curses is failing on Ubuntu 13.10 In-Reply-To: <1390467619.0.0.459315516203.issue20358@psf.upfronthosting.co.za> Message-ID: <1390717354.7.0.896449434331.issue20358@psf.upfronthosting.co.za> Larry Hastings added the comment: I changed the unit test so it doesn't specify a minium row/column greater than the maximum row/column. The tests now pass. So I'm calling this good. Thanks for looking in to it, Zachary and Nadeem! ---------- assignee: -> larry resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 08:13:35 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 07:13:35 +0000 Subject: [issue20390] Argument Clinic rollup patch, 2014/01/25 In-Reply-To: <1390663726.3.0.8274031742.issue20390@psf.upfronthosting.co.za> Message-ID: <1390720415.44.0.814458864418.issue20390@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Rietveld doesn't like patches against out of date tree. And unfortunately it doesn't like patches in git format. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 08:15:28 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 26 Jan 2014 07:15:28 +0000 Subject: [issue20390] Argument Clinic rollup patch, 2014/01/25 In-Reply-To: <1390663726.3.0.8274031742.issue20390@psf.upfronthosting.co.za> Message-ID: <1390720528.97.0.282462374535.issue20390@psf.upfronthosting.co.za> Larry Hastings added the comment: I don't know about diff #1, but diff #2 definitely applied cleanly against a fresh trunk at 8:22pm local time. I've turned off git format. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 08:35:21 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 07:35:21 +0000 Subject: [issue20394] Coverity complains on audioop Message-ID: <1390721721.09.0.648062700512.issue20394@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Christian Heimes reported (http://permalink.gmane.org/gmane.comp.python.devel/145253) Coverity issue: """ ** CID 1164423: Division or modulo by zero (DIVIDE_BY_ZERO) /Modules/audioop.c: 1375 in audioop_ratecv_impl() ________________________________________________________________________________________________________ *** CID 1164423: Division or modulo by zero (DIVIDE_BY_ZERO) /Modules/audioop.c: 1375 in audioop_ratecv_impl() 1369 without spurious overflow is the challenge; we can 1370 settle for a reasonable upper bound, though, in this 1371 case ceiling(len/inrate) * outrate. */ 1372 1373 /* compute ceiling(len/inrate) without overflow */ 1374 Py_ssize_t q = len > 0 ? 1 + (len - 1) / inrate : 0; >>> CID 1164423: Division or modulo by zero (DIVIDE_BY_ZERO) >>> In expression "9223372036854775807L / q", division by expression "q" which may be zero has undefined behavior. 1375 if (outrate > PY_SSIZE_T_MAX / q / bytes_per_frame) 1376 str = NULL; 1377 else 1378 str = PyBytes_FromStringAndSize(NULL, 1379 q * outrate * bytes_per_frame); 1380 } """ This is false positive. len should be non-negative and a case of 0 already checked just several lines before. Is Coverity aware asserts? Perhaps this patch will silence it. ---------- components: Build files: audioop_ratecv_coverity_silence.patch keywords: patch messages: 209284 nosy: christian.heimes, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Coverity complains on audioop versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33718/audioop_ratecv_coverity_silence.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 08:38:18 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 07:38:18 +0000 Subject: [issue20133] Derby: Convert the audioop module to use Argument Clinic In-Reply-To: <1390695883.21.0.497704215988.issue20133@psf.upfronthosting.co.za> Message-ID: <2636491.mNfmbWrLm3@raxxla> Serhiy Storchaka added the comment: > Christian Heimes just posted this to python-dev: See issue20394. This is unrelated to clicalization patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 08:50:48 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 26 Jan 2014 07:50:48 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: Message-ID: Charles-Fran?ois Natali added the comment: > > But what problem does it cause if, once in a while, the call takes less > > than the passed timeout? > > If that's the case, you'll simply perform another loop, an wake up 1ms > > later, that's all. > > "perform another loop" is my problem. If possible, I would like > useless calls to the loop. With my latest patch to asyncio, there is > no more useless calls to the loop (at least, not because of a time > rounding issue). Still, you fail to provide an example: you will only perform another call if you pass a tilmeout really close to an exact multiple of the granularity, *and* the syscall returns early. Just perform a test on your machine, you'll see that early wakeups are *really* rare. And even if that's the case, I argue that performing an extra loop isn't a problem: for example, noone ever complained about the way timpeouts are rounded in the select module. If you think otherwise, please back your claim by an example. > Oh, I forgot to mention that I'm also concerned by the backward > compatibility. Changing how poll and epoll round the timeout changes > the behaviour. It may break applications or maybe change performances > of applications (efficiency or reactivity). Changing the rounding > method in Python 3.3 was not a good idea. Don't apply it to 3.3 then. > @Charles-Fran?ois: I'm not sure that we are talking about the same > thing. If you still want to change poll and epoll, go ahead. Since the > performance issue has been fixed directly in asyncio, I don't feel the > need of changing the poll or epoll anymore in Python 3.4. Or maybe you > disagree with my change in the asyncio module? I disagree with the introduction of a granularity to selectors. If you really want to keep the change in asyncio, just introduce a fixed "slack" value, e.g. 1e-3 seconds. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 09:06:20 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 08:06:20 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1390723580.94.0.446267039511.issue20193@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file33709/zlib_clinic_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 09:07:11 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 08:07:11 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1390723631.82.0.143159409985.issue20193@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Synchronized with recent Argument Clinic changes. ---------- Added file: http://bugs.python.org/file33719/zlib_clinic_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 09:14:42 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 26 Jan 2014 08:14:42 +0000 Subject: [issue20338] Idle: increase max calltip width In-Reply-To: <1390344102.42.0.241411598779.issue20338@psf.upfronthosting.co.za> Message-ID: <1390724082.11.0.319154920092.issue20338@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I removed the incorrect * comment. Attached is a 2.7 port of the 3.3 patch. It turns out that textwrap.TextWrap in 2.7 is an old-style class. Such did not work previously because they do not have .__call__ and failed the hasattr() check, now a try:except check. In 2.7, callable(old) == True, so there must be an explicit type check. I added one in the patch. ---------- Added file: http://bugs.python.org/file33720/20338-2.7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 09:19:13 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 08:19:13 +0000 Subject: [issue20283] Wrong keyword parameter name in regex pattern methods In-Reply-To: <1389905067.44.0.489524795145.issue20283@psf.upfronthosting.co.za> Message-ID: <1390724353.15.0.942227344401.issue20283@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > The patch did not upload correctly. Oh, sorry. Here is correct patch. I propose to apply "soft" patch (which preserves support for old keyword parameter name) to 2.7 and 3.3, and apply "hard" patch (which just renames keyword parameter name) to 3.4. Or we can just apply "hard" patch (it's much simpler) to all versions. ---------- nosy: +benjamin.peterson, georg.brandl, larry Added file: http://bugs.python.org/file33721/sre_deprecate_pattern_keyword.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 09:30:07 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 26 Jan 2014 08:30:07 +0000 Subject: [issue20394] Coverity complains on audioop In-Reply-To: <1390721721.09.0.648062700512.issue20394@psf.upfronthosting.co.za> Message-ID: <1390725007.86.0.421794805876.issue20394@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Coverity appears concerned about the division by q. It apparently knows inrate != 0. I do not see any division by len. If q is cleared up, I presume it will check bytes_per_frame. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 09:31:04 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 26 Jan 2014 08:31:04 +0000 Subject: [issue20283] Wrong keyword parameter name in regex pattern methods In-Reply-To: <1389905067.44.0.489524795145.issue20283@psf.upfronthosting.co.za> Message-ID: <1390725064.7.0.143652549467.issue20283@psf.upfronthosting.co.za> Changes by Terry J. Reedy : Removed file: http://bugs.python.org/file33705/sre_deprecate_pattern_keyword.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 09:33:12 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 26 Jan 2014 08:33:12 +0000 Subject: [issue20283] Wrong keyword parameter name in regex pattern methods In-Reply-To: <1389905067.44.0.489524795145.issue20283@psf.upfronthosting.co.za> Message-ID: <1390725192.54.0.857174037187.issue20283@psf.upfronthosting.co.za> Georg Brandl added the comment: For 3.3 I prefer the "soft" patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 09:35:13 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 08:35:13 +0000 Subject: [issue20338] Idle: increase max calltip width In-Reply-To: <1390344102.42.0.241411598779.issue20338@psf.upfronthosting.co.za> Message-ID: <1390725313.1.0.866656191156.issue20338@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. But I prefer larger indent. Perhaps we need explicit tests for constructors of old- and new-style classes, with __new__, with __init__, and without __new__ and __init__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 11:23:08 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 10:23:08 +0000 Subject: [issue8260] When I use codecs.open(...) and f.readline() follow up by f.read() return bad result In-Reply-To: <1269875395.81.0.132261115225.issue8260@psf.upfronthosting.co.za> Message-ID: <1390731788.75.0.35549648424.issue8260@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 12:05:40 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 11:05:40 +0000 Subject: [issue20395] Extract generated clinic code in Modules/_pickle.c to separate file Message-ID: <1390734339.8.0.0968166670001.issue20395@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Argument Clinic had added about half-thousand lines of code to Modules/_pickle.c. This generated code is mixed with handwritten code. Last 8 changes of Modules/_pickle.c are caused by Argument Clinic evolution, and I afraid that many future Argument Clinic changes will change Modules/_pickle.c too. The proposed patch extracts generated clinic code in separate file to prevent or decrease code churn in future. It decreases the size of Modules/_pickle.c by 450 lines. ---------- files: pickle_clinic.patch keywords: patch messages: 209293 nosy: alexandre.vassalotti, larry, pitrou, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Extract generated clinic code in Modules/_pickle.c to separate file versions: Python 3.4 Added file: http://bugs.python.org/file33722/pickle_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 12:28:26 2014 From: report at bugs.python.org (Nadeem Vawda) Date: Sun, 26 Jan 2014 11:28:26 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1390735706.12.0.691539467908.issue20193@psf.upfronthosting.co.za> Nadeem Vawda added the comment: The latest patch for zlib seems to be missing Modules/zlibmodule.clinic.c > I suppose that zdict=b'' have same effect as not specifying zdict. Am I right? Probably, but to be on the safe side I'd prefer that we preserve the behavior of not calling deflateSetDictionary/inflateSetDictionary unless the caller explicitly provides zdict. If you need to give a Python default value, rather use None than b''. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 12:30:07 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 26 Jan 2014 11:30:07 +0000 Subject: [issue20395] Extract generated clinic code in Modules/_pickle.c to separate file In-Reply-To: <1390734339.8.0.0968166670001.issue20395@psf.upfronthosting.co.za> Message-ID: <1390735807.4.0.0101360699592.issue20395@psf.upfronthosting.co.za> Larry Hastings added the comment: Alexandre: We're still figuring out best practices with Argument Clinic. So, right now, there's no standard policy of "where should we put all the generated code?", and we're leaving it up to the owners of the individual modules. Putting it in a second file and #including it is a popular option, but there are other options too (and Guido says he hates code generators that put stuff in a second file). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 12:32:02 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 26 Jan 2014 11:32:02 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1390735922.42.0.648200788092.issue20193@psf.upfronthosting.co.za> Larry Hastings added the comment: We're not allowing changes in semantics for Argument Clinic conversion for 3.4. If it doesn't currently accept None, we can't add it right now, and we'll have to save it for 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 12:43:35 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 26 Jan 2014 11:43:35 +0000 Subject: [issue15759] "make suspicious" doesn't display instructions in case of failure In-Reply-To: <1345613663.78.0.519613331574.issue15759@psf.upfronthosting.co.za> Message-ID: <1390736615.24.0.312171209313.issue15759@psf.upfronthosting.co.za> Larry Hastings added the comment: I nominate this text: ********************************************************************** To make these errors go away, merge the contents of "build/suspicious/suspicious.csv" to "tools/sphinxext/susp-ignored.csv". ********************************************************************** Alternatively, we could add a "make trustworthy" target that did this work automatically, in which case the text should be ********************************************************************** To make these errors go away, run "make trustworthy". ********************************************************************** ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 13:05:23 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 12:05:23 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1390735706.12.0.691539467908.issue20193@psf.upfronthosting.co.za> Message-ID: <2429664.E1ABzK5tGP@raxxla> Serhiy Storchaka added the comment: Ah, sorry, here is full patch. Generated file is now named Modules/clinic/zlibmodule.c.h. The behavior is preserved. This case is exact analogue of _sha1.sha1(). No one additional function called when the parameter is not specified, but if it is specified as b'', the function behaves identically to not passing in that parameter. ---------- Added file: http://bugs.python.org/file33723/zlib_clinic_3.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 0ae768637a07 Modules/clinic/zlibmodule.c.h --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Modules/clinic/zlibmodule.c.h Sun Jan 26 13:43:32 2014 +0200 @@ -0,0 +1,411 @@ +/*[clinic input] +preserve +[clinic start generated code]*/ + +PyDoc_STRVAR(zlib_compress__doc__, +"compress(module, bytes, level=Z_DEFAULT_COMPRESSION)\n" +"Returns a bytes object containing compressed data.\n" +"\n" +" bytes\n" +" Binary data to be compressed.\n" +" level\n" +" Compression level, in 0-9."); + +#define ZLIB_COMPRESS_METHODDEF \ + {"compress", (PyCFunction)zlib_compress, METH_VARARGS, zlib_compress__doc__}, + +static PyObject * +zlib_compress_impl(PyModuleDef *module, Py_buffer *bytes, int level); + +static PyObject * +zlib_compress(PyModuleDef *module, PyObject *args) +{ + PyObject *return_value = NULL; + Py_buffer bytes = {NULL, NULL}; + int level = Z_DEFAULT_COMPRESSION; + + if (!PyArg_ParseTuple(args, + "y*|i:compress", + &bytes, &level)) + goto exit; + return_value = zlib_compress_impl(module, &bytes, level); + +exit: + /* Cleanup for bytes */ + if (bytes.obj) + PyBuffer_Release(&bytes); + + return return_value; +} + +PyDoc_STRVAR(zlib_decompress__doc__, +"decompress(module, data, wbits=MAX_WBITS, bufsize=DEF_BUF_SIZE)\n" +"Returns a bytes object containing the uncompressed data.\n" +"\n" +" data\n" +" Compressed data.\n" +" wbits\n" +" The window buffer size.\n" +" bufsize\n" +" The initial output buffer size."); + +#define ZLIB_DECOMPRESS_METHODDEF \ + {"decompress", (PyCFunction)zlib_decompress, METH_VARARGS, zlib_decompress__doc__}, + +static PyObject * +zlib_decompress_impl(PyModuleDef *module, Py_buffer *data, int wbits, unsigned int bufsize); + +static PyObject * +zlib_decompress(PyModuleDef *module, PyObject *args) +{ + PyObject *return_value = NULL; + Py_buffer data = {NULL, NULL}; + int wbits = MAX_WBITS; + unsigned int bufsize = DEF_BUF_SIZE; + + if (!PyArg_ParseTuple(args, + "y*|iO&:decompress", + &data, &wbits, uint_converter, &bufsize)) + goto exit; + return_value = zlib_decompress_impl(module, &data, wbits, bufsize); + +exit: + /* Cleanup for data */ + if (data.obj) + PyBuffer_Release(&data); + + return return_value; +} + +PyDoc_STRVAR(zlib_compressobj__doc__, +"compressobj(module, level=Z_DEFAULT_COMPRESSION, method=DEFLATED, wbits=MAX_WBITS, memLevel=DEF_MEM_LEVEL, strategy=Z_DEFAULT_STRATEGY, zdict=None)\n" +"Return a compressor object.\n" +"\n" +" level\n" +" The compression level (an integer in the range 0-9; default is 6).\n" +" Higher compression levels are slower, but produce smaller results.\n" +" method\n" +" The compression algorithm. If given, this must be DEFLATED.\n" +" wbits\n" +" The base two logarithm of the window size (range: 8..15).\n" +" memLevel\n" +" Controls the amount of memory used for internal compression state.\n" +" Valid values range from 1 to 9. Higher values result in higher memory\n" +" usage, faster compression, and smaller output.\n" +" strategy\n" +" Used to tune the compression algorithm. Possible values are\n" +" Z_DEFAULT_STRATEGY, Z_FILTERED, and Z_HUFFMAN_ONLY.\n" +" zdict\n" +" The predefined compression dictionary - a sequence of bytes\n" +" containing subsequences that are likely to occur in the input data."); + +#define ZLIB_COMPRESSOBJ_METHODDEF \ + {"compressobj", (PyCFunction)zlib_compressobj, METH_VARARGS|METH_KEYWORDS, zlib_compressobj__doc__}, + +static PyObject * +zlib_compressobj_impl(PyModuleDef *module, int level, int method, int wbits, int memLevel, int strategy, Py_buffer *zdict); + +static PyObject * +zlib_compressobj(PyModuleDef *module, PyObject *args, PyObject *kwargs) +{ + PyObject *return_value = NULL; + static char *_keywords[] = {"level", "method", "wbits", "memLevel", "strategy", "zdict", NULL}; + int level = Z_DEFAULT_COMPRESSION; + int method = DEFLATED; + int wbits = MAX_WBITS; + int memLevel = DEF_MEM_LEVEL; + int strategy = Z_DEFAULT_STRATEGY; + Py_buffer zdict = {NULL, NULL}; + + if (!PyArg_ParseTupleAndKeywords(args, kwargs, + "|iiiiiy*:compressobj", _keywords, + &level, &method, &wbits, &memLevel, &strategy, &zdict)) + goto exit; + return_value = zlib_compressobj_impl(module, level, method, wbits, memLevel, strategy, &zdict); + +exit: + /* Cleanup for zdict */ + if (zdict.obj) + PyBuffer_Release(&zdict); + + return return_value; +} + +PyDoc_STRVAR(zlib_decompressobj__doc__, +"decompressobj(module, wbits=MAX_WBITS, zdict=b\'\')\n" +"Return a decompressor object.\n" +"\n" +" wbits\n" +" The window buffer size.\n" +" zdict\n" +" The predefined compression dictionary. This must be the same\n" +" dictionary as used by the compressor that produced the input data."); + +#define ZLIB_DECOMPRESSOBJ_METHODDEF \ + {"decompressobj", (PyCFunction)zlib_decompressobj, METH_VARARGS|METH_KEYWORDS, zlib_decompressobj__doc__}, + +static PyObject * +zlib_decompressobj_impl(PyModuleDef *module, int wbits, PyObject *zdict); + +static PyObject * +zlib_decompressobj(PyModuleDef *module, PyObject *args, PyObject *kwargs) +{ + PyObject *return_value = NULL; + static char *_keywords[] = {"wbits", "zdict", NULL}; + int wbits = MAX_WBITS; + PyObject *zdict = NULL; + + if (!PyArg_ParseTupleAndKeywords(args, kwargs, + "|iO:decompressobj", _keywords, + &wbits, &zdict)) + goto exit; + return_value = zlib_decompressobj_impl(module, wbits, zdict); + +exit: + return return_value; +} + +PyDoc_STRVAR(zlib_Compress_compress__doc__, +"compress(self, data)\n" +"Returns a bytes object containing compressed data.\n" +"\n" +" data\n" +" Binary data to be compressed.\n" +"\n" +"After calling this function, some of the input data may still\n" +"be stored in internal buffers for later processing.\n" +"Call the flush() method to clear these buffers."); + +#define ZLIB_COMPRESS_COMPRESS_METHODDEF \ + {"compress", (PyCFunction)zlib_Compress_compress, METH_VARARGS, zlib_Compress_compress__doc__}, + +static PyObject * +zlib_Compress_compress_impl(compobject *self, Py_buffer *data); + +static PyObject * +zlib_Compress_compress(compobject *self, PyObject *args) +{ + PyObject *return_value = NULL; + Py_buffer data = {NULL, NULL}; + + if (!PyArg_ParseTuple(args, + "y*:compress", + &data)) + goto exit; + return_value = zlib_Compress_compress_impl(self, &data); + +exit: + /* Cleanup for data */ + if (data.obj) + PyBuffer_Release(&data); + + return return_value; +} + +PyDoc_STRVAR(zlib_Decompress_decompress__doc__, +"decompress(self, data, max_length=0)\n" +"Return a bytes object containing the decompressed version of the data.\n" +"\n" +" data\n" +" The binary data to decompress.\n" +" max_length\n" +" The maximum allowable length of the decompressed data.\n" +" Unconsumed input data will be stored in\n" +" the unconsumed_tail attribute.\n" +"\n" +"After calling this function, some of the input data may still be stored in\n" +"internal buffers for later processing.\n" +"Call the flush() method to clear these buffers."); + +#define ZLIB_DECOMPRESS_DECOMPRESS_METHODDEF \ + {"decompress", (PyCFunction)zlib_Decompress_decompress, METH_VARARGS, zlib_Decompress_decompress__doc__}, + +static PyObject * +zlib_Decompress_decompress_impl(compobject *self, Py_buffer *data, unsigned int max_length); + +static PyObject * +zlib_Decompress_decompress(compobject *self, PyObject *args) +{ + PyObject *return_value = NULL; + Py_buffer data = {NULL, NULL}; + unsigned int max_length = 0; + + if (!PyArg_ParseTuple(args, + "y*|O&:decompress", + &data, uint_converter, &max_length)) + goto exit; + return_value = zlib_Decompress_decompress_impl(self, &data, max_length); + +exit: + /* Cleanup for data */ + if (data.obj) + PyBuffer_Release(&data); + + return return_value; +} + +PyDoc_STRVAR(zlib_Compress_flush__doc__, +"flush(self, mode=Z_FINISH)\n" +"Return a bytes object containing any remaining compressed data.\n" +"\n" +" mode\n" +" One of the constants Z_SYNC_FLUSH, Z_FULL_FLUSH, Z_FINISH.\n" +" If mode == Z_FINISH, the compressor object can no longer be\n" +" used after calling the flush() method. Otherwise, more data\n" +" can still be compressed."); + +#define ZLIB_COMPRESS_FLUSH_METHODDEF \ + {"flush", (PyCFunction)zlib_Compress_flush, METH_VARARGS, zlib_Compress_flush__doc__}, + +static PyObject * +zlib_Compress_flush_impl(compobject *self, int mode); + +static PyObject * +zlib_Compress_flush(compobject *self, PyObject *args) +{ + PyObject *return_value = NULL; + int mode = Z_FINISH; + + if (!PyArg_ParseTuple(args, + "|i:flush", + &mode)) + goto exit; + return_value = zlib_Compress_flush_impl(self, mode); + +exit: + return return_value; +} + +PyDoc_STRVAR(zlib_Compress_copy__doc__, +"copy(self)\n" +"Return a copy of the compression object."); + +#define ZLIB_COMPRESS_COPY_METHODDEF \ + {"copy", (PyCFunction)zlib_Compress_copy, METH_NOARGS, zlib_Compress_copy__doc__}, + +static PyObject * +zlib_Compress_copy_impl(compobject *self); + +static PyObject * +zlib_Compress_copy(compobject *self, PyObject *Py_UNUSED(ignored)) +{ + return zlib_Compress_copy_impl(self); +} + +PyDoc_STRVAR(zlib_Decompress_copy__doc__, +"copy(self)\n" +"Return a copy of the decompression object."); + +#define ZLIB_DECOMPRESS_COPY_METHODDEF \ + {"copy", (PyCFunction)zlib_Decompress_copy, METH_NOARGS, zlib_Decompress_copy__doc__}, + +static PyObject * +zlib_Decompress_copy_impl(compobject *self); + +static PyObject * +zlib_Decompress_copy(compobject *self, PyObject *Py_UNUSED(ignored)) +{ + return zlib_Decompress_copy_impl(self); +} + +PyDoc_STRVAR(zlib_Decompress_flush__doc__, +"flush(self, length=DEF_BUF_SIZE)\n" +"Return a bytes object containing any remaining decompressed data.\n" +"\n" +" length\n" +" the initial size of the output buffer."); + +#define ZLIB_DECOMPRESS_FLUSH_METHODDEF \ + {"flush", (PyCFunction)zlib_Decompress_flush, METH_VARARGS, zlib_Decompress_flush__doc__}, + +static PyObject * +zlib_Decompress_flush_impl(compobject *self, unsigned int length); + +static PyObject * +zlib_Decompress_flush(compobject *self, PyObject *args) +{ + PyObject *return_value = NULL; + unsigned int length = DEF_BUF_SIZE; + + if (!PyArg_ParseTuple(args, + "|O&:flush", + uint_converter, &length)) + goto exit; + return_value = zlib_Decompress_flush_impl(self, length); + +exit: + return return_value; +} + +PyDoc_STRVAR(zlib_adler32__doc__, +"adler32(module, data, value=1)\n" +"Compute an Adler-32 checksum of data.\n" +"\n" +" value\n" +" Starting value of the checksum.\n" +"\n" +"The returned checksum is an integer."); + +#define ZLIB_ADLER32_METHODDEF \ + {"adler32", (PyCFunction)zlib_adler32, METH_VARARGS, zlib_adler32__doc__}, + +static PyObject * +zlib_adler32_impl(PyModuleDef *module, Py_buffer *data, unsigned int value); + +static PyObject * +zlib_adler32(PyModuleDef *module, PyObject *args) +{ + PyObject *return_value = NULL; + Py_buffer data = {NULL, NULL}; + unsigned int value = 1; + + if (!PyArg_ParseTuple(args, + "y*|I:adler32", + &data, &value)) + goto exit; + return_value = zlib_adler32_impl(module, &data, value); + +exit: + /* Cleanup for data */ + if (data.obj) + PyBuffer_Release(&data); + + return return_value; +} + +PyDoc_STRVAR(zlib_crc32__doc__, +"crc32(module, data, value=0)\n" +"Compute a CRC-32 checksum of data.\n" +"\n" +" value\n" +" Starting value of the checksum.\n" +"\n" +"The returned checksum is an integer."); + +#define ZLIB_CRC32_METHODDEF \ + {"crc32", (PyCFunction)zlib_crc32, METH_VARARGS, zlib_crc32__doc__}, + +static PyObject * +zlib_crc32_impl(PyModuleDef *module, Py_buffer *data, unsigned int value); + +static PyObject * +zlib_crc32(PyModuleDef *module, PyObject *args) +{ + PyObject *return_value = NULL; + Py_buffer data = {NULL, NULL}; + unsigned int value = 0; + + if (!PyArg_ParseTuple(args, + "y*|I:crc32", + &data, &value)) + goto exit; + return_value = zlib_crc32_impl(module, &data, value); + +exit: + /* Cleanup for data */ + if (data.obj) + PyBuffer_Release(&data); + + return return_value; +} +/*[clinic end generated code: checksum=04f94bbaf2652717753e237e4021bf6c92ddffdd]*/ diff -r 0ae768637a07 Modules/zlibmodule.c --- a/Modules/zlibmodule.c Sat Jan 25 22:19:47 2014 -0800 +++ b/Modules/zlibmodule.c Sun Jan 26 13:43:32 2014 +0200 @@ -28,10 +28,9 @@ #else # define DEF_MEM_LEVEL MAX_MEM_LEVEL #endif -#define DEF_WBITS MAX_WBITS -/* The output buffer will be increased in chunks of DEFAULTALLOC bytes. */ -#define DEFAULTALLOC (16*1024) +/* Initial buffer size. */ +#define DEF_BUF_SIZE (16*1024) static PyTypeObject Comptype; static PyTypeObject Decomptype; @@ -82,42 +81,13 @@ } /*[clinic input] +output preset file module zlib class zlib.Compress "compobject *" "&Comptype" class zlib.Decompress "compobject *" "&Decomptype" [clinic start generated code]*/ /*[clinic end generated code: checksum=da39a3ee5e6b4b0d3255bfef95601890afd80709]*/ -PyDoc_STRVAR(compressobj__doc__, -"compressobj(level=-1, method=DEFLATED, wbits=15, memlevel=8,\n" -" strategy=Z_DEFAULT_STRATEGY[, zdict])\n" -" -- Return a compressor object.\n" -"\n" -"level is the compression level (an integer in the range 0-9; default is 6).\n" -"Higher compression levels are slower, but produce smaller results.\n" -"\n" -"method is the compression algorithm. If given, this must be DEFLATED.\n" -"\n" -"wbits is the base two logarithm of the window size (range: 8..15).\n" -"\n" -"memlevel controls the amount of memory used for internal compression state.\n" -"Valid values range from 1 to 9. Higher values result in higher memory usage,\n" -"faster compression, and smaller output.\n" -"\n" -"strategy is used to tune the compression algorithm. Possible values are\n" -"Z_DEFAULT_STRATEGY, Z_FILTERED, and Z_HUFFMAN_ONLY.\n" -"\n" -"zdict is the predefined compression dictionary - a sequence of bytes\n" -"containing subsequences that are likely to occur in the input data."); - -PyDoc_STRVAR(decompressobj__doc__, -"decompressobj([wbits[, zdict]]) -- Return a decompressor object.\n" -"\n" -"Optional arg wbits is the window buffer size.\n" -"\n" -"Optional arg zdict is the predefined compression dictionary. This must be\n" -"the same dictionary as used by the compressor that produced the input data."); - static compobject * newcompobject(PyTypeObject *type) { @@ -165,70 +135,20 @@ } /*[clinic input] +zlib.compress -zlib.compress bytes: Py_buffer Binary data to be compressed. - [ - level: int + level: int(c_default="Z_DEFAULT_COMPRESSION") = Z_DEFAULT_COMPRESSION Compression level, in 0-9. - ] / -Returns compressed string. - +Returns a bytes object containing compressed data. [clinic start generated code]*/ -PyDoc_STRVAR(zlib_compress__doc__, -"compress(module, bytes, [level])\n" -"Returns compressed string.\n" -"\n" -" bytes\n" -" Binary data to be compressed.\n" -" level\n" -" Compression level, in 0-9."); - -#define ZLIB_COMPRESS_METHODDEF \ - {"compress", (PyCFunction)zlib_compress, METH_VARARGS, zlib_compress__doc__}, - static PyObject * -zlib_compress_impl(PyModuleDef *module, Py_buffer *bytes, int group_right_1, int level); - -static PyObject * -zlib_compress(PyModuleDef *module, PyObject *args) -{ - PyObject *return_value = NULL; - Py_buffer bytes = {NULL, NULL}; - int group_right_1 = 0; - int level = 0; - - switch (PyTuple_GET_SIZE(args)) { - case 1: - if (!PyArg_ParseTuple(args, "y*:compress", &bytes)) - goto exit; - break; - case 2: - if (!PyArg_ParseTuple(args, "y*i:compress", &bytes, &level)) - goto exit; - group_right_1 = 1; - break; - default: - PyErr_SetString(PyExc_TypeError, "zlib.compress requires 1 to 2 arguments"); - goto exit; - } - return_value = zlib_compress_impl(module, &bytes, group_right_1, level); - -exit: - /* Cleanup for bytes */ - if (bytes.obj) - PyBuffer_Release(&bytes); - - return return_value; -} - -static PyObject * -zlib_compress_impl(PyModuleDef *module, Py_buffer *bytes, int group_right_1, int level) -/*[clinic end generated code: checksum=ce8d4c0a17ecd79c3ffcc032dcdf8ac6830ded1e]*/ +zlib_compress_impl(PyModuleDef *module, Py_buffer *bytes, int level) +/*[clinic end generated code: checksum=5d7dd4588788efd3516e5f4225050d6413632601]*/ { PyObject *ReturnVal = NULL; Byte *input, *output = NULL; @@ -236,9 +156,6 @@ int err; z_stream zst; - if (!group_right_1) - level = Z_DEFAULT_COMPRESSION; - if ((size_t)bytes->len > UINT_MAX) { PyErr_SetString(PyExc_OverflowError, "Size does not fit in an unsigned int"); @@ -312,6 +229,7 @@ class uint_converter(CConverter): type = 'unsigned int' converter = 'uint_converter' + c_ignored_default = "0" [python start generated code]*/ /*[python end generated code: checksum=da39a3ee5e6b4b0d3255bfef95601890afd80709]*/ @@ -347,35 +265,38 @@ return 1; } -PyDoc_STRVAR(decompress__doc__, -"decompress(string[, wbits[, bufsize]]) -- Return decompressed string.\n" -"\n" -"Optional arg wbits is the window buffer size. Optional arg bufsize is\n" -"the initial output buffer size."); +/*[clinic input] +zlib.decompress + + data: Py_buffer + Compressed data. + wbits: int(c_default="MAX_WBITS") = MAX_WBITS + The window buffer size. + bufsize: uint(c_default="DEF_BUF_SIZE") = DEF_BUF_SIZE + The initial output buffer size. + / + +Returns a bytes object containing the uncompressed data. +[clinic start generated code]*/ static PyObject * -PyZlib_decompress(PyObject *self, PyObject *args) +zlib_decompress_impl(PyModuleDef *module, Py_buffer *data, int wbits, unsigned int bufsize) +/*[clinic end generated code: checksum=9e5464e72df9cb5fee73df662dbcaed867e01d32]*/ { PyObject *result_str = NULL; - Py_buffer pinput; Byte *input; unsigned int length; int err; - int wsize=DEF_WBITS; - unsigned int bufsize = DEFAULTALLOC, new_bufsize; + unsigned int new_bufsize; z_stream zst; - if (!PyArg_ParseTuple(args, "y*|iO&:decompress", - &pinput, &wsize, uint_converter, &bufsize)) - return NULL; - - if ((size_t)pinput.len > UINT_MAX) { + if ((size_t)data->len > UINT_MAX) { PyErr_SetString(PyExc_OverflowError, "Size does not fit in an unsigned int"); goto error; } - input = pinput.buf; - length = (unsigned int)pinput.len; + input = data->buf; + length = (unsigned int)data->len; if (bufsize == 0) bufsize = 1; @@ -391,7 +312,7 @@ zst.zfree = PyZlib_Free; zst.next_out = (Byte *)PyBytes_AS_STRING(result_str); zst.next_in = (Byte *)input; - err = inflateInit2(&zst, wsize); + err = inflateInit2(&zst, wbits); switch(err) { case(Z_OK): @@ -457,32 +378,45 @@ if (_PyBytes_Resize(&result_str, zst.total_out) < 0) goto error; - PyBuffer_Release(&pinput); return result_str; error: - PyBuffer_Release(&pinput); Py_XDECREF(result_str); return NULL; } +/*[clinic input] +zlib.compressobj + + level: int(c_default="Z_DEFAULT_COMPRESSION") = Z_DEFAULT_COMPRESSION + The compression level (an integer in the range 0-9; default is 6). + Higher compression levels are slower, but produce smaller results. + method: int(c_default="DEFLATED") = DEFLATED + The compression algorithm. If given, this must be DEFLATED. + wbits: int(c_default="MAX_WBITS") = MAX_WBITS + The base two logarithm of the window size (range: 8..15). + memLevel: int(c_default="DEF_MEM_LEVEL") = DEF_MEM_LEVEL + Controls the amount of memory used for internal compression state. + Valid values range from 1 to 9. Higher values result in higher memory + usage, faster compression, and smaller output. + strategy: int(c_default="Z_DEFAULT_STRATEGY") = Z_DEFAULT_STRATEGY + Used to tune the compression algorithm. Possible values are + Z_DEFAULT_STRATEGY, Z_FILTERED, and Z_HUFFMAN_ONLY. + zdict: Py_buffer = None + The predefined compression dictionary - a sequence of bytes + containing subsequences that are likely to occur in the input data. + +Return a compressor object. +[clinic start generated code]*/ + static PyObject * -PyZlib_compressobj(PyObject *selfptr, PyObject *args, PyObject *kwargs) +zlib_compressobj_impl(PyModuleDef *module, int level, int method, int wbits, int memLevel, int strategy, Py_buffer *zdict) +/*[clinic end generated code: checksum=89e5a6c1449caa9ed76f1baad066600e985151a9]*/ { compobject *self = NULL; - int level=Z_DEFAULT_COMPRESSION, method=DEFLATED; - int wbits=MAX_WBITS, memLevel=DEF_MEM_LEVEL, strategy=0, err; - Py_buffer zdict; - static char *kwlist[] = {"level", "method", "wbits", - "memLevel", "strategy", "zdict", NULL}; + int err; - zdict.buf = NULL; /* Sentinel, so we can tell whether zdict was supplied. */ - if (!PyArg_ParseTupleAndKeywords(args, kwargs, "|iiiiiy*:compressobj", - kwlist, &level, &method, &wbits, - &memLevel, &strategy, &zdict)) - return NULL; - - if (zdict.buf != NULL && (size_t)zdict.len > UINT_MAX) { + if (zdict->buf != NULL && (size_t)zdict->len > UINT_MAX) { PyErr_SetString(PyExc_OverflowError, "zdict length does not fit in an unsigned int"); goto error; @@ -500,11 +434,11 @@ switch(err) { case (Z_OK): self->is_initialised = 1; - if (zdict.buf == NULL) { + if (zdict->buf == NULL) { goto success; } else { err = deflateSetDictionary(&self->zst, - zdict.buf, (unsigned int)zdict.len); + zdict->buf, (unsigned int)zdict->len); switch (err) { case (Z_OK): goto success; @@ -532,22 +466,28 @@ Py_XDECREF(self); self = NULL; success: - if (zdict.buf != NULL) - PyBuffer_Release(&zdict); return (PyObject*)self; } +/*[clinic input] +zlib.decompressobj + + wbits: int(c_default="MAX_WBITS") = MAX_WBITS + The window buffer size. + zdict: object(c_default="NULL") = b'' + The predefined compression dictionary. This must be the same + dictionary as used by the compressor that produced the input data. + +Return a decompressor object. +[clinic start generated code]*/ + static PyObject * -PyZlib_decompressobj(PyObject *selfptr, PyObject *args, PyObject *kwargs) +zlib_decompressobj_impl(PyModuleDef *module, int wbits, PyObject *zdict) +/*[clinic end generated code: checksum=8ccd583fbd631798566d415933cd44440c8a74b5]*/ { - static char *kwlist[] = {"wbits", "zdict", NULL}; - int wbits=DEF_WBITS, err; + int err; compobject *self; - PyObject *zdict=NULL; - if (!PyArg_ParseTupleAndKeywords(args, kwargs, "|iO:decompressobj", - kwlist, &wbits, &zdict)) - return NULL; if (zdict != NULL && !PyObject_CheckBuffer(zdict)) { PyErr_SetString(PyExc_TypeError, "zdict argument must support the buffer protocol"); @@ -615,37 +555,41 @@ Dealloc(self); } -PyDoc_STRVAR(comp_compress__doc__, -"compress(data) -- Return a string containing data compressed.\n" -"\n" -"After calling this function, some of the input data may still\n" -"be stored in internal buffers for later processing.\n" -"Call the flush() method to clear these buffers."); +/*[clinic input] +zlib.Compress.compress + data: Py_buffer + Binary data to be compressed. + / + +Returns a bytes object containing compressed data. + +After calling this function, some of the input data may still +be stored in internal buffers for later processing. +Call the flush() method to clear these buffers. +[clinic start generated code]*/ static PyObject * -PyZlib_objcompress(compobject *self, PyObject *args) +zlib_Compress_compress_impl(compobject *self, Py_buffer *data) +/*[clinic end generated code: checksum=5d5cd791cbc6a7f4b6de4ec12c085c88d4d3e31c]*/ { int err; unsigned int inplen; - unsigned int length = DEFAULTALLOC, new_length; - PyObject *RetVal = NULL; - Py_buffer pinput; + unsigned int length = DEF_BUF_SIZE, new_length; + PyObject *RetVal; Byte *input; unsigned long start_total_out; - if (!PyArg_ParseTuple(args, "y*:compress", &pinput)) - return NULL; - if ((size_t)pinput.len > UINT_MAX) { + if ((size_t)data->len > UINT_MAX) { PyErr_SetString(PyExc_OverflowError, "Size does not fit in an unsigned int"); - goto error_outer; + return NULL; } - input = pinput.buf; - inplen = (unsigned int)pinput.len; + input = data->buf; + inplen = (unsigned int)data->len; if (!(RetVal = PyBytes_FromStringAndSize(NULL, length))) - goto error_outer; + return NULL; ENTER_ZLIB(self); @@ -668,7 +612,7 @@ new_length = UINT_MAX; if (_PyBytes_Resize(&RetVal, new_length) < 0) { Py_CLEAR(RetVal); - goto error; + goto done; } self->zst.next_out = (unsigned char *)PyBytes_AS_STRING(RetVal) + length; @@ -686,18 +630,15 @@ if (err != Z_OK && err != Z_BUF_ERROR) { zlib_error(self->zst, err, "while compressing data"); - Py_DECREF(RetVal); - RetVal = NULL; - goto error; + Py_CLEAR(RetVal); + goto done; } if (_PyBytes_Resize(&RetVal, self->zst.total_out - start_total_out) < 0) { Py_CLEAR(RetVal); } - error: + done: LEAVE_ZLIB(self); - error_outer: - PyBuffer_Release(&pinput); return RetVal; } @@ -745,7 +686,6 @@ } /*[clinic input] - zlib.Decompress.decompress data: Py_buffer @@ -756,61 +696,19 @@ the unconsumed_tail attribute. / -Return a string containing the decompressed version of the data. +Return a bytes object containing the decompressed version of the data. After calling this function, some of the input data may still be stored in internal buffers for later processing. Call the flush() method to clear these buffers. [clinic start generated code]*/ -PyDoc_STRVAR(zlib_Decompress_decompress__doc__, -"decompress(self, data, max_length=0)\n" -"Return a string containing the decompressed version of the data.\n" -"\n" -" data\n" -" The binary data to decompress.\n" -" max_length\n" -" The maximum allowable length of the decompressed data.\n" -" Unconsumed input data will be stored in\n" -" the unconsumed_tail attribute.\n" -"\n" -"After calling this function, some of the input data may still be stored in\n" -"internal buffers for later processing.\n" -"Call the flush() method to clear these buffers."); - -#define ZLIB_DECOMPRESS_DECOMPRESS_METHODDEF \ - {"decompress", (PyCFunction)zlib_Decompress_decompress, METH_VARARGS, zlib_Decompress_decompress__doc__}, - -static PyObject * -zlib_Decompress_decompress_impl(compobject *self, Py_buffer *data, unsigned int max_length); - -static PyObject * -zlib_Decompress_decompress(compobject *self, PyObject *args) -{ - PyObject *return_value = NULL; - Py_buffer data = {NULL, NULL}; - unsigned int max_length = 0; - - if (!PyArg_ParseTuple(args, - "y*|O&:decompress", - &data, uint_converter, &max_length)) - goto exit; - return_value = zlib_Decompress_decompress_impl(self, &data, max_length); - -exit: - /* Cleanup for data */ - if (data.obj) - PyBuffer_Release(&data); - - return return_value; -} - static PyObject * zlib_Decompress_decompress_impl(compobject *self, Py_buffer *data, unsigned int max_length) -/*[clinic end generated code: checksum=b7fd2e3b23430f57f5a84817189575bc46464901]*/ +/*[clinic end generated code: checksum=755cccc9087bfe55486b7e15fa7e2ab60b4c86d6]*/ { int err; - unsigned int old_length, length = DEFAULTALLOC; + unsigned int old_length, length = DEF_BUF_SIZE; PyObject *RetVal = NULL; unsigned long start_total_out; @@ -927,29 +825,31 @@ return RetVal; } -PyDoc_STRVAR(comp_flush__doc__, -"flush( [mode] ) -- Return a string containing any remaining compressed data.\n" -"\n" -"mode can be one of the constants Z_SYNC_FLUSH, Z_FULL_FLUSH, Z_FINISH; the\n" -"default value used when mode is not specified is Z_FINISH.\n" -"If mode == Z_FINISH, the compressor object can no longer be used after\n" -"calling the flush() method. Otherwise, more data can still be compressed."); +/*[clinic input] +zlib.Compress.flush + + mode: int(c_default="Z_FINISH") = Z_FINISH + One of the constants Z_SYNC_FLUSH, Z_FULL_FLUSH, Z_FINISH. + If mode == Z_FINISH, the compressor object can no longer be + used after calling the flush() method. Otherwise, more data + can still be compressed. + / + +Return a bytes object containing any remaining compressed data. +[clinic start generated code]*/ static PyObject * -PyZlib_flush(compobject *self, PyObject *args) +zlib_Compress_flush_impl(compobject *self, int mode) +/*[clinic end generated code: checksum=a203f4cefc9de727aa1d2ea39d11c0a16c32041a]*/ { int err; - unsigned int length = DEFAULTALLOC, new_length; + unsigned int length = DEF_BUF_SIZE, new_length; PyObject *RetVal; - int flushmode = Z_FINISH; unsigned long start_total_out; - if (!PyArg_ParseTuple(args, "|i:flush", &flushmode)) - return NULL; - /* Flushing with Z_NO_FLUSH is a no-op, so there's no point in doing any work at all; just return an empty string. */ - if (flushmode == Z_NO_FLUSH) { + if (mode == Z_NO_FLUSH) { return PyBytes_FromStringAndSize(NULL, 0); } @@ -964,7 +864,7 @@ self->zst.next_out = (unsigned char *)PyBytes_AS_STRING(RetVal); Py_BEGIN_ALLOW_THREADS - err = deflate(&(self->zst), flushmode); + err = deflate(&(self->zst), mode); Py_END_ALLOW_THREADS /* while Z_OK and the output buffer is full, there might be more output, @@ -984,14 +884,14 @@ length = new_length; Py_BEGIN_ALLOW_THREADS - err = deflate(&(self->zst), flushmode); + err = deflate(&(self->zst), mode); Py_END_ALLOW_THREADS } - /* If flushmode is Z_FINISH, we also have to call deflateEnd() to free + /* If mode is Z_FINISH, we also have to call deflateEnd() to free various data structures. Note we should only get Z_STREAM_END when - flushmode is Z_FINISH, but checking both for safety*/ - if (err == Z_STREAM_END && flushmode == Z_FINISH) { + mode is Z_FINISH, but checking both for safety*/ + if (err == Z_STREAM_END && mode == Z_FINISH) { err = deflateEnd(&(self->zst)); if (err != Z_OK) { zlib_error(self->zst, err, "while finishing compression"); @@ -1031,25 +931,9 @@ Return a copy of the compression object. [clinic start generated code]*/ -PyDoc_STRVAR(zlib_Compress_copy__doc__, -"copy(self)\n" -"Return a copy of the compression object."); - -#define ZLIB_COMPRESS_COPY_METHODDEF \ - {"copy", (PyCFunction)zlib_Compress_copy, METH_NOARGS, zlib_Compress_copy__doc__}, - -static PyObject * -zlib_Compress_copy_impl(compobject *self); - -static PyObject * -zlib_Compress_copy(compobject *self, PyObject *Py_UNUSED(ignored)) -{ - return zlib_Compress_copy_impl(self); -} - static PyObject * zlib_Compress_copy_impl(compobject *self) -/*[clinic end generated code: checksum=7aa841ad51297eb83250f511a76872e88fdc737e]*/ +/*[clinic end generated code: checksum=5144aa153c21e805afa5c19e5b48cf8e6480b5da]*/ { compobject *retval = NULL; int err; @@ -1099,11 +983,15 @@ return NULL; } -PyDoc_STRVAR(decomp_copy__doc__, -"copy() -- Return a copy of the decompression object."); +/*[clinic input] +zlib.Decompress.copy + +Return a copy of the decompression object. +[clinic start generated code]*/ static PyObject * -PyZlib_uncopy(compobject *self) +zlib_Decompress_copy_impl(compobject *self) +/*[clinic end generated code: checksum=02a883a2a510c8ccfeef3f89e317a275bfe8c094]*/ { compobject *retval = NULL; int err; @@ -1155,24 +1043,26 @@ } #endif -PyDoc_STRVAR(decomp_flush__doc__, -"flush( [length] ) -- Return a string containing any remaining\n" -"decompressed data. length, if given, is the initial size of the\n" -"output buffer.\n" -"\n" -"The decompressor object can no longer be used after this call."); +/*[clinic input] +zlib.Decompress.flush + + length: uint(c_default="DEF_BUF_SIZE") = DEF_BUF_SIZE + the initial size of the output buffer. + / + +Return a bytes object containing any remaining decompressed data. +[clinic start generated code]*/ static PyObject * -PyZlib_unflush(compobject *self, PyObject *args) +zlib_Decompress_flush_impl(compobject *self, unsigned int length) +/*[clinic end generated code: checksum=db6fb753ab698e22afe3957c9da9e5e77f4bfc08]*/ { int err; - unsigned int length = DEFAULTALLOC, new_length; + unsigned int new_length; PyObject * retval = NULL; unsigned long start_total_out; Py_ssize_t size; - if (!PyArg_ParseTuple(args, "|O&:flush", uint_converter, &length)) - return NULL; if (length == 0) { PyErr_SetString(PyExc_ValueError, "length must be greater than zero"); return NULL; @@ -1248,12 +1138,12 @@ return retval; } +#include "zlibmodule.clinic.c" + static PyMethodDef comp_methods[] = { - {"compress", (binaryfunc)PyZlib_objcompress, METH_VARARGS, - comp_compress__doc__}, - {"flush", (binaryfunc)PyZlib_flush, METH_VARARGS, - comp_flush__doc__}, + ZLIB_COMPRESS_COMPRESS_METHODDEF + ZLIB_COMPRESS_FLUSH_METHODDEF #ifdef HAVE_ZLIB_COPY ZLIB_COMPRESS_COPY_METHODDEF #endif @@ -1263,11 +1153,9 @@ static PyMethodDef Decomp_methods[] = { ZLIB_DECOMPRESS_DECOMPRESS_METHODDEF - {"flush", (binaryfunc)PyZlib_unflush, METH_VARARGS, - decomp_flush__doc__}, + ZLIB_DECOMPRESS_FLUSH_METHODDEF #ifdef HAVE_ZLIB_COPY - {"copy", (PyCFunction)PyZlib_uncopy, METH_NOARGS, - decomp_copy__doc__}, + ZLIB_DECOMPRESS_COPY_METHODDEF #endif {NULL, NULL} }; @@ -1280,95 +1168,95 @@ {NULL}, }; -PyDoc_STRVAR(adler32__doc__, -"adler32(string[, start]) -- Compute an Adler-32 checksum of string.\n" -"\n" -"An optional starting value can be specified. The returned checksum is\n" -"an integer."); +/*[clinic input] +zlib.adler32 + + data: Py_buffer + value: unsigned_int(bitwise=True) = 1 + Starting value of the checksum. + / + +Compute an Adler-32 checksum of data. + +The returned checksum is an integer. +[clinic start generated code]*/ static PyObject * -PyZlib_adler32(PyObject *self, PyObject *args) +zlib_adler32_impl(PyModuleDef *module, Py_buffer *data, unsigned int value) +/*[clinic end generated code: checksum=51d6d75ee655c78af8c968fdb4c11d97e62c67d5]*/ { - unsigned int adler32val = 1; /* adler32(0L, Z_NULL, 0) */ - Py_buffer pbuf; - - if (!PyArg_ParseTuple(args, "y*|I:adler32", &pbuf, &adler32val)) - return NULL; /* Releasing the GIL for very small buffers is inefficient and may lower performance */ - if (pbuf.len > 1024*5) { - unsigned char *buf = pbuf.buf; - Py_ssize_t len = pbuf.len; + if (data->len > 1024*5) { + unsigned char *buf = data->buf; + Py_ssize_t len = data->len; Py_BEGIN_ALLOW_THREADS /* Avoid truncation of length for very large buffers. adler32() takes length as an unsigned int, which may be narrower than Py_ssize_t. */ while ((size_t)len > UINT_MAX) { - adler32val = adler32(adler32val, buf, UINT_MAX); + value = adler32(value, buf, UINT_MAX); buf += (size_t) UINT_MAX; len -= (size_t) UINT_MAX; } - adler32val = adler32(adler32val, buf, (unsigned int)len); + value = adler32(value, buf, (unsigned int)len); Py_END_ALLOW_THREADS } else { - adler32val = adler32(adler32val, pbuf.buf, (unsigned int)pbuf.len); + value = adler32(value, data->buf, (unsigned int)data->len); } - PyBuffer_Release(&pbuf); - return PyLong_FromUnsignedLong(adler32val & 0xffffffffU); + return PyLong_FromUnsignedLong(value & 0xffffffffU); } -PyDoc_STRVAR(crc32__doc__, -"crc32(string[, start]) -- Compute a CRC-32 checksum of string.\n" -"\n" -"An optional starting value can be specified. The returned checksum is\n" -"an integer."); +/*[clinic input] +zlib.crc32 + + data: Py_buffer + value: unsigned_int(bitwise=True) = 0 + Starting value of the checksum. + / + +Compute a CRC-32 checksum of data. + +The returned checksum is an integer. +[clinic start generated code]*/ static PyObject * -PyZlib_crc32(PyObject *self, PyObject *args) +zlib_crc32_impl(PyModuleDef *module, Py_buffer *data, unsigned int value) +/*[clinic end generated code: checksum=c1e986e74fe7b62369998a71a81ebeb9b73e8d4c]*/ { - unsigned int crc32val = 0; /* crc32(0L, Z_NULL, 0) */ - Py_buffer pbuf; int signed_val; - if (!PyArg_ParseTuple(args, "y*|I:crc32", &pbuf, &crc32val)) - return NULL; /* Releasing the GIL for very small buffers is inefficient and may lower performance */ - if (pbuf.len > 1024*5) { - unsigned char *buf = pbuf.buf; - Py_ssize_t len = pbuf.len; + if (data->len > 1024*5) { + unsigned char *buf = data->buf; + Py_ssize_t len = data->len; Py_BEGIN_ALLOW_THREADS /* Avoid truncation of length for very large buffers. crc32() takes length as an unsigned int, which may be narrower than Py_ssize_t. */ while ((size_t)len > UINT_MAX) { - crc32val = crc32(crc32val, buf, UINT_MAX); + value = crc32(value, buf, UINT_MAX); buf += (size_t) UINT_MAX; len -= (size_t) UINT_MAX; } - signed_val = crc32(crc32val, buf, (unsigned int)len); + signed_val = crc32(value, buf, (unsigned int)len); Py_END_ALLOW_THREADS } else { - signed_val = crc32(crc32val, pbuf.buf, (unsigned int)pbuf.len); + signed_val = crc32(value, data->buf, (unsigned int)data->len); } - PyBuffer_Release(&pbuf); return PyLong_FromUnsignedLong(signed_val & 0xffffffffU); } static PyMethodDef zlib_methods[] = { - {"adler32", (PyCFunction)PyZlib_adler32, METH_VARARGS, - adler32__doc__}, + ZLIB_ADLER32_METHODDEF ZLIB_COMPRESS_METHODDEF - {"compressobj", (PyCFunction)PyZlib_compressobj, METH_VARARGS|METH_KEYWORDS, - compressobj__doc__}, - {"crc32", (PyCFunction)PyZlib_crc32, METH_VARARGS, - crc32__doc__}, - {"decompress", (PyCFunction)PyZlib_decompress, METH_VARARGS, - decompress__doc__}, - {"decompressobj", (PyCFunction)PyZlib_decompressobj, METH_VARARGS|METH_KEYWORDS, - decompressobj__doc__}, + ZLIB_COMPRESSOBJ_METHODDEF + ZLIB_CRC32_METHODDEF + ZLIB_DECOMPRESS_METHODDEF + ZLIB_DECOMPRESSOBJ_METHODDEF {NULL, NULL} }; @@ -1482,6 +1370,7 @@ PyModule_AddIntMacro(m, MAX_WBITS); PyModule_AddIntMacro(m, DEFLATED); PyModule_AddIntMacro(m, DEF_MEM_LEVEL); + PyModule_AddIntMacro(m, DEF_BUF_SIZE); PyModule_AddIntMacro(m, Z_BEST_SPEED); PyModule_AddIntMacro(m, Z_BEST_COMPRESSION); PyModule_AddIntMacro(m, Z_DEFAULT_COMPRESSION); From report at bugs.python.org Sun Jan 26 13:07:39 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 12:07:39 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1390738059.7.0.953110213253.issue20193@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file33719/zlib_clinic_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 13:12:08 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 26 Jan 2014 12:12:08 +0000 Subject: [issue15759] "make suspicious" doesn't display instructions in case of failure In-Reply-To: <1345613663.78.0.519613331574.issue15759@psf.upfronthosting.co.za> Message-ID: <1390738328.85.0.789241978776.issue15759@psf.upfronthosting.co.za> Larry Hastings added the comment: Since Ezio asked me, I guess I wasn't clear: This message should be displayed at the bottom, after the errors, and only when there are alleged suspicious documentation activities. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 13:22:29 2014 From: report at bugs.python.org (Glenn Langford) Date: Sun, 26 Jan 2014 12:22:29 +0000 Subject: [issue20319] concurrent.futures.wait() can block forever even if Futures have completed In-Reply-To: <1390263519.32.0.357208079457.issue20319@psf.upfronthosting.co.za> Message-ID: <1390738949.46.0.737140598473.issue20319@psf.upfronthosting.co.za> Glenn Langford added the comment: @Brian - Ah, I see now what you are referring to. The patch has changes to _create_and_install_waiters() which should not be there. The only code that needs to change is waiter removal as I originally suggested. I am set up with a dev environment now and will submit a revised patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 13:37:08 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 26 Jan 2014 12:37:08 +0000 Subject: [issue20326] Argument Clinic should use a non-error-prone syntax to mark text signatures In-Reply-To: <1390298749.1.0.12762219489.issue20326@psf.upfronthosting.co.za> Message-ID: <1390739828.14.0.848337591258.issue20326@psf.upfronthosting.co.za> Larry Hastings added the comment: Here's a first cut at a patch. All signatures now start with "sig=(". I also added a special marker: if the first parameter starts with "$", we know for certain it's a "self" (or "module" or "type") parameter. This means we can lose the heuristics for "do we have a self parameter?", making inspect.Signature a little more bullet-proof. "$" was chosen as it isn't a legal token in Python. ---------- Added file: http://bugs.python.org/file33724/larry.sig=.marker.for.signatures.diff.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 13:39:59 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 26 Jan 2014 12:39:59 +0000 Subject: [issue20283] Wrong keyword parameter name in regex pattern methods In-Reply-To: <1389905067.44.0.489524795145.issue20283@psf.upfronthosting.co.za> Message-ID: <1390739999.19.0.436376871276.issue20283@psf.upfronthosting.co.za> Larry Hastings added the comment: Georg: you're accepting this patch into 3.3? I'm surprised. I would only want the "soft" approach. But I haven't said "yes" yet. I want to discuss it a little more. (Hey, it's python core dev. Discussing things endlessly is our job.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 13:46:48 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 12:46:48 +0000 Subject: [issue20283] Wrong keyword parameter name in regex pattern methods In-Reply-To: <1390739999.19.0.436376871276.issue20283@psf.upfronthosting.co.za> Message-ID: <1631050.WlpfRdz2nh@raxxla> Serhiy Storchaka added the comment: If you want the "soft" approach, then you should revert your changes to _sre.SRE_Pattern.match. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 13:48:32 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 26 Jan 2014 12:48:32 +0000 Subject: [issue20283] Wrong keyword parameter name in regex pattern methods In-Reply-To: <1389905067.44.0.489524795145.issue20283@psf.upfronthosting.co.za> Message-ID: <1390740512.24.0.878276429685.issue20283@psf.upfronthosting.co.za> Larry Hastings added the comment: You can do it, if I accept the patch for 3.4. There's no point in doing it in two stages. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 13:56:19 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 26 Jan 2014 12:56:19 +0000 Subject: [issue20283] Wrong keyword parameter name in regex pattern methods In-Reply-To: <1389905067.44.0.489524795145.issue20283@psf.upfronthosting.co.za> Message-ID: <1390740978.99.0.494757245272.issue20283@psf.upfronthosting.co.za> Larry Hastings added the comment: Alternatively, we could use this cheap hack: /*[python input] class hidden_object_converter(object_converter): show_in_signature = False [python start generated code]*/ /*[clinic input] module _sre class _sre.SRE_Pattern "PatternObject *" "&Pattern_Type" _sre.SRE_Pattern.match as pattern_match string: object pos: Py_ssize_t = 0 endpos: Py_ssize_t(c_default="PY_SSIZE_T_MAX") = sys.maxsize pattern: hidden_object = None ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 14:07:44 2014 From: report at bugs.python.org (Glenn Langford) Date: Sun, 26 Jan 2014 13:07:44 +0000 Subject: [issue20319] concurrent.futures.wait() can block forever even if Futures have completed In-Reply-To: <1390263519.32.0.357208079457.issue20319@psf.upfronthosting.co.za> Message-ID: <1390741664.17.0.622740217679.issue20319@psf.upfronthosting.co.za> Glenn Langford added the comment: This patch shows the minimal desired outcome. It is not elegant in its current form, but does only what is necessary. Ultimately I think as_completed() should go its own way and not lock all Futures at once (#20297). ---------- Added file: http://bugs.python.org/file33725/issue20319.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 14:17:02 2014 From: report at bugs.python.org (Tom Edwards) Date: Sun, 26 Jan 2014 13:17:02 +0000 Subject: [issue17213] ctypes loads wrong version of C runtime, leading to error message box from system In-Reply-To: <1360992800.86.0.617349310494.issue17213@psf.upfronthosting.co.za> Message-ID: <1390742222.51.0.140806072987.issue17213@psf.upfronthosting.co.za> Tom Edwards added the comment: Still an issue in 3.3.3. Igor's fix still works, thankfully. ---------- nosy: +Artfunkel versions: +Python 3.3 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 14:23:54 2014 From: report at bugs.python.org (Stefan Krah) Date: Sun, 26 Jan 2014 13:23:54 +0000 Subject: [issue20326] Argument Clinic should use a non-error-prone syntax to mark text signatures In-Reply-To: <1390739828.14.0.848337591258.issue20326@psf.upfronthosting.co.za> Message-ID: <20140126132354.GA6550@sleipnir.bytereef.org> Stefan Krah added the comment: I like the "sig=" and the "$". There seems to be a small glitch in __rdivmod__: help(int.__rdivmod__) __rdivmod__(, value) sig=($self, value) Returns divmod(value, self). The sig line is shown (and the preferred form is the imperative "Return divmod"). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 14:31:16 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 13:31:16 +0000 Subject: [issue15759] "make suspicious" doesn't display instructions in case of failure In-Reply-To: <1345613663.78.0.519613331574.issue15759@psf.upfronthosting.co.za> Message-ID: <1390743076.14.0.525394788373.issue15759@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Try this patch. ---------- nosy: +serhiy.storchaka Added file: http://bugs.python.org/file33726/make_suspicious.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 14:33:00 2014 From: report at bugs.python.org (Tom Edwards) Date: Sun, 26 Jan 2014 13:33:00 +0000 Subject: [issue17213] ctypes loads wrong version of C runtime, leading to error message box from system In-Reply-To: <1360992800.86.0.617349310494.issue17213@psf.upfronthosting.co.za> Message-ID: <1390743180.67.0.685759523004.issue17213@psf.upfronthosting.co.za> Changes by Tom Edwards : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 14:43:37 2014 From: report at bugs.python.org (Georg Brandl) Date: Sun, 26 Jan 2014 13:43:37 +0000 Subject: [issue15759] "make suspicious" doesn't display instructions in case of failure In-Reply-To: <1345613663.78.0.519613331574.issue15759@psf.upfronthosting.co.za> Message-ID: <1390743817.02.0.558562922897.issue15759@psf.upfronthosting.co.za> Georg Brandl added the comment: Looks good. Maybe Larry will want his line of stars though :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 14:44:17 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 26 Jan 2014 13:44:17 +0000 Subject: [issue20326] Argument Clinic should use a non-error-prone syntax to mark text signatures In-Reply-To: <1390298749.1.0.12762219489.issue20326@psf.upfronthosting.co.za> Message-ID: <1390743857.06.0.747324159222.issue20326@psf.upfronthosting.co.za> Nick Coghlan added the comment: Stefan actually picked up on an existing bug there, that this patch just changes the spelling of: >>> int.__rdivmod__.__doc__ '__rdivmod__(self, value)\nReturns divmod(value, self).' >>> int.__rdivmod__.__text_signature__ '(self, value)' When reviewing Larry's typeobject.c patch, both Guido and I missed the fact that some of the "slot" macros have implicit lines in their docstrings if the signature is common across all instances of that slot: #define UNSLOT(NAME, SLOT, FUNCTION, WRAPPER, DOC) \ ETSLOT(NAME, as_number.SLOT, FUNCTION, WRAPPER, \ NAME "(self)\n" DOC) #define IBSLOT(NAME, SLOT, FUNCTION, WRAPPER, DOC) \ ETSLOT(NAME, as_number.SLOT, FUNCTION, WRAPPER, \ NAME "(self, value)\nReturns self" DOC "value.") #define BINSLOT(NAME, SLOT, FUNCTION, DOC) \ ETSLOT(NAME, as_number.SLOT, FUNCTION, wrap_binaryfunc_l, \ NAME "(self, value)\nReturns self" DOC "value.") #define RBINSLOT(NAME, SLOT, FUNCTION, DOC) \ ETSLOT(NAME, as_number.SLOT, FUNCTION, wrap_binaryfunc_r, \ NAME "(self, value)\nReturns value" DOC "self.") #define BINSLOTNOTINFIX(NAME, SLOT, FUNCTION, DOC) \ ETSLOT(NAME, as_number.SLOT, FUNCTION, wrap_binaryfunc_l, \ NAME "(self, value)\n" DOC) #define RBINSLOTNOTINFIX(NAME, SLOT, FUNCTION, DOC) \ ETSLOT(NAME, as_number.SLOT, FUNCTION, wrap_binaryfunc_r, \ NAME "(self, value)\n" DOC) For those, we need to change the macro and then remove the redundant info from the individual slot definitions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 14:47:14 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 26 Jan 2014 13:47:14 +0000 Subject: [issue20326] Argument Clinic should use a non-error-prone syntax to mark text signatures In-Reply-To: <1390298749.1.0.12762219489.issue20326@psf.upfronthosting.co.za> Message-ID: <1390744034.19.0.798129697284.issue20326@psf.upfronthosting.co.za> Nick Coghlan added the comment: Aside from that glitch, the new scheme looks good to me. I also like the fact it allows the text signature to be included in the docstring normally if inspect.Signature doesn't support it, so help(f) can still be generated automatically. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 14:55:21 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 26 Jan 2014 13:55:21 +0000 Subject: [issue20326] Argument Clinic should use a non-error-prone syntax to mark text signatures In-Reply-To: <1390298749.1.0.12762219489.issue20326@psf.upfronthosting.co.za> Message-ID: <1390744521.36.0.741869695044.issue20326@psf.upfronthosting.co.za> Larry Hastings added the comment: Nick: you lost me. Change the macro how? What is the redundant info? I already changed those macros so they generate signatures, both currently in trunk and in my patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 14:57:44 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 26 Jan 2014 13:57:44 +0000 Subject: [issue20326] Argument Clinic should use a non-error-prone syntax to mark text signatures In-Reply-To: <1390298749.1.0.12762219489.issue20326@psf.upfronthosting.co.za> Message-ID: <1390744664.51.0.0594557072085.issue20326@psf.upfronthosting.co.za> Larry Hastings added the comment: Stefan: I made the change. I left "Implements " alone as "Implement " sounded wrong, but all the rest dropped their s's. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 15:02:21 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 26 Jan 2014 14:02:21 +0000 Subject: [issue20396] Argument Clinic: Touch source file if any output file changed Message-ID: <1390744941.56.0.0539875742197.issue20396@psf.upfronthosting.co.za> New submission from Larry Hastings: A minor bug, but still one that could cause confusion. It's already bitten me once. If I change the code generator in clinic.py, then --make everything, files using the "file" destination often won't change. All the changes to the generated code will go in the generated file. And since the UNIX build process ignores those generated files, it doesn't rebuild the source file. I'd have to use "--make -f". This won't just happen to me though. If you update your trunk and run "make clinic" this could easily happen to you too. I propose that Clinic handle this as follows: if the generated file changes, but the source file does not, it "touches" the source file. (Technically I'll probably just rewrite the source file, as I already have code that does that.) ---------- assignee: larry messages: 209315 nosy: larry, ncoghlan, serhiy.storchaka, zach.ware priority: low severity: normal stage: needs patch status: open title: Argument Clinic: Touch source file if any output file changed type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 15:03:07 2014 From: report at bugs.python.org (Larry Hastings) Date: Sun, 26 Jan 2014 14:03:07 +0000 Subject: [issue15759] "make suspicious" doesn't display instructions in case of failure In-Reply-To: <1345613663.78.0.519613331574.issue15759@psf.upfronthosting.co.za> Message-ID: <1390744987.21.0.537479634494.issue15759@psf.upfronthosting.co.za> Larry Hastings added the comment: Can we use unicode characters? I'd like little ships, or U+1F4A9. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 15:03:10 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 14:03:10 +0000 Subject: [issue15759] "make suspicious" doesn't display instructions in case of failure In-Reply-To: <1345613663.78.0.519613331574.issue15759@psf.upfronthosting.co.za> Message-ID: <1390744990.74.0.335596188515.issue15759@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It was not such good. Here is better patch. ---------- Added file: http://bugs.python.org/file33727/make_suspicious.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 15:03:22 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 14:03:22 +0000 Subject: [issue15759] "make suspicious" doesn't display instructions in case of failure In-Reply-To: <1345613663.78.0.519613331574.issue15759@psf.upfronthosting.co.za> Message-ID: <1390745002.4.0.728670688571.issue15759@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file33726/make_suspicious.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 15:09:02 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 14:09:02 +0000 Subject: [issue20396] Argument Clinic: Touch source file if any output file changed In-Reply-To: <1390744941.56.0.0539875742197.issue20396@psf.upfronthosting.co.za> Message-ID: <1390745342.18.0.164725093022.issue20396@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It should first touch source file and then generated file. So that the date of generated file is always later the date of source file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 15:15:48 2014 From: report at bugs.python.org (Stefan Krah) Date: Sun, 26 Jan 2014 14:15:48 +0000 Subject: [issue20326] Argument Clinic should use a non-error-prone syntax to mark text signatures In-Reply-To: <1390744521.36.0.741869695044.issue20326@psf.upfronthosting.co.za> Message-ID: <20140126141547.GA6886@sleipnir.bytereef.org> Stefan Krah added the comment: > What is the redundant info? {"__rdivmod__", __builtin_offsetof (PyHeapTypeObject, as_number.nb_divmod), (void *)(slot_nb_divmod), wrap_binaryfunc_r, "sig=($self, value)\n" "sig=($self, value)\nReturns divmod(value, self)."} There are two "sig" instances. What Nick said is that the situation was pretty much the same before the "sig" patch and should be fixed regardless: {"__rdivmod__", __builtin_offsetof (PyHeapTypeObject, as_number.nb_divmod), (void *)(slot_nb_divmod), wrap_binaryfunc_r, "__rdivmod__" "(self, value)\n" "__rdivmod__(self, value)\nReturns divmod(value, self)."} ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 15:20:14 2014 From: report at bugs.python.org (Marcus von Appen) Date: Sun, 26 Jan 2014 14:20:14 +0000 Subject: [issue20397] distutils --record option does not validate existance of byte-compiled files Message-ID: <1390746014.88.0.900467086198.issue20397@psf.upfronthosting.co.za> New submission from Marcus von Appen: Using the --record argument with distutils' install command currently assumes that all .py files can be compiled (and optimized) successfully. If this is not the case for whatever reason, you end up with invalid entries in the record list. install_lib._bytecode_filenames() should verify, if the file could be created successfully (by e.g. checking for its existence) or the util.byte_compile() function should return a value that indicates, if the byte-compiled (or optimized) file could be created, so that the subsequent call to _bytecode_filenames() receives a list with valid entries. The issue can be recreated with e.g. http://pypi.python.org/pypi/Products.PasswordResetTool, which will create invalid entries for skins/PasswordReset/pwreset_constructURL.py, which acts as template/fragment. ---------- components: Distutils messages: 209320 nosy: marcusva priority: normal severity: normal status: open title: distutils --record option does not validate existance of byte-compiled files type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 15:20:26 2014 From: report at bugs.python.org (Glenn Langford) Date: Sun, 26 Jan 2014 14:20:26 +0000 Subject: [issue20367] concurrent.futures.as_completed() fails when given duplicate Futures In-Reply-To: <1390489248.24.0.751917808957.issue20367@psf.upfronthosting.co.za> Message-ID: <1390746026.47.0.881974774545.issue20367@psf.upfronthosting.co.za> Glenn Langford added the comment: Ah...ok, here is a patch that includes an update to Doc/library/concurrent.futures.rst as well. ---------- Added file: http://bugs.python.org/file33728/issue20367.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 15:21:24 2014 From: report at bugs.python.org (Tal Einat) Date: Sun, 26 Jan 2014 14:21:24 +0000 Subject: [issue20385] Argument Clinic: Support for __new__ not checking _PyArg_NoKeywords for sub-classes In-Reply-To: <1390599341.47.0.747419262521.issue20385@psf.upfronthosting.co.za> Message-ID: <1390746084.97.0.740085494425.issue20385@psf.upfronthosting.co.za> Tal Einat added the comment: Using the latest clinic.py from default branch, everything in itertools works like a charm :) ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 15:31:56 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 26 Jan 2014 14:31:56 +0000 Subject: [issue20396] Argument Clinic: Touch source file if any output file changed In-Reply-To: <1390745342.18.0.164725093022.issue20396@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: With Serhiy's modification, sounds like a reasonable plan to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 15:34:54 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 26 Jan 2014 14:34:54 +0000 Subject: [issue20326] Argument Clinic should use a non-error-prone syntax to mark text signatures In-Reply-To: <20140126141547.GA6886@sleipnir.bytereef.org> Message-ID: Nick Coghlan added the comment: Right, the macros I quoted all include the signature automatically (because it's consistent) and *then* the DOC that is passed in. So when you use them, the signature should be left out of the slot definition itself. Currently, we're defining it in both places, hence the duplication. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 15:53:52 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 26 Jan 2014 14:53:52 +0000 Subject: [issue20105] Codec exception chaining is losing traceback details In-Reply-To: <1388629413.58.0.988087871801.issue20105@psf.upfronthosting.co.za> Message-ID: <3fBxtQ5lkVz7Ll8@mail.python.org> Roundup Robot added the comment: New changeset b27352f87404 by Nick Coghlan in branch 'default': Close #20105: set __traceback__ when chaining exceptions in C http://hg.python.org/cpython/rev/b27352f87404 ---------- nosy: +python-dev resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 16:03:13 2014 From: report at bugs.python.org (Ram Rachum) Date: Sun, 26 Jan 2014 15:03:13 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390748593.19.0.203909876185.issue20218@psf.upfronthosting.co.za> Ram Rachum added the comment: New patch attached. Not tested. ---------- Added file: http://bugs.python.org/file33729/pathlib.readwrite4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 16:05:31 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 15:05:31 +0000 Subject: [issue16074] Bad error message in os.rename, os.link, and os.symlink In-Reply-To: <1348820000.8.0.496903200143.issue16074@psf.upfronthosting.co.za> Message-ID: <1390748731.5.0.713678201469.issue16074@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The 3.4 patch LGTM, but the 3.3 patch perhaps has a bug. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 16:13:00 2014 From: report at bugs.python.org (lothar) Date: Sun, 26 Jan 2014 15:13:00 +0000 Subject: [issue20398] stem crashes python Message-ID: <1390749180.01.0.603192717521.issue20398@psf.upfronthosting.co.za> New submission from lothar: setup: python 3.2 ; cygwin64 python crashes with a stackdump, which is attached. stem is a python controller module for tor. stem-1.1.1 can be had from here: https://pypi.python.org/pypi/stem/ the code is in version 2 form, but "python3 setup install" runs 2to3 on it. this code crashes before the for statement: #! /usr/bin/env python3 import urllib.request from stem import Signal from stem.control import Controller with Controller.from_port(port=9151) as controller: controller.signal(Signal.NEWNYM) for nn in range(1, 3): print("case %02d" % nn) proxy_support = urllib.request.ProxyHandler({"socks5" : "127.0.0.1:9150"}) opener = urllib.request.build_opener(proxy_support) urllib.request.install_opener(opener) print(urllib.request.urlopen("http://www.ifconfig.me/ip").read()) ---------- components: Interpreter Core files: python3.2m.exe.stackdump messages: 209328 nosy: lothar priority: normal severity: normal status: open title: stem crashes python type: crash versions: Python 3.2 Added file: http://bugs.python.org/file33730/python3.2m.exe.stackdump _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 16:26:01 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 26 Jan 2014 15:26:01 +0000 Subject: [issue19863] Missing function attributes in 2.7 docs. In-Reply-To: <1386010673.68.0.260580445507.issue19863@psf.upfronthosting.co.za> Message-ID: <1390749961.94.0.190466924922.issue19863@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > LGTM, but may be write Py3k compatible names at first place? +1 ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 16:40:05 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 26 Jan 2014 15:40:05 +0000 Subject: [issue8260] When I use codecs.open(...) and f.readline() follow up by f.read() return bad result In-Reply-To: <1269875395.81.0.132261115225.issue8260@psf.upfronthosting.co.za> Message-ID: <1390750805.24.0.773110458605.issue8260@psf.upfronthosting.co.za> Nick Coghlan added the comment: Patch looks good to me, but if any specific features are needed to work around misbehaving codecs (as per issue 20132), a comment in the appropriate place referencing that issue would be helpful. And if that workaround means we can remove the special casing from the test_readlines test for the binary transform, cool :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 16:41:16 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Sun, 26 Jan 2014 15:41:16 +0000 Subject: [issue19920] TarFile.list() fails on some files In-Reply-To: <1386437860.38.0.0478693655005.issue19920@psf.upfronthosting.co.za> Message-ID: <1390750876.59.0.945438410201.issue19920@psf.upfronthosting.co.za> Vajrasky Kok added the comment: I already have a patch addressing your concerns, Serhiy. But before I upload it here, some questions: 1. "Yes, we can add unencodable tarinfo.linkname later. Just add tests for external tar files." You mean, we need to create a tar file containing unencodable tarinfo.linkname dynamically in the test? Wouldn't modifying testtar.tar be easier? 2. "stdout encoding is just sys.stdout.encoding. Be aware that it can be None (if sys.stdout is StringIO), in that case the encoding/decoding is not needed". from io import StringIO import sys old_stdout = sys.stdout sys.stdout = mystdout = StringIO() import locale print(locale.getpreferredencoding()) sys.stdout = old_stdout print(mystdout.getvalue()) I always get UTF-8. Is there anything I miss? Once I get clarity from these questions, I'll upload the patch. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 16:55:33 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 26 Jan 2014 15:55:33 +0000 Subject: [issue20392] Inconsistency with uppercase file extensions in MimeTypes.guess_type In-Reply-To: <1390670268.05.0.579524422182.issue20392@psf.upfronthosting.co.za> Message-ID: <1390751733.72.0.530612229975.issue20392@psf.upfronthosting.co.za> R. David Murray added the comment: I'm tagging this for 3.5 instead, since there are backward compatibility concerns and the 3.4 RC will probably be a couple weeks from now. ---------- nosy: +r.david.murray versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 16:57:03 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 15:57:03 +0000 Subject: [issue19920] TarFile.list() fails on some files In-Reply-To: <1390750876.59.0.945438410201.issue19920@psf.upfronthosting.co.za> Message-ID: <2464056.IYRvxD1iL4@raxxla> Serhiy Storchaka added the comment: 1. No. Just use existing nonmodified testtar.tar now. Later we will add new items in it. 2. The encoding of sys.stdout is not always the same as default locale encoding. You can redirect sys.stdout to text file (opened with different encoding) or to socket or pipe (wrapped with TextIOWrapper). So you should use sys.stdout.encoding and nothing else. But even this not always work, because it can be None (in case of StringIO) or be absent (in case of user file-like object). Be aware of all this corner cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 17:06:18 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 26 Jan 2014 16:06:18 +0000 Subject: [issue20398] stem crashes python In-Reply-To: <1390749180.01.0.603192717521.issue20398@psf.upfronthosting.co.za> Message-ID: <1390752378.89.0.71531475768.issue20398@psf.upfronthosting.co.za> R. David Murray added the comment: For anyone else who wants to look at this: it doesn't look like stem involves any C code, and the 'signal' method appears to be a text-based interprocess communication. Can you reproduce this with 3.3.3? 3.2 is in security-fix-only mode, and while a crash can be a security issue, it isn't necessarily. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 17:23:24 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 16:23:24 +0000 Subject: [issue8260] When I use codecs.open(...) and f.readline() follow up by f.read() return bad result In-Reply-To: <1390750805.24.0.773110458605.issue8260@psf.upfronthosting.co.za> Message-ID: <1708994.pVPbtfUmiQ@raxxla> Serhiy Storchaka added the comment: Actually this patch doesn't work around misbehaving codecs. It just makes specific tests (one readline, one read) be passed. More complex tests which use multiple readline's or read's still can fail with these misbehaving codecs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 17:27:49 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 26 Jan 2014 16:27:49 +0000 Subject: [issue19990] Add unittests for imghdr module In-Reply-To: <1387146470.57.0.419345603545.issue19990@psf.upfronthosting.co.za> Message-ID: <1390753669.37.0.393868446947.issue19990@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Hello! Here's the new version of the patch, with tests proposed by Serhiy. ---------- Added file: http://bugs.python.org/file33731/test_imghdr_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 18:30:36 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 26 Jan 2014 17:30:36 +0000 Subject: [issue8260] When I use codecs.open(...) and f.readline() follow up by f.read() return bad result In-Reply-To: <1269875395.81.0.132261115225.issue8260@psf.upfronthosting.co.za> Message-ID: <3fC1MC3SZkz7Ll8@mail.python.org> Roundup Robot added the comment: New changeset e24265eb2271 by Serhiy Storchaka in branch '2.7': Issue #8260: The read(), readline() and readlines() methods of http://hg.python.org/cpython/rev/e24265eb2271 New changeset 9c96c266896e by Serhiy Storchaka in branch '3.3': Issue #8260: The read(), readline() and readlines() methods of http://hg.python.org/cpython/rev/9c96c266896e New changeset b72508a785de by Serhiy Storchaka in branch 'default': Issue #8260: The read(), readline() and readlines() methods of http://hg.python.org/cpython/rev/b72508a785de ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 18:34:32 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 17:34:32 +0000 Subject: [issue8260] When I use codecs.open(...) and f.readline() follow up by f.read() return bad result In-Reply-To: <1269875395.81.0.132261115225.issue8260@psf.upfronthosting.co.za> Message-ID: <1390757672.36.0.22065014197.issue8260@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 18:59:19 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 26 Jan 2014 17:59:19 +0000 Subject: [issue20367] concurrent.futures.as_completed() fails when given duplicate Futures In-Reply-To: <1390489248.24.0.751917808957.issue20367@psf.upfronthosting.co.za> Message-ID: <3fC20Q6Wgjz7Lkf@mail.python.org> Roundup Robot added the comment: New changeset 58b0f3e1ddf8 by Guido van Rossum in branch 'default': Fix issue #20367: concurrent.futures.as_completed() for duplicate arguments. http://hg.python.org/cpython/rev/58b0f3e1ddf8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 18:59:49 2014 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 26 Jan 2014 17:59:49 +0000 Subject: [issue20367] concurrent.futures.as_completed() fails when given duplicate Futures In-Reply-To: <1390489248.24.0.751917808957.issue20367@psf.upfronthosting.co.za> Message-ID: <1390759189.17.0.433100756589.issue20367@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 19:03:57 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 26 Jan 2014 18:03:57 +0000 Subject: [issue19898] No tests for dequereviter_new In-Reply-To: <1386256613.14.0.807664608281.issue19898@psf.upfronthosting.co.za> Message-ID: <1390759437.81.0.912001808503.issue19898@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Hi. Here's a patch. ---------- keywords: +patch nosy: +Claudiu.Popa Added file: http://bugs.python.org/file33732/test_deque_19898.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 19:22:30 2014 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 26 Jan 2014 18:22:30 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <1390760550.28.0.941574026584.issue20311@psf.upfronthosting.co.za> Guido van Rossum added the comment: AFAICT the changes to selectmodule.c have been rolled back, both in the 3.3 and the 3.4 (default) branches. That takes care of backwards compatibility. :-) So what we're talking about is whether (a) the selectors module (new in 3.3) should export a resolution property and what asyncio should do. The selectors module in the repo does export a resolution property. It is 1 usec for select, 1msec for poll and epoll, and 1 nsec for kqueue. AFAIK these values are derived from the data type and scale used by the corresponding syscall. The latest code in the asyncio module uses that resolution for exactly one purpose: if, after waking up from a selector.select() call, any events we are waiting for are less than the resolution in the future, we consider them ready. I like this approach -- it trusts the syscall to do approximately the right thing most of the time, but it doesn't fall into the busy-wait trap. This trap is especially egregious for [e]poll, where the timing resolution is limited to 1 msec due to the syscall interface. To explain the trap once more: suppose you have an event scheduled 0.9 msec in the future. Because of the 1 msec resolution of the [e]poll syscall API, the syscall is made with an argument of 0, which means it returns (almost) immediately. Given a fast CPU and no other IO ready, this might well take only a few usec. So the event loop does essentially nothing and then comes back to the poll call. The same event is now e.g. 0.89 msec in the future. So we call [e]poll with a timeout of 0 again, and we keep going around without ever releasing the CPU for the full 0.9 msec -- which nowadays is serious time in which a lot of other, more useful things could be accomplished by other threads or processes. I think what's currently in the repo is all a fine solution to all that. Because the resolution is specified on a per-selector-class basis, we compensate appropriately for [e]poll but don't apply such a coarse granularity to the other syscalls, which are (potentially) more accurate. If in the future we find that on some systems the kernel systematically rounds the timeout down using some coarser clock resolution we can add a system-specific compensation to the selectors module, and asyncio itself doesn't have to worry about it. (Though I personally don't expect we'll find this behavior.) One final comment: IIUC the earlier fix involved using ceil() and other cleverness was essentially trying to predict *when* the next tick would wake us up, assuming that if the resolution is R, the kernel would wake us up at times that are integral multiples of R since the clock epoch. I don't think we can assume this at all, so I'm glad Victor rolled that back. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 19:31:51 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 18:31:51 +0000 Subject: [issue19990] Add unittests for imghdr module In-Reply-To: <1387146470.57.0.419345603545.issue19990@psf.upfronthosting.co.za> Message-ID: <1390761111.92.0.949629358642.issue19990@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Looks as you forgot to include some test files in the patch. And these files are too large. Much smaller images would be enough. For example you can use python.org icon: http://www.python.org/favicon.ico. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 19:42:18 2014 From: report at bugs.python.org (Jeff Edwards) Date: Sun, 26 Jan 2014 18:42:18 +0000 Subject: [issue13866] {urllib, urllib.parse}.urlencode should not use quote_plus In-Reply-To: <1327529522.13.0.464287316871.issue13866@psf.upfronthosting.co.za> Message-ID: <1390761738.35.0.0336338411451.issue13866@psf.upfronthosting.co.za> Jeff Edwards added the comment: It's interesting how long this issue has been around. It seems to be because the form-urlencoded spec is specified as url-percent-encoding EXCEPT for ' ' -> '+', which does seem to be unintuitive. To note, there are a few known cases where the exception does lead to either confusion or outright breakage, such as AWS Signature V4 authentication which requires an an HMAC of the 'canonical' query string which expected the parameters sorted and url encoding where ' ' -> '%20'. While I do not believe that should be the sole reason to force a change, it does add to the utility of the currently-submitted patch as written. ---------- nosy: +Jeff.Edwards _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 20:08:00 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 26 Jan 2014 19:08:00 +0000 Subject: [issue19990] Add unittests for imghdr module In-Reply-To: <1387146470.57.0.419345603545.issue19990@psf.upfronthosting.co.za> Message-ID: <1390763280.48.0.0415666839833.issue19990@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Here's a smaller patch. Serhiy, what test files are missing? ---------- Added file: http://bugs.python.org/file33733/test_imghdr_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 20:24:02 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 19:24:02 +0000 Subject: [issue19990] Add unittests for imghdr module In-Reply-To: <1387146470.57.0.419345603545.issue19990@psf.upfronthosting.co.za> Message-ID: <1390764242.34.0.648895462118.issue19990@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Last patch contains only pbm and xbm test files, while test_imghdr expects 11 different image files: png, gif, bmp, etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 20:30:02 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Sun, 26 Jan 2014 19:30:02 +0000 Subject: [issue19990] Add unittests for imghdr module In-Reply-To: <1387146470.57.0.419345603545.issue19990@psf.upfronthosting.co.za> Message-ID: <1390764602.39.0.574629067958.issue19990@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Ah, I understand now. Maybe it is related to the fact that I used `hg diff --git`? Doing the following works for me, both Windows and FreeBsd and all the files are present afterwards: 1. hg diff --git > patch 2. hg import --no-commit patch Although I'm not sure why it doesn't work in your case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 20:46:02 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 19:46:02 +0000 Subject: [issue19990] Add unittests for imghdr module In-Reply-To: <1387146470.57.0.419345603545.issue19990@psf.upfronthosting.co.za> Message-ID: <1390765562.7.0.314865264605.issue19990@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, yes, my bad. I used the patch utility. Sorry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 20:52:56 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 26 Jan 2014 19:52:56 +0000 Subject: [issue20398] stem crashes python In-Reply-To: <1390749180.01.0.603192717521.issue20398@psf.upfronthosting.co.za> Message-ID: <1390765976.16.0.470141936684.issue20398@psf.upfronthosting.co.za> Antoine Pitrou added the comment: If this is a cygwin build (rather than a standard MSVC build), I'm afraid that's not a supported platform at all. Did you compile Python yourself? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 20:55:20 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 26 Jan 2014 19:55:20 +0000 Subject: [issue20395] Extract generated clinic code in Modules/_pickle.c to separate file In-Reply-To: <1390734339.8.0.0968166670001.issue20395@psf.upfronthosting.co.za> Message-ID: <1390766120.82.0.194510752626.issue20395@psf.upfronthosting.co.za> Antoine Pitrou added the comment: +1 for a separate file from me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 21:13:11 2014 From: report at bugs.python.org (Nadeem Vawda) Date: Sun, 26 Jan 2014 20:13:11 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1390767191.21.0.415868069885.issue20193@psf.upfronthosting.co.za> Nadeem Vawda added the comment: The patch for zlib looks good to me. Thanks for working on this, Serhiy. > We're not allowing changes in semantics for Argument Clinic conversion for 3.4. If it doesn't currently accept None, we can't add it right now, and we'll have to save it for 3.5. Fair enough. > The behavior is preserved. This case is exact analogue of _sha1.sha1(). No one > additional function called when the parameter is not specified, but if it is > specified as b'', the function behaves identically to not passing in that > parameter. Ah OK, I misunderstood the Argument Clinic input code when I first read it. Having actually read the docs, it makes sense. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 21:36:05 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 26 Jan 2014 20:36:05 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <1390768565.52.0.235664479683.issue19081@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I refactored the unittests a bit and added another test for subimports when a directory within the .zip file is in sys.path as well. The quizzical "wtf" TODO I had in the code has been "answered" in that I am unable to trigger a situation where path != buf and prefix is nonempty in that function. I'm leaving that as a NOTE in the code for future investigation, but it isnt' related to this bug. I cleaned up the code there regardless to refer to buf (guaranteed to be the path to the actual .zip file) rather than an odd mixture of path and buf. ---------- Added file: http://bugs.python.org/file33734/issue19081-subimport-fix-gps03.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 21:37:37 2014 From: report at bugs.python.org (fin swimmer) Date: Sun, 26 Jan 2014 20:37:37 +0000 Subject: [issue20399] Comparison of memoryview Message-ID: <1390768657.21.0.774991286622.issue20399@psf.upfronthosting.co.za> New submission from fin swimmer: Comparison by using memoryview seems not to work completely. This works: >>> memoryview(bytearray(range(5))) != memoryview(bytearray(range(5))) False >>> memoryview(bytearray(range(5))) == memoryview(bytearray(range(5))) True But: >>> memoryview(bytearray(range(5))) < memoryview(bytearray(range(5))) Traceback (most recent call last): File "", line 1, in TypeError: unorderable types: memoryview() < memoryview() So memoryview cannot be used as a key-value for sorting ---------- components: Library (Lib) messages: 209351 nosy: fin.swimmer priority: normal severity: normal status: open title: Comparison of memoryview type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 21:48:35 2014 From: report at bugs.python.org (fin swimmer) Date: Sun, 26 Jan 2014 20:48:35 +0000 Subject: [issue20339] Make bytes() use tp_as_buffer for cmp In-Reply-To: <1390351229.22.0.995411790956.issue20339@psf.upfronthosting.co.za> Message-ID: <1390769315.55.0.374977608353.issue20339@psf.upfronthosting.co.za> fin swimmer added the comment: This is exactly what I need! Would be a great work. ---------- nosy: +fin.swimmer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 22:47:22 2014 From: report at bugs.python.org (Ethan Furman) Date: Sun, 26 Jan 2014 21:47:22 +0000 Subject: [issue20386] socket.SocketType enum overwrites import of _socket.SocketType In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za> Message-ID: <1390772842.73.0.868372649022.issue20386@psf.upfronthosting.co.za> Ethan Furman added the comment: Okay, staying with SocketKind. This patch also has a very small doc enhancement. ---------- keywords: +patch Added file: http://bugs.python.org/file33735/issue20386.stoneleaf.03.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 22:53:55 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 26 Jan 2014 21:53:55 +0000 Subject: [issue19990] Add unittests for imghdr module In-Reply-To: <1387146470.57.0.419345603545.issue19990@psf.upfronthosting.co.za> Message-ID: <3fC7C7101rz7Ll8@mail.python.org> Roundup Robot added the comment: New changeset b28909d501c0 by Serhiy Storchaka in branch '2.7': Issue #19990: Added tests for the imghdr module. http://hg.python.org/cpython/rev/b28909d501c0 New changeset fde9e9832749 by Serhiy Storchaka in branch '3.3': Issue #19990: Added tests for the imghdr module. http://hg.python.org/cpython/rev/fde9e9832749 New changeset 94813eab5a58 by Serhiy Storchaka in branch 'default': Issue #19990: Added tests for the imghdr module. http://hg.python.org/cpython/rev/94813eab5a58 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 22:56:00 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 21:56:00 +0000 Subject: [issue19990] Add unittests for imghdr module In-Reply-To: <1387146470.57.0.419345603545.issue19990@psf.upfronthosting.co.za> Message-ID: <1390773360.23.0.679350059895.issue19990@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Claudiu. I have reorganized tests somewhat and added new test for file position. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 23:04:02 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 26 Jan 2014 22:04:02 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <3fC7Qn5X1Xz7Lkf@mail.python.org> Roundup Robot added the comment: New changeset 6f217456b9ba by Serhiy Storchaka in branch 'default': Issue #20193: The zlib module now uses Argument Clinic. http://hg.python.org/cpython/rev/6f217456b9ba ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 23:05:28 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 22:05:28 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <1390773928.16.0.833786207957.issue20193@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for reviews, Nadeem, Larry. ---------- dependencies: -pydoc fails with the "unspecified" default value resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 23:07:31 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 22:07:31 +0000 Subject: [issue20293] pydoc fails with the "unspecified" default value In-Reply-To: <1390045398.5.0.236293557583.issue20293@psf.upfronthosting.co.za> Message-ID: <1390774051.03.0.488187537798.issue20293@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Since Argument Clinic no more supports "unspecified" default value, this issue can be closed. ---------- resolution: -> out of date stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 23:34:03 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 26 Jan 2014 22:34:03 +0000 Subject: [issue20367] concurrent.futures.as_completed() fails when given duplicate Futures In-Reply-To: <1390489248.24.0.751917808957.issue20367@psf.upfronthosting.co.za> Message-ID: <3fC85Q6HSLz7LjS@mail.python.org> Roundup Robot added the comment: New changeset 1dac8c954488 by Victor Stinner in branch 'default': Issue #20367: Add Glenn Langford to Misc/ACKS http://hg.python.org/cpython/rev/1dac8c954488 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 23:36:24 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 26 Jan 2014 22:36:24 +0000 Subject: [issue20367] concurrent.futures.as_completed() fails when given duplicate Futures In-Reply-To: <1390489248.24.0.751917808957.issue20367@psf.upfronthosting.co.za> Message-ID: <1390775784.06.0.179337803468.issue20367@psf.upfronthosting.co.za> STINNER Victor added the comment: @Guido: Why not fixing the issue in Python 3.3? You forgot to add Gleen Langford to Misc/ACKS! @Gleen: Congrats for your first commit :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 23:42:34 2014 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 26 Jan 2014 22:42:34 +0000 Subject: [issue20367] concurrent.futures.as_completed() fails when given duplicate Futures In-Reply-To: <1390489248.24.0.751917808957.issue20367@psf.upfronthosting.co.za> Message-ID: <1390776154.65.0.97614720133.issue20367@psf.upfronthosting.co.za> Guido van Rossum added the comment: Sorry, I suppose it needs to be backported to 3.3. If someone wants to do that, please do (I'm afraid I'd mess up the merge). ---------- resolution: fixed -> remind status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 23:46:48 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 Jan 2014 22:46:48 +0000 Subject: [issue19456] ntpath doesn't join paths correctly when a drive is present In-Reply-To: <1383174757.86.0.861423882665.issue19456@psf.upfronthosting.co.za> Message-ID: <1390776408.97.0.753892973725.issue19456@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Merlijn for your information. So which patch is more preferable? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jan 26 23:53:34 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 26 Jan 2014 22:53:34 +0000 Subject: [issue19077] More robust TemporaryDirectory cleanup In-Reply-To: <2148515.ZNB7pLonG3@raxxla> Message-ID: <1390776811.2291.1.camel@fsol> Antoine Pitrou added the comment: > Here are updated patches for 3.3 and 3.4. Changed tests for 3.4, a patch for > 3.3 is changed more. Unfortunately in 3.3 exceptions still can be raised when > try to emit a warning during shutdown. Is there any way to determine the > shutdown mode? There's nothing obvious, but a possible hack would be: _is_shutdown = False def _on_shutdown(): global _is_shutdown _is_shutdown = True atexit.register(_on_shutdown) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 00:15:58 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sun, 26 Jan 2014 23:15:58 +0000 Subject: [issue15216] Support setting the encoding on a text stream after creation In-Reply-To: <1340880558.16.0.0136840668667.issue15216@psf.upfronthosting.co.za> Message-ID: <1390778158.98.0.905736507728.issue15216@psf.upfronthosting.co.za> Nikolaus Rath added the comment: I am working on this now. ---------- nosy: +nikratio _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 00:24:52 2014 From: report at bugs.python.org (Merlijn van Deen) Date: Sun, 26 Jan 2014 23:24:52 +0000 Subject: [issue19456] ntpath doesn't join paths correctly when a drive is present In-Reply-To: <1383174757.86.0.861423882665.issue19456@psf.upfronthosting.co.za> Message-ID: <1390778692.97.0.666612880388.issue19456@psf.upfronthosting.co.za> Merlijn van Deen added the comment: I'm not sure whether that question was aimed at me -- I think both options have their merits, but I'd suggest to adopt the .NET semantics. The semantics are also explicitly defined [1] and the behavior seems to be acceptable for the .NET world. [1] http://msdn.microsoft.com/en-us/library/fyy7a5kt(v=vs.110).aspx ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 00:40:11 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 26 Jan 2014 23:40:11 +0000 Subject: [issue20400] Add create_read_pipe_protocol/create_write_pipe_protocol to asyncio.SubprocessProtocol Message-ID: <1390779611.0.0.029550213682.issue20400@psf.upfronthosting.co.za> New submission from STINNER Victor: I reported the issue in Tulip project: http://code.google.com/p/tulip/issues/detail?id=115 I consider this issue as as serious API flaw and I would like to fix it before Python 3.4 final. ---------- messages: 209366 nosy: gvanrossum, haypo, larry priority: release blocker severity: normal status: open title: Add create_read_pipe_protocol/create_write_pipe_protocol to asyncio.SubprocessProtocol versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 00:43:54 2014 From: report at bugs.python.org (Glenn Langford) Date: Sun, 26 Jan 2014 23:43:54 +0000 Subject: [issue20367] concurrent.futures.as_completed() fails when given duplicate Futures In-Reply-To: <1390489248.24.0.751917808957.issue20367@psf.upfronthosting.co.za> Message-ID: <1390779834.11.0.252851859565.issue20367@psf.upfronthosting.co.za> Glenn Langford added the comment: @Victor: Thank you, and I appreciate all your advice! I am still learning the dev environment but hope to be helpful. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 00:45:59 2014 From: report at bugs.python.org (Christian Heimes) Date: Sun, 26 Jan 2014 23:45:59 +0000 Subject: [issue20394] Coverity complains on audioop In-Reply-To: <1390721721.09.0.648062700512.issue20394@psf.upfronthosting.co.za> Message-ID: <1390779959.83.0.901638495575.issue20394@psf.upfronthosting.co.za> Christian Heimes added the comment: Coverity is concerned about the value of `q` when `len < 0`. The expression Py_ssize_t q = len > 0 ? 1 + (len - 1) / inrate : 0; returns a positive, non-null value for len > 0. Another check ensures that len != 0 a couple of lines earlier. In theory it is possible that len < 0. After all it's a signed integer type. Coverity tries very hard to guess the intention of code. Because there is a check for len > 0, Coverity thinks that the code has to handle len < 0. IMO a good fix should check len >= 0 very early and replace that line with Py_ssize_t q = 1 + (len - 1) / inrate; ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 00:54:36 2014 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 26 Jan 2014 23:54:36 +0000 Subject: [issue20395] Extract generated clinic code in Modules/_pickle.c to separate file In-Reply-To: <1390734339.8.0.0968166670001.issue20395@psf.upfronthosting.co.za> Message-ID: <1390780476.19.0.255293895047.issue20395@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: +1 from me as well for a separate file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 01:07:06 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Jan 2014 00:07:06 +0000 Subject: [issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic In-Reply-To: <1389207811.28.0.849373473564.issue20193@psf.upfronthosting.co.za> Message-ID: <3fCB8p2qmdz7LjS@mail.python.org> Roundup Robot added the comment: New changeset c2e425a05d35 by Christian Heimes in branch 'default': Issue #20193: Fix commit r6f217456b9ba by including clinic/zlibmodule.c.h instead http://hg.python.org/cpython/rev/c2e425a05d35 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 01:12:28 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Jan 2014 00:12:28 +0000 Subject: [issue20394] Coverity complains on audioop In-Reply-To: <1390721721.09.0.648062700512.issue20394@psf.upfronthosting.co.za> Message-ID: <3fCBGz3Hcvz7LkF@mail.python.org> Roundup Robot added the comment: New changeset bf52f2dbfdde by Christian Heimes in branch 'default': Issue #20394: Attempt to silence CID 1164423: Division or modulo by zero in audioop_ratecv_impl() http://hg.python.org/cpython/rev/bf52f2dbfdde ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 01:39:07 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Jan 2014 00:39:07 +0000 Subject: [issue19023] ctypes docs: Unimplemented and undocumented features In-Reply-To: <1379246270.23.0.998338553474.issue19023@psf.upfronthosting.co.za> Message-ID: <1390783147.62.0.905191912048.issue19023@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +amaury.forgeotdarc, belopolsky, meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 02:14:52 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Jan 2014 01:14:52 +0000 Subject: [issue20391] windows python launcher should support explicit 64-bit version In-Reply-To: <1390666697.34.0.8179359034.issue20391@psf.upfronthosting.co.za> Message-ID: <1390785292.73.0.122530388401.issue20391@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 02:25:05 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Jan 2014 01:25:05 +0000 Subject: [issue20338] Idle: increase max calltip width In-Reply-To: <1390344102.42.0.241411598779.issue20338@psf.upfronthosting.co.za> Message-ID: <3fCCtj6N9Cz7Ln5@mail.python.org> Roundup Robot added the comment: New changeset d960c4cabb2b by Terry Jan Reedy in branch '2.7': Issue #20338: Increase allowed tip width slightly and wrap long signagure lines. http://hg.python.org/cpython/rev/d960c4cabb2b New changeset 7dcc19308a7b by Terry Jan Reedy in branch '3.3': Issue #20338: Increase allowed tip width slightly and wrap long signagure lines. http://hg.python.org/cpython/rev/7dcc19308a7b New changeset f7061219303c by Terry Jan Reedy in branch 'default': Issue #20338: Increase allowed tip width slightly and wrap long signagure lines. http://hg.python.org/cpython/rev/f7061219303c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 02:26:21 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 27 Jan 2014 01:26:21 +0000 Subject: [issue20399] Comparison of memoryview In-Reply-To: <1390768657.21.0.774991286622.issue20399@psf.upfronthosting.co.za> Message-ID: <1390785981.08.0.40149387217.issue20399@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This sounds reasonable, at least when the two memoryviews have the same shape. ---------- components: +Interpreter Core -Library (Lib) nosy: +pitrou, skrah type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 02:37:07 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 27 Jan 2014 01:37:07 +0000 Subject: [issue20338] Idle: increase max calltip width In-Reply-To: <1390344102.42.0.241411598779.issue20338@psf.upfronthosting.co.za> Message-ID: <1390786627.01.0.786797371496.issue20338@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I increased indent to 4 spaces and made it easier to change. I believe old-styles classes do not have .__new__, so test of TextWrapper will ensure that they work. Inspect.signature should have correct logic to handle .__new__, with or without .__init__. (I presume that if both are present, they must be consistent, so .__init__ should be used.) You might want to check both behavior and test file for .signature. Idle gets .signature upgrades for free when we switch, which I hope can be in a few months at worst. Programmer use of .__new__ without .__init__ is rare enough (extremely so) that I prefer to wait. As it is, switching will already mean removing some of the current logic. ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 02:52:38 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 27 Jan 2014 01:52:38 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <1390787558.68.0.938892264725.issue19081@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Updated to make that function (zipimporter_init) easier to follow by not repurposing the path variable mid-function and allocate the local path buffer rather than keeping it on the stack. ---------- Added file: http://bugs.python.org/file33736/issue19081-subimport-fix-gps04.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 03:09:10 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Mon, 27 Jan 2014 02:09:10 +0000 Subject: [issue15216] Support setting the encoding on a text stream after creation In-Reply-To: <1340880558.16.0.0136840668667.issue15216@psf.upfronthosting.co.za> Message-ID: <1390788550.72.0.133062417677.issue15216@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Question: What is the point of the old_encoding = codecs.lookup(self._encoding).name encoding = codecs.lookup(encoding).name if encoding == old_encoding and errors == self._errors: # no change return dance? Isn't this equivalent to if encoding == self.encoding and errors == self._errors: # no change return except that it doesn't validate the given encoding? But if the encoding is invalid, isn't it enough that the exception is raised a few lines further down? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 03:13:41 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Mon, 27 Jan 2014 02:13:41 +0000 Subject: [issue15216] Support setting the encoding on a text stream after creation In-Reply-To: <1340880558.16.0.0136840668667.issue15216@psf.upfronthosting.co.za> Message-ID: <1390788821.56.0.406260063646.issue15216@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Second question: The following looks as if a BOM might be written for writeable, non-seekable streams: # don't write a BOM in the middle of a file if self._seekable and self.writable(): position = self.buffer.tell() if position != 0: try: self._get_encoder().setstate(0) except LookupError: # Sometimes the encoder doesn't exist pass Is that really desirable? It seems to me the safe choice is to *not* write the BOM, except when we know it's safe. Eg: # don't write a BOM unless we know we're at the beginning of a file if (self.writeable() and not (self._seekable and self.buffer.tell() == 0)): try: self._get_encoder().setstate(0) except LookupError: # Sometimes the encoder doesn't exist pass ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 03:16:33 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 27 Jan 2014 02:16:33 +0000 Subject: [issue20401] inspect.signature removes initial starred method params (bug) Message-ID: <1390788993.17.0.660022728639.issue20401@psf.upfronthosting.co.za> New submission from Terry J. Reedy: >>> import inspect >>> class C: def meth(*args): pass >>> str(inspect.signature(C.meth)) '(*args)' >>> c=C() >>> str(s=inspect.signature(c.meth)) '()' *args should have been left in even for the bound method, as idlelib calltips do. Since '*' is not a word character, idlelib.Calltips._first_param = re.compile('(?<=\()\w*\,?\s*') does not see '*args' as a substring to be deleted with argspec = _first_param.sub("", argspec) The same comment applies to def meth2(**kwds): pass even though calling the bound method would fail. ---------- messages: 209378 nosy: terry.reedy, yselivanov priority: normal severity: normal stage: needs patch status: open title: inspect.signature removes initial starred method params (bug) type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 03:28:30 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 27 Jan 2014 02:28:30 +0000 Subject: [issue20401] inspect.signature removes initial starred method params (bug) In-Reply-To: <1390788993.17.0.660022728639.issue20401@psf.upfronthosting.co.za> Message-ID: <1390789710.04.0.416903172901.issue20401@psf.upfronthosting.co.za> Larry Hastings added the comment: Yury, can you look in to this? I have been modifying inspect.signature, but (almost) exclusively in from_builtin. If this is my fault I'll be happy to fix it. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 03:40:14 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 27 Jan 2014 02:40:14 +0000 Subject: [issue19903] Idle: Use inspect.signature for calltips In-Reply-To: <1386289306.22.0.0855188637089.issue19903@psf.upfronthosting.co.za> Message-ID: <1390790414.65.0.515744474185.issue19903@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- dependencies: +inspect.signature does not support new functools.partialmethod, inspect.signature removes initial starred method params (bug) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 04:24:16 2014 From: report at bugs.python.org (Rob Lanphier) Date: Mon, 27 Jan 2014 03:24:16 +0000 Subject: [issue20402] List comprehensions should be noted in for loop documentation Message-ID: <1390793056.66.0.0906291243976.issue20402@psf.upfronthosting.co.za> New submission from Rob Lanphier: The current list comprehension documentation is difficult to find for someone who doesn't know what a list comprehension is. Example of this problem: http://www.reddit.com/r/learnprogramming/comments/1w6slm/different_kind_of_for_loop_python/ Since list comprehensions are a riff off of "for" loop syntax, they should at least be noted and linked to from section 4.2 ("for statements" section) and quite possibly 5.6 ("Looping constructs") ---------- assignee: docs at python components: Documentation messages: 209380 nosy: docs at python, robla priority: normal severity: normal status: open title: List comprehensions should be noted in for loop documentation type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 04:28:01 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Jan 2014 03:28:01 +0000 Subject: [issue17721] Help button on preference window doesn't work In-Reply-To: <1365876479.31.0.960204905759.issue17721@psf.upfronthosting.co.za> Message-ID: <3fCGcc2zwjz7LkX@mail.python.org> Roundup Robot added the comment: New changeset 3d343dfe6269 by Terry Jan Reedy in branch '2.7': Issue #17721: Remove non-functional configuration dialog help button until we http://hg.python.org/cpython/rev/3d343dfe6269 New changeset 6e4b94019eae by Terry Jan Reedy in branch '3.3': Issue #17721: Remove non-functional configuration dialog help button until we http://hg.python.org/cpython/rev/6e4b94019eae New changeset be9843012124 by Terry Jan Reedy in branch 'default': Issue #17721: Remove non-functional configuration dialog help button until we http://hg.python.org/cpython/rev/be9843012124 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 04:35:30 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 27 Jan 2014 03:35:30 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1390793730.87.0.263499479993.issue7776@psf.upfronthosting.co.za> Benjamin Peterson added the comment: A few comments - Your docstring for set_tunnel claims the method sends CONNECT when it in fact doesn't touch the network at all. - Instead of 3 parallel arrays for tunnel information, it would be better to have a TunnelInfo class to contain host/port/headers (perhaps a namedtuple?). ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 04:41:27 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 27 Jan 2014 03:41:27 +0000 Subject: [issue20403] Idle options dialog: add help Message-ID: <1390794087.42.0.95323934944.issue20403@psf.upfronthosting.co.za> New submission from Terry J. Reedy: The Idle options/configuration dialog had a useless Help button that did nothing. #17721 commented out the creation and packing of the button. This issue is about making the Help method work. Perhaps it should open the general help document at the options section. Or perhaps this should be a separate file. Once Help() does something, re-enable the 4 disabled lines. ---------- messages: 209383 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: Idle options dialog: add help type: enhancement versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 04:42:56 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 27 Jan 2014 03:42:56 +0000 Subject: [issue17721] Help button on preference window doesn't work In-Reply-To: <1365876479.31.0.960204905759.issue17721@psf.upfronthosting.co.za> Message-ID: <1390794176.49.0.431767045903.issue17721@psf.upfronthosting.co.za> Terry J. Reedy added the comment: #20403 is about making Help work and putting the button back. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 04:43:15 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 27 Jan 2014 03:43:15 +0000 Subject: [issue17721] Help button on preference window doesn't work In-Reply-To: <1365876479.31.0.960204905759.issue17721@psf.upfronthosting.co.za> Message-ID: <1390794195.35.0.92767266349.issue17721@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- assignee: -> terry.reedy resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 04:44:40 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 27 Jan 2014 03:44:40 +0000 Subject: [issue15216] Support setting the encoding on a text stream after creation In-Reply-To: <1340880558.16.0.0136840668667.issue15216@psf.upfronthosting.co.za> Message-ID: <1390794280.19.0.796391625712.issue15216@psf.upfronthosting.co.za> Nick Coghlan added the comment: A given encoding may have multiple aliases, and also variant spellings that are normalized before doing the codec lookup. Doing the lookup first means we run through all of the normalisation and aliasing machinery and then compare the *canonical* names. For example: >>> import codecs >>> codecs.lookup('ANSI_X3.4_1968').name 'ascii' >>> codecs.lookup('ansi_x3.4_1968').name 'ascii' >>> codecs.lookup('ansi-x3.4-1968').name 'ascii' >>> codecs.lookup('ASCII').name 'ascii' >>> codecs.lookup('ascii').name 'ascii' A public "codecs.is_same_encoding" API might be a worthwhile and self-documenting addition, rather than just adding a comment that explains the need for the canonicalisation dance. As far as the second question goes, for non-seekable output streams, this API is inherently a case of "here be dragons" - that's a large part of the reason why it took so long for us to accept it as a feature we really should provide. We need to support writing a BOM to sys.stdout and sys.stderr - potentially doing so in the middle of existing output isn't really any different from the chance of implicitly switching encodings mid-stream. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 04:47:41 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 27 Jan 2014 03:47:41 +0000 Subject: [issue20401] inspect.signature removes initial starred method params (bug) In-Reply-To: <1390788993.17.0.660022728639.issue20401@psf.upfronthosting.co.za> Message-ID: <1390794461.32.0.659396040798.issue20401@psf.upfronthosting.co.za> Terry J. Reedy added the comment: There does not appear to be a test for this. If so, this case may not have ever worked right. Here is the only failure at the moment (which should also be fixed). F:\Python\dev>4\py34\pcbuild\python_d.exe -m test test_inspect [1/1] test_inspect test test_inspect failed -- Traceback (most recent call last): File "F:\Python\dev\4\py34\lib\test\test_inspect.py", line 1623, in test_signature_on_builtins test_callable(type) File "F:\Python\dev\4\py34\lib\test\test_inspect.py", line 1604, in test_callable signature = inspect.signature(o) File "F:\Python\dev\4\py34\lib\inspect.py", line 1555, in signature raise ValueError('callable {!r} is not supported by signature'.format(obj)) ValueError: callable is not supported by signature ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 04:49:41 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 27 Jan 2014 03:49:41 +0000 Subject: [issue20401] inspect.signature removes initial starred method params (bug) In-Reply-To: <1390788993.17.0.660022728639.issue20401@psf.upfronthosting.co.za> Message-ID: <1390794581.47.0.480307908094.issue20401@psf.upfronthosting.co.za> Larry Hastings added the comment: I just tried it in 3.3 (3.3.1rc1) and it had the same problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 04:58:51 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Jan 2014 03:58:51 +0000 Subject: [issue12704] Language Reference: Clarify behaviour of yield when generator is not resumed In-Reply-To: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za> Message-ID: <3fCHJB5MpQz7LjV@mail.python.org> Roundup Robot added the comment: New changeset e02da391741f by Benjamin Peterson in branch '3.3': eliminate redundancy between yield stmt and yield expr docs (closes #12704) http://hg.python.org/cpython/rev/e02da391741f New changeset c6b4a5354c23 by Benjamin Peterson in branch 'default': merge 3.3 (closes #12704) http://hg.python.org/cpython/rev/c6b4a5354c23 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 04:59:48 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 27 Jan 2014 03:59:48 +0000 Subject: [issue12704] Language Reference: Clarify behaviour of yield when generator is not resumed In-Reply-To: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za> Message-ID: <1390795188.74.0.809343548761.issue12704@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Thank you. In the future, please remember to wrap paragraphs to 80 chars and run "make patchcheck" to cleanup whitespace issues. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 05:00:59 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 27 Jan 2014 04:00:59 +0000 Subject: [issue19145] Inconsistent behaviour in itertools.repeat when using negative times In-Reply-To: <1380727396.47.0.412229295257.issue19145@psf.upfronthosting.co.za> Message-ID: <1390795259.43.0.0432461530567.issue19145@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: If "equivalent to" code is not considered to be part of documentation, then the meaning of negative times should be documented. ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 05:06:17 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 27 Jan 2014 04:06:17 +0000 Subject: [issue20338] Idle: increase max calltip width In-Reply-To: <1390344102.42.0.241411598779.issue20338@psf.upfronthosting.co.za> Message-ID: <1390795577.32.0.847658318016.issue20338@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Actually, all new-style classes .__new__ and .__init__ from object if not over-ridden. The calltip code depends on the .__init__ inheritance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 05:12:29 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Mon, 27 Jan 2014 04:12:29 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1390795949.56.0.601011130756.issue20173@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the updated patch for sha1module after changes from Larry to clinic. ---------- Added file: http://bugs.python.org/file33737/clinic_sha1module_v5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 05:20:00 2014 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Mon, 27 Jan 2014 04:20:00 +0000 Subject: [issue20366] SQLite FTS (full text search) In-Reply-To: <1390487950.26.0.724740577433.issue20366@psf.upfronthosting.co.za> Message-ID: <1390796400.08.0.127074773144.issue20366@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 05:37:54 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 27 Jan 2014 04:37:54 +0000 Subject: [issue20401] inspect.signature removes initial starred method params (bug) In-Reply-To: <1390794581.47.0.480307908094.issue20401@psf.upfronthosting.co.za> Message-ID: Yury Selivanov added the comment: Yes, that's s bug. I'll take a look tomorrow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 05:40:59 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Mon, 27 Jan 2014 04:40:59 +0000 Subject: [issue15216] Support setting the encoding on a text stream after creation In-Reply-To: <1340880558.16.0.0136840668667.issue15216@psf.upfronthosting.co.za> Message-ID: <1390797659.9.0.739101962609.issue15216@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Thanks Nick! Will take this into account. I've stumbled over another question in the meantime: It seems to me that after the call to set_encoding(), self._snapshot contains the decoder flags from the state of the *old* decoder. On the next call of eg. tell(), the flags from the old decoder are then passed to setstate() of the new decoder. Isn't this a problem? I thought the flags could mean different things to different codecs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 05:50:23 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 27 Jan 2014 04:50:23 +0000 Subject: [issue15216] Support setting the encoding on a text stream after creation In-Reply-To: <1340880558.16.0.0136840668667.issue15216@psf.upfronthosting.co.za> Message-ID: <1390798223.67.0.152662454713.issue15216@psf.upfronthosting.co.za> Nick Coghlan added the comment: That's entirely plausible - Victor's current patch is definitely a proof-of-concept rather than a battle-tested implementation. I'm not sure you could actually *provoke* that bug with any of our existing codecs, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 06:01:16 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 27 Jan 2014 05:01:16 +0000 Subject: [issue20404] Delayed exception using non-text encodings with TextIOWrapper Message-ID: <1390798876.83.0.936873438895.issue20404@psf.upfronthosting.co.za> New submission from Nick Coghlan: TextIOWrapper doesn't check the codec type early the way the convenience methods now do, so the open() method currently still suffers from the problems Victor described in issue 19619 for str.encode() and bytes.decode(): >>> with open("hex.txt", 'w') as f: ... f.write("aabbccddeeff") ... 12 >>> print(open('hex.txt').read()) aabbccddeeff >>> print(open('hex.txt', encoding='hex').read()) Traceback (most recent call last): File "", line 1, in TypeError: decoder should return a string result, not 'bytes' These codecs are never going to work correctly with TextIOWrapper, so we should add the appropriate compatibility check in the constructor. ---------- assignee: ncoghlan messages: 209396 nosy: haypo, larry, ncoghlan, serhiy.storchaka priority: release blocker severity: normal stage: test needed status: open title: Delayed exception using non-text encodings with TextIOWrapper type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 06:18:04 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Mon, 27 Jan 2014 05:18:04 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1390799884.78.0.480316997018.issue7776@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Thanks for the review! I've attached an updated patch. An update to the set_tunnel library documentation is being discussed in issue 11448. I'm not sure how to best handle the overlap. Maybe the best way is to first deal with issue 11448, and then add the changes resulting from this issue? ---------- Added file: http://bugs.python.org/file33738/issue7776_rev5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 06:24:39 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 27 Jan 2014 05:24:39 +0000 Subject: [issue20405] Add io.BinaryTransformWrapper and a "transform" parameter to open() Message-ID: <1390800279.91.0.834285021962.issue20405@psf.upfronthosting.co.za> New submission from Nick Coghlan: Issue 20404 points out that io.TextIOWrapper can't be used with binary transform codecs like bz2 because the types are wrong. By contrast, codecs.open() still defaults to working in binary mode, and just switches to returning a different type based on the specified encoding (exactly the kind of value-driven output type changes we're trying to eliminate from the core text model): >>> import codecs >>> print(codecs.open('hex.txt').read()) b'aabbccddeeff' >>> print(codecs.open('hex.txt', encoding='hex').read()) b'\xaa\xbb\xcc\xdd\xee\xff' >>> print(codecs.open('hex.txt', encoding='utf-8').read()) aabbccddeeff While for 3.4, I plan to just extend the issue 19619 blacklist to also cover TextIOWrapper (and hence open()), it seems to me that there is a valid use case for bytes-to-bytes transform support directly in the IO stack. A PEP for 3.5 could propose: - providing a public API that allows codecs to be classified into at least the following groups ("binary" = memorview compatible data exporters, including both bytes and bytearray): - text encodings (decodes binary to str, encodes str to bytes) - binary transforms (decodes *and* encodes binary to bytes) - text transforms (decodes and encodes str to str) - hybrid transforms (acts as both a binary transform *and* as a text transform) - hybrid encodings (decodes binary and potentially str to str, encodes binary and str to bytes) - arbitrary encodings (decodes and encodes object to object, without fitting any of the above categories) - adding io.BinaryTransformWrapper that applies binary transforms when reading and writing data (similar to the way TextIOWrapper applies text encodings) - adding a "transform" parameter to open that inserts BinaryTransformWrapper into the stack at the appropriate place (the PEP process would need to decide between supporting just a single transform per stream or multiple). In text mode, TextIOWrapper would be added to the stack after any binary transforms. Optionally, the idea could also be extended to adding io.TextTransformWrapper and a "text_transform" parameter, but those seem somewhat less useful. ---------- components: IO, Interpreter Core, Library (Lib) messages: 209398 nosy: benjamin.peterson, ezio.melotti, haypo, hynek, lemburg, ncoghlan, pitrou, serhiy.storchaka, stutzbach priority: normal severity: normal stage: needs patch status: open title: Add io.BinaryTransformWrapper and a "transform" parameter to open() type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 06:25:43 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 27 Jan 2014 05:25:43 +0000 Subject: [issue20404] Delayed exception using non-text encodings with TextIOWrapper In-Reply-To: <1390798876.83.0.936873438895.issue20404@psf.upfronthosting.co.za> Message-ID: <1390800343.6.0.843632031719.issue20404@psf.upfronthosting.co.za> Nick Coghlan added the comment: I also created issue 20405 as an RFE for 3.5, since it seems there is a possible gap in capability relative to Python 2 here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 06:35:14 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 27 Jan 2014 05:35:14 +0000 Subject: [issue20401] inspect.signature removes initial starred method params (bug) In-Reply-To: <1390788993.17.0.660022728639.issue20401@psf.upfronthosting.co.za> Message-ID: <1390800914.48.0.143803716665.issue20401@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Sorry, I should have said that I tried repository versions of both 3.3 and 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 07:15:22 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 27 Jan 2014 06:15:22 +0000 Subject: [issue20386] socket.SocketType enum overwrites import of _socket.SocketType In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za> Message-ID: <1390803322.93.0.341521216365.issue20386@psf.upfronthosting.co.za> Georg Brandl added the comment: "integer enumerations of " sounds weird to me. Also, here it might be nice to link to IntEnum (use :class:`.IntEnum`). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 07:30:11 2014 From: report at bugs.python.org (Christopher Welborn) Date: Mon, 27 Jan 2014 06:30:11 +0000 Subject: [issue19620] tokenize documentation contains typos (argment instead of argument) In-Reply-To: <1384569112.62.0.796047767365.issue19620@psf.upfronthosting.co.za> Message-ID: <1390804211.54.0.9570653761.issue19620@psf.upfronthosting.co.za> Christopher Welborn added the comment: I should've made the patch, sorry about that. I got really busy and by the time I came back it had been fixed already. (fast turnaround :) I'm just glad it got fixed. I'm removing myself from the nosy-list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 07:30:47 2014 From: report at bugs.python.org (Christopher Welborn) Date: Mon, 27 Jan 2014 06:30:47 +0000 Subject: [issue19620] tokenize documentation contains typos (argment instead of argument) In-Reply-To: <1384569112.62.0.796047767365.issue19620@psf.upfronthosting.co.za> Message-ID: <1390804247.88.0.873109759675.issue19620@psf.upfronthosting.co.za> Changes by Christopher Welborn : ---------- nosy: -cjwelborn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 07:41:18 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Mon, 27 Jan 2014 06:41:18 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1390804878.11.0.329121820617.issue20173@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the updated patch for sha256module after changes from Larry to clinic. ---------- Added file: http://bugs.python.org/file33739/clinic_sha256module_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 07:51:10 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Jan 2014 06:51:10 +0000 Subject: [issue20405] Add io.BinaryTransformWrapper and a "transform" parameter to open() In-Reply-To: <1390800279.91.0.834285021962.issue20405@psf.upfronthosting.co.za> Message-ID: <1390805470.62.0.510210597204.issue20405@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think this is redundant because codecs.StreamReader and codecs.StreamWriter already exist. They are buggy, but now they are less buggy then at the time when Victor wrote PEP 400 and can be improved more. TextIOWrapper serves important special case, but for binary->binary and text->text transformations codecs.Stream* should be enough (after fixing some misbehaving codecs of course). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 08:00:34 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Jan 2014 07:00:34 +0000 Subject: [issue20394] Coverity complains on audioop In-Reply-To: <1390721721.09.0.648062700512.issue20394@psf.upfronthosting.co.za> Message-ID: <1390806034.66.0.815356574647.issue20394@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If Coverity is silenced, this patch should be backported to 2.7 and 3.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 08:09:30 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 27 Jan 2014 07:09:30 +0000 Subject: [issue15189] tkinter.messagebox does not use the application's icon In-Reply-To: <1340695188.66.0.13086714969.issue15189@psf.upfronthosting.co.za> Message-ID: <1390806570.28.0.461447621349.issue15189@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 08:25:06 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 27 Jan 2014 07:25:06 +0000 Subject: [issue20405] Add io.BinaryTransformWrapper and a "transform" parameter to open() In-Reply-To: <1390800279.91.0.834285021962.issue20405@psf.upfronthosting.co.za> Message-ID: <1390807506.66.0.764675005243.issue20405@psf.upfronthosting.co.za> Nick Coghlan added the comment: That's certainly a reasonable position to take - they use the same object->object model that the codecs module in general provides, which means Python 3.x can already handle the relevant use cases. Any such PEP would be about deciding whether or not binary transforms are a case worth having additional infrastructure to support, or whether we just say that anyone wanting to deal with codecs other than test encodings should use the type neutral codec APIs. In the latter case, all that would be needed is a simple "is_text_encoding" flag, inspired by the private flag we already added to implement the non-text-encoding blacklist in 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 08:32:06 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Jan 2014 07:32:06 +0000 Subject: [issue19966] Wrong mtimes of Include/Python-ast.h and Python/Python-ast.c in tarballs In-Reply-To: <1386869822.97.0.610221510269.issue19966@psf.upfronthosting.co.za> Message-ID: <3fCN2F2t6kz7Llv@mail.python.org> Roundup Robot added the comment: New changeset 0279445c05d5 by Georg Brandl in branch 'default': Closes #19966: allow hgtouch to operate on a base dir that is != the repo root. http://hg.python.org/cpython/rev/0279445c05d5 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 08:33:06 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 27 Jan 2014 07:33:06 +0000 Subject: [issue19966] Wrong mtimes of Include/Python-ast.h and Python/Python-ast.c in tarballs In-Reply-To: <1386869822.97.0.610221510269.issue19966@psf.upfronthosting.co.za> Message-ID: <1390807986.6.0.0576386757058.issue19966@psf.upfronthosting.co.za> Georg Brandl added the comment: OK, 3.3.4rc1 shouldn't have the problem, and neither 3.4.0b4 ff. with the changes I just checked into hgtouch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 08:35:37 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 27 Jan 2014 07:35:37 +0000 Subject: [issue20184] Derby #16: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140504.71.0.617730511292.issue20184@psf.upfronthosting.co.za> Message-ID: <1390808137.5.0.410560804643.issue20184@psf.upfronthosting.co.za> Nick Coghlan added the comment: Assigning to myself to make it clear that bltinmodule is the only part of this still under consideration for 3.4. The test_pydoc and test_gdb failures pointed to real issues with the previous patch: - the pydoc errors themselves were incidental, indicating that I had added doctests to chr and ord. However, those new doctests used a Unicode character in a C string, which seems like a recipe for portability trouble. I took those doctests out again, and updated the prose docs instead. I like my obscure multilingual Monty Python reference and would like to keep it now I thought of it :) - the gdb error suggests that gdb is relying on being able to find builtin_id based on its exact signature, including the parameter names. Rather than trying to figure out the full details of that, I've instead partially reverted its conversion to Argument Clinic by disabling the input block and restoring the old parameter names in the function signature. We can change it back to full conversion for 3.5, after AC has the ability to use different names in the Python signature and in the C implementation function. This does mean we'll want to update the signature by hand once you merge the patch changing the indicators that argument clinic is looking for. ---------- assignee: -> ncoghlan Added file: http://bugs.python.org/file33740/issue20184_builtin_conversion_v3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 08:37:09 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Mon, 27 Jan 2014 07:37:09 +0000 Subject: [issue19145] Inconsistent behaviour in itertools.repeat when using negative times In-Reply-To: <1380727396.47.0.412229295257.issue19145@psf.upfronthosting.co.za> Message-ID: <1390808229.0.0.709693336234.issue19145@psf.upfronthosting.co.za> Vajrasky Kok added the comment: How to handle this "problem" in Python maintenance releases (2.7, 3.3 and soon-to-be 3.4) is being discussed here: https://mail.python.org/pipermail/python-dev/2014-January/132101.html In case, we are taking "backporting the full fix" road, here is the patch. I modified Larry's patch based on Serhiy's suggestion and bettered the error message, added test, and fixed the doc. "Better error message" -> without my fix, repeat('a', times='cutecat') will throw "an integer is required". I make it as such it will throw "times must be integer or None." ---------- Added file: http://bugs.python.org/file33741/fix_itertools_repeat_negative_number_means_0_v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 09:07:53 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Jan 2014 08:07:53 +0000 Subject: [issue20394] Coverity complains on audioop In-Reply-To: <1390721721.09.0.648062700512.issue20394@psf.upfronthosting.co.za> Message-ID: <3fCNqY0dF8z7Ljb@mail.python.org> Roundup Robot added the comment: New changeset 0a406b6fe61f by Christian Heimes in branch 'default': I forgot to add a Misc/NEWS entry for issue #20394 http://hg.python.org/cpython/rev/0a406b6fe61f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 09:09:38 2014 From: report at bugs.python.org (Christian Heimes) Date: Mon, 27 Jan 2014 08:09:38 +0000 Subject: [issue20394] Coverity complains on audioop In-Reply-To: <1390721721.09.0.648062700512.issue20394@psf.upfronthosting.co.za> Message-ID: <1390810178.66.0.568595350475.issue20394@psf.upfronthosting.co.za> Christian Heimes added the comment: The commit has silenced coverity's warning. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 09:13:52 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Jan 2014 08:13:52 +0000 Subject: [issue20367] concurrent.futures.as_completed() fails when given duplicate Futures In-Reply-To: <1390489248.24.0.751917808957.issue20367@psf.upfronthosting.co.za> Message-ID: <3fCNyR42yVz7LkC@mail.python.org> Roundup Robot added the comment: New changeset 791b69f9f96d by Victor Stinner in branch '3.3': Issue #20367: Fix behavior of concurrent.futures.as_completed() for duplicate http://hg.python.org/cpython/rev/791b69f9f96d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 09:14:07 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 27 Jan 2014 08:14:07 +0000 Subject: [issue20367] concurrent.futures.as_completed() fails when given duplicate Futures In-Reply-To: <1390489248.24.0.751917808957.issue20367@psf.upfronthosting.co.za> Message-ID: <1390810447.9.0.125492001047.issue20367@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: remind -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 09:15:27 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Jan 2014 08:15:27 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <3fCP0H2W4QzS64@mail.python.org> Roundup Robot added the comment: New changeset 323cb02abfc6 by Gregory P. Smith in branch '2.7': Issue #19081: Remove the zipimporter.files reference as the zip TOC http://hg.python.org/cpython/rev/323cb02abfc6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 09:17:13 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Mon, 27 Jan 2014 08:17:13 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1390810633.09.0.326200227114.issue20173@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the updated patch for sha512module after changes from Larry to clinic. ---------- Added file: http://bugs.python.org/file33742/clinic_sha512module_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 09:42:44 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Jan 2014 08:42:44 +0000 Subject: [issue19077] More robust TemporaryDirectory cleanup In-Reply-To: <1379948326.54.0.765934536043.issue19077@psf.upfronthosting.co.za> Message-ID: <1390812164.57.0.166824801372.issue19077@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yeah, I thought about it. Only flag should be false in shutdown mode, because it will be None when a module will be cleaned. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 09:47:05 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Mon, 27 Jan 2014 08:47:05 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1390812425.98.0.926599662207.issue20173@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the updated patch for md5module after changes from Larry to clinic. ---------- Added file: http://bugs.python.org/file33743/clinic_md5module_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 09:50:32 2014 From: report at bugs.python.org (Eduardo Robles Elvira) Date: Mon, 27 Jan 2014 08:50:32 +0000 Subject: [issue18321] Multivolume support in tarfile module In-Reply-To: <1372406777.07.0.523288075904.issue18321@psf.upfronthosting.co.za> Message-ID: <1390812631.99.0.943082241748.issue18321@psf.upfronthosting.co.za> Eduardo Robles Elvira added the comment: Do we have any news on this patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 10:08:54 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Mon, 27 Jan 2014 09:08:54 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1390813734.45.0.591987355784.issue20185@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the updated patch for resource module based on Zachary's comment. ---------- Added file: http://bugs.python.org/file33744/clinic_resource_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 10:14:09 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Mon, 27 Jan 2014 09:14:09 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1390814049.24.0.0780223564597.issue20173@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Status: Modules/sha1module.c: done Modules/sha256module.c: done Modules/sha512module.c: done Modules/md5module.c: done All of them are ready for Python 3.4. /* AC 3.5: optional positional arguments */ Modules/_codecsmodule ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 10:27:59 2014 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 27 Jan 2014 09:27:59 +0000 Subject: [issue20399] Comparison of memoryview In-Reply-To: <1390768657.21.0.774991286622.issue20399@psf.upfronthosting.co.za> Message-ID: <1390814879.95.0.290147489569.issue20399@psf.upfronthosting.co.za> Mark Lawrence added the comment: Some discussion here https://groups.google.com/forum/#!topic/dev-python/1D_iExlsva8 ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 10:33:37 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Jan 2014 09:33:37 +0000 Subject: [issue19077] More robust TemporaryDirectory cleanup In-Reply-To: <1379948326.54.0.765934536043.issue19077@psf.upfronthosting.co.za> Message-ID: <3fCQkS4syjz7LjW@mail.python.org> Roundup Robot added the comment: New changeset 50aa9e3ab9a4 by Serhiy Storchaka in branch '3.3': Issue #19077: tempfile.TemporaryDirectory cleanup is now most likely http://hg.python.org/cpython/rev/50aa9e3ab9a4 New changeset d792eb3afa58 by Serhiy Storchaka in branch 'default': Issue #19077: tempfile.TemporaryDirectory cleanup no longer fails when http://hg.python.org/cpython/rev/d792eb3afa58 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 10:33:38 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Jan 2014 09:33:38 +0000 Subject: [issue20395] Extract generated clinic code in Modules/_pickle.c to separate file In-Reply-To: <1390734339.8.0.0968166670001.issue20395@psf.upfronthosting.co.za> Message-ID: <3fCQkT2v0Tz7LjW@mail.python.org> Roundup Robot added the comment: New changeset 1aa8ea187560 by Serhiy Storchaka in branch 'default': Issue #20395: Extract generated clinic code in Modules/_pickle.c to separate file. http://hg.python.org/cpython/rev/1aa8ea187560 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 10:44:09 2014 From: report at bugs.python.org (Wim) Date: Mon, 27 Jan 2014 09:44:09 +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: <1390815849.5.0.564592979293.issue17088@psf.upfronthosting.co.za> Wim added the comment: Ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 10:52:06 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Jan 2014 09:52:06 +0000 Subject: [issue19077] More robust TemporaryDirectory cleanup In-Reply-To: <1379948326.54.0.765934536043.issue19077@psf.upfronthosting.co.za> Message-ID: <1390816326.89.0.557087656376.issue19077@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your patch Antoine. And thank you for your excellent idea Richard. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 10:52:31 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Jan 2014 09:52:31 +0000 Subject: [issue20395] Extract generated clinic code in Modules/_pickle.c to separate file In-Reply-To: <1390734339.8.0.0968166670001.issue20395@psf.upfronthosting.co.za> Message-ID: <1390816351.1.0.30728262847.issue20395@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 10:55:56 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 27 Jan 2014 09:55:56 +0000 Subject: [issue20405] Add io.BinaryTransformWrapper and a "transform" parameter to open() In-Reply-To: <1390800279.91.0.834285021962.issue20405@psf.upfronthosting.co.za> Message-ID: <1390816556.97.0.764787521437.issue20405@psf.upfronthosting.co.za> Antoine Pitrou added the comment: That doesn't sound terribly useful indeed. The "hex" example is a toy example. Real-world examples would involve compression (zlib...) but then it is probably much more efficient to have a dedicated implementation (GzipFile) rather than blindly call zlib.compress() or zlib.decompress() at each round. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 11:00:00 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 27 Jan 2014 10:00:00 +0000 Subject: [issue20405] Add io.BinaryTransformWrapper and a "transform" parameter to open() In-Reply-To: <1390800279.91.0.834285021962.issue20405@psf.upfronthosting.co.za> Message-ID: <1390816800.14.0.323059392586.issue20405@psf.upfronthosting.co.za> STINNER Victor added the comment: I agree with Antoine, I dislike the idea of BinaryTransformWrapper, it remembers me the evil codecs.EncodedFile thing. What are the usecases? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 11:08:10 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Jan 2014 10:08:10 +0000 Subject: [issue20406] Use application icon for IDLE Message-ID: <1390817290.68.0.153594821127.issue20406@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Currently IDLE use default Tk icon. The proposed patch sets special application icon for IDLE. ---------- components: IDLE files: idle_appicon.patch keywords: patch messages: 209428 nosy: kbk, roger.serwy, serhiy.storchaka, terry.reedy priority: normal severity: normal stage: patch review status: open title: Use application icon for IDLE type: enhancement Added file: http://bugs.python.org/file33745/idle_appicon.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 11:22:27 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Jan 2014 10:22:27 +0000 Subject: [issue15189] tkinter.messagebox does not use the application's icon In-Reply-To: <1340695188.66.0.13086714969.issue15189@psf.upfronthosting.co.za> Message-ID: <1390818147.55.0.140794417788.issue15189@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Mark's recipe works pretty well (requires Tk 8.5+). And you can use special method for this: app.wm_iconphoto(True, icon). What we can made more? We can set Python-related application icon for IDLE (issue20406). But for user applications their authors are responsible to configure properly icons. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 11:26:11 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 27 Jan 2014 10:26:11 +0000 Subject: [issue20405] Add io.BinaryTransformWrapper and a "transform" parameter to open() In-Reply-To: <1390816800.14.0.323059392586.issue20405@psf.upfronthosting.co.za> Message-ID: <52E6343E.1020002@egenix.com> Marc-Andre Lemburg added the comment: On 27.01.2014 11:00, STINNER Victor wrote: > > STINNER Victor added the comment: > > I agree with Antoine, I dislike the idea of BinaryTransformWrapper, it remembers me the evil codecs.EncodedFile thing. > > What are the usecases? Ever used "recode" ? The purpose of EncodedFile/StreamRecoder was to convert an externally used encoding to a standard internal one - mainly to allow programs that didn't want to use Unicode for processing to still benefit from the codecs that come with Python. E.g. the example at the end of codecs.py allows using Latin-1 within the application, while talking to the console using UTF-8. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 11:29:54 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Jan 2014 10:29:54 +0000 Subject: [issue20405] Add io.BinaryTransformWrapper and a "transform" parameter to open() In-Reply-To: <1390800279.91.0.834285021962.issue20405@psf.upfronthosting.co.za> Message-ID: <1390818594.06.0.076666678529.issue20405@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Nobody talks to the console using hex_codec. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 11:36:51 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Mon, 27 Jan 2014 10:36:51 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1390819011.09.0.893036237197.issue20185@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the updated patch for type module based on Zachary's comment. However, I can not convert this method. {"__subclasshook__", object_subclasshook, METH_CLASS | METH_VARARGS, object_subclasshook_doc}, static PyObject * object_subclasshook(PyObject *cls, PyObject *args) { Py_RETURN_NOTIMPLEMENTED; } >>> type.__subclasshook__() NotImplemented >>> type.__subclasshook__('cutecat') NotImplemented >>> type.__subclasshook__('cutecat', 1, []) NotImplemented ---------- Added file: http://bugs.python.org/file33746/clinic_typeobject_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 12:05:14 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 27 Jan 2014 11:05:14 +0000 Subject: [issue20405] Add io.BinaryTransformWrapper and a "transform" parameter to open() In-Reply-To: <1390800279.91.0.834285021962.issue20405@psf.upfronthosting.co.za> Message-ID: <1390820714.77.0.732482742044.issue20405@psf.upfronthosting.co.za> Nick Coghlan added the comment: I only used hex as the example because it was trivial to generate test data for. The stackable streaming IO model is an extremely powerful one - the approach we already use in the io module has some similarities to the one Texas Instruments use in DSP/BIOS (http://www.ti.com/tool/dspbios) and I know from experience how convenient that is. The model means you can push a lot of your data manipulation into your stream definitions, and keep all that data transformation logic out of your main application. (In my case, it let us mostly ignore the differences in a-law, u-law and ADPCM encoded audio, since we just built the IO streams differently depending on which one we were dealing with). However, relative to DSP/BIOS, our stream model is currently missing the "stackable" piece - it's difficult to plug additional wrappers into the stream, because we don't have either the "binary in, binary out" or the "text in, text out" component. A well designed streaming codec should be able to sit in the pipeline providing transparent encryption whether you're piping to a file, to another process or to a socket. If you're handling audio or video data, then you would also be able to place your codecs directly in the stream pipeline, rather than needing to come up with your own custom data pipeline model. This isn't a novel design overall - it's the way the signal processing world has been doing things for decades (I first learned this model when using DSP/BIOS more than a decade ago, and Linux STREAMS, which includes some similar concepts, is substantially older than that). The only novel concept here is the idea of offering this feature as part of Python 3's native io model. DSP/BIOS and STREAMS also have some solid design concepts around using gather/scatter devices for stream multiplexing, but that's not related to codec handling improvements. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 12:11:21 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 27 Jan 2014 11:11:21 +0000 Subject: [issue20405] Add io.BinaryTransformWrapper and a "transform" parameter to open() In-Reply-To: <1390800279.91.0.834285021962.issue20405@psf.upfronthosting.co.za> Message-ID: <1390821081.62.0.293477999856.issue20405@psf.upfronthosting.co.za> Nick Coghlan added the comment: Note that this is something that could (and should) start life as a module on PyPI, which would also provide cross version support. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 12:51:33 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 27 Jan 2014 11:51:33 +0000 Subject: [issue20407] heapq.nsmallest and heapq.nlargest don't accept a "key" parameter Message-ID: <1390823493.04.0.65431780694.issue20407@psf.upfronthosting.co.za> New submission from Larry Hastings: The documentation for heapq.nsmallest and heapq.nlargest: http://docs.python.org/3.3/library/heapq.html#heapq.nlargest claim that they accept three arguments: n, iterable, and key=None. In fact, the implementations of both these functions only accept two parameters: n and iterable. I assume the right thing to do here is to remove the erroneous documentation, rather than implement this apparently-not-needed feature? ---------- components: Library (Lib) messages: 209435 nosy: larry priority: low severity: normal stage: needs patch status: open title: heapq.nsmallest and heapq.nlargest don't accept a "key" parameter type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 12:53:04 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 27 Jan 2014 11:53:04 +0000 Subject: [issue20407] heapq.nsmallest and heapq.nlargest don't accept a "key" parameter In-Reply-To: <1390823493.04.0.65431780694.issue20407@psf.upfronthosting.co.za> Message-ID: <1390823584.67.0.72216500401.issue20407@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 12:53:11 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 27 Jan 2014 11:53:11 +0000 Subject: [issue20408] memoryview() constructor documentation error Message-ID: <1390823591.54.0.904712473888.issue20408@psf.upfronthosting.co.za> New submission from Larry Hastings: The documentation for the memoryview constructor says it takes memoryview(obj). Oddly, memoryview accepts keyword arguments (for its one required value), and the name of the argument is "object", not "obj". ---------- messages: 209436 nosy: georg.brandl, larry priority: low severity: normal stage: needs patch status: open title: memoryview() constructor documentation error type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 12:54:01 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 27 Jan 2014 11:54:01 +0000 Subject: [issue18321] Multivolume support in tarfile module In-Reply-To: <1372406777.07.0.523288075904.issue18321@psf.upfronthosting.co.za> Message-ID: <1390823641.49.0.297950937593.issue18321@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Lars, would you like to take a look? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 13:29:17 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 27 Jan 2014 12:29:17 +0000 Subject: [issue20404] Delayed exception using non-text encodings with TextIOWrapper In-Reply-To: <1390798876.83.0.936873438895.issue20404@psf.upfronthosting.co.za> Message-ID: <1390825757.7.0.260021011732.issue20404@psf.upfronthosting.co.za> Nick Coghlan added the comment: Attached patch checks the requested encoding is a valid text encoding in TextIOWrapper.__init__. Two additional test changes were needed: - the one that checks handling of non-text-encodings at runtime now tweaks quopri to lie about being a text encoding when creating the stream - the one that checks the interpreter doesn't crash at shutdown needed to be adjusted to handle the fact that _pyio now also fails in that situation, but with a different error (it can't find the ascii codec because the codec machinery is mostly gone) Currently, this adds a third lookup of the encoding name to the process of creating a TextIOWrapper instance. This could be reduced to just one by changing the retrieval of the encoder and decoder to look in the retrieved codec info tuple, rather than doing the lookup by name again. ---------- components: +IO keywords: +patch nosy: +pitrou Added file: http://bugs.python.org/file33747/issue20404_check_valid_textio_codec.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 13:49:14 2014 From: report at bugs.python.org (Glenn Langford) Date: Mon, 27 Jan 2014 12:49:14 +0000 Subject: [issue20319] concurrent.futures.wait() can block forever even if Futures have completed In-Reply-To: <1390263519.32.0.357208079457.issue20319@psf.upfronthosting.co.za> Message-ID: <1390826954.23.0.745940445436.issue20319@psf.upfronthosting.co.za> Glenn Langford added the comment: Revised patch; I don't think there is a need to sort the keys when waiters are being removed since only one lock is acquired at a time. Stress tests on both wait() and as_completed() work with this approach. ---------- Added file: http://bugs.python.org/file33748/issue20319-no-sort.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 13:49:38 2014 From: report at bugs.python.org (Larry Hastings) Date: Mon, 27 Jan 2014 12:49:38 +0000 Subject: [issue19145] Inconsistent behaviour in itertools.repeat when using negative times In-Reply-To: <1380727396.47.0.412229295257.issue19145@psf.upfronthosting.co.za> Message-ID: <1390826978.15.0.964476952273.issue19145@psf.upfronthosting.co.za> Larry Hastings added the comment: For what it's worth: I figured out how this happened. Maybe it's obvious to you, but this behavior baffled me until I went back and looked at the revision history. In revision e260d6daf784, the argument parsing for itertools.repeat looks like this: Py_ssize_t cnt = -1; if (type == &repeat_type && !_PyArg_NoKeywords("repeat()", kwds)) return NULL; if (!PyArg_ParseTuple(args, "O|n:repeat", &element, &cnt)) return NULL; if (PyTuple_Size(args) == 2 && cnt < 0) cnt = 0; In the subsequent revision, 3dbdbc5e6d85, it was changed to this: Py_ssize_t cnt = -1; if (!PyArg_ParseTupleAndKeywords(args, kwds, "O|n:repeat", kwargs, &element, &cnt)) return NULL; if (PyTuple_Size(args) == 2 && cnt < 0) cnt = 0; The original intent is now clear: only allow "cnt" to be -1 if it wasn't specified as an argument. The author simply forgot that "times" could now be passed in as a keyword argument too. What the author *probably* wanted was something like this: PyObject *times_keyword; ... times_keyword = PyDict_GetItemString(kwargs, "times"); Py_XDECREF(times_keyword); if ((PyTuple_Size(args) == 2 || times_keyword) && cnt < 0) cnt = 0; But I suggest it's far too late to change it to that now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 14:37:25 2014 From: report at bugs.python.org (Brett Cannon) Date: Mon, 27 Jan 2014 13:37:25 +0000 Subject: [issue20348] Argument Clinic HOWTO listed multiple times in HOWTO index In-Reply-To: <1390408747.92.0.288062862329.issue20348@psf.upfronthosting.co.za> Message-ID: <1390829845.99.0.765407696745.issue20348@psf.upfronthosting.co.za> Brett Cannon added the comment: Technically you should only have one title at the very top of the heading hierarchy. That's why the patch changed the title to use top+bottom asterisks. You could have just as easily used equal signs as reST doesn't care, just that you are consistent. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 14:38:40 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 27 Jan 2014 13:38:40 +0000 Subject: [issue20407] heapq.nsmallest and heapq.nlargest don't accept a "key" parameter In-Reply-To: <1390823493.04.0.65431780694.issue20407@psf.upfronthosting.co.za> Message-ID: <1390829920.31.0.637281668687.issue20407@psf.upfronthosting.co.za> Georg Brandl added the comment: Yes. Probably someone wished they would implement it :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 14:39:12 2014 From: report at bugs.python.org (lothar) Date: Mon, 27 Jan 2014 13:39:12 +0000 Subject: [issue20398] stem crashes python In-Reply-To: <1390749180.01.0.603192717521.issue20398@psf.upfronthosting.co.za> Message-ID: <1390829952.43.0.366190634875.issue20398@psf.upfronthosting.co.za> lothar added the comment: i have the current cygwin python3 package: http://mirrors.kernel.org/sourceware/cygwin/x86_64/release/python3/ i have no intention to build python myself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 14:41:16 2014 From: report at bugs.python.org (Brett Cannon) Date: Mon, 27 Jan 2014 13:41:16 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <1390830076.95.0.226822006403.issue19081@psf.upfronthosting.co.za> Brett Cannon added the comment: Just to answer Nick's question: I read the extension import code just last month to see if I could update it for PEP 451 fast enough (obviously the answer was no =). As for zipimport, I read that (and the extension import code yet again) in the 3.3 timeframe (and did not find the experience pleasant), so I don't know if that's too far in the past for you. =) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 14:42:52 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 27 Jan 2014 13:42:52 +0000 Subject: [issue20398] stem crashes python In-Reply-To: <1390749180.01.0.603192717521.issue20398@psf.upfronthosting.co.za> Message-ID: <1390830172.97.0.766549267307.issue20398@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Can you try with a standard Windows build? http://python.org/download/releases/3.3.3/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 14:45:46 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 27 Jan 2014 13:45:46 +0000 Subject: [issue20398] stem crashes python In-Reply-To: <1390749180.01.0.603192717521.issue20398@psf.upfronthosting.co.za> Message-ID: <1390830346.64.0.259437009895.issue20398@psf.upfronthosting.co.za> Antoine Pitrou added the comment: (note that stem.util.system at least uses ctypes) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 16:09:50 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 27 Jan 2014 15:09:50 +0000 Subject: [issue20407] heapq.nsmallest and heapq.nlargest don't accept a "key" parameter In-Reply-To: <1390823493.04.0.65431780694.issue20407@psf.upfronthosting.co.za> Message-ID: <1390835390.68.0.102570831271.issue20407@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The docs are correct as-is. This is a documented and tested behavior. >>> from heapq import nsmallest >>> list(nsmallest(3, ['larry', 'georg', 'raymond', 'guido', 'tim'], key=len)) ['tim', 'larry', 'georg'] The C implementation doesn't have a key-argument. That behavior gets added downstream in pure python in Lib/heapq.py which wraps the C-function and adds the additional behavior. ---------- assignee: -> rhettinger nosy: +rhettinger priority: low -> normal resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 16:12:38 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 27 Jan 2014 15:12:38 +0000 Subject: [issue20407] heapq.nsmallest and heapq.nlargest don't accept a "key" parameter In-Reply-To: <1390823493.04.0.65431780694.issue20407@psf.upfronthosting.co.za> Message-ID: <1390835558.83.0.233356601607.issue20407@psf.upfronthosting.co.za> Georg Brandl added the comment: I see, there are two "def nsmallest" in heapq.py. Tricky! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 16:46:56 2014 From: report at bugs.python.org (Stefan Krah) Date: Mon, 27 Jan 2014 15:46:56 +0000 Subject: [issue20399] Comparison of memoryview In-Reply-To: <1390785981.08.0.40149387217.issue20399@psf.upfronthosting.co.za> Message-ID: <20140127154655.GA21806@sleipnir.bytereef.org> Stefan Krah added the comment: For integer sequences I think non-equality comparisons will be somewhat confusing. Are the sequences little or big endian? If we start to view bytes more like latin-1 again (PEP 461), it would make sense for the 'B' and 'c' formats. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 17:49:15 2014 From: report at bugs.python.org (Tal Einat) Date: Mon, 27 Jan 2014 16:49:15 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za> Message-ID: <1390841355.06.0.855043016377.issue20180@psf.upfronthosting.co.za> Tal Einat added the comment: Attached is a complete AC conversion of itertools. This is a large conversion, so I was extra careful. I even went over the entire diff manually to check for any errors. Compilation runs without warnings and the entire test suite passes. Notes: * I didn't convert itertools.repeat due to the ongoing discussion regarding it. * I didn't convert itertools.islice since its signature is like range() but with an additional first required argument, making it impossible to convert properly. * I didn't convert several __new__ methods because they treat *args similarly to zip(): itertools.chain, itertools.product, itertools.zip_longest * I used Larry's "nullable ints" patch (see issue20341) for the 'r' parameter to itertools.permutations. * I converted all of the following methods when defined: __new__ (except for classes mentioned above), __sizeof__, __reduce__, __setstate__, __copy__, __length_hint__ ---------- Added file: http://bugs.python.org/file33749/taleinat.ac_conversion.itertools.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 17:51:29 2014 From: report at bugs.python.org (Tal Einat) Date: Mon, 27 Jan 2014 16:51:29 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za> Message-ID: <1390841489.51.0.203348987881.issue20180@psf.upfronthosting.co.za> Tal Einat added the comment: And at that, I've finished the conversion of this entire Derby group! Woohoo! (except for itertools.repeat which is pending discussion) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 18:11:38 2014 From: report at bugs.python.org (Xiaoqing Rong) Date: Mon, 27 Jan 2014 17:11:38 +0000 Subject: [issue20409] .readline() returned garble text Message-ID: <1390842698.27.0.934297855762.issue20409@psf.upfronthosting.co.za> New submission from Xiaoqing Rong: I'm using Windows 8. I created file 'weird1.txt' (attached) from an Excel worksheet using "save as Unicode Text (*.txt)". And this happened when I used Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:19:30) [MSC v.1600 64 bit (AMD64)] on win32: >>> handle = open('weird1.txt'); handle.readline() '??>\x00P\x006\x004\x00;\x00Y\x00A\x00L\x000\x000\x001\x00C\x00;\x00T\x00F\x00C\x003\x00;\x00 \x00S\x00G\x00D\x00I\x00D\x00:\x00S\x000\x000\x000\x000\x000\x000\x000\x000\x001\x00,\x00 \x00C\x00h\x00r\x00 \x00I\x00 \x00f\x00r\x00o\x00m\x00 \x001\x005\x001\x000\x000\x006\x00-\x001\x004\x007\x005\x009\x004\x00,\x001\x005\x001\x001\x006\x006\x00-\x001\x005\x001\x000\x009\x007\x00,\x00 \x00r\x00e\x00v\x00e\x00r\x00s\x00e\x00 \x00c\x00o\x00m\x00p\x00l\x00e\x00m\x00e\x00n\x00t\x00,\x00 \x00V\x00e\x00r\x00i\x00f\x00i\x00e\x00d\x00 \x00O\x00R\x00F\x00,\x00 \x00"\x00L\x00a\x00r\x00g\x00e\x00s\x00t\x00 \x00o\x00f\x00 \x00s\x00i\x00x\x00 \x00s\x00u\x00b\x00u\x00n\x00i\x00t\x00s\x00 \x00o\x00f\x00 \x00t\x00h\x00e\x00 \x00R\x00N\x00A\x00 \x00p\x00o\x00l\x00y\x00m\x00e\x00r\x00a\x00s\x00e\x00 \x00I\x00I\x00I\x00 \x00t\x00r\x00a\x00n\x00s\x00c\x00r\x00i\x00p\x00t\x00i\x00o\x00n\x00 \x00i\x00n\x00i\x00t\x00i\x00a\x00t\x00i\x00o\x00n\x00 \x00f\x00a\x00c\x00t\x00o\x00r\x00 \x00c\x00o\x00m\x00p\x00l\x00e\x00x\x00 \x00(\x00T\x00F\x00I\x00I\x00I\x00C\x00)\x00;\x00 \x00p\x00a\x00r\x00t\x00 \x00o\x00f\x00 \x00t\x00h\x00e\x00 \x00T\x00a\x00u\x00B\x00 \x00d\x00o\x00m\x00a\x00i\x00n\x00 \x00o\x00f\x00 \x00T\x00F\x00I\x00I\x00I\x00C\x00 \x00t\x00h\x00a\x00t\x00 \x00b\x00i\x00n\x00d\x00s\x00 \x00D\x00N\x00A\x00 \x00a\x00t\x00 \x00t\x00h\x00e\x00 \x00B\x00o\x00x\x00B\x00 \x00p\x00r\x00o\x00m\x00o\x00t\x00e\x00r\x00 \x00s\x00i\x00t\x00e\x00s\x00 \x00o\x00f\x00 \x00t\x00R\x00N\x00A\x00 \x00a\x00n\x00d\x00 \x00s\x00i\x00m\x00i\x00l\x00a\x00r\x00 \x00g\x00e\x00n\x00e\x00s\x00;\x00 \x00c\x00o\x00o\x00p\x00e\x00\n' Then I opened 'weird1.txt' in Notepad++ 6.5.2, created file 'weird2.txt' by copying the whole content of 'weird1.txt' into a new file and saved it in Notepad++ 6.5.2 (I wanted to attach 'weird2.txt' but only one attachment is allowed), and this happened: >>> handle = open('weird2.txt'); handle.readline() '>P64;YAL001C;TFC3; SGDID:S000000001, Chr I from 151006-147594,151166-151097, reverse complement, Verified ORF, "Largest of six subunits of the RNA polymerase III transcription initiation factor complex (TFIIIC); part of the TauB domain of TFIIIC that binds DNA at the BoxB promoter sites of tRNA and similar genes; coope\n' I can't see any difference between the contents of 'weird1.txt' and 'weird2.txt' using Notepad++ or the Windows Notepad. Maybe some experts could tell me what's going on here? ---------- components: IDLE files: weird1.txt messages: 209452 nosy: m123orning priority: normal severity: normal status: open title: .readline() returned garble text type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file33750/weird1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 18:27:02 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 27 Jan 2014 17:27:02 +0000 Subject: [issue20409] .readline() returned garble text In-Reply-To: <1390842698.27.0.934297855762.issue20409@psf.upfronthosting.co.za> Message-ID: <1390843622.9.0.404935420646.issue20409@psf.upfronthosting.co.za> R. David Murray added the comment: The file use different encodings. In the first case, the first two bytes (which don't appear in the second example) I believe are the BOM. I'm not an expert, but I believe it is a utf-16 file (thus all the \x00 bytes). The second file is presumably utf-8, with no BOM. Notepad++ handles both automatically. For Python, you have to tell it to look for the BOM by specifying the appropriate codec in the open call. This is because Python's philosophy is to not guess at the encoding of files (though it does have a default encoding, usually utf-8). Questions like this are better directed to the python-list mailing list, by the way. ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 18:49:41 2014 From: report at bugs.python.org (Glenn Langford) Date: Mon, 27 Jan 2014 17:49:41 +0000 Subject: [issue20369] concurrent.futures.wait() blocks forever when given duplicate Futures In-Reply-To: <1390491231.67.0.503348563079.issue20369@psf.upfronthosting.co.za> Message-ID: <1390844981.86.0.372903164552.issue20369@psf.upfronthosting.co.za> Glenn Langford added the comment: Updated patch with change to Doc/library/concurrent.futures.rst. ---------- Added file: http://bugs.python.org/file33751/issue20369.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 19:10:49 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 27 Jan 2014 18:10:49 +0000 Subject: [issue20378] Implement `Signature.__repr__` In-Reply-To: <1390592929.28.0.358636885148.issue20378@psf.upfronthosting.co.za> Message-ID: <1390846249.89.0.554237458313.issue20378@psf.upfronthosting.co.za> Yury Selivanov added the comment: Ram, yes, I agree. Something like '' should work. ---------- assignee: -> yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 19:12:55 2014 From: report at bugs.python.org (Ram Rachum) Date: Mon, 27 Jan 2014 18:12:55 +0000 Subject: [issue20378] Implement `Signature.__repr__` In-Reply-To: <1390592929.28.0.358636885148.issue20378@psf.upfronthosting.co.za> Message-ID: <1390846375.0.0.812585950224.issue20378@psf.upfronthosting.co.za> Ram Rachum added the comment: If you'd like to expand this issue's scope to all the objects related to Signature, I think that'll be good. All objects need good introspection strings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 19:30:18 2014 From: report at bugs.python.org (Zachary Ware) Date: Mon, 27 Jan 2014 18:30:18 +0000 Subject: [issue20410] Argument Clinic: add 'self' return converter Message-ID: <1390847418.07.0.605398644696.issue20410@psf.upfronthosting.co.za> New submission from Zachary Ware: It would be nice to have a 'self' return converter for simple functions like winreg.HKEYType.__enter__ (which is implemented as "Py_XINCREF(self); return self;"). With the typedef and type_object specifications now required for the class directive, 'self' is passed to that function as a PyHKEYObject *, but impl is expected to return a PyObject *. In this particular instance, I can solve the problem (which is a compiler warning) with a custom self_return_converter that casts _return_value to PyObject *. I think a generic solution would be better in the long run and useful in more places, though. ---------- messages: 209457 nosy: larry, zach.ware priority: low severity: normal stage: needs patch status: open title: Argument Clinic: add 'self' return converter type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 19:35:40 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Jan 2014 18:35:40 +0000 Subject: [issue20372] inspect.getfile should raise a TypeError if C object does not have __module__ In-Reply-To: <1390508769.95.0.155655534379.issue20372@psf.upfronthosting.co.za> Message-ID: <3fCflv5vwKz7LjV@mail.python.org> Roundup Robot added the comment: New changeset 50706164c38f by Yury Selivanov in branch 'default': inspect.getfile: Don't crash on classes without '__module__' attribute #20372 http://hg.python.org/cpython/rev/50706164c38f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 19:36:03 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 27 Jan 2014 18:36:03 +0000 Subject: [issue20372] inspect.getfile should raise a TypeError if C object does not have __module__ In-Reply-To: <1390508769.95.0.155655534379.issue20372@psf.upfronthosting.co.za> Message-ID: <1390847763.82.0.350198356386.issue20372@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 19:44:34 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 27 Jan 2014 18:44:34 +0000 Subject: [issue20380] __defaults__ changed by *args In-Reply-To: <1390573979.83.0.371857256149.issue20380@psf.upfronthosting.co.za> Message-ID: <1390848274.67.0.381352722505.issue20380@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Though perhaps a note in the documentation would be helpful for future confused people. I agree. Also, __kwdefaults__ wasn't documented. Please take a look at the attached patch. ---------- keywords: +patch nosy: +yselivanov Added file: http://bugs.python.org/file33752/inspect_doc_20380_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 19:49:26 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Jan 2014 18:49:26 +0000 Subject: [issue6815] UnicodeDecodeError in os.path.expandvars In-Reply-To: <1251791477.43.0.253856390345.issue6815@psf.upfronthosting.co.za> Message-ID: <1390848566.71.0.410449724304.issue6815@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch (for 3.3+) which add support for environment variables with non-ASCII values and names in posixpath and ntpath. ---------- nosy: +serhiy.storchaka stage: test needed -> patch review versions: +Python 3.3, Python 3.4 -Python 3.1 Added file: http://bugs.python.org/file33753/expandvars_nonascii.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 20:15:32 2014 From: report at bugs.python.org (Ethan Furman) Date: Mon, 27 Jan 2014 19:15:32 +0000 Subject: [issue20386] socket.SocketType enum overwrites import of _socket.SocketType In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za> Message-ID: <1390850132.8.0.980537791023.issue20386@psf.upfronthosting.co.za> Ethan Furman added the comment: Well, so far I have tried: :class:`IntEnum` :class:`.IntEnum` :class:`~IntEnum` :class:`enum.IntEnum` :class:`.enum.IntEnum` :class:`~enum.IntEnum` :class:`~.enum.IntEnum` and probably some others I have forgotten; nothing is giving me a link to enum.IntEnum. Any ideas? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 20:16:42 2014 From: report at bugs.python.org (Ram Rachum) Date: Mon, 27 Jan 2014 19:16:42 +0000 Subject: [issue20380] __defaults__ changed by *args In-Reply-To: <1390573979.83.0.371857256149.issue20380@psf.upfronthosting.co.za> Message-ID: <1390850202.38.0.0428137827522.issue20380@psf.upfronthosting.co.za> Ram Rachum added the comment: Looks good. Ideally there would be a more details explanation and an example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 20:20:41 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 27 Jan 2014 19:20:41 +0000 Subject: [issue20386] socket.SocketType enum overwrites import of _socket.SocketType In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za> Message-ID: <1390850441.72.0.346210426245.issue20386@psf.upfronthosting.co.za> Georg Brandl added the comment: Well, IntEnum is nowhere documented as a class. IOW, .. class:: IntEnum is missing if you want these references to work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 20:23:47 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 27 Jan 2014 19:23:47 +0000 Subject: [issue20380] __defaults__ changed by *args In-Reply-To: <1390573979.83.0.371857256149.issue20380@psf.upfronthosting.co.za> Message-ID: <1390850627.86.0.759139428883.issue20380@psf.upfronthosting.co.za> Yury Selivanov added the comment: Ram, those are internal attributes. I.e. it's not recommended to use them directly, there are better instruments for that, such as 'inspect.signature'. Hence, I don't think that having an example/detailed explanation here is really necessary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 20:24:30 2014 From: report at bugs.python.org (Ram Rachum) Date: Mon, 27 Jan 2014 19:24:30 +0000 Subject: [issue20380] __defaults__ changed by *args In-Reply-To: <1390573979.83.0.371857256149.issue20380@psf.upfronthosting.co.za> Message-ID: <1390850670.27.0.342790924044.issue20380@psf.upfronthosting.co.za> Ram Rachum added the comment: I take your point and I agree. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 20:27:12 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Jan 2014 19:27:12 +0000 Subject: [issue20380] __defaults__ changed by *args In-Reply-To: <1390573979.83.0.371857256149.issue20380@psf.upfronthosting.co.za> Message-ID: <3fCgvL4kd1z7LjW@mail.python.org> Roundup Robot added the comment: New changeset fc32459495fc by Yury Selivanov in branch 'default': doc/inspect: Clarify docs for __defaults__, add docs for __kwdefaults__ #20380 http://hg.python.org/cpython/rev/fc32459495fc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 20:30:30 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Jan 2014 19:30:30 +0000 Subject: [issue6815] UnicodeDecodeError in os.path.expandvars In-Reply-To: <1251791477.43.0.253856390345.issue6815@psf.upfronthosting.co.za> Message-ID: <1390851030.09.0.48556812163.issue6815@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file33753/expandvars_nonascii.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 20:31:45 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Jan 2014 19:31:45 +0000 Subject: [issue6815] UnicodeDecodeError in os.path.expandvars In-Reply-To: <1251791477.43.0.253856390345.issue6815@psf.upfronthosting.co.za> Message-ID: <1390851105.26.0.809298972526.issue6815@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ah, posixpath can be used on Windows. Here is corrected patch. Please test it on Windows. ---------- Added file: http://bugs.python.org/file33754/expandvars_nonascii.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 20:33:11 2014 From: report at bugs.python.org (Ethan Furman) Date: Mon, 27 Jan 2014 19:33:11 +0000 Subject: [issue20386] socket.SocketType enum overwrites import of _socket.SocketType In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za> Message-ID: <1390851191.22.0.820851809651.issue20386@psf.upfronthosting.co.za> Ethan Furman added the comment: IntEnum is not a class in the socket module. How do I make a link into another rst document? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 20:34:29 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 27 Jan 2014 19:34:29 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1390851269.06.0.0394834470813.issue17481@psf.upfronthosting.co.za> Yury Selivanov added the comment: > There's a major difference between getfullargspec/getargspec and inspect.signature: getfullargspec shows you the "self" parameter for bound methods, and inspect.signature does not. Larry, yes, that's correct. The attached patch simulates this behaviour, with: if ismethod(func): func = func.__func__ I'm attaching 'getargsspec_03.patch', as the previous one (02) was a bit crippled. ---------- Added file: http://bugs.python.org/file33755/getargsspec_03.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 21:08:57 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Jan 2014 20:08:57 +0000 Subject: [issue20356] fix formatting of positional-only parameters in inspect.Signature In-Reply-To: <1390431126.48.0.863526301324.issue20356@psf.upfronthosting.co.za> Message-ID: <3fChqX0fCgz7LjN@mail.python.org> Roundup Robot added the comment: New changeset ffe1d684b41e by Yury Selivanov in branch 'default': inspect.signature: Use '/' to separate positional-only parameters from http://hg.python.org/cpython/rev/ffe1d684b41e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 21:11:23 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 27 Jan 2014 20:11:23 +0000 Subject: [issue20356] fix formatting of positional-only parameters in inspect.Signature In-Reply-To: <1390431126.48.0.863526301324.issue20356@psf.upfronthosting.co.za> Message-ID: <1390853483.16.0.674050652866.issue20356@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 21:12:12 2014 From: report at bugs.python.org (Jason R. Coombs) Date: Mon, 27 Jan 2014 20:12:12 +0000 Subject: [issue20411] IndexError in sys.__interactivehook__ with pyreadline installed Message-ID: <1390853532.56.0.555307973012.issue20411@psf.upfronthosting.co.za> New submission from Jason R. Coombs: Following the blame history, this appears to be new issue following issue5845. I'm using Python 3.4b2 64-bit on Windows. I've installed pyreadline 2.0 using Setuptools 2.1. Now, when I start the interactive interpreter, I get this output: > python Python 3.4.0b2 (v3.4.0b2:ba32913eb13e, Jan 5 2014, 16:13:26) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. Failed calling sys.__interactivehook__ Traceback (most recent call last): File "c:\python\lib\site.py", line 412, in register_readline if readline.get_history_item(1) is None: File "c:\python\lib\site-packages\pyreadline-2.0-py3.4-win-amd64.egg\pyreadline\rlmain.py", line 154, in get_history_item File "c:\python\lib\site-packages\pyreadline-2.0-py3.4-win-amd64.egg\pyreadline\lineeditor\history.py", line 52, in get_history_item IndexError: list index out of range It seems I don't yet have any history, and it seems that site.py is expecting get_history_item() to return None when no history is present, but the pyreadline 2.0 implementation does no such thing, but instead tries to index the history array directly, causing the IndexError. ---------- components: Library (Lib) messages: 209471 nosy: jason.coombs priority: normal severity: normal status: open title: IndexError in sys.__interactivehook__ with pyreadline installed versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 21:13:41 2014 From: report at bugs.python.org (Jason R. Coombs) Date: Mon, 27 Jan 2014 20:13:41 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1390853621.01.0.799968111208.issue5845@psf.upfronthosting.co.za> Jason R. Coombs added the comment: Added issue20411, revealed in 3.4b2. ---------- nosy: +jason.coombs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 21:26:36 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Jan 2014 20:26:36 +0000 Subject: [issue19456] ntpath doesn't join paths correctly when a drive is present In-Reply-To: <1383174757.86.0.861423882665.issue19456@psf.upfronthosting.co.za> Message-ID: <1390854395.99.0.444858987343.issue19456@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +brian.curtin, tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 21:28:14 2014 From: report at bugs.python.org (Georg Brandl) Date: Mon, 27 Jan 2014 20:28:14 +0000 Subject: [issue20386] socket.SocketType enum overwrites import of _socket.SocketType In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za> Message-ID: <1390854494.21.0.835741614854.issue20386@psf.upfronthosting.co.za> Georg Brandl added the comment: IntEnum is not a class in the enum module either, as far as the docs are concerned ;) Otherwise :class:`enum.IntEnum` or :class:`.IntEnum` would work, no matter the source and target documents. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 21:31:08 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 27 Jan 2014 20:31:08 +0000 Subject: [issue19456] ntpath doesn't join paths correctly when a drive is present In-Reply-To: <1383174757.86.0.861423882665.issue19456@psf.upfronthosting.co.za> Message-ID: <1390854668.6.0.910535676405.issue19456@psf.upfronthosting.co.za> R. David Murray added the comment: I think a python programmer is going to expect that join(a, b, c) == join(join(a, b), c) so the answer to Serhiy's example should be 'c:z'. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 21:33:17 2014 From: report at bugs.python.org (Brian Curtin) Date: Mon, 27 Jan 2014 20:33:17 +0000 Subject: [issue19456] ntpath doesn't join paths correctly when a drive is present In-Reply-To: <1383174757.86.0.861423882665.issue19456@psf.upfronthosting.co.za> Message-ID: <1390854797.11.0.00472416189024.issue19456@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- nosy: +zach.ware -brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 21:33:43 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 27 Jan 2014 20:33:43 +0000 Subject: [issue15185] Validate callbacks in 'contextlib.ExitStack.callback()' In-Reply-To: <1340663500.78.0.8609663108.issue15185@psf.upfronthosting.co.za> Message-ID: <1390854823.79.0.207284018537.issue15185@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 21:34:56 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 27 Jan 2014 20:34:56 +0000 Subject: [issue16490] "inspect.getargspec()" and "inspect.getcallargs()" don't work for builtins In-Reply-To: <1353123389.46.0.245856363901.issue16490@psf.upfronthosting.co.za> Message-ID: <1390854896.21.0.969879380592.issue16490@psf.upfronthosting.co.za> Yury Selivanov added the comment: Closing this issue. See #17481 for details. ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 21:37:46 2014 From: report at bugs.python.org (Ethan Furman) Date: Mon, 27 Jan 2014 20:37:46 +0000 Subject: [issue20412] Enum and IntEnum classes are not defined in the documentation Message-ID: <1390855066.21.0.631218831969.issue20412@psf.upfronthosting.co.za> New submission from Ethan Furman: While trying to update the socket documentation it was brought to my attention that Enum and IntEnum are not defined as classes as far as the docs are concerned [1]. [1] http://bugs.python.org/issue20386#msg209473 ---------- assignee: ethan.furman messages: 209476 nosy: ethan.furman priority: normal severity: normal status: open title: Enum and IntEnum classes are not defined in the documentation versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 21:41:06 2014 From: report at bugs.python.org (RalfM) Date: Mon, 27 Jan 2014 20:41:06 +0000 Subject: [issue20413] Errors in documentation of standard codec error handlers Message-ID: <1390855266.06.0.0688884977578.issue20413@psf.upfronthosting.co.za> New submission from RalfM: The standard library documentation lists the standard codec error handlers in three places: (a) 2. Build-in Functions, section open() (b) 7.2 codecs - Codec registry and base classes (c) 7.2.1 Codec Base Classes As far as I can judge these lists, (c) looks ok, but (a) and (b) contain two errors: 1. 'surrogatepass' is not mentioned. 2. 'surrogateescape' is described as: 'on decoding, replace with code points in the Unicode Private Use Area ranging from U+DC80 to U+DCFF. These private code points will ...' This is incorrect in so far as U+DC80 to U+DCFF are not private code points, but (low-)surrogate code points. This is correctly explained in (c) and in PEP383 (and, of course, in the Unicode standard, chapter 16). I suggest to correct (a) and (b) by * adding 'surrogatepass' with the description given in (c), * changing the description of 'surrogateescape' to something like: 'on decoding, replace with surrogate code points ranging from U+DC80 to U+DCFF. These surrogate code points will ...'. These errors are present in the documentation (more precisely, the .chm files) of at least - Python 3.3.3 - Python 3.3.4rc1 - Python 3.4.0b3. ---------- assignee: docs at python components: Documentation messages: 209477 nosy: RalfM, docs at python priority: normal severity: normal status: open title: Errors in documentation of standard codec error handlers type: enhancement versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 21:42:21 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 27 Jan 2014 20:42:21 +0000 Subject: [issue20411] IndexError in sys.__interactivehook__ with pyreadline installed In-Reply-To: <1390853532.56.0.555307973012.issue20411@psf.upfronthosting.co.za> Message-ID: <1390855341.74.0.483875750211.issue20411@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Sounds reasonably easy to fix. Can you write a patch? ---------- nosy: +pitrou priority: normal -> high stage: -> needs patch type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 22:03:09 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 27 Jan 2014 21:03:09 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1390830076.95.0.226822006403.issue19081@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: Heh, OK. I've managed to avoid learning the gory details of the zipimporter internals so far, and the details of Windows DLL loading is the gap on the extension module side :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 22:08:34 2014 From: report at bugs.python.org (Jason R. Coombs) Date: Mon, 27 Jan 2014 21:08:34 +0000 Subject: [issue20411] IndexError in sys.__interactivehook__ with pyreadline installed In-Reply-To: <1390853532.56.0.555307973012.issue20411@psf.upfronthosting.co.za> Message-ID: <1390856914.14.0.529562450167.issue20411@psf.upfronthosting.co.za> Jason R. Coombs added the comment: Is the proper fix to address the issue in site.py? Does this issue reveal anything else of concern about the implementation? Assuming Yes and No, then yes, I can put together a fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 22:08:35 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 27 Jan 2014 21:08:35 +0000 Subject: [issue20308] inspect.Signature doesn't support user classes without __init__ or __new__ In-Reply-To: <1390168359.82.0.306015564457.issue20308@psf.upfronthosting.co.za> Message-ID: <1390856915.18.0.352580425462.issue20308@psf.upfronthosting.co.za> Yury Selivanov added the comment: Larry, Please take a look at the attached 'signature_plain_cls_04.patch'. This one supports classes (returns signature of 'object' builtin), and metaclasses (returns signature of 'type' builtin). ---------- Added file: http://bugs.python.org/file33756/signature_plain_cls_04.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 22:16:44 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Jan 2014 21:16:44 +0000 Subject: [issue19456] ntpath doesn't join paths correctly when a drive is present In-Reply-To: <1383174757.86.0.861423882665.issue19456@psf.upfronthosting.co.za> Message-ID: <3fCkKl6L8Jz7LjW@mail.python.org> Roundup Robot added the comment: New changeset 6b314f5c9404 by Serhiy Storchaka in branch '2.7': Issue #19456: ntpath.join() now joins relative paths correctly when a drive http://hg.python.org/cpython/rev/6b314f5c9404 New changeset f4377699fd47 by Serhiy Storchaka in branch '3.3': Issue #19456: ntpath.join() now joins relative paths correctly when a drive http://hg.python.org/cpython/rev/f4377699fd47 New changeset 7ce464ba615a by Serhiy Storchaka in branch 'default': Issue #19456: ntpath.join() now joins relative paths correctly when a drive http://hg.python.org/cpython/rev/7ce464ba615a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 22:17:27 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 27 Jan 2014 21:17:27 +0000 Subject: [issue20411] IndexError in sys.__interactivehook__ with pyreadline installed In-Reply-To: <1390856914.14.0.529562450167.issue20411@psf.upfronthosting.co.za> Message-ID: <1390857440.2289.4.camel@fsol> Antoine Pitrou added the comment: > Is the proper fix to address the issue in site.py? Does this issue > reveal anything else of concern about the implementation? I don't know, but it's a regression, so we'd better add a "fix" or "workaround" in site.py anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 22:21:39 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Jan 2014 21:21:39 +0000 Subject: [issue19456] ntpath doesn't join paths correctly when a drive is present In-Reply-To: <1383174757.86.0.861423882665.issue19456@psf.upfronthosting.co.za> Message-ID: <1390857699.05.0.379698456473.issue19456@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Committed first patch (with small change, ntpath.join('c:', 'C:') now returns 'C:'). There is yet one argument for first option: it is almost impossible (with current design) to implement second option in pathlib. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 23:04:22 2014 From: report at bugs.python.org (Moritz Neeb) Date: Mon, 27 Jan 2014 22:04:22 +0000 Subject: [issue20030] unittest.TestLoader.discover return value incorrectly documented. In-Reply-To: <1387530145.58.0.951879545916.issue20030@psf.upfronthosting.co.za> Message-ID: <1390860262.45.0.378295240414.issue20030@psf.upfronthosting.co.za> Changes by Moritz Neeb : ---------- nosy: +zormit _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 23:20:55 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Jan 2014 22:20:55 +0000 Subject: [issue18321] Multivolume support in tarfile module In-Reply-To: <1372406777.07.0.523288075904.issue18321@psf.upfronthosting.co.za> Message-ID: <1390861255.47.0.123433186496.issue18321@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 23:29:05 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Jan 2014 22:29:05 +0000 Subject: [issue20223] inspect.signature does not support new functools.partialmethod In-Reply-To: <1389475379.56.0.443397984378.issue20223@psf.upfronthosting.co.za> Message-ID: <3fClxD6h8Dz7LjM@mail.python.org> Roundup Robot added the comment: New changeset baedc256999a by Yury Selivanov in branch 'default': inspect.signature: Add support for 'functools.partialmethod' #20223 http://hg.python.org/cpython/rev/baedc256999a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 23:29:56 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 27 Jan 2014 22:29:56 +0000 Subject: [issue20223] inspect.signature does not support new functools.partialmethod In-Reply-To: <1389475379.56.0.443397984378.issue20223@psf.upfronthosting.co.za> Message-ID: <1390861796.39.0.0460946808714.issue20223@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks for the review, Nick. Closing the issue now. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 23:30:09 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 27 Jan 2014 22:30:09 +0000 Subject: [issue20356] fix formatting of positional-only parameters in inspect.Signature In-Reply-To: <1390431126.48.0.863526301324.issue20356@psf.upfronthosting.co.za> Message-ID: <1390861809.26.0.312836385001.issue20356@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jan 27 23:30:40 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 27 Jan 2014 22:30:40 +0000 Subject: [issue20372] inspect.getfile should raise a TypeError if C object does not have __module__ In-Reply-To: <1390508769.95.0.155655534379.issue20372@psf.upfronthosting.co.za> Message-ID: <1390861840.89.0.406042632187.issue20372@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 00:23:45 2014 From: report at bugs.python.org (Moritz Neeb) Date: Mon, 27 Jan 2014 23:23:45 +0000 Subject: [issue12296] Minor clarification in devguide In-Reply-To: <1307634327.28.0.988674687108.issue12296@psf.upfronthosting.co.za> Message-ID: <1390865025.25.0.49489882712.issue12296@psf.upfronthosting.co.za> Moritz Neeb added the comment: Tried to summarize the previous discussion and generate a compromise here. Patch attached. ---------- nosy: +zormit Added file: http://bugs.python.org/file33757/devguide-patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 01:03:49 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 28 Jan 2014 00:03:49 +0000 Subject: [issue20401] inspect.signature removes initial starred method params (bug) In-Reply-To: <1390788993.17.0.660022728639.issue20401@psf.upfronthosting.co.za> Message-ID: <1390867429.68.0.328491712178.issue20401@psf.upfronthosting.co.za> Yury Selivanov added the comment: Patch is attached, please review. Should we commit this to 3.3 too? ---------- assignee: -> yselivanov keywords: +patch nosy: +ncoghlan Added file: http://bugs.python.org/file33758/signature_method_first_arg_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 01:08:25 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 28 Jan 2014 00:08:25 +0000 Subject: [issue20308] inspect.Signature doesn't support user classes without __init__ or __new__ In-Reply-To: <1390168359.82.0.306015564457.issue20308@psf.upfronthosting.co.za> Message-ID: <1390867705.48.0.560026909029.issue20308@psf.upfronthosting.co.za> Larry Hastings added the comment: Looks perfect! Please check it in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 01:08:40 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 28 Jan 2014 00:08:40 +0000 Subject: [issue20308] inspect.Signature doesn't support user classes without __init__ or __new__ In-Reply-To: <1390168359.82.0.306015564457.issue20308@psf.upfronthosting.co.za> Message-ID: <1390867720.81.0.648509456768.issue20308@psf.upfronthosting.co.za> Larry Hastings added the comment: (With a Misc/NEWS entry of course.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 01:31:11 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 Jan 2014 00:31:11 +0000 Subject: [issue20308] inspect.Signature doesn't support user classes without __init__ or __new__ In-Reply-To: <1390168359.82.0.306015564457.issue20308@psf.upfronthosting.co.za> Message-ID: <3fCpf701Jkz7LjW@mail.python.org> Roundup Robot added the comment: New changeset b9ca2019bcb9 by Yury Selivanov in branch 'default': inspect.signature: Support classes without user-defined __init__/__new__ #20308 http://hg.python.org/cpython/rev/b9ca2019bcb9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 01:32:35 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 28 Jan 2014 00:32:35 +0000 Subject: [issue20308] inspect.Signature doesn't support user classes without __init__ or __new__ In-Reply-To: <1390168359.82.0.306015564457.issue20308@psf.upfronthosting.co.za> Message-ID: <1390869155.0.0.215402941402.issue20308@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 02:01:57 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 28 Jan 2014 01:01:57 +0000 Subject: [issue20406] Use application icon for IDLE In-Reply-To: <1390817290.68.0.153594821127.issue20406@psf.upfronthosting.co.za> Message-ID: <1390870917.5.0.107901473313.issue20406@psf.upfronthosting.co.za> Terry J. Reedy added the comment: There are two icon issues. First is the window icon at the left of the title bar of Idle windows. By the name 'wm_iconphote', I presume this is what this issue is about. Until recently, it *was* the red 'Tk' that is generally used for Tk windows. It is slightly different from idlelib/Icons/tk.gif so it must be in the tk code. For 3.4.0, since the change to tcl/tk 8.6, there are two changes. First the Tk icon is changed to a nearly vertical blue feather. Second, when displayed on the window title bar (as opposed to the Windows taskbar popup listing application windows), it is no longer displayed on the title bar directly but is placed in a square brown background with a white outline. It is atrociously ugly. The same is used for other Tk windows. (On the Windows taskbar popup window listing app windows, only the feather itself appears on the overall light blue background.) So I agree that we need to explicitly set the window title bar icon. I tried the snake (python.gif) and like it better than the feather. It appears on a black square with no outline. Unlike the feather, the same is true on the taskbar popup. Perhaps the background is created by Windows after analyzing the colors in the icon. Visually, it is not much better than the red Tk, but I definitely think we should have a consistent Idle icon. That particular snake is not the current Python logo and it is not Idle specific. Most apps (on Windows at least) use a miniture version of the app icon for the title bar icon. PC/py.ico is close to the Idle icon (see below) but is suffers when converted to py.gif (which I will attach in another message). The attached idle.gif is a cleaned up version of py.gif. It might be tweaked slightly. Or it might be redrawn from the console title bar icon, but I did not find the latter in the repository. In any case, I think we should add an idle.gif and use it in all versions. Otherwise, the patch looks good. (The other .gifs are used in TreeWidget. Idle.icns is an Apple icon collection format, though I do not know if it is actually used.) The other icon issue is the desktop and (on Windows at least) taskbar icon. Currently, when I first install Idle with the Windows installer, it uses the black console icon with Python icon in the lower right. After rebooting, it switches to a white spiral binder page with Python logo on the lower right. This seems to be specific to Idle and is appropriate as it represent the white Idle shell versus the black console. Once upon a time, Idle used this 'idle icon' when first installed, but something changed a few versions ago. There is another issue about this regression on the tracker. ---------- versions: +Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33759/idle.gif _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 02:02:51 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 28 Jan 2014 01:02:51 +0000 Subject: [issue20406] Use application icon for IDLE In-Reply-To: <1390817290.68.0.153594821127.issue20406@psf.upfronthosting.co.za> Message-ID: <1390870971.28.0.385160761563.issue20406@psf.upfronthosting.co.za> Terry J. Reedy added the comment: For comparison. ---------- Added file: http://bugs.python.org/file33760/py.gif _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 02:03:58 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Tue, 28 Jan 2014 01:03:58 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1390871038.1.0.626307634653.issue7776@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Hmm. I think I found another problem... please wait for another patch revision. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 02:31:36 2014 From: report at bugs.python.org (Thomas Kluyver) Date: Tue, 28 Jan 2014 01:31:36 +0000 Subject: [issue3158] Doctest fails to find doctests in extension modules In-Reply-To: <1214015505.39.0.384160170018.issue3158@psf.upfronthosting.co.za> Message-ID: <1390872696.86.0.520330798138.issue3158@psf.upfronthosting.co.za> Thomas Kluyver added the comment: I think there's an issue with this change - ismethoddescriptor() doesn't guarantee that that the object has an __objclass__ attribute. Unbound PyQt4 signals appear to be a case where this goes wrong. This came up testing IPython on Python 3.4 - we subclass DocTestFinder, which creates other problems, but it looks like it would run into trouble even with the base implementation. https://github.com/ipython/ipython/issues/4892 ---------- nosy: +takluyver _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 02:51:53 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Jan 2014 01:51:53 +0000 Subject: [issue20414] Python 3.4 has two Overlapped types Message-ID: <1390873913.58.0.40789965238.issue20414@psf.upfronthosting.co.za> New submission from STINNER Victor: Python 3.3 has _winapi.Overlapped. Python 3.4 _winapi.Overlapped but also _overlapped.Overlapped. Why do we have two implementations? Most code looks to be duplicated. ---------- components: Windows messages: 209496 nosy: gvanrossum, haypo, pitrou, sbt priority: normal severity: normal status: open title: Python 3.4 has two Overlapped types versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 02:54:59 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Jan 2014 01:54:59 +0000 Subject: [issue20414] Python 3.4 has two Overlapped types In-Reply-To: <1390873913.58.0.40789965238.issue20414@psf.upfronthosting.co.za> Message-ID: <1390874099.46.0.884113154325.issue20414@psf.upfronthosting.co.za> STINNER Victor added the comment: I found this issue while I was trying to understand the issue of pending operations which are not cancelled. The issue #19565 changed the behaviour in the _winapi module, but not in the _overlapped module :-( New changeset da10196b94f4 by Richard Oudkerk in branch 'default': Issue #19565: Prevent warnings at shutdown about pending overlapped ops. http://hg.python.org/cpython/rev/da10196b94f4 We know have two implementations. Which one is the best? I'm trying to understand why Python may crash on Windows with asyncio when the proactor event loop is used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 02:56:53 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Jan 2014 01:56:53 +0000 Subject: [issue20414] Python 3.4 has two Overlapped types In-Reply-To: <1390873913.58.0.40789965238.issue20414@psf.upfronthosting.co.za> Message-ID: <1390874213.92.0.273742722776.issue20414@psf.upfronthosting.co.za> STINNER Victor added the comment: _winapi is used for example by multiprocessing, whereas _overlapped is used by asyncio. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 03:22:19 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 28 Jan 2014 02:22:19 +0000 Subject: [issue15189] tkinter.messagebox does not use the application's icon In-Reply-To: <1340695188.66.0.13086714969.issue15189@psf.upfronthosting.co.za> Message-ID: <1390875739.16.0.116621348482.issue15189@psf.upfronthosting.co.za> Terry J. Reedy added the comment: After applying the .wm_iconphoto patch, I verifies that the icon specified is used for the options dialog and an ask file name message box opened by the dialog. In other words, dialogs and boxes *do* use the application title bar icon if one is provided. So I consider that existing method to be the feature requested, or at least as much of it as is sensible for tkinter. Title bar icons are 16x16. Desktop icons are much bigger. While large icons can be scaled down, the result will not necessarily be satisfactory. For instance, the Python console app has separate large and small icons. I claim on #20406 that Idle should also. In any case, automatic cross-platform access to and downscaling of a large desk icon to a small title icon should be done by tk, if at all. ---------- resolution: -> works for me stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 05:59:20 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Tue, 28 Jan 2014 04:59:20 +0000 Subject: [issue7776] http.client.HTTPConnection tunneling is broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1390885160.7.0.810831364881.issue7776@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Ok, I've attached yet another patch revision. This revision is less complex, because it gets rid of the ability to set up chains of tunnels. The only reason that I put that in was to preserve backward compatibility -- but upon reviewing the old implementation again, I found out that this actually did not work in the past either. ---------- Added file: http://bugs.python.org/file33761/issue7776_rev6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 06:30:45 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 28 Jan 2014 05:30:45 +0000 Subject: [issue19618] test_sysconfig_module fails on Ubuntu 12.04 In-Reply-To: <1384562223.55.0.434561574175.issue19618@psf.upfronthosting.co.za> Message-ID: <1390887045.0.0.838508004938.issue19618@psf.upfronthosting.co.za> Berker Peksag added the comment: The cause of the test failure was the Lib/_sysconfigdata.py file which is created by the _generate_posix_vars() function in Lib/sysconfig.py. With a fresh copy of the repo and a clean build, all tests are passed. ---------- resolution: -> out of date stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 06:43:55 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 28 Jan 2014 05:43:55 +0000 Subject: [issue20413] Errors in documentation of standard codec error handlers In-Reply-To: <1390855266.06.0.0688884977578.issue20413@psf.upfronthosting.co.za> Message-ID: <1390887835.58.0.297372145338.issue20413@psf.upfronthosting.co.za> Nick Coghlan added the comment: I plan to take a look at the codec docs in general in the next week or so, I'll tackle this as well. ---------- assignee: docs at python -> ncoghlan nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 06:48:16 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 28 Jan 2014 05:48:16 +0000 Subject: [issue19456] ntpath doesn't join paths correctly when a drive is present In-Reply-To: <1383174757.86.0.861423882665.issue19456@psf.upfronthosting.co.za> Message-ID: <1390888096.33.0.906445650479.issue19456@psf.upfronthosting.co.za> Berker Peksag added the comment: Hi Serhiy, there are commented-out lines in the 2.7 version of the patch. Are they intentionally there?: + #tester("ntpath.join('//computer/share', 'x/y')", '//computer/share\\x/y') + #tester("ntpath.join('//computer/share/', 'x/y')", '//computer/share/x/y') + #tester("ntpath.join('//computer/share/a/b', 'x/y')", '//computer/share/a/b\\x/y') + #tester("ntpath.join('//computer/share', '/x/y')", '//computer/share/x/y') + #tester("ntpath.join('//computer/share/', '/x/y')", '//computer/share/x/y') + #tester("ntpath.join('//computer/share/a', '/x/y')", '//computer/share/x/y') http://hg.python.org/cpython/rev/6b314f5c9404 ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 07:07:18 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 Jan 2014 06:07:18 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <3fCy5y1Mglz7Ljd@mail.python.org> Roundup Robot added the comment: New changeset d140e3f41796 by Gregory P. Smith in branch '2.7': Refactor the new test for issue19081 to exec import statements into a http://hg.python.org/cpython/rev/d140e3f41796 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 08:20:56 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 28 Jan 2014 07:20:56 +0000 Subject: [issue20414] Python 3.4 has two Overlapped types In-Reply-To: <1390873913.58.0.40789965238.issue20414@psf.upfronthosting.co.za> Message-ID: <1390893656.36.0.662737751332.issue20414@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I think overlapped.c should be merged back to _winapi (apparently, it started with code from _winapi). overlapped has a number of functions that aren't in _winapi, but should be (IMO). Then, the _overlapped module should be dropped. Of course, this may break code synchronization with Tulip. Guido: is it ok to proceed in this direction? ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 08:27:23 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 28 Jan 2014 07:27:23 +0000 Subject: [issue20414] Python 3.4 has two Overlapped types In-Reply-To: <1390873913.58.0.40789965238.issue20414@psf.upfronthosting.co.za> Message-ID: <1390894043.85.0.170412779731.issue20414@psf.upfronthosting.co.za> Martin v. L?wis added the comment: One sub issue then is naming: _overlapped renamed Overlapped.GetOverlappedResult to Overlapped.getresult. I think the _winapi name is better, since all other methods also use Windows API function names. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 08:44:03 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 28 Jan 2014 07:44:03 +0000 Subject: [issue17432] PyUnicode_ functions not accessible in Limited API on Windows In-Reply-To: <1363385884.71.0.776131230148.issue17432@psf.upfronthosting.co.za> Message-ID: <1390895043.19.0.103376083356.issue17432@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 09:20:33 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 28 Jan 2014 08:20:33 +0000 Subject: [issue17162] Py_LIMITED_API needs a PyType_GenericDealloc In-Reply-To: <1360348035.19.0.130949262051.issue17162@psf.upfronthosting.co.za> Message-ID: <1390897233.85.0.813379977711.issue17162@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I propose a more general solution: add a function PyType_GetSlot. ---------- keywords: +patch Added file: http://bugs.python.org/file33762/getslot.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 09:24:47 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 28 Jan 2014 08:24:47 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <1390897487.24.0.774393268344.issue19081@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Fixed in the 2.7 branch. The existing patch in the 3.3 and 3.4 branches is incomplete and does not actually fix the problem. Despite what the Misc/NEWS entry claims. The patch I am attaching now (applies to 3.3, I will forward port it to 3.4) fixes the remaining issue with zipimport failing subimports when the zip file has changed while the process is running. Marking as a release blocker as one of the following needs to happen for both 3.3 and 3.4 prior to their final release: A) The -gps05 patch needs to be applied (and forward ported to 3.4); I can do that. B) The Misc/NEWS entry claiming that this issue is fixed should simply be removed from the Misc/NEWS file and the releases should happen without this patch. After 3.4.0 and 3.3.4 I will commit this patch and re-add the Misc/NEWS entry under the 3.4.1 and 3.3.5 sections. Release managers for 3.3 and 3.4, please chime in. (+nosy'd) ---------- nosy: +georg.brandl, larry priority: normal -> release blocker versions: -Python 2.7 Added file: http://bugs.python.org/file33763/issue19081-subimport-fixes-py33-gps05.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 09:28:22 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 28 Jan 2014 08:28:22 +0000 Subject: [issue20326] Argument Clinic should use a non-error-prone syntax to mark text signatures In-Reply-To: <1390298749.1.0.12762219489.issue20326@psf.upfronthosting.co.za> Message-ID: <1390897702.29.0.511509811105.issue20326@psf.upfronthosting.co.za> Larry Hastings added the comment: Attached is a second patch. * Now includes input and output checksums. Checksums are now truncated to 16 characters each, otherwise the line is >80 columns. * Fixes the doubled-up signature lines for type object slot default signatures. I ran "gcc -E" and wrote a quick script to print out all lines with doubled-up signatures. There were only two: divmod and rdivmod. * Pretty sure this was in the first patch, but just thought I'd mention it: for functions using optional groups, we can't generate a legal signature. So Clinic kicks out the name of the function instead of "sig=", meaning that it puts back the docstring first line for human consumption! I am so clever, tee hee. ---------- keywords: +patch Added file: http://bugs.python.org/file33764/larry.sig=.marker.for.signatures.diff.2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 09:30:06 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 Jan 2014 08:30:06 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <3fD1Gf5Ywzz7LpD@mail.python.org> Roundup Robot added the comment: New changeset ca5431a434d6 by Gregory P. Smith in branch '2.7': Remove unneeded use of globals() and locals() in test on imports http://hg.python.org/cpython/rev/ca5431a434d6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 09:31:56 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 28 Jan 2014 08:31:56 +0000 Subject: [issue20264] Update patchcheck to looks for files with clinic comments In-Reply-To: <1389755559.69.0.925028805372.issue20264@psf.upfronthosting.co.za> Message-ID: <1390897916.44.0.171019269913.issue20264@psf.upfronthosting.co.za> Larry Hastings added the comment: I've attached a script here that uses the new tweaked format of Clinic blocks. The new tweaked format isn't checked in yet--that change is being tracked with #20326. Once that's checked in, though, the attached script will check that both the input and output blocks are unchanged and up-to-date, respectively. ---------- dependencies: +Argument Clinic should use a non-error-prone syntax to mark text signatures Added file: http://bugs.python.org/file33765/detect.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 09:31:57 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Jan 2014 08:31:57 +0000 Subject: [issue20414] Python 3.4 has two Overlapped types In-Reply-To: <1390873913.58.0.40789965238.issue20414@psf.upfronthosting.co.za> Message-ID: <1390897917.96.0.44504756303.issue20414@psf.upfronthosting.co.za> STINNER Victor added the comment: > One sub issue then is naming: _overlapped renamed Overlapped.GetOverlappedResult to Overlapped.getresult. I think the _winapi name is better, since all other methods also use Windows API function names. I also prefer Overlapped.GetOverlappedResult name. There are other differences. Using _overlapped, the overlapped object is created before calling an operation like WriteFile() or AcceptEx() (ex: ov.WriteFile(...)). Using _winapi, the operation may create an overlapped object if asked (ex: WriteFile(..., overlapped=True)). The structure is different. _winapi.c: --- typedef struct { PyObject_HEAD OVERLAPPED overlapped; /* For convenience, we store the file handle too */ HANDLE handle; /* Whether there's I/O in flight */ int pending; /* Whether I/O completed successfully */ int completed; /* Buffer used for reading (optional) */ PyObject *read_buffer; /* Buffer used for writing (optional) */ Py_buffer write_buffer; } OverlappedObject; --- overlapped.c: --- enum {TYPE_NONE, TYPE_NOT_STARTED, TYPE_READ, TYPE_WRITE, TYPE_ACCEPT, TYPE_CONNECT, TYPE_DISCONNECT, TYPE_CONNECT_NAMED_PIPE, TYPE_WAIT_NAMED_PIPE_AND_CONNECT}; typedef struct { PyObject_HEAD OVERLAPPED overlapped; /* For convenience, we store the file handle too */ HANDLE handle; /* Error returned by last method call */ DWORD error; /* Type of operation */ DWORD type; union { /* Buffer used for reading (optional) */ PyObject *read_buffer; /* Buffer used for writing (optional) */ Py_buffer write_buffer; }; } OverlappedObject; --- And the object in overlapped.c has much more methods. _winapi.c: --- static PyMethodDef overlapped_methods[] = { {"GetOverlappedResult", (PyCFunction) overlapped_GetOverlappedResult, METH_O, NULL}, {"getbuffer", (PyCFunction) overlapped_getbuffer, METH_NOARGS, NULL}, {"cancel", (PyCFunction) overlapped_cancel, METH_NOARGS, NULL}, {NULL} }; --- overlapped.c: --- static PyMethodDef Overlapped_methods[] = { {"getresult", (PyCFunction) Overlapped_getresult, METH_VARARGS, Overlapped_getresult_doc}, {"cancel", (PyCFunction) Overlapped_cancel, METH_NOARGS, Overlapped_cancel_doc}, {"ReadFile", (PyCFunction) Overlapped_ReadFile, METH_VARARGS, Overlapped_ReadFile_doc}, {"WSARecv", (PyCFunction) Overlapped_WSARecv, METH_VARARGS, Overlapped_WSARecv_doc}, {"WriteFile", (PyCFunction) Overlapped_WriteFile, METH_VARARGS, Overlapped_WriteFile_doc}, {"WSASend", (PyCFunction) Overlapped_WSASend, METH_VARARGS, Overlapped_WSASend_doc}, {"AcceptEx", (PyCFunction) Overlapped_AcceptEx, METH_VARARGS, Overlapped_AcceptEx_doc}, {"ConnectEx", (PyCFunction) Overlapped_ConnectEx, METH_VARARGS, Overlapped_ConnectEx_doc}, {"DisconnectEx", (PyCFunction) Overlapped_DisconnectEx, METH_VARARGS, Overlapped_DisconnectEx_doc}, {"ConnectNamedPipe", (PyCFunction) Overlapped_ConnectNamedPipe, METH_VARARGS, Overlapped_ConnectNamedPipe_doc}, {"WaitNamedPipeAndConnect", (PyCFunction) Overlapped_WaitNamedPipeAndConnect, METH_VARARGS, Overlapped_WaitNamedPipeAndConnect_doc}, {NULL} }; --- _winapi.c doesn't provide AcceptEx() nor Accept(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 09:39:16 2014 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 28 Jan 2014 08:39:16 +0000 Subject: [issue20414] Python 3.4 has two Overlapped types In-Reply-To: <1390894043.85.0.170412779731.issue20414@psf.upfronthosting.co.za> Message-ID: Richard Oudkerk added the comment: _overlapped is linked against the socket library whereas _winapi is not so it can be bundled in with python3.dll. I did intend to switch multiprocessing over to using _overlapped but I did not get round to it. Since this is a private module the names of methods do not matter to much. Note that getresult and GetOverlappedResult return values in different forms. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 09:39:17 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Jan 2014 08:39:17 +0000 Subject: [issue17162] Py_LIMITED_API needs a PyType_GenericDealloc In-Reply-To: <1360348035.19.0.130949262051.issue17162@psf.upfronthosting.co.za> Message-ID: <1390898357.21.0.791438460269.issue17162@psf.upfronthosting.co.za> STINNER Victor added the comment: + return *(void**)(((char*)type) + slotoffsets[slot]); New Python versions may add new slots. What do you think of returning NULL if the slot number is higher than the maximum slot? It looks like "#define Py_tp_free 74" is the highest slot number since Python 3.2. For example, Python 3.4 has a new "tp_finalize" slot, but I don't see it in typeslots.h. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 09:50:23 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Jan 2014 08:50:23 +0000 Subject: [issue20414] Python 3.4 has two Overlapped types In-Reply-To: <1390873913.58.0.40789965238.issue20414@psf.upfronthosting.co.za> Message-ID: <1390899023.73.0.487594884753.issue20414@psf.upfronthosting.co.za> STINNER Victor added the comment: > I did intend to switch multiprocessing over to using _overlapped > but I did not get round to it. Do you mean that _overlapped module is newer and should be used instead of _winapi? If multiprocssing is patched to use _overlapped, we can drop overlapped code from _winapi, should we keep functions like WriteFile() without overlapped support? (I think that we should keep these functions, it was discussed to support the native Windows API for files.) IMO such change can be done in Python 3.5, it is risky and can wait. But until that, I'm concerned by overlapped deallocator which is different in the two modules. Attached fixes _overlapped module to use the same logic than _winapi: give up on Windows XP during Python finalization if the overlapped is still pending, don't deallocate memory, exit immediatly. See issue #19565 for the rationale of this change. ---------- keywords: +patch Added file: http://bugs.python.org/file33766/overlapped_dealloc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 10:09:10 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Tue, 28 Jan 2014 09:09:10 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1390900150.74.0.826502110359.issue20185@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the updated patch for list module based on Zachary and Serhiy's reviews. ---------- Added file: http://bugs.python.org/file33767/clinic_listobject_v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 10:12:10 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Tue, 28 Jan 2014 09:12:10 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1390900330.73.0.574812656359.issue20185@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Forgot to say that, in list module, anything is convertable except __getitem__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 10:27:10 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 28 Jan 2014 09:27:10 +0000 Subject: [issue20326] Argument Clinic should use a non-error-prone syntax to mark text signatures In-Reply-To: <1390298749.1.0.12762219489.issue20326@psf.upfronthosting.co.za> Message-ID: <1390901230.09.0.0189523843684.issue20326@psf.upfronthosting.co.za> Larry Hastings added the comment: I'm surprised it made a review link. It didn't apply cleanly for me here. While merging I noticed that the imperative declension fix had snuck out of the diff somehow. So I redid that. Attached is an updated patch. Also I should mention: clinic.py currently accepts both the old and new comment format. I'll leave support for the old one in until just before the last release candidate. ---------- Added file: http://bugs.python.org/file33768/larry.sig=.marker.for.signatures.diff.3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 10:27:54 2014 From: report at bugs.python.org (Chen ZHANG) Date: Tue, 28 Jan 2014 09:27:54 +0000 Subject: [issue20415] Could method "isinstance" take a list as parameter? Message-ID: <1390901274.15.0.0556662587348.issue20415@psf.upfronthosting.co.za> New submission from Chen ZHANG: Since the usage of isinstance could be "isinstance(1, (int, float))", I'm wondering why it doesn't accept "[int, float]", if I do so, it would raise TypeError saying "arg 2 must be a type or tuple of types". What's the difference in effect between a tuple and a list here? (I know a tuple is immutable, but I think it doesn't matter when passing some other types of non-string iterables(yielding strings), am I right? ---------- components: Library (Lib) messages: 209519 nosy: Chen.ZHANG priority: normal severity: normal status: open title: Could method "isinstance" take a list as parameter? type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 10:32:00 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Tue, 28 Jan 2014 09:32:00 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1390901520.23.0.125386776296.issue20185@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the updated patch for marshal module based on Zachary's review. ---------- Added file: http://bugs.python.org/file33769/clinic_marshal_v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 10:35:21 2014 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 28 Jan 2014 09:35:21 +0000 Subject: [issue20415] Could method "isinstance" take a list as parameter? In-Reply-To: <1390901274.15.0.0556662587348.issue20415@psf.upfronthosting.co.za> Message-ID: <1390901721.72.0.698025029718.issue20415@psf.upfronthosting.co.za> Mark Dickinson added the comment: See related discussion on python-ideas here: https://mail.python.org/pipermail/python-ideas/2011-July/010610.html ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 10:36:33 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 28 Jan 2014 09:36:33 +0000 Subject: [issue20308] inspect.Signature doesn't support user classes without __init__ or __new__ In-Reply-To: <1390168359.82.0.306015564457.issue20308@psf.upfronthosting.co.za> Message-ID: <1390901793.68.0.25704478722.issue20308@psf.upfronthosting.co.za> Stefan Krah added the comment: One test fails --without-doc-strings: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%203.x/builds/6266/steps/test/logs/stdio ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 10:48:01 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 28 Jan 2014 09:48:01 +0000 Subject: [issue20338] Idle: increase max calltip width In-Reply-To: <1390344102.42.0.241411598779.issue20338@psf.upfronthosting.co.za> Message-ID: <1390902481.59.0.228426473777.issue20338@psf.upfronthosting.co.za> Stefan Krah added the comment: I think test_idle is failing on many build slaves following this commit. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 11:10:48 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Jan 2014 10:10:48 +0000 Subject: [issue20416] Marshal: special case int and float, don't use references Message-ID: <1390903848.78.0.660754858197.issue20416@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patched disables references for int and float types. ---------- files: marshal3_numbers.patch keywords: patch messages: 209524 nosy: haypo priority: normal severity: normal status: open title: Marshal: special case int and float, don't use references type: performance versions: Python 3.4 Added file: http://bugs.python.org/file33770/marshal3_numbers.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 11:14:40 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Jan 2014 10:14:40 +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: <1390904080.54.0.251964551869.issue20416@psf.upfronthosting.co.za> STINNER Victor added the comment: Use attached bench.py to compare performances. Without the patch: --- dumps v0: 389.6 ms data size v0: 45582.9 kB loads v0: 573.3 ms dumps v1: 391.4 ms data size v1: 45582.9 kB loads v1: 558.0 ms dumps v2: 166.9 ms data size v2: 41395.4 kB loads v2: 482.2 ms dumps v3: 431.2 ms data size v3: 41395.4 kB loads v3: 543.8 ms dumps v4: 361.8 ms data size v4: 37000.9 kB loads v4: 560.4 ms --- With the patch: --- dumps v0: 391.4 ms data size v0: 45582.9 kB loads v0: 578.2 ms dumps v1: 392.3 ms data size v1: 45582.9 kB loads v1: 556.8 ms dumps v2: 167.7 ms data size v2: 41395.4 kB loads v2: 484.6 ms dumps v3: 170.3 ms data size v3: 41395.4 kB loads v3: 467.0 ms dumps v4: 122.8 ms data size v4: 37000.9 kB loads v4: 468.9 ms --- dumps v3 is 60% faster, loads v3 is also 14% *faster*. dumps v4 is 66% faster, loads v4 is 16% faster. ---------- Added file: http://bugs.python.org/file33771/bench.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 11:14:45 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Jan 2014 10:14:45 +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: <1390904085.2.0.772620800777.issue20416@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 11:19:31 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Jan 2014 10:19:31 +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: <1390904371.88.0.663267591517.issue20416@psf.upfronthosting.co.za> STINNER Victor added the comment: Performance of Python 3.3.3+: --- dumps v0: 374.8 ms data size v0: 45582.9 kB loads v0: 625.3 ms dumps v1: 374.6 ms data size v1: 45582.9 kB loads v1: 605.1 ms dumps v2: 152.9 ms data size v2: 41395.4 kB loads v2: 556.5 ms --- So with the patch, the Python 3.4 default version (4) is *faster* (dump 20% faster, load 16% faster) and produces *smaller files* (10% smaller). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 11:20:21 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 28 Jan 2014 10:20:21 +0000 Subject: [issue20166] window x64 c-extensions not works on python3.4.0b2 In-Reply-To: <1389124118.85.0.0740185864803.issue20166@psf.upfronthosting.co.za> Message-ID: <1390904421.36.0.624027900188.issue20166@psf.upfronthosting.co.za> Stefan Krah added the comment: Ping. The blocker seems to have passed beta3. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 11:20:21 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Jan 2014 10:20:21 +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: <1390904421.84.0.690435944121.issue20416@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh by the way, on Python 3.4, the file size (on version 3 and 4) is unchanged with my patch. Writing a reference produces takes exactly the same size than an integer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 11:24:39 2014 From: report at bugs.python.org (Georg Brandl) Date: Tue, 28 Jan 2014 10:24:39 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <1390904679.54.0.44615931567.issue19081@psf.upfronthosting.co.za> Georg Brandl added the comment: Since this is a pretty big code churn, I'd prefer B) for 3.3.4. (3.3.5 will be soon anyway.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 11:25:57 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Tue, 28 Jan 2014 10:25:57 +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: <1390904757.42.0.54140951098.issue20416@psf.upfronthosting.co.za> Vajrasky Kok added the comment: I am doing clinic conversion for marshal module so I am adding myself to nosy list to make sure both tickets are synchronized. http://bugs.python.org/issue20185 ---------- nosy: +vajrasky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 11:36:08 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Jan 2014 10:36:08 +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: <1390905368.59.0.820876843706.issue20416@psf.upfronthosting.co.za> STINNER Victor added the comment: > I am doing clinic conversion for marshal module so I am adding myself to nosy list to make sure both tickets are synchronized. The Derby is suspended until the release of Python 3.4 final. I consider this issue as an important performance regression that should be fixed before Python 3.4 final. ---------- nosy: +larry priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 11:50:55 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 Jan 2014 10:50:55 +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: <1390906255.2.0.447144444371.issue20416@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +kristjan.jonsson, pitrou, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 11:54:50 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 Jan 2014 10:54:50 +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: <1390906490.47.0.0934760036999.issue20416@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Did you tested for numerous shared int and floats? [1000] * 1000000 and [1000.0] * 1000000? AFAIK this was important use cases for adding 3 or 4 versions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 12:34:43 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Jan 2014 11:34:43 +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: <1390908883.29.0.136463507827.issue20416@psf.upfronthosting.co.za> STINNER Victor added the comment: > Did you tested for numerous shared int and floats? [1000] * 1000000 and [1000.0] * 1000000? AFAIK this was important use cases for adding 3 or 4 versions. Here are new benchmarks on Python 3.4 with: Integers: [1000] * 1000000 Floats: [1000.0] * 1000000 Integers, without the patch: dumps v3: 62.8 ms data size v3: 4882.8 kB loads v3: 10.7 ms Integers, with the patch: dumps v3: 18.6 ms (-70%) data size v3: 4882.8 kB (same size) loads v3: 27.7 ms (+158%) Floats, without the patch: dumps v3: 62.5 ms data size v3: 4882.8 kB loads v3: 11.0 ms Floats, with the patch: dumps v3: 29.3 ms (-53%) data size v3: 8789.1 kB (+80%) loads v3: 25.5 ms (+132%) The version 3 was added by: --- changeset: 82816:01372117a5b4 user: Kristj?n Valur J?nsson date: Tue Mar 19 18:02:10 2013 -0700 files: Doc/library/marshal.rst Include/marshal.h Lib/test/test_marshal.py Misc/NEWS Python/marshal.c description: Issue #16475: Support object instancing, recursion and interned strings in marshal --- This issue tells about "sharing string constants, common tuples, even common code objects", not sharing numbers. For real data, here are interesting numbers: http://bugs.python.org/issue16475#msg176013 Integers only represent 4.8% of serialized data, and only 8.2% of these integers can be shared. (Floats represent 0.29%.) Whereas strings repsent 58% and 57% can be shared. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 12:35:30 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 28 Jan 2014 11:35:30 +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: <1390908930.9.0.249308625045.issue20416@psf.upfronthosting.co.za> Martin v. L?wis added the comment: For the record, format 3 was added through issue16475, format 4 was added through issue19219. In msg175962, Kristjan argued that there is no reason _not_ to share int objects, e.g. across multiple code objects. Now it seems that this argument is flawed: there is a reason, namely the performance impact. OTOH, I consider both use case (marshaling a large number of integers, and desiring to share ints across code objects) equally obscure: you shouldn't worry about marshal performance too much if you have loads of tiny int objects, and you shouldn't worry whether these ints get shared or not. As a compromise, we could suppress the sharing for small int objects, since they are singletons, anyway. This would allow marshal to preserve/copy the object graph, while not impacting the use case that the original poster on python-dev presented. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 12:39:26 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 28 Jan 2014 11:39:26 +0000 Subject: [issue20416] Marshal: special case int and float, don't use references In-Reply-To: <1390908883.29.0.136463507827.issue20416@psf.upfronthosting.co.za> Message-ID: <1390909163.2293.1.camel@fsol> Antoine Pitrou added the comment: > Integers, without the patch: > > dumps v3: 62.8 ms > data size v3: 4882.8 kB > loads v3: 10.7 ms > > Integers, with the patch: > > dumps v3: 18.6 ms (-70%) > data size v3: 4882.8 kB (same size) > loads v3: 27.7 ms (+158%) As I wrote on python-dev, dumps performance isn't important for the pyc use case, but loads performance is. Therefore it appears this patch goes into the wrong direction. You are also ignoring the *runtime* benefit of sharing objects: smaller memory footprint of the actual Python process. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 12:54:41 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 28 Jan 2014 11:54:41 +0000 Subject: [issue20417] ensurepip should not be installed with --without-ensurepip Message-ID: <1390910081.3.0.794745591099.issue20417@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis: ensurepip should not be installed when --without-ensurepip was passed to configure. I attach the patch. ---------- assignee: dstufft components: Installation files: ensurepip_installation.patch keywords: patch messages: 209536 nosy: Arfrever, dstufft priority: normal severity: normal stage: patch review status: open title: ensurepip should not be installed with --without-ensurepip versions: Python 3.4 Added file: http://bugs.python.org/file33772/ensurepip_installation.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 13:25:02 2014 From: report at bugs.python.org (Donald Stufft) Date: Tue, 28 Jan 2014 12:25:02 +0000 Subject: [issue20417] ensurepip should not be installed with --without-ensurepip In-Reply-To: <1390910081.3.0.794745591099.issue20417@psf.upfronthosting.co.za> Message-ID: <1390911902.62.0.690828682442.issue20417@psf.upfronthosting.co.za> Donald Stufft added the comment: I don't see any reason not to install ensurepip in this situation. That flag controls whether or not ``python -m ensurepip`` will be executed during the install, but ensurepip itself will still be installed. It is not an optional module ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 13:27:21 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 28 Jan 2014 12:27:21 +0000 Subject: [issue20166] window x64 c-extensions not works on python3.4.0b2 In-Reply-To: <1389124118.85.0.0740185864803.issue20166@psf.upfronthosting.co.za> Message-ID: <1390912041.09.0.321270815682.issue20166@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I think the change should be reverted, and the original issue closed as "won't fix". Alternatively, to fix the original issue, the specific linker warning could be suppressed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 13:43:06 2014 From: report at bugs.python.org (ariel-wikimedia) Date: Tue, 28 Jan 2014 12:43:06 +0000 Subject: [issue20418] socket.getaddrinfo fails for hostname that is all digits 0-9 Message-ID: <1390912986.46.0.278419787469.issue20418@psf.upfronthosting.co.za> New submission from ariel-wikimedia: With python 2.7.5 (running on fedora 20 with all updates), socket.getaddrinfo for a hostname such as 836937931829 will fail. Docker produces these sorts of hostnames (really random hex strings, but some hex strings only contain digits 0-9). How to reproduce: Add the lines 172.17.10.53 blobber 172.17.10.54 836937931829 to /etc/hosts run the following: import socket print socket.getaddrinfo('172.17.10.53',80,socket.AF_INET,0,socket.SOL_TCP) print socket.getaddrinfo('blobber',80,socket.AF_INET,0,socket.SOL_TCP) print socket.getaddrinfo('172.17.10.54',80,socket.AF_INET,0,socket.SOL_TCP) print socket.getaddrinfo('836937931829',80,socket.AF_INET,0,socket.SOL_TCP) Expected output: [(2, 1, 6, '', ('172.17.10.53', 80))] [(2, 1, 6, '', ('172.17.10.53', 80))] [(2, 1, 6, '', ('172.17.10.54', 80))] [(2, 1, 6, '', ('172.17.10.54', 80))] Actual output: [(2, 1, 6, '', ('172.17.10.53', 80))] [(2, 1, 6, '', ('172.17.10.53', 80))] [(2, 1, 6, '', ('172.17.10.54', 80))] Traceback (most recent call last): File "./test-getaddrinfo.py", line 6, in print socket.getaddrinfo('836937931829',80,socket.AF_INET,0,socket.SOL_TCP) socket.gaierror: [Errno -2] Name or service not known ---------- components: Library (Lib) messages: 209539 nosy: ariel-wikimedia priority: normal severity: normal status: open title: socket.getaddrinfo fails for hostname that is all digits 0-9 type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 13:43:56 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 28 Jan 2014 12:43:56 +0000 Subject: [issue20414] Python 3.4 has two Overlapped types In-Reply-To: <1390873913.58.0.40789965238.issue20414@psf.upfronthosting.co.za> Message-ID: <1390913036.13.0.749446403388.issue20414@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It seems fine to me to link pythonXY.dll with wsock32.dll. This is a standard library in Windows NT+, so there is no need to avoid linking with it. I also now agree that any change that we may make is too big for 3.4, so I propose to defer any action on this issue to 3.5. ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 13:47:05 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 28 Jan 2014 12:47:05 +0000 Subject: [issue20326] Argument Clinic should use a non-error-prone syntax to mark text signatures In-Reply-To: <1390298749.1.0.12762219489.issue20326@psf.upfronthosting.co.za> Message-ID: <1390913225.04.0.223804423919.issue20326@psf.upfronthosting.co.za> Nick Coghlan added the comment: Looks good to me :) I also like the fact it simplifies the internal APIs by making it really trivial to detect the presence of a clinic signature from C. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 14:00:28 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 Jan 2014 13:00:28 +0000 Subject: [issue20326] Argument Clinic should use a non-error-prone syntax to mark text signatures In-Reply-To: <1390298749.1.0.12762219489.issue20326@psf.upfronthosting.co.za> Message-ID: <3fD7Gg6yy9z7LjM@mail.python.org> Roundup Robot added the comment: New changeset d6311829da15 by Larry Hastings in branch 'default': Issue #20326: Argument Clinic now uses a simple, unique signature to http://hg.python.org/cpython/rev/d6311829da15 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 14:01:02 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 28 Jan 2014 13:01:02 +0000 Subject: [issue20326] Argument Clinic should use a non-error-prone syntax to mark text signatures In-Reply-To: <1390298749.1.0.12762219489.issue20326@psf.upfronthosting.co.za> Message-ID: <1390914062.71.0.792415632255.issue20326@psf.upfronthosting.co.za> Larry Hastings added the comment: Yeah. I did a pretty terrible job of articulating why the "(" signature was a bad idea in the first place ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 14:01:14 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 28 Jan 2014 13:01:14 +0000 Subject: [issue20326] Argument Clinic should use a non-error-prone syntax to mark text signatures In-Reply-To: <1390298749.1.0.12762219489.issue20326@psf.upfronthosting.co.za> Message-ID: <1390914074.81.0.549722521381.issue20326@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 14:08:02 2014 From: report at bugs.python.org (Alexandre Dias) Date: Tue, 28 Jan 2014 13:08:02 +0000 Subject: [issue18795] pstats - allow stats sorting by cumulative time per call and total time per call In-Reply-To: <1377042491.98.0.765142916486.issue18795@psf.upfronthosting.co.za> Message-ID: <1390914482.55.0.22243886821.issue18795@psf.upfronthosting.co.za> Alexandre Dias added the comment: Could I get an update on this please? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 14:09:00 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 28 Jan 2014 13:09:00 +0000 Subject: [issue20338] Idle: increase max calltip width In-Reply-To: <1390902481.59.0.228426473777.issue20338@psf.upfronthosting.co.za> Message-ID: <52E7ABD7.4060402@udel.edu> Terry J. Reedy added the comment: On 1/28/2014 4:48 AM, Stefan Krah wrote: > > Stefan Krah added the comment: > > I think test_idle is failing on many build slaves following this > commit. The two failures I saw on the first 4 3.x bots with Idle failures are the result of changes in the list docstrings. I presume these are related to use of Argument Clinic. I knew and documented that such failure was a possibility. On my Win 7 machine Jan 20, 32-bit repository build just before I added the tests that now fail. >>> list.__doc__ "list() -> new empty list\nlist(iterable) -> new list initialized from iterable's items" >>> list.__init__.__doc__ 'x.__init__(...) initializes x; see help(type(x)) for signature' Jan 26, 64-bit installed 3.4.0b3: >>> list.__doc__ "list(iterable) -> new list initialized from iterable's items" >>> list.__init__.__doc__ 'Initializes self. See help(type(self)) for accurate signature.' At some point, I will switch to using inspect.signature for Idle calltips and simplify the Idle code. I will also simplify the tests and make them more robust. I will re-compile and adjust the tests by the end of the day. Terry ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 15:05:39 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 Jan 2014 14:05:39 +0000 Subject: [issue9709] test_distutils warning: initfunc exported twice on Windows In-Reply-To: <1283101838.76.0.73949668593.issue9709@psf.upfronthosting.co.za> Message-ID: <3fD8jq1X61z7LjM@mail.python.org> Roundup Robot added the comment: New changeset 69827c2ab9d0 by Stefan Krah in branch 'default': Issue #9709: Revert 97fb852c5c26. Many extensions are not using PyMODINIT_FUNC. http://hg.python.org/cpython/rev/69827c2ab9d0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 15:09:25 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 28 Jan 2014 14:09:25 +0000 Subject: [issue9709] test_distutils warning: initfunc exported twice on Windows In-Reply-To: <1283101838.76.0.73949668593.issue9709@psf.upfronthosting.co.za> Message-ID: <1390918165.92.0.321289474523.issue9709@psf.upfronthosting.co.za> Stefan Krah added the comment: Too many extensions are not using PyMODINIT_FUNC (See #20166). Closing as WONT_FIX. ---------- resolution: fixed -> wont fix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 15:11:47 2014 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Tue, 28 Jan 2014 14:11:47 +0000 Subject: [issue20411] IndexError in sys.__interactivehook__ with pyreadline installed In-Reply-To: <1390853532.56.0.555307973012.issue20411@psf.upfronthosting.co.za> Message-ID: <1390918307.1.0.291197306257.issue20411@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 15:12:32 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Tue, 28 Jan 2014 14:12:32 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1390918352.04.0.988073213764.issue20185@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the updated patch for float object based on Zachary and Serhiy's reviews. Some methods that can not be converted are: __getnewargs__, __round__, float_new. So these files are ready for Python 3.4: resource, typeobject, listobject, and floatobject. These files are not ready yet: gc, longobject. ---------- Added file: http://bugs.python.org/file33773/clinic_floatobject_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 15:13:20 2014 From: report at bugs.python.org (Stefan Krah) Date: Tue, 28 Jan 2014 14:13:20 +0000 Subject: [issue20166] window x64 c-extensions not works on python3.4.0b2 In-Reply-To: <1389124118.85.0.0740185864803.issue20166@psf.upfronthosting.co.za> Message-ID: <1390918400.99.0.832013701171.issue20166@psf.upfronthosting.co.za> Stefan Krah added the comment: Thanks, that seems to be the best course of action. Fixed in 69827c2ab9d0. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed superseder: -> test_distutils warning: initfunc exported twice on Windows type: -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 15:18:12 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 Jan 2014 14:18:12 +0000 Subject: [issue20411] IndexError in sys.__interactivehook__ with pyreadline installed In-Reply-To: <1390853532.56.0.555307973012.issue20411@psf.upfronthosting.co.za> Message-ID: <3fD90M15qCz7Ljh@mail.python.org> Roundup Robot added the comment: New changeset ca6efeedfc0e by Jason R. Coombs in branch 'default': Issue #20411: Use readline.get_current_history_length to check for the presence of a history, rather than get_history_item, which assumes a history is present. http://hg.python.org/cpython/rev/ca6efeedfc0e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 15:19:58 2014 From: report at bugs.python.org (Jason R. Coombs) Date: Tue, 28 Jan 2014 14:19:58 +0000 Subject: [issue20411] IndexError in sys.__interactivehook__ with pyreadline installed In-Reply-To: <1390853532.56.0.555307973012.issue20411@psf.upfronthosting.co.za> Message-ID: <1390918798.54.0.279382885172.issue20411@psf.upfronthosting.co.za> Jason R. Coombs added the comment: After further consideration and investigation, I believe the fix is to simply use the API as exposed by pyreadline to check the length of the history to detect the presence of an existing history. I've tested that fix locally and it seems to be working suitably. Please review and suggest corrections as appropriate. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 15:55:14 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 28 Jan 2014 14:55:14 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1390920914.65.0.0289526038042.issue20172@psf.upfronthosting.co.za> Changes by Zachary Ware : Added file: http://bugs.python.org/file33774/bda6dc12a123.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 16:04:38 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 28 Jan 2014 15:04:38 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1390921478.23.0.955145467935.issue20172@psf.upfronthosting.co.za> Changes by Zachary Ware : Removed file: http://bugs.python.org/file33774/conglomerate.v6-post-20326.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 16:04:55 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 28 Jan 2014 15:04:55 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1390921495.4.0.408287668066.issue20172@psf.upfronthosting.co.za> Changes by Zachary Ware : Added file: http://bugs.python.org/file33775/41ad3c4fc03c.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 16:12:16 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 28 Jan 2014 15:12:16 +0000 Subject: [issue20414] Python 3.4 has two Overlapped types In-Reply-To: <1390873913.58.0.40789965238.issue20414@psf.upfronthosting.co.za> Message-ID: <1390921936.74.0.0201131768295.issue20414@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 16:14:25 2014 From: report at bugs.python.org (SSmith) Date: Tue, 28 Jan 2014 15:14:25 +0000 Subject: [issue18846] python.exe stdout stderr issues again In-Reply-To: <1377567265.93.0.22027447734.issue18846@psf.upfronthosting.co.za> Message-ID: <1390922065.68.0.0440070134832.issue18846@psf.upfronthosting.co.za> SSmith added the comment: Please pay some attention to this. This ISSUE is still valid in 3.4b4! Issue #18338 resolves only part of the problem. Look at this part of the OP: invoking python.exe prints its default output to stderr: [ in]>python 1> null [out]>Python 3.4.0a1 (v3.4.0a1:46535f65e7f3, Aug 3 2013, 22:59:31) [MSC v.1600 32 bit (Intel)] on win32 [out]>Type "help", "copyright", "credits" or "license" for more information. [out]>>> [ in]>python 2> null [out]>>> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 16:19:38 2014 From: report at bugs.python.org (SSmith) Date: Tue, 28 Jan 2014 15:19:38 +0000 Subject: [issue18846] python.exe stdout stderr issues again In-Reply-To: <1377567265.93.0.22027447734.issue18846@psf.upfronthosting.co.za> Message-ID: <1390922378.62.0.375497410134.issue18846@psf.upfronthosting.co.za> SSmith added the comment: r/3.4b4/3.4b3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 16:28:44 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 28 Jan 2014 15:28:44 +0000 Subject: [issue18846] python.exe stdout stderr issues again In-Reply-To: <1377567265.93.0.22027447734.issue18846@psf.upfronthosting.co.za> Message-ID: <1390922924.85.0.736325382983.issue18846@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Hmm, I'm not sure what the precedence is for that. Where do other interactive languages print their header to? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 16:36:55 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 28 Jan 2014 15:36:55 +0000 Subject: [issue3158] Doctest fails to find doctests in extension modules In-Reply-To: <1214015505.39.0.384160170018.issue3158@psf.upfronthosting.co.za> Message-ID: <1390923415.37.0.173224461019.issue3158@psf.upfronthosting.co.za> Zachary Ware added the comment: Does this patch fix things for you? ---------- resolution: fixed -> status: closed -> open Added file: http://bugs.python.org/file33776/issue3158.__objclass__-fix.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 16:39:16 2014 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 28 Jan 2014 15:39:16 +0000 Subject: [issue20414] Python 3.4 has two Overlapped types In-Reply-To: <1390873913.58.0.40789965238.issue20414@psf.upfronthosting.co.za> Message-ID: <1390923556.81.0.493248963926.issue20414@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm fine with this refactoring. The upstream tulip/asyncio repo will keep its own _overlapped for the purpose of supporting Python 3.3. (I'm not sure what Victor wants to do with Trollius but probably the same.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 16:39:26 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 28 Jan 2014 15:39:26 +0000 Subject: [issue20221] #define hypot _hypot conflicts with existing definition In-Reply-To: <1389409768.81.0.962130999427.issue20221@psf.upfronthosting.co.za> Message-ID: <1390923566.09.0.450669335798.issue20221@psf.upfronthosting.co.za> Zachary Ware added the comment: I'm having difficulty wrapping my head around why the math and cmath modules (both of which use hypot) compile fine, but your extensions don't. Anyone have any insight into why that is? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 16:45:44 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 28 Jan 2014 15:45:44 +0000 Subject: [issue20075] help(open) eats first line In-Reply-To: <1388090120.87.0.478863756961.issue20075@psf.upfronthosting.co.za> Message-ID: <1390923944.76.0.847943549767.issue20075@psf.upfronthosting.co.za> Zachary Ware added the comment: With #20326 fixed, this is no longer an issue. Gennadiy, thank you for the patch, and I'm sorry it ended up being unused. ---------- resolution: -> out of date stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 16:47:29 2014 From: report at bugs.python.org (Larry Hastings) Date: Tue, 28 Jan 2014 15:47:29 +0000 Subject: [issue20075] help(open) eats first line In-Reply-To: <1388090120.87.0.478863756961.issue20075@psf.upfronthosting.co.za> Message-ID: <1390924049.6.0.461858606777.issue20075@psf.upfronthosting.co.za> Larry Hastings added the comment: Yup, sorry about that. We're moving pretty fast with the Derby right now, and sometimes we don't figure out something important until later, and sometimes that means wasted effort. Sorry! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 17:08:29 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 28 Jan 2014 16:08:29 +0000 Subject: [issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows) In-Reply-To: <1389138308.61.0.497102640792.issue20172@psf.upfronthosting.co.za> Message-ID: <1390925309.17.0.143153515164.issue20172@psf.upfronthosting.co.za> Zachary Ware added the comment: I have high hopes for this latest update :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 17:12:43 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 28 Jan 2014 16:12:43 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1390925563.44.0.436268222147.issue20185@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 17:25:16 2014 From: report at bugs.python.org (Michael Gubser) Date: Tue, 28 Jan 2014 16:25:16 +0000 Subject: [issue20419] it's not possible to set ECDH curve name via ssl.wrap_socket Message-ID: <1390926316.58.0.114750274783.issue20419@psf.upfronthosting.co.za> New submission from Michael Gubser: One can only set the ECDH curve name via SSLContext.set_ecdh_curve(). ssl.wrap_socket() doesn't have a parameter to use it for the wrapping of the basic socket. Therefore one always has to do the detour over SSLContext. ---------- components: Library (Lib) messages: 209561 nosy: Michael.Gubser priority: normal severity: normal status: open title: it's not possible to set ECDH curve name via ssl.wrap_socket versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 17:31:43 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Jan 2014 16:31:43 +0000 Subject: [issue20414] Python 3.4 has two Overlapped types In-Reply-To: <1390873913.58.0.40789965238.issue20414@psf.upfronthosting.co.za> Message-ID: <1390926703.65.0.734809099751.issue20414@psf.upfronthosting.co.za> STINNER Victor added the comment: Can please someone review overlapped_dealloc.patch? I would like to apply it on Python 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 17:34:45 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 Jan 2014 16:34:45 +0000 Subject: [issue20420] BufferedIncrementalEncoder violates IncrementalEncoder interface Message-ID: <1390926885.67.0.351173619746.issue20420@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: The documentation of IncrementalEncoder.getstate() says: """ Return the current state of the encoder which must be an integer. The implementation should make sure that 0 is the most common state. (States that are more complicated than integers can be converted into an integer by marshaling/pickling the state and encoding the bytes of the resulting string into an integer). """ But implementation of BufferedIncrementalEncoder.getstate() is def getstate(self): return self.buffer or 0 self.buffer is "unencoded input that is kept between calls to encode()", e.g. a string. ---------- messages: 209563 nosy: doerwalter, lemburg, loewis, serhiy.storchaka priority: normal severity: normal status: open title: BufferedIncrementalEncoder violates IncrementalEncoder interface type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 17:36:54 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 28 Jan 2014 16:36:54 +0000 Subject: [issue20421] expose SSL socket protocol version Message-ID: <1390927014.41.0.169425093715.issue20421@psf.upfronthosting.co.za> New submission from Antoine Pitrou: SSL sockets should provide a way to query the current protocol version (e.g. "TLSv1.2"). OpenSSL makes it easy through SSL_get_version(). Open question is whether we return the string returned by SSL_get_version(), or we convert it to one of the constants ssl.PROTOCOL_XXX. ---------- components: Library (Lib) messages: 209564 nosy: christian.heimes, giampaolo.rodola, janssen, pitrou priority: normal severity: normal stage: needs patch status: open title: expose SSL socket protocol version type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 18:00:19 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 28 Jan 2014 17:00:19 +0000 Subject: [issue20422] Signature.from_builtin should raise a ValueError when no signature can be provided Message-ID: <1390928419.89.0.493774550745.issue20422@psf.upfronthosting.co.za> New submission from Yury Selivanov: Right now it may return `None` if no signature can be returned for the given builtin. If we decide to implement #17373 in 3.5, I'd like all three methods -- from_builtin, from_function, from_callable -- to either return a signature or to raise an exception. ---------- messages: 209565 nosy: brett.cannon, larry, ncoghlan, yselivanov priority: normal severity: normal status: open title: Signature.from_builtin should raise a ValueError when no signature can be provided type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 18:26:41 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 Jan 2014 17:26:41 +0000 Subject: [issue20401] inspect.signature removes initial starred method params (bug) In-Reply-To: <1390788993.17.0.660022728639.issue20401@psf.upfronthosting.co.za> Message-ID: <3fDF9r3fKsz7Llh@mail.python.org> Roundup Robot added the comment: New changeset 3544827d42e6 by Yury Selivanov in branch 'default': inspect.signature: Handle bound methods with '(*args)' signature correctly #20401 http://hg.python.org/cpython/rev/3544827d42e6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 18:27:33 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 28 Jan 2014 17:27:33 +0000 Subject: [issue20401] inspect.signature removes initial starred method params (bug) In-Reply-To: <1390788993.17.0.660022728639.issue20401@psf.upfronthosting.co.za> Message-ID: <1390930053.94.0.835318100941.issue20401@psf.upfronthosting.co.za> Yury Selivanov added the comment: Committed. Thank you, Terry. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 18:36:18 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 28 Jan 2014 17:36:18 +0000 Subject: [issue20418] socket.getaddrinfo fails for hostname that is all digits 0-9 In-Reply-To: <1390912986.46.0.278419787469.issue20418@psf.upfronthosting.co.za> Message-ID: <1390930578.34.0.113270690574.issue20418@psf.upfronthosting.co.za> R. David Murray added the comment: getaddrinfo is a thin wrapper around the system call. Have you tried the same thing in a C program and had it work? My guess would be that the all-numeric 'hostname' is being treated as the integer form of an IP address. I can't immediately find any documentation that addresses this for getaddrinfo, but the impression I get from googling is that turning numbers into ip addresses is not specified behavior but is what (most?) libc implementations do. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 19:02:10 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 28 Jan 2014 18:02:10 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1390932130.07.0.401607737422.issue17481@psf.upfronthosting.co.za> Yury Selivanov added the comment: Larry and Nick, Please review the final patch (getargsspec_04.patch). I'd like to commit it tomorrow. This one is the last one (hopefully), and it supports builtin methods properly -- i.e. works around 'self' parameter correctly. To do that, I check if the '__text_signature__' starts with "($", etc. ---------- assignee: -> yselivanov stage: -> patch review Added file: http://bugs.python.org/file33777/getargsspec_04.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 19:03:58 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 28 Jan 2014 18:03:58 +0000 Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za> Message-ID: <1390932238.68.0.180636681121.issue20185@psf.upfronthosting.co.za> Zachary Ware added the comment: Attaching a conglomerate patch consisting of clinic_resource_v2.patch, clinic_typeobject_v2.patch, clinic_listobject_v3.patch, clinic_marshal_v4.patch, and clinic_floatobject_v2.patch, with updated (post-#20326) clinic output, for easier review. ---------- Added file: http://bugs.python.org/file33778/issue20185_conglomerate.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 19:22:04 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 28 Jan 2014 18:22:04 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1390933324.06.0.844261767558.issue17481@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- keywords: +needs review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 19:25:47 2014 From: report at bugs.python.org (Tabrez Mohammed) Date: Tue, 28 Jan 2014 18:25:47 +0000 Subject: [issue20221] #define hypot _hypot conflicts with existing definition In-Reply-To: <1389409768.81.0.962130999427.issue20221@psf.upfronthosting.co.za> Message-ID: <1390933547.03.0.0248935044688.issue20221@psf.upfronthosting.co.za> Tabrez Mohammed added the comment: My extension doesn't compile because I treat warnings as errors. I believe Blender compiles fine, but crashes at runtime because of the infinite recursion (see the second code snippet in Brecht's response (http://bugs.python.org/msg208981). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 19:32:13 2014 From: report at bugs.python.org (Ariel Glenn) Date: Tue, 28 Jan 2014 18:32:13 +0000 Subject: [issue20418] socket.getaddrinfo fails for hostname that is all digits 0-9 In-Reply-To: <1390912986.46.0.278419787469.issue20418@psf.upfronthosting.co.za> Message-ID: <1390933933.96.0.855307368401.issue20418@psf.upfronthosting.co.za> Ariel Glenn added the comment: Yes, I had checked that just in case; getaddrinfo(3) works for the all-digit hostname, returning no error. I'm using these hints: memset(&hints, 0, sizeof(struct addrinfo)); hints.ai_family = AF_UNSPEC; hints.ai_socktype = SOCK_STREAM; hints.ai_flags = AI_PASSIVE; hints.ai_protocol = 0; hints.ai_canonname = NULL; hints.ai_addr = NULL; hints.ai_next = NULL; Tested on glibc-2.18. ---------- nosy: +ariel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 19:32:51 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 28 Jan 2014 18:32:51 +0000 Subject: [issue20221] #define hypot _hypot conflicts with existing definition In-Reply-To: <1389409768.81.0.962130999427.issue20221@psf.upfronthosting.co.za> Message-ID: <1390933971.14.0.909031622896.issue20221@psf.upfronthosting.co.za> Zachary Ware added the comment: Sorry, I wasn't entirely clear. By "compile fine", I meant "compiles without warnings, and actually works when you try to use it". Both math and cmath make use of hypot (as defined in pyconfig.h), but don't have any problems. They also have no problems with your patch applied, but I don't feel I understand the situation enough yet to move the patch forward. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 19:47:14 2014 From: report at bugs.python.org (SSmith) Date: Tue, 28 Jan 2014 18:47:14 +0000 Subject: [issue18846] python.exe stdout stderr issues again In-Reply-To: <1377567265.93.0.22027447734.issue18846@psf.upfronthosting.co.za> Message-ID: <1390934834.75.0.406331893096.issue18846@psf.upfronthosting.co.za> SSmith added the comment: Interestingly to me, you 're right! Powershell interpreter does the same. Ironically, failure to launch python from Powershell ISE(Integrated Scripting Environment) was what triggered this bug report. And as I see know, PowershellISE doesnt support launching a 'nested' powershell interpreter too. You also direct python.exe verbose output to stderr too. If I uncderstand the 'problem' correctly, it seems that having to choose from just 2 output channels leads to compromises like these. Thanks for your time and apologies for bumping this twice! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 19:51:48 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 28 Jan 2014 18:51:48 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <1390935108.48.0.99149478661.issue19081@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Thanks Georg. I'll leave it until after the 3.3.4 release. For simplicity's sake I'll leave it for 3.4.1 as well unless Larry says otherwise. ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 20:08:41 2014 From: report at bugs.python.org (Brecht Van Lommel) Date: Tue, 28 Jan 2014 19:08:41 +0000 Subject: [issue20221] #define hypot _hypot conflicts with existing definition In-Reply-To: <1389409768.81.0.962130999427.issue20221@psf.upfronthosting.co.za> Message-ID: <1390936121.64.0.902844504302.issue20221@psf.upfronthosting.co.za> Brecht Van Lommel added the comment: For Visual Studio 2013, here's how to redo the problem. Take this simple program: #include int main(int argc, char **argv) { return (int)hypot(rand(), rand()); } And compile it: cl.exe test.c -I include/python3.3 lib/python33.lib /W4 c:\program files (x86)\microsoft visual studio 12.0\vc\include\math.h(566) : warning C4717: '_hypot' : recursive on all control paths, function will cause runtime stack overflow I don't know about the conditions to get a warning in VS 2010, never tried that version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 20:24:38 2014 From: report at bugs.python.org (couplewavylines) Date: Tue, 28 Jan 2014 19:24:38 +0000 Subject: [issue20423] io.StringIO newline param has wrong default Message-ID: <1390937078.16.0.885697814935.issue20423@psf.upfronthosting.co.za> New submission from couplewavylines: In io.StringIO, the newline argument's default is currently documented as "newline=None" in the section header. However, it's described this way: "The default is to do no newline translation." The behavior of io.StringIO is consistent with this description (NO newline translation). The header should actually read "newline=''". "newline=None" would mean there IS newline translation by default, which is not the case. Code sample attached as no_translation.py. ---------- assignee: docs at python components: Documentation files: no_translation.py messages: 209577 nosy: couplewavylines, docs at python priority: normal severity: normal status: open title: io.StringIO newline param has wrong default type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33779/no_translation.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 20:26:20 2014 From: report at bugs.python.org (couplewavylines) Date: Tue, 28 Jan 2014 19:26:20 +0000 Subject: [issue20423] io.StringIO newline param has wrong default In-Reply-To: <1390937078.16.0.885697814935.issue20423@psf.upfronthosting.co.za> Message-ID: <1390937180.67.0.0738558071011.issue20423@psf.upfronthosting.co.za> Changes by couplewavylines : Added file: http://bugs.python.org/file33780/no_translation_output.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 20:32:57 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 28 Jan 2014 19:32:57 +0000 Subject: [issue20414] Python 3.4 has two Overlapped types In-Reply-To: <1390873913.58.0.40789965238.issue20414@psf.upfronthosting.co.za> Message-ID: <1390937577.28.0.222008386703.issue20414@psf.upfronthosting.co.za> Martin v. L?wis added the comment: See my review in Rietveld. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 20:37:23 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 Jan 2014 19:37:23 +0000 Subject: [issue20423] io.StringIO newline param has wrong default In-Reply-To: <1390937078.16.0.885697814935.issue20423@psf.upfronthosting.co.za> Message-ID: <1390937843.96.0.682710358648.issue20423@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: No, actual default is '\n'. >>> io.StringIO('abc\r\ndef\nghi\rklm').readlines() ['abc\r\n', 'def\n', 'ghi\rklm'] >>> io.StringIO('abc\r\ndef\nghi\rklm', newline=None).readlines() ['abc\n', 'def\n', 'ghi\n', 'klm'] >>> io.StringIO('abc\r\ndef\nghi\rklm', newline='').readlines() ['abc\r\n', 'def\n', 'ghi\r', 'klm'] >>> io.StringIO('abc\r\ndef\nghi\rklm', newline='\n').readlines() ['abc\r\n', 'def\n', 'ghi\rklm'] >>> io.StringIO('abc\r\ndef\nghi\rklm', newline='\r').readlines() ['abc\r', '\r', 'def\r', 'ghi\r', 'klm'] >>> io.StringIO('abc\r\ndef\nghi\rklm', newline='\r\n').readlines() ['abc\r\r\n', 'def\r\n', 'ghi\rklm'] ---------- keywords: +easy nosy: +serhiy.storchaka stage: -> needs patch versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 20:44:20 2014 From: report at bugs.python.org (couplewavylines) Date: Tue, 28 Jan 2014 19:44:20 +0000 Subject: [issue20423] io.StringIO newline param has wrong default In-Reply-To: <1390937078.16.0.885697814935.issue20423@psf.upfronthosting.co.za> Message-ID: <1390938260.26.0.413484710825.issue20423@psf.upfronthosting.co.za> couplewavylines added the comment: Serhiy, you're right, I now see the default behavior is "newline='\n'". So, the header is still wrong, and the text is "The default is to do no newline translation" may be incorrect too? Or just unclear (to me anyway)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 20:51:04 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 Jan 2014 19:51:04 +0000 Subject: [issue20423] io.StringIO newline param has wrong default In-Reply-To: <1390937078.16.0.885697814935.issue20423@psf.upfronthosting.co.za> Message-ID: <1390938664.94.0.197345244035.issue20423@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: On other hand, may be the behavior of io.StringIO is wrong. Because it is different from io.TextIOWrapper. >>> io.TextIOWrapper(io.BytesIO(b'abc\r\ndef\nghi\rklm')).readlines() ['abc\n', 'def\n', 'ghi\n', 'klm'] >>> io.TextIOWrapper(io.BytesIO(b'abc\r\ndef\nghi\rklm'), newline=None).readlines() ['abc\n', 'def\n', 'ghi\n', 'klm'] >>> io.TextIOWrapper(io.BytesIO(b'abc\r\ndef\nghi\rklm'), newline='').readlines() ['abc\r\n', 'def\n', 'ghi\r', 'klm'] >>> io.TextIOWrapper(io.BytesIO(b'abc\r\ndef\nghi\rklm'), newline='\n').readlines() ['abc\r\n', 'def\n', 'ghi\rklm'] >>> io.TextIOWrapper(io.BytesIO(b'abc\r\ndef\nghi\rklm'), newline='\r').readlines() ['abc\r', '\ndef\nghi\r', 'klm'] >>> io.TextIOWrapper(io.BytesIO(b'abc\r\ndef\nghi\rklm'), newline='\r\n').readlines() ['abc\r\n', 'def\nghi\rklm'] ---------- nosy: +benjamin.peterson, hynek, pitrou, stutzbach _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 21:17:07 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 28 Jan 2014 20:17:07 +0000 Subject: [issue20221] #define hypot _hypot conflicts with existing definition In-Reply-To: <1389409768.81.0.962130999427.issue20221@psf.upfronthosting.co.za> Message-ID: <1390940227.04.0.203812486611.issue20221@psf.upfronthosting.co.za> Zachary Ware added the comment: Your test program works for VS2010 as well (/W4 is unnecessary, the default warning level gives the warning), but still doesn't answer the question of why the math module (specifically math.hypot) doesn't show the problem. I understand why both of your cases *don't* work, I want to understand why mathmodule.c and cmathmodule.c (and complexobject.c, for that matter) *do* work. Attempting to compile mathmodule.c alone results in the warning, and even picking through mathmodule.i as produced by preprocessing to file, it looks like math_hypot should always have the problem. The fact that math_hypot works when compiled with the rest of Python frankly frustrates me quite a lot, because I can see no reason why it should. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 21:17:22 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 28 Jan 2014 20:17:22 +0000 Subject: [issue20221] #define hypot _hypot conflicts with existing definition In-Reply-To: <1389409768.81.0.962130999427.issue20221@psf.upfronthosting.co.za> Message-ID: <1390940242.35.0.69062413941.issue20221@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 21:26:55 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 Jan 2014 20:26:55 +0000 Subject: [issue20424] _pyio.StringIO doesn't work with lone surrogates Message-ID: <1390940815.88.0.957874925248.issue20424@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Unlike to io.StringIO, _pyio.StringIO doesn't work with lone surrogates. >>> import io, _pyio >>> io.StringIO('\ud880') <_io.StringIO object at 0xb71426ec> >>> _pyio.StringIO('\ud880') Traceback (most recent call last): File "", line 1, in File "/home/serhiy/py/cpython/Lib/_pyio.py", line 2065, in __init__ self.write(initial_value) File "/home/serhiy/py/cpython/Lib/_pyio.py", line 1629, in write b = encoder.encode(s) File "/home/serhiy/py/cpython/Lib/encodings/utf_8.py", line 20, in encode return codecs.utf_8_encode(input, self.errors)[0] UnicodeEncodeError: 'utf-8' codec can't encode character '\ud880' in position 0: surrogates not allowed Proposed patch adds support of lone surrogates to _pyio.StringIO. ---------- components: IO, Unicode files: stringio_lone_surrogates.patch keywords: patch messages: 209583 nosy: benjamin.peterson, ezio.melotti, haypo, hynek, pitrou, serhiy.storchaka, stutzbach priority: normal severity: normal stage: patch review status: open title: _pyio.StringIO doesn't work with lone surrogates type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33781/stringio_lone_surrogates.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 22:03:46 2014 From: report at bugs.python.org (Christopher Welborn) Date: Tue, 28 Jan 2014 21:03:46 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390943026.18.0.00457393100373.issue20218@psf.upfronthosting.co.za> Christopher Welborn added the comment: Using 'review' with pathlib.readwrite4.patch, it looks like it only modifies one file (test_pathlib.py), which can't be right. Maybe you edited the patch directly instead of generating a new one? (also, the line-counts haven't changed and I think they were suppose to.) The python-dev guide may help you to move forward with this, and any future ideas. I definitely have a lot to learn myself, but I do know that the less leg-work core-devs have to do, the easier it is to make a contribution. Python dev-guide: http://docs.python.org/devguide/ Here is the 'exclusive' feature with some tests, it raises TypeError when 'append' and 'exclusive' are used at the same time (mismatched args/kwargs usually raise TypeError in python from what I can tell). It's still missing the Doc changes, and probably more stuff that I don't know about yet. As usual, all tests pass including the python test-suite, and `make patchcheck` removed some whitespace for me. Thanks, -Chris (cjwelborn) ---------- Added file: http://bugs.python.org/file33782/pathlib.readwrite3_with_exclusive.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 22:04:52 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 28 Jan 2014 21:04:52 +0000 Subject: [issue20425] inspect.Signature should work on decorated builtins Message-ID: <1390943092.94.0.962174944377.issue20425@psf.upfronthosting.co.za> New submission from Yury Selivanov: inspect.signature should work with decorated builtins. Suppose I want to create a cached version of 'min' builtin: cached_min = functools.lru_cache()(min) The signature of the 'cached_min' should match the signature of 'min'. The patch is attached. ---------- assignee: yselivanov files: decorated_builtins_01.patch keywords: patch messages: 209585 nosy: brett.cannon, larry, ncoghlan, yselivanov priority: high severity: normal stage: patch review status: open title: inspect.Signature should work on decorated builtins type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file33783/decorated_builtins_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 22:05:02 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 28 Jan 2014 21:05:02 +0000 Subject: [issue20425] inspect.Signature should work on decorated builtins In-Reply-To: <1390943092.94.0.962174944377.issue20425@psf.upfronthosting.co.za> Message-ID: <1390943102.76.0.247254895189.issue20425@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- keywords: +needs review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 22:27:51 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 28 Jan 2014 21:27:51 +0000 Subject: [issue20422] Signature.from_builtin should raise a ValueError when no signature can be provided In-Reply-To: <1390928419.89.0.493774550745.issue20422@psf.upfronthosting.co.za> Message-ID: <1390944471.0.0.0640839129448.issue20422@psf.upfronthosting.co.za> Yury Selivanov added the comment: A patch is attached, please review. ---------- keywords: +needs review, patch stage: -> patch review Added file: http://bugs.python.org/file33784/from_builtin_errors_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 22:29:28 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Jan 2014 21:29:28 +0000 Subject: [issue20414] Python 3.4 has two Overlapped types In-Reply-To: <1390873913.58.0.40789965238.issue20414@psf.upfronthosting.co.za> Message-ID: <1390944568.39.0.0111890704991.issue20414@psf.upfronthosting.co.za> STINNER Victor added the comment: > See my review in Rietveld. Thanks Martin, but I cannot answer to your question. I didn't write this part of the code and I don't know it. Maybe Richard or Antoine would be able to answer? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 22:31:31 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Jan 2014 21:31:31 +0000 Subject: [issue20424] _pyio.StringIO doesn't work with lone surrogates In-Reply-To: <1390940815.88.0.957874925248.issue20424@psf.upfronthosting.co.za> Message-ID: <1390944691.31.0.528835250318.issue20424@psf.upfronthosting.co.za> STINNER Victor added the comment: I agree that StringIO should accept lone surrogates as str += str accept them. The patch looks good, but please mention the issue number in the unit test. And add an empty line between the two parts of the test (reader, writer). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 22:32:59 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 28 Jan 2014 21:32:59 +0000 Subject: [issue20379] help(instance_of_builtin_class.method) does not display self In-Reply-To: <1390572402.09.0.311482588548.issue20379@psf.upfronthosting.co.za> Message-ID: <1390944779.76.0.311911121664.issue20379@psf.upfronthosting.co.za> Yury Selivanov added the comment: FWIW, I solved the first arg consistency for inspect.getfullargspec in #17481. The latest patch always shows the first argument (self) for both python-defined and C-defined methods. ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 22:34:16 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 28 Jan 2014 21:34:16 +0000 Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za> Message-ID: <1390944856.0.0.817799096522.issue15582@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 22:35:28 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 28 Jan 2014 21:35:28 +0000 Subject: [issue19573] Fix the docstring of inspect.Parameter and the implementation of _ParameterKind In-Reply-To: <1384371223.06.0.467962768293.issue19573@psf.upfronthosting.co.za> Message-ID: <1390944928.76.0.633419113372.issue19573@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 22:42:10 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 28 Jan 2014 21:42:10 +0000 Subject: [issue20423] io.StringIO newline param has wrong default In-Reply-To: <1390937078.16.0.885697814935.issue20423@psf.upfronthosting.co.za> Message-ID: <1390945330.1.0.552773082155.issue20423@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Using '\n' as default is normal: StringIOs are not stored on disk so there's no point in converting newlines by default (it's only slower while not improving interoperability). '\n' is the default line separator in Python. So we should just fix the docs here. The bug when using '\r' or '\r\n' should probably be fixed though (that would be a separate issue). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 22:42:18 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 28 Jan 2014 21:42:18 +0000 Subject: [issue19573] Fix the docstring of inspect.Parameter and the implementation of _ParameterKind In-Reply-To: <1384371223.06.0.467962768293.issue19573@psf.upfronthosting.co.za> Message-ID: <1390945338.81.0.11906474838.issue19573@psf.upfronthosting.co.za> Yury Selivanov added the comment: Antony, the docstrings are fixed. Could you please provide a patch just for the _ParameterKind-Enum refactoring? I'll incorporate it into 3.5 then. ---------- assignee: docs at python -> yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 22:43:59 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 28 Jan 2014 21:43:59 +0000 Subject: [issue1764286] inspect.getsource does not work with decorated functions Message-ID: <1390945439.1.0.526674547428.issue1764286@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov versions: +Python 3.5 -Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 22:45:01 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 28 Jan 2014 21:45:01 +0000 Subject: [issue19140] inspect.Signature.bind() inaccuracies In-Reply-To: <1380660606.62.0.855384003289.issue19140@psf.upfronthosting.co.za> Message-ID: <1390945501.83.0.0216133250038.issue19140@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- assignee: -> yselivanov nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 22:49:09 2014 From: report at bugs.python.org (Julian Taylor) Date: Tue, 28 Jan 2014 21:49:09 +0000 Subject: [issue3158] Doctest fails to find doctests in extension modules In-Reply-To: <1214015505.39.0.384160170018.issue3158@psf.upfronthosting.co.za> Message-ID: <1390945749.74.0.0940981488178.issue3158@psf.upfronthosting.co.za> Julian Taylor added the comment: the patch seems to work for me in ipython. ---------- nosy: +jtaylor _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 22:52:04 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 28 Jan 2014 21:52:04 +0000 Subject: [issue20418] socket.getaddrinfo fails for hostname that is all digits 0-9 In-Reply-To: <1390912986.46.0.278419787469.issue20418@psf.upfronthosting.co.za> Message-ID: <1390945924.06.0.654797720837.issue20418@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: The culprint isn't Python, but the libc: """ $ ./python -c "import socket; print(socket.getaddrinfo('836937931829', 80, socket.AF_INET, 0, socket.SOL_TCP))" Traceback (most recent call last): File "", line 1, in socket.gaierror: [Errno -2] Name or service not known """ But with AF_UNSPEC: """ $ ./python -c "import socket; print(socket.getaddrinfo('836937931829', 80, socket.AF_UNSPEC, 0, socket.SOL_TCP))" [(2, 1, 6, '', ('172.17.10.54', 80))] """ And gdb confirms that the arguments are correctly passed to the libc: """ $ gdb --args ./python -c "import socket; print(socket.getaddrinfo('836937931829', 80, socket.AF_INET, 0, socket.SOL_TCP))" Breakpoint 1, __GI_getaddrinfo (name=0xb7cc9c84 "836937931829", service=0xbffff24e "80", hints=0xbffff278, pai=0xbffff274) at ../sysdeps/posix/getaddrinfo.c:2379 (gdb) p *hints $4 = {ai_flags = 0, ai_family = 2, ai_socktype = 0, ai_protocol = 6, ai_addrlen = 0, ai_addr = 0x0, ai_canonname = 0x0, ai_next = 0x0} """ You can also check directly with getaddrinfo(3). ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 22:57:21 2014 From: report at bugs.python.org (Ram Rachum) Date: Tue, 28 Jan 2014 21:57:21 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390946241.18.0.442473305058.issue20218@psf.upfronthosting.co.za> Ram Rachum added the comment: You're right Chris, I edited the patch naively and didn't know it wouldn't work. Your patch looks great except you probably want to change "except" to "accept" :) I hope I'll have time to work on the documentation addition soon. I'm assuming we want nothing more than method documentation on `Path`, right? I mean, just a short entry for each method, nothing more right? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 22:59:07 2014 From: report at bugs.python.org (Julian Taylor) Date: Tue, 28 Jan 2014 21:59:07 +0000 Subject: [issue20389] clarify meaning of xbar and mu in pvariance/variance of statistics module In-Reply-To: <1390653440.27.0.247965137131.issue20389@psf.upfronthosting.co.za> Message-ID: <1390946347.4.0.491513044178.issue20389@psf.upfronthosting.co.za> Changes by Julian Taylor : ---------- components: +Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 23:09:38 2014 From: report at bugs.python.org (leewz) Date: Tue, 28 Jan 2014 22:09:38 +0000 Subject: [issue20426] Compiling a regex with re.DEBUG should force a recompile Message-ID: <1390946978.37.0.473480948512.issue20426@psf.upfronthosting.co.za> New submission from leewz: Compiling a regex with the `re.DEBUG` flag indicates that the user wants to see the debug output. `re.compile` is cached, though, so there is the possibility of no output. Example: import re re.compile('1',re.DEBUG) #expected output re.compile('1',re.DEBUG) #no output re.compile('',re.DEBUG) #no output (empty regex) The workaround is to call `re.purge()`, which may remove other cached regexes that are still in use. (Background: I wanted to check for equivalence of regexes, and a StackOverflow answer suggested comparing their `re.DEBUG`. http://stackoverflow.com/a/21398362/2963903) ---------- components: Regular Expressions messages: 209595 nosy: ezio.melotti, leewz, mrabarnett priority: normal severity: normal status: open title: Compiling a regex with re.DEBUG should force a recompile type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 23:10:49 2014 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 28 Jan 2014 22:10:49 +0000 Subject: [issue20426] Compiling a regex with re.DEBUG should force a recompile In-Reply-To: <1390946978.37.0.473480948512.issue20426@psf.upfronthosting.co.za> Message-ID: <1390947049.33.0.815893127345.issue20426@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> test needed versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 23:28:59 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 Jan 2014 22:28:59 +0000 Subject: [issue19140] inspect.Signature.bind() inaccuracies In-Reply-To: <1380660606.62.0.855384003289.issue19140@psf.upfronthosting.co.za> Message-ID: <3fDMtf413Lz7LkJ@mail.python.org> Roundup Robot added the comment: New changeset 9cb32426d580 by Yury Selivanov in branch 'default': inspect.Signature.bind: Fix pos-only params with defaults; fix *args in named args #19140 http://hg.python.org/cpython/rev/9cb32426d580 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jan 28 23:29:28 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 28 Jan 2014 22:29:28 +0000 Subject: [issue19140] inspect.Signature.bind() inaccuracies In-Reply-To: <1380660606.62.0.855384003289.issue19140@psf.upfronthosting.co.za> Message-ID: <1390948168.74.0.541237363446.issue19140@psf.upfronthosting.co.za> Yury Selivanov added the comment: Pushed in 3.4. Yann, thank you for the bug report and the patch! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 00:01:06 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 28 Jan 2014 23:01:06 +0000 Subject: [issue20427] inspect.Signature should ensure that non-default params don't follow default ones Message-ID: <1390950066.9.0.564159460442.issue20427@psf.upfronthosting.co.za> New submission from Yury Selivanov: Right now it's possible to manually create signatures like "(a=1, b)". Patch is attached. ---------- assignee: yselivanov files: sig_validation_01.patch keywords: needs review, patch messages: 209598 nosy: brett.cannon, larry, ncoghlan, yselivanov priority: normal severity: normal stage: patch review status: open title: inspect.Signature should ensure that non-default params don't follow default ones type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file33785/sig_validation_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 00:03:39 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 28 Jan 2014 23:03:39 +0000 Subject: [issue11770] inspect.dir_static In-Reply-To: <1302001735.74.0.572603626553.issue11770@psf.upfronthosting.co.za> Message-ID: <1390950219.54.0.0384452489138.issue11770@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 00:07:55 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 28 Jan 2014 23:07:55 +0000 Subject: [issue19281] add __objclass__ to the docs In-Reply-To: <1382082111.84.0.378259232568.issue19281@psf.upfronthosting.co.za> Message-ID: <1390950475.56.0.14252020816.issue19281@psf.upfronthosting.co.za> Yury Selivanov added the comment: Should we commit this in 3.4? ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 00:36:11 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 28 Jan 2014 23:36:11 +0000 Subject: [issue16808] inspect.stack() should return list of named tuples In-Reply-To: <1356750149.18.0.966123919893.issue16808@psf.upfronthosting.co.za> Message-ID: <1390952171.46.0.909206244701.issue16808@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 00:36:17 2014 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 28 Jan 2014 23:36:17 +0000 Subject: [issue16808] inspect.stack() should return list of named tuples In-Reply-To: <1356750149.18.0.966123919893.issue16808@psf.upfronthosting.co.za> Message-ID: <1390952177.75.0.332657764704.issue16808@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 00:45:30 2014 From: report at bugs.python.org (Alexandre Vassalotti) Date: Tue, 28 Jan 2014 23:45:30 +0000 Subject: [issue20428] _Py_open does not work with O_CREAT Message-ID: <1390952730.76.0.147272441759.issue20428@psf.upfronthosting.co.za> New submission from Alexandre Vassalotti: The _Py_open function in Python/fileutils.c cannot be given correctly the flag O_CREAT. According to the POSIX spec, open(2) _must_ be given an additional mode argument when O_CREAT is used. _Py_open should be fixed to either to use a reasonable default value for the mode argument (e.g., O666) or to refuse the O_CREAT flag. ---------- components: Interpreter Core messages: 209600 nosy: alexandre.vassalotti, haypo priority: normal severity: normal stage: needs patch status: open title: _Py_open does not work with O_CREAT type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 00:55:56 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 28 Jan 2014 23:55:56 +0000 Subject: [issue12187] subprocess.wait() with a timeout uses polling on POSIX In-Reply-To: <1306416741.33.0.363365904037.issue12187@psf.upfronthosting.co.za> Message-ID: <1390953356.29.0.70792679287.issue12187@psf.upfronthosting.co.za> STINNER Victor added the comment: The new asyncio module doesn't have this performance issue: it allows to wait asynchronously for the process exit without busy loop. Right now, there is no high-level API for that, but it is very likely that Python 3.4 final will provide a simple proc.wait() method for that. See #20400 and related Tulip issue: http://code.google.com/p/tulip/issues/detail?id=115 On Unix, the default implementation sets an handler for SIGCHLD signal which calls waitpid(pid, WNOHANG) on all processes to detect process exit. But it has also a faster implementation which calls waitpid(-1, WNOHANG) only once. asyncio uses signal.set_wakeup_fd() to wake up its event loop when it gets a signal. Charles-Fran?ois wrote: > Honestly, I think the extra complexity and non-portability isn't worth it. I agree. And any change may break the backward compatibility, because signal handling is tricky and many detail are platform specific. asyncio is well designed and solves this issue in a portable way. On Windows, RegisterWaitWithQueue() is used with an overlapped object and a proactor event loop to wait for the process exit. I leave the issue open until all the new subprocess code is merged into Tulip and Python asyncio. ---------- nosy: +gvanrossum versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 01:03:03 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 29 Jan 2014 00:03:03 +0000 Subject: [issue20428] _Py_open does not work with O_CREAT In-Reply-To: <1390952730.76.0.147272441759.issue20428@psf.upfronthosting.co.za> Message-ID: <1390953783.37.0.665484328657.issue20428@psf.upfronthosting.co.za> STINNER Victor added the comment: I already search the "default mode" but I didn't see it in the manual page. Is it 0666? > The _Py_open function in Python/fileutils.c cannot be given correctly the flag O_CREAT. What is the current behaviour? A new _Py_open_mode() function can be added. Where do you need O_CREAT? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 01:03:35 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 29 Jan 2014 00:03:35 +0000 Subject: [issue12187] subprocess.wait() with a timeout uses polling on POSIX In-Reply-To: <1390953356.29.0.70792679287.issue12187@psf.upfronthosting.co.za> Message-ID: <1390953813.2308.8.camel@fsol> Antoine Pitrou added the comment: > Right now, there is no high-level API for that, but it is very likely > that Python 3.4 final will provide a simple proc.wait() method for > that. We aren't supposed to merge new features in 3.4 anymore. I know Tulip uses a separate repo, but you should only merge bug fixes IMO. (if you want an exemption, you should ask Larry) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 01:13:54 2014 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 29 Jan 2014 00:13:54 +0000 Subject: [issue12187] subprocess.wait() with a timeout uses polling on POSIX In-Reply-To: <1306416741.33.0.363365904037.issue12187@psf.upfronthosting.co.za> Message-ID: <1390954434.13.0.628881410134.issue12187@psf.upfronthosting.co.za> Guido van Rossum added the comment: I am trying to be conservative in changing existing Tulip APIs, but I hope to get an exemption from Larry for the "convenience" process API that we are currently adding in Tulip issue 115 (http://code.google.com/p/tulip/issues/detail?id=115). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 01:16:11 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jan 2014 00:16:11 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1390954571.76.0.336737599094.issue12916@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 01:16:15 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jan 2014 00:16:15 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1390954575.17.0.554817574016.issue12916@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 01:18:11 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jan 2014 00:18:11 +0000 Subject: [issue19239] add inspect functions to retrieve attributes from both old dir() and overridden dir() In-Reply-To: <1381617506.87.0.926836334477.issue19239@psf.upfronthosting.co.za> Message-ID: <1390954691.32.0.947445733727.issue19239@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 01:19:01 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 29 Jan 2014 00:19:01 +0000 Subject: [issue20429] 3.3.4rc1 install deleted Windows taskbar icons Message-ID: <1390954741.59.0.823038471265.issue20429@psf.upfronthosting.co.za> New submission from Terry J. Reedy: When I installed 3.3.4rc1, it unpinned all the icons from my Win 7 taskbar. Since I have about 15, is took several minutes to recreate by setup. Unless this is a unique glitch, this should be a release blocker until fixed. This happened after the install paused because 3.3.3 was running. After I closed that, it paused for an 'application' it called '3330'. I have seen this 'name' before, but I have no idea what it refers to. With task manager, I deleted one conhost process (there were about 10, and 10 of some other process), then thought better of continuing along that line, and clicked [Retry]. All icons for closed programs immediately disappeared. When I rebooted to see if the deletion was permanent, the rest were gone. ---------- components: Installation, Windows messages: 209605 nosy: georg.brandl, loewis, terry.reedy priority: normal severity: normal stage: needs patch status: open title: 3.3.4rc1 install deleted Windows taskbar icons type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 01:27:44 2014 From: report at bugs.python.org (Christopher Welborn) Date: Wed, 29 Jan 2014 00:27:44 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390955264.17.0.314367964272.issue20218@psf.upfronthosting.co.za> Christopher Welborn added the comment: hah, i did. I was working with 'except'ions and accidentally wrote 'except' instead of 'accept'. rookie mistake, its fixed now. As far as the docs I really can't say. Antoine would have the answers. ---------- Added file: http://bugs.python.org/file33786/pathlib.readwrite3_with_exclusive2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 01:28:01 2014 From: report at bugs.python.org (Christopher Welborn) Date: Wed, 29 Jan 2014 00:28:01 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1390955281.56.0.77910461326.issue20218@psf.upfronthosting.co.za> Changes by Christopher Welborn : Removed file: http://bugs.python.org/file33782/pathlib.readwrite3_with_exclusive.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 01:40:22 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 29 Jan 2014 00:40:22 +0000 Subject: [issue20419] it's not possible to set ECDH curve name via ssl.wrap_socket In-Reply-To: <1390926316.58.0.114750274783.issue20419@psf.upfronthosting.co.za> Message-ID: <1390956022.09.0.612106405492.issue20419@psf.upfronthosting.co.za> Antoine Pitrou added the comment: ssl.wrap_socket is pretty much a legacy API. It has too many parameters already, and I don't really want to make it worse. The SSLContext API is designed to be more palatable, even though it's a bit less compact. (also, ssl.wrap_socket will implicitly create a new context each time, which is wasteful - especially when context initialization implies loading certificates, etc.) ---------- nosy: +pitrou resolution: -> wont fix status: open -> closed versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 01:49:36 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 29 Jan 2014 00:49:36 +0000 Subject: [issue12187] subprocess.wait() with a timeout uses polling on POSIX In-Reply-To: <1306416741.33.0.363365904037.issue12187@psf.upfronthosting.co.za> Message-ID: <1390956576.12.0.318747254039.issue12187@psf.upfronthosting.co.za> Larry Hastings added the comment: I expect to be pretty lenient when it comes to asyncio, as it has no installed base yet and is marked provisional. Also it has a lot of eyes on it right now, so I'm kind of assuming the vetting process for changes at this late date is getting a lot of scrutiny. Let me know when you have something specific to go in pls. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 02:11:17 2014 From: report at bugs.python.org (Alexandre Vassalotti) Date: Wed, 29 Jan 2014 01:11:17 +0000 Subject: [issue20428] _Py_open does not work with O_CREAT In-Reply-To: <1390952730.76.0.147272441759.issue20428@psf.upfronthosting.co.za> Message-ID: <1390957877.21.0.877893583204.issue20428@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: > What is the current behaviour? I don't think the behaviour is defined. At least, I know it causes recent GCC/glibc combination to throw a compilation error when _FORTIFY_SOURCE is defined: http://www.eglibc.org/cgi-bin/viewvc.cgi/trunk/libc/io/open_2.c?view=markup For example, this is the error I got when I tried to compile Python with LTO: gcc-4.6 -pthread -flto -fuse-linker-plugin -Xlinker -export-dynamic -o python Modules/python.o libpython3.4m.a -lpthread -ldl -lutil -lm bytesobject.o (symbol from plugin): warning: memset used with constant zero length parameter; this could be due to transposed parameters In file included from ./Modules/_localemodule.c:404:0, from :459: /usr/include/x86_64-linux-gnu/bits/fcntl2.h: In function ?_Py_open?: /usr/include/x86_64-linux-gnu/bits/fcntl2.h:51:24: error: call to ?__open_missing_mode? declared with attribute error: open with O_CREAT in second argument needs 3 arguments lto-wrapper: gcc-4.6 returned 1 exit status /usr/bin/ld: lto-wrapper failed collect2: ld returned 1 exit status ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 03:33:16 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 29 Jan 2014 02:33:16 +0000 Subject: [issue20338] Idle: increase max calltip width In-Reply-To: <52E7ABD7.4060402@udel.edu> Message-ID: <52E8685A.2020607@udel.edu> Terry J. Reedy added the comment: On 1/28/2014 8:09 AM, Terry J. Reedy wrote: > > Terry J. Reedy added the comment: > > On 1/28/2014 4:48 AM, Stefan Krah wrote: >> >> Stefan Krah added the comment: >> >> I think test_idle is failing on many build slaves following this >> commit. > > The two failures I saw on the first 4 3.x bots with Idle failures are > the result of changes in the list docstrings. I presume these are > related to use of Argument Clinic. I knew and documented that such > failure was a possibility. > > On my Win 7 machine > > Jan 20, 32-bit repository build just before I added the tests that now fail. > >>> list.__doc__ > "list() -> new empty list\nlist(iterable) -> new list initialized from > iterable's items" > >>> list.__init__.__doc__ > 'x.__init__(...) initializes x; see help(type(x)) for signature' In rev88792, UTC 13:00 Larry fixed this mismatch by patching test_calltips.py to match the new string. > Jan 26, 64-bit installed 3.4.0b3: > >>> list.__doc__ > "list(iterable) -> new list initialized from iterable's items" > >>> list.__init__.__doc__ > 'Initializes self. See help(type(self)) for accurate signature.' and fixed fixed the first-line deletion somewhere in changes to about 30 other files. Until I know that there is another test somewhere that docstrings are not somehow mangled, I will leave some tests here that they are as expected. > I will re-compile and adjust the tests by the end of the day. I recompiled but will do something else instead. Terry ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 03:41:51 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 29 Jan 2014 02:41:51 +0000 Subject: [issue17162] Py_LIMITED_API needs a PyType_GenericDealloc In-Reply-To: <1360348035.19.0.130949262051.issue17162@psf.upfronthosting.co.za> Message-ID: <1390963311.98.0.73320207117.issue17162@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 03:52:34 2014 From: report at bugs.python.org (jzwinck) Date: Wed, 29 Jan 2014 02:52:34 +0000 Subject: [issue20430] argparse.SUPPRESS Message-ID: <1390963954.16.0.426686215118.issue20430@psf.upfronthosting.co.za> New submission from jzwinck: argparse.SUPPRESS is a special object which can be used in various parts of argparse to say "do nothing." One place where it does not seem to work is in an argument's "dest". This is despite some of the plumbing using "dest=SUPPRESS" internally. It can be made to work by patching argparse._StoreAction.__call__, like this: def __call__(self, parser, namespace, values, option_string=None): - setattr(namespace, self.dest, values) + if self.dest is not argparse.SUPPRESS: + setattr(namespace, self.dest, values) Once that's done, this works as one might expect: parser.add_argument('--foo', dest=argparse.SUPPRESS) With the patch, 'foo' will not appear if you parse args containing "--foo bar". Without the patch, args looks like this, which is not really useful: Namespace(==SUPPRESS==='bar') Note that the _SubParsersAction.__call__ code has something like the above patch already. ---------- components: Library (Lib) messages: 209611 nosy: jzwinck priority: normal severity: normal status: open title: argparse.SUPPRESS type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 03:56:53 2014 From: report at bugs.python.org (jzwinck) Date: Wed, 29 Jan 2014 02:56:53 +0000 Subject: [issue20430] Make argparse.SUPPRESS work as an argument "dest" In-Reply-To: <1390963954.16.0.426686215118.issue20430@psf.upfronthosting.co.za> Message-ID: <1390964213.25.0.647776221743.issue20430@psf.upfronthosting.co.za> Changes by jzwinck : ---------- title: argparse.SUPPRESS -> Make argparse.SUPPRESS work as an argument "dest" _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 04:46:54 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Wed, 29 Jan 2014 03:46:54 +0000 Subject: [issue15216] Support setting the encoding on a text stream after creation In-Reply-To: <1340880558.16.0.0136840668667.issue15216@psf.upfronthosting.co.za> Message-ID: <1390967214.06.0.469364259306.issue15216@psf.upfronthosting.co.za> Nikolaus Rath added the comment: I'm about 40% done with translating Victor's patch into C. However, in the process I got the feeling that this approach may not be so good after all. Note that: * The only use-case for set_encoding that I have found was changing the encoding of sys.{stdin,stdout,stderr} * When using non-seekable streams, set_encoding() has to be called before anything has been read from the stream, so it's unlikely that there is a situation (with the exception of sys.std*) where the stream cannot be opened with the right encoding instead (if you can't change the open call, then you probably cannot call set_encoding early enough either). * When using seekable streams, using set_encoding() breaks seeking, because the position cookie does not contain information about the decoder that was used at the given position. Example: $ cat ~/tmp/test.py import _pyio as io data = ('0123456789\r'*5).encode('utf-16_le') bstream = io.BytesIO(data) tstream = io.TextIOWrapper(bstream, encoding='latin1') tstream.readline() pos = tstream.tell() tstream.read(6) tstream.set_encoding('utf-16_le') tstream.seek(pos) $ ./python ~/tmp/test.py Traceback (most recent call last): File "/home/nikratio/tmp/test.py", line 9, in tstream.seek(pos) File "/home/nikratio/clones/cpython/Lib/_pyio.py", line 1989, in seek raise OSError("can't restore logical file position") OSError: can't restore logical file position I don't think there is a way to fix that that would not make the whole tell/seek and set_encoding code even more complicated than it already is. (It would probably involve keeping track of the history of encoders that have been used for different parts of the stream). In summary, using set_encoding() with seekable streams breaks seeking, using it with non-seekable streams requires it to be called right after open(), and the only reported case where one cannot simply change the open call instead is sys.std*. Given all that, do we really want to add a new public method to the TextIOWrapper class that can only reasonably be used with three specific streams? Personally, I think it would make much more sense to instead introduce three new functions in the sys module: sys.change_std{out,err,in}_encoding(). That solves the reported use-case just as well without polluting the namespace of all text streams. That said, I am happy to complete the implementation set_encoding in C. However, I'd like a core developer to first reconfirm that this is really the better solution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 04:48:20 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 29 Jan 2014 03:48:20 +0000 Subject: [issue20431] Should posix functions that accept fd also accept objects with .fileno()? Message-ID: <1390967300.86.0.244728862469.issue20431@psf.upfronthosting.co.za> New submission from Larry Hastings: While working on posixmodule.c today I noticed that some functions that accept file descriptors call PyObject_AsFileDescriptor(). This function accepts ints. It *also* accepts objects that expose a .fileno() attribute, calling that attribute and using the integer it returns. There are *other* functions in posixmodule.c that accept file descriptors that call _fd_converter(), which just looks for an int with a proper value. I figure it should be one way or the other. Should everything in posix that accepts file descriptor ints accept the .fileno() convention too? ---------- messages: 209613 nosy: larry priority: low severity: normal stage: needs patch status: open title: Should posix functions that accept fd also accept objects with .fileno()? type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 04:55:23 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 29 Jan 2014 03:55:23 +0000 Subject: [issue20431] Should posix functions that accept fd also accept objects with .fileno()? In-Reply-To: <1390967300.86.0.244728862469.issue20431@psf.upfronthosting.co.za> Message-ID: <1390967723.74.0.917973136187.issue20431@psf.upfronthosting.co.za> Larry Hastings added the comment: The functions that use PyObject_AsFileDescriptor() also call _PyVerify_fd(), which magically determines whether or not the file descriptor is valid. Only works on Windows though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 06:26:03 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 29 Jan 2014 05:26:03 +0000 Subject: [issue20432] Argument Clinic: when cloning functions with path_t, path_t retains the old name Message-ID: <1390973163.52.0.0655010569883.issue20432@psf.upfronthosting.co.za> New submission from Larry Hastings: If you have: module.f1 path: path_t ... module.f2 = module.f1 Then the initializer for "path" in module_f2 will supply "f1" as the function name for error messages. ---------- assignee: larry messages: 209615 nosy: larry priority: normal severity: normal stage: needs patch status: open title: Argument Clinic: when cloning functions with path_t, path_t retains the old name type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 06:39:13 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jan 2014 05:39:13 +0000 Subject: [issue20427] inspect.Signature should ensure that non-default params don't follow default ones In-Reply-To: <1390950066.9.0.564159460442.issue20427@psf.upfronthosting.co.za> Message-ID: <1390973953.08.0.0434201242199.issue20427@psf.upfronthosting.co.za> Yury Selivanov added the comment: New patch version: sig_validation_02.patch This one is a bit more correct--it uses Parameter's private '_partial_kwarg' to correctly validate partial signatures. ---------- Added file: http://bugs.python.org/file33787/sig_validation_02.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 07:43:54 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Wed, 29 Jan 2014 06:43:54 +0000 Subject: [issue16808] inspect.stack() should return list of named tuples In-Reply-To: <1356750149.18.0.966123919893.issue16808@psf.upfronthosting.co.za> Message-ID: <1390977834.62.0.0302427822513.issue16808@psf.upfronthosting.co.za> Changes by Claudiu.Popa : ---------- nosy: +Claudiu.Popa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 07:44:33 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Wed, 29 Jan 2014 06:44:33 +0000 Subject: [issue11770] inspect.dir_static In-Reply-To: <1302001735.74.0.572603626553.issue11770@psf.upfronthosting.co.za> Message-ID: <1390977873.5.0.0061065397479.issue11770@psf.upfronthosting.co.za> Changes by Claudiu.Popa : ---------- nosy: +Claudiu.Popa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 07:44:57 2014 From: report at bugs.python.org (Claudiu.Popa) Date: Wed, 29 Jan 2014 06:44:57 +0000 Subject: [issue12916] Add inspect.splitdoc In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> Message-ID: <1390977897.13.0.430096078422.issue12916@psf.upfronthosting.co.za> Changes by Claudiu.Popa : ---------- nosy: +Claudiu.Popa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 08:08:56 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 07:08:56 +0000 Subject: [issue20426] Compiling a regex with re.DEBUG should force a recompile In-Reply-To: <1390946978.37.0.473480948512.issue20426@psf.upfronthosting.co.za> Message-ID: <1390979336.3.0.189796154294.issue20426@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue17441. ---------- nosy: +pitrou, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 08:11:25 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 07:11:25 +0000 Subject: [issue18228] AIX locale parsing failure In-Reply-To: <1371355395.07.0.213079327558.issue18228@psf.upfronthosting.co.za> Message-ID: <1390979485.14.0.586465314712.issue18228@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 08:17:23 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 29 Jan 2014 07:17:23 +0000 Subject: [issue20431] Should posix functions that accept fd also accept objects with .fileno()? In-Reply-To: <1390967300.86.0.244728862469.issue20431@psf.upfronthosting.co.za> Message-ID: <1390979843.79.0.545874845879.issue20431@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 08:36:29 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 07:36:29 +0000 Subject: [issue6650] sre_parse contains a confusing generic error message In-Reply-To: <1249492479.55.0.250174703511.issue6650@psf.upfronthosting.co.za> Message-ID: <1390980989.13.0.146776449254.issue6650@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 08:41:20 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 07:41:20 +0000 Subject: [issue8264] hasattr doesn't show private (double underscore) attributes exist In-Reply-To: <1269946346.53.0.630682854213.issue8264@psf.upfronthosting.co.za> Message-ID: <1390981280.79.0.569186035617.issue8264@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +needs review stage: needs patch -> patch review versions: +Python 3.3, Python 3.4 -Python 2.6, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 08:42:35 2014 From: report at bugs.python.org (Shriramana Sharma) Date: Wed, 29 Jan 2014 07:42:35 +0000 Subject: [issue20433] add aliasedname() and namedaliases() methods to unicodedata module Message-ID: <1390981355.06.0.989685125573.issue20433@psf.upfronthosting.co.za> New submission from Shriramana Sharma: Currently we have unicodedata.name() which returns the formal character name of the character chr as per the second column in UnicodeData.txt from http://www.unicode.org/Public/UNIDATA/. However, there are a few characters where the formal character name has spelling mistakes. Also, the control characters in the Basic Latin and Latin-1 blocks aren't really given meaningful character names. In one case, that of FEFF, the formal name ZERO WIDTH NO-BREAK SPACE refers to a deprecated usage of the character (and the alternate name BYTE ORDER MARK refers to the recommended usage). In all these cases, improved names are provided as stable aliases in NameAliases.txt from the same UNIDATA source. These are also part of the stable standard and are intended to alleviate the naming situation w.r.t. the above issues. For the stability, see: http://www.unicode.org/policies/stability_policy.html#Formal_Name_Alias Hence it would be most useful if the unicodedata module would add an aliasedname() method with the same signature as name() to provide the official aliased name in the case of characters with aliases, and when a character does not have an alias, to provide the same output as name(). As of Py 3.3, unicodedata.lookup() already uses/supports NameAliases.txt for returning the character given the name. The present requirement is to use it for returning the name given the character. Note that NameAliases.txt has abbreviated names for some characters (where the third column reads "abbreviation"). While these would be useful for lookup(), they would not be useful to be returned for aliasedname(). For instance, one would prefer to see "SPACE" returned for 0020 rather than "SP". So these entries should be disregarded for aliasedname(). Also, NameAliases.txt has multiple entries for some characters even after discarding the abbreviation entries. In these cases, the first entry should be used (for want of a better rule). It is presumed that these are provided in some order of preference. It should be noted that discussion on this topic on the "unicore" (Unicode members) mailing list (on the thread "When normative aliases exist..." started 2014-01-21) indicates that the order of entries is subject to change although the entries themselves will not be removed. In this case, the first non-abbreviation entry may change. This is acceptable for the behaviour of aliasedname(). Also note that aliases may be defined in future. Thus the string returned by aliasedname() for a given character is not guaranteed to be the same, but whatever is returned by it will surely be valid to use with lookup(). Those who desire a single immutable name and do not require the improvements provided by the aliases should use name() and not aliasedname(). Finally, for extended support, a namealiases() function should return all the aliases together with their types, allowing the user full choice of the desired but official alias. The attached code should clarify the required behaviour. (It is not a patch, just an illustration.) ---------- components: Unicode files: aliasedname.py messages: 209618 nosy: ezio.melotti, haypo, jamadagni priority: normal severity: normal status: open title: add aliasedname() and namedaliases() methods to unicodedata module type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file33788/aliasedname.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 08:44:20 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 07:44:20 +0000 Subject: [issue7262] codecs.open() + eol (windows) In-Reply-To: <1257344010.52.0.739143662559.issue7262@psf.upfronthosting.co.za> Message-ID: <1390981460.6.0.0599363551509.issue7262@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Documentation -Library (Lib) keywords: +easy stage: -> needs patch versions: +Python 2.7, Python 3.3, Python 3.4 -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 08:46:46 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 29 Jan 2014 07:46:46 +0000 Subject: [issue15216] Support setting the encoding on a text stream after creation In-Reply-To: <1390967214.06.0.469364259306.issue15216@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: The specific motivating use cases I'm aware of involve the standard streams (for example, "How would you implement the equivalent of iconv in Python 3?"). There's actually the workaround for the missing feature right now: replace the standard streams with new streams, either by detaching the old ones or using the file descriptor with open(). It's also specifically the shadow references in __stdin__, __stdout__ and __stderr__ that make that replacement approach problematic (detaching breaks the shadow streams, using the file descriptor means you now have two independent IO stacks sharing the same descriptor). However, the other case where I can see this being useful is in pipes created by the subprocess module, and any other situation where an API creates a stream on your behalf, and you can't readily ensure you have replaced all the other references to that stream. In those cases, you really want to change the settings on the existing stream, rather than tracking down all the other references and rebinding them. Another question is whether or not we want to implement this as a no-op on StringIO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 08:48:50 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 29 Jan 2014 07:48:50 +0000 Subject: [issue20170] Derby #1: Convert 137 sites to Argument Clinic in Modules/posixmodule.c In-Reply-To: <1389138185.8.0.104398826507.issue20170@psf.upfronthosting.co.za> Message-ID: <1390981730.84.0.995422393929.issue20170@psf.upfronthosting.co.za> Larry Hastings added the comment: Submitting this just so I beat the deadline. I'm *about* half done, but I'm still working on it, so I'm just going to keep going--should only be another couple of hours. (If somebody else pulls this stunt, I guess I'll accept their final patch too.) ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file33789/larry.clinicize.posixmodule.1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 08:50:26 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 07:50:26 +0000 Subject: [issue20433] add aliasedname() and namedaliases() methods to unicodedata module In-Reply-To: <1390981355.06.0.989685125573.issue20433@psf.upfronthosting.co.za> Message-ID: <1390981826.47.0.934977725263.issue20433@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is a duplicate of issue18234. ---------- nosy: +serhiy.storchaka resolution: -> duplicate status: open -> pending superseder: -> Unicodedata module should provide access to codepoint aliases _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 08:56:20 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Wed, 29 Jan 2014 07:56:20 +0000 Subject: [issue19920] TarFile.list() fails on some files In-Reply-To: <1386437860.38.0.0478693655005.issue19920@psf.upfronthosting.co.za> Message-ID: <1390982180.85.0.375753360035.issue19920@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the patch to accommodate Serhiy's request. I added new test soutside CommandLineTest. The fix always uses sys.stdout.encoding. The test_list_command and test_list_command_verbose uses testtarnames now. ---------- Added file: http://bugs.python.org/file33790/fix_tarfile_list_print_lone_surrogate_v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 09:02:46 2014 From: report at bugs.python.org (Ariel Glenn) Date: Wed, 29 Jan 2014 08:02:46 +0000 Subject: [issue20418] socket.getaddrinfo fails for hostname that is all digits 0-9 In-Reply-To: <1390912986.46.0.278419787469.issue20418@psf.upfronthosting.co.za> Message-ID: <1390982566.28.0.635213089785.issue20418@psf.upfronthosting.co.za> Ariel Glenn added the comment: Verified that with AF_INET instead of AF_UNSPEC I get the error from my c program. I'll take this to the glibc folks and see what's up. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 09:36:40 2014 From: report at bugs.python.org (Vladimir Kerimov) Date: Wed, 29 Jan 2014 08:36:40 +0000 Subject: [issue20434] Process crashes if not enough memory to import module Message-ID: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za> New submission from Vladimir Kerimov: In the file _io\fileio.c in function static PyObject * fileio_readall(fileio *self) this code is incorrect and crashes the process of Python: if (_PyBytes_Resize(&result, newsize) < 0) { if (total == 0) { Py_DECREF(result); return NULL; } PyErr_Clear(); break; } In the call of _PyBytes_Resize there the result variable passed by reference and changes value to NULL-pointer when function fails and return < 0. So on the line Py_DECREF(result); the Python process crashes. ---------- components: Interpreter Core messages: 209624 nosy: asvetlov, qualab priority: normal severity: normal status: open title: Process crashes if not enough memory to import module type: crash versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 10:16:06 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 09:16:06 +0000 Subject: [issue20435] Discrepancy between io.StringIO and _pyio.StringIO with univeral newlines Message-ID: <1390986966.7.0.159416133233.issue20435@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: >>> import io, _pyio >>> io.StringIO('a\nb\r\nc\rd', newline=None) <_io.StringIO object at 0xb707c734> >>> io.StringIO('a\nb\r\nc\rd', newline=None).getvalue() 'a\nb\nc\nd' >>> _pyio.StringIO('a\nb\r\nc\rd', newline=None).getvalue() 'a\nb\r\nc\rd' >>> s = io.StringIO(newline=None); s.write('a\nb\r\nc\rd'); s.getvalue() 8 'a\nb\nc\nd' >>> s = _pyio.StringIO(newline=None); s.write('a\nb\r\nc\rd'); s.getvalue() 8 'a\nb\r\nc\rd' ---------- components: IO messages: 209625 nosy: benjamin.peterson, hynek, pitrou, serhiy.storchaka, stutzbach priority: normal severity: normal status: open title: Discrepancy between io.StringIO and _pyio.StringIO with univeral newlines type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 10:26:06 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 09:26:06 +0000 Subject: [issue20424] _pyio.StringIO doesn't work with lone surrogates In-Reply-To: <1390940815.88.0.957874925248.issue20424@psf.upfronthosting.co.za> Message-ID: <1390987566.5.0.0220264901211.issue20424@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Victor. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 10:35:35 2014 From: report at bugs.python.org (Stefan Krah) Date: Wed, 29 Jan 2014 09:35:35 +0000 Subject: [issue20338] Idle: increase max calltip width In-Reply-To: <52E8685A.2020607@udel.edu> Message-ID: <20140129093534.GA11390@sleipnir.bytereef.org> Stefan Krah added the comment: Terry J. Reedy wrote: > and fixed fixed the first-line deletion somewhere in changes to about 30 > other files. Ah, so it was a Derby accident. Let's hope things stabilize soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 10:49:31 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 29 Jan 2014 09:49:31 +0000 Subject: [issue20424] _pyio.StringIO doesn't work with lone surrogates In-Reply-To: <1390940815.88.0.957874925248.issue20424@psf.upfronthosting.co.za> Message-ID: <3fDfzt4dKlz7LlK@mail.python.org> Roundup Robot added the comment: New changeset 6ca9ba9eb76b by Serhiy Storchaka in branch '3.3': Issue #20424: Python implementation of io.StringIO now supports lone surrogates. http://hg.python.org/cpython/rev/6ca9ba9eb76b New changeset 483096ef1cf6 by Serhiy Storchaka in branch 'default': Issue #20424: Python implementation of io.StringIO now supports lone surrogates. http://hg.python.org/cpython/rev/483096ef1cf6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 10:52:37 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 09:52:37 +0000 Subject: [issue20424] _pyio.StringIO doesn't work with lone surrogates In-Reply-To: <1390940815.88.0.957874925248.issue20424@psf.upfronthosting.co.za> Message-ID: <1390989157.61.0.558950952909.issue20424@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The test is backported to 2.7 in 3971e1b07af4. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 11:03:11 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 10:03:11 +0000 Subject: [issue20436] test.regrtest is no more importable in 2.7 Message-ID: <1390989791.92.0.676223398517.issue20436@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: $ ./python -m test.regrtest /home/serhiy/py/cpython-2.7/python: No module named test.regrtest It worked several days ago. ---------- components: Tests messages: 209630 nosy: ezio.melotti, michael.foord, pitrou, serhiy.storchaka priority: normal severity: normal status: open title: test.regrtest is no more importable in 2.7 type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 11:21:01 2014 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 29 Jan 2014 10:21:01 +0000 Subject: [issue20434] Process crashes if not enough memory to import module In-Reply-To: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za> Message-ID: <1390990861.73.0.652174418757.issue20434@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Bug can be reproduced if _PyBytes_Resize fails with out-of-memory error than NULL object decrefed. Buggy modules are _io, binascii and zlib. 3.4 hasn't the problem. Patch for 3.3 is attached. Fix goes to mimic 3.4 -- (replace Py_DECREF with Py_CLEAR), while for _PyBytes_Resize that does not make sense, object has been set to NULL inside _PyBytes_Resize on fail. Also 2.7 has the same issue for _PyString_Resize calls. ---------- components: +Extension Modules -Interpreter Core keywords: +patch versions: +Python 2.7 Added file: http://bugs.python.org/file33791/issue20434.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 11:21:46 2014 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 29 Jan 2014 10:21:46 +0000 Subject: [issue20434] Process crashes if not enough memory to import module In-Reply-To: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za> Message-ID: <1390990906.68.0.148435094218.issue20434@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- keywords: +needs review stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 11:27:54 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 29 Jan 2014 10:27:54 +0000 Subject: [issue20434] Process crashes if not enough memory to import module In-Reply-To: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za> Message-ID: <1390991274.35.0.14727984347.issue20434@psf.upfronthosting.co.za> STINNER Victor added the comment: Ah yes, the bytes object is set to NULL. In fact, you don't need to call Py_CLEAR(&retval) in case of error, because retval is already NULL. Could you please update your patch to just do nothing on retval in case of error please? > 3.4 hasn't the problem. Yes, I played some weeks with pyfailmalloc, a new tool for Python 3.4 to inject random MemoryError errors. I fixed many other different issues. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 12:26:40 2014 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Wed, 29 Jan 2014 11:26:40 +0000 Subject: [issue18321] Multivolume support in tarfile module In-Reply-To: <1372406777.07.0.523288075904.issue18321@psf.upfronthosting.co.za> Message-ID: <1390994800.36.0.462210544435.issue18321@psf.upfronthosting.co.za> Lars Gust?bel added the comment: I cannot yet go into the details, because I have not tested the patch. The comments, docstrings and quoting are not very consistent with the rest of the module. There are a few spelling mistakes. The open_volume() method is more or less a copy of the open() method which is not optimal. The patch adds a lot of complexity to the tarfile module for a use case that only a few connoisseurs benefit from. It seems to alter some inherent TarFile mechanics that people might rely on, e.g. the members attribute contains only the members stored in the current volume not the overall entirety of members. Does this patch reliably allow random-access? Would it be possible/easier to add the same functionality using a separate class MultiVolumeTarFile instead? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 13:15:37 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 29 Jan 2014 12:15:37 +0000 Subject: [issue19281] add __objclass__ to the docs In-Reply-To: <1382082111.84.0.378259232568.issue19281@psf.upfronthosting.co.za> Message-ID: <1390997737.25.0.484192917447.issue19281@psf.upfronthosting.co.za> Nick Coghlan added the comment: Huh, I thought we did this back when Ethan was working on enum stuff, but I guess we never figured out exactly where to put it. Considering that question again now, I suggest adding it to the end of the subsection on implementing descriptors, since that's when it is most likely to be relevant: http://docs.python.org/dev/reference/datamodel.html#implementing-descriptors ---------- keywords: +easy stage: -> needs patch type: -> enhancement versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 13:15:46 2014 From: report at bugs.python.org (Eduardo Robles Elvira) Date: Wed, 29 Jan 2014 12:15:46 +0000 Subject: [issue18321] Multivolume support in tarfile module In-Reply-To: <1372406777.07.0.523288075904.issue18321@psf.upfronthosting.co.za> Message-ID: <1390997746.18.0.747962924226.issue18321@psf.upfronthosting.co.za> Eduardo Robles Elvira added the comment: > I cannot yet go into the details, because I have not tested the patch. > The comments, docstrings and quoting are not very consistent with the rest of the module. There are a few spelling mistakes. I can try to take care of this, though it'd be best if you can point me out concrete examples. > The open_volume() method is more or less a copy of the open() method which is not optimal. I know, but trying to do something else might be even worse.. > The patch adds a lot of complexity to the tarfile module for a use case that only a few connoisseurs benefit from. It seems to alter some inherent TarFile mechanics that people might rely on, e.g. the members attribute contains only the members stored in the current volume not the overall entirety of members. Well, that doesn't make much sense to me. You say that people rely on something like "members attribute contains only the members stored in the current volume not the overall entirety of members", but as you know, python tarfile lib didn't support volumes before this patch, so I guess people couldn't be relying on that anyway. Also please bear in mind that tarfile volumes support is part of the tar standard, and altough not everyone uses this, it has its niche uses (sliced backups etc). > Does this patch reliably allow random-access? Yes and no. No: when you open a volume for reading, the list of members is cleared as you pointed so you cannot access to them. Yes: you can open any volume at the begining of a file, and it read the tarfile from there. I do that in my use-case. > Would it be possible/easier to add the same functionality using a separate class MultiVolumeTarFile instead? If you find open_volume similar to open() and don't like, I'm quite sure you would like all the needed copy-paste having this a separate class would entail. Also as I said before, might not make much sense as this is part of the standard. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 13:19:27 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 29 Jan 2014 12:19:27 +0000 Subject: [issue20425] inspect.Signature should work on decorated builtins In-Reply-To: <1390943092.94.0.962174944377.issue20425@psf.upfronthosting.co.za> Message-ID: <1390997967.29.0.0386985689892.issue20425@psf.upfronthosting.co.za> Nick Coghlan added the comment: Patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 13:35:36 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 12:35:36 +0000 Subject: [issue19920] TarFile.list() fails on some files In-Reply-To: <1386437860.38.0.0478693655005.issue19920@psf.upfronthosting.co.za> Message-ID: <1390998936.9.0.516158491255.issue19920@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Well, good. But I still have several nitpicks. Here is revised patch. * Now ASCII encoding is used to test list() output. And tests now run even if sys.stdout is a StringIO. * test_list_verbose now test that printed files are actually separated by one new line, not by just spaces and not by two new lines. * safe_print was simplified and renamed to _safe_print. Now streams without the "encoding" attribute are supported. * Minor style fixes. ---------- Added file: http://bugs.python.org/file33792/fix_tarfile_list_print_lone_surrogate_v5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 13:36:44 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 29 Jan 2014 12:36:44 +0000 Subject: [issue20422] Signature.from_builtin should raise a ValueError when no signature can be provided In-Reply-To: <1390928419.89.0.493774550745.issue20422@psf.upfronthosting.co.za> Message-ID: <1390999004.53.0.0851041836763.issue20422@psf.upfronthosting.co.za> Nick Coghlan added the comment: This proposal and patch look good to me. The current behaviour definitely isn't desirable: >>> import inspect >>> inspect.Signature.from_function(1) Traceback (most recent call last): File "", line 1, in File "/home/ncoghlan/devel/py3k/Lib/inspect.py", line 1888, in from_function raise TypeError('{!r} is not a Python function'.format(func)) TypeError: 1 is not a Python function >>> inspect.Signature.from_builtin(1) >>> Signature.from_function() and Signature.from_builtin() should both also be documented, but we may want to wait for PEP 457 and #17373 in Python 3.5 before sorting all that out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 14:32:06 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 29 Jan 2014 13:32:06 +0000 Subject: [issue20436] test.regrtest is no more importable in 2.7 In-Reply-To: <1390989791.92.0.676223398517.issue20436@psf.upfronthosting.co.za> Message-ID: <1391002326.47.0.0150531013817.issue20436@psf.upfronthosting.co.za> R. David Murray added the comment: Still works fine for me, and I just updated. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 14:49:54 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 13:49:54 +0000 Subject: [issue20437] Use Py_CLEAR to safe clear attributes Message-ID: <1391003394.34.0.16321379297.issue20437@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Some time ago Victor proposed in issue16445 a large patch (275 changes) which replaces "Py_DECREF(expr); expr = NULL;" to safer "Py_CLEAR(expr);". That patch contained was so large because it included cases where expr is just a local variable, which are safe in general. Here are much simpler patches which make replacements only for complex expressions. These patches (as Victor patch) are generated automatically by the Coccinelle tool (http://coccinelle.lip6.fr/). ---------- components: Extension Modules, Interpreter Core files: py_clear.spatch messages: 209640 nosy: asvetlov, haypo, serhiy.storchaka, skrah priority: normal severity: normal stage: patch review status: open title: Use Py_CLEAR to safe clear attributes type: crash versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33793/py_clear.spatch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 14:50:23 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 13:50:23 +0000 Subject: [issue20437] Use Py_CLEAR to safe clear attributes In-Reply-To: <1391003394.34.0.16321379297.issue20437@psf.upfronthosting.co.za> Message-ID: <1391003423.45.0.965262125168.issue20437@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch Added file: http://bugs.python.org/file33794/py_clear-3.4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 14:50:38 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 13:50:38 +0000 Subject: [issue20437] Use Py_CLEAR to safe clear attributes In-Reply-To: <1391003394.34.0.16321379297.issue20437@psf.upfronthosting.co.za> Message-ID: <1391003438.86.0.683586328333.issue20437@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file33795/py_clear-3.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 14:50:55 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 13:50:55 +0000 Subject: [issue20437] Use Py_CLEAR to safe clear attributes In-Reply-To: <1391003394.34.0.16321379297.issue20437@psf.upfronthosting.co.za> Message-ID: <1391003455.7.0.529343904136.issue20437@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file33796/py_clear-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 15:00:55 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 14:00:55 +0000 Subject: [issue20437] Use Py_CLEAR to safe clear attributes In-Reply-To: <1391003394.34.0.16321379297.issue20437@psf.upfronthosting.co.za> Message-ID: <1391004055.43.0.112859445153.issue20437@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Patches are generated by following command: spatch --in-place --sp-file py_clear.spatch --dir . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 15:03:33 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 14:03:33 +0000 Subject: [issue20434] Process crashes if not enough memory to import module In-Reply-To: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za> Message-ID: <1391004213.41.0.149076233097.issue20434@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There are other places where Py_DECREF is called after failed _PyBytes_Resize(). For example in PyBytes_FromObject(): if (_PyBytes_Resize(&new, size) < 0) goto error; ... error: /* Error handling when new != NULL */ Py_XDECREF(it); Py_DECREF(new); return NULL; ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 15:10:22 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 29 Jan 2014 14:10:22 +0000 Subject: [issue20436] test.regrtest is no more importable in 2.7 In-Reply-To: <1390989791.92.0.676223398517.issue20436@psf.upfronthosting.co.za> Message-ID: <1391004622.83.0.79344027775.issue20436@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Works here too. Are you sure you don't have a test.py somewhere on your path? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 15:12:35 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 29 Jan 2014 14:12:35 +0000 Subject: [issue20170] Derby #1: Convert 137 sites to Argument Clinic in Modules/posixmodule.c In-Reply-To: <1389138185.8.0.104398826507.issue20170@psf.upfronthosting.co.za> Message-ID: <1391004755.4.0.94689295222.issue20170@psf.upfronthosting.co.za> Larry Hastings added the comment: Here's a complete patch, converts everything that I think should be converted for 3.4. With this patch applied, all unit tests pass on my 64-bit Linux box. I plan to also run tests with the buildbots before checking it in. The patch... well, it's 14,000 lines. 409k bytes. Do we have any takers? ---------- Added file: http://bugs.python.org/file33797/larry.clinicize.posixmodule.2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 15:12:50 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 14:12:50 +0000 Subject: [issue20436] test.regrtest is no more importable in 2.7 In-Reply-To: <1390989791.92.0.676223398517.issue20436@psf.upfronthosting.co.za> Message-ID: <1391004770.66.0.745192859289.issue20436@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Are you sure you don't have a test.py somewhere on your path? Oh, yes, I have. Sorry for the noise. ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 15:14:27 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 29 Jan 2014 14:14:27 +0000 Subject: [issue20170] Derby #1: Convert 137 sites to Argument Clinic in Modules/posixmodule.c In-Reply-To: <1389138185.8.0.104398826507.issue20170@psf.upfronthosting.co.za> Message-ID: <1391004867.06.0.428369196735.issue20170@psf.upfronthosting.co.za> Larry Hastings added the comment: By the way, my plan is to turn on the file preset just before checkin. The patch is *much* easier to read without turning that on first; with the file preset, now you have to keep two windows in sync to compare calls to PyArg_*(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 15:20:09 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 29 Jan 2014 14:20:09 +0000 Subject: [issue20437] Use Py_CLEAR to safe clear attributes In-Reply-To: <1391003394.34.0.16321379297.issue20437@psf.upfronthosting.co.za> Message-ID: <1391005209.26.0.497239863252.issue20437@psf.upfronthosting.co.za> Larry Hastings added the comment: LGTM. If it compiles cleanly and passes the unit test suite--which obviously it should--you may check the 3.4 patch to trunk. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 15:41:00 2014 From: report at bugs.python.org (Brian Quinlan) Date: Wed, 29 Jan 2014 14:41:00 +0000 Subject: [issue20319] concurrent.futures.wait() can block forever even if Futures have completed In-Reply-To: <1390263519.32.0.357208079457.issue20319@psf.upfronthosting.co.za> Message-ID: <1391006460.22.0.376372688151.issue20319@psf.upfronthosting.co.za> Changes by Brian Quinlan : ---------- assignee: -> bquinlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 15:44:26 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 29 Jan 2014 14:44:26 +0000 Subject: [issue20170] Derby #1: Convert 137 sites to Argument Clinic in Modules/posixmodule.c In-Reply-To: <1389138185.8.0.104398826507.issue20170@psf.upfronthosting.co.za> Message-ID: <1391006666.18.0.519433626753.issue20170@psf.upfronthosting.co.za> Larry Hastings added the comment: Sorry for the fresh update, but here's revision 3. Only changes: * Gave os.access a -> bool return converter. * Fixed up a lot of whitespace. Now, major "things" are separated by two empty lines, but removed whitespace between #ifdef HAVE_SOMETHING and /*[clinic input] os.something (I used to randomly have blank lines there. No more!) ---------- Added file: http://bugs.python.org/file33798/larry.clinicize.posixmodule.3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 16:46:28 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 29 Jan 2014 15:46:28 +0000 Subject: [issue20422] Signature.from_builtin should raise a ValueError when no signature can be provided In-Reply-To: <1390928419.89.0.493774550745.issue20422@psf.upfronthosting.co.za> Message-ID: <3fDpvl1Jxbz7Ljh@mail.python.org> Roundup Robot added the comment: New changeset 9433b380ad33 by Yury Selivanov in branch 'default': inspect.Signature: Make from_builtin to raise an exception if no signature can http://hg.python.org/cpython/rev/9433b380ad33 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 16:47:10 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jan 2014 15:47:10 +0000 Subject: [issue20422] Signature.from_builtin should raise a ValueError when no signature can be provided In-Reply-To: <1390928419.89.0.493774550745.issue20422@psf.upfronthosting.co.za> Message-ID: <1391010430.2.0.155924404642.issue20422@psf.upfronthosting.co.za> Yury Selivanov added the comment: Nick, thanks for the review. Committed. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 16:49:12 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jan 2014 15:49:12 +0000 Subject: [issue20422] Signature.from_builtin should raise a ValueError when no signature can be provided In-Reply-To: <1390928419.89.0.493774550745.issue20422@psf.upfronthosting.co.za> Message-ID: <1391010552.85.0.804388403233.issue20422@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Signature.from_function() and Signature.from_builtin() should both also be documented, but we may want to wait for PEP 457 and #17373 in Python 3.5 before sorting all that out. I would like to wait till 3.5 too. Right now both of them are sort of "private" API, so we still have the liberty to adjust their behaviour in 3.5 if needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 16:53:08 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 29 Jan 2014 15:53:08 +0000 Subject: [issue20425] inspect.Signature should work on decorated builtins In-Reply-To: <1390943092.94.0.962174944377.issue20425@psf.upfronthosting.co.za> Message-ID: <3fDq3R4y6Pz7LsL@mail.python.org> Roundup Robot added the comment: New changeset a9fedabb69e5 by Yury Selivanov in branch 'default': inspect.signature: Add support for decorated (wrapped) builtins #20425 http://hg.python.org/cpython/rev/a9fedabb69e5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 16:53:38 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jan 2014 15:53:38 +0000 Subject: [issue20425] inspect.Signature should work on decorated builtins In-Reply-To: <1390943092.94.0.962174944377.issue20425@psf.upfronthosting.co.za> Message-ID: <1391010818.04.0.345443727976.issue20425@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks for the review! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 16:58:49 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 29 Jan 2014 15:58:49 +0000 Subject: [issue20427] inspect.Signature should ensure that non-default params don't follow default ones In-Reply-To: <1390950066.9.0.564159460442.issue20427@psf.upfronthosting.co.za> Message-ID: <3fDqB10MZHz7Llr@mail.python.org> Roundup Robot added the comment: New changeset ca974997280d by Yury Selivanov in branch 'default': inspect.Signature: ensure that non-default params don't follow default ones #20427 http://hg.python.org/cpython/rev/ca974997280d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 16:59:02 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jan 2014 15:59:02 +0000 Subject: [issue20427] inspect.Signature should ensure that non-default params don't follow default ones In-Reply-To: <1390950066.9.0.564159460442.issue20427@psf.upfronthosting.co.za> Message-ID: <1391011142.74.0.955986035564.issue20427@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 17:45:49 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 29 Jan 2014 16:45:49 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <3fDrDD1vLvz7LjN@mail.python.org> Roundup Robot added the comment: New changeset 6d1e8162e855 by Yury Selivanov in branch 'default': inspect.getfullargspec: Use inspect.signature API behind the scenes #17481 http://hg.python.org/cpython/rev/6d1e8162e855 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 17:46:15 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jan 2014 16:46:15 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1391013975.07.0.228642775733.issue17481@psf.upfronthosting.co.za> Yury Selivanov added the comment: Committed. Thanks for the reviews! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 17:46:22 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jan 2014 16:46:22 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <1391013982.24.0.469348345426.issue17481@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 17:54:26 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 29 Jan 2014 16:54:26 +0000 Subject: [issue17481] inspect.getfullargspec should use __signature__ In-Reply-To: <1363714292.51.0.18841126063.issue17481@psf.upfronthosting.co.za> Message-ID: <3fDrQB0PCxz7LkV@mail.python.org> Roundup Robot added the comment: New changeset 0fa2750c7241 by Yury Selivanov in branch 'default': inspect.test.getfullargspec: Add a unittest to ensure correct annotations http://hg.python.org/cpython/rev/0fa2750c7241 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 18:00:13 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jan 2014 17:00:13 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? Message-ID: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> New submission from Yury Selivanov: Should we finally deprecate getfullargspec? With the AC and positional-only parameters support, getfullargspec doesn't provide full information anymore. By deprecation I mean changing its existing note "Consider using the new Signature Object interface, which provides a better way of introspecting functions." to "Deprecated since version 3.4: Use inspect.signature() instead". ---------- messages: 209658 nosy: brett.cannon, larry, ncoghlan, yselivanov priority: normal severity: normal status: open title: inspect: Deprecate getfullargspec? type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 18:27:04 2014 From: report at bugs.python.org (Larry Hastings) Date: Wed, 29 Jan 2014 17:27:04 +0000 Subject: [issue20170] Derby #1: Convert 137 sites to Argument Clinic in Modules/posixmodule.c In-Reply-To: <1389138185.8.0.104398826507.issue20170@psf.upfronthosting.co.za> Message-ID: <1391016424.61.0.88301611796.issue20170@psf.upfronthosting.co.za> Larry Hastings added the comment: Actually, forget about the file output preset. It wouldn't work for posixmodule. > 80% of the entry points are #ifdef conditional on platform functionality. Which means the Clinic generated stuff needs to be #ifdef too. It wouldn't be that hard to add the ability to #ifdef your generated code... but then what? Should it generate an #endif too, right before the end of the block? If it closed the #ifdef, then it'd look dumb: /*[clinic input]* ifdef HAVE_WHATNOT os.whatnot [clinic start generated code]*/ #ifdef HAVE_WHATNOT ... static PyObject * os_whatnot(PyModuleType *) #endif /* HAVE_WHATNOT */ /*[clinic end generated code: output=... ]*/ #ifdef HAVE_WHATNOT { ... } #endif /* HAVE_WHATNOT */ If it didn't close the #ifdef, well, that looks dumb too: /*[clinic input]* ifdef HAVE_WHATNOT os.whatnot [clinic start generated code]*/ #ifdef HAVE_WHATNOT ... static PyObject * os_whatnot(PyModuleType *) /*[clinic end generated code: output=... ]*/ { ... } #endif /* HAVE_WHATNOT */ though maybe that's less dumb. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 18:30:33 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jan 2014 17:30:33 +0000 Subject: [issue20439] inspect.Signature: Add Signature.format method to match formatargspec functionality Message-ID: <1391016633.41.0.856565781171.issue20439@psf.upfronthosting.co.za> New submission from Yury Selivanov: The ability to fine-tune formatting of Signature (currently Signature.__str__) might be useful for pydoc and idle. ---------- assignee: yselivanov messages: 209660 nosy: brett.cannon, larry, ncoghlan, terry.reedy, yselivanov priority: normal severity: normal status: open title: inspect.Signature: Add Signature.format method to match formatargspec functionality type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 18:40:51 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 17:40:51 +0000 Subject: [issue20437] Use Py_CLEAR to safe clear attributes In-Reply-To: <1391003394.34.0.16321379297.issue20437@psf.upfronthosting.co.za> Message-ID: <1391017251.01.0.104429769141.issue20437@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And here is a patch which replaces "Py_XDECREF(identifier); identifier = NULL;" to "Py_CLEAR(identifier);" (10 replaces in 7 files). It doesn't fix any bug (unless identifier is global variable), but makes a code a little cleaner. Compilers should generate equivalent code for both writing. It would be good to commit it too. ---------- Added file: http://bugs.python.org/file33799/py_xdecref_clear-3.4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 18:52:07 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 17:52:07 +0000 Subject: [issue20170] Derby #1: Convert 137 sites to Argument Clinic in Modules/posixmodule.c In-Reply-To: <1389138185.8.0.104398826507.issue20170@psf.upfronthosting.co.za> Message-ID: <1391017927.31.0.753815549638.issue20170@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The curses module also has many conditionally implemented functions. I think Argument Clinic can detect preprocessor instructions (#if/#ifdef/#ifndef/#else/#endif) and generate needed #if/#endif in generated file. This would be more robust than explicitly repeat condition in clinic declaration, because external conditions can be changed. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 19:05:05 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 29 Jan 2014 18:05:05 +0000 Subject: [issue20418] socket.getaddrinfo fails for hostname that is all digits 0-9 In-Reply-To: <1390912986.46.0.278419787469.issue20418@psf.upfronthosting.co.za> Message-ID: <1391018705.56.0.873684967128.issue20418@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 19:14:18 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 18:14:18 +0000 Subject: [issue20440] Use Py_REPLACE/Py_XREPLACE macros Message-ID: <1391019258.76.0.341506038923.issue20440@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patches replaced idiomatic code Py_DECREF(ptr); ptr = new_value; to "Py_REPLACE(ptr, new_value);" which is expanded to { PyObject *__tmp__ = ptr; ptr = new_value; Py_DECREF(__tmp__); } (and same for Py_XDECREF -> Py_XREPLACE). Victor proposed large patch for issue16447, but this issue was closed after fixing particular bug. Here are updated patches, which Py_REPLACE/Py_XREPLACE macros for cleaner code. They are also generated automatically by the Coccinelle tool (http://coccinelle.lip6.fr/): spatch --in-place --sp-file py_replace.spatch --dir . Patch for every version contains about 50 replaces in about 21-24 files. ---------- components: Extension Modules, Interpreter Core files: py_replace.spatch messages: 209663 nosy: benjamin.peterson, georg.brandl, haypo, larry, serhiy.storchaka, skrah priority: normal severity: normal stage: patch review status: open title: Use Py_REPLACE/Py_XREPLACE macros type: behavior versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33800/py_replace.spatch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 19:14:50 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 18:14:50 +0000 Subject: [issue20440] Use Py_REPLACE/Py_XREPLACE macros In-Reply-To: <1391019258.76.0.341506038923.issue20440@psf.upfronthosting.co.za> Message-ID: <1391019290.91.0.470180042642.issue20440@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch Added file: http://bugs.python.org/file33801/py_replace-3.4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 19:15:22 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 18:15:22 +0000 Subject: [issue20440] Use Py_REPLACE/Py_XREPLACE macros In-Reply-To: <1391019258.76.0.341506038923.issue20440@psf.upfronthosting.co.za> Message-ID: <1391019322.74.0.0382864994642.issue20440@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file33802/py_replace-3.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 19:16:00 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 18:16:00 +0000 Subject: [issue20440] Use Py_REPLACE/Py_XREPLACE macros In-Reply-To: <1391019258.76.0.341506038923.issue20440@psf.upfronthosting.co.za> Message-ID: <1391019360.68.0.932231520031.issue20440@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file33803/py_replace-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 19:16:52 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 18:16:52 +0000 Subject: [issue20437] Use Py_CLEAR to safe clear attributes In-Reply-To: <1391003394.34.0.16321379297.issue20437@psf.upfronthosting.co.za> Message-ID: <1391019412.07.0.738555154579.issue20437@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +benjamin.peterson, georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 19:28:28 2014 From: report at bugs.python.org (Brett Cannon) Date: Wed, 29 Jan 2014 18:28:28 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1391020108.62.0.875355328226.issue20438@psf.upfronthosting.co.za> Brett Cannon added the comment: I vote deprecation with no stated plans of removal ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 19:28:51 2014 From: report at bugs.python.org (Brett Cannon) Date: Wed, 29 Jan 2014 18:28:51 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1391020131.24.0.257092623513.issue20438@psf.upfronthosting.co.za> Brett Cannon added the comment: Although I say do it in 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 19:35:17 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 29 Jan 2014 18:35:17 +0000 Subject: [issue20440] Use Py_REPLACE/Py_XREPLACE macros In-Reply-To: <1391019258.76.0.341506038923.issue20440@psf.upfronthosting.co.za> Message-ID: <1391020517.28.0.585757989107.issue20440@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Something similar was proposed in issue3081. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 19:53:49 2014 From: report at bugs.python.org (Georg Brandl) Date: Wed, 29 Jan 2014 18:53:49 +0000 Subject: [issue17727] document that some distributions change site.py defaults In-Reply-To: <1365929014.79.0.72904930991.issue17727@psf.upfronthosting.co.za> Message-ID: <1391021629.9.0.979645425756.issue17727@psf.upfronthosting.co.za> Georg Brandl added the comment: Matthias and I agreed this isn't necessary since on the relevant distribution it's already documented. ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 19:56:22 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 29 Jan 2014 18:56:22 +0000 Subject: [issue20439] inspect.Signature: Add Signature.format method to match formatargspec functionality In-Reply-To: <1391016633.41.0.856565781171.issue20439@psf.upfronthosting.co.za> Message-ID: <1391021782.52.0.593738513451.issue20439@psf.upfronthosting.co.za> Terry J. Reedy added the comment: For an api, given that we have formatargvalue(*getargvalues, ...) formatargspec(*getfullargspec, ...) we might add formatsignature(signature, ...) with the default being the same as str(signature). I checked the first 80 hits at http://code.ohloh.net/search?s=formatargspec%28&p=7&pp=0&fl=Python&mp=1&ml=1&me=1&md=1&ff=1&filterChecked=true (which I found with 'search code' on Google) and 10-15% used one of the extended args. Another at least 5% used [1:=1] to strip of '(' and ')', so any new function might have 'parens=True' option. Idle uses the default formatargspec, like almost all other uses, and I presume str(sig) is the same except for where formatargspec is arguably wrong (bound methods). A calltip is a tip, not a doc, so I am most concerned that parameter names not be misleading, as in pattern.match(string) having the parameter misnamed 'pattern' in the C code and I presume, in .signature (absent being fixed). But that is not .signature's fault. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 20:00:04 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 19:00:04 +0000 Subject: [issue20440] Use Py_REPLACE/Py_XREPLACE macros In-Reply-To: <1391019258.76.0.341506038923.issue20440@psf.upfronthosting.co.za> Message-ID: <1391022004.87.0.530187687979.issue20440@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I do not understand why that issue was closed. Probably Py_SETREF is not the best name but this can be discussed. Adverse idea about Py_INCREF also looked questionable. But many people supported the introduction of a macro for safe replacement. And now we see that sources contain 50 potential bugs which can be fixed either by using special macros or by manually inlining them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 21:00:40 2014 From: report at bugs.python.org (Brett Cannon) Date: Wed, 29 Jan 2014 20:00:40 +0000 Subject: [issue20440] Use Py_REPLACE/Py_XREPLACE macros In-Reply-To: <1391019258.76.0.341506038923.issue20440@psf.upfronthosting.co.za> Message-ID: <1391025640.66.0.311338178524.issue20440@psf.upfronthosting.co.za> Brett Cannon added the comment: It all seems like a good idea to me and I like the Py_REPLACE naming (I was going to suggest Py_SWAP, but Py_XSWAP looks too weird to me). ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 21:14:48 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 29 Jan 2014 20:14:48 +0000 Subject: [issue20441] Test_tcl.TclTest.test_split(list) failures on Windows, 2.7. Message-ID: <1391026487.97.0.507324999213.issue20441@psf.upfronthosting.co.za> New submission from Terry J. Reedy: My Win7, AMD64 Win7, Server 2003, but not x86 Win7 buildbot or any others that run test ====================================================================== FAIL: test_split (test.test_tcl.TclTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\buildbot.python.org\2.7.kloth-win64\build\lib\test\test_tcl.py", line 321, in test_split self.assertEqual(split(arg), res) AssertionError: Tuples differ: ('12', u'\u20ac', u'\u20ac', '... != (12, u'\u20ac', u'\u20ac', (3.... First differing element 0: 12 12 - ('12', u'\u20ac', u'\u20ac', '3.4') ? - - ^ ^ + (12, u'\u20ac', u'\u20ac', (3.4,)) ? ^ ^ + ====================================================================== FAIL: test_splitlist (test.test_tcl.TclTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\buildbot.python.org\2.7.kloth-win64\build\lib\test\test_tcl.py", line 281, in test_splitlist self.assertEqual(splitlist(arg), res) AssertionError: Tuples differ: ('1', u'\u20ac', u'\u20ac', '3... != (1, u'\u20ac', u'\u20ac', (3.4... First differing element 0: 1 1 - ('1', u'\u20ac', u'\u20ac', '3.4') ? - - ^ ^ + (1, u'\u20ac', u'\u20ac', (3.4,)) ? ^ ^ + ======================================== I do not know which is correct and which wrong. ---------- components: Tkinter messages: 209671 nosy: serhiy.storchaka, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Test_tcl.TclTest.test_split(list) failures on Windows, 2.7. type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 21:18:23 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 20:18:23 +0000 Subject: [issue20441] Test_tcl.TclTest.test_split(list) failures on Windows, 2.7. In-Reply-To: <1391026487.97.0.507324999213.issue20441@psf.upfronthosting.co.za> Message-ID: <1391026703.03.0.897554219306.issue20441@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What is Tcl/Tk patchlevel? It is reported somewhere in tests log. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 21:39:11 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 29 Jan 2014 20:39:11 +0000 Subject: [issue20441] Test_tcl.TclTest.test_split(list) failures on Windows, 2.7. In-Reply-To: <1391026487.97.0.507324999213.issue20441@psf.upfronthosting.co.za> Message-ID: <1391027951.84.0.796749324544.issue20441@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am running tcl8.5.2.1 and tk8.5.2.0 as installed by Tools/buildbots/external.bat. I presume same for Windows buildbots. I did not find 'tcl' or 'tk' other than in test names in the log I checked. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 21:44:34 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 20:44:34 +0000 Subject: [issue20406] Use application icon for IDLE In-Reply-To: <1390870917.5.0.107901473313.issue20406@psf.upfronthosting.co.za> Message-ID: <6992646.i1YV4o6lXa@raxxla> Serhiy Storchaka added the comment: We can steal icon from http://www.python.org/favicon.ico. It contains three variants for different size (16, 32 and 48 pixels). Here is extracted and converted to GIF images. Please try them and original favicon on Windows. Or may be we even can cut larger icon from large official Python logo. ---------- Added file: http://bugs.python.org/file33804/python_16x16.gif Added file: http://bugs.python.org/file33805/python_32x32.gif Added file: http://bugs.python.org/file33806/python_48x48.gif _______________________________________ Python tracker _______________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: python_16x16.gif Type: image/gif Size: 585 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: python_32x32.gif Type: image/gif Size: 1373 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: python_48x48.gif Type: image/gif Size: 1266 bytes Desc: not available URL: From report at bugs.python.org Wed Jan 29 21:44:36 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jan 2014 20:44:36 +0000 Subject: [issue17159] Remove explicit type check from inspect.Signature.from_function() In-Reply-To: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za> Message-ID: <1391028276.17.0.267748316188.issue17159@psf.upfronthosting.co.za> Yury Selivanov added the comment: Stefan, is this one still relevant? If it is, I can review it (I have a couple of things to improve) and push in 3.4, as it doesn't really change any API. ---------- nosy: +yselivanov versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 21:47:56 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 20:47:56 +0000 Subject: [issue20406] Use application icon for IDLE In-Reply-To: <1390817290.68.0.153594821127.issue20406@psf.upfronthosting.co.za> Message-ID: <1391028476.16.0.190861383292.issue20406@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: As for desctop icon, see also issue1353344 and issue15869. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 21:48:17 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jan 2014 20:48:17 +0000 Subject: [issue20231] Argument Clinic accepts no-default args after default args In-Reply-To: <1389580315.91.0.810075963733.issue20231@psf.upfronthosting.co.za> Message-ID: <1391028497.08.0.0230922083573.issue20231@psf.upfronthosting.co.za> Yury Selivanov added the comment: Should this one be closed now? FWIW, signature object validates this case now. ---------- dependencies: +Argument Clinic rollup patch, 2014/01/25 nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 21:52:50 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jan 2014 20:52:50 +0000 Subject: [issue15931] inspect.findsource fails after directory change In-Reply-To: <1347463942.49.0.408409423071.issue15931@psf.upfronthosting.co.za> Message-ID: <1391028770.05.0.296971467029.issue15931@psf.upfronthosting.co.za> Yury Selivanov added the comment: Sadly, there is nothing we can do about it, as we simply don't have absolute paths in __file__ attributes in your case. ---------- nosy: +yselivanov resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 21:53:26 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 20:53:26 +0000 Subject: [issue20441] Test_tcl.TclTest.test_split(list) failures on Windows, 2.7. In-Reply-To: <1391026487.97.0.507324999213.issue20441@psf.upfronthosting.co.za> Message-ID: <1391028806.5.0.261459939641.issue20441@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is a duplicate of issue19320. ---------- resolution: -> duplicate superseder: -> Tkinter tests ran with wantobjects is false _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 21:54:47 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Jan 2014 20:54:47 +0000 Subject: [issue19320] Tkinter tests ran with wantobjects is false In-Reply-To: <1382302056.06.0.500513298536.issue19320@psf.upfronthosting.co.za> Message-ID: <1391028887.07.0.312531960702.issue19320@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Terry in issue20441 reported problems with same Tcl/Tk 8.5.2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 21:55:18 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jan 2014 20:55:18 +0000 Subject: [issue8639] Allow callable objects in inspect.getfullargspec In-Reply-To: <1273183110.15.0.600505035287.issue8639@psf.upfronthosting.co.za> Message-ID: <1391028918.95.0.727559284821.issue8639@psf.upfronthosting.co.za> Yury Selivanov added the comment: This is now fixed in #17481. ---------- dependencies: +inspect.getfullargspec should use __signature__ nosy: +yselivanov resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 22:01:44 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jan 2014 21:01:44 +0000 Subject: [issue20011] Changing the signature for Parameter's constructor In-Reply-To: <1387325083.19.0.919186460465.issue20011@psf.upfronthosting.co.za> Message-ID: <1391029304.02.0.0241487656134.issue20011@psf.upfronthosting.co.za> Yury Selivanov added the comment: I don't think this is a good idea, as it would require those who read with the code to know about this default. Explicit is definitely better than implicit in this case. ---------- nosy: +yselivanov resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 22:46:18 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 29 Jan 2014 21:46:18 +0000 Subject: [issue15869] IDLE: Include .desktop file and icon In-Reply-To: <1346929874.07.0.220677915984.issue15869@psf.upfronthosting.co.za> Message-ID: <1391031978.06.0.944932615687.issue15869@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Older issue has more patches and more discussion. ---------- nosy: +terry.reedy resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> python.desktop _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 22:46:48 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jan 2014 21:46:48 +0000 Subject: [issue20442] inspect: Document Signature & Parameter constructors' signatures Message-ID: <1391032008.93.0.17742024038.issue20442@psf.upfronthosting.co.za> New submission from Yury Selivanov: inspect.Signature & inspect.Parameter classes lack clear documentation about their constructors. Patch is attached. ---------- files: signature_docs_01.patch keywords: patch messages: 209684 nosy: eric.araujo, ezio.melotti, georg.brandl, larry, ncoghlan, yselivanov priority: normal severity: normal status: open title: inspect: Document Signature & Parameter constructors' signatures type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file33807/signature_docs_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 22:56:10 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 29 Jan 2014 21:56:10 +0000 Subject: [issue1353344] python.desktop Message-ID: <1391032570.01.0.302490427907.issue1353344@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I just closed #15869 as a duplicate of this. I has another patch and possibly useful discussion. To move forward, a concrete repository patch is needed. I only see here pieces of such a patch. I do not know how much of the Windows installation files are in the repository and how much in separate files. I know even less about Linux, what 'installation' means on that system, and how multiple languages would be handled. I should think that an addition could be made to all open branches. While anything outside of idlelib is not covered by PEP 434, I think the same principles apply. ---------- versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 23:14:11 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 29 Jan 2014 22:14:11 +0000 Subject: [issue20437] Use Py_CLEAR to safe clear attributes In-Reply-To: <1391003394.34.0.16321379297.issue20437@psf.upfronthosting.co.za> Message-ID: <1391033651.47.0.166816833558.issue20437@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Nice work, LGTM! ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 23:20:57 2014 From: report at bugs.python.org (Jeremy Kloth) Date: Wed, 29 Jan 2014 22:20:57 +0000 Subject: [issue19320] Tkinter tests ran with wantobjects is false In-Reply-To: <1382302056.06.0.500513298536.issue19320@psf.upfronthosting.co.za> Message-ID: <1391034057.63.0.991057510985.issue19320@psf.upfronthosting.co.za> Changes by Jeremy Kloth : ---------- nosy: +jkloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 23:21:09 2014 From: report at bugs.python.org (Jeremy Kloth) Date: Wed, 29 Jan 2014 22:21:09 +0000 Subject: [issue20441] Test_tcl.TclTest.test_split(list) failures on Windows, 2.7. In-Reply-To: <1391026487.97.0.507324999213.issue20441@psf.upfronthosting.co.za> Message-ID: <1391034069.21.0.69241076851.issue20441@psf.upfronthosting.co.za> Changes by Jeremy Kloth : ---------- nosy: +jkloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 23:32:38 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 29 Jan 2014 22:32:38 +0000 Subject: [issue14512] Pydocs module docs server not working on Windows. In-Reply-To: <1333645625.74.0.578211515784.issue14512@psf.upfronthosting.co.za> Message-ID: <1391034758.87.0.60082978869.issue14512@psf.upfronthosting.co.za> Terry J. Reedy added the comment: On current 3.3.4 and 3.4.0 start menus, clicking Module Docs does nothing that I can see except add a useless entry to the Frequent Programs list. I think the entry should be removed from the menu until it is made to work. All it does now is frustrate people and make Python look bad. ---------- nosy: +larry versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 23:40:53 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 29 Jan 2014 22:40:53 +0000 Subject: [issue20373] Use test.script_helper.assert_python_ok() instead of subprocess.* in test.test_warnings In-Reply-To: <1390531759.42.0.533556896595.issue20373@psf.upfronthosting.co.za> Message-ID: <1391035253.39.0.904340372608.issue20373@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 23:41:25 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 29 Jan 2014 22:41:25 +0000 Subject: [issue20373] Use test.script_helper.assert_python_ok() instead of subprocess.* in test.test_warnings In-Reply-To: <1390531759.42.0.533556896595.issue20373@psf.upfronthosting.co.za> Message-ID: <1391035285.75.0.435415023147.issue20373@psf.upfronthosting.co.za> Antoine Pitrou added the comment: There's not much point in changing the 2.7 tests at this point. It's reasonable to change both 3.3 and 3.x, so as to avoid divergence. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 23:45:15 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 29 Jan 2014 22:45:15 +0000 Subject: [issue20373] Use test.script_helper.assert_python_ok() instead of subprocess.* in test.test_warnings In-Reply-To: <1390531759.42.0.533556896595.issue20373@psf.upfronthosting.co.za> Message-ID: <3fF0By4xXcz7LkM@mail.python.org> Roundup Robot added the comment: New changeset d844b31471b5 by Antoine Pitrou in branch '3.3': Issue #20373: generalize use of test.script_helper in test_warnings. Patch by Arfrever. http://hg.python.org/cpython/rev/d844b31471b5 New changeset 04b658b3fe7c by Antoine Pitrou in branch 'default': Issue #20373: generalize use of test.script_helper in test_warnings. Patch by Arfrever. http://hg.python.org/cpython/rev/04b658b3fe7c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jan 29 23:45:36 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 29 Jan 2014 22:45:36 +0000 Subject: [issue20373] Use test.script_helper.assert_python_ok() instead of subprocess.* in test.test_warnings In-Reply-To: <1390531759.42.0.533556896595.issue20373@psf.upfronthosting.co.za> Message-ID: <1391035536.78.0.850787239854.issue20373@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the patch! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 00:16:54 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 29 Jan 2014 23:16:54 +0000 Subject: [issue20406] Use application icon for IDLE In-Reply-To: <1390817290.68.0.153594821127.issue20406@psf.upfronthosting.co.za> Message-ID: <1391037414.27.0.473977930023.issue20406@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Martin: is the medium 'python logo on white page' icon used in the Start menu in the repository or otherwise accessible? If not, could you upload it? --- I closed #15869 in favor of #1353344. Tk does not load .ico files (I tried). idle.gif is 16x16 because pc/py.ico is. That seems to be the standard default size for file lists, menus, including context menus, and title bars. On the other hand, I have my system set for larger type and gui objects, so I am better off with 24x24 or downscaled 32x32 icons. (So python_32x32 looks better than the 16x16 version.) I would like to use an 'idle' icon for Idle windows rather than the generic Python icon. I just noticed that there is a smaller 'white page with python logo' used for the Idle entry in the start menu#. It is not just a scaled-down version of the large white-page icon used on the taskbar. It is different from and better than py.ico. I think this is what we should use as menu and title bar icons are usually the same. * The same icon is also used for the 'Module docs' entry, which is supposed to be bring up a tkinter window running a pydoc script (it does in 2.7). ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 00:17:29 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 29 Jan 2014 23:17:29 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391020131.24.0.257092623513.issue20438@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: As Brett said - let's do a documented deprecation in 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 00:17:58 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jan 2014 23:17:58 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1391037478.35.0.238822531406.issue20438@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 00:37:36 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 29 Jan 2014 23:37:36 +0000 Subject: [issue15931] inspect.findsource fails after directory change In-Reply-To: <1347463942.49.0.408409423071.issue15931@psf.upfronthosting.co.za> Message-ID: <1391038656.82.0.721115983933.issue15931@psf.upfronthosting.co.za> R. David Murray added the comment: Note that this is fixed in 3.4. That is, in 3.4 __file__ paths are made absolute when the import happens. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 00:42:59 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 29 Jan 2014 23:42:59 +0000 Subject: [issue15931] inspect.findsource fails after directory change In-Reply-To: <1347463942.49.0.408409423071.issue15931@psf.upfronthosting.co.za> Message-ID: <1391038979.23.0.108144785527.issue15931@psf.upfronthosting.co.za> Yury Selivanov added the comment: Hm, maybe just for the imports? This simple script, run it directly: test.py: def foo(): pass print(foo.__code__.co_filename) "$ python3.4 test.py" will still print relative path "test.py". Hence, if you do 'os.chdir' in the above script, the introspection code will break. There are many similar issues on the tracker, btw. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 01:02:59 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 30 Jan 2014 00:02:59 +0000 Subject: [issue20417] ensurepip should not be installed with --without-ensurepip In-Reply-To: <1390910081.3.0.794745591099.issue20417@psf.upfronthosting.co.za> Message-ID: <1391040179.49.0.789303790468.issue20417@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: Some distributions have policies about not bundling external code. ensurepip currently bundles some versions of setuptools and pip. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 01:10:01 2014 From: report at bugs.python.org (Donald Stufft) Date: Thu, 30 Jan 2014 00:10:01 +0000 Subject: [issue20417] ensurepip should not be installed with --without-ensurepip In-Reply-To: <1390910081.3.0.794745591099.issue20417@psf.upfronthosting.co.za> Message-ID: <1391040601.22.0.375689355857.issue20417@psf.upfronthosting.co.za> Donald Stufft added the comment: Yes I am aware of that. However ensurepip is also required to maintain functionality of the "venv" module in 3.4. See the guidelines in http://www.python.org/dev/peps/pep-0453/#recommendations-for-downstream-distributors which explicitly mentions the fact that this is functionality equivalent to the same bundling that occurs in virtualenv and I've yet to see a distribution not include that and not make an exception to the bundling policy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 02:59:30 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 30 Jan 2014 01:59:30 +0000 Subject: [issue15931] inspect.findsource fails after directory change In-Reply-To: <1347463942.49.0.408409423071.issue15931@psf.upfronthosting.co.za> Message-ID: <1391047170.31.0.316639009633.issue15931@psf.upfronthosting.co.za> R. David Murray added the comment: __file__ is absolute for imports, yes. I didn't check co_filename, maybe that needs to be fixed too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 03:09:18 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 30 Jan 2014 02:09:18 +0000 Subject: [issue15931] inspect.findsource fails after directory change In-Reply-To: <1347463942.49.0.408409423071.issue15931@psf.upfronthosting.co.za> Message-ID: <1391047758.09.0.86841999307.issue15931@psf.upfronthosting.co.za> Yury Selivanov added the comment: Yes. I'll create an issue for that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 03:15:15 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 30 Jan 2014 02:15:15 +0000 Subject: [issue20443] __code__. co_filename should always be an absolute path Message-ID: <1391048115.83.0.412883752117.issue20443@psf.upfronthosting.co.za> New submission from Yury Selivanov: There are many issues on tracker related to the relative paths in co_filename. Most of them are about introspection functions in inspect module--which are usually broken after 'os.chdir'. Test case: create a file t.py: def foo(): pass print(foo.__code__.co_filename) Execute it with '$ python t.py' -> it will print 't.py'. Ideally, when executing a python file, interpreter should expand all relative paths for __file__ and __code__.co_filename attributes. ---------- messages: 209699 nosy: r.david.murray, yselivanov priority: normal severity: normal stage: needs patch status: open title: __code__. co_filename should always be an absolute path type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 03:15:56 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 30 Jan 2014 02:15:56 +0000 Subject: [issue20443] __code__. co_filename should always be an absolute path In-Reply-To: <1391048115.83.0.412883752117.issue20443@psf.upfronthosting.co.za> Message-ID: <1391048156.66.0.468013223882.issue20443@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 03:21:58 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 30 Jan 2014 02:21:58 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1391048518.43.0.382738609364.issue16991@psf.upfronthosting.co.za> Yury Selivanov added the comment: Can we still merge this in 3.4? ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 03:38:07 2014 From: report at bugs.python.org (dongwm) Date: Thu, 30 Jan 2014 02:38:07 +0000 Subject: [issue20444] Reduce logging.config.Converting duplication of code Message-ID: <1391049487.07.0.209856527412.issue20444@psf.upfronthosting.co.za> Changes by dongwm : ---------- components: Library (Lib) files: logging_config.patch keywords: patch nosy: dongwm priority: normal severity: normal status: open title: Reduce logging.config.Converting duplication of code type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file33808/logging_config.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 05:28:20 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 30 Jan 2014 04:28:20 +0000 Subject: [issue20440] Use Py_REPLACE/Py_XREPLACE macros In-Reply-To: <1391019258.76.0.341506038923.issue20440@psf.upfronthosting.co.za> Message-ID: <1391056100.56.0.572973953237.issue20440@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Unless some known bugs are being fixed, this should be 3.4 only. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 05:32:45 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 30 Jan 2014 04:32:45 +0000 Subject: [issue20170] Derby #1: Convert 137 sites to Argument Clinic in Modules/posixmodule.c In-Reply-To: <1389138185.8.0.104398826507.issue20170@psf.upfronthosting.co.za> Message-ID: <1391056365.25.0.135339766905.issue20170@psf.upfronthosting.co.za> Larry Hastings added the comment: That's a really good idea! I'm still thinking about how I'd do it, but I think I'm gonna give it a try. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 06:12:30 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 30 Jan 2014 05:12:30 +0000 Subject: [issue20442] inspect: Document Signature & Parameter constructors' signatures In-Reply-To: <1391032008.93.0.17742024038.issue20442@psf.upfronthosting.co.za> Message-ID: <3fF8nn2nD4z7LjV@mail.python.org> Roundup Robot added the comment: New changeset 0a3201aab2b8 by Yury Selivanov in branch 'default': inspect.docs: Document constructors for Signature & Parameter #20442 http://hg.python.org/cpython/rev/0a3201aab2b8 New changeset 885c709d0dde by Yury Selivanov in branch '3.3': inspect.docs: Document constructors for Signature & Parameter #20442 http://hg.python.org/cpython/rev/885c709d0dde ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 06:13:01 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 30 Jan 2014 05:13:01 +0000 Subject: [issue20442] inspect: Document Signature & Parameter constructors' signatures In-Reply-To: <1391032008.93.0.17742024038.issue20442@psf.upfronthosting.co.za> Message-ID: <1391058781.8.0.930735240655.issue20442@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 06:33:35 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 30 Jan 2014 05:33:35 +0000 Subject: [issue18801] inspect.classify_class_attrs() misclassifies object.__new__() In-Reply-To: <1377114694.59.0.675744683781.issue18801@psf.upfronthosting.co.za> Message-ID: <1391060015.89.0.74522807764.issue18801@psf.upfronthosting.co.za> Yury Selivanov added the comment: Tim, Eric, Please review the attached patch. ---------- keywords: +patch nosy: +tim.peters, yselivanov Added file: http://bugs.python.org/file33809/inspect_classify_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 06:46:19 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 30 Jan 2014 05:46:19 +0000 Subject: [issue19658] inspect.getsource weird case In-Reply-To: <1384896343.05.0.723899962428.issue19658@psf.upfronthosting.co.za> Message-ID: <1391060779.39.0.707449756773.issue19658@psf.upfronthosting.co.za> Yury Selivanov added the comment: Duplicate of #17526. ---------- nosy: +yselivanov resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 06:55:10 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 30 Jan 2014 05:55:10 +0000 Subject: [issue15731] Mechanism for inheriting docstrings and signatures In-Reply-To: <1345437452.28.0.514901819881.issue15731@psf.upfronthosting.co.za> Message-ID: <1391061310.74.0.755852570801.issue15731@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 07:20:02 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 30 Jan 2014 06:20:02 +0000 Subject: [issue15731] Mechanism for inheriting docstrings and signatures In-Reply-To: <1345437452.28.0.514901819881.issue15731@psf.upfronthosting.co.za> Message-ID: <1391062802.14.0.0879416743407.issue15731@psf.upfronthosting.co.za> Yury Selivanov added the comment: Perhaps, something like @functools.inherit decorator could help: https://gist.github.com/1st1/8703533 (just a quick illustration). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 08:03:17 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 30 Jan 2014 07:03:17 +0000 Subject: [issue19081] zipimport behaves badly when the zip file changes while the process is running In-Reply-To: <1379995203.41.0.89812771706.issue19081@psf.upfronthosting.co.za> Message-ID: <3fFCFc2pkCz7Ljf@mail.python.org> Roundup Robot added the comment: New changeset ecb272bae417 by Gregory P. Smith in branch '3.3': Remove issue 19081 Misc/NEWS entry since it isn't entirely fixed yet. http://hg.python.org/cpython/rev/ecb272bae417 New changeset 03fc7449f204 by Gregory P. Smith in branch 'default': Remove issue 19081 Misc/NEWS entry since it isn't entirely fixed yet. http://hg.python.org/cpython/rev/03fc7449f204 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 08:15:27 2014 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 30 Jan 2014 07:15:27 +0000 Subject: [issue17159] Remove explicit type check from inspect.Signature.from_function() In-Reply-To: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za> Message-ID: <1391066127.07.0.977808035995.issue17159@psf.upfronthosting.co.za> Stefan Behnel added the comment: Yes, the situation didn't change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 09:05:44 2014 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 30 Jan 2014 08:05:44 +0000 Subject: [issue20326] Argument Clinic should use a non-error-prone syntax to mark text signatures In-Reply-To: <1390298749.1.0.12762219489.issue20326@psf.upfronthosting.co.za> Message-ID: <1391069144.39.0.0629762351807.issue20326@psf.upfronthosting.co.za> Stefan Behnel added the comment: I stumble over this because I had already adapted our doctests in Cython to the changed Py3.4 behaviour, so they started failing now because the automatic signature extraction was essentially reverted in CPython. I had started to consider it a feature that CPython 3.4 was finally smart enough to pick up signatures from docstrings, at least for documentation purposes, much the same way that tools like epydoc or Sphinx do it. Cython has a feature to embed signatures for that reason, and so far, they happily ended up in "__text_signature__" in Py3.4. I understand the problem that not all of these signatures are valid Python signatures. What Cython currently generates certainly isn't. The new "sig=" is not supported by any of the existing documentation tools. Having Cython follow here would mean that they would no longer be able to read the signatures, and it's clearly more important for the time being to keep *them* working nicely. This change actually facilitates that, because it leaves the embedded signatures untouched, so that these tools can normally pick them up again. So I agree that the reverted behaviour is in fact better than what Py3.4 previously did. FWIW, I think the best way to go forward would be to try to find a way to map Cython's C signatures directly to a reasonable version of a "__signature__" object. This hasn't appeared entirely trivial so far, but my guess is that the recent requirements on and improvements to the argument clinic should also have made this mapping a little less hard, because there are at least a bit of an infrastructure and some precedents around. Still, Cython's coverage of C/C++ types (also in signatures) is hugely broader than what ac would ever want to support, so we'll have to see what stumbling blocks remain on that road. ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 11:48:54 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 30 Jan 2014 10:48:54 +0000 Subject: [issue12187] subprocess.wait() with a timeout uses polling on POSIX In-Reply-To: <1306416741.33.0.363365904037.issue12187@psf.upfronthosting.co.za> Message-ID: <1391078933.99.0.949690949389.issue12187@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: > The new asyncio module doesn't have this performance issue > On Unix, the default implementation sets an handler for SIGCHLD signal which > calls waitpid(pid, WNOHANG) on all processes to detect process exit. But it has > also a faster implementation which calls waitpid(-1, WNOHANG) only once. But that is still a busy loop, no? My understanding was that the goal of this ticket was to figure out a strategy to get rid of that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 12:57:45 2014 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Thu, 30 Jan 2014 11:57:45 +0000 Subject: [issue18321] Multivolume support in tarfile module In-Reply-To: <1372406777.07.0.523288075904.issue18321@psf.upfronthosting.co.za> Message-ID: <1391083065.85.0.00217916049909.issue18321@psf.upfronthosting.co.za> Lars Gust?bel added the comment: At first, I'd like to take back my comment on this patch being too complex for too little benefit. That is no real argument. Okay, I gave it a shot and I have a few more remarks: The patch does not support iterating over a multi-volume tar archive, e.g. for TarFile.list(). You must implement this. In my opinion, a tar archive is one logical unit even if it spans across multiple volumes. Thus, it is vital to have .getmembers() and .getnames() reflect the entirety of the archive, e.g. to support "if filename in .getnames()". I think it could be a good idea to store the volume number along each TarInfo object for random-access. By the way, which standard are you referring to? The only one I know of is POSIX pax which doesn't say anything about multiple volumes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 13:57:41 2014 From: report at bugs.python.org (George Kouryachy) Date: Thu, 30 Jan 2014 12:57:41 +0000 Subject: [issue20445] HAVE_BROKEN_NICE detected incorrectly due to configure.ac typo Message-ID: <1391086661.44.0.32383692097.issue20445@psf.upfronthosting.co.za> New submission from George Kouryachy: It's declared in pyconfig.h that HAVE_BROKEN_NICE is set if nice() returns success/failure instead of the new priority. But configure checks just opposite (as for http://hg.python.org/cpython/file/03fc7449f204/configure.ac#l4234): if (val1 != -1 && val1 == nice(2)) exit(0); We need "val1 != nice(2)" instead (to ensure that nicelevel is increased) or "val1 == nice(2)+2" (to check increment is proper; this can be tricky in some cases). ---------- components: Build messages: 209712 nosy: George.Kouryachy priority: normal severity: normal status: open title: HAVE_BROKEN_NICE detected incorrectly due to configure.ac typo type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 13:58:59 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 Jan 2014 12:58:59 +0000 Subject: [issue20440] Use Py_REPLACE/Py_XREPLACE macros In-Reply-To: <1391056100.56.0.572973953237.issue20440@psf.upfronthosting.co.za> Message-ID: <1978530.Utl7BbEJ05@raxxla> Serhiy Storchaka added the comment: > Unless some known bugs are being fixed, this should be 3.4 only. For example here is a bug very similar to a bug fixed in issue16447. class Nasty(str): def __del__(self): C.__qualname__ = "other" class C: pass C.__qualname__ = Nasty("abc") C.__qualname__ = "normal" C.__qualname__ = "normal" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 14:02:08 2014 From: report at bugs.python.org (flambda) Date: Thu, 30 Jan 2014 13:02:08 +0000 Subject: [issue20446] ipaddress: hash similarities for ipv4 and ipv6 Message-ID: <1391086928.1.0.694997709579.issue20446@psf.upfronthosting.co.za> New submission from flambda: Hi, I am a bit unsure if this is a problem but bear with me: Using ipaddress I noticed that: hash(ipaddress.ip_address("0.0.0.1")) == hash(ipaddress.ip_address("::1")) which makes sense as ipaddress uses this: (http://hg.python.org/cpython/file/default/Lib/ipaddress.py) def __hash__(self): return hash(hex(int(self._ip))) as the hash. This means that in a mixed environment (ipv4 and ipv6 addresses), hashtables with hash(hex(int(b))), int(b)<2**32 will be filled more then tables with int(b)>2**32 due to the ipv4 and ipv6 address space overlapping in the first 32bits. If this is intended behaviour, I am sorry to have bothered you. Have a nice evening. ---------- components: Interpreter Core messages: 209714 nosy: flambda priority: normal severity: normal status: open title: ipaddress: hash similarities for ipv4 and ipv6 type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 14:07:43 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 Jan 2014 13:07:43 +0000 Subject: [issue20440] Use Py_REPLACE/Py_XREPLACE macros In-Reply-To: <1391019258.76.0.341506038923.issue20440@psf.upfronthosting.co.za> Message-ID: <1391087263.59.0.0477115307869.issue20440@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- priority: normal -> high type: behavior -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 14:17:18 2014 From: report at bugs.python.org (George Kouryachy) Date: Thu, 30 Jan 2014 13:17:18 +0000 Subject: [issue20445] HAVE_BROKEN_NICE detected incorrectly due to configure.ac typo In-Reply-To: <1391086661.44.0.32383692097.issue20445@psf.upfronthosting.co.za> Message-ID: <1391087838.94.0.896647156513.issue20445@psf.upfronthosting.co.za> George Kouryachy added the comment: It seems to be permanent typo through all branches :( ---------- versions: +Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 14:24:08 2014 From: report at bugs.python.org (Jakub Wilk) Date: Thu, 30 Jan 2014 13:24:08 +0000 Subject: [issue20415] Could method "isinstance" take a list as parameter? In-Reply-To: <1390901274.15.0.0556662587348.issue20415@psf.upfronthosting.co.za> Message-ID: <1391088248.98.0.672449845722.issue20415@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 14:50:40 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 30 Jan 2014 13:50:40 +0000 Subject: [issue12187] subprocess.wait() with a timeout uses polling on POSIX In-Reply-To: <1391078933.99.0.949690949389.issue12187@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > But that is still a busy loop, no? No, it's not. asyncio uses a selector which waits for events on file descriptors. It uses signal.set_wakeup_fd() which writes asynchronously on a file descriptor. So asyncio is suspended until a file descriptor gets data. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 14:54:41 2014 From: report at bugs.python.org (Jakub Wilk) Date: Thu, 30 Jan 2014 13:54:41 +0000 Subject: [issue16202] sys.path[0] security issues In-Reply-To: <1349986223.57.0.879834971708.issue16202@psf.upfronthosting.co.za> Message-ID: <1391090081.5.0.12710729445.issue16202@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 15:03:45 2014 From: report at bugs.python.org (Jakub Wilk) Date: Thu, 30 Jan 2014 14:03:45 +0000 Subject: [issue20447] doctest.debug_script: insecure use of /tmp Message-ID: <1391090625.54.0.961890812263.issue20447@psf.upfronthosting.co.za> New submission from Jakub Wilk: The doctest.debug_script function creates temporary files in an insecure way: srcfilename = tempfile.mktemp(".py", "doctestdebug") f = open(srcfilename, 'w') This is already fixed for Python >= 3.2, although for reasons other than security: issue12451 ---------- components: Library (Lib) messages: 209717 nosy: jwilk priority: normal severity: normal status: open title: doctest.debug_script: insecure use of /tmp type: security versions: Python 2.7, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 15:16:17 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Thu, 30 Jan 2014 14:16:17 +0000 Subject: [issue20448] Adds missing backslash to devguide setup page Message-ID: <1391091377.95.0.274075734127.issue20448@psf.upfronthosting.co.za> New submission from Saimadhav Heblikar: This is a simple typofix. On line 224 and 225,there were unescaped backslashes,which resulted in the external.bat and external-amd64.bat appeared as Tools\buildbotexternal.bat and Tools\buildbotexternal-amd64.bat respectively. this patch escapes the two back-slashes,so that the text appears correctly as Tools\buildbot\external.bat or Tools\buildbot\external-amd64.bat ---------- components: Devguide files: mywork.patch keywords: patch messages: 209718 nosy: ezio.melotti, sahutd priority: normal severity: normal status: open title: Adds missing backslash to devguide setup page type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file33810/mywork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 15:23:43 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 30 Jan 2014 14:23:43 +0000 Subject: [issue17162] Py_LIMITED_API needs a PyType_GenericDealloc In-Reply-To: <1360348035.19.0.130949262051.issue17162@psf.upfronthosting.co.za> Message-ID: <1391091823.33.0.246252617186.issue17162@psf.upfronthosting.co.za> Martin v. L?wis added the comment: If the set of slots gets extended, extensions would have to opt-in to use the newer slots, i.e. the availability of slot numbers should be conditional at compile-time. Returning 0 for slots not supported in a version seems fine to me as well (after reconsideration), as this is also what you would get if you just recompiled the old type with the new Python headers (i.e. all fields added at the end are 0-initialized). As for slots added to 3.4: it would certainly possible to add them to the stable ABI, if we indeed trust that they are stable (i.e. won't go away until 4.0). That would have to be decided on a slot-by-slot case, preferably in individual roundup issues. ---------- Added file: http://bugs.python.org/file33811/getslot2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 15:26:50 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 30 Jan 2014 14:26:50 +0000 Subject: [issue20444] Reduce logging.config.Converting duplication of code Message-ID: <1391092010.66.0.038808053693.issue20444@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 15:32:54 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Thu, 30 Jan 2014 14:32:54 +0000 Subject: [issue20448] Adds missing backslash to devguide setup page In-Reply-To: <1391091377.95.0.274075734127.issue20448@psf.upfronthosting.co.za> Message-ID: <1391092374.01.0.0572690358263.issue20448@psf.upfronthosting.co.za> Saimadhav Heblikar added the comment: http://hg.python.org/devguide/rev/99419f310cf1 ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 15:49:11 2014 From: report at bugs.python.org (Jakub Wilk) Date: Thu, 30 Jan 2014 14:49:11 +0000 Subject: [issue12015] possible characters in temporary file name is too few In-Reply-To: <1304661107.62.0.977226402655.issue12015@psf.upfronthosting.co.za> Message-ID: <1391093351.53.0.8556867307.issue12015@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 15:49:19 2014 From: report at bugs.python.org (Jakub Wilk) Date: Thu, 30 Jan 2014 14:49:19 +0000 Subject: [issue18673] Add O_TMPFILE to os module In-Reply-To: <1375818220.16.0.883591943761.issue18673@psf.upfronthosting.co.za> Message-ID: <1391093359.01.0.403492567565.issue18673@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 16:21:28 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 30 Jan 2014 15:21:28 +0000 Subject: [issue20448] Adds missing backslash to devguide setup page In-Reply-To: <1391091377.95.0.274075734127.issue20448@psf.upfronthosting.co.za> Message-ID: <1391095288.44.0.900723465379.issue20448@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: duplicate -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 16:22:29 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 30 Jan 2014 15:22:29 +0000 Subject: [issue20449] _overlapped: read_buffer and write_buffer are misused Message-ID: <1391095349.64.0.498559512626.issue20449@psf.upfronthosting.co.za> New submission from STINNER Victor: I found an issue in overlapped.c: read_buffer and write_buffer attributes are defined in an union, but they are sometimes use even if the type is not good. I found this issue while trying to get a BrokenPipeError on Windows when the stdin stream of a subprocess is full but the process exited. Could you please review attached patch, especially the change in Overlapped_getresult? Another option would be to use two real attributes (remove the union), but I like the usage of union :-) All Tulip unit tests of my subprocess_stream pass on Linux and Windows with the patch. ---------- files: overlapped.patch keywords: patch messages: 209721 nosy: gvanrossum, haypo, larry, pitrou, sbt priority: release blocker severity: normal status: open title: _overlapped: read_buffer and write_buffer are misused versions: Python 3.4 Added file: http://bugs.python.org/file33812/overlapped.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 17:22:10 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 30 Jan 2014 16:22:10 +0000 Subject: [issue17162] Py_LIMITED_API needs a PyType_GenericDealloc In-Reply-To: <1360348035.19.0.130949262051.issue17162@psf.upfronthosting.co.za> Message-ID: <1391098930.74.0.309001691618.issue17162@psf.upfronthosting.co.za> Larry Hastings added the comment: I thought I replied to this... weird. Do I understand correctly that it's basically impossible to write a proper custom deallocator in the limited API right now, because you can't get access to your base class's tp_free? (If so, why didn't anybody notice?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 17:23:48 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 30 Jan 2014 16:23:48 +0000 Subject: [issue20448] Adds missing backslash to devguide setup page In-Reply-To: <1391091377.95.0.274075734127.issue20448@psf.upfronthosting.co.za> Message-ID: <3fFRhM3RD8z7Ljp@mail.python.org> Roundup Robot added the comment: New changeset 7d95a62513ce by Zachary Ware in branch 'default': Issue #20448: Escape backslashes. Caught by Saimadhav Heblikar. http://hg.python.org/devguide/rev/7d95a62513ce ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 17:26:34 2014 From: report at bugs.python.org (Zachary Ware) Date: Thu, 30 Jan 2014 16:26:34 +0000 Subject: [issue20448] Adds missing backslash to devguide setup page In-Reply-To: <1391091377.95.0.274075734127.issue20448@psf.upfronthosting.co.za> Message-ID: <1391099194.83.0.577129804764.issue20448@psf.upfronthosting.co.za> Zachary Ware added the comment: Actually, this was still an issue :) Thanks for the report and patch! If you intend to ever contribute more than the simplest of patches, please consider signing a contributor agreement: http://www.python.org/psf/contrib/ ---------- nosy: +zach.ware stage: -> committed/rejected versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 17:27:55 2014 From: report at bugs.python.org (Larry Hastings) Date: Thu, 30 Jan 2014 16:27:55 +0000 Subject: [issue17162] Py_LIMITED_API needs a PyType_GenericDealloc In-Reply-To: <1360348035.19.0.130949262051.issue17162@psf.upfronthosting.co.za> Message-ID: <1391099275.02.0.152495258919.issue17162@psf.upfronthosting.co.za> Larry Hastings added the comment: Also, isn't it reasonable to pass in non-heap type objects? I realize supporting this would complicate the implementation a great deal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 17:49:36 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 30 Jan 2014 16:49:36 +0000 Subject: [issue17159] Remove explicit type check from inspect.Signature.from_function() In-Reply-To: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za> Message-ID: <1391100576.49.0.403215842743.issue17159@psf.upfronthosting.co.za> Yury Selivanov added the comment: Stefan, I'm attaching a reviewed patch--was a bit easier to rebase it on the new code and fix the remaining issues. Please review. BTW, do cython functions have __name__ attribute? ---------- assignee: -> yselivanov Added file: http://bugs.python.org/file33813/sig_func_ducktype_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 18:05:40 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 30 Jan 2014 17:05:40 +0000 Subject: [issue20445] HAVE_BROKEN_NICE detected incorrectly due to configure.ac typo In-Reply-To: <1391086661.44.0.32383692097.issue20445@psf.upfronthosting.co.za> Message-ID: <1391101540.59.0.593948581457.issue20445@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Are you sure? The configure test sets ac_cv_broken_nice=1 if "val1 == nice(2)". That is if the call returns the same succesful value each time. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 18:15:30 2014 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 30 Jan 2014 17:15:30 +0000 Subject: [issue17159] Remove explicit type check from inspect.Signature.from_function() In-Reply-To: <1391100576.49.0.403215842743.issue17159@psf.upfronthosting.co.za> Message-ID: <52EA88B1.1000707@behnel.de> Stefan Behnel added the comment: LGTM, thanks! And works nicely with Cython: """ import inspect def test_isfunction(): """ >>> test_isfunction() True """ return inspect.isfunction(test_isfunction) def test_signature(): """ >>> test_signature() # doctest: +ELLIPSIS """ return inspect.signature(test_signature) """ > BTW, do cython functions have __name__ attribute? Yes, they have everything that can possibly be emulated (although not everything currently contains useful information). If your question is whether that should be tested for, too, then I'd say yes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 18:28:30 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 30 Jan 2014 17:28:30 +0000 Subject: [issue17159] Remove explicit type check from inspect.Signature.from_function() In-Reply-To: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za> Message-ID: <1391102910.64.0.624659698032.issue17159@psf.upfronthosting.co.za> Yury Selivanov added the comment: Attached is a second patch (sig_func_ducktype_02.patch), with a bit improved tests (and a small bug fixed). Larry, do you think it's OK if I merge this one in 3.4? Technically, it's a feature that we start to support Cython functions in inspect.signature, but from the standpoint of the API everything is the same. ---------- nosy: +larry stage: -> patch review type: behavior -> enhancement Added file: http://bugs.python.org/file33814/sig_func_ducktype_02.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 18:52:07 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 Jan 2014 17:52:07 +0000 Subject: [issue19320] Tkinter tests ran with wantobjects is false In-Reply-To: <1382302056.06.0.500513298536.issue19320@psf.upfronthosting.co.za> Message-ID: <1391104327.56.0.433653539869.issue19320@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Looks as dicts before 8.5.5 were converted to lists through string. Here are patches for 3.4 and 2.7. ---------- stage: committed/rejected -> patch review Added file: http://bugs.python.org/file33815/test_tcl_split_dict-3.4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 18:52:32 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 Jan 2014 17:52:32 +0000 Subject: [issue19320] Tkinter tests ran with wantobjects is false In-Reply-To: <1382302056.06.0.500513298536.issue19320@psf.upfronthosting.co.za> Message-ID: <1391104352.12.0.331077121605.issue19320@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file33816/test_tcl_split_dict-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 18:53:02 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 Jan 2014 17:53:02 +0000 Subject: [issue20441] Test_tcl.TclTest.test_split(list) failures on Windows, 2.7. In-Reply-To: <1391026487.97.0.507324999213.issue20441@psf.upfronthosting.co.za> Message-ID: <1391104382.22.0.128662352288.issue20441@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 19:06:52 2014 From: report at bugs.python.org (Ronald Oussoren) Date: Thu, 30 Jan 2014 18:06:52 +0000 Subject: [issue18378] locale.getdefaultlocale() fails on Mac OS X with default language set to English In-Reply-To: <1373113143.69.0.513997485887.issue18378@psf.upfronthosting.co.za> Message-ID: <1391105212.34.0.707753272423.issue18378@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I just ran into this problem myself. On fresh installs of OSX 10.9 LC_CTYPE is set to "UTF-8" (at least for english language users), and now sphinx won't work :-( Is Dimitrys patch acceptable (either as is, or with my suggestion of checking for sys.platform == "darwin")? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 19:51:20 2014 From: report at bugs.python.org (lothar) Date: Thu, 30 Jan 2014 18:51:20 +0000 Subject: [issue20398] stem crashes python In-Reply-To: <1390749180.01.0.603192717521.issue20398@psf.upfronthosting.co.za> Message-ID: <1391107880.01.0.50764822804.issue20398@psf.upfronthosting.co.za> lothar added the comment: you are right: windows native python 3.3.3 from your link runs the program properly - and without crashing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 20:15:33 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 Jan 2014 19:15:33 +0000 Subject: [issue20406] Use application icon for IDLE In-Reply-To: <1390817290.68.0.153594821127.issue20406@psf.upfronthosting.co.za> Message-ID: <1391109333.25.0.780493842325.issue20406@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think that all icons used in Windows installer are in the repository. All four ico-files in the PC directory contains 7 images: 16, 32 and 48 pixels size and 4-, 8- and 32-bits per pixel. Three of them (except PC/launcher.ico) were added in issue1490384. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 20:42:42 2014 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 30 Jan 2014 19:42:42 +0000 Subject: [issue20444] Reduce logging.config.Converting duplication of code Message-ID: <1391110962.17.0.305994187696.issue20444@psf.upfronthosting.co.za> Changes by Vinay Sajip : ---------- assignee: -> vinay.sajip versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 21:22:53 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 30 Jan 2014 20:22:53 +0000 Subject: [issue20444] Reduce logging.config.Converting duplication of code Message-ID: <3fFY0F1QBzz7LjQ@mail.python.org> New submission from Roundup Robot: New changeset 03b399c807d6 by Vinay Sajip in branch '2.7': Issue #20444: Reduced code duplication. Thanks to dongwm for the report and patch. http://hg.python.org/cpython/rev/03b399c807d6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 21:23:43 2014 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 30 Jan 2014 20:23:43 +0000 Subject: [issue20444] Reduce logging.config.Converting duplication of code In-Reply-To: <3fFY0F1QBzz7LjQ@mail.python.org> Message-ID: <1391113423.98.0.685008478687.issue20444@psf.upfronthosting.co.za> Vinay Sajip added the comment: I'll keep this issue open to remind me to patch 3.3 / 3.4 at the appropriate time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 21:29:39 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 Jan 2014 20:29:39 +0000 Subject: [issue20450] hg touch fails on System Z Linux buildbot Message-ID: <1391113779.26.0.124342883313.issue20450@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: "Touching generated files failed" step fails on System Z Linux buildbot (http://buildbot.python.org/all/builders/System%20Z%20Linux%203.x/builds/1157/steps/shell/logs/stdio): hg --config extensions.touch=Tools/hg/hgtouch.py touch -v ** unknown exception encountered, details follow ** report bug details to http://www.selenic.com/mercurial/bts ** or mercurial at selenic.com ** Mercurial Distributed SCM (version 1.0.2) Traceback (most recent call last): File "/usr/bin/hg", line 20, in mercurial.dispatch.run() File "/usr/lib64/python2.6/site-packages/mercurial/dispatch.py", line 20, in run sys.exit(dispatch(sys.argv[1:])) File "/usr/lib64/python2.6/site-packages/mercurial/dispatch.py", line 29, in dispatch return _runcatch(u, args) File "/usr/lib64/python2.6/site-packages/mercurial/dispatch.py", line 45, in _runcatch return _dispatch(ui, args) File "/usr/lib64/python2.6/site-packages/mercurial/dispatch.py", line 299, in _dispatch cmd, func, args, options, cmdoptions = _parse(lui, args) File "/usr/lib64/python2.6/site-packages/mercurial/dispatch.py", line 187, in _parse args = fancyopts.fancyopts(args, c, cmdoptions) File "/usr/lib64/python2.6/site-packages/mercurial/fancyopts.py", line 29, in fancyopts for short, name, default, comment in options: ValueError: too many values to unpack make: *** [touch] Error 1 I think upgrading Mercurial should fix this issue. ---------- components: Tests messages: 209736 nosy: ezio.melotti, michael.foord, pitrou, serhiy.storchaka priority: normal severity: normal status: open title: hg touch fails on System Z Linux buildbot _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 21:45:43 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 30 Jan 2014 20:45:43 +0000 Subject: [issue20449] _overlapped: read_buffer and write_buffer are misused In-Reply-To: <1391095349.64.0.498559512626.issue20449@psf.upfronthosting.co.za> Message-ID: <1391114743.61.0.243559760068.issue20449@psf.upfronthosting.co.za> STINNER Victor added the comment: Patch commited as 73dbb884eb09 in Python 3.4. (No need to backport, it's a new module in Python 3.4). Thanks for the review Richard. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 21:55:41 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 Jan 2014 20:55:41 +0000 Subject: [issue6478] time.tzset does not reset _strptime's locale time cache In-Reply-To: <1247506425.36.0.284798334504.issue6478@psf.upfronthosting.co.za> Message-ID: <1391115341.1.0.276130555217.issue6478@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: May be System Z Linux buildbot fails due to this bug (http://buildbot.python.org/all/builders/System%20Z%20Linux%203.x/builds/1154/steps/test/logs/stdio): ====================================================================== ERROR: test_strptime (test.datetimetester.TestDateTime_Pure) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dje/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/test/datetimetester.py", line 1879, in test_strptime dt = strptime(dtstr, "%z %Z") File "/home/dje/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/datetime.py", line 1593, in strptime return _strptime._strptime_datetime(cls, date_string, format) File "/home/dje/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/_strptime.py", line 500, in _strptime_datetime tt, fraction = _strptime(data_string, format) File "/home/dje/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/_strptime.py", line 337, in _strptime (data_string, format)) ValueError: time data '-0500 EST' does not match format '%z %Z' ---------------------------------------------------------------------- ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 22:39:20 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 Jan 2014 21:39:20 +0000 Subject: [issue19856] shutil.move() can't move a directory in non-empty directory on Windows In-Reply-To: <1385924474.74.0.566817188038.issue19856@psf.upfronthosting.co.za> Message-ID: <1391117960.25.0.526530757711.issue19856@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I suppose this patch should fix a bug on Windows. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file33817/shutil_move_dir_altsep.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 23:02:06 2014 From: report at bugs.python.org (Christopher Welborn) Date: Thu, 30 Jan 2014 22:02:06 +0000 Subject: [issue18916] Various out-of-date Lock text in 3.2+ In-Reply-To: <1378255145.39.0.17069692986.issue18916@psf.upfronthosting.co.za> Message-ID: <1391119326.25.0.744642212811.issue18916@psf.upfronthosting.co.za> Christopher Welborn added the comment: Hello, my name is Chris Welborn (or Cj). I've been looking for opportunities to work on python. I figured a little Doc fix would be perfect for my first patch, as you originally planned. I ran the python unit-tests and `make test`, plus a 'patchcheck'. Even though I really only changed a couple strings, I wanted to be sure. I hope this patch is acceptable, but if it's not I would be glad to tidy it up in whatever way you see fit. Thanks for leaving this for someone like me :) -Cj ---------- keywords: +patch nosy: +cjwelborn Added file: http://bugs.python.org/file33818/threading.lock.docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jan 30 23:26:00 2014 From: report at bugs.python.org (Glenn Langford) Date: Thu, 30 Jan 2014 22:26:00 +0000 Subject: [issue20319] concurrent.futures.wait() can block forever even if Futures have completed In-Reply-To: <1390263519.32.0.357208079457.issue20319@psf.upfronthosting.co.za> Message-ID: <1391120760.67.0.250291382963.issue20319@psf.upfronthosting.co.za> Glenn Langford added the comment: An idea for a different possible fix - rather than cleaning up waiters in wait() and as_completed(), could they be removed in Future.set_result() and Futures.set_exception() ? I'm not certain if any waiter should ever be notified twice; if not, perhaps set_result() and set_exception() could just include self._waiters = [] after all waiters have been signalled. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 00:18:21 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 30 Jan 2014 23:18:21 +0000 Subject: [issue20398] stem crashes python In-Reply-To: <1390749180.01.0.603192717521.issue20398@psf.upfronthosting.co.za> Message-ID: <1391123901.22.0.885971143687.issue20398@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the feedback! Then I suggest you report the issue to the cygwin Python packagers. ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 00:58:38 2014 From: report at bugs.python.org (Chris Angelico) Date: Thu, 30 Jan 2014 23:58:38 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1391126318.88.0.996148646949.issue2292@psf.upfronthosting.co.za> Changes by Chris Angelico : ---------- nosy: +Rosuav _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 02:18:04 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 31 Jan 2014 01:18:04 +0000 Subject: [issue18916] Various out-of-date Lock text in 3.2+ In-Reply-To: <1378255145.39.0.17069692986.issue18916@psf.upfronthosting.co.za> Message-ID: <1391131084.02.0.98739587742.issue18916@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for working on this. The patch looks pretty good. I would prefer to flow the two lines in the Lock docstring as a paragraph, rather than have once sentence per line. Also, the OP mentions that the docs for type(Lock) mention PyThread_allocate_lock...do you want to look at fixing that as well? As mentioned, it should reference Lock() instead. The reference to PyThread_allocate_lock should be moved into comments in the type, IMO. Also, this patch may be affected by the Argument Clinic Derby. I don't know if the threading module is one of the ones that is being converted or not. You can just ignore that issue since the full patch is needed for 3.3, but if you feel like figuring it out, and it is affected, you could produce an additional patch for 3.4. Otherwise whoever applies your patch will figure out how to merge it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 03:17:08 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 31 Jan 2014 02:17:08 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1391134628.78.0.802532856543.issue16991@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 03:17:24 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 31 Jan 2014 02:17:24 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1391134644.89.0.180451738157.issue16991@psf.upfronthosting.co.za> Antoine Pitrou added the comment: It's much too late for such a disruptive change in 3.4. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 04:01:00 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 31 Jan 2014 03:01:00 +0000 Subject: [issue19658] inspect.getsource weird case In-Reply-To: <1384896343.05.0.723899962428.issue19658@psf.upfronthosting.co.za> Message-ID: <1391137260.2.0.443621423228.issue19658@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> committed/rejected superseder: -> inspect.findsource raises undocumented error for code objects with empty filename _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 04:03:02 2014 From: report at bugs.python.org (Christopher Welborn) Date: Fri, 31 Jan 2014 03:03:02 +0000 Subject: [issue18916] Various out-of-date Lock text in 3.2+ In-Reply-To: <1378255145.39.0.17069692986.issue18916@psf.upfronthosting.co.za> Message-ID: <1391137382.79.0.472682971905.issue18916@psf.upfronthosting.co.za> Christopher Welborn added the comment: Yep, I missed the PyThread_allocate_lock reference. As far as the Argument Clinic Derby, I've been following the python-dev list and reading about Argument Clinic, but I don't know enough about it to do the conversion. It's a really good tool from what I can tell. I'll have to study it some more so in the future I can possibly help with the conversions. I see the threading module listed in Issue #20185 (Derby #17), but no patch for it yet. Forgive my newbness, but I omitted putting a reference to PyThread_allocate_lock in the comments because I was confused about what kind of reference you were talking about. Something about making sure Python users see "threading.Lock" instead of "PyThread_allocate_lock", or moving a statement like "to create a lock in C, call the PyThread_allocate_lock function" into the comments. If it's important for it to be there, could you let me know so I can make the edit? Hopefully I have been of some help, instead of just wasting your time. ---------- Added file: http://bugs.python.org/file33819/threading.lock.docs3.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 04:23:00 2014 From: report at bugs.python.org (Christopher Welborn) Date: Fri, 31 Jan 2014 03:23:00 +0000 Subject: [issue18916] Various out-of-date Lock text in 3.2+ In-Reply-To: <1378255145.39.0.17069692986.issue18916@psf.upfronthosting.co.za> Message-ID: <1391138580.08.0.455202888901.issue18916@psf.upfronthosting.co.za> Changes by Christopher Welborn : Removed file: http://bugs.python.org/file33818/threading.lock.docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 04:50:44 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 31 Jan 2014 03:50:44 +0000 Subject: [issue18916] Various out-of-date Lock text in 3.2+ In-Reply-To: <1378255145.39.0.17069692986.issue18916@psf.upfronthosting.co.za> Message-ID: <1391140244.73.0.0365854771341.issue18916@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, the latter: since someone thought it was important to mention, but only people working with the C code would benefit, it ought to be a comment in the C source. If there's no AC patch for threading yet, then there's no problem with that, and your patch will be good for both 3.3 and 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 05:45:40 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 31 Jan 2014 04:45:40 +0000 Subject: [issue20406] Use application icon for IDLE In-Reply-To: <1390817290.68.0.153594821127.issue20406@psf.upfronthosting.co.za> Message-ID: <1391143540.63.0.0582945604777.issue20406@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I see. MS Paint just pulled out one of the 16-pixel images. Photoshop (like Tk) refused to open the file. However, I found the following: iconbitmap = wm_iconbitmap(self, bitmap=None, default=None) Set bitmap for the iconified widget to BITMAP. Return the bitmap if None is given. Under Windows, the DEFAULT parameter can be used to set the icon for the widget and any descendents that don't have an icon set explicitly. DEFAULT can be the relative path to a .ico file (example: root.iconbitmap(default='myicon.ico') ). This works* with default= for Windows and is available in 2.7, while wm_iconphoto is not. I think we should use it for Windows. (I get the impression from the help text that default= only works for Windows, but I cannot test this.) See uploaded 3.4 patch. I plan to apply this before the next release. Someone else will have to add tested elif: clauses for other systems. For X, iconphoto might be better, as it accepts multiple bitmaps (of various sizes) and packages them for X. Images could be extracted from py.ico for this purpose. Or maybe just the 32-bit 32 pixel image in py.ico, save as the best quality .gif, would be enough. Iconphoto help says it does not work for Macs; the iconbitmap help says nothing, so maybe it does. * The title icon I see is better than than the 16 pixel gif extracted from py.ico, so I presume it is downsized from a 32 pixel version. Unlike any .gif, transparency is handled correctly. However, Tk somehow distorts the colors and it is much darker than the same-size Start menu icon. For the white page part, I like the darker outline and page holes.better. For the two snakes, it is much worse. The bright yellow-orange snake is instead a dull brownish orange and not properly recognizable as the Python snake. I renamed py.ico to idle.ico so someone could edit the colors to look better when run through Tk without having to rename the file and change the code later. (I would want to rename after editing so no one would think it identical to PC/py.ico.) But I do not think a commit should wait on an image edit. ---------- stage: patch review -> commit review Added file: http://bugs.python.org/file33820/20406-34.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 08:20:39 2014 From: report at bugs.python.org (Florian Bruhin) Date: Fri, 31 Jan 2014 07:20:39 +0000 Subject: [issue20451] os.exec* mangles argv on windows (splits on spaces, etc) Message-ID: <1391152839.26.0.437112268275.issue20451@psf.upfronthosting.co.za> New submission from Florian Bruhin: The os.exec* functions seem to mangle arguments on Windows. So far I noticed the supplied argv gets split on spaces, and double-quotes get stripped when not escaped. Example, on Windows 7: >>> platform.platform() 'Windows-7-6.1.7601-SP1' >>> os.execlp('python', 'python', '-c', "sys=__import__('sys');print(sys.argv)", 'Hello World') ['-c', 'Hello', 'World'] Same on Archlinux: ['-c', 'Hello World'] as expected. Both running Python 3.3.3. ---------- components: Library (Lib), Windows messages: 209748 nosy: The Compiler priority: normal severity: normal status: open title: os.exec* mangles argv on windows (splits on spaces, etc) type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 09:26:30 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 31 Jan 2014 08:26:30 +0000 Subject: [issue20452] test_timeout_rounding() of test_asyncio fails on "x86 Ubuntu Shared 3.x" buildbot Message-ID: <1391156790.09.0.38396612237.issue20452@psf.upfronthosting.co.za> New submission from STINNER Victor: The failure is minor, it's just a suboptimal code. Calling _run_once() 4 times instead of 3. http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/9630/steps/test/logs/stdio ====================================================================== FAIL: test_timeout_rounding (test.test_asyncio.test_events.EPollEventLoopTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_asyncio/test_events.py", line 1180, in test_timeout_rounding self.assertEqual(calls, [1, 3, 5, 6]) AssertionError: Lists differ: [1, 4, 6, 7] != [1, 3, 5, 6] First differing element 1: 4 3 - [1, 4, 6, 7] + [1, 3, 5, 6] I'm unable to reproduce the error on my Linux box. When we had the rounding away from zero in epoll directly, the epoll test failed on the same buildbot: http://bugs.python.org/issue20311#msg208601 http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.3/builds/1360/steps/test/logs/stdio ====================================================================== FAIL: test_timeout_rounding (test.test_epoll.TestEPoll) ---------------------------------------------------------------------- Traceback (most recent call last): File "/srv/buildbot/buildarea/3.3.bolen-ubuntu/build/Lib/test/test_epoll.py", line 58, in test_timeout_rounding self.assertGreaterEqual(dt, timeout) AssertionError: 0.009388947859406471 not greater than or equal to 0.01 ---------- components: Tests messages: 209749 nosy: gvanrossum, haypo priority: normal severity: normal status: open title: test_timeout_rounding() of test_asyncio fails on "x86 Ubuntu Shared 3.x" buildbot versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 09:32:19 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 31 Jan 2014 08:32:19 +0000 Subject: [issue20451] os.exec* mangles argv on windows (splits on spaces, etc) In-Reply-To: <1391152839.26.0.437112268275.issue20451@psf.upfronthosting.co.za> Message-ID: <1391157139.63.0.303113723573.issue20451@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 09:37:35 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 31 Jan 2014 08:37:35 +0000 Subject: [issue20452] test_timeout_rounding() of test_asyncio fails on "x86 Ubuntu Shared 3.x" buildbot In-Reply-To: <1391156790.09.0.38396612237.issue20452@psf.upfronthosting.co.za> Message-ID: <3fFsHy552cz7LjQ@mail.python.org> Roundup Robot added the comment: New changeset 5545634d98a1 by Victor Stinner in branch 'default': Issue #20452: add more info in case of test_asyncio failure to try to debug the http://hg.python.org/cpython/rev/5545634d98a1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 09:49:34 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 31 Jan 2014 08:49:34 +0000 Subject: [issue20452] test_timeout_rounding() of test_asyncio fails on "x86 Ubuntu Shared 3.x" buildbot In-Reply-To: <1391156790.09.0.38396612237.issue20452@psf.upfronthosting.co.za> Message-ID: <1391158174.45.0.949451536816.issue20452@psf.upfronthosting.co.za> STINNER Victor added the comment: _run_once() can be called more than expected if selector.select() was interrupted by a signal or because the granularity is wrong. If we want to avoid that, a simple fix is just to loop again in this case. Attached patch implements that (I wrote it for Tulip, it cannot applied cleanly on Python because I added debug code to investigate this issue). The patch should also fix the sporadic issue of signal interrupting _run_once(). The unit test should not be interrupted by a signal, but it can occur on a real application. For example when your resize a terminal. ---------- keywords: +patch Added file: http://bugs.python.org/file33821/loop_run_once.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 09:54:59 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 31 Jan 2014 08:54:59 +0000 Subject: [issue20406] Use application icon for IDLE In-Reply-To: <1390817290.68.0.153594821127.issue20406@psf.upfronthosting.co.za> Message-ID: <1391158499.89.0.741666078504.issue20406@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, the default option of wm_iconbitmap works only on Windows. Does wm_iconbitmap affect taskbar icon and icon used in task switching? Here is a patch which supports also X11 systems. I'm nor sure about Mac. ---------- Added file: http://bugs.python.org/file33822/idle_appicon_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 09:56:42 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 31 Jan 2014 08:56:42 +0000 Subject: [issue20406] Use application icon for IDLE In-Reply-To: <1390817290.68.0.153594821127.issue20406@psf.upfronthosting.co.za> Message-ID: <1391158602.56.0.259067738721.issue20406@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file33822/idle_appicon_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 09:58:04 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 31 Jan 2014 08:58:04 +0000 Subject: [issue20406] Use application icon for IDLE In-Reply-To: <1390817290.68.0.153594821127.issue20406@psf.upfronthosting.co.za> Message-ID: <1391158684.81.0.405107065951.issue20406@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file33823/idle_appicon_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 10:54:24 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 31 Jan 2014 09:54:24 +0000 Subject: [issue20406] Use application icon for IDLE In-Reply-To: <1390817290.68.0.153594821127.issue20406@psf.upfronthosting.co.za> Message-ID: <1391162064.77.0.112640322134.issue20406@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Yes, 'works' means displayed for title bar and task switching. Related but separate issue. A TreeWidget used for browsing files uses the old python.gif icon for .py files. I think we should switch to the modern one that you uploaded as python_16x16.gif. Agree? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 10:58:49 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 31 Jan 2014 09:58:49 +0000 Subject: [issue20452] test_timeout_rounding() of test_asyncio fails on "x86 Ubuntu Shared 3.x" buildbot In-Reply-To: <1391156790.09.0.38396612237.issue20452@psf.upfronthosting.co.za> Message-ID: <3fFv5h5mdkz7LjW@mail.python.org> Roundup Robot added the comment: New changeset 83e110399f3c by Victor Stinner in branch 'default': Issue #20452: Oops, fix debug code :-/ http://hg.python.org/cpython/rev/83e110399f3c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 11:08:52 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 31 Jan 2014 10:08:52 +0000 Subject: [issue20453] json.load() error message changed in 3.4 Message-ID: <1391162931.99.0.108127691347.issue20453@psf.upfronthosting.co.za> New submission from Barry A. Warsaw: Run the attached file under Python 3.3 and you get: No JSON object could be decoded Run the same file under Python 3.4 and you get: Expecting value: line 1 column 1 (char 0) So a couple of things: Since the error message changed, it makes it difficult to test in doctest and other text-based matches. I'm also not sure the new message is "better". Objectively speaking, probably both error messages are useful (i.e. that no json object was found, and where the problem was found). I think the second message by itself is pretty mysterious. I want to make sure the change was deliberate. I couldn't find anything in Misc/NEWS which might not be entirely unexpected since specific error messages aren't generally a part of the guaranteed API. Perhaps at the least, if the change was deliberate, let's document it in Misc/NEWS. ---------- files: foo.py messages: 209755 nosy: barry priority: normal severity: normal status: open title: json.load() error message changed in 3.4 versions: Python 3.4 Added file: http://bugs.python.org/file33824/foo.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 11:09:39 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 31 Jan 2014 10:09:39 +0000 Subject: [issue20406] Use application icon for IDLE In-Reply-To: <1391162064.77.0.112640322134.issue20406@psf.upfronthosting.co.za> Message-ID: <9466252.8KEHSjf58K@raxxla> Serhiy Storchaka added the comment: > Related but separate issue. A TreeWidget used for browsing files uses the > old python.gif icon for .py files. I think we should switch to the modern > one that you uploaded as python_16x16.gif. Agree? Agree. As for 2.7, we can use root.tk.call('wm', 'iconphoto', str(root), "-default", *icons) In Ubuntu (and perhaps other Linux distributives), just main Python logo (as in favicon) is used as IDLE desktop icon. May be we should discuss IDLE icon and logo (which can be shown in the About window) on Python-Dev. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 11:25:03 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 31 Jan 2014 10:25:03 +0000 Subject: [issue20452] test_timeout_rounding() of test_asyncio fails on "x86 Ubuntu Shared 3.x" buildbot In-Reply-To: <1391156790.09.0.38396612237.issue20452@psf.upfronthosting.co.za> Message-ID: <1391163903.22.0.971212919758.issue20452@psf.upfronthosting.co.za> STINNER Victor added the comment: It looks like select() and poll() in Linux < 2.6.28 has a resolution of 1/HZ, where HZ can be retrieved from os.sysconf('SC_CLK_TCK'). Since Linux 2.6.28, hrtimers are now used for timeouts. "High- (but not too high-) resolution timeouts" http://lwn.net/Articles/296578/ "What's in hrtimer.git for 2.6.28" https://lkml.org/lkml/2008/9/20/136 Attached patch improves the resolution field of selectors.BaseSelector. By the way, resolution should be a method (selector.resolution()) rather than a property, because we may query the kernel to compute the resolution, as shown in the patch. ---------- Added file: http://bugs.python.org/file33825/selector_resolution.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 11:30:58 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 31 Jan 2014 10:30:58 +0000 Subject: [issue20452] test_timeout_rounding() of test_asyncio fails on "x86 Ubuntu Shared 3.x" buildbot In-Reply-To: <1391156790.09.0.38396612237.issue20452@psf.upfronthosting.co.za> Message-ID: <1391164258.53.0.963351448814.issue20452@psf.upfronthosting.co.za> STINNER Victor added the comment: Platform of "x86 Ubuntu Shared 3.x" buildbot: "Linux-2.6.31.5-linode21-i686-with-debian-lenny-sid little-endian", so a Linux kernel 2.6.31. It looks common on this buildbot that selector.select(timeout) takes less timeout seconds (without returning any event). "dt+granularity > timeout" test is False and so _run_once() does nothing, a new call is required. Debug output of test_asyncio on "x86 Ubuntu Shared 3.x" (build 9632, test_asyncio passed): --- [ 75/389] test_asyncio WARNING: selector.select(timeout=0.09994344785809516907) took dt=0.09897190984338521957 sec (dt-timeout=-0.00097153801470994949) WARNING: dt+0.00100000000000000002 > timeout? True WARNING: selector.select(timeout=0.09991932008415460587) took dt=0.09855401515960693359 sec (dt-timeout=-0.00136530492454767227) WARNING: dt+0.00100000000000000002 > timeout? False WARNING: selector.select(timeout=0.00097305513918399811) took dt=0.00002539902925491333 sec (dt-timeout=-0.00094765610992908478) WARNING: dt+0.00100000000000000002 > timeout? True WARNING: selector.select(timeout=0.49995081406086683273) took dt=0.10032826289534568787 sec (dt-timeout=-0.39962255116552114487) WARNING: dt+0.00100000000000000002 > timeout? False WARNING: selector.select(timeout=0.39888287801295518875) took dt=0.39831575006246566772 sec (dt-timeout=-0.00056712795048952103) WARNING: dt+0.00100000000000000002 > timeout? True WARNING: selector.select(timeout=None) took dt=0.01029967889189720154 sec WARNING: selector.select(timeout=None) took dt=0.07110145408660173416 sec WARNING: selector.select(timeout=None) took dt=0.00214391853660345078 sec WARNING: selector.select(timeout=None) took dt=0.00361407827585935593 sec WARNING: selector.select(timeout=0.00991696026176214218) took dt=0.00975166168063879013 sec (dt-timeout=-0.00016529858112335205) WARNING: dt+0.00100000000000000002 > timeout? True WARNING: selector.select(timeout=0.49995493795722723007) took dt=0.10188415739685297012 sec (dt-timeout=-0.39807078056037425995) WARNING: dt+0.00100000000000000002 > timeout? False WARNING: selector.select(timeout=None) took dt=0.01038167160004377365 sec WARNING: selector.select(timeout=None) took dt=0.00922694429755210876 sec WARNING: selector.select(timeout=None) took dt=0.00215751212090253830 sec WARNING: selector.select(timeout=None) took dt=0.01459381356835365295 sec WARNING: selector.select(timeout=0.49995700363069772720) took dt=0.10038192663341760635 sec (dt-timeout=-0.39957507699728012085) WARNING: dt+0.00000100000000000000 > timeout? False WARNING: selector.select(timeout=None) took dt=0.01037232112139463425 sec WARNING: selector.select(timeout=None) took dt=0.00168939027935266495 sec WARNING: selector.select(timeout=None) took dt=0.00139459036290645599 sec WARNING: selector.select(timeout=None) took dt=0.00180943403393030167 sec WARNING: selector.select(timeout=None) took dt=0.00000000000000000000 sec WARNING: selector.select(timeout=None) took dt=0.00000000000000000000 sec WARNING: selector.select(timeout=None) took dt=0.00000000000000000000 sec WARNING: selector.select(timeout=None) took dt=0.00000000000000000000 sec WARNING: selector.select(timeout=None) took dt=0.00000000000000000000 sec WARNING: selector.select(timeout=None) took dt=0.00000000000000000000 sec WARNING: selector.select(timeout=None) took dt=0.00000000000000000000 sec WARNING: selector.select(timeout=None) took dt=0.00000000000000000000 sec WARNING: selector.select(timeout=None) took dt=0.00000000000000000000 sec --- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 11:32:19 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 31 Jan 2014 10:32:19 +0000 Subject: [issue20453] json.load() error message changed in 3.4 In-Reply-To: <1391162931.99.0.108127691347.issue20453@psf.upfronthosting.co.za> Message-ID: <1391164339.5.0.525108114891.issue20453@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, the change is deliberate (issue16009). ---------- nosy: +ezio.melotti, pitrou, rhettinger, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 11:36:31 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 31 Jan 2014 10:36:31 +0000 Subject: [issue20452] test_timeout_rounding() of test_asyncio fails on "x86 Ubuntu Shared 3.x" buildbot In-Reply-To: <1391156790.09.0.38396612237.issue20452@psf.upfronthosting.co.za> Message-ID: <1391164591.3.0.530227157249.issue20452@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: > It looks like select() and poll() in Linux < 2.6.28 has a resolution > of 1/HZ, where HZ can be retrieved from os.sysconf('SC_CLK_TCK'). Since > Linux 2.6.28, hrtimers are now used for timeouts. > Attached patch improves the resolution field of selectors.BaseSelector. > By the way, resolution should be a method (selector.resolution()) > rather than a property, because we may query the kernel to compute the > resolution, as shown in the patch. That's exactly why I said that an explicit resolution is a bad idea: - it's an implementation detail - it's fragile (just look at your latest patch) - it's useless Just round the timeout away from 0 and be happy: this will fix the busy-wait problem, and that's all we want. Once again, I know I keep repeating myself, but having select/epoll/whatever wake up 10usec before the timeout isn't an issue: *all* async-IO frameworks out there work just fine with this. So please, revert all this granuarity complexity, and re-apply the timeout rounding. ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 11:43:52 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 31 Jan 2014 10:43:52 +0000 Subject: [issue20453] json.load() error message changed in 3.4 In-Reply-To: <1391162931.99.0.108127691347.issue20453@psf.upfronthosting.co.za> Message-ID: <1391165032.73.0.548136189801.issue20453@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: What do you think of combining the error messages, e.g. No JSON object could be decoded, expecting value: line 1 column 1 (char 0) ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 11:45:17 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 31 Jan 2014 10:45:17 +0000 Subject: [issue20452] test_timeout_rounding() of test_asyncio fails on "x86 Ubuntu Shared 3.x" buildbot In-Reply-To: <1391156790.09.0.38396612237.issue20452@psf.upfronthosting.co.za> Message-ID: <1391165116.99.0.585988897251.issue20452@psf.upfronthosting.co.za> STINNER Victor added the comment: > Just round the timeout away from 0 and be happy: this will fix the busy-wait problem, and that's all we want. I didn't work, see: http://bugs.python.org/issue20311#msg208601 > Once again, I know I keep repeating myself, but having select/epoll/whatever wake up 10usec before the timeout isn't an issue: *all* async-IO frameworks out there work just fine with this. The previous issue #20311 and this one are not critical bug, just performance issues. I would prefer to not call _run_once() and epoll_wait() too many times if it's useless (if it can be avoided). > So please, revert all this granuarity complexity, and re-apply the timeout rounding. *If* we come back to the rounding aways zero option and granularity is removed from asyncio.BaseEventLoop, the issue should also be fixed in the IOCP selector used by the proactor event loop in Python. -- If we decide that it's not an issue that _run_once() is called too many times, the unit test can be changed to ensure that _run_once() is called less than 10 times, instead of expecting an exact number of calls (7 at the end): so tolerate 3 useless calls. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 11:56:00 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 31 Jan 2014 10:56:00 +0000 Subject: [issue20452] test_timeout_rounding() of test_asyncio fails on "x86 Ubuntu Shared 3.x" buildbot In-Reply-To: <1391156790.09.0.38396612237.issue20452@psf.upfronthosting.co.za> Message-ID: <1391165760.21.0.860247372116.issue20452@psf.upfronthosting.co.za> STINNER Victor added the comment: More debug info on a new failure: test_timeout_rounding failed because once EPollSelector.select(timeout=0.0099) took dt=0.0086 seconds. dt-timeout=-0.0014 and dt+granularity > timeout is False (granularity=0.001, 1 millisecond). * Buildbot: "x86 Gentoo Non-Debug 3.x" * Linux kernel 2.6.35 (i686) * clock_getres(CLOCK_MONOTONIC) = 1e-9 (1 nanosecond) * os.sysconf('SC_CLK_TCK') = 100 (1/HZ => 10 ms ?) http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/6121/steps/test/logs/stdio Re-running test 'test_asyncio' in verbose mode test_call_later (test.test_asyncio.test_events.EPollEventLoopTests) ... WARNING: selector.select(timeout=0.09998385910876095295) took dt=0.09878822183236479759 sec (dt-timeout=-0.00119563727639615536) WARNING: dt+0.00100000000000000002 > timeout? False WARNING: selector.select(timeout=0.00106247211806476116) took dt=0.00085310707800090313 sec (dt-timeout=-0.00020936504006385803) WARNING: dt+0.00100000000000000002 > timeout? True ok test_run_until_complete (test.test_asyncio.test_events.EPollEventLoopTests) ... WARNING: selector.select(timeout=0.09997870912775397301) took dt=0.09859465109184384346 sec (dt-timeout=-0.00138405803591012955) WARNING: dt+0.00100000000000000002 > timeout? False WARNING: selector.select(timeout=0.00126257794909179211) took dt=0.00086452695541083813 sec (dt-timeout=-0.00039805099368095398) WARNING: dt+0.00100000000000000002 > timeout? True ok test_signal_handling_args (test.test_asyncio.test_events.EPollEventLoopTests) ... WARNING: selector.select(timeout=0.49998698616400361061) took dt=0.10008734907023608685 sec (dt-timeout=-0.39989963709376752377) WARNING: dt+0.00100000000000000002 > timeout? False WARNING: selector.select(timeout=0.39968195999972522259) took dt=0.39848947990685701370 sec (dt-timeout=-0.00119248009286820889) WARNING: dt+0.00100000000000000002 > timeout? False WARNING: selector.select(timeout=0.00107327196747064590) took dt=0.00087298289872705936 sec (dt-timeout=-0.00020028906874358654) WARNING: dt+0.00100000000000000002 > timeout? True ok test_signal_handling_while_selecting (test.test_asyncio.test_events.EPollEventLoopTests) ... WARNING: selector.select(timeout=None) took dt=0.01009305310435593128 sec ok test_subprocess_close_after_finish (test.test_asyncio.test_events.EPollEventLoopTests) ... WARNING: selector.select(timeout=None) took dt=0.00544960913248360157 sec ok test_timeout_rounding (test.test_asyncio.test_events.EPollEventLoopTests) ... WARNING: selector.select(timeout=0.00997558492235839367) took dt=0.00856216903775930405 sec (dt-timeout=-0.00141341588459908962) WARNING: dt+0.00100000000000000002 > timeout? False WARNING: selector.select(timeout=0.00129276583902537823) took dt=0.00085931317880749702 sec (dt-timeout=-0.00043345266021788120) WARNING: dt+0.00100000000000000002 > timeout? True WARNING: selector.select(timeout=0.00007506809197366238) took dt=0.00000555603764951229 sec (dt-timeout=-0.00006951205432415009) WARNING: dt+0.00100000000000000002 > timeout? True FAIL test_signal_handling_args (test.test_asyncio.test_events.PollEventLoopTests) ... WARNING: selector.select(timeout=0.49998601293191313744) took dt=0.10008832695893943310 sec (dt-timeout=-0.39989768597297370434) WARNING: dt+0.00100000000000000002 > timeout? False ok (...) ====================================================================== FAIL: test_timeout_rounding (test.test_asyncio.test_events.EPollEventLoopTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/test_asyncio/test_events.py", line 1195, in test_timeout_rounding platform.platform())) AssertionError: Lists differ: [1, 4, 6, 7] != [1, 3, 5, 6] First differing element 1: 4 3 - [1, 4, 6, 7] + [1, 3, 5, 6] : (0.001, 0.001, namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09), 100, 'Linux-2.6.35-vs2.3.0.36.32-gentoo-i686-Intel-R-_Core-TM-2_CPU_6600_ at _2.40GHz-with-gentoo-2.1') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 12:02:45 2014 From: report at bugs.python.org (Francis Moreau) Date: Fri, 31 Jan 2014 11:02:45 +0000 Subject: [issue20454] platform.linux_distribution() returns empty value on Archlinux and python 2.7 Message-ID: <1391166165.52.0.4413803514.issue20454@psf.upfronthosting.co.za> New submission from Francis Moreau: On Archlinux: $ python2.7 -c 'import platform; print(platform.linux_distribution())' ('', '', '') This is because Archlinux is not part of the '_supported_dists' list. Could Archlinux be added to this list ? Thanks. ---------- components: Library (Lib) messages: 209764 nosy: fmoreau, lemburg priority: normal severity: normal status: open title: platform.linux_distribution() returns empty value on Archlinux and python 2.7 versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 12:03:13 2014 From: report at bugs.python.org (Francis Moreau) Date: Fri, 31 Jan 2014 11:03:13 +0000 Subject: [issue20454] platform.linux_distribution() returns empty value on Archlinux and python 2.7 In-Reply-To: <1391166165.52.0.4413803514.issue20454@psf.upfronthosting.co.za> Message-ID: <1391166193.34.0.566870155561.issue20454@psf.upfronthosting.co.za> Changes by Francis Moreau : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 12:07:09 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 31 Jan 2014 11:07:09 +0000 Subject: [issue20231] Argument Clinic accepts no-default args after default args In-Reply-To: <1389580315.91.0.810075963733.issue20231@psf.upfronthosting.co.za> Message-ID: <1391166429.33.0.561607245506.issue20231@psf.upfronthosting.co.za> Larry Hastings added the comment: Yup! ---------- assignee: -> larry resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 12:11:18 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 31 Jan 2014 11:11:18 +0000 Subject: [issue20349] Argument Clinic: error on __new__ or __init__ with no arguments In-Reply-To: <1390408922.24.0.609938123562.issue20349@psf.upfronthosting.co.za> Message-ID: <1391166678.16.0.11018354454.issue20349@psf.upfronthosting.co.za> Larry Hastings added the comment: parser_body_fields is initialized to () these days, which should make this problem go away. Do you still have the issue in current trunk? Again, if you'd attached a reproducable test case, I could have independently verified the problem, and that it was fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 12:19:24 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 31 Jan 2014 11:19:24 +0000 Subject: [issue20452] test_timeout_rounding() of test_asyncio fails on "x86 Ubuntu Shared 3.x" buildbot In-Reply-To: <1391156790.09.0.38396612237.issue20452@psf.upfronthosting.co.za> Message-ID: <3fFwtg5856zNhG@mail.python.org> Roundup Robot added the comment: New changeset 827d948ac6aa by Victor Stinner in branch 'default': Issue #20452: select and selectors round (again) timeout away from zero for http://hg.python.org/cpython/rev/827d948ac6aa ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 12:26:28 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 31 Jan 2014 11:26:28 +0000 Subject: [issue20452] test_timeout_rounding() of test_asyncio fails on "x86 Ubuntu Shared 3.x" buildbot In-Reply-To: <1391156790.09.0.38396612237.issue20452@psf.upfronthosting.co.za> Message-ID: <1391167588.36.0.148748716536.issue20452@psf.upfronthosting.co.za> STINNER Victor added the comment: > New changeset 827d948ac6aa by Victor Stinner in branch 'default': > Issue #20452: select and selectors round (again) timeout away from zero Let's test Charles-Francois option. > test_timeout_rounding failed because once EPollSelector.select(timeout=0.0099) took dt=0.0086 seconds We asked to wait 9.9 ms, which was rounding to 9 ms. But epoll_wait() took 8.6 seconds: 8.6 is smaller than 9 ms. In my opinion, rounding away from zero is not enough. We should probably round away from zero for selectors *and* compare times using the granularity. Let's see what buildbots say :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 12:41:26 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 31 Jan 2014 11:41:26 +0000 Subject: [issue17162] Py_LIMITED_API needs a PyType_GenericDealloc In-Reply-To: <1360348035.19.0.130949262051.issue17162@psf.upfronthosting.co.za> Message-ID: <1391168486.65.0.10873801381.issue17162@psf.upfronthosting.co.za> Martin v. L?wis added the comment: It's certainly possible to write a "proper" dealloc - just call PyObject_Del directly. This is correct if the type isn't subclassable, and works if it actually isn't subclassed, or if the subclass object can also be released through PyObject_Del. That this has *nobody* noticed yet isn't the case - the OP certainly noticed a year ago. Else, the limited API isn't in wide use yet, probably partly because it is too limited still for certain extension modules (but it is by design that it is limited at all, so that code might require active porting to use it, and may not be portable at all in certain cases). If the typical use case is PyTYPE(self)->tp_free, then the type ought to be a heap type, so limiting the implementation to heap types should be sufficient. It would be feasible to extend it to non-heaptypes, although I do wonder what use case this would allow for. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 12:49:32 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 31 Jan 2014 11:49:32 +0000 Subject: [issue17162] Py_LIMITED_API needs a PyType_GenericDealloc In-Reply-To: <1360348035.19.0.130949262051.issue17162@psf.upfronthosting.co.za> Message-ID: <1391168972.01.0.919110466169.issue17162@psf.upfronthosting.co.za> Larry Hastings added the comment: I was thinking of a subclass of an existing class, both implemented in C. collections.Counter does that, but it uses _PyType_LookupId() which is in the limited API. Would it be possible to achieve equivalent functionality by using _PyType_LookupId()? If so, maybe instead of the proposed new function PyType_GetSlot, we should make _PyType_Lookup and _PyType_LookupId part of the public API. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 12:49:55 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 31 Jan 2014 11:49:55 +0000 Subject: [issue17162] Py_LIMITED_API needs a PyType_GenericDealloc In-Reply-To: <1360348035.19.0.130949262051.issue17162@psf.upfronthosting.co.za> Message-ID: <1391168995.53.0.94380661853.issue17162@psf.upfronthosting.co.za> Larry Hastings added the comment: (And, I freely admit I don't understand all this that well and that could be a very dumb question.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 12:56:04 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 31 Jan 2014 11:56:04 +0000 Subject: [issue20452] test_timeout_rounding() of test_asyncio fails on "x86 Ubuntu Shared 3.x" buildbot In-Reply-To: <1391156790.09.0.38396612237.issue20452@psf.upfronthosting.co.za> Message-ID: <1391169364.6.0.539559957154.issue20452@psf.upfronthosting.co.za> STINNER Victor added the comment: Results on "x86 Gentoo 3.x" buildbot: [136/389] test_asyncio WARNING: selector.select(timeout=0.09997069113887846470) took dt=0.09961039200425148010 sec (dt-timeout=-0.00036029913462698460) WARNING: dt+0.00100000000000000002 > timeout? True WARNING: selector.select(timeout=0.09995610709302127361) took dt=0.09992253710515797138 sec (dt-timeout=-0.00003356998786330223) WARNING: dt+0.00100000000000000002 > timeout? True WARNING: selector.select(timeout=0.00994763919152319431) took dt=0.00972709804773330688 sec (dt-timeout=-0.00022054114378988743) WARNING: dt+0.00100000000000000002 > timeout? True Ok, it looks better: waiting 99.9 ms took 99.6 ms and 99.9 ms, and waiting 9.9 ms took 9.7 ms. So as I said, the granularity (of 1 ms) is still needed in asyncio (dt < timeout is sometimes False, but dt+granulary >= timeout is always True). We could round the timeout by adding 2 ms in epoll.poll(), but it would be inefficient: it reduces the accurary of 1 ms, whereas the change would only be needed by asyncio. IMO the granularity rounding is better because it uses also the resolution of the clock, which matters a lot on Windows whereas time.monotonic() has a resolution of 15.6 ms. There are same results on "x86 Gentoo Non-Debug 3.x" and "x86 Ubuntu Shared 3.x" buildbots. -- In test_signal_handling_args, dt+granularity > timeout is still True, because the selector was interrupted by a signal. For this case, loop_run_once.patch avoids a second call to _run_once(), but in fact it doesn't optimize anything (calling _run_once() again is just the same). Calling _run_once() again if selector was interrupted is just fine IMO. Example of interrupted selector: WARNING: selector.select(timeout=0.49998722597956657410) took dt=0.10003586183302104473 sec (dt-timeout=-0.39995136414654552937) WARNING: dt+0.00100000000000000002 > timeout? False -- For time handling on Linux, see also: http://www.python.org/dev/peps/pep-0418/#linux-clocksource ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 13:04:58 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 31 Jan 2014 12:04:58 +0000 Subject: [issue20452] test_timeout_rounding() of test_asyncio fails on "x86 Ubuntu Shared 3.x" buildbot In-Reply-To: <1391156790.09.0.38396612237.issue20452@psf.upfronthosting.co.za> Message-ID: <3fFxvG1Ct5z7LjW@mail.python.org> Roundup Robot added the comment: New changeset 21aa1a224049 by Victor Stinner in branch 'default': Issue #20452: Remove debug code, no more needed http://hg.python.org/cpython/rev/21aa1a224049 New changeset f9a09b40bc17 by Victor Stinner in branch 'default': Issue #20311, #20452: poll and epoll now round the timeout away from zero, http://hg.python.org/cpython/rev/f9a09b40bc17 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 13:04:59 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 31 Jan 2014 12:04:59 +0000 Subject: [issue20311] epoll.poll(timeout) and PollSelector.select(timeout) must round the timeout to the upper bound In-Reply-To: <1390214008.55.0.184258286527.issue20311@psf.upfronthosting.co.za> Message-ID: <3fFxvG6mfjz7LjW@mail.python.org> Roundup Robot added the comment: New changeset f9a09b40bc17 by Victor Stinner in branch 'default': Issue #20311, #20452: poll and epoll now round the timeout away from zero, http://hg.python.org/cpython/rev/f9a09b40bc17 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 13:07:35 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 31 Jan 2014 12:07:35 +0000 Subject: [issue17159] Remove explicit type check from inspect.Signature.from_function() In-Reply-To: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za> Message-ID: <1391170055.54.0.7375041159.issue17159@psf.upfronthosting.co.za> Stefan Behnel added the comment: pretty please? :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 13:16:13 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 31 Jan 2014 12:16:13 +0000 Subject: [issue20452] test_timeout_rounding() of test_asyncio fails on "x86 Ubuntu Shared 3.x" buildbot In-Reply-To: <1391156790.09.0.38396612237.issue20452@psf.upfronthosting.co.za> Message-ID: <1391170573.57.0.978638167658.issue20452@psf.upfronthosting.co.za> STINNER Victor added the comment: Summary of this issue: - test_asyncio was still failing because BaseEventLoop._granularity was not enough to round correctly timeouts, deadlines and times. poll/epoll rounded towards zero, whereas asyncio rounds away from zero. So the maximum difference in _run_once() was 2 x resolution (2 ms), not resolution (1 ms) - I modified poll and epoll in select and selectors modules in Python 3.4 to round the timeout away from zero. So the maximum difference is now resolution (1 ms for poll/epoll). Now the question is: should we backport the rounding changes in select and selectors in Python 3.3? It's not required for asyncio, since Tulip has its backport of selectors.py which has the fix. For avoid any regression, it's safer to leave Python 3.3 unchanged, since nobody complained. It looks like only asyncio is affected by this issue. In fact, I don't think that any large application relies on select for its event loop: C libraries like libev, libevent and libuv are usually preferred. So I prefer to leave Python 3.3 unchanged. Note: I removed my debug mode. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 13:18:53 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 31 Jan 2014 12:18:53 +0000 Subject: [issue20434] Process crashes if not enough memory to import module In-Reply-To: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za> Message-ID: <1391170733.1.0.920698473166.issue20434@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: These are very unusual semantics. The convention in the python api is that functions are refernece-invariant when there are errors. i.e. if a function fails or not does not change the caller's reference passing assumptions. For example, Py_BuildValue("N", myobject); takes care to always steal the reference of myobject, even when Py_BuildValue fails. Thi tehe case of _PyBytes_Resize(), the caller owns the (single) reference to the operand, and owns the reference to it (or a new one) on success. It is highly unusual that the case of failure causes it to no longer own this reference. Python 3 should have taken the opportunity to remove remove this unusual inheritance from _PyString_Resize() ---------- nosy: +kristjan.jonsson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 13:21:48 2014 From: report at bugs.python.org (Jonathan Dowland) Date: Fri, 31 Jan 2014 12:21:48 +0000 Subject: [issue20328] mailbox: In-Reply-To: <1390316884.16.0.778919240064.issue20328@psf.upfronthosting.co.za> Message-ID: <20140131122147.GA13658@bryant.redmars.org> Jonathan Dowland added the comment: Hi David, thanks for replying! On Tue, Jan 21, 2014 at 03:08:04PM +0000, R. David Murray wrote: > Conceptually the problem with this is that if you use the object to > delete the folder, you now have an object with no folder...that is, an > invalid object. You're absolutely right, and it turns out that this library already has this problem, because the mailbox.Maildir class has a remove_folder method, which can delete nested Maildirs. The following python code is enough to expose this problem: > import mailbox, os > > # create foo/{cur,new,tmp,.bar{,/{cur,new,tmp}}} > for d in "foo foo/.bar".split(): > os.mkdir(d) > for d2 in "cur new tmp".split(): > os.mkdir(os.path.join(d,d2)) > > mb1 = mailbox.Maildir("foo") > mb2 = mb1.get_folder("bar") > mb1.remove_folder("bar") > print mb2.items() Of course, if someone is using this module in any real environment where folders might come and go due to other processes (e.g. an IMAPd - quite a realistic prospect if you ask me), any mailbox.* object could become invalid at any time. Note that mailbox class has a 'lock/unlock' method, but this is a no-op for mailbox.Maildir. > Do we have any other stdlib examples of objects with a 'delete()' > method...looks like bdb has a deleteMe on breakpoint objects, but it > isn't clear that it tries to deal with what happens if a breakpoint > object that has been deleted is accessed again. There are also some > in idlelib/tk, which I haven't looked at. That's a very good question. I don't know, I will have to do some research. I wonder if it's worth looking outside of the python ecosystem too. > So, I guess the issue is to work out what the semantics of the object > would be if delete has been called, and make sure it actually makes > sense to have a delete method. Yes. My gut feeling is the module needs to gracefully handle situations where objects are not valid anymore, to allow inter-operation with other processes deleting or creating mailboxes outside of Python's control, but I suppose the first step is the research. If the consensus is that delete doesn't make sense, I think we need to address the existing delete_folder methods. Thanks for your interest, ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 13:35:00 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 31 Jan 2014 12:35:00 +0000 Subject: [issue20328] mailbox: In-Reply-To: <1390304458.71.0.378928457479.issue20328@psf.upfronthosting.co.za> Message-ID: <1391171700.02.0.189980582757.issue20328@psf.upfronthosting.co.za> Larry Hastings added the comment: Could you give this issue a more descriptive name please? ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 13:35:04 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 31 Jan 2014 12:35:04 +0000 Subject: [issue20328] mailbox: In-Reply-To: <1390304458.71.0.378928457479.issue20328@psf.upfronthosting.co.za> Message-ID: <1391171704.91.0.246665991907.issue20328@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- nosy: -larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 14:00:05 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 31 Jan 2014 13:00:05 +0000 Subject: [issue20434] Process crashes if not enough memory to import module In-Reply-To: <1391170733.1.0.920698473166.issue20434@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Python 3 should have taken the opportunity to remove remove this unusual inheritance from _PyString_Resize() It's not so unusual. PyUnicode_InternInPlace() replaces also a pointer to a object in the caller for example. There are many other functions taking PyObject** parameters: PyUnicode_Append(), PyDict_Next(), PyEval_EvalCodeEx(), PyErr_Fetch(), etc. Anyway, it's too late to change such major API, so it's not very useful the discuss this theorical change :-) And the function is well documented: http://docs.python.org/dev/c-api/bytes.html#_PyBytes_Resize "If the reallocation fails, the original bytes object at *bytes is deallocated, *bytes is set to NULL, a memory exception is set, and -1 is returned." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 14:00:59 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 31 Jan 2014 13:00:59 +0000 Subject: [issue20452] test_timeout_rounding() of test_asyncio fails on "x86 Ubuntu Shared 3.x" buildbot In-Reply-To: <1391156790.09.0.38396612237.issue20452@psf.upfronthosting.co.za> Message-ID: <1391173259.83.0.940026577333.issue20452@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, another question: should I reopen the issue #20320 (round timeout in select and kqueue)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 14:06:13 2014 From: report at bugs.python.org (Tal Einat) Date: Fri, 31 Jan 2014 13:06:13 +0000 Subject: [issue20349] Argument Clinic: error on __new__ or __init__ with no arguments In-Reply-To: <1390408922.24.0.609938123562.issue20349@psf.upfronthosting.co.za> Message-ID: <1391173573.79.0.473628341989.issue20349@psf.upfronthosting.co.za> Tal Einat added the comment: This has indeed been fixed by the change you mentioned. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 14:15:00 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 31 Jan 2014 13:15:00 +0000 Subject: [issue20455] test_asyncio hangs on Windows Message-ID: <1391174100.63.0.591447461885.issue20455@psf.upfronthosting.co.za> New submission from STINNER Victor: It's probably a regression caused by my changeset 73dbb884eb09 which fixed a bug (issue #20449). Related Tulip issue: http://code.google.com/p/tulip/issues/detail?id=121 ---------- messages: 209783 nosy: gvanrossum, haypo, sbt priority: normal severity: normal status: open title: test_asyncio hangs on Windows versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 14:18:32 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 31 Jan 2014 13:18:32 +0000 Subject: [issue20456] Argument Clinic rollup patch, 2014/01/31 Message-ID: <1391174310.68.0.164884497366.issue20456@psf.upfronthosting.co.za> New submission from Larry Hastings: Probably the last rollup patch for a while; I need to move on to code reviewing. Here's a list of changes in this patch: * I added the oft-requested "rename the C variable for a parameter" functionality. That works as follows: os.rename path as stinky: path_t Here the Python name is "path", and the C name is "stinky". Internally the "name" of the parameter is the Python name, and the "name" of the converter is the C name. (But the converter gets the Python name too, because it needs it sometimes, e.g. for the keywords array.) * Fixed a minor but difficult-to-fix problem: when cloning a function, the cloned function would still refer to the original function's name. (You can see this in the PATH_T_INITIALIZE macros in os_replace in posixmodule.c.) * While fixing the above I stumbled over a new problem: rendering often changes internal state of a parameter, which could cause problems if we clone an already-rendered parameter object. The solution: make a copy of all the Parameter objects before rendering, then render from the copies. * Fixing the above forced me to add a new initalizer to CConverter objects: pre_render(), which is called just before rendering. * This change also means it's pretty important to call up to the super() for converter_init() and pre_render(). * Fixing the above also required new semantics for converter_init(): you are no longer permitted to examine the function object in that method. (I made it fail noisily with a "LandMine".) * "clinic.py --converters" was broken, I fixed it. (It was confused by object_converter having format_unit=None.) * I fixed the unit tests too. * You can now specify blank lines between directives without Clinic getting angry at you. * I redid how I store all those little C code snippet template. Originally they were inline, but flush left, and that made reading them tiresome--the indent was jumping around on you. Changing to a central list removed the jumping around but now you had to scroll back and forth to correlate the template with where it was used. The final solution: have them inline again, but indented, and simply outdent the text before use. Go ahead, tell me that's *not* an improvement. :D (The outdenting function uses functools.lru_cache, so processing is really no slower.) And last but certainly not least...! Following a suggestion by Serhiy Storchaka, Argument Clinic is now incredibly sophisticated with respect to #if'd out code. In less than 200 lines, I wrote a reasonable C preprocessor monitor class. The monitor parses C files in parallel to Argument Clinic. At any time you can ask the monitor "what's the current preprocessor conditional state?" If the current code is potentially if'd out, Argument Clinic uses the same conditional to potentially #if out the parser function, the docstring, etc, when writing those to buffer or file. It even adds this to the end: #ifndef YOUR_FUNCTION_METHODDEF #define YOUR_FUNCTION_METHODDEF #endif /* !defined(YOUR_FUNCTION_METHODDEF) */ But *only* when necessary. You can see this in action in the diff for Modules/clinic/zlibmodule.c.h. I think this is a huge improvement! (Thanks for the suggestion, Serhiy!) ---------- assignee: larry files: larry.clinic.rollup.2014.01.31.1.diff keywords: patch messages: 209784 nosy: larry, ncoghlan, serhiy.storchaka, taleinat, zach.ware priority: normal severity: normal stage: patch review status: open title: Argument Clinic rollup patch, 2014/01/31 type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file33826/larry.clinic.rollup.2014.01.31.1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 14:18:54 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 31 Jan 2014 13:18:54 +0000 Subject: [issue20455] test_asyncio hangs on Windows In-Reply-To: <1391174100.63.0.591447461885.issue20455@psf.upfronthosting.co.za> Message-ID: <3fFzXZ0Xz7z7LjQ@mail.python.org> Roundup Robot added the comment: New changeset 4c496d53b1e1 by Victor Stinner in branch 'default': Issue #20455: asyncio: write a new write pipe transport class for proactor (on http://hg.python.org/cpython/rev/4c496d53b1e1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 14:19:55 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 31 Jan 2014 13:19:55 +0000 Subject: [issue20455] test_asyncio hangs on Windows In-Reply-To: <1391174100.63.0.591447461885.issue20455@psf.upfronthosting.co.za> Message-ID: <1391174395.45.0.928763191473.issue20455@psf.upfronthosting.co.za> STINNER Victor added the comment: I commited my patch before a review (even if Guido already wrote me that the approach is correct) because I wanted to unblock Windows buildbots (which were all red). Please review http://hg.python.org/cpython/rev/4c496d53b1e1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 14:22:14 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 31 Jan 2014 13:22:14 +0000 Subject: [issue17159] Remove explicit type check from inspect.Signature.from_function() In-Reply-To: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za> Message-ID: <1391174534.25.0.938845049145.issue17159@psf.upfronthosting.co.za> Larry Hastings added the comment: Tell you what. If this *specifically* is a fix for Cython, please add a some text saying that to the comment for the duck-type test function. If you do that, and assuming that test_inspect still passes, then you may check it in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 14:42:27 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 31 Jan 2014 13:42:27 +0000 Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1391175747.02.0.595469321552.issue20152@psf.upfronthosting.co.za> Changes by Brett Cannon : Removed file: http://bugs.python.org/file33594/pyexpat_derby.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 14:43:40 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 31 Jan 2014 13:43:40 +0000 Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1391175820.46.0.985078698416.issue20152@psf.upfronthosting.co.za> Brett Cannon added the comment: Here is pyexpat updated with ErrorString converted (and generally updated to manage changes now required by AC for class definitions). ---------- Added file: http://bugs.python.org/file33827/pyexpat_derby.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 14:44:44 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 31 Jan 2014 13:44:44 +0000 Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1391175884.63.0.998641673531.issue20152@psf.upfronthosting.co.za> Brett Cannon added the comment: Should only have two modules left to convert: Modules/cmathmodule.c: 8 sites Modules/arraymodule.c: 27 sites I have already started arraymodule.c; it's just taking a while. ---------- assignee: larry -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 14:45:02 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 31 Jan 2014 13:45:02 +0000 Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1391175902.25.0.567924571099.issue20152@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 14:49:01 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 31 Jan 2014 13:49:01 +0000 Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1391176141.63.0.708121675677.issue20152@psf.upfronthosting.co.za> Changes by Brett Cannon : Added file: http://bugs.python.org/file33828/pyexpat_derby.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 14:49:12 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 31 Jan 2014 13:49:12 +0000 Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1391176152.55.0.593945564619.issue20152@psf.upfronthosting.co.za> Changes by Brett Cannon : Removed file: http://bugs.python.org/file33827/pyexpat_derby.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 14:56:07 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 31 Jan 2014 13:56:07 +0000 Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1391176567.0.0.352811282989.issue20152@psf.upfronthosting.co.za> Changes by Brett Cannon : Added file: http://bugs.python.org/file33829/multibytecodec_derby.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 14:56:20 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 31 Jan 2014 13:56:20 +0000 Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1391176580.21.0.952285959236.issue20152@psf.upfronthosting.co.za> Changes by Brett Cannon : Removed file: http://bugs.python.org/file33514/multibytecodec_derby.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 14:59:58 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 31 Jan 2014 13:59:58 +0000 Subject: [issue20390] Argument Clinic rollup patch, 2014/01/25 In-Reply-To: <1390663726.3.0.8274031742.issue20390@psf.upfronthosting.co.za> Message-ID: <3fG0Rx6dK5zPkj@mail.python.org> Roundup Robot added the comment: New changeset 06b4fbb09c93 by Larry Hastings in branch 'default': Issue #20390: Removing detritus from Argument Clinic "file preset" name change. http://hg.python.org/cpython/rev/06b4fbb09c93 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 15:18:43 2014 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Fri, 31 Jan 2014 14:18:43 +0000 Subject: [issue20420] BufferedIncrementalEncoder violates IncrementalEncoder interface In-Reply-To: <1390926885.67.0.351173619746.issue20420@psf.upfronthosting.co.za> Message-ID: <1391177923.01.0.293405371011.issue20420@psf.upfronthosting.co.za> Walter D?rwald added the comment: I dug up an ancient email about that subject: >>> However, I've discovered that BufferedIncrementalEncoder.getstate() >>> doesn't match the specification (i.e. it returns the buffer, not an >>> int). However this class is unused (and probably useless, because it >>> doesn't make sense to delay encoding the input). The simplest solution >>> would be to simply drop the class. >> >> Sounds like a plan; go right ahead! > > Oops, there *is* one codec that uses it: The idna encoder. It buffers > the input until a '.' is encountered (or encode() is called with > final==True) and then encodes this part. > > Either the idna encoder encodes the unencoded input as a int, or we drop > the specification that encoder.getstate() must return an int, or we > change it to mirror the decoder specification (i.e. return a > (buffered_input, additional_state_info) tuple. > > (A more radical solution would be to completely drop the incremental > codecs for idna). > > Maybe we should wait and see how the implementation of writing turns out? And indeed the incremental encoder for idna behaves strange: >>> import io >>> b = io.BytesIO() >>> s = io.TextIOWrapper(b, 'idna') >>> s.write('x') 1 >>> s.tell() 0 >>> b.getvalue() b'' >>> s.write('.') 1 >>> s.tell() 2 >>> b.getvalue() b'x.' >>> b = io.BytesIO() >>> s = io.TextIOWrapper(b, 'idna') >>> s.write('x') 1 >>> s.seek(s.tell()) 0 >>> s.write('.') Traceback (most recent call last): File "", line 1, in File "/Users/walter/.local/lib/python3.3/codecs.py", line 218, in encode (result, consumed) = self._buffer_encode(data, self.errors, final) File "/Users/walter/.local/lib/python3.3/encodings/idna.py", line 246, in _buffer_encode result.extend(ToASCII(label)) File "/Users/walter/.local/lib/python3.3/encodings/idna.py", line 73, in ToASCII raise UnicodeError("label empty or too long") UnicodeError: label empty or too long The cleanest solution might probably by to switch to a (buffered_input, additional_state_info) state. However I don't know what changes this would require in the seek/tell imlementations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 15:51:59 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 31 Jan 2014 14:51:59 +0000 Subject: [issue20170] Derby #1: Convert 137 sites to Argument Clinic in Modules/posixmodule.c In-Reply-To: <1389138185.8.0.104398826507.issue20170@psf.upfronthosting.co.za> Message-ID: <1391179919.16.0.148993595994.issue20170@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 16:03:09 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 31 Jan 2014 15:03:09 +0000 Subject: [issue20328] mailbox: add method to delete mailbox In-Reply-To: <1390304458.71.0.378928457479.issue20328@psf.upfronthosting.co.za> Message-ID: <1391180589.39.0.918639729645.issue20328@psf.upfronthosting.co.za> R. David Murray added the comment: I think your arguments are good ones. So, if you want to propose a patch that defines some semantics for delete (and possibly address the maildir folder delete similarly), I will review it. Also fine if you want to discuss it more before working on a patch. (Also OK if you *don't* want to work on a patch, although in that case it is a lot less likely to happen :) ---------- stage: -> needs patch title: mailbox: -> mailbox: add method to delete mailbox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 16:07:54 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 31 Jan 2014 15:07:54 +0000 Subject: [issue20453] json.load() error message changed in 3.4 In-Reply-To: <1391162931.99.0.108127691347.issue20453@psf.upfronthosting.co.za> Message-ID: <1391180874.33.0.426841707278.issue20453@psf.upfronthosting.co.za> R. David Murray added the comment: It seems to me that it should indeed have been that way. I thought the referenced issue was *adding* the location information to the existing error messages. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 16:15:04 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 31 Jan 2014 15:15:04 +0000 Subject: [issue20434] Process crashes if not enough memory to import module In-Reply-To: <1390984600.38.0.476358983499.issue20434@psf.upfronthosting.co.za> Message-ID: <1391181304.27.0.44315479938.issue20434@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: I'm not talking about the PyObject** argument, Victor. I'm talking about reference counting semantics. It is a rule that reference counting semantics should be the same over a function call whether that function raised an exception or not. The this function effectively steals a reference in case of error. The caller owns the reference to the argument (passed by ref) if it succeeds, but if id doesn't, then he doesn't own it anymore. Reference counting invariance with errors is, as I mentioned, observed with e.g. the 'N' argument to Py_BuildValue(), which is defined to "steal" a reference and does so even if the call fails. This behaviour is observed by other reference-stealing functions, such as PyTuple_SetItem(). Similarly, functions who don't steal a reference, i.e. take their own, will not change that behaviour if they error. If you don't want to think about this in terms of reference counting semantics, think about it in terms of the fact that in case of error, most functions leave everything as it was. PyList_Append(), if it fails, leaves everything as it was. This function does not. In case of failure, it will, as a convenience to the caller, release the original object. It is equivalent to () realloc() freeing its operand if it cannot succeed. It is precisely these 'unusual' exceptions from established semantics that cause these kind of programming errors. Originally, this was probably designed as a convenience to the programmer for the handful of places that the function (_PyString_Resize) was used. But this decision forces every new user of this function (and its descendents) to be acutely aware of its unusual error behaviour. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 16:28:05 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 31 Jan 2014 15:28:05 +0000 Subject: [issue20455] test_asyncio hangs on Windows In-Reply-To: <1391174100.63.0.591447461885.issue20455@psf.upfronthosting.co.za> Message-ID: <3fG2Pd0Ytpz7LjQ@mail.python.org> Roundup Robot added the comment: New changeset 8fc69d43bc49 by Victor Stinner in branch 'default': Issue #20455: math.ceil() returns an int in Python 3, no need to cast the http://hg.python.org/cpython/rev/8fc69d43bc49 New changeset 3f54bc5392c3 by Victor Stinner in branch 'default': Issue #20455: asyncio: use the same code to round a timeout than the selectors http://hg.python.org/cpython/rev/3f54bc5392c3 New changeset 55abd847c9f5 by Victor Stinner in branch 'default': Issue #20455: Add a resolution attribute to IocpProactor (1 ms) http://hg.python.org/cpython/rev/55abd847c9f5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 16:29:57 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 31 Jan 2014 15:29:57 +0000 Subject: [issue20452] test_timeout_rounding() of test_asyncio fails on "x86 Ubuntu Shared 3.x" buildbot In-Reply-To: <1391156790.09.0.38396612237.issue20452@psf.upfronthosting.co.za> Message-ID: <1391182197.06.0.0897606789126.issue20452@psf.upfronthosting.co.za> STINNER Victor added the comment: Oops, I mentionned the wrong issue number in the following commits. There were related to this issue (#20452): New changeset 8fc69d43bc49 by Victor Stinner in branch 'default': Issue #20455: math.ceil() returns an int in Python 3, no need to cast the http://hg.python.org/cpython/rev/8fc69d43bc49 New changeset 3f54bc5392c3 by Victor Stinner in branch 'default': Issue #20455: asyncio: use the same code to round a timeout than the selectors http://hg.python.org/cpython/rev/3f54bc5392c3 New changeset 55abd847c9f5 by Victor Stinner in branch 'default': Issue #20455: Add a resolution attribute to IocpProactor (1 ms) http://hg.python.org/cpython/rev/55abd847c9f5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 16:30:06 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 31 Jan 2014 15:30:06 +0000 Subject: [issue20455] test_asyncio hangs on Windows In-Reply-To: <1391174100.63.0.591447461885.issue20455@psf.upfronthosting.co.za> Message-ID: <1391182206.1.0.761912912183.issue20455@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- Removed message: http://bugs.python.org/msg209795 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 16:30:51 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 31 Jan 2014 15:30:51 +0000 Subject: [issue20455] test_asyncio hangs on Windows In-Reply-To: <1391174100.63.0.591447461885.issue20455@psf.upfronthosting.co.za> Message-ID: <1391182251.3.0.963565088255.issue20455@psf.upfronthosting.co.za> STINNER Victor added the comment: (I removed the message msg209795 because the commits are related to #20452, not to this issue.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 16:33:32 2014 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 31 Jan 2014 15:33:32 +0000 Subject: [issue19363] Python 2.7's future_builtins.map is not compatible with Python 3's map In-Reply-To: <1382534189.14.0.63787411181.issue19363@psf.upfronthosting.co.za> Message-ID: <1391182412.88.0.32763520467.issue19363@psf.upfronthosting.co.za> Eric V. Smith added the comment: I agree with Raymond: it would have been nice to do this, but it's too late. Closing. ---------- nosy: +eric.smith resolution: -> wont fix stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 16:50:00 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 31 Jan 2014 15:50:00 +0000 Subject: [issue20452] test_timeout_rounding() of test_asyncio fails on "x86 Ubuntu Shared 3.x" buildbot In-Reply-To: <1391156790.09.0.38396612237.issue20452@psf.upfronthosting.co.za> Message-ID: <3fG2tv3NWvz7LjS@mail.python.org> Roundup Robot added the comment: New changeset 7f649ff0756c by Victor Stinner in branch 'default': Issue #20452: test_asyncio: Add more info if the test fails http://hg.python.org/cpython/rev/7f649ff0756c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 17:01:01 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 31 Jan 2014 16:01:01 +0000 Subject: [issue20452] test_timeout_rounding() of test_asyncio fails on "x86 Ubuntu Shared 3.x" buildbot In-Reply-To: <1391156790.09.0.38396612237.issue20452@psf.upfronthosting.co.za> Message-ID: <1391184061.71.0.668103832826.issue20452@psf.upfronthosting.co.za> STINNER Victor added the comment: There is a similar (but different?) issue on Windows XP. I tried to fix it with the 4 last commits. The test uses a busy loop. The scheduled handle is called after 0.100 - granularity. The granularity is usually 15.6 ms on Windows, so the expected mimiumum is around 0.084 (not 0.090). Attached patch test_base_events.patch uses the granularity to test the minimum. The check on the maximum should maybe be removed because of our slow buildbots. http://buildbot.python.org/all/builders/x86%20XP-4%203.x/builds/10071/steps/test/logs/stdio ====================================================================== FAIL: test_time_and_call_at (test.test_asyncio.test_base_events.BaseEventLoopTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_asyncio\test_base_events.py", line 124, in test_time_and_call_at self.assertTrue(0.09 <= t1-t0 <= 0.9, t1-t0) AssertionError: False is not true : 0.08999999985098839 ---------- Added file: http://bugs.python.org/file33830/test_base_events.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 17:01:46 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 31 Jan 2014 16:01:46 +0000 Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1391184106.19.0.312047135138.issue20152@psf.upfronthosting.co.za> Changes by Brett Cannon : Added file: http://bugs.python.org/file33831/array_derby.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 17:14:19 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 31 Jan 2014 16:14:19 +0000 Subject: [issue20453] json.load() error message changed in 3.4 In-Reply-To: <1391162931.99.0.108127691347.issue20453@psf.upfronthosting.co.za> Message-ID: <1391184859.73.0.866085632332.issue20453@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: So, here's a patch that should work. One thing I'm not positive about is that this is a more expansive change then just merging the two messages in the one case in the original description. But it probably makes sense to be consistent. Or should we try for a narrower fix? ---------- Added file: http://bugs.python.org/file33832/20453.expansive _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 17:16:40 2014 From: report at bugs.python.org (dongwm) Date: Fri, 31 Jan 2014 16:16:40 +0000 Subject: [issue20457] Use partition and enumerate make getopt easier Message-ID: <1391185000.25.0.00329512956589.issue20457@psf.upfronthosting.co.za> Changes by dongwm : ---------- components: Library (Lib) files: getopt_2.7_3.X.path nosy: dongwm priority: normal severity: normal status: open title: Use partition and enumerate make getopt easier type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file33833/getopt_2.7_3.X.path _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 17:16:54 2014 From: report at bugs.python.org (dongwm) Date: Fri, 31 Jan 2014 16:16:54 +0000 Subject: [issue20457] Use partition and enumerate make getopt easier Message-ID: <1391185014.88.0.357085821668.issue20457@psf.upfronthosting.co.za> Changes by dongwm : ---------- keywords: +patch Added file: http://bugs.python.org/file33834/getopt_3.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 17:17:38 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 31 Jan 2014 16:17:38 +0000 Subject: [issue20458] ``clinic.py --converters`` raises an exception Message-ID: <1391185058.63.0.464965785881.issue20458@psf.upfronthosting.co.za> New submission from Brett Cannon: > ./python.exe Tools/clinic/clinic.py --converters ~/Repositories/cpython/default Legacy converters: Traceback (most recent call last): File "Tools/clinic/clinic.py", line 4045, in sys.exit(main(sys.argv[1:])) File "Tools/clinic/clinic.py", line 3977, in main print(' ' + ' '.join(c for c in legacy if c[0].isupper())) File "Tools/clinic/clinic.py", line 3977, in print(' ' + ' '.join(c for c in legacy if c[0].isupper())) IndexError: string index out of range ---------- assignee: larry components: Build messages: 209802 nosy: brett.cannon, larry priority: release blocker severity: normal stage: needs patch status: open title: ``clinic.py --converters`` raises an exception type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 17:21:42 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 31 Jan 2014 16:21:42 +0000 Subject: [issue20459] No Argument Clinic documentation on how to specify a return converter Message-ID: <1391185302.8.0.888255910236.issue20459@psf.upfronthosting.co.za> New submission from Brett Cannon: There's no actual example of using a return converter so it's not obvious how to specify one. Is it specifying an argument of 'return'? ---------- assignee: larry components: Documentation messages: 209803 nosy: brett.cannon, larry priority: normal severity: normal stage: needs patch status: open title: No Argument Clinic documentation on how to specify a return converter versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 17:23:04 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 31 Jan 2014 16:23:04 +0000 Subject: [issue20453] json.load() error message changed in 3.4 In-Reply-To: <1391162931.99.0.108127691347.issue20453@psf.upfronthosting.co.za> Message-ID: <1391185384.78.0.313718360948.issue20453@psf.upfronthosting.co.za> R. David Murray added the comment: If backward compatibility is the concern, I'd think you'd just want to restore that one message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 17:26:22 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 31 Jan 2014 16:26:22 +0000 Subject: [issue20458] ``clinic.py --converters`` raises an exception In-Reply-To: <1391185058.63.0.464965785881.issue20458@psf.upfronthosting.co.za> Message-ID: <1391185582.15.0.22638416508.issue20458@psf.upfronthosting.co.za> Zachary Ware added the comment: This is a duplicate of (part of) #20456; adding you there, Brett. ---------- nosy: +zach.ware resolution: -> duplicate stage: needs patch -> committed/rejected status: open -> closed superseder: -> Argument Clinic rollup patch, 2014/01/31 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 17:26:25 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 31 Jan 2014 16:26:25 +0000 Subject: [issue20456] Argument Clinic rollup patch, 2014/01/31 In-Reply-To: <1391174310.68.0.164884497366.issue20456@psf.upfronthosting.co.za> Message-ID: <1391185585.35.0.807222272134.issue20456@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 17:31:05 2014 From: report at bugs.python.org (Ethan Furman) Date: Fri, 31 Jan 2014 16:31:05 +0000 Subject: [issue20457] Use partition and enumerate make getopt easier Message-ID: <1391185865.77.0.0148872171621.issue20457@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 17:51:28 2014 From: report at bugs.python.org (OSAMU NAKAMURA) Date: Fri, 31 Jan 2014 16:51:28 +0000 Subject: [issue20460] Wrong markup in c-api/arg.rst Message-ID: <1391187088.65.0.311524053525.issue20460@psf.upfronthosting.co.za> New submission from OSAMU NAKAMURA: ":func:`bytes`" in description for ``y`` format should be ":class:`bytes`". ---------- assignee: docs at python components: Documentation files: mywork.patch keywords: patch messages: 209806 nosy: OSAMU.NAKAMURA, docs at python priority: normal severity: normal status: open title: Wrong markup in c-api/arg.rst type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file33835/mywork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 18:02:00 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 31 Jan 2014 17:02:00 +0000 Subject: [issue20453] json.load() error message changed in 3.4 In-Reply-To: <1391185384.78.0.313718360948.issue20453@psf.upfronthosting.co.za> Message-ID: <20140131170154.2d49f7c6@anarchist> Barry A. Warsaw added the comment: On Jan 31, 2014, at 04:23 PM, R. David Murray wrote: >If backward compatibility is the concern, I'd think you'd just want to >restore that one message. Yeah. I think the tests are a little more difficult to adjust in that case, and of course, if we do change that one message it *won't* be completely backward compatible (because it will have the additional information). It's not a critical issue for me, so let's see if anybody else chimes in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 18:28:47 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 31 Jan 2014 17:28:47 +0000 Subject: [issue20461] Argument Clinic included return converters hard code use of ``_return_value`` Message-ID: <1391189327.05.0.0632329148594.issue20461@psf.upfronthosting.co.za> New submission from Brett Cannon: E.g. NoneType_return_converter assumes _return_value is used in render() although CReturnConverter.declare() stores it in data.return_value and it's a parameter to render(). ---------- assignee: larry components: Build messages: 209808 nosy: brett.cannon, larry priority: normal severity: normal stage: test needed status: open title: Argument Clinic included return converters hard code use of ``_return_value`` versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 19:07:44 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 31 Jan 2014 18:07:44 +0000 Subject: [issue20460] Wrong markup in c-api/arg.rst In-Reply-To: <1391187088.65.0.311524053525.issue20460@psf.upfronthosting.co.za> Message-ID: <3fG5xq3dTSz7LlF@mail.python.org> Roundup Robot added the comment: New changeset 7a611b7aae38 by Zachary Ware in branch '3.3': Issue #20460: Render 'bytes' as a class, not a function. http://hg.python.org/cpython/rev/7a611b7aae38 New changeset b56ce3410ca6 by Zachary Ware in branch 'default': Issue #20460: Merge with 3.3 http://hg.python.org/cpython/rev/b56ce3410ca6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 19:08:16 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 31 Jan 2014 18:08:16 +0000 Subject: [issue20460] Wrong markup in c-api/arg.rst In-Reply-To: <1391187088.65.0.311524053525.issue20460@psf.upfronthosting.co.za> Message-ID: <1391191696.26.0.368558764683.issue20460@psf.upfronthosting.co.za> Zachary Ware added the comment: Fixed, thanks for the report and patch! If you intend to ever contribute more than the simplest of patches, please consider signing a contributor's agreement: http://www.python.org/psf/contrib/ Thanks! ---------- nosy: +zach.ware resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 19:36:11 2014 From: report at bugs.python.org (Alessandro Reinoso) Date: Fri, 31 Jan 2014 18:36:11 +0000 Subject: [issue20462] Python IDLE auto closed when creating a new file or open existing file Message-ID: <1391193371.56.0.893226127057.issue20462@psf.upfronthosting.co.za> New submission from Alessandro Reinoso: I looked for some online help and i found a question on stackoverflow wich shows my same problem except that i just installed python to get started: http://stackoverflow.com/questions/20768949/python-idle-auto-closed-when-i-create-a-new-file-or-open-existing-file when i choose Edit with IDLE, doesn't even bother to open. im using windows 7 SP1 64-bit i tried using both python-3.3.3.msi and python-3.3.3.amd64.msi installers, both with same problem. Thank You. ---------- messages: 209811 nosy: Bishop priority: normal severity: normal status: open title: Python IDLE auto closed when creating a new file or open existing file type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 20:18:47 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 19:18:47 +0000 Subject: [issue17159] Remove explicit type check from inspect.Signature.from_function() In-Reply-To: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za> Message-ID: <1391195927.51.0.315159473346.issue17159@psf.upfronthosting.co.za> Yury Selivanov added the comment: Third version of the patch is attached (sig_func_ducktype_03.patch). Changes: - Toughen the tests for duck-typed function -- do not accept classes - Added comments to clarify the need of duck-typing - NEWS item - what's new item Stefan, please take a look. I want to make sure, that the fact that we won't accept classes that look like a function, is OK with you. ---------- keywords: +needs review -patch Added file: http://bugs.python.org/file33836/sig_func_ducktype_03.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 20:19:32 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 19:19:32 +0000 Subject: [issue17159] Remove explicit type check from inspect.Signature.from_function() In-Reply-To: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za> Message-ID: <1391195972.85.0.306444776241.issue17159@psf.upfronthosting.co.za> Changes by Yury Selivanov : Removed file: http://bugs.python.org/file33836/sig_func_ducktype_03.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 20:19:44 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 19:19:44 +0000 Subject: [issue17159] Remove explicit type check from inspect.Signature.from_function() In-Reply-To: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za> Message-ID: <1391195984.25.0.0604549763778.issue17159@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- keywords: +patch Added file: http://bugs.python.org/file33837/sig_func_ducktype_03.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 20:21:38 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 31 Jan 2014 19:21:38 +0000 Subject: [issue17162] Py_LIMITED_API needs a PyType_GenericDealloc In-Reply-To: <1360348035.19.0.130949262051.issue17162@psf.upfronthosting.co.za> Message-ID: <1391196098.6.0.493928444024.issue17162@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'm not sure we are looking at the same code base, I look at http://hg.python.org/cpython/file/b56ce3410ca6/Lib/collections/__init__.py#l401 and ISTM that collections.Counter is *not* implemented in C. Also, according to http://hg.python.org/cpython/file/b56ce3410ca6/Include/object.h#l486 I see that _PyType_LookupId is *not* in the limited API (and it really shouldn't). In any case, _PyType_LookupId cannot replace PyType_GetSlot, since it returns a PyObject* from the namespace of the type. Many of the slots don't actually have a Python name (including tp_free, which is the OP's original use case), plus the value returned ought to be a function pointer, not a PyObject*. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 20:28:40 2014 From: report at bugs.python.org (Ned Deily) Date: Fri, 31 Jan 2014 19:28:40 +0000 Subject: [issue17128] OS X system openssl deprecated - installer should build local libssl In-Reply-To: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za> Message-ID: <1391196520.23.0.468986629857.issue17128@psf.upfronthosting.co.za> Ned Deily added the comment: Update: the MacPorts certsync daemon has matured and is now included as an optional MacPorts port. It's not a perfect solution as noted in the macports-devel thread: >>The only catch is that custom added certificates or trust anchors need >>to be in the system keychain to be picked up by certsync by default. >Yeah, this was an unfortunate trade-off; since certsync is a system-wide >daemon, and the resulting CA certs file is also system-wide, it seemed to >be the most appropriate course of action. Most of the alternatives involve >patching OpenSSL and some of the software that depends on it, which is a >road I'm personally wary of committing to. http://comments.gmane.org/gmane.os.apple.macports.devel/22653 It works by registering a launchd agent that is run whenever any of the system keychain files or trust setting files are modified. That raises the issues of when and how a Python install should register the agent (will likely need admin/root privileges to do that) and how to delete the agent (we currently don't have a formal uninstall procedure on OS X). It would be easier to manage these things with the binary installer-based Pythons, as provided by python.org, in which case Pythons built by users from source would still use the deprecated Apple-supplied libssl and libcrypto. But I'd like to separate out the building of third-party libraries, like openssl, from the installer build process so that user source builds can take advantage of features like this. ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 20:32:31 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 31 Jan 2014 19:32:31 +0000 Subject: [issue13657] IDLE doesn't support sys.ps1 and sys.ps2. In-Reply-To: <1324640742.58.0.860347532783.issue13657@psf.upfronthosting.co.za> Message-ID: <1391196751.08.0.752793508419.issue13657@psf.upfronthosting.co.za> Zachary Ware added the comment: Robin Zimmermann on docs@ raised this issue again. Is this likely to be fixed soon, or would it be good to document this limitation of IDLE in the tutorial (since the tutorial is the most likely place for someone to be confused by this)? ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 20:33:46 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 31 Jan 2014 19:33:46 +0000 Subject: [issue17159] Remove explicit type check from inspect.Signature.from_function() In-Reply-To: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za> Message-ID: <1391196826.1.0.124641385615.issue17159@psf.upfronthosting.co.za> Stefan Behnel added the comment: Tried it, works for me. Explicitly rejecting classes is a good idea, IMHO, as is requiring that any function-like object must be callable, obviously. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 20:39:32 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 31 Jan 2014 19:39:32 +0000 Subject: [issue18801] inspect.classify_class_attrs() misclassifies object.__new__() In-Reply-To: <1377114694.59.0.675744683781.issue18801@psf.upfronthosting.co.za> Message-ID: <3fG7zl5H29z7LjQ@mail.python.org> Roundup Robot added the comment: New changeset c38f99554be4 by Yury Selivanov in branch 'default': inspect.classify_class_attrs: Classify object.__new__ and __init__ correctly #18801 http://hg.python.org/cpython/rev/c38f99554be4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 20:40:38 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 19:40:38 +0000 Subject: [issue18801] inspect.classify_class_attrs() misclassifies object.__new__() In-Reply-To: <1377114694.59.0.675744683781.issue18801@psf.upfronthosting.co.za> Message-ID: <1391197238.27.0.6981766404.issue18801@psf.upfronthosting.co.za> Yury Selivanov added the comment: Not sure if we need to backport this to older python versions ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 20:40:58 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 19:40:58 +0000 Subject: [issue18801] inspect.classify_class_attrs() misclassifies object.__new__() In-Reply-To: <1377114694.59.0.675744683781.issue18801@psf.upfronthosting.co.za> Message-ID: <1391197258.98.0.0499084709265.issue18801@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 20:42:42 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 31 Jan 2014 19:42:42 +0000 Subject: [issue18801] inspect.classify_class_attrs() misclassifies object.__new__() In-Reply-To: <1377114694.59.0.675744683781.issue18801@psf.upfronthosting.co.za> Message-ID: <3fG83P3N95z7LjQ@mail.python.org> Roundup Robot added the comment: New changeset d0f95094033d by Yury Selivanov in branch 'default': NEWS: Add news item for #18801 http://hg.python.org/cpython/rev/d0f95094033d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 20:47:15 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 19:47:15 +0000 Subject: [issue17159] Remove explicit type check from inspect.Signature.from_function() In-Reply-To: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za> Message-ID: <1391197635.66.0.36720756086.issue17159@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Explicitly rejecting classes is a good idea, IMHO, as is requiring that any function-like object must be callable, obviously. Yeah, I think it's good to restrict this duck-typing as much as possible. Committing the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 20:48:51 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 31 Jan 2014 19:48:51 +0000 Subject: [issue17159] Remove explicit type check from inspect.Signature.from_function() In-Reply-To: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za> Message-ID: <3fG8BV6ZGHz7LjQ@mail.python.org> Roundup Robot added the comment: New changeset 32a660a52aae by Yury Selivanov in branch 'default': inspect.signature: Support duck-types of Python functions (Cython, for instance) #17159 http://hg.python.org/cpython/rev/32a660a52aae ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 20:50:31 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 19:50:31 +0000 Subject: [issue17159] Remove explicit type check from inspect.Signature.from_function() In-Reply-To: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za> Message-ID: <1391197831.28.0.847400641847.issue17159@psf.upfronthosting.co.za> Yury Selivanov added the comment: OK, closing this one. Stefan, Larry, thank you for your reviews and time. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 20:51:05 2014 From: report at bugs.python.org (Christopher Welborn) Date: Fri, 31 Jan 2014 19:51:05 +0000 Subject: [issue18916] Various out-of-date Lock text in 3.2+ In-Reply-To: <1378255145.39.0.17069692986.issue18916@psf.upfronthosting.co.za> Message-ID: <1391197865.88.0.67215431334.issue18916@psf.upfronthosting.co.za> Christopher Welborn added the comment: Here's the 3.3 version, with the PyThread_allocate_lock comment in the lock type. Still working on the 3.4 argument clinic version. ---------- Added file: http://bugs.python.org/file33838/threading.lock.docs.3.3-with-comment.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 20:51:15 2014 From: report at bugs.python.org (Christopher Welborn) Date: Fri, 31 Jan 2014 19:51:15 +0000 Subject: [issue18916] Various out-of-date Lock text in 3.2+ In-Reply-To: <1378255145.39.0.17069692986.issue18916@psf.upfronthosting.co.za> Message-ID: <1391197875.92.0.617018883428.issue18916@psf.upfronthosting.co.za> Changes by Christopher Welborn : Removed file: http://bugs.python.org/file33819/threading.lock.docs3.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 20:54:07 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 31 Jan 2014 19:54:07 +0000 Subject: [issue17159] Remove explicit type check from inspect.Signature.from_function() In-Reply-To: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za> Message-ID: <1391198047.42.0.545994540317.issue17159@psf.upfronthosting.co.za> Stefan Behnel added the comment: Thanks a lot! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 20:57:36 2014 From: report at bugs.python.org (Ronny Pfannschmidt) Date: Fri, 31 Jan 2014 19:57:36 +0000 Subject: [issue20463] sqlite dumpiter dumps invalid script when virtual tables are used Message-ID: <1391198256.46.0.541752876278.issue20463@psf.upfronthosting.co.za> New submission from Ronny Pfannschmidt: when using virtual tables, dumpiter generates a broken db script virtual table entries must be created as master table entries the sqlite tools dump does that correctly however pythons iterdump seems to do that rather different and wrong sqlite3 test.db "create virtual table test using fts4(example);" ------------------------------- sqlite dump PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; PRAGMA writable_schema=ON; INSERT INTO sqlite_master(type,name,tbl_name,rootpage,sql)VALUES('table','test','test',0,'CREATE VIRTUAL TABLE test using fts4(example)'); CREATE TABLE 'test_content'(docid INTEGER PRIMARY KEY, 'c0example'); CREATE TABLE 'test_segments'(blockid INTEGER PRIMARY KEY, block BLOB); CREATE TABLE 'test_segdir'(level INTEGER,idx INTEGER,start_block INTEGER,leaves_end_block INTEGER,end_block INTEGER,root BLOB,PRIMARY KEY(level, idx)); CREATE TABLE 'test_docsize'(docid INTEGER PRIMARY KEY, size BLOB); CREATE TABLE 'test_stat'(id INTEGER PRIMARY KEY, value BLOB); PRAGMA writable_schema=OFF; COMMIT; ------------------------------ python iterdump "import sqlite3; c=sqlite3.connect("test.db"); print("\n".join(c.iterdump()))" BEGIN TRANSACTION; CREATE VIRTUAL TABLE test using fts4(example); CREATE TABLE 'test_content'(docid INTEGER PRIMARY KEY, 'c0example'); CREATE TABLE 'test_docsize'(docid INTEGER PRIMARY KEY, size BLOB); CREATE TABLE 'test_segdir'(level INTEGER,idx INTEGER,start_block INTEGER,leaves_end_block INTEGER,end_block INTEGER,root BLOB,PRIMARY KEY(level, idx)); CREATE TABLE 'test_segments'(blockid INTEGER PRIMARY KEY, block BLOB); CREATE TABLE 'test_stat'(id INTEGER PRIMARY KEY, value BLOB); COMMIT; ---------- messages: 209825 nosy: Ronny.Pfannschmidt priority: normal severity: normal status: open title: sqlite dumpiter dumps invalid script when virtual tables are used versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 21:04:21 2014 From: report at bugs.python.org (Ronny Pfannschmidt) Date: Fri, 31 Jan 2014 20:04:21 +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: <1391198661.62.0.600962860153.issue20463@psf.upfronthosting.co.za> Changes by Ronny Pfannschmidt : ---------- components: +Extension Modules type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 21:07:46 2014 From: report at bugs.python.org (Ned Deily) Date: Fri, 31 Jan 2014 20:07:46 +0000 Subject: [issue20462] Python IDLE auto closed when creating a new file or open existing file In-Reply-To: <1391193371.56.0.893226127057.issue20462@psf.upfronthosting.co.za> Message-ID: <1391198866.29.0.34943932563.issue20462@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- components: +IDLE nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 21:20:57 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 31 Jan 2014 20:20:57 +0000 Subject: [issue20152] Derby #15: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389039493.34.0.923814328387.issue20152@psf.upfronthosting.co.za> Message-ID: <1391199657.27.0.442320057651.issue20152@psf.upfronthosting.co.za> Brett Cannon added the comment: It took a bit of finessing but I managed to convert cmath in a way that didn't make it worse compared to before AC. I now consider this part of the derby done and ready for Larry to review. ---------- assignee: brett.cannon -> larry Added file: http://bugs.python.org/file33839/cmath_derby.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 21:22:10 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 31 Jan 2014 20:22:10 +0000 Subject: [issue17159] Remove explicit type check from inspect.Signature.from_function() In-Reply-To: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za> Message-ID: <3fG8wx6Bsbz7LjW@mail.python.org> Roundup Robot added the comment: New changeset 8a91132ed6aa by Yury Selivanov in branch 'default': inspect.Signauture.from_function: validate duck functions in Signature constructor #17159 http://hg.python.org/cpython/rev/8a91132ed6aa ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 21:26:22 2014 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 31 Jan 2014 20:26:22 +0000 Subject: [issue17633] zipimport's handling of namespace packages is incorrect In-Reply-To: <1365070223.85.0.365511954484.issue17633@psf.upfronthosting.co.za> Message-ID: <1391199982.47.0.968196757972.issue17633@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- keywords: +needs review versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 21:44:27 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 20:44:27 +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: <1391201067.42.0.328353301915.issue20463@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +ghaering _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 21:48:04 2014 From: report at bugs.python.org (Thomas Heller) Date: Fri, 31 Jan 2014 20:48:04 +0000 Subject: [issue17633] zipimport's handling of namespace packages is incorrect In-Reply-To: <1365070223.85.0.365511954484.issue17633@psf.upfronthosting.co.za> Message-ID: <1391201284.91.0.59093882783.issue17633@psf.upfronthosting.co.za> Changes by Thomas Heller : ---------- nosy: +theller _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 21:54:08 2014 From: report at bugs.python.org (Christopher Welborn) Date: Fri, 31 Jan 2014 20:54:08 +0000 Subject: [issue18916] Various out-of-date Lock text in 3.2+ In-Reply-To: <1378255145.39.0.17069692986.issue18916@psf.upfronthosting.co.za> Message-ID: <1391201648.5.0.229866657298.issue18916@psf.upfronthosting.co.za> Christopher Welborn added the comment: I meant to say 'attempting to work on the 3.4 arg clinic version', i can't make any promises. I'm using it as a learning experience but probably won't yield any real results any time soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 21:55:11 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 31 Jan 2014 20:55:11 +0000 Subject: [issue20464] Update distutils sample config file in Doc/install/index.rst Message-ID: <1391201711.97.0.184979826347.issue20464@psf.upfronthosting.co.za> New submission from Zachary Ware: >From docs@: On Thu, Jan 16, 2014 at 2:56 AM, Peter Br?cker wrote: > Hi, > > I have tried to set up the distutils config files for a custom module > installation. Using the suggested snippet from > > http://docs.python.org/2/install/ > > [install] > install-base=$HOME/python > install-purelib=lib > install-platlib=lib.$PLAT > install-scripts=scripts > install-data=data did not work for me. > > Instead, I had to add install-headers and additionally modify all paths > to include $base: > > [install] > install-base=/some/dir > install-purelib=$base/lib > install-platlib=$base/lib.$PLAT > install-scripts=$base/scripts > install-headers=$base/include > install-data=$base/data > > > I'm unsure if this is actually a bug, but I could only resolve this with > the help of this answer on stackoverflow: > http://stackoverflow.com/a/12768721 > > Best regards, > Peter ---------- assignee: docs at python components: Distutils, Documentation messages: 209829 nosy: docs at python, zach.ware priority: normal severity: normal stage: test needed status: open title: Update distutils sample config file in Doc/install/index.rst type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 21:57:25 2014 From: report at bugs.python.org (Ned Deily) Date: Fri, 31 Jan 2014 20:57:25 +0000 Subject: [issue20465] Upgrade SQLite to 3.8.3 with 3.4.0 Windows and OS X installers Message-ID: <1391201845.39.0.337535666199.issue20465@psf.upfronthosting.co.za> New submission from Ned Deily: The SQLite project has requested that we consider shipping SQLite version 3.8.3 with the Windows and OS X binary installers for Python 3.4.0, primarily to make available support for the new Common Table Expressions feature. 3.8.3 is expected to be officially released 2014-02-03. ---------- components: Build messages: 209830 nosy: larry, loewis, ned.deily priority: release blocker severity: normal stage: needs patch status: open title: Upgrade SQLite to 3.8.3 with 3.4.0 Windows and OS X installers versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 22:01:24 2014 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 31 Jan 2014 21:01:24 +0000 Subject: [issue20453] json.load() error message changed in 3.4 In-Reply-To: <1391162931.99.0.108127691347.issue20453@psf.upfronthosting.co.za> Message-ID: <1391202084.3.0.550527936868.issue20453@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 22:21:10 2014 From: report at bugs.python.org (Eric Snow) Date: Fri, 31 Jan 2014 21:21:10 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1391203270.74.0.993870692501.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: I agree with Antoine. It's first on my todo list for 3.5. My goal is that this and a couple of related features will land during the PyCon sprints. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 22:45:09 2014 From: report at bugs.python.org (Ram Rachum) Date: Fri, 31 Jan 2014 21:45:09 +0000 Subject: [issue20218] Add `pathlib.Path.write` and `pathlib.Path.read` In-Reply-To: <1389380693.53.0.752641621162.issue20218@psf.upfronthosting.co.za> Message-ID: <1391204709.68.0.191863605975.issue20218@psf.upfronthosting.co.za> Ram Rachum added the comment: Patch with documentation attached. ---------- Added file: http://bugs.python.org/file33840/patch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 22:47:18 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 21:47:18 +0000 Subject: [issue11117] Implementing Async IO In-Reply-To: <1296833201.02.0.659675625142.issue11117@psf.upfronthosting.co.za> Message-ID: <1391204838.9.0.750672207894.issue11117@psf.upfronthosting.co.za> Yury Selivanov added the comment: I guess PEP 3156 covers this, closing this one. ---------- nosy: +yselivanov resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 22:49:03 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 21:49:03 +0000 Subject: [issue8733] list type and UserList do not call super in __init__ and therefore, they cannot be parents in a multiple inheritence scheme In-Reply-To: <1274269644.21.0.524799705686.issue8733@psf.upfronthosting.co.za> Message-ID: <1391204943.29.0.0590931831853.issue8733@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 22:49:40 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 21:49:40 +0000 Subject: [issue1402289] Allow mappings as globals (was: Fix dictionary subclass ...) Message-ID: <1391204980.95.0.322468595119.issue1402289@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 22:54:24 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 31 Jan 2014 21:54:24 +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: <1391205264.61.0.987386304447.issue20463@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 22:57:25 2014 From: report at bugs.python.org (Larry Hastings) Date: Fri, 31 Jan 2014 21:57:25 +0000 Subject: [issue20456] Argument Clinic rollup patch, 2014/01/31 In-Reply-To: <1391174310.68.0.164884497366.issue20456@psf.upfronthosting.co.za> Message-ID: <1391205445.57.0.441788689865.issue20456@psf.upfronthosting.co.za> Larry Hastings added the comment: Updated the patch. * The "methoddef_ifndef" template is now sent to the "buffer" destination by default. I expected posixmodule to have an #ifndef, I was surprised to find _import had one too. Both files touched to move the buffer to an appropriate spot. * Fixed the "original" "preset" so it explicitly sets all three new templates just like the actual default. * Forgot a minor fix that was in revision 1: when generating the docstring for a function using optional groups, suppress the "self/type/module" first argument in the signature. (The signature isn't parsable by inspect.Signature, so we go ahead and insert something user-readable like the docstrings before Argument Clinic used to do.) * Changed _dbm.dbm.get to no longer use optional groups. Why was it doing that in the first place? There's now exactly one function checked in using optional groups, curses.window.addch. ---------- Added file: http://bugs.python.org/file33841/larry.clinic.rollup.2014.01.31.2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 22:57:44 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 21:57:44 +0000 Subject: [issue11107] Cache constant "slice" instances In-Reply-To: <1296761121.69.0.66743926851.issue11107@psf.upfronthosting.co.za> Message-ID: <1391205464.59.0.356261268725.issue11107@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 22:58:35 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 21:58:35 +0000 Subject: [issue11107] Cache constant "slice" instances In-Reply-To: <1296761121.69.0.66743926851.issue11107@psf.upfronthosting.co.za> Message-ID: <1391205515.9.0.473301615369.issue11107@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 23:05:49 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 22:05:49 +0000 Subject: [issue9232] Allow trailing comma in any function argument list. In-Reply-To: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za> Message-ID: <1391205949.42.0.931529145599.issue9232@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 23:07:45 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 22:07:45 +0000 Subject: [issue14665] faulthandler prints tracebacks in reverse order In-Reply-To: <1335305835.2.0.186027990116.issue14665@psf.upfronthosting.co.za> Message-ID: <1391206065.58.0.127564923624.issue14665@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- versions: +Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 23:09:59 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 22:09:59 +0000 Subject: [issue14854] faulthandler: fatal error with "SystemError: null argument to internal routine" In-Reply-To: <1337417592.83.0.722972299314.issue14854@psf.upfronthosting.co.za> Message-ID: <1391206199.38.0.138386038679.issue14854@psf.upfronthosting.co.za> Yury Selivanov added the comment: bump? ---------- nosy: +yselivanov versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 23:11:27 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 22:11:27 +0000 Subject: [issue14911] generator.throw() documentation inaccurate In-Reply-To: <1337943736.85.0.146138312281.issue14911@psf.upfronthosting.co.za> Message-ID: <1391206287.57.0.281908307509.issue14911@psf.upfronthosting.co.za> Yury Selivanov added the comment: Kristjan, can you write a patch for this? ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 23:14:09 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 31 Jan 2014 22:14:09 +0000 Subject: [issue20466] Example in Doc/extending/embedding.rst fails to compile cleanly Message-ID: <1391206449.61.0.838795178148.issue20466@psf.upfronthosting.co.za> New submission from Zachary Ware: Reported by Riccardo Rossi on docs@: The Very High Level Embedding example fails to compile cleanly, due to Py_SetProgramName expecting a wchar_t * argument, while the example passes a char *. ---------- assignee: docs at python components: Documentation messages: 209837 nosy: docs at python, zach.ware priority: normal severity: normal stage: needs patch status: open title: Example in Doc/extending/embedding.rst fails to compile cleanly type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 23:21:08 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 22:21:08 +0000 Subject: [issue7325] tempfile.mkdtemp() does not return absolute pathname when relative dir is specified In-Reply-To: <1258226856.45.0.72736645389.issue7325@psf.upfronthosting.co.za> Message-ID: <1391206868.32.0.15242179862.issue7325@psf.upfronthosting.co.za> Yury Selivanov added the comment: bump? see also #20267 ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 23:24:27 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 22:24:27 +0000 Subject: [issue12691] tokenize.untokenize is broken In-Reply-To: <1312496489.46.0.0769213514508.issue12691@psf.upfronthosting.co.za> Message-ID: <1391207067.08.0.151124496999.issue12691@psf.upfronthosting.co.za> Yury Selivanov added the comment: bump? ---------- nosy: +yselivanov versions: +Python 3.4 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 23:26:19 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 22:26:19 +0000 Subject: [issue14515] tempfile.TemporaryDirectory documented as returning object but returns name In-Reply-To: <1333678068.19.0.790451967958.issue14515@psf.upfronthosting.co.za> Message-ID: <1391207179.82.0.65110787011.issue14515@psf.upfronthosting.co.za> Yury Selivanov added the comment: bump? ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 23:27:27 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 22:27:27 +0000 Subject: [issue17444] multiprocessing.cpu_count() should use hw.availcpu on Mac OS X In-Reply-To: <1363518970.43.0.663033914557.issue17444@psf.upfronthosting.co.za> Message-ID: <1391207247.91.0.817764338302.issue17444@psf.upfronthosting.co.za> Yury Selivanov added the comment: bump? ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 23:28:33 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 22:28:33 +0000 Subject: [issue14965] super() and property inheritance behavior In-Reply-To: <1338433441.66.0.975494137492.issue14965@psf.upfronthosting.co.za> Message-ID: <1391207313.95.0.0260235008797.issue14965@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- versions: +Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 23:35:58 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 22:35:58 +0000 Subject: [issue18805] ipaddress netmask/hostmask parsing bugs In-Reply-To: <1377131918.88.0.806374780855.issue18805@psf.upfronthosting.co.za> Message-ID: <1391207758.5.0.239458122973.issue18805@psf.upfronthosting.co.za> Yury Selivanov added the comment: bump? ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 23:37:12 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 22:37:12 +0000 Subject: [issue19157] ipaddress.IPv6Network.hosts function omits network and broadcast addresses In-Reply-To: <1380840691.26.0.505062253334.issue19157@psf.upfronthosting.co.za> Message-ID: <1391207832.48.0.620968817593.issue19157@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 23:40:03 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 22:40:03 +0000 Subject: [issue10544] yield expression inside generator expression does nothing In-Reply-To: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za> Message-ID: <1391208003.01.0.0279519693222.issue10544@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- versions: +Python 3.5 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 23:41:34 2014 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 31 Jan 2014 22:41:34 +0000 Subject: [issue20467] Confusing wording about __init__ Message-ID: <1391208094.95.0.178232051767.issue20467@psf.upfronthosting.co.za> New submission from Mark Lawrence: I found the wording here http://docs.python.org/3/reference/datamodel.html#object.__init__ very confusing as it implies that __init__ is the class constructor and not the initialiser. Specifically it says "As a special constraint on constructors, no value may be returned; doing so will cause a TypeError to be raised at runtime". Can we please have the wording changed so that it states exactly what this method does? Possibly changes are also needed in the equivalent section for __new__. ---------- assignee: docs at python components: Documentation messages: 209843 nosy: BreamoreBoy, docs at python priority: normal severity: normal status: open title: Confusing wording about __init__ type: enhancement versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 23:50:41 2014 From: report at bugs.python.org (Kurt Rose) Date: Fri, 31 Jan 2014 22:50:41 +0000 Subject: [issue20468] resource module documentation is incorrect Message-ID: <1391208641.83.0.141932054107.issue20468@psf.upfronthosting.co.za> New submission from Kurt Rose: The documentation in the resource module for get_page_size() is incorrect. resource.getpagesize() Returns the number of bytes in a system page. (This need not be the same as the hardware page size.) This function is useful for determining the number of bytes of memory a process is using. The third element of the tuple returned by getrusage() describes memory usage in pages; multiplying by page size produces number of bytes. On Linux, the value returned in getrusage().ru_maxrss is in kilobytes. On OS-X it is in bytes. Ideally, this could be put into the documentation, but at least remove the inaccurate recommendation to multiply maxrss by page size :-) ---------- assignee: ronaldoussoren components: Macintosh messages: 209844 nosy: Kurt.Rose, ronaldoussoren priority: normal severity: normal status: open title: resource module documentation is incorrect versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 23:58:15 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 22:58:15 +0000 Subject: [issue2226] Small _abcoll Bugs / Oddities In-Reply-To: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za> Message-ID: <1391209095.97.0.261183103137.issue2226@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 23:58:23 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 22:58:23 +0000 Subject: [issue8743] set() operators don't work with collections.Set instances In-Reply-To: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za> Message-ID: <1391209103.62.0.912239204777.issue8743@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jan 31 23:59:21 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 31 Jan 2014 22:59:21 +0000 Subject: [issue12971] os.isdir() should contain skiplinks=False in arguments In-Reply-To: <1315920238.53.0.290032380593.issue12971@psf.upfronthosting.co.za> Message-ID: <1391209161.46.0.189272377553.issue12971@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________