From report at bugs.python.org Mon Dec 1 00:27:42 2014 From: report at bugs.python.org (KHH) Date: Sun, 30 Nov 2014 23:27:42 +0000 Subject: [issue22969] Compile fails with --without-signal-module Message-ID: <1417390062.47.0.624837709681.issue22969@psf.upfronthosting.co.za> New submission from KHH: When compiling with the ./configure --without-signal-module the configure file adds Parser/intrcheck.o to SIGNAL_OBJS, but the corresponding Parser/intercheck.c has been removed from the build tree. Removing the Parser/intrcheck.o causes the build to fail due to undefined references. The error logs are attached. ---------- components: Build files: python-compile-errors.txt messages: 231910 nosy: KHH priority: normal severity: normal status: open title: Compile fails with --without-signal-module type: compile error versions: Python 3.4 Added file: http://bugs.python.org/file37329/python-compile-errors.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 00:31:22 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 30 Nov 2014 23:31:22 +0000 Subject: [issue22935] Disabling SSLv3 support In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za> Message-ID: <1417390282.08.0.987515340092.issue22935@psf.upfronthosting.co.za> Ned Deily added the comment: Clearly we need to support openssl's without SSLv3 so I think some version of this needs to be applied to all branches (preferably in time for 2.7.9, Benjamin?). Kurt, if you haven't already, could you sign the contributor agreement so we can use the patch (https://www.python.org/psf/contrib/contrib-form/)? And I guess it would be nice to generalize the SSLv2 checks as doko suggests. ---------- components: +Build nosy: +benjamin.peterson, ned.deily priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 04:29:42 2014 From: report at bugs.python.org (David Coles) Date: Mon, 01 Dec 2014 03:29:42 +0000 Subject: [issue22970] Cancelling wait() after notification leaves Condition in an inconsistent state Message-ID: <1417404582.01.0.276361050449.issue22970@psf.upfronthosting.co.za> New submission from David Coles: If a task that is waiting on an asyncio.Condition is cancelled after notification but before having successfully reacquired the associated lock, the acquire() will be cancelled causing wait() to return without the lock held (violating wait()'s contract and leaving the program in an inconsistent state). This can be reproduced in cases where there's some contention on the Condition's lock. For example: import asyncio loop = asyncio.get_event_loop() cond = asyncio.Condition() @asyncio.coroutine def cond_wait_timeout(condition, timeout): wait_task = asyncio.async(condition.wait()) loop.call_later(timeout, wait_task.cancel) try: yield from wait_task return True except asyncio.CancelledError: print("Timeout (locked: {0})".format(condition.locked())) return False @asyncio.coroutine def waiter(): yield from cond.acquire() try: print("Wait") if (yield from cond_wait_timeout(cond, 1)): # Cause some lock contention print("Do work") yield from asyncio.sleep(1) finally: cond.release() @asyncio.coroutine def notifier(): # Yield to the waiters yield from asyncio.sleep(0.1) yield from cond.acquire() try: print("Notify") cond.notify_all() finally: cond.release() loop.run_until_complete(asyncio.wait([waiter(), waiter(), notifier()])) The most straightforward fix appears to be just to have wait() retry to acquire the lock, effectively ignoring cancellation at this point (since the condition has already finished waiting and just trying to reacquire the lock before returning). ---------- components: asyncio files: asyncio-fix-wait-cancellation-race.patch keywords: patch messages: 231912 nosy: dcoles, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: Cancelling wait() after notification leaves Condition in an inconsistent state type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file37330/asyncio-fix-wait-cancellation-race.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 09:46:12 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 01 Dec 2014 08:46:12 +0000 Subject: [issue22943] bsddb: test_queue fails on Windows In-Reply-To: <1416958599.21.0.951541238956.issue22943@psf.upfronthosting.co.za> Message-ID: <20141201084608.69787.55843@psf.io> Roundup Robot added the comment: New changeset df17d2b0878f by Serhiy Storchaka in branch '2.7': Issue #22943: bsddb tests are locale independend now. https://hg.python.org/cpython/rev/df17d2b0878f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 09:54:02 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 01 Dec 2014 08:54:02 +0000 Subject: [issue22924] Use of deprecated cgi.escape In-Reply-To: <1416737175.16.0.367831967609.issue22924@psf.upfronthosting.co.za> Message-ID: <20141201085359.55099.81071@psf.io> Roundup Robot added the comment: New changeset f5eb62bdcb1a by Serhiy Storchaka in branch '3.4': Issue #22924: Scripts gprof2html.py and highlight.py now use html.escape() https://hg.python.org/cpython/rev/f5eb62bdcb1a New changeset 8c1d1e861081 by Serhiy Storchaka in branch 'default': Issue #22924: Scripts gprof2html.py and highlight.py now use html.escape() https://hg.python.org/cpython/rev/8c1d1e861081 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 09:54:06 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 01 Dec 2014 08:54:06 +0000 Subject: [issue22943] bsddb: test_queue fails on Windows In-Reply-To: <1416958599.21.0.951541238956.issue22943@psf.upfronthosting.co.za> Message-ID: <1417424046.88.0.506244671629.issue22943@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 09:55:16 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 01 Dec 2014 08:55:16 +0000 Subject: [issue22924] Use of deprecated cgi.escape In-Reply-To: <1416737175.16.0.367831967609.issue22924@psf.upfronthosting.co.za> Message-ID: <1417424116.27.0.438688981212.issue22924@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 09:58:50 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 01 Dec 2014 08:58:50 +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: <1417424330.66.0.157361916105.issue22609@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: So what to do wish UserDict? Should we break backward compatibility and add support for "self" and "dict" keywords as in other dict-like types? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 10:10:48 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 01 Dec 2014 09:10:48 +0000 Subject: [issue22838] Convert re tests to unittest In-Reply-To: <1415639456.54.0.317814729132.issue22838@psf.upfronthosting.co.za> Message-ID: <20141201091040.55123.11690@psf.io> Roundup Robot added the comment: New changeset 21a7a92f4d0c by Serhiy Storchaka in branch '3.4': Issue #22838: All test_re tests now work with unittest test discovery. https://hg.python.org/cpython/rev/21a7a92f4d0c New changeset 258ee94b5bac by Serhiy Storchaka in branch 'default': Issue #22838: All test_re tests now work with unittest test discovery. https://hg.python.org/cpython/rev/258ee94b5bac ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 10:11:47 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 01 Dec 2014 09:11:47 +0000 Subject: [issue22838] Convert re tests to unittest In-Reply-To: <1415639456.54.0.317814729132.issue22838@psf.upfronthosting.co.za> Message-ID: <1417425107.86.0.191569875506.issue22838@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 10:15:24 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 01 Dec 2014 09:15:24 +0000 Subject: [issue21032] Socket leak if HTTPConnection.getresponse() fails In-Reply-To: <1395547547.76.0.268263591219.issue21032@psf.upfronthosting.co.za> Message-ID: <1417425324.13.0.321674016024.issue21032@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What is the status of your contributor agreement Martin? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 10:21:17 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 01 Dec 2014 09:21:17 +0000 Subject: [issue14099] ZipFile.open() should not reopen the underlying file In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za> Message-ID: <1417425677.6.0.672455620894.issue14099@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What your thoughts Benjamin? Should this patch be applied to 2.7.10 (this is not critical for 2.7.9)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 10:23:06 2014 From: report at bugs.python.org (Martin Richard) Date: Mon, 01 Dec 2014 09:23:06 +0000 Subject: [issue21998] asyncio: a new self-pipe should be created in the child process after fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1417425786.04.0.0696534583373.issue21998@psf.upfronthosting.co.za> Martin Richard added the comment: Guido, Currently in my program, I manually remove and then re-adds the reader to the loop in the parent process right after the fork(). I also considered a dirty monkey-patching of remove_reader() and remove_writer() which would act as the original versions but without removing the fds from the epoll object (ensuring I don't get bitten by the same behavior for an other fd). The easiest fix, I think, is indeed to close the selector without unregistering the fds, but I don't know if doing so would have undesired side effects on an other platform than Linux (resources leak, or the close call failing maybe). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 10:27:20 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 01 Dec 2014 09:27:20 +0000 Subject: [issue22578] Add additional attributes to re.error In-Reply-To: <1412772310.32.0.0247834995037.issue22578@psf.upfronthosting.co.za> Message-ID: <20141201092716.84295.28596@psf.io> Roundup Robot added the comment: New changeset 9711c60e3049 by Serhiy Storchaka in branch 'default': Removed unused function linecol() (added in issue #22578 by mistake). https://hg.python.org/cpython/rev/9711c60e3049 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 10:29:49 2014 From: report at bugs.python.org (Martin Richard) Date: Mon, 01 Dec 2014 09:29:49 +0000 Subject: [issue21998] asyncio: a new self-pipe should be created in the child process after fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1417426189.2.0.628098298456.issue21998@psf.upfronthosting.co.za> Martin Richard added the comment: I said something wrong in my previous comment: removing and re-adding the reader callback right after the fork() is obviously subject to a race condition. I'll go for the monkey patching. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 10:37:34 2014 From: report at bugs.python.org (Martin Panter) Date: Mon, 01 Dec 2014 09:37:34 +0000 Subject: [issue21032] Socket leak if HTTPConnection.getresponse() fails In-Reply-To: <1395547547.76.0.268263591219.issue21032@psf.upfronthosting.co.za> Message-ID: <1417426654.11.0.845135668049.issue21032@psf.upfronthosting.co.za> Martin Panter added the comment: Hi Serhiy, I submitted the form online on 22 Nov; just patiently waiting for it to come through now. In the last few minutes I noticed an asterisk has appeared against my name on the bug tracker, so hopefully it is all good now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 10:52:11 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 01 Dec 2014 09:52:11 +0000 Subject: [issue21032] Socket leak if HTTPConnection.getresponse() fails In-Reply-To: <1395547547.76.0.268263591219.issue21032@psf.upfronthosting.co.za> Message-ID: <20141201095208.126790.83875@psf.io> Roundup Robot added the comment: New changeset 561d1d0de518 by Serhiy Storchaka in branch 'default': Issue #21032: Deprecated the use of re.LOCALE flag with str patterns or https://hg.python.org/cpython/rev/561d1d0de518 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 10:53:48 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 01 Dec 2014 09:53:48 +0000 Subject: [issue22407] re.LOCALE is nonsensical for Unicode In-Reply-To: <1410709398.9.0.134852560063.issue22407@psf.upfronthosting.co.za> Message-ID: <1417427628.63.0.874594015155.issue22407@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 11:38:05 2014 From: report at bugs.python.org (Martin Panter) Date: Mon, 01 Dec 2014 10:38:05 +0000 Subject: [issue22407] re.LOCALE is nonsensical for Unicode In-Reply-To: <1410709398.9.0.134852560063.issue22407@psf.upfronthosting.co.za> Message-ID: <1417430285.49.0.996359398394.issue22407@psf.upfronthosting.co.za> Martin Panter added the comment: Looks like revision 561d1d0de518 was to fix this issue, but the NEWS entry has the wrong reference number ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 11:46:15 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 01 Dec 2014 10:46:15 +0000 Subject: [issue22971] test_pickle: "Fatal Python error: Cannot recover from stack overflow." on FreeBSD buildbot Message-ID: <1417430775.66.0.180152689809.issue22971@psf.upfronthosting.co.za> New submission from STINNER Victor: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%203.x/builds/2434/steps/test/logs/stdio ... [127/390] test_trace [128/390] test_imghdr [129/390] test_queue [130/390] test_thread Fatal Python error: Cannot recover from stack overflow. Current thread 0x0000000801407400 (most recent call first): File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/pickletester.py", line 1882 in __getattr__ ... [131/390] test_pickle Traceback (most recent call last): File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/runpy.py", line 170, in _run_module_as_main "__main__", mod_spec) File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/runpy.py", line 85, in _run_code exec(code, run_globals) File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/__main__.py", line 3, in regrtest.main_in_temp_cwd() File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/regrtest.py", line 1564, in main_in_temp_cwd main() File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/regrtest.py", line 738, in main raise Exception("Child error on {}: {}".format(test, result[1])) Exception: Child error on test_pickle: Exit code -6 *** [buildbottest] Error code 1 ---------- components: Tests keywords: buildbot messages: 231925 nosy: haypo priority: normal severity: normal status: open title: test_pickle: "Fatal Python error: Cannot recover from stack overflow." on FreeBSD buildbot versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 11:46:52 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 01 Dec 2014 10:46:52 +0000 Subject: [issue22971] test_pickle: "Fatal Python error: Cannot recover from stack overflow." on FreeBSD buildbot In-Reply-To: <1417430775.66.0.180152689809.issue22971@psf.upfronthosting.co.za> Message-ID: <1417430812.32.0.672203746019.issue22971@psf.upfronthosting.co.za> STINNER Victor added the comment: Can it be related to the issue #22676? ---------- nosy: +pitrou, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 11:49:06 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 01 Dec 2014 10:49:06 +0000 Subject: [issue22407] re.LOCALE is nonsensical for Unicode In-Reply-To: <1410709398.9.0.134852560063.issue22407@psf.upfronthosting.co.za> Message-ID: <1417430946.61.0.194651424696.issue22407@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Indeed. Thank you Martin. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 11:54:00 2014 From: report at bugs.python.org (Andrew Burrows) Date: Mon, 01 Dec 2014 10:54:00 +0000 Subject: [issue22972] Timeout making ajax calls to SimpleHTTPServer from internet explorer Message-ID: <1417431240.84.0.697766622208.issue22972@psf.upfronthosting.co.za> New submission from Andrew Burrows: I have flask webservice running on windows, run up with `app.run()` which works fine from Chrome but when accessed with IE it sometimes fails with a timeout error. I've managed to reproduce the problem without flask which suggests there is (maybe?) some problem in the underlying Python networking code that flask is using. I've attached a simple website that displays the problem using only SimpleHTTPServer. To reproduce the problem unzip the file, cd into the directory and start the server using: python -m SimpleHTTPServer 5001 Then visit http://localhost:5001 in Internet Explorer and it will timeout, usually within the first 20 or 30 ajax calls. I'm using IE11 on windows 7 and python 2.7.8 ---------- components: Windows files: timeout_bug.zip messages: 231928 nosy: Andrew.Burrows, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Timeout making ajax calls to SimpleHTTPServer from internet explorer type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file37331/timeout_bug.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 11:59:16 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 01 Dec 2014 10:59:16 +0000 Subject: [issue22676] _pickle's whichmodule() is slow In-Reply-To: <1413805102.58.0.53710829912.issue22676@psf.upfronthosting.co.za> Message-ID: <1417431556.47.0.367094587664.issue22676@psf.upfronthosting.co.za> STINNER Victor added the comment: This issue may have introduce a regression, please see: Issue #22971: test_pickle: "Fatal Python error: Cannot recover from stack overflow." on FreeBSD buildbot ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 12:16:43 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 01 Dec 2014 11:16:43 +0000 Subject: [issue21032] Socket leak if HTTPConnection.getresponse() fails In-Reply-To: <1395547547.76.0.268263591219.issue21032@psf.upfronthosting.co.za> Message-ID: <20141201111628.116304.22634@psf.io> Roundup Robot added the comment: New changeset f88c00391dd8 by Serhiy Storchaka in branch '2.7': Issue #21032. Fixed socket leak if HTTPConnection.getresponse() fails. https://hg.python.org/cpython/rev/f88c00391dd8 New changeset ba72da4883eb by Serhiy Storchaka in branch '3.4': Issue #21032. Fixed socket leak if HTTPConnection.getresponse() fails. https://hg.python.org/cpython/rev/ba72da4883eb New changeset 62a058c76869 by Serhiy Storchaka in branch 'default': Issue #21032. Fixed socket leak if HTTPConnection.getresponse() fails. https://hg.python.org/cpython/rev/62a058c76869 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 12:16:44 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 01 Dec 2014 11:16:44 +0000 Subject: [issue22407] re.LOCALE is nonsensical for Unicode In-Reply-To: <1410709398.9.0.134852560063.issue22407@psf.upfronthosting.co.za> Message-ID: <20141201111628.116304.34234@psf.io> Roundup Robot added the comment: New changeset abc7fe393016 by Serhiy Storchaka in branch 'default': Fixed issue number in Misc/NEWS for issue #22407. https://hg.python.org/cpython/rev/abc7fe393016 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 12:18:28 2014 From: report at bugs.python.org (ardabro) Date: Mon, 01 Dec 2014 11:18:28 +0000 Subject: [issue22973] hash() function gives the same result for -1 and for -2 argument (==-2) Message-ID: <1417432708.23.0.68936690634.issue22973@psf.upfronthosting.co.za> New submission from ardabro: built-in hash() function cannot be effectively used for integers due to weird behavior for -1 argument: >>> hash(0) 0 >>> hash(-1) -2 # !!!!! >>> hash(-2) -2 >>> hash(-3) -3 >>> ---------- components: Library (Lib) messages: 231932 nosy: ardabro priority: normal severity: normal status: open title: hash() function gives the same result for -1 and for -2 argument (==-2) type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 12:20:30 2014 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 01 Dec 2014 11:20:30 +0000 Subject: [issue22898] segfault during shutdown attempting to log ResourceWarning In-Reply-To: <1416345976.57.0.643107529371.issue22898@psf.upfronthosting.co.za> Message-ID: <1417432830.3.0.955062595251.issue22898@psf.upfronthosting.co.za> Xavier de Gaye added the comment: When tstate->overflowed is already set to 1 before entering PyErr_NormalizeException() to normalize an exception, the following cases may occur: 1) Normalizing a built-in exception => instantiation ok. 2) Normalizing a python exception that fails with a built-in exception => next recursion of PyErr_NormalizeException() ok. 3) Normalizing a python exception that fails with a python exception that fails with a python exception and so on infinitely... => PyObject_Call() never returns and the interpreter aborts with a fatal error when the high warter mark is exceeded, the infinite recursion is in PyObject_Call(). 4) Normalizing a python exception defined in an extension module and the instantiation returns NULL and sets the same exception: a) Without any patch, we get a segfault caused by another bug in PyErr_NormalizeException() at Py_DECREF(*val), just before setting val to PyExc_RecursionErrorInst. This is fixed by changing Py_DECREF(*val) to Py_XDECREF(*val). With the above fix, we get the same abort as the one caused by runtimerror_singleton_2.py, so this is another reproducer of the current issue. b) The test is ok with patch warn_5.patch, and the above fix. c) With patch remove_singleton.patch the interpreter aborts with a fatal error when the high warter mark is exceeded, the infinite recursion is in PyErr_NormalizeException(). Cases 3) and 4) can be tested with runtimerror_singleton_3.py (install mymodule with setup.py for all three test cases in 4). remove_singleton.patch introduces a regression in case c), but IMHO the abort in case c) is consistent with the abort in case 3), they are both related to a more general problem involving the low/high water mark heuristic and described by Antoine in [1]. [1] http://thread.gmane.org/gmane.comp.python.devel/97016 ---------- Added file: http://bugs.python.org/file37332/runtimerror_singleton_3.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 12:20:46 2014 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 01 Dec 2014 11:20:46 +0000 Subject: [issue22898] segfault during shutdown attempting to log ResourceWarning In-Reply-To: <1416345976.57.0.643107529371.issue22898@psf.upfronthosting.co.za> Message-ID: <1417432846.42.0.441315225933.issue22898@psf.upfronthosting.co.za> Changes by Xavier de Gaye : Added file: http://bugs.python.org/file37333/mymodule.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 12:21:08 2014 From: report at bugs.python.org (Xavier de Gaye) Date: Mon, 01 Dec 2014 11:21:08 +0000 Subject: [issue22898] segfault during shutdown attempting to log ResourceWarning In-Reply-To: <1416345976.57.0.643107529371.issue22898@psf.upfronthosting.co.za> Message-ID: <1417432868.26.0.16724241903.issue22898@psf.upfronthosting.co.za> Changes by Xavier de Gaye : Added file: http://bugs.python.org/file37334/setup.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 12:24:01 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 01 Dec 2014 11:24:01 +0000 Subject: [issue21032] Socket leak if HTTPConnection.getresponse() fails In-Reply-To: <1395547547.76.0.268263591219.issue21032@psf.upfronthosting.co.za> Message-ID: <1417433041.38.0.417670434578.issue21032@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Few notes about patches. Check patches for trailing spaces. And it would be more suitable if you provide single patch instead of a couple of patches. I have slightly changed the test, so it checks that the file is actually closed, not lost, The fix LGTM. Thank you for your contribution Martin. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 12:54:13 2014 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 01 Dec 2014 11:54:13 +0000 Subject: [issue22973] hash() function gives the same result for -1 and for -2 argument (==-2) In-Reply-To: <1417432708.23.0.68936690634.issue22973@psf.upfronthosting.co.za> Message-ID: <1417434853.22.0.459851584286.issue22973@psf.upfronthosting.co.za> Eric V. Smith added the comment: hash() is not defined to be unique, so you're always going to have collisions. The behavior of hash() for int that you're seeing is not a bug. There's some background here: http://stackoverflow.com/questions/10130454/why-do-1-and-2-both-hash-to-2-in-python ---------- components: +Interpreter Core -Library (Lib) nosy: +eric.smith resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 13:42:20 2014 From: report at bugs.python.org (Ethan Furman) Date: Mon, 01 Dec 2014 12:42:20 +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: <1417437740.1.0.923594701405.issue22609@psf.upfronthosting.co.za> Ethan Furman added the comment: Fix `self` now, add a warning and single minor cycle deprecation period for 'dict'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 14:38:10 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 01 Dec 2014 13:38:10 +0000 Subject: [issue7665] test_urllib2 and test_ntpath fail if path contains "\" In-Reply-To: <1263142226.0.0.91918347375.issue7665@psf.upfronthosting.co.za> Message-ID: <1417441090.64.0.546926671637.issue7665@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 14:59:00 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 01 Dec 2014 13:59:00 +0000 Subject: [issue22972] Timeout making ajax calls to SimpleHTTPServer from internet explorer In-Reply-To: <1417431240.84.0.697766622208.issue22972@psf.upfronthosting.co.za> Message-ID: <1417442340.87.0.248924414894.issue22972@psf.upfronthosting.co.za> R. David Murray added the comment: Why do you think this is a Python problem? Can you reproduce it without using javascript? Given that it works with other browsers (ie: python has no problem responding to the queries themselves) and javascript is doing the query, I think it would be much more likely to be an IE javascript bug, and hard to see how it could be a Python bug. Also, FYI we prefer people attach text files, not zip files, to the issue. It makes it easier for people to see what you are talking about. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 15:09:44 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 01 Dec 2014 14:09:44 +0000 Subject: [issue20148] Derby: Convert the _sre module to use Argument Clinic In-Reply-To: <1389024268.98.0.254349402597.issue20148@psf.upfronthosting.co.za> Message-ID: <1417442984.74.0.0694031901945.issue20148@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Synchronized with the tip again. ---------- Added file: http://bugs.python.org/file37335/sre_clinic_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 16:30:26 2014 From: report at bugs.python.org (Matthias Klose) Date: Mon, 01 Dec 2014 15:30:26 +0000 Subject: =?utf-8?b?W2lzc3VlMjI5NjZdIHB5X2NvbXBpbGU6IGZvby5iYXIucHkg4oaSIF9fcHlj?= =?utf-8?q?ache=5F=5F/foo=2Ecpython-34=2Epyc?= In-Reply-To: <1417256202.79.0.40494755597.issue22966@psf.upfronthosting.co.za> Message-ID: <1417447826.66.0.403733448405.issue22966@psf.upfronthosting.co.za> Matthias Klose added the comment: seen as well with 3.3 ---------- keywords: +3.3regression, 3.4regression nosy: +doko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 16:35:02 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 01 Dec 2014 15:35:02 +0000 Subject: [issue21998] asyncio: a new self-pipe should be created in the child process after fork In-Reply-To: <1417426189.2.0.628098298456.issue21998@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: How about not doing anything in the parent but in the child, closing the selector and then the event loop? On Mon, Dec 1, 2014 at 1:29 AM, Martin Richard wrote: > > Martin Richard added the comment: > > I said something wrong in my previous comment: removing and re-adding the > reader callback right after the fork() is obviously subject to a race > condition. > > I'll go for the monkey patching. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 16:54:58 2014 From: report at bugs.python.org (Kurt Roeckx) Date: Mon, 01 Dec 2014 15:54:58 +0000 Subject: [issue22935] Disabling SSLv3 support In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za> Message-ID: <1417449298.52.0.862367459434.issue22935@psf.upfronthosting.co.za> Kurt Roeckx added the comment: I've just signed the contributor agreement ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 16:59:28 2014 From: report at bugs.python.org (Dmitry Kazakov) Date: Mon, 01 Dec 2014 15:59:28 +0000 Subject: [issue22974] Make traceback functions support negative limits Message-ID: <1417449568.58.0.119614287353.issue22974@psf.upfronthosting.co.za> New submission from Dmitry Kazakov: This is a complete implementation of negative limits for functions from traceback module (see this proposal - https://mail.python.org/pipermail/python-ideas/2014-August/029105.html). I also added some tests. ---------- components: Library (Lib) files: traceback_patch_2.diff keywords: patch messages: 231943 nosy: vlth priority: normal severity: normal status: open title: Make traceback functions support negative limits type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file37336/traceback_patch_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 17:00:16 2014 From: report at bugs.python.org (Dmitry Kazakov) Date: Mon, 01 Dec 2014 16:00:16 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <1417449616.91.0.242810169511.issue22619@psf.upfronthosting.co.za> Changes by Dmitry Kazakov : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 17:06:05 2014 From: report at bugs.python.org (Matthias Klose) Date: Mon, 01 Dec 2014 16:06:05 +0000 Subject: =?utf-8?b?W2lzc3VlMjI5NjZdIHB5X2NvbXBpbGU6IGZvby5iYXIucHkg4oaSIF9fcHlj?= =?utf-8?q?ache=5F=5F/foo=2Ecpython-34=2Epyc?= In-Reply-To: <1417256202.79.0.40494755597.issue22966@psf.upfronthosting.co.za> Message-ID: <1417449965.26.0.966861598422.issue22966@psf.upfronthosting.co.za> Matthias Klose added the comment: proposed patch: diff -r 8dacb1a21793 Lib/importlib/_bootstrap.py --- a/Lib/importlib/_bootstrap.py Fri Nov 28 13:15:41 2014 +0100 +++ b/Lib/importlib/_bootstrap.py Mon Dec 01 17:05:00 2014 +0100 @@ -453,7 +453,7 @@ else: suffixes = OPTIMIZED_BYTECODE_SUFFIXES head, tail = _path_split(path) - base_filename, sep, _ = tail.partition('.') + base_filename, sep, _ = tail.rpartition('.') tag = sys.implementation.cache_tag if tag is None: raise NotImplementedError('sys.implementation.cache_tag is None') ---------- stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 17:17:04 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 01 Dec 2014 16:17:04 +0000 Subject: [issue22974] Make traceback functions support negative limits In-Reply-To: <1417449568.58.0.119614287353.issue22974@psf.upfronthosting.co.za> Message-ID: <1417450624.19.0.433412505034.issue22974@psf.upfronthosting.co.za> R. David Murray added the comment: This looks like a duplicate of issue 22619. Were you under the impression you needed to open a new issue just in order to update your patch? You would be better off posting the patch to issue 22619 and closing this one, unless I'm missing something. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 17:31:41 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 01 Dec 2014 16:31:41 +0000 Subject: =?utf-8?b?W2lzc3VlMjI5NjZdIHB5X2NvbXBpbGU6IGZvby5iYXIucHkg4oaSIF9fcHlj?= =?utf-8?q?ache=5F=5F/foo=2Ecpython-34=2Epyc?= In-Reply-To: <1417256202.79.0.40494755597.issue22966@psf.upfronthosting.co.za> Message-ID: <1417451501.47.0.568676056211.issue22966@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I'll take this one. I think it should be easy to add a test case, which I'll do. ---------- assignee: -> barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 17:32:50 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 01 Dec 2014 16:32:50 +0000 Subject: =?utf-8?b?W2lzc3VlMjI5NjZdIHB5X2NvbXBpbGU6IGZvby5iYXIucHkg4oaSIF9fcHlj?= =?utf-8?q?ache=5F=5F/foo=2Ecpython-34=2Epyc?= In-Reply-To: <1417256202.79.0.40494755597.issue22966@psf.upfronthosting.co.za> Message-ID: <1417451570.79.0.147584668289.issue22966@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 17:43:35 2014 From: report at bugs.python.org (Elazar Gershuni) Date: Mon, 01 Dec 2014 16:43:35 +0000 Subject: [issue22975] Crosses initialization? Message-ID: <1417452215.15.0.340440438084.issue22975@psf.upfronthosting.co.za> New submission from Elazar Gershuni: In Objects/unicodeobject.c, What happens in these lines? case PyUnicode_4BYTE_KIND: { \ Py_UCS4 * to_ = (Py_UCS4 *)((data)) + (start); \ for (; i_ < (length); ++i_, ++to_) *to_ = (value); \ break; \ default: assert(0); \ } \ // Closing earlier case block. Should be one line up? } \ // Closing the switch statement (I got error here trying to compile Python in g++). ---------- components: Build hgrepos: 282 messages: 231947 nosy: elazar priority: normal severity: normal status: open title: Crosses initialization? type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 17:44:28 2014 From: report at bugs.python.org (Elazar Gershuni) Date: Mon, 01 Dec 2014 16:44:28 +0000 Subject: [issue22975] Crosses initialization? In-Reply-To: <1417452215.15.0.340440438084.issue22975@psf.upfronthosting.co.za> Message-ID: <1417452268.56.0.302637814161.issue22975@psf.upfronthosting.co.za> Changes by Elazar Gershuni : ---------- hgrepos: -282 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 17:44:51 2014 From: report at bugs.python.org (Elazar Gershuni) Date: Mon, 01 Dec 2014 16:44:51 +0000 Subject: [issue22975] Crosses initialization? In-Reply-To: <1417452215.15.0.340440438084.issue22975@psf.upfronthosting.co.za> Message-ID: <1417452291.25.0.819291379851.issue22975@psf.upfronthosting.co.za> Elazar Gershuni added the comment: https://hg.python.org/cpython/file/62a058c76869/Objects/unicodeobject.c#l9884 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 17:52:03 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 01 Dec 2014 16:52:03 +0000 Subject: [issue22975] Crosses initialization? In-Reply-To: <1417452215.15.0.340440438084.issue22975@psf.upfronthosting.co.za> Message-ID: <1417452723.34.0.762565232507.issue22975@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 17:59:45 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 01 Dec 2014 16:59:45 +0000 Subject: [issue22975] Crosses initialization? In-Reply-To: <1417452215.15.0.340440438084.issue22975@psf.upfronthosting.co.za> Message-ID: <20141201165921.55115.63974@psf.io> Roundup Robot added the comment: New changeset 15a1070a2c66 by Serhiy Storchaka in branch '3.4': Issue #22975: Close block at right place. https://hg.python.org/cpython/rev/15a1070a2c66 New changeset e1afae23dfcd by Serhiy Storchaka in branch 'default': Issue #22975: Close block at right place. https://hg.python.org/cpython/rev/e1afae23dfcd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 18:05:22 2014 From: report at bugs.python.org (Dmitry Kazakov) Date: Mon, 01 Dec 2014 17:05:22 +0000 Subject: [issue22974] Make traceback functions support negative limits In-Reply-To: <1417449568.58.0.119614287353.issue22974@psf.upfronthosting.co.za> Message-ID: <1417453522.29.0.946198358411.issue22974@psf.upfronthosting.co.za> Dmitry Kazakov added the comment: Indeed, this is an exact duplicate, but I feel like that issue is an embarrassment: too many unnecessary actions, bad patches, and most of messages are totally useless. I wanted to start over for once, so I closed that issue. Pardon my initial ignorance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 18:08:35 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 01 Dec 2014 17:08:35 +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: <1417453715.61.0.071363110513.issue22609@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: serhiy.storchaka -> rhettinger priority: high -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 18:32:56 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 01 Dec 2014 17:32:56 +0000 Subject: [issue22975] Crosses initialization? In-Reply-To: <1417452215.15.0.340440438084.issue22975@psf.upfronthosting.co.za> Message-ID: <1417455176.75.0.738852227879.issue22975@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is correct syntax in C. But I agree that for clarity it should be changed. However note that building Python with g++ is not supported. There are many other things about which C compiler is lenient but which cause syntax error in C++ compiler. And resulting binary, if you will built it, will be binary incompatible with Python binary compiled with C compiler. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 18:57:26 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 01 Dec 2014 17:57:26 +0000 Subject: [issue20335] bytes constructor accepts more than one argument even if the first one is not a string In-Reply-To: <1390340737.95.0.677221459573.issue20335@psf.upfronthosting.co.za> Message-ID: <1417456646.42.0.16260992958.issue20335@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch with tests. ---------- stage: test needed -> patch review Added file: http://bugs.python.org/file37337/issue20335.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 21:22:12 2014 From: report at bugs.python.org (Chris Rebert) Date: Mon, 01 Dec 2014 20:22:12 +0000 Subject: [issue21557] os.popen & os.system lack shell-related security warnings In-Reply-To: <1400794428.31.0.170474236819.issue21557@psf.upfronthosting.co.za> Message-ID: <1417465332.61.0.494972634705.issue21557@psf.upfronthosting.co.za> Chris Rebert added the comment: Here is a patch that adds the necessary warnings from issue 7950. Please review it when you get a chance. ---------- keywords: +patch Added file: http://bugs.python.org/file37338/fix-21557.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 21:46:34 2014 From: report at bugs.python.org (Chris Rebert) Date: Mon, 01 Dec 2014 20:46:34 +0000 Subject: [issue22356] mention explicitly that stdlib assumes gmtime(0) epoch is 1970 In-Reply-To: <1410110444.5.0.966357232963.issue22356@psf.upfronthosting.co.za> Message-ID: <1417466794.79.0.570243222504.issue22356@psf.upfronthosting.co.za> Chris Rebert added the comment: Ping. This small patch has been waiting nearly 3 months for a review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 22:02:13 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 01 Dec 2014 21:02:13 +0000 Subject: [issue22356] mention explicitly that stdlib assumes gmtime(0) epoch is 1970 In-Reply-To: <1410110444.5.0.966357232963.issue22356@psf.upfronthosting.co.za> Message-ID: <1417467733.6.0.282110570513.issue22356@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 22:32:52 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 01 Dec 2014 21:32:52 +0000 Subject: [issue22356] mention explicitly that stdlib assumes gmtime(0) epoch is 1970 In-Reply-To: <1410110444.5.0.966357232963.issue22356@psf.upfronthosting.co.za> Message-ID: <1417469572.79.0.885593324312.issue22356@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I don't like the proposed note. 1. It is not the job of the time module documentation to warn about "many functions in the stdlib." What are these functions, BTW? 2. What is "calendar time in POSIX encoding"? This sounds like what time.asctime() returns. I think an improvement would be to spell Epoch with a capital E and define it as "The time zero hours, zero minutes, zero seconds, on January 1, 1970 Coordinated Universal Time (UTC)." See . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 22:59:18 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 01 Dec 2014 21:59:18 +0000 Subject: =?utf-8?b?W2lzc3VlMjI5NjZdIHB5X2NvbXBpbGU6IGZvby5iYXIucHkg4oaSIF9fcHlj?= =?utf-8?q?ache=5F=5F/foo=2Ecpython-34=2Epyc?= In-Reply-To: <1417256202.79.0.40494755597.issue22966@psf.upfronthosting.co.za> Message-ID: <1417471158.59.0.961113214333.issue22966@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Not counting importlib.h, here's the diff I'm going to apply to 3.4. It passes all the existing tests and includes a new test for this behavior. ---------- Added file: http://bugs.python.org/file37339/22966.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 23:36:03 2014 From: report at bugs.python.org (Akira Li) Date: Mon, 01 Dec 2014 22:36:03 +0000 Subject: [issue22356] mention explicitly that stdlib assumes gmtime(0) epoch is 1970 In-Reply-To: <1417469572.79.0.885593324312.issue22356@psf.upfronthosting.co.za> (Alexander Belopolsky's message of "Mon, 01 Dec 2014 21:32:52 +0000") Message-ID: <87egsj9eyn.fsf@gmail.com> Akira Li added the comment: > Alexander Belopolsky added the comment: > > 1. It is not the job of the time module documentation to warn about > "many functions in the stdlib." What are these functions, BTW? The e-mail linked in the first message of this issue msg226539 enumerates some of the functions: https://mail.python.org/pipermail/python-ideas/2014-September/029228.html > 2. What is "calendar time in POSIX encoding"? This sounds like what time.asctime() returns. It is the language used by C standard for time() function: The time function determines the current calendar time. The encoding of the value is unspecified. > I think an improvement would be to spell Epoch with a capital E and > define it as "The time zero hours, zero minutes, zero seconds, on > January 1, 1970 Coordinated Universal Time (UTC)." See > . > The word *epoch* (lowercase) is used by C standard. It is not enough to say that time module uses POSIX epoch (Epoch) e.g., a machine may use "right" zoneinfo (the same epoch year 1970) but the timestamp for the same UTC time are different by number of leap seconds (10+25 since 2012). POSIX encoding implies that the formula works: utc_time = datetime(1970, 1, 1) + timedelta(seconds=posix_timestamp) if time.time() doesn't return posix_timestamp than "many functions in the stdlib" will break. It is possible to inspect all stdlib functions that use time module and determine for some of them whether they will break if gmtime(0) is not 1970 or "right" zoneinfo is used or any non-POSIX time encoding is used. But it is hard to maintain such a list because any future code change may affect the behavior. I prefer a vague statement ("many functions") over a possible lie (the documentation shouldn't make promises that the implementation can't keep). POSIX language is (intentionally) vague and avoids SI seconds vs. UT1 (mean solar) seconds distinction. I don't consider systems where "seconds" doesn't mean SI seconds used by UTC time scale. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 1 23:46:42 2014 From: report at bugs.python.org (Demian Brecht) Date: Mon, 01 Dec 2014 22:46:42 +0000 Subject: [issue21557] os.popen & os.system lack shell-related security warnings In-Reply-To: <1400794428.31.0.170474236819.issue21557@psf.upfronthosting.co.za> Message-ID: <1417474002.88.0.975188658858.issue21557@psf.upfronthosting.co.za> Demian Brecht added the comment: Left a comment in Rietveld. ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 00:11:08 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 01 Dec 2014 23:11:08 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1417475468.72.0.0815975976078.issue18967@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I would like fixing NEWS to be the top infrastructure improvement project, as it is my biggest time waster, and certainly the most obnoxious. It definite makes working on Idle less pleasant. Since an empty 3.4.2a1 section was added to 3.4 NEWS, after 3.4.1 was released, Idle news items always fail to merge *even when there is no real conflict*. I think the problem is the offset of hundred of lines (now a thousand) between the position in the 3.4 file and the position in the 3.5 file. The hg merge jams the Idle entry somewhere in the middle of the Library section, creating spurious and bizarre-looking merge 'conflicts', instead of looking far enough down in 3.5 NEWS to find the proper context for successful insertion. I am not the only person this happens to, as the same should be true for all the other sections that come after the Library section. A couple of months ago, someone pushed a post-push patch to remove artifacts not properly removed before the original push. Today I just removed what looked like an artifact from a Demo news item. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 00:13:23 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 01 Dec 2014 23:13:23 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1417475468.72.0.0815975976078.issue18967@psf.upfronthosting.co.za> Message-ID: <547CF611.80102@free.fr> Antoine Pitrou added the comment: Le 02/12/2014 00:11, Terry J. Reedy a ?crit : > > Terry J. Reedy added the comment: > > I would like fixing NEWS to be the top infrastructure improvement > project, as it is my biggest time waster, and certainly the most > obnoxious. It definite makes working on Idle less pleasant. You could pair with Pierre-Yves David: https://mail.python.org/pipermail/python-dev/2014-December/137393.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 00:14:12 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 01 Dec 2014 23:14:12 +0000 Subject: [issue18053] Add checks for Misc/NEWS in make patchcheck In-Reply-To: <1369453600.75.0.470507945427.issue18053@psf.upfronthosting.co.za> Message-ID: <1417475652.67.0.121267319625.issue18053@psf.upfronthosting.co.za> Terry J. Reedy added the comment: To me, the line about a NEWS entry is useless noise. I would prefer that it be removed entirely. If it is kept, then leave it alone and close this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 00:15:18 2014 From: report at bugs.python.org (Demian Brecht) Date: Mon, 01 Dec 2014 23:15:18 +0000 Subject: [issue22974] Make traceback functions support negative limits In-Reply-To: <1417449568.58.0.119614287353.issue22974@psf.upfronthosting.co.za> Message-ID: <1417475718.98.0.717393092709.issue22974@psf.upfronthosting.co.za> Demian Brecht added the comment: It's generally better to keep everything in one issue in order to preserve history and avoid confusion as you've now found :). I'd suggest closing this one and adding the patch to the initial report. Keeping history intact is important for reviewers. Absolutely no need for embarrassment, we all start somewhere and have to learn processes and such along the way :) ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 00:17:54 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 01 Dec 2014 23:17:54 +0000 Subject: =?utf-8?b?W2lzc3VlMjI5NjZdIHB5X2NvbXBpbGU6IGZvby5iYXIucHkg4oaSIF9fcHlj?= =?utf-8?q?ache=5F=5F/foo=2Ecpython-34=2Epyc?= In-Reply-To: <1417256202.79.0.40494755597.issue22966@psf.upfronthosting.co.za> Message-ID: <20141201231738.116302.47688@psf.io> Roundup Robot added the comment: New changeset 269bf37a57a1 by Barry Warsaw in branch '3.4': - Issue #22966: Fix __pycache__ pyc file name clobber when pyc_compile is https://hg.python.org/cpython/rev/269bf37a57a1 New changeset 3b3ba38d503a by Barry Warsaw in branch '3.4': - Issue #22966: Fix __pycache__ pyc file name clobber when pyc_compile is https://hg.python.org/cpython/rev/3b3ba38d503a New changeset 25113281d543 by Barry Warsaw in branch 'default': - Issue #22966: Fix __pycache__ pyc file name clobber when pyc_compile is https://hg.python.org/cpython/rev/25113281d543 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 00:18:03 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 01 Dec 2014 23:18:03 +0000 Subject: [issue22356] mention explicitly that stdlib assumes gmtime(0) epoch is 1970 In-Reply-To: <1410110444.5.0.966357232963.issue22356@psf.upfronthosting.co.za> Message-ID: <1417475883.55.0.627965515414.issue22356@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: In the context of Python library documentation, the word "encoding" strongly suggests that you are dealing with string/bytes. The situation may be different in C. If you want to refer to something that is defined by the POSIX standard you should use the words that can actually be found in that standard. When I search for "encoding" at , I get crypt - string encoding function (CRYPT) encrypt - encoding function (CRYPT) setkey - set encoding key (CRYPT) and nothing related to time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 00:19:33 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 01 Dec 2014 23:19:33 +0000 Subject: [issue12987] Demo/scripts/newslist.py has non-free licensing terms In-Reply-To: <1316106376.14.0.821549088904.issue12987@psf.upfronthosting.co.za> Message-ID: <1417475973.7.0.588107893384.issue12987@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The windows installer does not install the demo directory. *nix distributions do what they want. I think it too late to change the 2.7 repository. ---------- nosy: +terry.reedy resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 00:19:48 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 01 Dec 2014 23:19:48 +0000 Subject: =?utf-8?b?W2lzc3VlMjI5NjZdIHB5X2NvbXBpbGU6IGZvby5iYXIucHkg4oaSIF9fcHlj?= =?utf-8?q?ache=5F=5F/foo=2Ecpython-34=2Epyc?= In-Reply-To: <1417256202.79.0.40494755597.issue22966@psf.upfronthosting.co.za> Message-ID: <1417475988.87.0.537036005332.issue22966@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 00:20:15 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 01 Dec 2014 23:20:15 +0000 Subject: [issue22676] _pickle's whichmodule() is slow In-Reply-To: <1413805102.58.0.53710829912.issue22676@psf.upfronthosting.co.za> Message-ID: <20141201232013.126792.33576@psf.io> Roundup Robot added the comment: New changeset 3e3bec66409c by Antoine Pitrou in branch 'default': Fix uninitialized variable after #22676. https://hg.python.org/cpython/rev/3e3bec66409c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 00:20:33 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 01 Dec 2014 23:20:33 +0000 Subject: [issue22676] _pickle's whichmodule() is slow In-Reply-To: <1413805102.58.0.53710829912.issue22676@psf.upfronthosting.co.za> Message-ID: <1417476033.1.0.590349551301.issue22676@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 00:21:08 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 01 Dec 2014 23:21:08 +0000 Subject: [issue22969] Compile fails with --without-signal-module In-Reply-To: <1417390062.47.0.624837709681.issue22969@psf.upfronthosting.co.za> Message-ID: <1417476068.69.0.80928788723.issue22969@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 00:24:18 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 01 Dec 2014 23:24:18 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1417476258.45.0.586973791796.issue18967@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Good idea. I will send him a note. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 00:31:10 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 01 Dec 2014 23:31:10 +0000 Subject: [issue12987] Demo/scripts/newslist.py has non-free licensing terms In-Reply-To: <1316106376.14.0.821549088904.issue12987@psf.upfronthosting.co.za> Message-ID: <1417476670.0.0.348702050962.issue12987@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +barry, doko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 00:33:35 2014 From: report at bugs.python.org (Akira Li) Date: Mon, 01 Dec 2014 23:33:35 +0000 Subject: [issue22356] mention explicitly that stdlib assumes gmtime(0) epoch is 1970 In-Reply-To: <1417475883.55.0.627965515414.issue22356@psf.upfronthosting.co.za> (Alexander Belopolsky's message of "Mon, 01 Dec 2014 23:18:03 +0000") Message-ID: <87a9379caq.fsf@gmail.com> Akira Li added the comment: > Alexander Belopolsky added the comment: > > In the context of Python library documentation, the word "encoding" > strongly suggests that you are dealing with string/bytes. The > situation may be different in C. If you want to refer to something > that is defined by the POSIX standard you should use the words that > can actually be found in that standard. > > When I search for "encoding" at , I get > > crypt - string encoding function (CRYPT) > encrypt - encoding function (CRYPT) > setkey - set encoding key (CRYPT) > > and nothing related to time. > I've provide the direct quote from *C* standard in my previous message msg231957: > 2. What is "calendar time in POSIX encoding"? This sounds like what time.asctime() returns. It is the language used by C standard for time() function: The time function determines the current calendar time. The encoding of the value is unspecified. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <- from the C standard notice the word *encoding* in the quote. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 01:07:12 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 02 Dec 2014 00:07:12 +0000 Subject: [issue22356] mention explicitly that stdlib assumes gmtime(0) epoch is 1970 In-Reply-To: <1410110444.5.0.966357232963.issue22356@psf.upfronthosting.co.za> Message-ID: <1417478832.05.0.394256656764.issue22356@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > It is possible to inspect all stdlib functions that use time module and > determine for some of them whether they will break if gmtime(0) is not > 1970 or "right" zoneinfo is used or any non-POSIX time encoding is > used. But it is hard to maintain such a list because any future code > change may affect the behavior. Let's not confuse the issue of gmtime(0) not being 1970-01-01T00 and localtime() expecting non-POSIX time_t. Since gmtime(0) is the same on all platforms supported by Python, it is a fair game to rely on this fact in Python code. The issue of "right" zoneinfo is different: at least two major Python platforms (OS X and Linux) can be configured in a non-POSIX way. The decision not to support these configurations in the datetime module was deliberate, but some partial support can be added. For example, datetime.astimezone() cannot work correctly in the "right" timezone because datetime.second cannot be 60, but if it returns values that are off by some 20 seconds in other times, I would call it a bug, but many will disagree. I don't know how popular configurations with right timezones are, but testing Python stdlib in those configurations can only help the overall stdlib quality. (Unfortunately, at the moment we have have very few tests even for the mainstream timezones such as Europe/Moscow.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 01:12:52 2014 From: report at bugs.python.org (Demian Brecht) Date: Tue, 02 Dec 2014 00:12:52 +0000 Subject: [issue22931] cookies with square brackets in value In-Reply-To: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za> Message-ID: <1417479172.54.0.464143391797.issue22931@psf.upfronthosting.co.za> Demian Brecht added the comment: Err, sorry, I entirely misunderstood the problem. The invalid characters are correct ([ = 5B, which indeed is illegal, I wasn't paying close enough attention to the hex values in the ABNF). It's the fact that the valid key/value pairs after the invalid one are ignored. I'll dig into the RFC and see if there's an expected behavior here and whether or not it's currently handled as expected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 01:38:57 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 02 Dec 2014 00:38:57 +0000 Subject: [issue22356] mention explicitly that stdlib assumes gmtime(0) epoch is 1970 In-Reply-To: <1410110444.5.0.966357232963.issue22356@psf.upfronthosting.co.za> Message-ID: <1417480737.76.0.402866431002.issue22356@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > I've provide the direct quote from *C* standard ... I understand that C standard uses the word "encoding", but it does so for a reason that is completely unrelated to the choice of epoch. "Encoding" is how the bytes in memory should be interpreted as "number of seconds" or some other notion of time. For, example "two's complement little-endian 32-bit signed int" is an example of valid time_t encoding, another example would be IEEE 754 big-endian 64-bit double. Note that these choices are valid for both C and POSIX standards. If you google for your phrase "time in POSIX encoding", this issue is the only hit. This strongly suggests that your choice of words is not the most natural. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 02:12:25 2014 From: report at bugs.python.org (Demian Brecht) Date: Tue, 02 Dec 2014 01:12:25 +0000 Subject: [issue22931] cookies with square brackets in value In-Reply-To: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za> Message-ID: <1417482745.94.0.98067043829.issue22931@psf.upfronthosting.co.za> Demian Brecht added the comment: Now I've confused myself and my first impression was correct. For some reason, my brain was thinking "%x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E" was the exclusion list for some reason (which is obviously horribly wrong). So my first observation was correct in that they should simply be added to the valid character list and I'll get a patch together for that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 03:06:46 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 02 Dec 2014 02:06:46 +0000 Subject: =?utf-8?b?W2lzc3VlMjI5NjZdIHB5X2NvbXBpbGU6IGZvby5iYXIucHkg4oaSIF9fcHlj?= =?utf-8?q?ache=5F=5F/foo=2Ecpython-34=2Epyc?= In-Reply-To: <1417256202.79.0.40494755597.issue22966@psf.upfronthosting.co.za> Message-ID: <1417486006.25.0.8829795991.issue22966@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 03:23:48 2014 From: report at bugs.python.org (Demian Brecht) Date: Tue, 02 Dec 2014 02:23:48 +0000 Subject: [issue22931] cookies with square brackets in value In-Reply-To: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za> Message-ID: <1417487028.7.0.433889068501.issue22931@psf.upfronthosting.co.za> Demian Brecht added the comment: Attached patch to fix the issue as reported. Something interesting that came out of this though is that due to the regex expression, if there's an invalid character in one of the cookie-octets, the rest of the cookie is ignored. I would assume that it should either a) ignore the entire cookie string or b) ignore the invalid cookie pair and accept valid pairs following. I've been unable to find that defined in any of the RFCs though. ---------- keywords: +patch Added file: http://bugs.python.org/file37340/issue22931.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 04:36:49 2014 From: report at bugs.python.org (Dan Mick) Date: Tue, 02 Dec 2014 03:36:49 +0000 Subject: [issue21963] 2.7.8 backport of Issue1856 (avoid daemon thread problems at shutdown) breaks ceph In-Reply-To: <1405112765.87.0.0636941236839.issue21963@psf.upfronthosting.co.za> Message-ID: <1417491409.55.0.230817919867.issue21963@psf.upfronthosting.co.za> Dan Mick added the comment: So, finally got to a Fedora21 beta to try this out today; the immediate problem, as identified by Joe Julian, is the shutdown() call in the __del__ method of Rados. Presumably something about object destructors is clashing with starting new threads; the hang occurs with a gdb backtrace like so: 1710 in sem_wait () from /lib64/libpthread.so.0 #1 0x00007fad36fbce75 in PyThread_acquire_lock () from /lib64/libpython2.7.so.1.0 #2 0x00007fad36fc0c82 in lock_PyThread_acquire_lock () from /lib64/libpython2.7.so.1.0 #3 0x00007fad36f91ade in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0 #4 0x00007fad36f92490 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0 #5 0x00007fad36f90b74 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0 #6 0x00007fad36f92490 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0 #7 0x00007fad36f90b74 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0 #8 0x00007fad36f90c76 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0 #9 0x00007fad36f92490 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0 #10 0x00007fad36f90b74 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0 #11 0x00007fad36f90c76 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0 #12 0x00007fad36f92490 in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0 #13 0x00007fad36f1e6dc in function_call () from /lib64/libpython2.7.so.1.0 #14 0x00007fad36ef98d3 in PyObject_Call () from /lib64/libpython2.7.so.1.0 #15 0x00007fad36f087e5 in instancemethod_call () from /lib64/libpython2.7.so.1.0 #16 0x00007fad36ef98d3 in PyObject_Call () from /lib64/libpython2.7.so.1.0 #17 0x00007fad36f8b557 in PyEval_CallObjectWithKeywords () from /lib64/libpython2.7.so.1.0 #18 0x00007fad36f5082c in slot_tp_del () from /lib64/libpython2.7.so.1.0 #19 0x00007fad36f4b88a in subtype_dealloc () from /lib64/libpython2.7.so.1.0 #20 0x00007fad36f2e1ff in insertdict_by_entry () from /lib64/libpython2.7.so.1.0 #21 0x00007fad36f2fcc0 in dict_set_item_by_hash_or_entry () from /lib64/libpython2.7.so.1.0 #22 0x00007fad36f3467c in _PyModule_Clear () from /lib64/libpython2.7.so.1.0 #23 0x00007fad36fa1c5b in PyImport_Cleanup () from /lib64/libpython2.7.so.1.0 #24 0x00007fad36fad598 in Py_Finalize () from /lib64/libpython2.7.so.1.0 #25 0x00007fad36faced8 in Py_Exit () from /lib64/libpython2.7.so.1.0 #26 0x00007fad36fad01a in handle_system_exit.part () from /lib64/libpython2.7.so.1.0 #27 0x00007fad36fad29d in PyErr_PrintEx () from /lib64/libpython2.7.so.1.0 #28 0x00007fad36fadea3 in PyRun_SimpleFileExFlags () from /lib64/libpython2.7.so.1.0 #29 0x00007fad36fbf30a in Py_Main () from /lib64/libpython2.7.so.1.0 #30 0x00007fad361e6fe0 in __libc_start_main () from /lib64/libc.so.6 #31 0x000000000040071e in _start () I'm guessing something about the changed shutdown is causing the deadlock?... Anyway, I'm pretty sure we can afford to remove that __del__ method, and that's another easily-applied workaround for the field. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 05:30:09 2014 From: report at bugs.python.org (irdb) Date: Tue, 02 Dec 2014 04:30:09 +0000 Subject: [issue1178] IDLE - add "paste code" functionality In-Reply-To: <1190153010.77.0.038299898053.issue1178@psf.upfronthosting.co.za> Message-ID: <1417494609.72.0.87596591902.issue1178@psf.upfronthosting.co.za> Changes by irdb : ---------- nosy: +irdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 05:48:30 2014 From: report at bugs.python.org (irdb) Date: Tue, 02 Dec 2014 04:48:30 +0000 Subject: [issue3559] Pasted \n not same as typed \n In-Reply-To: <1218778489.95.0.525643042727.issue3559@psf.upfronthosting.co.za> Message-ID: <1417495710.17.0.676665828489.issue3559@psf.upfronthosting.co.za> Changes by irdb : ---------- nosy: +irdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 05:49:55 2014 From: report at bugs.python.org (Dmitry Kazakov) Date: Tue, 02 Dec 2014 04:49:55 +0000 Subject: [issue22974] Make traceback functions support negative limits In-Reply-To: <1417449568.58.0.119614287353.issue22974@psf.upfronthosting.co.za> Message-ID: <1417495795.11.0.174917246964.issue22974@psf.upfronthosting.co.za> Changes by Dmitry Kazakov : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 05:52:49 2014 From: report at bugs.python.org (Dmitry Kazakov) Date: Tue, 02 Dec 2014 04:52:49 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <1417495969.14.0.730678688429.issue22619@psf.upfronthosting.co.za> Dmitry Kazakov added the comment: Moved the latest patch with implementation and tests from issue 22974 (http://bugs.python.org/issue22974). ---------- status: closed -> open Added file: http://bugs.python.org/file37341/traceback_patch_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 05:54:29 2014 From: report at bugs.python.org (Dmitry Kazakov) Date: Tue, 02 Dec 2014 04:54:29 +0000 Subject: [issue22974] Make traceback functions support negative limits In-Reply-To: <1417449568.58.0.119614287353.issue22974@psf.upfronthosting.co.za> Message-ID: <1417496069.09.0.906062976666.issue22974@psf.upfronthosting.co.za> Changes by Dmitry Kazakov : Removed file: http://bugs.python.org/file37336/traceback_patch_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 05:55:59 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 02 Dec 2014 04:55:59 +0000 Subject: [issue22974] Make traceback functions support negative limits In-Reply-To: <1417449568.58.0.119614287353.issue22974@psf.upfronthosting.co.za> Message-ID: <1417496159.23.0.264128688995.issue22974@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> duplicate stage: -> resolved superseder: -> Possible implementation of negative limit for traceback functions _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 08:10:57 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 02 Dec 2014 07:10:57 +0000 Subject: [issue1178] IDLE - add "paste code" functionality In-Reply-To: <1190153010.77.0.038299898053.issue1178@psf.upfronthosting.co.za> Message-ID: <1417504257.92.0.429361836003.issue1178@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: -ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 08:35:19 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 02 Dec 2014 07:35:19 +0000 Subject: [issue20335] bytes constructor accepts more than one argument even if the first one is not a string In-Reply-To: <1390340737.95.0.677221459573.issue20335@psf.upfronthosting.co.za> Message-ID: <20141202073514.84291.45006@psf.io> Roundup Robot added the comment: New changeset 8badbd65840e by Serhiy Storchaka in branch '3.4': Issue #20335: bytes constructor now raises TypeError when encoding or errors https://hg.python.org/cpython/rev/8badbd65840e New changeset 8d6b27837c69 by Serhiy Storchaka in branch 'default': Issue #20335: bytes constructor now raises TypeError when encoding or errors https://hg.python.org/cpython/rev/8d6b27837c69 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 08:39:09 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 02 Dec 2014 07:39:09 +0000 Subject: [issue20335] bytes constructor accepts more than one argument even if the first one is not a string In-Reply-To: <1390340737.95.0.677221459573.issue20335@psf.upfronthosting.co.za> Message-ID: <1417505949.01.0.108155074803.issue20335@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your patch Renaud. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 08:47:20 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 02 Dec 2014 07:47:20 +0000 Subject: [issue22971] test_pickle: "Fatal Python error: Cannot recover from stack overflow." on FreeBSD buildbot In-Reply-To: <1417430775.66.0.180152689809.issue22971@psf.upfronthosting.co.za> Message-ID: <1417506440.18.0.735561191998.issue22971@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This failure is sporadic. After failing build 2434 there was four successful builds. May be other tests affect this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 09:02:14 2014 From: report at bugs.python.org (Akira Li) Date: Tue, 02 Dec 2014 08:02:14 +0000 Subject: [issue22356] mention explicitly that stdlib assumes gmtime(0) epoch is 1970 In-Reply-To: <1417480737.76.0.402866431002.issue22356@psf.upfronthosting.co.za> (Alexander Belopolsky's message of "Tue, 02 Dec 2014 00:38:57 +0000") Message-ID: <8761dua3bh.fsf@gmail.com> Akira Li added the comment: > Alexander Belopolsky added the comment: > >> I've provide the direct quote from *C* standard ... > > I understand that C standard uses the word "encoding", but it does so > for a reason that is completely unrelated to the choice of epoch. > "Encoding" is how the bytes in memory should be interpreted as "number > of seconds" or some other notion of time. For, example "two's > complement little-endian 32-bit signed int" is an example of valid > time_t encoding, another example would be IEEE 754 big-endian 64-bit > double. Note that these choices are valid for both C and POSIX > standards. I agree one *part* of "encoding" is how time_t is *represented* in memory but it is not the only part e.g.: The mktime function converts the broken-down time, expressed as local time, in the structure pointed to by timeptr into a calendar time value with the same encoding as that of the values returned by the time function. notice: "the same encoding as ... returned by the time function". time() function can return values with different epoch (implementation defined). mktime() is specified to use the *same* encoding i.e., the same epoch, etc. i.e., [in simple words] we have calendar time (Gregorian date, time) and we can convert it to a number (e.g., Python integer), we can call that number "seconds" and we can represent that number as some (unspecified) bit-pattern in C. I consider the whole process of converting "time" to a bit-pattern in memory as "encoding" i.e., "32/64, un/signed int/754 double" is just *part* of it e.g., 1. specify that 1970-01-01T00:00:00Z is zero (0) 2. specify 0 has time_t type 3. specify how time_t type is represented in memory. I may be wrong that C standard includes the first item in time "encoding". > If you google for your phrase "time in POSIX encoding", this issue is > the only hit. This strongly suggests that your choice of words is not > the most natural. I've googled the phrase (no surrounding quotes) and the links talk about time encoded as POSIX time [1] and some *literally* contain the phrase *POSIX encoding* [2] because *Python* documentation for calendar.timegm contains it [3]: [timegm] returns the corresponding Unix timestamp value, assuming an epoch of 1970, and the POSIX encoding. In fact, time.gmtime() and timegm() are each others? inverse. In an effort to avoid personal influence, I've repeated the expreriment using Tor browser and other search engines -- the result is the same. timegm() documentation might be the reason why I've used the phrase. I agree "POSIX encoding" might be unclear. The patch could be replaced by any phrase that expresses that some functions in stdlib assume that time.time() returns (+/- fractional part) "seconds since the Epoch" as defined by POSIX [4]. [1] http://en.wikipedia.org/wiki/Unix_time#Encoding_time_as_a_number [2] http://ruslanspivak.com/2011/07/20/how-to-convert-python-utc-datetime-object-to-unix-timestamp/ [3] https://docs.python.org/3/library/calendar.html#calendar.timegm [4] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 09:07:59 2014 From: report at bugs.python.org (Greg Turner) Date: Tue, 02 Dec 2014 08:07:59 +0000 Subject: [issue22968] types._calculate_meta nit: isinstance != PyType_IsSubtype In-Reply-To: <1417293514.02.0.452977288528.issue22968@psf.upfronthosting.co.za> Message-ID: <1417507679.4.0.154391428418.issue22968@psf.upfronthosting.co.za> Greg Turner added the comment: Also: In types.prepare_class, here is what currently happens: we let x be, in order of preference: (a) the explicitly given type if, one is given, else (b) type(bases[0]), if it exists, else (c) type and then, if isinstance(x, type), we run _calculate_bases. In python 2, I think something like this really does happen, although, perhaps "isinstance(x, type)" should have been "issubclass(x, type)" to correctly capture how python 2 does it. In particular, I think we can stick a Callable in there as bases[0], and then any old crazy list of objects as base classes, and it will call our Callable, although if we don't do something about our crazy base classes, it will still break later (something like that... I don't remember exactly, except that the first base is definitely special somehow). But in python 3, if I'm reading the C code correctly, I don't think the first base class receives any "special" handling, and the cpython-equivalent to _calculate_bases /always/ happens, suggesting that any non-descending-from-type metaclass is expected to have removed itself from the picture before type_new is invoked. So maybe more minor re-factoring is needed to get it all straightened out. My brain is kind of fried from looking at it, I'll try again later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 10:15:15 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 02 Dec 2014 09:15:15 +0000 Subject: [issue20192] pprint chokes on set containing frozenset In-Reply-To: <1389202631.98.0.662803177988.issue20192@psf.upfronthosting.co.za> Message-ID: <1417511715.61.0.618291828468.issue20192@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For now sets and frozensets are comparable with other types in Python 2. >>> frozenset(xrange(10)) < 1 False >>> set(xrange(10)) < 1 False The only known to me uncomparable types in Python 2 are naive and aware datetime. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 10:23:25 2014 From: report at bugs.python.org (Waldemar Parzonka) Date: Tue, 02 Dec 2014 09:23:25 +0000 Subject: [issue22931] cookies with square brackets in value In-Reply-To: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za> Message-ID: <1417512205.38.0.283484487046.issue22931@psf.upfronthosting.co.za> Waldemar Parzonka added the comment: Thanks for taking a look into that. And yes the behaviour when invalid value is encountered is bit weird as the rest of the cookie is being silently ignored which is probably less than ideal in most cases. Just wonder if there is any easy way of making the matching more aware as browsers may allow various things as cookie values I guess. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 11:03:19 2014 From: report at bugs.python.org (Stefan Champailler) Date: Tue, 02 Dec 2014 10:03:19 +0000 Subject: [issue12657] Cannot override JSON encoding of basic type subclasses In-Reply-To: <1311964088.32.0.0267577465373.issue12657@psf.upfronthosting.co.za> Message-ID: <1417514599.68.0.232368789878.issue12657@psf.upfronthosting.co.za> Stefan Champailler added the comment: I'm adding a scenario for this problem, a real life one, so it gives a bit more substance. I use SQLALchemy. I do queries with it which returns KeyedTuples (an SQLALchemy type). KeyedTuples inherits from tuple. KeyedTuples are, in principle, like NamedTuple. I want to transmit the result of my queries over json. Since KeyedTuple inherit from tuple, json can't serialize them. Of course one might say that that problem is outside the scope of json. But if so, it means we have to first convert KeyedTuples to dict and then pass the dict to json. That's alot of copies to do... This problem is rather big because it affects my whole API (close to a hundred of functions)... I've looked into the code and as noted above, one could replace 'isinstance(x,tuple)' with 'type(x) == tuple'. But without knowledge of how many people use the flexibility introduced by isinstance, it's dangerous. We could also change the nature of default and say that default is called before any type checking in json (so default is not a 'default' anymore). We could also duplicate the default functionnality (so a function called before any type checks and then a default called if all type checks fail). But for these two last cases, I guess the difficulty is : how do we know the pre-type 'default' was applied correctly ? Patching is not easy because, at least in my case, the C code path is taken => an easy patch (i.e. full python) would force me out of the C path which may be bad for performance (I didn't measure the difference between the 2 paths). I see this bug is old and not much commented, should we conclude that nobody cares ? That'd a good news since it'd mean a patch wouldn't hurt many people :-) ---------- nosy: +wiz21 versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 11:09:33 2014 From: report at bugs.python.org (=?utf-8?q?Rados=C5=82aw_Szkodzi=C5=84ski?=) Date: Tue, 02 Dec 2014 10:09:33 +0000 Subject: [issue22976] multiprocessing Queue empty() is broken on Windows Message-ID: <1417514973.26.0.394264585481.issue22976@psf.upfronthosting.co.za> New submission from Rados?aw Szkodzi?ski: multiprocessing.Queue.empty() uses pipe polling on Windows. Unfortunately, pipe semantics on windows are different from POSIX. The result is either: - Hang when one process tries to get() and another checks for empty() - Falsely returning empty() == False despite nothing being possible to get - because the other process is actually trying to read from the queue. The attached testcase demonstrates the first case, with main process hard hanging on my Python 2.7.8 (anaconda), 32-bit on Windows 7 64-bit. Whether 1 or 2 happens depends on specific program flow. Both can cause deadlocks in code that should be valid. Note that get(block=False) actually works correctly. It is possible that the problem is also present in Python 3. ---------- components: Library (Lib), Windows files: testmp.py messages: 231984 nosy: Rados?aw.Szkodzi?ski, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: multiprocessing Queue empty() is broken on Windows versions: Python 2.7 Added file: http://bugs.python.org/file37342/testmp.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 11:34:12 2014 From: report at bugs.python.org (Stefan Champailler) Date: Tue, 02 Dec 2014 10:34:12 +0000 Subject: [issue12657] Cannot override JSON encoding of basic type subclasses In-Reply-To: <1311964088.32.0.0267577465373.issue12657@psf.upfronthosting.co.za> Message-ID: <1417516452.57.0.895079850226.issue12657@psf.upfronthosting.co.za> Stefan Champailler added the comment: Reading bugs a bit, I see this is quite related to : http://bugs.python.org/issue14886 stF ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 12:05:11 2014 From: report at bugs.python.org (Matthias Klose) Date: Tue, 02 Dec 2014 11:05:11 +0000 Subject: [issue12987] Demo/scripts/newslist.py has non-free licensing terms In-Reply-To: <1316106376.14.0.821549088904.issue12987@psf.upfronthosting.co.za> Message-ID: <1417518311.98.0.481867160458.issue12987@psf.upfronthosting.co.za> Matthias Klose added the comment: thanks for bringing this up. I don't agree that the non-availability in the windows build should be used to close the issue. Linux distros distribute the source, and are still affected? If it's already removed in Python3, why not remove it here as well? Anyway, I can repackage the sources for Debian/Ubuntu ---------- nosy: +ncoghlan status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 12:19:44 2014 From: report at bugs.python.org (Martin Panter) Date: Tue, 02 Dec 2014 11:19:44 +0000 Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?= =?utf-8?q?=E2=80=9D_exception_message?= Message-ID: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za> New submission from Martin Panter: The following code generates a connection reset error on Wine (Windows emulator, because I don?t have actual Windows to test on). Probably only a minor issue, but the error message isn?t quite right: >>> s = create_connection(("localhost", 8181)) >>> # Server end accepts connection and then closes it >>> s.sendall(b"3" * 3000000) Traceback (most recent call last): File "", line 1, in ConnectionResetError: [WinError 10054] Windows Error 0x%X I?m just guessing, but looking at Python/errors.c, there are two PyUnicode_FromFormat("Windows Error 0x%X", ...) calls. The documentation for that function says only a lower-case %x is supported, so that would explain the behaviour I am seeing. ---------- components: Windows messages: 231987 nosy: steve.dower, tim.golden, vadmium, zach.ware priority: normal severity: normal status: open title: Unformatted ?Windows Error 0x%X? exception message type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 12:35:01 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 02 Dec 2014 11:35:01 +0000 Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?= =?utf-8?q?=E2=80=9D_exception_message?= In-Reply-To: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za> Message-ID: <1417520101.0.0.61753560834.issue22977@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- keywords: +easy nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 12:54:50 2014 From: report at bugs.python.org (Matthias Klose) Date: Tue, 02 Dec 2014 11:54:50 +0000 Subject: [issue16041] poplib: unlimited readline() from connection In-Reply-To: <1348569563.2.0.69634867698.issue16041@psf.upfronthosting.co.za> Message-ID: <1417521290.21.0.0284676249165.issue16041@psf.upfronthosting.co.za> Matthias Klose added the comment: this looks ok to me, can we apply this for 2.7.9? ---------- nosy: +doko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 12:59:28 2014 From: report at bugs.python.org (Matthias Klose) Date: Tue, 02 Dec 2014 11:59:28 +0000 Subject: [issue16042] smtplib: unlimited readline() from connection In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za> Message-ID: <1417521568.17.0.702245203921.issue16042@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- nosy: +doko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 13:39:17 2014 From: report at bugs.python.org (Matthias Klose) Date: Tue, 02 Dec 2014 12:39:17 +0000 Subject: [issue16043] xmlrpc: gzip_decode has unlimited read() In-Reply-To: <1348570326.9.0.587983624118.issue16043@psf.upfronthosting.co.za> Message-ID: <1417523957.51.0.951693461436.issue16043@psf.upfronthosting.co.za> Matthias Klose added the comment: updated patch to use an optional parameter "max_decode". ---------- nosy: +doko Added file: http://bugs.python.org/file37343/xmlrpc_gzip_27_parameter.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 13:41:44 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 02 Dec 2014 12:41:44 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1417524104.36.0.549019781957.issue18967@psf.upfronthosting.co.za> Nick Coghlan added the comment: As an interim step, should we add Ezio's "newsmerge.py" to Tools/scripts and instructions for enabling it to the devguide? That seems straightforward enough, and doesn't require any global workflow changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 13:46:46 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 02 Dec 2014 12:46:46 +0000 Subject: [issue12987] Demo/scripts/newslist.py has non-free licensing terms In-Reply-To: <1316106376.14.0.821549088904.issue12987@psf.upfronthosting.co.za> Message-ID: <1417524406.66.0.314415620464.issue12987@psf.upfronthosting.co.za> Nick Coghlan added the comment: Given that it's only the demo directory (and a relatively obscure demo as well these days), I'm inclined to just fix it upstream rather than making the distros patch it. There's also the fact that we distribute the source tarballs from python.org as well, and assert that those are under the PSF license, which this script doesn't adhere to. ---------- nosy: +bkabrda resolution: wont fix -> stage: resolved -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 13:54:20 2014 From: report at bugs.python.org (Matthias Klose) Date: Tue, 02 Dec 2014 12:54:20 +0000 Subject: [issue16043] xmlrpc: gzip_decode has unlimited read() In-Reply-To: <1348570326.9.0.587983624118.issue16043@psf.upfronthosting.co.za> Message-ID: <1417524860.41.0.414501793608.issue16043@psf.upfronthosting.co.za> Matthias Klose added the comment: document the new exception ---------- Added file: http://bugs.python.org/file37344/xmlrpc_gzip_27_parameter.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 14:03:35 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 02 Dec 2014 13:03:35 +0000 Subject: [issue20453] json.load() error message changed in 3.4 In-Reply-To: <1391162931.99.0.108127691347.issue20453@psf.upfronthosting.co.za> Message-ID: <1417525415.55.0.248731156456.issue20453@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In issue19361 I suggest to change error messages even more and drop end position from "Extra data" error message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 14:19:23 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 02 Dec 2014 13:19:23 +0000 Subject: [issue22701] Write unescaped unicode characters (Japanese, Chinese, etc) in JSON module when "ensure_ascii=False" In-Reply-To: <1414004123.6.0.971106689488.issue22701@psf.upfronthosting.co.za> Message-ID: <1417526363.42.0.00424063433709.issue22701@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Looks either you have opened a file with the backslashreplace error handler or ran Python with PYTHONIOENCODING which sets the backslashreplace error handler. ---------- nosy: +serhiy.storchaka status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 14:42:56 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 02 Dec 2014 13:42:56 +0000 Subject: [issue13027] python 2.6.6 interpreter core dumps on modules command from help prompt In-Reply-To: <1316699786.14.0.395194212825.issue13027@psf.upfronthosting.co.za> Message-ID: <1417527776.14.0.824281101956.issue13027@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I suggest to close this issue as caused by a bug in third party extension. ---------- nosy: +serhiy.storchaka resolution: -> third party status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 14:45:46 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 02 Dec 2014 13:45:46 +0000 Subject: [issue7567] Messed up terminal after calling curses.initscr() twice. In-Reply-To: <1261532778.06.0.257601342471.issue7567@psf.upfronthosting.co.za> Message-ID: <1417527946.04.0.371831138235.issue7567@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 15:12:04 2014 From: report at bugs.python.org (Maytag Metalark) Date: Tue, 02 Dec 2014 14:12:04 +0000 Subject: [issue22978] Logical Negation of NotImplemented Message-ID: <1417529524.39.0.154038331271.issue22978@psf.upfronthosting.co.za> New submission from Maytag Metalark: Performing a logical negation (`not`) on `NotImplemented` should return `NotImplemented`. Currently, it returns `False`. A common pattern for implementing __eq__ and __ne__ is to implement the comparison in __eq__, and simply delegate to it in __ne__ with a negation. However, if two values are incomparable, then __eq__ and __ne__ should both return NotImplemented. If you try to negate NotImplemented in __ne__, you will end up with a value of False, instead of NotImplemented, so you have to specifically test for this case. For instance, here is how one would write the code now: def __ne__(self, other): eq = self.__eq__(other) if eq is NotImplemented: return NotImplemented return not eq Where as the following would be simpler, and could be used if this change was made: def __ne__(self, other): return not self.__eq__(other) This is not simply sugar to reduce typing, it is safer because some coders may forget about NotImplemented and implement __ne__ as shown in the second example anyway, which is not actually correct with the current behavior. ---------- messages: 231996 nosy: Brian.Mearns priority: normal severity: normal status: open title: Logical Negation of NotImplemented type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 15:14:10 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 02 Dec 2014 14:14:10 +0000 Subject: [issue9647] os.confstr() does not handle value changing length between calls In-Reply-To: <1282243493.08.0.1214343728.issue9647@psf.upfronthosting.co.za> Message-ID: <1417529650.21.0.884153128878.issue9647@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I agree with Victor that two calls to confstr() should be enough. An example in confstr manpage uses two calls and I think there is no many software (if any) in the world which does more. ---------- keywords: +easy nosy: +serhiy.storchaka stage: -> needs patch versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 15:25:38 2014 From: report at bugs.python.org (Maytag Metalark) Date: Tue, 02 Dec 2014 14:25:38 +0000 Subject: [issue22979] Use of None in min and max Message-ID: <1417530338.57.0.34442889749.issue22979@psf.upfronthosting.co.za> New submission from Maytag Metalark: `None` should never be the result of the built-in `min` and `max` functions. When `None` is supplied as one of the values to check, it should never be chosen as the result. This would make it much easier to find a minimum and/or maximum while iterating over values. For instance, the following is a common pattern: mn = None mx = None for x in iterable: if mn is None or x < mn: mn = x if mx is None or x > mx: mx = x Note that although the `min` and `max` functions could be applied directly to `iterable` in the above case, the above pattern is more efficient (only once through the loop) and covers the common case where additional operations are performed on each value of the iterable. If the suggested enhancement was made, the above code could be written more simply as: mn = None mx = None for x in iterable: mn = min(mn, x) mx = max(mx, x) At present, this will actually work for `max`, as None evaluates as less than every number, but it will not work for `min` (for the same reason). The suggested change would mean that None is simultaneously greater than and less than every other value, but that only matters if we assume a total ordering of all the values including None, which doesn't seem like it would be important. ---------- messages: 231998 nosy: Brian.Mearns priority: normal severity: normal status: open title: Use of None in min and max type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 15:33:05 2014 From: report at bugs.python.org (Tom Christie) Date: Tue, 02 Dec 2014 14:33:05 +0000 Subject: [issue18290] json encoder does not support JSONP/JavaScript safe escaping In-Reply-To: <1372049179.79.0.237326954931.issue18290@psf.upfronthosting.co.za> Message-ID: <1417530785.25.0.0326279463911.issue18290@psf.upfronthosting.co.za> Tom Christie added the comment: I believe the status of this should be reassessed and that python should default to escaping '\u2028' and '\u2029'. *Strictly* speaking this isn't a bug and is per the JSON spec. *However* this *is* a bug in the JSON spec - which *should* be a strict subset of JSON. Given that both escaped and unescaped are valid, ensuring that those two characters *are* always escaped would clearly be more user-friendly behavior on our part, and *would* lead to less bugs in, say web frameworks that use the JSON module and then pass the output to template (eg populating a javscript variable with some JSON output). ---------- nosy: +tomchristie _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 15:35:25 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 02 Dec 2014 14:35:25 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account Message-ID: <1417530925.56.0.55888060474.issue22980@psf.upfronthosting.co.za> New submission from Antoine Pitrou: Currently, C extensions are named something like "_helperlib.cpython-34dm.so". This doesn't take into account the bitness of the interpreter (32- vs. 64-bit), which makes it awkward to use the same working copy with two different interpreters (you have to rebuild everything each time you switch bitnesses). Worse, under Windows it seems ABI tags aren't even used, giving generic names such as "_helperlib.pyd". Why is that? ---------- messages: 232000 nosy: barry, brett.cannon, eric.snow, ncoghlan, pitrou, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: C extension naming doesn't take bitness into account type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 15:36:01 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 02 Dec 2014 14:36:01 +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: <1417530961.03.0.417098926645.issue22980@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 15:36:53 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 02 Dec 2014 14:36:53 +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: <1417531013.24.0.615240006185.issue22980@psf.upfronthosting.co.za> STINNER Victor added the comment: See also the PEP 3149. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 15:48:38 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 02 Dec 2014 14:48:38 +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: <1417531718.34.0.671295554861.issue22980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: PEP 3149 says """It is not currently clear that the facilities in this PEP are even useful for Windows""". Well, it seems I have found a use for it :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 16:13:12 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 02 Dec 2014 15:13:12 +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: <1417533192.57.0.855758514726.issue22980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ideally, we would use distutils.util.get_platform(). However, there are two cases where it relies on other modules: - the re module under CygWin - the sysconfig and _osx_support under OS X Of course, ideally we should be able to hardcode this into the compiled CPython executable... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 16:19:46 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 02 Dec 2014 15:19:46 +0000 Subject: [issue18290] json encoder does not support JSONP/JavaScript safe escaping In-Reply-To: <1372049179.79.0.237326954931.issue18290@psf.upfronthosting.co.za> Message-ID: <1417533586.62.0.308725146549.issue18290@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is explicit note in the documentation about incompatibility with JavaScript. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 16:20:45 2014 From: report at bugs.python.org (Florent Xicluna) Date: Tue, 02 Dec 2014 15:20:45 +0000 Subject: [issue21161] list comprehensions don't see local variables in pdb in python3 In-Reply-To: <1396698943.39.0.489151150852.issue21161@psf.upfronthosting.co.za> Message-ID: <1417533645.96.0.137832034317.issue21161@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 16:23:32 2014 From: report at bugs.python.org (Simeon Visser) Date: Tue, 02 Dec 2014 15:23:32 +0000 Subject: [issue22979] Use of None in min and max In-Reply-To: <1417530338.57.0.34442889749.issue22979@psf.upfronthosting.co.za> Message-ID: <1417533812.1.0.111440256739.issue22979@psf.upfronthosting.co.za> Simeon Visser added the comment: This doesn't happen in Python 3 as None can't be compared to other elements: >>> min([1,2,3,None]) Traceback (most recent call last): File "", line 1, in TypeError: unorderable types: NoneType() < int() I can also imagine people now using min with the intended behaviour of "give me the smallest element, or None if it happens to be present". ---------- nosy: +simeon.visser _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 16:32:10 2014 From: report at bugs.python.org (Tom Christie) Date: Tue, 02 Dec 2014 15:32:10 +0000 Subject: [issue18290] json encoder does not support JSONP/JavaScript safe escaping In-Reply-To: <1372049179.79.0.237326954931.issue18290@psf.upfronthosting.co.za> Message-ID: <1417534330.54.0.205276815654.issue18290@psf.upfronthosting.co.za> Tom Christie added the comment: > There is explicit note in the documentation about incompatibility with JavaScript. That may be, but we're still unnecessarily making for a poorer user experience. There's no good reason why we shouldn't just treat \u2028 and \u2029 as control characters - it's only going to making things better for developers using the json module. It is an unnecessary usability bug as it stands. Just because JSON has a bug in its spec wrt those two characters, doesn't mean we can't help our users avoid ever having to know about that or work around it in user code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 16:32:41 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 02 Dec 2014 15:32:41 +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: <1417534361.3.0.461123432125.issue22980@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 16:40:56 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 02 Dec 2014 15:40:56 +0000 Subject: [issue22976] multiprocessing Queue empty() is broken on Windows In-Reply-To: <1417514973.26.0.394264585481.issue22976@psf.upfronthosting.co.za> Message-ID: <1417534856.01.0.513622916261.issue22976@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 16:44:04 2014 From: report at bugs.python.org (Simeon Visser) Date: Tue, 02 Dec 2014 15:44:04 +0000 Subject: [issue22979] Use of None in min and max In-Reply-To: <1417530338.57.0.34442889749.issue22979@psf.upfronthosting.co.za> Message-ID: <1417535044.77.0.198697423813.issue22979@psf.upfronthosting.co.za> Simeon Visser added the comment: So, to clarify, as the problem no longer occurs in Python 3 (as it requires the caller to provide only orderable objects) I'm not sure a meaningful change can be made here. It would require changing the behaviour of min/max in Python 2.7.x in a way that could break existing code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 16:49:24 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 02 Dec 2014 15:49:24 +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: <1417535364.47.0.265619758458.issue22980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: As a side-note, it is interesting to note that Python currently wrongly identifies 32-bit builds under 64-bit Linux: Python 3.5.0a0 (default:64a54f0c87d7, Nov 2 2014, 17:18:13) [GCC 4.9.1] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sys, os, sysconfig >>> sys.maxsize 2147483647 >>> os.uname() posix.uname_result(sysname='Linux', nodename='fsol', release='3.16.0-25-generic', version='#33-Ubuntu SMP Tue Nov 4 12:06:54 UTC 2014', machine='x86_64') >>> sysconfig.get_platform() 'linux-x86_64' AFAIU, sysconfig.get_platform() (or its sibling distutils.util.get_platform()) is used for the naming of binary distributions... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 17:02:46 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 02 Dec 2014 16:02:46 +0000 Subject: [issue22978] Logical Negation of NotImplemented In-Reply-To: <1417529524.39.0.154038331271.issue22978@psf.upfronthosting.co.za> Message-ID: <1417536166.48.0.0218451535767.issue22978@psf.upfronthosting.co.za> R. David Murray added the comment: This would break Python's consistency. 'not' of a value returns its boolean inverse, and the boolean value of NotImplemented is True, just like the boolean value of any object that does not have methods that set its boolean value is True. Having anything that is True return True when not is applied would be even more perverse than NANs are :) The correct implementation of your __ne__ method is to not define it. Python will then do the 'not __eq__(other)' call itself. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 17:08:59 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 02 Dec 2014 16:08:59 +0000 Subject: =?utf-8?b?W2lzc3VlMjI5NjZdIHB5X2NvbXBpbGU6IGZvby5iYXIucHkg4oaSIF9fcHlj?= =?utf-8?q?ache=5F=5F/foo=2Ecpython-34=2Epyc?= In-Reply-To: <1417256202.79.0.40494755597.issue22966@psf.upfronthosting.co.za> Message-ID: <1417536539.47.0.970539090047.issue22966@psf.upfronthosting.co.za> Brett Cannon added the comment: Apparently this broke under Windows: http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/8999/steps/test/logs/stdio ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 17:09:39 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 02 Dec 2014 16:09:39 +0000 Subject: [issue22979] Use of None in min and max In-Reply-To: <1417530338.57.0.34442889749.issue22979@psf.upfronthosting.co.za> Message-ID: <1417536579.12.0.824183331096.issue22979@psf.upfronthosting.co.za> R. David Murray added the comment: Just select your initial value as something that works with the sequence you are iterating. If necessary, you can define custom 'always maximum' and 'always minimum' objects. (You could try proposing builtin objects with that feature on the python-ideas mailing list, if you want to pursue this, but since this is a specialized need and usually you don't even need custom objects, I suspect you won't get much enthusiasm. But I could be wrong, especially if you can some up with additional use cases. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 17:11:27 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 02 Dec 2014 16:11:27 +0000 Subject: [issue18053] Add checks for Misc/NEWS in make patchcheck In-Reply-To: <1369453600.75.0.470507945427.issue18053@psf.upfronthosting.co.za> Message-ID: <1417536687.24.0.688676632765.issue18053@psf.upfronthosting.co.za> Brett Cannon added the comment: If it's bugging you, Terry, feel free to delete that part of the check as it's of more use to core devs and we won't forget. ---------- assignee: -> terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 17:18:42 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 02 Dec 2014 16:18:42 +0000 Subject: [issue9584] Allow curly brace expansion In-Reply-To: <1281688613.27.0.00233773234268.issue9584@psf.upfronthosting.co.za> Message-ID: <1417537122.26.0.48933506568.issue9584@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 17:20:30 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 02 Dec 2014 16:20:30 +0000 Subject: [issue22981] Use CFLAGS when extracting multiarch Message-ID: <1417537230.69.0.64347205768.issue22981@psf.upfronthosting.co.za> New submission from Antoine Pitrou: This patch fixes MULTIARCH computation when using CFLAGS=-m32: diff --git a/configure b/configure --- a/configure +++ b/configure @@ -5402,7 +5402,7 @@ hp*|HP*) esac;; esac -MULTIARCH=$($CC --print-multiarch 2>/dev/null) +MULTIARCH=$($CC $CFLAGS --print-multiarch 2>/dev/null) diff --git a/configure.ac b/configure.ac --- a/configure.ac +++ b/configure.ac @@ -788,7 +788,7 @@ hp*|HP*) esac;; esac -MULTIARCH=$($CC --print-multiarch 2>/dev/null) +MULTIARCH=$($CC $CFLAGS --print-multiarch 2>/dev/null) AC_SUBST(MULTIARCH) ---------- messages: 232013 nosy: barry, doko, pitrou priority: normal severity: normal status: open title: Use CFLAGS when extracting multiarch type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 17:26:12 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 02 Dec 2014 16:26:12 +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: <1417537572.28.0.825290437108.issue22980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The MULTIARCH variable can help at least under Linux: >>> import sysconfig >>> sysconfig.get_platform() 'linux-x86_64' >>> sysconfig.get_config_var('MULTIARCH') 'i386-linux-gnu' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 17:41:42 2014 From: report at bugs.python.org (MarkIngramUK) Date: Tue, 02 Dec 2014 16:41:42 +0000 Subject: [issue22982] BOM incorrectly inserted before writing, after seeking in text file Message-ID: <1417538502.93.0.814458445398.issue22982@psf.upfronthosting.co.za> New submission from MarkIngramUK: If you open a text file for append, but then perform any form of seeking, before attempting to write to the file, it will cause the BOM to be written before you text. See the attached file for an example. If you run the test, take a look at the output file, and you'll notice the UTF16 BOM gets written out before each number. I'm running a 2014 iMac with Yosemite. ---------- components: IO files: append-test.py messages: 232015 nosy: MarkIngramUK priority: normal severity: normal status: open title: BOM incorrectly inserted before writing, after seeking in text file type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file37345/append-test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 17:46:58 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 02 Dec 2014 16:46:58 +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: <1417538818.3.0.981392313542.issue22980@psf.upfronthosting.co.za> STINNER Victor added the comment: There is also platform.architecture(). I don't like its implementation, it relies on the external file program :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 17:49:06 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 02 Dec 2014 16:49:06 +0000 Subject: [issue22685] memory leak: no transport for pipes by create_subprocess_exec/shell In-Reply-To: <1413894821.03.0.250322427022.issue22685@psf.upfronthosting.co.za> Message-ID: <1417538946.96.0.336038689184.issue22685@psf.upfronthosting.co.za> STINNER Victor added the comment: > Buildbot failures observed on koobs-freebsd9 and koobs-freebsd10 for 3.x and 3.4, respectively. It looks like test_asyncio pass on the last 5 builds of the following buildbots, and so I consider the issue as closed. http://buildbot.python.org/all/builders/AMD64 FreeBSD 9.x 3.x http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 17:53:13 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 02 Dec 2014 16:53:13 +0000 Subject: [issue22473] The gloss on asyncio "future with run_forever" example is confusing In-Reply-To: <1411515975.42.0.282827755318.issue22473@psf.upfronthosting.co.za> Message-ID: <20141202165304.69793.2925@psf.io> Roundup Robot added the comment: New changeset a4b58e779a16 by Victor Stinner in branch '3.4': Close #22473: asyncio doc: rephrase Future with run_forever() example https://hg.python.org/cpython/rev/a4b58e779a16 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 17:54:03 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 02 Dec 2014 16:54:03 +0000 Subject: [issue22473] The gloss on asyncio "future with run_forever" example is confusing In-Reply-To: <1411515975.42.0.282827755318.issue22473@psf.upfronthosting.co.za> Message-ID: <1417539243.21.0.917708299061.issue22473@psf.upfronthosting.co.za> STINNER Victor added the comment: I rephrase the explanation of the example and I removed the useless note. Thanks for your feedback David. Don't hesitate to propose other enhancements to the documentation! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 17:57:36 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 02 Dec 2014 16:57:36 +0000 Subject: =?utf-8?b?W2lzc3VlMjI5NjZdIHB5X2NvbXBpbGU6IGZvby5iYXIucHkg4oaSIF9fcHlj?= =?utf-8?q?ache=5F=5F/foo=2Ecpython-34=2Epyc?= In-Reply-To: <1417256202.79.0.40494755597.issue22966@psf.upfronthosting.co.za> Message-ID: <1417539456.17.0.943591668.issue22966@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 17:58:41 2014 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Tue, 02 Dec 2014 16:58:41 +0000 Subject: [issue22914] Rewrite of Python 2/3 porting HOWTO In-Reply-To: <1416600199.23.0.813278658343.issue22914@psf.upfronthosting.co.za> Message-ID: <1417539521.86.0.617128169071.issue22914@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 17:59:37 2014 From: report at bugs.python.org (Demian Brecht) Date: Tue, 02 Dec 2014 16:59:37 +0000 Subject: [issue22983] Cookie parsing should be more permissive Message-ID: <1417539577.52.0.585535774996.issue22983@psf.upfronthosting.co.za> New submission from Demian Brecht: As found in #22931, if an invalid cookie value is found while parsing, the rest of the cookie is silently ignored. The expected behavior is undefined in RFC 6265, but does state that if unexpected values are encountered that user agents MAY ignore an entire set-cookie string (not just a subsection of it). Given that, invalid cookie portions should likely be handled by either: 1. Ignore the cookie string in its entirety and log an error message, or 2. Ignore invalid cookie-pairs but still parse the rest of the string The latter would likely be the best path (Postel's law and all) ---------- components: Library (Lib) messages: 232020 nosy: demian.brecht priority: normal severity: normal status: open title: Cookie parsing should be more permissive type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 18:00:41 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 02 Dec 2014 17:00:41 +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: <1417539641.92.0.704802877085.issue22980@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 18:01:17 2014 From: report at bugs.python.org (Demian Brecht) Date: Tue, 02 Dec 2014 17:01:17 +0000 Subject: [issue22931] cookies with square brackets in value In-Reply-To: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za> Message-ID: <1417539677.33.0.610016397455.issue22931@psf.upfronthosting.co.za> Demian Brecht added the comment: I do think it should be a little more permissive when parsing cookies. I've created #22983 to address that as to not conflate this issue, which the attached patch does address. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 18:02:49 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 02 Dec 2014 17:02:49 +0000 Subject: [issue22475] asyncio task get_stack documentation seems to contradict itself In-Reply-To: <1411519909.22.0.512722932689.issue22475@psf.upfronthosting.co.za> Message-ID: <20141202170134.69793.53588@psf.io> Roundup Robot added the comment: New changeset 4b6b03c1f4ff by Victor Stinner in branch '3.4': Closes #22475: asyncio doc, fix Task.get_stack() doc https://hg.python.org/cpython/rev/4b6b03c1f4ff ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 18:04:23 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 02 Dec 2014 17:04:23 +0000 Subject: [issue22475] asyncio task get_stack documentation seems to contradict itself In-Reply-To: <1411519909.22.0.512722932689.issue22475@psf.upfronthosting.co.za> Message-ID: <1417539863.33.0.388957988983.issue22475@psf.upfronthosting.co.za> STINNER Victor added the comment: I fixed the most obvious issue in the documentation. I don't know the function enough to propose a better documentation, sorry. Don't hesitate to write a patch on the documentation if you have a better explanation of how get_stack() behaves. It is correct that get_stack() only returns 1 frame if the task is suspended, whereas it returns more frames if get_stack() is called while the task is running. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 18:04:35 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 02 Dec 2014 17:04:35 +0000 Subject: [issue19361] Specialize exceptions thrown by JSON parser In-Reply-To: <1382527334.08.0.362620105205.issue19361@psf.upfronthosting.co.za> Message-ID: <1417539875.97.0.743974663524.issue19361@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 18:04:42 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 02 Dec 2014 17:04:42 +0000 Subject: [issue20453] json.load() error message changed in 3.4 In-Reply-To: <1391162931.99.0.108127691347.issue20453@psf.upfronthosting.co.za> Message-ID: <1417539882.42.0.826448008018.issue20453@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 18:08:35 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 02 Dec 2014 17:08:35 +0000 Subject: [issue22983] Cookie parsing should be more permissive In-Reply-To: <1417539577.52.0.585535774996.issue22983@psf.upfronthosting.co.za> Message-ID: <1417540115.89.0.238854501913.issue22983@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, remember that we recently made parsing stricter in response to a security issue... ---------- nosy: +orsenthil, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 18:09:08 2014 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 02 Dec 2014 17:09:08 +0000 Subject: [issue22982] BOM incorrectly inserted before writing, after seeking in text file In-Reply-To: <1417538502.93.0.814458445398.issue22982@psf.upfronthosting.co.za> Message-ID: <1417540148.33.0.263877642442.issue22982@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: issue5006 was supposed to take care of this, but it has a flaw IMO: This statement https://hg.python.org/cpython/file/0744ceb5c0ed/Lib/_pyio.py#l2003 is missing an "and whence!=2". ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 18:10:39 2014 From: report at bugs.python.org (Steve Dower) Date: Tue, 02 Dec 2014 17:10:39 +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: <1417540239.26.0.0662410405167.issue22980@psf.upfronthosting.co.za> Steve Dower added the comment: I'm very much in favor of adding this for .pyds on Windows. I assume the hard part will be getting the details for Linux (doesn't bitness have to be compiled in there? For Windows it can be determined at compile-time...), but preferring an extension with the ABI tag and falling back on one without seems easy enough. (Would/could this also work for .py files? So a 2.7/3.x or Jython/CPython/IronPython package could include tags in pure-Python code files?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 18:12:20 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 02 Dec 2014 17:12:20 +0000 Subject: =?utf-8?b?W2lzc3VlMjI5NjZdIHB5X2NvbXBpbGU6IGZvby5iYXIucHkg4oaSIF9fcHlj?= =?utf-8?q?ache=5F=5F/foo=2Ecpython-34=2Epyc?= In-Reply-To: <1417256202.79.0.40494755597.issue22966@psf.upfronthosting.co.za> Message-ID: <1417540340.05.0.977168772656.issue22966@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I already pushed a fix. http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.4/builds/702/steps/test/logs/stdio (although asyncio is still failing there but that should be unrelated) ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 18:25:51 2014 From: report at bugs.python.org (Demian Brecht) Date: Tue, 02 Dec 2014 17:25:51 +0000 Subject: [issue22983] Cookie parsing should be more permissive In-Reply-To: <1417539577.52.0.585535774996.issue22983@psf.upfronthosting.co.za> Message-ID: <1417541151.27.0.0171050279959.issue22983@psf.upfronthosting.co.za> Demian Brecht added the comment: Sure, but this is in regards to the initial matching, not the parsing. Because the pattern expects RFC conformity, in this cookie string: Cookie: a=b; c=[; d=r; f=h The only matching parts will be: Cookie: a=b; The rest will be discarded. What I'm proposing is that this should instead result in: Cookie: a=b; d=r; f=h The recent changes would stay intact. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 18:26:46 2014 From: report at bugs.python.org (Demian Brecht) Date: Tue, 02 Dec 2014 17:26:46 +0000 Subject: [issue22983] Cookie parsing should be more permissive In-Reply-To: <1417539577.52.0.585535774996.issue22983@psf.upfronthosting.co.za> Message-ID: <1417541206.39.0.274884004627.issue22983@psf.upfronthosting.co.za> Demian Brecht added the comment: Sorry, bad example. Replace "[" in the previous example with any actually invalid character. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 18:32:06 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 02 Dec 2014 17:32:06 +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: <1417541526.21.0.167895062525.issue22980@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Note that there's a difference between the platform's architecture (which is what get_platform() returns) and the pointer size of the currently running Python executable. On 64-bit Linux, it's rather rare to have an application built as 32-bit executable. On 64-bit Windows, it's rather common to have 32-bit applications running. The best way to determine 32-bit vs. 64-bit is by using the struct module: # Determine bitsize used by Python (not necessarily the same as # the one used by the platform) import struct bits = struct.calcsize('P') * 8 This should be portable across all platforms and will always refer to the pointer size of the currently running Python executable. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 18:51:42 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 02 Dec 2014 17:51:42 +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: <1417542702.66.0.509832360102.issue22980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Note that there's a difference between the platform's architecture Yes, that's pointed out above. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 18:56:03 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 02 Dec 2014 17:56:03 +0000 Subject: [issue14099] ZipFile.open() should not reopen the underlying file In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za> Message-ID: <1417542963.07.0.633602308272.issue14099@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Okay for 2.7.10. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 18:59:37 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 02 Dec 2014 17:59:37 +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: <1417543177.08.0.91091428863.issue22980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Nothing new should be necessary for pyc files under Windows: Python 3.4.2 |Continuum Analytics, Inc.| (default, Oct 22 2014, 11:51:45) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.implementation.cache_tag 'cpython-34' The problem is with C extensions: >>> import _imp >>> _imp.extension_suffixes() ['.pyd'] Compare with Linux: >>> import _imp >>> _imp.extension_suffixes() ['.cpython-35dm.so', '.abi3.so', '.so'] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 19:02:13 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 02 Dec 2014 18:02:13 +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: <1417543333.2.0.0650717576383.issue22980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I assume the hard part will be getting the details for Linux (doesn't bitness > have to be compiled in there? For Windows it can be determined at compile- > time...), but preferring an extension with the ABI tag and falling back on > one without seems easy enough. Sticking to bitness should be easy (although I wonder if it would be desirable for platforms with fat binaries - Ned?). If we can go the extra mile and include platform identification all the better, of course. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 19:07:20 2014 From: report at bugs.python.org (David Wilson) Date: Tue, 02 Dec 2014 18:07:20 +0000 Subject: [issue14099] ZipFile.open() should not reopen the underlying file In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za> Message-ID: <1417543640.55.0.599141463631.issue14099@psf.upfronthosting.co.za> David Wilson added the comment: Could we also make a small tweak to zipfile.rst indicating the new behaviour? I had made an initial attempt in my patch but wasn't particularly happy with the wording. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 19:40:57 2014 From: report at bugs.python.org (Steve Dower) Date: Tue, 02 Dec 2014 18:40:57 +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: <1417545657.4.0.177414865595.issue22980@psf.upfronthosting.co.za> Steve Dower added the comment: I was more interested in source file resolution than bytecode caching. If Python 3.5 would prefer "spam.cpython-35.py" or "spam.cpython-3.py" over "spam.py" and Python 2 preferred "spam.py", then I can more easily separate the code that won't parse in the alternative. Happy to be told it's unrelated and I should raise it separately, but from my POV resolving .pyd filenames looks very similar to resolving .py files. ---------- _______________________________________ Python tracker _______________________________________ From mal at egenix.com Tue Dec 2 19:42:02 2014 From: mal at egenix.com (M.-A. Lemburg) Date: Tue, 02 Dec 2014 19:42:02 +0100 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <1417543333.2.0.0650717576383.issue22980@psf.upfronthosting.co.za> References: <1417543333.2.0.0650717576383.issue22980@psf.upfronthosting.co.za> Message-ID: <547E07FA.80909@egenix.com> On 02.12.2014 19:02, Antoine Pitrou wrote: > Sticking to bitness should be easy (although I wonder if it would be desirable for platforms with fat binaries - Ned?). If we can go the extra mile and include platform identification all the better, of course. I hear the "can of worms" alarm ringing :-) Seriously, I think that putting platform infos into the file name is bound to cause more trouble than it tries to solve. Fat builds leave the decision to the linker, which is a good method and avoids the file name clashes. I think we should only focus on platforms where fat builds are uncommon, while at the same time you do have to support multiple architectures, like e.g. Windows: http://en.wikipedia.org/wiki/Fat_binary Note that on Linux, 32-bit and 64-bit versions are typically placed into different directory trees: http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard so I'm not sure whether it's a real problem on Linux. -- Marc-Andre Lemburg eGenix.com From report at bugs.python.org Tue Dec 2 19:42:07 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 02 Dec 2014 18:42:07 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <1417543333.2.0.0650717576383.issue22980@psf.upfronthosting.co.za> Message-ID: <547E07FA.80909@egenix.com> Marc-Andre Lemburg added the comment: On 02.12.2014 19:02, Antoine Pitrou wrote: > Sticking to bitness should be easy (although I wonder if it would be desirable for platforms with fat binaries - Ned?). If we can go the extra mile and include platform identification all the better, of course. I hear the "can of worms" alarm ringing :-) Seriously, I think that putting platform infos into the file name is bound to cause more trouble than it tries to solve. Fat builds leave the decision to the linker, which is a good method and avoids the file name clashes. I think we should only focus on platforms where fat builds are uncommon, while at the same time you do have to support multiple architectures, like e.g. Windows: http://en.wikipedia.org/wiki/Fat_binary Note that on Linux, 32-bit and 64-bit versions are typically placed into different directory trees: http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard so I'm not sure whether it's a real problem on Linux. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 19:44:02 2014 From: report at bugs.python.org (Steve Dower) Date: Tue, 02 Dec 2014 18:44:02 +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: <1417545842.39.0.940476605916.issue22980@psf.upfronthosting.co.za> Steve Dower added the comment: But since you pointed out cache-tag, should that distinguish for bitness as well? It seems to be 'cpython-34' for both 32-bit and 64-bit interpreters on Windows, which isn't really a problem now, but may become one if we start allowing/encouraging sharing packages between interpreters. In fact, it probably is an issue now with user site-packages, since that path is the same for both 32-bit and 64-bit... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 19:44:10 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 02 Dec 2014 18:44:10 +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: <1417545850.84.0.68827214671.issue22980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Fat binaries seem to exist under: - OS X: yes, that's why I was asking for Ned's advice - Linux: "A proof-of-concept Ubuntu 9.04 image is available"... enough said - DOS: perhaps MicroPython is interested :-) http://en.wikipedia.org/wiki/Fat_binary ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 19:44:21 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 02 Dec 2014 18:44:21 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <1417545657.4.0.177414865595.issue22980@psf.upfronthosting.co.za> Message-ID: <547E0881.7080009@egenix.com> Marc-Andre Lemburg added the comment: On 02.12.2014 19:40, Steve Dower wrote: > > I was more interested in source file resolution than bytecode caching. If Python 3.5 would prefer "spam.cpython-35.py" or "spam.cpython-3.py" over "spam.py" and Python 2 preferred "spam.py", then I can more easily separate the code that won't parse in the alternative. > > Happy to be told it's unrelated and I should raise it separately, but from my POV resolving .pyd filenames looks very similar to resolving .py files. That's an interesting idea, but indeed unrelated to this ticket :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 19:46:12 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 02 Dec 2014 18:46:12 +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: <1417545972.07.0.657727614385.issue22980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Note that on Linux, 32-bit and 64-bit versions are typically placed > into different directory trees By whom? Our standard installer doesn't (it uses ../lib/python-X.Y for all builds). Also, one of the problems (and actually the problem which triggered this tracker entry) is when doing development inside a working copy (either through "setup.py develop" or "setup.py build_ext --inplace" - both copy C extensions directly into the source tree). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 19:49:38 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 02 Dec 2014 18:49:38 +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: <1417546178.5.0.548682063498.issue22980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: @Steve: IIRC, pyc files should be portable, so there's no need to differentiate between various bitnesses. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 19:55:39 2014 From: report at bugs.python.org (Steve Dower) Date: Tue, 02 Dec 2014 18:55:39 +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: <1417546539.52.0.983643314085.issue22980@psf.upfronthosting.co.za> Steve Dower added the comment: @Antoine: You're right. I hereby withdraw all contributions to this thread after my first statement of support :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 19:59:34 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 02 Dec 2014 18:59:34 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <1417545972.07.0.657727614385.issue22980@psf.upfronthosting.co.za> Message-ID: <547E0C11.7040200@egenix.com> Marc-Andre Lemburg added the comment: On 02.12.2014 19:46, Antoine Pitrou wrote: > >> Note that on Linux, 32-bit and 64-bit versions are typically placed >> into different directory trees > > By whom? Our standard installer doesn't (it uses ../lib/python-X.Y for all builds). By the system vendors. Packages (with extensions) will automatically pick up their configuration. > Also, one of the problems (and actually the problem which triggered this tracker entry) is when doing development inside a working copy (either through "setup.py develop" or "setup.py build_ext --inplace" - both copy C extensions directly into the source tree). Fair enough; it's a rare use case, but may be worth supporting. My main point was that we shouldn't start adding tags for e.g. PPC, Intel, ARM, etc. since platforms needing to support multiple such architectures will typically support fat builds anyway. How about using these flags: b0 - 16-bit b1 - 32-bit b2 - 64-bit b3 - 128-bit and so on ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 20:10:35 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 02 Dec 2014 19:10:35 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <547E0C11.7040200@egenix.com> Message-ID: <547E0EA8.6000704@free.fr> Antoine Pitrou added the comment: Le 02/12/2014 19:59, Marc-Andre Lemburg a ?crit : > > My main point was that we shouldn't start adding tags for e.g. > PPC, Intel, ARM, etc. since platforms needing to support multiple > such architectures will typically support fat builds anyway. > > How about using these flags: > > b0 - 16-bit > b1 - 32-bit > b2 - 64-bit > b3 - 128-bit Fair enough, although I think we only need 32-bit and 64-bit for now, and "32b" vs. "64b" would probably be more readable :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 20:46:05 2014 From: report at bugs.python.org (eryksun) Date: Tue, 02 Dec 2014 19:46:05 +0000 Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?= =?utf-8?q?=E2=80=9D_exception_message?= In-Reply-To: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za> Message-ID: <1417549565.47.0.339529281133.issue22977@psf.upfronthosting.co.za> eryksun added the comment: This also affects SEH-related exceptions raised by ctypes. For example, VC++ uses exception code 0xE06D7363 (i.e. b'\xe0msc'), so unhandled VC++ exceptions leak into Python like this: >>> ctypes.windll.kernel32.RaiseException(0xe06d7363, 0, 0, None) Traceback (most recent call last): File "", line 1, in OSError: [WinError -529697949] Windows Error 0x%X The ctypes SEH handler defaults to calling PyErr_SetFromWindowsErr(code). Since this isn't actually a Windows error code, Win32 FormatMessageW fails. Then Python uses the following default: PyUnicode_FromFormat("Windows Error 0x%X", err). Normally (i.e. not under Wine) the OP's error number formats correctly: >>> ctypes.windll.kernel32.RaiseException(10054, 0, 0, None) Traceback (most recent call last): File "", line 1, in ConnectionResetError: [WinError 10054] An existing connection was forcibly closed by the remote host PyErr_SetExcFromWindowsErrWithFilenameObjects https://hg.python.org/cpython/file/ab2c023a9432/Python/errors.c#l553 PyErr_SetFromErrnoWithFilenameObjects https://hg.python.org/cpython/file/ab2c023a9432/Python/errors.c#l416 ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 20:51:22 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 02 Dec 2014 19:51:22 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <547E0EA8.6000704@free.fr> Message-ID: <547E1834.40607@egenix.com> Marc-Andre Lemburg added the comment: On 02.12.2014 20:10, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > Le 02/12/2014 19:59, Marc-Andre Lemburg a ?crit : >> >> My main point was that we shouldn't start adding tags for e.g. >> PPC, Intel, ARM, etc. since platforms needing to support multiple >> such architectures will typically support fat builds anyway. >> >> How about using these flags: >> >> b0 - 16-bit >> b1 - 32-bit >> b2 - 64-bit >> b3 - 128-bit > > Fair enough, although I think we only need 32-bit and 64-bit for now, > and "32b" vs. "64b" would probably be more readable :-) True, I'm just not sure what the parsing requirements are and the ABI version names are too long already, IMO. PEP 425 used a nice short variant for the Python part. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 21:48:51 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 02 Dec 2014 20:48:51 +0000 Subject: [issue14099] ZipFile.open() should not reopen the underlying file In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za> Message-ID: <1417553331.91.0.0445336769397.issue14099@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: How about just "Objects returned by :meth:`.open` can operate independently of the ZipFile."? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 22:15:19 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 02 Dec 2014 21:15:19 +0000 Subject: [issue22984] test_json.test_endless_recursion(): "Fatal Python error: Cannot recover from stack overflow." on x86 XP-4 3.x buildbot Message-ID: <1417554919.08.0.0786746086364.issue22984@psf.upfronthosting.co.za> New submission from STINNER Victor: http://buildbot.python.org/all/builders/x86%20XP-4%203.x/builds/11271/steps/test/logs/stdio [116/390] test_json Fatal Python error: Cannot recover from stack overflow. Current thread 0x00000e84 (most recent call first): File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\json\encoder.py", line 250 in iterencode File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\json\encoder.py", line 192 in encode File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_json\test_recursion.py", line 96 in test_endless_recursion File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\case.py", line 577 in run File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\case.py", line 625 in __call__ File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 125 in run File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 87 in __call__ File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 125 in run File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 87 in __call__ File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 125 in run File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 87 in __call__ File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 125 in run File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 87 in __call__ File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 125 in run File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\suite.py", line 87 in __call__ File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\unittest\runner.py", line 168 in run File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\support\__init__.py", line 1769 in _run_suite File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\support\__init__.py", line 1803 in run_unittest File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\..\lib\test\regrtest.py", line 1279 in test_runner File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\..\lib\test\regrtest.py", line 1280 in runtest_inner File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\..\lib\test\regrtest.py", line 967 in runtest File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\..\lib\test\regrtest.py", line 763 in main File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\..\lib\test\regrtest.py", line 1564 in main_in_temp_cwd File "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\..\lib\test\regrtest.py", line 1589 in ---------- components: Tests keywords: buildbot messages: 232049 nosy: haypo priority: normal severity: normal status: open title: test_json.test_endless_recursion(): "Fatal Python error: Cannot recover from stack overflow." on x86 XP-4 3.x buildbot type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 22:20:50 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 02 Dec 2014 21:20:50 +0000 Subject: [issue22971] test_pickle: "Fatal Python error: Cannot recover from stack overflow." on FreeBSD buildbot In-Reply-To: <1417430775.66.0.180152689809.issue22971@psf.upfronthosting.co.za> Message-ID: <1417555250.17.0.0783048615386.issue22971@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- components: +Windows nosy: +steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 22:34:24 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 02 Dec 2014 21:34:24 +0000 Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?= =?utf-8?q?=E2=80=9D_exception_message_on_Wine?= In-Reply-To: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za> Message-ID: <1417556064.21.0.186979543562.issue22977@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Unformatted ?Windows Error 0x%X? exception message -> Unformatted ?Windows Error 0x%X? exception message on Wine _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 22:41:55 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 02 Dec 2014 21:41:55 +0000 Subject: [issue17401] io.FileIO closefd parameter is not documented nor shown in repr In-Reply-To: <1363057927.36.0.00381165430664.issue17401@psf.upfronthosting.co.za> Message-ID: <20141202214149.105523.53174@psf.io> Roundup Robot added the comment: New changeset fd80195b920f by Serhiy Storchaka in branch 'default': Issue #17401: Output the closefd attribute as boolean. https://hg.python.org/cpython/rev/fd80195b920f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 22:44:07 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 02 Dec 2014 21:44:07 +0000 Subject: [issue17401] io.FileIO closefd parameter is not documented nor shown in repr In-Reply-To: <1363057927.36.0.00381165430664.issue17401@psf.upfronthosting.co.za> Message-ID: <1417556647.89.0.800434211097.issue17401@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Committed the first patch (showing closefd always) with additional test from second path. ---------- versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 22:44:24 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 02 Dec 2014 21:44:24 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <547E1834.40607@egenix.com> Message-ID: STINNER Victor added the comment: Would it be possible to add something to the sys module, computed during the compilation, instead of having to rely on platform, sysconfig, struct or something else? Note: There is also the funnny x32 platform project :-) https://sites.google.com/site/x32abi/ 32-bit pointer on 64-bit CPU. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 22:46:21 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 02 Dec 2014 21:46:21 +0000 Subject: [issue22984] test_json.test_endless_recursion(): "Fatal Python error: Cannot recover from stack overflow." on x86 XP-4 3.x buildbot In-Reply-To: <1417554919.08.0.0786746086364.issue22984@psf.upfronthosting.co.za> Message-ID: <1417556781.51.0.0556495295996.issue22984@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 22:49:02 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 02 Dec 2014 21:49:02 +0000 Subject: [issue12987] Demo/scripts/newslist.py has non-free licensing terms In-Reply-To: <1316106376.14.0.821549088904.issue12987@psf.upfronthosting.co.za> Message-ID: <1417556942.04.0.454096826031.issue12987@psf.upfronthosting.co.za> Terry J. Reedy added the comment: If we are going to backport the removal from the distribution of Demo/scripts/newslist.py to 2.7, it might as well be done immediately, before 2.7.9 goes out. Benjamin? I am more concerned about separately licensed stdlib modules, such as turtle* (and others). Do they all properly 'fall under the PSF license'? Has this been systematically checked (and recorded)? Is there a policy in place with respect to new modules? * G.Lingl said in email he would sign he contributor agreement in August, but none is recorded yet. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 22:58:07 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 02 Dec 2014 21:58:07 +0000 Subject: [issue22984] test_json.test_endless_recursion(): "Fatal Python error: Cannot recover from stack overflow." on x86 XP-4 3.x buildbot In-Reply-To: <1417554919.08.0.0786746086364.issue22984@psf.upfronthosting.co.za> Message-ID: <1417557487.77.0.0429133076736.issue22984@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: JSON encoder uses recursion calls guards but they don't save from an overflow of C stack. How to reproduce: import json sys.setrecursionlimit(1000000000) json.dumps(5j, check_circular=False, default=lambda o: [o]) ---------- components: +Extension Modules _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 22:58:49 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 02 Dec 2014 21:58:49 +0000 Subject: [issue17401] io.FileIO closefd parameter is not documented nor shown in repr In-Reply-To: <1363057927.36.0.00381165430664.issue17401@psf.upfronthosting.co.za> Message-ID: <1417557529.7.0.0449431287642.issue17401@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 23:16:17 2014 From: report at bugs.python.org (David Wilson) Date: Tue, 02 Dec 2014 22:16:17 +0000 Subject: [issue14099] ZipFile.open() should not reopen the underlying file In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za> Message-ID: <1417558577.69.0.521383844212.issue14099@psf.upfronthosting.co.za> David Wilson added the comment: Sounds great :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 2 23:53:07 2014 From: report at bugs.python.org (eryksun) Date: Tue, 02 Dec 2014 22:53:07 +0000 Subject: [issue22976] multiprocessing Queue empty() is broken on Windows In-Reply-To: <1417514973.26.0.394264585481.issue22976@psf.upfronthosting.co.za> Message-ID: <1417560787.87.0.70902014554.issue22976@psf.upfronthosting.co.za> eryksun added the comment: This also hangs for me in 2.7.8 64-bit, Windows 7. To poll the pipe, the parent process calls PeekNamedPipe, which blocks because the child has already called ReadFile. > It is possible that the problem is also present in Python 3. multiprocessing switched to overlapped I/O in 3.3, which avoids this problem. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 00:06:55 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 02 Dec 2014 23:06:55 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1417561615.75.0.359564215765.issue18967@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Thanks for the reminder/suggestion. Re-reading Ezio's two patches (newsmerge.py and .hg/hgrc additions in msg217079), they appear to jointly automate what I now do by hand (revert to local and dump merge artifacts, replace with edited file with new entries pasted in, and mark as resolved) . I also checked that the current Windows installers make .py files executable, so hg should be able to run newsmerge on Windows. I have downloaded the file and made the additions to my 3.5 hgrc to test next time I have a news entry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 00:11:29 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 02 Dec 2014 23:11:29 +0000 Subject: [issue13027] python 2.6.6 interpreter core dumps on modules command from help prompt In-Reply-To: <1316699786.14.0.395194212825.issue13027@psf.upfronthosting.co.za> Message-ID: <1417561889.71.0.823790746855.issue13027@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I would close this anyway, but 2.6 is no longer maintained even for security patches. ---------- stage: -> resolved status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 00:16:34 2014 From: report at bugs.python.org (Omer Katz) Date: Tue, 02 Dec 2014 23:16:34 +0000 Subject: [issue22985] Segfault on time.sleep Message-ID: <1417562194.55.0.557233180564.issue22985@psf.upfronthosting.co.za> New submission from Omer Katz: I have found what appears to be a segfualt in time.sleep but I'm not sure. I have verified that the segfualt occurs both on Python 2.7.8 and 3.4.2. The following program that reproduces the segfault uses my fork of billiard, a replacement for the multiprocessing module that is used by celery. In order to install: pip install git+https://github.com/thedrow/billiard at topic/dill-with-threads The program: from billiard.pool import ThreadPool p1 = ThreadPool() class Foo(object): def a(self): print("a") return 1 def do(self): return p1.apply_async(self.a) foo = Foo() r = foo.do() print(r.get()) p1.close() p1.join() The output from gdb: gdb -ex r -q --args python mt_example.py Reading symbols from python...done. Starting program: /home/omer/.virtualenvs/billiard/bin/python mt_example.py [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7ffff31db700 (LWP 2897)] [New Thread 0x7ffff29da700 (LWP 2898)] [New Thread 0x7ffff21d9700 (LWP 2899)] [New Thread 0x7ffff19d8700 (LWP 2900)] [New Thread 0x7ffff11d7700 (LWP 2901)] [New Thread 0x7ffff09d6700 (LWP 2902)] [New Thread 0x7fffdbfff700 (LWP 2903)] Program received signal SIGTERM, Terminated. [Switching to Thread 0x7ffff21d9700 (LWP 2899)] 0x00007ffff71dc1c3 in select () at ../sysdeps/unix/syscall-template.S:81 81 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) bt #0 0x00007ffff71dc1c3 in select () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007ffff5fd5d5d in floatsleep (secs=) at Modules/timemodule.c:948 #2 time_sleep (self=, args=) at Modules/timemodule.c:206 #3 0x00000000004b658c in call_function (oparg=, pp_stack=0x7ffff21d8540) at Python/ceval.c:4033 #4 PyEval_EvalFrameEx (f=f at entry=0x7ffff463eda8, throwflag=throwflag at entry=0) at Python/ceval.c:2679 #5 0x00000000004b6f6b in PyEval_EvalCodeEx (co=, globals=, locals=locals at entry=0x0, args=, argcount=argcount at entry=4, kws=, kwcount=0, defs=0x7ffff40bab68, defcount=1, closure=0x0) at Python/ceval.c:3265 #6 0x00000000004b5b28 in fast_function (nk=, na=4, n=, pp_stack=0x7ffff21d8730, func=0x7ffff31e2938) at Python/ceval.c:4129 #7 call_function (oparg=, pp_stack=0x7ffff21d8730) at Python/ceval.c:4054 #8 PyEval_EvalFrameEx (f=f at entry=0x7fffe8000b50, throwflag=throwflag at entry=0) at Python/ceval.c:2679 #9 0x00000000004b6f6b in PyEval_EvalCodeEx (co=, globals=, locals=locals at entry=0x0, args=, argcount=argcount at entry=1, kws=, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3265 #10 0x00000000004b5b28 in fast_function (nk=, na=1, n=, pp_stack=0x7ffff21d8920, func=0x7ffff31e28c0) at Python/ceval.c:4129 #11 call_function (oparg=, pp_stack=0x7ffff21d8920) at Python/ceval.c:4054 #12 PyEval_EvalFrameEx (f=f at entry=0x7fffe8000910, throwflag=throwflag at entry=0) at Python/ceval.c:2679 #13 0x00000000004b5bc7 in fast_function (nk=, na=1, n=, pp_stack=0x7ffff21d8a70, func=0x7ffff7e55230) ---Type to continue, or q to quit--- at Python/ceval.c:4119 #14 call_function (oparg=, pp_stack=0x7ffff21d8a70) at Python/ceval.c:4054 #15 PyEval_EvalFrameEx (f=f at entry=0x7ffff31f1210, throwflag=throwflag at entry=0) at Python/ceval.c:2679 #16 0x00000000004b6f6b in PyEval_EvalCodeEx (co=, globals=, locals=locals at entry=0x0, args=args at entry=0x7ffff31dca68, argcount=, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=0x0) at Python/ceval.c:3265 #17 0x0000000000529e70 in function_call (func=0x7ffff7e55140, arg=0x7ffff31dca50, kw=0x0) at Objects/funcobject.c:526 #18 0x0000000000422f5a in PyObject_Call (func=func at entry=0x7ffff7e55140, arg=arg at entry=0x7ffff31dca50, kw=kw at entry=0x0) at Objects/abstract.c:2529 #19 0x000000000042747d in instancemethod_call (func=0x7ffff7e55140, arg=0x7ffff31dca50, kw=0x0) at Objects/classobject.c:2602 #20 0x0000000000422f5a in PyObject_Call (func=func at entry=0x7ffff4636d70, arg=arg at entry=0x7ffff7f93050, kw=) at Objects/abstract.c:2529 #21 0x00000000004b07f7 in PyEval_CallObjectWithKeywords (func=0x7ffff4636d70, arg=0x7ffff7f93050, kw=) at Python/ceval.c:3902 #22 0x00000000004fae92 in t_bootstrap (boot_raw=0x8899c0) at ./Modules/threadmodule.c:614 #23 0x00007ffff7bc40a5 in start_thread (arg=0x7ffff21d9700) at pthread_create.c:309 #24 0x00007ffff71e484d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 ---------- components: Interpreter Core messages: 232059 nosy: Omer.Katz priority: normal severity: normal status: open title: Segfault on time.sleep type: crash versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 00:25:06 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 02 Dec 2014 23:25:06 +0000 Subject: [issue18053] Add checks for Misc/NEWS in make patchcheck In-Reply-To: <1369453600.75.0.470507945427.issue18053@psf.upfronthosting.co.za> Message-ID: <1417562706.34.0.62269514556.issue18053@psf.upfronthosting.co.za> Terry J. Reedy added the comment: > As of now the patchcheck utility adds a notice to modify Misc/NEWS for every patch. Patchcheck truthfully reports whether /docs, ACKS, and NEWS have been modified. I do not read it as saying anything about whether they *should* be updated. For Docs and NEWS, *should* is a judgement call for core devs, which would be very hard to automate. The only remotely simple check would be whether a NEWS item contains a name not in ACKS, and even that is only a suggestion. So lets leave it alone. ---------- resolution: -> rejected stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 00:39:21 2014 From: report at bugs.python.org (Nathaniel Smith) Date: Tue, 02 Dec 2014 23:39:21 +0000 Subject: [issue22986] Improved handling of __class__ assignment Message-ID: <1417563561.24.0.575634102448.issue22986@psf.upfronthosting.co.za> New submission from Nathaniel Smith: Following on from the discussion starting here: http://thread.gmane.org/gmane.comp.python.devel/150438/focus=150604 Here's a patch to improve __class__ assignment. 1) We remove the HEAPTYPE check from object_set_class, and move it to same_slots_added. This fixes an outright bug: previously it was possible for non-HEAPTYPE types to get passed into same_slots_added (either b/c the loop in compatible_for_assignment ended up with non-HEAPTYPE types, or via __bases__ assignment), and it would then wander off following pointers through random memory. 2) Now that object_set_class can potentially accept non-HEAPTYPE types, adjust the reference counting appropriately. 3) To clarify the logic of compatible_for_assignment, rename equiv_structs to compatible_with_tp_base, tweak accordingly, and add a nice comment explaining the logic. (compatible_for_assignment is equiv_structs's only caller so this is totally safe.) 4) Now that equiv_structs/compatible_with_tp_base has a clearer purpose, also move the tp_dealloc check from compatible_for_assignment into compatible_with_tp_base. In the process, add special-case handling for subclass_dealloc, b/c subclass_dealloc delegates to the parent class tp_dealloc anyway. These changes together make it possible to assign to module instances's __class__ slot, which is useful for reasons described in the above thread. So I added a test for this to check the new code. ---------- components: Interpreter Core files: better-__class__-assignment-v1.patch keywords: patch messages: 232061 nosy: njs priority: normal severity: normal status: open title: Improved handling of __class__ assignment Added file: http://bugs.python.org/file37346/better-__class__-assignment-v1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 00:45:52 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 02 Dec 2014 23:45:52 +0000 Subject: [issue12987] Demo/scripts/newslist.py has non-free licensing terms In-Reply-To: <1316106376.14.0.821549088904.issue12987@psf.upfronthosting.co.za> Message-ID: <20141202234548.4187.79376@psf.io> Roundup Robot added the comment: New changeset 54af09408795 by Benjamin Peterson in branch '2.7': nuke ancient script with dubious license (closes #12987) https://hg.python.org/cpython/rev/54af09408795 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 00:47:31 2014 From: report at bugs.python.org (Ethan Furman) Date: Tue, 02 Dec 2014 23:47:31 +0000 Subject: [issue22986] Improved handling of __class__ assignment In-Reply-To: <1417563561.24.0.575634102448.issue22986@psf.upfronthosting.co.za> Message-ID: <1417564051.92.0.536372857772.issue22986@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 00:53:52 2014 From: report at bugs.python.org (Florent Xicluna) Date: Tue, 02 Dec 2014 23:53:52 +0000 Subject: [issue14134] xmlrpc.client.ServerProxy needs timeout parameter In-Reply-To: <1330294741.21.0.00592117933576.issue14134@psf.upfronthosting.co.za> Message-ID: <1417564432.45.0.33259125302.issue14134@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- nosy: +flox versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 00:58:12 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 02 Dec 2014 23:58:12 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: Message-ID: Nick Coghlan added the comment: My initial thought is to add an "abitags" attribute to sys.implementation (plural so we can also indicate stable ABI support). If we define the algorithm clearly, then setuptools & distlib could make it available on earlier Python versions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 01:04:19 2014 From: report at bugs.python.org (Nathaniel Smith) Date: Wed, 03 Dec 2014 00:04:19 +0000 Subject: [issue22986] Improved handling of __class__ assignment In-Reply-To: <1417563561.24.0.575634102448.issue22986@psf.upfronthosting.co.za> Message-ID: <1417565059.53.0.761539066779.issue22986@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Here's a slightly improved patch spurred by a parenthetical comment of Antoine's on the mailing list :-). The only change is that it adds a check in subclass_dealloc to correct the reference counting in the weird case that someone converts a HEAPTYPE object into a non-HEAPTYPE object while it is being deallocated. I should probably also mention that I ran the full test suite against the patched version and everything passed; and with -R 3:2 the only difference is a new reference leak in test_zipfile. I'm guessing this might be spurious, given that AFAIK this test shouldn't be touching __class__ assignment at all? But IDK. ---------- Added file: http://bugs.python.org/file37347/better-__class__-assignment-v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 01:17:15 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 03 Dec 2014 00:17:15 +0000 Subject: [issue22986] Improved handling of __class__ assignment In-Reply-To: <1417563561.24.0.575634102448.issue22986@psf.upfronthosting.co.za> Message-ID: <1417565835.28.0.910527089797.issue22986@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 01:43:15 2014 From: report at bugs.python.org (Eric Snow) Date: Wed, 03 Dec 2014 00:43:15 +0000 Subject: [issue22986] Improved handling of __class__ assignment In-Reply-To: <1417563561.24.0.575634102448.issue22986@psf.upfronthosting.co.za> Message-ID: <1417567395.82.0.7367979865.issue22986@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 01:44:48 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 03 Dec 2014 00:44:48 +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: <1417567488.93.0.65391518111.issue22980@psf.upfronthosting.co.za> Ned Deily added the comment: Re PEP 3149 file names: it hadn't struck me until fairly recently that PEP 3149-style extension file names were never implemented for OS X, i.e. they are still of the form _helperlib.so. I'm not sure why that is the case since other aspects of PEP 3149-like file names do exist on OS X, including naming libpython; perhaps it was just erring on the side of caution. Re bitness: As Marc-Andre points out, Apple addressed the multi-arch problem with the concept of universal (or "fat") binary files, implemented for executables, libs (static and dynamic), and bundles (e.g .so's). In general, dealing with multiple architectures is abstracted away by the compiler tool chain at build time and the dynamic loader at run time and it's not something either Python or the user have to deal with (usually), as various combinations of architectures (currently up to 4 on OS X) are contained within the same file; for example: $ file _socket.so _socket.so: Mach-O universal binary with 3 architectures _socket.so (for architecture x86_64): Mach-O 64-bit bundle x86_64 _socket.so (for architecture i386): Mach-O bundle i386 _socket.so (for architecture ppc7400): Mach-O bundle ppc $ file /usr/bin/python /usr/bin/python: Mach-O universal binary with 3 architectures /usr/bin/python (for architecture x86_64): Mach-O 64-bit executable x86_64 /usr/bin/python (for architecture i386): Mach-O executable i386 /usr/bin/python (for architecture ppc7400): Mach-O executable ppc So, I agree with Marc-Andre that adding arch info (like bitiness) to extension module file names on OS X would add unneeded complexity for little, if any, benefit. That part works well today. Changing builds on OS X to use today's PEP 3149 file names is a separate question. It could help in the case where one site-packages library is used with multiple Python instances but, even there, that is probably not a big issue outside of developer environments: (1) I don't know of any distributor of Python for OS X who supports multiple ABIs (e.g. non-debug vs debug) in one package; (2) Python OS X framework builds, used by python.org, Apple, and most third-parties, generally have separate install locations including their lib-dynload and site-packages directories so installing multiple instances of the same Python version from different vendors isn't a big deal. It would be nice to be able to allow non-debug vs debug builds to co-exist better (the primary use case I see for PEP 3149 file names for Py3 on OS X) but I don't recall anyone asking for it. If we were to change OS X to use today's PEP 3149 file names, I would only want to do it in a new release, not backport it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 01:55:16 2014 From: report at bugs.python.org (Dan Mick) Date: Wed, 03 Dec 2014 00:55:16 +0000 Subject: [issue21963] 2.7.8 backport of Issue1856 (avoid daemon thread problems at shutdown) breaks ceph In-Reply-To: <1405112765.87.0.0636941236839.issue21963@psf.upfronthosting.co.za> Message-ID: <1417568116.53.0.415744176976.issue21963@psf.upfronthosting.co.za> Dan Mick added the comment: Belaboring this a bit just in case what I learn helps with the interpreter change: seems like threading.Thread.start() is hanging in its normal "wait for start" code: (gdb) py-bt #4 Frame 0x25d4de0, for file /usr/lib64/python2.7/threading.py, line 339, in wait (self=<_Condition(_Verbose__verbose=False, _Condition__lock=, acquire=, _Condition__waiters=[], release=) at remote 0x7fe618b29110>, timeout=None, balancing=True, waiter=, saved_state=None) waiter.acquire() #8 Frame 0x7fe618b06d38, for file /usr/lib64/python2.7/threading.py, line 623, in wait (self=<_Event(_Verbose__verbose=False, _Event__flag=False, _Event__cond=<_Condition(_Verbose__verbose=False, _Condition__lock=, acquire=, _Condition__waiters=[], release=) at remote 0x7fe618b29110>) at remote 0x7fe6176a76d0>, timeout=None, balancing=True) self.__cond.wait(timeout, balancing) #12 Frame 0x7fe6175917d0, for file /usr/lib64/python2.7/threading.py, line 753, in start (self=, _Thread__block=<_Condition(_Verbose__verbose=False, _Condition__lock=, acquire=, _Condition__waiters=[], release=) at remote 0x7fe618b29150>, _Thread__name='Thread-11', _Thread__daemonic=True, args=(,), _Thread__started=<_Event(_Verbose__verbose=False, _Event__flag=False, _Event__cond=<_Condition(_Verbose__verbose=False, _Condition__lock=, acquire=, _Condition__waiters=[], release=, args=(,), timeout=0, sys=, interrupt=False, countdown=0, t=, _Thread__block=<_Condition(_Verbose__verbose=False, _Condition__lock=, acquire=, _Condition__waiters=[], release=) at remote 0x7fe618b29150>, _Thread__name='Thread-11', _Thread__daemonic=True, args=(...), _Thread__started=<_Event(_Verbose__verbose=False, _Event__flag=False, _Event__cond=<_Condition(_Verbose__verbose=False, _Condition__lock=, acquire=, _Condition__waiters=[, state='connected', librados=, rados_mon_command=<_FuncPtr(__name__='rados_mon_command') at remote 0x7fe617611a10>, rados_buffer_free=<_FuncPtr(__name__='rados_buffer_free') at remote 0x7fe617611ae0>, rados_conf_set=<_FuncPtr(__name__='rados_conf_set') at remote 0x7fe6176117a0>, _handle=39608352, _name='librados.so.2', rados_create2=<_FuncPtr(__name__='rados_create2') at remote 0x7fe6176116d0>, rados_conf_read_file=<_FuncPtr(__name__='rados_conf_read_file') at remote 0x7fe617611870>, rados_connect=<_FuncPtr(__name__='rados_connect') at remote 0x7fe617611940>, rados_shutdown=<_FuncPtr(__name__='rados_shutdown') at remote 0x7fe617611bb0>) at remote 0x7fe617572a10>, rados_id=None) at remote 0x7fe6175729d0>) run_in_thread(self.librados.rados_shutdown, (self.cluster,)) #22 Frame 0x7fe617683c20, for file /usr/lib/python2.7/site-packages/rados.py, line 264, in __del__ (self=, state='connected', librados=, rados_mon_command=<_FuncPtr(__name__='rados_mon_command') at remote 0x7fe617611a10>, rados_buffer_free=<_FuncPtr(__name__='rados_buffer_free') at remote 0x7fe617611ae0>, rados_conf_set=<_FuncPtr(__name__='rados_conf_set') at remote 0x7fe6176117a0>, _handle=39608352, _name='librados.so.2', rados_create2=<_FuncPtr(__name__='rados_create2') at remote 0x7fe6176116d0>, rados_conf_read_file=<_FuncPtr(__name__='rados_conf_read_file') at remote 0x7fe617611870>, rados_connect=<_FuncPtr(__name__='rados_connect') at remote 0x7fe617611940>, rados_shutdown=<_FuncPtr(__name__='rados_shutdown') at remote 0x7fe617611bb0>) at remote 0x7fe617572a10>, rados_id=None) at remote 0x7fe6175729d0>) self.shutdown() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 04:06:36 2014 From: report at bugs.python.org (Greg Turner) Date: Wed, 03 Dec 2014 03:06:36 +0000 Subject: [issue22968] types._calculate_meta nit: isinstance != PyType_IsSubtype In-Reply-To: <1417293514.02.0.452977288528.issue22968@psf.upfronthosting.co.za> Message-ID: <1417575996.27.0.0377229521666.issue22968@psf.upfronthosting.co.za> Greg Turner added the comment: > perhaps "isinstance(x, type)" should have been "issubclass(x, type)" to correctly capture how python 2 does it. Actually, scratch that -- its a brain fart. IIUC new_class was created because, at the time, there was no exposed turnkey method to execute the PEP3115 protocol... if that's right, is it worth considering, now that __build_class__ is exposed, a reimplementation like: def _pass(ns): pass def new_class(name, bases=(), kwds={}, exec_body=_pass): __build_class__(exec_body, name, *bases, **kwds) ? But this is the wrong place to ask. ... BTW, since my original post I've figured out a bunch of things, or think I have: * new_class should model __build_class__ * __build_class__ need not model type_new in terms of what it allows. I think point one is what was confusing me before. It is perhaps worth asking, if the differences between type_new and __build_class__ make sense, given that python 3's type_new is stricter than python 2's? I think I've figured that out too: A given (metatype, bases) tuple may be sensibly used to implement the PEP3115 protocol only if either: A) it can be proved that type_new will return NULL if it is invoked like type_new(metatype, name, bases,...), or, B) it can be proved that type_new, when invoked like type_new(metatype, name, bases, ...), will use metatype, and not some other (e.g., more derived) type, as the tp_base of the thing it creates, in the event that it does not return NULL. If the above is falsified, we pretty clearly have a situation where build_type has used the wrong metaclass. But the fact that __build_class__ is more liberal than type_new is not a problem from the perspective of type_new -- indeed it's a feature, and I'm now satisfied that the above constraint holds. I've attached a new patch, this time I tested it. ---------- Added file: http://bugs.python.org/file37348/fix_types_calculate_meta_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 04:17:39 2014 From: report at bugs.python.org (Greg Turner) Date: Wed, 03 Dec 2014 03:17:39 +0000 Subject: [issue22968] Lib/types.py nit: isinstance != PyType_IsSubtype In-Reply-To: <1417293514.02.0.452977288528.issue22968@psf.upfronthosting.co.za> Message-ID: <1417576659.4.0.621386271449.issue22968@psf.upfronthosting.co.za> Changes by Greg Turner : ---------- title: types._calculate_meta nit: isinstance != PyType_IsSubtype -> Lib/types.py nit: isinstance != PyType_IsSubtype _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 08:18:41 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 03 Dec 2014 07:18:41 +0000 Subject: [issue14099] ZipFile.open() should not reopen the underlying file In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za> Message-ID: <20141203071834.96696.10708@psf.io> Roundup Robot added the comment: New changeset c2c4cde55f6f by Serhiy Storchaka in branch '2.7': Issue #14099: ZipFile.open() no longer reopen the underlying file. Objects https://hg.python.org/cpython/rev/c2c4cde55f6f New changeset e5bb3044402b by Serhiy Storchaka in branch '3.4': Issue #14099: ZipFile.open() no longer reopen the underlying file. Objects https://hg.python.org/cpython/rev/e5bb3044402b New changeset 334c01aa7f93 by Serhiy Storchaka in branch 'default': Issue #14099: ZipFile.open() no longer reopen the underlying file. Objects https://hg.python.org/cpython/rev/334c01aa7f93 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 08:28:46 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 03 Dec 2014 07:28:46 +0000 Subject: [issue17401] io.FileIO closefd parameter is not documented nor shown in repr In-Reply-To: <1363057927.36.0.00381165430664.issue17401@psf.upfronthosting.co.za> Message-ID: <1417591726.49.0.652194225632.issue17401@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Arfrever have suggested on IRC to backport documentation part of the patch to 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 08:30:04 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 03 Dec 2014 07:30:04 +0000 Subject: [issue14099] ZipFile.open() should not reopen the underlying file In-Reply-To: <1329993992.32.0.270050568564.issue14099@psf.upfronthosting.co.za> Message-ID: <1417591804.62.0.301027542391.issue14099@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks Stepan for the idea. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 08:32:37 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 03 Dec 2014 07:32:37 +0000 Subject: [issue16569] Preventing errors of simultaneous access in zipfile In-Reply-To: <1354112511.94.0.436567820333.issue16569@psf.upfronthosting.co.za> Message-ID: <1417591957.95.0.552276220486.issue16569@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Closed in favor of issue14099. ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 08:36:23 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 03 Dec 2014 07:36:23 +0000 Subject: [issue22721] pprint output for sets and dicts is not stable In-Reply-To: <1414170050.02.0.186594262536.issue22721@psf.upfronthosting.co.za> Message-ID: <1417592183.35.0.908321982876.issue22721@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: My question to Raymond is should we use the "<" operator or special methods __lt__ and __gt__ (this is the difference between alternative patches)? The use of repr instead of id is different issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 08:50:08 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 03 Dec 2014 07:50:08 +0000 Subject: [issue22746] cgitb html: wrong encoding for utf-8 In-Reply-To: <1414435737.5.0.509535388247.issue22746@psf.upfronthosting.co.za> Message-ID: <1417593008.87.0.460263139809.issue22746@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: We can convert cgitb.hook to produce ASCII-compatible output with charrefs in 3.x. But there is a problem with str in 2.7. 8-bit string can contain non-ASCII data and the encoding is not known in general case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 10:24:53 2014 From: report at bugs.python.org (Waldemar Parzonka) Date: Wed, 03 Dec 2014 09:24:53 +0000 Subject: [issue22983] Cookie parsing should be more permissive In-Reply-To: <1417539577.52.0.585535774996.issue22983@psf.upfronthosting.co.za> Message-ID: <1417598693.53.0.420457843064.issue22983@psf.upfronthosting.co.za> Changes by Waldemar Parzonka : ---------- nosy: +Waldemar.Parzonka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 13:58:17 2014 From: report at bugs.python.org (Greg Turner) Date: Wed, 03 Dec 2014 12:58:17 +0000 Subject: [issue22968] Lib/types.py nit: isinstance != PyType_IsSubtype In-Reply-To: <1417293514.02.0.452977288528.issue22968@psf.upfronthosting.co.za> Message-ID: <1417611497.96.0.445192667418.issue22968@psf.upfronthosting.co.za> Greg Turner added the comment: Just added a commit message. ---------- Added file: http://bugs.python.org/file37349/fix_types_calculate_meta_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 14:02:25 2014 From: report at bugs.python.org (Greg Turner) Date: Wed, 03 Dec 2014 13:02:25 +0000 Subject: [issue22968] Lib/types.py nit: isinstance != PyType_IsSubtype In-Reply-To: <1417293514.02.0.452977288528.issue22968@psf.upfronthosting.co.za> Message-ID: <1417611745.87.0.964730894107.issue22968@psf.upfronthosting.co.za> Greg Turner added the comment: Here are some tests for this... first, some tests that pass right now and demonstrate, I think, correctness of the second batch of tests. ---------- Added file: http://bugs.python.org/file37350/test_virtual_metaclasses.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 14:04:02 2014 From: report at bugs.python.org (Greg Turner) Date: Wed, 03 Dec 2014 13:04:02 +0000 Subject: [issue22968] Lib/types.py nit: isinstance != PyType_IsSubtype In-Reply-To: <1417293514.02.0.452977288528.issue22968@psf.upfronthosting.co.za> Message-ID: <1417611842.01.0.400021436945.issue22968@psf.upfronthosting.co.za> Greg Turner added the comment: And some analogous tests for types.py, which don't pass without fix_types_calculate_meta_v3.patch. ---------- Added file: http://bugs.python.org/file37351/test_virtual_metaclasses_in_types_module.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 14:04:20 2014 From: report at bugs.python.org (Greg Turner) Date: Wed, 03 Dec 2014 13:04:20 +0000 Subject: [issue22968] Lib/types.py nit: isinstance != PyType_IsSubtype In-Reply-To: <1417293514.02.0.452977288528.issue22968@psf.upfronthosting.co.za> Message-ID: <1417611860.43.0.213722367754.issue22968@psf.upfronthosting.co.za> Greg Turner added the comment: And some analogous tests for types.py, which don't pass without fix_types_calculate_meta_v3.patch. ---------- Added file: http://bugs.python.org/file37352/test_virtual_metaclasses_in_types_module.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 14:15:58 2014 From: report at bugs.python.org (Kali Kaneko) Date: Wed, 03 Dec 2014 13:15:58 +0000 Subject: [issue22987] ssl module documentation: incorrect compatibility matrix Message-ID: <1417612558.33.0.597958584531.issue22987@psf.upfronthosting.co.za> New submission from Kali Kaneko: The SSLv23 row that can be read in the socket creation section in the documentation for the ssl module looks incorrect: https://docs.python.org/2.7/library/ssl.html#socket-creation by my tests (with python 2.7.8) that row should read: yes no yes yes yes yes instead of: yes no yes no no no as it does now. Since a client specifying SSLv23 should be (and it seems to be) able to negotiate the highest available version that the server can offer, no matter if the server has chosen a tls version. Is this an error in the documentation, or is there any situation in which the current values hold true? ---------- assignee: docs at python components: Documentation messages: 232078 nosy: docs at python, kali priority: normal severity: normal status: open title: ssl module documentation: incorrect compatibility matrix versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 17:05:05 2014 From: report at bugs.python.org (Alex Gaynor) Date: Wed, 03 Dec 2014 16:05:05 +0000 Subject: [issue22987] ssl module documentation: incorrect compatibility matrix In-Reply-To: <1417612558.33.0.597958584531.issue22987@psf.upfronthosting.co.za> Message-ID: <1417622705.12.0.262773504719.issue22987@psf.upfronthosting.co.za> Alex Gaynor added the comment: I agree this is a bug, but I believe the correct output is: no yes yes yes yes yes ---------- nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 17:13:44 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 03 Dec 2014 16:13:44 +0000 Subject: [issue22987] ssl module documentation: incorrect compatibility matrix In-Reply-To: <1417612558.33.0.597958584531.issue22987@psf.upfronthosting.co.za> Message-ID: <1417623224.61.0.286231210035.issue22987@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Alex is right. The current doc was valid for older OpenSSL versions, which sent a SSLv2 hello with SSLv23. Reference from the OpenSSL docs: """If the cipher list does not contain any SSLv2 ciphersuites (the default cipher list does not) or extensions are required (for example server name) a client will send out TLSv1 client hello messages including extensions and will indicate that it also understands TLSv1.1, TLSv1.2 and permits a fallback to SSLv3. A server will support SSLv3, TLSv1, TLSv1.1 and TLSv1.2 protocols.""" (https://www.openssl.org/docs/ssl/SSL_CTX_new.html) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 18:51:14 2014 From: report at bugs.python.org (Felipe) Date: Wed, 03 Dec 2014 17:51:14 +0000 Subject: [issue22988] No error when yielding from `finally` Message-ID: <1417629074.29.0.62488033247.issue22988@psf.upfronthosting.co.za> New submission from Felipe: This bug report is the opposite of issue #14718. The interpreter did not raise an error when it encountered a `yield` expression inside the `finally` part of a `try/finally` statement. My system's info: Python 3.4.2 (v3.4.2:ab2c023a9432, Oct 6 2014, 22:15:05) [MSC v.1600 32 bit (Intel)] on win32 More detail ======================================================= My interpreter does not raise any errors when yielding from a `finally` block. The documentation states, "Yield expressions are allowed in the try clause of a try ... finally construct."[1] Though not explicitly stated, the suggestion is that `yield` is not allowed in the `finally` clause. Issue #14718 suggests that this interpretation is correct. Not raising an exception for `yield` inside of `finally` can cause incorrect behavior when the generator raises its own unhandled exception in the `try` block. PEP 342 says, "If the generator raises an uncaught exception, it is propagated to send()'s caller." In this case, however, the exception gets paused at the `yield` expression, instead of propagating to the caller. Here's an example that can clarify the issue: >>> def f(): # I expected this function not to compile ... try: ... raise ValueError ... finally: ... yield 1 # Execution freezes here instead of propagating the ValueError ... yield "done" ... >>> g = f() >>> g.send(None) # PEP 342 would require ValueError to be raised here 1 >>> g.send(1) Traceback (most recent call last): File "", line 1, in File "", line 3, in f2 ValueError I may be arguing over the meaning of "uncaught exception," but I expected (given that the function compiles and doesn't raise a `RuntimeError`) the `ValueError` to propagate rather than get frozen. Example 2 ------------------------------------------------------- The second example is adapted from http://bugs.python.org/issue14718, where the submitter received a `RuntimeError`, but I did not: >>> def f2(): # I also expected this function not to compile ... try: ... yield 1 ... finally: ... yield 4 ... >>> g = f() # issue 14718 suggests this should raise RuntimeError >>> next(g) 1 >>> next(g) 4 >>> next(g) Traceback (most recent call last): File "", line 1, in StopIteration Possible resolution: ========================================================= 1. Enforce the ban on `yield` inside a finally `clause`. It seems like this should already be happening, so I'm not sure why my version isn't performing the check. This could be a run-time check (which seems like it may already be implemented), but I think this could even be a compile-time check (by looking at the AST). 2. Clarify the documentation to make explicit the ban on the use of `yield` inside the `finally` clause, and specify what type of error it will raise (i.e., `SyntaxError` or `RuntimeError`? or something else?). I'll submit a patch for 2 if there's support for this change, and I will work on 1 if someone can point me in the right direction. I've engaged with the C source relating to the different protocols, but have never looked through the compiler/VM. Notes ============================================ [1] https://docs.python.org/3.4/reference/expressions.html#yield-expressions ---------- components: Interpreter Core messages: 232081 nosy: fov priority: normal severity: normal status: open title: No error when yielding from `finally` type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 19:26:22 2014 From: report at bugs.python.org (Ethan Furman) Date: Wed, 03 Dec 2014 18:26:22 +0000 Subject: [issue22988] No error when yielding from `finally` In-Reply-To: <1417629074.29.0.62488033247.issue22988@psf.upfronthosting.co.za> Message-ID: <1417631182.58.0.029003401711.issue22988@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman, giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 19:38:03 2014 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 03 Dec 2014 18:38:03 +0000 Subject: [issue22988] No error when yielding from `finally` In-Reply-To: <1417629074.29.0.62488033247.issue22988@psf.upfronthosting.co.za> Message-ID: <1417631883.97.0.998003049828.issue22988@psf.upfronthosting.co.za> Guido van Rossum added the comment: There is no prohibition in the language against yield in a finally block. It may not be a good idea, but the behavior you see is all as it should be. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 19:45:17 2014 From: report at bugs.python.org (Paul Hartmann) Date: Wed, 03 Dec 2014 18:45:17 +0000 Subject: [issue22989] HTTPResponse.msg not as documented Message-ID: <1417632317.82.0.906874710781.issue22989@psf.upfronthosting.co.za> New submission from Paul Hartmann: HTTPResponse.msg is documented as a http.client.HTTPMessage object containing the headers of the response [1]. But in fact this is a string containing the status code: >>> import urllib.request >>> req=urllib.request.urlopen('http://heise.de') >>> content = req.read() >>> type(req.msg) >>> req.msg 'OK' This value is apparently overriden in urllib/request.py: ./urllib/request.py:1246: # This line replaces the .msg attribute of the HTTPResponse ./urllib/request.py-1247- # with .headers, because urllib clients expect the response to ./urllib/request.py:1248: # have the reason in .msg. It would be good to mark this ./urllib/request.py-1249- # attribute is deprecated and get then to use info() or ./urllib/request.py-1250- # .headers. ./urllib/request.py:1251: r.msg = r.reason Anyhow, it should be documented, that is not safe to retrieve the headers with HTTPResponse.msg and maybe add HTTPResponse.headers to the documentation. [1] https://docs.python.org/3/library/http.client.html ---------- assignee: docs at python components: Documentation messages: 232083 nosy: bastik, docs at python priority: normal severity: normal status: open title: HTTPResponse.msg not as documented versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 19:49:57 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 03 Dec 2014 18:49:57 +0000 Subject: [issue22988] No error when yielding from `finally` In-Reply-To: <1417629074.29.0.62488033247.issue22988@psf.upfronthosting.co.za> Message-ID: <1417632597.7.0.681785594826.issue22988@psf.upfronthosting.co.za> R. David Murray added the comment: FIlipe, in case you hadn't noticed, the reason for the error in the other issue is that the generator was closed when it got garbage collected, and it ignored the close (executed a yield after the close). Thus the error message there is accurate and expected, just as (as Guido said) the behavior here is consistent with the combined semantics of generators and try/finally. Do you want to suggest an improvement to the docs? It may be that we'll decide a change is more confusing than helpful, but we'll need someone to suggest a wording to decide that. ---------- assignee: -> docs at python components: +Documentation -Interpreter Core nosy: +docs at python, r.david.murray versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 19:56:51 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 03 Dec 2014 18:56:51 +0000 Subject: [issue22989] HTTPResponse.msg not as documented In-Reply-To: <1417632317.82.0.906874710781.issue22989@psf.upfronthosting.co.za> Message-ID: <1417633011.31.0.957705579881.issue22989@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 20:04:04 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 03 Dec 2014 19:04:04 +0000 Subject: [issue22987] ssl module documentation: incorrect compatibility matrix In-Reply-To: <1417612558.33.0.597958584531.issue22987@psf.upfronthosting.co.za> Message-ID: <20141203190354.105527.19779@psf.io> Roundup Robot added the comment: New changeset 7af5d5493497 by Antoine Pitrou in branch '2.7': Fix #22987: update the compatibility matrix for a SSLv23 client. https://hg.python.org/cpython/rev/7af5d5493497 New changeset 9f03572690d2 by Antoine Pitrou in branch '3.4': Fix #22987: update the compatibility matrix for a SSLv23 client. https://hg.python.org/cpython/rev/9f03572690d2 New changeset 7509a0607c40 by Antoine Pitrou in branch 'default': Fix #22987: update the compatibility matrix for a SSLv23 client. https://hg.python.org/cpython/rev/7509a0607c40 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 20:05:41 2014 From: report at bugs.python.org (Ethan Furman) Date: Wed, 03 Dec 2014 19:05:41 +0000 Subject: [issue22988] No error when yielding from `finally` In-Reply-To: <1417629074.29.0.62488033247.issue22988@psf.upfronthosting.co.za> Message-ID: <1417633541.42.0.915549597985.issue22988@psf.upfronthosting.co.za> Ethan Furman added the comment: Here's the excerpt from the docs: -------------------------------- > Yield expressions are allowed in the try clause of a try ... finally construct. > If the generator is not resumed before it is finalized (by reaching a zero reference > count or by being garbage collected), the generator-iterator?s close() method will be > called, allowing any pending finally clauses to execute. This certainly makes it sound like 'yield' is okay in the 'try' portion, but not the 'finally' portion. So 'yield' is allowed in the 'try' portion, and it's allowed in the 'finally' portion -- is it also allowed in the 'except' portion? If so, we could simplify the first line to: > Yield expressions are allowed in try ... except ... finally constructs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 20:11:10 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 03 Dec 2014 19:11:10 +0000 Subject: [issue22987] ssl module documentation: incorrect compatibility matrix In-Reply-To: <1417612558.33.0.597958584531.issue22987@psf.upfronthosting.co.za> Message-ID: <1417633870.66.0.780919789964.issue22987@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 20:37:42 2014 From: report at bugs.python.org (Felipe) Date: Wed, 03 Dec 2014 19:37:42 +0000 Subject: [issue22988] No error when yielding from `finally` In-Reply-To: <1417629074.29.0.62488033247.issue22988@psf.upfronthosting.co.za> Message-ID: <1417635462.26.0.321311362467.issue22988@psf.upfronthosting.co.za> Felipe added the comment: Thanks for the clarification; sorry I misread issue #14718. I agree with Ethan's point. Though I would say "Yield expressions are allowed anywhere in try ... except ... finally constructs." I'd also like to explicitly add a point about the exception-handling machinery getting frozen, but I'm not sure how to phrase it clearly and accurately. Here's an attempt (my adds in square brackets): "By suspended, we mean that all local state is retained, including the current bindings of local variables, the instruction pointer, the internal evaluation stack, [active exception handlers, and paused exceptions in finally blocks]." Another approach would be: "By suspended, we mean that all local state is retained, including the current bindings of local variables, the instruction pointer, and the internal evaluation stack. [The state of any exception-handling code is also retained when yielding from a try ... except ... finally statement.]" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 20:39:15 2014 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 03 Dec 2014 19:39:15 +0000 Subject: [issue22988] No error when yielding from `finally` In-Reply-To: <1417629074.29.0.62488033247.issue22988@psf.upfronthosting.co.za> Message-ID: <1417635555.27.0.57448612102.issue22988@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 20:40:44 2014 From: report at bugs.python.org (Matt Hansen) Date: Wed, 03 Dec 2014 19:40:44 +0000 Subject: [issue11101] plistlib has no graceful way of handing None values In-Reply-To: <1296673853.21.0.702351569168.issue11101@psf.upfronthosting.co.za> Message-ID: <1417635644.2.0.19815210343.issue11101@psf.upfronthosting.co.za> Changes by Matt Hansen : ---------- nosy: +Matt.Hansen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 20:45:40 2014 From: report at bugs.python.org (Jim Jewett) Date: Wed, 03 Dec 2014 19:45:40 +0000 Subject: [issue16329] mimetypes does not support webm type In-Reply-To: <1351258498.52.0.166970519729.issue16329@psf.upfronthosting.co.za> Message-ID: <1417635940.56.0.469613314708.issue16329@psf.upfronthosting.co.za> Jim Jewett added the comment: I interpreted Issue 15's closure as being about the distinction between Application/webm vs Video/webm, etc. As far as I understand it, the python stdlib doesn't actually care what the major Mime type is, or, frankly, even whether the definition makes sense. We just want Video/webm to be registered. I have created issue 886 on the webm site at https://code.google.com/p/webm/issues/detail?id=886&can=4&colspec=ID%20Pri%20mstone%20ReleaseBlock%20Type%20Component%20Status%20Owner%20Summary Anyone with more detail (e.g., do we need to define Application/webm as well as Video/webm ... do we care what the definition is ... etc ...) is encouraged to chime in. ---------- nosy: +Jim.Jewett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 20:48:41 2014 From: report at bugs.python.org (Demian Brecht) Date: Wed, 03 Dec 2014 19:48:41 +0000 Subject: [issue21557] os.popen & os.system lack shell-related security warnings In-Reply-To: <1400794428.31.0.170474236819.issue21557@psf.upfronthosting.co.za> Message-ID: <1417636121.92.0.773386061422.issue21557@psf.upfronthosting.co.za> Demian Brecht added the comment: After discussion in Rietveld, the patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 20:59:12 2014 From: report at bugs.python.org (Chris Rebert) Date: Wed, 03 Dec 2014 19:59:12 +0000 Subject: [issue16329] mimetypes does not support webm type In-Reply-To: <1351258498.52.0.166970519729.issue16329@psf.upfronthosting.co.za> Message-ID: <1417636752.18.0.771165995674.issue16329@psf.upfronthosting.co.za> Chris Rebert added the comment: WebM's docs use "video/webm" and never use an "application/*" type. See http://www.webmproject.org/docs/container/ They also specify "audio/webm" for audio-only content, but both use the same file extension, so associating ".webm" with "video/webm" seems quite reasonable since it's more general (an audio-only file is just a degenerate case of an audiovideo file). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 21:52:28 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 03 Dec 2014 20:52:28 +0000 Subject: [issue22982] BOM incorrectly inserted before writing, after seeking in text file In-Reply-To: <1417538502.93.0.814458445398.issue22982@psf.upfronthosting.co.za> Message-ID: <1417639948.46.0.787296473775.issue22982@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This is a limitation more than a bug. When you seek to the start of the file, the encoder is reset because Python thinks you are gonna to write there. If you remove the call to `file.seek(0, io.SEEK_SET)`, things work fine. @Amaury, whence can only be zero there: https://hg.python.org/cpython/file/0744ceb5c0ed/Lib/_pyio.py#l1960 ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 21:57:15 2014 From: report at bugs.python.org (Mark Ingram) Date: Wed, 03 Dec 2014 20:57:15 +0000 Subject: [issue22982] BOM incorrectly inserted before writing, after seeking in text file In-Reply-To: <1417538502.93.0.814458445398.issue22982@psf.upfronthosting.co.za> Message-ID: <1417640235.1.0.0763212335833.issue22982@psf.upfronthosting.co.za> Mark Ingram added the comment: It's more than a limitation, because if I call `file.seek(0, io.SEEK_END)` then the encoder is still reset, and will still write the BOM, even at the end of the file. This also means that it's impossible to seek in a text file that you want to append to. I've had to work around this by opening the file as binary, manually writing the BOM, and writing the strings as encoded bytes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 22:32:25 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 03 Dec 2014 21:32:25 +0000 Subject: [issue21557] os.popen & os.system lack shell-related security warnings In-Reply-To: <1400794428.31.0.170474236819.issue21557@psf.upfronthosting.co.za> Message-ID: <1417642345.9.0.793059048881.issue21557@psf.upfronthosting.co.za> R. David Murray added the comment: Since Raymond is the person who tends to object most strongly to warning boxes in the docs, let's get his opinion on this. I'm not sure that the warning box is necessary, the text may be sufficient. On the other hand, this *is* a significant insecurity vector. As far as the text goes, I'd combine the two paragraphs and introduce the text from the second one with "Alternatively, ...". And if it isn't a warning box, the the language should be refocused to be positive: "Use the Popen module with shell=False to avoid the common security issues involved in using unsanitized input from untrusted sources..." ---------- nosy: +r.david.murray, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 3 23:46:35 2014 From: report at bugs.python.org (Alan) Date: Wed, 03 Dec 2014 22:46:35 +0000 Subject: [issue22990] bdist installation dialog Message-ID: <1417646795.33.0.270415129525.issue22990@psf.upfronthosting.co.za> New submission from Alan: The "Select Python Installations" dialog box contains the line "Select the Python locations where should be installed." If is anything other than a very short string, the line is truncated, due to the following factors: - the line doesn't wrap - the dialog box can't be resized - the message (aside from the distribution name) is fairly lengthy See the screenshot, where I created a distribution of a package whose name is "not_such_a_long_name". At the same time as the line is made wrappable and/or the dialog box is made resizable, it would be nice to improve the wording of the message. It took me a while to figure out what was going on because the GUI elements have different meanings from the ones seen more commonly. Usually these elements (the menu with choices beginning with "Will be installed on local hard drive" and ending with "Entire feature will be unavailable") are used to choose one or more features of an application to install, not one or more places to install the same application. Maybe something like this would work: Select Where to Install Select Python locations in which to install : Python 2.7 (found in the registry) Python 3.3 (found in the registry) Python (other location) instead of the current: Select Python Installations Select the Python locations where should be installed: Python 2.7 from registry Python 3.3 from registry Python from another location ---------- components: Distutils files: bdist_screenshot.PNG messages: 232094 nosy: Alan, dstufft, eric.araujo priority: normal severity: normal status: open title: bdist installation dialog type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file37353/bdist_screenshot.PNG _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 00:10:25 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 03 Dec 2014 23:10:25 +0000 Subject: [issue16329] mimetypes does not support webm type In-Reply-To: <1351258498.52.0.166970519729.issue16329@psf.upfronthosting.co.za> Message-ID: <1417648225.04.0.70158626523.issue16329@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Antoine Pitrou and Ethan Furman agreed on pydev that this should be applied. Chris, is the existing patch exactly what you think is needed? ---------- nosy: +terry.reedy stage: -> commit review type: -> enhancement versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 00:12:05 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 03 Dec 2014 23:12:05 +0000 Subject: [issue16329] mimetypes does not support webm type In-Reply-To: <1351258498.52.0.166970519729.issue16329@psf.upfronthosting.co.za> Message-ID: <1417648325.68.0.789964099036.issue16329@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Does test_mimetypes (assuming it exists), have a test for the mapping, are is something needed? ---------- stage: commit review -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 00:19:44 2014 From: report at bugs.python.org (Chris Rebert) Date: Wed, 03 Dec 2014 23:19:44 +0000 Subject: [issue16329] mimetypes does not support webm type In-Reply-To: <1351258498.52.0.166970519729.issue16329@psf.upfronthosting.co.za> Message-ID: <1417648784.81.0.544269687854.issue16329@psf.upfronthosting.co.za> Chris Rebert added the comment: Yes, the existing patch looks fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 00:36:28 2014 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 03 Dec 2014 23:36:28 +0000 Subject: [issue16329] mimetypes does not support webm type In-Reply-To: <1351258498.52.0.166970519729.issue16329@psf.upfronthosting.co.za> Message-ID: <1417649788.6.0.685451001613.issue16329@psf.upfronthosting.co.za> Ezio Melotti added the comment: A while ago there was a discussion about updating the MIME registry on bug fix releases too, and I seem to remember people agreed it should be done. If this is indeed the case and the patch is accepted for 3.5, should it also be backported to 2.7 and 3.4? ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 00:50:33 2014 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 03 Dec 2014 23:50:33 +0000 Subject: [issue22991] test_gdb leaves the terminal in raw mode with gdb 7.8.1 Message-ID: <1417650633.0.0.0644519046784.issue22991@psf.upfronthosting.co.za> New submission from Xavier de Gaye: This happens on archlinux. Annoying: the terminal becomes unusable unless you type blindly 'stty sane ', and the backspace key is still wrong. This does not happen with gdb 7.6.1. And this does not happen when running gdb with the 'mi' interpreter. The attached patch uses GDB/MI. The problem with using the GDB/MI interface, is that it is very verbose when trying to debug a test. ---------- components: Tests files: gdbmi.patch keywords: patch messages: 232099 nosy: xdegaye priority: normal severity: normal status: open title: test_gdb leaves the terminal in raw mode with gdb 7.8.1 type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file37354/gdbmi.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 01:09:14 2014 From: report at bugs.python.org (Demian Brecht) Date: Thu, 04 Dec 2014 00:09:14 +0000 Subject: [issue22992] Adding a git developer's guide to Mercurial to devguide Message-ID: <1417651753.19.0.905189748743.issue22992@psf.upfronthosting.co.za> New submission from Demian Brecht: Coming out of a recent thread in python-dev, it was mentioned that adding a git developer's guide to mercurial may be beneficial to help lower the initial barrier of entry for prospective contributors (https://mail.python.org/pipermail/python-dev/2014-November/137280.html). The attached patch is a slightly reworded version of my blog post here: http://demianbrecht.github.io/vcs/2014/07/31/from-git-to-hg/. ---------- components: Devguide files: gitdevs.patch keywords: patch messages: 232100 nosy: demian.brecht, ezio.melotti priority: normal severity: normal status: open title: Adding a git developer's guide to Mercurial to devguide Added file: http://bugs.python.org/file37355/gitdevs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 02:00:55 2014 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 04 Dec 2014 01:00:55 +0000 Subject: [issue22992] Adding a git developer's guide to Mercurial to devguide In-Reply-To: <1417651753.19.0.905189748743.issue22992@psf.upfronthosting.co.za> Message-ID: <1417654855.14.0.21557160307.issue22992@psf.upfronthosting.co.za> Ezio Melotti added the comment: I have a few comments about the patch. About the markup: 1) you can specify the default highlight (bash) once at the top of the file, and just use :: afterwards instead of .. code-block::; 2) the ```` used for some headers is inconsistent with the other files; 3) when you use NamedBranches, do you want to create a link? if so you should use :ref:`NamedBranches` and add a reference; About the content: 1) you should make clear that bookmarks are local and they won't be included in the patch and/or affect the main repo; 2) we usually want a single diff for each issue -- you should show how to create a diff that includes all the changes related to issueA or issueB (this can be done easily with named branches, not sure about bookmarks); 3) hg ci --amend could be used to update existing changesets after a review (this will also solve the above problem); 4) it should be possible to use evolve instead of bookmarks, but evolve is currently still a work in progress, so I'm not sure is worth mentioning it yet; 5) you said that named branches, bookmarks, and queues are all branches types in Mercurial. Can you add a source for that? (I never heard of bookmarks and queues as branches, but they might be, and there are also non-named branches. I just want to make sure that the terms are used correctly.); 6) when you mention :code:`hg log -G`, you should probably mention -L10 too, otherwise on the CPython repo the command will result in a graph with 90k+ changesets; 7) "Note that Mercurial doesn't have git's concept of staging, so all changes will be committed." <- To avoid committing there are different ways: a) leave the code uncommitted in the working copy (works with one or two unrelated issues, but doesn't scale well); b) save changes on a .diff and apply it when needed (what I usually do, scales well but it has a bit of overhead since you need to update/apply the diff); c) use mq; d) use evolve. Mercurial also has the concept of phases (http://mercurial.selenic.com/wiki/Phases) that might be somewhat related, even though it affected committed changes (if you set a cs as secret it won't be pushed); 8) Trying to learn usual hg workflows might also be easier than trying to use a git-like workflow on mercurial, so you could suggest considering them too (I don't remember if we have anything about it in the devguide though). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 02:34:29 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 04 Dec 2014 01:34:29 +0000 Subject: [issue22991] test_gdb leaves the terminal in raw mode with gdb 7.8.1 In-Reply-To: <1417650633.0.0.0644519046784.issue22991@psf.upfronthosting.co.za> Message-ID: <1417656869.02.0.227391331973.issue22991@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +dmalcolm _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 02:52:05 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 04 Dec 2014 01:52:05 +0000 Subject: [issue20692] Tutorial and FAQ: how to call a method on an int In-Reply-To: <1392850224.09.0.571764135364.issue20692@psf.upfronthosting.co.za> Message-ID: <1417657925.78.0.611353991654.issue20692@psf.upfronthosting.co.za> Changes by Josh Rosenberg : ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 04:56:25 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 04 Dec 2014 03:56:25 +0000 Subject: [issue22992] Adding a git developer's guide to Mercurial to devguide In-Reply-To: <1417651753.19.0.905189748743.issue22992@psf.upfronthosting.co.za> Message-ID: <1417665385.22.0.423071821516.issue22992@psf.upfronthosting.co.za> Berker Peksag added the comment: +The workflow of a developer might look something like this: "a core developer" or "a contributor"? It would be good to split core developer and contributor workflows. + # address review comments and merge + git checkout master + git merge issueA + git branch -d issueA For example, from the contributor side, you shouldn't touch the master branch at all. It should be: # address review comments git commit -a # check upstream and rebase git pull --rebase upstream master # or "origin master" in this example # push changes (optional) git push origin issueA # origin should be contributor's fork here ---------- nosy: +berker.peksag stage: -> patch review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 06:04:05 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Thu, 04 Dec 2014 05:04:05 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1417669445.8.0.293512101474.issue17852@psf.upfronthosting.co.za> Changes by Nikolaus Rath : ---------- nosy: +nikratio _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 06:09:52 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Thu, 04 Dec 2014 05:09:52 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1417669792.64.0.700844496244.issue17852@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Serhiy, I believe this still happens in Python 3.4, but it is harder to reproduce. I couldn't get Armin's script to produce the problem either, but I'm pretty sure that this is what causes e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771452#60. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 06:31:25 2014 From: report at bugs.python.org (Greg Turner) Date: Thu, 04 Dec 2014 05:31:25 +0000 Subject: [issue22968] Lib/types.py nit: isinstance != PyType_IsSubtype In-Reply-To: <1417293514.02.0.452977288528.issue22968@psf.upfronthosting.co.za> Message-ID: <1417671085.25.0.580664885179.issue22968@psf.upfronthosting.co.za> Greg Turner added the comment: Fixed a trivial typo in test_virtual_metaclass_in_types_module.patch ---------- versions: +Python 3.5 Added file: http://bugs.python.org/file37356/test_virtual_metaclasses_in_types_module_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 06:56:10 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 04 Dec 2014 05:56:10 +0000 Subject: [issue16893] Generate Idle help from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <20141204055607.95980.11946@psf.io> Roundup Robot added the comment: New changeset 6db65ff985b6 by Terry Jan Reedy in branch '3.4': Issue #16893: For Idle doc, move index entries, copy no-subprocess section https://hg.python.org/cpython/rev/6db65ff985b6 New changeset feec1ea55127 by Terry Jan Reedy in branch '2.7': Issue #16893: Update 2.7 version of Idle doc to match 3.4 doc as of the just https://hg.python.org/cpython/rev/feec1ea55127 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 07:26:58 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 04 Dec 2014 06:26:58 +0000 Subject: [issue3068] IDLE - Add an extension configuration dialog In-Reply-To: <1213035033.21.0.781726477097.issue3068@psf.upfronthosting.co.za> Message-ID: <20141204062655.95986.88518@psf.io> Roundup Robot added the comment: New changeset 395673aac686 by Terry Jan Reedy in branch '2.7': Issue #3068: Document the new Configure Extensions dialog and menu entry. https://hg.python.org/cpython/rev/395673aac686 New changeset b099cc290ae9 by Terry Jan Reedy in branch '3.4': Issue #3068: Document the new Configure Extensions dialog and menu entry. https://hg.python.org/cpython/rev/b099cc290ae9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 07:27:53 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 04 Dec 2014 06:27:53 +0000 Subject: [issue3068] IDLE - Add an extension configuration dialog In-Reply-To: <1213035033.21.0.781726477097.issue3068@psf.upfronthosting.co.za> Message-ID: <1417674473.31.0.994571071.issue3068@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 07:34:34 2014 From: report at bugs.python.org (Connor Wolf) Date: Thu, 04 Dec 2014 06:34:34 +0000 Subject: [issue22993] Plistlib fails on certain valid plist values Message-ID: <1417674874.83.0.611673896272.issue22993@psf.upfronthosting.co.za> New submission from Connor Wolf: I'm using plistlib to process plist files produced by an iphone app. Somehow, the application is generating plist files with a absolute date value along the lines of `0000-12-30T00:00:00Z`. This is a valid date, and the apple plist libraries can handle this without issue. However, it causes a ValueError if you load a plist containing it. Minimal example: python file: ``` import plistlib test = plistlib.readPlist('./test.plist') ``` plist file: ``` Test 0000-12-30T00:00:00Z ``` This fails on both python3 and python2, with the exact same error: ``` herp at mainnas:/media/Storage/Scripts/pFail$ python3 test.py Traceback (most recent call last): File "test.py", line 3, in test = plistlib.readPlist('./test.plist') File "/usr/lib/python3.4/plistlib.py", line 164, in readPlist dict_type=_InternalDict) File "/usr/lib/python3.4/plistlib.py", line 995, in load return p.parse(fp) File "/usr/lib/python3.4/plistlib.py", line 325, in parse self.parser.ParseFile(fileobj) File "/usr/lib/python3.4/plistlib.py", line 337, in handle_end_element handler() File "/usr/lib/python3.4/plistlib.py", line 413, in end_date self.add_object(_date_from_string(self.get_data())) File "/usr/lib/python3.4/plistlib.py", line 291, in _date_from_string return datetime.datetime(*lst) ValueError: year is out of range herp at mainnas:/media/Storage/Scripts/pFail$ python test.py Traceback (most recent call last): File "test.py", line 3, in test = plistlib.readPlist('./test.plist') File "/usr/lib/python2.7/plistlib.py", line 78, in readPlist rootObject = p.parse(pathOrFile) File "/usr/lib/python2.7/plistlib.py", line 406, in parse parser.ParseFile(fileobj) File "/usr/lib/python2.7/plistlib.py", line 418, in handleEndElement handler() File "/usr/lib/python2.7/plistlib.py", line 474, in end_date self.addObject(_dateFromString(self.getData())) File "/usr/lib/python2.7/plistlib.py", line 198, in _dateFromString return datetime.datetime(*lst) ValueError: year is out of range herp at mainnas:/media/Storage/Scripts/pFail$ ``` ---------- components: Library (Lib) messages: 232107 nosy: Connor.Wolf priority: normal severity: normal status: open title: Plistlib fails on certain valid plist values type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 07:36:17 2014 From: report at bugs.python.org (Connor Wolf) Date: Thu, 04 Dec 2014 06:36:17 +0000 Subject: [issue22993] Plistlib fails on certain valid plist values In-Reply-To: <1417674874.83.0.611673896272.issue22993@psf.upfronthosting.co.za> Message-ID: <1417674977.46.0.776248433718.issue22993@psf.upfronthosting.co.za> Connor Wolf added the comment: Aaaand there is no markup processing. How do I edit my report? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 08:27:05 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 04 Dec 2014 07:27:05 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1417669792.64.0.700844496244.issue17852@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Serhiy, I believe this still happens in Python 3.4, but it is harder to reproduce. I couldn't get Armin's script to produce the problem either, but I'm pretty sure that this is what causes e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771452#60. Maybe, as it's been said several times, it's an application bug: files should be closed explicitly (or better with a context manager of course). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 08:54:05 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 04 Dec 2014 07:54:05 +0000 Subject: [issue22993] Plistlib fails on certain valid plist values In-Reply-To: <1417674874.83.0.611673896272.issue22993@psf.upfronthosting.co.za> Message-ID: <1417679645.33.0.574570072601.issue22993@psf.upfronthosting.co.za> Ned Deily added the comment: (Currently, it is not possible to edit a particular message in an issue. You could add a replacement comment to the issue and ask that the older message be delete.) This seems to be a problem date. As documented, plistlib converts plist dates to/from Python datetime.datetime objects. And, as is documented from datetime objects, the year field must be between 1 (MINYEAR) and 9999 (MAXYEAR). So, it would appear that dates with year 0 are not representable as datetime objects; it's not obvious to me how plistlib could handle a date like that without changing the API, i.e. returning something other than a datetime object or by changing the rules for datetime objects, which is very unlikely to happen. https://docs.python.org/dev/library/plistlib.html https://docs.python.org/dev/library/datetime.html#datetime.MINYEAR ---------- nosy: +belopolsky, ned.deily, ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 09:10:25 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 04 Dec 2014 08:10:25 +0000 Subject: [issue14134] xmlrpc.client.ServerProxy needs timeout parameter In-Reply-To: <1330294741.21.0.00592117933576.issue14134@psf.upfronthosting.co.za> Message-ID: <1417680625.48.0.82798198145.issue14134@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 09:24:47 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 04 Dec 2014 08:24:47 +0000 Subject: [issue16837] Number ABC can be instantiated In-Reply-To: <1357082763.61.0.378054227113.issue16837@psf.upfronthosting.co.za> Message-ID: <1417681487.43.0.0580115516551.issue16837@psf.upfronthosting.co.za> Berker Peksag added the comment: I left a couple of comments on Rietveld. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 09:43:40 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 04 Dec 2014 08:43:40 +0000 Subject: [issue22993] Plistlib fails on certain valid plist values In-Reply-To: <1417674874.83.0.611673896272.issue22993@psf.upfronthosting.co.za> Message-ID: <1417682620.45.0.127707715277.issue22993@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Another limitation is that on 32-bit platform it is impossible to load date before datetime.datetime(1901, 12, 13, 20, 45, 52) from binary plist. >>> plistlib.loads(b'bplist003'+struct.pack('>d', -2**31 - (31 * 365 + 8) * 86400)+b'\x08\x00\x00\x00\x00\x00\x00\x01\x01\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x11') datetime.datetime(1901, 12, 13, 20, 45, 52) >>> plistlib.loads(b'bplist003'+struct.pack('>d', -2**31 - (31 * 365 + 8) * 86400 - 1)+b'\x08\x00\x00\x00\x00\x00\x00\x01\x01\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x11') Traceback (most recent call last): File "", line 1, in File "/home/serhiy/py/cpython/Lib/plistlib.py", line 1006, in loads fp, fmt=fmt, use_builtin_types=use_builtin_types, dict_type=dict_type) File "/home/serhiy/py/cpython/Lib/plistlib.py", line 997, in load return p.parse(fp) File "/home/serhiy/py/cpython/Lib/plistlib.py", line 623, in parse return self._read_object(self._object_offsets[top_object]) File "/home/serhiy/py/cpython/Lib/plistlib.py", line 688, in _read_object return datetime.datetime.utcfromtimestamp(f + (31 * 365 + 8) * 86400) OverflowError: timestamp out of range for platform time_t Can second example be loaded by Apple tools on 32-bit? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 10:57:57 2014 From: report at bugs.python.org (Armin Rigo) Date: Thu, 04 Dec 2014 09:57:57 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1417687077.51.0.906127139455.issue17852@psf.upfronthosting.co.za> Armin Rigo added the comment: I hate to repeat myself, but if the C standard says "files are flushed at exit"; if Python 2 follows this standard; and if Python 3 follows it most of the time but *not always*... then it seems to me that something is very, very buggy in the worst possible way (rare data loss). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 11:14:03 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 04 Dec 2014 10:14:03 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1417688043.28.0.199068727169.issue17852@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Do you have working in 3.4+ example? ---------- stage: -> test needed versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 11:18:28 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 04 Dec 2014 10:18:28 +0000 Subject: [issue22993] Plistlib fails on certain valid plist values In-Reply-To: <1417674874.83.0.611673896272.issue22993@psf.upfronthosting.co.za> Message-ID: <1417688308.6.0.600961722328.issue22993@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Related issue is issue10733. Not all plists produced by Apple's tools can be proceeded by plistlib. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 11:24:42 2014 From: report at bugs.python.org (Armin Rigo) Date: Thu, 04 Dec 2014 10:24:42 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1417688682.2.0.0328311025386.issue17852@psf.upfronthosting.co.za> Armin Rigo added the comment: If I understood correctly, Python 3.4 tries harder to find cycles and call destructors at the end of the program, but that's not a full guarantee. For example you can have a reference from a random C extension module. While trying to come up with an example, I found one that I don't fully understand, but the point is that it shows how easy it is to defeats it: import sys f = open('foo.txt', 'w') f.write('abc') def func(*args): return func sys.settrace(func) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 11:26:52 2014 From: report at bugs.python.org (Armin Rigo) Date: Thu, 04 Dec 2014 10:26:52 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1417688812.77.0.25586771728.issue17852@psf.upfronthosting.co.za> Armin Rigo added the comment: (Ah, it's probably a reference from the trace function -> func_globals -> f). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 11:27:46 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 04 Dec 2014 10:27:46 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1417688866.37.0.722287653668.issue17852@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is an example. ---------- stage: test needed -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 11:28:05 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 04 Dec 2014 10:28:05 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1417688885.75.0.193369918531.issue17852@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Added file: http://bugs.python.org/file37357/gcio.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 11:30:01 2014 From: report at bugs.python.org (santhosh) Date: Thu, 04 Dec 2014 10:30:01 +0000 Subject: [issue22994] datetime buggy Message-ID: <1417689001.58.0.198336603717.issue22994@psf.upfronthosting.co.za> New submission from santhosh: val=datetime.datetime.strptime("2015-02-01",'%Y-%m-%d').date() zon=pytz.timezone('US/Pacific') dt=datetime.datetime(val.year,val.month,val.day, tzinfo=zon) print dt,zon output: 2015-02-01 00:00:00-07:53 US/Pacific output should be 2015-02-01 00:00:00-08:00 US/Pacific ---------- messages: 232119 nosy: santhoshch priority: normal severity: normal status: open title: datetime buggy type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 11:30:59 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 04 Dec 2014 10:30:59 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1417689059.79.0.820182655649.issue17852@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Note the example I posted doesn't involve the shutdown sequence. It calls gc.collect() explicitly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 11:39:39 2014 From: report at bugs.python.org (Armin Rigo) Date: Thu, 04 Dec 2014 10:39:39 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1417689579.01.0.632590463772.issue17852@psf.upfronthosting.co.za> Armin Rigo added the comment: To add to the confusion: Antoine's example produces an empty file on the current trunk cd282dd0cfe8. When I first tried it on a slightly older trunk (157 changesets ago), it correctly emitted a file with "barXXX ", but only if "gc.collect()" was present. Without "gc.collect()" it didn't. This seems at odds with the explanation that "gc.collect()" should be what occurs at shut-down now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 11:46:20 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 04 Dec 2014 10:46:20 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1417689980.82.0.0243195945479.issue17852@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The problem is that the order of tp_finalize calls is arbitrary when there is a reference cycle (same thing, of course, with tp_clear). So depending on the exact layout of the garbage list, the TextIOWrapper could be collected before the BufferedWriter and the FileIO (good), or after (bad). I don't see an easy way to solve this. Either _io should provide hints to the GC (which kind of hints?), or the tp_finalize should be customized to somehow call a dependent wrapper's tp_finalize (how? by keeping a weakref?). ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 11:49:56 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 04 Dec 2014 10:49:56 +0000 Subject: [issue22994] datetime buggy In-Reply-To: <1417689001.58.0.198336603717.issue22994@psf.upfronthosting.co.za> Message-ID: <1417690196.83.0.597022914234.issue22994@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 11:50:24 2014 From: report at bugs.python.org (Armin Rigo) Date: Thu, 04 Dec 2014 10:50:24 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1417690224.86.0.610074228959.issue17852@psf.upfronthosting.co.za> Armin Rigo added the comment: Maybe accepting the fact that relying on finalizers is a bad idea here? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 11:51:28 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 04 Dec 2014 10:51:28 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1417690288.3.0.246828862247.issue17852@psf.upfronthosting.co.za> Antoine Pitrou added the comment: You mean encourage people to explicitly use "with" or call close()? Yes, that's the simplest answer. It's why we added ResourceWarning. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 11:59:10 2014 From: report at bugs.python.org (Simeon Visser) Date: Thu, 04 Dec 2014 10:59:10 +0000 Subject: [issue22994] datetime buggy In-Reply-To: <1417689001.58.0.198336603717.issue22994@psf.upfronthosting.co.za> Message-ID: <1417690750.65.0.96713430891.issue22994@psf.upfronthosting.co.za> Simeon Visser added the comment: Datetimes in local timezones should be created using localize(): >>> zon.localize(datetime.datetime(2015, 2, 1)).isoformat() '2015-02-01T00:00:00-08:00' See the two supported methods of creating local datetimes at: http://pytz.sourceforge.net ---------- nosy: +simeon.visser _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 12:05:04 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Dec 2014 11:05:04 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1417691104.88.0.480478290737.issue17852@psf.upfronthosting.co.za> STINNER Victor added the comment: > The problem is that the order of tp_finalize calls is arbitrary when there is a reference cycle If we want to guaranty that all files are properly flushed at exit, the best option is to maintain a list of open files. I'm not interested to implement that, it sounds too complex. For example, open("text.txt", "w") creates 3 objects: FileIO, BufferedWriter, TextIOWrapper. You have to register these 3 objects and flush them in the right order. Python is dynamic, you are free to modify objects, for example using the detach() method or by modifying the buffer attribute of the TextIOWrapper. How do you decide which object should be flushed? In which order? We have to take care of signals, threads and forks, stay portable, etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 12:06:59 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 04 Dec 2014 11:06:59 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1417691104.88.0.480478290737.issue17852@psf.upfronthosting.co.za> Message-ID: <54804051.20807@free.fr> Antoine Pitrou added the comment: Le 04/12/2014 12:05, STINNER Victor a ?crit : > >> The problem is that the order of tp_finalize calls is arbitrary >> when there is a reference cycle > > If we want to guaranty that all files are properly flushed at exit, the best option is to maintain a list of open files. I am not talking about files flushing at exit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 12:25:20 2014 From: report at bugs.python.org (santhosh) Date: Thu, 04 Dec 2014 11:25:20 +0000 Subject: [issue22994] datetime buggy In-Reply-To: <1417689001.58.0.198336603717.issue22994@psf.upfronthosting.co.za> Message-ID: <1417692320.21.0.195219915756.issue22994@psf.upfronthosting.co.za> santhosh added the comment: i dont need local timezone i need other timezones like: (US/Pacific) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 12:27:38 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 04 Dec 2014 11:27:38 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1417691104.88.0.480478290737.issue17852@psf.upfronthosting.co.za> Message-ID: <2197037.qk2eIBcB8b@raxxla> Serhiy Storchaka added the comment: > How do you decide which object should be flushed? In which order? We have to > take care of signals, threads and forks, stay portable, etc. The order doesn't matter. If you call flush() of TextIOWrapper, flushes of buffered writer and raw file will be called automatically. And flush() can be called multiple times. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 12:49:56 2014 From: report at bugs.python.org (santhosh) Date: Thu, 04 Dec 2014 11:49:56 +0000 Subject: [issue22994] datetime buggy In-Reply-To: <1417689001.58.0.198336603717.issue22994@psf.upfronthosting.co.za> Message-ID: <1417693796.17.0.486801065189.issue22994@psf.upfronthosting.co.za> santhosh added the comment: zon=pytz.timezone('America/New_York') dt=datetime.datetime(2014,02,01, tzinfo=zon) print dt,zon => 2015-02-01 00:00:00-04:56 America/New_York zon=pytz.timezone('Asia/Kolkata') dt=datetime.datetime(2014,02,01, tzinfo=zon) print dt,zon =>2015-02-01 00:00:00+05:53 Asia/Kolkata all most for all timezones it is giving erroronous outputs we are dealing many timezones ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 13:53:14 2014 From: report at bugs.python.org (Armin Rigo) Date: Thu, 04 Dec 2014 12:53:14 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1417697594.93.0.502203896089.issue17852@psf.upfronthosting.co.za> Armin Rigo added the comment: Antoine: sorry if I wasn't clear enough. Obviously you want to encourage people to close their files, but I think personally that it is very bad for the implementation to *most of the time* work anyway and only rarely fail to flush the files. So, speaking only about the implementation, it is (imho) a bad idea to rely on finalizers to flush the files, and something else should be done. Victor: it does not sound complicated to me to keep the BufferedWriter objects in a doubly-chained list. You're overthinking the issue: there are no multithread issue (we have a GIL) and you don't have to keep track of all 3 objects created by "open". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 13:54:18 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 04 Dec 2014 12:54:18 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1417697594.93.0.502203896089.issue17852@psf.upfronthosting.co.za> Message-ID: <54805978.8080703@free.fr> Antoine Pitrou added the comment: Le 04/12/2014 13:53, Armin Rigo a ?crit : > > So, speaking only about the implementation, it is (imho) a bad idea to rely on finalizers to flush the files, and something else should be done. But what else? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 14:08:17 2014 From: report at bugs.python.org (Armin Rigo) Date: Thu, 04 Dec 2014 13:08:17 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1417698497.06.0.644926394657.issue17852@psf.upfronthosting.co.za> Armin Rigo added the comment: Antoine: I'm trying to explain what in the three lines that follow the parts you quoted. I already tried to explain it a few times above. Now I feel that I'm not going anywhere, so I'll quote back myself from 2013-04-27: "Feel free to close anyway as not-a-bug; I won't fight the Python 3 behavior, because Python 2 works as expected." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 14:10:29 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 04 Dec 2014 13:10:29 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1417698629.16.0.54551573602.issue17852@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Armin: I don't see how linked lists would help. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 14:16:43 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 04 Dec 2014 13:16:43 +0000 Subject: [issue22995] Restrict default picleability Message-ID: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: When no efforts were spent to support pickling of instances of Python class, in most cases the class will be pickleable. Default implementation just saves all attributes and this works if all attributes are pickleable. Exceptional special cases: 1) Classes with __slot__. In this case an attempt to pickle will raise an exception with explaining message. 2) Classes with __new__ wish mandatory parameters. In this case the pickling will be silently "successful", but actually data will be not saved and unpickling will fail. See for example issue21975, issue22955. But when the class is implemented in C and doesn't expose its attribute in __dict__, in most cases it is variant (2) -- silent incorrect pickling. I think we should prevent incorrect pickling by default. It is better to fail loudly. Default reduce could inspect the __new__ method and raise an exception if it has non-optional parameters and the class doesn't implement __getnewargs_ex__ or __getnewargs__ methods. And fail on all classes implemented in C if they don't implement any pickle-related methods. ---------- messages: 232135 nosy: alexandre.vassalotti, pitrou, serhiy.storchaka priority: normal severity: normal status: open title: Restrict default picleability _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 14:35:41 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 04 Dec 2014 13:35:41 +0000 Subject: [issue22994] datetime buggy In-Reply-To: <1417689001.58.0.198336603717.issue22994@psf.upfronthosting.co.za> Message-ID: <1417700141.06.0.542842288339.issue22994@psf.upfronthosting.co.za> R. David Murray added the comment: pytz is not a part of the python standard library, it is a 3rd party product. Please reread Simeon's message (he's talking about any timezone), and if you have further questions ask on whatever support forum pytz has, or on the python-list mailing list. ---------- nosy: +r.david.murray resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 14:39:37 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 04 Dec 2014 13:39:37 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1417698629.16.0.54551573602.issue17852@psf.upfronthosting.co.za> Message-ID: <1624549.WHV8HQtcLC@raxxla> Serhiy Storchaka added the comment: How it looks to me. Should be global collection of weak references (WeakSet?). Every instance of TextIOWrapper, BufferedWriter and BufferedRandom add itself to this collection on create and remove on close. A function registered with atexit calls flush() for all methods in the collection. This solution doesn't require changes to finalization machinery, only to the io module. I'm not particularly interested to implement that because I'm not convinced that Python should provide such guaranties. But the implementation shouldn't be too complex. More general solution could be to introduce special method (__predel__) which should be called before breaking reference loops (or just before __del__ if there is no loop). In case of output streams it will call flush() (but not close()!). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 14:43:25 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 04 Dec 2014 13:43:25 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1417700605.15.0.618824111305.issue22995@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- title: Restrict default picleability -> Restrict default pickleability _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 14:50:26 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 04 Dec 2014 13:50:26 +0000 Subject: [issue22996] Order of _io objects finalization can lose data in reference cycles Message-ID: <1417701026.92.0.498236598098.issue22996@psf.upfronthosting.co.za> New submission from Antoine Pitrou: Spun off from issue #17852, which sticks to interpreter shutdown issue. There is a more general issue when e.g. a BufferedWriter can be finalized (tp_finalize) before the TextIOWrapper wrapping it if they belong to a reference chain, losing unflushed data. Reproducer attached. ---------- components: IO files: gcio.py messages: 232138 nosy: pitrou priority: normal severity: normal status: open title: Order of _io objects finalization can lose data in reference cycles versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37358/gcio.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 14:50:35 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 04 Dec 2014 13:50:35 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1417701035.8.0.401928733518.issue17852@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: -pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 14:58:29 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 04 Dec 2014 13:58:29 +0000 Subject: [issue22996] Order of _io objects finalization can lose data in reference cycles In-Reply-To: <1417701026.92.0.498236598098.issue22996@psf.upfronthosting.co.za> Message-ID: <1417701509.24.0.548042524891.issue22996@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 15:06:01 2014 From: report at bugs.python.org (Armin Rigo) Date: Thu, 04 Dec 2014 14:06:01 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1417701961.13.0.682195403613.issue17852@psf.upfronthosting.co.za> Armin Rigo added the comment: Here is a proof-of-concept. It changes both _pyio.py and bufferedio.c and was tested with the examples here. (See what I meant with "linked lists".) The change in textio.c is still missing, but should be very similar to bufferedio.c. This is similar to the implementation in PyPy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 15:06:13 2014 From: report at bugs.python.org (Armin Rigo) Date: Thu, 04 Dec 2014 14:06:13 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1417701973.64.0.0281721257603.issue17852@psf.upfronthosting.co.za> Changes by Armin Rigo : ---------- keywords: +patch Added file: http://bugs.python.org/file37359/pyio.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 15:10:56 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 04 Dec 2014 14:10:56 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1417702256.88.0.553031780716.issue22995@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 16:32:29 2014 From: report at bugs.python.org (Brett Cannon) Date: Thu, 04 Dec 2014 15:32:29 +0000 Subject: [issue22992] Adding a git developer's guide to Mercurial to devguide In-Reply-To: <1417651753.19.0.905189748743.issue22992@psf.upfronthosting.co.za> Message-ID: <1417707149.79.0.355378758895.issue22992@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 16:41:13 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Dec 2014 15:41:13 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1417701973.66.0.486200538948.issue17852@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: By the way, I fixed various issues to ensure that ResourceWarning are displayed at Python exit. There are still corner cases when the warnings are not emited. For example, when a daemon thread is used. Or when the warning comes very late during Python finalization. Recent example of tricky issue related to this warning: #22898. IMO it's a bug, it must be fixed and it should be possible to emit the warning. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 17:06:06 2014 From: report at bugs.python.org (Demian Brecht) Date: Thu, 04 Dec 2014 16:06:06 +0000 Subject: [issue22992] Adding a git developer's guide to Mercurial to devguide In-Reply-To: <1417651753.19.0.905189748743.issue22992@psf.upfronthosting.co.za> Message-ID: <1417709166.39.0.825851403119.issue22992@psf.upfronthosting.co.za> Demian Brecht added the comment: Thanks for the comments, will try to have an updated patch today. > Trying to learn usual hg workflows might also be easier than trying to use a git-like workflow on mercurial, so you could suggest considering them too (I don't remember if we have anything about it in the devguide though). (For other as we briefly chatted about this over IM:) The intention of this guide was to minimize the cognitive load of context switching between git and mercurial projects for git developers just beginning to use mercurial. As their experience with mercurial increases, their workflow may change to be more of an "out of the box" type flow. Git developers (myself included) will likely spend a good deal of time trying to figure out "how to do X as I would in git using Mercurial". This is simply to try and lower the initial cost of development for new contributors. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 18:10:19 2014 From: report at bugs.python.org (Simeon Visser) Date: Thu, 04 Dec 2014 17:10:19 +0000 Subject: [issue22997] Minor improvements to "Functional API" section of Enum documentation Message-ID: <1417713019.92.0.36560038902.issue22997@psf.upfronthosting.co.za> New submission from Simeon Visser: This patch contributes two changes to the "Functional API" section of the Enum documentation: - Early in the section it mentions four different ways of creating an Enum but later it only lists three different ways (the "sequence of names" approach wasn't listed anymore). - The use of "Animal" and "Animals" wasn't consistent. This issue is mainly to test my ability to make a (trivial) patch. ---------- assignee: docs at python components: Documentation messages: 232142 nosy: docs at python, simeon.visser priority: normal severity: normal status: open title: Minor improvements to "Functional API" section of Enum documentation type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 18:11:27 2014 From: report at bugs.python.org (Simeon Visser) Date: Thu, 04 Dec 2014 17:11:27 +0000 Subject: [issue22997] Minor improvements to "Functional API" section of Enum documentation In-Reply-To: <1417713019.92.0.36560038902.issue22997@psf.upfronthosting.co.za> Message-ID: <1417713087.88.0.492646727457.issue22997@psf.upfronthosting.co.za> Changes by Simeon Visser : ---------- keywords: +patch Added file: http://bugs.python.org/file37360/issue22997.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 18:14:20 2014 From: report at bugs.python.org (Ethan Furman) Date: Thu, 04 Dec 2014 17:14:20 +0000 Subject: [issue22997] Minor improvements to "Functional API" section of Enum documentation In-Reply-To: <1417713019.92.0.36560038902.issue22997@psf.upfronthosting.co.za> Message-ID: <1417713260.13.0.870233947522.issue22997@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 18:20:48 2014 From: report at bugs.python.org (Ethan Furman) Date: Thu, 04 Dec 2014 17:20:48 +0000 Subject: [issue22997] Minor improvements to "Functional API" section of Enum documentation In-Reply-To: <1417713019.92.0.36560038902.issue22997@psf.upfronthosting.co.za> Message-ID: <1417713648.31.0.420918754101.issue22997@psf.upfronthosting.co.za> Ethan Furman added the comment: Simeon, the patch looks decent; I'll review it more carefully later. If you are going to contribute non-trivial patches, you'll need to sign the CLA: https://www.python.org/psf/contrib/contrib-form/ . Thanks for helping! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 18:26:17 2014 From: report at bugs.python.org (Kali Kaneko) Date: Thu, 04 Dec 2014 17:26:17 +0000 Subject: [issue22987] ssl module documentation: incorrect compatibility matrix In-Reply-To: <1417612558.33.0.597958584531.issue22987@psf.upfronthosting.co.za> Message-ID: <1417713977.76.0.909690881711.issue22987@psf.upfronthosting.co.za> Kali Kaneko added the comment: my bad, I had not actually tested the sslv2 and sslv3 options, since they were not available in the python in debian sid. thanks for the quick fix! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 18:58:38 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 04 Dec 2014 17:58:38 +0000 Subject: [issue21114] wsgiref.simple_server doesn't handle multi-line headers correctly In-Reply-To: <1396285351.75.0.166007035179.issue21114@psf.upfronthosting.co.za> Message-ID: <1417715918.53.0.250839259212.issue21114@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Tom. This was made in issue4718. But tests are passed without them. So 3.x needs tests too. ---------- assignee: serhiy.storchaka -> nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 19:23:49 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Thu, 04 Dec 2014 18:23:49 +0000 Subject: [issue17852] Built-in module _io can loose data from buffered files at exit In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za> Message-ID: <1417717429.37.0.398187494335.issue17852@psf.upfronthosting.co.za> Nikolaus Rath added the comment: This will probably be too radial, but I think it should at least be mentioned as a possible option. We could just not attempt to implicitly flush buffers in the finalizer at all. This means scripts relying on this will break, but in contrast to the current behavior they will break consistently so it's easy to find and fix the problem. I think this is still preferable to any solution that does not guarantee flushing in 100% of the cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 19:50:27 2014 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 04 Dec 2014 18:50:27 +0000 Subject: [issue22991] test_gdb leaves the terminal in raw mode with gdb 7.8.1 In-Reply-To: <1417650633.0.0.0644519046784.issue22991@psf.upfronthosting.co.za> Message-ID: <1417719027.21.0.966555464645.issue22991@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The previous patch failed many tests, sorry. The attached patch runs successfully test_gdb using gdb/mi. All the changes that were made in the test cases themselves, remove either a terminating new line or terminating white spaces in the assertion check. ---------- Added file: http://bugs.python.org/file37361/gdbmi_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 20:38:59 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 04 Dec 2014 19:38:59 +0000 Subject: [issue22994] datetime buggy In-Reply-To: <1417689001.58.0.198336603717.issue22994@psf.upfronthosting.co.za> Message-ID: <1417721939.09.0.317061836732.issue22994@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: santhosh, I would be interested to know how this gets resolved. I find it strange that zon gets fractional UTC offset: >>> zon If you ask on a pytz-related forum, please post a link here. Some other cases: >>> pytz.timezone('US/Eastern') >>> pytz.timezone('US/Central') >>> pytz.timezone('Asia/Kolkata') but >>> pytz.timezone('Europe/Paris') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 20:44:44 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 04 Dec 2014 19:44:44 +0000 Subject: [issue22994] datetime buggy In-Reply-To: <1417689001.58.0.198336603717.issue22994@psf.upfronthosting.co.za> Message-ID: <1417722284.98.0.337252778464.issue22994@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: It looks like pytz documentation [1] specifically warns about this kind of usage: """ Unfortunately using the tzinfo argument of the standard datetime constructors ??does not work?? with pytz for many timezones. """ [1] http://pytz.sourceforge.net/#localized-times-and-date-arithmetic ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 21:05:19 2014 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Thu, 04 Dec 2014 20:05:19 +0000 Subject: [issue19834] Unpickling exceptions pickled by Python 2 In-Reply-To: <1385740154.87.0.494742260047.issue19834@psf.upfronthosting.co.za> Message-ID: <1417723519.57.0.40219596019.issue19834@psf.upfronthosting.co.za> Changes by Walter D?rwald : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 21:14:01 2014 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Thu, 04 Dec 2014 20:14:01 +0000 Subject: [issue22998] inspect.Signature and default arguments Message-ID: <1417724041.66.0.201313804397.issue22998@psf.upfronthosting.co.za> New submission from Walter D?rwald: inspect.Signature.bind() doesn't add values for parameters that are unspecified but have a default value. The documentation at https://docs.python.org/3/library/inspect.html#inspect.BoundArguments.arguments includes an example how to add default values, but that example doesn't work for the * and ** parameters. This patch adds a new method Signature.bind_with_defaults() that works like Signature.bind(), but includes parameters with a default value (and can handle values for the * and ** parameters). ---------- components: Library (Lib) files: signature-bind.diff keywords: patch messages: 232150 nosy: doerwalter priority: normal severity: normal status: open title: inspect.Signature and default arguments type: enhancement Added file: http://bugs.python.org/file37362/signature-bind.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 21:20:38 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 04 Dec 2014 20:20:38 +0000 Subject: [issue22998] inspect.Signature and default arguments In-Reply-To: <1417724041.66.0.201313804397.issue22998@psf.upfronthosting.co.za> Message-ID: <1417724438.1.0.685691088134.issue22998@psf.upfronthosting.co.za> R. David Murray added the comment: Can you give an example of what you say doesn't work? IIRC the reason this method isn't part of the API is because normally it isn't needed (the defaults are filled in when you do the actual call). What is your use case for needing the defaults to be pre-bound? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 21:43:18 2014 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Thu, 04 Dec 2014 20:43:18 +0000 Subject: [issue22998] inspect.Signature and default arguments In-Reply-To: <1417724041.66.0.201313804397.issue22998@psf.upfronthosting.co.za> Message-ID: <1417725798.9.0.977944328507.issue22998@psf.upfronthosting.co.za> Walter D?rwald added the comment: The following doesn't work:: import inspect def foo(*args, **kwargs): return (args, kwargs) # Code from https://docs.python.org/3/library/inspect.html#inspect.BoundArguments.arguments to fill in the defaults sig = inspect.signature(foo) ba = sig.bind() for param in sig.parameters.values(): if param.name not in ba.arguments: ba.arguments[param.name] = param.default print(foo(*ba.args, **ba.kwargs)) instead it gives the following traceback:: Traceback (most recent call last): File "sig_test.py", line 16, in print(foo(*ba.args, **ba.kwargs)) File "/Users/walter/.local/lib/python3.4/inspect.py", line 2246, in args args.extend(arg) TypeError: 'type' object is not iterable In my use case there isn't a call to a function implemented in Python. Instead I'm implementing a templating languages that supports defining a signature for a template. Calling the template binds the arguments and inside the template the variables simply are a dictionary. I.e. define the template like this: t = Template("", signature="a, b=23") Then you can call it like this: t(17) and inside the template the variables will be {"a": 17, "b": 23}. The signature argument in the Template constructor will be parsed into an inspect.Signature object and I'd like to use Signature.bind() to get the final variables dictionary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 22:11:09 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Dec 2014 21:11:09 +0000 Subject: [issue22685] memory leak: no transport for pipes by create_subprocess_exec/shell In-Reply-To: <1413894821.03.0.250322427022.issue22685@psf.upfronthosting.co.za> Message-ID: <1417727469.34.0.198341814944.issue22685@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 22:28:34 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 04 Dec 2014 21:28:34 +0000 Subject: [issue22998] inspect.Signature and default arguments In-Reply-To: <1417724041.66.0.201313804397.issue22998@psf.upfronthosting.co.za> Message-ID: <1417728514.66.0.91904080569.issue22998@psf.upfronthosting.co.za> R. David Murray added the comment: This is indeed a bit tricky. Your use case is pretty specialized (it doesn't involve any actual python functions), so I don't think by itself it argues for the inclusion of a _with_defaults method. The example fill-in in the docs fails because args and kwargs don't check for _empty as a possible value for the VAR_POSITIONAL (resp VAR_KEYWORD). So I think either we add that check to args and kwargs, or we add a _with_defaults method because filling in the defaults would no longer be a simple loop (and thus easy to get wrong). Let's see what Yury thinks. ---------- nosy: +yselivanov versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 23:05:21 2014 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 04 Dec 2014 22:05:21 +0000 Subject: [issue22998] inspect.Signature and default arguments In-Reply-To: <1417724041.66.0.201313804397.issue22998@psf.upfronthosting.co.za> Message-ID: <1417730721.24.0.336896845856.issue22998@psf.upfronthosting.co.za> Yury Selivanov added the comment: I think we should just fix the documentation, and update the code in example with a proper check: for param in sig.parameters.values(): if (param.name not in ba.arguments and param.default is not param.empty): ba.arguments[param.name] = param.default I'm -1 on adding '_with_defaults' method, because usually you don't need this (at least in my experience). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 23:09:53 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 04 Dec 2014 22:09:53 +0000 Subject: [issue22922] asyncio: call_soon() should raise an exception if the event loop is closed In-Reply-To: <1416735123.89.0.671272792173.issue22922@psf.upfronthosting.co.za> Message-ID: <20141204220935.21268.5565@psf.io> Roundup Robot added the comment: New changeset 226f870b387d by Victor Stinner in branch '3.4': Closes #22922: More EventLoop methods fail if the loop is closed. Initial patch https://hg.python.org/cpython/rev/226f870b387d ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 23:09:54 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 04 Dec 2014 22:09:54 +0000 Subject: [issue22685] memory leak: no transport for pipes by create_subprocess_exec/shell In-Reply-To: <1413894821.03.0.250322427022.issue22685@psf.upfronthosting.co.za> Message-ID: <20141204220936.21268.18640@psf.io> Roundup Robot added the comment: New changeset 2c18dd99829c by Victor Stinner in branch '3.4': Issue #22685: Fix test_pause_reading() of asyncio test_subprocess https://hg.python.org/cpython/rev/2c18dd99829c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 4 23:12:36 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Dec 2014 22:12:36 +0000 Subject: [issue22922] asyncio: call_soon() should raise an exception if the event loop is closed In-Reply-To: <1416735123.89.0.671272792173.issue22922@psf.upfronthosting.co.za> Message-ID: <1417731155.99.0.383166353916.issue22922@psf.upfronthosting.co.za> STINNER Victor added the comment: I didn't change subprocess_exec() nor subprocess_shell() because they are coroutine. A coroutine object can only raise an exception when they are executed, whereas a closed loop cannot execute a coroutine object. I modified create_task() to fail if the event loop is closed, it should be enough. Thanks Torsten Landschoff for your fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 00:02:53 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Dec 2014 23:02:53 +0000 Subject: [issue22922] asyncio: call_soon() should raise an exception if the event loop is closed In-Reply-To: <1416735123.89.0.671272792173.issue22922@psf.upfronthosting.co.za> Message-ID: <1417734173.92.0.406624926091.issue22922@psf.upfronthosting.co.za> STINNER Victor added the comment: Windows buildbots are not happy: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/5385/steps/test/logs/stdio ====================================================================== ERROR: test_close (test.test_asyncio.test_windows_events.ProactorTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\asyncio\proactor_events.py", line 394, in close self._close_self_pipe() File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\asyncio\proactor_events.py", line 423, in _close_self_pipe self._self_reading_future.cancel() File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\asyncio\windows_events.py", line 70, in cancel return super().cancel() File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\asyncio\futures.py", line 230, in cancel self._schedule_callbacks() File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\asyncio\futures.py", line 245, in _schedule_callbacks self._loop.call_soon(callback, self) File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\asyncio\base_events.py", line 384, in call_soon handle = self._call_soon(callback, args, check_loop=True) File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\asyncio\base_events.py", line 395, in _call_soon self._check_closed() File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\asyncio\base_events.py", line 234, in _check_closed raise RuntimeError('Event loop is closed') RuntimeError: Event loop is closed ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 00:09:28 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 04 Dec 2014 23:09:28 +0000 Subject: [issue20220] TarFile.list() outputs wrong time In-Reply-To: <1389384273.4.0.330615086279.issue20220@psf.upfronthosting.co.za> Message-ID: <1417734568.37.0.268889050177.issue20220@psf.upfronthosting.co.za> STINNER Victor added the comment: The bug still occurs on the System Z buildbot: http://buildbot.python.org/all/builders/System%20Z%20Linux%203.x/builds/2375/steps/test/logs/stdio ====================================================================== FAIL: test_list_command_verbose (test.test_tarfile.CommandLineTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/mnt/9707/edelsohn/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/test/test_tarfile.py", line 1953, in test_list_command_verbose self.assertEqual(out, expected) AssertionError: b'?rw[39 chars]-01-05 18:19:43 ustar/conttype \n?rw-r--r-- ta[6470 chars]f \n' != b'?rw[39 chars]-01-06 00:19:43 ustar/conttype \n?rw-r--r-- ta[6470 chars]f \n' ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 00:12:42 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 04 Dec 2014 23:12:42 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1417734762.08.0.840582006429.issue22995@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Minor note: Python classes with __slots__ pickle and unpickle just fine under protocol 2 and higher. Only protocols 0 and 1 have this problem, and they are no longer used by default on Py3, and not necessary to communicate with Py2, where protocol 2 is supported and generally more efficient. I understand that you're not suggesting any changes to address issue #1, just wanted to mention this. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 00:27:38 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 04 Dec 2014 23:27:38 +0000 Subject: [issue22996] Order of _io objects finalization can lose data in reference cycles In-Reply-To: <1417701026.92.0.498236598098.issue22996@psf.upfronthosting.co.za> Message-ID: <1417735658.55.0.772757218818.issue22996@psf.upfronthosting.co.za> Josh Rosenberg added the comment: What is the proposal? Global registration of file objects that should be flushed before cleanup when they participate in a reference cycle? Adding a special "__predel__" method as suggested in the linked bug? Weak backrefs for file objects that allow a child being destroyed to flush/close its parent (recursively) such that the top of the I/O wrapping chain is always flushed/closed first? Something else? The underlying problem is that people don't use with statements or otherwise explicitly close their objects, and 99.9% of the time, they get away with it in CPython because of the deterministic reference counting for non-cycles and the finalizers. I'm not sure it's worth adding new complexity (to the interpreter or the I/O hierarchy) to address an issue that can be fixed by closing your files properly, which is already recommended practice. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 01:03:04 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 05 Dec 2014 00:03:04 +0000 Subject: [issue22996] Order of _io objects finalization can lose data in reference cycles In-Reply-To: <1417701026.92.0.498236598098.issue22996@psf.upfronthosting.co.za> Message-ID: <1417737784.57.0.445687004391.issue22996@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I was thinking about weak backrefs. It's specialized for the io module but it would be fairly reliable, and not too complicated to implement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 01:27:50 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 05 Dec 2014 00:27:50 +0000 Subject: [issue22922] asyncio: call_soon() should raise an exception if the event loop is closed In-Reply-To: <1416735123.89.0.671272792173.issue22922@psf.upfronthosting.co.za> Message-ID: <20141205002741.73372.55630@psf.io> Roundup Robot added the comment: New changeset 6a955db1f78f by Victor Stinner in branch 'default': Issue #22922: Fix ProactorEventLoop.close() https://hg.python.org/cpython/rev/6a955db1f78f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 01:45:35 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 05 Dec 2014 00:45:35 +0000 Subject: [issue22922] asyncio: call_soon() should raise an exception if the event loop is closed In-Reply-To: <1416735123.89.0.671272792173.issue22922@psf.upfronthosting.co.za> Message-ID: <20141205004531.73394.90387@psf.io> Roundup Robot added the comment: New changeset 0a7d956a2f2d by Victor Stinner in branch '3.4': Issue #22922: Fix ProactorEventLoop.close() https://hg.python.org/cpython/rev/0a7d956a2f2d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 01:45:35 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 05 Dec 2014 00:45:35 +0000 Subject: [issue22429] asyncio: pending call to loop.stop() if a coroutine raises a BaseException In-Reply-To: <1410954714.23.0.464914894828.issue22429@psf.upfronthosting.co.za> Message-ID: <20141205004531.73394.86426@psf.io> Roundup Robot added the comment: New changeset 83bddbfbd3a4 by Victor Stinner in branch '3.4': Closes #22429, asyncio: Fix EventLoop.run_until_complete(), don't stop the https://hg.python.org/cpython/rev/83bddbfbd3a4 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 01:47:01 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Dec 2014 00:47:01 +0000 Subject: [issue22926] asyncio: raise an exception when called from the wrong thread In-Reply-To: <1416760694.74.0.749180510867.issue22926@psf.upfronthosting.co.za> Message-ID: <1417740421.07.0.431101274453.issue22926@psf.upfronthosting.co.za> STINNER Victor added the comment: Guido, Yury: What do you think? Does it sound reasonable to raise an exception if an event loop is used from the wrong thread? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 01:48:38 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Dec 2014 00:48:38 +0000 Subject: [issue22768] Add a way to get the peer certificate of a SSL Transport In-Reply-To: <1414693136.26.0.003644122895.issue22768@psf.upfronthosting.co.za> Message-ID: <1417740518.46.0.748626969412.issue22768@psf.upfronthosting.co.za> STINNER Victor added the comment: > Thanks, that indeed works; I don't know why I missed it while reading the source. Ok, it looks like we can close the issue. > That will be problematic with issue22560. In this case, it should be discussed there. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 01:51:34 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Dec 2014 00:51:34 +0000 Subject: [issue22599] traceback: errors in the linecache module at exit In-Reply-To: <1412940961.34.0.0781587147709.issue22599@psf.upfronthosting.co.za> Message-ID: <1417740694.76.0.164279684124.issue22599@psf.upfronthosting.co.za> STINNER Victor added the comment: Can I apply traceback_at_exit-2.patch? I know that my change on tokenize is not perfect, but it doesn't look like an hack, and it adds a new unit test. The linecache module can be enhanced in the issue #22696. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 02:00:22 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 05 Dec 2014 01:00:22 +0000 Subject: [issue22560] Add loop-agnostic SSL implementation to asyncio In-Reply-To: <1412548102.84.0.685230620276.issue22560@psf.upfronthosting.co.za> Message-ID: <1417741222.12.0.801599690328.issue22560@psf.upfronthosting.co.za> Antoine Pitrou added the comment: >From issue 22768: """ > Maybe > transport.get_extra_info('socket').getpeercert(True) > would be okay, no patch needed? That will be problematic with issue22560. The clear-text socket object and the SSL object become unrelated, and it would be logical for get_extra_info('socket') to return the clear-text socket, so either a get_extra_info('ssl') would be needed, or we should expose the SSL properties directly as extra info members. """ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 02:01:50 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Dec 2014 01:01:50 +0000 Subject: [issue22984] test_json.test_endless_recursion(): "Fatal Python error: Cannot recover from stack overflow." on x86 XP-4 3.x buildbot In-Reply-To: <1417554919.08.0.0786746086364.issue22984@psf.upfronthosting.co.za> Message-ID: <1417741310.67.0.754752070941.issue22984@psf.upfronthosting.co.za> STINNER Victor added the comment: Here is a patch to use a lower recursion limit to no stress the C stack. ---------- keywords: +patch Added file: http://bugs.python.org/file37363/test_endless_recursion.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 02:21:00 2014 From: report at bugs.python.org (Demian Brecht) Date: Fri, 05 Dec 2014 01:21:00 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za> Message-ID: <1417742460.97.0.920404520361.issue21793@psf.upfronthosting.co.za> Demian Brecht added the comment: Bump (again) for hopeful merge. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 02:32:50 2014 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 05 Dec 2014 01:32:50 +0000 Subject: [issue22926] asyncio: raise an exception when called from the wrong thread In-Reply-To: <1417740421.07.0.431101274453.issue22926@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Maybe only in debug mode? Getting thread ID or current thread may be expensive. Also it is conceivable that run... is called first from one thread and then from another. Maybe. On Dec 4, 2014 4:47 PM, "STINNER Victor" wrote: > > STINNER Victor added the comment: > > Guido, Yury: What do you think? Does it sound reasonable to raise an > exception if an event loop is used from the wrong thread? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 03:32:19 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 05 Dec 2014 02:32:19 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za> Message-ID: <1417746739.04.0.107557843817.issue21793@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 04:21:52 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 05 Dec 2014 03:21:52 +0000 Subject: [issue22926] asyncio: raise an exception when called from the wrong thread In-Reply-To: <1416760694.74.0.749180510867.issue22926@psf.upfronthosting.co.za> Message-ID: <1417749712.43.0.707557293621.issue22926@psf.upfronthosting.co.za> Yury Selivanov added the comment: > - modify tests to set the event loop to the newly created event loop, instead of setting it to None I'm not sure that this particular change is a great idea. I kind of liked that unittests ensure that loop is passed everywhere explicitly in asyncio. > - modify get_event_loop() to always raise a RuntimeError if the thread has no event loop. Before an AssertionError was not raised if python runs with -O option +1. > - modify BaseEventLoop._assert_is_current_event_loop() to fail if the thread has an event loop Hm, I think I don't understand why this function doesn't to anything when there is no loop in the thread... Let's fix it. In your patch, you should also replace 'except AsserionError' with 'except RuntimeError'. > Does it sound reasonable to raise an exception if an event loop is used from the wrong thread? I think we should in debug mode at least. > Getting thread ID or current thread may be expensive. Victor, can you benchmark this? I'm pretty sure that Guido is right about this, but sometimes syscalls are pretty fast. I doubt that a lot of people know about debug mode, so if it has a negligible cost I'd do the check every time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 04:30:49 2014 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 05 Dec 2014 03:30:49 +0000 Subject: [issue22926] asyncio: raise an exception when called from the wrong thread In-Reply-To: <1417749712.43.0.707557293621.issue22926@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: On Thu, Dec 4, 2014 at 7:21 PM, Yury Selivanov wrote: > > Yury Selivanov added the comment: > > > - modify tests to set the event loop to the newly created event loop, > instead of setting it to None > > I'm not sure that this particular change is a great idea. I kind of liked > that unittests ensure that loop is passed everywhere explicitly in asyncio. > Indeed, don't break that. > > > - modify get_event_loop() to always raise a RuntimeError if the thread > has no event loop. Before an AssertionError was not raised if python runs > with -O option > > +1. > +1 > > > - modify BaseEventLoop._assert_is_current_event_loop() to fail if the > thread has an event loop > > Hm, I think I don't understand why this function doesn't to anything when > there is no loop in the thread... Let's fix it. In your patch, you should > also replace 'except AsserionError' with 'except RuntimeError'. > > > > Does it sound reasonable to raise an exception if an event loop is used > from the wrong thread? > > I think we should in debug mode at least. > > > > Getting thread ID or current thread may be expensive. > > Victor, can you benchmark this? I'm pretty sure that Guido is right about > this, but sometimes syscalls are pretty fast. I doubt that a lot of people > know about debug mode, so if it has a negligible cost I'd do the check > every time. > I take it back, it's only 250 nsec to call threading.current_thread(), and 300 nsec to acquire and release a lock. I still think you shouldn't set the thread when the loop is created but only when run*() is active. (Using call_later() from another thread when the loop is inactive should not be an error IMO -- there's nothing against passing a selector instance to another thread as long as only one thread at a time waits for it.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 04:49:03 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 05 Dec 2014 03:49:03 +0000 Subject: [issue22998] inspect.Signature and default arguments In-Reply-To: <1417724041.66.0.201313804397.issue22998@psf.upfronthosting.co.za> Message-ID: <20141205034901.76710.6094@psf.io> Roundup Robot added the comment: New changeset 71c38c233e5c by Yury Selivanov in branch '3.4': docs.inspect: Fix BoundArguments example. Issue #22998. https://hg.python.org/cpython/rev/71c38c233e5c New changeset 697adefaba6b by Yury Selivanov in branch 'default': docs.inspect: Fix BoundArguments example. Issue #22998. https://hg.python.org/cpython/rev/697adefaba6b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 05:26:39 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 05 Dec 2014 04:26:39 +0000 Subject: [issue19834] Unpickling exceptions pickled by Python 2 In-Reply-To: <1385740154.87.0.494742260047.issue19834@psf.upfronthosting.co.za> Message-ID: <1417753599.45.0.41027219784.issue19834@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 08:11:43 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 05 Dec 2014 07:11:43 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za> Message-ID: <1417763503.94.0.665861337203.issue21793@psf.upfronthosting.co.za> Berker Peksag added the comment: I left a couple of comments on Rietveld. Thanks for the patch, Demian. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 08:37:11 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 05 Dec 2014 07:37:11 +0000 Subject: [issue22768] Add a way to get the peer certificate of a SSL Transport In-Reply-To: <1414693136.26.0.003644122895.issue22768@psf.upfronthosting.co.za> Message-ID: <1417765031.5.0.876760592292.issue22768@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 08:41:57 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Dec 2014 07:41:57 +0000 Subject: [issue22599] traceback: errors in the linecache module at exit In-Reply-To: <1412940961.34.0.0781587147709.issue22599@psf.upfronthosting.co.za> Message-ID: <1417765317.74.0.43019910103.issue22599@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, please do this. ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 08:44:23 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Dec 2014 07:44:23 +0000 Subject: [issue22696] Add a function to know about interpreter shutdown In-Reply-To: <1413980453.04.0.451789079104.issue22696@psf.upfronthosting.co.za> Message-ID: <1417765463.0.0.325665227416.issue22696@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: After solving this issue we should reconsider the traceback_ignore_linecache_error.patch patch in issue22599. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 08:54:57 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Dec 2014 07:54:57 +0000 Subject: [issue22996] Order of _io objects finalization can lose data in reference cycles In-Reply-To: <1417701026.92.0.498236598098.issue22996@psf.upfronthosting.co.za> Message-ID: <1417766097.18.0.319618411672.issue22996@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think that reference loop breaker should be smarter. If we have a loop A ? B ? C ? D then the order of the finalization of A and B is not defined, but B should be finalized before C and C before D. This should fix unintentional issues with chained io classes because they have no back references. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 09:03:45 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Dec 2014 08:03:45 +0000 Subject: [issue22996] Order of _io objects finalization can lose data in reference cycles In-Reply-To: <1417701026.92.0.498236598098.issue22996@psf.upfronthosting.co.za> Message-ID: <1417766625.7.0.575255407095.issue22996@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Note that the same issue is exist with gzip, bz2, lzma, tarfile and zipfile (or even worse). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 09:41:30 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Dec 2014 08:41:30 +0000 Subject: [issue22984] test_json.test_endless_recursion(): "Fatal Python error: Cannot recover from stack overflow." on x86 XP-4 3.x buildbot In-Reply-To: <1417554919.08.0.0786746086364.issue22984@psf.upfronthosting.co.za> Message-ID: <1417768890.07.0.34408829192.issue22984@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think this patch will break the purpose of the test. We should fix the issue instead of hide it from tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 09:42:26 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Dec 2014 08:42:26 +0000 Subject: [issue22984] test_json.test_endless_recursion(): "Fatal Python error: Cannot recover from stack overflow." on x86 XP-4 3.x buildbot In-Reply-To: <1417554919.08.0.0786746086364.issue22984@psf.upfronthosting.co.za> Message-ID: <1417768946.37.0.559999089787.issue22984@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 10:11:41 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Dec 2014 09:11:41 +0000 Subject: [issue22926] asyncio: raise an exception when called from the wrong thread In-Reply-To: <1416760694.74.0.749180510867.issue22926@psf.upfronthosting.co.za> Message-ID: <1417770701.14.0.00871345911493.issue22926@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, here is an updated patch (version 2): - tests still ensure that the event loop is passed explicitly - call_soon() & cie now fail if the policy has no event loop set for the current thread (before it only failed if the event loop set in the policy was different than the called event loop) > I'm not sure that this particular change is a great idea. I kind of liked that unittests ensure that loop is passed everywhere explicitly in asyncio. I agree, but we can just monkey-patch the _assert_is_current_event_loop() to disable the check even if debug mode. For example, it can be done in test_utils.TestCase.set_event_loop(), no need to modify individual test cases. > Maybe only in debug mode? Oh sorry, I forgot to mention that my patch only enhance an existing test, _assert_is_current_event_loop(), which is only done in debug mode. I'm so happy to have this debug mode, at the beginning Guido didn't want it :-D > - modify BaseEventLoop._assert_is_current_event_loop() to fail if the thread has an event loop Oops, the method already fails if the event loop is different than the current event loop of the policy. My patch changes the behaviour when the policy has *no* current event loop. > In your patch, you should also replace 'except AsserionError' with 'except RuntimeError'. Ok, that's why we must reject any patch without unit test :-D > I still think you shouldn't set the thread when the loop is created but only when run*() is active. (Using call_later() from another thread when the loop is inactive should not be an error IMO -- there's nothing against passing a selector instance to another thread as long as only one thread at a time waits for it.) Hum, I'm not fully convinced. Technically, it "works" to call call_soon() instead of call_soon_threadsafe() when the event loop is not running yet. But multithreading means race condition. It probably means that in most cases, calling call_soon() would work because the event loop didn't start yet, but in some cases, the event loop may already run depending on the timing. I prefer to force users to always use call_soon_threadsafe() to avoid bad suprises. ---------- Added file: http://bugs.python.org/file37364/asyncio_thread-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 10:25:49 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 05 Dec 2014 09:25:49 +0000 Subject: [issue22599] traceback: errors in the linecache module at exit In-Reply-To: <1412940961.34.0.0781587147709.issue22599@psf.upfronthosting.co.za> Message-ID: <20141205092546.27511.78779@psf.io> Roundup Robot added the comment: New changeset cd3244416592 by Victor Stinner in branch '3.4': Issue #22599: Enhance tokenize.open() to be able to call it during Python https://hg.python.org/cpython/rev/cd3244416592 New changeset 22f2784a276e by Victor Stinner in branch 'default': (Merge 3.4) Issue #22599: Enhance tokenize.open() to be able to call it during https://hg.python.org/cpython/rev/22f2784a276e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 10:27:35 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Dec 2014 09:27:35 +0000 Subject: [issue22599] traceback: errors in the linecache module at exit In-Reply-To: <1412940961.34.0.0781587147709.issue22599@psf.upfronthosting.co.za> Message-ID: <1417771655.32.0.57156482631.issue22599@psf.upfronthosting.co.za> STINNER Victor added the comment: > Yes, please do this. Ok done. I only added the test to default, not in the 3.4 branch. As Antoine noticed, the test is fragile, I perfer to not backport it. Ok, let's focus now on the issue #22696 ;-) ---------- dependencies: -Add a function to know about interpreter shutdown resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 10:29:15 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Dec 2014 09:29:15 +0000 Subject: [issue22696] Add a function to know about interpreter shutdown In-Reply-To: <1413980453.04.0.451789079104.issue22696@psf.upfronthosting.co.za> Message-ID: <1417771755.13.0.437656738197.issue22696@psf.upfronthosting.co.za> STINNER Victor added the comment: > After solving this issue we should reconsider the traceback_ignore_linecache_error.patch patch in issue22599. I reposted the patch in this issue since I just closed the issue #22599. ---------- Added file: http://bugs.python.org/file37365/traceback_ignore_linecache_error.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 10:41:16 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Dec 2014 09:41:16 +0000 Subject: [issue22984] test_json.test_endless_recursion(): "Fatal Python error: Cannot recover from stack overflow." on x86 XP-4 3.x buildbot In-Reply-To: <1417554919.08.0.0786746086364.issue22984@psf.upfronthosting.co.za> Message-ID: <1417772476.08.0.633036066292.issue22984@psf.upfronthosting.co.za> STINNER Victor added the comment: > I think this patch will break the purpose of the test. We should fix the issue instead of hide it from tests. The test ensures that json calls Py_EnterRecursiveCall() which relies on sys.getrecursionlimit(), see the commit below. There is no generic fix for C stack overflow. The tes failed on Windows XP which is no more supported, I don't think that it's interesting to spend time on it. changeset: 70021:9557e4eeb291 branch: 3.1 parent: 69997:b7abf0590e1c user: Ezio Melotti date: Wed May 11 01:02:56 2011 +0300 files: Lib/json/tests/test_recursion.py Misc/NEWS Modules/_json.c description: #12051: Fix segfault in json.dumps() while encoding highly-nested objects using the C accelerations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 10:58:05 2014 From: report at bugs.python.org (Cees Timmerman) Date: Fri, 05 Dec 2014 09:58:05 +0000 Subject: [issue22999] Copying emoji to Windows clipboard corrupts string in Python 3.3 and up Message-ID: <1417773485.83.0.226794721808.issue22999@psf.upfronthosting.co.za> New submission from Cees Timmerman: # http://stackoverflow.com/a/25678113/819417 def copy(data): if not isinstance(data, unicode): data = data.decode('mbcs') OpenClipboard(None) EmptyClipboard() hCd = GlobalAlloc(GMEM_DDESHARE, 2 * (len(data) + 1)) pchData = GlobalLock(hCd) wcscpy(ctypes.c_wchar_p(pchData), data) GlobalUnlock(hCd) SetClipboardData(CF_UNICODETEXT, hCd) CloseClipboard() Emoji "?" (\U0001f400) is copied as "?" (\U0001f4cb), or "?." turns to "?" (note the period). It works fine in Python 3.2.5. ---------- components: Unicode messages: 232188 nosy: Cees.Timmerman, ezio.melotti, haypo priority: normal severity: normal status: open title: Copying emoji to Windows clipboard corrupts string in Python 3.3 and up type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 11:11:03 2014 From: report at bugs.python.org (Cees Timmerman) Date: Fri, 05 Dec 2014 10:11:03 +0000 Subject: [issue22999] Copying emoji to Windows clipboard corrupts string in Python 3.3 and up In-Reply-To: <1417773485.83.0.226794721808.issue22999@psf.upfronthosting.co.za> Message-ID: <1417774263.87.0.889197632272.issue22999@psf.upfronthosting.co.za> Cees Timmerman added the comment: A copy of my test program at https://gist.github.com/CTimmerman/133cb80100357dde92d8 ---------- Added file: http://bugs.python.org/file37366/test_clipboard_win.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 11:32:39 2014 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2014 10:32:39 +0000 Subject: [issue22999] Copying emoji to Windows clipboard corrupts string in Python 3.3 and up In-Reply-To: <1417773485.83.0.226794721808.issue22999@psf.upfronthosting.co.za> Message-ID: <1417775559.06.0.304131383456.issue22999@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: (you swapped the unicode values: \U0001f4cb is copied as \U0001f400) On Windows, strings have changed in 3.3. See in https://docs.python.org/3/whatsnew/3.3.html, "len() now always returns 1 for non-BMP characters". The call to GlobalAlloc should use the number of wchar_t units, something like len(data.encode('utf-16')) + 2 ---------- nosy: +amaury.forgeotdarc resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 11:36:01 2014 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 05 Dec 2014 10:36:01 +0000 Subject: [issue22999] Copying emoji to Windows clipboard corrupts string in Python 3.3 and up In-Reply-To: <1417773485.83.0.226794721808.issue22999@psf.upfronthosting.co.za> Message-ID: <1417775761.95.0.453660903605.issue22999@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Better use utf-16-le encoding: len(data.encode('utf-16-le')) + 2 otherwise the encoded bytes start with the \fffe BOM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 11:39:38 2014 From: report at bugs.python.org (santhosh) Date: Fri, 05 Dec 2014 10:39:38 +0000 Subject: [issue22994] datetime buggy In-Reply-To: <1417689001.58.0.198336603717.issue22994@psf.upfronthosting.co.za> Message-ID: <1417775978.54.0.240750144929.issue22994@psf.upfronthosting.co.za> santhosh added the comment: Thanks simeon.visser, I understood your point. Didn't got your point earlier. Hey belopolsky, Here is the solution val=datetime.datetime.strptime("2015-02-01",'%Y-%m-%d').date() zon=pytz.timezone('US/Pacific') Bad Code: dt=datetime.datetime(val.year,val.month,val.day, tzinfo=zon) Good Code: dt=zon.localize(datetime.datetime(val.year,val.month,val.day)) In Linux, good code works perfectly Both code are working perfectly in Mac ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 15:11:20 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 05 Dec 2014 14:11:20 +0000 Subject: [issue22394] Update documentation building to use venv and pip In-Reply-To: <1410532646.93.0.821580086561.issue22394@psf.upfronthosting.co.za> Message-ID: <1417788680.03.0.677496355069.issue22394@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: georg.brandl -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 16:29:30 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 05 Dec 2014 15:29:30 +0000 Subject: [issue22581] Other mentions of the buffer protocol In-Reply-To: <1412785100.97.0.773176507587.issue22581@psf.upfronthosting.co.za> Message-ID: <1417793370.54.0.631171882867.issue22581@psf.upfronthosting.co.za> R. David Murray added the comment: Made some review comments. The last comment change (deletion) in unicodeobject.c is not as obvious as the other changes were; I'm not familiar enough with the C API to know why it is correct. I trust you on that, though :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 16:56:46 2014 From: report at bugs.python.org (Demian Brecht) Date: Fri, 05 Dec 2014 15:56:46 +0000 Subject: [issue22992] Adding a git developer's guide to Mercurial to devguide In-Reply-To: <1417651753.19.0.905189748743.issue22992@psf.upfronthosting.co.za> Message-ID: <1417795006.61.0.272560735995.issue22992@psf.upfronthosting.co.za> Demian Brecht added the comment: I believe most points should be addressed in the updated patch. Below are responses to other comments (those not included have resulted in changes in the patch). @Ezio: > 4) it should be possible to use evolve instead of bookmarks, but evolve is currently still a work in progress, so I'm not sure is worth mentioning it yet; I don't think that it's worth mentioning at this point given it's in an experimental state. 5) you said that named branches, bookmarks, and queues are all branches types in Mercurial. Can you add a source for that? No I can't, I was apparently completely off my face with the wording there :) 7) "Note that Mercurial doesn't have git's concept of staging, so all changes will be committed." [...] Agreed that there are a number of solutions to this, my intention here is simply to point out a difference that developers coming from a git background will be surprised about. This one caught me a little off guard initially as I personally really like git's staging feature and bank on it at times. @Berker: > "a core developer" or "a contributor"? Great point, thanks for that. My intention was to remove all merging-related operations and tailor it entirely towards contributors. I've reworded passages to make this clear and have removed all steps related to merging. ---------- Added file: http://bugs.python.org/file37367/issue22992.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 17:01:57 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 05 Dec 2014 16:01:57 +0000 Subject: [issue22914] Rewrite of Python 2/3 porting HOWTO In-Reply-To: <1416600199.23.0.813278658343.issue22914@psf.upfronthosting.co.za> Message-ID: <20141205160143.21274.7941@psf.io> Roundup Robot added the comment: New changeset 55b94462ca7f by Brett Cannon in branch '3.4': Issue #22914: Update the Python 2/3 porting HOWTO to describe a more https://hg.python.org/cpython/rev/55b94462ca7f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 17:02:07 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 05 Dec 2014 16:02:07 +0000 Subject: [issue22914] Rewrite of Python 2/3 porting HOWTO In-Reply-To: <1416600199.23.0.813278658343.issue22914@psf.upfronthosting.co.za> Message-ID: <1417795327.74.0.676240882915.issue22914@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 17:09:25 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 05 Dec 2014 16:09:25 +0000 Subject: [issue22992] Adding a git developer's guide to Mercurial to devguide In-Reply-To: <1417651753.19.0.905189748743.issue22992@psf.upfronthosting.co.za> Message-ID: <1417795765.81.0.368571892581.issue22992@psf.upfronthosting.co.za> Berker Peksag added the comment: + # address review comments and merge You can remove the "and merge" part. + # generate patch for submission + git diff master..issueA > issueA.patch Contributors may need to update their repos before this step. It would be good to add a note about "git pull --rebase". + # create patch + # git diff master..issueA > issueA.patch + hg diff -c issueA > issueA.patch Same here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 17:25:02 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Dec 2014 16:25:02 +0000 Subject: [issue22581] Other mentions of the buffer protocol In-Reply-To: <1412785100.97.0.773176507587.issue22581@psf.upfronthosting.co.za> Message-ID: <1417796702.95.0.131301349919.issue22581@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you David. I have left enumerations of concrete bytes-like classes (bytes and bytearray) because I thought that it is good to be more verbose in the documentation. I left the decision how write it to you: ":class:`bytes`, :class:`bytearray` or :term:`bytes-like object`", ":term:`bytes-like object` such as :class:`bytes` and :class:`bytearray`", or just ":term:`bytes-like object`". I don't understand your comment about unicodeobject.c. This change doesn't differ from others. May be you mean unicodeobject.h? Yes, "char buffer" is Python 2 term and doesn't make sense in 3.x. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 17:38:20 2014 From: report at bugs.python.org (Demian Brecht) Date: Fri, 05 Dec 2014 16:38:20 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za> Message-ID: <1417797500.82.0.502792266697.issue21793@psf.upfronthosting.co.za> Demian Brecht added the comment: Updated patch addressing review comments. Thanks for the review. ---------- Added file: http://bugs.python.org/file37368/issue21793_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 17:47:45 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 05 Dec 2014 16:47:45 +0000 Subject: [issue22581] Other mentions of the buffer protocol In-Reply-To: <1412785100.97.0.773176507587.issue22581@psf.upfronthosting.co.za> Message-ID: <1417798065.38.0.89272709535.issue22581@psf.upfronthosting.co.za> R. David Murray added the comment: Yeah, just ignore the unicodeobject.c comment comment. It seems to me that the stuff in the parens is supposed to be a precise description of what the format code handles, with elaboration in the following text. So I'd prefer to just use the :term: in those lists. But like I said I'm not that familiar with the C api, so I'm not sure how much weight my opinion should carry :) The biggest thing is consistency. If you want to keep all of them in the list, I'd favor the "such as" formulation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 18:57:51 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 05 Dec 2014 17:57:51 +0000 Subject: [issue22914] Rewrite of Python 2/3 porting HOWTO In-Reply-To: <1416600199.23.0.813278658343.issue22914@psf.upfronthosting.co.za> Message-ID: <1417802271.94.0.0782582860466.issue22914@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 19:19:00 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 05 Dec 2014 18:19:00 +0000 Subject: [issue22696] Add a function to know about interpreter shutdown In-Reply-To: <1413980453.04.0.451789079104.issue22696@psf.upfronthosting.co.za> Message-ID: <1417803540.04.0.393616342357.issue22696@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch with docs. ---------- Added file: http://bugs.python.org/file37369/is_finalizing2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 19:25:35 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 05 Dec 2014 18:25:35 +0000 Subject: [issue18835] Add aligned memory variants to the suite of PyMem functions/macros In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za> Message-ID: <1417803935.55.0.132612764987.issue18835@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Benchmarks and Intel's recommendation show that aligned allocation is actually important for AVX performance, and NumPy depends on CPython providing the right allocation APIs (for integration with tracemalloc): https://github.com/numpy/numpy/issues/5312 So I think for 3.5 we should start providing the APIs. Whether we use them in Python core is another discussion. Nathaniel, what APIs would you need exactly? See Victor's proposal in msg196834. ---------- nosy: +njs type: -> enhancement versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 19:31:53 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Dec 2014 18:31:53 +0000 Subject: [issue22984] test_json.test_endless_recursion(): "Fatal Python error: Cannot recover from stack overflow." on x86 XP-4 3.x buildbot In-Reply-To: <1417772476.08.0.633036066292.issue22984@psf.upfronthosting.co.za> Message-ID: <1444741.HiYMFTc3V3@raxxla> Serhiy Storchaka added the comment: > The tes failed on Windows XP which is no more supported, I don't think that > it's interesting to spend time on it. So may be just skip it on Windows XP? Or as far as this approach doesn't solve the problem and the test may crash on other platforms, may be run this test in a subprocess? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 19:36:24 2014 From: report at bugs.python.org (Demian Brecht) Date: Fri, 05 Dec 2014 18:36:24 +0000 Subject: [issue22946] urllib gives incorrect url after open when using HTTPS In-Reply-To: <1416998247.62.0.575795755864.issue22946@psf.upfronthosting.co.za> Message-ID: <1417804584.45.0.172114035842.issue22946@psf.upfronthosting.co.za> Demian Brecht added the comment: +1 to the addition of a test. Also, I know it's only related, but it might be nice to also have this fixed in http_error_default: https://hg.python.org/cpython/file/021c1df36910/Lib/urllib/request.py#l2003. ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 19:37:46 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Dec 2014 18:37:46 +0000 Subject: [issue22984] test_json.test_endless_recursion(): "Fatal Python error: Cannot recover from stack overflow." on x86 XP-4 3.x buildbot In-Reply-To: <1417554919.08.0.0786746086364.issue22984@psf.upfronthosting.co.za> Message-ID: <1417804666.15.0.0154872629962.issue22984@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 19:45:46 2014 From: report at bugs.python.org (Demian Brecht) Date: Fri, 05 Dec 2014 18:45:46 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za> Message-ID: <1417805146.57.0.700631135919.issue21793@psf.upfronthosting.co.za> Changes by Demian Brecht : Added file: http://bugs.python.org/file37370/issue21793_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 19:50:32 2014 From: report at bugs.python.org (John McKay) Date: Fri, 05 Dec 2014 18:50:32 +0000 Subject: [issue22946] urllib gives incorrect url after open when using HTTPS In-Reply-To: <1416998247.62.0.575795755864.issue22946@psf.upfronthosting.co.za> Message-ID: <1417805432.0.0.307926013279.issue22946@psf.upfronthosting.co.za> John McKay added the comment: For the test can I assume that we have the openssl binary in the path? The other tests just use a static response to emulate the server, but without being able to use s_client it would be quite a bit more effort to fake a working HTTP server with TLS so that it can be tested properly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 20:52:27 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 05 Dec 2014 19:52:27 +0000 Subject: [issue22946] urllib gives incorrect url after open when using HTTPS In-Reply-To: <1416998247.62.0.575795755864.issue22946@psf.upfronthosting.co.za> Message-ID: <1417809147.01.0.229625416514.issue22946@psf.upfronthosting.co.za> Benjamin Peterson added the comment: We have a testing HTTPS server in Lib/test/ssl_servers.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 21:17:47 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 05 Dec 2014 20:17:47 +0000 Subject: [issue22394] Update documentation building to use venv and pip In-Reply-To: <1410532646.93.0.821580086561.issue22394@psf.upfronthosting.co.za> Message-ID: <20141205201742.73388.84127@psf.io> Roundup Robot added the comment: New changeset 888103600e72 by Brett Cannon in branch 'default': Issue #22394: Add a 'venv' command to Doc/Makefile. https://hg.python.org/cpython/rev/888103600e72 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 21:18:01 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 05 Dec 2014 20:18:01 +0000 Subject: [issue22394] Update documentation building to use venv and pip In-Reply-To: <1410532646.93.0.821580086561.issue22394@psf.upfronthosting.co.za> Message-ID: <1417810681.23.0.515577281424.issue22394@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 21:30:51 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 05 Dec 2014 20:30:51 +0000 Subject: [issue22581] Other mentions of the buffer protocol In-Reply-To: <1412785100.97.0.773176507587.issue22581@psf.upfronthosting.co.za> Message-ID: <20141205203037.27495.40177@psf.io> Roundup Robot added the comment: New changeset 853e3e115db4 by Serhiy Storchaka in branch '3.4': Issue #22581: Use more "bytes-like object" throughout the docs and comments. https://hg.python.org/cpython/rev/853e3e115db4 New changeset 450a025b1669 by Serhiy Storchaka in branch 'default': Issue #22581: Use more "bytes-like object" throughout the docs and comments. https://hg.python.org/cpython/rev/450a025b1669 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 21:35:28 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Dec 2014 20:35:28 +0000 Subject: [issue22581] Other mentions of the buffer protocol In-Reply-To: <1412785100.97.0.773176507587.issue22581@psf.upfronthosting.co.za> Message-ID: <1417811728.78.0.750723737816.issue22581@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Committed with just "bytes-like object". Thank you David for your review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 21:36:17 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Dec 2014 20:36:17 +0000 Subject: [issue22581] Other mentions of the buffer protocol In-Reply-To: <1412785100.97.0.773176507587.issue22581@psf.upfronthosting.co.za> Message-ID: <1417811777.56.0.653026409446.issue22581@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 Dec 5 22:20:21 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Dec 2014 21:20:21 +0000 Subject: [issue18835] Add aligned memory variants to the suite of PyMem functions/macros In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za> Message-ID: <1417814421.42.0.36851356357.issue18835@psf.upfronthosting.co.za> STINNER Victor added the comment: Windows provides: void * _aligned_malloc( size_t size, size_t alignment ); http://msdn.microsoft.com/en-US/library/8z34s9c6%28v=vs.80%29.aspx How should we handle platforms which don't provide a memory allocator with an alignment? The simplest option is to return NULL (MemoryError). Allocating more memory and skip first bytes may work, but how do we retrieve the original address if the function releasing the memory block? What about Solaris, Mac OS X, FreeBSD, etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 22:22:56 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Dec 2014 21:22:56 +0000 Subject: [issue22696] Add a function to know about interpreter shutdown In-Reply-To: <1413980453.04.0.451789079104.issue22696@psf.upfronthosting.co.za> Message-ID: <1417814576.67.0.739671562982.issue22696@psf.upfronthosting.co.za> STINNER Victor added the comment: is_finalizing2.patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 22:32:58 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Dec 2014 21:32:58 +0000 Subject: [issue22996] Order of _io objects finalization can lose data in reference cycles In-Reply-To: <1417701026.92.0.498236598098.issue22996@psf.upfronthosting.co.za> Message-ID: <1417815178.37.0.0874438521845.issue22996@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 22:33:59 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Dec 2014 21:33:59 +0000 Subject: [issue21557] os.popen & os.system lack shell-related security warnings In-Reply-To: <1400794428.31.0.170474236819.issue21557@psf.upfronthosting.co.za> Message-ID: <1417815239.89.0.0224162531632.issue21557@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 22:37:40 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Dec 2014 21:37:40 +0000 Subject: [issue21557] os.popen & os.system lack shell-related security warnings In-Reply-To: <1400794428.31.0.170474236819.issue21557@psf.upfronthosting.co.za> Message-ID: <1417815460.63.0.113242150461.issue21557@psf.upfronthosting.co.za> STINNER Victor added the comment: Python 3.5 doc has no red warning in the subprocess module, but a nice section: https://docs.python.org/dev/library/subprocess.html#security-considerations Why not simply copying the note of the subprocess doc? "Note: Read the Security Considerations section before using shell=True." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 22:37:46 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Dec 2014 21:37:46 +0000 Subject: [issue22696] Add a function to know about interpreter shutdown In-Reply-To: <1413980453.04.0.451789079104.issue22696@psf.upfronthosting.co.za> Message-ID: <1417815466.18.0.904565469479.issue22696@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Before committing the patch it will be good to find places in the code which will benefit from this function. And please don't forget to fix a typo in the docstring. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 22:38:35 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Dec 2014 21:38:35 +0000 Subject: [issue21557] os.popen & os.system lack shell-related security warnings In-Reply-To: <1400794428.31.0.170474236819.issue21557@psf.upfronthosting.co.za> Message-ID: <1417815515.31.0.162604296255.issue21557@psf.upfronthosting.co.za> STINNER Victor added the comment: subprocess.getstatusoutput(cmd) needs also this note (or warning). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 22:38:48 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 05 Dec 2014 21:38:48 +0000 Subject: [issue22996] Order of _io objects finalization can lose data in reference cycles In-Reply-To: <1417701026.92.0.498236598098.issue22996@psf.upfronthosting.co.za> Message-ID: <1417815528.82.0.0787958117428.issue22996@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file37371/gcgzipio.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 22:44:09 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Dec 2014 21:44:09 +0000 Subject: [issue22985] Segfault on time.sleep In-Reply-To: <1417562194.55.0.557233180564.issue22985@psf.upfronthosting.co.za> Message-ID: <1417815849.15.0.64705955926.issue22985@psf.upfronthosting.co.za> STINNER Victor added the comment: > Program received signal SIGTERM, Terminated. SIGTERM is not a segmentation fault. SIGSEGV is for segmentation faults. ---------- nosy: +haypo resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 22:45:34 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Dec 2014 21:45:34 +0000 Subject: [issue9584] fnmatch, glob: Allow curly brace expansion In-Reply-To: <1281688613.27.0.00233773234268.issue9584@psf.upfronthosting.co.za> Message-ID: <1417815934.25.0.0197189299691.issue9584@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Allow curly brace expansion -> fnmatch, glob: Allow curly brace expansion _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 22:49:47 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 05 Dec 2014 21:49:47 +0000 Subject: [issue18835] Add aligned memory variants to the suite of PyMem functions/macros In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za> Message-ID: <1417816187.02.0.632054286149.issue18835@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > How should we handle platforms which don't provide a memory allocator > with an alignment? The simplest option is to return NULL (MemoryError). Are there such platforms? posix_memalign() is a POSIX standard, even OpenBSD has it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 22:52:30 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 05 Dec 2014 21:52:30 +0000 Subject: [issue9647] os.confstr() does not handle value changing length between calls In-Reply-To: <1282243493.08.0.1214343728.issue9647@psf.upfronthosting.co.za> Message-ID: <20141205215223.76716.77165@psf.io> Roundup Robot added the comment: New changeset a7a8947e9ce4 by Victor Stinner in branch 'default': Issue #9647: os.confstr() ensures that the second call to confstr() returns the https://hg.python.org/cpython/rev/a7a8947e9ce4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 23:00:10 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Dec 2014 22:00:10 +0000 Subject: [issue9647] os.confstr() does not handle value changing length between calls In-Reply-To: <1282243493.08.0.1214343728.issue9647@psf.upfronthosting.co.za> Message-ID: <1417816810.39.0.368499544739.issue9647@psf.upfronthosting.co.za> STINNER Victor added the comment: I added an assertion. Can we close this issue? ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 23:03:53 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Dec 2014 22:03:53 +0000 Subject: [issue22696] Add a function to know about interpreter shutdown In-Reply-To: <1413980453.04.0.451789079104.issue22696@psf.upfronthosting.co.za> Message-ID: <1417817033.46.0.62313035879.issue22696@psf.upfronthosting.co.za> STINNER Victor added the comment: > Before committing the patch it will be good to find places in the code which will benefit from this function. The traceback and/or the linecache is a first good candidate to use this new function. We may patch more functions later if needed, I don't think that we need to address all issues right now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 23:15:18 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Dec 2014 22:15:18 +0000 Subject: [issue18835] Add aligned memory variants to the suite of PyMem functions/macros In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za> Message-ID: <1417817718.88.0.594601568713.issue18835@psf.upfronthosting.co.za> STINNER Victor added the comment: PyMem_GetAllocator() and PyMem_SetAllocator() have a domain parameter which can take 3 values: PYMEM_DOMAIN_RAW, PYMEM_DOMAIN_MEM and PYMEM_DOMAIN_OBJ. I don't think that we need 3 flavors of allocators (PyMem_Raw, PyMem, PyObject). Maybe the PYMEM_DOMAIN_RAW domain is enough: OS functions don't require the GIL. In this case, should we add a new pair of Get/Set functions with an associated structure? Or maybe PyMem_SetAllocator() may ignore the aligned members of the patched PyMemAllocatorEx structure for domains other than PYMEM_DOMAIN_RAW? And PyMem_GetAllocator() would fill members with NULL. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 23:15:56 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Dec 2014 22:15:56 +0000 Subject: [issue9647] os.confstr() does not handle value changing length between calls In-Reply-To: <1282243493.08.0.1214343728.issue9647@psf.upfronthosting.co.za> Message-ID: <1417817756.14.0.792811616614.issue9647@psf.upfronthosting.co.za> STINNER Victor added the comment: (Oops, I didn't want to close the issue.) ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 23:30:35 2014 From: report at bugs.python.org (Nathaniel Smith) Date: Fri, 05 Dec 2014 22:30:35 +0000 Subject: [issue18835] Add aligned memory variants to the suite of PyMem functions/macros In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za> Message-ID: <1417818635.46.0.672447136733.issue18835@psf.upfronthosting.co.za> Nathaniel Smith added the comment: It's not terribly difficult to write a crude-but-effective aligned allocator on top of raw malloc: def aligned_malloc(size, alignment): assert alignment < 255 raw_pointer = (uint8*) malloc(size + alignment) shift = alignment - (raw_pointer % alignment) assert 0 < shift <= alignment aligned_pointer = raw_pointer + shift *(aligned_pointer - 1) = shift return aligned_pointer def aligned_free(uint8* pointer): shift = *(pointer - 1) free(pointer - shift) But, this fallback and the official Win32 API both disallow the use of plain free() (like Victor points out in msg196834), so we can't just add an aligned_malloc slot to the PyMemAllocator struct. This kind of aligned allocation is effectively its own memory domain. If native aligned allocation support were added to PyMalloc then it could potentially do better (e.g. by noticing that it already has a block on its freelist with the requested alignment and just returning that instead of overallocating). This might be the ideal solution for Raymond's use case, but I have no idea how much work it would be to mess around with PyMalloc innards. Numpy doesn't currently use aligned allocation for anything, but we'd like to keep our options open. If we do end up using it in the future then there's a reasonable chance we might want to use it *without* the GIL held (e.g. for allocating temporary buffers inside C loops). OTOH we are also happy to implement the aligned allocation ourselves (either on top of the system APIs or directly) -- we just don't want to lose tracemalloc support when we do. For numpy's purposes, I think the best approach would be to add a tracemalloc "escape valve", with an interface like: PyMem_RecordAlloc(const char* domain, void* tag, size_t quantity, PyMem_RecordRealloc(const char* domain, void* old_tag, void* new_tag, size_t new_quantity) PyMem_RecordFree(const char* domain, void* tag) where the idea is that if after someone allocates memory (or potentially other discrete resources) directly without going through PyMem_*, they could then call these functions to tell tracemalloc what they just did. This would be useful in a number of cases: in addition to tracking aligned allocations, it would make it possible to re-use the tracemalloc infrastructure to track GPU buffers allocated by CUDA/GPGPU-type code, mmap usage, hugetlbfs usage, etc. Potentially even open file descriptors if one wants to go there (seems pretty useful, actually). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 23:36:22 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 05 Dec 2014 22:36:22 +0000 Subject: [issue18835] Add aligned memory variants to the suite of PyMem functions/macros In-Reply-To: <1417817718.88.0.594601568713.issue18835@psf.upfronthosting.co.za> Message-ID: <54823364.3040406@free.fr> Antoine Pitrou added the comment: Le 05/12/2014 23:15, STINNER Victor a ?crit : > > > I don't think that we need 3 flavors of allocators (PyMem_Raw, > PyMem, PyObject). > > Maybe the PYMEM_DOMAIN_RAW domain is enough: OS functions don't require the GIL. In this case, should we add a new pair of Get/Set functions with an associated structure? How about a new domain instead? PYMEM_DOMAIN_RAW_ALIGNED? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 23:43:08 2014 From: report at bugs.python.org (Nathaniel Smith) Date: Fri, 05 Dec 2014 22:43:08 +0000 Subject: [issue18835] Add aligned memory variants to the suite of PyMem functions/macros In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za> Message-ID: <1417819388.53.0.882788594746.issue18835@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Re: msg232219: If you go down the route of adding both aligned_malloc and aligned_free to the Allocator structure, I think you might as well support it for all domains? For the PyMem and PyObject domains you can just literally set the default functions to be PyMem_RawAlignedMalloc and PyMem_RawAlignedFree, and that leaves the door open to fancier implementations in the future (e.g. if PyMalloc starts implementing aligned allocation directly). Re: msg232222: Currently all the domains share the same vtable struct, though, whereas aligned allocator functions have different signatures. So you can't literally just add an entry to the existing domain enum and be done. It also occurs to me that if numpy ever gets serious about using aligned memory then we might also need aligned_realloc (numpy allows arrays to be resized, sigh), which is possible to do but I *cannot* recommend python attempt to provide as a standard interface. (It's not available at all in POSIX.) I guess this is another argument that it might be best to just give numpy an escape valve and worry about CPython's internal needs separately. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 23:51:03 2014 From: report at bugs.python.org (Martin Panter) Date: Fri, 05 Dec 2014 22:51:03 +0000 Subject: [issue22989] HTTPResponse.msg not as documented In-Reply-To: <1417632317.82.0.906874710781.issue22989@psf.upfronthosting.co.za> Message-ID: <1417819863.55.0.702333447273.issue22989@psf.upfronthosting.co.za> Martin Panter added the comment: See Issue 21228 for a patch which documents the ?.msg? hack, and that the info() method is available for HTTP responses. I think documenting the ?.headers? attribute would be a bad idea, because it is introducing yet another way to do what the almost-documented info() method already does. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 5 23:58:03 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 05 Dec 2014 22:58:03 +0000 Subject: [issue18835] Add aligned memory variants to the suite of PyMem functions/macros In-Reply-To: <1417819388.53.0.882788594746.issue18835@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: You cannot just add a new domain because the function prototypes are different (need an extra alignement parameter). You have to add new members to the structure or add a new structure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 00:32:59 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 05 Dec 2014 23:32:59 +0000 Subject: [issue21228] Missing enumeration of HTTPResponse Objects methods of urllib.request.urlopen's http.client.HTTPResponse? In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za> Message-ID: <1417822379.86.0.904168005437.issue21228@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> patch review versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 00:53:07 2014 From: report at bugs.python.org (Martin Panter) Date: Fri, 05 Dec 2014 23:53:07 +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: <1417823587.7.0.76562915989.issue22153@psf.upfronthosting.co.za> Martin Panter added the comment: Updated patch with indentation fixed and new wording. I am just guessing the RST syntax based on the surrounding text, so please review :) ---------- Added file: http://bugs.python.org/file37372/runtest.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 00:57:30 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 05 Dec 2014 23:57:30 +0000 Subject: [issue22998] inspect.Signature and default arguments In-Reply-To: <1417724041.66.0.201313804397.issue22998@psf.upfronthosting.co.za> Message-ID: <1417823850.87.0.502685152069.issue22998@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Should this be closed now? ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 01:05:53 2014 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 06 Dec 2014 00:05:53 +0000 Subject: [issue22998] inspect.Signature and default arguments In-Reply-To: <1417724041.66.0.201313804397.issue22998@psf.upfronthosting.co.za> Message-ID: <1417824353.33.0.973860088854.issue22998@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Should this be closed now? Yes, let's close it. David and Walter, you're welcome to re-open the issue if you want to discuss it in more detail. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 02:01:03 2014 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 06 Dec 2014 01:01:03 +0000 Subject: [issue22926] asyncio: raise an exception when called from the wrong thread In-Reply-To: <1416760694.74.0.749180510867.issue22926@psf.upfronthosting.co.za> Message-ID: <1417827663.5.0.437312029511.issue22926@psf.upfronthosting.co.za> Yury Selivanov added the comment: Hi Victor, I left you some feedback in code review. I'm kind of leaning towards your proposal that we should force users to always use safe API. But I also understand Guido's point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 02:17:14 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 06 Dec 2014 01:17:14 +0000 Subject: [issue16041] poplib: unlimited readline() from connection In-Reply-To: <1348569563.2.0.69634867698.issue16041@psf.upfronthosting.co.za> Message-ID: <20141206011658.27511.32791@psf.io> Roundup Robot added the comment: New changeset 339f877cca11 by Benjamin Peterson in branch '2.7': in poplib, limit maximum line length that we read from the network (closes #16041) https://hg.python.org/cpython/rev/339f877cca11 ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 02:17:14 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 06 Dec 2014 01:17:14 +0000 Subject: [issue16043] xmlrpc: gzip_decode has unlimited read() In-Reply-To: <1348570326.9.0.587983624118.issue16043@psf.upfronthosting.co.za> Message-ID: <20141206011658.27511.46636@psf.io> Roundup Robot added the comment: New changeset d50096708b2d by Benjamin Peterson in branch '2.7': add a default limit for the amount of data xmlrpclib.gzip_decode will return (closes #16043) https://hg.python.org/cpython/rev/d50096708b2d ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 02:17:19 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 06 Dec 2014 01:17:19 +0000 Subject: [issue16042] smtplib: unlimited readline() from connection In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za> Message-ID: <20141206011658.27511.73754@psf.io> Roundup Robot added the comment: New changeset 923aac88a3cc by Benjamin Peterson in branch '2.7': smtplib: limit amount read from the network (closes #16042) https://hg.python.org/cpython/rev/923aac88a3cc ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 02:26:50 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 06 Dec 2014 01:26:50 +0000 Subject: [issue16893] Generate Idle help from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <20141206012641.27511.2487@psf.io> Roundup Robot added the comment: New changeset 283c364c372a by Terry Jan Reedy in branch '2.7': Issue #16893: Update Idle doc chapter to match current Idle and add new https://hg.python.org/cpython/rev/283c364c372a New changeset 2fc341c6e314 by Terry Jan Reedy in branch '3.4': Issue #16893: Update Idle doc chapter to match current Idle and add new https://hg.python.org/cpython/rev/2fc341c6e314 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 02:32:18 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 06 Dec 2014 01:32:18 +0000 Subject: [issue22998] inspect.Signature and default arguments In-Reply-To: <1417724041.66.0.201313804397.issue22998@psf.upfronthosting.co.za> Message-ID: <1417829538.21.0.754195135155.issue22998@psf.upfronthosting.co.za> R. David Murray added the comment: I'm good with your solution, but I'm going to adjust the resolution by changing the component :) ---------- assignee: -> docs at python components: +Documentation -Library (Lib) nosy: +docs at python resolution: wont fix -> fixed stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 02:36:14 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 06 Dec 2014 01:36:14 +0000 Subject: [issue16043] xmlrpc: gzip_decode has unlimited read() In-Reply-To: <1348570326.9.0.587983624118.issue16043@psf.upfronthosting.co.za> Message-ID: <20141206013612.27497.10892@psf.io> Roundup Robot added the comment: New changeset a0368f81af9a by Benjamin Peterson in branch '3.2': add a default limit for the amount of data xmlrpclib.gzip_decode will return (closes #16043) https://hg.python.org/cpython/rev/a0368f81af9a New changeset 4a9418c6f8ae by Benjamin Peterson in branch '3.3': merge 3.2 (#16043) https://hg.python.org/cpython/rev/4a9418c6f8ae New changeset 6b83e21c8679 by Benjamin Peterson in branch '3.4': merge 3.3 (#16043) https://hg.python.org/cpython/rev/6b83e21c8679 New changeset 6f002c4741e2 by Benjamin Peterson in branch 'default': merge 3.4 (#16043) https://hg.python.org/cpython/rev/6f002c4741e2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 02:47:33 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 06 Dec 2014 01:47:33 +0000 Subject: [issue9179] Lookback with group references incorrect (two issues?) In-Reply-To: <1278411814.72.0.368411829683.issue9179@psf.upfronthosting.co.za> Message-ID: <1417830453.07.0.434919911403.issue9179@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 04:11:46 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 06 Dec 2014 03:11:46 +0000 Subject: [issue22935] Disabling SSLv3 support In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za> Message-ID: <20141206031143.74585.36801@psf.io> Roundup Robot added the comment: New changeset 49d267a58cc2 by Benjamin Peterson in branch '2.7': allow ssl module to compile if openssl doesn't support SSL 3 (closes #22935) https://hg.python.org/cpython/rev/49d267a58cc2 New changeset 4077e0cd8d48 by Benjamin Peterson in branch '3.4': allow ssl module to compile if openssl doesn't support SSL 3 (closes #22935) https://hg.python.org/cpython/rev/4077e0cd8d48 New changeset fbf3747e721c by Benjamin Peterson in branch 'default': merge 3.4 (#22935) https://hg.python.org/cpython/rev/fbf3747e721c ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 07:34:34 2014 From: report at bugs.python.org (Steve Dower) Date: Sat, 06 Dec 2014 06:34:34 +0000 Subject: [issue22919] Update PCBuild for VS 2015 In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za> Message-ID: <1417847674.28.0.817809045526.issue22919@psf.upfronthosting.co.za> Steve Dower added the comment: Does anyone else want to provide any feedback? Or should I go ahead and get it in (after rebasing/retesting/etc.)? The feedback so far has been really helpful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 08:52:39 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 06 Dec 2014 07:52:39 +0000 Subject: [issue9584] fnmatch, glob: Allow curly brace expansion In-Reply-To: <1281688613.27.0.00233773234268.issue9584@psf.upfronthosting.co.za> Message-ID: <1417852359.0.0.912422592515.issue9584@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 09:48:47 2014 From: report at bugs.python.org (STINNER Victor) Date: Sat, 06 Dec 2014 08:48:47 +0000 Subject: [issue22935] Disabling SSLv3 support In-Reply-To: <20141206031143.74585.36801@psf.io> Message-ID: STINNER Victor added the comment: The documentation should be modified to explain that SSLv2 and SSLv3 are not always available. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 11:14:57 2014 From: report at bugs.python.org (Zachary Ware) Date: Sat, 06 Dec 2014 10:14:57 +0000 Subject: [issue22919] Update PCBuild for VS 2015 In-Reply-To: <1417847674.28.0.817809045526.issue22919@psf.upfronthosting.co.za> Message-ID: Zachary Ware added the comment: Sorry Steve, I haven't been on Windows since my last review to give it another try. And, of course, somewhere in the 5 seconds between shutting down from Gentoo and turning back on for Windows last night, my laptop decided that POSTing was just too much effort, and it would rather just sit around spinning the fan and not doing anything else at all. I should be able to get VS2015 set up on my backup (wife's) machine Tuesday; until then, if you'd like to post another full patch to appease Rietveld, I can try to look through it again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 13:24:02 2014 From: report at bugs.python.org (StoreIntegrator) Date: Sat, 06 Dec 2014 12:24:02 +0000 Subject: [issue23000] More support for Visual Studio users on Windows? Message-ID: <1417868642.13.0.879452614087.issue23000@psf.upfronthosting.co.za> New submission from StoreIntegrator: Hi, When using Python on Windows I always encounter plenty of errors which are simply frustrating. Typically issues compilation, linking, libraries which have nothing to do with functional coding in Python are numerous. Do have a look at PTVS tools how an integrated UI can work... And do try to get rid of the already for > 5 years existing BUGS like: https://pytools.codeplex.com/workitem/2808 Simply frustrating to use Python this way. J. ---------- messages: 232240 nosy: StoreIntegrator priority: normal severity: normal status: open title: More support for Visual Studio users on Windows? type: compile error 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 Dec 6 13:33:48 2014 From: report at bugs.python.org (Omer Katz) Date: Sat, 06 Dec 2014 12:33:48 +0000 Subject: [issue22985] Segfault on time.sleep In-Reply-To: <1417815849.15.0.64705955926.issue22985@psf.upfronthosting.co.za> Message-ID: Omer Katz added the comment: So why exactly the program terminates on a system call? 2014-12-05 23:44 GMT+02:00 STINNER Victor : > > STINNER Victor added the comment: > > > Program received signal SIGTERM, Terminated. > > SIGTERM is not a segmentation fault. SIGSEGV is for segmentation faults. > > ---------- > nosy: +haypo > resolution: -> not a bug > status: open -> closed > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 14:54:38 2014 From: report at bugs.python.org (SilentGhost) Date: Sat, 06 Dec 2014 13:54:38 +0000 Subject: [issue23000] More support for Visual Studio users on Windows? In-Reply-To: <1417868642.13.0.879452614087.issue23000@psf.upfronthosting.co.za> Message-ID: <1417874078.34.0.0231801072991.issue23000@psf.upfronthosting.co.za> SilentGhost added the comment: This seem like an issue with numpy, not python. Perhaps installing using binary would be a better option for you? In any case, this need further elaborating at what the actual problem and the solution could be. ---------- nosy: +SilentGhost resolution: -> not a bug status: open -> closed 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 Dec 6 15:21:07 2014 From: report at bugs.python.org (David Edelsohn) Date: Sat, 06 Dec 2014 14:21:07 +0000 Subject: [issue20220] TarFile.list() outputs wrong time In-Reply-To: <1389384273.4.0.330615086279.issue20220@psf.upfronthosting.co.za> Message-ID: <1417875667.11.0.125292841074.issue20220@psf.upfronthosting.co.za> David Edelsohn added the comment: There now are two zLinux buildbots: zlinux (running SUSE) and zwheezy (running Debian). zlinux (running on SUSE) has the libc problem causing the timezone error. A second buildbot was added, not converting or upgrading the existing buildbot. I still would appreciate the patch from Issue22844 to fix the test_gdb failure on the zwheezy buildbot. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 15:25:08 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 06 Dec 2014 14:25:08 +0000 Subject: [issue23001] Accept mutable bytes-like objects Message-ID: <1417875906.64.0.311564166909.issue23001@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Some builtins accept only read-only bytes-like objects (PyArg_Parse format codes "s#", "z#", "y", and "y#"). Proposed patch makes them accepting also mutable bytes-like objects such as bytearray. I'm not sure that all these changes are useful, but in some cases this can get rid of copying binary data created in bytearray (e.g. read by readinto()). ---------- components: Extension Modules files: accept_mutable_buffers.patch keywords: patch messages: 232244 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Accept mutable bytes-like objects type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file37373/accept_mutable_buffers.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 16:42:03 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 06 Dec 2014 15:42:03 +0000 Subject: [issue23000] More support for Visual Studio users on Windows? In-Reply-To: <1417868642.13.0.879452614087.issue23000@psf.upfronthosting.co.za> Message-ID: <1417880523.75.0.655704705677.issue23000@psf.upfronthosting.co.za> R. David Murray added the comment: Note also that there are going to be significant improvements in the Python Windows build system for 3.5. Any further (specific, non-distutils) requests for improvement should be targeted against that version once issue 22919 has been integrated. Please do open a new issue with *specific* problems if they are problems with the CPython compile itself or with distutils, as opposed to problems with a specific 3rd party project's compilation instructions...the latter should be reported to the 3rd party project first, and if the project determines it is rooted in a problem with CPython/distutils, it can then be reported upstream here with sufficient details for us to take action. ---------- nosy: +r.david.murray resolution: not a bug -> third party stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 16:55:28 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Sat, 06 Dec 2014 15:55:28 +0000 Subject: [issue23001] Accept mutable bytes-like objects In-Reply-To: <1417875906.64.0.311564166909.issue23001@psf.upfronthosting.co.za> Message-ID: <1417881328.98.0.646919280576.issue23001@psf.upfronthosting.co.za> Josh Rosenberg added the comment: In the event of calls back into Python code in multithreaded execution (or GIL release), this would mean you no longer have guarantees as to the contents (or even the validity) of the pointer you get back. I'd think the only safe way to accept mutable buffers would be to use the s*, z*, y* codes, which lock the buffer to prevent resize/destruction. Do we want to open segfault vulnerabilities in arbitrary functions? ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 17:31:42 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 06 Dec 2014 16:31:42 +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: <1417883502.98.0.185842626125.issue22153@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 17:55:52 2014 From: report at bugs.python.org (Omer Katz) Date: Sat, 06 Dec 2014 16:55:52 +0000 Subject: [issue22985] Segfault on time.sleep In-Reply-To: <1417562194.55.0.557233180564.issue22985@psf.upfronthosting.co.za> Message-ID: <1417884952.02.0.0666112917824.issue22985@psf.upfronthosting.co.za> Omer Katz added the comment: Capturing the signal provides the following traceback: File "mt_example.py", line 10, in p1 = ThreadPool() File "/home/omer/.virtualenvs/billiard/lib/python2.7/site-packages/billiard/pool.py", line 1016, in __init__ self._result_handler.start() File "/home/omer/.virtualenvs/billiard/lib/python2.7/site-packages/billiard/pool.py", line 504, in start super(PoolThread, self).start(*args, **kwargs) File "/home/omer/.virtualenvs/billiard/lib/python2.7/site-packages/billiard/py2/dummy/__init__.py", line 69, in start threading.Thread.start(self) File "/home/omer/.pyenv/versions/2.7.8/lib/python2.7/threading.py", line 750, in start self.__started.wait() File "/home/omer/.pyenv/versions/2.7.8/lib/python2.7/threading.py", line 620, in wait self.__cond.wait(timeout) File "/home/omer/.pyenv/versions/2.7.8/lib/python2.7/threading.py", line 339, in wait waiter.acquire() File "mt_example.py", line 6, in handler print(''.join(traceback.format_stack(frame))) File "mt_example.py", line 10, in p1 = ThreadPool() File "/home/omer/.virtualenvs/billiard/lib/python2.7/site-packages/billiard/pool.py", line 1016, in __init__ self._result_handler.start() File "/home/omer/.virtualenvs/billiard/lib/python2.7/site-packages/billiard/pool.py", line 504, in start super(PoolThread, self).start(*args, **kwargs) File "/home/omer/.virtualenvs/billiard/lib/python2.7/site-packages/billiard/py2/dummy/__init__.py", line 69, in start threading.Thread.start(self) File "/home/omer/.pyenv/versions/2.7.8/lib/python2.7/threading.py", line 750, in start self.__started.wait() File "/home/omer/.pyenv/versions/2.7.8/lib/python2.7/threading.py", line 620, in wait self.__cond.wait(timeout) File "/home/omer/.pyenv/versions/2.7.8/lib/python2.7/threading.py", line 339, in wait waiter.acquire() The following code reproduces that traceback every time: from billiard.pool import ThreadPool import signal def handler(signum, frame): import traceback print(''.join(traceback.format_stack(frame))) signal.signal(signal.SIGTERM, handler) p1 = ThreadPool() class Foo(object): def a(self): print("a") return 1 def do(self): return p1.apply_async(self.a) foo = Foo() r = foo.do() print(r.get()) p1.close() p1.join() I'm convinced that there is a bug somewhere and it seems that Python is the source of the bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 18:54:18 2014 From: report at bugs.python.org (Steve Dower) Date: Sat, 06 Dec 2014 17:54:18 +0000 Subject: [issue22919] Update PCBuild for VS 2015 In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za> Message-ID: <1417888458.96.0.955188580167.issue22919@psf.upfronthosting.co.za> Steve Dower added the comment: Rebased everything onto default and pushed it to my sandbox. ---------- hgrepos: +283 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 18:55:27 2014 From: report at bugs.python.org (Steve Dower) Date: Sat, 06 Dec 2014 17:55:27 +0000 Subject: [issue22919] Update PCBuild for VS 2015 In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za> Message-ID: <1417888527.08.0.34220181316.issue22919@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- hgrepos: -283 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 19:40:20 2014 From: report at bugs.python.org (Steve Dower) Date: Sat, 06 Dec 2014 18:40:20 +0000 Subject: [issue22919] Update PCBuild for VS 2015 In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za> Message-ID: <1417891220.53.0.431880780748.issue22919@psf.upfronthosting.co.za> Steve Dower added the comment: Having trouble getting the patch uploaded... next attempt. ---------- Added file: http://bugs.python.org/file37374/round5complete.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 19:40:34 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 06 Dec 2014 18:40:34 +0000 Subject: [issue9351] argparse set_defaults on subcommands should override top level set_defaults In-Reply-To: <1279894012.43.0.0678646409.issue9351@psf.upfronthosting.co.za> Message-ID: <1417891234.31.0.958149374228.issue9351@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: fixed -> stage: commit review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 19:49:37 2014 From: report at bugs.python.org (Ethan Furman) Date: Sat, 06 Dec 2014 18:49:37 +0000 Subject: [issue23001] Accept mutable bytes-like objects In-Reply-To: <1417875906.64.0.311564166909.issue23001@psf.upfronthosting.co.za> Message-ID: <1417891777.85.0.907934440325.issue23001@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 21:08:16 2014 From: report at bugs.python.org (Clement Rouault) Date: Sat, 06 Dec 2014 20:08:16 +0000 Subject: [issue22939] integer overflow in iterator object In-Reply-To: <1416912993.1.0.671503723984.issue22939@psf.upfronthosting.co.za> Message-ID: <1417896496.07.0.755848796156.issue22939@psf.upfronthosting.co.za> Clement Rouault added the comment: Here is a first try for a patch. There are two points I am not sure about: 1) The message for the OverflowError: is that explicit enough ? 2) The behaviour of the iterator after the raise of OverflowError. With this patch every call to `next(it)` where `it` have overflowed will raise `OverflowError` again. Does this behaviour seems correct our should it raise StopIteration after the first OverflowError ? ---------- keywords: +patch Added file: http://bugs.python.org/file37375/issue22939.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 21:11:39 2014 From: report at bugs.python.org (Steve Dower) Date: Sat, 06 Dec 2014 20:11:39 +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: <1417896699.72.0.657372583636.issue22980@psf.upfronthosting.co.za> Steve Dower added the comment: What can I do to help move this along? It sounds like for Windows builds we could change _imp.extension_suffixes() from ['.pyd'] to ['.{}.pyd'.format(distutils.util.get_platform()), '.pyd'] and update distutils to produce the more specific name (I've got some work to do on distutils anyway for 3.5, so I'm happy to do this part). This would also include somehow hard-coding the get_platform() result into the executable (probably a #define in pyconfig.h) I'm more inclined towards get_platform() than adding new architecture tags. Windows at least doesn't support fat binaries - the closest equivalent is universal apps, which use separate binaries and a naming convention. Adding a debug marker here would also be nice, as I've never been a huge fan of the "_d" suffix we currently have, but it's not a big deal. I suspect any changes here would be completely separate from other platforms, but ISTM that we're looking at a similar change to handle the bitness/debug issue on Linux. I'm not volunteering to do that part :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 21:51:26 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 06 Dec 2014 20:51:26 +0000 Subject: [issue23001] Accept mutable bytes-like objects In-Reply-To: <1417881328.98.0.646919280576.issue23001@psf.upfronthosting.co.za> Message-ID: <1493406.0tBvMFm1VI@raxxla> Serhiy Storchaka added the comment: That is was the patch does. Convert from s# to s* etc. See also issue22896 about potential bugs with the use of pointers to unlocked buffers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 23:09:16 2014 From: report at bugs.python.org (Aivar Annamaa) Date: Sat, 06 Dec 2014 22:09:16 +0000 Subject: [issue23002] Trackpad scrolling in tkinter doesn't work on some laptops Message-ID: <1417903756.15.0.927903848388.issue23002@psf.upfronthosting.co.za> New submission from Aivar Annamaa: Here's a simple tkinter program, where text can be scrolled by mouse wheel, and by trackpads of some laptops (Macbook Pro, Dell Latitude E5430), but not by trackpads of some other laptops (Lenovo T420). from tkinter import Tk from tkinter import scrolledtext window = Tk() text = scrolledtext.ScrolledText(window) text.grid() window.mainloop() ---------- components: Tkinter messages: 232253 nosy: Aivar.Annamaa priority: normal severity: normal status: open title: Trackpad scrolling in tkinter doesn't work on some laptops versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 23:14:16 2014 From: report at bugs.python.org (Aivar Annamaa) Date: Sat, 06 Dec 2014 22:14:16 +0000 Subject: [issue23002] Trackpad scrolling in tkinter doesn't work on some laptops In-Reply-To: <1417903756.15.0.927903848388.issue23002@psf.upfronthosting.co.za> Message-ID: <1417904056.53.0.939720221164.issue23002@psf.upfronthosting.co.za> Aivar Annamaa added the comment: Clarification: In general trackpad scrolling does work on my Lenovo (eg. in Windows Notepad), it just doesn't work in tkinter programs (including IDLE) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 23:22:28 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Sat, 06 Dec 2014 22:22:28 +0000 Subject: [issue23001] Accept mutable bytes-like objects In-Reply-To: <1417875906.64.0.311564166909.issue23001@psf.upfronthosting.co.za> Message-ID: <1417904548.03.0.386841976009.issue23001@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Ah, sorry. Should have examined patch. I thought you were making a change to the behavior of s#, z#, y and y#, not converting actual uses of them. Again, sorry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 23:28:21 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 06 Dec 2014 22:28:21 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <1417896699.72.0.657372583636.issue22980@psf.upfronthosting.co.za> Message-ID: <54838303.8000800@free.fr> Antoine Pitrou added the comment: Le 06/12/2014 21:11, Steve Dower a ?crit : > > I suspect any changes here would be completely separate from other platforms, but ISTM that we're looking at a similar change to handle the bitness/debug issue on Linux. I'm not volunteering to do that part :) I think committing changes on a per-platform basis is fine here. After all the current scheme is quite platform-specific (I was unaware of this until a few days ago :-)). So, yes, let's get the ball rolling under Windows. I think you're the most competent person to choose a naming scheme! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 23:30:48 2014 From: report at bugs.python.org (Zachary Ware) Date: Sat, 06 Dec 2014 22:30:48 +0000 Subject: [issue23002] Trackpad scrolling in tkinter doesn't work on some laptops In-Reply-To: <1417903756.15.0.927903848388.issue23002@psf.upfronthosting.co.za> Message-ID: <1417905048.57.0.648021160899.issue23002@psf.upfronthosting.co.za> Zachary Ware added the comment: Sorry, but there's nothing we can do about it; that will be a Tk issue. I'd suggest discussing it with the Tcl/Tk developers, see http://wiki.tcl.tk/1020 ---------- nosy: +zach.ware resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 6 23:52:01 2014 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 06 Dec 2014 22:52:01 +0000 Subject: [issue22926] asyncio: raise an exception when called from the wrong thread In-Reply-To: <1416760694.74.0.749180510867.issue22926@psf.upfronthosting.co.za> Message-ID: <1417906321.79.0.655360075354.issue22926@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm okay with this approach now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 00:37:27 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 06 Dec 2014 23:37:27 +0000 Subject: [issue23003] traceback.{print_exc, print_exception, format_exc, format_exception}: Potential AttributeError Message-ID: <1417909047.64.0.652633919593.issue23003@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis: Usage of some functions from traceback module can result in AttributeError exception in Python 3, while simply printing/returning something with None in Python 2. This regression was introduced in Python 3.0. $ python2.7 -c 'import traceback; print(traceback.print_exc())' None None $ python2.7 -c 'import traceback; print(traceback.print_exception(None, None, None))' None None $ python2.7 -c 'import traceback; print(traceback.format_exc())' None $ python2.7 -c 'import traceback; print(traceback.format_exception(None, None, None))' ['None\n'] $ python3.5 -c 'import traceback; print(traceback.print_exc())' Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.5/traceback.py", line 252, in print_exc print_exception(*sys.exc_info(), limit=limit, file=file, chain=chain) File "/usr/lib64/python3.5/traceback.py", line 169, in print_exception for line in _format_exception_iter(etype, value, tb, limit, chain): File "/usr/lib64/python3.5/traceback.py", line 146, in _format_exception_iter for value, tb in values: File "/usr/lib64/python3.5/traceback.py", line 125, in _iter_chain context = exc.__context__ AttributeError: 'NoneType' object has no attribute '__context__' $ python3.5 -c 'import traceback; print(traceback.print_exception(None, None, None))' Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.5/traceback.py", line 169, in print_exception for line in _format_exception_iter(etype, value, tb, limit, chain): File "/usr/lib64/python3.5/traceback.py", line 146, in _format_exception_iter for value, tb in values: File "/usr/lib64/python3.5/traceback.py", line 125, in _iter_chain context = exc.__context__ AttributeError: 'NoneType' object has no attribute '__context__' $ python3.5 -c 'import traceback; print(traceback.format_exc())' Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.5/traceback.py", line 256, in format_exc return "".join(format_exception(*sys.exc_info(), limit=limit, chain=chain)) File "/usr/lib64/python3.5/traceback.py", line 181, in format_exception return list(_format_exception_iter(etype, value, tb, limit, chain)) File "/usr/lib64/python3.5/traceback.py", line 146, in _format_exception_iter for value, tb in values: File "/usr/lib64/python3.5/traceback.py", line 125, in _iter_chain context = exc.__context__ AttributeError: 'NoneType' object has no attribute '__context__' $ python3.5 -c 'import traceback; print(traceback.format_exception(None, None, None))' Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.5/traceback.py", line 181, in format_exception return list(_format_exception_iter(etype, value, tb, limit, chain)) File "/usr/lib64/python3.5/traceback.py", line 146, in _format_exception_iter for value, tb in values: File "/usr/lib64/python3.5/traceback.py", line 125, in _iter_chain context = exc.__context__ AttributeError: 'NoneType' object has no attribute '__context__' ---------- messages: 232259 nosy: Arfrever priority: normal severity: normal status: open title: traceback.{print_exc,print_exception,format_exc,format_exception}: Potential AttributeError versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 00:44:58 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 06 Dec 2014 23:44:58 +0000 Subject: [issue23003] traceback.{print_exc, print_exception, format_exc, format_exception}: Potential AttributeError In-Reply-To: <1417909047.64.0.652633919593.issue23003@psf.upfronthosting.co.za> Message-ID: <1417909498.59.0.103653004533.issue23003@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- assignee: -> georg.brandl nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 00:52:48 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 06 Dec 2014 23:52:48 +0000 Subject: [issue22896] Don't use PyObject_As*Buffer() functions In-Reply-To: <1416319375.33.0.739222572648.issue22896@psf.upfronthosting.co.za> Message-ID: <1417909968.65.0.450175967864.issue22896@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 00:52:56 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 06 Dec 2014 23:52:56 +0000 Subject: [issue23001] Accept mutable bytes-like objects In-Reply-To: <1417875906.64.0.311564166909.issue23001@psf.upfronthosting.co.za> Message-ID: <1417909976.35.0.443884439968.issue23001@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 00:58:20 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 06 Dec 2014 23:58:20 +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: <1417910300.23.0.797109348929.issue22153@psf.upfronthosting.co.za> Martin Panter added the comment: Updated patch, which applies to current tip of the default branch, and includes the formatting fix. Also including a version that applies to the 3.4 branch. Alternatively, if you patch the 3.4 branch it looks like merging to default automatically gives the correct result. ---------- Added file: http://bugs.python.org/file37376/runTest2-default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 00:58:33 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 06 Dec 2014 23:58:33 +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: <1417910313.2.0.356004312933.issue22153@psf.upfronthosting.co.za> Changes by Martin Panter : Added file: http://bugs.python.org/file37377/runTest2-3.4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 01:29:54 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 07 Dec 2014 00:29:54 +0000 Subject: [issue22696] Add a function to know about interpreter shutdown In-Reply-To: <1413980453.04.0.451789079104.issue22696@psf.upfronthosting.co.za> Message-ID: <20141207002951.76708.29469@psf.io> Roundup Robot added the comment: New changeset 7f3695701724 by Antoine Pitrou in branch 'default': Issue #22696: Add function :func:`sys.is_finalizing` to know about interpreter shutdown. https://hg.python.org/cpython/rev/7f3695701724 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 01:30:35 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 07 Dec 2014 00:30:35 +0000 Subject: [issue22696] Add a function to know about interpreter shutdown In-Reply-To: <1413980453.04.0.451789079104.issue22696@psf.upfronthosting.co.za> Message-ID: <1417912235.66.0.132532587965.issue22696@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Using the function in the stdlib can be done separately. I fixed the typo in the docstring. Thanks! ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 02:11:49 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 07 Dec 2014 01:11:49 +0000 Subject: [issue22982] BOM incorrectly inserted before writing, after seeking in text file In-Reply-To: <1417538502.93.0.814458445398.issue22982@psf.upfronthosting.co.za> Message-ID: <1417914709.78.0.438908308213.issue22982@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch. ---------- keywords: +patch stage: -> patch review versions: +Python 3.5 Added file: http://bugs.python.org/file37378/bom_seek_append.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 02:40:28 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 07 Dec 2014 01:40:28 +0000 Subject: [issue23001] Accept mutable bytes-like objects In-Reply-To: <1417875906.64.0.311564166909.issue23001@psf.upfronthosting.co.za> Message-ID: <1417916428.43.0.275114481867.issue23001@psf.upfronthosting.co.za> Antoine Pitrou added the comment: +1 on the principle. I haven't looked at the patch. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 02:42:57 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 07 Dec 2014 01:42:57 +0000 Subject: [issue22992] Adding a git developer's guide to Mercurial to devguide In-Reply-To: <1417651753.19.0.905189748743.issue22992@psf.upfronthosting.co.za> Message-ID: <1417916577.13.0.531690129952.issue22992@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I was going to say I'm skeptical that we need this but the proposed text is well researched and well written (I'll probably learn something about bookmarks myself, actually). Kudos! ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 04:34:07 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 07 Dec 2014 03:34:07 +0000 Subject: [issue20603] sys.path disappears at shutdown In-Reply-To: <1392146740.92.0.319556816065.issue20603@psf.upfronthosting.co.za> Message-ID: <1417923247.83.0.092860587551.issue20603@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 04:38:36 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 07 Dec 2014 03:38:36 +0000 Subject: [issue22696] Add a function to know about interpreter shutdown In-Reply-To: <1413980453.04.0.451789079104.issue22696@psf.upfronthosting.co.za> Message-ID: <1417923516.5.0.786329951915.issue22696@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 07:48:18 2014 From: report at bugs.python.org (Steve Dower) Date: Sun, 07 Dec 2014 06:48:18 +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: <1417934898.84.0.807250709146.issue22980@psf.upfronthosting.co.za> Steve Dower added the comment: The attached patch adds platform tags for .pyd files for "win32", "win-arm", "win-amd64" and "win-ia64", which are the known compilers in pyconfig.h and the potential return values from distutils.util.get_platform(). It also fixes a bug where the suffix would be incorrect if building a debug extension. I haven't been able to think of any scenarios where this could break other than perhaps packaging (since distutils defaults to including the tag), and we've got plenty of time to sort those issues out. A quick test installing Cython and some packages built with Cython seemed to be fine. AIUI, MinGW/cygwin builds won't use PC/pyconfig.h, and so they won't see any change. ---------- keywords: +patch Added file: http://bugs.python.org/file37379/22980_windows.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 09:44:12 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 07 Dec 2014 08:44:12 +0000 Subject: [issue22939] integer overflow in iterator object In-Reply-To: <1417896496.07.0.755848796156.issue22939@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: You should not rely on undefined behaviour: check if the index is greater or equal than PY_SSIZET_MAX - 1. __setstate__ must implement the same check. You must always raise an error, not hide it in a second call to next (raise StopIteration). Your unit test must check this behaviour. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 09:51:06 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 07 Dec 2014 08:51:06 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <1417934898.84.0.807250709146.issue22980@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Why not using on Windows the same naming scheme than Unix. It may be useful to also add the debug flag (d) in the name for example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 10:20:21 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 07 Dec 2014 09:20:21 +0000 Subject: [issue22939] integer overflow in iterator object In-Reply-To: <1416912993.1.0.671503723984.issue22939@psf.upfronthosting.co.za> Message-ID: <1417944021.58.0.283685560103.issue22939@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > check if the index is greater or equal than PY_SSIZET_MAX - 1. Just PY_SSIZET_MAX. Added other comments on Rietveld (look the email in the Spam folder). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 15:07:05 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 07 Dec 2014 14:07:05 +0000 Subject: [issue23003] traceback.{print_exc, print_exception, format_exc, format_exception}: Potential AttributeError In-Reply-To: <1417909047.64.0.652633919593.issue23003@psf.upfronthosting.co.za> Message-ID: <1417961225.08.0.116284940844.issue23003@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +patch nosy: +berker.peksag stage: -> patch review type: -> behavior Added file: http://bugs.python.org/file37380/issue23003.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 15:18:11 2014 From: report at bugs.python.org (Steve Dower) Date: Sun, 07 Dec 2014 14:18:11 +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: <1417961891.55.0.218956126149.issue22980@psf.upfronthosting.co.za> Steve Dower added the comment: > Why not using on Windows the same naming scheme than Unix. > It may be useful to also add the debug flag (d) in the name for example. Windows already puts the debug flag in the name, the fact that it's CPython is in the .pyd extension, and the version number is in the directory for all the standard sys.path locations. Platform is the only variable unaccounted for. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 16:24:17 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sun, 07 Dec 2014 15:24:17 +0000 Subject: [issue23004] mock_open() should allow reading binary data Message-ID: <1417965857.24.0.521739131396.issue23004@psf.upfronthosting.co.za> New submission from Jes?s Cea Avi?n: mock_open(read_data=b'...') gives an error: """Traceback (most recent call last): File "z.py", line 6, in print(f.read()) File "/usr/local/lib/python3.4/unittest/mock.py", line 896, in __call__ return _mock_self._mock_call(*args, **kwargs) File "/usr/local/lib/python3.4/unittest/mock.py", line 962, in _mock_call ret_val = effect(*args, **kwargs) File "/usr/local/lib/python3.4/unittest/mock.py", line 2279, in _read_side_effect return ''.join(_data) File "/usr/local/lib/python3.4/unittest/mock.py", line 2244, in _iterate_read_data data_as_list = ['{}\n'.format(l) for l in read_data.split('\n')] """ Easy to reproduce: """ from unittest.mock import mock_open, patch m = mock_open(read_data= b'abc') with patch('__main__.open', m, create=True) : with open('abc', 'rb') as f : print(f.read()) """ Looks like this bug was introduced as result of issue #17467. I add those people to the nosy list. ---------- keywords: easy messages: 232271 nosy: a.badger, jcea, michael.foord priority: normal severity: normal status: open title: mock_open() should allow reading binary data versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 16:25:42 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sun, 07 Dec 2014 15:25:42 +0000 Subject: [issue17467] Enhancement: give mock_open readline() and readlines() methods In-Reply-To: <1363637353.75.0.10594649772.issue17467@psf.upfronthosting.co.za> Message-ID: <1417965942.09.0.919416776001.issue17467@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- superseder: -> mock_open() should allow reading binary data _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 16:25:59 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sun, 07 Dec 2014 15:25:59 +0000 Subject: [issue23004] mock_open() should allow reading binary data In-Reply-To: <1417965857.24.0.521739131396.issue23004@psf.upfronthosting.co.za> Message-ID: <1417965959.55.0.292636336858.issue23004@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- dependencies: +Enhancement: give mock_open readline() and readlines() methods _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 17:02:33 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 07 Dec 2014 16:02:33 +0000 Subject: [issue23003] traceback.{print_exc, print_exception, format_exc, format_exception}: Potential AttributeError In-Reply-To: <1417909047.64.0.652633919593.issue23003@psf.upfronthosting.co.za> Message-ID: <1417968153.6.0.643146144131.issue23003@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 17:09:22 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 07 Dec 2014 16:09:22 +0000 Subject: [issue23004] mock_open() should allow reading binary data In-Reply-To: <1417965857.24.0.521739131396.issue23004@psf.upfronthosting.co.za> Message-ID: <1417968562.5.0.0459061418365.issue23004@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> needs patch type: -> behavior versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 17:53:57 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 07 Dec 2014 16:53:57 +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: <1417971237.79.0.138130951717.issue22980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Windows already puts the debug flag in the name, the fact that it's > CPython is in the .pyd extension, and the version number is in the > directory for all the standard sys.path locations. The version number would be useful for in-place builds (i.e. when developping), but the patch is still a nice step forward. Could you perhaps add some tests (e.g. in test_distutils)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 19:47:34 2014 From: report at bugs.python.org (Martin Matusiak) Date: Sun, 07 Dec 2014 18:47:34 +0000 Subject: [issue23005] typos on heapq doc Message-ID: <1417978054.94.0.0217424241667.issue23005@psf.upfronthosting.co.za> New submission from Martin Matusiak: - which are pre-sorted sequences, which size is usually related to the amount of CPU memory whose size - Tournaments are a good way to that. Tournaments are a good way to achieve that. ---------- components: Library (Lib) files: heapq_docs_typos.diff keywords: patch messages: 232273 nosy: ned.deily, numerodix priority: normal severity: normal status: open title: typos on heapq doc type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37381/heapq_docs_typos.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 19:47:49 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 07 Dec 2014 18:47:49 +0000 Subject: [issue22959] http.client.HTTPSConnection checks hostname when SSL context has check_hostname==False In-Reply-To: <1417117359.84.0.965866100579.issue22959@psf.upfronthosting.co.za> Message-ID: <20141207184747.27509.21943@psf.io> Roundup Robot added the comment: New changeset a409a7cd908d by Benjamin Peterson in branch '3.4': HTTPSConnection: prefer the context's check_hostname attribute over the constructor parameter (#22959) https://hg.python.org/cpython/rev/a409a7cd908d New changeset 41021c771510 by Benjamin Peterson in branch '2.7': remove HTTPSConnection's check_hostname parameter (#22959) https://hg.python.org/cpython/rev/41021c771510 New changeset ee095a2e2b35 by Benjamin Peterson in branch 'default': merge 3.4 (#22959) https://hg.python.org/cpython/rev/ee095a2e2b35 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 19:49:12 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 07 Dec 2014 18:49:12 +0000 Subject: [issue22959] http.client.HTTPSConnection checks hostname when SSL context has check_hostname==False In-Reply-To: <1417117359.84.0.965866100579.issue22959@psf.upfronthosting.co.za> Message-ID: <1417978152.8.0.238054005092.issue22959@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Okay, I basically applied my patch to 3.4/3.5. I simply removed the check_hostname parameter from 2.7, since it was to be added in 2.7.9. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 19:54:32 2014 From: report at bugs.python.org (Ned Deily) Date: Sun, 07 Dec 2014 18:54:32 +0000 Subject: [issue23005] typos on heapq doc In-Reply-To: <1417978054.94.0.0217424241667.issue23005@psf.upfronthosting.co.za> Message-ID: <1417978472.21.0.467770180815.issue23005@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- assignee: -> docs at python components: +Documentation -Library (Lib) nosy: +docs at python -ned.deily versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 20:00:29 2014 From: report at bugs.python.org (Brett Cannon) Date: Sun, 07 Dec 2014 19:00:29 +0000 Subject: [issue20603] sys.path disappears at shutdown In-Reply-To: <1392146740.92.0.319556816065.issue20603@psf.upfronthosting.co.za> Message-ID: <1417978829.1.0.211974369824.issue20603@psf.upfronthosting.co.za> Brett Cannon added the comment: Since issue #19255 is closed is this still an issue, Antoine? ---------- assignee: -> pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 20:05:14 2014 From: report at bugs.python.org (Steve Dower) Date: Sun, 07 Dec 2014 19:05:14 +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: <1417979114.54.0.266381942482.issue22980@psf.upfronthosting.co.za> Steve Dower added the comment: > The version number would be useful for in-place builds (i.e. when developping) Ah, I see now how that would be useful (I haven't tried to deal with that before). I'll revise the patch to use/allow the version number. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 20:12:25 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 07 Dec 2014 19:12:25 +0000 Subject: [issue20603] sys.path disappears at shutdown In-Reply-To: <1392146740.92.0.319556816065.issue20603@psf.upfronthosting.co.za> Message-ID: <1417979545.1.0.532882671875.issue20603@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't know. Not for issue #19255 obviously, so we can probably close :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 21:02:51 2014 From: report at bugs.python.org (Ethan Furman) Date: Sun, 07 Dec 2014 20:02:51 +0000 Subject: [issue9536] defaultdict doc makes incorrect reference to __missing__ method In-Reply-To: <1281106528.37.0.0435364267174.issue9536@psf.upfronthosting.co.za> Message-ID: <1417982571.93.0.00103089846856.issue9536@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 21:49:30 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 07 Dec 2014 20:49:30 +0000 Subject: [issue23006] Improve the doc and indexing of adict.__missing__. Message-ID: <1417985369.96.0.326358204226.issue23006@psf.upfronthosting.co.za> New submission from Terry J. Reedy: Currently, the only index entry for __missing__ is "__missing__() (collections.defaultdict method)". This entry should probably not exist -- see #9536, which inspired this issue. The method is not mentioned in the special-methods doc, and the explanation in the dict doc is not indexed. Two suggestions: https://docs.python.org/3/reference/datamodel.html#emulating-container-types After __getitem__ entry, add automatically indexed entry, something like object.__missing__(self, key): When present in a dict subclass, called by dict.__getitem__ for missing keys. https://docs.python.org/3/library/stdtypes.html#mapping-types-dict Before the d[key] paragraph starting "If a subclass of dict defines a method __missing__()" add explicit __missing__ index directive. The last sentence of the paragraph "See collections.Counter for a complete implementation including other methods helpful for accumulating and managing tallies." is confusing because the linked entry makes no mention of __missing__ (as it should not). Change sentence to something like "There are two stdlib dict subclasses that use (different) __missing__ methods as part of their implementation: collections.Counter and collections.defaultdict." I will work on a patch and try to get the markup correct. ---------- assignee: docs at python components: Documentation messages: 232279 nosy: docs at python, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Improve the doc and indexing of adict.__missing__. type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 21:54:59 2014 From: report at bugs.python.org (David Watson) Date: Sun, 07 Dec 2014 20:54:59 +0000 Subject: [issue9647] os.confstr() does not handle value changing length between calls In-Reply-To: <1417816810.39.0.368499544739.issue9647@psf.upfronthosting.co.za> Message-ID: <20141207205501.GA7040@dbwatson.uk7.net> David Watson added the comment: On Fri 5 Dec 2014, STINNER Victor wrote: > I added an assertion. Can we close this issue? Well, if no one complains about the interpreter dying with SIGABRT, that will suggest that the worries about OS bugs creating infinite loops were unfounded :) If you do want to leave this open, I can provide patches based on the original one from issue #9579. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 22:02:30 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 07 Dec 2014 21:02:30 +0000 Subject: [issue9536] defaultdict doc makes incorrect reference to __missing__ method In-Reply-To: <1281106528.37.0.0435364267174.issue9536@psf.upfronthosting.co.za> Message-ID: <1417986150.74.0.497588278431.issue9536@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I agree that the patch is not acceptable as is. The public attribute *defaultdict* should be explicitly documented as it is now, so that it is indexed. On the other hand, users should not directly call .__missing__, and it is not normal to document the private special method implementation of classes. For example, a collections.Counter returns 0 for missing keys but the doc makes no mention of .__missing__ as the implementation. It simply describe how a counter works. John is correct that people writing other subclasses with __missing__ should usually subclass dict. This might be clearer if that special method were properly documented and indexed. I opened #23006 for this. ---------- nosy: +terry.reedy resolution: not a bug -> stage: resolved -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 22:26:59 2014 From: report at bugs.python.org (Clement Rouault) Date: Sun, 07 Dec 2014 21:26:59 +0000 Subject: [issue22939] integer overflow in iterator object In-Reply-To: <1416912993.1.0.671503723984.issue22939@psf.upfronthosting.co.za> Message-ID: <1417987619.48.0.191261477246.issue22939@psf.upfronthosting.co.za> Clement Rouault added the comment: Thanks for the comments. I corrected the patch and updated the test. I also added a test that check the behavior of setstate with negative indice. Just one question: > __setstate__ must implement the same check. Why should __setstate__ check for PY_SSIZE_T_MAX (throwing OverflowError when unpickling) if the check will be done when calling next on the resulting iterator ? ---------- Added file: http://bugs.python.org/file37382/issue22939v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 22:27:48 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 07 Dec 2014 21:27:48 +0000 Subject: [issue9647] os.confstr() does not handle value changing length between calls In-Reply-To: <1282243493.08.0.1214343728.issue9647@psf.upfronthosting.co.za> Message-ID: <1417987668.88.0.424426177041.issue9647@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't think that assert() is appropriate solution here. assert() is used to check internal logic, it shouldn't check conditions which rely on external world. Raising RuntimeError looks more appropriate to me. ---------- versions: -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 22:31:54 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 07 Dec 2014 21:31:54 +0000 Subject: [issue22939] integer overflow in iterator object In-Reply-To: <1416912993.1.0.671503723984.issue22939@psf.upfronthosting.co.za> Message-ID: <1417987914.36.0.296317209516.issue22939@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: __setstate__ should check that an index is not negative. All values from 0 to PY_SSIZE_T_MAX are acceptable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 22:39:01 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 07 Dec 2014 21:39:01 +0000 Subject: [issue22939] integer overflow in iterator object In-Reply-To: <1416912993.1.0.671503723984.issue22939@psf.upfronthosting.co.za> Message-ID: <1417988341.9.0.201366180703.issue22939@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ah, __setstate__ already handles negative indices. Then the patch LGTM. ---------- stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 23:07:33 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 07 Dec 2014 22:07:33 +0000 Subject: [issue23006] Improve the doc and indexing of adict.__missing__. In-Reply-To: <1417985369.96.0.326358204226.issue23006@psf.upfronthosting.co.za> Message-ID: <1417990053.94.0.0172707439696.issue23006@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- keywords: +patch Added file: http://bugs.python.org/file37383/__missing__.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 23:17:54 2014 From: report at bugs.python.org (Ethan Furman) Date: Sun, 07 Dec 2014 22:17:54 +0000 Subject: [issue23006] Improve the doc and indexing of adict.__missing__. In-Reply-To: <1417985369.96.0.326358204226.issue23006@psf.upfronthosting.co.za> Message-ID: <1417990674.03.0.133514558212.issue23006@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 7 23:43:11 2014 From: report at bugs.python.org (Sergey Litvinov) Date: Sun, 07 Dec 2014 22:43:11 +0000 Subject: [issue23007] Unnecessary big intermediate result in Lib/bisect.py Message-ID: <1417992191.21.0.852637765732.issue23007@psf.upfronthosting.co.za> New submission from Sergey Litvinov: Bisection algorithms use mid = (lo+hi)//2 Textbook formula is mid = (hi-lo)//2 + lo See http://en.wikipedia.org/w/index.php?title=Binary_search_algorithm&oldid=634658510#Arithmetic For "vanilla" lists and integers it is not a problem but one can run into troubles with user defined types. ---------- components: Library (Lib) messages: 232286 nosy: Sergey.Litvinov priority: normal severity: normal status: open title: Unnecessary big intermediate result in Lib/bisect.py type: behavior versions: Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 00:00:58 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 07 Dec 2014 23:00:58 +0000 Subject: [issue1225584] crash in gcmodule.c on python reinitialization Message-ID: <1417993258.23.0.339414926272.issue1225584@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am closing since the initial problem has been fixed and there is no known current problem to fix. If someone does discover one, they can reopen or, probably better, open a new issue. ---------- resolution: -> fixed stage: test needed -> resolved status: languishing -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 00:09:53 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 07 Dec 2014 23:09:53 +0000 Subject: [issue1425127] os.remove OSError: [Errno 13] Permission denied Message-ID: <1417993793.79.0.613461544022.issue1425127@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> out of date stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 00:30:34 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 07 Dec 2014 23:30:34 +0000 Subject: [issue18305] [patch] Fast sum() for non-numbers In-Reply-To: <1372228439.5.0.789865081817.issue18305@psf.upfronthosting.co.za> Message-ID: <1417995034.24.0.00695418818667.issue18305@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Sergey, please stop calling the current documented behavior a bug. https://docs.python.org/3/library/functions.html#sum says 'The iterable?s items are normally numbers ... To concatenate a series of iterables, consider using itertools.chain(). To make a change, there must be discussion and approval on python-ideas, including by Guido. I believe that GvR's rejection of optimizing for strings covers optimizing for other sequences. If you want to continue, make a pep-like post there that summarizes the discussion here and makes your current proposal. ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 00:34:06 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 07 Dec 2014 23:34:06 +0000 Subject: [issue19451] urlparse accepts invalid hostnames In-Reply-To: <1383138962.68.0.105445419369.issue19451@psf.upfronthosting.co.za> Message-ID: <1417995246.75.0.373313690971.issue19451@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 00:36:37 2014 From: report at bugs.python.org (zodalahtathi) Date: Sun, 07 Dec 2014 23:36:37 +0000 Subject: [issue22959] http.client.HTTPSConnection checks hostname when SSL context has check_hostname==False In-Reply-To: <1417117359.84.0.965866100579.issue22959@psf.upfronthosting.co.za> Message-ID: <1417995397.53.0.296556562795.issue22959@psf.upfronthosting.co.za> zodalahtathi added the comment: Thank you ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 00:42:22 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 07 Dec 2014 23:42:22 +0000 Subject: [issue19846] Python 3 raises Unicode errors with the C locale In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za> Message-ID: <1417995742.55.0.220746966345.issue19846@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Since Viktor's alternative in #19977 has been applied, should this issue be closed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 00:47:52 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 07 Dec 2014 23:47:52 +0000 Subject: [issue20866] segfailt with os.popen and SIGPIPE In-Reply-To: <1394216549.17.0.426654108401.issue20866@psf.upfronthosting.co.za> Message-ID: <1417996072.55.0.446498926557.issue20866@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Does anyone disagree with closing this as Won't fix'? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 00:51:54 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 07 Dec 2014 23:51:54 +0000 Subject: [issue20895] Add bytes.empty_buffer and deprecate bytes(17) for the same purpose In-Reply-To: <1394620197.12.0.249138601017.issue20895@psf.upfronthosting.co.za> Message-ID: <1417996314.91.0.527400781884.issue20895@psf.upfronthosting.co.za> Terry J. Reedy added the comment: May we close this as superceded by pep467? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 01:02:47 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 08 Dec 2014 00:02:47 +0000 Subject: [issue21427] Windows installer: cannot register 64 bit component In-Reply-To: <1399217925.98.0.594848268677.issue21427@psf.upfronthosting.co.za> Message-ID: <1417996967.78.0.931643295561.issue21427@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am following Martin's suggestion that there is no actionable issue here and that new issues be opened with new details if and when available. ---------- components: +Installation, Windows resolution: -> third party stage: -> resolved status: open -> closed type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 01:07:09 2014 From: report at bugs.python.org (Ethan Furman) Date: Mon, 08 Dec 2014 00:07:09 +0000 Subject: [issue20895] Add bytes.empty_buffer and deprecate bytes(17) for the same purpose In-Reply-To: <1394620197.12.0.249138601017.issue20895@psf.upfronthosting.co.za> Message-ID: <1417997229.23.0.316700276848.issue20895@psf.upfronthosting.co.za> Ethan Furman added the comment: Superseded by PEP467. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 01:16:43 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 08 Dec 2014 00:16:43 +0000 Subject: [issue9882] abspath from directory In-Reply-To: <1284682917.39.0.650396347526.issue9882@psf.upfronthosting.co.za> Message-ID: <1417997803.31.0.456820394367.issue9882@psf.upfronthosting.co.za> Terry J. Reedy added the comment: https://mail.python.org/pipermail/python-ideas/2014-July/028382.html is the thread. No surge of support. ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 01:42:59 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 08 Dec 2014 00:42:59 +0000 Subject: [issue23007] Unnecessary big intermediate result in Lib/bisect.py In-Reply-To: <1417992191.21.0.852637765732.issue23007@psf.upfronthosting.co.za> Message-ID: <1417999379.47.0.908801961159.issue23007@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +mark.dickinson, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 02:26:35 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 08 Dec 2014 01:26:35 +0000 Subject: [issue20866] segfailt with os.popen and SIGPIPE In-Reply-To: <1394216549.17.0.426654108401.issue20866@psf.upfronthosting.co.za> Message-ID: <1418001995.3.0.77790350455.issue20866@psf.upfronthosting.co.za> R. David Murray added the comment: I agree it should be closed. "Rewrite the IO system" was done, and it was even backported to 2.x...it just isn't the default there. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 06:09:27 2014 From: report at bugs.python.org (Steve Dower) Date: Mon, 08 Dec 2014 05:09:27 +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: <1418015367.95.0.333560964558.issue22980@psf.upfronthosting.co.za> Steve Dower added the comment: Added "cp35" (and later "cp36", etc.) to the tag, so now it looks similar to PEP 425 without the ABI tag (ironically, since there's fundamentally no difference between the Python version and the ABI). "cp3" is also accepted for stable ABI extensions that still need a platform specifier. distutils will always build extensions with the most specific tag, which I believe is best. If you want a different tag, then you currently need to do the build manually (unless there's a way to override the suffix distutils/setuptools uses? It didn't look like an obvious option) I also added the tag into the stdlib pyds. This is kind of nice, but not really necessary. We don't (and probably can't) tag python.exe and python35.dll, so there's no opportunity to install different version/platform interpreters in the same directory anyway. It's a trivial change to remove, though it does further help test the mechanism (along with an importlib test to validate the tag value). Example names with tags: spam.cp35-win_amd64.pyd spam_d.cp35-win32.pyd spam.cp3-win32.pyd ---------- Added file: http://bugs.python.org/file37384/22980_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 07:04:08 2014 From: report at bugs.python.org (Antony Lee) Date: Mon, 08 Dec 2014 06:04:08 +0000 Subject: [issue23008] pydoc enum.{,Int}Enum fails Message-ID: <1418018648.34.0.0967171282391.issue23008@psf.upfronthosting.co.za> New submission from Antony Lee: Not a big deal, but "$ pydoc enum.Enum" and "$ pydoc enum.IntEnum" fail to retrieve the docstrings, while they are visible with "$ pydoc enum". ---------- components: Library (Lib) messages: 232298 nosy: Antony.Lee priority: normal severity: normal status: open title: pydoc enum.{,Int}Enum fails versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 10:32:49 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 08 Dec 2014 09:32:49 +0000 Subject: [issue23007] Unnecessary big intermediate result in Lib/bisect.py In-Reply-To: <1417992191.21.0.852637765732.issue23007@psf.upfronthosting.co.za> Message-ID: <1418031169.34.0.301273842431.issue23007@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What troubles? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 11:36:45 2014 From: report at bugs.python.org (Alexey Poryadin) Date: Mon, 08 Dec 2014 10:36:45 +0000 Subject: [issue23009] selectors.EpollSelector.select raises exception when nothing to select. Message-ID: <1418035005.39.0.294462650059.issue23009@psf.upfronthosting.co.za> New submission from Alexey Poryadin: When is called `select`, but registered no one `fileobject` rise exception: ... polled = self._selector.select(timeout) File "/usr/lib/python3.4/selectors.py", line 424, in select fd_event_list = self._epoll.poll(timeout, max_ev) ValueError: maxevents must be greater than 0, got 0 Of course, it makes no sense to call `select` if there is nothing to watch. But "select.epol.poll" is not raises exception in the same case if `max_ev`=-1. And this simplifies the application code and is useful if need just sleep for a timeout. So, I suggest a small fix: - fd_event_list = self._epoll.poll(timeout, max_ev) + fd_event_list = self._epoll.poll(timeout, max_ev or -1) ---------- messages: 232300 nosy: Alexey.Poryadin priority: normal severity: normal status: open title: selectors.EpollSelector.select raises exception when nothing to select. type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 11:40:47 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 08 Dec 2014 10:40:47 +0000 Subject: [issue23009] selectors.EpollSelector.select raises exception when nothing to select. In-Reply-To: <1418035005.39.0.294462650059.issue23009@psf.upfronthosting.co.za> Message-ID: <1418035247.11.0.149841304695.issue23009@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo, neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 11:40:53 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 08 Dec 2014 10:40:53 +0000 Subject: [issue23009] selectors.EpollSelector.select raises exception when nothing to select. In-Reply-To: <1418035005.39.0.294462650059.issue23009@psf.upfronthosting.co.za> Message-ID: <1418035253.34.0.507401122642.issue23009@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 11:40:59 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 08 Dec 2014 10:40:59 +0000 Subject: [issue23009] selectors.EpollSelector.select raises exception when nothing to select. In-Reply-To: <1418035005.39.0.294462650059.issue23009@psf.upfronthosting.co.za> Message-ID: <1418035259.94.0.957983117569.issue23009@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- components: +asyncio nosy: +gvanrossum, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 12:20:24 2014 From: report at bugs.python.org (Martin Richard) Date: Mon, 08 Dec 2014 11:20:24 +0000 Subject: [issue21998] asyncio: a new self-pipe should be created in the child process after fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1418037624.89.0.273221676807.issue21998@psf.upfronthosting.co.za> Martin Richard added the comment: Currently, this is what I do in the child after the fork: >>> selector = loop._selector >>> parent_class = selector.__class__.__bases__[0] >>> selector.unregister = lambda fd: parent_class.unregister(selector, fd) It replaces unregister() by _BaseSelectorImpl.unregister(), so "our" data structures are still cleaned (the dict _fd_to_key, for instance). If a fix for this issue is desired in tulip, the first solution proposed by Guido (closing the selector and let the unregister call fail, see the -trivial- patch attached) is probably good enough. ---------- keywords: +patch Added file: http://bugs.python.org/file37385/close_self_pipe_after_selector.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 14:46:55 2014 From: report at bugs.python.org (Walter Doekes) Date: Mon, 08 Dec 2014 13:46:55 +0000 Subject: [issue23010] "unclosed file" warning when defining unused logging FileHandler in dictConfig Message-ID: <1418046415.01.0.116582999558.issue23010@psf.upfronthosting.co.za> New submission from Walter Doekes: If you define a FileHandler in your logging dictConfig but fail to use it in the same configuration, the file handle is leaked and a ResourceWarning is thrown. Versions: $ python3 -V Python 3.4.0 $ apt-cache show python3.4 | grep ^Version Version: 3.4.0-2ubuntu1 Expected: $ PYTHONWARNINGS="default,ignore::DeprecationWarning" \ python3 problem.py imported once Observed: $ PYTHONWARNINGS="default,ignore::DeprecationWarning" \ python3 problem.py .../lib/python3.4/importlib/_bootstrap.py:656: ResourceWarning: unclosed file <_io.FileIO name='/tmp/debug.log' mode='ab'> code = marshal.loads(data) imported once To reproduce, save below as problem.py: if __name__ == '__main__': LOGGING = { 'version': 1, 'handlers': { 'logfile': { 'level': 'DEBUG', 'class': 'logging.FileHandler', 'filename': '/tmp/debug.log', }, }, } from logging.config import dictConfig dictConfig(LOGGING) # using importlib on a new file triggers the warnings import importlib, shutil, os shutil.copy(__file__, __file__ + '.new') os.unlink(__file__) os.rename(__file__ + '.new', __file__) importlib.import_module('problem') else: print('imported once') Fixed by: --- /usr/lib/python3.4/logging/config.py.orig 2014-12-08 14:06:24.911460799 +0100 +++ /usr/lib/python3.4/logging/config.py 2014-12-08 14:16:17.519460799 +0100 @@ -637,6 +637,16 @@ class DictConfigurator(BaseConfigurator) except Exception as e: raise ValueError('Unable to configure root ' 'logger: %s' % e) + + # Close unused loggers + used_handlers = set() + for logger in logging.root.manager.loggerDict.values(): + if hasattr(logger, 'handlers') and logger.handlers: + used_handlers.add(*logger.handlers) + for name, handler in handlers.items(): + if handler not in used_handlers: + if hasattr(handler, 'close'): + handler.close() finally: logging._releaseLock() The fix above might not be the best fix, but it proves where the problem is. Perhaps the handlers shouldn't be instantiated until the first user of such a handler is instantiated. This issue was found by using Django 1.7 with Python 3.4 when enabling the PYTHONWARNINGS. Cheers, Walter Doekes OSSO B.V. ---------- components: Library (Lib) messages: 232302 nosy: wdoekes priority: normal severity: normal status: open title: "unclosed file" warning when defining unused logging FileHandler in dictConfig versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 15:08:55 2014 From: report at bugs.python.org (berndca) Date: Mon, 08 Dec 2014 14:08:55 +0000 Subject: [issue23011] Duplicate Paragraph in documentation for json module Message-ID: <1418047735.37.0.83441849339.issue23011@psf.upfronthosting.co.za> New submission from berndca: There is a duplication of the first section of 18.2.2 (JSON) Encoders and Decoders of the python 2.7.9RC1 doc as well of the corresponding paragraph in 19.2.2 of the Python 3 docs. ---------- assignee: docs at python components: Documentation messages: 232303 nosy: berndca, docs at python priority: normal severity: normal status: open title: Duplicate Paragraph in documentation for json module type: enhancement versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 15:20:10 2014 From: report at bugs.python.org (Simeon Visser) Date: Mon, 08 Dec 2014 14:20:10 +0000 Subject: [issue23011] Duplicate Paragraph in documentation for json module In-Reply-To: <1418047735.37.0.83441849339.issue23011@psf.upfronthosting.co.za> Message-ID: <1418048410.64.0.955397709896.issue23011@psf.upfronthosting.co.za> Simeon Visser added the comment: What paragraph are you referring to? Various documented parameters are similar but I don't see duplicate paragraphs. ---------- nosy: +simeon.visser _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 15:25:34 2014 From: report at bugs.python.org (Trent Nelson) Date: Mon, 08 Dec 2014 14:25:34 +0000 Subject: [issue18835] Add aligned memory variants to the suite of PyMem functions/macros In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za> Message-ID: <1418048734.23.0.309038806848.issue18835@psf.upfronthosting.co.za> Changes by Trent Nelson : ---------- nosy: +trent _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 15:26:18 2014 From: report at bugs.python.org (Armin Rigo) Date: Mon, 08 Dec 2014 14:26:18 +0000 Subject: [issue23012] RuntimeError: settrace/setprofile function gets lost Message-ID: <1418048778.92.0.0497543506697.issue23012@psf.upfronthosting.co.za> New submission from Armin Rigo: It's not possible to write a settrace() or setprofile() function that remains active if we're about to run out of stack. If we are, we get a RuntimeError when the function is called. The RuntimeError is normally propagated, but in case it is eaten (e.g. see example) then the program continues to run normally --- but the trace/profile function is disabled from now on. ---------- files: test9.py messages: 232305 nosy: arigo priority: normal severity: normal status: open title: RuntimeError: settrace/setprofile function gets lost type: behavior Added file: http://bugs.python.org/file37386/test9.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 15:29:37 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 08 Dec 2014 14:29:37 +0000 Subject: [issue23012] RuntimeError: settrace/setprofile function gets lost In-Reply-To: <1418048778.92.0.0497543506697.issue23012@psf.upfronthosting.co.za> Message-ID: <1418048977.21.0.359816157425.issue23012@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 16:36:05 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 08 Dec 2014 15:36:05 +0000 Subject: [issue23010] "unclosed file" warning when defining unused logging FileHandler in dictConfig In-Reply-To: <1418046415.01.0.116582999558.issue23010@psf.upfronthosting.co.za> Message-ID: <1418052965.51.0.599919229933.issue23010@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 16:36:51 2014 From: report at bugs.python.org (Brett Cannon) Date: Mon, 08 Dec 2014 15:36:51 +0000 Subject: [issue20603] sys.path disappears at shutdown In-Reply-To: <1392146740.92.0.319556816065.issue20603@psf.upfronthosting.co.za> Message-ID: <1418053011.62.0.523955103303.issue20603@psf.upfronthosting.co.za> Brett Cannon added the comment: That's enough reason for me to close this as out of date. =) ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 16:42:47 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 08 Dec 2014 15:42:47 +0000 Subject: [issue23009] selectors.EpollSelector.select raises exception when nothing to select. In-Reply-To: <1418035005.39.0.294462650059.issue23009@psf.upfronthosting.co.za> Message-ID: <1418053367.27.0.0243663395394.issue23009@psf.upfronthosting.co.za> Yury Selivanov added the comment: Patch attached. Tests pass on Linux. ---------- keywords: +patch Added file: http://bugs.python.org/file37387/epoll_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 16:47:57 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 08 Dec 2014 15:47:57 +0000 Subject: [issue21998] asyncio: a new self-pipe should be created in the child process after fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1418053677.9.0.333193760937.issue21998@psf.upfronthosting.co.za> STINNER Victor added the comment: I suggest to split this issue: create a new issue focus on selectors.EpollSelector, it doesn't behave well with forking. If I understood correctly, you can workaround this specific issue by forcing the selector to selectors.SelectSelector for example, right? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 16:51:41 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 08 Dec 2014 15:51:41 +0000 Subject: [issue23009] selectors.EpollSelector.select raises exception when nothing to select. In-Reply-To: <1418035005.39.0.294462650059.issue23009@psf.upfronthosting.co.za> Message-ID: <1418053900.99.0.322311757314.issue23009@psf.upfronthosting.co.za> STINNER Victor added the comment: + s.select(timeout=0) I suggest to ensure that the result is an empty list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 16:55:35 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 08 Dec 2014 15:55:35 +0000 Subject: [issue23009] selectors.EpollSelector.select raises exception when nothing to select. In-Reply-To: <1418035005.39.0.294462650059.issue23009@psf.upfronthosting.co.za> Message-ID: <1418054135.36.0.845426535263.issue23009@psf.upfronthosting.co.za> Changes by Yury Selivanov : Added file: http://bugs.python.org/file37388/epoll_02.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 16:56:07 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 08 Dec 2014 15:56:07 +0000 Subject: [issue23009] selectors.EpollSelector.select raises exception when nothing to select. In-Reply-To: <1418035005.39.0.294462650059.issue23009@psf.upfronthosting.co.za> Message-ID: <1418054167.22.0.846442283422.issue23009@psf.upfronthosting.co.za> Yury Selivanov added the comment: I agree. Please see another one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 17:01:36 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 08 Dec 2014 16:01:36 +0000 Subject: [issue23009] selectors.EpollSelector.select raises exception when nothing to select. In-Reply-To: <1418035005.39.0.294462650059.issue23009@psf.upfronthosting.co.za> Message-ID: <1418054496.82.0.376962240787.issue23009@psf.upfronthosting.co.za> STINNER Victor added the comment: It's a little bit surprising to call epoll_wait() without any FD subscribed, but select([], [], [], delay) is a known way to sleep 'delay' seconds, so why not using epoll in a similar way? :-) epoll_02.patch looks good to me. Can you please also apply the patch to the Tulip project? (By the way, test_selectors.py to Tulip is completly different, we may just reuse the file from CPython and drop the code from Tulip.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 17:09:14 2014 From: report at bugs.python.org (Brett Cannon) Date: Mon, 08 Dec 2014 16:09:14 +0000 Subject: [issue23013] Tweak wording for importlib.util.LazyLoader in regards to Loader.create_module() Message-ID: <1418054954.8.0.232826100302.issue23013@psf.upfronthosting.co.za> New submission from Brett Cannon: The docs for importlib.util.LazyLoader emphatically say that a "loader cannot define importlib.abc.Loader.create_module()" if it is to be subclassed. What in fact should say is that the subclass' create_module() will not be called; whether it is defined or not is of no consequence. ---------- assignee: brett.cannon components: Documentation keywords: easy messages: 232312 nosy: brett.cannon priority: normal severity: normal stage: needs patch status: open title: Tweak wording for importlib.util.LazyLoader in regards to Loader.create_module() versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 17:14:47 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 08 Dec 2014 16:14:47 +0000 Subject: [issue23008] pydoc enum.{,Int}Enum fails In-Reply-To: <1418018648.34.0.0967171282391.issue23008@psf.upfronthosting.co.za> Message-ID: <1418055287.31.0.312413789055.issue23008@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 17:18:58 2014 From: report at bugs.python.org (Brett Cannon) Date: Mon, 08 Dec 2014 16:18:58 +0000 Subject: [issue23014] Don't have importlib.abc.Loader.create_module() be optional Message-ID: <1418055538.78.0.471721917483.issue23014@psf.upfronthosting.co.za> New submission from Brett Cannon: I continue to be bothered by how we designed importlib.abc.Loader.create_module(). I don't like that it's optional and I don't like that it can return None. I would much rather make it so that importlib.abc.Loader.create_module() was a static method that does what importlib.util.module_from_spec() does. I would also like importlib to throw a fit if exec_module() was defined on a loader but not create_module() with a DeprecationWarning to start and then an AttributeError later (as I said, this requires exec_module() defined and does not play into the whole load_module() discussion). This should also hopefully promote people subclassing importlib.abc.Loader more as well. What do other people think? ---------- components: Interpreter Core messages: 232313 nosy: brett.cannon, eric.snow, ncoghlan priority: normal severity: normal stage: test needed status: open title: Don't have importlib.abc.Loader.create_module() be optional type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 17:35:44 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 08 Dec 2014 16:35:44 +0000 Subject: [issue23009] selectors.EpollSelector.select raises exception when nothing to select. In-Reply-To: <1418054496.82.0.376962240787.issue23009@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Please add a comment explaining the complaint from epoll.poll() we're trying to avoid here. I presume Tulip never gets into this state because of the self-pipe. On Mon, Dec 8, 2014 at 8:01 AM, STINNER Victor wrote: > > STINNER Victor added the comment: > > It's a little bit surprising to call epoll_wait() without any FD > subscribed, but select([], [], [], delay) is a known way to sleep 'delay' > seconds, so why not using epoll in a similar way? :-) > > epoll_02.patch looks good to me. Can you please also apply the patch to > the Tulip project? > > (By the way, test_selectors.py to Tulip is completly different, we may > just reuse the file from CPython and drop the code from Tulip.) > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 17:45:28 2014 From: report at bugs.python.org (Kurt Roeckx) Date: Mon, 08 Dec 2014 16:45:28 +0000 Subject: [issue22935] Disabling SSLv3 support In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za> Message-ID: <1418057128.35.0.932941205125.issue22935@psf.upfronthosting.co.za> Kurt Roeckx added the comment: I did update the documentation to mention that, but it seems none of my documentation changes got applied. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 18:23:02 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 08 Dec 2014 17:23:02 +0000 Subject: [issue23009] selectors.EpollSelector.select raises exception when nothing to select. In-Reply-To: <1418035005.39.0.294462650059.issue23009@psf.upfronthosting.co.za> Message-ID: <20141208172258.21250.44683@psf.io> Roundup Robot added the comment: New changeset b2ee06684b6a by Yury Selivanov in branch '3.4': selectors: Make sure EpollSelecrtor.select() works when no FD is registered. https://hg.python.org/cpython/rev/b2ee06684b6a New changeset 202995833ef4 by Yury Selivanov in branch 'default': selectors: Make sure EpollSelecrtor.select() works when no FD is registered. https://hg.python.org/cpython/rev/202995833ef4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 18:23:31 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 08 Dec 2014 17:23:31 +0000 Subject: [issue23009] selectors.EpollSelector.select raises exception when nothing to select. In-Reply-To: <1418035005.39.0.294462650059.issue23009@psf.upfronthosting.co.za> Message-ID: <1418059411.72.0.733401969752.issue23009@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Please add a comment explaining the complaint from epoll.poll() we're trying to avoid here. Good point! Committed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 18:24:07 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 08 Dec 2014 17:24:07 +0000 Subject: [issue23009] selectors.EpollSelector.select raises exception when nothing to select. In-Reply-To: <1418035005.39.0.294462650059.issue23009@psf.upfronthosting.co.za> Message-ID: <1418059447.3.0.213937847172.issue23009@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 18:35:21 2014 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 08 Dec 2014 17:35:21 +0000 Subject: [issue23009] selectors.EpollSelector.select raises exception when nothing to select. In-Reply-To: <1418059447.33.0.136114198709.issue23009@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: Thanks for taking care of this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 18:37:49 2014 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 08 Dec 2014 17:37:49 +0000 Subject: [issue23007] Unnecessary big intermediate result in Lib/bisect.py In-Reply-To: <1417992191.21.0.852637765732.issue23007@psf.upfronthosting.co.za> Message-ID: <1418060269.97.0.535649167419.issue23007@psf.upfronthosting.co.za> Mark Dickinson added the comment: > What troubles? Well, I imagine that something like "bisect(a, 155, lo=numpy.uint8(0), hi=numpy.uint8(254))" would be asking for trouble. But (a) it's hard to imagine why anyone would want to do that given that NumPy has its own bisection code, and (b) you'd have to somehow make sure that you were using the plain Python bisect code and not the `_bisect` module code, which AFAIK does the right thing here. Sergey: what troubles have you run into? With what user-defined types? Note that if you just do "from bisect import *" at a Python prompt, you're not even using the code in Lib/bisect.py: the main implementation is written in C. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 18:38:20 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 08 Dec 2014 17:38:20 +0000 Subject: [issue23009] selectors.EpollSelector.select raises exception when nothing to select. In-Reply-To: <1418035005.39.0.294462650059.issue23009@psf.upfronthosting.co.za> Message-ID: <20141208173810.73374.26458@psf.io> Roundup Robot added the comment: New changeset 8f1be68dfcab by Yury Selivanov in branch '3.4': NEWS: Add news entry for issue #23009. https://hg.python.org/cpython/rev/8f1be68dfcab New changeset d36711410f48 by Yury Selivanov in branch 'default': NEWS: Add news entry for issue #23009. https://hg.python.org/cpython/rev/d36711410f48 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 20:36:09 2014 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 08 Dec 2014 19:36:09 +0000 Subject: [issue23010] "unclosed file" warning when defining unused logging FileHandler in dictConfig In-Reply-To: <1418046415.01.0.116582999558.issue23010@psf.upfronthosting.co.za> Message-ID: <1418067369.86.0.144392094874.issue23010@psf.upfronthosting.co.za> Vinay Sajip added the comment: Well, it's possible that you could configure handlers in the configuration for later use (i.e. at some point after the dictConfig() call returns). If you want to avoid opening the file until it's actually needed, you can specify delay=True, and then you shouldn't see the resource leak because the stream will be opened when it's actually needed. Unless there's some reason you can't do that, or there's something I've overlooked, I think I should close this as invalid. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 20:45:38 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 08 Dec 2014 19:45:38 +0000 Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za> Message-ID: <1418067938.67.0.868753522085.issue15582@psf.upfronthosting.co.za> Yury Selivanov added the comment: @Claudiu, you should also add this test and make sure that it passes: class Parent: __doc__ = 'some documentation' class Child(Parent): __doc__ = None assert getdoc(Child) is None In other words -- we use __doc__ defined in parent classes only when there was no __doc__ in children's __dict__s. ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 20:49:38 2014 From: report at bugs.python.org (Claudiu Popa) Date: Mon, 08 Dec 2014 19:49:38 +0000 Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za> Message-ID: <1418068178.1.0.844883031535.issue15582@psf.upfronthosting.co.za> Claudiu Popa added the comment: Alright, I'll update my patch later this week. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 21:00:44 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 08 Dec 2014 20:00:44 +0000 Subject: [issue21740] doctest doesn't allow duck-typing callables In-Reply-To: <1402606753.04.0.326464066676.issue21740@psf.upfronthosting.co.za> Message-ID: <20141208200025.76728.53716@psf.io> Roundup Robot added the comment: New changeset d22ca7496c54 by Yury Selivanov in branch 'default': Issue #21740: Support wrapped callables in pydoc. Patch by Claudiu Popa. https://hg.python.org/cpython/rev/d22ca7496c54 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 21:01:17 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 08 Dec 2014 20:01:17 +0000 Subject: [issue21740] doctest doesn't allow duck-typing callables In-Reply-To: <1402606753.04.0.326464066676.issue21740@psf.upfronthosting.co.za> Message-ID: <1418068877.34.0.981964332067.issue21740@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thank you for the patch, Claudiu! ---------- nosy: +yselivanov resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 21:23:22 2014 From: report at bugs.python.org (Walter Doekes) Date: Mon, 08 Dec 2014 20:23:22 +0000 Subject: [issue23010] "unclosed file" warning when defining unused logging FileHandler in dictConfig In-Reply-To: <1418046415.01.0.116582999558.issue23010@psf.upfronthosting.co.za> Message-ID: <1418070202.44.0.213597405532.issue23010@psf.upfronthosting.co.za> Walter Doekes added the comment: Thanks for the quick response! > Well, it's possible that you could configure handlers in the configuration for later use (i.e. at some point after the dictConfig() call returns). After the dictConfig call returns, the StreamHandler/FileHandler is not referenced by anyone anymore. That's what causes the ResourceWarning. Unless I'm severely mistaken, there is no way to reach that old FileHandler instance. > If you want to avoid opening the file until it's actually needed, you can specify delay=True. I am aware of that, but that's a workaround, not a fix. (And it has drawbacks of its own, for example in forking and/or setuid situations.) > Unless there's some reason you can't do that, or there's something I've overlooked, I think I should close this as invalid. You could do that, but -- barring me overlooking something here -- I think that would only be correct if the dictionary that I passed to dictConfig is judged as being illegal, because it contains unused handlers. The ResourceWarning thrown is hard to understand because of where it is raised (at random points in a different modules), so like it is now, it may dissuade users from enabling more (visual) warnings. I'd rather see a warning raised earlier from dictConfig() that I configured an unused handler, so I have a better indication of what to fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 21:33:10 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 08 Dec 2014 20:33:10 +0000 Subject: [issue23015] Improve test_uuid Message-ID: <1418070790.02.0.347463680837.issue23015@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch makes following changes to test_uuid. * Report the test as skipped if this method to determine MAC address doesn't work on this platform. * Output found node value if test ran with -vv. * Output node values in hexadecimal if node tests fail. * Check that 47 bit is clear for node values obtained from network card. * Remove unused commented out code. * Move internal functions tests to separate test class. ---------- components: Tests files: test_uuid.patch keywords: patch messages: 232327 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Improve test_uuid type: enhancement versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37389/test_uuid.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 22:06:18 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 08 Dec 2014 21:06:18 +0000 Subject: [issue1218234] inspect.getsource doesn't update when a module is reloaded Message-ID: <20141208210601.21260.83736@psf.io> Roundup Robot added the comment: New changeset 8e2505d535c8 by Yury Selivanov in branch 'default': inspect: Fix getsource() to load updated source of reloaded module https://hg.python.org/cpython/rev/8e2505d535c8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 22:07:29 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 08 Dec 2014 21:07:29 +0000 Subject: [issue1218234] inspect.getsource doesn't update when a module is reloaded Message-ID: <1418072849.58.0.894468905619.issue1218234@psf.upfronthosting.co.za> Yury Selivanov added the comment: Fixed in 3.5. Not sure if we need to backport this to 3.4 and 2.7. Closing this issue. Thanks to Bj?rn Lindqvist and Berker Peksag! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 22:07:36 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 08 Dec 2014 21:07:36 +0000 Subject: [issue1218234] inspect.getsource doesn't update when a module is reloaded Message-ID: <1418072856.89.0.965369076401.issue1218234@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 22:26:36 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 08 Dec 2014 21:26:36 +0000 Subject: [issue9678] uuid._ifconfig_getnode can't work on NetBSD In-Reply-To: <1282705798.9.0.0619423981288.issue9678@psf.upfronthosting.co.za> Message-ID: <1418073996.69.0.273568859759.issue9678@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch is updated to current sources. Please test on NetBSD5. ---------- nosy: +serhiy.storchaka stage: -> patch review versions: +Python 3.4, Python 3.5 -Python 3.2 Added file: http://bugs.python.org/file37390/uuid_arp_getnode_netbsd.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 22:29:34 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 08 Dec 2014 21:29:34 +0000 Subject: [issue19164] Update uuid.UUID TypeError exception: integer should not be an argument. In-Reply-To: <1380885490.13.0.480584034262.issue19164@psf.upfronthosting.co.za> Message-ID: <1418074174.1.0.0235862519736.issue19164@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +needs review stage: needs patch -> patch review versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 22:47:13 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 08 Dec 2014 21:47:13 +0000 Subject: [issue1703178] link_objects in setup.cfg crashes build Message-ID: <1418075233.13.0.539661985169.issue1703178@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Donald, can you look at this one-line patch? ?ric has not responded. ---------- nosy: +dstufft, terry.reedy -tarek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 22:48:50 2014 From: report at bugs.python.org (Jason R. Coombs) Date: Mon, 08 Dec 2014 21:48:50 +0000 Subject: [issue1218234] inspect.getsource doesn't update when a module is reloaded Message-ID: <1418075330.47.0.974163868519.issue1218234@psf.upfronthosting.co.za> Jason R. Coombs added the comment: FWIW, I'd appreciate a backport to 3.4, given that 3.5 is scheduled for release in Sep 2015. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 23:20:08 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 08 Dec 2014 22:20:08 +0000 Subject: [issue1703178] link_objects in setup.cfg crashes build Message-ID: <1418077208.34.0.409346240693.issue1703178@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks for the patch. It looks good to me. ---------- assignee: eric.araujo -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 23:24:35 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 08 Dec 2014 22:24:35 +0000 Subject: [issue1218234] inspect.getsource doesn't update when a module is reloaded Message-ID: <1418077475.73.0.045963925418.issue1218234@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 8 23:34:19 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 08 Dec 2014 22:34:19 +0000 Subject: [issue23014] Don't have importlib.abc.Loader.create_module() be optional In-Reply-To: <1418055538.78.0.471721917483.issue23014@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: I mostly like the idea, but am wary of having the base class implement it as a static method that subclasses are then likely to override with a normal instance method. A module level function somewhere + a base class instance method that just delegates to the stateless function version would feel cleaner to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 00:01:53 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 08 Dec 2014 23:01:53 +0000 Subject: [issue1218234] inspect.getsource doesn't update when a module is reloaded Message-ID: <20141208230143.27505.13882@psf.io> Roundup Robot added the comment: New changeset e52d8e888df1 by Yury Selivanov in branch '3.4': inspect: Fix getsource() to load updated source of reloaded module https://hg.python.org/cpython/rev/e52d8e888df1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 00:10:15 2014 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 08 Dec 2014 23:10:15 +0000 Subject: [issue1218234] inspect.getsource doesn't update when a module is reloaded Message-ID: <1418080215.64.0.240937447402.issue1218234@psf.upfronthosting.co.za> Yury Selivanov added the comment: @Jason: done ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 00:20:50 2014 From: report at bugs.python.org (Vinay Sajip) Date: Mon, 08 Dec 2014 23:20:50 +0000 Subject: [issue23010] "unclosed file" warning when defining unused logging FileHandler in dictConfig In-Reply-To: <1418046415.01.0.116582999558.issue23010@psf.upfronthosting.co.za> Message-ID: <1418080850.64.0.869398799215.issue23010@psf.upfronthosting.co.za> Vinay Sajip added the comment: The delay= is not really a workaround for this particular circumstance, it's mainly there to avoid leaving empty files around and allocating resources that might never be used (which is analogous to this issue, but delay was not implemented to work around this specific scenario). The handlers are AFAIK referenced - if you peek at logging._handlerList or logging._handlers you should see them in there. A config dictionary is not judged as being illegal just because it contains unused handlers - you just happen to allocate resource that you never use. You could just leave out the handlers, since you're never using them; it's not logging's job to be overly restrictive about this sort of thing. Python doesn't warn you for allocating a dictionary that you never populate, or if you populate a dictionary that you then never interrogate. The type of unnecessary allocation of resources you're talking about happens a lot in programs - in fact, it also applies to loggers, since you might never use them in a specific program run, because of which code gets run based on command-line arguments, or with handlers that are "used" (in the sens you mean here, because they are linked to loggers), but never *actually* used because the levels in the configuration are set to CRITICAL, and there are no .critical() calls encountered during a program run. I'm not sure a line can usefully be drawn regarding "useless" allocations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 00:37:29 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Mon, 08 Dec 2014 23:37:29 +0000 Subject: [issue1425127] os.remove OSError: [Errno 13] Permission denied Message-ID: <1418081849.76.0.89897148885.issue1425127@psf.upfronthosting.co.za> Josh Rosenberg added the comment: I think you're overinterpreting. The bug probably still exists on Windows if you're using a poorly designed anti-virus or indexing tool; nothing fundamental has changed in how files are deleted on Windows since this was opened. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 01:30:45 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 09 Dec 2014 00:30:45 +0000 Subject: [issue22123] Provide a direct function for types.SimpleNamespace() In-Reply-To: <1406966548.11.0.912987884229.issue22123@psf.upfronthosting.co.za> Message-ID: <1418085045.76.0.399645746386.issue22123@psf.upfronthosting.co.za> Eric Snow added the comment: > It's not a builtin yet, solely because we get far fewer arguments about the contents of the types module than we do builtins :) Exactly. As Mark noted, I did have hopes of it reaching that status though. :) So +1 from me for adding the namespace builtin! ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 02:00:13 2014 From: report at bugs.python.org (Philip Jenvey) Date: Tue, 09 Dec 2014 01:00:13 +0000 Subject: [issue19725] Richer stat object In-Reply-To: <1385156508.32.0.63377992281.issue19725@psf.upfronthosting.co.za> Message-ID: <1418086813.69.0.647529576436.issue19725@psf.upfronthosting.co.za> Philip Jenvey added the comment: I can't find the paper trail of what I originally thought was a "consensus" or even that many clear pronouncements about it, but I recall Nick being originally opposed to it but he later changed his mind, you can see his approval here: https://mail.python.org/pipermail/python-dev/2013-May/125809.html 'It's also quite likely the "rich stat object" API will be pursued for 3.5' https://mail.python.org/pipermail/python-dev/2013-November/130582.html https://mail.python.org/pipermail/python-dev/2013-November/130588.html Antoine seems ok w/ it, encouraging others to make it happen: https://mail.python.org/pipermail//python-dev/2013-September/128708.html You can probably find a bit more discussion within those threads ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 02:10:16 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 09 Dec 2014 01:10:16 +0000 Subject: [issue1425127] os.remove OSError: [Errno 13] Permission denied Message-ID: <1418087416.79.0.979755774979.issue1425127@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I sometimes have problems deleting files in Windows Explorer. Sometimes I have to wait for reboot, sometimes I have to login as admin. None of this is a bug in Python. The original post, nearly 9 years ago, was not obviously a Python bug report but appears to be question about quirks in Windows. Two Python experts disagreed whether there is a Python bug. In any case, an open issue needs a repeatable test case that demonstrates a problem with current Python running on a currently supported OS, preferably without 'poorly designed' 3rd party software involved. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 02:27:03 2014 From: report at bugs.python.org (stockbsd Li) Date: Tue, 09 Dec 2014 01:27:03 +0000 Subject: [issue23016] uncatched exception in lib/warnings.py when executed with pythonw Message-ID: <1418088423.32.0.545997731561.issue23016@psf.upfronthosting.co.za> New submission from stockbsd Li: in py3k, the following simple code will throw an uncatched exception when executed with pythonw: import warnings warnings.warn('test') the problem occurs in showarning function: in py3k's pythonw , stderr/stdout is set to None, so the file.write(...) statement will thorw AttributeError uncatched. I think a catch-all except(delete 'OSError') can solve this. def showwarning(message, category, filename, lineno, file=None, line=None): """Hook to write a warning to a file; replace if you like.""" if file is None: file = sys.stderr try: file.write(formatwarning(message, category, filename, lineno, line)) except OSError: pass # the file (probably stderr) is invalid - this warning gets lost. ---------- components: Library (Lib) messages: 232342 nosy: stockbsd priority: normal severity: normal status: open title: uncatched exception in lib/warnings.py when executed with pythonw type: crash versions: Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 04:52:01 2014 From: report at bugs.python.org (Steve Ward) Date: Tue, 09 Dec 2014 03:52:01 +0000 Subject: [issue23017] string.printable.isprintable() returns False Message-ID: <1418097121.16.0.891016494417.issue23017@psf.upfronthosting.co.za> New submission from Steve Ward: string.printable includes all whitespace characters. However, the only whitespace character that is printable is the space (0x20). By definition, the only ASCII characters considered printable are: alphanumeric characters punctuation characters the space character (not all whitespace characters) Source: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html#tag_07_03 7.2 POSIX Locale Conforming systems shall provide a POSIX locale, also known as the C locale. 7.3.1 LC_CTYPE space Define characters to be classified as white-space characters. In the POSIX locale, exactly , , , , , and shall be included. cntrl Define characters to be classified as control characters. In the POSIX locale, no characters in classes alpha or print shall be included. graph Define characters to be classified as printable characters, not including the . In the POSIX locale, all characters in classes alpha, digit, and punct shall be included; no characters in class cntrl shall be included. print Define characters to be classified as printable characters, including the . In the POSIX locale, all characters in class graph shall be included; no characters in class cntrl shall be included. LC_CTYPE Category in the POSIX Locale # "print" is by default "alnum", "punct", and the ---------- components: Library (Lib) files: bug-string-ascii.py messages: 232343 nosy: planet36 priority: normal severity: normal status: open title: string.printable.isprintable() returns False type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file37391/bug-string-ascii.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 06:25:36 2014 From: report at bugs.python.org (Steve Dower) Date: Tue, 09 Dec 2014 05:25:36 +0000 Subject: [issue22919] Update PCBuild for VS 2015 In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za> Message-ID: <1418102736.32.0.0802217718929.issue22919@psf.upfronthosting.co.za> Steve Dower added the comment: Small incremental patch from Zach's feedback and a few sysconfig changes I missed. ---------- Added file: http://bugs.python.org/file37392/round6incremental.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 06:27:42 2014 From: report at bugs.python.org (Steve Dower) Date: Tue, 09 Dec 2014 05:27:42 +0000 Subject: [issue23018] Add version info to python[w].exe Message-ID: <1418102862.79.0.624047396863.issue23018@psf.upfronthosting.co.za> New submission from Steve Dower: We should include the version resource in python[w].exe as well as python35.dll so that it can be properly identified. (If possible, we should do .pyd files too, though I don't think the version info will be displayed, so it's probably not worth it.) ---------- assignee: steve.dower messages: 232345 nosy: steve.dower priority: normal severity: normal status: open title: Add version info to python[w].exe type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 06:42:50 2014 From: report at bugs.python.org (Steve Dower) Date: Tue, 09 Dec 2014 05:42:50 +0000 Subject: [issue23018] Add version info to python[w].exe In-Reply-To: <1418102862.79.0.624047396863.issue23018@psf.upfronthosting.co.za> Message-ID: <1418103770.42.0.833217974107.issue23018@psf.upfronthosting.co.za> Steve Dower added the comment: Patch for the version info, and also for half of #19143 since I was there. ---------- components: +Windows keywords: +patch nosy: +tim.golden, zach.ware Added file: http://bugs.python.org/file37393/23018.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 07:53:33 2014 From: report at bugs.python.org (Dmitry Shachnev) Date: Tue, 09 Dec 2014 06:53:33 +0000 Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone constant In-Reply-To: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za> Message-ID: <1418108013.15.0.34692131925.issue22932@psf.upfronthosting.co.za> Dmitry Shachnev added the comment: Here is the updated patch based on Alexander?s suggestion. Works fine, the only difference with previous behavior is that the zero time zone is now +0000 instead of -0000. ---------- Added file: http://bugs.python.org/file37394/issue22932_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 08:45:27 2014 From: report at bugs.python.org (=?utf-8?q?Bj=C3=B6rn_Karge?=) Date: Tue, 09 Dec 2014 07:45:27 +0000 Subject: [issue23019] pyexpat.errors wrongly bound to message strings instead of message codes Message-ID: <1418111127.16.0.333870475533.issue23019@psf.upfronthosting.co.za> New submission from Bj?rn Karge: expat.errors should expose the enum values and NOT the associated message strings, so they can be tested against ExpatError.code ---------- components: Library (Lib) messages: 232348 nosy: bkarge priority: normal severity: normal status: open title: pyexpat.errors wrongly bound to message strings instead of message codes type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 09:09:41 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 09 Dec 2014 08:09:41 +0000 Subject: [issue23006] Improve the doc and indexing of adict.__missing__. In-Reply-To: <1417985369.96.0.326358204226.issue23006@psf.upfronthosting.co.za> Message-ID: <1418112581.66.0.632451375676.issue23006@psf.upfronthosting.co.za> Raymond Hettinger added the comment: These edits look reasonable, useful and correct. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 09:10:03 2014 From: report at bugs.python.org (Walter Doekes) Date: Tue, 09 Dec 2014 08:10:03 +0000 Subject: [issue23010] "unclosed file" warning when defining unused logging FileHandler in dictConfig In-Reply-To: <1418046415.01.0.116582999558.issue23010@psf.upfronthosting.co.za> Message-ID: <1418112603.55.0.229856423566.issue23010@psf.upfronthosting.co.za> Walter Doekes added the comment: > The handlers are AFAIK referenced - if you peek at logging._handlerList or logging._handlers you should see them in there. Aha. But that's the point. They aren't. If they were, I wouldn't have any problems with this. But I have this problem because the warnings are generated at startup of my program, not at cleanup. Look at this: $ PYTHONWARNINGS=default python3 problem.py 2>&1 | sed -e 's/^/ /' 2014-12-09 08:58:45.982258: starting 2014-12-09 08:58:46.011788: after dictconfig /usr/lib/python3.4/importlib/_bootstrap.py:321: ResourceWarning: unclosed file <_io.FileIO name='/tmp/debug.log' mode='ab'> return f(*args, **kwds) imported once 2014-12-09 08:58:46.019327: after error 2014-12-09 08:58:51.024376: after sleep _handlerList: [] _handlers: [] If what you say is true, the following wouldn't be: - _handlerList is non-empty (wrong, see above) - the warning would be generated at application shutdown (no, it's generated at importlib time, see the timestamps) (See source below.) > You could just leave out the handlers, since you're never using them; it's not logging's job to be overly restrictive about this sort of thing. I could agree with you there. But in that case I still think we should call it illegal (and perhaps raise a more sensible warning). Obviously you spot the problem immediately in my toy example. But in a large LOGGING dictionary, items may be shuffled around and changed. When that happens, and these warnings turn up out of the blue, that's distracting to put it mildly. I expect that you'll reconsider your strict opinion after seeing that logging._handlers is indeed empty and the handlers are not referenced (and therefore should have been destroyed properly or not created at all). Cheers, Walter Example source: $ cat problem.py | sed -e 's/^/ /' from datetime import datetime from time import sleep import sys if __name__ == '__main__': LOGGING = { 'version': 1, 'handlers': { 'logfile': { 'level': 'DEBUG', 'class': 'logging.FileHandler', 'filename': '/tmp/debug.log', }, }, } print('%s: starting' % (datetime.now(),)) from logging.config import dictConfig dictConfig(LOGGING) print('%s: after dictconfig' % (datetime.now(),)) sys.stdout.flush() # using importlib on a new file triggers the warnings import importlib, shutil, os shutil.copy(__file__, __file__ + '.new') os.unlink(__file__) os.rename(__file__ + '.new', __file__) importlib.import_module('problem') sys.stderr.flush() print('%s: after error' % (datetime.now(),)) sys.stdout.flush() sleep(5) print('%s: after sleep' % (datetime.now(),)) # Vinay Sajip wrote: # > The handlers are AFAIK referenced - if you peek at # logging._handlerList or logging._handlers you should see them in # there. from logging import _handlerList, _handlers print('_handlerList:', _handlerList) print('_handlers:', [i for i in _handlers.values()]) else: print('imported once') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 09:18:51 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 09 Dec 2014 08:18:51 +0000 Subject: [issue18305] [patch] Fast sum() for non-numbers In-Reply-To: <1372228439.5.0.789865081817.issue18305@psf.upfronthosting.co.za> Message-ID: <1418113131.35.0.436549594643.issue18305@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Guido, do you care to close this one? Terry, has channeled you and thinks it may be against your wishes to turn sum() into a general purpose sequence concatenator. I also seem to recall you expresses similar thoughts back when Alex Martelli first designed sum() many years ago. If it helps, here is the guidance currently expressed in the docs for __builtin__.sum(): """ For some use cases, there are good alternatives to sum(). The preferred, fast way to concatenate a sequence of strings is by calling ''.join(sequence). To add floating point values with extended precision, see math.fsum(). To concatenate a series of iterables, consider using itertools.chain(). """ ---------- assignee: -> gvanrossum nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 09:26:14 2014 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 09 Dec 2014 08:26:14 +0000 Subject: [issue23007] Unnecessary big intermediate result in Lib/bisect.py In-Reply-To: <1417992191.21.0.852637765732.issue23007@psf.upfronthosting.co.za> Message-ID: <1418113574.86.0.741034258021.issue23007@psf.upfronthosting.co.za> Mark Dickinson added the comment: Sergey: do you have an example of the Lib/bisect.py code causing problems in real (non-contrived) code? If not, I'd suggest closing this report as "not a bug". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 09:38:52 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 09 Dec 2014 08:38: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: <1418114332.72.0.557616774614.issue22609@psf.upfronthosting.co.za> Raymond Hettinger added the comment: [Serhiy] > So what to do wish UserDict? I'm leaning in favor of leaving UserDict as-is. AFAICT, in the very long history of UserDict, this has never been a problem. So, I don't think there is an issue worth breaking the published API and possibly breaking code that currently works. (This is a case of practicality beating purity). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 09:50:06 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 09 Dec 2014 08:50:06 +0000 Subject: [issue22123] Provide a direct function for types.SimpleNamespace() In-Reply-To: <1406966548.11.0.912987884229.issue22123@psf.upfronthosting.co.za> Message-ID: <1418115006.69.0.273596531171.issue22123@psf.upfronthosting.co.za> Raymond Hettinger added the comment: -1 on moving this to builtin status. For a long time, we've tried to keep a back pressure against adding more builtins (in part because it increases the learning curve for the core language). The SimpleNamespace() type would need to become *much* more popular to warrant becoming a builtin (even then, other tools such as copy.copy() or collections.OrderedDict() would likely be able to make stronger claims). AFAICT, the SimpleNamespace() class has been used exactly once is the standard library (in venv) and almost not at all in published code. IMO, it is *very* far from warranting builtin status. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 09:52:06 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 09 Dec 2014 08:52:06 +0000 Subject: [issue23005] typos on heapq doc In-Reply-To: <1417978054.94.0.0217424241667.issue23005@psf.upfronthosting.co.za> Message-ID: <1418115126.96.0.311662685028.issue23005@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This change looks reasonable and correct. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 09:58:43 2014 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 09 Dec 2014 08:58:43 +0000 Subject: [issue23010] "unclosed file" warning when defining unused logging FileHandler in dictConfig In-Reply-To: <1418046415.01.0.116582999558.issue23010@psf.upfronthosting.co.za> Message-ID: <1418115523.67.0.505108009593.issue23010@psf.upfronthosting.co.za> Vinay Sajip added the comment: > Aha. But that's the point. They aren't. Ok, I'll investigate further. Thanks for your persistence :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 09:59:42 2014 From: report at bugs.python.org (Bruno Cauet) Date: Tue, 09 Dec 2014 08:59:42 +0000 Subject: [issue1703178] link_objects in setup.cfg crashes build Message-ID: <1418115582.83.0.591245827506.issue1703178@psf.upfronthosting.co.za> Bruno Cauet added the comment: There's a small typo in the comments: + # make sure cmd.link_objects is turned into a list + # is it's a string Should be: + # make sure cmd.link_objects is turned into a list + # if it's a string ---------- nosy: +bru _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 10:41:08 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 09 Dec 2014 09:41:08 +0000 Subject: [issue22958] Constructors of weakref mapping classes don't accept "self" and "dict" keyword arguments In-Reply-To: <1417104803.61.0.896440563309.issue22958@psf.upfronthosting.co.za> Message-ID: <1418118068.48.0.310457191501.issue22958@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch similar to patch from issue22609 which makes WeakValueDictionary constructor and update accept keyword arguments "self" and "dict". ---------- keywords: +needs review, patch stage: -> patch review Added file: http://bugs.python.org/file37395/WeakValueDictionary_pos_only_params.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 10:52:17 2014 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 09 Dec 2014 09:52:17 +0000 Subject: [issue23007] Unnecessary big intermediate result in Lib/bisect.py In-Reply-To: <1417992191.21.0.852637765732.issue23007@psf.upfronthosting.co.za> Message-ID: <1418118737.68.0.72553208348.issue23007@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- resolution: -> not a bug status: open -> pending versions: +Python 3.4 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 11:09:15 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 09 Dec 2014 10:09:15 +0000 Subject: [issue9536] defaultdict doc makes incorrect reference to __missing__ method In-Reply-To: <1281106528.37.0.0435364267174.issue9536@psf.upfronthosting.co.za> Message-ID: <1418119755.16.0.313799366707.issue9536@psf.upfronthosting.co.za> Raymond Hettinger added the comment: [John Posner] > The fact is that a programmer using defaultdict does not need > to know anything about __missing__. I disagree. It seems to help people understand the defaultdict which otherwise seems more magical that it actually is. Also, it is a part of the description of how the default_factory attribute is used. Further, it helps explain why the factory is only called by __getitem__ rather than by get() or other methods. [David Murray] > I believe the description of __missing__ is there for those who > want to subclass defaultdict, but I'll let Raymond confirm. Yes, it serves that purpose but it also serves to make clear what the actual mechanics are for the defaultdict. I think there is no downside to keeping the current wording which provides some insights and hasn't seemed to cause any problems in practice (this has been around since Python 2.5). Terry's proposed changes in issue 23006 do seem like a good idea. I recommend against OP's proposed patch or any variant of it. That patch is predicated on the notion that __missing__ is an irrelevant, unnecessary, and confusing implementation detail. I don't agree that sentiment at all. Please keep in mind that this part of the documentation was written by Guido van Rossum and it clearly expresses what he had it mind when he implemented the defaultdict back in 2006. I really don't think we should throw away this text because 8 or 9 years later John has opined that Guido was fundamentally misguided when he wrote the documentation (back in the days when the docs were all in TeX markup). ---------- assignee: docs at python -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 11:14:47 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 09 Dec 2014 10:14:47 +0000 Subject: [issue23007] Unnecessary big intermediate result in Lib/bisect.py In-Reply-To: <1417992191.21.0.852637765732.issue23007@psf.upfronthosting.co.za> Message-ID: <1418120087.7.0.285839991692.issue23007@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I agree with Mark. This code is *very* old and AFAICT it has never caused a problem in practice. The "textbook" formula is more important in languages without something like Python long ints. In Python, "textbook" form just slows down and obfuscates the intention of the code. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 11:18:56 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 09 Dec 2014 10:18:56 +0000 Subject: [issue22918] Doc for __iter__ makes inexact comment about dict.__iter__ In-Reply-To: <1416689379.36.0.290921977035.issue22918@psf.upfronthosting.co.za> Message-ID: <1418120336.47.0.838319993149.issue22918@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > I think the first half of the sentence is enough: > ?For mappings, it should iterate over the keys of the container.? That should do it :-) ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 11:32:32 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 09 Dec 2014 10:32:32 +0000 Subject: [issue22939] integer overflow in iterator object In-Reply-To: <1416912993.1.0.671503723984.issue22939@psf.upfronthosting.co.za> Message-ID: <1418121152.68.0.614991496608.issue22939@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I would think that the PY_SSIZE_T_MAX check belongs inside the: if (result != NULL) { it->it_index++; return result; } just before the increment which could cause the overflow. Also, PY_SSIZE_T_MAX is a valid value to pass to PySequence_GetItem(), so it shouldn't be blocked unless necessary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 11:35:27 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 09 Dec 2014 10:35:27 +0000 Subject: [issue22955] Pickling of methodcaller, attrgetter, and itemgetter In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za> Message-ID: <1418121327.92.0.653766464422.issue22955@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > I'd prefer to just reimplement itemgetter and attrgetter to make > them picklable rather than adding pickling methods to them; > see attached patch. That isn't the usual approach. The pickling methods are there for a reason. I prefer to leave the existing code in a stable state and avoid unnecessary code churn or risk introducing bugs into code that is working correctly and as designed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 11:40:38 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 09 Dec 2014 10:40:38 +0000 Subject: [issue22955] Pickling of methodcaller, attrgetter, and itemgetter In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za> Message-ID: <1418121638.24.0.638041085604.issue22955@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Please remember that a potential new pickling feature is the least import part of the design of methodcaller, itemgetter, and attrgetter. Pickle support should be driven by the design rather become a predominant consideration. One other note: the OP's original concern has very little to do with these particular objects. Instead, it is the picking and unpickling tools themselves that tend to have crummy error messages when presented with objects that weren't specially designed with pickle support. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 11:41:19 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 09 Dec 2014 10:41:19 +0000 Subject: [issue22939] integer overflow in iterator object In-Reply-To: <1416912993.1.0.671503723984.issue22939@psf.upfronthosting.co.za> Message-ID: <1418121679.93.0.412654268842.issue22939@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This doesn't matter because next() will raise an exception if it_index == PY_SSIZE_T_MAX in any case. The code should be changed much more to allow yielding an item with index PY_SSIZE_T_MAX, use other (negative) signal value and change the behavior of __setstate__ for negative values. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 11:42:44 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 09 Dec 2014 10:42:44 +0000 Subject: [issue9536] defaultdict doc makes incorrect reference to __missing__ method In-Reply-To: <1281106528.37.0.0435364267174.issue9536@psf.upfronthosting.co.za> Message-ID: <1418121764.61.0.0884764329105.issue9536@psf.upfronthosting.co.za> Raymond Hettinger added the comment: http://svn.python.org/view/python/branches/release25-maint/Doc/lib/libcollections.tex?r1=38658&r2=42573 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 11:46:39 2014 From: report at bugs.python.org (Clement Rouault) Date: Tue, 09 Dec 2014 10:46:39 +0000 Subject: [issue22939] integer overflow in iterator object In-Reply-To: <1416912993.1.0.671503723984.issue22939@psf.upfronthosting.co.za> Message-ID: <1418121999.47.0.576207634511.issue22939@psf.upfronthosting.co.za> Clement Rouault added the comment: > Also, PY_SSIZE_T_MAX is a valid value to pass to PySequence_GetItem(), so it shouldn't be blocked unless necessary. I agree with you, that's why my first path was checking at the next call if it->it_index had overflowed. But then it relies on undefined behaviour. > I would think that the PY_SSIZE_T_MAX check belongs inside the: > > if (result != NULL) { > it->it_index++; > return result; > } If we raise the OverflowError when it->it_index really overflow (just after the getitem PY_SSIZE_T_MAX). Is it really necessary to do the overflow check after the GetItem ? because the value returned by `PySequence_GetItem(seq, PY_SSIZE_T_MAX);` will be never used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 12:22:03 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 09 Dec 2014 11:22:03 +0000 Subject: [issue22939] integer overflow in iterator object In-Reply-To: <1418121999.47.0.576207634511.issue22939@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: I prefer to raise an OverflowError *before* calling PySequence_GetItem(). The call to PySequence_GetItem() may be expensive, and we have to drop the result if an OverflowError is raised after the call. At the end, the behaviour is the same: an OverflowError is raised. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 12:49:40 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 09 Dec 2014 11:49:40 +0000 Subject: [issue23016] uncatched exception in lib/warnings.py when executed with pythonw In-Reply-To: <1418088423.32.0.545997731561.issue23016@psf.upfronthosting.co.za> Message-ID: <1418125780.76.0.931867411077.issue23016@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch. 2.7 is affected too. ---------- keywords: +patch nosy: +serhiy.storchaka stage: -> patch review type: crash -> behavior versions: +Python 2.7, Python 3.5 -Python 3.2, Python 3.3 Added file: http://bugs.python.org/file37396/warnings_stderr_none.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 12:50:38 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 09 Dec 2014 11:50:38 +0000 Subject: [issue23017] string.printable.isprintable() returns False In-Reply-To: <1418097121.16.0.891016494417.issue23017@psf.upfronthosting.co.za> Message-ID: <1418125838.86.0.930553761464.issue23017@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 13:01:46 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 09 Dec 2014 12:01:46 +0000 Subject: [issue22955] Pickling of methodcaller, attrgetter, and itemgetter In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za> Message-ID: <1418126506.92.0.888355830129.issue22955@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Instead, it is the picking and unpickling tools themselves that tend to have crummy error messages when presented with objects that weren't specially designed with pickle support. See issue22995 about this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 13:21:16 2014 From: report at bugs.python.org (stockbsd Li) Date: Tue, 09 Dec 2014 12:21:16 +0000 Subject: [issue23016] uncatched exception in lib/warnings.py when executed with pythonw In-Reply-To: <1418088423.32.0.545997731561.issue23016@psf.upfronthosting.co.za> Message-ID: <1418127676.43.0.775038982485.issue23016@psf.upfronthosting.co.za> stockbsd Li added the comment: 1. py2 is unaffected, because stderr/stdout is not None in py2's pythonw and the catch works correctly. 2. as to py3, I prefer this patch: - execpt OSError: + execpt: ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 13:31:43 2014 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 09 Dec 2014 12:31:43 +0000 Subject: [issue23020] New matmul operator crashes modules compiled with CPython3.4 Message-ID: <1418128303.35.0.105853053103.issue23020@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: When an extension module is compiled with CPython3.4, the nb_matrix_multiply slot is not filled, and no memory is allocated for it. If the extension module is imported by CPython3.5, nb_matrix_multiply contains garbage and segfaults the interpreter. In Python 2.7 there are flags like Py_TPFLAGS_HAVE_INDEX to gate the access to recently added slots. I think Python3.5 should have a similar one. ---------- messages: 232372 nosy: amaury.forgeotdarc, benjamin.peterson priority: normal severity: normal status: open title: New matmul operator crashes modules compiled with CPython3.4 type: crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 13:32:46 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 09 Dec 2014 12:32: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: <1418128366.55.0.304901376308.issue23020@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- priority: normal -> release blocker versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 13:42:13 2014 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 09 Dec 2014 12:42:13 +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: <1418128933.09.0.645650640492.issue23020@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Here is a test module that segfaults on Python3.5. It's derived from _testcapi, but it can be anything with a PyNumberMethods. I compiled with gcc -g -I path/to/cpython3.4/Include/ -I /path/to/cpython3.4 mytest.c -fPIC --shared -o mytest.so Then I ran python3.5 and: import mytest print(mytest.matmulType() @ 1) When the module is compiled with 3.5, TypeError is correctly raised. ---------- Added file: http://bugs.python.org/file37397/mytest.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 14:10:45 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 09 Dec 2014 13:10:45 +0000 Subject: [issue23016] uncatched exception in lib/warnings.py when executed with pythonw In-Reply-To: <1418088423.32.0.545997731561.issue23016@psf.upfronthosting.co.za> Message-ID: <1418130645.03.0.431373985856.issue23016@psf.upfronthosting.co.za> STINNER Victor added the comment: + execpt: Please never use that, but "except Exception:" instead to not catch SystemExit or KeyboardInterrupt. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 14:33:49 2014 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Tue, 09 Dec 2014 13:33:49 +0000 Subject: [issue22998] inspect.Signature and default arguments In-Reply-To: <1417724041.66.0.201313804397.issue22998@psf.upfronthosting.co.za> Message-ID: <1418132029.44.0.11153520637.issue22998@psf.upfronthosting.co.za> Walter D?rwald added the comment: The updated code in the documentation still doesn't set the * and ** parameters. I would have preferred the following code: for param in sig.parameters.values(): if param.name not in ba.arguments: if param.kind is inspect.Parameter.VAR_POSITIONAL: default = () elif param.kind is inspect.Parameter.VAR_KEYWORD: default = {} else: default = param.default ba.arguments[param.name] = default ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 15:15:32 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 09 Dec 2014 14:15:32 +0000 Subject: [issue22883] Get rid of references to PyInt in Py3 sources In-Reply-To: <1416147146.5.0.625860400609.issue22883@psf.upfronthosting.co.za> Message-ID: <1418134532.03.0.303076974061.issue22883@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 15:42:29 2014 From: report at bugs.python.org (Bruno Cauet) Date: Tue, 09 Dec 2014 14:42:29 +0000 Subject: [issue23017] string.printable.isprintable() returns False In-Reply-To: <1418097121.16.0.891016494417.issue23017@psf.upfronthosting.co.za> Message-ID: <1418136149.84.0.346258245066.issue23017@psf.upfronthosting.co.za> Bruno Cauet added the comment: Here is a simple fix for the issue, plus a test. It does not break any unit test but this raises a backwards-compatibility problem. Therefore I wouldn't advise using it for Python 3.4 but only 3.5+. ---------- keywords: +patch nosy: +bru versions: +Python 3.5 Added file: http://bugs.python.org/file37398/0001-Fix-string.printable-respect-POSIX-spec.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 15:44:04 2014 From: report at bugs.python.org (Rishi) Date: Tue, 09 Dec 2014 14:44:04 +0000 Subject: [issue1610654] cgi.py multipart/form-data Message-ID: <1418136244.52.0.862717016998.issue1610654@psf.upfronthosting.co.za> Rishi added the comment: There is indeed a test failure that occurs without the patch. This is a new test I had added. The reason is that in the existing implementation, when a boundary does not exist, the implementation does not include the trailing CRLF, LF or for that matter CR as part of the payload. I think that is not correct. However, to keep this patch compatible with behavior of existing implementation I have updated the patch to strip a single CRLF, LR or CR from the payload if a boundary is not found. ---------- Added file: http://bugs.python.org/file37399/issue1610654_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 15:44:14 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 09 Dec 2014 14:44:14 +0000 Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone constant In-Reply-To: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za> Message-ID: <1418136254.97.0.10906453823.issue22932@psf.upfronthosting.co.za> R. David Murray added the comment: That's a bug (you will note that it causes a test failure in the email test suite). -0000 means "this date is in UTC, but that may or may not be the local timezone of the message". +0000 means "this date really is in the UTC timezone". utils.format_datetime uses +0000 if and only if the datetime is an aware UTC datetime. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 15:53:05 2014 From: report at bugs.python.org (Rishi) Date: Tue, 09 Dec 2014 14:53:05 +0000 Subject: [issue1610654] cgi.py multipart/form-data Message-ID: <1418136785.82.0.0425670021194.issue1610654@psf.upfronthosting.co.za> Rishi added the comment: One of my comments shot the wrapped line limit. Also changed the test in question to check the lengths of the expected and actual buffer to checking the contents of the respective buffers. ---------- Added file: http://bugs.python.org/file37400/issue1610654_5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 15:53:08 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 09 Dec 2014 14:53:08 +0000 Subject: [issue23014] Don't have importlib.abc.Loader.create_module() be optional In-Reply-To: <1418055538.78.0.471721917483.issue23014@psf.upfronthosting.co.za> Message-ID: <1418136788.4.0.287434233609.issue23014@psf.upfronthosting.co.za> Brett Cannon added the comment: Fair enough. I have no qualms with keeping importlib.util.module_from_spec() and have Loader.create_module() just call module_from_spec(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 16:00:31 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 09 Dec 2014 15:00:31 +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: <1418137231.0.0.901036051074.issue23020@psf.upfronthosting.co.za> Benjamin Peterson added the comment: This technically falls under the fact that we don't have ABI compatibility between 3.N and 3.(N + 1). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 16:14:34 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 09 Dec 2014 15:14:34 +0000 Subject: [issue23017] string.printable.isprintable() returns False In-Reply-To: <1418097121.16.0.891016494417.issue23017@psf.upfronthosting.co.za> Message-ID: <1418138074.52.0.237452082674.issue23017@psf.upfronthosting.co.za> R. David Murray added the comment: This is a bit of a conundrum. Our (string module) definition of printable is very clear, and it includes the other whitespace characters. We could document that this does not match the posix definition of printable. It also does not match the RFC 5822 definition of printable (for example), which does *not* include whitespace characters (not even space), but the posix definition is a more likely source of confusion. isprintable is a newer function than string.printable, and serves a different purpose. I suppose that when PEP 3138 was written and implemented the disconnect between the two definitions was not noticed. For backward compatibility reasons I suspect we are stuck with the discrepancy, but perhaps others will think it worth the pain of changing string.printable. I kind of doubt it, though. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 16:24:49 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 09 Dec 2014 15:24:49 +0000 Subject: [issue23019] pyexpat.errors wrongly bound to message strings instead of message codes In-Reply-To: <1418111127.16.0.333870475533.issue23019@psf.upfronthosting.co.za> Message-ID: <1418138689.31.0.505872242396.issue23019@psf.upfronthosting.co.za> R. David Murray added the comment: The API is what it is. In the Python3 docs this is documented as a backward compatibility issue, and the workaround using the new errors.codes is provided. For 2.7 we are stuck with what we have, since we don't add new features to 2.7. ---------- nosy: +r.david.murray resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 16:38:49 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 09 Dec 2014 15:38:49 +0000 Subject: [issue23017] string.printable.isprintable() returns False In-Reply-To: <1418097121.16.0.891016494417.issue23017@psf.upfronthosting.co.za> Message-ID: <1418139529.28.0.421706892807.issue23017@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- components: +Unicode nosy: +ezio.melotti, haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 16:58:22 2014 From: report at bugs.python.org (Tom Tanner) Date: Tue, 09 Dec 2014 15:58:22 +0000 Subject: [issue21114] wsgiref.simple_server doesn't handle multi-line headers correctly In-Reply-To: <1396285351.75.0.166007035179.issue21114@psf.upfronthosting.co.za> Message-ID: <1418140702.32.0.156256649738.issue21114@psf.upfronthosting.co.za> Tom Tanner added the comment: This is actually more complicated than I initially thought. According to https://www.python.org/dev/peps/pep-3333/#the-start-response-callable "Each header_value must not include any control characters, including carriage returns or linefeeds, either embedded or at the end. (These requirements are to minimize the complexity of any parsing that must be performed by servers, gateways, and intermediate response processors that need to inspect or modify response headers.) " There's a discussion at https://mail.python.org/pipermail/web-sig/2006-September/002244.html It think the spec should be changed as parsing multi-line headers is really simple and sometimes necessary (e.g., when passing the X.509 client certificate). Anyway, attached you find a patch for Python 2.7.8 which includes a test and allows CR/LF in header values. ---------- Added file: http://bugs.python.org/file37401/wsgi.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 17:03:24 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 09 Dec 2014 16:03:24 +0000 Subject: [issue22939] integer overflow in iterator object In-Reply-To: <1416912993.1.0.671503723984.issue22939@psf.upfronthosting.co.za> Message-ID: <1418141004.13.0.914718556587.issue22939@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > The call to PySequence_GetItem() may be expensive, and we have to drop > the result if an OverflowError is raised after the call. You do realize that this error will be very rare and therefore inconsequential. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 17:03:49 2014 From: report at bugs.python.org (Dmitry Shachnev) Date: Tue, 09 Dec 2014 16:03:49 +0000 Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone constant In-Reply-To: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za> Message-ID: <1418141029.81.0.465535822694.issue22932@psf.upfronthosting.co.za> Dmitry Shachnev added the comment: Thanks, I did not know that. Here is version 3. ---------- Added file: http://bugs.python.org/file37402/issue22932_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 17:05:04 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 09 Dec 2014 16:05:04 +0000 Subject: [issue23021] Get rid of references to PyString in Modules/ Message-ID: <1418141104.02.0.91056311182.issue23021@psf.upfronthosting.co.za> New submission from Berker Peksag: See issue 22883 for a similar issue. Modules/_io/_iomodule.h:72:/* Printing a variable of type off_t (with e.g., PyString_FromFormat) Modules/_json.c:708: /* Read a JSON array from PyString pystr. Modules/_json.c:781: /* Read a JSON constant from PyString pystr. Modules/_sqlite/connection.h:55: /* None for autocommit, otherwise a PyString with the isolation level */ Modules/unicodedata.c:482: /* XXX: could allocate the PyString up front instead ---------- components: Extension Modules keywords: easy messages: 232387 nosy: berker.peksag, serhiy.storchaka priority: low severity: normal stage: needs patch status: open title: Get rid of references to PyString in Modules/ type: enhancement versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 17:09:16 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 09 Dec 2014 16:09:16 +0000 Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone constant In-Reply-To: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za> Message-ID: <1418141356.37.0.0355637437921.issue22932@psf.upfronthosting.co.za> R. David Murray added the comment: Yeah, only someone who has studied the RFCs would know that detail. I have no idea whether or not any email clients/processors actually *use* that distinction for anything, and I doubt there are very many humans who do :). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 17:14:01 2014 From: report at bugs.python.org (Demian Brecht) Date: Tue, 09 Dec 2014 16:14:01 +0000 Subject: [issue22992] Adding a git developer's guide to Mercurial to devguide In-Reply-To: <1417651753.19.0.905189748743.issue22992@psf.upfronthosting.co.za> Message-ID: <1418141641.71.0.552655277705.issue22992@psf.upfronthosting.co.za> Demian Brecht added the comment: > Contributors may need to update their repos before this step. It would be good to add a note about "git pull --rebase". Working through this flow actually exposed a blocking issue as far as this guide goes. As I understand it, because Mercurial sends hashes of all topological heads in headers, the size of the headers goes quite quickly as the number of topological heads increases. When the size of the headers exceeds what the server accepts, you run into 400 responses. Details in a blog post: http://barahilia.github.io/blog/computers/2014/10/09/hg-pull-via-http-fails-400.html One of the suggested options listed in https://bitbucket.org/site/master/issue/8263/http-400-bad-request-error-when-pulling is to use SSH rather than HTTPS, but is that even an option for non core devs? I'm investigating other options right now, but thanks for pointing out the merging Berker, it definitely pointed out a flaw in this workflow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 17:36:38 2014 From: report at bugs.python.org (Demian Brecht) Date: Tue, 09 Dec 2014 16:36:38 +0000 Subject: [issue22992] Adding a git developer's guide to Mercurial to devguide In-Reply-To: <1417651753.19.0.905189748743.issue22992@psf.upfronthosting.co.za> Message-ID: <1418142998.1.0.645450982569.issue22992@psf.upfronthosting.co.za> Demian Brecht added the comment: One option would be to increase LimitRequestFieldSize in Apache, but that really is only a stopgap solution as that limit will be hit again as one's local repo grows over time. It really would be nice to allow read only access via SSH, which isn't affected by the header issue, but I'm pretty sure that would entail a decent amount of work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 17:41:40 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 09 Dec 2014 16:41:40 +0000 Subject: [issue23016] uncatched exception in lib/warnings.py when executed with pythonw In-Reply-To: <1418127676.43.0.775038982485.issue23016@psf.upfronthosting.co.za> Message-ID: <28365320.uaPgMXpBTu@raxxla> Serhiy Storchaka added the comment: I afraid this will silence unexpected errors. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 17:45:18 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 09 Dec 2014 16:45:18 +0000 Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone constant In-Reply-To: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za> Message-ID: <1418143518.63.0.0554927015726.issue22932@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: v3 looks good to me. BTW, I knew that the sign of TZ 0000 was significant, but would have to look up the RFC to recall what the significance was. Thanks, David, for the explanation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 17:59:11 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 09 Dec 2014 16:59:11 +0000 Subject: [issue22992] Adding a git developer's guide to Mercurial to devguide In-Reply-To: <1418142998.1.0.645450982569.issue22992@psf.upfronthosting.co.za> Message-ID: <54872A5C.6010907@free.fr> Antoine Pitrou added the comment: Le 09/12/2014 17:36, Demian Brecht a ?crit : > > One option would be to increase LimitRequestFieldSize in Apache, but that really is only a stopgap solution as that limit will be hit again as one's local repo grows over time. It really would be nice to allow read only access via SSH, which isn't affected by the header issue, but I'm pretty sure that would entail a decent amount of work. Did you actually hit this issue with hg.python.org? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 18:12:14 2014 From: report at bugs.python.org (Demian Brecht) Date: Tue, 09 Dec 2014 17:12:14 +0000 Subject: [issue22992] Adding a git developer's guide to Mercurial to devguide In-Reply-To: <1417651753.19.0.905189748743.issue22992@psf.upfronthosting.co.za> Message-ID: <1418145134.58.0.0771941962322.issue22992@psf.upfronthosting.co.za> Demian Brecht added the comment: > Did you actually hit this issue with hg.python.org? Yes I did, with only one additional head: https://gist.github.com/demianbrecht/f525cceda8a0c99794ae. This would also lead me to believe that the public at large will also start hitting this with the introduction of new named branches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 18:37:51 2014 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 09 Dec 2014 17:37: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: <1418146671.82.0.0753022212078.issue23020@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Oh, has this ABI compatibility requirement changed from the 2.x series? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 18:39:34 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 09 Dec 2014 17:39:34 +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: <1418146774.02.0.293536652829.issue23020@psf.upfronthosting.co.za> Benjamin Peterson added the comment: We never had compatibility between 2.N and 2.(N + 1) either. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 18:45:54 2014 From: report at bugs.python.org (Pablo Aguiar) Date: Tue, 09 Dec 2014 17:45:54 +0000 Subject: [issue14787] pkgutil.walk_packages returns extra modules In-Reply-To: <1336813271.29.0.464157696844.issue14787@psf.upfronthosting.co.za> Message-ID: <1418147154.63.0.912676269885.issue14787@psf.upfronthosting.co.za> Changes by Pablo Aguiar : ---------- nosy: +scorphus _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 19:11:30 2014 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 09 Dec 2014 18:11:30 +0000 Subject: [issue18305] [patch] Fast sum() for non-numbers In-Reply-To: <1372228439.5.0.789865081817.issue18305@psf.upfronthosting.co.za> Message-ID: <1418148690.16.0.5014197907.issue18305@psf.upfronthosting.co.za> Guido van Rossum added the comment: The example code is a perversion and should not be encouraged. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 19:15:34 2014 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 09 Dec 2014 18:15:34 +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: <1418148934.66.0.725783908098.issue23020@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I would not mind the change, but I've always thought the opposite (except on Windows, where the string Python27.dll is stored in the .pyd) There are traces of this binary compatibility still today in the 3.4 headers: https://hg.python.org/cpython/file/v3.4.0/Include/pymem.h#l23 """...if you do use the macros you must recompile your extensions with each Python release...""" Which seems to imply that extensions usually don't need to be recompiled! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 19:50:05 2014 From: report at bugs.python.org (PJ Eby) Date: Tue, 09 Dec 2014 18:50:05 +0000 Subject: [issue21114] wsgiref.simple_server doesn't handle multi-line headers correctly In-Reply-To: <1418140702.32.0.156256649738.issue21114@psf.upfronthosting.co.za> Message-ID: PJ Eby added the comment: The fix for the server looks ok, but the validation and tests must not be changed, since they void spec compatibility and aren't a bug fix (and so must not be added to 2.7.) Indeed, if the validation library *doesn't* fail on CRLF, then *that* would be a bug, since it's supposed to tell you about every verifiable spec violation. Also, simple_server *should* unfold multiline headers, if it's not already doing so. (If it's not, it is a bug and can therefore be fixed in 2.7.) On Tue, Dec 9, 2014 at 10:58 AM, Tom Tanner wrote: > > Tom Tanner added the comment: > > This is actually more complicated than I initially thought. > According to https://www.python.org/dev/peps/pep-3333/#the-start-response-callable > "Each header_value must not include any control characters, including carriage returns or linefeeds, either embedded or at the end. (These requirements are to minimize the complexity of any parsing that must be performed by servers, gateways, and intermediate response processors that need to inspect or modify response headers.) " > > There's a discussion at https://mail.python.org/pipermail/web-sig/2006-September/002244.html > > It think the spec should be changed as parsing multi-line headers is really simple and sometimes necessary (e.g., when passing the X.509 client certificate). > > Anyway, attached you find a patch for Python 2.7.8 which includes a test and allows CR/LF in header values. > > ---------- > Added file: http://bugs.python.org/file37401/wsgi.diff > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 21:50:23 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 09 Dec 2014 20:50:23 +0000 Subject: [issue22848] Subparser help does not respect SUPPRESS argument In-Reply-To: <1415728297.74.0.809984326992.issue22848@psf.upfronthosting.co.za> Message-ID: <1418158223.1.0.639729250456.issue22848@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Targetting to 3.5 and nosying myself. It would be nice if it were possible to suppress the help of an entire subparser, but I took a quick look at the code and it seems tricky. ---------- nosy: +barry versions: +Python 3.5 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 22:29:46 2014 From: report at bugs.python.org (Valerie Lambert) Date: Tue, 09 Dec 2014 21:29:46 +0000 Subject: [issue1703178] link_objects in setup.cfg crashes build Message-ID: <1418160586.49.0.846901107498.issue1703178@psf.upfronthosting.co.za> Valerie Lambert added the comment: Fixed the typo and reuploaded. Thanks for spotting that! ---------- Added file: http://bugs.python.org/file37403/build_ext_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 9 23:07:32 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 09 Dec 2014 22:07:32 +0000 Subject: [issue1703178] link_objects in setup.cfg crashes build Message-ID: <1418162852.26.0.876702587536.issue1703178@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 00:01:07 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 09 Dec 2014 23:01:07 +0000 Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3 In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za> Message-ID: <1418166067.87.0.773630502996.issue13153@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- type: crash -> behavior versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 00:21:35 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 09 Dec 2014 23:21:35 +0000 Subject: [issue23014] Don't have importlib.abc.Loader.create_module() be optional In-Reply-To: <1418136788.4.0.287434233609.issue23014@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: OK, that sounds good to me, then. From a compatibility perspective, a porting note for 3.5 should cover it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 00:47:44 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 09 Dec 2014 23:47:44 +0000 Subject: [issue12602] Missing cross-references in Doc/using In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za> Message-ID: <20141209234739.118676.89670@psf.io> Roundup Robot added the comment: New changeset bd14c4e5ef00 by Berker Peksag in branch '3.4': Issue #12602: Add missing cross-references to runpy and using/cmdline docs. https://hg.python.org/cpython/rev/bd14c4e5ef00 New changeset 3a648b3d1694 by Berker Peksag in branch 'default': Issue #12602: Add missing cross-references to runpy and using/cmdline docs. https://hg.python.org/cpython/rev/3a648b3d1694 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 01:06:58 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 10 Dec 2014 00:06:58 +0000 Subject: [issue12602] Missing cross-references in Doc/using In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za> Message-ID: <20141210000655.50285.47905@psf.io> Roundup Robot added the comment: New changeset 078dbecf2e2c by Berker Peksag in branch '2.7': Issue #12602: Add missing cross-references to runpy and using/cmdline docs. https://hg.python.org/cpython/rev/078dbecf2e2c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 01:08:31 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 10 Dec 2014 00:08:31 +0000 Subject: [issue12602] Missing cross-references in Doc/using In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za> Message-ID: <1418170111.34.0.862203074397.issue12602@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, ?ric. ---------- assignee: eric.araujo -> berker.peksag nosy: +berker.peksag resolution: -> fixed stage: commit review -> resolved status: open -> closed type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 01:17:40 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 10 Dec 2014 00:17:40 +0000 Subject: [issue22823] Use set literals instead of creating a set from a list In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za> Message-ID: <1418170660.6.0.204894127641.issue22823@psf.upfronthosting.co.za> Berker Peksag added the comment: Updated Serhiy's patch. ---------- nosy: +berker.peksag Added file: http://bugs.python.org/file37404/issue22823-mock.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 01:34:00 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 10 Dec 2014 00:34:00 +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: <1418171640.7.0.935502742164.issue23020@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +lemburg, loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 01:34:04 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 10 Dec 2014 00:34:04 +0000 Subject: [issue17554] Compact output for regrtest In-Reply-To: <1364331735.49.0.0652208703783.issue17554@psf.upfronthosting.co.za> Message-ID: <20141210003358.88687.27827@psf.io> Roundup Robot added the comment: New changeset 8c337b4a8811 by Berker Peksag in branch 'default': Issue #17554: Print "fetching ..." messages only in verbose mode. https://hg.python.org/cpython/rev/8c337b4a8811 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 01:51:29 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 10 Dec 2014 00:51:29 +0000 Subject: [issue21775] shutil.copytree() crashes copying to VFAT on Linux: AttributeError: 'PermissionError' object has no attribute 'winerror' In-Reply-To: <1402868260.95.0.79401871707.issue21775@psf.upfronthosting.co.za> Message-ID: <20141210005124.127596.47269@psf.io> Roundup Robot added the comment: New changeset 50517a4d7cce by Berker Peksag in branch '3.4': Issue #21775: shutil.copytree(): fix crash when copying to VFAT https://hg.python.org/cpython/rev/50517a4d7cce New changeset 7d5754af95a9 by Berker Peksag in branch 'default': Issue #21775: shutil.copytree(): fix crash when copying to VFAT https://hg.python.org/cpython/rev/7d5754af95a9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 01:52:06 2014 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 10 Dec 2014 00:52:06 +0000 Subject: [issue19903] Idle: Use inspect.signature for calltips In-Reply-To: <1386289306.22.0.0855188637089.issue19903@psf.upfronthosting.co.za> Message-ID: <1418172726.7.0.358011516085.issue19903@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 01:55:37 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 10 Dec 2014 00:55:37 +0000 Subject: [issue21775] shutil.copytree() crashes copying to VFAT on Linux: AttributeError: 'PermissionError' object has no attribute 'winerror' In-Reply-To: <1402868260.95.0.79401871707.issue21775@psf.upfronthosting.co.za> Message-ID: <1418172937.0.0.714029309304.issue21775@psf.upfronthosting.co.za> Berker Peksag added the comment: Committed the patch with a NEWS entry. Thanks Greg. (You can send your SSH key to hgaccounts at python.org. See also https://docs.python.org/devguide/coredev.html#ssh) ---------- nosy: +berker.peksag resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 04:05:43 2014 From: report at bugs.python.org (Steve Dower) Date: Wed, 10 Dec 2014 03:05:43 +0000 Subject: [issue22919] Update PCBuild for VS 2015 In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za> Message-ID: <1418180743.08.0.336322665782.issue22919@psf.upfronthosting.co.za> Steve Dower added the comment: Rebased and updated NEWS, so here's a complete patch (and it's all in the latest change in https://hg.python.org/sandbox/steve.dower#Projects) ---------- Added file: http://bugs.python.org/file37405/round7complete.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 04:35:58 2014 From: report at bugs.python.org (Eric Snow) Date: Wed, 10 Dec 2014 03:35:58 +0000 Subject: [issue21600] mock.patch.stopall doesn't work with patch.dict to sys.modules In-Reply-To: <1401334528.48.0.358693350259.issue21600@psf.upfronthosting.co.za> Message-ID: <1418182558.65.0.726655532221.issue21600@psf.upfronthosting.co.za> Eric Snow added the comment: FYI, you probably don't want to be patching out sys.modules. It isn't guaranteed that doing so will have the expected effect on import semantics. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 06:12:11 2014 From: report at bugs.python.org (Eric Snow) Date: Wed, 10 Dec 2014 05:12:11 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1418188331.32.0.915642039705.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: I haven't had time for a while to do much work on this. At the last posting this patch was basically done. I'm sure it no longer applies cleanly. The biggest obstacle to wrapping this issue up is the size of the patch. It's hard to get a thorough review because someone would have to dedicate the time for it. Furthermore, adding this much code introduces a debatable risk which needs to be minimized. When I'm able to get back to this I'll likely split the patch up. I'd really like to introduce some helpers (perhaps macros) to the C API for writing iterators, since the boilerplate involved is massive; just take a look at how much code in my implementation involves the boilerplate of creating iterators. Unfortunately I don't know when my time will free up in the near future. I still hope to land this for 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 06:49:32 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 10 Dec 2014 05:49:32 +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: <1418190572.24.0.700699657264.issue23020@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: Extensions need not to be rebuilt only when using stable ABI: https://www.python.org/dev/peps/pep-0384/ But mytest.c fails to build with -DPy_LIMITED_API so it uses features from outside of stable ABI and must be rebuilt. ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 06:56:05 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 10 Dec 2014 05:56:05 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1418190965.14.0.299526208426.issue16991@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 07:01:16 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 10 Dec 2014 06:01:16 +0000 Subject: [issue17554] Compact output for regrtest In-Reply-To: <1364331735.49.0.0652208703783.issue17554@psf.upfronthosting.co.za> Message-ID: <1418191276.03.0.985551969426.issue17554@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 07:16:23 2014 From: report at bugs.python.org (=?utf-8?q?Bj=C3=B6rn_Karge?=) Date: Wed, 10 Dec 2014 06:16:23 +0000 Subject: [issue23019] pyexpat.errors wrongly bound to message strings instead of message codes In-Reply-To: <1418111127.16.0.333870475533.issue23019@psf.upfronthosting.co.za> Message-ID: <1418192183.33.0.296266937808.issue23019@psf.upfronthosting.co.za> Bj?rn Karge added the comment: I strongly disagree. The constants are just useless as they are (so this bug can hardly be considered a feature). The behaviour is not matching the 2.7 docs, so fixing it certainly won't be adding a new feature, and the python 3 behaviour can easily be preserved even if these constants are numbers. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 07:46:55 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 10 Dec 2014 06:46:55 +0000 Subject: [issue23014] Don't have importlib.abc.Loader.create_module() be optional In-Reply-To: <1418055538.78.0.471721917483.issue23014@psf.upfronthosting.co.za> Message-ID: <1418194015.3.0.774600454703.issue23014@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:11:26 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 10 Dec 2014 08:11:26 +0000 Subject: [issue17128] OS X system openssl deprecated - installer should build local libssl In-Reply-To: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za> Message-ID: <20141210081118.127612.91646@psf.io> Roundup Robot added the comment: New changeset 31f506f4e2d2 by Ned Deily in branch '2.7': Issue #17128: Use private version of OpenSSL for 2.7.9 OS X 10.5+ installer. https://hg.python.org/cpython/rev/31f506f4e2d2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 09:59:00 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 10 Dec 2014 08:59:00 +0000 Subject: [issue19104] pprint produces invalid output for long strings In-Reply-To: <1380289250.98.0.0529515271695.issue19104@psf.upfronthosting.co.za> Message-ID: <1418201940.64.0.197571488255.issue19104@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What to do with this issue? ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 10:43:38 2014 From: report at bugs.python.org (peerhash) Date: Wed, 10 Dec 2014 09:43:38 +0000 Subject: [issue23022] heap-use-after-free in find_maxchar_surrogates Message-ID: <1418204618.33.0.00964424099855.issue23022@psf.upfronthosting.co.za> New submission from peerhash: Line 27-29 trigger use-after-free. ================================================================= ==18203== ERROR: AddressSanitizer: heap-use-after-free on address 0x60080003b2e0 at pc 0x5e844f bp 0x7ffff5351750 sp 0x7ffff5351748 READ of size 4 at 0x60080003b2e0 thread T0 #0 0x5e844e in find_maxchar_surrogates ./cpython/Objects/unicodeobject.c:1428 #1 0x5ed62e in PyUnicode_FromUnicode ./cpython/Objects/unicodeobject.c:1822 #2 0x5f57cd in PyUnicode_FromWideChar ./cpython/Objects/unicodeobject.c:2311 #3 0x7f4ebbd00976 in Z_get /media/truecrypt1/bounty/cpython/Modules/_ctypes/cfield.c:1429 #4 0x7f4ebbcde48b in PyCData_get /media/truecrypt1/bounty/cpython/Modules/_ctypes/_ctypes.c:2756 #5 0x7f4ebbcf90b8 in PyCField_get /media/truecrypt1/bounty/cpython/Modules/_ctypes/cfield.c:230 #6 0x56ff34 in _PyObject_GenericGetAttrWithDict ./cpython/Objects/object.c:1059 #7 0x5704ee in PyObject_GenericGetAttr ./cpython/Objects/object.c:1119 #8 0x56f169 in PyObject_GetAttr ./cpython/Objects/object.c:889 #9 0x70ef2d in PyEval_EvalFrameEx ./cpython/Python/ceval.c:2442 #10 0x723c20 in fast_function ./cpython/Python/ceval.c:4368 #11 0x7234ea in call_function ./cpython/Python/ceval.c:4294 #12 0x715433 in PyEval_EvalFrameEx ./cpython/Python/ceval.c:2860 #13 0x71e164 in _PyEval_EvalCodeWithName ./cpython/Python/ceval.c:3610 #14 0x71e354 in PyEval_EvalCodeEx ./cpython/Python/ceval.c:3631 #15 0x6f7af3 in PyEval_EvalCode ./cpython/Python/ceval.c:773 #16 0x42ea99 in run_mod ./cpython/Python/pythonrun.c:968 #17 0x42e69f in PyRun_FileExFlags ./cpython/Python/pythonrun.c:921 #18 0x42b456 in PyRun_SimpleFileExFlags ./cpython/Python/pythonrun.c:394 #19 0x429ac3 in PyRun_AnyFileExFlags ./cpython/Python/pythonrun.c:80 #20 0x45624b in run_file ./cpython/Modules/main.c:318 #21 0x457717 in Py_Main ./cpython/Modules/main.c:767 #22 0x41b845 in main ./cpython/./Programs/python.c:69 #23 0x7f4ebc741ed4 in __libc_start_main ??:? #24 0x41b438 in _start /glibc-tmp-c47113ea580c02d806fd2bb53621c6f5/glibc-2.20/csu/../sysdeps/x86_64/start.S:122 0x60080003b2e0 is located 16 bytes inside of 37-byte region [0x60080003b2d0,0x60080003b2f5) freed by thread T0 here: #0 0x7f4ebd41d34a in __interceptor_free ??:? #1 0x41b9b5 in _PyMem_RawFree ./cpython/Objects/obmalloc.c:90 #2 0x41f4aa in _PyMem_DebugFree ./cpython/Objects/obmalloc.c:1892 #3 0x41c3db in PyMem_Free ./cpython/Objects/obmalloc.c:349 #4 0x502f7a in float_repr ./cpython/Objects/floatobject.c:275 #5 0x56d68a in PyObject_Str ./cpython/Objects/object.c:535 #6 0x500926 in PyFile_WriteObject ./cpython/Objects/fileobject.c:141 #7 0x6efe19 in builtin_print ./cpython/Python/bltinmodule.c:2243 #8 0x564fb5 in PyCFunction_Call ./cpython/Objects/methodobject.c:100 #9 0x72310c in call_function ./cpython/Python/ceval.c:4269 (discriminator 2) #10 0x715433 in PyEval_EvalFrameEx ./cpython/Python/ceval.c:2860 #11 0x723c20 in fast_function ./cpython/Python/ceval.c:4368 #12 0x7234ea in call_function ./cpython/Python/ceval.c:4294 #13 0x715433 in PyEval_EvalFrameEx ./cpython/Python/ceval.c:2860 #14 0x71e164 in _PyEval_EvalCodeWithName ./cpython/Python/ceval.c:3610 #15 0x71e354 in PyEval_EvalCodeEx ./cpython/Python/ceval.c:3631 #16 0x6f7af3 in PyEval_EvalCode ./cpython/Python/ceval.c:773 #17 0x42ea99 in run_mod ./cpython/Python/pythonrun.c:968 #18 0x42e69f in PyRun_FileExFlags ./cpython/Python/pythonrun.c:921 #19 0x42b456 in PyRun_SimpleFileExFlags ./cpython/Python/pythonrun.c:394 #20 0x429ac3 in PyRun_AnyFileExFlags ./cpython/Python/pythonrun.c:80 #21 0x45624b in run_file ./cpython/Modules/main.c:318 #22 0x457717 in Py_Main ./cpython/Modules/main.c:767 #23 0x41b845 in main ./cpython/./Programs/python.c:69 #24 0x7f4ebc741ed4 in __libc_start_main ??:? previously allocated by thread T0 here: #0 0x7f4ebd41d42a in malloc ??:? #1 0x41b918 in _PyMem_RawMalloc ./cpython/Objects/obmalloc.c:62 #2 0x41efe9 in _PyMem_DebugAlloc ./cpython/Objects/obmalloc.c:1838 #3 0x41f29e in _PyMem_DebugMalloc ./cpython/Objects/obmalloc.c:1861 #4 0x41c256 in PyMem_Malloc ./cpython/Objects/obmalloc.c:325 #5 0x78b7c0 in format_float_short ./cpython/Python/pystrtod.c:1094 #6 0x78c224 in PyOS_double_to_string ./cpython/Python/pystrtod.c:1231 #7 0x502ecb in float_repr ./cpython/Objects/floatobject.c:268 #8 0x56d68a in PyObject_Str ./cpython/Objects/object.c:535 #9 0x500926 in PyFile_WriteObject ./cpython/Objects/fileobject.c:141 #10 0x6efe19 in builtin_print ./cpython/Python/bltinmodule.c:2243 #11 0x564fb5 in PyCFunction_Call ./cpython/Objects/methodobject.c:100 #12 0x72310c in call_function ./cpython/Python/ceval.c:4269 (discriminator 2) #13 0x715433 in PyEval_EvalFrameEx ./cpython/Python/ceval.c:2860 #14 0x723c20 in fast_function ./cpython/Python/ceval.c:4368 #15 0x7234ea in call_function ./cpython/Python/ceval.c:4294 #16 0x715433 in PyEval_EvalFrameEx ./cpython/Python/ceval.c:2860 #17 0x71e164 in _PyEval_EvalCodeWithName ./cpython/Python/ceval.c:3610 #18 0x71e354 in PyEval_EvalCodeEx ./cpython/Python/ceval.c:3631 #19 0x6f7af3 in PyEval_EvalCode ./cpython/Python/ceval.c:773 #20 0x42ea99 in run_mod ./cpython/Python/pythonrun.c:968 #21 0x42e69f in PyRun_FileExFlags ./cpython/Python/pythonrun.c:921 #22 0x42b456 in PyRun_SimpleFileExFlags ./cpython/Python/pythonrun.c:394 #23 0x429ac3 in PyRun_AnyFileExFlags ./cpython/Python/pythonrun.c:80 #24 0x45624b in run_file ./cpython/Modules/main.c:318 #25 0x457717 in Py_Main ./cpython/Modules/main.c:767 #26 0x41b845 in main ./cpython/./Programs/python.c:69 #27 0x7f4ebc741ed4 in __libc_start_main ??:? Shadow bytes around the buggy address: 0x0c017ffff600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c017ffff610: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c017ffff620: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c017ffff630: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c017ffff640: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c017ffff650: fa fa fa fa fa fa fa fa fa fa fd fd[fd]fd fd fa 0x0c017ffff660: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa 0x0c017ffff670: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fa 0x0c017ffff680: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd fd 0x0c017ffff690: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 04 0x0c017ffff6a0: fa fa 00 00 00 00 00 04 fa fa fd fd fd fd fd fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap righ redzone: fb Freed Heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 ASan internal: fe ==18203== ABORTING ---------- components: ctypes files: repro.py hgrepos: 284 messages: 232417 nosy: peerhash priority: normal severity: normal status: open title: heap-use-after-free in find_maxchar_surrogates type: security versions: Python 3.5 Added file: http://bugs.python.org/file37406/repro.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 10:44:08 2014 From: report at bugs.python.org (peerhash) Date: Wed, 10 Dec 2014 09:44:08 +0000 Subject: [issue23022] heap-use-after-free in find_maxchar_surrogates In-Reply-To: <1418204618.33.0.00964424099855.issue23022@psf.upfronthosting.co.za> Message-ID: <1418204648.04.0.255593421094.issue23022@psf.upfronthosting.co.za> Changes by peerhash : ---------- hgrepos: -284 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 10:54:29 2014 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 10 Dec 2014 09:54:29 +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: <1418205269.1.0.847710840832.issue23020@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: PEP384 is presented as a new way to write modules that can be loaded by multiple Python versions, specially on Windows. I could not find any place that says that modules not using the stable ABI need to be recompiled. I'm not against changing this rule (after all, I started on Windows platform where all this discussion does not apply), but it should be clearly stated somewhere in the API docs, and also in the "whatsnew" pages (all of them?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 11:51:40 2014 From: report at bugs.python.org (Chaitanya agrawal) Date: Wed, 10 Dec 2014 10:51:40 +0000 Subject: [issue22918] Doc for __iter__ makes inexact comment about dict.__iter__ In-Reply-To: <1416689379.36.0.290921977035.issue22918@psf.upfronthosting.co.za> Message-ID: <1418208700.9.0.315381877106.issue22918@psf.upfronthosting.co.za> Changes by Chaitanya agrawal : ---------- keywords: +patch Added file: http://bugs.python.org/file37407/issue22918-inexactComment.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 12:26:24 2014 From: report at bugs.python.org (Chaitanya agrawal) Date: Wed, 10 Dec 2014 11:26:24 +0000 Subject: [issue22883] Get rid of references to PyInt in Py3 sources In-Reply-To: <1416147146.5.0.625860400609.issue22883@psf.upfronthosting.co.za> Message-ID: <1418210784.69.0.184613628604.issue22883@psf.upfronthosting.co.za> Changes by Chaitanya agrawal : ---------- keywords: +patch Added file: http://bugs.python.org/file37408/issue22883.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 13:02:08 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 10 Dec 2014 12:02:08 +0000 Subject: [issue22883] Get rid of references to PyInt in Py3 sources In-Reply-To: <1416147146.5.0.625860400609.issue22883@psf.upfronthosting.co.za> Message-ID: <1418212928.38.0.0560124878433.issue22883@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I doubt that just removing PyInt is correct. At least in longobject.h current comment looks correct. And in fcntlmodule.c and itertoolsmodule.c proposed changes look questionable. There are also mentions of PyInt_* in *.rst and *.py files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 13:30:33 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 10 Dec 2014 12:30:33 +0000 Subject: [issue23023] ./Modules/ld_so_aix not found on AIX during test_distutils Message-ID: <1418214633.02.0.849905032386.issue23023@psf.upfronthosting.co.za> New submission from Marc-Andre Lemburg: Here's the traceback from one of the AIX buildbots: [ 32/400] test_distutils unable to execute './Modules/ld_so_aix': No such file or directory [22429 refs] test test_distutils failed -- Traceback (most recent call last): File "/home/shager/cpython-buildarea/2.7.edelsohn-aix-ppc64/build/Lib/distutils/tests/test_build_ext.py", line 285, in test_get_outputs cmd.run() File "/home/shager/cpython-buildarea/2.7.edelsohn-aix-ppc64/build/Lib/distutils/command/build_ext.py", line 337, in run self.build_extensions() File "/home/shager/cpython-buildarea/2.7.edelsohn-aix-ppc64/build/Lib/distutils/command/build_ext.py", line 446, in build_extensions self.build_extension(ext) File "/home/shager/cpython-buildarea/2.7.edelsohn-aix-ppc64/build/Lib/distutils/command/build_ext.py", line 528, in build_extension target_lang=language) File "/home/shager/cpython-buildarea/2.7.edelsohn-aix-ppc64/build/Lib/distutils/ccompiler.py", line 691, in link_shared_object extra_preargs, extra_postargs, build_temp, target_lang) File "/home/shager/cpython-buildarea/2.7.edelsohn-aix-ppc64/build/Lib/distutils/unixccompiler.py", line 200, in link raise LinkError, msg LinkError: command './Modules/ld_so_aix' failed with exit status 1 (this is the build: http://buildbot.python.org/all/builders/PPC64%20AIX%202.7/builds/917) This appears to be related to issue18235 which was only fixed for 3.3 and 3.4. I guess a backport should fix the problem for Python 2.7 as well, but cannot test this. The result of traceback is AIX Python 2.7 always failing on the buildbot waterfall: http://buildbot.python.org/all/builders/PPC64%20AIX%202.7 ---------- components: Build, Distutils messages: 232420 nosy: dstufft, eric.araujo, lemburg priority: normal severity: normal status: open title: ./Modules/ld_so_aix not found on AIX during test_distutils versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 13:37:22 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 10 Dec 2014 12:37:22 +0000 Subject: [issue23023] ./Modules/ld_so_aix not found on AIX during test_distutils In-Reply-To: <1418214633.02.0.849905032386.issue23023@psf.upfronthosting.co.za> Message-ID: <1418215042.55.0.620814478211.issue23023@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: The problem also still exists on Python 3.4 (and probably 3.3 and 3.5 as well), even though these should have the patch from issue18235 applied: * http://buildbot.python.org/all/builders/PPC64%20AIX%203.4/builds/707 * http://buildbot.python.org/all/builders/PPC64%20AIX%203.4/builds/707/steps/test/logs/stdio Traceback: Traceback (most recent call last): File "/home/shager/cpython-buildarea/3.4.edelsohn-aix-ppc64/build/Lib/distutils/tests/test_build_ext.py", line 58, in test_build_ext cmd.run() File "/home/shager/cpython-buildarea/3.4.edelsohn-aix-ppc64/build/Lib/distutils/command/build_ext.py", line 339, in run self.build_extensions() File "/home/shager/cpython-buildarea/3.4.edelsohn-aix-ppc64/build/Lib/distutils/command/build_ext.py", line 448, in build_extensions self.build_extension(ext) File "/home/shager/cpython-buildarea/3.4.edelsohn-aix-ppc64/build/Lib/distutils/command/build_ext.py", line 535, in build_extension target_lang=language) File "/home/shager/cpython-buildarea/3.4.edelsohn-aix-ppc64/build/Lib/distutils/ccompiler.py", line 717, in link_shared_object extra_preargs, extra_postargs, build_temp, target_lang) File "/home/shager/cpython-buildarea/3.4.edelsohn-aix-ppc64/build/Lib/distutils/unixccompiler.py", line 196, in link raise LinkError(msg) distutils.errors.LinkError: command './Modules/ld_so_aix' failed with exit status 1 ---------- versions: +Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 13:38:56 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 10 Dec 2014 12:38:56 +0000 Subject: [issue23023] ./Modules/ld_so_aix not found on AIX during test_distutils In-Reply-To: <1418214633.02.0.849905032386.issue23023@psf.upfronthosting.co.za> Message-ID: <1418215136.62.0.626565603223.issue23023@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Note that the helper Modules/ld_so_aix is created during configure. Just the path to the helper in the sysconfig data is wrong (relative to the current dir, which will most likely always be wrong except for a few special situations such as when building Python itself). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 13:39:08 2014 From: report at bugs.python.org (Tom Tanner) Date: Wed, 10 Dec 2014 12:39:08 +0000 Subject: [issue21114] wsgiref.simple_server doesn't handle multi-line headers correctly In-Reply-To: <1396285351.75.0.166007035179.issue21114@psf.upfronthosting.co.za> Message-ID: <1418215148.33.0.4586542942.issue21114@psf.upfronthosting.co.za> Tom Tanner added the comment: attached is the updated patch, which unfolds multiline headers but not validate them (tests included). ---------- Added file: http://bugs.python.org/file37409/wsgi2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 14:09:22 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 10 Dec 2014 13:09:22 +0000 Subject: [issue23016] uncatched exception in lib/warnings.py when executed with pythonw In-Reply-To: <1418088423.32.0.545997731561.issue23016@psf.upfronthosting.co.za> Message-ID: <1418216962.18.0.826032389899.issue23016@psf.upfronthosting.co.za> STINNER Victor added the comment: warnings_stderr_none.patch looks good to me. It can be applied on Python 2.7, 3.4 and 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 14:11:02 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 10 Dec 2014 13:11:02 +0000 Subject: [issue21775] shutil.copytree() crashes copying to VFAT on Linux: AttributeError: 'PermissionError' object has no attribute 'winerror' In-Reply-To: <1402868260.95.0.79401871707.issue21775@psf.upfronthosting.co.za> Message-ID: <1418217061.99.0.245608800335.issue21775@psf.upfronthosting.co.za> STINNER Victor added the comment: Note: Python 2.7 is not affected, I cannot find "winerror" in shutil.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 15:27:48 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 10 Dec 2014 14:27:48 +0000 Subject: [issue23019] pyexpat.errors wrongly bound to message strings instead of message codes In-Reply-To: <1418111127.16.0.333870475533.issue23019@psf.upfronthosting.co.za> Message-ID: <1418221668.27.0.0627802445758.issue23019@psf.upfronthosting.co.za> R. David Murray added the comment: For backward compatibility reasons this *can not be changed*. We are stuck with it, even though we agree it is broken. Please do not reopen the issue. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 15:36:44 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 10 Dec 2014 14:36:44 +0000 Subject: [issue23019] pyexpat.errors wrongly bound to message strings instead of message codes In-Reply-To: <1418111127.16.0.333870475533.issue23019@psf.upfronthosting.co.za> Message-ID: <1418222204.04.0.936976772319.issue23019@psf.upfronthosting.co.za> R. David Murray added the comment: Actually, I'm going to reopen it as a doc issue. This should be explained in the 2.7 docs. ---------- assignee: -> docs at python components: +Documentation -Library (Lib) nosy: +docs at python status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 15:46:57 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 10 Dec 2014 14:46:57 +0000 Subject: [issue23019] pyexpat.errors wrongly bound to message strings instead of message codes In-Reply-To: <1418111127.16.0.333870475533.issue23019@psf.upfronthosting.co.za> Message-ID: <1418222817.58.0.0765119454999.issue23019@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +easy stage: resolved -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 15:51:48 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 10 Dec 2014 14:51:48 +0000 Subject: [issue22918] Doc for __iter__ makes inexact comment about dict.__iter__ In-Reply-To: <1416689379.36.0.290921977035.issue22918@psf.upfronthosting.co.za> Message-ID: <20141210145145.50271.65291@psf.io> Roundup Robot added the comment: New changeset 743ebaba14db by R David Murray in branch '3.4': #22918: Drop obsolete mention of 'keys' in datamodel __iter__ docs. https://hg.python.org/cpython/rev/743ebaba14db New changeset 1a1f577ca647 by R David Murray in branch 'default': Merge: #22918: Drop obsolete mention of 'keys' in datamodel __iter__ docs. https://hg.python.org/cpython/rev/1a1f577ca647 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 15:52:41 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 10 Dec 2014 14:52:41 +0000 Subject: [issue22918] Doc for __iter__ makes inexact comment about dict.__iter__ In-Reply-To: <1416689379.36.0.290921977035.issue22918@psf.upfronthosting.co.za> Message-ID: <1418223161.18.0.528340534286.issue22918@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Chaitanya. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 15:58:24 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 10 Dec 2014 14:58:24 +0000 Subject: [issue23016] uncaught exception in lib/warnings.py when executed with pythonw In-Reply-To: <1418088423.32.0.545997731561.issue23016@psf.upfronthosting.co.za> Message-ID: <1418223504.42.0.170886409979.issue23016@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- title: uncatched exception in lib/warnings.py when executed with pythonw -> uncaught exception in lib/warnings.py when executed with pythonw _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 16:15:59 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 10 Dec 2014 15:15:59 +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: <1418224559.74.0.279842419994.issue23020@psf.upfronthosting.co.za> Benjamin Peterson added the comment: This is why C-extensions' PEP 3147 file tags depend on Python version. I agree the policy could stand to be documented. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 16:28:01 2014 From: report at bugs.python.org (Brett Cannon) Date: Wed, 10 Dec 2014 15:28:01 +0000 Subject: [issue23014] Don't have importlib.abc.Loader.create_module() be optional In-Reply-To: <1418055538.78.0.471721917483.issue23014@psf.upfronthosting.co.za> Message-ID: <1418225281.92.0.633506978606.issue23014@psf.upfronthosting.co.za> Brett Cannon added the comment: What do you think about requiring create_module() and/or not supporting a None value return? The only reason I ask is to think through the ramifications and how long to raise a DeprecationWarning. I think I can live with having a reasonable default if create_module() isn't defined, but also supporting None seems a bit much. Or I can live with a None value to have import just do the most reasonable thing, but you should then explicitly ask for that by returning None. Or we just go full-on explicit and require create_module() and that it return the object to use. So assuming we go with the latter, that means people who chose to not subclass importlib.abc.Loader will have to now implement create_module(). In Python 3.5 that's easy since importlib.util.module_from_spec() now exists. But if you're supporting older versions it's a bit more work since there was only types.ModuleType() and that didn't fill in all attributes since it was missing key bits of information that is now (potentially) in the spec. That means if someone wants to be compatible from 3.4 on then it will be a bit of work to do properly. That means either a deprecation cycle that is long enough to outlast code that wants to work in 3.4 or we don't go as far and support either returning None *or* not defining create_module(). My gut says to either deprecate both options and make the deprecation last until Python 4 or to require create_module() but allow for the returning of None and have that last only a single release since adding a create_module() that returns None takes no effort and is fully backwards-compatible (my reasoning for the latter is that screwing up to return None when you meant a module is easier to debug than accidentally typing the method name, plus it means people calling super() won't break in a transition). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 17:01:37 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 10 Dec 2014 16:01:37 +0000 Subject: [issue23014] Don't have importlib.abc.Loader.create_module() be optional In-Reply-To: <1418055538.78.0.471721917483.issue23014@psf.upfronthosting.co.za> Message-ID: <1418227297.75.0.471458027.issue23014@psf.upfronthosting.co.za> Nick Coghlan added the comment: The specific reason I wanted the "return None to delegate to the default behaviour" feature was to make it easier to migrate the C extension machinery. With that design, a PEP 451 based C extension loader would just need to return None when there was no appropriate "Create" symbol exported from the module. If returning None was disallowed, it would need to instead arrange to call importlib.util.module_from_spec(). That's doable, of course, but requires loaders to reimplement behaviour provided by the standard import system, rather than being able to just say "do the default thing, whatever that happens to be". That's the kind of really easy to get wrong responsibility I appreciated PEP 451 taking *away* from custom loaders. However, I have no problem with making create_module() mandatory if the "return None to request the default behaviour" feature is retained. As you say, adding an implementation that returns None is both easy and remains compatible with Python 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 17:11:22 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 10 Dec 2014 16:11:22 +0000 Subject: [issue17128] OS X system openssl deprecated - installer should build local libssl In-Reply-To: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za> Message-ID: <20141210154705.56382.3576@psf.io> Roundup Robot added the comment: New changeset 2b5fa8651bd0 by Ned Deily in branch '2.7': Issue #17128: Use private version of OpenSSL for 2.7.9 OS X 10.5+ installer. https://hg.python.org/cpython/rev/2b5fa8651bd0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 17:49:32 2014 From: report at bugs.python.org (zhuoyikang) Date: Wed, 10 Dec 2014 16:49:32 +0000 Subject: [issue23024] Python Compile Error on Mac os X ld: unknown option: -export-dynamic Message-ID: <1418230172.81.0.749154265279.issue23024@psf.upfronthosting.co.za> New submission from zhuoyikang: /Applications/Xcode.app/Contents/Developer/usr/bin/make Parser/pgen gcc -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -L/usr/local/lib -export-dynamic Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/dynamic_annotations.o Python/mysnprintf.o Python/pyctype.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/parsetok_pgen.o Parser/pgenmain.o -ldl -framework CoreFoundation -o Parser/pgen ld: unknown option: -export-dynamic collect2: error: ld returned 1 exit status make[1]: *** [Parser/pgen] Error 1 make: *** [Include/graminit.h] Error 2 ---------- components: Cross-Build messages: 232434 nosy: zhuoyikang priority: normal severity: normal status: open title: Python Compile Error on Mac os X ld: unknown option: -export-dynamic versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 17:57:58 2014 From: report at bugs.python.org (Michael Foord) Date: Wed, 10 Dec 2014 16:57:58 +0000 Subject: [issue21600] mock.patch.stopall doesn't work with patch.dict to sys.modules In-Reply-To: <1401334528.48.0.358693350259.issue21600@psf.upfronthosting.co.za> Message-ID: <1418230678.76.0.361826080613.issue21600@psf.upfronthosting.co.za> Michael Foord added the comment: why not? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 19:16:06 2014 From: report at bugs.python.org (Alex Gaynor) Date: Wed, 10 Dec 2014 18:16:06 +0000 Subject: [issue23025] ssl.RAND_bytes docs should mention os.urandom Message-ID: <1418235366.16.0.20927959194.issue23025@psf.upfronthosting.co.za> New submission from Alex Gaynor: For almost any conceivable application, os.urandom is a preferable way to access a CSPRNG, and is less error prone, the docs should point this out. ---------- assignee: docs at python components: Documentation files: rand.diff keywords: patch messages: 232436 nosy: alex, docs at python priority: normal severity: normal status: open title: ssl.RAND_bytes docs should mention os.urandom Added file: http://bugs.python.org/file37410/rand.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 19:23:32 2014 From: report at bugs.python.org (Donald Stufft) Date: Wed, 10 Dec 2014 18:23:32 +0000 Subject: [issue23025] ssl.RAND_bytes docs should mention os.urandom In-Reply-To: <1418235366.16.0.20927959194.issue23025@psf.upfronthosting.co.za> Message-ID: <1418235812.48.0.464938550086.issue23025@psf.upfronthosting.co.za> Donald Stufft added the comment: I agree completely. This is something that should generally be discouraged all together. See: http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ ---------- nosy: +dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 19:39:27 2014 From: report at bugs.python.org (Simon Zack) Date: Wed, 10 Dec 2014 18:39:27 +0000 Subject: [issue14965] super() and property inheritance behavior In-Reply-To: <1338433441.66.0.975494137492.issue14965@psf.upfronthosting.co.za> Message-ID: <1418236767.39.0.102946217339.issue14965@psf.upfronthosting.co.za> Simon Zack added the comment: +1 to this feature, this will dramatically simplify property setting code. ---------- nosy: +simonzack _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 20:03:11 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 10 Dec 2014 19:03:11 +0000 Subject: [issue22518] integer overflow in encoding unicode In-Reply-To: <1412024485.39.0.908219343503.issue22518@psf.upfronthosting.co.za> Message-ID: <1418238191.19.0.99490579574.issue22518@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 20:07:11 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 10 Dec 2014 19:07:11 +0000 Subject: [issue22520] integer overflow in computing unicode's object representation In-Reply-To: <1412024659.14.0.152968090659.issue22520@psf.upfronthosting.co.za> Message-ID: <1418238431.32.0.557905411637.issue22520@psf.upfronthosting.co.za> Benjamin Peterson added the comment: As Serhiy has noted on other bugs, the fact that the tests must be restricted to 32-bits limits their usefulness unfortunately. ---------- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 20:11:38 2014 From: report at bugs.python.org (Colton Leekley-Winslow) Date: Wed, 10 Dec 2014 19:11:38 +0000 Subject: [issue21600] mock.patch.stopall doesn't work with patch.dict to sys.modules In-Reply-To: <1401334528.48.0.358693350259.issue21600@psf.upfronthosting.co.za> Message-ID: <1418238698.53.0.637586825501.issue21600@psf.upfronthosting.co.za> Colton Leekley-Winslow added the comment: Patching sys.modules is an idea I got from the official documentation https://docs.python.org/3/library/unittest.mock.html#patch-dict http://mock.readthedocs.org/en/latest/patch.html#patch-dict ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 20:38:02 2014 From: report at bugs.python.org (Ned Deily) Date: Wed, 10 Dec 2014 19:38:02 +0000 Subject: [issue23024] Python Compile Error on Mac os X ld: unknown option: -export-dynamic In-Reply-To: <1418230172.81.0.749154265279.issue23024@psf.upfronthosting.co.za> Message-ID: <1418240282.06.0.296755524713.issue23024@psf.upfronthosting.co.za> Ned Deily added the comment: The -export-dynamic compile option is not supported nor selected at configure time for normal builds on OS X. Exactly what configure options did you use? I see that you have checked Cross-Build for components. What sort of cross-building are you attempting? ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 21:13:54 2014 From: report at bugs.python.org (Mark Grandi) Date: Wed, 10 Dec 2014 20:13:54 +0000 Subject: [issue23026] Winreg module doesn't support REG_QWORD, small DWORD doc update Message-ID: <1418242433.97.0.849861872047.issue23026@psf.upfronthosting.co.za> New submission from Mark Grandi: The winreg module has constants for the different Windows registry types: https://docs.python.org/3/library/winreg.html?highlight=winreg#value-types It also links to the Microsoft documentation on the registry types, and I noticed that python doesn't have constants for 2 of the types (really just 1), REG_QWORD and REG_QWORD_LITTLE_ENDIAN (same as REG_QWORD). So I added the constants in winreg.c, which I think is right, as its the same format as the other ones, and I edited the documentation inside of winreg.c, which is the same changes i made to the docs in winreg.rst, except it doesn't have the markdown/rst/whatever formatting markers. I also made notes on REG_DWORD_LITTLE_ENDIAN that it is equivalent to REG_DWORD. I also tested to make sure that the documentation builds fine, but I haven't tested building python with the winreg.c changes, as I don't have access to a windows computer that can compile it at the moment. Some concerns: 1: I have no idea if REG_QWORD is defined on 32 bit windows, I would assume it would be, but I can't check at the moment. 2: There should probably be some switch statement entries in the Reg2Py() and Py2Reg() functions that deal with QWORDs, and dealing with if the python build is 32 bit vs 64 bit. I'm not comfortable with the python C internals to do that myself. My initial patch is attached, with the documentation + changes to winreg.c that just add the constants to the module ---------- components: Windows files: winreg_add_qword_constants_part1_markgrandi.patch keywords: patch messages: 232442 nosy: markgrandi, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Winreg module doesn't support REG_QWORD, small DWORD doc update versions: Python 3.4 Added file: http://bugs.python.org/file37411/winreg_add_qword_constants_part1_markgrandi.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 22:12:49 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 10 Dec 2014 21:12:49 +0000 Subject: [issue23016] uncaught exception in lib/warnings.py when executed with pythonw In-Reply-To: <1418088423.32.0.545997731561.issue23016@psf.upfronthosting.co.za> Message-ID: <20141210211233.50285.25112@psf.io> Roundup Robot added the comment: New changeset d04dab84388f by Serhiy Storchaka in branch '3.4': Issue #23016: A warning no longer produces AttributeError when the program https://hg.python.org/cpython/rev/d04dab84388f New changeset 0050e770b34c by Serhiy Storchaka in branch 'default': Issue #23016: A warning no longer produces an AttributeError when the program https://hg.python.org/cpython/rev/0050e770b34c New changeset aeeec8a4b9b8 by Serhiy Storchaka in branch '2.7': Issue #23016: A warning no longer produces an AttributeError when sys.stderr https://hg.python.org/cpython/rev/aeeec8a4b9b8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 22:22:27 2014 From: report at bugs.python.org (Demian Brecht) Date: Wed, 10 Dec 2014 21:22:27 +0000 Subject: [issue22992] Adding a git developer's guide to Mercurial to devguide In-Reply-To: <1417651753.19.0.905189748743.issue22992@psf.upfronthosting.co.za> Message-ID: <1418246547.57.0.280552826091.issue22992@psf.upfronthosting.co.za> Demian Brecht added the comment: After some further investigation, this seems to be what's happening. Note: this is based on a small amount of research and hasn't been validated by any mercurial devs, so it might be missing key pieces: In cases where a local topological head is unknown to a remote, the commit history of that head's branch is sent to the remote server for comparison. This /is/ chunked, but it seems that the number of commits sent per request is hardcoded to 200 (in Mercurial 2.9.2 at any rate). Because 200 commit hashes are added to the header, the size of the header is greater than what is allowed by the app server (I'm seeing > 8k headers when the discovery step runs with my changes) leading to the error responses when using HTTP(S). So, to encounter this issue, the following must be true: * The user must have a topological head that the remote is unaware of * The number of commits resulting from a DAG traversal must result in a header that exceeds the allowed limits of the given app server Because the discovery requests are chunked, if the allowed header size was increased on the app server to account for the worst case scenario (200 commit hashes), this problem should be fixed and not encountered again as I previously thought would be the case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 22:25:19 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 10 Dec 2014 21:25:19 +0000 Subject: [issue22992] Adding a git developer's guide to Mercurial to devguide In-Reply-To: <1417651753.19.0.905189748743.issue22992@psf.upfronthosting.co.za> Message-ID: <1418246719.21.0.365095577315.issue22992@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I suggest you post your findings on the mercurial mailing-list (http://selenic.com/mailman/listinfo/mercurial, there's a gmane mirror also). I would be surprised if there weren't an easy way of circumventing it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 22:51:35 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 10 Dec 2014 21:51:35 +0000 Subject: [issue23027] test_warnings fails with -Werror Message-ID: <1418248295.01.0.00165630152899.issue23027@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: $ ./python -Werror -m test.regrtest -v test_warnings ... ====================================================================== ERROR: test_warning_classes (test.test_warnings.CWarnTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/test/test_warnings.py", line 460, in test_warning_classes self.module.warn('good warning category', MyWarningClass) test.test_warnings.WarnTests.test_warning_classes..MyWarningClass: good warning category ====================================================================== ERROR: test_warning_classes (test.test_warnings.PyWarnTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/test/test_warnings.py", line 460, in test_warning_classes self.module.warn('good warning category', MyWarningClass) File "/home/serhiy/py/cpython/Lib/warnings.py", line 204, in warn globals) File "/home/serhiy/py/cpython/Lib/warnings.py", line 249, in warn_explicit raise message test.test_warnings.WarnTests.test_warning_classes..MyWarningClass: good warning category ---------------------------------------------------------------------- This is 3.x only issue. ---------- components: Tests messages: 232446 nosy: serhiy.storchaka priority: normal severity: normal status: open title: test_warnings fails with -Werror type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 22:58:49 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 10 Dec 2014 21:58:49 +0000 Subject: [issue23028] CEnvironmentVariableTests and PyEnvironmentVariableTests test the same implementation Message-ID: <1418248729.18.0.338181805026.issue23028@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: CEnvironmentVariableTests and PyEnvironmentVariableTests are purposed to test C and Python implementations. But they are test the same implementation because execute test code in a subprocess and changes of sys.modules in current process don't affect a subprocess. ---------- components: Tests messages: 232447 nosy: serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: CEnvironmentVariableTests and PyEnvironmentVariableTests test the same implementation type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 23:08:11 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 10 Dec 2014 22:08:11 +0000 Subject: [issue23029] test_warnings produces extra output in quit mode Message-ID: <1418249291.77.0.334327768838.issue23029@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: $ ./python -m test.regrtest -q test_warnings test.test_warnings:559: UserWarning: test This is 2.7 only issue. ---------- components: Tests messages: 232448 nosy: serhiy.storchaka priority: normal severity: normal status: open title: test_warnings produces extra output in quit mode type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 23:08:57 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 10 Dec 2014 22:08:57 +0000 Subject: [issue23016] uncaught exception in lib/warnings.py when executed with pythonw In-Reply-To: <1418088423.32.0.545997731561.issue23016@psf.upfronthosting.co.za> Message-ID: <1418249337.23.0.907461526865.issue23016@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 23:11:32 2014 From: report at bugs.python.org (Demian Brecht) Date: Wed, 10 Dec 2014 22:11:32 +0000 Subject: [issue22992] Adding a git developer's guide to Mercurial to devguide In-Reply-To: <1417651753.19.0.905189748743.issue22992@psf.upfronthosting.co.za> Message-ID: <1418249492.13.0.0632909878944.issue22992@psf.upfronthosting.co.za> Demian Brecht added the comment: The issue and solution was confirmed on IRC in #mercurial by mpm (Matt Mackall). According to him, there is also no easy way to change this behaviour from the client. The problem isn't /really/ a Mercurial issue, but an issue with web server specific defaults. The default for Apache (which is what is being used here, correct?) is 8k. The worst case header size was ~8.4k. So I'd say that upping the limit to 9k or 10k would account for the worst case scenario as well as add a small buffer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 23:20:56 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 10 Dec 2014 22:20:56 +0000 Subject: [issue23027] test_warnings fails with -Werror In-Reply-To: <1418248295.01.0.00165630152899.issue23027@psf.upfronthosting.co.za> Message-ID: <1418250056.15.0.723078872516.issue23027@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 23:31:50 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 10 Dec 2014 22:31:50 +0000 Subject: [issue23029] test_warnings produces extra output in quiet mode In-Reply-To: <1418249291.77.0.334327768838.issue23029@psf.upfronthosting.co.za> Message-ID: <1418250710.86.0.945306348471.issue23029@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- title: test_warnings produces extra output in quit mode -> test_warnings produces extra output in quiet mode _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 23:35:47 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 10 Dec 2014 22:35:47 +0000 Subject: [issue19527] Test failures with COUNT_ALLOCS In-Reply-To: <1383913813.74.0.198352256395.issue19527@psf.upfronthosting.co.za> Message-ID: <1418250947.0.0.0424863175714.issue19527@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Tests nosy: +serhiy.storchaka stage: -> patch review type: -> behavior versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 23:40:04 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 10 Dec 2014 22:40:04 +0000 Subject: [issue19527] Test failures with COUNT_ALLOCS In-Reply-To: <1383913813.74.0.198352256395.issue19527@psf.upfronthosting.co.za> Message-ID: <1418251204.59.0.852157540323.issue19527@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Why do you check hasattr(sys, 'getrefcount') in test_io.py, but hasattr(sys, 'getcounts') in all other tests? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 23:55:00 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 10 Dec 2014 22:55:00 +0000 Subject: [issue18383] test_warnings modifies warnings.filters when running with "-W default" In-Reply-To: <1373117774.47.0.846306714059.issue18383@psf.upfronthosting.co.za> Message-ID: <1418252100.75.0.224950294536.issue18383@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch fixes symptoms. It would be better to fix the cause of the issue -- warnings.filters shouldn't duplicate after module reloading. ---------- nosy: +serhiy.storchaka versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 10 23:55:40 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 10 Dec 2014 22:55:40 +0000 Subject: [issue14784] Re-importing _warnings changes warnings.filters In-Reply-To: <1336765216.03.0.0611996113989.issue14784@psf.upfronthosting.co.za> Message-ID: <1418252140.65.0.605177324371.issue14784@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Issue18383 is a duplicate of this issue but it has a patch (not perfect). ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 00:28:55 2014 From: report at bugs.python.org (Michael Foord) Date: Wed, 10 Dec 2014 23:28:55 +0000 Subject: [issue22823] Use set literals instead of creating a set from a list In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za> Message-ID: <1418254135.22.0.853558026461.issue22823@psf.upfronthosting.co.za> Michael Foord added the comment: Patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 00:50:57 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 10 Dec 2014 23:50:57 +0000 Subject: [issue23006] Improve the doc and indexing of adict.__missing__. In-Reply-To: <1417985369.96.0.326358204226.issue23006@psf.upfronthosting.co.za> Message-ID: <20141210235048.54572.86169@psf.io> Roundup Robot added the comment: New changeset 0fe3fb886c38 by Terry Jan Reedy in branch '2.7': Issue #23006: Improve the documentation and indexing of dict.__missing__. https://hg.python.org/cpython/rev/0fe3fb886c38 New changeset 31875b244bdf by Terry Jan Reedy in branch '3.4': Issue #23006: Improve the documentation and indexing of dict.__missing__. https://hg.python.org/cpython/rev/31875b244bdf New changeset 41b172fd4479 by Terry Jan Reedy in branch '3.4': Issue #23006 whitespace https://hg.python.org/cpython/rev/41b172fd4479 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 01:02:50 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 11 Dec 2014 00:02:50 +0000 Subject: [issue23006] Improve the doc and indexing of adict.__missing__. In-Reply-To: <1417985369.96.0.326358204226.issue23006@psf.upfronthosting.co.za> Message-ID: <1418256170.08.0.805781951886.issue23006@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I made a couple more minor revisions to the 3.4 stdtypes text and copied the revised paragraph, with the code example, to 2.7 ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 01:05:09 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 11 Dec 2014 00:05:09 +0000 Subject: [issue20866] segfailt with os.popen and SIGPIPE In-Reply-To: <1394216549.17.0.426654108401.issue20866@psf.upfronthosting.co.za> Message-ID: <1418256309.49.0.89467288434.issue20866@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> fixed stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 02:02:24 2014 From: report at bugs.python.org (Demian Brecht) Date: Thu, 11 Dec 2014 01:02:24 +0000 Subject: [issue22992] Adding a git developer's guide to Mercurial to devguide In-Reply-To: <1417651753.19.0.905189748743.issue22992@psf.upfronthosting.co.za> Message-ID: <1418259744.96.0.139179785456.issue22992@psf.upfronthosting.co.za> Demian Brecht added the comment: I've added a section about rebasing and removed the comment about merging. Of course, I'm assuming that the config changes can be made to Apache to allow for this workflow. ---------- Added file: http://bugs.python.org/file37412/issue22992_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 02:05:11 2014 From: report at bugs.python.org (Demian Brecht) Date: Thu, 11 Dec 2014 01:05:11 +0000 Subject: [issue22225] Add SQLite support to http.cookiejar In-Reply-To: <1408387746.24.0.600227999545.issue22225@psf.upfronthosting.co.za> Message-ID: <1418259911.46.0.788303481507.issue22225@psf.upfronthosting.co.za> Demian Brecht added the comment: Coming back to this, it's likely a bad idea as an addition to the standard library as an update may be required out of band with scheduled deployments should schemas and such change. This is best developed as an external module. Closing. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 04:52:13 2014 From: report at bugs.python.org (Eric Snow) Date: Thu, 11 Dec 2014 03:52:13 +0000 Subject: [issue21600] mock.patch.stopall doesn't work with patch.dict to sys.modules In-Reply-To: <1401334528.48.0.358693350259.issue21600@psf.upfronthosting.co.za> Message-ID: <1418269933.69.0.494646006026.issue21600@psf.upfronthosting.co.za> Eric Snow added the comment: At least for CPython sys.modules is initially set to the modules dict on the interpreter struct. As of 3.4 the import system itself only cares about sys.modules (I'll have to double check on builtin___import__). However, if I recall correctly at least part of the import C-API interacts directly with the original interpreter copy of the modules dict. The catch is that setting sys.modules to something else does not also change the dict on the interpreter struct. So they will be out of sync. This may cause problems. In practice I don't think it's a big deal, but there is no guarantee that patching out sys.modules will give you the behavior that you expect. See also issue #12633. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 06:17:58 2014 From: report at bugs.python.org (zhuoyikang) Date: Thu, 11 Dec 2014 05:17:58 +0000 Subject: [issue23024] Python Compile Error on Mac os X ld: unknown option: -export-dynamic In-Reply-To: <1418240282.06.0.296755524713.issue23024@psf.upfronthosting.co.za> Message-ID: zhuoyikang added the comment: Sorry, i am not cross-build , i just building it on my mac os x machine : i fellow this => Build Instructions ------------------ On Unix, Linux, BSD, OSX, and Cygwin: New text ./configure make make test sudo make install This will install Python as python3. 2014-12-11 3:38 GMT+08:00 Ned Deily : > > Ned Deily added the comment: > > The -export-dynamic compile option is not supported nor selected at > configure time for normal builds on OS X. Exactly what configure options > did you use? I see that you have checked Cross-Build for components. What > sort of cross-building are you attempting? > > ---------- > nosy: +ned.deily > > _______________________________________ > Python tracker > > _______________________________________ > ---------- title: Python Compile Error on Mac os X ld: unknown option: -export-dynamic -> Python Compile Error on Mac os X ld: unknown option: -export-dynamic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 07:42:09 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 11 Dec 2014 06:42:09 +0000 Subject: [issue23024] Python Compile Error on Mac os X ld: unknown option: -export-dynamic In-Reply-To: <1418230172.81.0.749154265279.issue23024@psf.upfronthosting.co.za> Message-ID: <1418280129.56.0.00952071552031.issue23024@psf.upfronthosting.co.za> Ned Deily added the comment: That should work just fine, assuming you are using an unmodified Python 3.4.x source download or the 3.4 branch of a source repo. My best guess as to why you are running into problems is that you may be picking up build tools other than those supplied by Apple. On recent versions of OS X, make sure you have run 'sudo xcode-select --install' to install the latest version of the command line tools and check your shell $PATH variable. There may be clues in the config.log file produced by running ./configure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 08:05:29 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 11 Dec 2014 07:05:29 +0000 Subject: [issue22823] Use set literals instead of creating a set from a list In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za> Message-ID: <1418281529.63.0.927663615631.issue22823@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: michael.foord -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 09:03:07 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Dec 2014 08:03:07 +0000 Subject: [issue20866] Crash in the libc fwrite() on SIGPIPE (segfault with os.popen and SIGPIPE) In-Reply-To: <1394216549.17.0.426654108401.issue20866@psf.upfronthosting.co.za> Message-ID: <1418284987.7.0.276360607024.issue20866@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: segfailt with os.popen and SIGPIPE -> Crash in the libc fwrite() on SIGPIPE (segfault with os.popen and SIGPIPE) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 09:13:00 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Dec 2014 08:13:00 +0000 Subject: [issue20866] Crash in the libc fwrite() on SIGPIPE (segfault with os.popen and SIGPIPE) In-Reply-To: <1394216549.17.0.426654108401.issue20866@psf.upfronthosting.co.za> Message-ID: <1418285580.74.0.973162367158.issue20866@psf.upfronthosting.co.za> STINNER Victor added the comment: I added this bug to my list of "Bugs that won?t be fixed in Python 2 anymore": http://haypo-notes.readthedocs.org/python.html#bugs-in-the-c-stdio-used-by-the-python-i-o ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 09:36:23 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 11 Dec 2014 08:36:23 +0000 Subject: [issue22823] Use set literals instead of creating a set from a list In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za> Message-ID: <20141211083606.20695.88177@psf.io> Roundup Robot added the comment: New changeset b6e6a86a92a7 by Serhiy Storchaka in branch 'default': Issue #22823: Use set literals instead of creating a set from a list. https://hg.python.org/cpython/rev/b6e6a86a92a7 New changeset 86a694781bee by Serhiy Storchaka in branch '3.4': Issue #22823: Fixed an output of sets in examples. https://hg.python.org/cpython/rev/86a694781bee ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 09:43:42 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Dec 2014 08:43:42 +0000 Subject: [issue22823] Use set literals instead of creating a set from a list In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za> Message-ID: <1418287422.75.0.946163133258.issue22823@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Docs changes were applied to 3.4 too. Here is a patch for lib2to3. ---------- assignee: serhiy.storchaka -> benjamin.peterson nosy: +benjamin.peterson stage: commit review -> patch review Added file: http://bugs.python.org/file37413/set_literal_2to3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 09:46:28 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Dec 2014 08:46:28 +0000 Subject: [issue22823] Use set literals instead of creating a set from a list In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za> Message-ID: <1418287588.6.0.560268052813.issue22823@psf.upfronthosting.co.za> STINNER Victor added the comment: > Here is a patch for lib2to3. In Python 3.5, I still found some "set([" and "frozenset([" in Lib/lib2to3, Lib/test/, Lib/stringrep.py, Lib/unittest/test/ and Lib/idlelib/CodeContext.py if someone is motived to patch them. (Ok, Serhiy wrote a patch for lib2to3.) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 10:14:40 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Dec 2014 09:14:40 +0000 Subject: [issue22823] Use set literals instead of creating a set from a list In-Reply-To: <1418287588.6.0.560268052813.issue22823@psf.upfronthosting.co.za> Message-ID: <3168294.zniS2OsPqj@raxxla> Serhiy Storchaka added the comment: Tests are intentionally omitted, Lib/stringrep.py is very special case (it's code is generated and outdated, see issue15239), idlelib is deferred by Terry. And there is yet one one-line change to Lib/distutils/msvc9compiler.py in set_literal_3.patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 10:45:07 2014 From: report at bugs.python.org (zhuoyikang) Date: Thu, 11 Dec 2014 09:45:07 +0000 Subject: [issue23024] Python Compile Error on Mac os X ld: unknown option: -export-dynamic In-Reply-To: <1418280129.56.0.00952071552031.issue23024@psf.upfronthosting.co.za> Message-ID: zhuoyikang added the comment: thank u very much ! question solved 2014-12-11 14:42 GMT+08:00 Ned Deily : > > Ned Deily added the comment: > > That should work just fine, assuming you are using an unmodified Python > 3.4.x source download or the 3.4 branch of a source repo. My best guess as > to why you are running into problems is that you may be picking up build > tools other than those supplied by Apple. On recent versions of OS X, make > sure you have run 'sudo xcode-select --install' to install the latest > version of the command line tools and check your shell $PATH variable. > There may be clues in the config.log file produced by running ./configure. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 11:18:07 2014 From: report at bugs.python.org (Michael Foord) Date: Thu, 11 Dec 2014 10:18:07 +0000 Subject: [issue21600] mock.patch.stopall doesn't work with patch.dict to sys.modules In-Reply-To: <1401334528.48.0.358693350259.issue21600@psf.upfronthosting.co.za> Message-ID: <1418293087.77.0.769664261955.issue21600@psf.upfronthosting.co.za> Michael Foord added the comment: Using patch.dict manipulates the contents of sys.modules, it doesn't replace sys.modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 11:32:34 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 11 Dec 2014 10:32:34 +0000 Subject: [issue23025] ssl.RAND_bytes docs should mention os.urandom In-Reply-To: <1418235366.16.0.20927959194.issue23025@psf.upfronthosting.co.za> Message-ID: <1418293954.17.0.912100715617.issue23025@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 11:34:18 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 11 Dec 2014 10:34:18 +0000 Subject: [issue22823] Use set literals instead of creating a set from a list In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za> Message-ID: <20141211103412.51893.68575@psf.io> Roundup Robot added the comment: New changeset ce66b65ad8d6 by Terry Jan Reedy in branch '2.7': Issue 22823: Use set literal in idlelib. https://hg.python.org/cpython/rev/ce66b65ad8d6 New changeset daec40891d43 by Terry Jan Reedy in branch '3.4': Issue 22823: Use set literal in idlelib. https://hg.python.org/cpython/rev/daec40891d43 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 11:54:43 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 11 Dec 2014 10:54:43 +0000 Subject: [issue23022] heap-use-after-free in find_maxchar_surrogates In-Reply-To: <1418204618.33.0.00964424099855.issue23022@psf.upfronthosting.co.za> Message-ID: <1418295283.32.0.127634065561.issue23022@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 12:22:03 2014 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Thu, 11 Dec 2014 11:22:03 +0000 Subject: [issue19527] Test failures with COUNT_ALLOCS In-Reply-To: <1383913813.74.0.198352256395.issue19527@psf.upfronthosting.co.za> Message-ID: <1418296923.68.0.692773271787.issue19527@psf.upfronthosting.co.za> Bohuslav "Slavek" Kabrda added the comment: Good catch, using getrefcount was a mistake. I'm attaching a new version which always checks for getcounts (and also applies on 3.4.2). ---------- Added file: http://bugs.python.org/file37414/00141-fix-tests_with_COUNT_ALLOCS-v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 12:36:40 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Dec 2014 11:36:40 +0000 Subject: [issue23022] heap-use-after-free in find_maxchar_surrogates In-Reply-To: <1418204618.33.0.00964424099855.issue23022@psf.upfronthosting.co.za> Message-ID: <1418297800.45.0.552359995718.issue23022@psf.upfronthosting.co.za> STINNER Victor added the comment: Your code is strange. It exchanges pointer between processes if I understand correctly: class Berbagi(ctypes.Structure): _fields_ = [('a', ctypes.c_wchar_p), ('b', ctypes.c_double) ] nilai = multiprocessing.Array(Berbagi, [Berbagi() for x in range(9)] ) You must not do that. Instead, Berbagi.a must be an array of c_wchar characters with a fixed size. Try for example: class Berbagi(ctypes.Structure): _fields_ = [('a', ctypes.c_wchar * 10), ('b', ctypes.c_double) ] Note: I'm not sure that ctypes is the most efficient module to serialize data, but maybe you have to use ctypes for a reason not explained in your issue. The bug is in your code, not in Python. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 12:36:51 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Dec 2014 11:36:51 +0000 Subject: [issue23022] heap-use-after-free in find_maxchar_surrogates In-Reply-To: <1418204618.33.0.00964424099855.issue23022@psf.upfronthosting.co.za> Message-ID: <1418297811.71.0.848161789486.issue23022@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 12:45:40 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Dec 2014 11:45:40 +0000 Subject: [issue23025] ssl.RAND_bytes docs should mention os.urandom In-Reply-To: <1418235366.16.0.20927959194.issue23025@psf.upfronthosting.co.za> Message-ID: <1418298340.35.0.866199120398.issue23025@psf.upfronthosting.co.za> STINNER Victor added the comment: RAND_bytes() has an annoying bug: it can produces the same byte sequence in two different processes if they get the same identifier (yes, it occurs sometimes). See the issue #18747 and warnings about fork in the ssl module. I don't know if it is now fixed in OpenSSL or maybe in LibreSSL. I was surprised that such bug exist in a serious library designed for cryptography. The usual reply to bug report is that users have to inject entropy manually at fork. It may be possible in an application, the issue #18747 explains why it is not a good idea to that in Python. /dev/urandom doesn't have such issue... I made the change to expose RAND_bytes(). I made it for my Hasard program (expermental tool to learn PRNG), to easily test the OpenSSL library in Python. That's how I "discovered" the fork issue (it was already known in fact..). I never used ssl.RAND_bytes() in a (real) Python application. http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ gives good reasons to not use ssl.RAND_bytes. So rand.diff looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 12:46:52 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 11 Dec 2014 11:46:52 +0000 Subject: [issue23025] ssl.RAND_bytes docs should mention os.urandom In-Reply-To: <1418235366.16.0.20927959194.issue23025@psf.upfronthosting.co.za> Message-ID: <1418298412.32.0.932494258862.issue23025@psf.upfronthosting.co.za> STINNER Victor added the comment: Note: ssl.RAND_bytes() doesn't exist in Python 2 (even in Python 2.7.9!). ---------- versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 12:57:06 2014 From: report at bugs.python.org (peerhash) Date: Thu, 11 Dec 2014 11:57:06 +0000 Subject: [issue23022] heap-use-after-free in find_maxchar_surrogates In-Reply-To: <1418204618.33.0.00964424099855.issue23022@psf.upfronthosting.co.za> Message-ID: <1418299026.58.0.706728133478.issue23022@psf.upfronthosting.co.za> Changes by peerhash : Removed file: http://bugs.python.org/file37406/repro.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 13:07:34 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Dec 2014 12:07:34 +0000 Subject: [issue19527] Test failures with COUNT_ALLOCS In-Reply-To: <1383913813.74.0.198352256395.issue19527@psf.upfronthosting.co.za> Message-ID: <1418299654.71.0.889169833596.issue19527@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 13:12:23 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Dec 2014 12:12:23 +0000 Subject: [issue17679] sysconfig generation uses some env variables multiple times In-Reply-To: <1365515508.55.0.936246153534.issue17679@psf.upfronthosting.co.za> Message-ID: <1418299943.62.0.487749860572.issue17679@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: needs patch -> patch review versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 13:13:26 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Dec 2014 12:13:26 +0000 Subject: [issue22765] Fixes for test_gdb (first frame address, entry values) In-Reply-To: <1414669906.53.0.952011236022.issue22765@psf.upfronthosting.co.za> Message-ID: <1418300006.87.0.041417363323.issue22765@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka stage: -> patch review type: -> behavior versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 13:21:41 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Dec 2014 12:21:41 +0000 Subject: [issue18028] Warnings with -fstrict-aliasing In-Reply-To: <1369125142.14.0.432992440388.issue18028@psf.upfronthosting.co.za> Message-ID: <1418300501.41.0.86531926142.issue18028@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- assignee: -> christian.heimes nosy: +serhiy.storchaka stage: patch review -> commit review versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 13:53:02 2014 From: report at bugs.python.org (Xuefer x) Date: Thu, 11 Dec 2014 12:53:02 +0000 Subject: [issue8027] distutils fail to determine c++ linker with unixcompiler if using ccache In-Reply-To: <1267284243.46.0.756608052144.issue8027@psf.upfronthosting.co.za> Message-ID: <1418302382.24.0.556104530668.issue8027@psf.upfronthosting.co.za> Xuefer x added the comment: please fix this bug. it seems the patch no longer applies to the current 2.7/3.4 code but the bug is still reproduce-able in another way i have CXX="ccache_cxx -pthread -shared" but what actually happen is: ccache_cxx gcc -pthread -shared ... x86_64-openwrt-linux-gnu-g++: error: gcc: No such file or directory error: command 'ccache_cxx' failed with exit status 1 Makefile:511: recipe for target 'all-local' failed make[5]: *** [all-local] Error 1 this is when building libtorrent-rasterbar-0.16.17 in openwrt build system, ccache_cxx is a wrapper script and distuils make a wrong build rule ---------- nosy: +Xuefer.x _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 14:11:25 2014 From: report at bugs.python.org (Xuefer x) Date: Thu, 11 Dec 2014 13:11:25 +0000 Subject: [issue8027] distutils fail to determine c++ linker with unixcompiler if using ccache In-Reply-To: <1267284243.46.0.756608052144.issue8027@psf.upfronthosting.co.za> Message-ID: <1418303485.8.0.723383057586.issue8027@psf.upfronthosting.co.za> Xuefer x added the comment: even with CXX="x86_64-openwrt-linux-gnu-g++ -pthread -shared" /usr/src/xuefer/openwrt/trunk/staging_dir/host/bin/python setup.py build it's donig x86_64-openwrt-linux-gnu-g++ gcc -pthread -shared .... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 14:54:38 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 11 Dec 2014 13:54:38 +0000 Subject: [issue22225] Add SQLite support to http.cookiejar In-Reply-To: <1408387746.24.0.600227999545.issue22225@psf.upfronthosting.co.za> Message-ID: <1418306078.75.0.691142636184.issue22225@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> rejected stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 14:59:36 2014 From: report at bugs.python.org (Constantin) Date: Thu, 11 Dec 2014 13:59:36 +0000 Subject: [issue23030] lru_cache manual get/put Message-ID: <1418306376.38.0.155577623227.issue23030@psf.upfronthosting.co.za> New submission from Constantin: In an effort for improved communication between stacked decorators, I would like to propose that all decorators providing caching mechanisms should provide the functions cache_info, cache_clear, cache_get and cache_put. The standard lib only provides functools.lru_cache as caching decorators, which already implements the former two. I have attached a patch to provide the latter two. On python-ideas there was also the idea to create a cache data structure and then have a decorator take its data structure as an argument. But it was argued that this could lead to some optimizations of the caching being impossible. I think my suggested approach should not impose a problem on highly optimized caching code, because every cache - no matter how optimized - must have some functionality to add something to the cache and lookup something in the cache. ---------- components: Library (Lib) files: lru_get_put.patch keywords: patch messages: 232476 nosy: ConnyOnny priority: normal severity: normal status: open title: lru_cache manual get/put type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file37415/lru_get_put.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 15:00:41 2014 From: report at bugs.python.org (Sergey Litvinov) Date: Thu, 11 Dec 2014 14:00:41 +0000 Subject: [issue23007] Unnecessary big intermediate result in Lib/bisect.py In-Reply-To: <1417992191.21.0.852637765732.issue23007@psf.upfronthosting.co.za> Message-ID: <1418306441.0.0.558598996419.issue23007@psf.upfronthosting.co.za> Sergey Litvinov added the comment: mark.dickinson> do you have an example of the Lib/bisect.py code No. I was thinking about something hypothetical similar to the one you provided. rhettinger> The "textbook" formula is more important in languages rhettinger> without something like Python long ints. In Python, rhettinger> "textbook" form just slows down and obfuscates the intention rhettinger> of the code. I agree and do not object to closing the report. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 15:22:47 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 11 Dec 2014 14:22:47 +0000 Subject: [issue23007] Unnecessary big intermediate result in Lib/bisect.py In-Reply-To: <1417992191.21.0.852637765732.issue23007@psf.upfronthosting.co.za> Message-ID: <1418307767.38.0.812589261917.issue23007@psf.upfronthosting.co.za> Mark Dickinson added the comment: Sergey: thanks for the response. Closing. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 15:24:36 2014 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 11 Dec 2014 14:24:36 +0000 Subject: [issue23007] Unnecessary big intermediate result in Lib/bisect.py In-Reply-To: <1417992191.21.0.852637765732.issue23007@psf.upfronthosting.co.za> Message-ID: <1418307876.22.0.955828633873.issue23007@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 15:28:52 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 11 Dec 2014 14:28:52 +0000 Subject: [issue23024] Python Compile Error on Mac os X ld: unknown option: -export-dynamic In-Reply-To: <1418230172.81.0.749154265279.issue23024@psf.upfronthosting.co.za> Message-ID: <1418308132.06.0.248659933674.issue23024@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 15:40:17 2014 From: report at bugs.python.org (Brett Cannon) Date: Thu, 11 Dec 2014 14:40:17 +0000 Subject: [issue23014] Don't have importlib.abc.Loader.create_module() be optional In-Reply-To: <1418055538.78.0.471721917483.issue23014@psf.upfronthosting.co.za> Message-ID: <1418308817.2.0.353255986239.issue23014@psf.upfronthosting.co.za> Brett Cannon added the comment: OK, then why don't we just make create_module() a required method to use exec_module(), add a DeprecationWarning for when it isn't defined, leave Loader.create_module() as-is (already returns None), and then plan to make it a requirement in Python 3.6 since the fix is so simple. That leaves the None return value for pragmatic reasons but makes it only way to specify the default instead of 2. ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 15:57:10 2014 From: report at bugs.python.org (Eric Snow) Date: Thu, 11 Dec 2014 14:57:10 +0000 Subject: [issue21600] mock.patch.stopall doesn't work with patch.dict to sys.modules In-Reply-To: <1401334528.48.0.358693350259.issue21600@psf.upfronthosting.co.za> Message-ID: <1418309830.04.0.387268958227.issue21600@psf.upfronthosting.co.za> Eric Snow added the comment: Ah. Never mind then. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 16:59:56 2014 From: report at bugs.python.org (Dan) Date: Thu, 11 Dec 2014 15:59:56 +0000 Subject: [issue23031] pdb crashes when jumping over "with" statement Message-ID: <1418313596.21.0.478510528753.issue23031@psf.upfronthosting.co.za> New submission from Dan: -> print(1) (Pdb) jump 6 Segmentation fault ---------- components: Library (Lib) files: pdb_segfault.py messages: 232481 nosy: DSP priority: normal severity: normal status: open title: pdb crashes when jumping over "with" statement type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file37416/pdb_segfault.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 17:55:25 2014 From: report at bugs.python.org (Chaitanya agrawal) Date: Thu, 11 Dec 2014 16:55:25 +0000 Subject: [issue22883] Get rid of references to PyInt in Py3 sources In-Reply-To: <1416147146.5.0.625860400609.issue22883@psf.upfronthosting.co.za> Message-ID: <1418316925.95.0.337656359891.issue22883@psf.upfronthosting.co.za> Changes by Chaitanya agrawal : Added file: http://bugs.python.org/file37417/issue228813_msg232419.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 17:56:19 2014 From: report at bugs.python.org (Chaitanya agrawal) Date: Thu, 11 Dec 2014 16:56:19 +0000 Subject: [issue22883] Get rid of references to PyInt in Py3 sources In-Reply-To: <1416147146.5.0.625860400609.issue22883@psf.upfronthosting.co.za> Message-ID: <1418316979.13.0.98237386268.issue22883@psf.upfronthosting.co.za> Changes by Chaitanya agrawal : Removed file: http://bugs.python.org/file37417/issue228813_msg232419.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 17:56:37 2014 From: report at bugs.python.org (Chaitanya agrawal) Date: Thu, 11 Dec 2014 16:56:37 +0000 Subject: [issue22883] Get rid of references to PyInt in Py3 sources In-Reply-To: <1416147146.5.0.625860400609.issue22883@psf.upfronthosting.co.za> Message-ID: <1418316997.85.0.36565536248.issue22883@psf.upfronthosting.co.za> Changes by Chaitanya agrawal : Added file: http://bugs.python.org/file37417/issue228813_msg232419.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 18:01:27 2014 From: report at bugs.python.org (Ethan Furman) Date: Thu, 11 Dec 2014 17:01:27 +0000 Subject: [issue23030] lru_cache manual get/put In-Reply-To: <1418306376.38.0.155577623227.issue23030@psf.upfronthosting.co.za> Message-ID: <1418317286.99.0.0796231524953.issue23030@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 18:02:40 2014 From: report at bugs.python.org (Ethan Furman) Date: Thu, 11 Dec 2014 17:02:40 +0000 Subject: [issue23030] lru_cache manual get/put In-Reply-To: <1418306376.38.0.155577623227.issue23030@psf.upfronthosting.co.za> Message-ID: <1418317360.7.0.624350875546.issue23030@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ncoghlan, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 19:50:09 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 11 Dec 2014 18:50:09 +0000 Subject: [issue23030] lru_cache manual get/put In-Reply-To: <1418306376.38.0.155577623227.issue23030@psf.upfronthosting.co.za> Message-ID: <1418323809.39.0.74862963165.issue23030@psf.upfronthosting.co.za> R. David Murray added the comment: It would be helpful (and provide a better record) if you could provide a link to the python-ideas discussion that endorses your idea. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 20:03:05 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 11 Dec 2014 19:03:05 +0000 Subject: [issue22866] ssl module in 2.7 should provide a way to configure default context options In-Reply-To: <1415905159.27.0.459058409364.issue22866@psf.upfronthosting.co.za> Message-ID: <1418324585.43.0.495161379439.issue22866@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Reopening the ticket, since I apparently missed the two important uses in the Python 2.7.9 stdlib: urllib2.py: -- context = ssl._create_stdlib_context(cert_reqs=ssl.CERT_REQUIRED, httplib.py: -- context = ssl._create_default_https_context() So it turns out that the context functions are indeed used for all stdlib HTTP interfacing. The ssl module itself doesn't use the hardcoded defaults (which is good), but having to write your own context function and then monkey patching this into the stdlib doesn't sound like a good solution to changing the default SSL context options, should this be needed. ---------- status: closed -> open title: ssl module in 2.7.9 should provide a way to configure default context options -> ssl module in 2.7 should provide a way to configure default context options _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 20:42:13 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 11 Dec 2014 19:42:13 +0000 Subject: [issue22866] ssl module in 2.7 should provide a way to configure default context options In-Reply-To: <1415905159.27.0.459058409364.issue22866@psf.upfronthosting.co.za> Message-ID: <1418326933.41.0.0254259808675.issue22866@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Usually you can pass your own context. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 20:51:11 2014 From: report at bugs.python.org (Ethan Furman) Date: Thu, 11 Dec 2014 19:51:11 +0000 Subject: [issue15443] datetime module has no support for nanoseconds In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za> Message-ID: <1418327471.68.0.447068720335.issue15443@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 20:58:08 2014 From: report at bugs.python.org (Ethan Furman) Date: Thu, 11 Dec 2014 19:58:08 +0000 Subject: [issue23030] lru_cache manual get/put In-Reply-To: <1418306376.38.0.155577623227.issue23030@psf.upfronthosting.co.za> Message-ID: <1418327888.87.0.87472588853.issue23030@psf.upfronthosting.co.za> Ethan Furman added the comment: When reading this thread, keep in mind that most of it was taken up with rejecting exposing the underlying data structure, which is not what this patch does. https://mail.python.org/pipermail/python-ideas/2014-December/030230.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 21:24:10 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 11 Dec 2014 20:24:10 +0000 Subject: [issue22866] ssl module in 2.7 should provide a way to configure default context options In-Reply-To: <1418326933.41.0.0254259808675.issue22866@psf.upfronthosting.co.za> Message-ID: <5489FD63.9020803@egenix.com> Marc-Andre Lemburg added the comment: On 11.12.2014 20:42, Benjamin Peterson wrote: > > Usually you can pass your own context. Yes, in new code, but not in existing Python 2.7 code that wasn't written for the newly added SSL context feature. BTW: Having a way to change the SSL options globally would be useful for Python 3.x as well, since OpenSSL often adds new options and it's not unlikely we'll see an OP_NO_TLSv1 option soon, given its age and similarity to SSLv3... https://www.imperialviolet.org/2014/12/08/poodleagain.html (the poodle strikes back ;-)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 21:26:32 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 11 Dec 2014 20:26:32 +0000 Subject: [issue22866] ssl module in 2.7 should provide a way to configure default context options In-Reply-To: <5489FD63.9020803@egenix.com> Message-ID: <1418329590.2570749.201827961.6C1B2B49@webmail.messagingengine.com> Benjamin Peterson added the comment: On Thu, Dec 11, 2014, at 15:24, Marc-Andre Lemburg wrote: > > Marc-Andre Lemburg added the comment: > > On 11.12.2014 20:42, Benjamin Peterson wrote: > > > > Usually you can pass your own context. > > Yes, in new code, but not in existing Python 2.7 code that wasn't > written for the newly added SSL context feature. How is modifying code to use a context different from modifying it to mess around with a hypothetical ssl.DEFAULT_SSL_OPTIONS? > > BTW: Having a way to change the SSL options globally would be useful > for Python 3.x as well, since OpenSSL often adds new options and > it's not unlikely we'll see an OP_NO_TLSv1 option soon, given its > age and similarity to SSLv3... > https://www.imperialviolet.org/2014/12/08/poodleagain.html > (the poodle strikes back ;-)) That option already exists and is exposed. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 21:29:58 2014 From: report at bugs.python.org (Donald Stufft) Date: Thu, 11 Dec 2014 20:29:58 +0000 Subject: [issue22866] ssl module in 2.7 should provide a way to configure default context options In-Reply-To: <1415905159.27.0.459058409364.issue22866@psf.upfronthosting.co.za> Message-ID: <1418329798.2.0.361763032595.issue22866@psf.upfronthosting.co.za> Donald Stufft added the comment: >> >> BTW: Having a way to change the SSL options globally would be useful >> for Python 3.x as well, since OpenSSL often adds new options and >> it's not unlikely we'll see an OP_NO_TLSv1 option soon, given its >> age and similarity to SSLv3... >> https://www.imperialviolet.org/2014/12/08/poodleagain.html >> (the poodle strikes back ;-)) > > That option already exists and is exposed. :) It even has OP_NO_TLSv1_1 and OP_NO_TLSv1_2! ---------- nosy: +dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 21:38:00 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 11 Dec 2014 20:38:00 +0000 Subject: [issue22866] ssl module in 2.7 should provide a way to configure default context options In-Reply-To: <1418329590.2570749.201827961.6C1B2B49@webmail.messagingengine.com> Message-ID: <548A00A0.3080909@egenix.com> Marc-Andre Lemburg added the comment: > Benjamin Peterson added the comment: > > On Thu, Dec 11, 2014, at 15:24, Marc-Andre Lemburg wrote: >> >> Marc-Andre Lemburg added the comment: >> >> On 11.12.2014 20:42, Benjamin Peterson wrote: >>> >>> Usually you can pass your own context. >> >> Yes, in new code, but not in existing Python 2.7 code that wasn't >> written for the newly added SSL context feature. > > How is modifying code to use a context different from modifying it to > mess around with a hypothetical ssl.DEFAULT_SSL_OPTIONS? Hmm, isn't that obvious ? You only have to add a single line of code to tweak the default options rather than add context support throughout your application. >> BTW: Having a way to change the SSL options globally would be useful >> for Python 3.x as well, since OpenSSL often adds new options and >> it's not unlikely we'll see an OP_NO_TLSv1 option soon, given its >> age and similarity to SSLv3... >> https://www.imperialviolet.org/2014/12/08/poodleagain.html >> (the poodle strikes back ;-)) > > That option already exists and is exposed. :) Right, but it's not used in the current default context. Hard coding options in a function is not a good idea, really, esp. not for things that change as often as cipher strings and protocol options :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 21:41:07 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 11 Dec 2014 20:41:07 +0000 Subject: [issue23032] 2.7 OS X installer builds fail building OpenSSL on OS X 10.4 / Xcode 2.5 Message-ID: <1418330467.3.0.591486521242.issue23032@psf.upfronthosting.co.za> New submission from Ned Deily: As of 2.7.9, OS X installer builds now build and link with a private copy of OpenSSL when building for deployment targets of 10.5 or earlier (see Issue17128). Although we no longer produce installers for earlier than 10.5 and even then built them on 10.5 systems, the legacy installer dmg buildbot still produces 10.3+ builds on OS X 10.4 (presumably using the Xcode 2.5 tool chain) and now fails. x86cpuid.s:327:Rest of line ignored. 1st junk character valued 44 (,). make[1]: *** [x86cpuid.o] Error 1 make: *** [build_crypto] Error 1 I have verified that it is still possible to build for 10.3+ using Xcode 3.1.6 on OS X 10.5 so there is that workaround if anyone needs to build installers for old systems. It looks like a fix is to disable assembly code in OpenSSL ("no-asm") when building on 10.4. http://buildbot.python.org/all/builders/bolen-dmg-2.7 https://trac.macports.org/ticket/42049 ---------- assignee: ned.deily components: Build, Macintosh messages: 232490 nosy: ned.deily, ronaldoussoren priority: low severity: normal stage: needs patch status: open title: 2.7 OS X installer builds fail building OpenSSL on OS X 10.4 / Xcode 2.5 versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 21:52:44 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 11 Dec 2014 20:52:44 +0000 Subject: [issue18028] Warnings with -fstrict-aliasing In-Reply-To: <1369125142.14.0.432992440388.issue18028@psf.upfronthosting.co.za> Message-ID: <1418331164.44.0.754774276111.issue18028@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Looks good to me as well. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 21:55:01 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Dec 2014 20:55:01 +0000 Subject: [issue19527] Test failures with COUNT_ALLOCS In-Reply-To: <1383913813.74.0.198352256395.issue19527@psf.upfronthosting.co.za> Message-ID: <1418331301.62.0.472320958496.issue19527@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM (only one nitpick -- there are trailing spaces in test_gc). But there are other tests which are failed with COUNT_ALLOCS. Here is a patch with additional fixes for these tests in test_gc and test_warnings. ---------- Added file: http://bugs.python.org/file37418/00141-fix-tests_with_COUNT_ALLOCS-v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 22:03:43 2014 From: report at bugs.python.org (Donald Stufft) Date: Thu, 11 Dec 2014 21:03:43 +0000 Subject: [issue23033] Disallow support for a*.example.net, *a.example.net, and a*b.example.net in certificate wildcard handling. Message-ID: <1418331823.45.0.0499057066046.issue23033@psf.upfronthosting.co.za> New submission from Donald Stufft: Various browsers[1][2] are dropping support for wild card certificates which are anything but a single "*" alone in the left most position. The other style wildcards were deprecated previously and they should not appear in any public certificate and in the words of the Chrome project are "dang weird for internal certificates". I believe we should follow suite and just only allow a single "*" alone in the left most segment for the SSL handling code. [1] https://codereview.chromium.org/762013002 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1107791 ---------- messages: 232493 nosy: dstufft priority: normal severity: normal status: open title: Disallow support for a*.example.net, *a.example.net, and a*b.example.net in certificate wildcard handling. versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 22:06:48 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 11 Dec 2014 21:06:48 +0000 Subject: [issue23033] Disallow support for a*.example.net, *a.example.net, and a*b.example.net in certificate wildcard handling. In-Reply-To: <1418331823.45.0.0499057066046.issue23033@psf.upfronthosting.co.za> Message-ID: <1418332008.01.0.537515296296.issue23033@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Sounds fine for me in 3.5. ---------- nosy: +pitrou versions: -Python 2.7, Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 22:09:33 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Dec 2014 21:09:33 +0000 Subject: [issue23034] Dynamically control debugging output Message-ID: <1418332173.89.0.386427809737.issue23034@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: When Python is compiled with some defined macros (e.g. COUNT_ALLOCS) it prints additional debugging output at shutdown. This additional output can cause tests failure (see issue19527). It would be good if Python will silent by default and produce debugging output only if special command line option or environment variable is set. Debugging output switched by Py_REF_DEBUG is now enabled only when "-X showrefcount" is specified (issue17323). ---------- components: Interpreter Core messages: 232495 nosy: bkabrda, ezio.melotti, serhiy.storchaka priority: normal severity: normal status: open title: Dynamically control debugging output type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 22:27:15 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 11 Dec 2014 21:27:15 +0000 Subject: [issue22823] Use set literals instead of creating a set from a list In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za> Message-ID: <20141211212709.54566.61576@psf.io> Roundup Robot added the comment: New changeset 7c2811521261 by Victor Stinner in branch 'default': Issue #22823: Fix typo in unittest/mock.py https://hg.python.org/cpython/rev/7c2811521261 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 22:41:19 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Dec 2014 21:41:19 +0000 Subject: [issue22765] Fixes for test_gdb (first frame address, entry values) In-Reply-To: <1414669906.53.0.952011236022.issue22765@psf.upfronthosting.co.za> Message-ID: <1418334079.0.0.03421649461.issue22765@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: test_gdb is failed on my computer (gdb 7.7) and I confirm that the patch fixes it. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 23:00:16 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 11 Dec 2014 22:00:16 +0000 Subject: [issue23031] pdb crashes when jumping over "with" statement In-Reply-To: <1418313596.21.0.478510528753.issue23031@psf.upfronthosting.co.za> Message-ID: <1418335216.72.0.88657033329.issue23031@psf.upfronthosting.co.za> Ned Deily added the comment: Sorry, I wasn't able to reproduce this. What platform are you running on and what is the output from the following? python2.7 -c 'import sys;print(sys.version)' ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 23:02:08 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Dec 2014 22:02:08 +0000 Subject: [issue17679] sysconfig generation uses some env variables multiple times In-Reply-To: <1365515508.55.0.936246153534.issue17679@psf.upfronthosting.co.za> Message-ID: <1418335328.78.0.982839551704.issue17679@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch doesn't look good to me. If the value contains "-lfoo-lbar $(name)" then substituting name="-lfoo" or name="-lbar" doesn't work. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 23:07:58 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Dec 2014 22:07:58 +0000 Subject: [issue15178] Doctest should handle situations when test files are not readable In-Reply-To: <1340622105.45.0.77795142646.issue15178@psf.upfronthosting.co.za> Message-ID: <1418335678.39.0.685292398746.issue15178@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> patch review versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 23:28:08 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Dec 2014 22:28:08 +0000 Subject: [issue15178] Doctest should handle situations when test files are not readable In-Reply-To: <1340622105.45.0.77795142646.issue15178@psf.upfronthosting.co.za> Message-ID: <1418336888.02.0.326692711076.issue15178@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Added few nitpicks on Rietveld. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 23:36:11 2014 From: report at bugs.python.org (Dan) Date: Thu, 11 Dec 2014 22:36:11 +0000 Subject: [issue23031] pdb crashes when jumping over "with" statement In-Reply-To: <1418313596.21.0.478510528753.issue23031@psf.upfronthosting.co.za> Message-ID: <1418337371.1.0.154029590495.issue23031@psf.upfronthosting.co.za> Dan added the comment: Sorry, it happens in: 2.7.3 |EPD 7.3-2 (64-bit)| (default, Apr 11 2012, 17:52:16) \n[GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] Works as expected in 2.7.8 and 3.3.2 2.7.8 (default, Jun 30 2014, 16:03:49) [MSC v.1500 32 bit (Intel)] 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600 32 bit (Intel)] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 11 23:39:42 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 11 Dec 2014 22:39:42 +0000 Subject: [issue22095] Use of set_tunnel with default port results in incorrect post value in host header In-Reply-To: <1406570983.98.0.143155526303.issue22095@psf.upfronthosting.co.za> Message-ID: <1418337582.27.0.105990164592.issue22095@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also comments on Rietveld (e-mail notification likely fell in spam). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 00:54:15 2014 From: report at bugs.python.org (Alex Gaynor) Date: Thu, 11 Dec 2014 23:54:15 +0000 Subject: [issue23033] Disallow support for a*.example.net, *a.example.net, and a*b.example.net in certificate wildcard handling. In-Reply-To: <1418331823.45.0.0499057066046.issue23033@psf.upfronthosting.co.za> Message-ID: <1418342055.43.0.285078914459.issue23033@psf.upfronthosting.co.za> Alex Gaynor added the comment: As a part of this, we might want to consider changing the implementation to not compile the SANs into a regular expression. Constantly compiling new regexs can cause churn in the `re` cache, which can degrade performance -- also, it's probably much worse on PyPy :-) ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 00:56:37 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 11 Dec 2014 23:56:37 +0000 Subject: [issue23032] 2.7 OS X installer builds fail building OpenSSL on OS X 10.4 / Xcode 2.5 In-Reply-To: <1418330467.3.0.591486521242.issue23032@psf.upfronthosting.co.za> Message-ID: <20141211235631.54568.52603@psf.io> Roundup Robot added the comment: New changeset dd677917355d by Ned Deily in branch '2.7': Issue #23032: Fix installer build failures on OS X 10.4 Tiger https://hg.python.org/cpython/rev/dd677917355d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 00:57:31 2014 From: report at bugs.python.org (Ned Deily) Date: Thu, 11 Dec 2014 23:57:31 +0000 Subject: [issue23032] 2.7 OS X installer builds fail building OpenSSL on OS X 10.4 / Xcode 2.5 In-Reply-To: <1418330467.3.0.591486521242.issue23032@psf.upfronthosting.co.za> Message-ID: <1418342251.9.0.0985559637464.issue23032@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 01:17:15 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 12 Dec 2014 00:17:15 +0000 Subject: [issue22866] ssl module in 2.7 should provide a way to configure default context options In-Reply-To: <1415905159.27.0.459058409364.issue22866@psf.upfronthosting.co.za> Message-ID: <1418343435.85.0.485088456986.issue22866@psf.upfronthosting.co.za> Benjamin Peterson added the comment: People who are using SSLv3 should explicitly pass in a context. Globally enabling SSLv3 will surely be a footgun e.g for apps that talk to an outdated device then request a webpage. I suppose wishing to globally use more secure defaults is a reasonable request. If someone writes a patch to put default context options in a global variable of the ssl module, we can look at it for 2.7.10. ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 02:13:42 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 12 Dec 2014 01:13:42 +0000 Subject: [issue16217] Tracebacks are unnecessarily verbose when using 'python -m' In-Reply-To: <1350132701.04.0.542395484982.issue16217@psf.upfronthosting.co.za> Message-ID: <1418346822.37.0.718241913143.issue16217@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 02:16:16 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 12 Dec 2014 01:16:16 +0000 Subject: [issue16974] when "python -c command" does a traceback, it open the file "" In-Reply-To: <1358286006.48.0.232332339533.issue16974@psf.upfronthosting.co.za> Message-ID: <1418346976.31.0.242935518168.issue16974@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 02:17:28 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 12 Dec 2014 01:17:28 +0000 Subject: [issue2786] Names in traceback should have class names, if they're methods In-Reply-To: <1210191958.85.0.412869826908.issue2786@psf.upfronthosting.co.za> Message-ID: <1418347048.14.0.855644452965.issue2786@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 02:44:07 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 12 Dec 2014 01:44:07 +0000 Subject: [issue23035] -c: Line causing exception not shown for exceptions other than SyntaxErrors Message-ID: <1418348647.52.0.502974463654.issue23035@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis: When 'python -c ${command}' is used and exception other than SyntaxError occurs, then line causing exception is not shown. Problem seen in output of last 2 commands below: $ cat /tmp/test1 1 / $ cat /tmp/test2 1 / 0 $ cat /tmp/test3 a $ python3.5 /tmp/test1 File "/tmp/test1", line 1 1 / ^ SyntaxError: invalid syntax $ python3.5 /tmp/test2 Traceback (most recent call last): File "/tmp/test2", line 1, in 1 / 0 ZeroDivisionError: division by zero $ python3.5 /tmp/test3 Traceback (most recent call last): File "/tmp/test3", line 1, in a NameError: name 'a' is not defined $ python3.5 -c '1 /' File "", line 1 1 / ^ SyntaxError: invalid syntax $ python3.5 -c '1 / 0' Traceback (most recent call last): File "", line 1, in ZeroDivisionError: division by zero $ python3.5 -c 'a' Traceback (most recent call last): File "", line 1, in NameError: name 'a' is not defined ---------- components: Interpreter Core messages: 232506 nosy: Arfrever, benjamin.peterson, pitrou, serhiy.storchaka priority: normal severity: normal status: open title: -c: Line causing exception not shown for exceptions other than SyntaxErrors versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 03:16:48 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 12 Dec 2014 02:16:48 +0000 Subject: [issue23030] lru_cache manual get/put In-Reply-To: <1418306376.38.0.155577623227.issue23030@psf.upfronthosting.co.za> Message-ID: <1418350608.33.0.553068638242.issue23030@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Manual adding to the cache seems of limited utility for the proposed recursion base case approach when your cache is actually operating in LRU mode (maxsize isn't None). You can inject your base cases all you want, but unless you wrap every call to the decorated function with another function that reinserts the base cases every time (and even that won't always work), you can't actually rely on the cache containing your base cases; they could be aged off at any time. I've been bad and (for fun) used inspect to directly find the cache closure variable in an lru_cache wrapped function to inject base cases, but it only works if your cache is unbounded. Trying to make it actually work reliably in LRU mode would complicate matters. I suppose a collections.ChainMap (where one is the LRU map, and the other is an unbounded dictionary solely for injected entries) might work, but it also starts making the cache more expensive to use in general for a really limited use case. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 06:20:38 2014 From: report at bugs.python.org (Demian Brecht) Date: Fri, 12 Dec 2014 05:20:38 +0000 Subject: [issue22095] Use of set_tunnel with default port results in incorrect post value in host header In-Reply-To: <1406570983.98.0.143155526303.issue22095@psf.upfronthosting.co.za> Message-ID: <1418361638.74.0.847467434663.issue22095@psf.upfronthosting.co.za> Demian Brecht added the comment: Thanks for the ping Serhiy, indeed the review notification email was sitting in spam. New patch addressing review comments as well as rectifying my own silliness. ---------- Added file: http://bugs.python.org/file37419/issue22095_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 06:32:07 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 12 Dec 2014 05:32:07 +0000 Subject: [issue22095] Use of set_tunnel with default port results in incorrect post value in host header In-Reply-To: <1406570983.98.0.143155526303.issue22095@psf.upfronthosting.co.za> Message-ID: <1418362327.36.0.67427796382.issue22095@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 06:42:37 2014 From: report at bugs.python.org (Demian Brecht) Date: Fri, 12 Dec 2014 05:42:37 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za> Message-ID: <1418362957.67.0.66193429871.issue21793@psf.upfronthosting.co.za> Demian Brecht added the comment: Self review/update: removed two errant breakpoints and updated the what's new section (missed in my previous patch). ---------- Added file: http://bugs.python.org/file37420/issue21793_5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 06:48:32 2014 From: report at bugs.python.org (Demian Brecht) Date: Fri, 12 Dec 2014 05:48:32 +0000 Subject: [issue22992] Adding a git developer's guide to Mercurial to devguide In-Reply-To: <1417651753.19.0.905189748743.issue22992@psf.upfronthosting.co.za> Message-ID: <1418363312.98.0.77463295346.issue22992@psf.upfronthosting.co.za> Demian Brecht added the comment: The issue was actually HAProxy rather than Apache (I had misread a line in the documentation so my understanding of Apache header limitations was incorrect). This was fixed by Donald today. If there are no objections, this should be good to merge now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 06:53:42 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 12 Dec 2014 05:53:42 +0000 Subject: [issue23030] lru_cache manual get/put In-Reply-To: <1418306376.38.0.155577623227.issue23030@psf.upfronthosting.co.za> Message-ID: <1418363622.46.0.15989379538.issue23030@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 07:29:43 2014 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 12 Dec 2014 06:29:43 +0000 Subject: [issue23014] Don't have importlib.abc.Loader.create_module() be optional In-Reply-To: <1418055538.78.0.471721917483.issue23014@psf.upfronthosting.co.za> Message-ID: <1418365783.02.0.42403222524.issue23014@psf.upfronthosting.co.za> Nick Coghlan added the comment: Sounds good to me. I'm not sure what to put in the docs about calling importlib.util.module_from_spec() from create_module() implementations. Really, if a loader can use that, then it should be doing whatever it was going to do after the call in exec_module() instead. create_module() is intended specifically for cases where you genuinely need to do something different to create the object (as in the concept of calling in to a C level module creation hook, or the idea of allowing a __new__.py file in package directories) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 07:36:09 2014 From: report at bugs.python.org (Zachary Ware) Date: Fri, 12 Dec 2014 06:36:09 +0000 Subject: [issue22955] Pickling of methodcaller, attrgetter, and itemgetter In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za> Message-ID: <1418366169.5.0.39187198415.issue22955@psf.upfronthosting.co.za> Zachary Ware added the comment: Serhiy: functools.partial is a somewhat less than ideal comparison. The pure-Python version is not picklable, the Python and C versions return different things (the Python version is a function returning a function, the C version is a regular class and returns an instance). Also, both versions make their necessary attributes public anyway, unlike methodcaller. Raymond: Not necessarily the usual approach, no. However, I think my reimplementations of the pure-Python itemgetter and attrgetter have a few benefits, namely: - they're somewhat less complex and thus a bit easier to understand - they're slightly faster - they don't require extra pickling methods, which to me just seem like clutter when it's so simple to not need them Note that I have no intention of reimplementing the C versions: those are much more mature than the Python versions, and would likely require pickling methods anyway. All that said, I'm not going to fight about it; if I'm overruled, I'm overruled. Josh: Serhiy's points about needing more tests stand; would you like to add them? You can use your patch or mine as a base, depending on how you feel about reimplementing the pure-Python (item|attr}getter. If you use yours, please remember to look through my comments on it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 08:36:55 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 12 Dec 2014 07:36:55 +0000 Subject: [issue22095] Use of set_tunnel with default port results in incorrect post value in host header In-Reply-To: <1406570983.98.0.143155526303.issue22095@psf.upfronthosting.co.za> Message-ID: <20141212073223.54562.12374@psf.io> Roundup Robot added the comment: New changeset 676d6bcfc031 by Serhiy Storchaka in branch '3.4': Issue #22095: Fixed HTTPConnection.set_tunnel with default port. The port https://hg.python.org/cpython/rev/676d6bcfc031 New changeset ebe2072e5472 by Serhiy Storchaka in branch 'default': Issue #22095: Fixed HTTPConnection.set_tunnel with default port. The port https://hg.python.org/cpython/rev/ebe2072e5472 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 08:47:00 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 12 Dec 2014 07:47:00 +0000 Subject: [issue22095] Use of set_tunnel with default port results in incorrect post value in host header In-Reply-To: <1406570983.98.0.143155526303.issue22095@psf.upfronthosting.co.za> Message-ID: <1418370420.88.0.0613984189419.issue22095@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your contribution Demian. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 08:52:39 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 12 Dec 2014 07:52:39 +0000 Subject: [issue18028] Warnings with -fstrict-aliasing In-Reply-To: <1369125142.14.0.432992440388.issue18028@psf.upfronthosting.co.za> Message-ID: <1418370759.97.0.582535458643.issue18028@psf.upfronthosting.co.za> Raymond Hettinger added the comment: +1 ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 08:56:05 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 12 Dec 2014 07:56:05 +0000 Subject: [issue23005] typos on heapq doc In-Reply-To: <1417978054.94.0.0217424241667.issue23005@psf.upfronthosting.co.za> Message-ID: <20141212075600.20697.11279@psf.io> Roundup Robot added the comment: New changeset cb085b07ea34 by Raymond Hettinger in branch '2.7': Issue 23005: Fix typos https://hg.python.org/cpython/rev/cb085b07ea34 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 08:57:14 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 12 Dec 2014 07:57:14 +0000 Subject: [issue23005] typos on heapq doc In-Reply-To: <1417978054.94.0.0217424241667.issue23005@psf.upfronthosting.co.za> Message-ID: <20141212075700.95330.16849@psf.io> Roundup Robot added the comment: New changeset 7f2cf63cf95a by Raymond Hettinger in branch '3.4': Issue 23005: Fix typos https://hg.python.org/cpython/rev/7f2cf63cf95a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 08:58:50 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 12 Dec 2014 07:58:50 +0000 Subject: [issue23005] typos on heapq doc In-Reply-To: <1417978054.94.0.0217424241667.issue23005@psf.upfronthosting.co.za> Message-ID: <1418371130.12.0.735992014814.issue23005@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 08:59:34 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 12 Dec 2014 07:59:34 +0000 Subject: [issue15267] tempfile.TemporaryFile and httplib incompatibility In-Reply-To: <1341620675.47.0.0551988049302.issue15267@psf.upfronthosting.co.za> Message-ID: <1418371174.65.0.687728237643.issue15267@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +needs review stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 08:59:37 2014 From: report at bugs.python.org (gladman) Date: Fri, 12 Dec 2014 07:59:37 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za> Message-ID: <1418371177.52.0.041885318517.issue22477@psf.upfronthosting.co.za> gladman added the comment: I notice on the documentation for Python 3.5 that this proposed addition is not mentioned. Is it still the intention to add this proposed change to Python 3.5? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 08:59:53 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 12 Dec 2014 07:59:53 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za> Message-ID: <1418371193.8.0.194930301085.issue21793@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 09:00:36 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 12 Dec 2014 08:00:36 +0000 Subject: [issue9536] defaultdict doc makes incorrect reference to __missing__ method In-Reply-To: <1281106528.37.0.0435364267174.issue9536@psf.upfronthosting.co.za> Message-ID: <1418371236.82.0.4063837203.issue9536@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 09:23:22 2014 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Fri, 12 Dec 2014 08:23:22 +0000 Subject: [issue15178] Doctest should handle situations when test files are not readable In-Reply-To: <1340622105.45.0.77795142646.issue15178@psf.upfronthosting.co.za> Message-ID: <1418372602.43.0.590447823736.issue15178@psf.upfronthosting.co.za> Bohuslav "Slavek" Kabrda added the comment: Attaching a new version of patch: - Rebased to latest default branch - Simplified prints - Using OSError instead of IOError Hopefully this is the final version :) ---------- Added file: http://bugs.python.org/file37421/doctest-dont-end-with-exception-on-unreadable-files-v6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 09:43:25 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 12 Dec 2014 08:43:25 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za> Message-ID: <1418373805.1.0.0901420230409.issue21793@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 09:56:21 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Dec 2014 08:56:21 +0000 Subject: [issue22477] GCD in Fractions In-Reply-To: <1411543502.18.0.966419857361.issue22477@psf.upfronthosting.co.za> Message-ID: <1418374581.12.0.0212416922325.issue22477@psf.upfronthosting.co.za> STINNER Victor added the comment: I see that the issue #22486 is still open. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 09:57:02 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Dec 2014 08:57:02 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1418374622.84.0.324589245574.issue22486@psf.upfronthosting.co.za> STINNER Victor added the comment: What's the status of this issue? See also the issue #22477. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 10:44:34 2014 From: report at bugs.python.org (Ned Deily) Date: Fri, 12 Dec 2014 09:44:34 +0000 Subject: [issue22935] Disabling SSLv3 support In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za> Message-ID: <1418377474.37.0.956252629243.issue22935@psf.upfronthosting.co.za> Ned Deily added the comment: The changes for 3.4 are incomplete: >>> import ssl Traceback (most recent call last): File "", line 1, in File "/py/dev/34/source/Lib/ssl.py", line 122, in from _ssl import PROTOCOL_SSLv3, PROTOCOL_SSLv23, PROTOCOL_TLSv1 ImportError: cannot import name 'PROTOCOL_SSLv3' For the default (3.5) branch, f776771ab0ee for Issue21068 changed ssl.py to handle missing SSLv3 support; 3.4 needs something similar. ---------- resolution: fixed -> stage: resolved -> needs patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 12:12:36 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 12 Dec 2014 11:12:36 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1418382756.32.0.286469693048.issue22486@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which addresses both Mark's suggestions. * math.gcd() now work with arbitrary Python objects implementing __index__. * fractions.gcd() and Fraction's constructor now use math.gcd() if both arguments are int, but also support non-ints (e.g. Fractions or floats). * fractions.gcd() now is deprecated. But before committing I want to experiment with simpler implementation and compare it with current complex implementation. If the difference will be not too large, we could use simpler implementation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 12:13:19 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 12 Dec 2014 11:13:19 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1418382799.5.0.966562749741.issue22486@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file37422/lehmer_gcd_8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 12:22:18 2014 From: report at bugs.python.org (Mark Summerfield) Date: Fri, 12 Dec 2014 11:22:18 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1418383338.81.0.760234653774.issue17914@psf.upfronthosting.co.za> Mark Summerfield added the comment: In message http://bugs.python.org/issue17914#msg188626 Victor Stenner says "On Windows, GetSystemInfo() is called instead of reading an environment variable. I suppose that this function is more reliable." >From my reading, and based on feedback from one of my customers, I believe he is correct and that GetSystemInfo() ought to be used on Windows. (It is available in pywin32 win32api.) ---------- nosy: +mark _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 12:25:49 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 12 Dec 2014 11:25:49 +0000 Subject: [issue22935] Disabling SSLv3 support In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za> Message-ID: <20141212112534.54564.17042@psf.io> Roundup Robot added the comment: New changeset 773e55c95703 by Victor Stinner in branch '3.4': Issue #22935: Fix ssl module when SSLv3 protocol is not supported https://hg.python.org/cpython/rev/773e55c95703 New changeset fb1ffd40d33e by Victor Stinner in branch 'default': Issue #22935: Fix test_ssl when the SSLv3 protocol is not supported https://hg.python.org/cpython/rev/fb1ffd40d33e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 12:28:04 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 12 Dec 2014 11:28:04 +0000 Subject: [issue22935] Disabling SSLv3 support In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za> Message-ID: <20141212112737.54556.41792@psf.io> Roundup Robot added the comment: New changeset f0297263a1e8 by Victor Stinner in branch '3.4': Issue #22935: Fix test_ssl when the SSLv3 protocol is not supported https://hg.python.org/cpython/rev/f0297263a1e8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 12:31:40 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Dec 2014 11:31:40 +0000 Subject: [issue22935] Disabling SSLv3 support In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za> Message-ID: <1418383900.7.0.802906239842.issue22935@psf.upfronthosting.co.za> STINNER Victor added the comment: > The changes for 3.4 are incomplete Ok, I fixed most obvious issues. There is a major severe issue in Lib/ssl.py: def get_server_certificate(addr, ssl_version=PROTOCOL_SSLv3, ca_certs=None): ... This line fails if PROTOCOL_SSLv3 name does not exist. I propose to use PROTOCOL_SSLv23 by default if PROTOCOL_SSLv3 does not exist, as done in Python 3.5. See attached patch. A better option (more secure?) is to use PROTOCOL_SSLv23 by default. What do you think? I prefer to switch to PROTOCOL_SSLv23 by default in Python 3.4. ---------- Added file: http://bugs.python.org/file37423/get_server_certificate_sslv3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 12:35:39 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Dec 2014 11:35:39 +0000 Subject: [issue22935] Disabling SSLv3 support In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za> Message-ID: <1418384139.56.0.196991844119.issue22935@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, in Python 3.4, create_default_context() uses PROTOCOL_SSLv23, SSLSocket, wrap_socket() and _create_unverified_context() use PROTOCOL_SSLv23 by default. In Python 3.5, get_server_certificate() now uses PROTOCOL_SSLv23 by default because test_ssl failed on the host svn.python.org: see issue #20896. changeset: 90360:55f62fa5bebc user: Antoine Pitrou date: Wed Apr 16 18:56:28 2014 +0200 files: Doc/library/ssl.rst Lib/ssl.py Lib/test/test_ssl.py Misc/NEWS description: Issue #20896: ssl.get_server_certificate() now uses PROTOCOL_SSLv23, not PROTOCOL_SSLv3, for maximum compatibility. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 12:52:08 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Dec 2014 11:52:08 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1418385128.72.0.0907834935645.issue17914@psf.upfronthosting.co.za> STINNER Victor added the comment: > From my reading, and based on feedback from one of my customers, I believe he is correct and that GetSystemInfo() ought to be used on Windows. (It is available in pywin32 win32api.) Please open a new issue to suggest this enhancement, this issue is closed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 12:56:20 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Dec 2014 11:56:20 +0000 Subject: [issue22935] Disabling SSLv3 support In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za> Message-ID: <1418385380.38.0.357897920479.issue22935@psf.upfronthosting.co.za> STINNER Victor added the comment: get_server_certificate_sslv23.patch: Patch to use PROTOCOL_SSLv23 by default in get_server_certificate(), as done in Python 2.7 and 3.5. ---------- Added file: http://bugs.python.org/file37424/get_server_certificate_sslv23.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 12:58:22 2014 From: report at bugs.python.org (E Roberts) Date: Fri, 12 Dec 2014 11:58:22 +0000 Subject: [issue23036] Crash Error? Message-ID: <1418385501.98.0.240780144753.issue23036@psf.upfronthosting.co.za> New submission from E Roberts: New to the world of Python. The picture attached is an error that a teacher at my school is receiving when he tries to run anything in IDLE. I know nothing about coding/python/idle or anything of that nature. Sorry I am of little help. Please can someone help me out with this error and provide any help or an answer. Thank you for dealing with a complete novice. ---------- components: IDLE files: python error.png messages: 232531 nosy: E.Roberts priority: normal severity: normal status: open title: Crash Error? type: crash versions: Python 3.3 Added file: http://bugs.python.org/file37425/python error.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 13:02:02 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Dec 2014 12:02:02 +0000 Subject: [issue23036] Crash Error? In-Reply-To: <1418385501.98.0.240780144753.issue23036@psf.upfronthosting.co.za> Message-ID: <1418385722.48.0.195108206049.issue23036@psf.upfronthosting.co.za> STINNER Victor added the comment: The problem is that your student created a file called random.py which conflicts with the module "random" of the Python standard library. Please rename the random.py file to random.py and remove .pyc files (ex: random.pyc or __pycache__/random*pyc). ---------- nosy: +haypo resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 13:12:06 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Dec 2014 12:12:06 +0000 Subject: [issue15267] tempfile.TemporaryFile and httplib incompatibility In-Reply-To: <1341620675.47.0.0551988049302.issue15267@psf.upfronthosting.co.za> Message-ID: <1418386326.0.0.593764216401.issue15267@psf.upfronthosting.co.za> STINNER Victor added the comment: Catching TypeError on len() looks as an ugly test to check if body is a string. Why not doing the opposite: first to call fileno() and call AttributeError? Or even use hasattr(body, "fileno")? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 13:14:03 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Dec 2014 12:14:03 +0000 Subject: [issue15267] tempfile.TemporaryFile and httplib incompatibility In-Reply-To: <1341620675.47.0.0551988049302.issue15267@psf.upfronthosting.co.za> Message-ID: <1418386443.38.0.893901190023.issue15267@psf.upfronthosting.co.za> STINNER Victor added the comment: issue15267.patch: I would feel more confortable if test_send_tempfile() ensures that the socket contains the file content. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 13:20:28 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 12 Dec 2014 12:20:28 +0000 Subject: [issue18028] Warnings with -fstrict-aliasing In-Reply-To: <1369125142.14.0.432992440388.issue18028@psf.upfronthosting.co.za> Message-ID: <20141212122022.95312.97985@psf.io> Roundup Robot added the comment: New changeset 9565b56a4615 by Victor Stinner in branch '2.7': Issue #18028: Fix aliasing issue in READ_TIMESTAMP() of ceval.c on x86_64, https://hg.python.org/cpython/rev/9565b56a4615 New changeset adb445578995 by Victor Stinner in branch '3.4': Issue #18028: Fix aliasing issue in READ_TIMESTAMP() of ceval.c on x86_64, https://hg.python.org/cpython/rev/adb445578995 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 13:22:32 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Dec 2014 12:22:32 +0000 Subject: [issue18028] Warnings with -fstrict-aliasing In-Reply-To: <1369125142.14.0.432992440388.issue18028@psf.upfronthosting.co.za> Message-ID: <1418386952.6.0.981157872137.issue18028@psf.upfronthosting.co.za> STINNER Victor added the comment: 3 core developers reviewed Christian's patch, so it also looks good to me :-) Since Christian looks to be busy, I commited his patch. Thanks Christian for your fix. We might enable -fstrict-aliasing later, at least to compile Python core (not to build extensions). ---------- nosy: +haypo resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 13:22:56 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Dec 2014 12:22:56 +0000 Subject: [issue23035] python -c: Line causing exception not shown for exceptions other than SyntaxErrors In-Reply-To: <1418348647.52.0.502974463654.issue23035@psf.upfronthosting.co.za> Message-ID: <1418386976.17.0.61108717831.issue23035@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: -c: Line causing exception not shown for exceptions other than SyntaxErrors -> python -c: Line causing exception not shown for exceptions other than SyntaxErrors _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 13:28:41 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Dec 2014 12:28:41 +0000 Subject: [issue23035] python -c: Line causing exception not shown for exceptions other than SyntaxErrors In-Reply-To: <1418348647.52.0.502974463654.issue23035@psf.upfronthosting.co.za> Message-ID: <1418387321.0.0.634327213122.issue23035@psf.upfronthosting.co.za> STINNER Victor added the comment: SyntaxError exceptions have a text attribute which contains the line where the error occurred. It's really a special case. For other exceptions, Python only knows that the error occurred in the file called "". Being able to display the line for any exception requires a complex development. I'm not interested to implement it, I don't think that it's very useful (compared to the time needed to develop it). ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 13:29:32 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 12 Dec 2014 12:29:32 +0000 Subject: [issue23034] Dynamically control debugging output In-Reply-To: <1418332173.89.0.386427809737.issue23034@psf.upfronthosting.co.za> Message-ID: <1418387372.59.0.433411499565.issue23034@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Also this debug output should be printed on stderr, not stdout. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 13:30:33 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Dec 2014 12:30:33 +0000 Subject: [issue23034] Dynamically control debugging output In-Reply-To: <1418332173.89.0.386427809737.issue23034@psf.upfronthosting.co.za> Message-ID: <1418387433.02.0.134322048164.issue23034@psf.upfronthosting.co.za> STINNER Victor added the comment: > Debugging output switched by Py_REF_DEBUG is now enabled only when "-X showrefcount" is specified (issue17323). Yes, I like the idea of doing that for other debug options. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 13:36:11 2014 From: report at bugs.python.org (Mark Summerfield) Date: Fri, 12 Dec 2014 12:36:11 +0000 Subject: [issue23037] cpu_count() unreliable on Windows Message-ID: <1418387771.87.0.957316406628.issue23037@psf.upfronthosting.co.za> New submission from Mark Summerfield: In message http://bugs.python.org/issue17914#msg188626 Victor Stenner says "On Windows, GetSystemInfo() is called instead of reading an environment variable. I suppose that this function is more reliable." >From my reading, and based on feedback from one of my customers, I believe he is correct and that GetSystemInfo() ought to be used on Windows. (It is available in pywin32 win32api.) ---------- components: Library (Lib), Windows messages: 232540 nosy: mark, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 13:36:49 2014 From: report at bugs.python.org (Mark Summerfield) Date: Fri, 12 Dec 2014 12:36:49 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1418387809.75.0.658658271798.issue17914@psf.upfronthosting.co.za> Mark Summerfield added the comment: Since this is closed I've created a new issue as requested: http://bugs.python.org/issue23037 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 13:47:55 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 12 Dec 2014 12:47:55 +0000 Subject: [issue22935] Disabling SSLv3 support In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za> Message-ID: <1418388475.6.0.215630692093.issue22935@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Please always use PROTOCOL_SSLv23 since this is the only forward compatible way of telling OpenSSL to use the best protocol available. Any of the other options such as PROTOCOL_TLSv1 will fix the protocol version to that one protocol version, whereas PROTOCOL_SSLv23 means to use any protocol starting with SSLv2. In the context options you can then disable SSLv2 and SSLv3 to e.g. have the connection use TLS 1.0 or later. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 14:08:01 2014 From: report at bugs.python.org (Kurt Roeckx) Date: Fri, 12 Dec 2014 13:08:01 +0000 Subject: [issue22935] Disabling SSLv3 support In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za> Message-ID: <1418389681.06.0.183415894422.issue22935@psf.upfronthosting.co.za> Kurt Roeckx added the comment: So this seems to be a function that just gets the certificate? You need to be careful with this since a server could perfectly decide to send a different certificate depending on the client hello it receives. Like if you support ECDSA it might decide to send you the ECDSA certificate instead of the RSA certificate. Or maybe you're even connecting to a different IP address? In any case, you should always use SSLv23, stop supporting anything else. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 14:13:57 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Dec 2014 13:13:57 +0000 Subject: [issue23037] cpu_count() unreliable on Windows In-Reply-To: <1418387771.87.0.957316406628.issue23037@psf.upfronthosting.co.za> Message-ID: <1418390037.47.0.763339629136.issue23037@psf.upfronthosting.co.za> STINNER Victor added the comment: The code getting the number of processors on Windows is different between the multiprocessing (Python 3.3) and os (Python 3.5) modules. multiprocessing (old code): try: num = int(os.environ['NUMBER_OF_PROCESSORS']) except (ValueError, KeyError): num = 0 os (new code): SYSTEM_INFO sysinfo; GetSystemInfo(&sysinfo); ncpu = sysinfo.dwNumberOfProcessors; os.cpu_count() is already implemented with GetSystemInfo() in Python 3.5, so this issue can be closed. Thanks for the reminder Mark, it was useful to double check. If you want to take a look at the source code: https://hg.python.org/cpython/file/35b7dde7fd53/Modules/posixmodule.c#l16064 ---------- nosy: +haypo resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 14:16:40 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Dec 2014 13:16:40 +0000 Subject: [issue22935] Disabling SSLv3 support In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za> Message-ID: <1418390199.99.0.697604840555.issue22935@psf.upfronthosting.co.za> STINNER Victor added the comment: > So this seems to be a function that just gets the certificate? You need to be careful with this since a server could perfectly decide to send a different certificate depending on the client hello it receives. (...) In any case, you should always use SSLv23, stop supporting anything else. I don't understand. You say that depending on the protocol, you may get a different certificate, and then that we should stop supporting multiple protocol. Does it mean that you ask to remove a Python feature? Even if it is technically possible to return a different certificate, I don't think that much servers will return a different certificate if the client uses SSLv23 instead of SSLv3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 14:23:26 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Dec 2014 13:23:26 +0000 Subject: [issue22935] Disabling SSLv3 support In-Reply-To: <1418390199.99.0.697604840555.issue22935@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Any of the other options such as PROTOCOL_TLSv1 will fix the protocol version to that one protocol version, whereas PROTOCOL_SSLv23 means to use any protocol starting with SSLv2. In the context options you can then disable SSLv2 and SSLv3 to e.g. have the connection use TLS 1.0 or later. get_server_certificate() uses _create_unverified_context() (In Python 2.7, 3.4 & 3.5) which explicitly disable SSLv2 and SSLv3. I still have trouble to understand which protocol will be negociated. We use SSLv3 and disable SSLv3, so the server can only use SSLv23. Am I right? https://docs.python.org/dev/library/ssl.html#ssl.wrap_socket ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 14:28:54 2014 From: report at bugs.python.org (Kurt Roeckx) Date: Fri, 12 Dec 2014 13:28:54 +0000 Subject: [issue22935] Disabling SSLv3 support In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za> Message-ID: <1418390934.75.0.962621340158.issue22935@psf.upfronthosting.co.za> Kurt Roeckx added the comment: SSLv3 does not support the TLS extensions so it's going to send a totally different Client Hello. It will for instance not indicate with elliptic curves it supports. So yes the behavior for SSLv3 and SSLv23 can be totally different. But even with both SSLv23 and a different cipher list you can get a different certificate. So what I'm really saying is that if you have an API to get a certificate that creates a new connection and you can set the options for that connection too that you need to document that properly that you might get a different certificate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 14:30:17 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 12 Dec 2014 13:30:17 +0000 Subject: [issue22935] Disabling SSLv3 support In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za> Message-ID: <1418391017.08.0.917255781908.issue22935@psf.upfronthosting.co.za> STINNER Victor added the comment: Do you have an example of server returning a different certificate depending on the protocol? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 15:39:19 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 12 Dec 2014 14:39:19 +0000 Subject: [issue23014] Don't have importlib.abc.Loader.create_module() be optional In-Reply-To: <1418055538.78.0.471721917483.issue23014@psf.upfronthosting.co.za> Message-ID: <1418395159.86.0.671315332574.issue23014@psf.upfronthosting.co.za> Brett Cannon added the comment: I don't think we really need to say anything. If people want default results, simply return None (which is handled for them by importlib.abc.Loader). The only thing changing here is that the method will now be required instead of optional. I'll post the patch here before I commit to make sure it's all clear. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 15:44:33 2014 From: report at bugs.python.org (Collin Anderson) Date: Fri, 12 Dec 2014 14:44:33 +0000 Subject: [issue23038] #python.web irc channel is dead Message-ID: <1418395473.68.0.943574829813.issue23038@psf.upfronthosting.co.za> New submission from Collin Anderson: Can we remove references to #python.web? I assume it was a flourishing channel at some point. https://docs.python.org/3/howto/webservers.html#other-notable-frameworks ---------- assignee: docs at python components: Documentation messages: 232550 nosy: collinanderson, docs at python priority: normal severity: normal status: open title: #python.web irc channel is dead versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 15:48:03 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 12 Dec 2014 14:48:03 +0000 Subject: [issue22935] Disabling SSLv3 support In-Reply-To: Message-ID: <548B001A.9060407@egenix.com> Marc-Andre Lemburg added the comment: > STINNER Victor added the comment: > >> Any of the other options such as PROTOCOL_TLSv1 will fix the protocol version to that one protocol version, whereas PROTOCOL_SSLv23 means to use any protocol starting with SSLv2. In the context options you can then disable SSLv2 and SSLv3 to e.g. have the connection use TLS 1.0 or later. > > get_server_certificate() uses _create_unverified_context() (In Python > 2.7, 3.4 & 3.5) which explicitly disable SSLv2 and SSLv3. I still have > trouble to understand which protocol will be negociated. We use SSLv3 > and disable SSLv3, so the server can only use SSLv23. Am I right? > https://docs.python.org/dev/library/ssl.html#ssl.wrap_socket I'm not sure what OpenSSL will do if you tell it to use protocol SSLv3 and then disable this via the options again. This sounds like it won't connect at all, since PROTOCOL_SSLv3 means: only support SSLv3 :-) The logic used for protocol selection in OpenSSL is, well, weird. You have the choice between fixing one single protocol version or selecting a range and then disabling certain protocol versions when configuring the context options. FWIW: The ssl_version parameter in _create_unverified_context() already uses the correct default; IMO, exposing the parameter in get_server_certificate() is fairly useless, unless you want to (ab)use the function to test supported protocol versions :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 15:53:07 2014 From: report at bugs.python.org (Kurt Roeckx) Date: Fri, 12 Dec 2014 14:53:07 +0000 Subject: [issue22935] Disabling SSLv3 support In-Reply-To: <1416867260.32.0.182122908289.issue22935@psf.upfronthosting.co.za> Message-ID: <1418395987.49.0.103918191868.issue22935@psf.upfronthosting.co.za> Kurt Roeckx added the comment: Most such sites actually seem to have dropped support for SSLv3. One site where it depends on the cipher string is bugs.cdburnerxp.se ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 15:56:25 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 12 Dec 2014 14:56:25 +0000 Subject: [issue23034] Dynamically control debugging output In-Reply-To: <1418387433.02.0.134322048164.issue23034@psf.upfronthosting.co.za> Message-ID: <1816267.gMSlt7QJ4h@raxxla> Serhiy Storchaka added the comment: Here is (conceivably incomplete) list of debugging and tracing output (but not error reporting) from C code. Controlled output. Import and shutdown details -- controlled by the -v flag. Parser tracing -- controlled by the -d flag. If Py_REF_DEBUG is defined -- controlled by the -X showrefcount flag. If PYMALLOC_DEBUG is defined -- controlled by the PYTHONMALLOCSTATS environment variable. If Py_TRACE_REFS is defined -- controlled by the PYTHONDUMPREFS environment variable. Garbage collecting details -- controlled by gc.set_debug(). If LLTRACE is defined -- controlled by the __ltrace__ global variable. Uncomtrolled output. To stderr: In PyType_ClearCache (Objects/typeobject.c) if MCACHE_STATS is defined. Lists allocations if SHOW_ALLOC_COUNT is defined. Tuples allocations if SHOW_TRACK_COUNT is defined. Interned strings statistics if __INSURE__ is defined. In Python/ceval.c if WITH_TSC is defined. In _PyHash_Fini if Py_HASH_STATS is defined. To stdout: In Modules/_ctypes/malloc_closure.c if MALLOC_CLOSURE_DEBUG is defined. Regex matching trace in Modules/_sre.c if VERBOSE is defined. Statistics in Modules/hashtable.c if Py_DEBUG is defined. Allocation counts if COUNT_ALLOCS is defined. There is also dead code in Parser/parsetok.c, Parser/tokenizer.c, Python/pyarena.c, Python/compile.c, Python/formatter_unicode.c, Modules/_elementtree.c, Modules/_tkinter.c, Objects/unicodeobject.c. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 15:57:32 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 12 Dec 2014 14:57:32 +0000 Subject: [issue23038] #python.web irc channel is dead In-Reply-To: <1418395473.68.0.943574829813.issue23038@psf.upfronthosting.co.za> Message-ID: <20141212145704.54586.55445@psf.io> Roundup Robot added the comment: New changeset 1edff7001f58 by Benjamin Peterson in branch '2.7': remove reference to dead irc channel (closes #23038) https://hg.python.org/cpython/rev/1edff7001f58 New changeset aba5f771f5ec by Benjamin Peterson in branch '3.4': remove reference to dead irc channel (closes #23038) https://hg.python.org/cpython/rev/aba5f771f5ec ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 16:33:43 2014 From: report at bugs.python.org (Philip Lee) Date: Fri, 12 Dec 2014 15:33:43 +0000 Subject: [issue23039] File name restriction on Windows Message-ID: <1418398423.1.0.43489098063.issue23039@psf.upfronthosting.co.za> New submission from Philip Lee: when using open(filename, 'w') on Windows , File names are not allowed to contain any characters in \/:*?"<>| , however open(filename, 'w') doesn't throw any exceptions when the file name contains these characters . I think some warning should be written in the documentation or exceptions thrown should happen when the file name contains these characters . ---------- components: IO messages: 232555 nosy: iMath priority: normal severity: normal status: open title: File name restriction on Windows type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 16:34:59 2014 From: report at bugs.python.org (Wojtek Ruszczewski) Date: Fri, 12 Dec 2014 15:34:59 +0000 Subject: [issue23040] Better documentation for the urlencode safe parameter Message-ID: <1418398499.72.0.468214874616.issue23040@psf.upfronthosting.co.za> New submission from Wojtek Ruszczewski: The documentation for urlencode() [1] isn't very clear on how the safe parameter is used, it would better not list it together with encoding and error as only applying to strings. [1] https://docs.python.org/3.5/library/urllib.parse.html#urllib.parse.urlencode ---------- assignee: docs at python components: Documentation files: urlencode-safe.diff keywords: patch messages: 232556 nosy: docs at python, wrwrwr priority: normal severity: normal status: open title: Better documentation for the urlencode safe parameter type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file37426/urlencode-safe.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 17:20:10 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 12 Dec 2014 16:20:10 +0000 Subject: [issue23039] File name restriction on Windows In-Reply-To: <1418398423.1.0.43489098063.issue23039@psf.upfronthosting.co.za> Message-ID: <1418401210.55.0.251456676258.issue23039@psf.upfronthosting.co.za> R. David Murray added the comment: The argument to open is a path. Some of those characters have a meaning in a path. I ran a couple of quick experiments: "ab*c.txt" fails with an exception. ":16.txt" created a file, which I can do an 'ls' and cat (but not rm) on in git-bash, but I'm not sure where it actually is in the file system. Open is just calling the OS to do the open, so if no error is raised, the *OS* (Windows) is not raising the error. I don't think there is a bug here, unless it is in Windows itself. ---------- components: +Windows nosy: +r.david.murray, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 17:26:16 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 12 Dec 2014 16:26:16 +0000 Subject: [issue23040] Better documentation for the urlencode safe parameter In-Reply-To: <1418398499.72.0.468214874616.issue23040@psf.upfronthosting.co.za> Message-ID: <1418401576.95.0.586795102276.issue23040@psf.upfronthosting.co.za> R. David Murray added the comment: The current documentation looks very clear to me, and I don't understand your changed version. Can you give an example of how the existing text is inaccurate or results in confusion? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 17:29:18 2014 From: report at bugs.python.org (Tim Golden) Date: Fri, 12 Dec 2014 16:29:18 +0000 Subject: [issue23039] File name restriction on Windows In-Reply-To: <1418398423.1.0.43489098063.issue23039@psf.upfronthosting.co.za> Message-ID: <1418401758.22.0.134362103123.issue23039@psf.upfronthosting.co.za> Tim Golden added the comment: Agree with RDM: we're just passing the path through to the Windows API (on Windows). We don't generally carry out this kind of pre-emptive check. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 17:36:45 2014 From: report at bugs.python.org (Samwyse) Date: Fri, 12 Dec 2014 16:36:45 +0000 Subject: [issue23041] csv needs more quoting rules Message-ID: <1418402205.61.0.685044268577.issue23041@psf.upfronthosting.co.za> New submission from Samwyse: The csv module currently implements four quoting rules for dialects: QUOTE_MINIMAL, QUOTE_ALL, QUOTE_NONNUMERIC and QUOTE_NONE. These rules treat values of None the same as an empty string, i.e. by outputting two consecutive quotes. I propose the addition of two new rules, QUOTE_NOTNULL and QUOTE_STRINGS. The former behaves like QUOTE_ALL while the later behaves like QUOTE_NONNUMERIC, except that in both cases values of None are output as an empty field. Examples follow. Current behavior (which will remain unchanged) >>> csv.register_dialect('quote_all', quoting=csv.QUOTE_ALL) >>> csv.writer(sys.stdout, dialect='quote_all').writerow(['foo', None, 42]) "foo","","42" >>> csv.register_dialect('quote_nonnumeric', quoting=csv.QUOTE_NONNUMERIC) >>> csv.writer(sys.stdout, dialect='quote_nonnumeric').writerow(['foo', None, 42]) "foo","",42 Proposed behavior >>> csv.register_dialect('quote_notnull', quoting=csv.QUOTE_NOTNULL) >>> csv.writer(sys.stdout, dialect='quote_notnull').writerow(['foo', None, 42]) "foo",,"42" >>> csv.register_dialect('quote_strings', quoting=csv.QUOTE_STRINGS) >>> csv.writer(sys.stdout, dialect='quote_strings').writerow(['foo', None, 42]) "foo",,42 ---------- components: Library (Lib) messages: 232560 nosy: samwyse priority: normal severity: normal status: open title: csv needs more quoting rules type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 17:52:33 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 12 Dec 2014 16:52:33 +0000 Subject: [issue23041] csv needs more quoting rules In-Reply-To: <1418402205.61.0.685044268577.issue23041@psf.upfronthosting.co.za> Message-ID: <1418403153.39.0.137710360481.issue23041@psf.upfronthosting.co.za> R. David Murray added the comment: As an enhancement, this could be added only to 3.5. The proposal sounds reasonable to me. ---------- keywords: +easy nosy: +r.david.murray stage: -> needs patch versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 18:04:37 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 12 Dec 2014 17:04:37 +0000 Subject: [issue9536] defaultdict doc makes incorrect reference to __missing__ method In-Reply-To: <1281106528.37.0.0435364267174.issue9536@psf.upfronthosting.co.za> Message-ID: <1418403877.69.0.393678215912.issue9536@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 18:26:53 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 12 Dec 2014 17:26:53 +0000 Subject: [issue23014] Don't have importlib.abc.Loader.create_module() be optional In-Reply-To: <1418055538.78.0.471721917483.issue23014@psf.upfronthosting.co.za> Message-ID: <1418405213.2.0.679894958698.issue23014@psf.upfronthosting.co.za> Brett Cannon added the comment: Here is a patch that makes sure that if exec_module() is defined then so is create_module(). There really isn't any benefit in the code now, but starting in Python 3.6 we can make a very clear code path delineation between spec-based loading and old-fashioned load_module() instead of the current solution we have now where create_module() is used for either path and everything is intertwined. ---------- keywords: +patch stage: test needed -> patch review Added file: http://bugs.python.org/file37427/require_create_module.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 18:27:18 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 12 Dec 2014 17:27:18 +0000 Subject: [issue23013] Tweak wording for importlib.util.LazyLoader in regards to Loader.create_module() In-Reply-To: <1418054954.8.0.232826100302.issue23013@psf.upfronthosting.co.za> Message-ID: <1418405238.32.0.639969289379.issue23013@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- dependencies: +Don't have importlib.abc.Loader.create_module() be optional _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 18:27:41 2014 From: report at bugs.python.org (Samwyse) Date: Fri, 12 Dec 2014 17:27:41 +0000 Subject: [issue23041] csv needs more quoting rules In-Reply-To: <1418402205.61.0.685044268577.issue23041@psf.upfronthosting.co.za> Message-ID: <1418405261.6.0.0580801462027.issue23041@psf.upfronthosting.co.za> Samwyse added the comment: David: That's not a problem for me. Sorry I can't provide real patches, but I'm not in a position to compile (much less test) the C implementation of _csv. I've looked at the code online and below are the changes that I think need to be made. My use cases don't require special handing when reading empty fields, so the only changes I've made are to the code for writers. I did verify that the reader code mostly only checks for QUOTE_NOTNULL when parsing. This means that completely empty fields will continue to load as zero-length strings, not None. I won't stand in the way of anyone wanting to "fix" that for these new rules. typedef enum { QUOTE_MINIMAL, QUOTE_ALL, QUOTE_NONNUMERIC, QUOTE_NONE, QUOTE_STRINGS, QUOTE_NOTNULL } QuoteStyle; static StyleDesc quote_styles[] = { { QUOTE_MINIMAL, "QUOTE_MINIMAL" }, { QUOTE_ALL, "QUOTE_ALL" }, { QUOTE_NONNUMERIC, "QUOTE_NONNUMERIC" }, { QUOTE_NONE, "QUOTE_NONE" }, { QUOTE_STRINGS, "QUOTE_STRINGS" }, { QUOTE_NOTNULL, "QUOTE_NOTNULL" }, { 0 } }; switch (dialect->quoting) { case QUOTE_NONNUMERIC: quoted = !PyNumber_Check(field); break; case QUOTE_ALL: quoted = 1; break; case QUOTE_STRINGS: quoted = PyString_Check(field); break; case QUOTE_NOTNULL: quoted = field != Py_None; break; default: quoted = 0; break; } " csv.QUOTE_MINIMAL means only when required, for example, when a\n" " field contains either the quotechar or the delimiter\n" " csv.QUOTE_ALL means that quotes are always placed around fields.\n" " csv.QUOTE_NONNUMERIC means that quotes are always placed around\n" " fields which do not parse as integers or floating point\n" " numbers.\n" " csv.QUOTE_STRINGS means that quotes are always placed around\n" " fields which are strings. Note that the Python value None\n" " is not a string.\n" " csv.QUOTE_NOTNULL means that quotes are only placed around fields\n" " that are not the Python value None.\n" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 18:28:00 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 12 Dec 2014 17:28:00 +0000 Subject: [issue23013] Tweak wording for importlib.util.LazyLoader in regards to Loader.create_module() In-Reply-To: <1418054954.8.0.232826100302.issue23013@psf.upfronthosting.co.za> Message-ID: <1418405280.57.0.317066245753.issue23013@psf.upfronthosting.co.za> Brett Cannon added the comment: Fix is part of issue #23014, so if that goes in then this will be fixed as a side-effect. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 18:30:20 2014 From: report at bugs.python.org (Wojtek Ruszczewski) Date: Fri, 12 Dec 2014 17:30:20 +0000 Subject: [issue23040] Better documentation for the urlencode safe parameter In-Reply-To: <1418398499.72.0.468214874616.issue23040@psf.upfronthosting.co.za> Message-ID: <1418405420.67.0.0646374777583.issue23040@psf.upfronthosting.co.za> Wojtek Ruszczewski added the comment: I was looking at the sentence: "When query parameter is a str, the safe, encoding and error parameters are passed down to quote_plus() for encoding." The query argument can't be a string itself (gives a TypeError with 3.5a0 and I think it's only intended to accept dicts or sequences of 2-tuples). The "parameter" then must refer to a component of the query -- a key or a value. The safe argument is passed down and is effective no matter if a component is of str or bytes type (or a sequence with doseq), for example: >>> urlencode({b'/ n': ''}, safe='/') '/+n=' (note the "b"; without "safe" the slash would get encoded as %2F). Maybe it would also be good to change "query parameter" to "query component" in that sentence. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 18:30:24 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 12 Dec 2014 17:30:24 +0000 Subject: [issue21581] Consider dropping importlib.abc.Loader.create_module() In-Reply-To: <1401115897.78.0.38815519118.issue21581@psf.upfronthosting.co.za> Message-ID: <1418405424.48.0.841831332222.issue21581@psf.upfronthosting.co.za> Brett Cannon added the comment: Issue #23014 is planning to make create_module() required so that module creation doesn't have a two-tiered way of specifying a default module (which is handy in C code). ---------- dependencies: +Don't have importlib.abc.Loader.create_module() be optional _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 18:31:08 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 12 Dec 2014 17:31:08 +0000 Subject: [issue21581] Consider dropping importlib.abc.Loader.create_module() In-Reply-To: <1401115897.78.0.38815519118.issue21581@psf.upfronthosting.co.za> Message-ID: <1418405468.42.0.389368663073.issue21581@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 18:36:42 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 12 Dec 2014 17:36:42 +0000 Subject: [issue21099] Switch applicable importlib tests to use PEP 451 API In-Reply-To: <1396128875.13.0.712473033591.issue21099@psf.upfronthosting.co.za> Message-ID: <1418405802.1.0.207595003713.issue21099@psf.upfronthosting.co.za> Brett Cannon added the comment: Should this be closed, Eric? ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 18:37:42 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 12 Dec 2014 17:37:42 +0000 Subject: [issue19711] add test for changed portions after reloading a namespace package In-Reply-To: <1385138827.34.0.898717139288.issue19711@psf.upfronthosting.co.za> Message-ID: <1418405862.08.0.316391076968.issue19711@psf.upfronthosting.co.za> Brett Cannon added the comment: Do we still need this patch, Eric? ---------- status: open -> pending versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 18:40:19 2014 From: report at bugs.python.org (Brett Cannon) Date: Fri, 12 Dec 2014 17:40:19 +0000 Subject: [issue19698] Implement _imp.exec_builtin and exec_dynamic In-Reply-To: <1385137675.64.0.235823443194.issue19698@psf.upfronthosting.co.za> Message-ID: <1418406019.73.0.122534656856.issue19698@psf.upfronthosting.co.za> Brett Cannon added the comment: I would still like to get this solved for Python 3.5. Should we hash out a solution at PyCon? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 18:50:12 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 12 Dec 2014 17:50:12 +0000 Subject: [issue22919] Update PCBuild for VS 2015 In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za> Message-ID: <20141212174948.117631.57937@psf.io> Roundup Robot added the comment: New changeset 5754f069b123 by Steve Dower in branch 'default': Issue #22919: Windows build updated to support VC 14.0 (Visual Studio 2015), which will be used for the official 3.5 release. https://hg.python.org/cpython/rev/5754f069b123 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 19:01:49 2014 From: report at bugs.python.org (Steve Dower) Date: Fri, 12 Dec 2014 18:01:49 +0000 Subject: [issue22919] Update PCBuild for VS 2015 In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za> Message-ID: <1418407309.21.0.530837424981.issue22919@psf.upfronthosting.co.za> Steve Dower added the comment: I'll be closely tracking any issues that arise out of this throughout the next couple of days, but it should be fairly smooth (especially for people who don't upgrade VS immediately). There are certainly a few things that are broken, but I'll make separate issues for those. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 20:41:50 2014 From: report at bugs.python.org (David Watson) Date: Fri, 12 Dec 2014 19:41:50 +0000 Subject: [issue9647] os.confstr() does not handle value changing length between calls In-Reply-To: <1417987668.88.0.424426177041.issue9647@psf.upfronthosting.co.za> Message-ID: <20141212194150.GA15494@dbwatson.uk7.net> David Watson added the comment: Here are the alternative patches to allow more than two calls to confstr(). One patch set just keeps reallocating the buffer until it's big enough, while the other makes a limited number of attempts (in this case 20) before raising RuntimeError. ---------- keywords: +patch Added file: http://bugs.python.org/file37428/confstr-realloc-endless-2.7.diff Added file: http://bugs.python.org/file37429/confstr-realloc-endless-3.4.diff Added file: http://bugs.python.org/file37430/confstr-realloc-endless-3.5.diff Added file: http://bugs.python.org/file37431/confstr-realloc-limited-2.7.diff Added file: http://bugs.python.org/file37432/confstr-realloc-limited-3.4.diff Added file: http://bugs.python.org/file37433/confstr-realloc-limited-3.5.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- # HG changeset patch # Parent 1edff7001f589dffaf8de4aebcb65a1f1d7deb5c diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c --- a/Modules/posixmodule.c +++ b/Modules/posixmodule.c @@ -7936,12 +7936,24 @@ posix_confstr(PyObject *self, PyObject * PyObject *result = NULL; int name; char buffer[256]; + char *recvbuf = buffer; + char *allocated = NULL; + size_t buflen = sizeof(buffer); + size_t len; if (PyArg_ParseTuple(args, "O&:confstr", conv_confstr_confname, &name)) { - int len; - - errno = 0; - len = confstr(name, buffer, sizeof(buffer)); + + /* Reset errno before each call as we may need to check it afterwards */ + while (errno = 0, (len = confstr(name, recvbuf, buflen)) > buflen) { + recvbuf = PyMem_Realloc(allocated, len); + if (recvbuf == NULL) { + PyErr_NoMemory(); + goto finally; + } + allocated = recvbuf; + buflen = len; + } + if (len == 0) { if (errno) { posix_error(); @@ -7952,15 +7964,11 @@ posix_confstr(PyObject *self, PyObject * } } else { - if ((unsigned int)len >= sizeof(buffer)) { - result = PyString_FromStringAndSize(NULL, len-1); - if (result != NULL) - confstr(name, PyString_AS_STRING(result), len); - } - else - result = PyString_FromStringAndSize(buffer, len-1); - } - } + result = PyString_FromStringAndSize(recvbuf, len-1); + } + } +finally: + PyMem_Free(allocated); return result; } #endif -------------- next part -------------- # HG changeset patch # Parent aba5f771f5ec9e4004c0375ab4302f246a04bae7 diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c --- a/Modules/posixmodule.c +++ b/Modules/posixmodule.c @@ -9727,33 +9727,38 @@ posix_confstr(PyObject *self, PyObject * PyObject *result = NULL; int name; char buffer[255]; + char *recvbuf = buffer; + char *allocated = NULL; + size_t buflen = sizeof(buffer); size_t len; if (!PyArg_ParseTuple(args, "O&:confstr", conv_confstr_confname, &name)) return NULL; - errno = 0; - len = confstr(name, buffer, sizeof(buffer)); + /* Reset errno before each call as we may need to check it afterwards */ + while (errno = 0, (len = confstr(name, recvbuf, buflen)) > buflen) { + recvbuf = PyMem_Realloc(allocated, len); + if (recvbuf == NULL) { + PyErr_NoMemory(); + goto finally; + } + allocated = recvbuf; + buflen = len; + } + if (len == 0) { if (errno) { posix_error(); - return NULL; } else { - Py_RETURN_NONE; - } - } - - if (len >= sizeof(buffer)) { - char *buf = PyMem_Malloc(len); - if (buf == NULL) - return PyErr_NoMemory(); - confstr(name, buf, len); - result = PyUnicode_DecodeFSDefaultAndSize(buf, len-1); - PyMem_Free(buf); + result = Py_None; + Py_INCREF(Py_None); + } } else - result = PyUnicode_DecodeFSDefaultAndSize(buffer, len-1); + result = PyUnicode_DecodeFSDefaultAndSize(recvbuf, len-1); +finally: + PyMem_Free(allocated); return result; } #endif -------------- next part -------------- # HG changeset patch # Parent 5754f069b12342acb69dff739782416092522748 diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c --- a/Modules/posixmodule.c +++ b/Modules/posixmodule.c @@ -14372,32 +14372,35 @@ os_confstr_impl(PyModuleDef *module, int { PyObject *result = NULL; char buffer[255]; + char *recvbuf = buffer; + char *allocated = NULL; + size_t buflen = sizeof(buffer); size_t len; - errno = 0; - len = confstr(name, buffer, sizeof(buffer)); + /* Reset errno before each call as we may need to check it afterwards */ + while (errno = 0, (len = confstr(name, recvbuf, buflen)) > buflen) { + recvbuf = PyMem_Realloc(allocated, len); + if (recvbuf == NULL) { + PyErr_NoMemory(); + goto finally; + } + allocated = recvbuf; + buflen = len; + } + if (len == 0) { if (errno) { posix_error(); - return NULL; } else { - Py_RETURN_NONE; - } - } - - if (len >= sizeof(buffer)) { - size_t len2; - char *buf = PyMem_Malloc(len); - if (buf == NULL) - return PyErr_NoMemory(); - len2 = confstr(name, buf, len); - assert(len == len2); - result = PyUnicode_DecodeFSDefaultAndSize(buf, len-1); - PyMem_Free(buf); - } - else - result = PyUnicode_DecodeFSDefaultAndSize(buffer, len-1); + result = Py_None; + Py_INCREF(Py_None); + } + } + else + result = PyUnicode_DecodeFSDefaultAndSize(recvbuf, len-1); +finally: + PyMem_Free(allocated); return result; } #endif /* HAVE_CONFSTR */ -------------- next part -------------- # HG changeset patch # Parent 1edff7001f589dffaf8de4aebcb65a1f1d7deb5c diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c --- a/Modules/posixmodule.c +++ b/Modules/posixmodule.c @@ -7936,12 +7936,32 @@ posix_confstr(PyObject *self, PyObject * PyObject *result = NULL; int name; char buffer[256]; + char *recvbuf = buffer; + char *allocated = NULL; + size_t buflen = sizeof(buffer); + size_t len; + const int max_attempts = 20; + int attempts_remaining = max_attempts; if (PyArg_ParseTuple(args, "O&:confstr", conv_confstr_confname, &name)) { - int len; - - errno = 0; - len = confstr(name, buffer, sizeof(buffer)); + + /* Reset errno before each call as we may need to check it afterwards */ + while (errno = 0, (len = confstr(name, recvbuf, buflen)) > buflen) { + if (--attempts_remaining <= 0) { + PyErr_Format(PyExc_RuntimeError, + "confstr() made %d consecutive requests for a larger " + "buffer; giving up", max_attempts); + goto finally; + } + recvbuf = PyMem_Realloc(allocated, len); + if (recvbuf == NULL) { + PyErr_NoMemory(); + goto finally; + } + allocated = recvbuf; + buflen = len; + } + if (len == 0) { if (errno) { posix_error(); @@ -7952,15 +7972,11 @@ posix_confstr(PyObject *self, PyObject * } } else { - if ((unsigned int)len >= sizeof(buffer)) { - result = PyString_FromStringAndSize(NULL, len-1); - if (result != NULL) - confstr(name, PyString_AS_STRING(result), len); - } - else - result = PyString_FromStringAndSize(buffer, len-1); - } - } + result = PyString_FromStringAndSize(recvbuf, len-1); + } + } +finally: + PyMem_Free(allocated); return result; } #endif -------------- next part -------------- # HG changeset patch # Parent aba5f771f5ec9e4004c0375ab4302f246a04bae7 diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c --- a/Modules/posixmodule.c +++ b/Modules/posixmodule.c @@ -9727,33 +9727,46 @@ posix_confstr(PyObject *self, PyObject * PyObject *result = NULL; int name; char buffer[255]; + char *recvbuf = buffer; + char *allocated = NULL; + size_t buflen = sizeof(buffer); size_t len; + const int max_attempts = 20; + int attempts_remaining = max_attempts; if (!PyArg_ParseTuple(args, "O&:confstr", conv_confstr_confname, &name)) return NULL; - errno = 0; - len = confstr(name, buffer, sizeof(buffer)); + /* Reset errno before each call as we may need to check it afterwards */ + while (errno = 0, (len = confstr(name, recvbuf, buflen)) > buflen) { + if (--attempts_remaining <= 0) { + PyErr_Format(PyExc_RuntimeError, + "confstr() made %d consecutive requests for a larger " + "buffer; giving up", max_attempts); + goto finally; + } + recvbuf = PyMem_Realloc(allocated, len); + if (recvbuf == NULL) { + PyErr_NoMemory(); + goto finally; + } + allocated = recvbuf; + buflen = len; + } + if (len == 0) { if (errno) { posix_error(); - return NULL; } else { - Py_RETURN_NONE; - } - } - - if (len >= sizeof(buffer)) { - char *buf = PyMem_Malloc(len); - if (buf == NULL) - return PyErr_NoMemory(); - confstr(name, buf, len); - result = PyUnicode_DecodeFSDefaultAndSize(buf, len-1); - PyMem_Free(buf); + result = Py_None; + Py_INCREF(Py_None); + } } else - result = PyUnicode_DecodeFSDefaultAndSize(buffer, len-1); + result = PyUnicode_DecodeFSDefaultAndSize(recvbuf, len-1); +finally: + PyMem_Free(allocated); return result; } #endif -------------- next part -------------- # HG changeset patch # Parent 5754f069b12342acb69dff739782416092522748 diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c --- a/Modules/posixmodule.c +++ b/Modules/posixmodule.c @@ -14372,32 +14372,43 @@ os_confstr_impl(PyModuleDef *module, int { PyObject *result = NULL; char buffer[255]; + char *recvbuf = buffer; + char *allocated = NULL; + size_t buflen = sizeof(buffer); size_t len; - - errno = 0; - len = confstr(name, buffer, sizeof(buffer)); + const int max_attempts = 20; + int attempts_remaining = max_attempts; + + /* Reset errno before each call as we may need to check it afterwards */ + while (errno = 0, (len = confstr(name, recvbuf, buflen)) > buflen) { + if (--attempts_remaining <= 0) { + PyErr_Format(PyExc_RuntimeError, + "confstr() made %d consecutive requests for a larger " + "buffer; giving up", max_attempts); + goto finally; + } + recvbuf = PyMem_Realloc(allocated, len); + if (recvbuf == NULL) { + PyErr_NoMemory(); + goto finally; + } + allocated = recvbuf; + buflen = len; + } + if (len == 0) { if (errno) { posix_error(); - return NULL; } else { - Py_RETURN_NONE; - } - } - - if (len >= sizeof(buffer)) { - size_t len2; - char *buf = PyMem_Malloc(len); - if (buf == NULL) - return PyErr_NoMemory(); - len2 = confstr(name, buf, len); - assert(len == len2); - result = PyUnicode_DecodeFSDefaultAndSize(buf, len-1); - PyMem_Free(buf); - } - else - result = PyUnicode_DecodeFSDefaultAndSize(buffer, len-1); + result = Py_None; + Py_INCREF(Py_None); + } + } + else + result = PyUnicode_DecodeFSDefaultAndSize(recvbuf, len-1); +finally: + PyMem_Free(allocated); return result; } #endif /* HAVE_CONFSTR */ From report at bugs.python.org Fri Dec 12 21:32:17 2014 From: report at bugs.python.org (Eldar Abusalimov) Date: Fri, 12 Dec 2014 20:32:17 +0000 Subject: [issue22735] Fix various crashes exposed through mro() customization In-Reply-To: <1414357581.7.0.216281535095.issue22735@psf.upfronthosting.co.za> Message-ID: <1418416337.67.0.0597563342706.issue22735@psf.upfronthosting.co.za> Eldar Abusalimov added the comment: ping? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 21:40:59 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 12 Dec 2014 20:40:59 +0000 Subject: [issue23042] Python 2.7.9 ctypes module doesn't build on FreeBSD x86 Message-ID: <1418416859.8.0.212660740366.issue23042@psf.upfronthosting.co.za> New submission from Marc-Andre Lemburg: With Python 2.7.8, ctypes builds fine on FreeBSD x86, but with Python 2.7.9, the build fails with: *** WARNING: renaming "_ctypes" since importing it failed: build/lib.freebsd-8.3-RELEASE-p3-i386-2.7/_ctypes.so: Undefined symbol "ffi_call_win32" Since this is FreeBSD, there shouldn't really be any calls to ffi_call_win32() in the _ctypes module or libffi. Looking at the code changes in libffi/src/x86/ffi.c, it looks as if some of the #ifdefs for X86_WIN64 and X86_WIN32 were mixed up, causing calls to the Windows function to be compiled on FreeBSD x86, without also compiling the function definition in the same file. ---------- components: Build, ctypes messages: 232574 nosy: lemburg priority: normal severity: normal status: open title: Python 2.7.9 ctypes module doesn't build on FreeBSD x86 versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 21:50:31 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 12 Dec 2014 20:50:31 +0000 Subject: [issue23042] Python 2.7.9 ctypes module doesn't build on FreeBSD x86 In-Reply-To: <1418416859.8.0.212660740366.issue23042@psf.upfronthosting.co.za> Message-ID: <1418417431.28.0.236333239502.issue23042@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: The cause seems to be these changes of the file (diff between the 2.7.8 and 2.7.9 version): @@ -368,14 +374,21 @@ void ffi_call(ffi_cif *cif, void (*fn)(v #ifdef X86_WIN64 case FFI_WIN64: ffi_call_win64(ffi_prep_args, &ecif, cif->bytes, cif->flags, ecif.rvalue, fn); break; -#elif defined(X86_WIN32) +#else +#ifndef X86_WIN32 + case FFI_SYSV: + ffi_call_SYSV(ffi_prep_args, &ecif, cif->bytes, cif->flags, ecif.rvalue, + fn); + break; +#else case FFI_SYSV: - case FFI_STDCALL: case FFI_MS_CDECL: +#endif + case FFI_STDCALL: ffi_call_win32(ffi_prep_args, &ecif, cif->abi, cif->bytes, cif->flags, ecif.rvalue, fn); break; case FFI_THISCALL: case FFI_FASTCALL: @@ -404,15 +417,10 @@ void ffi_call(ffi_cif *cif, void (*fn)(v abi = FFI_STDCALL; ffi_call_win32(ffi_prep_args, &ecif, abi, cif->bytes, cif->flags, ecif.rvalue, fn); } break; -#else - case FFI_SYSV: - ffi_call_SYSV(ffi_prep_args, &ecif, cif->bytes, cif->flags, ecif.rvalue, - fn); - break; #endif default: FFI_ASSERT(0); break; } @@ -785,14 +797,21 @@ ffi_raw_call(ffi_cif *cif, void (*fn)(vo ecif.rvalue = rvalue; switch (cif->abi) { -#ifdef X86_WIN32 +#ifndef X86_WIN32 + case FFI_SYSV: + ffi_call_SYSV(ffi_prep_args_raw, &ecif, cif->bytes, cif->flags, + ecif.rvalue, fn); + break; +#else case FFI_SYSV: - case FFI_STDCALL: case FFI_MS_CDECL: +#endif +#ifndef X86_WIN64 + case FFI_STDCALL: ffi_call_win32(ffi_prep_args_raw, &ecif, cif->abi, cif->bytes, cif->flags, ecif.rvalue, fn); break; case FFI_THISCALL: case FFI_FASTCALL: @@ -821,15 +840,10 @@ ffi_raw_call(ffi_cif *cif, void (*fn)(vo cif->abi = abi = FFI_STDCALL; ffi_call_win32(ffi_prep_args_raw, &ecif, abi, cif->bytes, cif->flags, ecif.rvalue, fn); } break; -#else - case FFI_SYSV: - ffi_call_SYSV(ffi_prep_args_raw, &ecif, cif->bytes, cif->flags, - ecif.rvalue, fn); - break; #endif default: FFI_ASSERT(0); break; } If neither X86_WIN64 nor X86_WIN32 are defined, the #ifndefs cause the functions calls to be compiled in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 22:07:38 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 12 Dec 2014 21:07:38 +0000 Subject: [issue23040] Better documentation for the urlencode safe parameter In-Reply-To: <1418398499.72.0.468214874616.issue23040@psf.upfronthosting.co.za> Message-ID: <1418418458.06.0.632229076486.issue23040@psf.upfronthosting.co.za> R. David Murray added the comment: OK, now I understand. How about this phrasing: "The *safe*, *encoding*, and *error* parameters are passed down to :func:`quote_plus` (the *encoding* and *error* parameters are only passed when the query element is a :class:`str`). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 22:28:18 2014 From: report at bugs.python.org (Vjacheslav) Date: Fri, 12 Dec 2014 21:28:18 +0000 Subject: [issue23043] doctest ignores "from __future__ import print_function" Message-ID: <1418419698.58.0.173848086418.issue23043@psf.upfronthosting.co.za> New submission from Vjacheslav: >>> from __future__ import print_function >>> print (1,2) 1 2 in interactive session, but, with this 3 lines in tmp.txt: python -m doctest tmp.txt fails (prints tuple) ---------- components: Library (Lib) messages: 232577 nosy: fva priority: normal severity: normal status: open title: doctest ignores "from __future__ import print_function" type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 12 23:15:20 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 12 Dec 2014 22:15:20 +0000 Subject: [issue23035] python -c: Line causing exception not shown for exceptions other than SyntaxErrors In-Reply-To: <1418348647.52.0.502974463654.issue23035@psf.upfronthosting.co.za> Message-ID: <1418422520.97.0.550310668964.issue23035@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: It should not be more complex to read a line from a command line argument than to read a line from a regular file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 00:35:02 2014 From: report at bugs.python.org (Wojtek Ruszczewski) Date: Fri, 12 Dec 2014 23:35:02 +0000 Subject: [issue23040] Better documentation for the urlencode safe parameter In-Reply-To: <1418398499.72.0.468214874616.issue23040@psf.upfronthosting.co.za> Message-ID: <1418427302.41.0.671036714488.issue23040@psf.upfronthosting.co.za> Wojtek Ruszczewski added the comment: Thanks, that's right and better, as it doesn't replicate the safe explanation. I've just noticed another small one, the docstring for quote() [2] says: "encoding must not be specified if string is a str" -- that should be "... is a bytes". [2] https://hg.python.org/cpython/file/default/Lib/urllib/parse.py#l690 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 01:17:54 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 13 Dec 2014 00:17:54 +0000 Subject: [issue22823] Use set literals instead of creating a set from a list In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za> Message-ID: <1418429874.3.0.114385538828.issue22823@psf.upfronthosting.co.za> Benjamin Peterson added the comment: 2to3 patch lgtm. Please apply to 3.4, too, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 01:43:07 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 13 Dec 2014 00:43:07 +0000 Subject: [issue23011] Duplicate Paragraph in documentation for json module In-Reply-To: <1418047735.37.0.83441849339.issue23011@psf.upfronthosting.co.za> Message-ID: <1418431387.19.0.877982995403.issue23011@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The section documents JSONDecoder and then JSONEncoder. Looking at the current 3.4 online docs, I do not see any significant duplication within either entry. Even if there were duplication between, we might leave it to keep the entries complete in themselves. But not seeing any, this is moot. ---------- nosy: +terry.reedy versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 02:20:21 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 13 Dec 2014 01:20:21 +0000 Subject: [issue23035] python -c: Line causing exception not shown for exceptions other than SyntaxErrors In-Reply-To: <1418348647.52.0.502974463654.issue23035@psf.upfronthosting.co.za> Message-ID: <1418433621.44.0.207885213575.issue23035@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Code entered with -c seems to be treated the same as code entered at the >>> prompt of the interactive interpreter. >>> 1/0 Traceback (most recent call last): File "", line 1, in ZeroDivisionError: division by zero In both cases, the offending code is right there to be seen, so I can understand reluctance to echo it. For SyntaxErrors (and only them) echoing the code is needed to have something to point to. Idle's Shell does what you want. >>> 1/0 Traceback (most recent call last): File "", line 1, in 1/0 ZeroDivisionError: division by zero Shell can do this because it has easy, platform-independent access to the tkinter Text widget storing and displaying previously entered code. I presume accessing a system-dependent console history buffer is much harder. Where the difference really matters is when the error is in previously defined objects. >>> def f(): ... return a >>> f() Traceback (most recent call last): File "", line 1, in File "", line 2, in f NameError: name 'a' is not defined versus (Shell) >>> def f(): return a >>> f() Traceback (most recent call last): File "", line 1, in f() File "", line 2, in f return a NameError: name 'a' is not defined ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 02:32:49 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 13 Dec 2014 01:32:49 +0000 Subject: [issue23035] python -c: Line causing exception not shown for exceptions other than SyntaxErrors In-Reply-To: <1418348647.52.0.502974463654.issue23035@psf.upfronthosting.co.za> Message-ID: <1418434369.37.0.409501447657.issue23035@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: Argument of -c option can have multiple lines, while only 1 line can be directly entered in interactive interpreter. python -c $'line1\nline2\nline3\nline4\n...' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 02:37:45 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 13 Dec 2014 01:37:45 +0000 Subject: [issue18373] implement sys.get/setbyteswarningflag() In-Reply-To: <1373065124.82.0.249288626652.issue18373@psf.upfronthosting.co.za> Message-ID: <1418434665.43.0.0994130949969.issue18373@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 02:42:12 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 13 Dec 2014 01:42:12 +0000 Subject: [issue18679] include a codec to handle escaping only control characters but not any others In-Reply-To: <1375910565.85.0.834240880509.issue18679@psf.upfronthosting.co.za> Message-ID: <1418434932.82.0.381267246158.issue18679@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 02:58:30 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 13 Dec 2014 01:58:30 +0000 Subject: [issue5166] ElementTree and minidom don't prevent creation of not well-formed XML In-Reply-To: <1233918825.25.0.360851750395.issue5166@psf.upfronthosting.co.za> Message-ID: <1418435910.31.0.24270027785.issue5166@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 03:15:23 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 13 Dec 2014 02:15:23 +0000 Subject: [issue23035] python -c: Line causing exception not shown for exceptions other than SyntaxErrors In-Reply-To: <1418348647.52.0.502974463654.issue23035@psf.upfronthosting.co.za> Message-ID: <1418436923.35.0.426174027156.issue23035@psf.upfronthosting.co.za> Terry J. Reedy added the comment: One can paste multiple lines, comprising multiple statements, into the console interprer. (Shell only recognizes a single pasted statement.) I agree, however, that it seems that Python could keep the split version of the input line for the purpose of tracebacks. I just tried C:\Users\Terry>python -c "import sys; print(sys.argv)" ['-c'] I expected to see to see a list of 3 strings, not 1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 03:22:17 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 13 Dec 2014 02:22:17 +0000 Subject: [issue23035] python -c: Line causing exception not shown for exceptions other than SyntaxErrors In-Reply-To: <1418348647.52.0.502974463654.issue23035@psf.upfronthosting.co.za> Message-ID: <1418437337.65.0.279079735862.issue23035@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: Arguments after argument of -c option are included in sys.argv: $ python -c "import sys; print(sys.argv)" a b ['-c', 'a', 'b'] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 03:34:22 2014 From: report at bugs.python.org (Bart Grzybicki) Date: Sat, 13 Dec 2014 02:34:22 +0000 Subject: [issue23044] incorrect addition of floating point numbers Message-ID: <1418438061.96.0.666548140464.issue23044@psf.upfronthosting.co.za> New submission from Bart Grzybicki: Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 115.26 + 2.01 117.27000000000001 >>> 115.26 + 2.02 117.28 >>> 115.27 + 2.01 117.28 >>> ---------- messages: 232586 nosy: bartgee priority: normal severity: normal status: open title: incorrect addition of floating point numbers type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 03:35:10 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 13 Dec 2014 02:35:10 +0000 Subject: [issue23044] incorrect addition of floating point numbers In-Reply-To: <1418438061.96.0.666548140464.issue23044@psf.upfronthosting.co.za> Message-ID: <1418438110.53.0.216050743116.issue23044@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Welcome to base 2. https://docs.python.org/2/tutorial/floatingpoint.html ---------- nosy: +benjamin.peterson resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 03:41:05 2014 From: report at bugs.python.org (Demian Brecht) Date: Sat, 13 Dec 2014 02:41:05 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za> Message-ID: <1418438465.89.0.214619789336.issue21793@psf.upfronthosting.co.za> Demian Brecht added the comment: Updated patch addressing further reviews ---------- Added file: http://bugs.python.org/file37434/issue21793_6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 04:07:50 2014 From: report at bugs.python.org (Aaron Hill) Date: Sat, 13 Dec 2014 03:07:50 +0000 Subject: [issue23004] mock_open() should allow reading binary data In-Reply-To: <1417965857.24.0.521739131396.issue23004@psf.upfronthosting.co.za> Message-ID: <1418440070.75.0.461369461186.issue23004@psf.upfronthosting.co.za> Aaron Hill added the comment: I've created a patch that fixes this, and added an accompanying unit test (which fails without the change). ---------- keywords: +patch nosy: +Aaron1011 Added file: http://bugs.python.org/file37435/mock-open-allow-binary-data.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 04:21:49 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 13 Dec 2014 03:21:49 +0000 Subject: [issue21279] str.translate documentation incomplete In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za> Message-ID: <1418440909.43.0.455473081371.issue21279@psf.upfronthosting.co.za> Martin Panter added the comment: Update patch with typo fixed, removed note about the ?codecs? module (which I never found useful either), and updated the doc string with similar wording. Terry, do you think the wording in the patch is good enough, or do you think some of your proposed wording should be included? ---------- Added file: http://bugs.python.org/file37436/issue21279.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 04:32:41 2014 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 13 Dec 2014 03:32:41 +0000 Subject: [issue23017] string.printable.isprintable() returns False In-Reply-To: <1418097121.16.0.891016494417.issue23017@psf.upfronthosting.co.za> Message-ID: <1418441561.61.0.473993135125.issue23017@psf.upfronthosting.co.za> Changes by Steven D'Aprano : ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 04:41:18 2014 From: report at bugs.python.org (Demian Brecht) Date: Sat, 13 Dec 2014 03:41:18 +0000 Subject: [issue23004] mock_open() should allow reading binary data In-Reply-To: <1417965857.24.0.521739131396.issue23004@psf.upfronthosting.co.za> Message-ID: <1418442078.72.0.491346043221.issue23004@psf.upfronthosting.co.za> Demian Brecht added the comment: Thanks for the patch Aaron. Unfortunately this doesn't quite fix the issue. There are two problems with the patch: If a bytes object is passed into mock_open, I'd expect a bytes object in the output. In your patch, not only is this not the case (the output is a string object), but the bytes object is being coerced into its string representation in the resulting list. For example (simplified from your patch): >>> data = b'foo\nbar' >>> newline = b'\n' >>> >>> ['{}\n'.format(l) for l in data.split(newline)] ["b'foo'\n", "b'bar'\n"] What I would expect to see in this case is: [b'foo\n', b'bar\n'] ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 04:42:30 2014 From: report at bugs.python.org (Demian Brecht) Date: Sat, 13 Dec 2014 03:42:30 +0000 Subject: [issue23004] mock_open() should allow reading binary data In-Reply-To: <1417965857.24.0.521739131396.issue23004@psf.upfronthosting.co.za> Message-ID: <1418442150.13.0.230855902296.issue23004@psf.upfronthosting.co.za> Demian Brecht added the comment: > There are two problems with the patch That was intended to be removed after I changed the wording :P ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 05:06:37 2014 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 13 Dec 2014 04:06:37 +0000 Subject: [issue22979] Use of None in min and max In-Reply-To: <1417530338.57.0.34442889749.issue22979@psf.upfronthosting.co.za> Message-ID: <1418443597.85.0.717851476877.issue22979@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Even though I agree with closing this issue, there is some support for ignoring certain "missing values" when calculating min() and max(). The draft 2008 revision of IEEE-754 includes two functions maxNum and minNum which silently skip over NANs: https://en.wikipedia.org/wiki/IEEE_754_revision#min_and_max The R language also supports max and min skipping over missing values: https://stat.ethz.ch/R-manual/R-devel/library/base/html/Extremes.html The problem is that there are so many different things which somebody might want to do, it is hard to tell which (if any) the built-ins should support: - silently skip over None - or NANs - or treat some other, user-specified, value as "missing" - treat None as the smallest (or largest) value - treat the presence of None as an error - etc. I think that min() and max() should continue to be relatively simple-minded and let users write their own more complex versions if needed, e.g. by calling min(filter(condition, values)). ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 05:57:16 2014 From: report at bugs.python.org (vegeshna satyanarayana raju) Date: Sat, 13 Dec 2014 04:57:16 +0000 Subject: [issue23045] json data iteration through loop in python Message-ID: <1418446635.96.0.654636210763.issue23045@psf.upfronthosting.co.za> Changes by vegeshna satyanarayana raju : ---------- nosy: satyanani40 priority: normal severity: normal status: open title: json data iteration through loop in python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 05:59:19 2014 From: report at bugs.python.org (vegeshna satyanarayana raju) Date: Sat, 13 Dec 2014 04:59:19 +0000 Subject: [issue23045] json data iteration through loop in python Message-ID: <1418446759.27.0.0299579851537.issue23045@psf.upfronthosting.co.za> New submission from vegeshna satyanarayana raju: I have json data in following format {"message":["frappe","websocerp","erpnext"]} I want each name (frappe, websocerp, erpnext) in three iteration after that i can use as frappe.something.get_data() websocerp.something.get_data() erpnext.something.get_data() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 06:05:30 2014 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 13 Dec 2014 05:05:30 +0000 Subject: [issue23045] json data iteration through loop in python In-Reply-To: <1418446759.27.0.0299579851537.issue23045@psf.upfronthosting.co.za> Message-ID: <1418447130.31.0.304485716149.issue23045@psf.upfronthosting.co.za> Steven D'Aprano added the comment: This is a bug tracker for issues in the Python language and standard library, not a service for learning how to program using Python. If you have an actual bug to report, you should give more detail including the actual code you used, the result you expected, and the result you actually got. Otherwise you should try asking your question on the python-list at python.org mailing list, the comp.lang.python newsgroup, /r/python on Reddit, StackOverflow, or one of the many other public forums for discussing Python programming issues. ---------- nosy: +steven.daprano resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 06:08:42 2014 From: report at bugs.python.org (Demian Brecht) Date: Sat, 13 Dec 2014 05:08:42 +0000 Subject: [issue23043] doctest ignores "from __future__ import print_function" In-Reply-To: <1418419698.58.0.173848086418.issue23043@psf.upfronthosting.co.za> Message-ID: <1418447322.6.0.439454032021.issue23043@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 07:46:51 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 13 Dec 2014 06:46:51 +0000 Subject: [issue23041] csv needs more quoting rules In-Reply-To: <1418402205.61.0.685044268577.issue23041@psf.upfronthosting.co.za> Message-ID: <1418453211.0.0.640463427604.issue23041@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Samwyse, are these suggestions just based on ideas of what could be done or have you encountered real-world CSV data exchanges that couldn't be handled by the CSV module? ---------- assignee: -> skip.montanaro nosy: +rhettinger, skip.montanaro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 07:53:02 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 13 Dec 2014 06:53:02 +0000 Subject: [issue22875] asyncio: call_soon() documentation unclear on timing In-Reply-To: <1415995304.37.0.00737491261157.issue22875@psf.upfronthosting.co.za> Message-ID: <1418453582.27.0.793612227254.issue22875@psf.upfronthosting.co.za> Martin Panter added the comment: I have been bitten by this when attempting to implement my own event loops. Parts of the ?asyncio? code itself expects that the callback is not invoked directly after call_soon() returns. Here is a simple patch. ---------- keywords: +patch nosy: +vadmium versions: +Python 3.4 Added file: http://bugs.python.org/file37437/call_soon.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 08:13:12 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 13 Dec 2014 07:13:12 +0000 Subject: [issue23046] asyncio.BaseEventLoop is documented, but only exported via asyncio.base_events Message-ID: <1418454792.43.0.104807870648.issue23046@psf.upfronthosting.co.za> New submission from Martin Panter: The documentation mentions BaseEventLoop as an attribute of the ?asyncio? module, but it is not actually there (at least in v3.4.2). I have to import it specially from ?asyncio.base_events?. Is this an oversight in the documentation, or am I relying on undocumented internals? I find the BaseEventLoop class is somewhat helpful for implementing my own event loops. ---------- components: asyncio messages: 232598 nosy: gvanrossum, haypo, vadmium, yselivanov priority: normal severity: normal status: open title: asyncio.BaseEventLoop is documented, but only exported via asyncio.base_events versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 09:35:32 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 13 Dec 2014 08:35:32 +0000 Subject: [issue17128] OS X system openssl deprecated - installer should build local libssl In-Reply-To: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za> Message-ID: <20141213083525.28220.32165@psf.io> Roundup Robot added the comment: New changeset 288b03b5c60d by Ned Deily in branch '3.4': Issue #17128: Use private version of OpenSSL for 3.x OS X 10.5+ installers. https://hg.python.org/cpython/rev/288b03b5c60d New changeset 1c249d0cab5d by Ned Deily in branch 'default': Issue #17128: Merge / update from 3.4 https://hg.python.org/cpython/rev/1c249d0cab5d New changeset 961f988eaa6a by Ned Deily in branch '2.7': Use rtf format files for legacy OS X installer builds. https://hg.python.org/cpython/rev/961f988eaa6a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 11:01:17 2014 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 13 Dec 2014 10:01:17 +0000 Subject: [issue23047] typo in pyporting.rst Message-ID: <1418464877.74.0.653707717476.issue23047@psf.upfronthosting.co.za> New submission from Xavier de Gaye: In Doc/howto/pyporting.rst at line "from __future__ import print_statement": s/print_statement/print_function/ ---------- assignee: docs at python components: Documentation messages: 232600 nosy: brett.cannon, docs at python, xdegaye priority: normal severity: normal status: open title: typo in pyporting.rst type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 11:05:40 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 13 Dec 2014 10:05:40 +0000 Subject: [issue17636] Modify IMPORT_FROM to fallback on sys.modules In-Reply-To: <1365124502.39.0.727243640375.issue17636@psf.upfronthosting.co.za> Message-ID: <20141213100537.28220.21446@psf.io> Roundup Robot added the comment: New changeset 3a35638bce66 by Ned Deily in branch 'default': Issue #17636: Install new test directories. https://hg.python.org/cpython/rev/3a35638bce66 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 11:29:00 2014 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 13 Dec 2014 10:29:00 +0000 Subject: [issue23031] pdb crashes when jumping over "with" statement In-Reply-To: <1418313596.21.0.478510528753.issue23031@psf.upfronthosting.co.za> Message-ID: <1418466540.12.0.104035561304.issue23031@psf.upfronthosting.co.za> Xavier de Gaye added the comment: This has been fixed by issue 14612 for version 2.7.4. ---------- nosy: +xdegaye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 12:08:31 2014 From: report at bugs.python.org (Dan) Date: Sat, 13 Dec 2014 11:08:31 +0000 Subject: [issue23031] pdb crashes when jumping over "with" statement In-Reply-To: <1418313596.21.0.478510528753.issue23031@psf.upfronthosting.co.za> Message-ID: <1418468911.22.0.178228196201.issue23031@psf.upfronthosting.co.za> Changes by Dan : ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 12:24:50 2014 From: report at bugs.python.org (Constantin) Date: Sat, 13 Dec 2014 11:24:50 +0000 Subject: [issue23030] lru_cache manual get/put In-Reply-To: <1418306376.38.0.155577623227.issue23030@psf.upfronthosting.co.za> Message-ID: <1418469890.47.0.697918243731.issue23030@psf.upfronthosting.co.za> Constantin added the comment: It may be the case, that an lru_cache does not provide the best strategy for reliably caching many base cases in recursively written code. I suggest that someday we think about a different caching paradigm which fits this purpose and add it to functools e.g. as functools.recopt_cache. This cache would then implement the same interface as lru_cache and therefore all code currently using lru_cache could benefit from recopt_cache with just one line of code change. Furthermore, by designing this interface, it becomes more probable that user defined caching decorators are compatible. Please remember: My suggestion isn't just about lru_cache, but about an interface for caching decorators. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 12:34:33 2014 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 13 Dec 2014 11:34:33 +0000 Subject: [issue23048] abort when jumping out of a loop Message-ID: <1418470473.22.0.855190450782.issue23048@psf.upfronthosting.co.za> New submission from Xavier de Gaye: With the following jump.py script: def foo(): import pdb; pdb.set_trace() while 1: pass return # this is line 5 foo() The following debugging session aborts on Python 3.5.0a0 (default:334c01aa7f93, Dec 3 2014, 16:20:19): $ python jump.py > /tmp/test/jump.py(3)foo() -> while 1: (Pdb) next > /tmp/test/jump.py(4)foo() -> pass (Pdb) jump 5 python: Objects/frameobject.c:258: frame_setlineno: Assertion `blockstack_top == 0' failed. Aborted (core dumped) ---------- components: Interpreter Core messages: 232604 nosy: xdegaye priority: normal severity: normal status: open title: abort when jumping out of a loop type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 12:51:30 2014 From: report at bugs.python.org (Chaitanya agrawal) Date: Sat, 13 Dec 2014 11:51:30 +0000 Subject: [issue23047] typo in pyporting.rst In-Reply-To: <1418464877.74.0.653707717476.issue23047@psf.upfronthosting.co.za> Message-ID: <1418471490.92.0.922109335168.issue23047@psf.upfronthosting.co.za> Chaitanya agrawal added the comment: Typo corrected according to message232600. ---------- keywords: +patch nosy: +krypten Added file: http://bugs.python.org/file37438/issue23047.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 12:51:36 2014 From: report at bugs.python.org (Wojtek Ruszczewski) Date: Sat, 13 Dec 2014 11:51:36 +0000 Subject: [issue23040] Better documentation for the urlencode safe parameter In-Reply-To: <1418398499.72.0.468214874616.issue23040@psf.upfronthosting.co.za> Message-ID: <1418471496.21.0.0489814930539.issue23040@psf.upfronthosting.co.za> Wojtek Ruszczewski added the comment: Updated the patch, additionally changing "be" to "contain" in the first sentence. ---------- Added file: http://bugs.python.org/file37439/urlencode-safe-v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 14:05:03 2014 From: report at bugs.python.org (Skip Montanaro) Date: Sat, 13 Dec 2014 13:05:03 +0000 Subject: [issue23041] csv needs more quoting rules In-Reply-To: <1418402205.61.0.685044268577.issue23041@psf.upfronthosting.co.za> Message-ID: <1418475903.25.0.0628359304541.issue23041@psf.upfronthosting.co.za> Skip Montanaro added the comment: It doesn't look like a difficult change, but is it really needed? I guess my reaction is the same as Raymond's. Are there real-world uses where the current set of quoting styles isn't sufficient? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 14:48:37 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 13 Dec 2014 13:48:37 +0000 Subject: [issue23047] typo in pyporting.rst In-Reply-To: <1418464877.74.0.653707717476.issue23047@psf.upfronthosting.co.za> Message-ID: <20141213134832.18143.78957@psf.io> Roundup Robot added the comment: New changeset 914e9092984e by Berker Peksag in branch '3.4': Issue #23047: Fix typo in pyporting.rst. https://hg.python.org/cpython/rev/914e9092984e New changeset 81a56c9e1e1c by Berker Peksag in branch 'default': Issue #23047: Fix typo in pyporting.rst. https://hg.python.org/cpython/rev/81a56c9e1e1c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 14:50:53 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 13 Dec 2014 13:50:53 +0000 Subject: [issue23047] typo in pyporting.rst In-Reply-To: <1418464877.74.0.653707717476.issue23047@psf.upfronthosting.co.za> Message-ID: <20141213135052.50097.81389@psf.io> Roundup Robot added the comment: New changeset f1f404f5422a by Berker Peksag in branch '2.7': Issue #23047: Fix typo in pyporting.rst. https://hg.python.org/cpython/rev/f1f404f5422a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 14:52:28 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 13 Dec 2014 13:52:28 +0000 Subject: [issue23047] typo in pyporting.rst In-Reply-To: <1418464877.74.0.653707717476.issue23047@psf.upfronthosting.co.za> Message-ID: <1418478748.6.0.268484947859.issue23047@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report, Xavier and thanks for the patch, Chaitanya. ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 15:13:42 2014 From: report at bugs.python.org (Aaron Hill) Date: Sat, 13 Dec 2014 14:13:42 +0000 Subject: [issue23004] mock_open() should allow reading binary data In-Reply-To: <1417965857.24.0.521739131396.issue23004@psf.upfronthosting.co.za> Message-ID: <1418480022.53.0.0609431926307.issue23004@psf.upfronthosting.co.za> Aaron Hill added the comment: I've created a new patch, which addresses the problem. Your example now currently returns [b'foo\n', b'bar\n'] ---------- Added file: http://bugs.python.org/file37440/mock-open-allow-binary-data-updated.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 15:53:56 2014 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 13 Dec 2014 14:53:56 +0000 Subject: [issue19698] Implement _imp.exec_builtin and exec_dynamic In-Reply-To: <1385137675.64.0.235823443194.issue19698@psf.upfronthosting.co.za> Message-ID: <1418482436.59.0.117164487989.issue19698@psf.upfronthosting.co.za> Nick Coghlan added the comment: Yes, if we don't get to it beforehand. I'd still like to take the draft Create/Exec C level hook design I came up with and turn it into a PEP, but I don't know when I'll get time. Maybe I should just put that together as a (very) rough draft and lob it at import-sig? Then we'll have a concrete base for discussion at PyCon, and someone may be able to put together a draft implementation while you, me & Eric are all in the same place at the same time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 16:30:05 2014 From: report at bugs.python.org (Akira Li) Date: Sat, 13 Dec 2014 15:30:05 +0000 Subject: [issue23017] string.printable.isprintable() returns False In-Reply-To: <1418097121.16.0.891016494417.issue23017@psf.upfronthosting.co.za> Message-ID: <1418484605.96.0.78891909405.issue23017@psf.upfronthosting.co.za> Akira Li added the comment: C standard defines locale-specific *printing characters* that are [ -~] in "C" locale for implementations that use 7-bit US ASCII character set i.e., SP (space, 0x20) is a printing character in C (isprint() returns nonzero). There is isgraph() function that returns zero for the space but otherwise is equivalent to isprint(). POSIX definition is aligned with the ISO C standard. I don't know what RFC 5822 has to do with this issue but the rfc contradicts itself e.g., in one place it has: "printable US-ASCII characters except SP" that imlies that SP *is* printable but in other places it considers isprint==isgraph. The authors probably meant characters for which isgraph() is nonzero when they use "printable US-ASCII" (that is incorrect according to C standard). Tests from issue9770 show the relation between C character classes and string constants [1]: set(string.printable) == set(C['graph']) + set(C['space']) where C['space'] is '\t\n\v\f\r ' (the standard C whitespace). It is a documented behavior [2]: This is a combination of digits, ascii_letters, punctuation, and whitespace where *whitespace* is C['space']. In Python 2, *printable* is locale-dependent and it coincides with the corresponding Python 3 definition in "C" locale with ASCII charset. Unlike other string constants, *printable* differs from C['print'] on both Python 2 and 3 because it includes whitespace characters other than space. str.isprintable [3] obeys C['print'] (in ASCII range) and considers SP to be printable. --- It might be too late to change string.printable to correspond to C isprint() (for ASCII characters). I've uploaded a documentation patch that mentions that string.printable and str.isprintable differ. [1] http://bugs.python.org/review/9770/diff/12212/Lib/test/test_curses_ascii.py [2] https://hg.python.org/cpython/file/3.4/Doc/library/string.rst#l62 [3] https://docs.python.org/3.4/library/stdtypes.html#str.isprintable ---------- nosy: +akira Added file: http://bugs.python.org/file37441/docs-string.printable.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 18:42:58 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 13 Dec 2014 17:42:58 +0000 Subject: [issue23048] abort when jumping out of a loop In-Reply-To: <1418470473.22.0.855190450782.issue23048@psf.upfronthosting.co.za> Message-ID: <1418492578.0.0.0545374584001.issue23048@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Building on OS X 10.10 with the head of the code tree (as of today), I cannot reproduce this. Also the disassembly looks fine: $ python3.5 jump.py > /Users/raymond/tmp/jump.py(3)foo() -> while 1: (Pdb) next > /Users/raymond/tmp/jump.py(4)foo() -> pass (Pdb) jump 5 > /Users/raymond/tmp/jump.py(5)foo() -> return # this is line 5 (Pdb) list 1 def foo(): 2 import pdb; pdb.set_trace() 3 while 1: 4 pass 5 -> return # this is line 5 6 7 foo() 8 [EOF] (Pdb) !from dis import dis (Pdb) !dis(foo) 2 0 LOAD_CONST 1 (0) 3 LOAD_CONST 0 (None) 6 IMPORT_NAME 0 (pdb) 9 STORE_FAST 0 (pdb) 12 LOAD_FAST 0 (pdb) 15 LOAD_ATTR 1 (set_trace) 18 CALL_FUNCTION 0 (0 positional, 0 keyword pair) 21 POP_TOP 3 22 SETUP_LOOP 3 (to 28) 4 >> 25 JUMP_ABSOLUTE 25 5 >> 28 LOAD_CONST 0 (None) 31 RETURN_VALUE (Pdb) !import sys (Pdb) p sys.version_info sys.version_info(major=3, minor=5, micro=0, releaselevel='alpha', serial=0) ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 18:47:36 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 13 Dec 2014 17:47:36 +0000 Subject: [issue19527] Test failures with COUNT_ALLOCS In-Reply-To: <1383913813.74.0.198352256395.issue19527@psf.upfronthosting.co.za> Message-ID: <1418492856.85.0.214387389348.issue19527@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thenks Antoine for great idea proposed in comments on Rietveld. Following patch introduces strip_python_stdout() which strips COUNT_ALLOCS debug output from stdout (unfortunately this operation is not always unambiguous) and call it in assert_python_ok() and assert_python_failure(). This automatically fixes a large number of tests. Also fixed a number of other tests failing with COUNT_ALLOCS. Virtually all tests are now fixed except test_doctest and test_distutils. A large part of the patch will be applied only to 3.4 and 2.7. With resolved issue23034 the patch for 3.5 will be much simpler, strip_python_stdout() and @requires_clean_stdout will gone away. ---------- dependencies: +Dynamically control debugging output Added file: http://bugs.python.org/file37442/00141-fix-tests_with_COUNT_ALLOCS-v5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 18:54:41 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 13 Dec 2014 17:54:41 +0000 Subject: [issue22955] Pickling of methodcaller, attrgetter, and itemgetter In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za> Message-ID: <1418493281.54.0.605503027891.issue22955@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > functools.partial is a somewhat less than ideal comparison. The pure-Python version is not picklable, the Python and C versions return different things (the Python version is a function returning a function, the C version is a regular class and returns an instance). Looks as Python version of functools.partial() needs a fix. Reimplementations of the pure-Python itemgetter and attrgetter to automatically pickleable Python classes have a disadvantage. It makes the pickling incompatible between Python and C versions. This means that itemgetter pickled in CPython will be not unpickleable on Python implementation which don't use C accelerator and vice versa. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 18:58:13 2014 From: report at bugs.python.org (Zachary Ware) Date: Sat, 13 Dec 2014 17:58:13 +0000 Subject: [issue22955] Pickling of methodcaller, attrgetter, and itemgetter In-Reply-To: <1418493281.54.0.605503027891.issue22955@psf.upfronthosting.co.za> Message-ID: Zachary Ware added the comment: Serhiy Storchaka added the comment: > Reimplementations of the pure-Python itemgetter and attrgetter to > automatically pickleable Python classes have a disadvantage. It makes > the pickling incompatible between Python and C versions. This means > that itemgetter pickled in CPython will be not unpickleable on Python > implementation which don't use C accelerator and vice versa. That's a very good point that I hadn't thought about. Consider my patch withdrawn. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 20:14:52 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 13 Dec 2014 19:14:52 +0000 Subject: [issue9393] shelve.open/bsddb.hashopen exception with unicode paths In-Reply-To: <1280308243.23.0.510970772038.issue9393@psf.upfronthosting.co.za> Message-ID: <1418498092.99.0.36926901746.issue9393@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: test needed -> needs patch versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 20:46:27 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 13 Dec 2014 19:46:27 +0000 Subject: [issue22823] Use set literals instead of creating a set from a list In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za> Message-ID: <1418499987.68.0.181036319099.issue22823@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: benjamin.peterson -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 20:53:18 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 13 Dec 2014 19:53:18 +0000 Subject: [issue22823] Use set literals instead of creating a set from a list In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za> Message-ID: <20141213195316.50103.74625@psf.io> Roundup Robot added the comment: New changeset c3f960cff3e6 by Serhiy Storchaka in branch '3.4': Issue #22823: Use set literals in lib2to3. https://hg.python.org/cpython/rev/c3f960cff3e6 New changeset d3e43f7ecca8 by Serhiy Storchaka in branch 'default': Issue #22823: Use set literals in lib2to3. https://hg.python.org/cpython/rev/d3e43f7ecca8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 20:56:38 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 13 Dec 2014 19:56:38 +0000 Subject: [issue22823] Use set literals instead of creating a set from a list In-Reply-To: <1415502287.52.0.928876975666.issue22823@psf.upfronthosting.co.za> Message-ID: <1418500598.15.0.0848857168073.issue22823@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: That's all I think. Distutils is too conservative for such changes. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 21:50:53 2014 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 13 Dec 2014 20:50:53 +0000 Subject: [issue22875] asyncio: call_soon() documentation unclear on timing In-Reply-To: <1418453582.27.0.793612227254.issue22875@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Docfix LGTM. On Fri, Dec 12, 2014 at 10:53 PM, Martin Panter wrote: > > > Martin Panter added the comment: > > I have been bitten by this when attempting to implement my own event > loops. Parts of the ?asyncio? code itself expects that the callback is not > invoked directly after call_soon() returns. Here is a simple patch. > > ---------- > keywords: +patch > nosy: +vadmium > versions: +Python 3.4 > Added file: http://bugs.python.org/file37437/call_soon.patch > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 21:56:07 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 13 Dec 2014 20:56:07 +0000 Subject: [issue19949] Explicitly skip or mask skipped/disabled tests in test_xpickle In-Reply-To: <1386696725.08.0.917922388786.issue19949@psf.upfronthosting.co.za> Message-ID: <1418504167.61.0.494551574993.issue19949@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In updated patch the "xpickle" resource is tested before attempts to run Python executables. Also these checks are moved from decorator to the setUp() method. The result of have_python_version() now is memoized. Fixed running the test in unicode-disabled build. And added tests for installed Python 2.7. As far as older Python versions are rarely installed nowadays, this allows to check that the test is work at all (and that there is no significant regression against previous bugfix). ---------- Added file: http://bugs.python.org/file37443/test_xpickle_cleanup_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 22:08:22 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 13 Dec 2014 21:08:22 +0000 Subject: [issue23048] abort when jumping out of a loop In-Reply-To: <1418470473.22.0.855190450782.issue23048@psf.upfronthosting.co.za> Message-ID: <1418504902.37.0.594506891909.issue23048@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- assignee: -> benjamin.peterson nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 13 22:08:30 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 13 Dec 2014 21:08:30 +0000 Subject: [issue23048] abort when jumping out of a loop In-Reply-To: <1418470473.22.0.855190450782.issue23048@psf.upfronthosting.co.za> Message-ID: <20141213210827.80981.47893@psf.io> Roundup Robot added the comment: New changeset 09f938915c6f by Benjamin Peterson in branch '3.4': pop the loop block even for infinite while loops (closes #23048) https://hg.python.org/cpython/rev/09f938915c6f New changeset baa5258bef22 by Benjamin Peterson in branch '2.7': pop the loop block even for infinite while loops (closes #23048) https://hg.python.org/cpython/rev/baa5258bef22 New changeset ec96ffa6aa95 by Benjamin Peterson in branch 'default': merge 3.4 (#23048) https://hg.python.org/cpython/rev/ec96ffa6aa95 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 00:24:13 2014 From: report at bugs.python.org (Brett Cannon) Date: Sat, 13 Dec 2014 23:24:13 +0000 Subject: [issue19698] Implement _imp.exec_builtin and exec_dynamic In-Reply-To: <1385137675.64.0.235823443194.issue19698@psf.upfronthosting.co.za> Message-ID: <1418513053.21.0.0485101070942.issue19698@psf.upfronthosting.co.za> Brett Cannon added the comment: sgtm ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 00:50:42 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 13 Dec 2014 23:50:42 +0000 Subject: [issue21279] str.translate documentation incomplete In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za> Message-ID: <1418514642.36.0.479120687189.issue21279@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Many people may not know that IndexError and KeyError are subclasses of LookupError. I have not decided what to add yet, but I think we are close. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 00:52:46 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 13 Dec 2014 23:52:46 +0000 Subject: [issue23011] Duplicate Paragraph in documentation for json module In-Reply-To: <1418047735.37.0.83441849339.issue23011@psf.upfronthosting.co.za> Message-ID: <1418514766.09.0.0736364013325.issue23011@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Will reconsider if an actual duplication is presented. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 01:27:27 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 14 Dec 2014 00:27:27 +0000 Subject: [issue23049] Fix functools.reduce code equivalent. Message-ID: <1418516847.13.0.26860108886.issue23049@psf.upfronthosting.co.za> New submission from Terry J. Reedy: from functools import reduce def add(a,b): return a+b reduce(add, {}) >>> Traceback (most recent call last): File "C:\Programs\Python34\tem.py", line 3, in reduce(add, {}) TypeError: reduce() of empty sequence with no initial value However, the reduce-equivalent code in the doc sets a bad example and forgets to account for empty iterators. def reduce(function, iterable, initializer=None): it = iter(iterable) if initializer is None: value = next(it) else: ... So it lets the StopIteration escape (a bad practice that can silently break iterators). The code should be def reduce(function, iterable, initializer=None): it = iter(iterable) if initializer is None: try: value = next(it) except StopIteration: raise TypeError("reduce() of empty sequence with no initial value") from None else: ... (patch coming) ---------- assignee: docs at python components: Documentation, Interpreter Core messages: 232626 nosy: docs at python, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Fix functools.reduce code equivalent. type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 02:13:17 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 14 Dec 2014 01:13:17 +0000 Subject: [issue23030] lru_cache manual get/put In-Reply-To: <1418306376.38.0.155577623227.issue23030@psf.upfronthosting.co.za> Message-ID: <1418519597.4.0.760276678993.issue23030@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Sorry Constantin, I am rejecting this proposal or any variants of it. * As Nick pointed-out in the referenced thread, we provide two tools: a functools caching decorator that is tightly focused on the task of caching function calls and a collections OrderedDict that is a general purpose data store suitable for implementing custom LRU logic when needed. * As John pointed-out, this proposal isn't even fit for the original use case. Any speed benefits of a tail recursion optimization get immediately wiped out by overhead of a LRU cache decorator, and the clarity of the original code starts to get lost in the extra code to call cache_get() and cache_put() -- remember the decorator was designed to wrap around a function without having to change the logic inside it. Also, the optimization itself is fundamentally suspect because it changes the semantics of the language (thereby defeating all decorators that supply wrapper functions including memoization decorators, call loggers, precondition/postcondition checkers, subscription notifiers, type checkers, etc). * The essence of this proposal is at odds with what the functools caching decorator is all about -- providing a cache for function calls. The proposal bypasses the function call itself, making it more difficult to reason about what is in the cache (i.e. the result of previous function calls) and mucking up the cache hit/miss statistics which stop being meaningful. * The proposal also adds API complexity (making it less like a function decorator and more like an exposed data store such as an ordered dictionary). And, it creates a new control flow exception NotInCache. Collectively, these changes make the decorator slower, harder to maintain, harder to learn, harder to avoid reentrancy and locking problems, and harder to reason about but it doesn't provide much if any incremental benefit over using an OrderedDict directly. * To the extent there are valid niche use cases, we shouldn't try to cater to all of them. Good standard library API design stay focused on serving on the common case as well as possible and leaving the rest to OrderedDict or a third-party package (you're welcome to publish one to see if it actually serves a real need). * In designing the cache, I surveyed previously published memoization decorators and did not find the proposed feature. That means that it is false to state that every memoization decorator *must have* some functionality to insert or lookup entries while bypassing the function call that was intended to be cached. If it really was "must have" behavior, then it would have already been commonplace. IMO, cache_put() is bad design (would you want you database cache to return something that was never in the database or your disk cache to return values that had never been written to disk?) * Hopefully, this message explains my reasoning clearly, so you will understand why I'm closing this one. That said, judging by the insistent wording of your posts, I don't expect that you will be convinced. Your mental model of caching tools is very different from what the functools.lru_cache was intended to accomplish. To the extent that you don't really want a transparent function decorator and would prefer a full featured class (with methods for getting, setting, deleting, re-ordering, listing, monitoring, etc), I recommend that you write one and post it to the Python Package Index. The collections.OrderedDict() class should easily handle the LRU storage logic, so all you have to do is specify your API and decide which parts of the store you want to expose. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 03:09:19 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 14 Dec 2014 02:09:19 +0000 Subject: [issue23049] Fix functools.reduce code equivalent. In-Reply-To: <1418516847.13.0.26860108886.issue23049@psf.upfronthosting.co.za> Message-ID: <1418522959.74.0.0913003752691.issue23049@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 04:09:18 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 14 Dec 2014 03:09:18 +0000 Subject: [issue22735] Fix various crashes exposed through mro() customization In-Reply-To: <1414357581.7.0.216281535095.issue22735@psf.upfronthosting.co.za> Message-ID: <1418526558.19.0.137095233568.issue22735@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I will try to look eventually. ---------- assignee: -> benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 05:54:56 2014 From: report at bugs.python.org (Demian Brecht) Date: Sun, 14 Dec 2014 04:54:56 +0000 Subject: [issue23004] mock_open() should allow reading binary data In-Reply-To: <1417965857.24.0.521739131396.issue23004@psf.upfronthosting.co.za> Message-ID: <1418532896.07.0.251816679875.issue23004@psf.upfronthosting.co.za> Demian Brecht added the comment: Thanks for the update, but this doesn't quite work either as you're assuming utf-8 (which is what .encode() and .decode() default to). For example, when using latin-1: >>> m = mock_open(read_data= b'\xc6') >>> with patch('__main__.open', m, create=True) : ... with open('abc', 'rb') as f : ... print(f.read()) ... Traceback (most recent call last): [snip] UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc6 in position 0: unexpected end of data Additionally, a bytes object may simply be binary data that doesn't adhere to any specific encoding. My suggestion is to remove the use of format() altogether as it's really not doing anything complex and simply append either '\n' or b'\n' depending on the type of object passed in. That way, you can deal with the type of object passed in directly without coercion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 06:14:55 2014 From: report at bugs.python.org (Chaitanya agrawal) Date: Sun, 14 Dec 2014 05:14:55 +0000 Subject: [issue23041] csv needs more quoting rules In-Reply-To: <1418402205.61.0.685044268577.issue23041@psf.upfronthosting.co.za> Message-ID: <1418534095.29.0.239536607688.issue23041@psf.upfronthosting.co.za> Chaitanya agrawal added the comment: Used function PyUnicode_Check instead of PyString_Check ---------- keywords: +patch nosy: +krypten Added file: http://bugs.python.org/file37444/issue23041.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 06:45:01 2014 From: report at bugs.python.org (Chaitanya agrawal) Date: Sun, 14 Dec 2014 05:45:01 +0000 Subject: [issue23041] csv needs more quoting rules In-Reply-To: <1418402205.61.0.685044268577.issue23041@psf.upfronthosting.co.za> Message-ID: <1418535901.61.0.599946848322.issue23041@psf.upfronthosting.co.za> Changes by Chaitanya agrawal : Added file: http://bugs.python.org/file37445/issue23041_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 09:15:09 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 14 Dec 2014 08:15:09 +0000 Subject: [issue23016] uncaught exception in lib/warnings.py when executed with pythonw In-Reply-To: <1418088423.32.0.545997731561.issue23016@psf.upfronthosting.co.za> Message-ID: <1418544909.16.0.0189789033973.issue23016@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: > + # sys.stderr is None when ran with pythonw.exe - warnings get lost s/ran/run/ ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 09:58:06 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 14 Dec 2014 08:58:06 +0000 Subject: [issue23016] uncaught exception in lib/warnings.py when executed with pythonw In-Reply-To: <1418088423.32.0.545997731561.issue23016@psf.upfronthosting.co.za> Message-ID: <20141214085803.50113.56045@psf.io> Roundup Robot added the comment: New changeset 70b6fe58c425 by Serhiy Storchaka in branch '3.4': Fixed a typo in a comment (issue #23016). https://hg.python.org/cpython/rev/70b6fe58c425 New changeset da1ec8e0e068 by Serhiy Storchaka in branch 'default': Fixed a typo in a comment (issue #23016). https://hg.python.org/cpython/rev/da1ec8e0e068 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 09:58:48 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 14 Dec 2014 08:58:48 +0000 Subject: [issue23016] uncaught exception in lib/warnings.py when executed with pythonw In-Reply-To: <1418544909.16.0.0189789033973.issue23016@psf.upfronthosting.co.za> Message-ID: <2191573.abc2ZvtIQ7@raxxla> Serhiy Storchaka added the comment: Thanks Arfrever. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 10:15:46 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 14 Dec 2014 09:15:46 +0000 Subject: [issue23049] Fix functools.reduce code equivalent. In-Reply-To: <1418516847.13.0.26860108886.issue23049@psf.upfronthosting.co.za> Message-ID: <1418548546.54.0.38267938244.issue23049@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think it would be good to add Python implementation in functools.py and test they equivalence in tests. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 11:15:18 2014 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 14 Dec 2014 10:15:18 +0000 Subject: [issue23048] abort when jumping out of a loop In-Reply-To: <1418470473.22.0.855190450782.issue23048@psf.upfronthosting.co.za> Message-ID: <1418552118.52.0.285161879843.issue23048@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > Building on OS X 10.10 with the head of the code tree (as of today), I cannot reproduce this. Also the disassembly looks fine: I should have mentionned that I am running a debug build of python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 11:37:48 2014 From: report at bugs.python.org (Constantin) Date: Sun, 14 Dec 2014 10:37:48 +0000 Subject: [issue23030] lru_cache manual get/put In-Reply-To: <1418306376.38.0.155577623227.issue23030@psf.upfronthosting.co.za> Message-ID: <1418553468.82.0.0121171787594.issue23030@psf.upfronthosting.co.za> Constantin added the comment: I understand your decision. Even though it makes my life a little bit harder, it is definitely not the end of the world, the end of Python or even the end for my libtco project. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 14:45:04 2014 From: report at bugs.python.org (Aaron Hill) Date: Sun, 14 Dec 2014 13:45:04 +0000 Subject: [issue23004] mock_open() should allow reading binary data In-Reply-To: <1417965857.24.0.521739131396.issue23004@psf.upfronthosting.co.za> Message-ID: <1418564704.96.0.835617120282.issue23004@psf.upfronthosting.co.za> Aaron Hill added the comment: Thanks, I've fixed that. Not sure why I thought decoding and re-encoding would work with any binary data. I've also updated one of the tests to use non-utf8-decodeable binary data, to prevent a future regression. ---------- Added file: http://bugs.python.org/file37446/mock-open-allow-binary-without-coerce.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 15:34:51 2014 From: report at bugs.python.org (Tetsuya Morimoto) Date: Sun, 14 Dec 2014 14:34:51 +0000 Subject: [issue23050] Add Japanese legacy encodings Message-ID: <1418567689.35.0.572357268777.issue23050@psf.upfronthosting.co.za> New submission from Tetsuya Morimoto: This patch adds Japanese legacy encodings as below. https://bitbucket.org/t2y/cpython/branches/compare/japanese-legacy-encoding..default * eucjp_ms (euc-jp compatible with cp932) * iso2022_jp_ms (yet another iso-2022-jp compatible with cp932, similar to cp50220) * cp50220 (http://www.iana.org/assignments/charset-reg/CP50220) * cp50221 (a variant of cp50220) * cp50222 (a variant of cp50220) * cp51932 (http://www.iana.org/assignments/charset-reg/CP51932) Originally, these character encodings patch was created as result in IPA project in 2005, by Masayuki Moriyama. The result was contributed to several community: libiconv, glibc, perl, PHP, Ruby, PostgreSQL, MySQL, nkf. He had made a patch for Python 2.4.3 at that time, but somehow, no one worked to integrate. That's a crying shame. These character encodings are legacy, but are still used. Lots of end-user don't care the character encoding. Unfortunately, for historical reason, e-mails are encoded with these legacy encodings on Japanese Windows platform. Actually, my customer recently reported about Mojibake since its e-mail data would be encoded with cp50220 (iso-2022-jp-ms). References: * About IPA: http://www.ipa.go.jp/english/about/summary.html * Mojibake: http://en.wikipedia.org/wiki/Mojibake * Java encoding names: http://docs.oracle.com/javase/8/docs/technotes/guides/intl/encoding.doc.html References in Japanese: * Japanese Legacy Encoding Project: http://legacy-encoding.sourceforge.jp/wiki/ * Project details: http://www.ipa.go.jp/about/jigyoseika/05fy-pro/open/2005-1467d.pdf ---------- components: Library (Lib) files: add-japanese-legacy-encoding1.patch hgrepos: 285 keywords: patch messages: 232638 nosy: ishimoto, naoki, t2y priority: normal severity: normal status: open title: Add Japanese legacy encodings type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file37447/add-japanese-legacy-encoding1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 17:04:39 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 14 Dec 2014 16:04:39 +0000 Subject: [issue23050] Add Japanese legacy encodings In-Reply-To: <1418567689.35.0.572357268777.issue23050@psf.upfronthosting.co.za> Message-ID: <1418573079.05.0.448418438534.issue23050@psf.upfronthosting.co.za> R. David Murray added the comment: In emails these are labeled as, say, iso-2022-jp-ms? See also issue 8898 with regards to email encodings. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 17:28:43 2014 From: report at bugs.python.org (Tetsuya Morimoto) Date: Sun, 14 Dec 2014 16:28:43 +0000 Subject: [issue23050] Add Japanese legacy encodings In-Reply-To: <1418573079.05.0.448418438534.issue23050@psf.upfronthosting.co.za> Message-ID: Tetsuya Morimoto added the comment: On Mon, Dec 15, 2014 at 1:04 AM, R. David Murray wrote: > In emails these are labeled as, say, iso-2022-jp-ms? No. These are labeled just 'iso-2022-jp' and we (japanese) choose proper charset encoding to decode the encoded text. You can see several variants of iso-2022-jp. Yes, that's a very strange, but it's a historical reason. http://en.wikipedia.org/wiki/ISO/IEC_2022#ISO.2FIEC_2022_character_sets > See also issue 8898 with regards to email encodings. Therefore, this is different issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 17:49:30 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 14 Dec 2014 16:49:30 +0000 Subject: [issue22955] Pickling of methodcaller, attrgetter, and itemgetter In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za> Message-ID: <1418575770.13.0.526222191228.issue22955@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is revised Josh's patch. Added tests for consistency between both implementations, fixed inconsistencies and bugs. I still hesitate about pickling format of methodcaller. First, there is asymmetry between positional and keyword arguments. Second, for now methodcaller is not inheritable, but if it will be in future (as functools.partial is), it would be harder to extend pickling format to support instance attributes. ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file37448/pickle_getter_and_caller3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 17:55:24 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 14 Dec 2014 16:55:24 +0000 Subject: [issue23050] Add Japanese legacy encodings In-Reply-To: <1418567689.35.0.572357268777.issue23050@psf.upfronthosting.co.za> Message-ID: <1418576124.7.0.652033270892.issue23050@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +lemburg, loewis, serhiy.storchaka stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 19:24:06 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 14 Dec 2014 18:24:06 +0000 Subject: [issue23049] Fix functools.reduce code equivalent. In-Reply-To: <1418516847.13.0.26860108886.issue23049@psf.upfronthosting.co.za> Message-ID: <1418581446.49.0.648514240081.issue23049@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Background: the OP of #19202 proposed equivalent code for all the functool functions, including two versions for reduce. Georg combined the two versions into the one that Raymond pushed. Both agreed that reduce was the only function that really needed this. I called Georg's code 'excellent'. I have changed my mind slightly because people use such code equivalents not only for understanding but also as models for writing code, and because some people have had problems when by doing the same as this model, which ignores the empty iterable case. If you do not want to 'uglify' the doc code by making it exactly equivalent, how about qualifying the claim instead? Change 'equivalent' to 'equivalent for non-empty iterables'. ---------- keywords: +patch nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 23:47:29 2014 From: report at bugs.python.org (Alon Diamant) Date: Sun, 14 Dec 2014 22:47:29 +0000 Subject: [issue23051] multiprocessing.pool methods imap() and imap_unordered() cause deadlock Message-ID: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za> New submission from Alon Diamant: When imap() or imap_unordered() are called with the iterable parameter set as a generator function, and when that generator function raises an exception, then the _task_handler thread (running the method _handle_tasks) dies immediately, without causing the other threads to stop and without reporting the exception to the main thread (that one that called imap()). I saw this issue in Python 2.7.8, 2.7.9 and 3.4.2. Didn't check other versions, but I assume this is a bug in all Python versions since 2.6. I will be attaching examples that reproduce this issue, as well as patches for both Python 2.7 and Python 3.4. ---------- components: Library (Lib) messages: 232643 nosy: advance512 priority: normal severity: normal status: open title: multiprocessing.pool methods imap() and imap_unordered() cause deadlock type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 23:50:55 2014 From: report at bugs.python.org (Alon Diamant) Date: Sun, 14 Dec 2014 22:50:55 +0000 Subject: [issue23051] multiprocessing.pool methods imap() and imap_unordered() cause deadlock In-Reply-To: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za> Message-ID: <1418597455.48.0.65570313294.issue23051@psf.upfronthosting.co.za> Changes by Alon Diamant : Added file: http://bugs.python.org/file37449/Issue_23051_reproducer_v2_7.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 23:53:39 2014 From: report at bugs.python.org (Alon Diamant) Date: Sun, 14 Dec 2014 22:53:39 +0000 Subject: [issue23051] multiprocessing.pool methods imap() and imap_unordered() cause deadlock In-Reply-To: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za> Message-ID: <1418597619.01.0.231463444421.issue23051@psf.upfronthosting.co.za> Changes by Alon Diamant : ---------- keywords: +patch Added file: http://bugs.python.org/file37450/Issue_23051_fix_v2_7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 23:57:34 2014 From: report at bugs.python.org (Alon Diamant) Date: Sun, 14 Dec 2014 22:57:34 +0000 Subject: [issue23051] multiprocessing.pool methods imap() and imap_unordered() cause deadlock In-Reply-To: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za> Message-ID: <1418597854.92.0.200022426182.issue23051@psf.upfronthosting.co.za> Changes by Alon Diamant : Added file: http://bugs.python.org/file37451/Issue_23051_reproducer_v3_4.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 23:57:52 2014 From: report at bugs.python.org (Alon Diamant) Date: Sun, 14 Dec 2014 22:57:52 +0000 Subject: [issue23051] multiprocessing.pool methods imap() and imap_unordered() cause deadlock In-Reply-To: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za> Message-ID: <1418597872.49.0.435760988717.issue23051@psf.upfronthosting.co.za> Changes by Alon Diamant : Added file: http://bugs.python.org/file37452/Issue_23051_fix_v3_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 23:58:20 2014 From: report at bugs.python.org (Alon Diamant) Date: Sun, 14 Dec 2014 22:58:20 +0000 Subject: [issue23051] multiprocessing.pool methods imap() and imap_unordered() cause deadlock In-Reply-To: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za> Message-ID: <1418597900.07.0.130532053869.issue23051@psf.upfronthosting.co.za> Changes by Alon Diamant : Removed file: http://bugs.python.org/file37452/Issue_23051_fix_v3_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 14 23:58:55 2014 From: report at bugs.python.org (Alon Diamant) Date: Sun, 14 Dec 2014 22:58:55 +0000 Subject: [issue23051] multiprocessing.pool methods imap() and imap_unordered() cause deadlock In-Reply-To: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za> Message-ID: <1418597935.81.0.805124839385.issue23051@psf.upfronthosting.co.za> Changes by Alon Diamant : Added file: http://bugs.python.org/file37453/Issue_23051_fix_v3_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 00:03:12 2014 From: report at bugs.python.org (Alon Diamant) Date: Sun, 14 Dec 2014 23:03:12 +0000 Subject: [issue23051] multiprocessing.pool methods imap() and imap_unordered() cause deadlock In-Reply-To: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za> Message-ID: <1418598191.99.0.544871839796.issue23051@psf.upfronthosting.co.za> Alon Diamant added the comment: The patches I attached do 2 things: 1. A deadlock is prevented, wherein the main thread waits forever for the Pool thread/s to finish their execution, while they wait for instructions to terminate from the _task_handler thread which has died. Instead, the exception are caught and handled and termination of the pool execution is performed. 2. The exception that was raised is caught and passed to the main thread, and is re-thrown in the context of the main thread - hence the user catch it and handle it, or - at the very least - be aware of the issue. I tested the patch to the best of my abilities, and am almost certain nothing was changed performance wise nor anything broken. Further eyes would, of course, only help for confirming this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 02:04:58 2014 From: report at bugs.python.org (Demian Brecht) Date: Mon, 15 Dec 2014 01:04:58 +0000 Subject: [issue23004] mock_open() should allow reading binary data In-Reply-To: <1417965857.24.0.521739131396.issue23004@psf.upfronthosting.co.za> Message-ID: <1418605498.34.0.222661698672.issue23004@psf.upfronthosting.co.za> Demian Brecht added the comment: Thanks again for the update Aaron, I've left a couple small comments in Rietveld. Other than those, the patch looks good to me. Thanks for the contribution! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 03:26:35 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 15 Dec 2014 02:26:35 +0000 Subject: [issue23049] Fix functools.reduce code equivalent. In-Reply-To: <1418516847.13.0.26860108886.issue23049@psf.upfronthosting.co.za> Message-ID: <1418610395.24.0.967138011118.issue23049@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Elsewhere I have used "rough equivalent". FWIW, the initializer defaulting to "None" is also an approximation. It would be more technically correct to have "initializer = sentinel" where "sentinel = object()". But of course this too would obfuscate the documentation which mainly aimed to clarify two sticky points: 1) the order of arguments to the function call (accm, x) vs (x, accm) and 2) that if an initializer isn't specified, the first value from the iterable is used. These are the two issues that Guido found difficult to remember and caused reduce() to be banished from builtins. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 06:03:25 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 15 Dec 2014 05:03:25 +0000 Subject: [issue15506] configure should use PKG_PROG_PKG_CONFIG In-Reply-To: <1343670741.23.0.818269374942.issue15506@psf.upfronthosting.co.za> Message-ID: <20141215050256.80987.80007@psf.io> Roundup Robot added the comment: New changeset 54939f3c1e17 by Benjamin Peterson in branch '2.7': use autoconf macro to check for pkg-config (closes #15506) https://hg.python.org/cpython/rev/54939f3c1e17 New changeset 76df5870757a by Benjamin Peterson in branch '3.4': use autoconf macro to check for pkg-config (closes #15506) https://hg.python.org/cpython/rev/76df5870757a New changeset 5e473a7a01f3 by Benjamin Peterson in branch 'default': merge 3.4 (#15506) https://hg.python.org/cpython/rev/5e473a7a01f3 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 06:28:48 2014 From: report at bugs.python.org (Demian Brecht) Date: Mon, 15 Dec 2014 05:28:48 +0000 Subject: [issue14134] xmlrpc.client.ServerProxy needs timeout parameter In-Reply-To: <1330294741.21.0.00592117933576.issue14134@psf.upfronthosting.co.za> Message-ID: <1418621328.0.0.669831860115.issue14134@psf.upfronthosting.co.za> Demian Brecht added the comment: I'm a -1 to adding the timeout parameter to the ServerProxy implementation for pretty much the same reasons Jeff mentioned, but mainly because of the ambiguity that is introduced between the timeout and transport parameters (who should win in the case that they're both used?). I'm also a -1, although a little less strongly, on adding the timeout parameter to the transport layer. Instead, what I would /like/ to see is to have a connection_factory parameter added to Transport.__init__ that takes a host parameter (i.e. what's passed into HTTPConnection here: https://hg.python.org/cpython/file/e301ef500178/Lib/xmlrpc/client.py#l1231) which would default to a local function or lambda that does exactly what it's doing now. There are a few benefits to doing this: 1. Adding a timeout is just slightly less trivial than the current proposal 2. Encapsulation of the HTTPConnection object isn't broken 3. By exposing the ability to override the lower level HTTPConnection, connection_factory can result in a client that not only allows for setting changes such as timeouts, but can also result in any connection object that adheres to the expected HTTPConnection interface. For me, the 3rd point is the biggest selling feature. Not only can tweaks such as the timeout be made, but if other features are required such as customized logging, exponential back-off and such, they can easily be implemented in a child class of HTTPConnection. You could even write a (possibly) trivial adapter layer to interface with a 3rd party HTTP library if you so chose to. So, instantiating a ServerProxy object with an HTTPConnection with a custom timeout in its transport layer might look like this: def updated_timeout(host): return HTTPConnection(host, timeout=42) proxy = ServerProxy('http://example.com/gateway/', transport=Transport(connection_factory=updated_timeout)) While the use cases that you've used as examples can tend to happen, I firmly believe that those should be solved by enhanced documentation and not by implementation changes. ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 06:46:14 2014 From: report at bugs.python.org (binbjz) Date: Mon, 15 Dec 2014 05:46:14 +0000 Subject: [issue23052] python2.7.9 [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) Message-ID: <1418622374.17.0.593606620292.issue23052@psf.upfronthosting.co.za> New submission from binbjz: It will prompt ssl certificate_vefify_failed(_ssl.c:581) when I used pysphere with python 2.7.9 to connect server. But I switched python 2.7.8 it works well. 2014-12-15 13:22:53,187 [DEBUG] Can not connect to xxx.xxx.xxx.108: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) 2014-12-15 13:22:53,187 [DEBUG] Can not connect to 153.65.178.113: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) Process Process-2: Process Process-3: Traceback (most recent call last): Traceback (most recent call last): File "2.7.9/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap File "2.7.9/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap 2014-12-15 13:22:53,187 [DEBUG] Can not connect to xxx.xxx.xxx.109: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) Process Process-4: Traceback (most recent call last): File "2.7.9/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap 2014-12-15 13:22:53,188 [DEBUG] Can not connect to xxx.xxx.xxx.104: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) Process Process-6: Traceback (most recent call last): File "2.7.9/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap 2014-12-15 13:22:53,188 [DEBUG] Can not connect to 153.65.178.112: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) Process Process-1: Traceback (most recent call last): File "2.7.9/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap 2014-12-15 13:22:53,189 [DEBUG] Can not connect to xxx.xxx.xxx.105: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) Process Process-7: Traceback (most recent call last): File "2.7.9/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap 2014-12-15 13:22:53,190 [DEBUG] Can not connect to xxx.xxx.xxx.106: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) Process Process-8: Traceback (most recent call last): File "2.7.9/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap self.run() self.run() self.run() self.run() File "2.7.9/lib/python2.7/multiprocessing/process.py", line 114, in run File "2.7.9/lib/python2.7/multiprocessing/process.py", line 114, in run self.run() File "2.7.9/lib/python2.7/multiprocessing/process.py", line 114, in run File "2.7.9/lib/python2.7/multiprocessing/process.py", line 114, in run self._target(*self._args, **self._kwargs) self.run() File "2.7.9/lib/python2.7/multiprocessing/process.py", line 114, in run self._target(*self._args, **self._kwargs) File "EsxiControler.py", line 153, in get_all_inUse_vm_statusList File "2.7.9/lib/python2.7/multiprocessing/process.py", line 114, in run self._target(*self._args, **self._kwargs) File "EsxiControler.py", line 153, in get_all_inUse_vm_statusList self._target(*self._args, **self._kwargs) File "EsxiControler.py", line 153, in get_all_inUse_vm_statusList self._target(*self._args, **self._kwargs) self._target(*self._args, **self._kwargs) File "EsxiControler.py", line 153, in get_all_inUse_vm_statusList File "EsxiControler.py", line 153, in get_all_inUse_vm_statusList File "EsxiControler.py", line 153, in get_all_inUse_vm_statusList meth2='get_inUse_vmstatus', meth3='disconnect', initK='vm_name', initV='vm_status') File "EsxiControler.py", line 210, in get_output_formatter meth2='get_inUse_vmstatus', meth3='disconnect', initK='vm_name', initV='vm_status') meth2='get_inUse_vmstatus', meth3='disconnect', initK='vm_name', initV='vm_status') File "EsxiControler.py", line 210, in get_output_formatter vm_dict = mtd2() meth2='get_inUse_vmstatus', meth3='disconnect', initK='vm_name', initV='vm_status') File "EsxiControler.py", line 210, in get_output_formatter meth2='get_inUse_vmstatus', meth3='disconnect', initK='vm_name', initV='vm_status') File "/tmp/EsxiControler.py", line 69, in get_inUse_vmstatus File "EsxiControler.py", line 210, in get_output_formatter vm_dict = mtd2() File "EsxiControler.py", line 210, in get_output_formatter vm_dict = mtd2() File "/tmp/EsxiControler.py", line 69, in get_inUse_vmstatus vm_dict = mtd2() File "/tmp/EsxiControler.py", line 69, in get_inUse_vmstatus vm_dict = mtd2() File "/tmp/EsxiControler.py", line 69, in get_inUse_vmstatus File "/tmp/EsxiControler.py", line 69, in get_inUse_vmstatus meth2='get_inUse_vmstatus', meth3='disconnect', initK='vm_name', initV='vm_status') File "EsxiControler.py", line 210, in get_output_formatter vm_dict = mtd2() File "/tmp/EsxiControler.py", line 69, in get_inUse_vmstatus for vmPath in self.get_vmlist(): for vmPath in self.get_vmlist(): File "/tmp/EsxiControler.py", line 56, in get_vmlist File "/tmp/EsxiControler.py", line 56, in get_vmlist for vmPath in self.get_vmlist(): for vmPath in self.get_vmlist(): for vmPath in self.get_vmlist(): self.vmlist = self.server.get_registered_vms() self.vmlist = self.server.get_registered_vms() File "/tmp/EsxiControler.py", line 56, in get_vmlist File "/tmp/EsxiControler.py", line 56, in get_vmlist File "/tmp/EsxiControler.py", line 56, in get_vmlist File "2.7.9/lib/python2.7/site-packages/pysphere/vi_server.py", line 357, in get_registered_vms File "2.7.9/lib/python2.7/site-packages/pysphere/vi_server.py", line 357, in get_registered_vms self.vmlist = self.server.get_registered_vms() self.vmlist = self.server.get_registered_vms() self.vmlist = self.server.get_registered_vms() File "2.7.9/lib/python2.7/site-packages/pysphere/vi_server.py", line 357, in get_registered_vms File "2.7.9/lib/python2.7/site-packages/pysphere/vi_server.py", line 357, in get_registered_vms File "2.7.9/lib/python2.7/site-packages/pysphere/vi_server.py", line 357, in get_registered_vms for vmPath in self.get_vmlist(): File "/tmp/EsxiControler.py", line 56, in get_vmlist self.vmlist = self.server.get_registered_vms() File "2.7.9/lib/python2.7/site-packages/pysphere/vi_server.py", line 357, in get_registered_vms self.run() File "2.7.9/lib/python2.7/multiprocessing/process.py", line 114, in run self._target(*self._args, **self._kwargs) File "EsxiControler.py", line 153, in get_all_inUse_vm_statusList 2014-12-15 13:22:53,192 [DEBUG] Can not connect to xxx.xxx.xxx.83: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) meth2='get_inUse_vmstatus', meth3='disconnect', initK='vm_name', initV='vm_status') File "EsxiControler.py", line 210, in get_output_formatter vm_dict = mtd2() File "/tmp/EsxiControler.py", line 69, in get_inUse_vmstatus for vmPath in self.get_vmlist(): File "/tmp/EsxiControler.py", line 56, in get_vmlist self.vmlist = self.server.get_registered_vms() File "2.7.9/lib/python2.7/site-packages/pysphere/vi_server.py", line 357, in get_registered_vms Process Process-5: Traceback (most recent call last): File "2.7.9/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap 2014-12-15 13:22:53,192 [DEBUG] Can not connect to xxx.xxx.xxx.107: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) 2014-12-15 13:22:53,192 [DEBUG] Can not connect to xxx.xxx.xxx.101: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) self.run() File "2.7.9/lib/python2.7/multiprocessing/process.py", line 114, in run self._target(*self._args, **self._kwargs) File "EsxiControler.py", line 153, in get_all_inUse_vm_statusList meth2='get_inUse_vmstatus', meth3='disconnect', initK='vm_name', initV='vm_status') File "EsxiControler.py", line 210, in get_output_formatter vm_dict = mtd2() Process Process-10: File "/tmp/EsxiControler.py", line 69, in get_inUse_vmstatus Traceback (most recent call last): Process Process-9: Traceback (most recent call last): File "2.7.9/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap File "2.7.9/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap for vmPath in self.get_vmlist(): File "/tmp/EsxiControler.py", line 56, in get_vmlist self.vmlist = self.server.get_registered_vms() File "2.7.9/lib/python2.7/site-packages/pysphere/vi_server.py", line 357, in get_registered_vms self.run() File "2.7.9/lib/python2.7/multiprocessing/process.py", line 114, in run self._target(*self._args, **self._kwargs) self.run() File "EsxiControler.py", line 153, in get_all_inUse_vm_statusList File "2.7.9/lib/python2.7/multiprocessing/process.py", line 114, in run self._target(*self._args, **self._kwargs) File "EsxiControler.py", line 153, in get_all_inUse_vm_statusList meth2='get_inUse_vmstatus', meth3='disconnect', initK='vm_name', initV='vm_status') File "EsxiControler.py", line 210, in get_output_formatter vm_dict = mtd2() meth2='get_inUse_vmstatus', meth3='disconnect', initK='vm_name', initV='vm_status') File "/tmp/EsxiControler.py", line 69, in get_inUse_vmstatus File "EsxiControler.py", line 210, in get_output_formatter vm_dict = mtd2() File "/tmp/EsxiControler.py", line 69, in get_inUse_vmstatus for vmPath in self.get_vmlist(): File "/tmp/EsxiControler.py", line 56, in get_vmlist self.vmlist = self.server.get_registered_vms() File "2.7.9/lib/python2.7/site-packages/pysphere/vi_server.py", line 357, in get_registered_vms for vmPath in self.get_vmlist(): File "/tmp/EsxiControler.py", line 56, in get_vmlist self.vmlist = self.server.get_registered_vms() File "2.7.9/lib/python2.7/site-packages/pysphere/vi_server.py", line 357, in get_registered_vms 2014-12-15 13:22:53,193 [DEBUG] Can not connect to xxx.xxx.xxx.102: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) Process Process-11: Traceback (most recent call last): File "2.7.9/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap 2014-12-15 13:22:53,194 [DEBUG] Can not connect to xxx.xxx.xxx.103: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) self.run() File "2.7.9/lib/python2.7/multiprocessing/process.py", line 114, in run self._target(*self._args, **self._kwargs) File "EsxiControler.py", line 153, in get_all_inUse_vm_statusList meth2='get_inUse_vmstatus', meth3='disconnect', initK='vm_name', initV='vm_status') File "EsxiControler.py", line 210, in get_output_formatter vm_dict = mtd2() File "/tmp/EsxiControler.py", line 69, in get_inUse_vmstatus Process Process-12: Traceback (most recent call last): File "2.7.9/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap for vmPath in self.get_vmlist(): File "/tmp/EsxiControler.py", line 56, in get_vmlist self.vmlist = self.server.get_registered_vms() File "2.7.9/lib/python2.7/site-packages/pysphere/vi_server.py", line 357, in get_registered_vms self.run() File "2.7.9/lib/python2.7/multiprocessing/process.py", line 114, in run self._target(*self._args, **self._kwargs) File "EsxiControler.py", line 153, in get_all_inUse_vm_statusList meth2='get_inUse_vmstatus', meth3='disconnect', initK='vm_name', initV='vm_status') File "EsxiControler.py", line 210, in get_output_formatter vm_dict = mtd2() File "/tmp/EsxiControler.py", line 69, in get_inUse_vmstatus for vmPath in self.get_vmlist(): File "/tmp/EsxiControler.py", line 56, in get_vmlist self.vmlist = self.server.get_registered_vms() File "2.7.9/lib/python2.7/site-packages/pysphere/vi_server.py", line 357, in get_registered_vms FaultTypes.NOT_CONNECTED) FaultTypes.NOT_CONNECTED) VIException: [Not Connected]: Must call 'connect' before invoking this method VIException: [Not Connected]: Must call 'connect' before invoking this method FaultTypes.NOT_CONNECTED) VIException: [Not Connected]: Must call 'connect' before invoking this method FaultTypes.NOT_CONNECTED) VIException: [Not Connected]: Must call 'connect' before invoking this method FaultTypes.NOT_CONNECTED) VIException: [Not Connected]: Must call 'connect' before invoking this method FaultTypes.NOT_CONNECTED) VIException: [Not Connected]: Must call 'connect' before invoking this method FaultTypes.NOT_CONNECTED) VIException: [Not Connected]: Must call 'connect' before invoking this method FaultTypes.NOT_CONNECTED) VIException: [Not Connected]: Must call 'connect' before invoking this method FaultTypes.NOT_CONNECTED) VIException: [Not Connected]: Must call 'connect' before invoking this method FaultTypes.NOT_CONNECTED) FaultTypes.NOT_CONNECTED) VIException: [Not Connected]: Must call 'connect' before invoking this method VIException: [Not Connected]: Must call 'connect' before invoking this method FaultTypes.NOT_CONNECTED) VIException: [Not Connected]: Must call 'connect' before invoking this method ---------- components: Library (Lib) messages: 232649 nosy: binbjz priority: normal severity: normal status: open title: python2.7.9 [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 06:52:57 2014 From: report at bugs.python.org (Demian Brecht) Date: Mon, 15 Dec 2014 05:52:57 +0000 Subject: [issue22928] HTTP header injection in urrlib2/urllib/httplib/http.client In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za> Message-ID: <1418622777.85.0.306910181648.issue22928@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 07:46:04 2014 From: report at bugs.python.org (Alex Gaynor) Date: Mon, 15 Dec 2014 06:46:04 +0000 Subject: [issue23052] python2.7.9 [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) In-Reply-To: <1418622374.17.0.593606620292.issue23052@psf.upfronthosting.co.za> Message-ID: <1418625964.19.0.104914745101.issue23052@psf.upfronthosting.co.za> Alex Gaynor added the comment: Python 2.7.9 enabled certificate validation by default for HTTP connections, see PEP476. The server you're connecting to does not have a certificate that is trusted by your client. pysphere should configure SSL appropriately for this use case. ---------- nosy: +alex resolution: -> not a bug stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 08:03:00 2014 From: report at bugs.python.org (Andrej A Antonov) Date: Mon, 15 Dec 2014 07:03:00 +0000 Subject: [issue14134] xmlrpc.client.ServerProxy needs timeout parameter In-Reply-To: <1330294741.21.0.00592117933576.issue14134@psf.upfronthosting.co.za> Message-ID: <1418626980.19.0.151997866168.issue14134@psf.upfronthosting.co.za> Andrej A Antonov added the comment: @demian.brecht , your example code-fragment is too big. :-) too many lines -- just only for adding "timeout". it is uncomfortably. most people will not using that: most likely they just will forget about "timeout" (but in *MOST* situations not using "timeout" -- it is mistake). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 08:19:15 2014 From: report at bugs.python.org (binbjz) Date: Mon, 15 Dec 2014 07:19:15 +0000 Subject: [issue23052] python2.7.9 [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) In-Reply-To: <1418622374.17.0.593606620292.issue23052@psf.upfronthosting.co.za> Message-ID: <1418627955.22.0.241716223307.issue23052@psf.upfronthosting.co.za> binbjz added the comment: alex, thank you for quick reponse. I will check http://www.python.org/dev/peps/pep-0476/ ---------- resolution: not a bug -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 08:23:35 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 15 Dec 2014 07:23:35 +0000 Subject: [issue23052] python2.7.9 [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) In-Reply-To: <1418622374.17.0.593606620292.issue23052@psf.upfronthosting.co.za> Message-ID: <1418628215.14.0.473122273708.issue23052@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> not a bug status: open -> closed type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 09:16:35 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 15 Dec 2014 08:16:35 +0000 Subject: [issue23051] multiprocessing.pool methods imap() and imap_unordered() cause deadlock In-Reply-To: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za> Message-ID: <1418631395.76.0.93633645023.issue23051@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 09:20:39 2014 From: report at bugs.python.org (binbjz) Date: Mon, 15 Dec 2014 08:20:39 +0000 Subject: [issue23052] python2.7.9 [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) In-Reply-To: <1418622374.17.0.593606620292.issue23052@psf.upfronthosting.co.za> Message-ID: <1418631639.26.0.836220864539.issue23052@psf.upfronthosting.co.za> binbjz added the comment: I have added code to disable global verification on phsphere. It works well. thanks. ---------- resolution: not a bug -> type: behavior -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 11:08:41 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Mon, 15 Dec 2014 10:08:41 +0000 Subject: [issue22706] Idle extension configuration and key bindings In-Reply-To: <1414023453.7.0.681663520586.issue22706@psf.upfronthosting.co.za> Message-ID: <1418638121.42.0.202858339735.issue22706@psf.upfronthosting.co.za> Saimadhav Heblikar added the comment: Need some clarification on this issue. I tried changing the cfgBindings for FormatParagraph. It creates a new key-set and writes the changes to user config-keys.cfg in ~/.idlerc(the keybindings). Any changes made to FormatParagraph in extension dialog(the [X]) are written to the user config-extensions.cfg file in ~/.idlerc. Have I understood the issue correctly in saying that the desired outcome is both [X] and [X_cfgBindings] write to config-extensions.cfg in ~/.idlerc? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 12:02:53 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 15 Dec 2014 11:02:53 +0000 Subject: [issue23015] Improve test_uuid In-Reply-To: <1418070790.02.0.347463680837.issue23015@psf.upfronthosting.co.za> Message-ID: <20141215110227.18151.91673@psf.io> Roundup Robot added the comment: New changeset f972583c7c4f by Serhiy Storchaka in branch '2.7': Issue #23015: Improved testing of the uuid module. https://hg.python.org/cpython/rev/f972583c7c4f New changeset 3551dc8af54e by Serhiy Storchaka in branch '3.4': Issue #23015: Improved testing of the uuid module. https://hg.python.org/cpython/rev/3551dc8af54e New changeset fd1d994afe52 by Serhiy Storchaka in branch 'default': Issue #23015: Improved testing of the uuid module. https://hg.python.org/cpython/rev/fd1d994afe52 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 13:09:36 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 15 Dec 2014 12:09:36 +0000 Subject: [issue22777] Test pickling with all protocols In-Reply-To: <1414793093.86.0.888366361477.issue22777@psf.upfronthosting.co.za> Message-ID: <20141215120921.28198.17300@psf.io> Roundup Robot added the comment: New changeset 9927781e457f by Serhiy Storchaka in branch '2.7': Issue #22777: Test pickling with all protocols. https://hg.python.org/cpython/rev/9927781e457f New changeset 04c9fffde184 by Serhiy Storchaka in branch '3.4': Issue #22777: Test pickling with all protocols. https://hg.python.org/cpython/rev/04c9fffde184 New changeset 77fc30182dc2 by Serhiy Storchaka in branch 'default': Issue #22777: Test pickling with all protocols. https://hg.python.org/cpython/rev/77fc30182dc2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 13:13:18 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 15 Dec 2014 12:13:18 +0000 Subject: [issue23015] Improve test_uuid In-Reply-To: <1418070790.02.0.347463680837.issue23015@psf.upfronthosting.co.za> Message-ID: <1418645598.38.0.76783766117.issue23015@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 13:13:49 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 15 Dec 2014 12:13:49 +0000 Subject: [issue22777] Test pickling with all protocols In-Reply-To: <1414793093.86.0.888366361477.issue22777@psf.upfronthosting.co.za> Message-ID: <1418645629.98.0.618897303883.issue22777@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 13:19:02 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 15 Dec 2014 12:19:02 +0000 Subject: [issue22818] Deprecate splitting on possible zero-width re patterns In-Reply-To: <1415444480.37.0.198748558658.issue22818@psf.upfronthosting.co.za> Message-ID: <1418645941.99.0.753904412019.issue22818@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I there are no objections I'm going to commit the patch soon. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 13:20:05 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 15 Dec 2014 12:20:05 +0000 Subject: [issue22826] Support context management protocol in bkfile In-Reply-To: <1415549255.85.0.105011780634.issue22826@psf.upfronthosting.co.za> Message-ID: <1418646005.17.0.0807049099484.issue22826@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +needs review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 13:34:53 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 15 Dec 2014 12:34:53 +0000 Subject: [issue19858] Make pickletools.optimize aware of the MEMOIZE opcode. In-Reply-To: <1385946014.54.0.601831543599.issue19858@psf.upfronthosting.co.za> Message-ID: <1418646893.37.0.925988691058.issue19858@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- keywords: +needs review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 13:35:17 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 15 Dec 2014 12:35:17 +0000 Subject: [issue18473] some objects pickled by Python 3.x are not unpicklable in Python 2.x because of incorrect REVERSE_IMPORT_MAPPING In-Reply-To: <1373973767.04.0.0542870445433.issue18473@psf.upfronthosting.co.za> Message-ID: <1418646917.32.0.420876069887.issue18473@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- keywords: +needs review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 13:35:56 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 15 Dec 2014 12:35:56 +0000 Subject: [issue22783] Pickle: use NEWOBJ instead of NEWOBJ_EX if possible In-Reply-To: <1414942122.91.0.879577274082.issue22783@psf.upfronthosting.co.za> Message-ID: <1418646956.0.0.688573768248.issue22783@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- keywords: +needs review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 13:45:39 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 15 Dec 2014 12:45:39 +0000 Subject: [issue15513] Correct __sizeof__ support for pickle In-Reply-To: <1343723739.69.0.648602242607.issue15513@psf.upfronthosting.co.za> Message-ID: <1418647539.9.0.337109897464.issue15513@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- keywords: +needs review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 14:38:48 2014 From: report at bugs.python.org (John Posner) Date: Mon, 15 Dec 2014 13:38:48 +0000 Subject: [issue21279] str.translate documentation incomplete In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za> Message-ID: <1418650728.14.0.202359912501.issue21279@psf.upfronthosting.co.za> John Posner added the comment: Kindly ignore message #2 on the Rietveld page (sorry for the channel noise). Here's my suggested revision: Return a copy of the string *str* in which each character has been mapped through the given translation *table*. The table must be a subscriptable object, for instance a list or dictionary; when subscripted (indexed) by a Unicode ordinal (an integer in range(1048576)), the table object can: * return a Unicode ordinal or a string, to map the character to one or more other characters. * return None, to delete the character from the return string. * raise a LookupError (possibly an instance of subclass IndexError or KeyError), to map the character to itself. ---------- nosy: +jjposner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 15:10:37 2014 From: report at bugs.python.org (jan matejek) Date: Mon, 15 Dec 2014 14:10:37 +0000 Subject: [issue23053] test_urllib2_localnet fails without ssl Message-ID: <1418652637.29.0.740829735045.issue23053@psf.upfronthosting.co.za> New submission from jan matejek: The pep 476 commit to Python 2.7 [1] adds unconditional "import ssl" to test_urllib2_localnet.py. This causes the test to fail with an ImportError if ssl module is not built. Note that like 5 lines later, ssl is imported conditionally, and all the relevant tests are configured to skip if ssl is not present. So to fix this, all that is needed is to remove the "import ssl" line. Attached patch does just that. [1] https://hg.python.org/cpython/rev/fb83916c3ea1 ---------- components: Tests files: python-2.7-urllib2-localnet-ssl.patch keywords: patch messages: 232663 nosy: matejcik priority: normal severity: normal status: open title: test_urllib2_localnet fails without ssl type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file37454/python-2.7-urllib2-localnet-ssl.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 15:49:03 2014 From: report at bugs.python.org (Joe Cabrera) Date: Mon, 15 Dec 2014 14:49:03 +0000 Subject: [issue23054] ConnectionError: ('Connection aborted.', BadStatusLine(""''''")) Message-ID: <1418654943.54.0.176050651858.issue23054@psf.upfronthosting.co.za> New submission from Joe Cabrera: ConnectionError: ('Connection aborted.', BadStatusLine(""''''")) This error can also occur on Linux and Windows, a more descriptive error messages would be useful for people trying to debug their code. ---------- assignee: docs at python components: Documentation messages: 232664 nosy: docs at python, joecabrera priority: normal severity: normal status: open title: ConnectionError: ('Connection aborted.', BadStatusLine(""''''")) type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 16:05:32 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 15 Dec 2014 15:05:32 +0000 Subject: [issue23053] test_urllib2_localnet fails without ssl In-Reply-To: <1418652637.29.0.740829735045.issue23053@psf.upfronthosting.co.za> Message-ID: <20141215150519.18157.4221@psf.io> Roundup Robot added the comment: New changeset ebe8917189a3 by Benjamin Peterson in branch '2.7': remove extra ssl imports (closes #23053) https://hg.python.org/cpython/rev/ebe8917189a3 New changeset 1da9e9eaeae8 by Benjamin Peterson in branch '3.4': remove extra ssl imports (closes #23053) https://hg.python.org/cpython/rev/1da9e9eaeae8 New changeset 8214675f6385 by Benjamin Peterson in branch 'default': merge 3.4 (#23053) https://hg.python.org/cpython/rev/8214675f6385 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 16:06:05 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 15 Dec 2014 15:06:05 +0000 Subject: [issue23054] ConnectionError: ('Connection aborted.', BadStatusLine(""''''")) In-Reply-To: <1418654943.54.0.176050651858.issue23054@psf.upfronthosting.co.za> Message-ID: <1418655965.73.0.689384380154.issue23054@psf.upfronthosting.co.za> R. David Murray added the comment: I think you made a mistake in your copy and paste or retyping of that line, since it is not valid python syntax. What is not explicit about it? It is telling you there was a bad status line, and what the bad status line contents was. (Used to be you couldn't tell, when the badness of the status line was that it was empty, that that was what the error message was saying, but I'm pretty sure we fixed that so that it shows an empty status line as an empty string in the message). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 16:08:53 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 15 Dec 2014 15:08:53 +0000 Subject: [issue23054] ConnectionError: ('Connection aborted.', BadStatusLine(""''''")) In-Reply-To: <1418654943.54.0.176050651858.issue23054@psf.upfronthosting.co.za> Message-ID: <1418656133.98.0.948710268009.issue23054@psf.upfronthosting.co.za> R. David Murray added the comment: Perhaps part of your problem is that you are not getting the string representation of the error message. Is that because of your code, or is this representation something the stdlib is generating? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 17:45:57 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 15 Dec 2014 16:45:57 +0000 Subject: [issue23050] Add Japanese legacy encodings In-Reply-To: <1418567689.35.0.572357268777.issue23050@psf.upfronthosting.co.za> Message-ID: <1418661957.65.0.00216039629905.issue23050@psf.upfronthosting.co.za> STINNER Victor added the comment: > These character encodings are legacy, but are still used. Do you have an idea of how many users still have documents stored or exchanged using these encodings? The patch is not trivial, the legacy japanese codecs are complex and so error prone :-/ For previous requests to add new codecs, we closed issues as wontfix and we suggested to share the codecs at the Python Cheeseshop (PyPI). Here it's more complex because C code is modified to implement the new encodings. $ diffstat issue23050_13417.diff Doc/library/codecs.rst | 16 Lib/encodings/aliases.py | 26 Lib/test/test_codecencodings_iso2022.py | 59 + Lib/test/test_codecs.py | 2 Lib/test/test_multibytecodec.py | 6 Lib/test/test_xml_etree.py | 4 Modules/cjkcodecs/_codecs_iso2022.c | 718 ++++++++++++++++++----- Modules/cjkcodecs/_codecs_jp.c | 305 +++++++++ Modules/cjkcodecs/mappings_jp.h | 950 ++++++++++++++++++++++--------- Modules/cjkcodecs/multibytecodec.h | 11 Python/importlib.h | 860 ++++++++++++++-------------- b/Lib/encodings/cp50220.py | 39 + b/Lib/encodings/cp50221.py | 39 + b/Lib/encodings/cp50222.py | 39 + b/Lib/encodings/cp51932.py | 39 + b/Lib/encodings/eucjp_ms.py | 39 + b/Lib/encodings/iso2022_jp_ms.py | 39 + b/Lib/test/cjkencodings/cp50220-utf8.txt | 30 b/Lib/test/cjkencodings/cp50220.txt | 30 b/Modules/cjkcodecs/mappings_cp50220_k.h | 31 + 20 files changed, 2452 insertions(+), 830 deletions(-) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 17:52:12 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 15 Dec 2014 16:52:12 +0000 Subject: [issue22875] asyncio: call_soon() documentation unclear on timing In-Reply-To: <1415995304.37.0.00737491261157.issue22875@psf.upfronthosting.co.za> Message-ID: <1418662332.64.0.48787501686.issue22875@psf.upfronthosting.co.za> STINNER Victor added the comment: Thanks Martin for your change, I commited it. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 17:52:44 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 15 Dec 2014 16:52:44 +0000 Subject: [issue22875] asyncio: call_soon() documentation unclear on timing In-Reply-To: <1415995304.37.0.00737491261157.issue22875@psf.upfronthosting.co.za> Message-ID: <1418662364.62.0.0164366660847.issue22875@psf.upfronthosting.co.za> STINNER Victor added the comment: Oops, I forgot to mention the issue number in my commit. changeset: 93893:a59fed8c710b branch: 3.4 parent: 93891:1da9e9eaeae8 user: Victor Stinner date: Mon Dec 15 17:50:55 2014 +0100 files: Doc/library/asyncio-eventloop.rst description: asyncio doc: call_soon() does not call immediatly the callback. Patch written by Martin Panter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 17:55:23 2014 From: report at bugs.python.org (Demian Brecht) Date: Mon, 15 Dec 2014 16:55:23 +0000 Subject: [issue14134] xmlrpc.client.ServerProxy needs timeout parameter In-Reply-To: <1330294741.21.0.00592117933576.issue14134@psf.upfronthosting.co.za> Message-ID: <1418662523.24.0.235600638158.issue14134@psf.upfronthosting.co.za> Demian Brecht added the comment: + loewis as he's listed as the xmlrpc expert If you're worried about the number of lines, turn the function into a lambda: proxy = ServerProxy('http://example.com/gateway/', transport=Transport( connection_factory=lambda h: HTTPConnection(h, timeout=42))) I think that the problem with the way that you're looking at the problem:'just only for adding "timeout"', when what you're fundamentally after is to modify the attribute of an object two levels removed by composition. I /do/ agree that this is slightly more complex than simply setting a timeout parameter, but I also think that it's actually quite a bit more flexible and practically useful. Borrowing from PEP20: "There should be one-- and preferably only one --obvious way to do it.". Having a timeout at the top level ServerProxy object introduces ambiguity and therefore doesn't conform. Should the connection_factory concept be used, having a timeout parameter at the Transport level also introduces ambiguity. Setting the timeout through a custom HTTPConnection instantiated through connection_factory is an obvious way to do it (especially if documented) and is marginally more code. If you /only/ care about the timeout and really don't want to be bothered with the connection_factory, you can always set the global socket timeout for the given request with: socket.setdefaulttimeout([timeout]) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 17:56:13 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 15 Dec 2014 16:56:13 +0000 Subject: [issue22875] asyncio: call_soon() documentation unclear on timing In-Reply-To: <1415995304.37.0.00737491261157.issue22875@psf.upfronthosting.co.za> Message-ID: <1418662573.28.0.0419936790192.issue22875@psf.upfronthosting.co.za> STINNER Victor added the comment: FYI I added a new test to the aiotest project (test suite for asyncio), for this issue: https://bitbucket.org/haypo/aiotest/commits/17dd11fc2f4bafad623f940b1a33a3b8b0d39ccd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 18:18:35 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Dec 2014 17:18:35 +0000 Subject: [issue23055] PyUnicode_FromFormatV crasher Message-ID: <1418663915.64.0.885404540917.issue23055@psf.upfronthosting.co.za> New submission from Guido van Rossum: Fix as reported by Guido Vranken on security at python.org, with minimal test by me. Needs: - review - port to 3.2--3.5 Questions: - Does my test case cover all changed code? ---------- assignee: gvanrossum files: vranken.diff keywords: needs review, patch messages: 232673 nosy: gvanrossum priority: normal severity: normal status: open title: PyUnicode_FromFormatV crasher type: crash versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37455/vranken.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 18:21:59 2014 From: report at bugs.python.org (Tetsuya Morimoto) Date: Mon, 15 Dec 2014 17:21:59 +0000 Subject: [issue23050] Add Japanese legacy encodings In-Reply-To: <1418661957.65.0.00216039629905.issue23050@psf.upfronthosting.co.za> Message-ID: Tetsuya Morimoto added the comment: >> These character encodings are legacy, but are still used. > > Do you have an idea of how many users still have documents stored or exchanged using these encodings? Hmm, I guess iso-2022-jp codec is still default charset of MUA (Mail User Agent) on Japanese Windows platform. But I'm not sure how many so I'll investigate, wait a few days. > The patch is not trivial, the legacy japanese codecs are complex and so error prone :-/ Ya, this patch has some refactoring. However, existing tests have passed and adding encoding codecs wouldn't affect other codecs basically. Why do you think it's "error plone"? > For previous requests to add new codecs, we closed issues as wontfix and we suggested to share the codecs at the Python Cheeseshop (PyPI). Here it's more complex because C code is modified to implement the new encodings. Could you show me previous requests? I can understand C code modifying is higher cost to review. However, we have codec tests and it wouldn't affect other codecs, I think. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 20:27:54 2014 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 15 Dec 2014 19:27:54 +0000 Subject: [issue23056] tarfile raises an exception when reading an empty tar in streaming mode Message-ID: <1418671674.41.0.864207249713.issue23056@psf.upfronthosting.co.za> New submission from Gregory P. Smith: $ cat >test.py < info = f.next() File "/usr/lib/python2.7/tarfile.py", line 2319, in next self.fileobj.seek(self.offset) File "/usr/lib/python2.7/tarfile.py", line 555, in seek raise StreamError("seeking backwards is not allowed") tarfile.StreamError: seeking backwards is not allowed $ python3.4 test.py test.tar Traceback (most recent call last): File "test.py", line 6, in info = f.next() File "/usr/lib/python3.4/tarfile.py", line 2244, in next self.fileobj.seek(self.offset) File "/usr/lib/python3.4/tarfile.py", line 518, in seek raise StreamError("seeking backwards is not allowed") tarfile.StreamError: seeking backwards is not allowed I have reconfirmed that the above still happens using a top of tree 2.7.9+ build. ---------- components: Library (Lib) messages: 232675 nosy: gregory.p.smith priority: normal severity: normal stage: needs patch status: open title: tarfile raises an exception when reading an empty tar in streaming mode type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 20:40:10 2014 From: report at bugs.python.org (Samwyse) Date: Mon, 15 Dec 2014 19:40:10 +0000 Subject: [issue23041] csv needs more quoting rules In-Reply-To: <1418402205.61.0.685044268577.issue23041@psf.upfronthosting.co.za> Message-ID: <1418672410.26.0.213816640681.issue23041@psf.upfronthosting.co.za> Samwyse added the comment: Yes, it's based on a real-world need. I work for a Fortune 500 company and we have an internal tool that exports CSV files using what I've described as the QUOTE_NOTNULL rules. I need to create similar files for re-importation. Right now, I have to post-process the output of my Python program to get it right. I added in the QUOTE_STRINGS rule for completeness. I think these two new rules would be useful for anyone wanting to create sparse CSV files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 20:52:44 2014 From: report at bugs.python.org (Skip Montanaro) Date: Mon, 15 Dec 2014 19:52:44 +0000 Subject: [issue23041] csv needs more quoting rules In-Reply-To: <1418402205.61.0.685044268577.issue23041@psf.upfronthosting.co.za> Message-ID: <1418673164.16.0.485101059504.issue23041@psf.upfronthosting.co.za> Skip Montanaro added the comment: If I understand correctly, your software needs to distinguish between # wrote ["foo", "", 42, None] with quote_all in effect "foo","","42","" and # wrote ["foo", None, 42, ""] with quote_nonnull in effect "foo",,"42","" so you in effect want to transmit some type information through a CSV file? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 21:10:56 2014 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 15 Dec 2014 20:10:56 +0000 Subject: [issue23057] asyncio loop on Windows should stop on keyboard interrupt Message-ID: <1418674256.87.0.827009141117.issue23057@psf.upfronthosting.co.za> New submission from Andrew Svetlov: See http://stackoverflow.com/questions/27480967/why-does-the-asyncios-event-loop-suppress-the-keyboardinterrupt-on-windows for details ---------- components: asyncio messages: 232678 nosy: asvetlov, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio loop on Windows should stop on keyboard interrupt type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 22:02:07 2014 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=) Date: Mon, 15 Dec 2014 21:02:07 +0000 Subject: [issue23058] argparse silently ignores arguments Message-ID: <1418677327.73.0.355612765077.issue23058@psf.upfronthosting.co.za> New submission from R?mi Rampin: This works correctly on Python 3.4. On Python 2.7, argparse seems to completely and silently ignore arguments in some conditions, for instance this setup will cause --verbose to be ignored on the main parser: options = argparse.ArgumentParser(add_help=False) options.add_argument('-v', '--verbose', action='store_true') parser = argparse.ArgumentParser(parents=[options]) subparsers = parser.add_subparsers() parser_cmd = subparsers.add_parser('cmd', parents=[options]) Full runnable example here: http://paste.pound-python.org/show/XfVVhdJHSPISXLP1lASd/ Might or might not be related to #9351, workarounds welcome. ---------- components: Library (Lib) messages: 232679 nosy: remram priority: normal severity: normal status: open title: argparse silently ignores arguments type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 22:02:49 2014 From: report at bugs.python.org (Samwyse) Date: Mon, 15 Dec 2014 21:02:49 +0000 Subject: [issue23059] sort misc help topics in cmd Message-ID: <1418677369.11.0.558268336279.issue23059@psf.upfronthosting.co.za> New submission from Samwyse: I've discovered that do_help method of cmd.Cmd prints the documented and undocumented commands in sorted order, but does not sort the miscellaneous topics. This would be an easy fix, just change "self.print_topics(self.misc_header, help.keys(),15,80)" to use "sorted(help.keys())". ---------- components: Library (Lib) messages: 232680 nosy: samwyse priority: normal severity: normal status: open title: sort misc help topics in cmd versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 22:17:02 2014 From: report at bugs.python.org (Samwyse) Date: Mon, 15 Dec 2014 21:17:02 +0000 Subject: [issue23041] csv needs more quoting rules In-Reply-To: <1418402205.61.0.685044268577.issue23041@psf.upfronthosting.co.za> Message-ID: <1418678222.1.0.127488086661.issue23041@psf.upfronthosting.co.za> Samwyse added the comment: Skip, I don't have any visibility into how the Java program I'm feeding data into works, I'm just trying to replicate the csv files that it exports as accurately as possible. It has several other quirks, but I can replicate all of them using Dialects; this is the only "feature" I can't. The files I'm looking at have quoted strings and numbers, but there aren't any quoted empty strings. I'm using a DictWriter to create similar csv files, where missing keys are treated as values of None, so I'd like those printed without quotes. If we also want to print empty strings without quotes, that wouldn't impact me at all. Besides my selfish needs, this could be useful to anyone wanting to reduce the save of csv files that have lots of empty fields, but wants to quote all non-empty values. This may be an empty set, I don't know. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 22:20:51 2014 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=) Date: Mon, 15 Dec 2014 21:20:51 +0000 Subject: [issue23058] argparse silently ignores arguments In-Reply-To: <1418677327.73.0.355612765077.issue23058@psf.upfronthosting.co.za> Message-ID: <1418678451.09.0.872398455962.issue23058@psf.upfronthosting.co.za> R?mi Rampin added the comment: Interestingly, this worked before my upgrade 2.7.8 -> 2.7.9. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 22:35:20 2014 From: report at bugs.python.org (Berker Peksag) Date: Mon, 15 Dec 2014 21:35:20 +0000 Subject: [issue22826] Support context management protocol in bkfile In-Reply-To: <1415549255.85.0.105011780634.issue22826@psf.upfronthosting.co.za> Message-ID: <1418679320.19.0.947774024876.issue22826@psf.upfronthosting.co.za> Berker Peksag added the comment: The second patch raises "RuntimeError: maximum recursion depth exceeded" if the target file is exist. File "/home/berker/projects/cpython/default/Tools/freeze/bkfile.py", line 18, in close f.close() RuntimeError: maximum recursion depth exceeded ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 22:35:36 2014 From: report at bugs.python.org (STINNER Victor) Date: Mon, 15 Dec 2014 21:35:36 +0000 Subject: [issue23050] Add Japanese legacy encodings In-Reply-To: Message-ID: STINNER Victor added the comment: I refactored some parts of CJK codecs for performances, after the PEP 393 was implemented. A blocker point was that these codecs have very few tests. Not for valid data but for invalid data. It may be a little bit better. I tried to write a test for each path in if/else, to test all cases, in the codecs that I modified. By error prone, it mean that it's easy to introduce a bug or a regressio, since the code is complex and almost nobody maintains it. I'm not stongly opposed to any change. I'm just trying to understand the context. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 22:48:29 2014 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Mon, 15 Dec 2014 21:48:29 +0000 Subject: [issue23050] Add Japanese legacy encodings In-Reply-To: <1418567689.35.0.572357268777.issue23050@psf.upfronthosting.co.za> Message-ID: <1418680109.23.0.696958135422.issue23050@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Another traditional issue with Japanese codecs is that people have different opinions on what the encoding should do. It may be that when we release the codec, somebody comes up and says that the codec is incorrect, and it should do something different for some code points, citing some other applications which he considers right. In particular for the Microsoft ones, people may claim that some version of Windows did things differently. Now, for this set, the ones that got registered with IANA sound ok (in the sense that it is our bug if they fail to conform to the IANA spec, and IANA's fault if they fail to do what users expect). For the other ones, I wonder whether there is some official source that can be consulted for correctness. On a different note: why do you claim that the code is written by Perky? (it's not you, is it?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 23:06:54 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 15 Dec 2014 22:06:54 +0000 Subject: [issue22783] Pickle: use NEWOBJ instead of NEWOBJ_EX if possible In-Reply-To: <1414942122.91.0.879577274082.issue22783@psf.upfronthosting.co.za> Message-ID: <1418681214.3.0.899689672391.issue22783@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Some examples (with issue19858 for protocol 4 optimization). Unpatched: >>> len(pickle.dumps([P(12, 34) for i in range(1000)], 3)) 17258 >>> len(pickletools.optimize(pickle.dumps([P(12, 34) for i in range(1000)], 3))) 8018 >>> len(pickle.dumps([P(i, -i) for i in range(1000)], 3)) 20999 >>> len(pickletools.optimize(pickle.dumps([P(i, -i) for i in range(1000)], 3))) 11759 >>> len(pickle.dumps([P(12, 34) for i in range(1000)], 4)) 12031 >>> len(pickletools.optimize(pickle.dumps([P(12, 34) for i in range(1000)], 4))) 9028 >>> len(pickle.dumps([P(i, -i) for i in range(1000)], 4)) 15772 >>> len(pickletools.optimize(pickle.dumps([P(i, -i) for i in range(1000)], 4))) 12769 Patched: >>> len(pickle.dumps([P(12, 34) for i in range(1000)], 4)) 10031 >>> len(pickletools.optimize(pickle.dumps([P(12, 34) for i in range(1000)], 4))) 8028 >>> len(pickle.dumps([P(i, -i) for i in range(1000)], 4)) 13772 >>> len(pickletools.optimize(pickle.dumps([P(i, -i) for i in range(1000)], 4))) 11769 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 23:19:52 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 15 Dec 2014 22:19:52 +0000 Subject: [issue22826] Support context management protocol in bkfile In-Reply-To: <1415549255.85.0.105011780634.issue22826@psf.upfronthosting.co.za> Message-ID: <1418681992.39.0.714381431254.issue22826@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Good catch Berker. Updated patch fixes recursion issue. ---------- Added file: http://bugs.python.org/file37456/bkfile3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 15 23:47:51 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 15 Dec 2014 22:47:51 +0000 Subject: [issue21740] doctest doesn't allow duck-typing callables In-Reply-To: <1402606753.04.0.326464066676.issue21740@psf.upfronthosting.co.za> Message-ID: <20141215224748.50119.45998@psf.io> Roundup Robot added the comment: New changeset 12ef799a9a51 by Zachary Ware in branch 'default': Issue #21740: Fix module name in NEWS entry. https://hg.python.org/cpython/rev/12ef799a9a51 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 00:38:37 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 15 Dec 2014 23:38:37 +0000 Subject: [issue23055] PyUnicode_FromFormatV crasher In-Reply-To: <1418663915.64.0.885404540917.issue23055@psf.upfronthosting.co.za> Message-ID: <1418686717.56.0.403405831895.issue23055@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I have added a couple of comments. Here is a patch which fixes found bugs. 3.4+ is not affected by this bug. 3.2 looks same as 2.7 and is affected, 3.3 uses different code but at first glance looks affected too. Is it worth to fix this bug in 3.2 and 3.3? ---------- components: +Interpreter Core nosy: +georg.brandl, haypo, serhiy.storchaka stage: -> patch review versions: -Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37457/issue23055-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 00:46:59 2014 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 15 Dec 2014 23:46:59 +0000 Subject: [issue23055] PyUnicode_FromFormatV crasher In-Reply-To: <1418663915.64.0.885404540917.issue23055@psf.upfronthosting.co.za> Message-ID: <1418687219.66.0.596400201366.issue23055@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thank you for digging into this! I'd say go ahead and update 3.2 and 3.3 too -- these are in security-fix-only mode meaning that we only fix security issues and don't do actual releases. But we still do security bugfixes: for 3.2 until February 2016 (PEP 392), for 3.3 until September 2017 (PEP 398). I don't think that this warrants changing the 2.7 bugfix release schedule. ---------- versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 01:25:11 2014 From: report at bugs.python.org (Guido Vranken) Date: Tue, 16 Dec 2014 00:25:11 +0000 Subject: [issue23055] PyUnicode_FromFormatV crasher In-Reply-To: <1418663915.64.0.885404540917.issue23055@psf.upfronthosting.co.za> Message-ID: <1418689511.63.0.442689994987.issue23055@psf.upfronthosting.co.za> Guido Vranken added the comment: Serhiy Storchaka: good call on changing my 'n += (width + precision) < 20 ? 20 : (width + precision);' into 'if (width < precision) width = precision;', I didn't realize that sprintf's space requirement entails using the largest of the two instead of adding the two together. I noticed the apparently pointless width calculation in 'step 1' but decided not to touch it -- good that it's removed now though. I will start doing more debugging based on this new patch now to ensure that the bug is gone now. On a more design-related note, for the sake of readability and stability, I'd personally opt for implementing toned-down custom sprintf-like function that does exactly what it needs to do and nothing more, since a function like this one requires perfect alignment with the underlying sprintf() in terms of functionality, at the possible expense of stability and integrity issues like we see here. For instance, width and precision are currently overflowable, resulting in either a minus sign appearing in the resulant format string given to sprintf() (width and precision are signed integers), or completely overflowing it (ie. (uint64_t)18446744073709551617 == 1 ). Considering the latter example, how do we know sprintf uses the same logic? Guido ---------- nosy: +Guido _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 01:39:58 2014 From: report at bugs.python.org (Guido Vranken) Date: Tue, 16 Dec 2014 00:39:58 +0000 Subject: [issue23055] PyUnicode_FromFormatV crasher In-Reply-To: <1418663915.64.0.885404540917.issue23055@psf.upfronthosting.co.za> Message-ID: <1418690398.53.0.216616576171.issue23055@psf.upfronthosting.co.za> Guido Vranken added the comment: I'd also like to add that, although I agree with Guido van Rossum that the likelihood of even triggering this bug in a general programming context is low, there are two buffer overflows at play here (one stack-based and one heap-based), and given an adversary's control over the format and vargs parameters, I'd there is a reasonable likelihood of exploiting it to execute arbitrary code, since the one controlling the parameters has some control as to which bytes end up where outside buffer boundaries. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 02:06:12 2014 From: report at bugs.python.org (Aaron Hill) Date: Tue, 16 Dec 2014 01:06:12 +0000 Subject: [issue23004] mock_open() should allow reading binary data In-Reply-To: <1417965857.24.0.521739131396.issue23004@psf.upfronthosting.co.za> Message-ID: <1418691972.72.0.0965038091826.issue23004@psf.upfronthosting.co.za> Aaron Hill added the comment: I've fixed the issues you pointed out. Is there a better way than uploading a new patch file to make changes? ---------- Added file: http://bugs.python.org/file37458/mock-open-allow-binary-without-coerce-fixup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 02:09:09 2014 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 16 Dec 2014 01:09:09 +0000 Subject: [issue23055] PyUnicode_FromFormatV crasher In-Reply-To: <1418663915.64.0.885404540917.issue23055@psf.upfronthosting.co.za> Message-ID: <1418692148.99.0.110209252903.issue23055@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'd be much worried about attack scenarios if this function was part of the standard library. But it's not -- the stdlib's % operator uses completely different code. The most common use case is probably to generate error messages from extension modules -- and there the format is almost always a literal in the C code. (An adversary who can load a C extension doesn't need this exploit.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 02:12:42 2014 From: report at bugs.python.org (Martin Panter) Date: Tue, 16 Dec 2014 01:12:42 +0000 Subject: [issue21279] str.translate documentation incomplete In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za> Message-ID: <1418692362.04.0.56521597689.issue21279@psf.upfronthosting.co.za> Martin Panter added the comment: I?m largely happy with any of these revisions. If I end up doing another patch I would omit the *str* (it is a class name, not a parameter). Also I would omit the range(2^20) claim. Unless people think it is important; why is it different to sys.maxunicode + 1 = 0x110000? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 02:43:51 2014 From: report at bugs.python.org (Martin Panter) Date: Tue, 16 Dec 2014 01:43:51 +0000 Subject: [issue22928] HTTP header injection in urrlib2/urllib/httplib/http.client In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za> Message-ID: <1418694231.6.0.430158011863.issue22928@psf.upfronthosting.co.za> Martin Panter added the comment: There could be potential for breaking compatibility if people are intentionally sending values with folded lines (obsoleted by the new HTTP RFC). Perhaps the same error should be raised for values that cannot be encoded in Latin-1? Also, maybe most control characters should trigger an error, not just CR and LF. Apart from line folding, the HTTP RFC only allows visible ASCII characters, spaces and tabs, and obsolete non-ASCII chars >= 0x80. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 03:29:55 2014 From: report at bugs.python.org (Steve Dower) Date: Tue, 16 Dec 2014 02:29:55 +0000 Subject: [issue23060] Assert fails in multiprocessing.heap.Arena.__setstate__ on Windows Message-ID: <1418696995.02.0.22756137648.issue23060@psf.upfronthosting.co.za> New submission from Steve Dower: Currently, the implementation of __setstate__ at Lib/multiprocessing/heap.py:54 looks like this: def __setstate__(self, state): self.size, self.name = self._state = state self.buffer = mmap.mmap(-1, self.size, tagname=self.name) assert _winapi.GetLastError() == _winapi.ERROR_ALREADY_EXISTS This assertion can fail when the assignment to buffer triggers memory [re]allocation, which could clear the last error result. So far, this fails reliably on debug builds using VS 2015 (which causes some tests to timeout when all of the child processes fail to start), but could also fail in threaded code at any time. I don't know why release builds or builds with VS 2010 did not trigger this, but I would speculate that either VS 2015 is using a different API to allocate memory or Windows 8.1 has changed the behaviour of an API. Whether a function resets the last error code is deliberately unspecified (http://msdn.microsoft.com/en-us/library/windows/desktop/ms679360(v=vs.85).aspx - "some functions set the last-error code to 0 on success and others do not"). In my opinion, the assertion should just be removed. A hack that appears to work currently is to add "self.buffer = None" before the existing assignment (to pre-expand self.__dict__ and avoid the allocation). If the assertion is important, someone may want to add a parameter to mmap() to require that the memory-mapped file already exists and throws otherwise, but I am not volunteering to do this. ---------- components: Windows messages: 232697 nosy: jnoller, sbt, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Assert fails in multiprocessing.heap.Arena.__setstate__ on Windows versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 03:30:51 2014 From: report at bugs.python.org (Steve Dower) Date: Tue, 16 Dec 2014 02:30:51 +0000 Subject: [issue23060] Assert fails in multiprocessing.heap.Arena.__setstate__ on Windows In-Reply-To: <1418696995.02.0.22756137648.issue23060@psf.upfronthosting.co.za> Message-ID: <1418697051.07.0.619237050989.issue23060@psf.upfronthosting.co.za> Steve Dower added the comment: A buildbot failure due to this can be seen here: http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x/builds/183/steps/test/logs/stdio ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 03:36:52 2014 From: report at bugs.python.org (Samwyse) Date: Tue, 16 Dec 2014 02:36:52 +0000 Subject: [issue23059] cmd module should sort misc help topics In-Reply-To: <1418677369.11.0.558268336279.issue23059@psf.upfronthosting.co.za> Message-ID: <1418697412.88.0.0639681951273.issue23059@psf.upfronthosting.co.za> Changes by Samwyse : ---------- title: sort misc help topics in cmd -> cmd module should sort misc help topics _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 03:47:44 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 16 Dec 2014 02:47:44 +0000 Subject: [issue23014] Don't have importlib.abc.Loader.create_module() be optional In-Reply-To: <1418055538.78.0.471721917483.issue23014@psf.upfronthosting.co.za> Message-ID: <1418698064.71.0.572778536037.issue23014@psf.upfronthosting.co.za> Eric Snow added the comment: Thanks for bringing this up, Brett. The goal and approach seem good to me. Did you bring this up during the PEP 451 discussions? If so, sorry I missed it. You've made a good point. And hopefully this will encourage people to subclass Loader more. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 03:47:53 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 16 Dec 2014 02:47:53 +0000 Subject: [issue23014] Don't have importlib.abc.Loader.create_module() be optional In-Reply-To: <1418055538.78.0.471721917483.issue23014@psf.upfronthosting.co.za> Message-ID: <1418698073.98.0.617399444983.issue23014@psf.upfronthosting.co.za> Eric Snow added the comment: At some point should we make create_module (and exec_module) always required? In other words, when should would drop the legacy loader support? I expect the answer is Python 4. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 03:49:31 2014 From: report at bugs.python.org (Eric Snow) Date: Tue, 16 Dec 2014 02:49:31 +0000 Subject: [issue19698] Implement _imp.exec_builtin and exec_dynamic In-Reply-To: <1385137675.64.0.235823443194.issue19698@psf.upfronthosting.co.za> Message-ID: <1418698171.52.0.842081861917.issue19698@psf.upfronthosting.co.za> Eric Snow added the comment: Same here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 03:49:37 2014 From: report at bugs.python.org (Tetsuya Morimoto) Date: Tue, 16 Dec 2014 02:49:37 +0000 Subject: [issue23050] Add Japanese legacy encodings In-Reply-To: Message-ID: Tetsuya Morimoto added the comment: > By error prone, it mean that it's easy to introduce a bug or a regression, > since the code is complex and almost nobody maintains it. Indeed. Actually, I encountered some faults when I migrated original patch. The character encoding is a kind of specialty area. This patch is written by Masayuki Moriyama, who is an expert of character encoding and he have been contributed to various communities for a long time. Also, he helps me to migrate original patch(for Python 2.4.3) to Python 3.5. You can see commit log he fixed some bugs. https://bitbucket.org/t2y/cpython/commits/all > I'm not stongly opposed to any change. I'm just trying to understand the > context. Thanks. I'll help it by explaining the context. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 03:50:14 2014 From: report at bugs.python.org (Ben Finney) Date: Tue, 16 Dec 2014 02:50:14 +0000 Subject: [issue21720] "TypeError: Item in ``from list'' not a string" message In-Reply-To: <1402493325.12.0.160112781213.issue21720@psf.upfronthosting.co.za> Message-ID: <1418698214.39.0.0220155741104.issue21720@psf.upfronthosting.co.za> Ben Finney added the comment: Is there room for a better resolution: fix the API so that Unicode objects are accepted in the ?fromlist? items? ---------- nosy: +bignose _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 03:50:26 2014 From: report at bugs.python.org (Ben Finney) Date: Tue, 16 Dec 2014 02:50:26 +0000 Subject: [issue21720] "TypeError: Item in ``from list'' not a string" message In-Reply-To: <1402493325.12.0.160112781213.issue21720@psf.upfronthosting.co.za> Message-ID: <1418698226.8.0.273335842278.issue21720@psf.upfronthosting.co.za> Changes by Ben Finney : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 04:10:32 2014 From: report at bugs.python.org (Demian Brecht) Date: Tue, 16 Dec 2014 03:10:32 +0000 Subject: [issue23004] mock_open() should allow reading binary data In-Reply-To: <1417965857.24.0.521739131396.issue23004@psf.upfronthosting.co.za> Message-ID: <1418699432.61.0.0271675055437.issue23004@psf.upfronthosting.co.za> Demian Brecht added the comment: Thanks for the updated patch, looks good to me. If you haven't already read it, the patch workflow is here: https://docs.python.org/devguide/patch.html and is the only workflow currently available. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 04:26:34 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 16 Dec 2014 03:26:34 +0000 Subject: [issue23004] mock_open() should allow reading binary data In-Reply-To: <1417965857.24.0.521739131396.issue23004@psf.upfronthosting.co.za> Message-ID: <1418700394.92.0.417886601643.issue23004@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 05:11:35 2014 From: report at bugs.python.org (Andrej A Antonov) Date: Tue, 16 Dec 2014 04:11:35 +0000 Subject: [issue14134] xmlrpc.client.ServerProxy needs timeout parameter In-Reply-To: <1330294741.21.0.00592117933576.issue14134@psf.upfronthosting.co.za> Message-ID: <1418703095.36.0.336946885097.issue14134@psf.upfronthosting.co.za> Andrej A Antonov added the comment: @demian.brecht , socket.setdefaulttimeout([timeout]) -- it is bad practice, because setting this global varible we may spoil other cases. example "TCP keepalive" [ s.setsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE, true) ] and global variables is bad practice for other things. and again -- compare what shorter (and what more clear): proxy = ServerProxy('http://example.com/gateway/', transport=Transport( connection_factory=lambda h: HTTPConnection(h, timeout=42))) or proxy = ServerProxy('http://example.com/gateway/', timeout=42) > There should be one-- and preferably only one --obvious way to do it.". Having a timeout at the top level ServerProxy object introduces ambiguity and therefore doesn't conform if you NOT point timeout in "RPC-client" -- you program will freeze or will maked resource leak (with small probability). "RPC-client" and "timeout" -- these two concepts are inseparable! you are allowed *NOT_using* "timeout" in "RPC-client" -- *ONLY* in *localhost* operations! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 05:18:37 2014 From: report at bugs.python.org (Steve Dower) Date: Tue, 16 Dec 2014 04:18:37 +0000 Subject: [issue22733] MSVC ffi_prep_args doesn't handle 64-bit arguments properly In-Reply-To: <1414355754.77.0.458541552576.issue22733@psf.upfronthosting.co.za> Message-ID: <1418703517.39.0.165083373797.issue22733@psf.upfronthosting.co.za> Steve Dower added the comment: This patch also resolves this test issue: [ 68/390/2] test_ttk_textonly test test_ttk_textonly crashed -- Traceback (most recent call last): File "D:\...\lib\test\regrtest.py", line 1280, in runtest_inner test_runner() File "D:\...\lib\test\test_ttk_textonly.py", line 14, in test_main *runtktests.get_tests(gui=False, packages=['test_ttk'])) File "D:\...\lib\tkinter\test\runtktests.py", line 65, in get_tests for module in get_tests_modules(gui=gui, packages=packages): File "D:\...\lib\tkinter\test\runtktests.py", line 50, in get_tests_modules "tkinter.test") File "D:\...\lib\importlib\__init__.py", line 109, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "", line 2208, in _gcd_import File "", line 2191, in _find_and_load File "", line 2180, in _find_and_load_unlocked File "", line 1149, in _load_unlocked File "", line 1420, in exec_module File "", line 321, in _call_with_frames_removed File "D:\...\lib\tkinter\test\test_ttk\test_extensions.py", line 8, in requires('gui') File "D:\...\lib\test\support\__init__.py", line 492, in requires if resource == 'gui' and not _is_gui_available(): File "D:\...\lib\test\support\__init__.py", line 436, in _is_gui_available raise ctypes.WinError() OSError: [WinError 0] The operation completed successfully. I'm not entirely sure when/if I should just commit the fix without any reviews, but this issue needs to be fixed, so eventually I'll probably just do it :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 05:18:44 2014 From: report at bugs.python.org (Tetsuya Morimoto) Date: Tue, 16 Dec 2014 04:18:44 +0000 Subject: [issue23050] Add Japanese legacy encodings In-Reply-To: <1418680109.23.0.696958135422.issue23050@psf.upfronthosting.co.za> Message-ID: Tetsuya Morimoto added the comment: > Another traditional issue with Japanese codecs is that people have different opinions on what the encoding should do. It may be that when we release the codec, somebody comes up and says that the codec is incorrect, and it should do something different for some code points, citing some other applications which he considers right. In particular for the Microsoft ones, people may claim that some version of Windows did things differently. In regard to e-mail encoding, Japanese should use utf-8, then it resolves most problems. However, for historical reason or compatibility reason, it's different even today. I don't think these legacy codecs are needed for individual application, but we sometimes encounter an encoding issue when an application collaborates to external system like e-mail. > Now, for this set, the ones that got registered with IANA sound ok (in the sense that it is our bug if they fail to conform to the IANA spec, and IANA's fault if they fail to do what users expect). For the other ones, I wonder whether there is some official source that can be consulted for correctness. Exactly. Now, I'm finding euc-jp-ms and iso-2022-jp-ms spec in English. Of course, there's a voluntary document in Japanese as follows. http://www.wdic.org/w/WDIC/eucJP-ms http://www.wdic.org/w/WDIC/ISO-2022-JP-MS I may agree with dropping character encoding which is difficult to find official source. > On a different note: why do you claim that the code is written by Perky? (it's not you, is it?) Right! Because the credit belongs to him. I'm an assistant. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 05:24:24 2014 From: report at bugs.python.org (Ian Lee) Date: Tue, 16 Dec 2014 04:24:24 +0000 Subject: [issue23061] Update pep8 to specify explicitly 'module level' imports at top of file Message-ID: <1418703864.09.0.281927050653.issue23061@psf.upfronthosting.co.za> New submission from Ian Lee: Minor update pep8 to specify explicitly that "Imports at top of file" refers specifically to module level imports, per input from Nick Coghlan @ https://github.com/jcrocholl/pep8/pull/304#issuecomment-66939162 ---------- assignee: docs at python components: Documentation files: pep-0008.patch keywords: patch messages: 232708 nosy: IanLee1521, docs at python, ncoghlan priority: normal severity: normal status: open title: Update pep8 to specify explicitly 'module level' imports at top of file type: enhancement Added file: http://bugs.python.org/file37459/pep-0008.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 05:50:36 2014 From: report at bugs.python.org (Andrej A Antonov) Date: Tue, 16 Dec 2014 04:50:36 +0000 Subject: [issue14134] xmlrpc.client.ServerProxy needs timeout parameter In-Reply-To: <1330294741.21.0.00592117933576.issue14134@psf.upfronthosting.co.za> Message-ID: <1418705436.62.0.444529135846.issue14134@psf.upfronthosting.co.za> Andrej A Antonov added the comment: ok, let's go to other side of this problem: question: why default transport (xmlrpc.client.Transport()) is not setting value of timeout?`` answer: because *unknown* which value need to using by default. in various cases programmer need various timeout. default value of timeout for default transport -- what may be this number? may be value "300" for timeout of default transport (xmlrpc.client.Transport()) may be normal in *most_cases*. but this will brake legacy soft that using socket.setdefaulttimeout(...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 05:52:01 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 16 Dec 2014 04:52:01 +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: <20141216045158.18135.70574@psf.io> Roundup Robot added the comment: New changeset f70c16189876 by Steve Dower in branch 'default': #22980 Adds platform and version tags to .pyd files https://hg.python.org/cpython/rev/f70c16189876 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 05:54:50 2014 From: report at bugs.python.org (Steve Dower) Date: Tue, 16 Dec 2014 04:54:50 +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: <1418705690.43.0.683002430368.issue22980@psf.upfronthosting.co.za> Steve Dower added the comment: Nobody seemed too bothered by it, so I committed a slightly simpler change that only includes the most specific tag (that is, ".cp35-win32.pyd" or ".pyd"). We can always add another tag easily enough if it seems useful, or roll this change back if it was a mistake. Now, let's stop talking about Windows and get back to the original discussion :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 06:12:16 2014 From: report at bugs.python.org (Martin Panter) Date: Tue, 16 Dec 2014 05:12:16 +0000 Subject: [issue23062] test_argparse --version test cases Message-ID: <1418706736.64.0.85644160224.issue23062@psf.upfronthosting.co.za> New submission from Martin Panter: In Lib/test/test_argparse.py: class TestHelpVersionOptional(HelpTestCase): """Test that the --version argument can be suppressed help messages""" Assuming that the docstring means something like ?. . . can be suppressed _in_ help messages?, the test is wrong, because the --version option is present in the expected output. Maybe it is missing a help=SUPPRESS option? Otherwise it seems this test class would be largely redundant with TestHelpVersionAction. It also looks like the ?version? attribute of the test classes is not used. ---------- components: Tests messages: 232712 nosy: vadmium priority: normal severity: normal status: open title: test_argparse --version test cases versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 06:22:08 2014 From: report at bugs.python.org (Zachary Ware) Date: Tue, 16 Dec 2014 05:22:08 +0000 Subject: [issue22733] MSVC ffi_prep_args doesn't handle 64-bit arguments properly In-Reply-To: <1414355754.77.0.458541552576.issue22733@psf.upfronthosting.co.za> Message-ID: <1418707328.0.0.945600016565.issue22733@psf.upfronthosting.co.za> Zachary Ware added the comment: I don't know near enough to comment on this one. If you feel confident in it, I'd say go ahead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 07:17:28 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 16 Dec 2014 06:17:28 +0000 Subject: [issue23062] test_argparse --version test cases In-Reply-To: <1418706736.64.0.85644160224.issue23062@psf.upfronthosting.co.za> Message-ID: <1418710648.62.0.105162646314.issue23062@psf.upfronthosting.co.za> Berker Peksag added the comment: I think that your analysis is correct. Also, looks like the original test is problematic: https://code.google.com/p/argparse/source/browse/test/test_argparse.py#3710 Here is a patch to fix the test. ---------- keywords: +patch nosy: +berker.peksag, bethard, paul.j3 stage: -> patch review type: -> behavior versions: +Python 3.4 Added file: http://bugs.python.org/file37460/issue23062.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 07:27:58 2014 From: report at bugs.python.org (Martin Panter) Date: Tue, 16 Dec 2014 06:27:58 +0000 Subject: [issue9694] argparse required arguments displayed under "optional arguments" In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za> Message-ID: <1418711278.0.0.893397618697.issue9694@psf.upfronthosting.co.za> Martin Panter added the comment: Here is much larger patch in the spirit of Ryan?s, that fixes the documentation, adjusts the tests, and some of the internal comments and variable names in the source code as well. However if some changes are too controversial, I am happy to simplify it to (say) Ryan?s patch plus the minimum test fixes. ---------- versions: +Python 3.5 Added file: http://bugs.python.org/file37461/option-internal.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 07:30:14 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 16 Dec 2014 06:30:14 +0000 Subject: [issue22945] Ctypes inconsistent between Linux and OS X In-Reply-To: <1416977210.81.0.587848085748.issue22945@psf.upfronthosting.co.za> Message-ID: <1418711414.81.0.894235218909.issue22945@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks, eryksun. Any objections to closing this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 07:39:42 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 16 Dec 2014 06:39:42 +0000 Subject: [issue22912] urlretreive locks up in 2.7.8 In-Reply-To: <1416599758.35.0.866747041142.issue22912@psf.upfronthosting.co.za> Message-ID: <1418711982.77.0.465643140819.issue22912@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +orsenthil -ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 07:42:48 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 16 Dec 2014 06:42:48 +0000 Subject: [issue22672] float arguments in scientific notation not supported by argparse In-Reply-To: <1413742215.74.0.884028294997.issue22672@psf.upfronthosting.co.za> Message-ID: <1418712168.32.0.77865779545.issue22672@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: -ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 08:11:57 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 16 Dec 2014 07:11:57 +0000 Subject: [issue22706] Idle extension configuration and key bindings In-Reply-To: <1414023453.7.0.681663520586.issue22706@psf.upfronthosting.co.za> Message-ID: <1418713917.82.0.29749616023.issue22706@psf.upfronthosting.co.za> Terry J. Reedy added the comment: When I alter an *extension* key binding (in the keys page of idle pref dialog), the change shows up in .idlerc/config-extensions.cfg, not config-keys.cfg. For instance, [ZoomHeight_cfgBindings] zoom-height = If I also disable zoom-height, the following appears in a separate part of the same file. [XoomHeight] enable=False For me, the two blocks are already in the same file. The same is true for FormatParagraph. I intended this issue to be about bringing them together in the file, with the [X] block first. You seem to be saying that the current behavior is different on linux. Since FormatParagraph is still special (see #20577), try ZoomHeight also. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 08:20:06 2014 From: report at bugs.python.org (Demian Brecht) Date: Tue, 16 Dec 2014 07:20:06 +0000 Subject: [issue14134] xmlrpc.client.ServerProxy needs timeout parameter In-Reply-To: <1330294741.21.0.00592117933576.issue14134@psf.upfronthosting.co.za> Message-ID: <1418714406.91.0.765137865683.issue14134@psf.upfronthosting.co.za> Demian Brecht added the comment: > socket.setdefaulttimeout([timeout]) -- it is bad practice I'm not really arguing this. It solves the problem, but definitely not in the best of ways. My point in referencing setdefaulttimeout is that if /all/ you care about is the timeout and you're horribly opposed to using an API as I suggested, you still have the option of using setdefaulttimeout. To be clear, it's not something that I'd advocate. > because setting this global varible we may spoil other cases. example "TCP keepalive" [s.setsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE, true) ] I'm afraid you've somewhat lost me here. Calling setdefaulttimeout simply sets the value of defaulttimeout in socketmodule.c, which newly created sockets use as their default value until explicitly overridden via settimeout(). > and again -- compare what shorter (and what more clear): Sure, your example is clear for this /specific/ use case. To illustrate my point about ambiguity though, it's unclear what the behaviour should be here based on your patch: proxy = ServerProxy('http://example.com/gateway/', timeout=42, transport=Transport(2)) Should the value in the Transport instance be used or the one in the ServerProxy parameter list? It's not obvious and therefore not a sound decision from an API design standpoint. Ignoring my suggestion of a connection_factory altogether, limiting the timeout to the Transport class is a little more sane and doesn't risk ambiguity: proxy = ServerProxy('http://example.com/gateway/', transport=Transport(timeout=2)) Should my suggestion be tossed out, I do think that this is the most sane path to go down. Now, re-introducing my thoughts on a connection factory (which I still believe is /much/ more flexible and extensible than simply passing in a timeout parameter for the reasons I previously mentioned), should the timeout parameter still be accepted at the Transport level, you run into the same level of ambiguity: transport = Transport(timeout=2, connection_factory=lambda h: HTTPConnection(h, timeout=42)) So now the argument in my mind becomes: Should the connection attributes be assignable through Transport instantiation or should the user have accessibility to create their own instance of a connection class that adheres to the expected API and pass that in? To me, the flexibility and benefits of the latter far outweighs the additional complexity: transport = Transport(timeout=2) transport = Transport(connection_factory=lambda h: HTTPConnection(h, timeout=42)) > if you NOT point timeout in "RPC-client" -- you program will freeze or will maked resource leak (with small probability). Assuming a lack of concurrency, your program will indeed freeze until the system timeout has been reached. I'm not sure about a leak. If you have an example of such a case, it would likely be a good candidate for a new issue. > answer: because *unknown* which value need to using by default. No, the default should be set to socket._GLOBAL_DEFAULT_TIMEOUT (the same default used by HTTPConnection). When unset, the timeout on the socket is unspecified resulting in a value of -1, which then defaults to the system-specific timeout. Hopefully I've clarified things a little better. Of course, that doesn't mean that you'll agree, in which case we'll just have to agree to disagree :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 08:40:44 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 16 Dec 2014 07:40:44 +0000 Subject: [issue23056] tarfile raises an exception when reading an empty tar in streaming mode In-Reply-To: <1418671674.41.0.864207249713.issue23056@psf.upfronthosting.co.za> Message-ID: <1418715644.76.0.296368287896.issue23056@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +larry, lars.gustaebel, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 08:45:35 2014 From: report at bugs.python.org (Andrej A Antonov) Date: Tue, 16 Dec 2014 07:45:35 +0000 Subject: [issue14134] xmlrpc.client.ServerProxy needs timeout parameter In-Reply-To: <1330294741.21.0.00592117933576.issue14134@psf.upfronthosting.co.za> Message-ID: <1418715935.3.0.891646742391.issue14134@psf.upfronthosting.co.za> Andrej A Antonov added the comment: >> if you NOT point timeout in "RPC-client" -- you program will freeze or will maked resource leak (with small probability). > Assuming a lack of concurrency, your program will indeed freeze until the system timeout has been reached. I'm not sure about a leak. If you have an example of such a case, it would likely be a good candidate for a new issue. I do not know how behavior in Microsoft Windows... in GNU/Linux "system timeout has been reached" -- means that system timeout will *never* reached. you may easy to test this (to make this test -- we need using: "client-computer" and "network-router-computer"): step 1. run next code on "client-computer" (GNU/Linux): $ python3 >>> from xmlrpc.client import ServerProxy >>> server = ServerProxy("http://betty.userland.com") >>> for _ in range(100): print(server.examples.getStateName(41)) step 2: to broke network in "network-router-computer". step 3: wait some minutes. example 60 minutes. step 4: to repear netework in "network-router-computer". step 5: we will see, that program on "client-computer" will freeze *forever*. system timeout will *never* reached. even after some days -- system timeout will not reached. :-) > it would likely be a good candidate for a new issue. yes, may be we need new issue-ticket? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 08:58:05 2014 From: report at bugs.python.org (Marc Abramowitz) Date: Tue, 16 Dec 2014 07:58:05 +0000 Subject: [issue23063] `python setup.py check --restructuredtext --strict --metadata` fails with: `warning: check: Could not finish the parsing.` if the RST document uses code or code-block directives. Message-ID: <1418716685.25.0.847417973192.issue23063@psf.upfronthosting.co.za> New submission from Marc Abramowitz: `python setup.py check --restructuredtext --strict --metadata` fails with: warning: check: Could not finish the parsing. if the RST document uses `code` or `code-block` directives. This is annoying because the document is valid, but it appears to be invalid and confuses people. For example, see https://github.com/ionelmc/pytest-benchmark/pull/4#issuecomment-66940307 How to reproduce this bug ------------------------- Clone a repo that has a `README.rst` with `code-block` directives in it. E.g.: $ git clone git at github.com:ionelmc/pytest-benchmark.git $ cd pytest-benchmark $ git checkout ab0b08f6fccb06a7909905a8409f8faa8b01e0d8 Observe that it has "code-blocks" in it: $ grep 'code-block' README.rst .. code-block:: python .. code-block:: python Observe that RST document is valid, according to `rst2html.py`: $ rst2html.py --halt=1 README.rst > README.html && echo "RST was OK." RST was OK. $ head -n 3 README.html Observe that `python setup.py check --restructuredtext --strict --metadata` fails: $ python setup.py check --restructuredtext --strict --metadata running check warning: check: Could not finish the parsing. error: Please correct your package. $ echo $? 1 **What was expected**: `python setup.py check --restructuredtext --strict --metadata` should succeed with no warnings, just as `rst2html.py did`, because `README.rst` is a valid RST document. **What actually happened**: `python setup.py check --restructuredtext --strict --metadata` prints a warning and an error and fails, unlike `rst2html.py` The error is coming from here: https://github.com/python/cpython/blob/master/Lib/distutils/command/check.py#L142 It's happening because of this line: https://github.com/python/cpython/blob/master/Lib/distutils/command/check.py#L125 :::python settings = frontend.OptionParser().get_default_values() If this is changed to: :::python settings = frontend.OptionParser(components=(Parser,)).get_default_values() then things work much better (this is how `tools/quicktest.py` in docutils does it for example -- see https://sourceforge.net/p/docutils/code/HEAD/tree/trunk/docutils/tools/quicktest.py#l196) The attached patch prevents the failure from happening and also adds more information to the error when things go south. ---------- components: Distutils hgrepos: 286 messages: 232720 nosy: Marc.Abramowitz, dstufft, eric.araujo priority: normal severity: normal status: open title: `python setup.py check --restructuredtext --strict --metadata` fails with: `warning: check: Could not finish the parsing.` if the RST document uses code or code-block directives. 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 Tue Dec 16 09:10:00 2014 From: report at bugs.python.org (Marc Abramowitz) Date: Tue, 16 Dec 2014 08:10:00 +0000 Subject: [issue23063] `python setup.py check --restructuredtext --strict --metadata` fails with: `warning: check: Could not finish the parsing.` if the RST document uses code or code-block directives. In-Reply-To: <1418716685.25.0.847417973192.issue23063@psf.upfronthosting.co.za> Message-ID: <1418717400.01.0.59502170314.issue23063@psf.upfronthosting.co.za> Marc Abramowitz added the comment: Testing a few common cases: $ python setup.py check --restructuredtext --strict --metadata running check error: The docutils package is needed. $ python setup.py check --restructuredtext --strict --metadata running check warning: check: Cannot analyze code. Pygments package not found. (line 66) warning: check: Cannot analyze code. Pygments package not found. (line 99) error: Please correct your package. $ python setup.py check --restructuredtext --strict --metadata && echo "RST was OK." running check RST was OK. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 09:14:05 2014 From: report at bugs.python.org (Marc Abramowitz) Date: Tue, 16 Dec 2014 08:14:05 +0000 Subject: [issue23063] `python setup.py check --restructuredtext --strict --metadata` fails with: `warning: check: Could not finish the parsing.` if the RST document uses code or code-block directives. In-Reply-To: <1418716685.25.0.847417973192.issue23063@psf.upfronthosting.co.za> Message-ID: <1418717645.73.0.267252472725.issue23063@psf.upfronthosting.co.za> Marc Abramowitz added the comment: Note that this patch does 2 things: 1. Improves the error message 2. Prevents check from failing when there are code-blocks If I only did #1 and not #2, then output looks like this: $ python setup.py check --restructuredtext --strict --metadata && echo "RST was OK." running check warning: check: Could not finish the parsing: 'Values' object has no attribute 'syntax_highlight'. error: Please correct your package. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 09:16:49 2014 From: report at bugs.python.org (Tim Golden) Date: Tue, 16 Dec 2014 08:16:49 +0000 Subject: [issue22733] MSVC ffi_prep_args doesn't handle 64-bit arguments properly In-Reply-To: <1418707328.0.0.945600016565.issue22733@psf.upfronthosting.co.za> Message-ID: <548FEA6E.7060505@timgolden.me.uk> Tim Golden added the comment: Likewise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 09:17:37 2014 From: report at bugs.python.org (Demian Brecht) Date: Tue, 16 Dec 2014 08:17:37 +0000 Subject: [issue14134] xmlrpc.client.ServerProxy needs timeout parameter In-Reply-To: <1330294741.21.0.00592117933576.issue14134@psf.upfronthosting.co.za> Message-ID: <1418717857.11.0.252412734222.issue14134@psf.upfronthosting.co.za> Demian Brecht added the comment: > in GNU/Linux "system timeout has been reached" -- means that system timeout will *never* reached. That's quite likely because the system limits may be very large. For example, on my OSX box: --- ~ ? sysctl net.inet.tcp.keepinit net.inet.tcp.keepinit: 75000 According to Apple developer docs, this is in seconds. Meaning for your example to run all 100 iterations, you'd be looking at an inordinate amount of time to finish a loop that timed out at each connection attempt and deferred to system defaults for the timeout value. Not exactly "never", but far from a reasonable time frame. Of course, this can be tuned to a more reasonable limit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 09:22:32 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 16 Dec 2014 08:22:32 +0000 Subject: [issue20577] IDLE: Remove FormatParagraph's width setting from config dialog In-Reply-To: <1391974116.91.0.4701294104.issue20577@psf.upfronthosting.co.za> Message-ID: <20141216082213.50099.27517@psf.io> Roundup Robot added the comment: New changeset 51de0da524b4 by Terry Jan Reedy in branch '2.7': Issue #20577: move configuration of FormatParagraph extension to new extension https://hg.python.org/cpython/rev/51de0da524b4 New changeset 3ffa8438d274 by Terry Jan Reedy in branch '3.4': Issue #20577: move configuration of FormatParagraph extension to new extension https://hg.python.org/cpython/rev/3ffa8438d274 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 09:33:01 2014 From: report at bugs.python.org (Andrej A Antonov) Date: Tue, 16 Dec 2014 08:33:01 +0000 Subject: [issue14134] xmlrpc.client.ServerProxy needs timeout parameter In-Reply-To: <1330294741.21.0.00592117933576.issue14134@psf.upfronthosting.co.za> Message-ID: <1418718781.19.0.978417459965.issue14134@psf.upfronthosting.co.za> Andrej A Antonov added the comment: I just will write next code-fragment: import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM, socket.IPPROTO_TCP) s.connect(('python.org', 80)) print( 'is my operation system using (by default) "tcpkeepalive"-algorithm for testing broken-connection? answer:', s.getsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE) ) # answer is 0 (false) -- for all GNU/Linux my previous code-example has 100-iteration -- only for we could catch the right-moment when testing (and for nothing else). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 09:37:16 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 16 Dec 2014 08:37:16 +0000 Subject: [issue20577] IDLE: Remove FormatParagraph's width setting from config dialog In-Reply-To: <1391974116.91.0.4701294104.issue20577@psf.upfronthosting.co.za> Message-ID: <1418719036.13.0.928260170875.issue20577@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- assignee: -> terry.reedy resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 09:47:57 2014 From: report at bugs.python.org (Andrej A Antonov) Date: Tue, 16 Dec 2014 08:47:57 +0000 Subject: [issue14134] xmlrpc.client.ServerProxy needs timeout parameter In-Reply-To: <1330294741.21.0.00592117933576.issue14134@psf.upfronthosting.co.za> Message-ID: <1418719677.05.0.93698849755.issue14134@psf.upfronthosting.co.za> Andrej A Antonov added the comment: >> in GNU/Linux "system timeout has been reached" -- means that system timeout will *never* reached. > That's quite likely because the system limits may be very large. I tested system-timeout GNU/Linux (on various computers). I waited more then 5 days. system-timeout works on GNU/Linux -- only if was custom-set tcpkeepalive, else (by default): even after 5 days system-timeout was not reached. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 09:50:59 2014 From: report at bugs.python.org (Tim Golden) Date: Tue, 16 Dec 2014 08:50:59 +0000 Subject: [issue23060] Assert fails in multiprocessing.heap.Arena.__setstate__ on Windows In-Reply-To: <1418696995.02.0.22756137648.issue23060@psf.upfronthosting.co.za> Message-ID: <548FF270.7010702@timgolden.me.uk> Tim Golden added the comment: I agree that this is a fragile assertion; it's too far removed from the CreateFileMapping call which can generate it and almost impossible to work around (in calling code) if it should fail in the way we're seeing in the buildbot. I think we're better off relying on a genuine exception bubbling up from the CreateFileMapping/MapViewOfFile calls than trying to assert the no-exception error return. While the "preallocate self.buffer" hack you mention would probably have the effect of preventing the assertion, it's really just adding another layer of unwanted complexity. (And might still not work in some future memory-allocation algorithm). @Richard: if you're watching, have I missed anything? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 09:57:07 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 16 Dec 2014 08:57:07 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <1418705690.43.0.683002430368.issue22980@psf.upfronthosting.co.za> Message-ID: <548FF3DF.8010304@egenix.com> Marc-Andre Lemburg added the comment: On 16.12.2014 05:54, Steve Dower wrote: > Nobody seemed too bothered by it, so I committed a slightly simpler change that only includes the most specific tag (that is, ".cp35-win32.pyd" or ".pyd"). We can always add another tag easily enough if it seems useful, or roll this change back if it was a mistake. I'm not sure the format you've chosen is a good idea. We now have a different tag for .pyc (PEP 3149) and .pyd files, in addition to yet another tag format defined in wheels (PEP 425 and PEP 427). The .pyd format looks similar to PEP 425 abi tag + platform tag, but it's missing the abi flags. IMO, we should use one of the available PEP standards instead of creating yet another variant. The checkin also only adds import support for the tags. Shouldn't distutils also be changed to create such .pyd files per default or at least via an option ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 10:41:22 2014 From: report at bugs.python.org (liu chang) Date: Tue, 16 Dec 2014 09:41:22 +0000 Subject: [issue23064] pep8 asyncore.py Message-ID: <1418722882.44.0.721367843466.issue23064@psf.upfronthosting.co.za> New submission from liu chang: pep8 Lib/asycore.py. ---------- components: Library (Lib) files: pep8-asyncore.patch hgrepos: 287 keywords: patch messages: 232730 nosy: ?.? priority: normal severity: normal status: open title: pep8 asyncore.py type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file37462/pep8-asyncore.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 10:56:55 2014 From: report at bugs.python.org (Andrej A Antonov) Date: Tue, 16 Dec 2014 09:56:55 +0000 Subject: [issue14134] xmlrpc.client.ServerProxy needs timeout parameter In-Reply-To: <1330294741.21.0.00592117933576.issue14134@psf.upfronthosting.co.za> Message-ID: <1418723815.57.0.225987055115.issue14134@psf.upfronthosting.co.za> Andrej A Antonov added the comment: @demian.brecht , for high probably to catch *infinite_freeze* (at GNU/Linux) -- if we may will run requests of "xmlrpc.client.ServerProxy" -- parallely: (when running next code -- need to make some network-disconnections on "network-router-computer") #!/usr/bin/env python3 import threading from xmlrpc.client import ServerProxy ITERATION_COUNT = 100 THREAD_COUNT = 100 def thread_func(thread_name): for i in range(ITERATION_COUNT): try: server = ServerProxy("http://betty.userland.com") rpc_result = server.examples.getStateName(41) print('{}/iter_{} {!r}'.format(thread_name, i, rpc_result)) except Exception as e: print('{}/iter_{} error: {} {}'.format(thread_name, i, type(e), str(e))) def main(): print('***** testing begin *****') thread_list = [] for i in range(THREAD_COUNT): thread_name = 'thread_{}'.format(i) thread_list.append(threading.Thread(target=thread_func, args=(thread_name,))) for thr in thread_list: thr.start() for thr in thread_list: thr.join() print('***** testing end *****') if __name__ == '__main__': main() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 11:47:26 2014 From: report at bugs.python.org (Martin Panter) Date: Tue, 16 Dec 2014 10:47:26 +0000 Subject: [issue21619] Cleaning up a subprocess with a broken pipe In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za> Message-ID: <1418726846.57.0.741196312323.issue21619@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch to fix this by calling wait() even if stdin.close() fails, including a test case. With my patch, the subprocess context manager __exit__() will still raise a BrokenPipeError, but no zombie will be left. ---------- keywords: +patch Added file: http://bugs.python.org/file37463/pipe-cleanup.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 11:55:19 2014 From: report at bugs.python.org (GamesGamble) Date: Tue, 16 Dec 2014 10:55:19 +0000 Subject: [issue23065] Pyhton27.dll at SysWOW64 not updated when updating Python 2.7.X Message-ID: <1418727319.18.0.894015013947.issue23065@psf.upfronthosting.co.za> New submission from GamesGamble: Hello, the Python27.dll at >C:\Windows\SysWOW64< not get updated when updating Python 2.7.X at Windows 7 SP1 (Reported weak spot from Kaspersky Pure 3.0 weak spot search). When I?am manually deinstalling Python und install Python after deinstalling It got the updated *.dll . ---------- components: Windows messages: 232733 nosy: GamesGamble, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Pyhton27.dll at SysWOW64 not updated when updating Python 2.7.X type: security versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 12:52:40 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 16 Dec 2014 11:52:40 +0000 Subject: [issue23063] `python setup.py check --restructuredtext --strict --metadata` fails with: `warning: check: Could not finish the parsing.` if the RST document uses code or code-block directives. In-Reply-To: <1418716685.25.0.847417973192.issue23063@psf.upfronthosting.co.za> Message-ID: <1418730760.45.0.369305119547.issue23063@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +patch Added file: http://bugs.python.org/file37464/cfabe07bc98f.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 12:53:23 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 16 Dec 2014 11:53:23 +0000 Subject: [issue23063] `python setup.py check --restructuredtext --strict --metadata` fails with: `warning: check: Could not finish the parsing.` if the RST document uses code or code-block directives. In-Reply-To: <1418716685.25.0.847417973192.issue23063@psf.upfronthosting.co.za> Message-ID: <1418730803.25.0.669200592664.issue23063@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> patch review versions: -Python 3.2, Python 3.3, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 12:55:49 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 16 Dec 2014 11:55:49 +0000 Subject: [issue23063] `python setup.py check --restructuredtext --strict --metadata` fails with: `warning: check: Could not finish the parsing.` if the RST document uses code or code-block directives. In-Reply-To: <1418716685.25.0.847417973192.issue23063@psf.upfronthosting.co.za> Message-ID: <1418730949.92.0.41228152397.issue23063@psf.upfronthosting.co.za> Berker Peksag added the comment: Could you add a test? See Lib/distutils/tests/test_check.py. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 13:02:19 2014 From: report at bugs.python.org (liu chang) Date: Tue, 16 Dec 2014 12:02:19 +0000 Subject: [issue23056] tarfile raises an exception when reading an empty tar in streaming mode In-Reply-To: <1418671674.41.0.864207249713.issue23056@psf.upfronthosting.co.za> Message-ID: <1418731339.2.0.85773236239.issue23056@psf.upfronthosting.co.za> liu chang added the comment: 2232 def next(self): 2233 """Return the next member of the archive as a TarInfo object, when 2234 TarFile is opened for reading. Return None if there is no more 2235 available. 2236 """ 2237 self._check("ra") 2238 if self.firstmember is not None: 2239 m = self.firstmember 2240 self.firstmember = None 2241 return m 2242 2243 # Read the next block. 2244 self.fileobj.seek(self.offset) 2245 tarinfo = None raise a StreamError at #2244, It should catch this Error and return None. I would like to post a patch to fix it. ---------- nosy: +liu chang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 13:09:20 2014 From: report at bugs.python.org (liu chang) Date: Tue, 16 Dec 2014 12:09:20 +0000 Subject: [issue23056] tarfile raises an exception when reading an empty tar in streaming mode In-Reply-To: <1418671674.41.0.864207249713.issue23056@psf.upfronthosting.co.za> Message-ID: <1418731760.06.0.430843870605.issue23056@psf.upfronthosting.co.za> liu chang added the comment: a simple fix ---------- keywords: +patch Added file: http://bugs.python.org/file37465/fix-tar-23056.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 13:31:37 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 16 Dec 2014 12:31:37 +0000 Subject: [issue23055] PyUnicode_FromFormatV crasher In-Reply-To: <1418692148.99.0.110209252903.issue23055@psf.upfronthosting.co.za> Message-ID: <5700338.LW00qqNYSG@raxxla> Serhiy Storchaka added the comment: Here is updated patch for 2.7 (backported tests from 3.5), patches for 3.2 and 3.3. ---------- Added file: http://bugs.python.org/file37466/issue23055-2.7-2.patch Added file: http://bugs.python.org/file37467/issue23055-3.2.patch Added file: http://bugs.python.org/file37468/issue23055-3.3.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 9927781e457f Lib/test/test_unicode.py --- a/Lib/test/test_unicode.py Mon Dec 15 14:02:43 2014 +0200 +++ b/Lib/test/test_unicode.py Tue Dec 16 13:52:24 2014 +0200 @@ -1700,6 +1700,9 @@ class UnicodeTest( if sys.maxunicode > 0xffff: check_format(u'\U0010ffff', b'%c', c_int(0x10ffff)) + else: + with self.assertRaises(OverflowError): + PyUnicode_FromFormat(b'%c', c_int(0x10000)) with self.assertRaises(OverflowError): PyUnicode_FromFormat(b'%c', c_int(0x110000)) # Issue #18183 @@ -1750,8 +1753,45 @@ class UnicodeTest( b'%zu', c_size_t(123)) # test long output + min_long = -(2 ** (8 * sizeof(c_long) - 1)) + max_long = -min_long - 1 + check_format(unicode(min_long), + b'%ld', c_long(min_long)) + check_format(unicode(max_long), + b'%ld', c_long(max_long)) + max_ulong = 2 ** (8 * sizeof(c_ulong)) - 1 + check_format(unicode(max_ulong), + b'%lu', c_ulong(max_ulong)) PyUnicode_FromFormat(b'%p', c_void_p(-1)) + # test padding (width and/or precision) + check_format(u'123'.rjust(10, u'0'), + b'%010i', c_int(123)) + check_format(u'123'.rjust(100), + b'%100i', c_int(123)) + check_format(u'123'.rjust(100, u'0'), + b'%.100i', c_int(123)) + check_format(u'123'.rjust(80, u'0').rjust(100), + b'%100.80i', c_int(123)) + + check_format(u'123'.rjust(10, u'0'), + b'%010u', c_uint(123)) + check_format(u'123'.rjust(100), + b'%100u', c_uint(123)) + check_format(u'123'.rjust(100, u'0'), + b'%.100u', c_uint(123)) + check_format(u'123'.rjust(80, u'0').rjust(100), + b'%100.80u', c_uint(123)) + + check_format(u'123'.rjust(10, u'0'), + b'%010x', c_int(0x123)) + check_format(u'123'.rjust(100), + b'%100x', c_int(0x123)) + check_format(u'123'.rjust(100, u'0'), + b'%.100x', c_int(0x123)) + check_format(u'123'.rjust(80, u'0').rjust(100), + b'%100.80x', c_int(0x123)) + # test %V check_format(u'repr=abc', b'repr=%V', u'abc', b'xyz') diff -r 9927781e457f Misc/NEWS --- a/Misc/NEWS Mon Dec 15 14:02:43 2014 +0200 +++ b/Misc/NEWS Tue Dec 16 13:52:24 2014 +0200 @@ -10,6 +10,9 @@ What's New in Python 2.7.10? Core and Builtins ----------------- +- Issue #23055: Fixed a buffer overflow in PyUnicode_FromFormatV. Analysis + and fix by Guido Vranken. + - Issue #23048: Fix jumping out of an infinite while loop in the pdb. Library diff -r 9927781e457f Objects/unicodeobject.c --- a/Objects/unicodeobject.c Mon Dec 15 14:02:43 2014 +0200 +++ b/Objects/unicodeobject.c Tue Dec 16 13:52:24 2014 +0200 @@ -735,15 +735,10 @@ PyUnicode_FromFormatV(const char *format * objects once during step 3 and put the result in an array) */ for (f = format; *f; f++) { if (*f == '%') { - if (*(f+1)=='%') - continue; - if (*(f+1)=='S' || *(f+1)=='R') - ++callcount; - while (isdigit((unsigned)*f)) - width = (width*10) + *f++ - '0'; - while (*++f && *f != '%' && !isalpha((unsigned)*f)) - ; - if (*f == 's') + f++; + while (*f && *f != '%' && !isalpha((unsigned)*f)) + f++; + if (*f == 's' || *f=='S' || *f=='R') ++callcount; } } @@ -760,12 +755,16 @@ PyUnicode_FromFormatV(const char *format /* step 3: figure out how large a buffer we need */ for (f = format; *f; f++) { if (*f == '%') { - const char* p = f; + const char* p = f++; width = 0; while (isdigit((unsigned)*f)) width = (width*10) + *f++ - '0'; - while (*++f && *f != '%' && !isalpha((unsigned)*f)) - ; + precision = 0; + if (*f == '.') { + f++; + while (isdigit((unsigned)*f)) + precision = (precision*10) + *f++ - '0'; + } /* skip the 'l' or 'z' in {%ld, %zd, %lu, %zu} since * they don't affect the amount of space we reserve. @@ -800,6 +799,8 @@ PyUnicode_FromFormatV(const char *format break; case 'd': case 'u': case 'i': case 'x': (void) va_arg(count, int); + if (width < precision) + width = precision; /* 20 bytes is enough to hold a 64-bit integer. Decimal takes the most space. This isn't enough for octal. -------------- next part -------------- diff -r a0368f81af9a Lib/test/test_unicode.py --- a/Lib/test/test_unicode.py Fri Dec 05 20:15:15 2014 -0500 +++ b/Lib/test/test_unicode.py Tue Dec 16 13:51:07 2014 +0200 @@ -1661,7 +1661,10 @@ class UnicodeTest(string_tests.CommonTes # Test PyUnicode_FromFormat() def test_from_format(self): support.import_module('ctypes') - from ctypes import pythonapi, py_object, c_int + from ctypes import ( + pythonapi, py_object, sizeof, + c_int, c_long, c_longlong, c_ssize_t, + c_uint, c_ulong, c_ulonglong, c_size_t, c_void_p) if sys.maxunicode == 65535: name = "PyUnicodeUCS2_FromFormat" else: @@ -1675,9 +1678,13 @@ class UnicodeTest(string_tests.CommonTes for arg in args) return _PyUnicode_FromFormat(format, *cargs) + def check_format(expected, format, *args): + text = PyUnicode_FromFormat(format, *args) + self.assertEqual(expected, text) + # ascii format, non-ascii argument - text = PyUnicode_FromFormat(b'ascii\x7f=%U', 'unicode\xe9') - self.assertEqual(text, 'ascii\x7f=unicode\xe9') + check_format('ascii\x7f=unicode\xe9', + b'ascii\x7f=%U', 'unicode\xe9') # non-ascii format, ascii argument: ensure that PyUnicode_FromFormatV() # raises an error @@ -1686,25 +1693,131 @@ class UnicodeTest(string_tests.CommonTes 'string, got a non-ASCII byte: 0xe9$', PyUnicode_FromFormat, b'unicode\xe9=%s', 'ascii') - self.assertEqual(PyUnicode_FromFormat(b'%c', c_int(0xabcd)), '\uabcd') - self.assertEqual(PyUnicode_FromFormat(b'%c', c_int(0x10ffff)), '\U0010ffff') + # test "%c" + check_format('\uabcd', + b'%c', c_int(0xabcd)) + check_format('\U0010ffff', + b'%c', c_int(0x10ffff)) + with self.assertRaises(OverflowError): + PyUnicode_FromFormat(b'%c', c_int(0x110000)) + # Issue #18183 + check_format('\U00010000\U00100000', + b'%c%c', c_int(0x10000), c_int(0x100000)) - # other tests - text = PyUnicode_FromFormat(b'%%A:%A', 'abc\xe9\uabcd\U0010ffff') - self.assertEqual(text, r"%A:'abc\xe9\uabcd\U0010ffff'") + # test "%" + check_format('%', + b'%') + check_format('%', + b'%%') + check_format('%s', + b'%%s') + check_format('[%]', + b'[%%]') + check_format('%abc', + b'%%%s', b'abc') - text = PyUnicode_FromFormat(b'repr=%V', 'abc', b'xyz') - self.assertEqual(text, 'repr=abc') + # test %S + check_format("repr=\u20acABC", + b'repr=%S', '\u20acABC') + + # test %R + check_format("repr='\u20acABC'", + b'repr=%R', '\u20acABC') + + # test integer formats (%i, %d, %u) + check_format('010', + b'%03i', c_int(10)) + check_format('0010', + b'%0.4i', c_int(10)) + check_format('-123', + b'%i', c_int(-123)) + + check_format('-123', + b'%d', c_int(-123)) + check_format('-123', + b'%ld', c_long(-123)) + check_format('-123', + b'%lld', c_longlong(-123)) + check_format('-123', + b'%zd', c_ssize_t(-123)) + + check_format('123', + b'%u', c_uint(123)) + check_format('123', + b'%lu', c_ulong(123)) + check_format('123', + b'%llu', c_ulonglong(123)) + check_format('123', + b'%zu', c_size_t(123)) + + # test long output + min_longlong = -(2 ** (8 * sizeof(c_longlong) - 1)) + max_longlong = -min_longlong - 1 + check_format(str(min_longlong), + b'%lld', c_longlong(min_longlong)) + check_format(str(max_longlong), + b'%lld', c_longlong(max_longlong)) + max_ulonglong = 2 ** (8 * sizeof(c_ulonglong)) - 1 + check_format(str(max_ulonglong), + b'%llu', c_ulonglong(max_ulonglong)) + PyUnicode_FromFormat(b'%p', c_void_p(-1)) + + # test padding (width and/or precision) + check_format('123'.rjust(10, '0'), + b'%010i', c_int(123)) + check_format('123'.rjust(100), + b'%100i', c_int(123)) + check_format('123'.rjust(100, '0'), + b'%.100i', c_int(123)) + check_format('123'.rjust(80, '0').rjust(100), + b'%100.80i', c_int(123)) + + check_format('123'.rjust(10, '0'), + b'%010u', c_uint(123)) + check_format('123'.rjust(100), + b'%100u', c_uint(123)) + check_format('123'.rjust(100, '0'), + b'%.100u', c_uint(123)) + check_format('123'.rjust(80, '0').rjust(100), + b'%100.80u', c_uint(123)) + + check_format('123'.rjust(10, '0'), + b'%010x', c_int(0x123)) + check_format('123'.rjust(100), + b'%100x', c_int(0x123)) + check_format('123'.rjust(100, '0'), + b'%.100x', c_int(0x123)) + check_format('123'.rjust(80, '0').rjust(100), + b'%100.80x', c_int(0x123)) + + # test %A + check_format(r"%A:'abc\xe9\uabcd\U0010ffff'", + b'%%A:%A', 'abc\xe9\uabcd\U0010ffff') + + # test %V + check_format('repr=abc', + b'repr=%V', 'abc', b'xyz') # Test string decode from parameter of %s using utf-8. # b'\xe4\xba\xba\xe6\xb0\x91' is utf-8 encoded byte sequence of # '\u4eba\u6c11' - text = PyUnicode_FromFormat(b'repr=%V', None, b'\xe4\xba\xba\xe6\xb0\x91') - self.assertEqual(text, 'repr=\u4eba\u6c11') + check_format('repr=\u4eba\u6c11', + b'repr=%V', None, b'\xe4\xba\xba\xe6\xb0\x91') #Test replace error handler. - text = PyUnicode_FromFormat(b'repr=%V', None, b'abc\xff') - self.assertEqual(text, 'repr=abc\ufffd') + check_format('repr=abc\ufffd', + b'repr=%V', None, b'abc\xff') + + # not supported: copy the raw format string. these tests are just here + # to check for crashs and should not be considered as specifications + check_format('%s', + b'%1%s', b'abc') + check_format('%1abc', + b'%1abc') + check_format('%+i', + b'%+i', c_int(10)) + check_format('%s', + b'%.%s', b'abc') # Test PyUnicode_AsWideChar() def test_aswidechar(self): diff -r a0368f81af9a Misc/NEWS --- a/Misc/NEWS Fri Dec 05 20:15:15 2014 -0500 +++ b/Misc/NEWS Tue Dec 16 13:51:07 2014 +0200 @@ -2,6 +2,18 @@ Python News +++++++++++ +What's New in Python 3.2.7? +============================ + +*Release date: XXXX-XX-XX* + +Core and Builtins +----------------- + +- Issue #23055: Fixed a buffer overflow in PyUnicode_FromFormatV. Analysis + and fix by Guido Vranken. + + What's New in Python 3.2.6? =========================== diff -r a0368f81af9a Objects/unicodeobject.c --- a/Objects/unicodeobject.c Fri Dec 05 20:15:15 2014 -0500 +++ b/Objects/unicodeobject.c Tue Dec 16 13:51:07 2014 +0200 @@ -759,15 +759,10 @@ PyUnicode_FromFormatV(const char *format * result in an array) */ for (f = format; *f; f++) { if (*f == '%') { - if (*(f+1)=='%') - continue; - if (*(f+1)=='S' || *(f+1)=='R' || *(f+1)=='A' || *(f+1) == 'V') - ++callcount; - while (Py_ISDIGIT((unsigned)*f)) - width = (width*10) + *f++ - '0'; - while (*++f && *f != '%' && !Py_ISALPHA((unsigned)*f)) - ; - if (*f == 's') + f++; + while (*f && *f != '%' && !Py_ISALPHA((unsigned)*f)) + f++; + if (*f == 's' || *f=='S' || *f=='R' || *f=='A' || *f=='V') ++callcount; } else if (128 <= (unsigned char)*f) { @@ -794,12 +789,16 @@ PyUnicode_FromFormatV(const char *format #ifdef HAVE_LONG_LONG int longlongflag = 0; #endif - const char* p = f; + const char* p = f++; width = 0; while (Py_ISDIGIT((unsigned)*f)) width = (width*10) + *f++ - '0'; - while (*++f && *f != '%' && !Py_ISALPHA((unsigned)*f)) - ; + precision = 0; + if (*f == '.') { + f++; + while (Py_ISDIGIT((unsigned)*f)) + precision = (precision*10) + *f++ - '0'; + } /* skip the 'l' or 'z' in {%ld, %zd, %lu, %zu} since * they don't affect the amount of space we reserve. @@ -823,16 +822,18 @@ PyUnicode_FromFormatV(const char *format switch (*f) { case 'c': { + int ordinal = va_arg(count, int); + if (ordinal < 0 || ordinal > 0x10ffff) { + PyErr_SetString(PyExc_OverflowError, + "%c arg not in range(0x110000)"); + goto fail; + } #ifndef Py_UNICODE_WIDE - int ordinal = va_arg(count, int); if (ordinal > 0xffff) n += 2; else - n++; -#else - (void)va_arg(count, int); +#endif n++; -#endif break; } case '%': @@ -840,6 +841,8 @@ PyUnicode_FromFormatV(const char *format break; case 'd': case 'u': case 'i': case 'x': (void) va_arg(count, int); + if (width < precision) + width = precision; #ifdef HAVE_LONG_LONG if (longlongflag) { if (width < MAX_LONG_LONG_CHARS) -------------- next part -------------- diff -r 4a9418c6f8ae Lib/test/test_unicode.py --- a/Lib/test/test_unicode.py Fri Dec 05 20:30:54 2014 -0500 +++ b/Lib/test/test_unicode.py Tue Dec 16 13:51:18 2014 +0200 @@ -2016,9 +2016,10 @@ class UnicodeTest(string_tests.CommonTes # Test PyUnicode_FromFormat() def test_from_format(self): support.import_module('ctypes') - from ctypes import (pythonapi, py_object, + from ctypes import ( + pythonapi, py_object, sizeof, c_int, c_long, c_longlong, c_ssize_t, - c_uint, c_ulong, c_ulonglong, c_size_t) + c_uint, c_ulong, c_ulonglong, c_size_t, c_void_p) name = "PyUnicode_FromFormat" _PyUnicode_FromFormat = getattr(pythonapi, name) _PyUnicode_FromFormat.restype = py_object @@ -2029,9 +2030,13 @@ class UnicodeTest(string_tests.CommonTes for arg in args) return _PyUnicode_FromFormat(format, *cargs) + def check_format(expected, format, *args): + text = PyUnicode_FromFormat(format, *args) + self.assertEqual(expected, text) + # ascii format, non-ascii argument - text = PyUnicode_FromFormat(b'ascii\x7f=%U', 'unicode\xe9') - self.assertEqual(text, 'ascii\x7f=unicode\xe9') + check_format('ascii\x7f=unicode\xe9', + b'ascii\x7f=%U', 'unicode\xe9') # non-ascii format, ascii argument: ensure that PyUnicode_FromFormatV() # raises an error @@ -2041,64 +2046,136 @@ class UnicodeTest(string_tests.CommonTes PyUnicode_FromFormat, b'unicode\xe9=%s', 'ascii') # test "%c" - self.assertEqual(PyUnicode_FromFormat(b'%c', c_int(0xabcd)), '\uabcd') - self.assertEqual(PyUnicode_FromFormat(b'%c', c_int(0x10ffff)), '\U0010ffff') + check_format('\uabcd', + b'%c', c_int(0xabcd)) + check_format('\U0010ffff', + b'%c', c_int(0x10ffff)) with self.assertRaises(OverflowError): PyUnicode_FromFormat(b'%c', c_int(0x110000)) # Issue #18183 - self.assertEqual( - PyUnicode_FromFormat(b'%c%c', c_int(0x10000), c_int(0x100000)), - '\U00010000\U00100000') + check_format('\U00010000\U00100000', + b'%c%c', c_int(0x10000), c_int(0x100000)) # test "%" - self.assertEqual(PyUnicode_FromFormat(b'%'), '%') - self.assertEqual(PyUnicode_FromFormat(b'%%'), '%') - self.assertEqual(PyUnicode_FromFormat(b'%%s'), '%s') - self.assertEqual(PyUnicode_FromFormat(b'[%%]'), '[%]') - self.assertEqual(PyUnicode_FromFormat(b'%%%s', b'abc'), '%abc') + check_format('%', + b'%') + check_format('%', + b'%%') + check_format('%s', + b'%%s') + check_format('[%]', + b'[%%]') + check_format('%abc', + b'%%%s', b'abc') + + # test %S + check_format("repr=\u20acABC", + b'repr=%S', '\u20acABC') + + # test %R + check_format("repr='\u20acABC'", + b'repr=%R', '\u20acABC') # test integer formats (%i, %d, %u) - self.assertEqual(PyUnicode_FromFormat(b'%03i', c_int(10)), '010') - self.assertEqual(PyUnicode_FromFormat(b'%0.4i', c_int(10)), '0010') - self.assertEqual(PyUnicode_FromFormat(b'%i', c_int(-123)), '-123') - self.assertEqual(PyUnicode_FromFormat(b'%li', c_long(-123)), '-123') - self.assertEqual(PyUnicode_FromFormat(b'%lli', c_longlong(-123)), '-123') - self.assertEqual(PyUnicode_FromFormat(b'%zi', c_ssize_t(-123)), '-123') + check_format('010', + b'%03i', c_int(10)) + check_format('0010', + b'%0.4i', c_int(10)) + check_format('-123', + b'%i', c_int(-123)) + check_format('-123', + b'%li', c_long(-123)) + check_format('-123', + b'%lli', c_longlong(-123)) + check_format('-123', + b'%zi', c_ssize_t(-123)) - self.assertEqual(PyUnicode_FromFormat(b'%d', c_int(-123)), '-123') - self.assertEqual(PyUnicode_FromFormat(b'%ld', c_long(-123)), '-123') - self.assertEqual(PyUnicode_FromFormat(b'%lld', c_longlong(-123)), '-123') - self.assertEqual(PyUnicode_FromFormat(b'%zd', c_ssize_t(-123)), '-123') + check_format('-123', + b'%d', c_int(-123)) + check_format('-123', + b'%ld', c_long(-123)) + check_format('-123', + b'%lld', c_longlong(-123)) + check_format('-123', + b'%zd', c_ssize_t(-123)) - self.assertEqual(PyUnicode_FromFormat(b'%u', c_uint(123)), '123') - self.assertEqual(PyUnicode_FromFormat(b'%lu', c_ulong(123)), '123') - self.assertEqual(PyUnicode_FromFormat(b'%llu', c_ulonglong(123)), '123') - self.assertEqual(PyUnicode_FromFormat(b'%zu', c_size_t(123)), '123') + check_format('123', + b'%u', c_uint(123)) + check_format('123', + b'%lu', c_ulong(123)) + check_format('123', + b'%llu', c_ulonglong(123)) + check_format('123', + b'%zu', c_size_t(123)) + + # test long output + min_longlong = -(2 ** (8 * sizeof(c_longlong) - 1)) + max_longlong = -min_longlong - 1 + check_format(str(min_longlong), + b'%lld', c_longlong(min_longlong)) + check_format(str(max_longlong), + b'%lld', c_longlong(max_longlong)) + max_ulonglong = 2 ** (8 * sizeof(c_ulonglong)) - 1 + check_format(str(max_ulonglong), + b'%llu', c_ulonglong(max_ulonglong)) + PyUnicode_FromFormat(b'%p', c_void_p(-1)) + + # test padding (width and/or precision) + check_format('123'.rjust(10, '0'), + b'%010i', c_int(123)) + check_format('123'.rjust(100), + b'%100i', c_int(123)) + check_format('123'.rjust(300, '0'), + b'%.300i', c_int(123)) + check_format('123'.rjust(80, '0').rjust(100), + b'%100.80i', c_int(123)) + + check_format('123'.rjust(10, '0'), + b'%010u', c_uint(123)) + check_format('123'.rjust(100), + b'%100u', c_uint(123)) + check_format('123'.rjust(300, '0'), + b'%.300u', c_uint(123)) + check_format('123'.rjust(80, '0').rjust(100), + b'%100.80u', c_uint(123)) + + check_format('123'.rjust(10, '0'), + b'%010x', c_int(0x123)) + check_format('123'.rjust(100), + b'%100x', c_int(0x123)) + check_format('123'.rjust(300, '0'), + b'%.300x', c_int(0x123)) + check_format('123'.rjust(80, '0').rjust(100), + b'%100.80x', c_int(0x123)) # test %A - text = PyUnicode_FromFormat(b'%%A:%A', 'abc\xe9\uabcd\U0010ffff') - self.assertEqual(text, r"%A:'abc\xe9\uabcd\U0010ffff'") + check_format(r"%A:'abc\xe9\uabcd\U0010ffff'", + b'%%A:%A', 'abc\xe9\uabcd\U0010ffff') # test %V - text = PyUnicode_FromFormat(b'repr=%V', 'abc', b'xyz') - self.assertEqual(text, 'repr=abc') + check_format('repr=abc', + b'repr=%V', 'abc', b'xyz') # Test string decode from parameter of %s using utf-8. # b'\xe4\xba\xba\xe6\xb0\x91' is utf-8 encoded byte sequence of # '\u4eba\u6c11' - text = PyUnicode_FromFormat(b'repr=%V', None, b'\xe4\xba\xba\xe6\xb0\x91') - self.assertEqual(text, 'repr=\u4eba\u6c11') + check_format('repr=\u4eba\u6c11', + b'repr=%V', None, b'\xe4\xba\xba\xe6\xb0\x91') #Test replace error handler. - text = PyUnicode_FromFormat(b'repr=%V', None, b'abc\xff') - self.assertEqual(text, 'repr=abc\ufffd') + check_format('repr=abc\ufffd', + b'repr=%V', None, b'abc\xff') # not supported: copy the raw format string. these tests are just here # to check for crashs and should not be considered as specifications - self.assertEqual(PyUnicode_FromFormat(b'%1%s', b'abc'), '%s') - self.assertEqual(PyUnicode_FromFormat(b'%1abc'), '%1abc') - self.assertEqual(PyUnicode_FromFormat(b'%+i', c_int(10)), '%+i') - self.assertEqual(PyUnicode_FromFormat(b'%.%s', b'abc'), '%.%s') + check_format('%s', + b'%1%s', b'abc') + check_format('%1abc', + b'%1abc') + check_format('%+i', + b'%+i', c_int(10)) + check_format('%.%s', + b'%.%s', b'abc') # Test PyUnicode_AsWideChar() @support.cpython_only diff -r 4a9418c6f8ae Misc/NEWS --- a/Misc/NEWS Fri Dec 05 20:30:54 2014 -0500 +++ b/Misc/NEWS Tue Dec 16 13:51:18 2014 +0200 @@ -2,6 +2,18 @@ Python News +++++++++++ +What's New in Python 3.3.7? +============================ + +*Release date: XXXX-XX-XX* + +Core and Builtins +----------------- + +- Issue #23055: Fixed a buffer overflow in PyUnicode_FromFormatV. Analysis + and fix by Guido Vranken. + + What's New in Python 3.3.6? =========================== diff -r 4a9418c6f8ae Objects/unicodeobject.c --- a/Objects/unicodeobject.c Fri Dec 05 20:30:54 2014 -0500 +++ b/Objects/unicodeobject.c Tue Dec 16 13:51:18 2014 +0200 @@ -2335,6 +2335,8 @@ parse_format_flags(const char *f, f--; } } + if (width < precision) + width = precision; if (*f == '\0') { /* bogus format "%.1" => go backward, f points to "1" */ f--; From report at bugs.python.org Tue Dec 16 13:48:48 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 16 Dec 2014 12:48:48 +0000 Subject: [issue19858] Make pickletools.optimize aware of the MEMOIZE opcode. In-Reply-To: <1385946014.54.0.601831543599.issue19858@psf.upfronthosting.co.za> Message-ID: <1418734128.0.0.354139021536.issue19858@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which addresses Antoine's comments. Also added dis() output for binary example in comments. ---------- Added file: http://bugs.python.org/file37469/pickle_optimize_memoize_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 13:53:32 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 16 Dec 2014 12:53:32 +0000 Subject: [issue22783] Pickle: use NEWOBJ instead of NEWOBJ_EX if possible In-Reply-To: <1414942122.91.0.879577274082.issue22783@psf.upfronthosting.co.za> Message-ID: <1418734412.88.0.486078743542.issue22783@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated patch addresses Antoine's comments. Also added few comments explaining binary data. ---------- Added file: http://bugs.python.org/file37470/pickle_newobj_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 14:38:52 2014 From: report at bugs.python.org (Steve Dower) Date: Tue, 16 Dec 2014 13:38:52 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <1417530925.56.0.55888060474.issue22980@psf.upfronthosting.co.za> Message-ID: <1418737132.92.0.582001607945.issue22980@psf.upfronthosting.co.za> Steve Dower added the comment: I justified leaving out the ABI tag in an earlier post as well as in an email to distutils-sig, where two of the PEPs you mention were developed, and nobody had any comment. Cache tags don't include platform information and are worthless here. distutils uses the first extension from _imp.extension_suffixes() and so will automatically tag binaries. I also tested with setuptools and Cython. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 14:47:21 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 16 Dec 2014 13:47:21 +0000 Subject: [issue23014] Don't have importlib.abc.Loader.create_module() be optional In-Reply-To: <1418055538.78.0.471721917483.issue23014@psf.upfronthosting.co.za> Message-ID: <1418737641.17.0.404515469457.issue23014@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'm still a fan of "never" - it's a good escape hatch that means we never have to contort the new API to deal with some of the more esoteric use cases that involved completely overloading the import process in the loader :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 14:53:18 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 16 Dec 2014 13:53:18 +0000 Subject: [issue23064] pep8 asyncore.py In-Reply-To: <1418722882.44.0.721367843466.issue23064@psf.upfronthosting.co.za> Message-ID: <1418737998.7.0.898970701818.issue23064@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for the effort, but we do not apply PEP8-only patches. The small improvements in readability do not justify the costs of code churn and the chance of introducing bugs. (Also, FYI, PEP8 discourages using \ for line continuation.) ---------- nosy: +r.david.murray resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 14:54:32 2014 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 16 Dec 2014 13:54:32 +0000 Subject: [issue19698] Implement _imp.exec_builtin and exec_dynamic In-Reply-To: <1385137675.64.0.235823443194.issue19698@psf.upfronthosting.co.za> Message-ID: <1418738072.34.0.502101810539.issue19698@psf.upfronthosting.co.za> Nick Coghlan added the comment: Turns out I had written up a recap of the PEP 451 C extension support status back in July, so I just resent that to import-sig. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 15:35:05 2014 From: report at bugs.python.org (Daniel Standage) Date: Tue, 16 Dec 2014 14:35:05 +0000 Subject: [issue22945] Ctypes inconsistent between Linux and OS X In-Reply-To: <1416977210.81.0.587848085748.issue22945@psf.upfronthosting.co.za> Message-ID: <1418740505.44.0.80407733423.issue22945@psf.upfronthosting.co.za> Daniel Standage added the comment: Sorry for my radio silence. Your example was very helpful, and restores the behavior I was looking for. Thanks! ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 16:05:24 2014 From: report at bugs.python.org (Brett Cannon) Date: Tue, 16 Dec 2014 15:05:24 +0000 Subject: [issue23014] Don't have importlib.abc.Loader.create_module() be optional In-Reply-To: <1418055538.78.0.471721917483.issue23014@psf.upfronthosting.co.za> Message-ID: <1418742324.91.0.121944762829.issue23014@psf.upfronthosting.co.za> Brett Cannon added the comment: Yeah, we need to settle the whole load_module() thing at PyCon because I'm tired of it hanging over our heads since the code is entirely structured to yank it out and if it's going to stay I want to clean up _bootstrap.py to make the code flow easier to follow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 16:28:28 2014 From: report at bugs.python.org (Jie Yin) Date: Tue, 16 Dec 2014 15:28:28 +0000 Subject: [issue23066] re.match hang Message-ID: <1418743708.93.0.075282769465.issue23066@psf.upfronthosting.co.za> New submission from Jie Yin: The following expression hang in 2.7.9 for the module re: re.match('^([a-zA-Z0-9]+|[\\s]+|[,.])+$', 'Feature Test Macro Requirements for glibc ()') ---------- components: Interpreter Core messages: 232746 nosy: writalnaie priority: normal severity: normal status: open title: re.match hang type: security versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 16:40:48 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 16 Dec 2014 15:40:48 +0000 Subject: [issue23066] re.match hang In-Reply-To: <1418743708.93.0.075282769465.issue23066@psf.upfronthosting.co.za> Message-ID: <1418744448.54.0.514667530965.issue23066@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 16:43:17 2014 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 16 Dec 2014 15:43:17 +0000 Subject: [issue23066] re.match hang In-Reply-To: <1418743708.93.0.075282769465.issue23066@psf.upfronthosting.co.za> Message-ID: <1418744597.35.0.802918950858.issue23066@psf.upfronthosting.co.za> Guido van Rossum added the comment: Please go to python-list to get help about writing re expressions for parsing. The example regexp does not technically hang, it is just exploring a very large set of alternatives, none of which match (because the trailing '()' doesn't match anything). ---------- nosy: +gvanrossum resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 17:06:07 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 16 Dec 2014 16:06:07 +0000 Subject: [issue19858] Make pickletools.optimize aware of the MEMOIZE opcode. In-Reply-To: <1385946014.54.0.601831543599.issue19858@psf.upfronthosting.co.za> Message-ID: <20141216160604.28208.35430@psf.io> Roundup Robot added the comment: New changeset c49b7acba06f by Serhiy Storchaka in branch '3.4': Issue #19858: pickletools.optimize() now aware of the MEMOIZE opcode, can https://hg.python.org/cpython/rev/c49b7acba06f New changeset e7dd739b4b4e by Serhiy Storchaka in branch 'default': Issue #19858: pickletools.optimize() now aware of the MEMOIZE opcode, can https://hg.python.org/cpython/rev/e7dd739b4b4e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 18:24:51 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 16 Dec 2014 17:24:51 +0000 Subject: [issue23060] Assert fails in multiprocessing.heap.Arena.__setstate__ on Windows In-Reply-To: <1418696995.02.0.22756137648.issue23060@psf.upfronthosting.co.za> Message-ID: <1418750691.77.0.23489511623.issue23060@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Or perhaps: buffer = mmap.mmap(-1, self.size, tagname=self.name) assert _winapi.GetLastError() == _winapi.ERROR_ALREADY_EXISTS self.buffer = buffer ? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 19:03:09 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 16 Dec 2014 18:03:09 +0000 Subject: [issue22783] Pickle: use NEWOBJ instead of NEWOBJ_EX if possible In-Reply-To: <1414942122.91.0.879577274082.issue22783@psf.upfronthosting.co.za> Message-ID: <20141216180242.18149.85234@psf.io> Roundup Robot added the comment: New changeset 2ffaac4c8e53 by Serhiy Storchaka in branch 'default': Issue #22783: Pickling now uses the NEWOBJ opcode instead of the NEWOBJ_EX https://hg.python.org/cpython/rev/2ffaac4c8e53 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 19:03:09 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 16 Dec 2014 18:03:09 +0000 Subject: [issue15513] Correct __sizeof__ support for pickle In-Reply-To: <1343723739.69.0.648602242607.issue15513@psf.upfronthosting.co.za> Message-ID: <20141216180242.18149.22013@psf.io> Roundup Robot added the comment: New changeset fed774c926f5 by Serhiy Storchaka in branch '3.4': Issue #15513: Added a __sizeof__ implementation for pickle classes. https://hg.python.org/cpython/rev/fed774c926f5 New changeset e11d99ed3d3f by Serhiy Storchaka in branch 'default': Issue #15513: Added a __sizeof__ implementation for pickle classes. https://hg.python.org/cpython/rev/e11d99ed3d3f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 19:08:13 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 16 Dec 2014 18:08:13 +0000 Subject: [issue19858] Make pickletools.optimize aware of the MEMOIZE opcode. In-Reply-To: <1385946014.54.0.601831543599.issue19858@psf.upfronthosting.co.za> Message-ID: <1418753293.76.0.469042189546.issue19858@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Many thanks for all your reviews Antoine! ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 19:09:27 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 16 Dec 2014 18:09:27 +0000 Subject: [issue22783] Pickle: use NEWOBJ instead of NEWOBJ_EX if possible In-Reply-To: <1414942122.91.0.879577274082.issue22783@psf.upfronthosting.co.za> Message-ID: <1418753367.16.0.515336446278.issue22783@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 19:10:14 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 16 Dec 2014 18:10:14 +0000 Subject: [issue22777] Test pickling with all protocols In-Reply-To: <1414793093.86.0.888366361477.issue22777@psf.upfronthosting.co.za> Message-ID: <1418753414.81.0.858082200157.issue22777@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 19:14:48 2014 From: report at bugs.python.org (Marc Abramowitz) Date: Tue, 16 Dec 2014 18:14:48 +0000 Subject: [issue23063] `python setup.py check --restructuredtext --strict --metadata` fails with: `warning: check: Could not finish the parsing.` if the RST document uses code or code-block directives. In-Reply-To: <1418716685.25.0.847417973192.issue23063@psf.upfronthosting.co.za> Message-ID: <1418753688.94.0.464849754135.issue23063@psf.upfronthosting.co.za> Marc Abramowitz added the comment: OK, I added a test. See: * https://bitbucket.org/msabramo/cpython/commits/9b8f6812ff6981b5f195b6bf73cefb0fea46fba6 * https://bitbucket.org/msabramo/cpython/pull-request/1/fix-distutils-setuppy-check/diff If you want, I can also update the diff attached here, but maybe it's easier to just look at my branch on Bitbucket? Whatever is most convenient for you... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 19:16:17 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 16 Dec 2014 18:16:17 +0000 Subject: [issue23063] `python setup.py check --restructuredtext --strict --metadata` fails with: `warning: check: Could not finish the parsing.` if the RST document uses code or code-block directives. In-Reply-To: <1418716685.25.0.847417973192.issue23063@psf.upfronthosting.co.za> Message-ID: <1418753777.81.0.495656745072.issue23063@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- hgrepos: +288 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 19:16:31 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 16 Dec 2014 18:16:31 +0000 Subject: [issue23063] `python setup.py check --restructuredtext --strict --metadata` fails with: `warning: check: Could not finish the parsing.` if the RST document uses code or code-block directives. In-Reply-To: <1418716685.25.0.847417973192.issue23063@psf.upfronthosting.co.za> Message-ID: <1418753791.33.0.992521923001.issue23063@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- hgrepos: -286 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 19:16:50 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 16 Dec 2014 18:16:50 +0000 Subject: [issue23063] `python setup.py check --restructuredtext --strict --metadata` fails with: `warning: check: Could not finish the parsing.` if the RST document uses code or code-block directives. In-Reply-To: <1418716685.25.0.847417973192.issue23063@psf.upfronthosting.co.za> Message-ID: <1418753810.7.0.390802840481.issue23063@psf.upfronthosting.co.za> Changes by ?ric Araujo : Added file: http://bugs.python.org/file37471/9b8f6812ff69.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 19:17:42 2014 From: report at bugs.python.org (Marc Abramowitz) Date: Tue, 16 Dec 2014 18:17:42 +0000 Subject: [issue23063] `python setup.py check --restructuredtext --strict --metadata` fails with: `warning: check: Could not finish the parsing.` if the RST document uses code or code-block directives. In-Reply-To: <1418716685.25.0.847417973192.issue23063@psf.upfronthosting.co.za> Message-ID: <1418753862.62.0.339823636523.issue23063@psf.upfronthosting.co.za> Changes by Marc Abramowitz : Added file: http://bugs.python.org/file37472/issue23063.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 19:18:49 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 16 Dec 2014 18:18:49 +0000 Subject: [issue23063] `python setup.py check --restructuredtext --strict --metadata` fails with: `warning: check: Could not finish the parsing.` if the RST document uses code or code-block directives. In-Reply-To: <1418716685.25.0.847417973192.issue23063@psf.upfronthosting.co.za> Message-ID: <1418753929.1.0.849288600158.issue23063@psf.upfronthosting.co.za> ?ric Araujo added the comment: The Mercurial integration lets you update the patch with one click. Decentralized VCSes are nice :?) Patch looks good to me. Thank you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 19:39:08 2014 From: report at bugs.python.org (Steve Dower) Date: Tue, 16 Dec 2014 18:39:08 +0000 Subject: [issue23060] Assert fails in multiprocessing.heap.Arena.__setstate__ on Windows In-Reply-To: <1418696995.02.0.22756137648.issue23060@psf.upfronthosting.co.za> Message-ID: <1418755148.37.0.944597712753.issue23060@psf.upfronthosting.co.za> Steve Dower added the comment: That was actually my first hack and it also works. The fundamental problem here is that GetLastError() is not actually meant to indicate *whether* an error has occurred, but when one has occurred it describes what it was. Indeed, in this case no error has occurred - CreateFileMapping was called and there is a file mapping available. OpenFileMapping is provided if an error is required when the mapping does not already exist. The best option is definitely a separate method (or parameter) on mmap to open/raise rather than open/create. I may just comment out the assertion with a reference to this bug in the meantime, so that the buildbots aren't getting stuck every time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 19:41:21 2014 From: report at bugs.python.org (Marc Abramowitz) Date: Tue, 16 Dec 2014 18:41:21 +0000 Subject: [issue23063] `python setup.py check --restructuredtext --strict --metadata` fails with: `warning: check: Could not finish the parsing.` if the RST document uses code or code-block directives. In-Reply-To: <1418716685.25.0.847417973192.issue23063@psf.upfronthosting.co.za> Message-ID: <1418755281.0.0.380479004114.issue23063@psf.upfronthosting.co.za> Marc Abramowitz added the comment: What's the next step? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 20:29:14 2014 From: report at bugs.python.org (Chris Hand) Date: Tue, 16 Dec 2014 19:29:14 +0000 Subject: [issue23067] Export readline forced_update_display Message-ID: <1418758154.75.0.0731776033419.issue23067@psf.upfronthosting.co.za> New submission from Chris Hand: The current implementation of readline implements the redisplay function, but not the forced version. This patch maintains the current behavior as the default, but also allows a bool to be passed which, if True, calls rl_forced_update_display instead. ---------- components: Extension Modules files: readline_redisplay_force.patch keywords: patch messages: 232757 nosy: dexteradeus priority: normal severity: normal status: open title: Export readline forced_update_display type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file37473/readline_redisplay_force.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 20:29:54 2014 From: report at bugs.python.org (Joe Cabrera) Date: Tue, 16 Dec 2014 19:29:54 +0000 Subject: [issue23054] ConnectionError: ('Connection aborted.', BadStatusLine(""''''")) In-Reply-To: <1418654943.54.0.176050651858.issue23054@psf.upfronthosting.co.za> Message-ID: <1418758194.0.0.102659125226.issue23054@psf.upfronthosting.co.za> Joe Cabrera added the comment: This is an error wrapping coming from requests. https://github.com/kennethreitz/requests/issues/2364 The Requests team has concluded they can do nothing about this error, I believe the next step up is the python httplib library. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 20:42:32 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 16 Dec 2014 19:42:32 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <1418737132.92.0.582001607945.issue22980@psf.upfronthosting.co.za> Message-ID: <54908B23.3080109@egenix.com> Marc-Andre Lemburg added the comment: On 16.12.2014 14:38, Steve Dower wrote: > > Steve Dower added the comment: > > I justified leaving out the ABI tag in an earlier post as well as in an email to distutils-sig, where two of the PEPs you mention were developed, and nobody had any comment. Cache tags don't include platform information and are worthless here. I was referring to ABI flags (https://www.python.org/dev/peps/pep-0425/#abi-tag), eg. the "m" when using pymalloc. If we do stick with a PEP 425 format, we should at least stay compatible to it - even if we don't necessarily need this on Windows. On Linux, the extensions use the PEP 3149 tags, e.g. readline.cpython-34m.so Wouldn't it make sense to change those to the same PEP 425 style format ? Exmaple: readline.cp35m-linux-x86_64.so The "_d" suffix on Windows would then turn into the "d" ABI flag. Note that this only works nicely for Linux. For other platforms, get_platform() returns a mess... e.g. on FreeBSD: freebsd-8.3-RELEASE-p3-i386 (32-bit) freebsd-8.3-RELEASE-p3-amd64 (64-bit) instead of the more useful freebsd-i386 freebsd-amd64 The situation is similar on other less main stream platforms, so it may make sense to define mappings other than get_platform() on those. > distutils uses the first extension from _imp.extension_suffixes() and so will automatically tag binaries. I also tested with setuptools and Cython. Ah, clever. So no additional patches are needed :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 20:48:50 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 16 Dec 2014 19:48:50 +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: <1418759330.95.0.607900200981.issue22980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: get_platform() will be difficult to reuse, for bootstrapping reasons (you need to know the allowed extensions as soon as the interpreter starts up, or at least as soon as the first extension module may be loaded). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 21:11:17 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 16 Dec 2014 20:11:17 +0000 Subject: [issue23054] ConnectionError: ('Connection aborted.', BadStatusLine(""''''")) In-Reply-To: <1418654943.54.0.176050651858.issue23054@psf.upfronthosting.co.za> Message-ID: <1418760677.87.0.473254724609.issue23054@psf.upfronthosting.co.za> R. David Murray added the comment: I wonder the actual error reported in that issue has any relationship to issue 15082? In any case, the error being presented to requests is *accurate*: httplib tried to read the status line and got nothing (the actual text in the linked issue is BadStatusLine("''")). (Note that issue 7427 was where we fixed the repr, if you are curious). I see that requests would like "a better error message". Is there a concrete suggestion for what that better error message would look like? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 21:15:39 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 16 Dec 2014 20:15:39 +0000 Subject: [issue23049] Fix functools.reduce code equivalent. In-Reply-To: <1418516847.13.0.26860108886.issue23049@psf.upfronthosting.co.za> Message-ID: <1418760939.47.0.295170735902.issue23049@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I agree with Raymond. Examples in the code are not meant to be a reference but, well, examples. That is, the educational value should come first and strict adherence to the language spec only second. "Roughly equivalent" is already used in the functools doc, it can probably be reused :-) ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 21:27:24 2014 From: report at bugs.python.org (Martin Panter) Date: Tue, 16 Dec 2014 20:27:24 +0000 Subject: [issue23054] ConnectionError: ('Connection aborted.', BadStatusLine(""''''")) In-Reply-To: <1418654943.54.0.176050651858.issue23054@psf.upfronthosting.co.za> Message-ID: <1418761644.91.0.515271094091.issue23054@psf.upfronthosting.co.za> Martin Panter added the comment: Not exactly sure what do you want the Python library to do, but perhaps this is a duplicate of Issue 8450, about making the error less misleading when the connection is closed before _any_ status line is sent. See also Issue 7427. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 21:28:19 2014 From: report at bugs.python.org (Steve Dower) Date: Tue, 16 Dec 2014 20:28:19 +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: <1418761699.1.0.0259430870894.issue22980@psf.upfronthosting.co.za> Steve Dower added the comment: > get_platform() will be difficult to reuse, for bootstrapping reasons ISTM that if you can't determine the value at compile time, then it doesn't matter to compilation enough to need to appear in the tag. As far as matching PEP 425 for the sake of matching it goes, I'd rather keep using search path tricks than have ".cp35-cp35m-win_amd64.pyd" appear on every single one of my extension modules. Removing the "_d" suffix is very likely more disruptive than it's worth, especially since untagged pyds are still supported but the debug tag is still necessary. 'm' is always the case in Windows and is benign for a correct extension anyway, and AFAICT 'u' is totally unused. ---------- _______________________________________ Python tracker _______________________________________ From mal at egenix.com Tue Dec 16 22:26:47 2014 From: mal at egenix.com (M.-A. Lemburg) Date: Tue, 16 Dec 2014 22:26:47 +0100 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <1418761699.1.0.0259430870894.issue22980@psf.upfronthosting.co.za> References: <1418761699.1.0.0259430870894.issue22980@psf.upfronthosting.co.za> Message-ID: <5490A397.9020803@egenix.com> On 16.12.2014 21:28, Steve Dower wrote: > > Steve Dower added the comment: > >> get_platform() will be difficult to reuse, for bootstrapping reasons > > ISTM that if you can't determine the value at compile time, then it doesn't matter to compilation enough to need to appear in the tag. Antoine has a point there. Together with the problems I mentioned with non-mainstream platforms, it would be better to use a compile time definition of the platform tag as you've chosen for Windows. PEP 425 unfortunately ignores the mentioned problems of get_platform(). > As far as matching PEP 425 for the sake of matching it goes, I'd rather keep using search path tricks than have ".cp35-cp35m-win_amd64.pyd" appear on every single one of my extension modules. Removing the "_d" suffix is very likely more disruptive than it's worth, especially since untagged pyds are still supported but the debug tag is still necessary. 'm' is always the case in Windows and is benign for a correct extension anyway, and AFAICT 'u' is totally unused. You may have misread my comment. There's no need to add the Python tag to the extension tag, only the ABI tag (with flags) and the platform tag to determine bitness: spam.cp35m-win_amd64.pyd Could you explain what replacing the _d suffix with a "d" ABI flag would break ? To be clear, this would mean: spam.cp35dm-win_amd64.pyd instead of spam_d.cp35m-win_amd64.pyd -- Marc-Andre Lemburg eGenix.com From report at bugs.python.org Tue Dec 16 22:26:51 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 16 Dec 2014 21:26:51 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <1418761699.1.0.0259430870894.issue22980@psf.upfronthosting.co.za> Message-ID: <5490A397.9020803@egenix.com> Marc-Andre Lemburg added the comment: On 16.12.2014 21:28, Steve Dower wrote: > > Steve Dower added the comment: > >> get_platform() will be difficult to reuse, for bootstrapping reasons > > ISTM that if you can't determine the value at compile time, then it doesn't matter to compilation enough to need to appear in the tag. Antoine has a point there. Together with the problems I mentioned with non-mainstream platforms, it would be better to use a compile time definition of the platform tag as you've chosen for Windows. PEP 425 unfortunately ignores the mentioned problems of get_platform(). > As far as matching PEP 425 for the sake of matching it goes, I'd rather keep using search path tricks than have ".cp35-cp35m-win_amd64.pyd" appear on every single one of my extension modules. Removing the "_d" suffix is very likely more disruptive than it's worth, especially since untagged pyds are still supported but the debug tag is still necessary. 'm' is always the case in Windows and is benign for a correct extension anyway, and AFAICT 'u' is totally unused. You may have misread my comment. There's no need to add the Python tag to the extension tag, only the ABI tag (with flags) and the platform tag to determine bitness: spam.cp35m-win_amd64.pyd Could you explain what replacing the _d suffix with a "d" ABI flag would break ? To be clear, this would mean: spam.cp35dm-win_amd64.pyd instead of spam_d.cp35m-win_amd64.pyd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 23:29:23 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 16 Dec 2014 22:29:23 +0000 Subject: [issue23054] ConnectionError: ('Connection aborted.', BadStatusLine(""''''")) In-Reply-To: <1418654943.54.0.176050651858.issue23054@psf.upfronthosting.co.za> Message-ID: <1418768963.66.0.530087897115.issue23054@psf.upfronthosting.co.za> R. David Murray added the comment: Ouch. I assumed the change was made to the repr, not the contents of line (I wasn't involved in that fix). Not that that would actually affect this issue, I think, since Requests doesn't want to "introspect exception objects". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 23:34:55 2014 From: report at bugs.python.org (Martin Panter) Date: Tue, 16 Dec 2014 22:34:55 +0000 Subject: [issue16349] Document whether it's safe to use bytes for struct format string In-Reply-To: <1351428222.6.0.656645524198.issue16349@psf.upfronthosting.co.za> Message-ID: <1418769295.36.0.70958096855.issue16349@psf.upfronthosting.co.za> Martin Panter added the comment: Actually the ?struct? module doc string seems to already hint that format strings can be byte strings: ?Python bytes objects are used to hold the data representing the C struct and also as format strings . . .? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 16 23:57:16 2014 From: report at bugs.python.org (Martin Panter) Date: Tue, 16 Dec 2014 22:57:16 +0000 Subject: [issue21071] struct.Struct.format is bytes, but should be str In-Reply-To: <1395856133.5.0.672707015318.issue21071@psf.upfronthosting.co.za> Message-ID: <1418770636.35.0.11657145904.issue21071@psf.upfronthosting.co.za> Martin Panter added the comment: It seems to me that the simplest fix is to document: 1. Struct.format attribute is a byte string 2. The input format strings for struct.pack(), Struct class, etc, are also allowed to be byte strings, for consistency (Issue 16349) Here is a patch that does that, and adds some simple test cases. ---------- keywords: +patch Added file: http://bugs.python.org/file37474/format-bytes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 00:29:00 2014 From: report at bugs.python.org (Martijn Pieters) Date: Tue, 16 Dec 2014 23:29:00 +0000 Subject: [issue17876] Doc issue with threading.Event In-Reply-To: <1367301985.85.0.51301072011.issue17876@psf.upfronthosting.co.za> Message-ID: <1418772540.96.0.514453020385.issue17876@psf.upfronthosting.co.za> Martijn Pieters added the comment: I notice that the same issue still exists in the 3.5 documentation. Surely this can at least be fixed in the development copy? ---------- nosy: +mjpieters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 00:43:58 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 16 Dec 2014 23:43:58 +0000 Subject: [issue23057] asyncio loop on Windows should stop on keyboard interrupt In-Reply-To: <1418674256.87.0.827009141117.issue23057@psf.upfronthosting.co.za> Message-ID: <1418773438.73.0.420354511139.issue23057@psf.upfronthosting.co.za> STINNER Victor added the comment: Hi, I started to work on this topic a few months ago: https://code.google.com/p/tulip/issues/detail?id=191 I should update my patches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 00:45:12 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 16 Dec 2014 23:45:12 +0000 Subject: [issue23046] asyncio.BaseEventLoop is documented, but only exported via asyncio.base_events In-Reply-To: <1418454792.43.0.104807870648.issue23046@psf.upfronthosting.co.za> Message-ID: <1418773512.19.0.835345974183.issue23046@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm in favor of exposing BaseEventLoop in the asyncio namespace directly (asyncio.BaseEventLoop) because I'm using it in various asyncio projects, and I don't like having to use submodules. I consider asyncio.base_events as the private API. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 00:46:45 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 16 Dec 2014 23:46:45 +0000 Subject: [issue23057] asyncio loop on Windows should stop on keyboard interrupt In-Reply-To: <1418674256.87.0.827009141117.issue23057@psf.upfronthosting.co.za> Message-ID: <1418773605.27.0.634764496416.issue23057@psf.upfronthosting.co.za> STINNER Victor added the comment: This issue is specific to Windows. On all others platforms, signal handling is nicely supported. ---------- components: +Windows nosy: +steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 00:48:12 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 16 Dec 2014 23:48:12 +0000 Subject: [issue17876] Doc issue with threading.Event In-Reply-To: <1367301985.85.0.51301072011.issue17876@psf.upfronthosting.co.za> Message-ID: <1418773692.23.0.442691171542.issue17876@psf.upfronthosting.co.za> R. David Murray added the comment: If there really is an issue in the 3.4/3.5 docs, you should open an new issue explaining what the problem is. In 3.4/3.5, Event is a class, not a function, and is documented accordingly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 00:48:40 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 16 Dec 2014 23:48:40 +0000 Subject: [issue22926] asyncio: raise an exception when called from the wrong thread In-Reply-To: <1416760694.74.0.749180510867.issue22926@psf.upfronthosting.co.za> Message-ID: <1418773720.59.0.919194502637.issue22926@psf.upfronthosting.co.za> STINNER Victor added the comment: Guido wrote: > I'm okay with this approach now. I'm not sure that I understood your opinion. Are you ok to raise an exception in debug mode if call_soon() is called from a thread which has no event loop attached? (Currently, an exception is already raised in debug mode, but only if the thread has an attached event loop, but not the good one.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 00:49:47 2014 From: report at bugs.python.org (Martijn Pieters) Date: Tue, 16 Dec 2014 23:49:47 +0000 Subject: [issue17876] Doc issue with threading.Event In-Reply-To: <1367301985.85.0.51301072011.issue17876@psf.upfronthosting.co.za> Message-ID: <1418773787.78.0.484746926933.issue17876@psf.upfronthosting.co.za> Martijn Pieters added the comment: Ah! Mea Culpa, you are correct. The issue is then with Python 2.7 only for which no doubt exists a separate ticket. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 00:51:31 2014 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 16 Dec 2014 23:51:31 +0000 Subject: [issue23046] asyncio.BaseEventLoop is documented, but only exported via asyncio.base_events In-Reply-To: <1418773512.19.0.835345974183.issue23046@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: OK, fine to expose the BaseEventLoop class. On Tue, Dec 16, 2014 at 3:45 PM, STINNER Victor wrote: > > > STINNER Victor added the comment: > > I'm in favor of exposing BaseEventLoop in the asyncio namespace directly > (asyncio.BaseEventLoop) because I'm using it in various asyncio projects, > and I don't like having to use submodules. I consider asyncio.base_events > as the private API. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 00:53:31 2014 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 16 Dec 2014 23:53:31 +0000 Subject: [issue22926] asyncio: raise an exception when called from the wrong thread In-Reply-To: <1418773720.59.0.919194502637.issue22926@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Well, the PEP clearly states that get_event_loop() should never return None and raise an exception if the context has no environment. (Where context ~~ thread.) On Tue, Dec 16, 2014 at 3:48 PM, STINNER Victor wrote: > > > STINNER Victor added the comment: > > Guido wrote: > > I'm okay with this approach now. > > I'm not sure that I understood your opinion. Are you ok to raise an > exception in debug mode if call_soon() is called from a thread which has no > event loop attached? > > (Currently, an exception is already raised in debug mode, but only if the > thread has an attached event loop, but not the good one.) > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 00:56:17 2014 From: report at bugs.python.org (STINNER Victor) Date: Tue, 16 Dec 2014 23:56:17 +0000 Subject: [issue22922] asyncio: call_soon() should raise an exception if the event loop is closed In-Reply-To: <1416735123.89.0.671272792173.issue22922@psf.upfronthosting.co.za> Message-ID: <1418774177.97.0.991166340542.issue22922@psf.upfronthosting.co.za> STINNER Victor added the comment: > Windows buildbots are not happy: test_asyncio pass again on Windows buildbots, I close the issue. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 01:13:38 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 17 Dec 2014 00:13:38 +0000 Subject: [issue23009] selectors.EpollSelector.select raises exception when nothing to select. In-Reply-To: <1418035005.39.0.294462650059.issue23009@psf.upfronthosting.co.za> Message-ID: <20141217001255.80981.93626@psf.io> Roundup Robot added the comment: New changeset 1e985daa7be6 by Victor Stinner in branch 'default': Issue #23009: Skip test_selectors.test_empty_select() on Windows https://hg.python.org/cpython/rev/1e985daa7be6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 01:17:28 2014 From: report at bugs.python.org (Demian Brecht) Date: Wed, 17 Dec 2014 00:17:28 +0000 Subject: [issue14134] xmlrpc.client.ServerProxy needs timeout parameter In-Reply-To: <1330294741.21.0.00592117933576.issue14134@psf.upfronthosting.co.za> Message-ID: <1418775448.92.0.528808090168.issue14134@psf.upfronthosting.co.za> Demian Brecht added the comment: I think we've started to venture into system-level territory that the standard library itself shouldn't have to account for. If TCP on systems are configured by default to allow for infinite timeouts, then it should likely be an issue for those distros. I don't think accounting for such things should be the responsibility of the standard library. The socket module behaves appropriately in handing off timeouts to be managed by the system level if left undefined. I think that any further discussion around timeouts should be taken up on distro mailing lists, or even perhaps python-list as it's not directly relevant to this issue. As for this specific issue, unless someone beats me to it, I'll get a patch together introducing the session_factory as soon as I can. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 01:17:54 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 17 Dec 2014 00:17:54 +0000 Subject: [issue23046] asyncio.BaseEventLoop is documented, but only exported via asyncio.base_events In-Reply-To: <1418454792.43.0.104807870648.issue23046@psf.upfronthosting.co.za> Message-ID: <1418775474.65.0.0212569640767.issue23046@psf.upfronthosting.co.za> STINNER Victor added the comment: Here is a patch to expose BaseEventLoop. It removes Server from base_events.__all__, which means that "from asyncio.base_events import *" will no import Server anymore. Can it break real applications? ---------- keywords: +patch Added file: http://bugs.python.org/file37475/base_event_loop.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 01:21:17 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 17 Dec 2014 00:21:17 +0000 Subject: [issue22926] asyncio: raise an exception when called from the wrong thread In-Reply-To: Message-ID: STINNER Victor added the comment: 2014-12-17 0:53 GMT+01:00 Guido van Rossum : > Well, the PEP clearly states that get_event_loop() should never return None > and raise an exception if the context has no environment. (Where context ~~ > thread.) You don't reply to my question, or I misunderstood your anwer. call_soon() is a method an event loop, there is no need to call get_event_loop(). get_event_loop() is only called in debug mode to help the developer to detect obvious bugs. I don't think that the behaviour of the debug mode must be written in the PEP, it's more implementation specific. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 01:21:40 2014 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 17 Dec 2014 00:21:40 +0000 Subject: [issue23046] asyncio.BaseEventLoop is documented, but only exported via asyncio.base_events In-Reply-To: <1418775474.65.0.0212569640767.issue23046@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Sounds unlikely. If they write "from asyncio.base_events import Server" it will still work. Only if they wrote "from asyncio.base_events import *" will they be broken, and that sounds not worth worrying about. So LGTM on the patch. (But why was Server there at all? Tests? On Tue, Dec 16, 2014 at 4:17 PM, STINNER Victor wrote: > > > STINNER Victor added the comment: > > Here is a patch to expose BaseEventLoop. It removes Server from > base_events.__all__, which means that "from asyncio.base_events import *" > will no import Server anymore. Can it break real applications? > > ---------- > keywords: +patch > Added file: http://bugs.python.org/file37475/base_event_loop.patch > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 01:24:03 2014 From: report at bugs.python.org (Demian Brecht) Date: Wed, 17 Dec 2014 00:24:03 +0000 Subject: [issue14134] xmlrpc.client.ServerProxy needs timeout parameter In-Reply-To: <1330294741.21.0.00592117933576.issue14134@psf.upfronthosting.co.za> Message-ID: <1418775843.28.0.176893081916.issue14134@psf.upfronthosting.co.za> Demian Brecht added the comment: On another note, running a simple test with against a non-routable IP yields that OSX's default timeout is 75 seconds and not 7500 seconds as the developer docs lead me to believe. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 01:27:58 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 17 Dec 2014 00:27:58 +0000 Subject: [issue23046] asyncio.BaseEventLoop is documented, but only exported via asyncio.base_events In-Reply-To: Message-ID: STINNER Victor added the comment: > why was Server there at all? Tests? If you cannot answer, who can answer? :-) https://code.google.com/p/tulip/source/detail?r=f136c04d82c0 (You added Server to __all__.) I don't see any use case which needs to create explicitly a Server class. There are the create_server() method and start_server() function for that. By the way, the Server class *is* documented as asyncio.Server, which is the same mistake than asyncio.BaseEventLoop: https://docs.python.org/dev/library/asyncio-eventloop.html#asyncio.Server I propose to update the doc for Server, replace asyncio.Server with asyncio.base_events.Server. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 01:31:25 2014 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 17 Dec 2014 00:31:25 +0000 Subject: [issue22926] asyncio: raise an exception when called from the wrong thread In-Reply-To: Message-ID: Guido van Rossum added the comment: Oh sorry. I'm in too much of a hurry. :-( The problem is that the thread may not have a loop, but the loop still has a tread. E.g. the tests intentionally call set_event_loop(None) to make sure that no code depends on the implict event loop. An app should be allowed to do the same, even in debug mode. IIUC this is already broken in debug mode? (Or perhaps only in non-main threads?) So in order to do correct diagnostics here we would have to add an "owning thread" pointer to every event loop; then call_later() and friends can check that the owning thread is the same as the current thread. But I'm not sure that this is worth the work. (And I could see issues with the owning thread concept as well.) On Tue, Dec 16, 2014 at 4:21 PM, STINNER Victor wrote: > > > STINNER Victor added the comment: > > 2014-12-17 0:53 GMT+01:00 Guido van Rossum : > > Well, the PEP clearly states that get_event_loop() should never return > None > > and raise an exception if the context has no environment. (Where context > ~~ > > thread.) > > You don't reply to my question, or I misunderstood your anwer. > call_soon() is a method an event loop, there is no need to call > get_event_loop(). get_event_loop() is only called in debug mode to > help the developer to detect obvious bugs. I don't think that the > behaviour of the debug mode must be written in the PEP, it's more > implementation specific. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 01:39:30 2014 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 17 Dec 2014 00:39:30 +0000 Subject: [issue23046] asyncio.BaseEventLoop is documented, but only exported via asyncio.base_events In-Reply-To: Message-ID: Guido van Rossum added the comment: Heh. Well I don't remember why I did that any more, and it doesn't seem to matter now. However the doc issue seems different than for BaseEventLoop -- Server is the *concrete* class (it actually gets instantiated, not a subclass). We could instead document the AbstractServer class, but it doesn't have the 'sockets' instance variable. Maybe we should document both -- AbstractServer as the minimal interface that create_server() returns, Server as the actual class that the default event loops (Unix and Windows) create. With a warning that 'sockets' attribute may not be available if the event loop has been configured differently. On Tue, Dec 16, 2014 at 4:27 PM, STINNER Victor wrote: > > > STINNER Victor added the comment: > > > why was Server there at all? Tests? > > If you cannot answer, who can answer? :-) > https://code.google.com/p/tulip/source/detail?r=f136c04d82c0 (You > added Server to __all__.) > > I don't see any use case which needs to create explicitly a Server > class. There are the create_server() method and start_server() > function for that. > > By the way, the Server class *is* documented as asyncio.Server, which > is the same mistake than asyncio.BaseEventLoop: > https://docs.python.org/dev/library/asyncio-eventloop.html#asyncio.Server > > I propose to update the doc for Server, replace asyncio.Server with > asyncio.base_events.Server. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 02:13:20 2014 From: report at bugs.python.org (Martin Panter) Date: Wed, 17 Dec 2014 01:13:20 +0000 Subject: [issue16776] Document PyCFunction_New and PyCFunction_NewEx functions In-Reply-To: <1356434154.16.0.0981038830976.issue16776@psf.upfronthosting.co.za> Message-ID: <1418778800.17.0.108259002635.issue16776@psf.upfronthosting.co.za> Martin Panter added the comment: I?m far from an expert on the C API, but I was looking for a way to inspect a ?builtin_function_or_method? a.k.a. PyCFunction_Type a.k.a. types.BuiltinMethodType, and ended up looking at the ?Instance Method Objects? section. So maybe your functions should go near there, or perhaps the nearby ?Function Objects? section. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 02:33:51 2014 From: report at bugs.python.org (Eric Snow) Date: Wed, 17 Dec 2014 01:33:51 +0000 Subject: [issue23014] Don't have importlib.abc.Loader.create_module() be optional In-Reply-To: <1418055538.78.0.471721917483.issue23014@psf.upfronthosting.co.za> Message-ID: <1418780031.09.0.189198849531.issue23014@psf.upfronthosting.co.za> Eric Snow added the comment: @Nick As long as those esoteric cases can be handled without much work via create_module and exec_module, we should have a goal in mind for yanking legacy load_module support. If there are valid use cases that can't be handled via PEP 451 then I'd say we should consider finding a better way. If Loader.load_module is that better way then we need to consider a better way to handle it. What cases do you have in mind that only load_module handles (at least easily)? I can vaguely imagine the circumstances, but nothing concrete comes to mind. It doesn't seem like the sort of situation that has come up more that a handful of times nor one the currently couldn't be addressed in another way. I'm probably missing something here and I wouldn't be surprised if we discussed this point during the PEP 451 discussions. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 02:36:43 2014 From: report at bugs.python.org (Eric Snow) Date: Wed, 17 Dec 2014 01:36:43 +0000 Subject: [issue23014] Don't have importlib.abc.Loader.create_module() be optional In-Reply-To: <1418055538.78.0.471721917483.issue23014@psf.upfronthosting.co.za> Message-ID: <1418780203.42.0.7697802022.issue23014@psf.upfronthosting.co.za> Eric Snow added the comment: @Brett Discussing this at PyCon sounds good. I'm in favor of dropping load_module as soon as possible (if possible), as you might have guessed by the way I implemented the module spec code. :) I agree that we should make a decision about load_module one way or the other, as either way we can consequently clean up that code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 02:48:57 2014 From: report at bugs.python.org (Martin Panter) Date: Wed, 17 Dec 2014 01:48:57 +0000 Subject: [issue19176] DeprecationWarning for doctype() method when subclassing _elementtree.XMLParser In-Reply-To: <1381041750.41.0.637077946349.issue19176@psf.upfronthosting.co.za> Message-ID: <1418780937.46.0.138596380307.issue19176@psf.upfronthosting.co.za> Martin Panter added the comment: Since the doctype() method doesn?t appear to be removed from the ?default? (3.5?) branch either, here is a patch that avoids the deprecation warning when inheriting method + a test. Hopefully this will be useful when you get some time to look at it. I?m not sure if the PyCFunction_ calls are a good idea; they don?t seem to be documented, but I couldn?t think of a better way to check if the method was overridden. ---------- keywords: +patch versions: +Python 3.5 Added file: http://bugs.python.org/file37476/inherit-doctype.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 03:14:37 2014 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 17 Dec 2014 02:14:37 +0000 Subject: [issue23068] Add a way to determine if the current thread has the import lock Message-ID: <1418782477.87.0.643327890289.issue23068@psf.upfronthosting.co.za> New submission from Guido van Rossum: imp.lock_held() returns True if *any* thread is currently importing something. I'd like to have an API that can tell whether the *current* thread has the import lock. The implementation keeps track of this, but doesn't make the info available. Use case: print a warning/error if a network call is made during import. ---------- components: Library (Lib) messages: 232792 nosy: gvanrossum priority: normal severity: normal stage: needs patch status: open title: Add a way to determine if the current thread has the import lock type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 03:15:20 2014 From: report at bugs.python.org (Martin Panter) Date: Wed, 17 Dec 2014 02:15:20 +0000 Subject: [issue634412] RFC 2387 (multipart/related) in email package Message-ID: <1418782520.66.0.99996109961.issue634412@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- title: RFC 2387 in email package -> RFC 2387 (multipart/related) in email package _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 03:17:32 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 17 Dec 2014 02:17:32 +0000 Subject: [issue23049] Fix functools.reduce code equivalent. In-Reply-To: <1418516847.13.0.26860108886.issue23049@psf.upfronthosting.co.za> Message-ID: <20141217021724.92271.92861@psf.io> Roundup Robot added the comment: New changeset 0b3d69f15950 by Raymond Hettinger in branch '3.4': Issue #23049: Pure python equivalent shouldn't imply more exactitude than is really there. https://hg.python.org/cpython/rev/0b3d69f15950 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 03:17:55 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 17 Dec 2014 02:17:55 +0000 Subject: [issue23049] Fix functools.reduce code equivalent. In-Reply-To: <1418516847.13.0.26860108886.issue23049@psf.upfronthosting.co.za> Message-ID: <1418782675.2.0.42880658892.issue23049@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 03:30:30 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 17 Dec 2014 02:30:30 +0000 Subject: [issue23069] IDLE's F5 Run Module doesn't transfer effects of future import Message-ID: <1418783430.85.0.171264628982.issue23069@psf.upfronthosting.co.za> New submission from Raymond Hettinger: Future imports in a module aren't transferring to the interactive shell when executing Run Module. Given the file tmp_future.py ---------------------------- $ cat tmp_future.py from __future__ import division, print_function print(32 / 5) Run Python interactively ------------------------ $ python2.7 -i tmp_future.py 6.4 >>> 32 / 5 # this works fine! 6.4 But open the file in IDLE and press F5: --------------------------------------- Python 2.7.9 (v2.7.9:648dcafa7e5f, Dec 10 2014, 10:10:46) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "copyright", "credits" or "license()" for more information. >>> ================================ RESTART ================================ >>> 6.4 >>> print(32 / 5) # this is broken! 6 Note, the problem may also apply to IDLE Python 3.4 and 3.5 but it won't affect this example because the future imports have not effect. ---------- components: IDLE files: tmp_future.py messages: 232794 nosy: rhettinger priority: normal severity: normal stage: needs patch status: open title: IDLE's F5 Run Module doesn't transfer effects of future import type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file37477/tmp_future.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 03:51:07 2014 From: report at bugs.python.org (Ross Burnett) Date: Wed, 17 Dec 2014 02:51:07 +0000 Subject: [issue23070] Error in Tutorial comment Message-ID: <1418784667.28.0.75679477956.issue23070@psf.upfronthosting.co.za> New submission from Ross Burnett: In section "3.1.2. Strings" of the Tutorial (version 3.4 plus others?), a comment on a slicing error has an error: "word[42] # the word only has 7 characters" It should say "word[42] # the word has 6 characters" ---------- assignee: docs at python components: Documentation messages: 232795 nosy: docs at python, rossburnett priority: normal severity: normal status: open title: Error in Tutorial comment versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 03:51:42 2014 From: report at bugs.python.org (Martin Panter) Date: Wed, 17 Dec 2014 02:51:42 +0000 Subject: [issue19737] Documentation of globals() and locals() should be improved In-Reply-To: <1385225461.09.0.671908077084.issue19737@psf.upfronthosting.co.za> Message-ID: <1418784702.15.0.263122013714.issue19737@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch with my suggestion. It also now refers to _the_ dictionary rather than just _a_ dictionary, and drops the word ?current?, so that it does not sound like saving a snapshot. ---------- keywords: +patch Added file: http://bugs.python.org/file37478/globals-copy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 03:53:41 2014 From: report at bugs.python.org (Martin Panter) Date: Wed, 17 Dec 2014 02:53:41 +0000 Subject: [issue19737] Documentation of globals() and locals() should be improved In-Reply-To: <1385225461.09.0.671908077084.issue19737@psf.upfronthosting.co.za> Message-ID: <1418784821.37.0.632881332226.issue19737@psf.upfronthosting.co.za> Changes by Martin Panter : Added file: http://bugs.python.org/file37479/globals-copy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 03:53:53 2014 From: report at bugs.python.org (Martin Panter) Date: Wed, 17 Dec 2014 02:53:53 +0000 Subject: [issue19737] Documentation of globals() and locals() should be improved In-Reply-To: <1385225461.09.0.671908077084.issue19737@psf.upfronthosting.co.za> Message-ID: <1418784833.28.0.824899560222.issue19737@psf.upfronthosting.co.za> Changes by Martin Panter : Removed file: http://bugs.python.org/file37478/globals-copy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 05:03:48 2014 From: report at bugs.python.org (Martin Panter) Date: Wed, 17 Dec 2014 04:03:48 +0000 Subject: [issue20059] Inconsistent urlparse/urllib.parse handling of invalid port values? In-Reply-To: <1387842710.57.0.78188368243.issue20059@psf.upfronthosting.co.za> Message-ID: <1418789028.15.0.814790104172.issue20059@psf.upfronthosting.co.za> Martin Panter added the comment: I would go for raising ValueError for port numbers out of range. The value of None was already defined to mean that no port is included in the URL. Also, the ValueError exception should be documented. It is surprising that urlsplit() does not raise any exception, but then simply getting the ?port? attribute does raise the exception. BTW your third example is wrong: >>> urlparse("http://www.example.com:").port is None True It?s probably safest to keep this one as it is, but maybe it also needs documenting :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 05:18:32 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 17 Dec 2014 04:18:32 +0000 Subject: [issue16893] Generate Idle help from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <1418789912.1.0.390363972019.issue16893@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The goal of this issue is that Idle -> Help -> IDLE Help display a good-looking, accurate help page based on Doc/library/idle.rst. The current Lib/idlelib/help.txt is neither good-looking nor accurate and must somehow be replaced, even if by temporary means, before another release (2.7.9 was missed, 3.4.3 is coming in January). Ned's gave some comments on the alternatives in msg185726. I am extending those (and in some places implicitly referring back to them) based on further thinking and investigation. A summary of what I currently think might be best: if Windows: open .chm to Idle page else: try: open offline docs to Idle page except failure: open generated .txt without `s. The easiest alternative would be to display the online python.org page in a browser. It looks nice, has a sidebar index, and access to the rest of the docs. An obvious problem is that this requires a browser and online access, either of which might be lacking in a classroom or when one is away from home base. More subtle is that Idle features can be changed or added at any time. The online docs, generated daily from the repository, should reflect the repository version of Idle. Released versions need a doc frozen at the time of release. Still easy, perhaps, would be building Doc/build/html/library/idle.html and copying it to idlelib/help.html as part of the release process*, and changing the code to display that instead However as Zack hinted ("clean up the output a bit"), this file is not a standalone file. It has many links to files in '..', such as "Index" and "Copyright"; these would have to be removed completely as the text is useless without the link. For cross-reference link, such as 'Tkinter' or 'sys.path', the text should be left but the linkage removed. In both cases, clicking the link gives a File not Found page. The broken links to javascript formatting files in '../.source' appears to be ignored and the formatting simply not done. So the page index is at the bottom of the page instead of the sidebar. * The beginners who most need the help doc are running installed Python, not respository builds, so the latter concerns me less. But why make an off-line page when there already is one in off-line docs? I presume that the linux and osx doc urls just need 'index.html' replaced with '/library/idle.html'. The 'standard location' for linux is x.y.z specific. The python2 rpm location does not seem to be. The osx location I will not guess about. For Windows, startfile('x.chm') does the same as double-clicking x.chm in Explorer, which is to open the file with the Help Control, with a nice sidebar for contents, index, search, and favorites. Adding "::/library/idle.html" does not work because it makes the path invalid. But with an special prefix >>> os.startfile("mk:@MSITStore:c:/programs/Python34/Doc/python342.chm::/library/idle.html") opens the page in InternetExplorer. However, there is no sidebar and the page has to be clicked on the taskbar to make it visible. In 1 of 4 tries, the above failed. An answer to this StackOverflow question https://stackoverflow.com/questions/11076952/open-chm-file-at-specific-page-topic-using-command-line-arguments?rq=1 prompted me to try >>> subprocess.Popen("hh ms-its:c:/programs/Python34/Doc/python342.chm::/library/idle.html") This opens the chm doc with the help control (and sidebar) to the Idle page, just as I wanted. Since Doc/pythonxyz.chm is part of the installation, I think this is the solution for Windows. The one glitch is that testing that the exact code in the repository works needs to be done with a pre-final install. That is already true of testing that "Help -> Python docs F1" opens the .chm to the index page. These both should be part of a new installed idle test file. After generating html.txt from idle.rst, the backticks could be filtered out. It would be close to what we have now. Is there any need to keep it as a backup for non-Windows systems? If not, I would be inclined to delete it. For repository builds, users could go to the online Idle page. I might even look for ../../Misc and if present, open it directly. That page would be at most a day out of date. ---------- assignee: -> terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 05:28:13 2014 From: report at bugs.python.org (Martin Panter) Date: Wed, 17 Dec 2014 04:28:13 +0000 Subject: [issue18828] urljoin behaves differently with custom and standard schemas In-Reply-To: <1377435120.2.0.153064775964.issue18828@psf.upfronthosting.co.za> Message-ID: <1418790493.86.0.711752495988.issue18828@psf.upfronthosting.co.za> Martin Panter added the comment: I think a global registry seems like overkill. Here is a patch to make urljoin() treat schemes more equally and work with arbitrary schemes automatically. I haven?t heard any arguments against this option yet, and it didn?t break any tests. Another option, still simpler than a registry, would be an extra parameter, say urljoin(a, b, any_scheme=True). ---------- keywords: +patch Added file: http://bugs.python.org/file37480/urljoin-scheme.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 05:53:33 2014 From: report at bugs.python.org (Martin Panter) Date: Wed, 17 Dec 2014 04:53:33 +0000 Subject: [issue23071] codecs.__all__ incomplete Message-ID: <1418792013.22.0.617617600077.issue23071@psf.upfronthosting.co.za> New submission from Martin Panter: First ones I noticed were codecs.encode() and codecs.decode(). Here is a list of other candidates, although they are not all documented, so maybe should not all be in __all__. >>> import codecs >>> public = (a for a in dir(codecs) if not a.startswith("_")) >>> sorted(set(public).difference(codecs.__all__)) ['BufferedIncrementalDecoder', 'BufferedIncrementalEncoder', 'Codec', 'CodecInfo', 'IncrementalDecoder', 'IncrementalEncoder', 'StreamReader', 'StreamReaderWriter', 'StreamRecoder', 'StreamWriter', 'ascii_decode', 'ascii_encode', 'backslashreplace_errors', 'builtins', 'charmap_build', 'charmap_decode', 'charmap_encode', 'decode', 'encode', 'escape_decode', 'escape_encode', 'getdecoder', 'getencoder', 'getincrementaldecoder', 'getincrementalencoder', 'getreader', 'getwriter', 'iterdecode', 'iterencode', 'latin_1_decode', 'latin_1_encode', 'make_encoding_map', 'make_identity_dict', 'raw_unicode_escape_decode', 'raw_unicode_escape_encode', 'readbuffer_encode', 'sys', 'unicode_escape_decode', 'unicode_escape_encode', 'unicode_internal_decode', 'unicode_internal_encode', 'utf_16_be_decode', 'utf_16_be_encode', 'utf_16_decode', 'utf_16_encode', 'utf_16_ex_decode', 'utf_16_le_decode', 'utf_16_le_encode', 'utf_32_be_decode', 'utf_32_be_encode', 'utf_32_decode', 'utf_32_encode', 'utf_32_ex_decode', 'utf_32_le_decode', 'utf_32_le_encode', 'utf_7_decode', 'utf_7_encode', 'utf_8_decode', 'utf_8_encode'] ---------- components: Library (Lib) messages: 232800 nosy: vadmium priority: normal severity: normal status: open title: codecs.__all__ incomplete type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 05:56:15 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 17 Dec 2014 04:56:15 +0000 Subject: [issue23071] codecs.__all__ incomplete In-Reply-To: <1418792013.22.0.617617600077.issue23071@psf.upfronthosting.co.za> Message-ID: <1418792175.6.0.158513424252.issue23071@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 06:37:53 2014 From: report at bugs.python.org (aab) Date: Wed, 17 Dec 2014 05:37:53 +0000 Subject: [issue23072] 2.7.9 multiprocessing compile conflict Message-ID: <1418794673.39.0.221318823729.issue23072@psf.upfronthosting.co.za> New submission from aab: python-2.7.9/Modules/_multiprocessing/multiprocessing.c python-2.7.9/Modules/_multiprocessing/semaphore.c The compile lines for the above two files have "-DHAVE_SEM_OPEN=1 -DHAVE_FD_TRANSFER=1 -DHAVE_SEM_TIMEDWAIT=0" in them. The cpp code in those files uses "#ifdef" and "#ifndef" with those symbols commensurate with the #define/#undef commands used in 'pyconfig.h'. In my case, the biggest problem is the "-DHAVE_SEM_TIMEDWAIT=0" which DEFINES that symbol so that the "#ifndef HAVE_SEM_TIMEDWAIT" in semaphore.c fails to do what the coder wanted. Being very lazy, I just hacked the files to use "#if SYMBOL" and "#if ! SYMBOL". Worked fine. Solaris 2.8 Studio 11 Compiler Suite -- Thanks, -- aab ---------- components: Build messages: 232801 nosy: aab at purdue.edu priority: normal severity: normal status: open title: 2.7.9 multiprocessing compile conflict versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 06:59:41 2014 From: report at bugs.python.org (Eric Snow) Date: Wed, 17 Dec 2014 05:59:41 +0000 Subject: [issue23068] Add a way to determine if the current thread has the import lock In-Reply-To: <1418782477.87.0.643327890289.issue23068@psf.upfronthosting.co.za> Message-ID: <1418795981.03.0.234284187244.issue23068@psf.upfronthosting.co.za> Eric Snow added the comment: Keep in mind that the global import lock is only held long enough to create a module-level lock. The cache of module locks is found at line 166 of Lib/importlib/_bootstrap.py and the code related to module-level locking follows. So unfortunately it won't be as simple as just getting the thread info from the global import lock. Regardless, would it be useful to expose a function in importlib.util that indicates whether or not the current thread is importing a module (actually the names of the modules it is importing)? Something like that would probably check both the global import lock and the module level locks, but make it unnecessary to expose the locks directly. Given the situation with module-level locks I image such a helper is going to be desirable. ---------- nosy: +brett.cannon, eric.snow, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 07:17:35 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 17 Dec 2014 06:17:35 +0000 Subject: [issue23049] Fix functools.reduce code equivalent. In-Reply-To: <1418516847.13.0.26860108886.issue23049@psf.upfronthosting.co.za> Message-ID: <1418797055.16.0.349503909082.issue23049@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 07:31:12 2014 From: report at bugs.python.org (Eric Snow) Date: Wed, 17 Dec 2014 06:31:12 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1418797872.12.0.0078679086957.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: I'm open to suggestions on how to help make the patch more reviewable. Currently at roughly +2500 lines of code it's a lot to ask someone to review. While probably not the only way to help reviewers, I expect the best thing I could do is to split the patch up into several smaller parts. However, I could use some insight into the best way to approach that. I keep considering factoring out the iterator/view boilerplate into helpers (macros?) in a separate patch. That would go a long way to making the actual cOrderedDict implementation more reasonably sized. I'm just not convinced yet it's the *right* approach. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 07:50:58 2014 From: report at bugs.python.org (Demian Brecht) Date: Wed, 17 Dec 2014 06:50:58 +0000 Subject: [issue14134] xmlrpc.client.ServerProxy needs timeout parameter In-Reply-To: <1330294741.21.0.00592117933576.issue14134@psf.upfronthosting.co.za> Message-ID: <1418799058.93.0.613830424452.issue14134@psf.upfronthosting.co.za> Demian Brecht added the comment: I've attached a test-less patch with my suggested approach. If there's no opposition to this change, I'll put some work into getting tests done for it as well. ---------- Added file: http://bugs.python.org/file37481/issue14134.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 07:54:04 2014 From: report at bugs.python.org (Andrej A Antonov) Date: Wed, 17 Dec 2014 06:54:04 +0000 Subject: [issue14134] xmlrpc.client.ServerProxy needs timeout parameter In-Reply-To: <1330294741.21.0.00592117933576.issue14134@psf.upfronthosting.co.za> Message-ID: <1418799244.95.0.159092525694.issue14134@psf.upfronthosting.co.za> Andrej A Antonov added the comment: good patch (issue14134.patch) ! thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 08:01:07 2014 From: report at bugs.python.org (aab) Date: Wed, 17 Dec 2014 07:01:07 +0000 Subject: [issue23072] 2.7.9 multiprocessing compile conflict In-Reply-To: <1418794673.39.0.221318823729.issue23072@psf.upfronthosting.co.za> Message-ID: <1418799667.64.0.0145310215734.issue23072@psf.upfronthosting.co.za> aab added the comment: Oh mud in face is me (:@{). The problem exists but I exacerbated it with some patches that worked with the 2.4.3 distribution - removed them. There is, however, a bit of a saving grace. An #if/#else/#endif near the top of multiprocessor.c #defines "HAVE_FD_TRANSFER to be 0 or 1. Subsequently in the file, "#if HAVE_FD_TRANSFER" is used except for the one near the bottom of the file which uses "#ifdef HAVE_FD_TRANSFER". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 08:01:53 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 17 Dec 2014 07:01:53 +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: <1418799713.0.0.863146590713.issue22980@psf.upfronthosting.co.za> Nick Coghlan added the comment: As far as PEP 425 goes, we handwaved a *lot* in order to be able to improve the user experience of the CPython Windows and Mac OS X binary installers by pairing them up with wheel files on PyPI. That handwaving is the key reason wheels for other platforms are still disallowed: the compatibility tags simply don't provide the information they need to provide for installers to make good decisions. I'd love to see a clear, needs based, revision of the compatibility tagging specification, that covers both source tagging and binary tagging, and gets away from the reliance on distutils.get_platform(). It's just a rather tedious exercise (as this issue shows...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 08:35:46 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 17 Dec 2014 07:35:46 +0000 Subject: [issue23071] codecs.__all__ incomplete In-Reply-To: <1418792013.22.0.617617600077.issue23071@psf.upfronthosting.co.za> Message-ID: <1418801746.53.0.0521941635933.issue23071@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, only documented names should be in __all__. Do you want to provide a patch Martin? Suggestion: first filter names which are contained in codecs.rst. ---------- keywords: +easy nosy: +serhiy.storchaka stage: -> needs patch versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 08:54:37 2014 From: report at bugs.python.org (Martin Panter) Date: Wed, 17 Dec 2014 07:54:37 +0000 Subject: [issue23071] codecs.__all__ incomplete In-Reply-To: <1418792013.22.0.617617600077.issue23071@psf.upfronthosting.co.za> Message-ID: <1418802877.88.0.825464498484.issue23071@psf.upfronthosting.co.za> Martin Panter added the comment: Okay I will try and make a patch for this once I have finished a patch to revise the documentation for Issue 19548 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 09:00:24 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Wed, 17 Dec 2014 08:00:24 +0000 Subject: [issue22706] Idle extension configuration and key bindings In-Reply-To: <1414023453.7.0.681663520586.issue22706@psf.upfronthosting.co.za> Message-ID: <1418803224.14.0.527184829782.issue22706@psf.upfronthosting.co.za> Saimadhav Heblikar added the comment: ZoomHeight behavior on linux is as what you mentioned. Now I have understood this issue. Working on it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 10:44:53 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 17 Dec 2014 09:44:53 +0000 Subject: [issue15513] Correct __sizeof__ support for pickle In-Reply-To: <1343723739.69.0.648602242607.issue15513@psf.upfronthosting.co.za> Message-ID: <1418809493.19.0.0946734532576.issue15513@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 Wed Dec 17 10:49:38 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 17 Dec 2014 09:49:38 +0000 Subject: [issue19548] 'codecs' module docs improvements In-Reply-To: <1384133353.82.0.173341188397.issue19548@psf.upfronthosting.co.za> Message-ID: <1418809778.33.0.650332915854.issue19548@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> needs patch type: -> enhancement versions: +Python 2.7, Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 12:14:32 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 17 Dec 2014 11:14:32 +0000 Subject: [issue23068] Add a way to determine if the current thread has the import lock In-Reply-To: <1418782477.87.0.643327890289.issue23068@psf.upfronthosting.co.za> Message-ID: <1418814872.86.0.386240743337.issue23068@psf.upfronthosting.co.za> Nick Coghlan added the comment: Perhaps an API like "importlib.util.locks_held()" that returns a list of module names? We'd then just iterate over the _module_locks() dictionary, looking for locks where the owner matched the current thread id (alternatively, if speed was critical for Guido's use case, add a separate reverse mapping from tid to locks held) (Unless I've missed something, we don't run user code with the global import lock held any more) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 12:52:23 2014 From: report at bugs.python.org (Martin Panter) Date: Wed, 17 Dec 2014 11:52:23 +0000 Subject: [issue20121] quopri_codec newline handling In-Reply-To: <1388836490.83.0.337537980753.issue20121@psf.upfronthosting.co.za> Message-ID: <1418817143.65.0.152841593586.issue20121@psf.upfronthosting.co.za> Martin Panter added the comment: RFC 1521 says that a text newline should be encoded as CRLF, and that any combination of 0x0D and 0x0A bytes that do not represent newlines should be encoded like other control characters as =0D and =0A. Since in Python 3 the codec outputs bytes, I don?t think there is any excuse for it to be outputting plain CR or LF bytes. The question is, do they represent newlines to be encoded as CRLF, or just data bytes that need ordinary encoding. ---------- nosy: +vadmium versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 13:22:53 2014 From: report at bugs.python.org (Gustavo Frederico Temple Pedrosa) Date: Wed, 17 Dec 2014 12:22:53 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1418818973.25.0.253499437136.issue22038@psf.upfronthosting.co.za> Gustavo Frederico Temple Pedrosa added the comment: ping ---------- nosy: +gustavotemple _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 13:26:48 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 17 Dec 2014 12:26:48 +0000 Subject: [issue20121] quopri_codec newline handling In-Reply-To: <1388836490.83.0.337537980753.issue20121@psf.upfronthosting.co.za> Message-ID: <1418819208.25.0.160487673278.issue20121@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: I agree with Vajrasky: a patch for the documentation would probably be a good idea. Note that mixing line end conventions in a single text is never a good idea. If you stick to one line end convention, there's no problem with the codec, AFAICT. >>> codecs.encode(b'\r\n\r\n', 'quopri_codec') b'\r\n\r\n' >>> codecs.decode(_, 'quopri_codec') b'\r\n\r\n' >>> codecs.encode(b'\n\n', 'quopri_codec') b'\n\n' >>> codecs.decode(_, 'quopri_codec') b'\n\n' ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 13:51:52 2014 From: report at bugs.python.org (Trent Nelson) Date: Wed, 17 Dec 2014 12:51:52 +0000 Subject: [issue22919] Update PCBuild for VS 2015 In-Reply-To: <1416692407.19.0.899325125222.issue22919@psf.upfronthosting.co.za> Message-ID: <1418820712.1.0.146425173847.issue22919@psf.upfronthosting.co.za> Changes by Trent Nelson : ---------- nosy: +trent _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 13:57:46 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 17 Dec 2014 12:57:46 +0000 Subject: [issue23070] Error in Tutorial comment In-Reply-To: <1418784667.28.0.75679477956.issue23070@psf.upfronthosting.co.za> Message-ID: <20141217125629.50111.22087@psf.io> Roundup Robot added the comment: New changeset 81c73f964066 by Berker Peksag in branch '3.4': Issue #23070: Fix a comment in the tutorial. https://hg.python.org/cpython/rev/81c73f964066 New changeset 81e2f58d9e4b by Berker Peksag in branch 'default': Issue #23070: Fix a comment in the tutorial. https://hg.python.org/cpython/rev/81e2f58d9e4b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 13:58:57 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 17 Dec 2014 12:58:57 +0000 Subject: [issue23070] Error in Tutorial comment In-Reply-To: <1418784667.28.0.75679477956.issue23070@psf.upfronthosting.co.za> Message-ID: <20141217125847.18159.88098@psf.io> Roundup Robot added the comment: New changeset 8cd84e62c1fd by Berker Peksag in branch '2.7': Issue #23070: Fix a comment in the tutorial. https://hg.python.org/cpython/rev/8cd84e62c1fd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 14:00:05 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 17 Dec 2014 13:00:05 +0000 Subject: [issue23070] Error in Tutorial comment In-Reply-To: <1418784667.28.0.75679477956.issue23070@psf.upfronthosting.co.za> Message-ID: <1418821205.68.0.431770608401.issue23070@psf.upfronthosting.co.za> Berker Peksag added the comment: Fixed. Thanks for the report, Ross. ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 15:36:27 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 17 Dec 2014 14:36:27 +0000 Subject: [issue22733] MSVC ffi_prep_args doesn't handle 64-bit arguments properly In-Reply-To: <1414355754.77.0.458541552576.issue22733@psf.upfronthosting.co.za> Message-ID: <20141217143608.50103.87087@psf.io> Roundup Robot added the comment: New changeset 4c81b1846e14 by Steve Dower in branch 'default': Issue #22733: MSVC ffi_prep_args doesn't handle 64-bit arguments properly https://hg.python.org/cpython/rev/4c81b1846e14 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 15:36:48 2014 From: report at bugs.python.org (Eric Snow) Date: Wed, 17 Dec 2014 14:36:48 +0000 Subject: [issue23068] Add a way to determine if the current thread has the import lock In-Reply-To: <1418814872.86.0.386240743337.issue23068@psf.upfronthosting.co.za> Message-ID: Eric Snow added the comment: > (Unless I've missed something, we don't run user code with the global import lock held any more) Ah. You are correct. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 15:40:13 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 17 Dec 2014 14:40:13 +0000 Subject: [issue23060] Assert fails in multiprocessing.heap.Arena.__setstate__ on Windows In-Reply-To: <1418696995.02.0.22756137648.issue23060@psf.upfronthosting.co.za> Message-ID: <20141217144007.28222.8891@psf.io> Roundup Robot added the comment: New changeset 1794d754ff3c by Steve Dower in branch 'default': Issue #23060: Suppresses a multiprocessing assert that fails incorrectly https://hg.python.org/cpython/rev/1794d754ff3c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 15:40:13 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 17 Dec 2014 14:40:13 +0000 Subject: [issue22733] MSVC ffi_prep_args doesn't handle 64-bit arguments properly In-Reply-To: <1414355754.77.0.458541552576.issue22733@psf.upfronthosting.co.za> Message-ID: <20141217144007.28222.85927@psf.io> Roundup Robot added the comment: New changeset 24f4569a1308 by Steve Dower in branch 'default': Issue #22733: Added NEWS item https://hg.python.org/cpython/rev/24f4569a1308 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 15:41:18 2014 From: report at bugs.python.org (Steve Dower) Date: Wed, 17 Dec 2014 14:41:18 +0000 Subject: [issue23060] Assert fails in multiprocessing.heap.Arena.__setstate__ on Windows In-Reply-To: <1418696995.02.0.22756137648.issue23060@psf.upfronthosting.co.za> Message-ID: <1418827278.65.0.406085438783.issue23060@psf.upfronthosting.co.za> Steve Dower added the comment: I've commented out the assertion for now with a comment pointing to this issue, so that'll keep the buildbots running while we figure out how to deal with this properly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 15:41:44 2014 From: report at bugs.python.org (Steve Dower) Date: Wed, 17 Dec 2014 14:41:44 +0000 Subject: [issue22733] MSVC ffi_prep_args doesn't handle 64-bit arguments properly In-Reply-To: <1414355754.77.0.458541552576.issue22733@psf.upfronthosting.co.za> Message-ID: <1418827304.85.0.164015424943.issue22733@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 15:42:57 2014 From: report at bugs.python.org (Steve Dower) Date: Wed, 17 Dec 2014 14:42:57 +0000 Subject: [issue23065] Pyhton27.dll at SysWOW64 not updated when updating Python 2.7.X In-Reply-To: <1418727319.18.0.894015013947.issue23065@psf.upfronthosting.co.za> Message-ID: <1418827377.81.0.649952522126.issue23065@psf.upfronthosting.co.za> Steve Dower added the comment: When you say "2.7.X", which version are you installing and which version did you have installed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 17:29:35 2014 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 17 Dec 2014 16:29:35 +0000 Subject: [issue23068] Add a way to determine if the current thread has the import lock In-Reply-To: Message-ID: Guido van Rossum added the comment: Oh. I'd forgotten the PY3 situation is completely different from the PY2 situation. We're still stuck here in PY2 land where there's just the one import lock. I guess not even ctypes can help us find out whether the current thread is holding the import lock (which is the condition we're trying to test for so we can print the warning). Our current hack is to check lock_held() and if it is held wait for up to 5 second (in 10 msec increments) to see if it goes away -- if it doesn't go away it would seem we are holding it in the current thread and then we fail with a rude assert. If it does go away within that time we assume some other thread was doing some lazy importing and we hope they'll be done soon because the whole world is waiting for them. On Wed, Dec 17, 2014 at 6:36 AM, Eric Snow wrote: > > > Eric Snow added the comment: > > > (Unless I've missed something, we don't run user code with the global > import lock held any more) > > Ah. You are correct. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 17:43:54 2014 From: report at bugs.python.org (Wes Turner) Date: Wed, 17 Dec 2014 16:43:54 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1418834634.17.0.240871126751.issue16991@psf.upfronthosting.co.za> Wes Turner added the comment: * Macros could be useful. * Would this make it easy/faster to also have a DefaultOrderedDict (which can/could also be accomplished with .get(attr, []) and .setdefault(attr, [])? * There may be some value in looking at https://pypi.python.org/pypi/cyordereddict * (I'm really not qualified to review this. Valgrind?) ---------- nosy: +westurner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 21:11:15 2014 From: report at bugs.python.org (Martin Panter) Date: Wed, 17 Dec 2014 20:11:15 +0000 Subject: [issue20121] quopri_codec newline handling In-Reply-To: <1388836490.83.0.337537980753.issue20121@psf.upfronthosting.co.za> Message-ID: <1418847075.67.0.651028555221.issue20121@psf.upfronthosting.co.za> Martin Panter added the comment: Okay so maybe the documentation should include these restrictions on encoding: * The data being encoded should only include \r or \n bytes that are part of \n or \r\n newline sequences. Encoding arbitrary non-text data is not supported. * The two kinds of newlines should not be mixed * If \n is used for newlines in the input, the encoder will output \n newlines, and they will need converting to CRLF in a later step to conform to the RFC ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 21:50:35 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 17 Dec 2014 20:50:35 +0000 Subject: [issue20121] quopri_codec newline handling In-Reply-To: <1388836490.83.0.337537980753.issue20121@psf.upfronthosting.co.za> Message-ID: <1418849435.74.0.146958719535.issue20121@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Pure Python implementation returns different result. >>> import quopri >>> quopri.encodestring(b'\r\n') b'\r\n' >>> quopri.a2b_qp = quopri.b2a_qp = None >>> quopri.encodestring(b'\r\n') b'=0D\n' See also issue18022. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 22:27:03 2014 From: report at bugs.python.org (Eric Snow) Date: Wed, 17 Dec 2014 21:27:03 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1418851623.87.0.396112470564.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: Suggestions from Antoine on python-dev: * do not make cOrderedDict "builtin"; drop changes to: - Include/Python.h - Objects/object.c - Makefile.pre.in * do not add a C-API * include the linked list pointers in the hash entries? (may simplify things) * drop the shared/split keys mechanism? * do not subclass dict? (can of worms) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 22:28:40 2014 From: report at bugs.python.org (bbc) Date: Wed, 17 Dec 2014 21:28:40 +0000 Subject: [issue23073] Broken turtle example in Cmd documentation Message-ID: <1418851720.64.0.216827601034.issue23073@psf.upfronthosting.co.za> New submission from bbc: The documentation page for the cmd module contains an example with the turtle module: https://docs.python.org/3.4/library/cmd.html#cmd-example It seems like the turtle module has changed quite a bit since the code was written, and exposes a Pen class instead of all the various movement functions. The example, while still useful, cannot be executed as is. I like the example and would be happy to provide an idiomatic replacement if you think this is necessary. ---------- assignee: docs at python components: Documentation messages: 232829 nosy: bbc, docs at python priority: normal severity: normal status: open title: Broken turtle example in Cmd documentation type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 17 23:49:12 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 17 Dec 2014 22:49:12 +0000 Subject: [issue23074] asyncio: get_event_loop() must always raise an exception, even when assertions are disabled by -O Message-ID: <1418856552.4.0.422863873532.issue23074@psf.upfronthosting.co.za> New submission from STINNER Victor: Spinoff of the issue #22926: asyncio.get_event_loop() must always raise an exception, even when assertions are disabled by -O. Attached patch implements this suggestion. ---------- components: asyncio files: get_event_loop.patch keywords: patch messages: 232830 nosy: gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio: get_event_loop() must always raise an exception, even when assertions are disabled by -O versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37482/get_event_loop.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 00:14:40 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 17 Dec 2014 23:14:40 +0000 Subject: [issue23068] Add a way to determine if the current thread has the import lock In-Reply-To: <1418782477.87.0.643327890289.issue23068@psf.upfronthosting.co.za> Message-ID: <1418858080.35.0.286462910971.issue23068@psf.upfronthosting.co.za> Nick Coghlan added the comment: Looking at the implementation of PyImport_ImportModuleNoBlock, you should be able to invoke that via ctypes with a nonsense module name to probe for whether or not the current thread has the import lock. A call like 'PyImport_ImportModuleNoBlock("this-is-not-a-legal-module-name")' will always fail with ImportError, but the exception message will be different if another thread holds the import lock. Specifically, it will end with "because the import lock is held by another thread". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 00:20:25 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 17 Dec 2014 23:20:25 +0000 Subject: [issue23068] Add a way to determine if the current thread has the import lock In-Reply-To: <1418782477.87.0.643327890289.issue23068@psf.upfronthosting.co.za> Message-ID: <1418858425.07.0.452902424916.issue23068@psf.upfronthosting.co.za> Nick Coghlan added the comment: You'd still need to check lock_held() to see if *some* thread is holding the import lock. The non-blocking import API should then let you determine if that thread is the current one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 00:21:36 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 17 Dec 2014 23:21:36 +0000 Subject: [issue22926] asyncio: raise an exception when called from the wrong thread In-Reply-To: <1416760694.74.0.749180510867.issue22926@psf.upfronthosting.co.za> Message-ID: <1418858496.51.0.288625875113.issue22926@psf.upfronthosting.co.za> STINNER Victor added the comment: Guido> So in order to do correct diagnostics here we would have to add an "owning thread" pointer to every event loop; I didn't understand why this approach was not taken when the check was introduced. I was surprised that get_event_loop() was used for the check instead. Here is a patch checking the thread using threading.get_ident(). The check still works when set_event_loop(None) is used in unit tests. I created the issue #23074 for the change: get_event_loop() must always raise an exception, even when assertions are disabled by -O. -- asyncio requires thread support, it is already the case without my patch. For example, the event loop policy uses threading.Local. In the aioeventlet project, call_soon() writes a byte in the self pipe (to wake up the selector) if the selector is waiting for events; call_soon() is "green thread safe". It is less efficient than calling forcing users to call explicitly call_soon_threadsafe(), but aioeventlet is written to be compatible with asyncio and eventlet, while these projects are very different. In the aiogevent and aioeventlet projects, I also store the current greenlet, but for a different purpose: ensure that yield_future() is not called in the greenlet running the event loop, which would blocking. ---------- Added file: http://bugs.python.org/file37483/check_thread.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 00:29:13 2014 From: report at bugs.python.org (Ethan Furman) Date: Wed, 17 Dec 2014 23:29:13 +0000 Subject: [issue23073] Broken turtle example in Cmd documentation In-Reply-To: <1418851720.64.0.216827601034.issue23073@psf.upfronthosting.co.za> Message-ID: <1418858953.29.0.617300801646.issue23073@psf.upfronthosting.co.za> Ethan Furman added the comment: Please do! Working examples are better than non-working ones. :) ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 00:30:48 2014 From: report at bugs.python.org (Ethan Furman) Date: Wed, 17 Dec 2014 23:30:48 +0000 Subject: [issue23073] Broken turtle example in Cmd documentation In-Reply-To: <1418851720.64.0.216827601034.issue23073@psf.upfronthosting.co.za> Message-ID: <1418859048.92.0.426903457721.issue23073@psf.upfronthosting.co.za> Ethan Furman added the comment: While you're at it, could you also sign the contributors' license agreement? https://www.python.org/psf/contrib/contrib-form/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 00:32:15 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 17 Dec 2014 23:32:15 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1418859135.58.0.827669783868.issue22038@psf.upfronthosting.co.za> STINNER Victor added the comment: Fedora 20 provides GCC 4.7 but no stdatomic.c: HAVE_BUILTIN_ATOMIC set (HAVE_STD_ATOMIC unset). Fedora 21 provides GCC 4.9 with stdatomic.c: HAVE_BUILTIN_ATOMIC and HAVE_STD_ATOMIC are set. I tested atomicv2.patch on Fedora 20 (x86_64) and Fedora 21 (x86_64): the whole test suite pass. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 00:45:12 2014 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 17 Dec 2014 23:45:12 +0000 Subject: [issue23068] Add a way to determine if the current thread has the import lock In-Reply-To: <1418782477.87.0.643327890289.issue23068@psf.upfronthosting.co.za> Message-ID: <1418859912.56.0.0737999954251.issue23068@psf.upfronthosting.co.za> Guido van Rossum added the comment: Interesting. The Dropbox server team thanks you for the suggestion! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 00:52:00 2014 From: report at bugs.python.org (Alex Gaynor) Date: Wed, 17 Dec 2014 23:52:00 +0000 Subject: [issue23075] Mock backport in 2.7 relies on implementation defined behavior Message-ID: <1418860320.5.0.0748673104985.issue23075@psf.upfronthosting.co.za> New submission from Alex Gaynor: Whether __builtins__ is a module or a dict is undefined in CPython. Use the reliably well defined `import __builtin__` instead. ---------- components: Library (Lib) files: mock-backport.diff keywords: patch messages: 232838 nosy: alex, benjamin.peterson, dstufft priority: normal severity: normal status: open title: Mock backport in 2.7 relies on implementation defined behavior versions: Python 2.7 Added file: http://bugs.python.org/file37484/mock-backport.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 00:53:27 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 17 Dec 2014 23:53:27 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1418860407.31.0.963467729742.issue22038@psf.upfronthosting.co.za> STINNER Victor added the comment: atomicv2.patch: > _Atomic int _value; Why not using the atomic_int type from stdatomic.h here? > https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html "__atomic_store_n(): The valid memory model variants are __ATOMIC_RELAXED, __ATOMIC_SEQ_CST, and __ATOMIC_RELEASE." I understand that _Py_atomic_store_explicit() only accept some values for order. An assertion should be added here, maybe for any implementation. Something like: #define _Py_atomic_store_explicit(ATOMIC_VAL, NEW_VAL, ORDER) \ (assert((ORDER) == __ATOMIC_RELAXED \ || (ORDER) == __ATOMIC_SEQ_CST \ || (ORDER) == __ATOMIC_RELEASE), \ __atomic_store_n(&(ATOMIC_VAL)->_value, NEW_VAL, ORDER)) Same remark for _Py_atomic_load_explicit(): "__atomic_load_n(): The valid memory model variants are __ATOMIC_RELAXED, __ATOMIC_SEQ_CST, __ATOMIC_ACQUIRE, and __ATOMIC_CONSUME." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 00:56:28 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 17 Dec 2014 23:56:28 +0000 Subject: [issue21071] struct.Struct.format is bytes, but should be str In-Reply-To: <1395856133.5.0.672707015318.issue21071@psf.upfronthosting.co.za> Message-ID: <1418860588.32.0.0269241215165.issue21071@psf.upfronthosting.co.za> STINNER Victor added the comment: > It would be backwards incompatible to change, though. I'm in favor of breaking the compatibility with Python 3.4 and return the format as an Unicode string. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 00:58:38 2014 From: report at bugs.python.org (STINNER Victor) Date: Wed, 17 Dec 2014 23:58:38 +0000 Subject: [issue21619] Cleaning up a subprocess with a broken pipe In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za> Message-ID: <1418860718.32.0.880368976776.issue21619@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 00:59:40 2014 From: report at bugs.python.org (Antony Lee) Date: Wed, 17 Dec 2014 23:59:40 +0000 Subject: [issue23076] path.glob("") fails with IndexError Message-ID: <1418860780.4.0.558535328721.issue23076@psf.upfronthosting.co.za> New submission from Antony Lee: glob.glob returns an empty list when passed an empty pattern as argument, but pathlib's Path.glob fails with IndexError. The first option seems more reasonable (or at least it should be a ValueError). ---------- components: Library (Lib) messages: 232841 nosy: Antony.Lee priority: normal severity: normal status: open title: path.glob("") fails with IndexError versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 01:08:58 2014 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 18 Dec 2014 00:08:58 +0000 Subject: [issue23077] PEP 1: Allow Provisional status for PEPs Message-ID: <1418861338.72.0.949069550217.issue23077@psf.upfronthosting.co.za> New submission from Nick Coghlan: As per python-dev discussion [1], filing this as the home for a proposed update to PEP 1 that allows Standards Track PEPs to be granted Provisional status before moving on to Accepted/Final. The new status will be for PEPs where we want to release an initial reference implementation (whether in CPython under PEP 411 or through the PyPA toolchain) before locking down the exact details of the API specification. [1] https://mail.python.org/pipermail/python-dev/2014-December/137622.html ---------- assignee: ncoghlan messages: 232842 nosy: Jeremy.Hylton, barry, goodger, ncoghlan priority: normal severity: normal stage: needs patch status: open title: PEP 1: Allow Provisional status for PEPs type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 01:17:19 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 18 Dec 2014 00:17:19 +0000 Subject: [issue21071] struct.Struct.format is bytes, but should be str In-Reply-To: <1395856133.5.0.672707015318.issue21071@psf.upfronthosting.co.za> Message-ID: <1418861839.57.0.832104732761.issue21071@psf.upfronthosting.co.za> Martin Panter added the comment: I originally assumed it would be a text string from the existing documentation, so changing the behaviour to match also seems reasonable ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 01:22:04 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 18 Dec 2014 00:22:04 +0000 Subject: [issue23074] asyncio: get_event_loop() must always raise an exception, even when assertions are disabled by -O In-Reply-To: <1418856552.4.0.422863873532.issue23074@psf.upfronthosting.co.za> Message-ID: <20141218002154.80997.91751@psf.io> Roundup Robot added the comment: New changeset b4dce0e695df by Victor Stinner in branch '3.4': Issue #23074: asyncio.get_event_loop() now raises an exception if the thread https://hg.python.org/cpython/rev/b4dce0e695df ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 01:22:53 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 18 Dec 2014 00:22:53 +0000 Subject: [issue23074] asyncio: get_event_loop() must always raise an exception, even when assertions are disabled by -O In-Reply-To: <1418856552.4.0.422863873532.issue23074@psf.upfronthosting.co.za> Message-ID: <1418862173.41.0.388320300631.issue23074@psf.upfronthosting.co.za> STINNER Victor added the comment: Change applied to Python 3.4, 3.5 and Tulip (c6115bc83acc). Thanks for the review Guido. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 01:24:25 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 18 Dec 2014 00:24:25 +0000 Subject: [issue23074] asyncio: get_event_loop() must always raise an exception, even when assertions are disabled by -O In-Reply-To: <1418862173.41.0.388320300631.issue23074@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: I also updated aiotest test suite: https://bitbucket.org/haypo/aiotest/commits/d6f544a16a8f55729268d8d4b8d864d1b0af2d12 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 01:42:24 2014 From: report at bugs.python.org (bbc) Date: Thu, 18 Dec 2014 00:42:24 +0000 Subject: [issue23073] Broken turtle example in Cmd documentation In-Reply-To: <1418851720.64.0.216827601034.issue23073@psf.upfronthosting.co.za> Message-ID: <1418863344.96.0.726343622065.issue23073@psf.upfronthosting.co.za> bbc added the comment: It turns out the script is fine. I could have investigated it more thoroughly at first if I had more carefully read the docs for turtle. I thought those functions were not exposed because they were reportedly not found after I copy-pasted, executed the example script and entered commands. The reason was my file was named turtle.py. Sorry for the noise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 01:44:11 2014 From: report at bugs.python.org (Ethan Furman) Date: Thu, 18 Dec 2014 00:44:11 +0000 Subject: [issue23073] Broken turtle example in Cmd documentation In-Reply-To: <1418851720.64.0.216827601034.issue23073@psf.upfronthosting.co.za> Message-ID: <1418863451.78.0.401321730509.issue23073@psf.upfronthosting.co.za> Ethan Furman added the comment: No worries, thanks for following up. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 03:21:07 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 18 Dec 2014 02:21:07 +0000 Subject: [issue19548] 'codecs' module docs improvements In-Reply-To: <1384133353.82.0.173341188397.issue19548@psf.upfronthosting.co.za> Message-ID: <1418869267.88.0.885938002462.issue19548@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch addressing many of the points raised. Please have a look and give any feedback. Beware I am not very familiar with the Restructured Text markup and haven?t tried compiling it. 1. Mentioned bytes-to-bytes and text-to-text in general right at the top. Any APIs (e.g. see Issue 20132) that don't support them should be pointed out as exceptions to the rule. 8. The underlying mode is forced to binary, so 'r' is the same as 'rb'. I removed the 'b' from the signature for clarity. ## Jan?s points not yet addressed: ## 3. I expect the built-in open() function would already be much more obvious and advertised, so I didn't add any cross-reference from codecs.open(). 5. Both points still need addressing: * Lack of requirement for implementing incremental codecs * Responsibility of implementing error handlers 9. First point left unaddressed: * register_error() error_handler replacement data type (unsure of details) ## Numbering Nick?s points: ## 12. Codec name normalization: Not addressed; what should be written? [13. Registration not reversible: Added in patch] [14. Added CodecInfo class, pulling out some existing details from register().] 15. ?encodings? module: not done 16. Import system: not done ## My (Martin?s) point: ## [17. IncrementalEncoder.reset(): done] ## Zoinkity?s points, not addressed: ## 18. Multibyte codecs 19. register() usage example ## Some new points of my own that need fixing: ## 20. The doc string for register() says the search function is also allowed to return a tuple of functions, but the reference manual does not mention this. Which is more accurate? (I notice CodecInfo is a subclass of ?tuple?.) 21. EncodedFile() seems to return StreamRecoder instances. Perhaps move them closer together? Should probably warn that EncodedFile's data_encoding is handled by a stateless codec. 22. The Codec.encode() and decode() methods return a length consumed, but I suspect they have to consume everything they are supplied because the code I have seen ignores this return value. ---------- keywords: +patch Added file: http://bugs.python.org/file37485/codecs-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 03:25:22 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 18 Dec 2014 02:25:22 +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: <1418869522.73.0.330533347223.issue20132@psf.upfronthosting.co.za> Martin Panter added the comment: The ?unicode-escape? and ?utf-7? cases affect the more widely-used TextIOWrapper interface: >>> TextIOWrapper(BytesIO(br"\u2013" * 2000), "unicode-escape").read(1) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.4/encodings/unicode_escape.py", line 26, in decode return codecs.unicode_escape_decode(input, self.errors)[0] UnicodeDecodeError: 'unicodeescape' codec can't decode bytes in position 8190-8191: truncated \uXXXX escape >>> w = TextIOWrapper(BytesIO(), "utf-7") >>> w.writelines("\xA9\xA9") # Write one character at a time >>> w.detach().getvalue() b'+AKk-+AKk-' >>> r = TextIOWrapper(BytesIO(b"+" + b"AAAAAAAA" * 100000 + b"-"), "utf-7") >>> r.read(1) # Short delay as all 800 kB are decoded to read one character '\x00' >>> r.buffer.tell() 800002 For UTF-7 decoding to work optimally I think the amount of data buffering necessary would be limited to only a few bytes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 03:27:23 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 18 Dec 2014 02:27:23 +0000 Subject: [issue19539] The 'raw_unicode_escape' codec buggy + not appropriate for Python 3.x In-Reply-To: <1384051905.56.0.969775270474.issue19539@psf.upfronthosting.co.za> Message-ID: <1418869643.65.0.0205262185798.issue19539@psf.upfronthosting.co.za> Martin Panter added the comment: I included the proposed doc fix in my patch for Issue 19548 ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 03:56:40 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 18 Dec 2014 02:56:40 +0000 Subject: [issue19548] 'codecs' module docs improvements In-Reply-To: <1384133353.82.0.173341188397.issue19548@psf.upfronthosting.co.za> Message-ID: <1418871400.03.0.863584101648.issue19548@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 04:40:10 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 18 Dec 2014 03:40:10 +0000 Subject: [issue23071] codecs.__all__ incomplete In-Reply-To: <1418792013.22.0.617617600077.issue23071@psf.upfronthosting.co.za> Message-ID: <1418874010.33.0.579948191731.issue23071@psf.upfronthosting.co.za> Martin Panter added the comment: Here is the patch (against the default branch) ---------- keywords: +patch Added file: http://bugs.python.org/file37486/codecs-all.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 04:42:33 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 18 Dec 2014 03:42:33 +0000 Subject: [issue23062] test_argparse --version test cases In-Reply-To: <1418706736.64.0.85644160224.issue23062@psf.upfronthosting.co.za> Message-ID: <1418874153.03.0.65563397825.issue23062@psf.upfronthosting.co.za> Martin Panter added the comment: Patch looks sensible enough to me ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 04:45:44 2014 From: report at bugs.python.org (Berker Peksag) Date: Thu, 18 Dec 2014 03:45:44 +0000 Subject: [issue23071] codecs.__all__ incomplete In-Reply-To: <1418792013.22.0.617617600077.issue23071@psf.upfronthosting.co.za> Message-ID: <1418874344.19.0.691037793018.issue23071@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks! Could you also add a test? See PublicAPITests in Lib/test/test_shutil.py as an example. ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 05:14:07 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 18 Dec 2014 04:14:07 +0000 Subject: [issue21279] str.translate documentation incomplete In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za> Message-ID: <1418876047.72.0.153587798126.issue21279@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a new patch based on John?s suggestion ---------- Added file: http://bugs.python.org/file37487/issue21279.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 05:30:48 2014 From: report at bugs.python.org (liu chang) Date: Thu, 18 Dec 2014 04:30:48 +0000 Subject: [issue23076] path.glob("") fails with IndexError In-Reply-To: <1418860780.4.0.558535328721.issue23076@psf.upfronthosting.co.za> Message-ID: <1418877048.39.0.468399368653.issue23076@psf.upfronthosting.co.za> liu chang added the comment: In[6]: pathlib.Path.glob("") Traceback (most recent call last): File "/home/liuchang/ENV3/lib/python3.4/site-packages/IPython/core/interactiveshell.py", line 2883, in run_code exec(code_obj, self.user_global_ns, self.user_ns) File "", line 1, in pathlib.Path.glob("") TypeError: glob() missing 1 required positional argument: 'pattern' the version of my python is 3.4? I got a TypeError? No IndexError? ---------- nosy: +liu chang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 06:25:00 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 18 Dec 2014 05:25:00 +0000 Subject: [issue21071] struct.Struct.format is bytes, but should be str In-Reply-To: <1395856133.5.0.672707015318.issue21071@psf.upfronthosting.co.za> Message-ID: <1418880300.53.0.182606524162.issue21071@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch that changes over to a str() type. Is it safe to assume PyUnicode_AsUTF8() is null-terminated (like PyBytes_AS_STRING() is)? My documentation doesn?t say. ---------- Added file: http://bugs.python.org/file37488/format-str.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 06:55:28 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 18 Dec 2014 05:55:28 +0000 Subject: [issue16349] Document whether it's safe to use bytes for struct format string In-Reply-To: <1351428222.6.0.656645524198.issue16349@psf.upfronthosting.co.za> Message-ID: <1418882128.32.0.427721774331.issue16349@psf.upfronthosting.co.za> Martin Panter added the comment: Assuming it is intended to support byte strings, here is a patch that documents them being allowed, and adds a test case ---------- keywords: +patch Added file: http://bugs.python.org/file37489/format-bytes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 07:40:13 2014 From: report at bugs.python.org (GamesGamble) Date: Thu, 18 Dec 2014 06:40:13 +0000 Subject: [issue23065] Pyhton27.dll at SysWOW64 not updated when updating Python 2.7.X In-Reply-To: <1418727319.18.0.894015013947.issue23065@psf.upfronthosting.co.za> Message-ID: <1418884813.03.0.0833103364092.issue23065@psf.upfronthosting.co.za> GamesGamble added the comment: 2.7.7 was installed and I has installed 2.7.8 and 2.7.8 was installed and then I has installed 2.7.9. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 07:42:51 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 18 Dec 2014 06:42:51 +0000 Subject: [issue19176] DeprecationWarning for doctype() method when subclassing _elementtree.XMLParser In-Reply-To: <1381041750.41.0.637077946349.issue19176@psf.upfronthosting.co.za> Message-ID: <1418884971.42.0.776857171501.issue19176@psf.upfronthosting.co.za> Martin Panter added the comment: Here is another patch that removes the method instead, as suggested in the review ---------- Added file: http://bugs.python.org/file37490/doctype-remove.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 08:08:02 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 18 Dec 2014 07:08:02 +0000 Subject: [issue23071] codecs.__all__ incomplete In-Reply-To: <1418792013.22.0.617617600077.issue23071@psf.upfronthosting.co.za> Message-ID: <1418886482.91.0.26842526769.issue23071@psf.upfronthosting.co.za> Martin Panter added the comment: This patch includes a new test; although this kind of testing won?t detect when someone adds a new API and forgets to add it to __all__. ---------- Added file: http://bugs.python.org/file37491/codecs-all.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 08:37:58 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 18 Dec 2014 07:37:58 +0000 Subject: [issue19176] DeprecationWarning for doctype() method when subclassing _elementtree.XMLParser In-Reply-To: <1381041750.41.0.637077946349.issue19176@psf.upfronthosting.co.za> Message-ID: <1418888278.42.0.742566265687.issue19176@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: doctype-remove.patch is acceptable for both 3.4 and 3.5 or only 3.5? If only 3.5, then please apply inherit-doctype.patch in 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 09:13:13 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 18 Dec 2014 08:13:13 +0000 Subject: [issue21071] struct.Struct.format is bytes, but should be str In-Reply-To: <1418880300.53.0.182606524162.issue21071@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Is it safe to assume PyUnicode_AsUTF8() is null-terminated? Yes, Python ensures that the string is null terminated. > (like PyBytes_AS_STRING() is) Yes, PyBytes_AS_STRING() also ends with a null byte. By the way, Unicode strings internally ends with a null character. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 09:45:23 2014 From: report at bugs.python.org (Kevin Benton) Date: Thu, 18 Dec 2014 08:45:23 +0000 Subject: [issue23078] unittest.mock patch autospec doesn't work on staticmethods Message-ID: <1418892323.1.0.910322233262.issue23078@psf.upfronthosting.co.za> New submission from Kevin Benton: If one of the mock.patch methods is used with autospec=True on a staticmethod in an object, the mock library determines that it is not callable by checking for the __call__ attribute. This results in a NonCallableMagicMock being returned which of course dies with the following error when the mocked method is called: TypeError: 'NonCallableMagicMock' object is not callable It seems that the create_autospec needs to special case for classmethod and staticmethod. The following change seems to fix it, however I am only vaguely familiar with the internals of mock so I'm not sure what this breaks. diff -r d356250e275d mock.py --- a/mock.py Tue Apr 09 14:53:33 2013 +0100 +++ b/mock.py Wed Dec 17 07:35:15 2014 -0800 @@ -2191,7 +2191,8 @@ # descriptors don't have a spec # because we don't know what type they return _kwargs = {} - elif not _callable(spec): + elif not _callable(spec) and not isinstance(spec, (staticmethod, + classmethod)): Klass = NonCallableMagicMock elif is_type and instance and not _instance_callable(spec): Klass = NonCallableMagicMock ---------- components: Tests messages: 232864 nosy: kevinbenton, michael.foord priority: normal severity: normal status: open title: unittest.mock patch autospec doesn't work on staticmethods type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 10:30:15 2014 From: report at bugs.python.org (Kimmo Parviainen-Jalanko) Date: Thu, 18 Dec 2014 09:30:15 +0000 Subject: [issue23057] asyncio loop on Windows should stop on keyboard interrupt In-Reply-To: <1418674256.87.0.827009141117.issue23057@psf.upfronthosting.co.za> Message-ID: <1418895015.43.0.0444987674647.issue23057@psf.upfronthosting.co.za> Kimmo Parviainen-Jalanko added the comment: Seems to happen on FreeBSD 10.1 as well with 3.4.2 ---------- nosy: +Kimmo.Parviainen-Jalanko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 10:37:05 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 18 Dec 2014 09:37:05 +0000 Subject: [issue23057] asyncio loop on Windows should stop on keyboard interrupt In-Reply-To: <1418674256.87.0.827009141117.issue23057@psf.upfronthosting.co.za> Message-ID: <1418895425.31.0.553081391076.issue23057@psf.upfronthosting.co.za> STINNER Victor added the comment: > Seems to happen on FreeBSD 10.1 as well with 3.4.2 FreeBSD uses a completly different implementation. Please open a new issue, describe your problem and write a script reproducing your issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 10:59:50 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 18 Dec 2014 09:59:50 +0000 Subject: [issue23071] codecs.__all__ incomplete In-Reply-To: <1418792013.22.0.617617600077.issue23071@psf.upfronthosting.co.za> Message-ID: <1418896790.76.0.589969469312.issue23071@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 11:04:04 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 18 Dec 2014 10:04:04 +0000 Subject: [issue21071] struct.Struct.format is bytes, but should be str In-Reply-To: <1395856133.5.0.672707015318.issue21071@psf.upfronthosting.co.za> Message-ID: <1418897044.36.0.220393651692.issue21071@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think breaking the compatibility should be discussed on Python-Dev. Similar issue (and even worse) is issue8934. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 11:33:56 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 18 Dec 2014 10:33:56 +0000 Subject: [issue23071] codecs.__all__ incomplete In-Reply-To: <1418792013.22.0.617617600077.issue23071@psf.upfronthosting.co.za> Message-ID: <1418898836.87.0.806817851894.issue23071@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: +1 ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 12:12:33 2014 From: report at bugs.python.org (=?utf-8?q?Bj=C3=B6rn_Dahlgren?=) Date: Thu, 18 Dec 2014 11:12:33 +0000 Subject: [issue21697] shutil.copytree() handles symbolic directory incorrectly In-Reply-To: <1402319959.34.0.00412025295877.issue21697@psf.upfronthosting.co.za> Message-ID: <1418901153.81.0.383172511298.issue21697@psf.upfronthosting.co.za> Bj?rn Dahlgren added the comment: I ran across this bug too. Applying Eduardo's patch got my package working under Py 3.4 ---------- nosy: +Bj?rn.Dahlgren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 13:02:11 2014 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 18 Dec 2014 12:02:11 +0000 Subject: [issue23079] os.path.normcase documentation confusing Message-ID: <1418904131.32.0.416083778815.issue23079@psf.upfronthosting.co.za> New submission from Chris Jerdonek: The documentation for os.path.normcase(path) is currently confusing or self-contradictory. Currently, it reads-- "Normalize the case of a pathname. On Unix and Mac OS X, this returns the path unchanged; on case-insensitive filesystems, it converts the path to lowercase." However, with a case-insensitive file system on Mac OS X (e.g. "File System Personality: Journaled HFS+"), normcase() does not convert paths to lowercase. As it stands, it seems like the clause "on case-insensitive filesystems, it converts the path to lowercase" should be removed or further qualified. I don't know what the qualification is though. ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 232871 nosy: chris.jerdonek, docs at python priority: normal severity: normal status: open title: os.path.normcase documentation confusing type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 13:16:09 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 18 Dec 2014 12:16:09 +0000 Subject: [issue23079] os.path.normcase documentation confusing In-Reply-To: <1418904131.32.0.416083778815.issue23079@psf.upfronthosting.co.za> Message-ID: <1418904969.04.0.316295126062.issue23079@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: s/on case-insensitive filesystems/on Windows/ ? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 13:18:34 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 18 Dec 2014 12:18:34 +0000 Subject: [issue23079] os.path.normcase documentation confusing In-Reply-To: <1418904131.32.0.416083778815.issue23079@psf.upfronthosting.co.za> Message-ID: <1418905114.03.0.915709501192.issue23079@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: ... and OS/2 (in 2.7). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 13:56:29 2014 From: report at bugs.python.org (Antony Lee) Date: Thu, 18 Dec 2014 12:56:29 +0000 Subject: [issue23080] BoundArguments.arguments should be unordered Message-ID: <1418907389.55.0.608772896554.issue23080@psf.upfronthosting.co.za> New submission from Antony Lee: This patch makes BoundArguments.arguments an unordered dict. As discussed on python-ideas, the rationale for this is 1. The current ordering in ba.arguments is the one of the parameters in the signature (which is already available via the ba.signature attribute), not the one in which the arguments are given (which will always be unavailable as long as Python doesn't keep the order of keyword arguments), so no information is lost by this patch. 2. The recipe in the docs for updating ba.arguments to also contain default argument values breaks that ordering, making __eq__ behavior difficult to explain: s = signature(lambda x=None, y=None: None) ba0 = s.bind() ba1 = s.bind(x=None) ba2 = s.bind(y=None) At that point, with the current implementation, we'll have ba0 == ba1 != ba2... why? 3. Implementing ba.arguments as a regular dict makes signature.bind much faster, which is important e.g. if it is used in a decorating type-checker as suggested in PEP362. (That specific issue could also be improved by a C-implemented OrderedDict, but the other reasons remain valid.) ---------- components: Library (Lib) files: unordered-boundarguments.patch keywords: patch messages: 232874 nosy: Antony.Lee priority: normal severity: normal status: open title: BoundArguments.arguments should be unordered versions: Python 3.5 Added file: http://bugs.python.org/file37492/unordered-boundarguments.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 14:15:20 2014 From: report at bugs.python.org (Lars Buitinck) Date: Thu, 18 Dec 2014 13:15:20 +0000 Subject: [issue23081] Document PySequence_List(o) as equivalent to list(o) Message-ID: <1418908520.28.0.480794985208.issue23081@psf.upfronthosting.co.za> New submission from Lars Buitinck: PySequence_List has accepted iterables since changeset 6c82277e77f3 of May 1, 2001 ("NEEDS DOC CHANGES" :), but its documentation still only speaks of sequences. I suggest that it is changed to promise to handle arbitrary iterables, just like PySequence_Tuple. ---------- assignee: docs at python components: Documentation files: PySequence_List-doc.patch keywords: patch messages: 232875 nosy: docs at python, larsmans priority: normal severity: normal status: open title: Document PySequence_List(o) as equivalent to list(o) versions: Python 3.5 Added file: http://bugs.python.org/file37493/PySequence_List-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 14:37:19 2014 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 18 Dec 2014 13:37:19 +0000 Subject: [issue23082] pathlib relative_to() can give confusing error message Message-ID: <1418909839.25.0.648032443428.issue23082@psf.upfronthosting.co.za> New submission from Chris Jerdonek: pathlib's relative_to(other) can give a confusing message when "other" is os.curdir. For example-- Python 3.4.2 (default, Nov 12 2014, 18:23:59) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.54)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> from pathlib import Path >>> Path("/foo").relative_to(os.curdir) Traceback (most recent call last): File "", line 1, in File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/pathlib.py", line 806, in relative_to .format(str(self), str(formatted))) ValueError: '/foo' does not start with '' I guess the error here is that the path must be relative when "other" is relative. ---------- components: Library (Lib) messages: 232876 nosy: chris.jerdonek priority: normal severity: normal status: open title: pathlib relative_to() can give confusing error message type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 14:46:59 2014 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 18 Dec 2014 13:46:59 +0000 Subject: [issue23082] pathlib relative_to() can give confusing error message In-Reply-To: <1418909839.25.0.648032443428.issue23082@psf.upfronthosting.co.za> Message-ID: <1418910419.51.0.75475140069.issue23082@psf.upfronthosting.co.za> Chris Jerdonek added the comment: By the way, here is another (less) confusing error message: >>> Path("foo").relative_to("fo") Traceback (most recent call last): File "", line 1, in File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/pathlib.py", line 806, in relative_to .format(str(self), str(formatted))) ValueError: 'foo' does not start with 'fo' Without knowing that "foo" is a path, the message seems wrong. If it said something like "Path 'foo' does not start with part 'fo'", it would be clearer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 14:55:37 2014 From: report at bugs.python.org (Chris Jerdonek) Date: Thu, 18 Dec 2014 13:55:37 +0000 Subject: [issue19918] PureWindowsPath.relative_to() is not case insensitive In-Reply-To: <1386414151.7.0.591578690469.issue19918@psf.upfronthosting.co.za> Message-ID: <1418910937.47.0.241789430839.issue19918@psf.upfronthosting.co.za> Chris Jerdonek added the comment: Was this also fixed for Mac OS X? Mac OS X is also case-insensitive by default, and on Python 3.4.2 I'm getting: >>> Path("Foo").relative_to("foo") Traceback (most recent call last): File "", line 1, in File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/pathlib.py", line 806, in relative_to .format(str(self), str(formatted))) ValueError: 'Foo' does not start with 'foo' ---------- nosy: +chris.jerdonek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 15:17:33 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 18 Dec 2014 14:17:33 +0000 Subject: [issue23079] os.path.normcase documentation confusing In-Reply-To: <1418904131.32.0.416083778815.issue23079@psf.upfronthosting.co.za> Message-ID: <1418912253.2.0.436670845171.issue23079@psf.upfronthosting.co.za> R. David Murray added the comment: Or would s/case-insensitive/not case-preserving/ be more accurate? (Well, you'd probably rewrite the sentence to eliminate the 'not'). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 15:21:01 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 18 Dec 2014 14:21:01 +0000 Subject: [issue21071] struct.Struct.format is bytes, but should be str In-Reply-To: <1395856133.5.0.672707015318.issue21071@psf.upfronthosting.co.za> Message-ID: <1418912461.23.0.157153983738.issue21071@psf.upfronthosting.co.za> R. David Murray added the comment: A backward compatibility break would certainly need to be discussed, IMO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 15:46:41 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 18 Dec 2014 14:46:41 +0000 Subject: [issue23079] os.path.normcase documentation confusing In-Reply-To: <1418912253.2.0.436670845171.issue23079@psf.upfronthosting.co.za> Message-ID: <1583671.jtY2RXP0F0@raxxla> Serhiy Storchaka added the comment: > Or would s/case-insensitive/not case-preserving/ be more accurate? (Well, > you'd probably rewrite the sentence to eliminate the 'not'). This would not be more accurate because behavior depends from OS, not from file system. On Unix/Linux your can mount case-insensitive filesystem, but normcase() doesn't know anything about this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 16:00:05 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 18 Dec 2014 15:00:05 +0000 Subject: [issue19918] PureWindowsPath.relative_to() is not case insensitive In-Reply-To: <1386414151.7.0.591578690469.issue19918@psf.upfronthosting.co.za> Message-ID: <1418914805.19.0.777076650854.issue19918@psf.upfronthosting.co.za> Antoine Pitrou added the comment: pathlib is case-sensitive under OS X (under any non-Windows platform actually). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 16:06:24 2014 From: report at bugs.python.org (Polux Moon) Date: Thu, 18 Dec 2014 15:06:24 +0000 Subject: [issue23083] sys.exit with bool parameter Message-ID: <1418915184.17.0.474799432406.issue23083@psf.upfronthosting.co.za> New submission from Polux Moon: when using a bool as parameter implementation (2.7) behave like: sys.exit(True) <=> sys.exit(1) sys.exit(False) <=> sys.exit(0) so the bool indicate if the termination is abnormal following the doc it should be equivalent to sys.exit(1) in all cases if we assume the implementation is right, the doc should describe the behavior for boolean input ---------- assignee: docs at python components: Documentation messages: 232883 nosy: Polux.Moon, docs at python priority: normal severity: normal status: open title: sys.exit with bool parameter type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 16:15:53 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 18 Dec 2014 15:15:53 +0000 Subject: [issue23083] sys.exit with bool parameter In-Reply-To: <1418915184.17.0.474799432406.issue23083@psf.upfronthosting.co.za> Message-ID: <1418915753.99.0.457821782871.issue23083@psf.upfronthosting.co.za> R. David Murray added the comment: >>> issubclass(bool, int) True >>> True == 1 True [41846 refs] >>> False == 0 True This is fundamental to Python, so it is not obvious that it is a good idea to mention bool explicitly in the sys.exit docs. Perhaps we could change it to say "int (or an int subclass such as bool)". ---------- nosy: +r.david.murray versions: -Python 3.2, Python 3.3, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 16:17:02 2014 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 18 Dec 2014 15:17:02 +0000 Subject: [issue23083] sys.exit with bool parameter In-Reply-To: <1418915184.17.0.474799432406.issue23083@psf.upfronthosting.co.za> Message-ID: <1418915822.02.0.579098705141.issue23083@psf.upfronthosting.co.za> Eric V. Smith added the comment: I'm not sure this should be documented. It follows from int and bool equivalence. Plus, I consider it an anti-pattern. We don't want to document everywhere you can pass a bool where an int is called for. That's thousands of places. ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 16:20:44 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 18 Dec 2014 15:20:44 +0000 Subject: [issue23083] sys.exit with bool parameter In-Reply-To: <1418915184.17.0.474799432406.issue23083@psf.upfronthosting.co.za> Message-ID: <1418916044.98.0.987816091523.issue23083@psf.upfronthosting.co.za> R. David Murray added the comment: Hmm. Good point about the anti-pattern. I agree that it is probably best to leave the docs as they are. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 16:37:44 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 18 Dec 2014 15:37:44 +0000 Subject: [issue19104] pprint produces invalid output for long strings In-Reply-To: <1380289250.98.0.0529515271695.issue19104@psf.upfronthosting.co.za> Message-ID: <1418917064.37.0.745370488043.issue19104@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +needs review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 16:40:34 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 18 Dec 2014 15:40:34 +0000 Subject: [issue22896] Don't use PyObject_As*Buffer() functions In-Reply-To: <1416319375.33.0.739222572648.issue22896@psf.upfronthosting.co.za> Message-ID: <1418917234.66.0.785533462095.issue22896@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +needs review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 16:40:46 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 18 Dec 2014 15:40:46 +0000 Subject: [issue23001] Accept mutable bytes-like objects In-Reply-To: <1417875906.64.0.311564166909.issue23001@psf.upfronthosting.co.za> Message-ID: <1418917246.8.0.617569382971.issue23001@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +needs review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 16:49:09 2014 From: report at bugs.python.org (Piotr Dobrogost) Date: Thu, 18 Dec 2014 15:49:09 +0000 Subject: [issue6792] Distutils-based installer does not detect 64bit versions of Python In-Reply-To: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za> Message-ID: <1418917749.04.0.941199515553.issue6792@psf.upfronthosting.co.za> Changes by Piotr Dobrogost : ---------- nosy: +piotr.dobrogost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 16:58:06 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 18 Dec 2014 15:58:06 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1418918286.0.0.469452005046.issue22995@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is sample patch which adds two restrictions. Default reduce method for protocol >= 2 will forbid pickling objects: 1) When tp_new == NULL. 2) Builtins without any of pickle-related methods: __getnewargs_ex__, __getnewargs__ or __getstate__. Are there any other ideas? ---------- components: +Interpreter Core stage: -> patch review type: -> enhancement versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 16:58:46 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 18 Dec 2014 15:58:46 +0000 Subject: [issue23083] sys.exit with bool parameter In-Reply-To: <1418915184.17.0.474799432406.issue23083@psf.upfronthosting.co.za> Message-ID: <1418918326.73.0.868465524982.issue23083@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I agree that the docs are best as-is. ---------- nosy: +rhettinger resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 16:58:48 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 18 Dec 2014 15:58:48 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1418918328.39.0.287053629623.issue22995@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch Added file: http://bugs.python.org/file37494/pickle_restrictions.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 17:23:58 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 18 Dec 2014 16:23:58 +0000 Subject: [issue22113] memoryview and struct.pack_into In-Reply-To: <1406795471.99.0.191583556895.issue22113@psf.upfronthosting.co.za> Message-ID: <1418919838.6.0.173619943056.issue22113@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +needs review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 17:34:38 2014 From: report at bugs.python.org (mdcb) Date: Thu, 18 Dec 2014 16:34:38 +0000 Subject: [issue23084] nanosecond support Message-ID: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za> New submission from mdcb: nanosecond support has been discussed at length on python-dev and issue 15443. POSIX.1b defines a struct timespec that is commonly used in C, and seems a good candidate to add core nanosecond support. kernel's time-related structs typically end up in the time module. Attached patch defines a new type struct_timespec for the time module. A new capsule exports the type along with to/from converters - opening a bridge for C, and for example the datetime module. ---------- components: Library (Lib) files: time.struct_timespec.patch hgrepos: 289 keywords: patch messages: 232889 nosy: mdcb808 at gmail.com priority: normal severity: normal status: open title: nanosecond support type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file37495/time.struct_timespec.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 17:44:20 2014 From: report at bugs.python.org (mdcb) Date: Thu, 18 Dec 2014 16:44:20 +0000 Subject: [issue23084] nanosecond support In-Reply-To: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za> Message-ID: <1418921060.13.0.371903765337.issue23084@psf.upfronthosting.co.za> Changes by mdcb : ---------- hgrepos: -289 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 17:49:51 2014 From: report at bugs.python.org (Ethan Furman) Date: Thu, 18 Dec 2014 16:49:51 +0000 Subject: [issue23084] nanosecond support In-Reply-To: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za> Message-ID: <1418921391.42.0.15242854533.issue23084@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +belopolsky, ethan.furman, lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 18:13:24 2014 From: report at bugs.python.org (Gustavo Temple) Date: Thu, 18 Dec 2014 17:13:24 +0000 Subject: [issue23085] update internal libffi copy to 3.1 Message-ID: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za> New submission from Gustavo Temple: Link to the file: https://github.com/gustavotemple/cpython/pull/2.diff Link to the changes: https://github.com/gustavotemple/cpython/pull/2/commits ---------- components: ctypes files: libffi.patch keywords: patch messages: 232890 nosy: doko, gustavotemple, meador.inge priority: normal severity: normal status: open title: update internal libffi copy to 3.1 versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37496/libffi.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 18:17:56 2014 From: report at bugs.python.org (Matthias Klose) Date: Thu, 18 Dec 2014 17:17:56 +0000 Subject: [issue23085] update internal libffi copy to 3.1 In-Reply-To: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za> Message-ID: <1418923076.54.0.387493988605.issue23085@psf.upfronthosting.co.za> Matthias Klose added the comment: some issues: - the local change for Windows still needs upstream forwarding. Steve, any progress on this? - the libffi.diff is not updated (including Steve's changes) - this should be applied to 2.7 as well. ---------- nosy: +steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 18:22:23 2014 From: report at bugs.python.org (Gustavo Temple) Date: Thu, 18 Dec 2014 17:22:23 +0000 Subject: [issue23085] update internal libffi copy to 3.2.1 In-Reply-To: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za> Message-ID: <1418923343.27.0.940641208879.issue23085@psf.upfronthosting.co.za> Changes by Gustavo Temple : ---------- title: update internal libffi copy to 3.1 -> update internal libffi copy to 3.2.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 18:45:15 2014 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 18 Dec 2014 17:45:15 +0000 Subject: [issue23083] sys.exit with bool parameter In-Reply-To: <1418915184.17.0.474799432406.issue23083@psf.upfronthosting.co.za> Message-ID: <1418924715.74.0.535507532773.issue23083@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 18:57:20 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 18 Dec 2014 17:57:20 +0000 Subject: [issue23084] nanosecond support In-Reply-To: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za> Message-ID: <1418925440.08.0.536145940404.issue23084@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: See also discussion in #9079, #14127 and #14180. At some point there was some resistance to use capsule mechanism to share code within stdlib and the functions that were shared between time and datetime modules were moved to the core. I am -1 on adding struct_timespec type. POSIX defines [1] the following functions that take struct timespec: int clock_getres(clockid_t, struct timespec *); int clock_gettime(clockid_t, struct timespec *); int clock_settime(clockid_t, const struct timespec *); int nanosleep(const struct timespec *, struct timespec *); and a pair of timer functions that take timespec indirectly through itimerspec struct: int timer_gettime(timer_t, struct itimerspec *); int timer_settime(timer_t, int, const struct itimerspec *, struct itimerspec *); In addition, struct stat provides timespec members on some systems. There was a long discussion on how to represent high precession time in Python. PEP 410 proposed using the decimal type and it was rejected. Nanosecond support was ultimately added to os.struct() by adding integer st_{a,m,c}time_ns members. See #14127. Interface to nanosleep is already available via time.sleep() function. If we ever need higher precision sleep we can add time.nanosleep() that takes time in nanoseconds. We have a similar story with time.clock(). Overall, the proposed type is much less convenient than integer nanoseconds because it does not support arithmetics. In any case, I think it is premature to discuss adding a new type before some functions are proposed that would produce or consume instances of this type. [1] http://pubs.opengroup.org/onlinepubs/7908799/xsh/time.h.html ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 18:59:28 2014 From: report at bugs.python.org (Gustavo Temple) Date: Thu, 18 Dec 2014 17:59:28 +0000 Subject: [issue23085] update internal libffi copy to 3.2.1 In-Reply-To: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za> Message-ID: <1418925568.96.0.524672739293.issue23085@psf.upfronthosting.co.za> Gustavo Temple added the comment: @doko, sorry, but what are the Steve's changes? The issue #22733? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 19:12:48 2014 From: report at bugs.python.org (Ethan Furman) Date: Thu, 18 Dec 2014 18:12:48 +0000 Subject: [issue23084] nanosecond support In-Reply-To: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za> Message-ID: <1418926368.75.0.530936252386.issue23084@psf.upfronthosting.co.za> Ethan Furman added the comment: I haven't reviewed the patch yet, but I believe the intent is not for better sleep support, but simply to be able to create and record time data which contains nano-seconds. python-dev discussion here: https://mail.python.org/pipermail/python-dev/2014-December/137522.html As far as producing and consuming: time() could be used to produce them, and then any user-function that cares could consume them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 19:21:31 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 18 Dec 2014 18:21:31 +0000 Subject: [issue23084] nanosecond support In-Reply-To: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za> Message-ID: <1418926891.15.0.313858062064.issue23084@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > .. the intent is not for better sleep support, but simply > to be able to create and record time data which contains nano-seconds. Can you describe a specific use-case? What's the advantage of the proposed time.struct_timespec over say >>> timespec = namedtuple('timespec', 'sec,nsec') ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 19:25:18 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 18 Dec 2014 18:25:18 +0000 Subject: [issue23084] nanosecond support In-Reply-To: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za> Message-ID: <1418927118.68.0.162060497817.issue23084@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > time() could be used to produce them How? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 19:43:39 2014 From: report at bugs.python.org (Steve Dower) Date: Thu, 18 Dec 2014 18:43:39 +0000 Subject: [issue23085] update internal libffi copy to 3.2.1 In-Reply-To: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za> Message-ID: <1418928219.0.0.169269513607.issue23085@psf.upfronthosting.co.za> Steve Dower added the comment: I think Matthias is referring to #20160, but as far as I could tell libffi is multiple versions ahead of the version in Python and already has the fixes. I was told to wait for it to be submitted/accepted upstream, so I've been waiting :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 19:44:07 2014 From: report at bugs.python.org (Steve Dower) Date: Thu, 18 Dec 2014 18:44:07 +0000 Subject: [issue21236] patch to use cabinet.lib instead of fci.lib (fixes build with Windows SDK 8.0) In-Reply-To: <1397576015.94.0.746613486015.issue21236@psf.upfronthosting.co.za> Message-ID: <1418928247.68.0.280463820771.issue21236@psf.upfronthosting.co.za> Steve Dower added the comment: This was fixed with #22919. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 19:52:07 2014 From: report at bugs.python.org (Matthias Klose) Date: Thu, 18 Dec 2014 18:52:07 +0000 Subject: [issue23085] update internal libffi copy to 3.2.1 In-Reply-To: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za> Message-ID: <1418928727.71.0.469974668077.issue23085@psf.upfronthosting.co.za> Matthias Klose added the comment: you should actively drive upstream integration, and ping patches if they are not addressed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 20:00:52 2014 From: report at bugs.python.org (Steve Dower) Date: Thu, 18 Dec 2014 19:00:52 +0000 Subject: [issue23085] update internal libffi copy to 3.2.1 In-Reply-To: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za> Message-ID: <1418929252.34.0.381001639411.issue23085@psf.upfronthosting.co.za> Steve Dower added the comment: As I mentioned on the other post, libffi's current version bears no relation to what we have in CPython, so the patches don't apply. I'm not planning on rewriting CPython patches so that they will apply to libffi, nor do I intend to replace our current version of it with libffi's latest. There's nothing to send upstream. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 20:47:16 2014 From: report at bugs.python.org (Gustavo Temple) Date: Thu, 18 Dec 2014 19:47:16 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1418932036.74.0.877947815628.issue22038@psf.upfronthosting.co.za> Changes by Gustavo Temple : Added file: http://bugs.python.org/file37497/atomicv3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 20:47:58 2014 From: report at bugs.python.org (Gustavo Temple) Date: Thu, 18 Dec 2014 19:47:58 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1418932078.69.0.789355276121.issue22038@psf.upfronthosting.co.za> Gustavo Temple added the comment: @haypo, done: atomicv3.patch ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 21:00:14 2014 From: report at bugs.python.org (Gustavo Temple) Date: Thu, 18 Dec 2014 20:00:14 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1418932814.88.0.177644298179.issue22038@psf.upfronthosting.co.za> Changes by Gustavo Temple : Removed file: http://bugs.python.org/file37497/atomicv3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 21:00:46 2014 From: report at bugs.python.org (Gustavo Temple) Date: Thu, 18 Dec 2014 20:00:46 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1418932846.53.0.0984718417334.issue22038@psf.upfronthosting.co.za> Changes by Gustavo Temple : Added file: http://bugs.python.org/file37498/atomicv3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 21:05:07 2014 From: report at bugs.python.org (Gustavo Temple) Date: Thu, 18 Dec 2014 20:05:07 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1418933107.22.0.517559257252.issue22038@psf.upfronthosting.co.za> Changes by Gustavo Temple : Removed file: http://bugs.python.org/file37498/atomicv3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 21:05:46 2014 From: report at bugs.python.org (Gustavo Temple) Date: Thu, 18 Dec 2014 20:05:46 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1418933146.86.0.5101844768.issue22038@psf.upfronthosting.co.za> Changes by Gustavo Temple : Added file: http://bugs.python.org/file37499/atomicv3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 21:13:53 2014 From: report at bugs.python.org (Gustavo Temple) Date: Thu, 18 Dec 2014 20:13:53 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1418933633.13.0.938104707298.issue22038@psf.upfronthosting.co.za> Changes by Gustavo Temple : Removed file: http://bugs.python.org/file37499/atomicv3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 21:14:03 2014 From: report at bugs.python.org (Gustavo Temple) Date: Thu, 18 Dec 2014 20:14:03 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1418933643.14.0.567361344642.issue22038@psf.upfronthosting.co.za> Changes by Gustavo Temple : Added file: http://bugs.python.org/file37500/atomicv3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 21:17:05 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 18 Dec 2014 20:17:05 +0000 Subject: [issue23084] nanosecond support In-Reply-To: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za> Message-ID: <1418933825.25.0.818862936188.issue23084@psf.upfronthosting.co.za> STINNER Victor added the comment: See the issue #22117 which basically implement the PEP 410, but only for private C API. The idea is to avoid loss of precision caused by the float type when it is possible. For example, it would be possible for datetime.datetime.now() to avoid the float time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 21:28:15 2014 From: report at bugs.python.org (mike bayer) Date: Thu, 18 Dec 2014 20:28:15 +0000 Subject: [issue22956] Improved support for prepared SQL statements In-Reply-To: <1417095519.92.0.197896622793.issue22956@psf.upfronthosting.co.za> Message-ID: <1418934495.92.0.77502655115.issue22956@psf.upfronthosting.co.za> Changes by mike bayer : ---------- nosy: +zzzeek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 21:30:12 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 18 Dec 2014 20:30:12 +0000 Subject: [issue23085] update internal libffi copy to 3.2.1 In-Reply-To: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za> Message-ID: <1418934612.78.0.771009524478.issue23085@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Will this also fix http://bugs.python.org/issue23042 ? ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 21:41:46 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 18 Dec 2014 20:41:46 +0000 Subject: [issue23086] Add start and stop parameters to the Sequence.index() ABC mixin method Message-ID: <1418935306.72.0.256960321979.issue23086@psf.upfronthosting.co.za> New submission from Raymond Hettinger: Currently, the Sequence ABC doesn't support start and stop arguments for the index() method which limits its usefulness in doing repeated searches (iterating over a target value) and which limits it substitutablity for various concrete sequences such as tuples, lists, strings, bytes, bytearrays, etc. >>> help(Sequence.index) Help on method index in module _abcoll: index(self, value) unbound _abcoll.Sequence method S.index(value) -> integer -- return first index of value. Raises ValueError if the value is not present. >>> help(list.index) Help on method_descriptor: index(...) L.index(value, [start, [stop]]) -> integer -- return first index of value. Raises ValueError if the value is not present. >>> help(str.index) Help on method_descriptor: index(...) S.index(sub [,start [,end]]) -> int Like S.find() but raise ValueError when the substring is not found. >>> help(tuple.index) Help on method_descriptor: index(...) T.index(value, [start, [stop]]) -> integer -- return first index of value. Raises ValueError if the value is not present. >>> help(bytes.index) Help on method_descriptor: index(...) S.index(sub [,start [,end]]) -> int Like S.find() but raise ValueError when the substring is not found. >>> help(bytearray.index) Help on method_descriptor: index(...) B.index(sub [,start [,end]]) -> int Like B.find() but raise ValueError when the subsection is not found. ---------- assignee: rhettinger components: Library (Lib) messages: 232904 nosy: rhettinger priority: normal severity: normal status: open title: Add start and stop parameters to the Sequence.index() ABC mixin method versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 21:43:55 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 18 Dec 2014 20:43:55 +0000 Subject: [issue23084] nanosecond support In-Reply-To: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za> Message-ID: <1418935435.35.0.807157211786.issue23084@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > it would be possible for datetime.datetime.now() > to avoid the float time. C implementation of datetime.now() does not rely on float time, so this is only an issue for the Python implementation. Moreover, as long as datetime keeps its microsecond resolution, float timestamps are good until the next century. In any case, I don't see how struct_timespec is better than integer expressing time in nanoseconds. We can implement time.nanotime() returning an int without having to invent a new type. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 22:17:24 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 18 Dec 2014 21:17:24 +0000 Subject: [issue23084] nanosecond support In-Reply-To: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za> Message-ID: <1418937444.52.0.371939435165.issue23084@psf.upfronthosting.co.za> STINNER Victor added the comment: > C implementation of datetime.now() does not rely on float time, so this is only an issue for the Python implementation. Ah yes, but there is another technical issue that I'm trying to address in the issue #22117: datetime.datetime.now() is implemented with _PyTime_gettimeofday() which has a resolution of 1 microsecond, even it is now implemented with clock_gettime(CLOCK_REALTIME) which has a resolution of 1 nanoecond. On Linux, the effictive resolution of clock_gettime(CLOCK_REALTIME) is better than 1 microsecond, around 1/4 microsecond (250 nanosecond). > Overall, the proposed type is much less convenient than integer nanoseconds because it does not support arithmetics. I'm working on using a number of nanoseconds using an integer type. It's just a signed 64-bit bit integer. If we decide to support nanosecond resolution in Python, a integer number of nanosecond may be enough. But this issue looks like the PEP 410 which was rejected. If you are motivated enough, you may update the PEP and write a new one. But first, read again the PEP and the discussion explaining why it was rejected. Basically, the loss of precision is very rare (or may not occur) in practice and the PEP 410 required to modify a lot of functions. Remember that the effictive resolution of time.time() on Windows is just 1 millisecond (0.001 second)... See the PEP 418 for many numbers, list of hardware clocks, operating system, etc. https://www.python.org/dev/peps/pep-0418/#system-time ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 23:27:04 2014 From: report at bugs.python.org (Keith Chewning) Date: Thu, 18 Dec 2014 22:27:04 +0000 Subject: [issue23087] Exec variable not found error Message-ID: <1418941624.73.0.497940658508.issue23087@psf.upfronthosting.co.za> New submission from Keith Chewning: If I %paste this code into an ipython shell the test passes. If this is saved to a file DictTest.py and run with ./DictTest.py -m the test fails. with the error name 'keys' is not defined If the variable keys is made global, as is suggested in the comment, the test passes with both methods of execution. Is there a scoping issue with executing this as a script? I am using version: '3.4.1 |Anaconda 2.1.0 (64-bit)| (default, Sep 10 2014, 17:10:18) \n[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)]' import unittest class DictTest(unittest.TestCase): def test_dict_comprehension(self): code = """ d = {'a':1, 'b':2, 'c':3, 'd':4} # global keys # UNCOMMENT FOR TEST TO PASS keys = ['a', 'd'] items = d.items() nd = {k: v for k, v in items if k in keys} print('>>> ' + str(nd)) """ try: exec(code) except Exception as e: self.assertTrue(False, "Exec ERROR>>> %s" % e) def main(): dt = DictTest() dt.test_dict_comprehension() if __name__ =='__main__':main() ---------- messages: 232907 nosy: Keith.Chewning priority: normal severity: normal status: open title: Exec variable not found error type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 23:41:04 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 18 Dec 2014 22:41:04 +0000 Subject: [issue23084] nanosecond support In-Reply-To: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za> Message-ID: <1418942464.12.0.410125636872.issue23084@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Would anyone object if I rename this issue to "Expose C struct timespec in time module"? The current title is way too broad. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 23:43:27 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 18 Dec 2014 22:43:27 +0000 Subject: [issue18590] 'Search' and 'Replace' dialogs don't work on quoted text in Windows In-Reply-To: <1375128565.7.0.113615028691.issue18590@psf.upfronthosting.co.za> Message-ID: <1418942607.39.0.489370069062.issue18590@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I should note that in msg225543 of #22179, I verified that there is a problem in Replace for highlighting found text within quotes, as well as in keywords, until the dialog is closed. On the other hand, the same text is hihglighted in identifiers, plain code, buildin names, and comments. This might be an issue of stacking order. Merely using replace.show_hit in search also will not solve this. ---------- assignee: -> terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 18 23:58:18 2014 From: report at bugs.python.org (Ethan Furman) Date: Thu, 18 Dec 2014 22:58:18 +0000 Subject: [issue23084] nanosecond support In-Reply-To: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za> Message-ID: <1418943498.1.0.197090924655.issue23084@psf.upfronthosting.co.za> Ethan Furman added the comment: Just keep the word nanasecond in there somewhere, as that is the motivating purpose behind the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 00:08:08 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 18 Dec 2014 23:08:08 +0000 Subject: [issue23087] Exec variable not found error In-Reply-To: <1418941624.73.0.497940658508.issue23087@psf.upfronthosting.co.za> Message-ID: <1418944088.11.0.460748294232.issue23087@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 00:19:22 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 18 Dec 2014 23:19:22 +0000 Subject: [issue23084] Expose C struct timespec (nanosecond resolution) in time module In-Reply-To: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za> Message-ID: <1418944762.23.0.98950427932.issue23084@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- title: nanosecond support -> Expose C struct timespec (nanosecond resolution) in time module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 00:28:54 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 18 Dec 2014 23:28:54 +0000 Subject: [issue23084] Expose C struct timespec (nanosecond resolution) in time module In-Reply-To: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za> Message-ID: <1418945334.7.0.671103752969.issue23084@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I would say that rejection note for PEP 410 [1] and the implementation of st_[amc]time_ns fields in os.stats() have established a de-facto standard for representing nanosecond resolution timestamps in Python. I think this proposal should be rejected. [1] https://mail.python.org/pipermail/python-dev/2012-February/116837.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 00:49:04 2014 From: report at bugs.python.org (Martin Panter) Date: Thu, 18 Dec 2014 23:49:04 +0000 Subject: [issue23001] Accept mutable bytes-like objects In-Reply-To: <1417875906.64.0.311564166909.issue23001@psf.upfronthosting.co.za> Message-ID: <1418946544.02.0.692200422926.issue23001@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 00:49:37 2014 From: report at bugs.python.org (Ethan Furman) Date: Thu, 18 Dec 2014 23:49:37 +0000 Subject: [issue23084] Expose C struct timespec (nanosecond resolution) in time module In-Reply-To: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za> Message-ID: <1418946577.11.0.483547422566.issue23084@psf.upfronthosting.co.za> Ethan Furman added the comment: If I am reading data from an external device that has nanosecond resolution, how would I create such a time stamp in Python right now? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 00:52:15 2014 From: report at bugs.python.org (mdcb) Date: Thu, 18 Dec 2014 23:52:15 +0000 Subject: [issue23084] Expose C struct timespec (nanosecond resolution) in time module In-Reply-To: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za> Message-ID: <1418946735.5.0.433892883324.issue23084@psf.upfronthosting.co.za> mdcb added the comment: I'm going to be my own devil's advocate: PyLong_FromLong ... Thanks for all the links, I hadn't realized there was so much background to the issue, there is some good reading there too. you've changed the title now, but in fact the intention was the other aspect, core nanosecond support in python. I just happened to pick timespec because it does the job and is reasonably widespread. reading all this, and threading lighlty, I was playing with class timestamp(int): pass """measure of time expressed as a number of nanoseconds""" but that seems to loose the type information after doing arithmetics x=timestamp(10) y=timestamp(20) type(x+y) gives ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 00:55:53 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 18 Dec 2014 23:55:53 +0000 Subject: [issue23084] Expose C struct timespec (nanosecond resolution) in time module In-Reply-To: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za> Message-ID: <1418946953.67.0.982644250641.issue23084@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 00:57:08 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 18 Dec 2014 23:57:08 +0000 Subject: [issue23042] Python 2.7.9 ctypes module doesn't build on FreeBSD x86 In-Reply-To: <1418416859.8.0.212660740366.issue23042@psf.upfronthosting.co.za> Message-ID: <1418947028.21.0.83575179141.issue23042@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 00:57:09 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 18 Dec 2014 23:57:09 +0000 Subject: [issue23084] Expose C struct timespec (nanosecond resolution) in time module In-Reply-To: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za> Message-ID: <1418947029.03.0.486669276795.issue23084@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > If I am reading data from an external device that has nanosecond > resolution, how would I create such a time stamp in Python right now? seconds * 10**9 + nanoseconds (translated to C API if necessary) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 00:57:46 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 18 Dec 2014 23:57:46 +0000 Subject: [issue23085] update internal libffi copy to 3.2.1 In-Reply-To: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za> Message-ID: <1418947066.55.0.638728047521.issue23085@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 01:00:11 2014 From: report at bugs.python.org (mdcb) Date: Fri, 19 Dec 2014 00:00:11 +0000 Subject: [issue23084] Expose C struct timespec (nanosecond resolution) in time module In-Reply-To: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za> Message-ID: <1418947211.27.0.525706469477.issue23084@psf.upfronthosting.co.za> mdcb added the comment: can we change back the title because in fact, exposing struct timespec wasn't really the intention (but keep the patch if you want it!) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 01:02:50 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 19 Dec 2014 00:02:50 +0000 Subject: [issue23087] Exec variable not found error In-Reply-To: <1418941624.73.0.497940658508.issue23087@psf.upfronthosting.co.za> Message-ID: <1418947370.69.0.578151882314.issue23087@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 01:03:33 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 19 Dec 2014 00:03:33 +0000 Subject: [issue23084] Expose C struct timespec (nanosecond resolution) in time module In-Reply-To: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za> Message-ID: <1418947413.06.0.199652279322.issue23084@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > but that seems to loose the type information after doing arithmetics Hear, hear. See #2267. If you find out why Python was designed this way - let me know. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 01:04:55 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 19 Dec 2014 00:04:55 +0000 Subject: [issue22038] Implement atomic operations on non-x86 platforms In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za> Message-ID: <1418947495.74.0.299554604284.issue22038@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 01:05:47 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 19 Dec 2014 00:05:47 +0000 Subject: [issue22113] memoryview and struct.pack_into In-Reply-To: <1406795471.99.0.191583556895.issue22113@psf.upfronthosting.co.za> Message-ID: <1418947547.27.0.581675229263.issue22113@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 01:07:55 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 19 Dec 2014 00:07:55 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1418947675.8.0.464345057681.issue22995@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 01:08:30 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 19 Dec 2014 00:08:30 +0000 Subject: [issue18590] 'Search' and 'Replace' dialogs don't work on quoted text in Windows In-Reply-To: <1375128565.7.0.113615028691.issue18590@psf.upfronthosting.co.za> Message-ID: <1418947710.39.0.941891665809.issue18590@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- dependencies: -Idle. Search dialog found text not highlited on Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 01:09:20 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 19 Dec 2014 00:09:20 +0000 Subject: [issue22179] Idle. Search dialog found text not highlited on Windows In-Reply-To: <1407672062.65.0.813743837574.issue22179@psf.upfronthosting.co.za> Message-ID: <1418947760.11.0.806804106545.issue22179@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The first # comment above should be "On Windows, the selection highlight is *not* visible while the modal dialog is open." This bug was, in a sense, introduced by #17511, which kept the dialog open after [Find] is pressed, instead of closing it immediately. About the last comment: the selection tag does not need to be applied until closing. (Ditto for find/replace.) The missing found highlighting for Replace is issue #18590 ---------- assignee: -> terry.reedy dependencies: +'Search' and 'Replace' dialogs don't work on quoted text in Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 01:11:02 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 19 Dec 2014 00:11:02 +0000 Subject: [issue19104] pprint produces invalid output for long strings In-Reply-To: <1380289250.98.0.0529515271695.issue19104@psf.upfronthosting.co.za> Message-ID: <1418947862.37.0.927049021663.issue19104@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 01:16:34 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 19 Dec 2014 00:16:34 +0000 Subject: [issue23084] Expose C struct timespec (nanosecond resolution) in time module In-Reply-To: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za> Message-ID: <1418948194.82.0.359271929615.issue23084@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > can we change back the title because in fact Please don't. If you would like to discuss general ideas - the right forum would be the "python-ideas" mailing list. We have no shortage of issue numbers: once you have another specific proposal - feel free to open a new issue. If you withdraw your proposal to apply time.struct_timespec.patch, I will close this issue. ---------- assignee: -> belopolsky resolution: -> rejected stage: -> resolved status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 01:17:39 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 19 Dec 2014 00:17:39 +0000 Subject: [issue16349] Document whether it's safe to use bytes for struct format string In-Reply-To: <1351428222.6.0.656645524198.issue16349@psf.upfronthosting.co.za> Message-ID: <1418948259.29.0.710014545893.issue16349@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 01:17:51 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 19 Dec 2014 00:17:51 +0000 Subject: [issue21071] struct.Struct.format is bytes, but should be str In-Reply-To: <1395856133.5.0.672707015318.issue21071@psf.upfronthosting.co.za> Message-ID: <1418948271.17.0.966919152059.issue21071@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 01:19:36 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 19 Dec 2014 00:19:36 +0000 Subject: [issue8934] aifc should use str instead of bytes (wave, sunau compatibility) In-Reply-To: <1275936965.71.0.27334704307.issue8934@psf.upfronthosting.co.za> Message-ID: <1418948376.21.0.888160949503.issue8934@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 01:30:29 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 19 Dec 2014 00:30:29 +0000 Subject: [issue23076] list(pathlib.Path().glob("")) fails with IndexError In-Reply-To: <1418860780.4.0.558535328721.issue23076@psf.upfronthosting.co.za> Message-ID: <1418949029.79.0.0255136115903.issue23076@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: >>> list(pathlib.Path().glob("")) Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.5/pathlib.py", line 999, in glob selector = _make_selector(tuple(pattern_parts)) File "/usr/lib64/python3.5/functools.py", line 458, in wrapper result = user_function(*args, **kwds) File "/usr/lib64/python3.5/pathlib.py", line 403, in _make_selector pat = pattern_parts[0] IndexError: tuple index out of range >>> ---------- assignee: -> pitrou nosy: +Arfrever, pitrou title: path.glob("") fails with IndexError -> list(pathlib.Path().glob("")) fails with IndexError versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 01:33:19 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 19 Dec 2014 00:33:19 +0000 Subject: [issue23082] pathlib relative_to() can give confusing error message In-Reply-To: <1418909839.25.0.648032443428.issue23082@psf.upfronthosting.co.za> Message-ID: <1418949199.7.0.717376870151.issue23082@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- assignee: -> pitrou nosy: +Arfrever, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 01:40:59 2014 From: report at bugs.python.org (mdcb) Date: Fri, 19 Dec 2014 00:40:59 +0000 Subject: [issue23084] Expose C struct timespec (nanosecond resolution) in time module In-Reply-To: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za> Message-ID: <1418949659.65.0.205046989771.issue23084@psf.upfronthosting.co.za> mdcb added the comment: I'm fine my patch doesn't resolve the "nanosecond support", but that doesn't mean the issue is closed per say. Ref. to PEP410 rejection and de facto standard seems a bit expeditive. assuming it worked, this would somewhat be more agreeable ? >class timestamp(int): pass > """measure of time expressed as a number of nanoseconds""" ---------- resolution: rejected -> status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 01:48:05 2014 From: report at bugs.python.org (mdcb) Date: Fri, 19 Dec 2014 00:48:05 +0000 Subject: [issue23084] Expose C struct timespec (nanosecond resolution) in time module In-Reply-To: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za> Message-ID: <1418950085.68.0.944517386197.issue23084@psf.upfronthosting.co.za> mdcb added the comment: firefox did something and changed some fields I did not intend to. I'm trying to undo that now. ---------- resolution: -> rejected status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 02:26:16 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 19 Dec 2014 01:26:16 +0000 Subject: [issue23084] Expose C struct timespec (nanosecond resolution) in time module In-Reply-To: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za> Message-ID: <1418952376.68.0.0106466269913.issue23084@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: "nanosecond support [in Python]" is a PEP-size topic. As Victor suggested, "If you are motivated enough, you may update the PEP and write a new one." The tracker does not provide a sufficiently large forum to discuss "nanosecond support" in full generality. >assuming it worked, this would somewhat be more agreeable ? >class timestamp(int): pass > """measure of time expressed as a number of nanoseconds""" By "working", I assume you mean "if arithmetic operations worked as expected." In this case you are reinventing mxDateTime [1], which is similar to stdlib datetime, but supports a much higher resolution. > Ref. to PEP410 rejection and de facto standard seems a bit expeditive. I don't think so. Possibly, I should have referred to PEP 20, as well, but that is usually implicit. We now have two APIs in stdlib that pass nanosecond-resolution timestamps as plain integers: os.stat() and os.utime(). This is not going to change, so for compatibility reasons, any new type would have to be interchangeable with int. In theory, your timestamp subclass would qualify, but what advantage would it give you over plain int? If you start adding functionality to timestamp, you will quickly end up with something that is half-way between int and either datetime or timedelta. [1] http://www.egenix.com/products/python/mxBase/mxDateTime ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 03:05:55 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 19 Dec 2014 02:05:55 +0000 Subject: [issue23080] BoundArguments.arguments should be unordered In-Reply-To: <1418907389.55.0.608772896554.issue23080@psf.upfronthosting.co.za> Message-ID: <1418954755.46.0.821910799979.issue23080@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 03:15:34 2014 From: report at bugs.python.org (Berker Peksag) Date: Fri, 19 Dec 2014 02:15:34 +0000 Subject: [issue23081] Document PySequence_List(o) as equivalent to list(o) In-Reply-To: <1418908520.28.0.480794985208.issue23081@psf.upfronthosting.co.za> Message-ID: <1418955334.69.0.74040759216.issue23081@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag, tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 03:54:26 2014 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 19 Dec 2014 02:54:26 +0000 Subject: [issue23080] BoundArguments.arguments should be unordered In-Reply-To: <1418907389.55.0.608772896554.issue23080@psf.upfronthosting.co.za> Message-ID: <1418957666.87.0.730458285687.issue23080@psf.upfronthosting.co.za> Yury Selivanov added the comment: I'd like to see PEP 468 explicitly rejected or postponed till 3.6 before we make this change in 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 05:23:02 2014 From: report at bugs.python.org (Martin Panter) Date: Fri, 19 Dec 2014 04:23:02 +0000 Subject: [issue22350] nntplib file write failure causes exception from QUIT command In-Reply-To: <1410061219.03.0.0230581897355.issue22350@psf.upfronthosting.co.za> Message-ID: <1418962982.52.0.0302985274096.issue22350@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch with a fix and a test ---------- keywords: +patch Added file: http://bugs.python.org/file37501/fail-close.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 05:42:34 2014 From: report at bugs.python.org (Martin Panter) Date: Fri, 19 Dec 2014 04:42:34 +0000 Subject: [issue23088] Document that PyUnicode_AsUTF8() returns a null-terminated string Message-ID: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za> New submission from Martin Panter: As discussed in msg232863, and later confirmed in the code ---------- assignee: docs at python components: Documentation files: utf8-null.patch keywords: patch messages: 232925 nosy: docs at python, vadmium priority: normal severity: normal status: open title: Document that PyUnicode_AsUTF8() returns a null-terminated string versions: Python 3.4 Added file: http://bugs.python.org/file37502/utf8-null.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 05:53:59 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 19 Dec 2014 04:53:59 +0000 Subject: [issue18590] Found text not always highlighted by Replace dialog In-Reply-To: <1375128565.7.0.113615028691.issue18590@psf.upfronthosting.co.za> Message-ID: <1418964839.56.0.301471546789.issue18590@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am narrowing the scope of this issue to Replace dialogs and widening the scope to output as well as edit windows. The attached patch solves the issue as redefined. (It has a temporary hack to pass the unittests.) For edit windows, the problem is that the default tag stacking order seems to be alphabetical. No tag, 'builtin, 'comment', and 'definition, are followed and dominated by 'hit'; 'keyword' and 'string' come after and dominate 'hit'. The solution is to raise 'hit' to the top. The test (from msg225543), which should be added to htest), is that all 6 'i's in "def i(): this list is 'is' # is not" are both found and highlighted. They are with the patch. For output windows, the problem, mentioned in msg225382, is that the 'hit' tag is configured in ColorDelegator, which is not used in output windows. Ths solution, also mentioned there, is to move the configuration to SearchDialogBase. The path does this and Replace dialog Find work for Output Windows. I tested on Windows. I am 99.9% sure there should be no problem on other systems, but would like confirmation on other systems before or after committing an expanded patch with test changes added. ---------- nosy: +sahutd stage: patch review -> test needed title: 'Search' and 'Replace' dialogs don't work on quoted text in Windows -> Found text not always highlighted by Replace dialog Added file: http://bugs.python.org/file37503/replace_find_hit.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 06:14:30 2014 From: report at bugs.python.org (Martin Panter) Date: Fri, 19 Dec 2014 05:14:30 +0000 Subject: [issue22341] Python 3 crc32 documentation clarifications In-Reply-To: <1409918129.4.0.321897542374.issue22341@psf.upfronthosting.co.za> Message-ID: <1418966070.05.0.526031070029.issue22341@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch that fixes the binascii, zlib.crc32() and adler32() documentation as I suggested. I?m still interested why there are two ways to do a CRC-32, each equally non-obvious as the other. ---------- keywords: +patch Added file: http://bugs.python.org/file37504/crc-sign.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 06:24:10 2014 From: report at bugs.python.org (Martin Panter) Date: Fri, 19 Dec 2014 05:24:10 +0000 Subject: [issue9694] argparse required arguments displayed under "optional arguments" In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za> Message-ID: <1418966650.58.0.259474860247.issue9694@psf.upfronthosting.co.za> Martin Panter added the comment: Updated my patch with a ?version changed? notice ---------- Added file: http://bugs.python.org/file37505/option-internal.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 06:52:28 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 19 Dec 2014 05:52:28 +0000 Subject: [issue18590] Found text not always highlighted by Replace dialog on Windows In-Reply-To: <1375128565.7.0.113615028691.issue18590@psf.upfronthosting.co.za> Message-ID: <1418968348.02.0.538757538749.issue18590@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Additional notes: Sarah's Replace patch consists of the tag raise. I just verified the reason why it works and moved it to the dialog base to include output windows and soon, Search dialogs. Sarah, if you do not provide a 'family' name, I will list you in Misc/ACKS, in alphabetical position, as just 'Sarah'. Or are you already in that file? Currently, Replace dialog Find hits are tagged with both the 'hit' and the 'sel' tag, which does not show on Windows as long as the dialog is the active window, but apparently does on other systems. Raising the hit tag to the top (either patch) means that the visible highlight on other systems will change from 'selected' to 'found' (which are independently configurable in Idle preferences). If this not desired, the patch could be altered to use tag 'hit' on Windows and 'sel' elsewhere; change 'hit' (on Windows) to 'sel' when the dialog is closed; and configure 'hit' to look like 'sel' (so there is no visible change when closing, as on other systems). On Windows, only one slice can be selected and I presume this is true on other systems. If so, a non-'sel' tag is needed on all systems to tag multiple hits. I would like to auto-highlight all hits in grep output windows and add an explicit 'find in current file' option (though it is possible now by adding the file name to the search path). Raymond, I added you as nosy since this is an appearance change issue that you might possibly have an opinion on, and I would prefer getting it before a change is released in January If I am wrong, un-nosy yourself. ---------- nosy: +rhettinger title: Found text not always highlighted by Replace dialog -> Found text not always highlighted by Replace dialog on Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 06:59:49 2014 From: report at bugs.python.org (mdcb) Date: Fri, 19 Dec 2014 05:59:49 +0000 Subject: [issue23084] Expose C struct timespec (nanosecond resolution) in time module In-Reply-To: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za> Message-ID: <1418968789.86.0.432679694872.issue23084@psf.upfronthosting.co.za> mdcb added the comment: naively and coming from C, you have time_t to represent time so even though underneath it's typedef, it gives the casual user like me comfort (2038 not accounted). I don't know the details why struct timespec was chosen rather than nanoseconds as integer, and in fact would rather leave that worry to others. maybe a typdef PyTimeStamp would make the defacto you mention more obvious, and maybe class timestamp(int):pass in python that seems to bring even more meaning but I don't know how you map that in the C API. more practically speaking: you're welcomed to close this issue since it's seeminly going nowhere. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 11:22:00 2014 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 19 Dec 2014 10:22:00 +0000 Subject: [issue22113] memoryview and struct.pack_into In-Reply-To: <1406795471.99.0.191583556895.issue22113@psf.upfronthosting.co.za> Message-ID: <1418984520.14.0.357304199357.issue22113@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: lgtm :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 15:07:54 2014 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 19 Dec 2014 14:07:54 +0000 Subject: [issue21862] cProfile command-line should accept "-m module_name" as an alternative to script path In-Reply-To: <1403640414.18.0.449527177368.issue21862@psf.upfronthosting.co.za> Message-ID: <1418998074.98.0.995931695811.issue21862@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The patch does not seem to allow parameters after the -m option. I'm sure this restriction can be lifted. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 15:58:58 2014 From: report at bugs.python.org (John Posner) Date: Fri, 19 Dec 2014 14:58:58 +0000 Subject: [issue21279] str.translate documentation incomplete In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za> Message-ID: <1419001138.18.0.93427051912.issue21279@psf.upfronthosting.co.za> John Posner added the comment: Regarding Martin's patch of 12-18: stdtypes.rst -- looks good to me unicodeobject.c -- I suggest changing this sentence: If a character is not in the table, the subscript operation should raise LookupError, and the character is left untouched. ... to: If the subscript operation raises a LookupError, the character is left untouched. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 16:30:30 2014 From: report at bugs.python.org (Gustavo Temple) Date: Fri, 19 Dec 2014 15:30:30 +0000 Subject: [issue23085] update internal libffi copy to 3.2.1 In-Reply-To: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za> Message-ID: <1419003030.88.0.158104019607.issue23085@psf.upfronthosting.co.za> Gustavo Temple added the comment: @steve.dower, so, can I abandon this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 16:51:53 2014 From: report at bugs.python.org (Steve Dower) Date: Fri, 19 Dec 2014 15:51:53 +0000 Subject: [issue23085] update internal libffi copy to 3.2.1 In-Reply-To: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za> Message-ID: <1419004313.18.0.0353756380261.issue23085@psf.upfronthosting.co.za> Steve Dower added the comment: I'm not entirely familiar with our layout of libffi, but I don't think your patch will affect Windows at all. If your intent was to update the version used in Windows builds, then you may as well abandon it. I'm not the one to ask about other platforms - apparently we need new ctypes maintainers... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 16:55:02 2014 From: report at bugs.python.org (Gustavo Temple) Date: Fri, 19 Dec 2014 15:55:02 +0000 Subject: [issue23085] update internal libffi copy to 3.2.1 In-Reply-To: <1418922803.63.0.55729998299.issue23085@psf.upfronthosting.co.za> Message-ID: <1419004502.75.0.835099894752.issue23085@psf.upfronthosting.co.za> Gustavo Temple added the comment: @steve.dower, so no problems, because my patch won't affect Windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 17:07:34 2014 From: report at bugs.python.org (Gustavo Temple) Date: Fri, 19 Dec 2014 16:07:34 +0000 Subject: [issue23089] Update config files Message-ID: <1419005254.2.0.517752739413.issue23089@psf.upfronthosting.co.za> New submission from Gustavo Temple: Update config.guess and config.sub ---------- components: Installation files: config.patch keywords: patch messages: 232937 nosy: gustavotemple priority: normal severity: normal status: open title: Update config files versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37506/config.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 17:09:22 2014 From: report at bugs.python.org (Gustavo Temple) Date: Fri, 19 Dec 2014 16:09:22 +0000 Subject: [issue23089] Update config files In-Reply-To: <1419005254.2.0.517752739413.issue23089@psf.upfronthosting.co.za> Message-ID: <1419005362.21.0.0741277426429.issue23089@psf.upfronthosting.co.za> Changes by Gustavo Temple : ---------- nosy: +doko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 17:17:07 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 19 Dec 2014 16:17:07 +0000 Subject: [issue23084] Expose C struct timespec (nanosecond resolution) in time module In-Reply-To: <1418920478.46.0.204307396965.issue23084@psf.upfronthosting.co.za> Message-ID: <1419005827.76.0.729532130323.issue23084@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- components: +Extension Modules -Library (Lib) status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 17:30:20 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 19 Dec 2014 16:30:20 +0000 Subject: [issue23089] Update libffi config files In-Reply-To: <1419005254.2.0.517752739413.issue23089@psf.upfronthosting.co.za> Message-ID: <1419006620.34.0.254320906044.issue23089@psf.upfronthosting.co.za> R. David Murray added the comment: How does this patch relate to the discussion on python-dev about libffi? ---------- components: +ctypes nosy: +r.david.murray title: Update config files -> Update libffi config files _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 17:49:28 2014 From: report at bugs.python.org (Gustavo Temple) Date: Fri, 19 Dec 2014 16:49:28 +0000 Subject: [issue23089] Update libffi config files In-Reply-To: <1419005254.2.0.517752739413.issue23089@psf.upfronthosting.co.za> Message-ID: <1419007768.51.0.484465380029.issue23089@psf.upfronthosting.co.za> Gustavo Temple added the comment: @r.david.murray, I think they aren't related. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 17:51:08 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 19 Dec 2014 16:51:08 +0000 Subject: [issue23089] Update libffi config files In-Reply-To: <1419005254.2.0.517752739413.issue23089@psf.upfronthosting.co.za> Message-ID: <1419007868.22.0.111887203385.issue23089@psf.upfronthosting.co.za> R. David Murray added the comment: What is the purpose of your patch, then? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 18:03:03 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 19 Dec 2014 17:03:03 +0000 Subject: [issue22896] Don't use PyObject_As*Buffer() functions In-Reply-To: <1416319375.33.0.739222572648.issue22896@psf.upfronthosting.co.za> Message-ID: <1419008583.2.0.850577144395.issue22896@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated patch addresses Antoine's comments. I still hesitate about C-contiguousity. Looks as all buffers created in the stdlib are C-contiguous, so we can't test non-contiguous buffers. Shouldn't PyObject_AsCharBuffer (or even PyObject_AsReadBuffer and_PyBuffer_Converter) accept only C-contiguous buffers? Who are buffer protocol experts? ---------- Added file: http://bugs.python.org/file37507/buffers_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 18:04:25 2014 From: report at bugs.python.org (Gustavo Temple) Date: Fri, 19 Dec 2014 17:04:25 +0000 Subject: [issue23089] Update libffi config files In-Reply-To: <1419005254.2.0.517752739413.issue23089@psf.upfronthosting.co.za> Message-ID: <1419008665.02.0.911313362015.issue23089@psf.upfronthosting.co.za> Gustavo Temple added the comment: @r.david.murray, the config.guess inside the root folder fixes some verifications about IBM arch, the config.guess inside the libffi folder fixes some verifications about PowerPC, and the config.sub inside the libffi folder fixes some verifications about ppc64p7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 18:34:27 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 19 Dec 2014 17:34:27 +0000 Subject: [issue23063] `python setup.py check --restructuredtext --strict --metadata` fails with: `warning: check: Could not finish the parsing.` if the RST document uses code or code-block directives. In-Reply-To: <1418716685.25.0.847417973192.issue23063@psf.upfronthosting.co.za> Message-ID: <1419010467.34.0.43218860145.issue23063@psf.upfronthosting.co.za> ?ric Araujo added the comment: An active core developer needs to see this and decide to commit the patch. You can see if there?s someone on IRC. If there?s no action in a week or two, feel free to ask on python-dev (maybe listing more than one waiting patch, or offering reviews in exchange for core dev time). ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 18:53:40 2014 From: report at bugs.python.org (Brian Kearns) Date: Fri, 19 Dec 2014 17:53:40 +0000 Subject: [issue23090] fix test_doctest relying on refcounting to close files Message-ID: <1419011620.53.0.891989929963.issue23090@psf.upfronthosting.co.za> Changes by Brian Kearns : ---------- files: fix_test_doctest.patch keywords: patch nosy: bdkearns priority: normal severity: normal status: open title: fix test_doctest relying on refcounting to close files type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file37508/fix_test_doctest.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 18:54:49 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 19 Dec 2014 17:54:49 +0000 Subject: [issue22896] Don't use PyObject_As*Buffer() functions In-Reply-To: <1416319375.33.0.739222572648.issue22896@psf.upfronthosting.co.za> Message-ID: <1419011689.25.0.468891164645.issue22896@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Shouldn't PyObject_AsCharBuffer (or even PyObject_AsReadBuffer and_PyBuffer_Converter) accept only C-contiguous buffers? PyBUF_SIMPLE enforces contiguity. See https://www.python.org/dev/peps/pep-3118/#access-flags and https://docs.python.org/3/c-api/buffer.html#c.Py_buffer.len Also Stefan's post at http://mail.scipy.org/pipermail/numpy-discussion/2011-August/058189.html Perhaps Stefan can confirm. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 19:11:29 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 19 Dec 2014 18:11:29 +0000 Subject: [issue23089] Update libffi config files In-Reply-To: <1419005254.2.0.517752739413.issue23089@psf.upfronthosting.co.za> Message-ID: <1419012689.19.0.809407510613.issue23089@psf.upfronthosting.co.za> R. David Murray added the comment: How do these relate to the upstream libffi? I think we probably need to deal with this as part of the libffi discussion on python-dev. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 21:13:30 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 19 Dec 2014 20:13:30 +0000 Subject: [issue23051] multiprocessing.pool methods imap()[_unordered()] deadlock In-Reply-To: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za> Message-ID: <1419020010.65.0.408714088426.issue23051@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- title: multiprocessing.pool methods imap() and imap_unordered() cause deadlock -> multiprocessing.pool methods imap()[_unordered()] deadlock _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 21:36:29 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 19 Dec 2014 20:36:29 +0000 Subject: [issue22896] Don't use PyObject_As*Buffer() functions In-Reply-To: <1416319375.33.0.739222572648.issue22896@psf.upfronthosting.co.za> Message-ID: <1419021389.49.0.420602058384.issue22896@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ah, there is a way to create non-contiguous buffers. >>> b = bytes(range(16)) >>> m = memoryview(b) >>> m[::2].c_contiguous False > PyBUF_SIMPLE enforces contiguity. Then contiguousity check in getbuffer() in Python/getargs.c is redundant. And in most cases the use of _PyBuffer_Converter() and PyObject_GetBuffer() could be replaced by the use of "y*" and "w*" format units. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 21:43:18 2014 From: report at bugs.python.org (Stefan Krah) Date: Fri, 19 Dec 2014 20:43:18 +0000 Subject: [issue22896] Don't use PyObject_As*Buffer() functions In-Reply-To: <1416319375.33.0.739222572648.issue22896@psf.upfronthosting.co.za> Message-ID: <1419021798.35.0.396205615751.issue22896@psf.upfronthosting.co.za> Stefan Krah added the comment: Yes, a PyBUF_SIMPLE request implies c-contiguous, so it's ok. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 22:45:41 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 19 Dec 2014 21:45:41 +0000 Subject: [issue23059] cmd module should sort misc help topics In-Reply-To: <1418677369.11.0.558268336279.issue23059@psf.upfronthosting.co.za> Message-ID: <1419025541.5.0.854424396364.issue23059@psf.upfronthosting.co.za> Terry J. Reedy added the comment: cmd.Cmd has a documented do_help(self, arg) method (written in 2000). If arg is '', it prints 1. Documented commands (do_x with help_x or do_x.__doc__ != ''), sorted 2. Other help topics (help_y with no do_y), unsorted 3. Undocumented commands (do_ without no help_x and no do_x.__doc__), sorted The dict called 'help' (which should be a set, and might better be called 'topics') ends up with a member for each help_y topic without a do_y command. Not sorting the keys is at least a design bug. Leaving users aside, it makes do_help unpredictable and hard to test. Our test.test_cmd omits misc help topics. In verbose mode, it prints Trying: mycmd.do_help("") Expecting: Documented commands (type help ): ======================================== add help Undocumented commands: ====================== exit shell ok As near as I can tell, text_cmd would still pass if Misc topics were removed and never printed. Topics can only be added to the test above is they are dependably ordered (ie, sorted). --- This '?' or 'help' case is also not properly documented, but should be. 3.4 cmd.__doc__ has this mishmash: "With no arguments, it lists all topics with defined help_ functions, broken into up to three topics; documented commands, miscellaneous help topics, and undocumented commands." 3.4 doc says "With no argument, do_help() lists all available help topics (that is, all commands with corresponding help_*() methods or commands that have docstrings), and also lists any undocumented commands." ---------- nosy: +terry.reedy stage: -> test needed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 19 23:06:11 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 19 Dec 2014 22:06:11 +0000 Subject: [issue23061] Update pep8 to specify explicitly 'module level' imports at top of file In-Reply-To: <1418703864.09.0.281927050653.issue23061@psf.upfronthosting.co.za> Message-ID: <1419026771.7.0.585369050048.issue23061@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I read Nick's post and I would like PEP8 to continue to discourage imports at class scope unless there is actually a use case. I discovered yesterday that idlelib.ColorDelegator has several imports at the top of the module and more as the top of the class (of the same name). I cannot think of any good reason for the split. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 00:48:55 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 19 Dec 2014 23:48:55 +0000 Subject: [issue23051] multiprocessing.pool methods imap()[_unordered()] deadlock In-Reply-To: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za> Message-ID: <1419032935.3.0.799662158559.issue23051@psf.upfronthosting.co.za> Changes by Josh Rosenberg : ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 00:48:56 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 19 Dec 2014 23:48:56 +0000 Subject: [issue23069] IDLE's F5 Run Module doesn't transfer effects of future import In-Reply-To: <1418783430.85.0.171264628982.issue23069@psf.upfronthosting.co.za> Message-ID: <1419032936.93.0.700262890191.issue23069@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I agree that this is broken. I verified that the following works in 2.7.9 >>> from __future__ import division, print_function >>> 32 / 5 6.4 >>> print(2,3,sep='**') 2**3 #13296 was about self.compile.compiler.flags (in ModifiedInterpreter, which inherits .compile... from code.InteractiveInterpreter) not being *reset* to their original values upon Shell restart. They are now. This issue is about the same flags not being *set* by Run Module. This will be tricky to fix, but I think it can be done using the previous flag issue as a hint. self.compile (in InteractiveInterpreter) = codeop.CommandCompiler(). The docstring for the class says """Instances of this class have __call__ methods identical in signature to compile_command; the difference is that if the instance compiles program text containing a __future__ statement, the instance 'remembers' and compiles all subsequent program texts with the statement in force.""" The __call__ method handles partial or complete single statements. Run -> Run Module F5, on the other hand, is handled by the ScriptBindind.py extension. ScriptBinding.run_module_event calls .checksyntax(). The latter calls builtin compile(), independent of the shell interpreter.compile, without saving the compile flags. To save the compile flags, we could use codeop.Compile.__call__, which calls builtin compile() and then extracts and saves future compile flags from the resulting code object using constants defined in the module. The next issue is timing. The shell restarts (and resets its flags) only after the file passes compile and tabnanny steps. After the restart, it should be possible to update the shell compile flags with any future flags saved by the Compile() instance. I have skipped over some details (including the lack of tests for Run Module), but I *think* that the above outlines a safe solution. As for 3.x, there are changes in 3.4 ScriptBinding.py, but the essential points for this issue seem the same. 3.x should be patched also to be ready for future __future__ imports. ---------- nosy: +terry.reedy versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 00:59:11 2014 From: report at bugs.python.org (Martin Panter) Date: Fri, 19 Dec 2014 23:59:11 +0000 Subject: [issue22896] Don't use PyObject_As*Buffer() functions In-Reply-To: <1416319375.33.0.739222572648.issue22896@psf.upfronthosting.co.za> Message-ID: <1419033551.81.0.350284790361.issue22896@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 01:00:34 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 20 Dec 2014 00:00:34 +0000 Subject: [issue23087] Exec variable not found error In-Reply-To: <1418941624.73.0.497940658508.issue23087@psf.upfronthosting.co.za> Message-ID: <1419033634.06.0.136868338376.issue23087@psf.upfronthosting.co.za> Terry J. Reedy added the comment: https://stackoverflow.com/questions/27554334/python-3-dictionary-comprehension-exec-error/27571212#27571212 ---------- nosy: +terry.reedy resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 01:13:10 2014 From: report at bugs.python.org (mdcb) Date: Sat, 20 Dec 2014 00:13:10 +0000 Subject: [issue15443] datetime module has no support for nanoseconds In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za> Message-ID: <1419034390.77.0.143839102382.issue15443@psf.upfronthosting.co.za> mdcb added the comment: patch in attachment is an attempt to provide the datetime type nanosecond support, handles pickle versioning, expose a new class method datetime.fromnanoseconds ---------- keywords: +patch nosy: +mdcb808 at gmail.com Added file: http://bugs.python.org/file37509/datetime.nanosecond.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 01:13:39 2014 From: report at bugs.python.org (mdcb) Date: Sat, 20 Dec 2014 00:13:39 +0000 Subject: [issue15443] datetime module has no support for nanoseconds In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za> Message-ID: <1419034419.22.0.961856321584.issue15443@psf.upfronthosting.co.za> Changes by mdcb : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 01:36:30 2014 From: report at bugs.python.org (Nikolaus Rath) Date: Sat, 20 Dec 2014 00:36:30 +0000 Subject: [issue15955] gzip, bz2, lzma: add option to limit output size In-Reply-To: <1347884562.79.0.801674791772.issue15955@psf.upfronthosting.co.za> Message-ID: <1419035790.34.0.0565014630032.issue15955@psf.upfronthosting.co.za> Nikolaus Rath added the comment: *ping*. It's been another 8 months. It would be nice if someone could review the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 03:02:21 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 20 Dec 2014 02:02:21 +0000 Subject: [issue23080] BoundArguments.arguments should be unordered In-Reply-To: <1418907389.55.0.608772896554.issue23080@psf.upfronthosting.co.za> Message-ID: <1419040941.46.0.417739772428.issue23080@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 03:04:43 2014 From: report at bugs.python.org (Aaron Hill) Date: Sat, 20 Dec 2014 02:04:43 +0000 Subject: [issue23004] mock_open() should allow reading binary data In-Reply-To: <1417965857.24.0.521739131396.issue23004@psf.upfronthosting.co.za> Message-ID: <1419041083.26.0.137774075576.issue23004@psf.upfronthosting.co.za> Aaron Hill added the comment: I've fixed the formatting issues. ---------- Added file: http://bugs.python.org/file37510/mock-open-allow-binary-data-fix-formatting.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 03:11:00 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 20 Dec 2014 02:11:00 +0000 Subject: [issue21071] struct.Struct.format is bytes, but should be str In-Reply-To: <1395856133.5.0.672707015318.issue21071@psf.upfronthosting.co.za> Message-ID: <1419041460.93.0.877523639206.issue21071@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I would like to see this and issue 8934 discussed as a usability bug. As far as I can tell, the current state of affairs an unintended by-product of a rushed effort to split the standard library to bytes apis and unicode apis. I don't see any reason that we should have to live with this forever. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 03:37:18 2014 From: report at bugs.python.org (S. Andrew Sheppard) Date: Sat, 20 Dec 2014 02:37:18 +0000 Subject: [issue23091] unpacked keyword arguments are not unicode normalized Message-ID: <1419043038.74.0.103514960492.issue23091@psf.upfronthosting.co.za> New submission from S. Andrew Sheppard: I came across unexpected behavior working with unpacking keyword arguments in Python 3. It appears to be related to the automatic normalization of unicode characters to NFKC (PEP 3131), which converts e.g. MICRO SIGN to GREEK SMALL LETTER MU. This conversion is applied to regular keyword arguments but not when unpacking arguments via **. This issue arose while I was working with some automatically generated namedtuple classes, but I was able to reproduce it with a simple function: def test(?): print(?) >>> test(?="test1") # chr(181) test1 >>> test(?="test2") # chr(956) test2 >>> test(**{'?': "test3"}) # chr(956) test3 >>> test(**{'?': "test4"}) # chr(181) Traceback (most recent call last): File "", line 1, in TypeError: test() got an unexpected keyword argument '?' I can obviously work around this, but wanted to bring it up in case it's a bug. My naive expectation would be that unpacked ** keys should be treated exactly like normal keyword arguments. ---------- components: Unicode messages: 232956 nosy: ezio.melotti, haypo, sheppard priority: normal severity: normal status: open title: unpacked keyword arguments are not unicode normalized versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 03:39:46 2014 From: report at bugs.python.org (Vinson Lee) Date: Sat, 20 Dec 2014 02:39:46 +0000 Subject: [issue23092] Python 2.7.9 test_readline regression on CentOS 6 Message-ID: <1419043185.97.0.756938564911.issue23092@psf.upfronthosting.co.za> New submission from Vinson Lee: test_readline regressed from Python 2.7.8 to Python 2.7.9 on CentOS 6 Python 2.7.8 $ ./python -m test.regrtest test_readline test_readline 1 test OK. Python 2.7.9 $ ./python -m test.regrtest test_readline [1/1] test_readline test test_readline failed -- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_readline.py", line 56, in test_init self.assertEqual(stdout, b'') AssertionError: '\x1b[?1034h' != '' 1 test failed: test_readline $ cat /etc/redhat-release CentOS release 6.6 (Final) $ rpm -qa | grep readline readline-6.0-4.el6.x86_64 compat-readline5-5.2-17.1.el6.x86_64 readline-devel-6.0-4.el6.x86_64 ---------- components: Tests messages: 232957 nosy: vlee priority: normal severity: normal status: open title: Python 2.7.9 test_readline regression on CentOS 6 versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 03:51:03 2014 From: report at bugs.python.org (S. Andrew Sheppard) Date: Sat, 20 Dec 2014 02:51:03 +0000 Subject: [issue23091] unpacked keyword arguments are not unicode normalized In-Reply-To: <1419043038.74.0.103514960492.issue23091@psf.upfronthosting.co.za> Message-ID: <1419043863.58.0.0453053672153.issue23091@psf.upfronthosting.co.za> S. Andrew Sheppard added the comment: Here's a simple namedtuple example for good measure. from collections import namedtuple Test = namedtuple("Test", [chr(181)]) >>> Test(**{chr(956): "test1"}) Test(?='test1') >>> Test(**{chr(181): "test1"}) Traceback (most recent call last): File "", line 1, in TypeError: __new__() got an unexpected keyword argument '?' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 04:27:57 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 20 Dec 2014 03:27:57 +0000 Subject: [issue23091] unpacked keyword arguments are not unicode normalized In-Reply-To: <1419043038.74.0.103514960492.issue23091@psf.upfronthosting.co.za> Message-ID: <1419046077.14.0.770085782772.issue23091@psf.upfronthosting.co.za> R. David Murray added the comment: I suspect that the normalization is happening in the parsing phase. That is, the keyword argument gets normalized when the python source is compiled, but the dictionary key is, of course, *not* normalized, since it is a literal string. If I'm right, I think is not a bug. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 05:08:48 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 20 Dec 2014 04:08:48 +0000 Subject: [issue23091] unpacked keyword arguments are not unicode normalized In-Reply-To: <1419043038.74.0.103514960492.issue23091@psf.upfronthosting.co.za> Message-ID: <1419048528.19.0.35703627515.issue23091@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Yeah, kwarg dicts do not have the same checks applied to them as syntactic keyword args. It would be weird if, for example, dict(**mydict) normalized the keys of mydict. ---------- nosy: +benjamin.peterson resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 05:18:38 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 20 Dec 2014 04:18:38 +0000 Subject: [issue22836] Broken "Exception ignored in:" message on exceptions in __repr__ In-Reply-To: <1415614969.23.0.620237340846.issue22836@psf.upfronthosting.co.za> Message-ID: <1419049118.12.0.397772596768.issue22836@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch that substitutes an explanation if the repr() fails. Output now looks like this, terminated with a newline: === BrokenObj === Exception ignored in: Traceback (most recent call last): File "", line 3, in __del__ Exception: in del $ ./python -c 'import sys; sys.stdout.detach()' Exception ignored in: ValueError: underlying buffer has been detached I also made it work sensibly if printing the exception message fails: >>> class Exception(Exception): ... def __str__(self): raise Exception("Exception is broken") ... >>> f = BrokenObj(); del f Exception ignored in: Traceback (most recent call last): File "", line 3, in __del__ __main__.Exception: >>> raise Exception() Traceback (most recent call last): File "", line 1, in __main__.Exception: >>> ---------- keywords: +patch Added file: http://bugs.python.org/file37511/unraisable-continue.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 05:29:10 2014 From: report at bugs.python.org (mdcb) Date: Sat, 20 Dec 2014 04:29:10 +0000 Subject: [issue15443] datetime module has no support for nanoseconds In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za> Message-ID: <1419049750.72.0.0834066832693.issue15443@psf.upfronthosting.co.za> mdcb added the comment: minor bug fixes and improvements in new attachment. ---------- Added file: http://bugs.python.org/file37512/datetime.nanosecond.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 06:00:17 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 20 Dec 2014 05:00:17 +0000 Subject: [issue5319] stdout error at interpreter shutdown fails to return OS error status In-Reply-To: <1235065081.04.0.732738239861.issue5319@psf.upfronthosting.co.za> Message-ID: <1419051617.35.0.618625066927.issue5319@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 06:10:10 2014 From: report at bugs.python.org (S. Andrew Sheppard) Date: Sat, 20 Dec 2014 05:10:10 +0000 Subject: [issue23091] unpacked keyword arguments are not unicode normalized In-Reply-To: <1419043038.74.0.103514960492.issue23091@psf.upfronthosting.co.za> Message-ID: <1419052210.17.0.592347644505.issue23091@psf.upfronthosting.co.za> S. Andrew Sheppard added the comment: Fair enough. For future reference by anyone coming across this issue, here's a simplified version of the workaround I used: from unicodedata import normalize def normalize_keys(data): return { normalize('NFKC', key): value for key, value in data.items() } def test(?): print(?) >>> test(**normalize_keys({'?': "test4"})) test4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 07:14:24 2014 From: report at bugs.python.org (Steve Dower) Date: Sat, 20 Dec 2014 06:14:24 +0000 Subject: [issue23065] Pyhton27.dll at SysWOW64 not updated when updating Python 2.7.X In-Reply-To: <1418727319.18.0.894015013947.issue23065@psf.upfronthosting.co.za> Message-ID: <1419056064.97.0.806435372562.issue23065@psf.upfronthosting.co.za> Steve Dower added the comment: That's strange, and it isn't what normally happens, so I suspect it's a configuration or corruption issue on your machine (possibly Kapersky Pure is to blame?). The 2.7.7, 2.7.8 and 2.7.9 installers all have the correct version information and there's no indication that under normal circumstances the upgrade wouldn't be fine. We're also not investing much time into the installer for 2.7 any more - the builds are still coming because I'm building them, but I'm not able to actively maintain it beyond that - and so we don't really have much interest in debugging issues with workarounds. So thank you for reporting the problem, but there probably won't be a fix coming for it and you'll need to uninstall 2.7.9 before upgrading to the next version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 08:06:15 2014 From: report at bugs.python.org (Chandan kumar) Date: Sat, 20 Dec 2014 07:06:15 +0000 Subject: [issue22671] Typo in class io.BufferedIOBase docs In-Reply-To: <1413711352.27.0.0253692424247.issue22671@psf.upfronthosting.co.za> Message-ID: <1419059175.86.0.380248351953.issue22671@psf.upfronthosting.co.za> Changes by Chandan kumar : ---------- nosy: +Chandan.kumar _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 08:25:36 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 20 Dec 2014 07:25:36 +0000 Subject: [issue23092] Python 2.7.9 test_readline regression on CentOS 6 In-Reply-To: <1419043185.97.0.756938564911.issue23092@psf.upfronthosting.co.za> Message-ID: <1419060336.44.0.436957987274.issue23092@psf.upfronthosting.co.za> Berker Peksag added the comment: This looks like a duplicate of issue 19884. ---------- nosy: +berker.peksag resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Importing readline produces erroneous output type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 08:38:35 2014 From: report at bugs.python.org (Vinson Lee) Date: Sat, 20 Dec 2014 07:38:35 +0000 Subject: [issue23092] Python 2.7.9 test_readline regression on CentOS 6 In-Reply-To: <1419043185.97.0.756938564911.issue23092@psf.upfronthosting.co.za> Message-ID: <1419061115.39.0.648738910669.issue23092@psf.upfronthosting.co.za> Vinson Lee added the comment: The regression is introduced with this commit. commit fa06e2bb13a3e67a0641025483efb19ef569dbd9 Author: Victor Stinner Date: Thu Jul 24 12:22:24 2014 +0200 Issue #19884: readline: Disable the meta modifier key if stdout is not a terminal to not write the ANSI sequence "\033[1034h" into stdout. This sequence is used on some terminal (ex: TERM=xterm-256color") to enable support of 8 bit characters. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 09:55:12 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 20 Dec 2014 08:55:12 +0000 Subject: [issue5319] stdout error at interpreter shutdown fails to return OS error status In-Reply-To: <1235065081.04.0.732738239861.issue5319@psf.upfronthosting.co.za> Message-ID: <1419065712.61.0.340558050688.issue5319@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch that changes Py_Finalize() to return -1 on error, and then sets the exit status to 1. It did not introduce any failures in the test suite for me. However I suspect it deserves more consideration about backwards compatibility etc, which is beyond my knowledge. ---------- Added file: http://bugs.python.org/file37513/finalize-error.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 11:48:56 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 20 Dec 2014 10:48:56 +0000 Subject: [issue22896] Don't use PyObject_As*Buffer() functions In-Reply-To: <1416319375.33.0.739222572648.issue22896@psf.upfronthosting.co.za> Message-ID: <1419072536.74.0.238044171958.issue22896@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is simplified patch. _PyBuffer_Converter() and "simple_buffer" converter are gone. Fixed few leaks found by Martin. Fixed potential crash in ctypes. Fixed minor bugs and cleaned up ctypes tests for from_buffer(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 11:50:57 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 20 Dec 2014 10:50:57 +0000 Subject: [issue22896] Don't use PyObject_As*Buffer() functions In-Reply-To: <1416319375.33.0.739222572648.issue22896@psf.upfronthosting.co.za> Message-ID: <1419072657.88.0.182270202182.issue22896@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file37514/buffers_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 13:18:49 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 20 Dec 2014 12:18:49 +0000 Subject: [issue23090] fix test_doctest relying on refcounting to close files Message-ID: <1419077929.31.0.496573304626.issue23090@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: See also issue22831. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 13:30:29 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 20 Dec 2014 12:30:29 +0000 Subject: [issue22671] Typo in class io.BufferedIOBase docs In-Reply-To: <1413711352.27.0.0253692424247.issue22671@psf.upfronthosting.co.za> Message-ID: <1419078629.55.0.485596151979.issue22671@psf.upfronthosting.co.za> Martin Panter added the comment: The documentation was technically correct but too scanty. RawIOBase.read(-1) does defer to readall(), but with a proper size passed, it defers to readinto() instead. Here is a patch which hopefully clarifies this, and also explains which methods have a usable default implementation. Includes some tests for RawIOBase and BufferedIOBase which didn?t seem to be there already. ---------- keywords: +patch nosy: +vadmium Added file: http://bugs.python.org/file37515/read-defaults.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 15:19:49 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 20 Dec 2014 14:19:49 +0000 Subject: [issue23093] repr() on detached stream objects fails Message-ID: <1419085189.47.0.13249408936.issue23093@psf.upfronthosting.co.za> New submission from Martin Panter: Patch to fix the underlying issue I mentioned in msg230955. After calling detach() on one of the BufferedIOBase wrappers or a TextIOWrapper, most operations will raise an exception. My patch ensures the following operations are still usable, because they are documented and it doesn?t make sense to disable them: repr(stream) stream.encoding stream.errors stream.line_buffering ---------- components: IO files: detach-indep.patch keywords: patch messages: 232971 nosy: vadmium priority: normal severity: normal status: open title: repr() on detached stream objects fails type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file37516/detach-indep.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 16:31:21 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 20 Dec 2014 15:31:21 +0000 Subject: [issue23071] codecs.__all__ incomplete In-Reply-To: <1418792013.22.0.617617600077.issue23071@psf.upfronthosting.co.za> Message-ID: <1419089481.61.0.49157987592.issue23071@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 16:52:15 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 20 Dec 2014 15:52:15 +0000 Subject: [issue23071] codecs.__all__ incomplete In-Reply-To: <1418792013.22.0.617617600077.issue23071@psf.upfronthosting.co.za> Message-ID: <20141220155212.81005.49798@psf.io> Roundup Robot added the comment: New changeset c6491d91d59a by Serhiy Storchaka in branch '2.7': Issue #23071: Added missing names to codecs.__all__. Patch by Martin Panter. https://hg.python.org/cpython/rev/c6491d91d59a New changeset 2b642f2ca391 by Serhiy Storchaka in branch '3.4': Issue #23071: Added missing names to codecs.__all__. Patch by Martin Panter. https://hg.python.org/cpython/rev/2b642f2ca391 New changeset 73086376ed3c by Serhiy Storchaka in branch 'default': Issue #23071: Added missing names to codecs.__all__. Patch by Martin Panter. https://hg.python.org/cpython/rev/73086376ed3c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 17:42:27 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 20 Dec 2014 16:42:27 +0000 Subject: [issue23093] repr() on detached stream objects fails In-Reply-To: <1419085189.47.0.13249408936.issue23093@psf.upfronthosting.co.za> Message-ID: <1419093747.81.0.469743388402.issue23093@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The issue is still here. >>> f = open('/dev/null') >>> f <_io.TextIOWrapper name='/dev/null' mode='r' encoding='UTF-8'> >>> f.buffer.detach() <_io.FileIO name='/dev/null' mode='rb' closefd=True> >>> f Traceback (most recent call last): File "", line 1, in ValueError: raw stream has been detached Python implementation works. >>> import _pyio >>> f = _pyio.open('/dev/null') >>> f <_pyio.TextIOWrapper name='/dev/null' mode='r' encoding='UTF-8'> >>> f.buffer.detach() <_io.FileIO name='/dev/null' mode='rb' closefd=True> >>> f <_pyio.TextIOWrapper mode='r' encoding='UTF-8'> >>> f = _pyio.open('/dev/null') >>> f.detach() <_pyio.BufferedReader name='/dev/null'> >>> f <_pyio.TextIOWrapper mode='r' encoding='UTF-8'> >>> f = _pyio.open('/dev/null', 'rb') >>> f <_pyio.BufferedReader name='/dev/null'> >>> f.detach() <_io.FileIO name='/dev/null' mode='rb' closefd=True> >>> f <_pyio.BufferedReader> I would be good to make Python and C implementation match. ---------- nosy: +benjamin.peterson, hynek, pitrou, serhiy.storchaka, stutzbach stage: -> patch review versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 17:43:38 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 20 Dec 2014 16:43:38 +0000 Subject: [issue23071] codecs.__all__ incomplete In-Reply-To: <1418792013.22.0.617617600077.issue23071@psf.upfronthosting.co.za> Message-ID: <1419093818.8.0.886768114592.issue23071@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your patch Martin. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 17:45:03 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 20 Dec 2014 16:45:03 +0000 Subject: [issue23071] codecs.__all__ incomplete In-Reply-To: <1418792013.22.0.617617600077.issue23071@psf.upfronthosting.co.za> Message-ID: <1419093903.17.0.951949803413.issue23071@psf.upfronthosting.co.za> Berker Peksag added the comment: In 3.4, "namereplace_errors" needs to be removed in the test: https://hg.python.org/cpython/rev/2b642f2ca391#l2.17 ====================================================================== FAIL: test_all (test.test_codecs.CodecsModuleTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/python/3.4.koobs-freebsd9/build/Lib/test/test_codecs.py", line 1668, in test_all self.assertCountEqual(api, codecs.__all__) AssertionError: Element counts were not equal: First has 1, Second has 0: 'namereplace_errors' http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%203.4/builds/645/steps/test/logs/stdio ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 17:48:24 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 20 Dec 2014 16:48:24 +0000 Subject: [issue22350] nntplib file write failure causes exception from QUIT command In-Reply-To: <1410061219.03.0.0230581897355.issue22350@psf.upfronthosting.co.za> Message-ID: <1419094104.2.0.74795803783.issue22350@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +pitrou stage: -> patch review type: -> behavior versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 18:00:50 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 20 Dec 2014 17:00:50 +0000 Subject: [issue23071] codecs.__all__ incomplete In-Reply-To: <1418792013.22.0.617617600077.issue23071@psf.upfronthosting.co.za> Message-ID: <20141220170047.92281.91162@psf.io> Roundup Robot added the comment: New changeset 1ab04bcd03bf by Serhiy Storchaka in branch '3.4': Issue #23071: "namereplace_errors" was added only in 3.5. https://hg.python.org/cpython/rev/1ab04bcd03bf ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 18:02:05 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 20 Dec 2014 17:02:05 +0000 Subject: [issue23071] codecs.__all__ incomplete In-Reply-To: <1419093903.17.0.951949803413.issue23071@psf.upfronthosting.co.za> Message-ID: <2329930.QreX8btVcY@raxxla> Serhiy Storchaka added the comment: Hmm, I have no ideas how I missed this when ran tests. Thank you Berker. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 19:50:23 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 20 Dec 2014 18:50:23 +0000 Subject: [issue17530] pprint could use line continuation for long bytes literals In-Reply-To: <1364067577.46.0.261047534718.issue17530@psf.upfronthosting.co.za> Message-ID: <1419101423.28.0.109780977623.issue17530@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +pprint doesn't use all width, pprint produces invalid output for long strings versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 20:02:26 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 20 Dec 2014 19:02:26 +0000 Subject: [issue19104] pprint produces invalid output for long strings In-Reply-To: <1380289250.98.0.0529515271695.issue19104@psf.upfronthosting.co.za> Message-ID: <20141220190221.18155.19214@psf.io> Roundup Robot added the comment: New changeset 872f048f0403 by Serhiy Storchaka in branch '3.4': Issue #19104: pprint now produces evaluable output for wrapped strings. https://hg.python.org/cpython/rev/872f048f0403 New changeset 4d3066d4a5df by Serhiy Storchaka in branch 'default': Issue #19104: pprint now produces evaluable output for wrapped strings. https://hg.python.org/cpython/rev/4d3066d4a5df ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 20:17:10 2014 From: report at bugs.python.org (Jason R. Coombs) Date: Sat, 20 Dec 2014 19:17:10 +0000 Subject: [issue1763] Get path to shell/known folders on Windows In-Reply-To: <1199812378.67.0.278096816271.issue1763@psf.upfronthosting.co.za> Message-ID: <1419103030.92.0.492431144956.issue1763@psf.upfronthosting.co.za> Jason R. Coombs added the comment: +1 from me for supporting this functionality in Python natively. I tried winpaths but it doesn't yet support Python 3. I've e-mailed the author so it might be considered for a future release. ---------- nosy: +jason.coombs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 20:43:23 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 20 Dec 2014 19:43:23 +0000 Subject: [issue23090] fix test_doctest relying on refcounting to close files In-Reply-To: <1419077929.31.0.496573304626.issue23090@psf.upfronthosting.co.za> Message-ID: <20141220194320.18151.32197@psf.io> Roundup Robot added the comment: New changeset f00412d32b41 by Benjamin Peterson in branch '2.7': explicitly close files (closes #23090) https://hg.python.org/cpython/rev/f00412d32b41 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 20:44:15 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 20 Dec 2014 19:44:15 +0000 Subject: [issue19104] pprint produces invalid output for long strings In-Reply-To: <1380289250.98.0.0529515271695.issue19104@psf.upfronthosting.co.za> Message-ID: <1419104655.27.0.744739956508.issue19104@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Antoine for your review. ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 20:48:38 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 20 Dec 2014 19:48:38 +0000 Subject: [issue19105] pprint doesn't use all width In-Reply-To: <1380289834.62.0.88627838079.issue19105@psf.upfronthosting.co.za> Message-ID: <1419104918.81.0.160700177763.issue19105@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Resolved conflicts with issue19104. ---------- Added file: http://bugs.python.org/file37517/pprint_all_width_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 21:56:00 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 20 Dec 2014 20:56:00 +0000 Subject: [issue1763] Get path to shell/known folders on Windows In-Reply-To: <1199812378.67.0.278096816271.issue1763@psf.upfronthosting.co.za> Message-ID: <1419108960.56.0.0163295852528.issue1763@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 23:01:00 2014 From: report at bugs.python.org (Martin Panter) Date: Sat, 20 Dec 2014 22:01:00 +0000 Subject: [issue23093] repr() on detached stream objects fails In-Reply-To: <1419085189.47.0.13249408936.issue23093@psf.upfronthosting.co.za> Message-ID: <1419112860.9.0.538838614069.issue23093@psf.upfronthosting.co.za> Martin Panter added the comment: Damn, detaching the intermediate buffered stream is a bit more awkward. The difference between the ?io? and ?_pyio? implementations boils down to: * io.BufferedReader/Writer/RWPair.name properties raise a ValueError if the stream is detached * _pyio._BufferedIOMixin.name property returns ?self.raw.name?. When detached, ?self.raw? is None, so this causes an AttributeError. This is significant because io.TextIOWrapper.__repr__() only handles AttributeError when accessing ?self.buffer.name?. The best option that I can think of to fix this is to make all the repr() implementations handle this ValueError exception. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 20 23:33:25 2014 From: report at bugs.python.org (STINNER Victor) Date: Sat, 20 Dec 2014 22:33:25 +0000 Subject: [issue23088] Document that PyUnicode_AsUTF8() returns a null-terminated string In-Reply-To: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za> Message-ID: <1419114805.15.0.0182067201887.issue23088@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 00:24:32 2014 From: report at bugs.python.org (CensoredUsername) Date: Sat, 20 Dec 2014 23:24:32 +0000 Subject: [issue23094] Unpickler failing with PicklingError at frame end on readline due to a broken comparison Message-ID: <1419117872.02.0.125928182025.issue23094@psf.upfronthosting.co.za> New submission from CensoredUsername: If a pickle frame ends at the end of a pickle._Unframer.readline() call then an UnpicklingError("pickle exhausted before end of frame") will unconditionally be raised due to a faulty check if the frame ended before the line ended. It concerns this conditional in pickle._Unframer.readline, line 245 in pickle.py: if data[-1] != b'\n': raise UnpicklingError( "pickle exhausted before end of frame") This comparison will always evaluate to True even if data ends in a newline. This is caused by data being a bytes object, and such data[-1] will evaluate to 10 in case of data ending in a newline. 10 != b'\n' will then always evaluate to True due to the type mismatch, and the UnpicklingError will be raised. This error can be corrected by slicing an actual one character bytes object like: if data[-1:] != b'\n': raise UnpicklingError( "pickle exhausted before end of frame") Or by comparing against the numeric representation of b'\n': if data[-1] != b'\n'[0]: raise UnpicklingError( "pickle exhausted before end of frame") ---------- messages: 232984 nosy: CensoredUsername priority: normal severity: normal status: open title: Unpickler failing with PicklingError at frame end on readline due to a broken comparison type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 00:41:07 2014 From: report at bugs.python.org (STINNER Victor) Date: Sat, 20 Dec 2014 23:41:07 +0000 Subject: [issue22926] asyncio: raise an exception when called from the wrong thread In-Reply-To: <1416760694.74.0.749180510867.issue22926@psf.upfronthosting.co.za> Message-ID: <1419118867.47.0.462665978886.issue22926@psf.upfronthosting.co.za> STINNER Victor added the comment: Rebased patch which now always check the thread, even in release mode. Summary of the current version of the patch (check_thread-2.patch): - call_soon/call_at now checks if they are called from the thread running the event loop - the check is only done when the event loop in running - the check is always done, in relase and debug mode (we may only do it in release mode if you consider that the overhead is too high, see benchmark numbers below) - add a unit test for the thread check - since the check is only done when the event loop in running, we don't need the hack to avoid the thread check in the proactor event loop, for "self._call_soon(self._loop_self_reading, ())" - replace the _running attribute with a new _owner attribute in BaseEventLoop > Victor, can you benchmark this? Here is a benchmark for call_soon(): bench_call_soon.py. It computes the performance of one call to call_soon() in average. It uses 10,000 iterations, the test is run 5 times and the minimum timing is displayed. Since a call to traceback.extract_stack() takes more than 65 us, whereas a call to call_soon() in release mode takes 2.8 us, I removed the call in Handle constructor for the benchmark to focus on the thread check. - asyncio without extract_stack(), in release mode: 2491 ns per call - asyncio without extract_stack(), in debug mode: 3588 ns per call (1.4x slower, +1097 ns) - asyncio without extract_stack(), with check_thread-2.patch: 2721 ns per call (1.1x slower, +230 ns) The overhead of check_thread-2.patch is +230 ns (1.1x slower) per call to call_soon(). Do you consider that the overhead is low enough to run the check even in release mode? At least on Linux, threading.get_ident() is not a system call. Performances may be different on other platforms (ex: BSD, Windows). In check_thread-2.patch, I "inlined" the thread check directly in call_at() and call_soon(). For performance, but also because the check only takes 2 lines, and so the error message can contain the function name (call_soon/call_at). ---------- Added file: http://bugs.python.org/file37518/check_thread-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 00:41:15 2014 From: report at bugs.python.org (STINNER Victor) Date: Sat, 20 Dec 2014 23:41:15 +0000 Subject: [issue22926] asyncio: raise an exception when called from the wrong thread In-Reply-To: <1416760694.74.0.749180510867.issue22926@psf.upfronthosting.co.za> Message-ID: <1419118875.15.0.175947488196.issue22926@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file37519/bench_call_soon.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 01:18:30 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 21 Dec 2014 00:18:30 +0000 Subject: [issue22585] os.urandom() should use getentropy() of OpenBSD 5.6 In-Reply-To: <1412846768.8.0.764206346975.issue22585@psf.upfronthosting.co.za> Message-ID: <20141221001824.92269.73483@psf.io> Roundup Robot added the comment: New changeset 75ede5bec8db by Victor Stinner in branch 'default': Issue #22585: On OpenBSD 5.6 and newer, os.urandom() now calls getentropy(), https://hg.python.org/cpython/rev/75ede5bec8db ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 01:18:41 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 21 Dec 2014 00:18:41 +0000 Subject: [issue22585] os.urandom() should use getentropy() of OpenBSD 5.6 In-Reply-To: <1412846768.8.0.764206346975.issue22585@psf.upfronthosting.co.za> Message-ID: <1419121121.63.0.683930386517.issue22585@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 01:47:46 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 21 Dec 2014 00:47:46 +0000 Subject: [issue23095] asyncio: race condition in the IOCP code (proactor event loop) Message-ID: <1419122866.29.0.725788641938.issue23095@psf.upfronthosting.co.za> New submission from STINNER Victor: On Windows using the IOCP (proactor) event loop, I noticed race conditions when running the test suite of Trollius. For examples, sometimes the returncode of a process is None, which should never happen. It looks like wait_for_handle() has an invalid behaviour. When I run the test suite of asyncio in debug mode (PYTHONASYNCIODEBUG=1), sometimes I see the message "GetQueuedCompletionStatus() returned an unexpected event" which should never occur neither. I added debug traces. I saw that the IocpProactor.wait_for_handle() calls later PostQueuedCompletionStatus() through its internal C callback (PostToQueueCallback). It looks like sometimes the callback is called whereas the wait was cancelled/acked with UnregisterWait(). I didn't understand the logic between RegisterWaitForSingleObject(), UnregisterWait() and the callback. It looks like sometimes the overlapped object created in Python ("ov = _overlapped.Overlapped(NULL)") is destroyed, before PostToQueueCallback() was called. In the unit tests, it doesn't crash because a different overlapped object is created and it gets the same memory address (probably because we are lucky!). The current implementation of wait_for_handle() has an optimization: it polls immediatly the wait to check if it already completed. I tried to remove it, but I got some different issues. If I understood correctly, this optimization hides other bugs and reduce the probability of getting the race condition. wait_for_handle() in used to wait for the completion of a subprocess, so by all unit tests running subprocesses, but also in test_wait_for_handle() and test_wait_for_handle_cancel() tests. I suspect that running test_wait_for_handle() or test_wait_for_handle_cancel() schedule the bug. Note: Removing "_winapi.CloseHandle(self._iocp)" in IocpProactor.close() works around the bug. The bug looks to be an expected call to PostToQueueCallback() which calls PostQueuedCompletionStatus() on an IOCP. Not closing the IOCP means using a different IOCP for each test, so the unexpected call to PostQueuedCompletionStatus() has no effect on following tests. -- I rewrote some parts of the IOCP code in asyncio. Maybe I introduced this issue during the refactoring. Maybe it already existed before but nobody noticed it, asyncio had fewer unit tests before. At the beginning, I wanted to fix this crash: https://code.google.com/p/tulip/issues/detail?id=195 "_WaitHandleFuture.cancel() crash if the wait event was already unregistered" Later, I tried to make the code more reliable in this issue: https://code.google.com/p/tulip/issues/detail?id=196 "_OverlappedFuture.set_result() should clear the its reference to the overlapped object" Read Trollius 1.0.1 changelog which lists these changes: http://trollius.readthedocs.org/changelog.html#version-1-0-1 -- Note: The IOCP code still has code which can be enhanced: - "Investigate IocpProactor.accept_pipe() special case (don't register overlapped)" https://code.google.com/p/tulip/issues/detail?id=204 - "Rewrite IocpProactor.connect_pipe() with non-blocking calls to avoid non interruptible QueueUserWorkItem()" https://code.google.com/p/tulip/issues/detail?id=197 ---------- components: Windows, asyncio messages: 232987 nosy: gvanrossum, haypo, steve.dower, tim.golden, yselivanov, zach.ware priority: normal severity: normal status: open title: asyncio: race condition in the IOCP code (proactor event loop) versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 01:48:08 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 21 Dec 2014 00:48:08 +0000 Subject: [issue23095] asyncio: race condition in IocpProactor.wait_for_handle() In-Reply-To: <1419122866.29.0.725788641938.issue23095@psf.upfronthosting.co.za> Message-ID: <1419122888.7.0.866764505492.issue23095@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: asyncio: race condition in the IOCP code (proactor event loop) -> asyncio: race condition in IocpProactor.wait_for_handle() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 02:19:16 2014 From: report at bugs.python.org (Martin Panter) Date: Sun, 21 Dec 2014 01:19:16 +0000 Subject: [issue12600] Add example of using load_tests to parameterise Test Cases In-Reply-To: <1311226769.48.0.369455670372.issue12600@psf.upfronthosting.co.za> Message-ID: <1419124756.86.0.498686411993.issue12600@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 02:35:43 2014 From: report at bugs.python.org (Martin Panter) Date: Sun, 21 Dec 2014 01:35:43 +0000 Subject: [issue7897] Support parametrized tests in unittest In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za> Message-ID: <1419125743.78.0.223320605957.issue7897@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 02:50:28 2014 From: report at bugs.python.org (Martin Panter) Date: Sun, 21 Dec 2014 01:50:28 +0000 Subject: [issue22673] document the special features (eg: fdclose=False) of the standard streams In-Reply-To: <1413745258.02.0.518044907787.issue22673@psf.upfronthosting.co.za> Message-ID: <1419126628.84.0.837862279486.issue22673@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 03:28:49 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 21 Dec 2014 02:28:49 +0000 Subject: [issue23095] asyncio: race condition in IocpProactor.wait_for_handle() In-Reply-To: <1419122866.29.0.725788641938.issue23095@psf.upfronthosting.co.za> Message-ID: <1419128929.64.0.504701403752.issue23095@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 03:32:38 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 21 Dec 2014 02:32:38 +0000 Subject: [issue23094] Unpickler failing with PicklingError at frame end on readline due to a broken comparison In-Reply-To: <1419117872.02.0.125928182025.issue23094@psf.upfronthosting.co.za> Message-ID: <1419129158.81.0.774703652027.issue23094@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the report. Do you have actual data that can exhibit the problem? ---------- nosy: +pitrou, serhiy.storchaka versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 04:08:24 2014 From: report at bugs.python.org (Martin Panter) Date: Sun, 21 Dec 2014 03:08:24 +0000 Subject: [issue19051] Unify buffered readers In-Reply-To: <1379600529.46.0.258828532264.issue19051@psf.upfronthosting.co.za> Message-ID: <1419131304.57.0.868486750554.issue19051@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 04:13:29 2014 From: report at bugs.python.org (Martin Panter) Date: Sun, 21 Dec 2014 03:13:29 +0000 Subject: [issue12053] Add prefetch() for Buffered IO (experiment) In-Reply-To: <1305056245.15.0.0737815347229.issue12053@psf.upfronthosting.co.za> Message-ID: <1419131609.82.0.886231286621.issue12053@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 06:34:24 2014 From: report at bugs.python.org (Martin Panter) Date: Sun, 21 Dec 2014 05:34:24 +0000 Subject: [issue22854] Documentation/implementation out of sync for IO In-Reply-To: <1415804787.06.0.347049835041.issue22854@psf.upfronthosting.co.za> Message-ID: <1419140064.02.0.706445505076.issue22854@psf.upfronthosting.co.za> Martin Panter added the comment: Some of the docstrings already mention UnsupportedOperation. This patch updates the rest of the documentation. Also adds some tests to verify this on all the concrete classes I could think of. Some discoveries in the process: * BufferedWriter.readable() and BufferedReader.writable() could return True depending on the underlying raw stream. Fixed to always return False. * Removed a branch in a test case that assumed BufferedReader.close() did not call flush(), but never activated due to the above writable() bug * seek(), tell() and truncate() do not raise UnsupportedOperation, despite seekable() == False, at least for a pipe. Adjusted doc strings. ---------- keywords: +patch Added file: http://bugs.python.org/file37520/UnsupportedOperation.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 07:54:07 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Sun, 21 Dec 2014 06:54:07 +0000 Subject: [issue18590] Found text not always highlighted by Replace dialog on Windows In-Reply-To: <1375128565.7.0.113615028691.issue18590@psf.upfronthosting.co.za> Message-ID: <1419144847.68.0.604390820545.issue18590@psf.upfronthosting.co.za> Saimadhav Heblikar added the comment: I tested for the behaviour described in msg193895 before and after your patch. Everything remains same except as what you mentioned. >Currently, Replace dialog Find hits are tagged with both the 'hit' and the 'sel' tag, which does not show on Windows as long as the dialog is the active window, but apparently does on other systems. Raising the hit tag to the top (either patch) means that the visible highlight on other systems will change from 'selected' to 'found' (which are independently configurable in Idle preferences). > >If this not desired, the patch could be altered to use tag 'hit' on Windows and 'sel' elsewhere; change 'hit' (on Windows) to 'sel' when the dialog is closed; and configure 'hit' to look like 'sel' (so there is no visible change when closing, as on other systems). It would be better to ensure that there is no visible change when closing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 08:57:26 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 21 Dec 2014 07:57:26 +0000 Subject: [issue23094] Unpickler failing with PicklingError at frame end on readline due to a broken comparison In-Reply-To: <1419117872.02.0.125928182025.issue23094@psf.upfronthosting.co.za> Message-ID: <1419148646.66.0.128875676828.issue23094@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: readline() is used only when unpickle opcodes PERSID, INT, LONG, FLOAT, STRING, UNICODE, INST, GLOBAL, GET, PUT. These opcodes are not used with protocol 4 (all opcodes except GLOBAL is used only with protocol 0, and GLOBAL is used with protocol <= 3). Frames are used only with protocol 4. So there is very small chance to meet this bug in real data. But it is not zero, artificial pickled data which mixes FRAME with protocol 0 opcodes can be constructed by third-party software for some reasons. Artificial example: >>> pickletools.dis(b"\x80\x04\x95\x05\x00\x00\x00\x00\x00\x00\x00I42\n.") 0: \x80 PROTO 4 2: \x95 FRAME 5 11: I INT 42 15: . STOP highest protocol among opcodes = 4 ---------- components: +Library (Lib) stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 09:10:33 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 21 Dec 2014 08:10:33 +0000 Subject: [issue23096] Implementation-depended pickling floats with protocol 0 Message-ID: <1419149433.29.0.802482425543.issue23096@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Python and C implementations of pickle produce different results when pickle floats with protocol 0. >>> pickle.dumps(4.2, 0) b'F4.2000000000000002\n.' >>> pickle._dumps(4.2, 0) b'F4.2\n.' ---------- components: Library (Lib) messages: 232992 nosy: alexandre.vassalotti, pitrou, serhiy.storchaka priority: normal severity: normal status: open title: Implementation-depended pickling floats with protocol 0 type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 09:42:19 2014 From: report at bugs.python.org (Chris Jerdonek) Date: Sun, 21 Dec 2014 08:42:19 +0000 Subject: [issue23097] unittest can unnecessarily modify sys.path (and with the wrong case) Message-ID: <1419151339.28.0.203745779889.issue23097@psf.upfronthosting.co.za> New submission from Chris Jerdonek: I have observed that when running unit tests using unittest's test discovery, unittest can simultaneously (1) modify sys.path unnecessarily (by adding a path that is already in sys.path with a different case), and (2) modify sys.path by adding a path of the "wrong" case. This occurs for me on Mac OS X with the default case-insensitive file system. If the path-- '/Users/chris/Dev/python/my_package' is already in sys.path, running unittest's test discovery will prepend sys.path with the following: '/Users/chris/dev/python/my_package' Aside from causing unnecessary modifications of sys.path, this also causes an issue in coverage, for example: https://bitbucket.org/ned/coveragepy/issue/348 The relevant code is here in unittest/loader.py (with `top_level_dir` starting out as os.curdir): top_level_dir = os.path.abspath(top_level_dir) if not top_level_dir in sys.path: # all test modules must be importable from the top level directory # should we *unconditionally* put the start directory in first # in sys.path to minimise likelihood of conflicts between installed # modules and development versions? sys.path.insert(0, top_level_dir) self._top_level_dir = top_level_dir (from https://hg.python.org/cpython/file/75ede5bec8db/Lib/unittest/loader.py#l259 ) The issue occurs when os.path.abspath(top_level_dir) is already in sys.path but with a different case. (Note that if os.path.abspath() returned a path with the "right" case, then the unittest code would be okay.) See also these two threads regarding obtaining the correct case for a path: 1. https://mail.python.org/pipermail/python-dev/2010-September/103823.html 2. https://mail.python.org/pipermail/python-ideas/2010-September/008153.html ---------- components: Library (Lib) messages: 232993 nosy: chris.jerdonek priority: normal severity: normal status: open title: unittest can unnecessarily modify sys.path (and with the wrong case) type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 09:45:51 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 21 Dec 2014 08:45:51 +0000 Subject: [issue23094] Unpickler failing with PicklingError at frame end on readline due to a broken comparison In-Reply-To: <1419117872.02.0.125928182025.issue23094@psf.upfronthosting.co.za> Message-ID: <1419151551.96.0.972536555254.issue23094@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch Added file: http://bugs.python.org/file37521/pickle_frame_readline.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 09:50:48 2014 From: report at bugs.python.org (Martin Panter) Date: Sun, 21 Dec 2014 08:50:48 +0000 Subject: [issue21279] str.translate documentation incomplete In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za> Message-ID: <1419151848.58.0.455835181135.issue21279@psf.upfronthosting.co.za> Martin Panter added the comment: Patch v4 with John?s doc string wording ---------- Added file: http://bugs.python.org/file37522/issue21279.v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 09:58:21 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 21 Dec 2014 08:58:21 +0000 Subject: [issue23096] Implementation-depended pickling floats with protocol 0 In-Reply-To: <1419149433.29.0.802482425543.issue23096@psf.upfronthosting.co.za> Message-ID: <1419152301.87.0.450196479811.issue23096@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Python implementation uses repr(value) and C implementation uses '%.17g' % value. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 11:38:05 2014 From: report at bugs.python.org (CensoredUsername) Date: Sun, 21 Dec 2014 10:38:05 +0000 Subject: [issue23094] Unpickler failing with PicklingError at frame end on readline due to a broken comparison In-Reply-To: <1419117872.02.0.125928182025.issue23094@psf.upfronthosting.co.za> Message-ID: <1419158285.2.0.0766973509963.issue23094@psf.upfronthosting.co.za> CensoredUsername added the comment: Indeed. In my case the problem was caused a subclassed Pickler which still used GLOBAL instead of STACK_GLOBAL in protocol 4. My own minimized test case was: data = b"\x80\x04\x95\x11\x00\x00\x00\x00\x00\x00\x00cpickle\nPickler\n." >>> pickletools.dis(data) 0: \x80 PROTO 4 2: \x95 FRAME 17 11: c GLOBAL 'pickle Pickler' 27: . STOP highest protocol among opcodes = 4 which should return pickle.Pickler ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 12:17:11 2014 From: report at bugs.python.org (Martin Panter) Date: Sun, 21 Dec 2014 11:17:11 +0000 Subject: [issue23093] repr() on detached stream objects fails In-Reply-To: <1419085189.47.0.13249408936.issue23093@psf.upfronthosting.co.za> Message-ID: <1419160631.81.0.86343022189.issue23093@psf.upfronthosting.co.za> Martin Panter added the comment: Here is patch v2, which ignores any exception derived from the Exception base class when reading the self.name etc properties. I?m interested what people think of this approach. ---------- Added file: http://bugs.python.org/file37523/detach-indep.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 15:17:16 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 21 Dec 2014 14:17:16 +0000 Subject: [issue23093] repr() on detached stream objects fails In-Reply-To: <1419085189.47.0.13249408936.issue23093@psf.upfronthosting.co.za> Message-ID: <1419171436.44.0.618482246515.issue23093@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It looks reasonable to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 16:58:49 2014 From: report at bugs.python.org (John Posner) Date: Sun, 21 Dec 2014 15:58:49 +0000 Subject: [issue21279] str.translate documentation incomplete In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za> Message-ID: <1419177529.03.0.258196797525.issue21279@psf.upfronthosting.co.za> John Posner added the comment: Patch of 12-21 looks good, Martin. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 17:59:25 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 21 Dec 2014 16:59:25 +0000 Subject: [issue21279] str.translate documentation incomplete In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za> Message-ID: <1419181165.9.0.117431387835.issue21279@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed wording looks superfluously verbose to me. Look also at description in Include/unicodeobject.h: /* Translate a string by applying a character mapping table to it and return the resulting Unicode object. The mapping table must map Unicode ordinal integers to Unicode ordinal integers or None (causing deletion of the character). Mapping tables may be dictionaries or sequences. Unmapped character ordinals (ones which cause a LookupError) are left untouched and are copied as-is. */ It is repeated (more detailed) in Doc/c-api/unicode.rst. Isn't it pretty clear? ---------- components: +Unicode nosy: +ezio.melotti, georg.brandl, haypo, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 19:24:26 2014 From: report at bugs.python.org (R. David Murray) Date: Sun, 21 Dec 2014 18:24:26 +0000 Subject: [issue22836] Broken "Exception ignored in:" message on exceptions in __repr__ In-Reply-To: <1415614969.23.0.620237340846.issue22836@psf.upfronthosting.co.za> Message-ID: <1419186266.58.0.856283162079.issue22836@psf.upfronthosting.co.za> R. David Murray added the comment: See also issue 6294 for a related problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 23:05:30 2014 From: report at bugs.python.org (Martin Panter) Date: Sun, 21 Dec 2014 22:05:30 +0000 Subject: [issue21279] str.translate documentation incomplete In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za> Message-ID: <1419199530.2.0.500289468832.issue21279@psf.upfronthosting.co.za> Martin Panter added the comment: Serhiy can you point out which bits are too verbose? Perhaps you prefer it without the bullet list like in the earlier 2014-12-13 version of the patch. Looking at the C API, I see a couple problems there: * Omits mentioning that an ordinal can map to a replacement string * It looks like the documented None behaviour applies when errors="ignore", otherwise it invokes a codec error handler ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 23:17:12 2014 From: report at bugs.python.org (Martin Panter) Date: Sun, 21 Dec 2014 22:17:12 +0000 Subject: [issue6294] Improve shutdown exception ignored message In-Reply-To: <1245196911.61.0.437199244327.issue6294@psf.upfronthosting.co.za> Message-ID: <1419200232.83.0.396173806105.issue6294@psf.upfronthosting.co.za> Martin Panter added the comment: Not sure what the original method to cause this message is. I?m guessing some code was trying to call a function that was set to None by the shutdown process, causing the exception message, and that repr() was also failing, causing the broken wording. Like this: $ python2 << PYTHON > class C: > def __repr__(self): return None() > def __del__(self): None() > x = C() > PYTHON Exception TypeError: "'NoneType' object is not callable" in ignored If this is the case, then it is the same problem as Issue 22836, where I have posted a test and a fix for Python 3. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 21 23:36:24 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Sun, 21 Dec 2014 22:36:24 +0000 Subject: [issue23098] mknod devices can be >32 bits Message-ID: <1419201384.94.0.109155979555.issue23098@psf.upfronthosting.co.za> New submission from Jes?s Cea Avi?n: Dan MacDonald told me that "os.mknod()" should accept devices >32 bits. I wrote this code in linux 64 bits: """ #include #include #include #include #include int main(void) { printf("%d", sizeof(dev_t)); return 0; } """ The result of running this is "8". We need a long long. I did this change in Python 2.7 branch: """ diff -r f00412d32b41 Modules/posixmodule.c --- a/Modules/posixmodule.c Sat Dec 20 13:41:14 2014 -0600 +++ b/Modules/posixmodule.c Sun Dec 21 23:30:00 2014 +0100 @@ -7009,9 +7009,9 @@ { char *filename; int mode = 0600; - int device = 0; + long long device = 0; int res; - if (!PyArg_ParseTuple(args, "s|ii:mknod", &filename, &mode, &device)) + if (!PyArg_ParseTuple(args, "s|iL:mknod", &filename, &mode, &device)) return NULL; Py_BEGIN_ALLOW_THREADS res = mknod(filename, mode, device); """ Looks like this patch is trivial. Please, comment. ---------- assignee: jcea keywords: easy messages: 233004 nosy: jcea priority: normal severity: normal stage: patch review status: open title: mknod devices can be >32 bits versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 00:34:16 2014 From: report at bugs.python.org (Martin Panter) Date: Sun, 21 Dec 2014 23:34:16 +0000 Subject: [issue22836] Broken "Exception ignored in:" message on exceptions in __repr__ In-Reply-To: <1415614969.23.0.620237340846.issue22836@psf.upfronthosting.co.za> Message-ID: <1419204856.49.0.210805257354.issue22836@psf.upfronthosting.co.za> Martin Panter added the comment: Patch v2 revises the unit tests so they are cleaner. Also now tests that the placeholders are in the exception reports. ---------- Added file: http://bugs.python.org/file37524/unraisable-continue.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 04:01:25 2014 From: report at bugs.python.org (Roundup Robot) Date: Mon, 22 Dec 2014 03:01:25 +0000 Subject: [issue23093] repr() on detached stream objects fails In-Reply-To: <1419085189.47.0.13249408936.issue23093@psf.upfronthosting.co.za> Message-ID: <20141222030111.50119.28980@psf.io> Roundup Robot added the comment: New changeset f3ff3e424b6f by Benjamin Peterson in branch '3.4': allow more operations to work on detached streams (closes #23093) https://hg.python.org/cpython/rev/f3ff3e424b6f New changeset afa8d8ab0937 by Benjamin Peterson in branch '2.7': allow more operations to work on detached streams (closes #23093) https://hg.python.org/cpython/rev/afa8d8ab0937 New changeset f2cfa8a348dd by Benjamin Peterson in branch 'default': merge 3.4 (#23093) https://hg.python.org/cpython/rev/f2cfa8a348dd ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 07:01:56 2014 From: report at bugs.python.org (Martin Panter) Date: Mon, 22 Dec 2014 06:01:56 +0000 Subject: [issue19539] The 'raw_unicode_escape' codec buggy + not appropriate for Python 3.x In-Reply-To: <1384051905.56.0.969775270474.issue19539@psf.upfronthosting.co.za> Message-ID: <1419228116.31.0.0723368338311.issue19539@psf.upfronthosting.co.za> Martin Panter added the comment: [Edit Error: 'utf8' codec can't decode byte 0xe2 in position 212: invalid continuation byte] Re-reading the suggested description, it struck me that for encoding, this is redundant with the ?backslashreplace? error handler: >>> test = "".join(map(chr, range(sys.maxunicode + 1))) >>> test.encode("raw-unicode-escape") == test.encode("latin-1", "backslashreplace") True However, decoding also seems similar to ?unicode_escape?, except that only \uXXXX and \UXXXXXXXX seem to be supported. Maybe there should be a warning that backslashes are not escaped: >>> "\\u005C".encode("raw-unicode-escape").decode("raw-unicode-escape") '\\' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 07:04:40 2014 From: report at bugs.python.org (Ian Lee) Date: Mon, 22 Dec 2014 06:04:40 +0000 Subject: [issue23061] Update pep8 to specify explicitly 'module level' imports at top of file In-Reply-To: <1418703864.09.0.281927050653.issue23061@psf.upfronthosting.co.za> Message-ID: <1419228280.63.0.0650862735677.issue23061@psf.upfronthosting.co.za> Ian Lee added the comment: So one concern that was brought up on GitHub was the fact that currently this is not actually followed universally in the Python standard library. In particular there are 636 errors in the standard library ``python pep8.py --select E402 --statistics /usr/lib/python3.4``. The vast majority are due to issues with dunder definitions ``__{all,author,copyright,credits,version,etc...}__`` before the imports. A lesser cause is imports in the middle of files. ``Lib/tokenize.py`` has pretty much all of these issues. In particular ``__all__`` is specifically mentioned that it should be declared AFTER the imports by PEP-8. That said, I would argue this is a good time to clean up that code in the standard library. Additionally, its possible that there might need to be some wording in the PEP about intermixing "try,except,else,finally" and possibly "if,elif,else" into the imports. E.g. ``` try: import unittest2 except: import unittest ``` ``` if sys.platform == 'win32': import foo ``` ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 07:16:07 2014 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 22 Dec 2014 06:16:07 +0000 Subject: [issue23061] Update pep8 to specify explicitly 'module level' imports at top of file In-Reply-To: <1418703864.09.0.281927050653.issue23061@psf.upfronthosting.co.za> Message-ID: <1419228967.14.0.24462771725.issue23061@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 07:37:23 2014 From: report at bugs.python.org (Ian Lee) Date: Mon, 22 Dec 2014 06:37:23 +0000 Subject: [issue23061] Update pep8 to specify explicitly 'module level' imports at top of file In-Reply-To: <1418703864.09.0.281927050653.issue23061@psf.upfronthosting.co.za> Message-ID: <1419230243.39.0.165402099002.issue23061@psf.upfronthosting.co.za> Ian Lee added the comment: I should add that I would be happy to patch the standard libraries to be compliant w.r.t. the imports at top of the files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 08:35:40 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 22 Dec 2014 07:35:40 +0000 Subject: [issue21279] str.translate documentation incomplete In-Reply-To: <1419199530.2.0.500289468832.issue21279@psf.upfronthosting.co.za> Message-ID: <2045607.dbza6R0L2x@raxxla> Serhiy Storchaka added the comment: > Serhiy can you point out which bits are too verbose? Perhaps you prefer it > without the bullet list like in the earlier 2014-12-13 version of the > patch. I prefer it without the bullet list and without LookupError expansion (there is a link to LookupError definition where IndexError and KeyError should be mentioned). Instead of new term "subscriptable objects" use "mappings or sequences" with links to glossary. > Looking at the C API, I see a couple problems there: Yes, it is slightly outdated and needs updates. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 09:38:25 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 22 Dec 2014 08:38:25 +0000 Subject: [issue21279] str.translate documentation incomplete In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za> Message-ID: <1419237505.86.0.309990949029.issue21279@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I agree with Serhiy: no bullet points, links to glossary (at least in doc), without repeating. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 10:20:23 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 22 Dec 2014 09:20:23 +0000 Subject: [issue23098] mknod devices can be >32 bits In-Reply-To: <1419201384.94.0.109155979555.issue23098@psf.upfronthosting.co.za> Message-ID: <1419240023.24.0.288419371995.issue23098@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is not so easy as look at first glance. PY_LONG_LONG should be used instead of long long. And as far as this type is optional, its use should be conditional if HAVE_LONG_LONG is defined. May be needed complex converter like _Py_Uid_Converter because dev_t on Linux is 64-bit unsigned int and can not fit in the range of 64-bit signed int. The code for 3.x should be even more complex due to using Argument Clinic. ---------- components: +Extension Modules nosy: +serhiy.storchaka type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 12:41:17 2014 From: report at bugs.python.org (Martin Panter) Date: Mon, 22 Dec 2014 11:41:17 +0000 Subject: [issue23099] BytesIO and StringIO values unavailable when closed Message-ID: <1419248477.31.0.512702147737.issue23099@psf.upfronthosting.co.za> New submission from Martin Panter: IOBase.close() doc says file operations raise ValueError, but it is not obvious to me that reading back the ?file? buffer is a file operation. >>> with BytesIO() as b: ... b.write(b"123") ... 3 >>> b.getvalue() Traceback (most recent call last): File "", line 1, in ValueError: I/O operation on closed file. Even worse, the memoryview gets corrupted on close(): >>> b = BytesIO(b"123") >>> m = b.getbuffer() >>> b.close() >>> bytes(m) b'\x98\x02>' I also noticed that in the ?io? implementation, writing to the file seems to be completely disallowed, even if it would not seem to change the size: >>> b = BytesIO(b"123") >>> m = b.getbuffer() >>> b.write(b"x") Traceback (most recent call last): File "", line 1, in BufferError: Existing exports of data: object cannot be re-sized ---------- components: IO messages: 233016 nosy: vadmium priority: normal severity: normal status: open title: BytesIO and StringIO values unavailable when closed type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 12:51:12 2014 From: report at bugs.python.org (Martin Panter) Date: Mon, 22 Dec 2014 11:51:12 +0000 Subject: [issue19548] 'codecs' module docs improvements In-Reply-To: <1384133353.82.0.173341188397.issue19548@psf.upfronthosting.co.za> Message-ID: <1419249072.56.0.121390982512.issue19548@psf.upfronthosting.co.za> Martin Panter added the comment: Adding patch v2 after learning how to compile the docs and fixing my errors. I also simplified the descriptions of the CodecInfo attributes by defering the constructor signatures to where they are fully defined under ?Codec base classes?, and merged the list of error handlers there as well. A side effect of merging error handler lists is that ?surrogatepass? is now defined for codecs in general, not just Codec.encode() and decode(). Also I noticed that ?unicode_escape? actually does Latin-1 decoding. ---------- Added file: http://bugs.python.org/file37525/codecs-doc.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 13:29:01 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 22 Dec 2014 12:29:01 +0000 Subject: [issue23099] BytesIO and StringIO values unavailable when closed In-Reply-To: <1419248477.31.0.512702147737.issue23099@psf.upfronthosting.co.za> Message-ID: <1419251341.08.0.124015492422.issue23099@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: getvalue() doesn't work after close() for purpose. close() frees memory used by BytesIO. >>> import io, sys >>> bio = io.BytesIO() >>> sys.getsizeof(bio) 52 >>> bio.write(b'x'*1000) 1000 >>> sys.getsizeof(bio) 1053 >>> bio.close() >>> sys.getsizeof(bio) 52 Changing the behavior will cause regression. The behavior of memoryview looks as a bug. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 14:08:18 2014 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Mon, 22 Dec 2014 13:08:18 +0000 Subject: [issue23098] mknod devices can be >32 bits In-Reply-To: <1419201384.94.0.109155979555.issue23098@psf.upfronthosting.co.za> Message-ID: <1419253698.69.0.389079144022.issue23098@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: Serhiy, could you consider to create a patch for 2.7 and 3.4?. I am not familiar with the details of Argument Clinic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 16:26:21 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 22 Dec 2014 15:26:21 +0000 Subject: [issue19548] 'codecs' module docs improvements In-Reply-To: <1384133353.82.0.173341188397.issue19548@psf.upfronthosting.co.za> Message-ID: <1419261981.09.0.0358603712356.issue19548@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thanks for those drafts, Martin - they look like a strong improvement to me. While I still had plenty of comments/questions on v2, I think that's more a reflection on how long it has been since we gave these docs a thorough overall review, moreso than a reflection on the proposed changes. Victor - I added you to the nosy list for this one, as I'd specifically like your comments on the StreamReader/Writer docs updates. I'd like to make it clear that these are distinct from the "text encoding only" APIs in the io module, while still accurately describing the behaviour of the standard codecs. ---------- nosy: +haypo versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 16:36:13 2014 From: report at bugs.python.org (Clement Rouault) Date: Mon, 22 Dec 2014 15:36:13 +0000 Subject: [issue22939] integer overflow in iterator object In-Reply-To: <1416912993.1.0.671503723984.issue22939@psf.upfronthosting.co.za> Message-ID: <1419262573.73.0.836648946466.issue22939@psf.upfronthosting.co.za> Clement Rouault added the comment: > > The call to PySequence_GetItem() may be expensive, and we have to drop > > the result if an OverflowError is raised after the call. > You do realize that this error will be very rare and therefore inconsequential. The real question is: why would you call the iterator for a new value if it will be discarded anyway ? I think it could be very misleading to see _getitem__ being called and have an OverflowError being raised afterward. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 17:32:47 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 22 Dec 2014 16:32:47 +0000 Subject: [issue23098] mknod devices can be >32 bits In-Reply-To: <1419201384.94.0.109155979555.issue23098@psf.upfronthosting.co.za> Message-ID: <1419265967.39.0.476973737849.issue23098@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch against 3.5. Unsigned bitwise int converter is used for dev_t because dev_t can be unsigned (and it is on Linux). This is not ideal solution, there is no overflow check, but at least it should work for correct code. ---------- keywords: +patch Added file: http://bugs.python.org/file37526/posix_dev_t_converter-3.5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 18:14:58 2014 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 22 Dec 2014 17:14:58 +0000 Subject: [issue19548] 'codecs' module docs improvements In-Reply-To: <1384133353.82.0.173341188397.issue19548@psf.upfronthosting.co.za> Message-ID: <1419268498.44.0.250008417455.issue19548@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 20:46:49 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 22 Dec 2014 19:46:49 +0000 Subject: [issue23099] BytesIO and StringIO values unavailable when closed In-Reply-To: <1419248477.31.0.512702147737.issue23099@psf.upfronthosting.co.za> Message-ID: <1419277609.93.0.827602251893.issue23099@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Even worse, the memoryview gets corrupted on close(): The BytesIO object should probably reject closing when a buffer is exported. > writing to the file seems to be completely disallowed, even if it > would not seem to change the size: An enhancement is probably possible there. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 21:13:36 2014 From: report at bugs.python.org (Alexandre Vassalotti) Date: Mon, 22 Dec 2014 20:13:36 +0000 Subject: [issue23096] Implementation-depended pickling floats with protocol 0 In-Reply-To: <1419149433.29.0.802482425543.issue23096@psf.upfronthosting.co.za> Message-ID: <1419279216.67.0.394146979167.issue23096@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: The repr for floats was changed some time ago to use a shorter decimal strings when possible. Both representations should yield the same float value once decoded. If we want to make the C and Python implementations of pickle consistent, then we should pick on what the Python version does currently: i.e., call repr on the float. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 21:34:56 2014 From: report at bugs.python.org (Martin Panter) Date: Mon, 22 Dec 2014 20:34:56 +0000 Subject: [issue21279] str.translate documentation incomplete In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za> Message-ID: <1419280496.64.0.224480509347.issue21279@psf.upfronthosting.co.za> Martin Panter added the comment: The problem with mappings and sequences is that they both require len() and iter() implementations, but str.translate() only requires __getitem__(). Perhaps a qualifier could work, like: The table must implement the __getitem__() method of mappings and sequences. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 22:22:06 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 22 Dec 2014 21:22:06 +0000 Subject: [issue23098] mknod devices can be >32 bits In-Reply-To: <1419201384.94.0.109155979555.issue23098@psf.upfronthosting.co.za> Message-ID: <1419283326.2.0.681534371927.issue23098@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: As pointed by Antoine there are other affected functions. Updated patch fixes converting of arguments or results in makedev(), major() and minor(). ---------- Added file: http://bugs.python.org/file37527/posix_dev_t_converter-3.5_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 22 23:58:17 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 22 Dec 2014 22:58:17 +0000 Subject: [issue23096] Implementation-depended pickling floats with protocol 0 In-Reply-To: <1419149433.29.0.802482425543.issue23096@psf.upfronthosting.co.za> Message-ID: <1419289097.18.0.35889629687.issue23096@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This looks less like a bug than an enhancement request. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 00:00:53 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 22 Dec 2014 23:00:53 +0000 Subject: [issue23088] Document that PyUnicode_AsUTF8() returns a null-terminated string In-Reply-To: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za> Message-ID: <1419289253.79.0.728700820447.issue23088@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This looks good to me. ---------- nosy: +pitrou stage: -> commit review type: -> behavior versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 00:31:12 2014 From: report at bugs.python.org (Martin Panter) Date: Mon, 22 Dec 2014 23:31:12 +0000 Subject: [issue22671] Typo in class io.BufferedIOBase docs In-Reply-To: <1413711352.27.0.0253692424247.issue22671@psf.upfronthosting.co.za> Message-ID: <1419291072.97.0.119230498097.issue22671@psf.upfronthosting.co.za> Martin Panter added the comment: Adding patch v2 with readinto1() as a ?mixin method? and dropped many of my earlier changes for better consistency with the introduction of the classes (which I never really read before :P) ---------- Added file: http://bugs.python.org/file37528/read-defaults.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 00:58:11 2014 From: report at bugs.python.org (Davin Potts) Date: Mon, 22 Dec 2014 23:58:11 +0000 Subject: [issue23100] multiprocessing doc organization impedes understanding Message-ID: <1419292691.51.0.0335324108877.issue23100@psf.upfronthosting.co.za> New submission from Davin Potts: The organization and multiple sections of the multiprocessing module's documentation do not adhere to the Python Dev Guidelines for economy of expression, affirmative tone, and/or code examples. Problem description: The raw material and information in the multiprocessing module docs are good to excellent and very information rich -- the presentation of that information suffers primarily from its organization. (1) Too much information is presented in the same or neighboring subsections where the economy of expression guidelines would advocate for a different approach. Specifically, section 17.2.2 "Reference" co-mingles discourses on usage topics with a description of the available objects and apis. Section 17.2.1 "Introduction" does something similar and though some of this can be helpful in an intro section, it takes discourse a bit far at times, arguably losing its focus which is to clearly introduce the reader to the module and efficiently set them on a healthy path to understanding topics and establish sufficient comfort to begin working with the module. Economy of expression would have us maintain focus in an Introduction or Reference section and re-organize such helpful discourses into supporting but distinct sections. (2) Affirmative tone is not consistently used throughout the docs. Multiple of the items under section 17.2.3 "Programming guidelines" leverage negative examples to motivate what should be done instead -- each of these can be rewritten in the way advocated in the Python Dev Guidelines for affirmative tone. (3) Per the Python Dev Guidelines for code examples, examples should accelerate understanding versus alternative prose. Code snippets showcasing internal behavior to the module, such as the "Beware of replacing sys.stdin" subsection inside 17.2.3.1 "All start methods", should arguably have their example code blocks replaced with prose. Section 17.2.4 "Examples" provides examples showcasing many facets all in the same example code block yet little to no supporting or motivating explanation is offered for each (more could be offered inline as well as outside as prose). Suggested changes: * Re-organize the single multiprocessing module doc into multiple in the style of the logging module. Specifically, tutorials should be created to house the "bunny trail" discourses from the Introduction/Reference sections and a cookbook should be created to house the material from the Examples section. * By de-bunny-trailing the Introduction/Reference sections, a more focused set of sections in the style of the threading module should result. * Limited modifications to code examples are advocated only so far as they restore the affirmative tone as needed. * New examples are not advocated as part of this issue; they are out-of-scope. This issue is intended to add to the path started/advocated by Issue 22952. It does not supplant but rather expands upon that issue. ---------- assignee: docs at python components: Documentation messages: 233030 nosy: davin, docs at python, rhettinger priority: normal severity: normal status: open title: multiprocessing doc organization impedes understanding type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 01:00:13 2014 From: report at bugs.python.org (Davin Potts) Date: Tue, 23 Dec 2014 00:00:13 +0000 Subject: [issue23100] multiprocessing doc organization impedes understanding In-Reply-To: <1419292691.51.0.0335324108877.issue23100@psf.upfronthosting.co.za> Message-ID: <1419292813.06.0.613585139377.issue23100@psf.upfronthosting.co.za> Davin Potts added the comment: I am happy to provide proposed patches but first can someone please clarify for me whether I should have those patches depend upon the patches from Issue 22952? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 01:03:38 2014 From: report at bugs.python.org (Davin Potts) Date: Tue, 23 Dec 2014 00:03:38 +0000 Subject: [issue22952] multiprocessing doc introduction not in affirmative tone In-Reply-To: <1417037709.37.0.435561396576.issue22952@psf.upfronthosting.co.za> Message-ID: <1419293018.0.0.450724956793.issue22952@psf.upfronthosting.co.za> Davin Potts added the comment: Procedural question (wanting to understand the label given to this issue): when documentation does not adhere to the Python Developer's Guide, is a fix for this considered an "enhancement"? ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 06:23:11 2014 From: report at bugs.python.org (Greg Turner) Date: Tue, 23 Dec 2014 05:23:11 +0000 Subject: [issue23101] \\di\\\\ Message-ID: <1419312191.92.0.129176482008.issue23101@psf.upfronthosting.co.za> Changes by Greg Turner : ---------- components: Distutils nosy: dstufft, eric.araujo, gmt priority: normal severity: normal status: open title: \\di\\\\ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 06:26:11 2014 From: report at bugs.python.org (Greg Turner) Date: Tue, 23 Dec 2014 05:26:11 +0000 Subject: [issue23101] bleh, sorry, my cat reported this non-bug :) Message-ID: <1419312371.53.0.207706834593.issue23101@psf.upfronthosting.co.za> Changes by Greg Turner : ---------- status: open -> closed title: \\di\\\\ -> bleh, sorry, my cat reported this non-bug :) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 07:26:38 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 23 Dec 2014 06:26:38 +0000 Subject: [issue23101] bleh, sorry, my cat reported this non-bug :) Message-ID: <1419315998.13.0.120454468156.issue23101@psf.upfronthosting.co.za> New submission from ?ric Araujo: :-) ---------- resolution: -> not a bug stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 07:36:29 2014 From: report at bugs.python.org (Greg Turner) Date: Tue, 23 Dec 2014 06:36:29 +0000 Subject: [issue23102] distutils: tip-toe around quirks owing to setuptools monkey-patching Extension Message-ID: <1419316588.75.0.487755278973.issue23102@psf.upfronthosting.co.za> New submission from Greg Turner: Clinical Presentation: Sometimes a developer consuming distutils will write what seems like a perfectly sensible setup.py, but something inscrutable happens: setup.py bombs out claiming "error: each element of 'ext_modules' option must be an Extension instance or 2-tuple". Prognosis: Once she manages to capture this error in pdb (takes some doing), intrepid developer may discover that, bizarrely, it IS an Extension instance, yet, somehow, (not isinstance(that_thing, Extension)) == True. Sooner or later she'll likely throw up her hands and follow some far-seeing dude's advice on StackOverflow([1]), which will probably work. If she undertakes a more thorough investigation, she may figure out the true etiology (see below), at which point, various minor tweaks will likely present themselves to her as obvious situation-specific solutions to the problem. Etiology: Developer likely employed code early in her module like: from distutils.extension import Extension . . (some other imports) . setup(..., ext_modules = [ Extension(...), ..., ], ...) What happened was that setuptools got imported by (presumably) some third-party code, at which point, setuptools monkey-patched distutils.extension.Extension(*), as is setuptools' SOP. However, in setup.py, a reference to the un-monkey-patched Extension was already saved off as __main__.Extension (along with, in all probability, other un-patched distutils things, as folks tend to consistently use one style or another of import). So __main__ calls (an un-monkey-patched version of) distutils.core.setup, which ultimately iterates through the list of Extensions, checking isinstance(item, Extension), or so, which, as can now be seen, is not going to be true. So, the error message is correct, it just fails to mention the possibility that there are multiple things called "Extension" floating around with identical repr's. Epidemiological Outlook: Seemingly this is a rare condition, but when a case develops, it can be costly, due to the likelihood of misdiagnosis and/or partial remission and relapse. One possible vaccine has been developed and is enclosed. It has not been subjected to clinical trial, nor peer-review (until now). It is enclosed as a patch which applies to python 2.7-3.5 and seems to do the trick in the particular case that was buggin' me (wish I could say it will do the trick for any non-broken use-case, but I can't, as if I made such a claim, I'd clearly jinx it). -- * Arguably, this is a bug or misfeature of setuptools, as here setuptools appears to too liberally assume that, if its modules were even casually imported, then it's a good time to monkey-patch distutils. However, IME, fixing this putative bug, threatens to be a non-trivial undertaking and cause a bunch of regressions and contingent hassles. Background URLS: [1] http://stackoverflow.com/questions/21594925/error-each-element-of-ext-modules-option-must-be-an-extension-instance-or-2-t https://bitbucket.org/pypa/setuptools/issue/309 https://bugs.gentoo.org/show_bug.cgi?id=532708 ---------- components: Distutils files: distutils_accomodate_extension_ducktypes.patch keywords: patch messages: 233034 nosy: dstufft, eric.araujo, gmt priority: normal severity: normal status: open title: distutils: tip-toe around quirks owing to setuptools monkey-patching Extension type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file37529/distutils_accomodate_extension_ducktypes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 07:44:22 2014 From: report at bugs.python.org (Ned Deily) Date: Tue, 23 Dec 2014 06:44:22 +0000 Subject: [issue23100] multiprocessing doc organization impedes understanding In-Reply-To: <1419292691.51.0.0335324108877.issue23100@psf.upfronthosting.co.za> Message-ID: <1419317062.64.0.113771945952.issue23100@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 08:22:29 2014 From: report at bugs.python.org (Martin Panter) Date: Tue, 23 Dec 2014 07:22:29 +0000 Subject: [issue19548] 'codecs' module docs improvements In-Reply-To: <1384133353.82.0.173341188397.issue19548@psf.upfronthosting.co.za> Message-ID: <1419319349.79.0.432489363036.issue19548@psf.upfronthosting.co.za> Martin Panter added the comment: New patch version addressing many of the comments; thanks for reviewing! Also adds and extends some unit tests to confirm some of the corner cases I am documenting. ---------- Added file: http://bugs.python.org/file37530/codecs-doc.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 08:26:17 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 23 Dec 2014 07:26:17 +0000 Subject: [issue23099] BytesIO and StringIO values unavailable when closed In-Reply-To: <1419248477.31.0.512702147737.issue23099@psf.upfronthosting.co.za> Message-ID: <1419319577.48.0.199310652307.issue23099@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which rejects close() when a buffer is exported. ---------- keywords: +patch stage: -> patch review versions: +Python 2.7, Python 3.5 Added file: http://bugs.python.org/file37531/bytesio_exported_reject_close.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 08:55:51 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 23 Dec 2014 07:55:51 +0000 Subject: [issue23098] mknod devices can be >32 bits In-Reply-To: <1419283326.2.0.681534371927.issue23098@psf.upfronthosting.co.za> Message-ID: <6860135.5NaleL5fka@raxxla> Serhiy Storchaka added the comment: And here are patches for 2.7 and 3.4 (unfortunately none of patches is applied clear to other version). ---------- Added file: http://bugs.python.org/file37532/posix_dev_t_converter-2.7.patch Added file: http://bugs.python.org/file37533/posix_dev_t_converter-3.4.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r c6491d91d59a Modules/posixmodule.c --- a/Modules/posixmodule.c Sat Dec 20 17:42:24 2014 +0200 +++ b/Modules/posixmodule.c Tue Dec 23 09:48:10 2014 +0200 @@ -474,6 +474,29 @@ OverflowUp: #endif /* MS_WINDOWS */ +#if defined(HAVE_MKNOD) && defined(HAVE_MAKEDEV) +static int +_Py_Dev_Converter(PyObject *obj, void *p) +{ +#ifdef HAVE_LONG_LONG + *((dev_t *)p) = PyLong_AsUnsignedLongLong(obj); +#else + *((dev_t *)p) = PyLong_AsUnsignedLong(obj); +#endif + if (PyErr_Occurred()) + return 0; + return 1; +} + +#ifdef HAVE_LONG_LONG +# define _PyLong_FromDev PyLong_FromLongLong +#else +# define _PyLong_FromDev PyLong_FromLong +#endif + +#endif + + #if defined _MSC_VER && _MSC_VER >= 1400 /* Microsoft CRT in VS2005 and higher will verify that a filehandle is * valid and raise an assertion if it isn't. @@ -1426,11 +1449,10 @@ static PyObject* #else PyStructSequence_SET_ITEM(v, 1, PyInt_FromLong((long)st->st_ino)); #endif -#if defined(HAVE_LONG_LONG) && !defined(MS_WINDOWS) - PyStructSequence_SET_ITEM(v, 2, - PyLong_FromLongLong((PY_LONG_LONG)st->st_dev)); +#ifdef MS_WINDOWS + PyStructSequence_SET_ITEM(v, 2, PyLong_FromUnsignedLong(st->st_dev)); #else - PyStructSequence_SET_ITEM(v, 2, PyInt_FromLong((long)st->st_dev)); + PyStructSequence_SET_ITEM(v, 2, _PyLong_FromDev(st->st_dev)); #endif PyStructSequence_SET_ITEM(v, 3, PyInt_FromLong((long)st->st_nlink)); #if defined(MS_WINDOWS) @@ -7009,9 +7031,11 @@ posix_mknod(PyObject *self, PyObject *ar { char *filename; int mode = 0600; - int device = 0; + dev_t device = 0; int res; - if (!PyArg_ParseTuple(args, "s|ii:mknod", &filename, &mode, &device)) + if (!PyArg_ParseTuple(args, "s|iO&:mknod", + &filename, &mode, + _Py_Dev_Converter, &device)) return NULL; Py_BEGIN_ALLOW_THREADS res = mknod(filename, mode, device); @@ -7031,8 +7055,8 @@ Extracts a device major number from a ra static PyObject * posix_major(PyObject *self, PyObject *args) { - int device; - if (!PyArg_ParseTuple(args, "i:major", &device)) + dev_t device; + if (!PyArg_ParseTuple(args, "O&:major", _Py_Dev_Converter, &device)) return NULL; return PyInt_FromLong((long)major(device)); } @@ -7044,8 +7068,8 @@ Extracts a device minor number from a ra static PyObject * posix_minor(PyObject *self, PyObject *args) { - int device; - if (!PyArg_ParseTuple(args, "i:minor", &device)) + dev_t device; + if (!PyArg_ParseTuple(args, "O&:minor", _Py_Dev_Converter, &device)) return NULL; return PyInt_FromLong((long)minor(device)); } @@ -7060,7 +7084,7 @@ posix_makedev(PyObject *self, PyObject * int major, minor; if (!PyArg_ParseTuple(args, "ii:makedev", &major, &minor)) return NULL; - return PyInt_FromLong((long)makedev(major, minor)); + return _PyLong_FromDev(makedev(major, minor)); } #endif /* device macros */ @@ -8522,7 +8546,6 @@ setup_confname_table(struct constdef *ta { PyObject *d = NULL; size_t i; - qsort(table, tablesize, sizeof(struct constdef), cmp_constdefs); d = PyDict_New(); if (d == NULL) -------------- next part -------------- diff -r c4643b32cd9a Modules/posixmodule.c --- a/Modules/posixmodule.c Mon Dec 22 22:09:50 2014 +0100 +++ b/Modules/posixmodule.c Tue Dec 23 09:37:08 2014 +0200 @@ -623,6 +623,29 @@ fail: #endif /* MS_WINDOWS */ +#if defined(HAVE_MKNOD) && defined(HAVE_MAKEDEV) +static int +_Py_Dev_Converter(PyObject *obj, void *p) +{ +#ifdef HAVE_LONG_LONG + *((dev_t *)p) = PyLong_AsUnsignedLongLong(obj); +#else + *((dev_t *)p) = PyLong_AsUnsignedLong(obj); +#endif + if (PyErr_Occurred()) + return 0; + return 1; +} + +#ifdef HAVE_LONG_LONG +# define _PyLong_FromDev PyLong_FromLongLong +#else +# define _PyLong_FromDev PyLong_FromLong +#endif + +#endif + + #ifdef AT_FDCWD /* * Why the (int) cast? Solaris 10 defines AT_FDCWD as 0xffd19553 (-3041965); @@ -2218,11 +2241,8 @@ static PyObject* #endif #ifdef MS_WINDOWS PyStructSequence_SET_ITEM(v, 2, PyLong_FromUnsignedLong(st->st_dev)); -#elif defined(HAVE_LONG_LONG) - PyStructSequence_SET_ITEM(v, 2, - PyLong_FromLongLong((PY_LONG_LONG)st->st_dev)); -#else - PyStructSequence_SET_ITEM(v, 2, PyLong_FromLong((long)st->st_dev)); +#else + PyStructSequence_SET_ITEM(v, 2, _PyLong_FromDev(st->st_dev)); #endif PyStructSequence_SET_ITEM(v, 3, PyLong_FromLong((long)st->st_nlink)); #if defined(MS_WINDOWS) @@ -8633,16 +8653,16 @@ posix_mknod(PyObject *self, PyObject *ar { path_t path; int mode = 0666; - int device = 0; + dev_t device = 0; int dir_fd = DEFAULT_DIR_FD; int result; PyObject *return_value = NULL; static char *keywords[] = {"path", "mode", "device", "dir_fd", NULL}; memset(&path, 0, sizeof(path)); - if (!PyArg_ParseTupleAndKeywords(args, kwargs, "O&|ii$O&:mknod", keywords, + if (!PyArg_ParseTupleAndKeywords(args, kwargs, "O&|iO&$O&:mknod", keywords, path_converter, &path, - &mode, &device, + &mode, _Py_Dev_Converter, &device, #ifdef HAVE_MKNODAT dir_fd_converter, &dir_fd #else @@ -8682,8 +8702,8 @@ Extracts a device major number from a ra static PyObject * posix_major(PyObject *self, PyObject *args) { - int device; - if (!PyArg_ParseTuple(args, "i:major", &device)) + dev_t device; + if (!PyArg_ParseTuple(args, "O&:major", _Py_Dev_Converter, &device)) return NULL; return PyLong_FromLong((long)major(device)); } @@ -8695,8 +8715,8 @@ Extracts a device minor number from a ra static PyObject * posix_minor(PyObject *self, PyObject *args) { - int device; - if (!PyArg_ParseTuple(args, "i:minor", &device)) + dev_t device; + if (!PyArg_ParseTuple(args, "O&:minor", _Py_Dev_Converter, &device)) return NULL; return PyLong_FromLong((long)minor(device)); } @@ -8711,7 +8731,7 @@ posix_makedev(PyObject *self, PyObject * int major, minor; if (!PyArg_ParseTuple(args, "ii:makedev", &major, &minor)) return NULL; - return PyLong_FromLong((long)makedev(major, minor)); + return _PyLong_FromDev(makedev(major, minor)); } #endif /* device macros */ From report at bugs.python.org Tue Dec 23 10:57:26 2014 From: report at bugs.python.org (Seth Bromberger) Date: Tue, 23 Dec 2014 09:57:26 +0000 Subject: [issue23103] ipaddress should be Flyweight Message-ID: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> New submission from Seth Bromberger: ipaddress.ip_address instances should be flyweight. There's really no reason to make them mutable: >>> a = ipaddress.ip_address("10.1.2.3") >>> b = ipaddress.ip_address("10.1.2.3") >>> id(a) 140066533772368 >>> id(b) 140066504622544 Especially with IPv6 and large numbers of addresses, it would be helpful not to have separate instances with the same underlying properties. ---------- components: Library (Lib) messages: 233038 nosy: Seth.Bromberger priority: normal severity: normal status: open title: ipaddress should be Flyweight type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 11:04:21 2014 From: report at bugs.python.org (Seth Bromberger) Date: Tue, 23 Dec 2014 10:04:21 +0000 Subject: [issue23103] ipaddress should be Flyweight In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> Message-ID: <1419329061.09.0.728813519886.issue23103@psf.upfronthosting.co.za> Seth Bromberger added the comment: Confirmed on 3.4.0; likely exists in previous versions as well. ---------- versions: +Python 3.4 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 11:38:47 2014 From: report at bugs.python.org (Berker Peksag) Date: Tue, 23 Dec 2014 10:38:47 +0000 Subject: [issue23103] ipaddress should be Flyweight In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> Message-ID: <1419331127.81.0.411011171159.issue23103@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +ncoghlan, pmoody _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 11:48:50 2014 From: report at bugs.python.org (Changaco) Date: Tue, 23 Dec 2014 10:48:50 +0000 Subject: [issue23058] argparse silently ignores arguments In-Reply-To: <1418677327.73.0.355612765077.issue23058@psf.upfronthosting.co.za> Message-ID: <1419331730.52.0.922162928129.issue23058@psf.upfronthosting.co.za> Changaco added the comment: honcho has been affected by this: https://github.com/nickstenning/honcho/issues/122 Working around the problem is possible but not very pretty: https://github.com/nickstenning/honcho/pull/121 ---------- nosy: +Changaco _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 11:49:08 2014 From: report at bugs.python.org (Changaco) Date: Tue, 23 Dec 2014 10:49:08 +0000 Subject: [issue9351] argparse set_defaults on subcommands should override top level set_defaults In-Reply-To: <1279894012.43.0.0678646409.issue9351@psf.upfronthosting.co.za> Message-ID: <1419331748.4.0.242584980935.issue9351@psf.upfronthosting.co.za> Changaco added the comment: The broken patch made it into the 2.7.9 release, causing argparse to silently ignore arguments, cf http://bugs.python.org/issue23058 ---------- nosy: +Changaco _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 12:33:43 2014 From: report at bugs.python.org (=?utf-8?b?0JDQvdC00YDQtdC5INCf0LDRgNCw0LzQvtC90L7Qsg==?=) Date: Tue, 23 Dec 2014 11:33:43 +0000 Subject: [issue23104] [Windows x86-64] Incorrect function call Message-ID: <1419334423.22.0.551057120801.issue23104@psf.upfronthosting.co.za> New submission from ?????? ?????????: To reproduce: 0) Compile attached testlib.c 1) Run the following code: from __future__ import print_function from __future__ import unicode_literals from ctypes import * testlib = windll.LoadLibrary('testlib') testfun = testlib.test class objid(Structure): _fields_ = [('bytes', c_ubyte*16)] print('Calling...') testfun(objid(), c_wchar_p('test')) print('Done.') --- It gives different output for different versions of Python and processor architectures: >c:\python27\python test.py Calling... test Done. >c:\python34\python test.py Calling... test Done. >c:\python27-64\python test.py Calling... test Done. >c:\python34-64\python test.py Calling... Done. It appears that Python 3.4 on Windows x86-64 generates incorrect function call code. ---------- components: ctypes files: testlib.c messages: 233042 nosy: ??????.????????? priority: normal severity: normal status: open title: [Windows x86-64] Incorrect function call versions: Python 3.4 Added file: http://bugs.python.org/file37534/testlib.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 12:49:43 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 23 Dec 2014 11:49:43 +0000 Subject: [issue23103] ipaddress should be Flyweight In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> Message-ID: <1419335383.23.0.383068397044.issue23103@psf.upfronthosting.co.za> Josh Rosenberg added the comment: What is your proposal? WeakValueDictionary mapping raw bytes object to single instance of ipaddress that is queried from ipaddress's __new__? No built-in has quite that extensive a level of caching and aggressive deduplication to my knowledge. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 14:52:14 2014 From: report at bugs.python.org (Seth Bromberger) Date: Tue, 23 Dec 2014 13:52:14 +0000 Subject: [issue23103] ipaddress should be Flyweight In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> Message-ID: <1419342734.31.0.498385362884.issue23103@psf.upfronthosting.co.za> Seth Bromberger added the comment: >What is your proposal? WeakValueDictionary mapping raw bytes object to single instance of ipaddress that is queried from ipaddress's __new__? No built-in has quite that extensive a level of caching and aggressive deduplication to my knowledge. I was thinking along those lines, but since v4 addresses are just UInt32 and v6 are UInt128, somehow mapping just the "address" information if we can do that via weakref dicts. Right now these objects can't really be used to represent addresses parsed from logs with tens of millions of entries generated by a couple thousand machines. It would be nice to have a memory-efficient way of doing that without having to duplicate the concept in a third-party package. There are a few other changes I'd like to see/make as well - this package is too focused on external functions for manipulating/creating addresses, when standard object/method structure would serve it better and be more intuitive. There is also no discernible need to modify an IP address' value. They should be thought of as immutables to the extent we can enforce that policy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 15:19:07 2014 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 23 Dec 2014 14:19:07 +0000 Subject: [issue23102] distutils: tip-toe around quirks owing to setuptools monkey-patching Extension In-Reply-To: <1419316588.75.0.487755278973.issue23102@psf.upfronthosting.co.za> Message-ID: <1419344347.71.0.878553587574.issue23102@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 15:22:39 2014 From: report at bugs.python.org (Donald Stufft) Date: Tue, 23 Dec 2014 14:22:39 +0000 Subject: [issue22669] Test_venv fails when _ctypes is not available. In-Reply-To: <1413679068.77.0.788594007735.issue22669@psf.upfronthosting.co.za> Message-ID: <1419344559.69.0.272784283966.issue22669@psf.upfronthosting.co.za> Donald Stufft added the comment: This should be fixed now as of https://hg.python.org/cpython/rev/651e1862dbed, https://hg.python.org/cpython/rev/651e1862dbed, and https://hg.python.org/cpython/rev/9f60d024e586. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 15:30:27 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 23 Dec 2014 14:30:27 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za> Message-ID: <20141223143009.125169.9822@psf.io> Roundup Robot added the comment: New changeset edf669b13482 by Serhiy Storchaka in branch 'default': Issue #21793: Added http.HTTPStatus enums (i.e. HTTPStatus.OK, https://hg.python.org/cpython/rev/edf669b13482 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 15:31:42 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 23 Dec 2014 14:31:42 +0000 Subject: [issue21793] httplib client/server status refactor In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za> Message-ID: <1419345102.98.0.685056222705.issue21793@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your contribution Demian. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 15:38:55 2014 From: report at bugs.python.org (Sworddragon) Date: Tue, 23 Dec 2014 14:38:55 +0000 Subject: [issue23105] os.O_SHLOCK and os.O_EXLOCK are not available on Linux Message-ID: <1419345535.42.0.312768269587.issue23105@psf.upfronthosting.co.za> New submission from Sworddragon: >From the documentation: " os.O_DSYNC os.O_RSYNC os.O_SYNC os.O_NDELAY os.O_NONBLOCK os.O_NOCTTY os.O_SHLOCK os.O_EXLOCK os.O_CLOEXEC These constants are only available on Unix. " But os.O_SHLOCK and os.O_EXLOCK are not available on my system (Linux 3.16.7-ckt1 x86_64): sworddragon at ubuntu:~$ python3 Python 3.4.2 (default, Dec 4 2014, 09:34:20) [GCC 4.9.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.O_SHLOCK Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'O_SHLOCK' >>> os.O_EXLOCK Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'O_EXLOCK' >>> exit() ---------- messages: 233048 nosy: Sworddragon priority: normal severity: normal status: open title: os.O_SHLOCK and os.O_EXLOCK are not available on Linux versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 15:39:17 2014 From: report at bugs.python.org (Sworddragon) Date: Tue, 23 Dec 2014 14:39:17 +0000 Subject: [issue23105] os.O_SHLOCK and os.O_EXLOCK are not available on Linux In-Reply-To: <1419345535.42.0.312768269587.issue23105@psf.upfronthosting.co.za> Message-ID: <1419345557.21.0.168579533326.issue23105@psf.upfronthosting.co.za> Changes by Sworddragon : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 15:39:27 2014 From: report at bugs.python.org (Sworddragon) Date: Tue, 23 Dec 2014 14:39:27 +0000 Subject: [issue23105] os.O_SHLOCK and os.O_EXLOCK are not available on Linux In-Reply-To: <1419345535.42.0.312768269587.issue23105@psf.upfronthosting.co.za> Message-ID: <1419345567.27.0.925513837781.issue23105@psf.upfronthosting.co.za> Changes by Sworddragon : ---------- components: +Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 15:50:59 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 23 Dec 2014 14:50:59 +0000 Subject: [issue23103] ipaddress should be Flyweight In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> Message-ID: <1419346259.93.0.833989186719.issue23103@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: IP address instances already are immutable and flyweight. There are no mutating methods. And a number of address attributes (packed, is_loopback, etc) are calculated on fly from integer representation. But IP address objects can be lighter. 1) Use __slots__. 2) Every instance has the _version attribute. Why this is not class attribute? 3) Memory consumption can be even less if IP addresses would int subclasses. But this changes the API (in particular adds the __index__ method) and I doubt that we should do this. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 16:32:36 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 23 Dec 2014 15:32:36 +0000 Subject: [issue23103] ipaddress should be Flyweight In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> Message-ID: <1419348756.61.0.984052252765.issue23103@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 16:39:44 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 23 Dec 2014 15:39:44 +0000 Subject: [issue23105] os.O_SHLOCK and os.O_EXLOCK are not available on Linux In-Reply-To: <1419345535.42.0.312768269587.issue23105@psf.upfronthosting.co.za> Message-ID: <1419349184.22.0.850960619975.issue23105@psf.upfronthosting.co.za> R. David Murray added the comment: The documentation says "Some of them are not available on all platforms. For descriptions of their availability and use, consult the open(2) manual page on Unix or the MSDN on Windows.". The important bit there being "consult the open(2) manual page on Unix" for availability. That said, since the options are grouped and labeled with per-platform availability...but with a slightly different meaning of the word platform...I think the docs could be clarified. Do you have a suggestion for rewording that sentence to make it clearer? ---------- assignee: -> docs at python components: +Documentation -Library (Lib) nosy: +docs at python, r.david.murray versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 17:11:22 2014 From: report at bugs.python.org (Sworddragon) Date: Tue, 23 Dec 2014 16:11:22 +0000 Subject: [issue23105] os.O_SHLOCK and os.O_EXLOCK are not available on Linux In-Reply-To: <1419345535.42.0.312768269587.issue23105@psf.upfronthosting.co.za> Message-ID: <1419351082.15.0.771690075404.issue23105@psf.upfronthosting.co.za> Sworddragon added the comment: I have missed the first part of the documentation and am not sure if something needs really to be changed. But if you think so maybe comments like "These constants are only available on Unix." could be extended by the word "commonly" like "These constants are commonly only available on Unix.". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 17:29:57 2014 From: report at bugs.python.org (Seth Bromberger) Date: Tue, 23 Dec 2014 16:29:57 +0000 Subject: [issue23103] ipaddress should be Flyweight In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> Message-ID: <1419352197.47.0.223627339081.issue23103@psf.upfronthosting.co.za> Seth Bromberger added the comment: 1) However: >>> b = ipaddress.IPv4Address('1.2.3.4') >>> a = ipaddress.IPv4Address('1.2.3.4') >>> id(a) 4428380928 >>> id(b) 4428381768 >>> a == b True >>> b._ip += 6 >>> id(b) 4428381768 >>> b IPv4Address('1.2.3.10') 2) Isn?t _version already a class attribute? It?s set in _Basev4/Basev6. 3) Memory consumption seems particularly wasteful in the current implementation: it takes 56 bytes (via sys.getsizeof) to store what amounts to 4 bytes of data. I thought about subclassing Int as well, and I agree it?s the wrong approach. There are too many int methods that don?t make sense in the context of IP addresses. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 18:25:06 2014 From: report at bugs.python.org (Julien Palard) Date: Tue, 23 Dec 2014 17:25:06 +0000 Subject: [issue23043] doctest ignores "from __future__ import print_function" In-Reply-To: <1418419698.58.0.173848086418.issue23043@psf.upfronthosting.co.za> Message-ID: <1419355506.39.0.77810297941.issue23043@psf.upfronthosting.co.za> Julien Palard added the comment: Works for me in 2.7.8: $ python --version Python 2.7.8 # cat /tmp/test.py #!/usr/bin/env python from __future__ import print_function def toto(): """ >>> print (42, 43) 42 43 """ return 42 $ python -m doctest -v /tmp/test.py Trying: print (42, 43) Expecting: 42 43 ok 1 items had no tests: test 1 items passed all tests: 1 tests in test.toto 1 tests in 2 items. 1 passed and 0 failed. Test passed. ---------- nosy: +Julien.Palard _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 18:59:16 2014 From: report at bugs.python.org (Demian Brecht) Date: Tue, 23 Dec 2014 17:59:16 +0000 Subject: [issue23043] doctest ignores "from __future__ import print_function" In-Reply-To: <1418419698.58.0.173848086418.issue23043@psf.upfronthosting.co.za> Message-ID: <1419357556.68.0.163023318175.issue23043@psf.upfronthosting.co.za> Demian Brecht added the comment: @Julien.Palard: There's a subtle difference between your test and the issue as written. Your test lives within a module and therefore executes testmodule (see https://hg.python.org/cpython/file/9f60d024e586/Lib/doctest.py#l1819) whereas the issue reported uses testfile (see https://hg.python.org/cpython/file/9f60d024e586/Lib/doctest.py#l1923). I believe the issue is that the __future__ import doesn't make it into compile (https://hg.python.org/cpython/file/9f60d024e586/Lib/doctest.py#l1314). I've been able to confirm the issue on 2.7 and that it's been resolved in 3.5. Unfortunately, I haven't had time to dig into this any further. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 19:03:08 2014 From: report at bugs.python.org (Demian Brecht) Date: Tue, 23 Dec 2014 18:03:08 +0000 Subject: [issue23043] doctest ignores "from __future__ import print_function" In-Reply-To: <1418419698.58.0.173848086418.issue23043@psf.upfronthosting.co.za> Message-ID: <1419357788.31.0.529127505731.issue23043@psf.upfronthosting.co.za> Demian Brecht added the comment: > it's been resolved in 3.5 Sorry, that statement can be a little misleading, possibly indicating that something may have changed in the doctest globals handling. It was resolved in 3.5 because print is no longer a statement so this ambiguous behaviour resolved by the print_function import no longer exists. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 20:52:08 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 23 Dec 2014 19:52:08 +0000 Subject: [issue23103] ipaddress should be Flyweight In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> Message-ID: <1419364328.71.0.31432154759.issue23103@psf.upfronthosting.co.za> R. David Murray added the comment: If ipaddress objects are already immutable, it seems to me that having a registry that makes it so there is only one instance per ip value isn't a crazy idea. I've written such code in other contexts and it's not complicated. We have caching of identifier strings and "common" integer constants for a reason...this seems a logical extension of that policy in the realm of a specific library data type. The opposite argument is that it may be better left up to the application that has to handle lots of ips to do the caching according to what it knows to be an optimum pattern. So consider me +0 on the idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 21:08:58 2014 From: report at bugs.python.org (Seth Bromberger) Date: Tue, 23 Dec 2014 20:08:58 +0000 Subject: [issue23103] ipaddress should be Flyweight In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> Message-ID: <1419365338.31.0.0904698826059.issue23103@psf.upfronthosting.co.za> Seth Bromberger added the comment: >The opposite argument is that it may be better left up to the application that has to handle lots of ips to do the caching according to what it knows to be an optimum pattern. I'd agree with you wholeheartedly if ipaddress wasn't part of stdlib, but the issue is that people generally gravitate to using stdlib over other packages when given the choice, and having something that behaves reasonably* in stdlib makes sense wherever possible. *in this case, reasonably means, I think, "I shouldn't have to worry that there's 1300% overhead for using IPv4Address() over a native 32-bit representation of an IP address." This matters little when you're just creating a few of these, but best practices regarding reuse might persuade folks to use these classes for all sorts of things. Doing things sanely at scale by default doesn't necessarily preclude further optimization if some developer thinks it's warranted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 21:24:27 2014 From: report at bugs.python.org (Jakub Wilk) Date: Tue, 23 Dec 2014 20:24:27 +0000 Subject: [issue22350] nntplib file write failure causes exception from QUIT command In-Reply-To: <1410061219.03.0.0230581897355.issue22350@psf.upfronthosting.co.za> Message-ID: <1419366267.84.0.780011933507.issue22350@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 23:32:56 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 23 Dec 2014 22:32:56 +0000 Subject: [issue22669] Test_venv fails when _ctypes is not available. In-Reply-To: <1413679068.77.0.788594007735.issue22669@psf.upfronthosting.co.za> Message-ID: <1419373976.5.0.830030655292.issue22669@psf.upfronthosting.co.za> Terry J. Reedy added the comment: test_venv passed on Open Indiana in the 14:10-14:22 buildbot runs triggered by the patch. It failed with a different error on a later default run, but that looked like a different issue, if permanent. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 23:33:51 2014 From: report at bugs.python.org (Donald Stufft) Date: Tue, 23 Dec 2014 22:33:51 +0000 Subject: [issue22669] Test_venv fails when _ctypes is not available. In-Reply-To: <1413679068.77.0.788594007735.issue22669@psf.upfronthosting.co.za> Message-ID: <1419374031.47.0.289610512136.issue22669@psf.upfronthosting.co.za> Donald Stufft added the comment: I'm not sure how to get a link to that, can you link it and I can see if I think it's a permanent error or not? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 23 23:42:14 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 23 Dec 2014 22:42:14 +0000 Subject: [issue22669] Test_venv fails when _ctypes is not available. In-Reply-To: <1413679068.77.0.788594007735.issue22669@psf.upfronthosting.co.za> Message-ID: <1419374534.49.0.0612119768109.issue22669@psf.upfronthosting.co.za> Terry J. Reedy added the comment: http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/9012/steps/test/logs/stdio Start with buildbot.python.org, select set of (all/stable) buildbots for version. 'Build ####' like gives commit(s) that triggered build. Test stdio link, as above, gives test results. Above was triggered by Serhiy's commit after yours. "No module named pip.__main__;" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 00:04:39 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 23 Dec 2014 23:04:39 +0000 Subject: [issue23103] ipaddress should be Flyweight In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> Message-ID: <1419375879.99.0.158111396046.issue23103@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Adding __slots__ is reasonable. Adding caching to fold together repeated addresses is dubious (it comes with its own space and time cost but won't benefit all users) and, as David said, the decision on how to handle this is up to the user. Also, it is rather late in the game to be challenging the design of the module. IIRC, this code or some variant of it already had heavy use prior to landing in the standard library (it also took into account what was learned with various other ipaddr modules). The module docs say that the library was designed for speed and makes no mention of optimizing for space. For the most part, once an API is deployed, users can be expected to exercise every feature whether intended or not. Right now, you can add attributes to two otherwise indistinct ipaddresses. The OP proposes to break that code. Right now, if a user has concerns about memory use due to duplicate address instances, they can easily created their own interning scheme (a = intern_dict.setdefault(a, a)). If the OP get his wish, then those users will be worse off (due to double interning). In other words, this ship has already sailed. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 00:07:22 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Tue, 23 Dec 2014 23:07:22 +0000 Subject: [issue23103] ipaddress should be Flyweight In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> Message-ID: <1419376042.44.0.12430024255.issue23103@psf.upfronthosting.co.za> Josh Rosenberg added the comment: So, just to be clear, checking the implementation (as of 3.4): 1. All the ipaddress classes leave __slots__ unset. So the overhead is actually higher than 56 bytes per instance; the __dict__ for an IPv4Address (ignoring the actual keys and values in the dict, just looking at the size of the dict itself), on Python 3.4, 64 bit Windows, is 56 + 288 = 344 bytes. Based on the size of the dict, I'm guessing some instance attributes aren't being set eagerly in __init__, so it's not getting the reduced memory usage from shared key dictionaries either. 2. It looks like as of 3.4, _version and _max_prefixlen were both instance attributes; the current code base seems to have made _max_prefixlen a class attribute, but left _version as an instance attribute (anything set on self is an instance attribute; doesn't matter if it's set in __init__ of a base class) 3. Even if we switch to using __slots__, remove support for weak references and user added attributes, and store nothing but the raw address encoded as an int, you're never going to get true "flyweight" objects in CPython. The lowest instance cost you can get for a class defined in Python (on a system with 64 bit pointers) inheriting from object, is 40 bytes, plus 8 bytes per slot (plus the actual cost of the int object, which is another 16 bytes for an IPv4 address on a 64 bit OS). If you want it lighter-weight than that, either you need to inherit from another built-in that it even lighter-weight, or you need to implement it in C. If you built IPv4Address on top of int for instance, you could get the instance cost down to 16 bytes. Downside to inheriting from int is that you'll interact with many other objects as if you were an int, which can cause a lot of unexpected behaviors (as others have noted). Basically, there is no concept of "flyweight" object in Python. Aside from implementing it in C or inheriting from int, you're going to be using an absolute minimum (on 64 bit build) of 48 bytes for the basic object structure, plus another 16 for the int itself, 64 bytes total, or about 16x the "real" data being stored. Using a WeakValueDictionary would actually require another 8 bytes per instance (a slot for __weakref__), and the overhead of the dictionary would likely be higher than the memory saved (unless you're regularly creating duplicate IP addresses and storing them for the long haul, but I suspect this is a less common use case than processing many different IP addresses once or twice). I do think it would be a good idea to use __slots__ properly to get the memory down below 100 bytes per instance, but adding automatic "IP address interning" is probably not worth the effort. In the longer term, a C implementation of ipaddress might be worth it, not for improvements in computational performance, but to get the memory usage down for applications that need to make millions of instances. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 00:08:42 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 23 Dec 2014 23:08:42 +0000 Subject: [issue22952] multiprocessing doc introduction not in affirmative tone In-Reply-To: <1417037709.37.0.435561396576.issue22952@psf.upfronthosting.co.za> Message-ID: <1419376122.15.0.89469142439.issue22952@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Procedural question ... is a fix for this considered an "enhancement"? Improvements to documentation are almost always backported. The contrasts with code changes where enhancements (new features, optimizations, or refactorings) are made only on the latest development branch to reduce the risk of destabilizing code that has already shipped. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 00:16:07 2014 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 23 Dec 2014 23:16:07 +0000 Subject: [issue23103] ipaddress should be Flyweight In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> Message-ID: <1419376567.98.0.261729618376.issue23103@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Josh, you might want to have a look at the lightning talk on this page and the associated slides... http://www.egenix.com/library/presentations/PyCon-UK-2014-When-performance-matters/ After having done the tests, using __slots__ is what I consider the flyweight pattern in Python. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 00:16:53 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 23 Dec 2014 23:16:53 +0000 Subject: [issue23061] Update pep8 to specify explicitly 'module level' imports at top of file In-Reply-To: <1418703864.09.0.281927050653.issue23061@psf.upfronthosting.co.za> Message-ID: <1419376613.71.0.869174523479.issue23061@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > I would argue this is a good time to clean up that code in the standard library. Please leave any clean-ups to the module maintainers. PEP 8 is something you should do to your own code, rather than something you inflict on other people's code. We generally leave "clean-ups" to the module maintainers rather than creating code churn which can make it more difficult to apply actual bug fixes across versions. Also, GvR has long expressed a preference for "holistic refactoring" where we avoid making superficial changes across the library and reserve those changes for occasions where we're thinking more deeply about a specific piece of code. The basis for this viewpoint has been confirmed a number of times when we've received Pep 8 patches that introduced bugs into code that was previously correct. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 00:18:35 2014 From: report at bugs.python.org (Seth Bromberger) Date: Tue, 23 Dec 2014 23:18:35 +0000 Subject: [issue23103] ipaddress should be Flyweight In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> Message-ID: <1419376715.58.0.734090310723.issue23103@psf.upfronthosting.co.za> Seth Bromberger added the comment: As a test, I tried the following (taken mostly from http://codesnipers.com/?q=python-flyweights): class Foo(object): _Foo = weakref.WeakValueDictionary() def __new__(cls, addr): obj = Foo._Foo.get(addr, None) if obj is None: obj = object.__new__(cls) Foo._Foo[addr] = obj obj.addr = addr return obj I created 10 million instances of Foo(34) in an array. Total space taken: ~80 MB. Times: CPU times: user 6.93 s, sys: 48.7 ms, total: 6.98 s Wall time: 6.98 s I then created 10 million instances of a non-flyweight object, assigning an int to an instance variable: class Bar(object): pass Total space taken: ~1.4 GB. Times: CPU times: user 7.64 s, sys: 794 ms, total: 8.44 s Wall time: 8.44 s This corresponds (roughly) to the space taken by 10 million IPAddr objects. So it appears, informally, that caching / flyweight results in modest time and significant memory savings. I understand that the ship has sailed for a stdlib implementation, but these results are compelling enough for me to create a separate package. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 00:27:11 2014 From: report at bugs.python.org (Seth Bromberger) Date: Tue, 23 Dec 2014 23:27:11 +0000 Subject: [issue23103] ipaddress should be Flyweight In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> Message-ID: <1419377231.95.0.330190455135.issue23103@psf.upfronthosting.co.za> Seth Bromberger added the comment: Sorry for the additional followup, but I re-ran the test with approximately real-world parameters. In this second test, I created 10 million Foo() instances with random values from 1-2000 (using random.randint). This corresponds to "2000 hosts generating 10 million logs". Memory use is ~80 MB. Times: CPU times: user 27.5 s, sys: 101 ms, total: 27.6 s Wall time: 27.6 s For the nonoptimized run (10m instances of 2000 random values): Memory use is ~1.8GB. Times: CPU times: user 28.2 s, sys: 1.29 s, total: 29.5 s Wall time: 29.5 s ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 00:40:45 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 23 Dec 2014 23:40:45 +0000 Subject: [issue23106] Remove smalltable from set objects Message-ID: <1419378045.35.0.931278321867.issue23106@psf.upfronthosting.co.za> New submission from Raymond Hettinger: This tracker item is here to record my efforts to re-evaluate whether we were getting much if any benefit from the smalltable in set objects. Removing the smalltable special case and instead using a memory allocation had the following effects: * Nice simplification of the code, greatly improving the clarity of the functions for resizing, clearing, and swapping. * Reduced the memory consumption for sets that were already using memory allocated tables (saved the memory cost of the unused smalltable). * Nearly doubled the time to allocate and free set objects (see timings below for CLang and GCC). As a percentage change, the time penalty seems like a killer, but then we're talking about only 1/10th of a ?sec per set. # CLANG ######### ~/base_cp/python.exe -m timeit -s 'from itertools import repeat, starmap' 'list(starmap(set, repeat((), 250000)))' 10 loops, best of 3: 39.1 msec per loop ~/cpython/python.exe -m timeit -s 'from itertools import repeat, starmap' 'list(starmap(set, repeat((), 250000)))' 10 loops, best of 3: 76.7 msec per loop ~/base_cp/python.exe -m timeit -s 'from itertools import repeat, starmap' 'list(starmap(set, repeat((), 250000)))' 10 loops, best of 3: 38.8 msec per loop ~/cpython/python.exe -m timeit -s 'from itertools import repeat, starmap' 'list(starmap(set, repeat((), 250000)))' 10 loops, best of 3: 76.6 msec per loop ~/base_cp/python.exe -m timeit '{1,2,3}' 10000000 loops, best of 3: 0.0964 usec per loop ~/cpython/python.exe -m timeit '{1,2,3}' 10000000 loops, best of 3: 0.148 usec per loop ~/base_cp/python.exe -m timeit '{1,2,3}' 10000000 loops, best of 3: 0.0964 usec per loop ~/cpython/python.exe -m timeit '{1,2,3}' 10000000 loops, best of 3: 0.149 usec per loop # GCC-4.9 ######## ~/base_cp $ ~/base_cp/python.exe -m timeit '{1,2,3}' 10000000 loops, best of 3: 0.0701 usec per loop ~/base_cp $ ~/cpython/python.exe -m timeit '{1,2,3}' 10000000 loops, best of 3: 0.155 usec per loop ~/base_cp $ ~/base_cp/python.exe -m timeit '{1,2,3}' 10000000 loops, best of 3: 0.0691 usec per loop ~/base_cp $ ~/cpython/python.exe -m timeit '{1,2,3}' 10000000 loops, best of 3: 0.157 usec per loop ~/base_cp $ ~/base_cp/python.exe -m timeit -s 'from itertools import repeat, starmap' 'list(starmap(set, repeat((), 250000)))' 10 loops, best of 3: 34.6 msec per loop ~/base_cp $ ~/cpython/python.exe -m timeit -s 'from itertools import repeat, starmap' 'list(starmap(set, repeat((), 250000)))' 10 loops, best of 3: 77 msec per loop ~/base_cp $ ~/base_cp/python.exe -m timeit -s 'from itertools import repeat, starmap' 'list(starmap(set, repeat((), 250000)))' 10 loops, best of 3: 34.1 msec per loop ~/base_cp $ ~/cpython/python.exe -m timeit -s 'from itertools import repeat, starmap' 'list(starmap(set, repeat((), 250000)))' 10 loops, best of 3: 77.3 msec per loop ---------- assignee: rhettinger components: Interpreter Core files: no_smalltable2.diff keywords: patch messages: 233068 nosy: rhettinger priority: low severity: normal status: open title: Remove smalltable from set objects type: performance versions: Python 3.5 Added file: http://bugs.python.org/file37535/no_smalltable2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 01:05:02 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 24 Dec 2014 00:05:02 +0000 Subject: [issue23103] ipaddress should be Flyweight In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> Message-ID: <1419379502.74.0.139489460844.issue23103@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Marc-Andre: Oh, I know. I proselytize to coworkers on the virtues of using __slots__ for classes that will have many instances created (particularly since entirely too much of our stuff is still Py2.7, so we don't have the "free" savings from shared key dictionaries). Heck, I particularly enjoy inheriting from an inlined collections.namedtuple and an empty __slots__(which does add 8 bytes to the size over declaring the __slots__ directly, but gets you as close to truly immutable instances as you can get when you need them, not just "we're all adults here" immutable instances). I'm just pointing out that if he thinks 56 bytes per object is too large, he's going to be disappointed with what Python has to offer. General purpose user-defined Python objects don't optimize for low memory usage, and even __slots__ only gets you so far. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 02:59:31 2014 From: report at bugs.python.org (Seth Bromberger) Date: Wed, 24 Dec 2014 01:59:31 +0000 Subject: [issue23103] ipaddress should be Flyweight In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> Message-ID: <1419386371.27.0.829484283751.issue23103@psf.upfronthosting.co.za> Seth Bromberger added the comment: >I'm just pointing out that if he thinks 56 bytes per object is too large, he's going to be disappointed with what Python has to offer. General purpose user-defined Python objects don't optimize for low memory usage, and even __slots__ only gets you so far. "He" thinks that 1300% overhead is a bit too much for a simple object that can be represented by a 32-bit number, and "he" has been using python for several years and understands, generally, what the language has to offer (though not nearly so well as some of the respondents here). It may be in the roundoff at n < 1e5, but when you start using these objects for real-world analysis, the overhead becomes problematic. I note with some amusement that the overhead is several orders of magnitude greater than those of the protocols these objects represent :) In any case - I have no issues with the decision not to make these objects memory-efficient in stdlib and consequently with closing this out. Rolling my own package appears to be the best solution in any case. Thanks for the discussion. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 03:27:34 2014 From: report at bugs.python.org (John Posner) Date: Wed, 24 Dec 2014 02:27:34 +0000 Subject: [issue21279] str.translate documentation incomplete In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za> Message-ID: <1419388054.76.0.872020577922.issue21279@psf.upfronthosting.co.za> John Posner added the comment: issue21279.v5.patch tries to apply the comments in msg233013, msg233014, and msg233025 to the Doc/library/stdtypes.rst writeup. Then it applies some of the same language to the docstring in Objects/unicodeobject.c. ---------- Added file: http://bugs.python.org/file37536/issue21279.v5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 03:30:22 2014 From: report at bugs.python.org (Gustavo Temple) Date: Wed, 24 Dec 2014 02:30:22 +0000 Subject: [issue23089] Update libffi config files In-Reply-To: <1419005254.2.0.517752739413.issue23089@psf.upfronthosting.co.za> Message-ID: <1419388222.94.0.402827977596.issue23089@psf.upfronthosting.co.za> Changes by Gustavo Temple : ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 03:30:46 2014 From: report at bugs.python.org (Gustavo Temple) Date: Wed, 24 Dec 2014 02:30:46 +0000 Subject: [issue23089] Update libffi config files In-Reply-To: <1419005254.2.0.517752739413.issue23089@psf.upfronthosting.co.za> Message-ID: <1419388246.74.0.110285232594.issue23089@psf.upfronthosting.co.za> Changes by Gustavo Temple : ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 03:32:16 2014 From: report at bugs.python.org (Gustavo Temple) Date: Wed, 24 Dec 2014 02:32:16 +0000 Subject: [issue23089] Update libffi config files In-Reply-To: <1419005254.2.0.517752739413.issue23089@psf.upfronthosting.co.za> Message-ID: <1419388336.86.0.396913055421.issue23089@psf.upfronthosting.co.za> Changes by Gustavo Temple : ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 03:32:44 2014 From: report at bugs.python.org (Gustavo Temple) Date: Wed, 24 Dec 2014 02:32:44 +0000 Subject: [issue23089] Update libffi config files In-Reply-To: <1419005254.2.0.517752739413.issue23089@psf.upfronthosting.co.za> Message-ID: <1419388364.36.0.408204421705.issue23089@psf.upfronthosting.co.za> Changes by Gustavo Temple : ---------- nosy: +tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 03:32:54 2014 From: report at bugs.python.org (Gustavo Temple) Date: Wed, 24 Dec 2014 02:32:54 +0000 Subject: [issue23089] Update libffi config files In-Reply-To: <1419005254.2.0.517752739413.issue23089@psf.upfronthosting.co.za> Message-ID: <1419388374.89.0.542689792937.issue23089@psf.upfronthosting.co.za> Changes by Gustavo Temple : ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 04:14:51 2014 From: report at bugs.python.org (Zachary Ware) Date: Wed, 24 Dec 2014 03:14:51 +0000 Subject: [issue23089] Update libffi config files In-Reply-To: <1419005254.2.0.517752739413.issue23089@psf.upfronthosting.co.za> Message-ID: <1419390891.74.0.30673797046.issue23089@psf.upfronthosting.co.za> Zachary Ware added the comment: Not sure why I was added here, but... I agree with David, we need to see the python-dev discussion to its finish before we make any more changes to any of our private copies of libffi. I hope to get some experimental results from Windows written up and posted soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 06:52:12 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 24 Dec 2014 05:52:12 +0000 Subject: [issue23107] Tighten-up search loops in sets Message-ID: <1419400332.58.0.470390691587.issue23107@psf.upfronthosting.co.za> New submission from Raymond Hettinger: The lookkey functions currently check for an exact key match in the inner search-loop. Move that test to occur after a matching hash is found rather than testing every entry. This gives a modest speed improvement. --- n = 10,000 --- $ ~/baseline/python.exe -m timeit -s 'from time_tight import s,t,u' 's&t' 1000 loops, best of 3: 396 usec per loop $ ~/tight/python.exe -m timeit -s 'from time_tight import s,t,u' 's&t' 1000 loops, best of 3: 367 usec per loop $ ~/tight/python.exe -m timeit -s 'from time_tight import s,t,u' 's&t' 1000 loops, best of 3: 375 usec per loop $ ~/baseline/python.exe -m timeit -s 'from time_tight import s,t,u' 's&t' 1000 loops, best of 3: 389 usec per loop $ $ ~/baseline/python.exe -m timeit -s 'from time_tight import s,t,u' 's&u' 1000 loops, best of 3: 656 usec per loop $ ~/tight/python.exe -m timeit -s 'from time_tight import s,t,u' 's&u' 1000 loops, best of 3: 657 usec per loop $ ~/baseline/python.exe -m timeit -s 'from time_tight import s,t,u' 's&u' 1000 loops, best of 3: 662 usec per loop $ ~/tight/python.exe -m timeit -s 'from time_tight import s,t,u' 's&u' 1000 loops, best of 3: 642 usec per loop -- n = 1,000,000 -- $ ~/baseline/python.exe -m timeit -s 'from time_tight import s,t,u' 's&t' 10 loops, best of 3: 67 msec per loop $ ~/tight/python.exe -m timeit -s 'from time_tight import s,t,u' 's&t' 10 loops, best of 3: 48.2 msec per loop $ ~/baseline/python.exe -m timeit -s 'from time_tight import s,t,u' 's&t' 10 loops, best of 3: 59.9 msec per loop $ ~/tight/python.exe -m timeit -s 'from time_tight import s,t,u' 's&t' 10 loops, best of 3: 49.1 msec per loop $ ~/baseline/python.exe -m timeit -s 'from time_tight import s,t,u' 's&u' 10 loops, best of 3: 173 msec per loop $ ~/tight/python.exe -m timeit -s 'from time_tight import s,t,u' 's&u' 10 loops, best of 3: 152 msec per loop $ ~/baseline/python.exe -m timeit -s 'from time_tight import s,t,u' 's&u' 10 loops, best of 3: 170 msec per loop $ ~/tight/python.exe -m timeit -s 'from time_tight import s,t,u' 's&u' 10 loops, best of 3: 167 msec per loop ---------- assignee: rhettinger components: Interpreter Core files: tight0.diff keywords: patch messages: 233073 nosy: rhettinger priority: normal severity: normal status: open title: Tighten-up search loops in sets type: performance versions: Python 3.5 Added file: http://bugs.python.org/file37537/tight0.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 06:53:04 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 24 Dec 2014 05:53:04 +0000 Subject: [issue23107] Tighten-up search loops in sets In-Reply-To: <1419400332.58.0.470390691587.issue23107@psf.upfronthosting.co.za> Message-ID: <1419400384.85.0.534790450215.issue23107@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file37538/time_tight.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 09:37:22 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 24 Dec 2014 08:37:22 +0000 Subject: [issue23103] ipaddress should be Flyweight In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> Message-ID: <1419410242.98.0.822852247038.issue23103@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which makes IPv4Address and IPv6Address more lightweight (for other classes the size is not so important). It makes _version the class attribute and adds __slots__. ---------- keywords: +patch resolution: wont fix -> stage: -> patch review status: closed -> open versions: +Python 3.5 -Python 3.4 Added file: http://bugs.python.org/file37539/ipaddress_lightweight.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 11:56:54 2014 From: report at bugs.python.org (Lukas Barth) Date: Wed, 24 Dec 2014 10:56:54 +0000 Subject: [issue23108] pysha3 fails with obscure internal error Message-ID: <1419418614.4.0.468641067745.issue23108@psf.upfronthosting.co.za> New submission from Lukas Barth: Hi! Since there is no separate bug tracker for pysha3 (and it is being discussed in some other bug on this tracker), I figured that this is the right place to file this bug. I hope I'm right. I'm trying to import pysha3, and it fails with the error "undefined symbol: _PyUnicode_CheckConsistency" (full backtrace here: http://pastebin.com/ueXDAwu6 ) I can't find anything useful about this error using Google etc. I'm using Python 3.3.5 on a current Gentoo Linux. I'm running in a virtualenv, so there should not be too much getting in the way. I basically have Django and pysha3 installed. Full output of 'pip freeze': http://pastebin.com/Z7DF96Z0 Full output of 'python -v': http://pastebin.com/1HeSJJ8p ---------- components: Extension Modules, Interpreter Core messages: 233075 nosy: tinLoaf priority: normal severity: normal status: open title: pysha3 fails with obscure internal error type: crash versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 12:42:35 2014 From: report at bugs.python.org (=?utf-8?q?Cl=C3=A9ment?=) Date: Wed, 24 Dec 2014 11:42:35 +0000 Subject: [issue23109] French quotes in the documentation are often ungrammatical Message-ID: <1419421355.57.0.399831572163.issue23109@psf.upfronthosting.co.za> New submission from Cl?ment: >From https://docs.python.org/3/howto/unicode.html: > For a while people just wrote programs that didn?t display accents. > In the mid-1980s an Apple II BASIC program written by a French > speaker might have lines like these: > > PRINT "FICHIER EST COMPLETE." > PRINT "CARACTERE NON ACCEPTE." > > Those messages should contain accents (complet?, caract?re, accept?), > and they just look wrong to someone who can read French. One of the reasons the message looks wrong is that "FICHIER EST COMPLETE" in ungrammatical in French. Google has 16 hits for that query, half of which are from the Python documentation. The second one is better. I imagine the first one comes from the English "FILE IS COMPLETE", but I'm not even sure what that meant, so it's hard to give a better translation :/ Instead, here are a few examples that could work: MISE A JOUR TERMINEE (Update completed ? missing ? and ? in termin?e) VEUILLEZ REDEMARRER (Please reboot ? missing ? in red?marrer) PARAMETRES ENREGISTRES (Settings saved ? missing ? in param?tre and ? in enregistr?s) Similarly, https://docs.python.org/3/library/email-examples.html#examples-using-the-provisional-api: > msg['Subject'] = "Ayons asperges pour le d?jeuner" I imagine this comes from the English "Let's have asparagus for lunch!", but the translation reads "Possess asparagus for lunch we". A proper idiomatic French version would be "?a te dirait de manger des asperges ? midi?" (Would you like to eat asparagus for lunch?) Again further on the same page: > Cela ressemble ? un excellent recipie[1] d?jeuner. Could this mean "This looks like a delicious lunch recipie?" The typo in recipie would have prevented the machine translation from picking up recipie, which survived in the French version? This currently reads "This look like recipie lunch a excellent". A proper French version (adjusted to have accents) might be "J'ai trouv? une recette sympa: [1]" ("I found a nice recipe: [1]"). Not sure why using French is needed though; English already has a few accented words: a message with subject "R?sum? attached", and body "Here's my r?sum?" would probably work just as well, and might not divert the reader's attention as much. Side note: in the example P?p? writes to Fabrette and Penelope. Aren't they the same character? Cl?ment. ---------- assignee: docs at python components: Documentation messages: 233076 nosy: cpitcla, docs at python priority: normal severity: normal status: open title: French quotes in the documentation are often ungrammatical 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 Dec 24 12:57:53 2014 From: report at bugs.python.org (irdb) Date: Wed, 24 Dec 2014 11:57:53 +0000 Subject: [issue433030] SRE: Atomic Grouping (?>...) is not supported Message-ID: <1419422273.22.0.88980649685.issue433030@psf.upfronthosting.co.za> Changes by irdb : ---------- nosy: +irdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 15:25:03 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 24 Dec 2014 14:25:03 +0000 Subject: [issue23109] French quotes in the documentation are often ungrammatical In-Reply-To: <1419421355.57.0.399831572163.issue23109@psf.upfronthosting.co.za> Message-ID: <1419431103.55.0.652033101554.issue23109@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +haypo, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 15:31:51 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 24 Dec 2014 14:31:51 +0000 Subject: [issue23108] pysha3 fails with obscure internal error In-Reply-To: <1419418614.4.0.468641067745.issue23108@psf.upfronthosting.co.za> Message-ID: <1419431511.99.0.147248621331.issue23108@psf.upfronthosting.co.za> Benjamin Peterson added the comment: pysha3 has been compiled against a debug build of Python and you are running an non-debug one. ---------- nosy: +benjamin.peterson resolution: -> third party status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 15:40:54 2014 From: report at bugs.python.org (Lukas Barth) Date: Wed, 24 Dec 2014 14:40:54 +0000 Subject: [issue23108] pysha3 fails with obscure internal error In-Reply-To: <1419418614.4.0.468641067745.issue23108@psf.upfronthosting.co.za> Message-ID: <1419432054.44.0.177294202648.issue23108@psf.upfronthosting.co.za> Lukas Barth added the comment: D'Oh. Thanks for the hint. So, is it on purpose that there is some piece of software that's only working on debug builds installable via pip? There was no warning whatsoever when I installed pysha3 via pip.. ---------- resolution: third party -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 16:23:24 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 24 Dec 2014 15:23:24 +0000 Subject: [issue23109] French quotes in the documentation are often ungrammatical In-Reply-To: <1419421355.57.0.399831572163.issue23109@psf.upfronthosting.co.za> Message-ID: <1419434604.72.0.395169066051.issue23109@psf.upfronthosting.co.za> R. David Murray added the comment: Heh, I never claimed I understood French, but none of our French speakers decided to review my fake-french examples :) (I can't speak to the examples from the unicode howto.) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 16:30:48 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 24 Dec 2014 15:30:48 +0000 Subject: [issue23108] pysha3 fails with obscure internal error In-Reply-To: <1419418614.4.0.468641067745.issue23108@psf.upfronthosting.co.za> Message-ID: <1419435048.87.0.698054494961.issue23108@psf.upfronthosting.co.za> R. David Murray added the comment: I doubt that it is on purpose, but it is not a CPython bug. You have one bug in pysha3 (a third party product) and one possible bug (I don't know enough to know if it is one) in pip, which has its own tracker (we track *ensurepip* bugs here, but not pip bugs). ---------- nosy: +r.david.murray resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 17:22:53 2014 From: report at bugs.python.org (Robert Snoeberger) Date: Wed, 24 Dec 2014 16:22:53 +0000 Subject: [issue23110] Document if argument to Py_SetPath requires static storage. Message-ID: <1419438173.5.0.679263724855.issue23110@psf.upfronthosting.co.za> New submission from Robert Snoeberger: The documentation for the Py_SetPath API does not indicate if the argument should point to a wide character array in static storage. However, the documentation for Py_GetPath says, "The returned string points into static storage; the caller should not modify its value." This leads me to believe that static storage is required for Py_SetPath. The documentation for similar API functions, Py_SetPythonHome and Py_SetProgramName, indicates, "The argument should point to a zero-terminated wide character string in static storage whose contents will not change...". ---------- assignee: docs at python components: Documentation messages: 233081 nosy: docs at python, snoeberger priority: normal severity: normal status: open title: Document if argument to Py_SetPath requires static storage. type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 17:51:20 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 24 Dec 2014 16:51:20 +0000 Subject: [issue23110] Document if argument to Py_SetPath requires static storage. In-Reply-To: <1419438173.5.0.679263724855.issue23110@psf.upfronthosting.co.za> Message-ID: <20141224165115.102371.46152@psf.io> Roundup Robot added the comment: New changeset 08972a47f710 by Benjamin Peterson in branch '3.4': doucment that Py_SetPath copies its argument (closes #23110) https://hg.python.org/cpython/rev/08972a47f710 New changeset edf4ea3cfe68 by Benjamin Peterson in branch 'default': merge 3.4 (#23110) https://hg.python.org/cpython/rev/edf4ea3cfe68 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 17:55:53 2014 From: report at bugs.python.org (Chris Rebert) Date: Wed, 24 Dec 2014 16:55:53 +0000 Subject: [issue19776] Provide expanduser() on Path objects In-Reply-To: <1385409778.55.0.842571848249.issue19776@psf.upfronthosting.co.za> Message-ID: <1419440153.16.0.196529198922.issue19776@psf.upfronthosting.co.za> Changes by Chris Rebert : ---------- nosy: +cvrebert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 18:22:28 2014 From: report at bugs.python.org (Eric Snow) Date: Wed, 24 Dec 2014 17:22:28 +0000 Subject: [issue23103] ipaddress should be Flyweight In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> Message-ID: <1419441748.1.0.0798850527575.issue23103@psf.upfronthosting.co.za> Eric Snow added the comment: @sbromberger, there's no need for your own package. Just use something like this: _addr_cache = {} def ipaddr(addr): try: return _addr_cache[addr] except KeyError: _addr_cache[addr] = ipaddress.ipaddress(addr) return _addr_cache[addr] You could even throw weakrefs in there if your use case demanded it. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 18:55:59 2014 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 24 Dec 2014 17:55:59 +0000 Subject: [issue23103] ipaddress should be Flyweight In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> Message-ID: <1419443759.64.0.179471876753.issue23103@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Serhiy: I believe you need to add a bunch of __slots__ = () to various base classes in the module, even though they lack member variables. Every link in the inheritance chain must declare __slots__, or the child class will have __dict__ and __weakref__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 19:47:23 2014 From: report at bugs.python.org (sorin) Date: Wed, 24 Dec 2014 18:47:23 +0000 Subject: [issue22269] Resolve distutils option conflicts with priorities In-Reply-To: <1408919544.9.0.398406846461.issue22269@psf.upfronthosting.co.za> Message-ID: <1419446843.21.0.922022429263.issue22269@psf.upfronthosting.co.za> sorin added the comment: Can't we do something about this bug? I think that most python devs are ignoring the severity of this one, especially because it does break distribution of packages (or at least their testing) On OS X the experience is awful as --user doesn't work at all and as a maintainer of many python packages I end-up with a case where installing packages for the current user doesn't work. It works well on all other platforms but not on OS X (when you have the brew python). We cannot really expect all the package developers to spend a lot of time creating new scenarios only for trying to bypass this bug. For the sake of our Python users let's fix this and make the Python experience a good one, especially for people that do not have much experience with python. Maybe Santa will get my message ;) Wish you happy holidays! ---------- nosy: +sorin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 20:15:59 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Wed, 24 Dec 2014 19:15:59 +0000 Subject: [issue22231] httplib: unicode url will cause an ascii codec error when combined with a utf-8 string header In-Reply-To: <1408502977.94.0.555848371144.issue22231@psf.upfronthosting.co.za> Message-ID: <1419448559.21.0.972307204281.issue22231@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 20:59:10 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 24 Dec 2014 19:59:10 +0000 Subject: [issue23109] French quotes in the documentation are often ungrammatical In-Reply-To: <1419421355.57.0.399831572163.issue23109@psf.upfronthosting.co.za> Message-ID: <20141224195858.22196.14726@psf.io> Roundup Robot added the comment: New changeset 55462210ba2d by Benjamin Peterson in branch '2.7': improve incorrect French (#23109) https://hg.python.org/cpython/rev/55462210ba2d New changeset 2c87dd2d821e by Benjamin Peterson in branch '3.4': improve incorrect French (#23109) https://hg.python.org/cpython/rev/2c87dd2d821e New changeset c5603b77df68 by Benjamin Peterson in branch 'default': merge 3.4 (#23109) https://hg.python.org/cpython/rev/c5603b77df68 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 22:45:07 2014 From: report at bugs.python.org (varde) Date: Wed, 24 Dec 2014 21:45:07 +0000 Subject: [issue23111] ftplib.FTP_TLS's default constructor does not work with TLSv1.1 or TLSv1.2 Message-ID: <1419457507.62.0.0499182915126.issue23111@psf.upfronthosting.co.za> New submission from varde: When trying to connect to a server which only supports TLS version 1.1 or 1.2, the following error is raised: ssl.SSLError: [SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:598) For some reason, the SSL version is set to ssl.PROTOCOL_TLSv1 before initialisation and an SSL context is created in __init__, making any subsequent change to ssl_version useless. The only way to establish a successful connection is to pass a custom SSL context to the constructor. I think ssl_version should be settable at construction time before the context is created. I'm not sure exposing ssl_version is useful either, the documentation mentions it but it has no use after initialisation. The following lines should also be changed: if self.ssl_version == ssl.PROTOCOL_TLSv1: resp = self.voidcmd('AUTH TLS') ---------- components: Library (Lib) messages: 233087 nosy: varde priority: normal severity: normal status: open title: ftplib.FTP_TLS's default constructor does not work with TLSv1.1 or TLSv1.2 type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 24 23:08:07 2014 From: report at bugs.python.org (Roundup Robot) Date: Wed, 24 Dec 2014 22:08:07 +0000 Subject: [issue23109] French quotes in the documentation are often ungrammatical In-Reply-To: <1419421355.57.0.399831572163.issue23109@psf.upfronthosting.co.za> Message-ID: <20141224220805.120051.9175@psf.io> Roundup Robot added the comment: New changeset 181dfe9288d4 by Benjamin Peterson in branch '3.4': update correct French examples (#23109) https://hg.python.org/cpython/rev/181dfe9288d4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 25 03:24:23 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 25 Dec 2014 02:24:23 +0000 Subject: [issue23040] Better documentation for the urlencode safe parameter In-Reply-To: <1418398499.72.0.468214874616.issue23040@psf.upfronthosting.co.za> Message-ID: <20141225022419.22214.57880@psf.io> Roundup Robot added the comment: New changeset 126aff7c6a33 by R David Murray in branch '3.4': #23040: Clarify treatment of encoding and errors when component is bytes. https://hg.python.org/cpython/rev/126aff7c6a33 New changeset 367ba031a743 by R David Murray in branch 'default': Merge: #23040: Clarify treatment of encoding and errors when component is bytes. https://hg.python.org/cpython/rev/367ba031a743 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 25 03:25:08 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 25 Dec 2014 02:25:08 +0000 Subject: [issue23040] Better documentation for the urlencode safe parameter In-Reply-To: <1418398499.72.0.468214874616.issue23040@psf.upfronthosting.co.za> Message-ID: <1419474308.82.0.329309174722.issue23040@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Wojtek. ---------- resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 25 03:27:49 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 25 Dec 2014 02:27:49 +0000 Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone constant In-Reply-To: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za> Message-ID: <1419474469.07.0.148428867953.issue22932@psf.upfronthosting.co.za> R. David Murray added the comment: Is there any way to write a test for this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 25 03:40:32 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 25 Dec 2014 02:40:32 +0000 Subject: [issue1703178] link_objects in setup.cfg crashes build Message-ID: <1419475232.44.0.144492615452.issue1703178@psf.upfronthosting.co.za> R. David Murray added the comment: This issue is marked for 2.7, 3.4, and 3.5, but the test runs only on 3.5. ---------- assignee: -> eric.araujo nosy: +r.david.murray stage: commit review -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 25 06:41:37 2014 From: report at bugs.python.org (Akira Li) Date: Thu, 25 Dec 2014 05:41:37 +0000 Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone constant In-Reply-To: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za> Message-ID: <1419486097.67.0.0425782466957.issue22932@psf.upfronthosting.co.za> Changes by Akira Li <4kir4.1i at gmail.com>: ---------- nosy: +akira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 25 07:02:41 2014 From: report at bugs.python.org (Akira Li) Date: Thu, 25 Dec 2014 06:02:41 +0000 Subject: [issue22673] document the special features (eg: fdclose=False) of the standard streams In-Reply-To: <1413745258.02.0.518044907787.issue22673@psf.upfronthosting.co.za> Message-ID: <1419487361.68.0.683851761394.issue22673@psf.upfronthosting.co.za> Akira Li added the comment: Two minor details: 1. It is possible that `fileno(stdout) != 1` even in C [1]. I don't know what happens if the code from the answer is run on Windows. In principle, it may break eryksun's workaround. I don't know how likely it is in practice. 2. you can redirect at the file descriptor level in Python [2] using os.dup2(). I don't know whether the code in the answer works on Windows. [1] http://stackoverflow.com/questions/25516375/is-it-possible-that-filenostdout-1-on-a-posix-system [2] http://stackoverflow.com/questions/4675728/redirect-stdout-to-a-file-in-python/22434262#22434262 ---------- nosy: +akira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 25 10:17:44 2014 From: report at bugs.python.org (Vajrasky Kok) Date: Thu, 25 Dec 2014 09:17:44 +0000 Subject: [issue20069] Add unit test for os.chown In-Reply-To: <1388053703.09.0.645818054692.issue20069@psf.upfronthosting.co.za> Message-ID: <1419499064.35.0.432805982811.issue20069@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Here is the latest patch which executes unittest.main inside __main__ based on R. David Murray's review. Thanks! ---------- Added file: http://bugs.python.org/file37540/add_unit_test_os_chown_v7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 25 12:34:44 2014 From: report at bugs.python.org (Josep Portella Florit) Date: Thu, 25 Dec 2014 11:34:44 +0000 Subject: [issue23112] SimpleHTTPServer/http.server adds trailing slash after query string Message-ID: <1419507284.07.0.378357430215.issue23112@psf.upfronthosting.co.za> New submission from Josep Portella Florit: To reproduce: 1) Create directory "foo" in the current directory. 2) Run "python -m SimpleHTTPServer" or "python3 -m http.server". 3A) Point web browser to "http://127.0.0.1:8000/foo/?". The request is redirected to "http://127.0.0.1:8000/foo/?/". The expected behaviour was no redirection. 3B) Point web browser to "http://127.0.0.1:8000/foo?". The request is redirected to "http://127.0.0.1:8000/foo?/". The expected behaviour was a redirection to "http://127.0.0.1:8000/foo/?". Reproduced with 2.7.6 and 3.4.0. ---------- components: Library (Lib) messages: 233095 nosy: jpf priority: normal severity: normal status: open title: SimpleHTTPServer/http.server adds trailing slash after query string type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 25 18:05:06 2014 From: report at bugs.python.org (John Firestone) Date: Thu, 25 Dec 2014 17:05:06 +0000 Subject: [issue23113] Compiler doesn't recognize qualified exec('', {}) Message-ID: <1419527106.51.0.659290194447.issue23113@psf.upfronthosting.co.za> New submission from John Firestone: Python 2.7.8 (v2.7.8:ee879c0ffa11, Jun 29 2014, 21:07:35) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> def outer(): ... def inner(arg): ... len(arg) ... exec('', {}) ... File "", line 4 SyntaxError: unqualified exec is not allowed in function 'outer' it contains a nested function with free variables >>> >>> def outer(): ... def inner(arg): ... len(arg) ... exec '' in {} ... >>> ---------- components: Interpreter Core files: bug.py messages: 233096 nosy: johnf priority: normal severity: normal status: open title: Compiler doesn't recognize qualified exec('', {}) type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file37541/bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 25 18:10:46 2014 From: report at bugs.python.org (John Firestone) Date: Thu, 25 Dec 2014 17:10:46 +0000 Subject: [issue23113] Compiler doesn't recognize qualified exec('', {}) In-Reply-To: <1419527106.51.0.659290194447.issue23113@psf.upfronthosting.co.za> Message-ID: <1419527446.25.0.399162379273.issue23113@psf.upfronthosting.co.za> John Firestone added the comment: Sorry. Duplicates 21591 ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Dec 25 18:17:05 2014 From: report at bugs.python.org (R. David Murray) Date: Thu, 25 Dec 2014 17:17:05 +0000 Subject: [issue23113] Compiler doesn't recognize qualified exec('', {}) In-Reply-To: <1419527106.51.0.659290194447.issue23113@psf.upfronthosting.co.za> Message-ID: <1419527825.75.0.467314638889.issue23113@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> duplicate stage: -> resolved superseder: -> "exec(a, b, c)" not the same as "exec a in b, c" in nested functions _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 00:03:27 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 25 Dec 2014 23:03:27 +0000 Subject: [issue23107] Tighten-up search loops in sets In-Reply-To: <1419400332.58.0.470390691587.issue23107@psf.upfronthosting.co.za> Message-ID: <1419548607.48.0.29292644004.issue23107@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +pitrou, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 00:20:00 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 25 Dec 2014 23:20:00 +0000 Subject: [issue22926] asyncio: raise an exception when called from the wrong thread In-Reply-To: <1416760694.74.0.749180510867.issue22926@psf.upfronthosting.co.za> Message-ID: <1419549600.97.0.0201710162381.issue22926@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm going to commit check_thread-3.patch if nobody complains: in debug mode, call_soon(), call_at() and call_later() now check threading.get_ident() to ensure that they are called from the thread running the event loop. ---------- Added file: http://bugs.python.org/file37542/check_thread-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 00:26:29 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 25 Dec 2014 23:26:29 +0000 Subject: [issue23104] [Windows x86-64] Incorrect function call In-Reply-To: <1419334423.22.0.551057120801.issue23104@psf.upfronthosting.co.za> Message-ID: <1419549989.86.0.0731491642444.issue23104@psf.upfronthosting.co.za> STINNER Victor added the comment: > testfun(objid(), c_wchar_p('test')) I'm not sure that the objid object lives until testfun() is called. It would be safer to write: o = objid() testfun(o, c_wchar_p('test'))) o = None ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 00:26:36 2014 From: report at bugs.python.org (STINNER Victor) Date: Thu, 25 Dec 2014 23:26:36 +0000 Subject: [issue23104] [Windows x86-64] ctypes: Incorrect function call In-Reply-To: <1419334423.22.0.551057120801.issue23104@psf.upfronthosting.co.za> Message-ID: <1419549996.43.0.451098818091.issue23104@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: [Windows x86-64] Incorrect function call -> [Windows x86-64] ctypes: Incorrect function call _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 00:38:11 2014 From: report at bugs.python.org (Roundup Robot) Date: Thu, 25 Dec 2014 23:38:11 +0000 Subject: [issue20069] Add unit test for os.chown In-Reply-To: <1388053703.09.0.645818054692.issue20069@psf.upfronthosting.co.za> Message-ID: <20141225233759.125173.89561@psf.io> Roundup Robot added the comment: New changeset 32c5b9aeee82 by R David Murray in branch 'default': #20069: Add tests for os.chown. https://hg.python.org/cpython/rev/32c5b9aeee82 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 01:24:23 2014 From: report at bugs.python.org (R. David Murray) Date: Fri, 26 Dec 2014 00:24:23 +0000 Subject: [issue20069] Add unit test for os.chown In-Reply-To: <1388053703.09.0.645818054692.issue20069@psf.upfronthosting.co.za> Message-ID: <1419553463.36.0.754220133502.issue20069@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Vajrasky. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 01:31:41 2014 From: report at bugs.python.org (Jan Kaliszewski) Date: Fri, 26 Dec 2014 00:31:41 +0000 Subject: [issue19539] The 'raw_unicode_escape' codec buggy + not appropriate for Python 3.x In-Reply-To: <1384051905.56.0.969775270474.issue19539@psf.upfronthosting.co.za> Message-ID: <1419553901.94.0.468922386574.issue19539@psf.upfronthosting.co.za> Changes by Jan Kaliszewski : ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 01:33:00 2014 From: report at bugs.python.org (Jan Kaliszewski) Date: Fri, 26 Dec 2014 00:33:00 +0000 Subject: [issue19539] The 'raw_unicode_escape' codec buggy + not appropriate for Python 3.x In-Reply-To: <1384051905.56.0.969775270474.issue19539@psf.upfronthosting.co.za> Message-ID: <1419553980.48.0.482873934702.issue19539@psf.upfronthosting.co.za> Jan Kaliszewski added the comment: My concerns are now being addressed in the issue19548. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 03:08:28 2014 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 26 Dec 2014 02:08:28 +0000 Subject: [issue22926] asyncio: raise an exception when called from the wrong thread In-Reply-To: <1416760694.74.0.749180510867.issue22926@psf.upfronthosting.co.za> Message-ID: <1419559708.04.0.581194814347.issue22926@psf.upfronthosting.co.za> Guido van Rossum added the comment: SGTM. Merry Xmas! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 11:30:55 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 26 Dec 2014 10:30:55 +0000 Subject: [issue23114] "dist must be a Distribution instance" check fails with setuptools Message-ID: <1419589855.59.0.704259891528.issue23114@psf.upfronthosting.co.za> New submission from Stefan Behnel: distutils uses this code to validate the input in "Command.__init__()": # late import because of mutual dependence between these classes from distutils.dist import Distribution if not isinstance(dist, Distribution): raise TypeError, "dist must be a Distribution instance" (Lib/distutils/cmd.py, after line 50) This fails if the calling code uses the stdlib Distribution type (e.g. with a module global import) but setuptools was only imported afterwards and replaced "distutils.dist.Distribution" with its own implementation. In this case, the above code will get hold of the setuptools implementation and the isinstance() check will fail as both classes are not compatible. I guess this is a problem more in setuptools than in distutils, but a) this isinstance() check has a general code smell and b) pip and setuptools are automatically installed in a specific (impacted) version in Py2.7.9 and Py3.4, which makes this problem quite pressing for the stdlib side. ---------- components: Distutils messages: 233104 nosy: dstufft, eric.araujo, scoder priority: normal severity: normal status: open title: "dist must be a Distribution instance" check fails with setuptools type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 14:21:27 2014 From: report at bugs.python.org (Kevin J Pallan) Date: Fri, 26 Dec 2014 13:21:27 +0000 Subject: [issue23112] SimpleHTTPServer/http.server adds trailing slash after query string In-Reply-To: <1419507284.07.0.378357430215.issue23112@psf.upfronthosting.co.za> Message-ID: <1419600087.11.0.681696695089.issue23112@psf.upfronthosting.co.za> Changes by Kevin J Pallan : ---------- nosy: +artifex93 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 17:21:13 2014 From: report at bugs.python.org (Alex Gaynor) Date: Fri, 26 Dec 2014 16:21:13 +0000 Subject: [issue23115] Backport #22585 -- getentropy for urandom to Python 2.7 Message-ID: <1419610873.69.0.17447907262.issue23115@psf.upfronthosting.co.za> New submission from Alex Gaynor: This makes the urandom codebase easier to maintain by allowing porting patches between 2.7 and 3.x easier; it also improves support for the OpenBSD platform. Support for porting patches is not just a theoretical concern, it's likely that Linux's getrandom() will be supported at some point; like getentropy() it's useful because it's less error prone, and works in chroots and other environments that don't explicitly set up the /dev/urandom device. ---------- components: Library (Lib) keywords: needs review, patch messages: 233105 nosy: alex, benjamin.peterson, dstufft priority: normal severity: normal status: open title: Backport #22585 -- getentropy for urandom to Python 2.7 versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 17:21:39 2014 From: report at bugs.python.org (Alex Gaynor) Date: Fri, 26 Dec 2014 16:21:39 +0000 Subject: [issue23115] Backport #22585 -- getentropy for urandom to Python 2.7 In-Reply-To: <1419610873.69.0.17447907262.issue23115@psf.upfronthosting.co.za> Message-ID: <1419610899.71.0.512113961642.issue23115@psf.upfronthosting.co.za> Changes by Alex Gaynor : Added file: http://bugs.python.org/file37543/issue23115.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 17:57:12 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 26 Dec 2014 16:57:12 +0000 Subject: [issue23112] SimpleHTTPServer/http.server adds trailing slash after query string In-Reply-To: <1419507284.07.0.378357430215.issue23112@psf.upfronthosting.co.za> Message-ID: <20141226165708.120073.94305@psf.io> Roundup Robot added the comment: New changeset b058a904c630 by Benjamin Peterson in branch '2.7': fix behavior of trailing slash redirection when a query string is involved (closes #23112) https://hg.python.org/cpython/rev/b058a904c630 New changeset 3d19f419cc44 by Benjamin Peterson in branch '3.4': fix behavior of trailing slash redirection when a query string is involved (closes #23112) https://hg.python.org/cpython/rev/3d19f419cc44 New changeset e7c7e1fce3e2 by Benjamin Peterson in branch 'default': merge 3.4 (#23112) https://hg.python.org/cpython/rev/e7c7e1fce3e2 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 18:09:12 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 26 Dec 2014 17:09:12 +0000 Subject: [issue22585] os.urandom() should use getentropy() of OpenBSD 5.6 In-Reply-To: <1412846768.8.0.764206346975.issue22585@psf.upfronthosting.co.za> Message-ID: <20141226170909.22198.41035@psf.io> Roundup Robot added the comment: New changeset f11f84902713 by Victor Stinner in branch '3.4': Issue #22585: On OpenBSD 5.6 and newer, os.urandom() now calls getentropy(), https://hg.python.org/cpython/rev/f11f84902713 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 18:09:12 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 26 Dec 2014 17:09:12 +0000 Subject: [issue23115] Backport #22585 -- getentropy for urandom to Python 2.7 In-Reply-To: <1419610873.69.0.17447907262.issue23115@psf.upfronthosting.co.za> Message-ID: <20141226170909.22198.68600@psf.io> Roundup Robot added the comment: New changeset 9cd2641765dc by Benjamin Peterson in branch '2.7': use getentropy when available (backport of 75ede5bec8db) (closes #23115) https://hg.python.org/cpython/rev/9cd2641765dc ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 18:16:37 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 26 Dec 2014 17:16:37 +0000 Subject: [issue23102] distutils: tip-toe around quirks owing to setuptools monkey-patching Extension In-Reply-To: <1419316588.75.0.487755278973.issue23102@psf.upfronthosting.co.za> Message-ID: <1419614197.93.0.474392695015.issue23102@psf.upfronthosting.co.za> ?ric Araujo added the comment: IMO this would be best fixed in setuptools, but it may not be possible. ---------- versions: -Python 3.2, Python 3.3, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 18:17:29 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 26 Dec 2014 17:17:29 +0000 Subject: [issue23114] "dist must be a Distribution instance" check fails with setuptools In-Reply-To: <1419589855.59.0.704259891528.issue23114@psf.upfronthosting.co.za> Message-ID: <1419614249.45.0.204322100762.issue23114@psf.upfronthosting.co.za> ?ric Araujo added the comment: Can this ticket be merged into #23102 ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 18:20:42 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 26 Dec 2014 17:20:42 +0000 Subject: [issue23109] French quotes in the documentation are often ungrammatical In-Reply-To: <1419421355.57.0.399831572163.issue23109@psf.upfronthosting.co.za> Message-ID: <1419614442.32.0.507065968167.issue23109@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Heh, I never claimed I understood French, but none of our French speakers decided to review my fake-french examples :) I just thought they looked funny :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 18:43:57 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 26 Dec 2014 17:43:57 +0000 Subject: [issue23107] Tighten-up search loops in sets In-Reply-To: <1419400332.58.0.470390691587.issue23107@psf.upfronthosting.co.za> Message-ID: <1419615837.41.0.679983214924.issue23107@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file37544/tight_insert.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 19:53:40 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 26 Dec 2014 18:53:40 +0000 Subject: [issue23114] "dist must be a Distribution instance" check fails with setuptools In-Reply-To: <1419589855.59.0.704259891528.issue23114@psf.upfronthosting.co.za> Message-ID: <1419620020.74.0.566625996071.issue23114@psf.upfronthosting.co.za> Stefan Behnel added the comment: Yes, pretty much the same problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 19:54:56 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 26 Dec 2014 18:54:56 +0000 Subject: [issue23114] "dist must be a Distribution instance" check fails with setuptools In-Reply-To: <1419589855.59.0.704259891528.issue23114@psf.upfronthosting.co.za> Message-ID: <1419620096.87.0.146820623133.issue23114@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> distutils: tip-toe around quirks owing to setuptools monkey-patching Extension _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 19:55:44 2014 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 26 Dec 2014 18:55:44 +0000 Subject: [issue23102] distutils: tip-toe around quirks owing to setuptools monkey-patching Extension In-Reply-To: <1419316588.75.0.487755278973.issue23102@psf.upfronthosting.co.za> Message-ID: <1419620144.09.0.733904247912.issue23102@psf.upfronthosting.co.za> Stefan Behnel added the comment: The same applies to the error "dist must be a Distribution instance" in cmd.py. See issue 23114. ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 19:56:49 2014 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 26 Dec 2014 18:56:49 +0000 Subject: [issue23102] distutils: isinstance checks fail with setuptools-monkeypatched Extension/Distribution In-Reply-To: <1419316588.75.0.487755278973.issue23102@psf.upfronthosting.co.za> Message-ID: <1419620209.11.0.422772756776.issue23102@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- title: distutils: tip-toe around quirks owing to setuptools monkey-patching Extension -> distutils: isinstance checks fail with setuptools-monkeypatched Extension/Distribution _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 20:42:14 2014 From: report at bugs.python.org (Amy) Date: Fri, 26 Dec 2014 19:42:14 +0000 Subject: [issue23116] Python Tutorial 4.7.1: Improve ask_ok() to cover more input values Message-ID: <1419622934.77.0.489991713093.issue23116@psf.upfronthosting.co.za> New submission from Amy: https://docs.python.org/3/tutorial/controlflow.html#default-argument-values def ask_ok(prompt, retries=4, complaint='Yes or no, please!'): while True: ok = input(prompt) Suggestion: change to "ok = input(prompt).lower()" in order to cover values with capitalized characters such as "Yes" or "NO". ---------- messages: 233114 nosy: amyluo priority: normal severity: normal status: open title: Python Tutorial 4.7.1: Improve ask_ok() to cover more input values type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 20:56:34 2014 From: report at bugs.python.org (Mike Gilbert) Date: Fri, 26 Dec 2014 19:56:34 +0000 Subject: [issue22758] Regression in Python 3.2 cookie parsing In-Reply-To: <1414577677.93.0.364604019199.issue22758@psf.upfronthosting.co.za> Message-ID: <1419623794.42.0.483622782653.issue22758@psf.upfronthosting.co.za> Changes by Mike Gilbert : ---------- nosy: +floppymaster _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 20:59:29 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 26 Dec 2014 19:59:29 +0000 Subject: [issue23107] Tighten-up search loops in sets In-Reply-To: <1419400332.58.0.470390691587.issue23107@psf.upfronthosting.co.za> Message-ID: <1419623969.16.0.0320801022058.issue23107@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The patches are orthogonal, right? Both patches look ok to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 21:46:40 2014 From: report at bugs.python.org (Roundup Robot) Date: Fri, 26 Dec 2014 20:46:40 +0000 Subject: [issue22926] asyncio: raise an exception when called from the wrong thread In-Reply-To: <1416760694.74.0.749180510867.issue22926@psf.upfronthosting.co.za> Message-ID: <20141226204637.22186.83338@psf.io> Roundup Robot added the comment: New changeset 4e8ac4173b3c by Victor Stinner in branch '3.4': Issue #22926: In debug mode, call_soon(), call_at() and call_later() methods of https://hg.python.org/cpython/rev/4e8ac4173b3c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 21:47:31 2014 From: report at bugs.python.org (STINNER Victor) Date: Fri, 26 Dec 2014 20:47:31 +0000 Subject: [issue22926] asyncio: raise an exception when called from the wrong thread In-Reply-To: <1416760694.74.0.749180510867.issue22926@psf.upfronthosting.co.za> Message-ID: <1419626851.77.0.112475453059.issue22926@psf.upfronthosting.co.za> STINNER Victor added the comment: Thanks for the review. I commited my change in Tulip, Python 3.4 & 3.5. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 22:38:40 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 26 Dec 2014 21:38:40 +0000 Subject: [issue23111] ftplib.FTP_TLS's default constructor does not work with TLSv1.1 or TLSv1.2 In-Reply-To: <1419457507.62.0.0499182915126.issue23111@psf.upfronthosting.co.za> Message-ID: <1419629920.94.0.985053129916.issue23111@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > The only way to establish a successful connection is to pass a custom SSL context to the constructor. Why don't you do just that? ---------- nosy: +giampaolo.rodola, pitrou versions: +Python 3.5 -Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 22:49:38 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 26 Dec 2014 21:49:38 +0000 Subject: [issue23103] ipaddress should be Flyweight In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> Message-ID: <1419630578.32.0.298459836478.issue23103@psf.upfronthosting.co.za> Antoine Pitrou added the comment: So, there are several aspects to this request: - add a __slots__: this is Serhiy's patch - add some weak interning of IP addresses: I believe it is ok to add it as an optimization, provided it doesn't otherwise change the API or the classes' behaviour Seth: feel free to write a draft patch of interning, in order to get actual performance/memory consumption numbers. Also, perhaps open a specific issue for it, so we don't have many patches on the same issue? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Dec 26 23:17:53 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 26 Dec 2014 22:17:53 +0000 Subject: [issue23107] Tighten-up search loops in sets In-Reply-To: <1419400332.58.0.470390691587.issue23107@psf.upfronthosting.co.za> Message-ID: <1419632273.81.0.615254596707.issue23107@psf.upfronthosting.co.za> Raymond Hettinger added the comment: One more small orthogonal patch: in the presence of dummy entries, it is a bit cheaper to count filled entries than used entries. ---------- Added file: http://bugs.python.org/file37545/set_fill_to_used.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 00:03:04 2014 From: report at bugs.python.org (James Wahlman) Date: Fri, 26 Dec 2014 23:03:04 +0000 Subject: [issue23117] Properly codesign Mac python 2.7.9.pkg so it can work thru OS X firewall Message-ID: <1419634984.21.0.96201874002.issue23117@psf.upfronthosting.co.za> New submission from James Wahlman: The app is not code signed properly so when using Python 2.7.9 on OS X 10.10 or any version or OS X I imagine when a user enables the built in OS X firewall and runs Python it complains about allowing the app thru the firewall. The only way to fix since it wasn't signed properly was to install command line tools then typing this in terminal: sudo codesign -f -s - /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app please sign this app properly so it works without this annoying workaround. Thanks ;) ---------- messages: 233121 nosy: James.Wahlman priority: normal severity: normal status: open title: Properly codesign Mac python 2.7.9.pkg so it can work thru OS X firewall _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 00:04:09 2014 From: report at bugs.python.org (James Wahlman) Date: Fri, 26 Dec 2014 23:04:09 +0000 Subject: [issue23118] Properly codesign Mac python 2.7.9.pkg so it can work thru OS X firewall Message-ID: <1419635049.3.0.430313609014.issue23118@psf.upfronthosting.co.za> New submission from James Wahlman: The app is not code signed properly so when using Python 2.7.9 on OS X 10.10 or any version of OS X I imagine when a user enables the built in OS X firewall and runs Python it complains about allowing the app thru the firewall. The only way to fix since it wasn't signed properly was to install command line tools then typing this in terminal: sudo codesign -f -s - /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app please sign this app properly so it works without this annoying workaround. Thanks ;) ---------- messages: 233122 nosy: James.Wahlman priority: normal severity: normal status: open title: Properly codesign Mac python 2.7.9.pkg so it can work thru OS X firewall _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 00:05:04 2014 From: report at bugs.python.org (SilentGhost) Date: Fri, 26 Dec 2014 23:05:04 +0000 Subject: [issue23118] Properly codesign Mac python 2.7.9.pkg so it can work thru OS X firewall In-Reply-To: <1419635049.3.0.430313609014.issue23118@psf.upfronthosting.co.za> Message-ID: <1419635104.53.0.630903928468.issue23118@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 00:05:26 2014 From: report at bugs.python.org (SilentGhost) Date: Fri, 26 Dec 2014 23:05:26 +0000 Subject: [issue23117] Properly codesign Mac python 2.7.9.pkg so it can work thru OS X firewall In-Reply-To: <1419634984.21.0.96201874002.issue23117@psf.upfronthosting.co.za> Message-ID: <1419635126.19.0.00870854265165.issue23117@psf.upfronthosting.co.za> SilentGhost added the comment: Closed issue23118 as identical issue to this one. ---------- nosy: +SilentGhost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 00:07:07 2014 From: report at bugs.python.org (SilentGhost) Date: Fri, 26 Dec 2014 23:07:07 +0000 Subject: [issue23117] Properly codesign Mac python 2.7.9.pkg so it can work thru OS X firewall In-Reply-To: <1419634984.21.0.96201874002.issue23117@psf.upfronthosting.co.za> Message-ID: <1419635227.29.0.755487723688.issue23117@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Macintosh nosy: +ned.deily, ronaldoussoren versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 00:38:11 2014 From: report at bugs.python.org (Ned Deily) Date: Fri, 26 Dec 2014 23:38:11 +0000 Subject: [issue23117] Properly codesign Mac python 2.7.9.pkg so it can work thru OS X firewall In-Reply-To: <1419634984.21.0.96201874002.issue23117@psf.upfronthosting.co.za> Message-ID: <1419637091.8.0.773029298974.issue23117@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- assignee: -> ned.deily components: +Build stage: -> needs patch versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 01:04:50 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Dec 2014 00:04:50 +0000 Subject: [issue22269] Resolve distutils option conflicts with priorities In-Reply-To: <1408919544.9.0.398406846461.issue22269@psf.upfronthosting.co.za> Message-ID: <1419638690.65.0.779890463098.issue22269@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I do think this needs fixing. It's just that the patch is non-trivial and someone must take the time to review it. Also, the patch should add a unit test to avoid regressions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 05:14:13 2014 From: report at bugs.python.org (Roundup Robot) Date: Sat, 27 Dec 2014 04:14:13 +0000 Subject: [issue23107] Tighten-up search loops in sets In-Reply-To: <1419400332.58.0.470390691587.issue23107@psf.upfronthosting.co.za> Message-ID: <20141227041409.102379.79925@psf.io> Roundup Robot added the comment: New changeset c15f8debd6c9 by Raymond Hettinger in branch 'default': Issue #23107: Tighten-up loops in setobject.c https://hg.python.org/cpython/rev/c15f8debd6c9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 05:41:11 2014 From: report at bugs.python.org (Nikhil Benesch) Date: Sat, 27 Dec 2014 04:41:11 +0000 Subject: [issue14776] Add SystemTap static markers In-Reply-To: <1336683916.13.0.827403167525.issue14776@psf.upfronthosting.co.za> Message-ID: <1419655271.32.0.151449409055.issue14776@psf.upfronthosting.co.za> Changes by Nikhil Benesch : ---------- nosy: +benesch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 05:41:32 2014 From: report at bugs.python.org (Nikhil Benesch) Date: Sat, 27 Dec 2014 04:41:32 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1419655292.07.0.264388757926.issue13405@psf.upfronthosting.co.za> Changes by Nikhil Benesch : ---------- nosy: +benesch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 07:57:43 2014 From: report at bugs.python.org (Nikhil Benesch) Date: Sat, 27 Dec 2014 06:57:43 +0000 Subject: [issue21590] Systemtap and DTrace support In-Reply-To: <1401195995.8.0.935339035852.issue21590@psf.upfronthosting.co.za> Message-ID: <1419663463.5.0.144309137072.issue21590@psf.upfronthosting.co.za> Nikhil Benesch added the comment: Since it looks like development on this has stalled, I took the liberty of compiling all prior patches https://github.com/benesch/python-dtrace-tracker and am actively working on merging them into one superpatch. I am neither a Python nor a DTrace expert, so I'm happy to step aside should one of you more experienced folks have something ready. A few thoughts so far: * SPARC support? Can we drop this? It seems to add a bunch of intrusive inlined NOPs?that I'm not sure are even necessary. * @jcea, is this the original DTrace patch? https://github.com/benesch/python-dtrace-tracker/blob/master/dtrace-solaris-oracle-24.patch I'm trying to determine where those NOPs came from. Cheers! ---------- nosy: +benesch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 09:26:39 2014 From: report at bugs.python.org (Simon Zack) Date: Sat, 27 Dec 2014 08:26:39 +0000 Subject: [issue14965] super() and property inheritance behavior In-Reply-To: <1338433441.66.0.975494137492.issue14965@psf.upfronthosting.co.za> Message-ID: <1419668799.34.0.239952829409.issue14965@psf.upfronthosting.co.za> Simon Zack added the comment: For those who want to use this right away, I've added a python implementation of the patch, which passes the unit tests. There's a slight difference in usage, where instead of using super() directly, super_prop(super()) needs to be used, so we can still use super without arguments. ---------- Added file: http://bugs.python.org/file37546/superprop.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 09:36:51 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 27 Dec 2014 08:36:51 +0000 Subject: [issue23107] Tighten-up search loops in sets In-Reply-To: <1419400332.58.0.470390691587.issue23107@psf.upfronthosting.co.za> Message-ID: <1419669411.36.0.537228492427.issue23107@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 11:50:11 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 27 Dec 2014 10:50:11 +0000 Subject: [issue23119] Remove unicode specialization from set objects Message-ID: <1419677411.19.0.303130627071.issue23119@psf.upfronthosting.co.za> New submission from Raymond Hettinger: This tracker item is to record experiments with removing unicode specialization code from set objects and run timings to determine the performance benefits or losses from those specializations. * Removes the set_lookkey_unicode() function and the attendant so->lookup indirections. That saves 60 lines of code. On each lookup, it saves one indirection for the lookup dispatch, but in the case of unicode only tables, it costs an additional indirection through the abstract API for PyObject_RichCompareBool. * Removes the specialization code in add, discard, and contains functions to check for a unicode key with an already computed hash value. This saves a type check (cheap), a hash field check, and a nine lines of code. In the cast where the hash value would have already been computed, it costs a call to PyObject_Hash (which has an indirection, but otherwise does the same field test that we are doing). The working hypothesis is that this specialization code saves only a little in cases where it applies and adds a little to all the cases where it does not apply. (Note, the use cases for sets are less likely than dicts to be looking up strings whose hash value has already been computed.) ---------------------- Here are some initial timings for the first patch. It seems to show that intersection benefits slightly and that set creation time is unaffected. $ ./time_suite.sh 100000 loops, best of 3: 14.9 usec per loop 100000 loops, best of 3: 15.3 usec per loop 1000000 loops, best of 3: 1.17 usec per loop 1000000 loops, best of 3: 1.13 usec per loop 10000 loops, best of 3: 24.9 usec per loop 10000 loops, best of 3: 24.2 usec per loop $ ./time_suite.sh 100000 loops, best of 3: 14.7 usec per loop 100000 loops, best of 3: 14.6 usec per loop 1000000 loops, best of 3: 1.16 usec per loop 1000000 loops, best of 3: 1.07 usec per loop 10000 loops, best of 3: 23.1 usec per loop 10000 loops, best of 3: 23.4 usec per loop $ ./time_suite.sh 100000 loops, best of 3: 14.5 usec per loop 100000 loops, best of 3: 14.5 usec per loop 1000000 loops, best of 3: 1.16 usec per loop 1000000 loops, best of 3: 1.17 usec per loop 10000 loops, best of 3: 22.5 usec per loop 10000 loops, best of 3: 22 usec per loop ---------- assignee: rhettinger components: Interpreter Core files: one_lookkey.diff keywords: patch messages: 233128 nosy: rhettinger priority: normal severity: normal status: open title: Remove unicode specialization from set objects type: performance versions: Python 3.5 Added file: http://bugs.python.org/file37547/one_lookkey.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 11:51:10 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 27 Dec 2014 10:51:10 +0000 Subject: [issue23119] Remove unicode specialization from set objects In-Reply-To: <1419677411.19.0.303130627071.issue23119@psf.upfronthosting.co.za> Message-ID: <1419677470.3.0.373645154863.issue23119@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file37548/no_special_hash.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 11:51:56 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 27 Dec 2014 10:51:56 +0000 Subject: [issue23119] Remove unicode specialization from set objects In-Reply-To: <1419677411.19.0.303130627071.issue23119@psf.upfronthosting.co.za> Message-ID: <1419677516.84.0.0394585637247.issue23119@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file37549/time_suite.sh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 14:29:27 2014 From: report at bugs.python.org (Ned Batchelder) Date: Sat, 27 Dec 2014 13:29:27 +0000 Subject: [issue20844] SyntaxError: encoding problem: iso-8859-1 on Windows In-Reply-To: <1393854882.06.0.561987523346.issue20844@psf.upfronthosting.co.za> Message-ID: <1419686967.38.0.0700657887702.issue20844@psf.upfronthosting.co.za> Ned Batchelder added the comment: This bug just bit me. Changing "# coding: utf8" to "# coding: utf-8" works around it. ---------- nosy: +nedbat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 14:29:55 2014 From: report at bugs.python.org (Ned Batchelder) Date: Sat, 27 Dec 2014 13:29:55 +0000 Subject: [issue20844] SyntaxError: encoding problem: iso-8859-1 on Windows In-Reply-To: <1393854882.06.0.561987523346.issue20844@psf.upfronthosting.co.za> Message-ID: <1419686995.94.0.442506203483.issue20844@psf.upfronthosting.co.za> Ned Batchelder added the comment: (oops: with Python 3.4.1 on Windows) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 14:38:30 2014 From: report at bugs.python.org (Peter Santoro) Date: Sat, 27 Dec 2014 13:38:30 +0000 Subject: [issue23120] installation order of 32bit and 64bit python seems to matter Message-ID: <1419687510.82.0.457945734006.issue23120@psf.upfronthosting.co.za> New submission from Peter Santoro: It appears that installation order matters when installing both 32bit and 64bit versions of Python. If you install the 32bit version first, the 64bit version will uninstall the 32bit version. Here are the steps I used: 1. Starting point (Windows 7 64bit with latest MS patches): Python 3.3.5 32bit (c:\bin32\python33, required for support of older systems that will be upgraded to 3.4.3 when it's available) Python 3.4.1 32bit (c:\bin32\python34) Python 3.4.1 64bit (c:\bin\python34, included in PATH) 2. Uninstalled Python 3.4.1 32bit - ran as expected Python 3.4.1 64bit - ran as expected 3. Attempted Install (32bit install before 64bit install) Python 3.4.2 32bit (c:\bin32\python34) - ran as expected Python 3.4.2 64bit (c:\bin\python34) - install dialog had red warning message at top stating that previous version will be uninstalled; if you continue, the 64bit install deletes the Python 3.4.2 32bit install 4. Work around installation order (64bit install before 32bit install): Python 3.4.2 64bit (c:\bin\python34) - ran as expected Python 3.4.2 32bit (c:\bin32\python34) - ran as expected Notes: I've reported other strange issues with multiple versions of python installed, but they were deemed different than the original reported bug and were not further discussed. It's quite possible that the combination of python versions installed/uninstalled over time on this system has caused some bad/unexpected/untested state (e.g. Windows registry entries). ---------- components: Installation messages: 233131 nosy: peter at psantoro.net priority: normal severity: normal status: open title: installation order of 32bit and 64bit python seems to matter type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 14:59:59 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 27 Dec 2014 13:59:59 +0000 Subject: [issue23119] Remove unicode specialization from set objects In-Reply-To: <1419677411.19.0.303130627071.issue23119@psf.upfronthosting.co.za> Message-ID: <1419688799.5.0.0742414260158.issue23119@psf.upfronthosting.co.za> Antoine Pitrou added the comment: +1 for this. In my experience sets of unicode keys are not as common as dicts with unicode keys, and the posted numbers make the simplification a no-brainer. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 15:06:37 2014 From: report at bugs.python.org (Tim Golden) Date: Sat, 27 Dec 2014 14:06:37 +0000 Subject: [issue23120] installation order of 32bit and 64bit python seems to matter In-Reply-To: <1419687510.82.0.457945734006.issue23120@psf.upfronthosting.co.za> Message-ID: <1419689197.78.0.851919231719.issue23120@psf.upfronthosting.co.za> Changes by Tim Golden : ---------- components: +Windows nosy: +steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 16:10:13 2014 From: report at bugs.python.org (Joshua Ellinger) Date: Sat, 27 Dec 2014 15:10:13 +0000 Subject: [issue23121] pip.exe breaks if python 2.7.9 is installed under c:\Program Files\Python Message-ID: <1419693013.55.0.898507304072.issue23121@psf.upfronthosting.co.za> New submission from Joshua Ellinger: The problem is that the python path name is quoted if it contains spaces. The launcher does not remove the extra quotes and fails. I 'solved' by editing the pip.exe to remove the quotes. ps - Windows programs are normally installed under c:\Program Files or c:\Program Files (x86). That should be the default in the installer if possible. ---------- components: Windows messages: 233133 nosy: joshuaellinger, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: pip.exe breaks if python 2.7.9 is installed under c:\Program Files\Python type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 16:27:55 2014 From: report at bugs.python.org (R. David Murray) Date: Sat, 27 Dec 2014 15:27:55 +0000 Subject: [issue23118] Properly codesign Mac python 2.7.9.pkg so it can work thru OS X firewall In-Reply-To: <1419635049.3.0.430313609014.issue23118@psf.upfronthosting.co.za> Message-ID: <1419694075.54.0.337779846062.issue23118@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- superseder: -> Properly codesign Mac python 2.7.9.pkg so it can work thru OS X firewall _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 16:31:19 2014 From: report at bugs.python.org (Marcel Hellkamp) Date: Sat, 27 Dec 2014 15:31:19 +0000 Subject: [issue23122] python@93442 breaks build if system Python is 2.6 Message-ID: <1419694279.3.0.364576182532.issue23122@psf.upfronthosting.co.za> New submission from Marcel Hellkamp: On CentOS 6.6 the system Python is 2.6. The use to set literals in Parser/adsl.py breaks the build process on these systems. The ./configure should ensure that a compatible version of python is available. ---------- components: Build messages: 233134 nosy: Marcel.Hellkamp priority: normal severity: normal status: open title: python at 93442 breaks build if system Python is 2.6 type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 16:46:35 2014 From: report at bugs.python.org (Steve Dower) Date: Sat, 27 Dec 2014 15:46:35 +0000 Subject: [issue23120] installation order of 32bit and 64bit python seems to matter In-Reply-To: <1419687510.82.0.457945734006.issue23120@psf.upfronthosting.co.za> Message-ID: <1419695195.38.0.841011815786.issue23120@psf.upfronthosting.co.za> Steve Dower added the comment: I'm already quite keen to rename the registry key for 32-bit on Windows, since there are some places where that will cause conflicts. This won't be done for 3.4 though, as we don't have an active maintainer for the old installer (Martin is still building them, but not working on it). I haven't yet thought about how the updated keys should look, but when I get time to get back to the installer I'll try some things. The 3.5 installer shouldn't have this issue as it will use product codes to detect other Python installations rather than registry keys. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 16:49:07 2014 From: report at bugs.python.org (Steve Dower) Date: Sat, 27 Dec 2014 15:49:07 +0000 Subject: [issue23121] pip.exe breaks if python 2.7.9 is installed under c:\Program Files\Python In-Reply-To: <1419693013.55.0.898507304072.issue23121@psf.upfronthosting.co.za> Message-ID: <1419695347.82.0.292727249821.issue23121@psf.upfronthosting.co.za> Steve Dower added the comment: I've previously reported this issue against setuptools (which generates the executable) and apparently they consider it a "feature". I don't have the link handy from my phone, but if you find the issue on bitbucket you can help attract some more attention to this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 17:33:18 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 27 Dec 2014 16:33:18 +0000 Subject: [issue23122] python@93442 breaks build if system Python is 2.6 In-Reply-To: <1419694279.3.0.364576182532.issue23122@psf.upfronthosting.co.za> Message-ID: <1419697998.73.0.648092576657.issue23122@psf.upfronthosting.co.za> Berker Peksag added the comment: Could you try the following command? make touch See also https://docs.python.org/devguide/setup.html?highlight=touch#avoiding-re-creating-auto-generated-files ---------- nosy: +berker.peksag title: python at 93442 breaks build if system Python is 2.6 -> python at 93442 breaks build if system Python is 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 17:46:03 2014 From: report at bugs.python.org (Marcel Hellkamp) Date: Sat, 27 Dec 2014 16:46:03 +0000 Subject: [issue23122] python@93442 breaks build if system Python is 2.6 In-Reply-To: <1419694279.3.0.364576182532.issue23122@psf.upfronthosting.co.za> Message-ID: <1419698763.71.0.917554487294.issue23122@psf.upfronthosting.co.za> Marcel Hellkamp added the comment: "make touch" solved the problem. A clear case of RTFM :) Sorry for the noise. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 17:47:53 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 27 Dec 2014 16:47:53 +0000 Subject: [issue23122] python@93442 breaks build if system Python is 2.6 In-Reply-To: <1419694279.3.0.364576182532.issue23122@psf.upfronthosting.co.za> Message-ID: <1419698873.98.0.737312630386.issue23122@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 18:10:51 2014 From: report at bugs.python.org (Anders Rundgren) Date: Sat, 27 Dec 2014 17:10:51 +0000 Subject: [issue23123] Only READ support for Decimal in json Message-ID: <1419700251.42.0.619867786079.issue23123@psf.upfronthosting.co.za> New submission from Anders Rundgren: jsonString = '{"t":6,"h":4.50, "g":"text","j":1.40e450}' jsonObject = json.loads(jsonString, object_pairs_hook=collections.OrderedDict,parse_float=Decimal) for item in jsonObject: print jsonObject[item] 6 4.50 text 1.40E+450 Works as expected. However, there seems to be no way to get back to the original JSON string as far as I can tell since you have to convert Decimal to str in cls when using json.dumps which adds "" around the arguments ---------- components: Extension Modules messages: 233139 nosy: anders.rundgren.net at gmail.com priority: normal severity: normal status: open title: Only READ support for Decimal in json type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 19:51:46 2014 From: report at bugs.python.org (eryksun) Date: Sat, 27 Dec 2014 18:51:46 +0000 Subject: [issue23121] pip.exe breaks if python 2.7.9 is installed under c:\Program Files\Python In-Reply-To: <1419693013.55.0.898507304072.issue23121@psf.upfronthosting.co.za> Message-ID: <1419706306.2.0.911363105061.issue23121@psf.upfronthosting.co.za> eryksun added the comment: See issue 21699. This is fixed in distlib 0.1.9. The latest pip uses distlib 0.2.0, so just update from pip 1.5.6 to 6.0.3. C:\>"C:\Program Files\Python27\Scripts\pip.exe" --version pip 6.0.3 from C:\Program Files\Python27\lib\site-packages (python 2.7) Instructions for upgrading: https://pip.pypa.io/en/latest/installing.html#upgrade-pip ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 21:31:25 2014 From: report at bugs.python.org (Dirkjan Ochtman) Date: Sat, 27 Dec 2014 20:31:25 +0000 Subject: [issue23102] distutils: isinstance checks fail with setuptools-monkeypatched Extension/Distribution In-Reply-To: <1419316588.75.0.487755278973.issue23102@psf.upfronthosting.co.za> Message-ID: <1419712285.61.0.24015954722.issue23102@psf.upfronthosting.co.za> Changes by Dirkjan Ochtman : ---------- nosy: +djc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 21:35:04 2014 From: report at bugs.python.org (Carsten Grohmann) Date: Sat, 27 Dec 2014 20:35:04 +0000 Subject: [issue23102] distutils: isinstance checks fail with setuptools-monkeypatched Extension/Distribution In-Reply-To: <1419316588.75.0.487755278973.issue23102@psf.upfronthosting.co.za> Message-ID: <1419712504.63.0.433705567363.issue23102@psf.upfronthosting.co.za> Changes by Carsten Grohmann : ---------- nosy: +cgrohmann _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 22:04:02 2014 From: report at bugs.python.org (Berker Peksag) Date: Sat, 27 Dec 2014 21:04:02 +0000 Subject: [issue19539] The 'raw_unicode_escape' codec buggy + not appropriate for Python 3.x In-Reply-To: <1384051905.56.0.969775270474.issue19539@psf.upfronthosting.co.za> Message-ID: <1419714242.75.0.698702313483.issue19539@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> resolved superseder: -> 'codecs' module docs improvements _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 23:04:53 2014 From: report at bugs.python.org (Joshua Ellinger) Date: Sat, 27 Dec 2014 22:04:53 +0000 Subject: [issue23121] pip.exe breaks if python 2.7.9 is installed under c:\Program Files\Python In-Reply-To: <1419695347.82.0.292727249821.issue23121@psf.upfronthosting.co.za> Message-ID: <9B7FBDF2-7291-4965-BFCA-3D7C6B349C72@exemplartech.com> Joshua Ellinger added the comment: Having pip not work after a straight install to the normal place you'd install it on windows can't be a feature. Even after I changed the .exe, pip itself breaks on the same problem. Basically, you can't install python to the normal place on windows until this is fixed. Josh On Dec 27, 2014, at 9:49 AM, Steve Dower wrote: > > Steve Dower added the comment: > > I've previously reported this issue against setuptools (which generates the executable) and apparently they consider it a "feature". I don't have the link handy from my phone, but if you find the issue on bitbucket you can help attract some more attention to this. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 23:24:29 2014 From: report at bugs.python.org (Joshua Ellinger) Date: Sat, 27 Dec 2014 22:24:29 +0000 Subject: [issue23121] pip.exe breaks if python 2.7.9 is installed under c:\Program Files\Python In-Reply-To: <9B7FBDF2-7291-4965-BFCA-3D7C6B349C72@exemplartech.com> Message-ID: Joshua Ellinger added the comment: The safest fix would be to make subprocess strip double-quotes from the executable path. Double quote (") is not an allowed character in Windows file systems. There is no case under which it can be correct to spawn a process in Windows where the path is quoted. http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx On Dec 27, 2014, at 4:04 PM, Joshua Ellinger wrote: > > Joshua Ellinger added the comment: > > Having pip not work after a straight install to the normal place you'd install it on windows can't be a feature. > > Even after I changed the .exe, pip itself breaks on the same problem. Basically, you can't install python to > the normal place on windows until this is fixed. > > Josh > > On Dec 27, 2014, at 9:49 AM, Steve Dower wrote: > >> >> Steve Dower added the comment: >> >> I've previously reported this issue against setuptools (which generates the executable) and apparently they consider it a "feature". I don't have the link handy from my phone, but if you find the issue on bitbucket you can help attract some more attention to this. >> >> ---------- >> >> _______________________________________ >> Python tracker >> >> _______________________________________ > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Dec 27 23:39:00 2014 From: report at bugs.python.org (Donald Stufft) Date: Sat, 27 Dec 2014 22:39:00 +0000 Subject: [issue23121] pip.exe breaks if python 2.7.9 is installed under c:\Program Files\Python In-Reply-To: <1419693013.55.0.898507304072.issue23121@psf.upfronthosting.co.za> Message-ID: <1419719940.79.0.372460321011.issue23121@psf.upfronthosting.co.za> Donald Stufft added the comment: If distlib 0.2.0 fixes this, then it should be fixed in pip 6+ when installing from Wheels. If the same problem exists in setuptools then it'll need to get fixed in setuptools (or pip will need to start writing it's own console scripts when installing from sdist too). ---------- nosy: +dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 02:13:09 2014 From: report at bugs.python.org (eryksun) Date: Sun, 28 Dec 2014 01:13:09 +0000 Subject: [issue23121] pip.exe breaks if python 2.7.9 is installed under c:\Program Files\Python In-Reply-To: <1419693013.55.0.898507304072.issue23121@psf.upfronthosting.co.za> Message-ID: <1419729189.22.0.785527243229.issue23121@psf.upfronthosting.co.za> eryksun added the comment: > If the same problem exists in setuptools then it'll need to > get fixed in setuptools (or pip will need to start writing > it's own console scripts when installing from sdist too). Will setuptools eventually switch to using distlib also? Currently setuptools has a different problem. Instead of errnously double quoting the EXE path, it doesn't quote it at all. As you can see in the cdb debugger output below, CreateProcessA is called without properly quoting the path to python.exe (register rdx is the 2nd parameter, lpCommandLine). C:\>cdb "C:\Program Files\Python27\Scripts\test.exe" [clip] 0:000> bp kernel32!CreateProcessA 0:000> g Breakpoint 0 hit kernel32!CreateProcessA: 00000000`77a4acf0 4c8bdc mov r11,rsp 0:000> db @rdx 00000000`00585c40 43 3a 5c 50 72 6f 67 72-61 6d 20 46 69 6c 65 73 C:\Program Files 00000000`00585c50 5c 50 79 74 68 6f 6e 32-37 5c 70 79 74 68 6f 6e \Python27\python 00000000`00585c60 2e 65 78 65 20 22 43 3a-5c 50 72 6f 67 72 61 6d .exe "C:\Program 00000000`00585c70 20 46 69 6c 65 73 5c 50-79 74 68 6f 6e 32 37 5c Files\Python27\ 00000000`00585c80 53 63 72 69 70 74 73 5c-74 65 73 74 2d 73 63 72 Scripts\test-scr 00000000`00585c90 69 70 74 2e 70 79 22 00-00 ab ab ab ab ab ab ab ipt.py"......... 00000000`00585ca0 ab ab ab ab ab ab ab ab-ab fe ee fe ee fe ee fe ................ 00000000`00585cb0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ So test.exe will actually run C:\program.exe, if it exists. For example: C:\>type program.c #include int main(int argc, char *argv[]) { int i; for (i=0; i < argc; i++) printf("%s\n", argv[i]); return 0; } C:\>dir /b C:\program.exe program.exe C:\>"C:\Program Files\Python27\Scripts\test.exe" C:\Program Files\Python27\python.exe C:\Program Files\Python27\Scripts\test-script.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 02:48:19 2014 From: report at bugs.python.org (Adam Carruthers) Date: Sun, 28 Dec 2014 01:48:19 +0000 Subject: [issue23124] Incorrect Integer saving Message-ID: <1419731299.6.0.137708787639.issue23124@psf.upfronthosting.co.za> New submission from Adam Carruthers: 255 is 255 -> True (255).bit_length() -> 8 256 is 256 -> True (256).bit_length() -> 9 257 is 257 -> False (257).bit_length() -> 9 ^ Will show True if you do it exactly like this because of a quirk. a = 257 b = 257 a is b -> False I think you don't want to map variables to integers direct unless they are at or under 8 bits in length. ---------- messages: 233145 nosy: Adam.Carruthers priority: normal severity: normal status: open title: Incorrect Integer saving type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 02:48:35 2014 From: report at bugs.python.org (Adam Carruthers) Date: Sun, 28 Dec 2014 01:48:35 +0000 Subject: [issue23124] Incorrect Integer saving In-Reply-To: <1419731299.6.0.137708787639.issue23124@psf.upfronthosting.co.za> Message-ID: <1419731315.42.0.632204240953.issue23124@psf.upfronthosting.co.za> Changes by Adam Carruthers : ---------- nosy: -Adam.Carruthers _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 02:59:16 2014 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 28 Dec 2014 01:59:16 +0000 Subject: [issue23124] Incorrect Integer saving In-Reply-To: <1419731299.6.0.137708787639.issue23124@psf.upfronthosting.co.za> Message-ID: <1419731956.88.0.398942484595.issue23124@psf.upfronthosting.co.za> Ezio Melotti added the comment: On CPython small ints are cached to improve performances. This is an implementation detail and "is" should not be used to compare ints (== should be used instead). ---------- nosy: +ezio.melotti resolution: -> not a bug stage: -> resolved status: open -> closed type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 09:01:44 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Sun, 28 Dec 2014 08:01:44 +0000 Subject: [issue22706] Idle extension configuration and key bindings In-Reply-To: <1414023453.7.0.681663520586.issue22706@psf.upfronthosting.co.za> Message-ID: <1419753704.48.0.589034887862.issue22706@psf.upfronthosting.co.za> Changes by Saimadhav Heblikar : ---------- keywords: +patch Added file: http://bugs.python.org/file37550/issue22706_1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 09:48:33 2014 From: report at bugs.python.org (STINNER Victor) Date: Sun, 28 Dec 2014 08:48:33 +0000 Subject: [issue19539] The 'raw_unicode_escape' codec buggy + not appropriate for Python 3.x In-Reply-To: <1419714242.79.0.428689061804.issue19539@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: This issue is just a documentation issue. The do must be more explicit, explain that the codecs is only used internally by the pickle module, and that its output cannot be used anymore by eval(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 09:50:57 2014 From: report at bugs.python.org (=?utf-8?q?Damien_Mari=C3=A9?=) Date: Sun, 28 Dec 2014 08:50:57 +0000 Subject: [issue23125] Link to the nose project obsolete Message-ID: <1419756657.65.0.513358597735.issue23125@psf.upfronthosting.co.za> New submission from Damien Mari?: The Nose project moved from Google Code to Github, the link in the unittest documentation didn't change. How to reproduce: - Go to https://docs.python.org/3.5/library/unittest.html - Click on nose (in the "See also" section) - See the Google Code project being moved to github How to fix: Replace the link with the readthedocs page ( https://nose.readthedocs.org/en/latest/ ) or the github page ---------- assignee: docs at python components: Documentation messages: 233148 nosy: docs at python, mariedam priority: normal severity: normal status: open title: Link to the nose project obsolete 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 Dec 28 17:35:01 2014 From: report at bugs.python.org (Chris Angelico) Date: Sun, 28 Dec 2014 16:35:01 +0000 Subject: [issue23126] Add Python hook function to replace NameError Message-ID: <1419784501.24.0.582986414066.issue23126@psf.upfronthosting.co.za> New submission from Chris Angelico: Creating an issue to keep track of a patch, but this probably wants to be discussed on python-ideas. The attached patch allows a Python function to be put into sys.__getglobal__, which then works like __getattr__ but for global names. This allows interactive interpreters to auto-import, for instance: def try_import(n): try: return __import__(n) except ImportError: raise NameError("Name %r is not defined"%n) import sys sys.__getglobal__ = try_import ---------- components: Interpreter Core files: nameerror_hook.patch keywords: patch messages: 233149 nosy: Rosuav priority: normal severity: normal status: open title: Add Python hook function to replace NameError versions: Python 3.5 Added file: http://bugs.python.org/file37551/nameerror_hook.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 17:47:23 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 28 Dec 2014 16:47:23 +0000 Subject: [issue23125] Link to the nose project obsolete In-Reply-To: <1419756657.65.0.513358597735.issue23125@psf.upfronthosting.co.za> Message-ID: <20141228164720.22202.40704@psf.io> Roundup Robot added the comment: New changeset 0a2bb697d1c3 by Berker Peksag in branch '3.4': Issue #23125: Update nose project page link. https://hg.python.org/cpython/rev/0a2bb697d1c3 New changeset 11fd71a37665 by Berker Peksag in branch 'default': Issue #23125: Update nose project page link. https://hg.python.org/cpython/rev/11fd71a37665 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 17:49:51 2014 From: report at bugs.python.org (Roundup Robot) Date: Sun, 28 Dec 2014 16:49:51 +0000 Subject: [issue23125] Link to the nose project obsolete In-Reply-To: <1419756657.65.0.513358597735.issue23125@psf.upfronthosting.co.za> Message-ID: <20141228164945.120047.32672@psf.io> Roundup Robot added the comment: New changeset 88de50c1696b by Berker Peksag in branch '2.7': Issue #23125: Update nose project page link. https://hg.python.org/cpython/rev/88de50c1696b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 17:51:02 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 28 Dec 2014 16:51:02 +0000 Subject: [issue23125] Link to the nose project obsolete In-Reply-To: <1419756657.65.0.513358597735.issue23125@psf.upfronthosting.co.za> Message-ID: <1419785462.26.0.128745401544.issue23125@psf.upfronthosting.co.za> Berker Peksag added the comment: Fixed. Thanks for the report, Damien. ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 2.7 -Python 3.2, Python 3.3, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 20:01:19 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 28 Dec 2014 19:01:19 +0000 Subject: [issue19776] Provide expanduser() on Path objects In-Reply-To: <1385409778.55.0.842571848249.issue19776@psf.upfronthosting.co.za> Message-ID: <1419793279.03.0.680859368363.issue19776@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +steve.dower, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 20:03:22 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 28 Dec 2014 19:03:22 +0000 Subject: [issue19776] Provide expanduser() on Path objects In-Reply-To: <1385409778.55.0.842571848249.issue19776@psf.upfronthosting.co.za> Message-ID: <1419793402.5.0.19351712378.issue19776@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Steve, would you like to give an opinion on the Windows aspects of this patch? Otherwise I will simply commit it soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 20:46:44 2014 From: report at bugs.python.org (Berker Peksag) Date: Sun, 28 Dec 2014 19:46:44 +0000 Subject: [issue11638] python setup.py sdist --formats tar* crashes if version is unicode In-Reply-To: <1300828733.05.0.475519990909.issue11638@psf.upfronthosting.co.za> Message-ID: <1419796004.09.0.798244162529.issue11638@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 21:07:41 2014 From: report at bugs.python.org (Steve Dower) Date: Sun, 28 Dec 2014 20:07:41 +0000 Subject: [issue19776] Provide expanduser() on Path objects In-Reply-To: <1385409778.55.0.842571848249.issue19776@psf.upfronthosting.co.za> Message-ID: <1419797261.23.0.317766748306.issue19776@psf.upfronthosting.co.za> Steve Dower added the comment: I thought that USERPROFILE was the preferred environment variable and should be checked before HOME, but I could be wrong. Consistency with the existing expanduser function is more important probably. There's almost certainly an API to find an arbitrary user directory, but it may only be available to administrators, so the guess is probably necessary anyway. The directory name doesn't necessarily match the user name either, especially since a lot of Windows users these days authenticate with their email address. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Dec 28 23:01:25 2014 From: report at bugs.python.org (varde) Date: Sun, 28 Dec 2014 22:01:25 +0000 Subject: [issue23111] ftplib.FTP_TLS's default constructor does not work with TLSv1.1 or TLSv1.2 In-Reply-To: <1419457507.62.0.0499182915126.issue23111@psf.upfronthosting.co.za> Message-ID: <1419804085.35.0.00705407215179.issue23111@psf.upfronthosting.co.za> varde added the comment: Well, because the ssl_version parameter should have a purpose. If it doesn't, the least we could do is remove it from the docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 00:36:04 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 28 Dec 2014 23:36:04 +0000 Subject: [issue23123] Only READ support for Decimal in json In-Reply-To: <1419700251.42.0.619867786079.issue23123@psf.upfronthosting.co.za> Message-ID: <1419809764.74.0.533133023627.issue23123@psf.upfronthosting.co.za> Raymond Hettinger added the comment: It is unfortunate that there doesn't seem to be a way to round-trip Decimals. That would seem to be a fundamental capability that we should expect to support. I have a vague recollection that you used to be able to trick the encoder by returning a subclass of float with a custom __str__; however, I don't think that hack would work anymore because float subclasses now get coerced back to a regular float in order to make the json module work with Enums (which have a __str__ that is meaningless in JSON). In Python 3.5, it would be nice to add a hook that affords more control than "cls" currently does. Ideally, it should allow any class to special exactly what it wants written-out. Another option, for Py2.7, 3.4, and 3.5 is to add direct support for decimal instances (much like the enum support was backported). ---------- assignee: -> bob.ippolito nosy: +bob.ippolito, ethan.furman, rhettinger versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 02:20:04 2014 From: report at bugs.python.org (Ethan Furman) Date: Mon, 29 Dec 2014 01:20:04 +0000 Subject: [issue23123] Only READ support for Decimal in json In-Reply-To: <1419700251.42.0.619867786079.issue23123@psf.upfronthosting.co.za> Message-ID: <1419816004.02.0.276440790073.issue23123@psf.upfronthosting.co.za> Ethan Furman added the comment: Enums (and other numeric subclasses), do not round-trip back to themselves. An IntEnum with the value of 4 is written as 4 and converted back from json as the integer 4 (not Settings.TabSpaces, or whatever). Given that json is multi-language format (or a javascript format -- but either way not a Python-specific format) I don't know that we can expect much more from it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 03:29:19 2014 From: report at bugs.python.org (Bertrand Janin) Date: Mon, 29 Dec 2014 02:29:19 +0000 Subject: [issue3372] socket.setsockopt() is broken for multicast TTL and Loop options In-Reply-To: <1216172332.9.0.582364259682.issue3372@psf.upfronthosting.co.za> Message-ID: <1419820159.27.0.311177712639.issue3372@psf.upfronthosting.co.za> Bertrand Janin added the comment: This is still an issue as of OpenBSD 5.6. Here is an updated patch for the latest 2.7 branch: diff -r 88de50c1696b Modules/socketmodule.c --- a/Modules/socketmodule.c Sun Dec 28 18:51:25 2014 +0200 +++ b/Modules/socketmodule.c Sun Dec 28 21:24:41 2014 -0500 @@ -1881,24 +1881,29 @@ { int level; int optname; int res; char *buf; int buflen; int flag; if (PyArg_ParseTuple(args, "iii:setsockopt", &level, &optname, &flag)) { buf = (char *) &flag; buflen = sizeof flag; + /* Multi cast options take shorter arguments */ + if (optname == IP_MULTICAST_TTL + || optname == IP_MULTICAST_LOOP) + buflen = sizeof(u_char); + buf = (char *) &flag; } else { PyErr_Clear(); if (!PyArg_ParseTuple(args, "iis#:setsockopt", &level, &optname, &buf, &buflen)) return NULL; } res = setsockopt(s->sock_fd, level, optname, (void *)buf, buflen); if (res < 0) return s->errorhandler(); Py_INCREF(Py_None); return Py_None; ---------- nosy: +tamentis versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 06:32:17 2014 From: report at bugs.python.org (Bob Ippolito) Date: Mon, 29 Dec 2014 05:32:17 +0000 Subject: [issue23123] Only READ support for Decimal in json In-Reply-To: <1419700251.42.0.619867786079.issue23123@psf.upfronthosting.co.za> Message-ID: <1419831137.46.0.328928612125.issue23123@psf.upfronthosting.co.za> Bob Ippolito added the comment: simplejson has had a use_decimal flag for output since 2.1.0 and has been enabled by default since 2.2.0. simplejson 3.2.0 introduced a for_json argument that checks objects for a method of that name for serialization. https://github.com/simplejson/simplejson/blob/master/CHANGES.txt ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 06:46:09 2014 From: report at bugs.python.org (Anders Rundgren) Date: Mon, 29 Dec 2014 05:46:09 +0000 Subject: [issue23123] Only READ support for Decimal in json In-Reply-To: <1419700251.42.0.619867786079.issue23123@psf.upfronthosting.co.za> Message-ID: <1419831969.98.0.754700236755.issue23123@psf.upfronthosting.co.za> Anders Rundgren added the comment: I was actually hoping to implement the final part of this: https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html#Normalization_and_Signature_Validation It seems that the current Decimal implementation wouldn't save me anyway since it modifies the input :-( Anyway, floats in JSON have rather little use so maybe my existing Pyhton (PoC) solution will be "good enough": https://code.google.com/p/openkeystore/source/browse/python/trunk/src/org/webpki/json/JCSValidator.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 08:31:06 2014 From: report at bugs.python.org (Bob Ippolito) Date: Mon, 29 Dec 2014 07:31:06 +0000 Subject: [issue23123] Only READ support for Decimal in json In-Reply-To: <1419700251.42.0.619867786079.issue23123@psf.upfronthosting.co.za> Message-ID: <1419838266.53.0.211340402583.issue23123@psf.upfronthosting.co.za> Bob Ippolito added the comment: I'm sure there's some hack that would allow you to preserve the input. I would try using parse_float and have it return some object that preserves the string and will be output in precisely the same way. It may need to be a Decimal subclass. I'm traveling for the next few weeks so I won't have much of a chance to investigate myself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 08:48:54 2014 From: report at bugs.python.org (Anders Rundgren) Date: Mon, 29 Dec 2014 07:48:54 +0000 Subject: [issue23123] Only READ support for Decimal in json In-Reply-To: <1419700251.42.0.619867786079.issue23123@psf.upfronthosting.co.za> Message-ID: <1419839334.41.0.639762755243.issue23123@psf.upfronthosting.co.za> Anders Rundgren added the comment: It would be great if I could use a sub-classed Decimal during parsing but since it doesn't appear to be a way to serialize the result using the "json" package I'm probably stuck with the current "99%" solution. I have solved this in Java and JavaScript by writing my own JSON stuff http://webpki.org/papers/keygen2/doc/org/webpki/json/package-summary.html but that method obviously doesn't scale and I'm a real n00b when it comes to Python although it was more fun than I had expected :-) A minor patch addressing serialization of Decimal would probably do fine (after sub-classing) and would be generally useful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 08:53:59 2014 From: report at bugs.python.org (Bob Ippolito) Date: Mon, 29 Dec 2014 07:53:59 +0000 Subject: [issue23123] Only READ support for Decimal in json In-Reply-To: <1419700251.42.0.619867786079.issue23123@psf.upfronthosting.co.za> Message-ID: <1419839639.59.0.287469422108.issue23123@psf.upfronthosting.co.za> Bob Ippolito added the comment: Subclass Decimal and implement __str__ to return your own representation. Use parse_float to use your Decimal subclass. Should work with simplejson, a similar hack may be possible with the json module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 09:15:42 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 29 Dec 2014 08:15:42 +0000 Subject: [issue23119] Remove unicode specialization from set objects In-Reply-To: <1419677411.19.0.303130627071.issue23119@psf.upfronthosting.co.za> Message-ID: <1419840942.0.0.931955644118.issue23119@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Attaching an alternative patch that handles the unicode specific case with far less code and less overhead. It seems to speed-up all the timings I've tried. It keeps the unicode_eq() specific path which bypasses several unneeded steps: * an incref/decref of the startkey * an incref/decref of Py_True or Py_False * Py_Enter/LeaveRecursive call overhead * A NotImplemented check * Various indirections, null checks, xor bool result, and several nested function calls that save and restore registers * Test for an error result * Test for changed table or entry usual incref/decref, richbool, richcmp, tablesize_change, errorcheck, recursion depth, check for NotImplemented, conv to PyTrue/False, incr/dec Py_True/Py_False, conv back to int } ---------- Added file: http://bugs.python.org/file37552/move_unicode_inside.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 09:30:19 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 29 Dec 2014 08:30:19 +0000 Subject: [issue23123] Only READ support for Decimal in json In-Reply-To: <1419700251.42.0.619867786079.issue23123@psf.upfronthosting.co.za> Message-ID: <1419841819.39.0.11705903842.issue23123@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Given that json is multi-language format ... I don't know > that we can expect much more from it. JSON specifies a textual number format but doesn't dictate whether that format represents a fixed precision binary float point number or a decimal floating point number. It is perfectly reasonable for someone to want to read and write a JSON number format to and from a decimal (we also see this with database formats as well -- such as sqlite). This bug report isn't a JSON spec issue; rather, it is about how the JSON module API can support (or inhibit) valid use cases. AFAICT, the patch to make the API better support enums had the side-effect of inhibiting the APIs ability to support number objects that want to control their output via __str__ or __repr__. This seems to block-off decimal support and support for controlling displayed precision. I think the Enum patch is suspect and could be considered a regression. That said, we could simply add direct support for decimals and leave the enum patch in-place (though it still impairs a user's ability to control the displayed precision). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 10:08:06 2014 From: report at bugs.python.org (Anders Rundgren) Date: Mon, 29 Dec 2014 09:08:06 +0000 Subject: [issue23123] Only READ support for Decimal in json In-Reply-To: <1419700251.42.0.619867786079.issue23123@psf.upfronthosting.co.za> Message-ID: <1419844086.12.0.441766974471.issue23123@psf.upfronthosting.co.za> Anders Rundgren added the comment: I guess my particular requirement/wish is unusual (keeping the original textual representation of a floating point number intact) while using Decimal should be fairly universal. If these things could be combined in a Decimal support option I would (of course) be extremely happy. They do not appear to be in conflict. Currently I'm a bit bogged down by the crypto-stuff since it is spread over different and incompatible modules which makes it awkward creating a nice unified RSA/EC solution. I may end-up writing a wrapper... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 10:10:35 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 29 Dec 2014 09:10:35 +0000 Subject: [issue19548] 'codecs' module docs improvements In-Reply-To: <1384133353.82.0.173341188397.issue19548@psf.upfronthosting.co.za> Message-ID: <1419844235.65.0.616803684977.issue19548@psf.upfronthosting.co.za> Nick Coghlan added the comment: I started making a few edits based on Zuo and Walter's comments while getting this patch ready for merging, and decided the end result could benefit from an additional round of feedback before committing it. This particular patch is also aimed at the Python 3.4 maintenance branch rather than at trunk - the introduction of the new namereplace error handler in 3.5 means that the previous patch didn't apply cleanly to the maintenance branch. While Zoinkity's feedback is also valid (i.e. multibyte codecs aren't documented properly, custom codec registration is both harder than it really should be and not well documented), I think those are better filed and handled as separate issues, rather than trying to handle them here as part of the general "bring the current content of the codec module documentation up to date with the current state of Python 3". ---------- assignee: docs at python -> ncoghlan stage: patch review -> commit review Added file: http://bugs.python.org/file37553/issue19548-codecs-doc.py34.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 10:30:16 2014 From: report at bugs.python.org (Bob Ippolito) Date: Mon, 29 Dec 2014 09:30:16 +0000 Subject: [issue23123] Only READ support for Decimal in json In-Reply-To: <1419700251.42.0.619867786079.issue23123@psf.upfronthosting.co.za> Message-ID: <1419845416.87.0.651673483479.issue23123@psf.upfronthosting.co.za> Bob Ippolito added the comment: I don't think it's reasonable to expect Decimal to always output precisely the same string it was given. It's a waste of complexity and space and the only time you would want this behavior is when you really should've left it accessible as a string in the first place. It sounds like the spec for that signature may be poorly designed (with regard to portability). Relying on the precise string output of a number is not going to work in any JSON parser I've ever seen. You'd need to work at the tokenizer level and not all of the parsers provide an interface at that layer (since many of them combine tokenization and parsing). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 10:40:07 2014 From: report at bugs.python.org (Anders Rundgren) Date: Mon, 29 Dec 2014 09:40:07 +0000 Subject: [issue23123] Only READ support for Decimal in json In-Reply-To: <1419700251.42.0.619867786079.issue23123@psf.upfronthosting.co.za> Message-ID: <1419846007.01.0.767419210283.issue23123@psf.upfronthosting.co.za> Anders Rundgren added the comment: Bob, Your'e right, I have put up a requirement for JSON serializing that may be "over the top". OTOH, there are (AFAICT...) only two possible solutions: 1. Outlaw floating point data from the plot 2. Insist that serializers conform to the spec As a pragmatic I have settled on something in between :-) https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html#Interoperability I don't think that the overhead in Decimal would be a problem but I'm not a Python platform maintainer so I leave it to you guys. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 10:58:30 2014 From: report at bugs.python.org (Anders Rundgren) Date: Mon, 29 Dec 2014 09:58:30 +0000 Subject: [issue23123] Only READ support for Decimal in json In-Reply-To: <1419700251.42.0.619867786079.issue23123@psf.upfronthosting.co.za> Message-ID: <1419847110.11.0.128746604663.issue23123@psf.upfronthosting.co.za> Anders Rundgren added the comment: Well, I could have insisted on canonicalization of floating-point data but that's so awkward that outlawing such data is a cleaner approach. Since the target for JCS is security- and payment-protocols, I don't think the absence of floating-point support will be a show-stopper. I does though make the IETF folks unhappy. Another reason for still wanting it to work as currently specified is because it would be nice to have JCS running on three fully compatible platforms, including one which I haven't designed :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 11:55:08 2014 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 29 Dec 2014 10:55:08 +0000 Subject: [issue23103] Reduce memory usage for ipaddress object instances In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> Message-ID: <1419850508.64.0.371404712972.issue23103@psf.upfronthosting.co.za> Nick Coghlan added the comment: I've retitled this issue to be specifically about reducing the memory consumption of the existing types in the IP Address module, as that's a change that isn't easily implemented externally, and shouldn't have any negative side effects under intended usage (although we should probably consider keeping __weakref__ support when adding the __slots__ definitions - I'm OK with taking away arbitrary attribute support, but far more wary of removing the existing weakref support) By contrast, interning for even more aggressive memory usage reduction is something that can be implemented relatively easily externally, and is also something that is really hard to tune in the general case. "Small integers" and "strings that look like identifiers" are a win because of the way the language itself works, but there's no similar general purpose heuristic that applies for caching of IP addresses. ---------- title: ipaddress should be Flyweight -> Reduce memory usage for ipaddress object instances _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 12:26:01 2014 From: report at bugs.python.org (Greg Turner) Date: Mon, 29 Dec 2014 11:26:01 +0000 Subject: [issue23102] distutils: isinstance checks fail with setuptools-monkeypatched Extension/Distribution In-Reply-To: <1419316588.75.0.487755278973.issue23102@psf.upfronthosting.co.za> Message-ID: <1419852361.0.0.362904193961.issue23102@psf.upfronthosting.co.za> Greg Turner added the comment: Here's the same deal more-or-less for issue 23114... this time I expended considerably less effort verifying that it's not a bad idea. At a glance, though, it looks fine, and solved an instance of the issue 23114 problem I was able to repro on my box. Patch context reduced so as to be applicable to all three pythons in one go. ---------- Added file: http://bugs.python.org/file37554/distutils_accomodate_distribution_ducktypes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 12:55:03 2014 From: report at bugs.python.org (Greg Turner) Date: Mon, 29 Dec 2014 11:55:03 +0000 Subject: [issue23102] distutils: isinstance checks fail with setuptools-monkeypatched Extension/Distribution In-Reply-To: <1419316588.75.0.487755278973.issue23102@psf.upfronthosting.co.za> Message-ID: <1419854103.32.0.914804062743.issue23102@psf.upfronthosting.co.za> Greg Turner added the comment: Perhaps it is worth addressing, briefly, the following hypothetical question, as a litmus test against the faint dis-encapsulation code-smell some folks might be picking up from this: In a hypothetcial world without setuptools, would these changes have merit? I'd say, technically, yes. In the Extension case, we are just really trying to ask, "is it a tuple", and in the Distribution case, "Can we use this thing to finalize/reinitialize Commands?", so, in theory, at least, these isinstance() checks are less pythonic than the hasattr checks in my patches. That stated, I think isinstance was the sensible way to code this in a vacuum, and obviously, I would never have thought this was a fantastic and self-evident proposal, were it not for these setuptools problems. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 14:31:07 2014 From: report at bugs.python.org (Bertrand Janin) Date: Mon, 29 Dec 2014 13:31:07 +0000 Subject: [issue23127] socket.setsockopt() is still broken for multicast TTL and Loop options Message-ID: <1419859867.69.0.91970081595.issue23127@psf.upfronthosting.co.za> New submission from Bertrand Janin: Since I can't re-open issue 3372, I'm opening a new issue. socket.setsockopt() still sets an optlen of '4' in the setsockopt() system call for options IP_MULTICAST_TTL and IP_MULTICAST_LOOP. On OpenBSD, this causes the kernel to hit an error condition and set errno 22 when these options are set: socket.error: (22, 'Invalid argument') According to both FreeBSD and OpenBSD manual pages (see e.g. http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/ip.4), these fields are in fact both 8 bit unsigned, and the manuals suggest the following: u_char ttl; /* range: 0 to 255, default = 1 */ setsockopt(s, IPPROTO_IP, IP_MULTICAST_TTL, &ttl, sizeof(ttl)); The following updated patch for branch "2.7" passes a shorter "optlen" for certain Multicast options, it was tested on OpenBSD, Linux and OSX and was initially proposed by niallo: diff -r 88de50c1696b Modules/socketmodule.c --- a/Modules/socketmodule.c Sun Dec 28 18:51:25 2014 +0200 +++ b/Modules/socketmodule.c Mon Dec 29 08:27:24 2014 -0500 @@ -1879,26 +1879,29 @@ static PyObject * sock_setsockopt(PySocketSockObject *s, PyObject *args) { int level; int optname; int res; char *buf; int buflen; int flag; if (PyArg_ParseTuple(args, "iii:setsockopt", &level, &optname, &flag)) { + buflen = sizeof flag; + /* Multicast options take shorter arguments */ + if (optname == IP_MULTICAST_TTL || optname == IP_MULTICAST_LOOP) + buflen = sizeof(u_char); buf = (char *) &flag; - buflen = sizeof flag; } else { PyErr_Clear(); if (!PyArg_ParseTuple(args, "iis#:setsockopt", &level, &optname, &buf, &buflen)) return NULL; } res = setsockopt(s->sock_fd, level, optname, (void *)buf, buflen); if (res < 0) return s->errorhandler(); Py_INCREF(Py_None); return Py_None; ---------- components: Library (Lib) messages: 233174 nosy: tamentis priority: normal severity: normal status: open title: socket.setsockopt() is still broken for multicast TTL and Loop options type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 16:23:07 2014 From: report at bugs.python.org (Anders Rundgren) Date: Mon, 29 Dec 2014 15:23:07 +0000 Subject: [issue23123] Only READ support for Decimal in json In-Reply-To: <1419700251.42.0.619867786079.issue23123@psf.upfronthosting.co.za> Message-ID: <1419866587.6.0.880761148098.issue23123@psf.upfronthosting.co.za> Anders Rundgren added the comment: Using simplejson I got it to work!!! I just wonder what you think of the solution: import collections import simplejson as json from decimal import Decimal class EnhancedDecimal(Decimal): def __str__ (self): return self.saved_string def __new__(cls, value="0", context=None): obj = Decimal.__new__(cls,value,context) obj.saved_string = value return obj; jsonString = '{"t":6,"h":4.50, "g":"text","j":1.40e450}' jsonObject = json.loads(jsonString, object_pairs_hook=collections.OrderedDict,parse_float=EnhancedDecimal) for item in jsonObject: print jsonObject[item] print json.dumps(jsonObject) 6 4.50 text 1.40e450 {"t": 6, "h": 4.50, "g": "text", "j": 1.40e450} ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 16:26:18 2014 From: report at bugs.python.org (Gereon Kremer) Date: Mon, 29 Dec 2014 15:26:18 +0000 Subject: [issue11245] Implementation of IMAP IDLE in imaplib? In-Reply-To: <1298061371.03.0.0638918089315.issue11245@psf.upfronthosting.co.za> Message-ID: <1419866778.06.0.809603829695.issue11245@psf.upfronthosting.co.za> Gereon Kremer added the comment: So, let's resurrect this one. For the project that lead to the old patch, we did not need this feature. However, we now needed are more complete implementation of IDLE. Hence, we extended this to return after sending idle() and support polling, leaving idle mode or wait until something happens (like before). ---------- Added file: http://bugs.python.org/file37555/imapidle.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 17:34:22 2014 From: report at bugs.python.org (Philipp Emanuel Weidmann) Date: Mon, 29 Dec 2014 16:34:22 +0000 Subject: [issue23128] Key presses are doubled in Tkinter dialog invoked from window close handler (OS X only) Message-ID: <1419870862.78.0.0503102610416.issue23128@psf.upfronthosting.co.za> New submission from Philipp Emanuel Weidmann: Minimal code example: from Tkinter import Tk from tkSimpleDialog import askstring def close_handler(): askstring('', '') root.destroy() root = Tk() root.protocol('WM_DELETE_WINDOW', close_handler) root.mainloop() Closing the main window brings up the askstring dialog. *When run on OS X* (Yosemite, default Python and Tkinter version), each key press on the dialog's input field is doubled (thus when typing "abc" what will actually be entered is "aabbcc"). On Linux (Python + Tkinter 2.7.8) the problem does not occur. When the dialog is invoked from outside the close handler, the problem does not occur. This bug is causing a downstream issue in the "quicksafe" system (https://github.com/p-e-w/quicksafe/issues/2). ---------- components: Tkinter messages: 233177 nosy: pew priority: normal severity: normal status: open title: Key presses are doubled in Tkinter dialog invoked from window close handler (OS X only) type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 18:11:18 2014 From: report at bugs.python.org (Jim Carroll) Date: Mon, 29 Dec 2014 17:11:18 +0000 Subject: [issue23129] sqlite3 COMMIT nested in SELECT returns unexpected results Message-ID: <1419873078.33.0.518262497665.issue23129@psf.upfronthosting.co.za> New submission from Jim Carroll: I reported this to the sqlite mailing list, and the comments I received suggested the problem may by the python sqlite connector issue, so I'm opening this as a bug report. I understand that performing a SELECT and nested COMMIT on the same table is not supported in sqlite, but I would have expected a COMMIT on a separate table would not be a problem. Some test code in python however reveals that performing the COMMIT disrupts the SELECT statement, and causes duplicate data to be returned. If this is not a supported operation, would you mind pointing me to the docs so I can understand it better? Example #!/usr/bin/env python import sqlite3 as sq db = sq.connect(':memory:') db.execute('CREATE TABLE tbl (col INTEGER)') db.execute('CREATE TABLE tbl2 (col INTEGER)') db.executemany('INSERT INTO tbl (col) VALUES (?)', [(0,), (1,), (2,)]) db.commit() print('count=' + str(db.execute('SELECT count(*) FROM tbl').fetchone()[0])) # Read and print the values just inserted into tbl for col in db.execute('SELECT col FROM tbl'): print(col) db.execute('INSERT INTO tbl2 VALUES (?)', col) db.commit() print('count=' + str(db.execute('SELECT count(*) FROM tbl').fetchone()[0])) The output we see is: count=3 (0,) (1,) (0,) (1,) (2,) count=3 The expected output was: count=3 (0,) (1,) (2,) count=3 Tested on Linux: sqlite version 3.7.13 sqlite3 connector version 2.6.0 # uname -a Linux hostname 3.16-0.bpo.3-amd64 #1 SMP Debian 3.16.5-1~bpo70+1 (2014-11-02) x86_64 GNU/Linux Also tested on Windows with identical results Sqlite version 3.6.21 Windows 7 Professional, 64-bit ---------- messages: 233178 nosy: jamercee priority: normal severity: normal status: open title: sqlite3 COMMIT nested in SELECT returns unexpected results type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 19:08:12 2014 From: report at bugs.python.org (R. David Murray) Date: Mon, 29 Dec 2014 18:08:12 +0000 Subject: [issue23129] sqlite3 COMMIT nested in SELECT returns unexpected results In-Reply-To: <1419873078.33.0.518262497665.issue23129@psf.upfronthosting.co.za> Message-ID: <1419876492.9.0.253732586674.issue23129@psf.upfronthosting.co.za> R. David Murray added the comment: I'd say you have a bug here of some sort, but I'm not sure if it is a doc bug or a code bug. Commit specifically does *not* reset the cursors, according to the code, but I'm not even sure what resetting a cursor means :) I've poked around the sqlite3 module's code a bit, but not enough to have an answer to this. I do note that a commit does a call to sqlite3_reset on all statements associated with the connection, and I suspect that's where the problem originates. Which probably makes it a doc bug. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 19:17:08 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 29 Dec 2014 18:17:08 +0000 Subject: [issue23127] socket.setsockopt() is still broken for multicast TTL and Loop options In-Reply-To: <1419859867.69.0.91970081595.issue23127@psf.upfronthosting.co.za> Message-ID: <1419877028.69.0.0586977358223.issue23127@psf.upfronthosting.co.za> Benjamin Peterson added the comment: "Just" use the extended signature of the setsockopt: mysocket.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, struct.pack("B", desired_ttl)) ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 19:49:51 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 29 Dec 2014 18:49:51 +0000 Subject: [issue23119] Remove unicode specialization from set objects In-Reply-To: <1419677411.19.0.303130627071.issue23119@psf.upfronthosting.co.za> Message-ID: <1419878991.04.0.746042521762.issue23119@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Timings for no_special_hash.diff: $ ~/cpython/python.exe -m timeit -r7 -s 's={"html"}' '"html" in s' 10000000 loops, best of 7: 0.0315 usec per loop $ ~/nounicode/python.exe -m timeit -r7 -s 's={"html"}' '"html" in s' 10000000 loops, best of 7: 0.0336 usec per loop $ ~/cpython/python.exe -m timeit -r7 -s 's={"html"}' '"html" in s' 10000000 loops, best of 7: 0.0316 usec per loop $ ~/nounicode/python.exe -m timeit -r7 -s 's={"html"}' '"html" in s' 10000000 loops, best of 7: 0.0336 usec per loop $ ~/cpython/python.exe -m timeit -r7 -s 's={1}' '1 in s' 10000000 loops, best of 7: 0.0331 usec per loop $ ~/nounicode/python.exe -m timeit -r7 -s 's={1}' '1 in s' 10000000 loops, best of 7: 0.0328 usec per loop $ ~/cpython/python.exe -m timeit -r7 -s 's={1}' '1 in s' 10000000 loops, best of 7: 0.0332 usec per loop $ ~/nounicode/python.exe -m timeit -r7 -s 's={1}' '1 in s' 10000000 loops, best of 7: 0.0328 usec per loop The unicode specialization in set_add, set_discard, and set_contains benefits unicode lookups by 7% but impairs other lookups by 1%. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 20:34:50 2014 From: report at bugs.python.org (Matthew Brett) Date: Mon, 29 Dec 2014 19:34:50 +0000 Subject: [issue4431] Distutils MSVC doesn't create manifest file In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za> Message-ID: <1419881690.2.0.913539859621.issue4431@psf.upfronthosting.co.za> Matthew Brett added the comment: I think this is a frank bug for Pythons that use MSVC 10+ by default (3.3, 3.4 for example). The lack of the /MANIFEST flag breaks the distutils.ccompiler.CCompiler.link_executable command - see attached setup.py example. The example gives the error "main.exe.exe.manifest : general error c1010070: Failed to load and parse the manifest. The system cannot find the file specified." We (http://nipy.org/dipy) ran into this because we were innocently using compilation of a 'main.c' file to an executable to check link flags. ---------- nosy: +Matthew.Brett Added file: http://bugs.python.org/file37556/setup.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 21:42:26 2014 From: report at bugs.python.org (Bob Ippolito) Date: Mon, 29 Dec 2014 20:42:26 +0000 Subject: [issue23123] Only READ support for Decimal in json In-Reply-To: <1419700251.42.0.619867786079.issue23123@psf.upfronthosting.co.za> Message-ID: <1419885746.33.0.207937380377.issue23123@psf.upfronthosting.co.za> Bob Ippolito added the comment: Yeah, that's the hack I was suggesting. I suppose I don't see the point of having a protocol that normalizes *almost* everything. Normalization should be all or nothing. Other options would be to define the signature at the encoded byte level with no normalization (in which case you could use any off the shelf signing), or at the value level and prescribe a specific interpretation for data types. I would've done it at the value level and prescribed that dictionaries should be key sorted, strings dealt with as UTF-8, and numbers as IEEE 754. I would make sure not to depend on the decimal conversion of numbers, and just work with the serialized bit representation in a particular endian (which you can even do efficiently in modern browser JS with Float64Array, DataView and ArrayBuffer). For JS portability it'd probably treat *all* numbers as floats in the same way, whether they had a decimal to begin with or not. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 22:19:04 2014 From: report at bugs.python.org (Anders Rundgren) Date: Mon, 29 Dec 2014 21:19:04 +0000 Subject: [issue23123] Only READ support for Decimal in json In-Reply-To: <1419700251.42.0.619867786079.issue23123@psf.upfronthosting.co.za> Message-ID: <1419887944.5.0.117426150005.issue23123@psf.upfronthosting.co.za> Anders Rundgren added the comment: Bob, I'm not sure I understand why you say that JCS requires *almost* full normalization. Using browsers you can generate fully compliant JCS objects using like 20 lines of javascript/webcrypto (here excluding base64 support). No normalization step is needed. But sure, the IETF JOSE WG has taken an entirely different approach and require JSON objects to be serialized and Base64-encoded. Then the Base64 is signed. Boring. And in conflict with complex messaging like: https://openkeystore.googlecode.com/svn/wcpp-payment-demo/trunk/docs/messages.html#UserAuthorizesTransaction Thanx anyway, I'm pretty happy with how it works now! Well, if Decimal didn't manipulate its argument I would be even happier :-) because then there wouldn't even be a hack. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 23:29:33 2014 From: report at bugs.python.org (Jim Carroll) Date: Mon, 29 Dec 2014 22:29:33 +0000 Subject: [issue23129] sqlite3 COMMIT nested in SELECT returns unexpected results In-Reply-To: <1419876492.9.0.253732586674.issue23129@psf.upfronthosting.co.za> Message-ID: <00a401d023b6$e3438f20$a9caad60$@carroll.com> Jim Carroll added the comment: Hi David, One more data point. Although I demonstrated the bug using the .execute() method associated with a connection object -- you can also create the exact problem using the .execute() method associated with cursors. This leaves no means to COMMIT inside a nested SELECT. The members of the sqlite mailing list confirmed they had no problem executing the SQL statements using C and PHP. I think this is a bug, rather than just a problem with the docs. I've been digging around the pysqlite C source but can't quite figure out what's going on yet. Jim > -----Original Message----- > From: R. David Murray [mailto:report at bugs.python.org] > Sent: Monday, December 29, 2014 1:08 PM > To: jim at carroll.com > Subject: [issue23129] sqlite3 COMMIT nested in SELECT returns > unexpected results > > > R. David Murray added the comment: > > I'd say you have a bug here of some sort, but I'm not sure if it is a > doc bug or a code bug. Commit specifically does *not* reset the > cursors, according to the code, but I'm not even sure what resetting a > cursor means :) I've poked around the sqlite3 module's code a bit, but > not enough to have an answer to this. I do note that a commit does a > call to sqlite3_reset on all statements associated with the connection, > and I suspect that's where the problem originates. Which probably > makes it a doc bug. > > ---------- > nosy: +r.david.murray > > _______________________________________ > Python tracker > > _______________________________________ ---------- title: sqlite3 COMMIT nested in SELECT returns unexpected results -> sqlite3 COMMIT nested in SELECT returns unexpected results _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Dec 29 23:35:42 2014 From: report at bugs.python.org (Ned Deily) Date: Mon, 29 Dec 2014 22:35:42 +0000 Subject: [issue23128] Key presses are doubled in Tkinter dialog invoked from window close handler (OS X only) In-Reply-To: <1419870862.78.0.0503102610416.issue23128@psf.upfronthosting.co.za> Message-ID: <1419892542.36.0.455293321231.issue23128@psf.upfronthosting.co.za> Ned Deily added the comment: By default Python, do you mean the Apple supplied Python in /usr/bin? If so, it uses an old Apple supplied Tk 8.5. Can you reproduce the problem with the current python.org 2.7.9 with the current ActiveState Tk 8.5 installed? ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 00:20:23 2014 From: report at bugs.python.org (Anders Rundgren) Date: Mon, 29 Dec 2014 23:20:23 +0000 Subject: [issue23123] Only READ support for Decimal in json In-Reply-To: <1419700251.42.0.619867786079.issue23123@psf.upfronthosting.co.za> Message-ID: <1419895223.57.0.191754083298.issue23123@psf.upfronthosting.co.za> Anders Rundgren added the comment: The current JCS validator is only 150 lines and does both RSA and EC signatures: https://code.google.com/p/openkeystore/source/browse/python/trunk/src/org/webpki/json/JCSValidator.py My Java-version is much more advanced but this is quite useful anyway ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 01:19:27 2014 From: report at bugs.python.org (Ethan Furman) Date: Tue, 30 Dec 2014 00:19:27 +0000 Subject: [issue23123] Only READ support for Decimal in json In-Reply-To: <1419700251.42.0.619867786079.issue23123@psf.upfronthosting.co.za> Message-ID: <1419898767.57.0.953315982194.issue23123@psf.upfronthosting.co.za> Ethan Furman added the comment: Raymond Hettinger added the comment: ----------------------------------- > This bug report isn't a JSON spec issue; rather, it is about how the JSON module API can > support (or inhibit) valid use cases. > > AFAICT, the patch to make the API better support enums had the side-effect of inhibiting > the APIs ability to support number objects that want to control their output via __str__ > or __repr__. This seems to block-off decimal support and support for controlling displayed > precision. > > I think the Enum patch is suspect and could be considered a regression. That said, we > could simply add direct support for decimals and leave the enum patch in-place (though it > still impairs a user's ability to control the displayed precision). The enum patch is in issue18264 if anyone wants to read the discussion. I am not a regular json user, but my impression is the format is pretty basic, and we would be overloading it to try and keep numbers with three decimal places as Decimal, and anything else as float. Isn't json's main purpose to support data exchange between different programs of different languages? Not between different Python programs? ---------- nosy: +barry, eli.bendersky, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 02:56:34 2014 From: report at bugs.python.org (Guido Vranken) Date: Tue, 30 Dec 2014 01:56:34 +0000 Subject: [issue23130] Tools/scripts/ftpmirror.py allows overwriting arbitrary files on filesystem Message-ID: <1419904594.24.0.782191401639.issue23130@psf.upfronthosting.co.za> New submission from Guido Vranken: Tools/scripts/ftpmirror.py does not guard against arbitrary path constructions, and, given a connection to a malicious FTP server (or a man in the middle attack), it is possible that any file on the client's filesystem gets overwritten. Ie,. if we suppose that ftpmirror.py is run from a "base directory" /home/xxx/yyy, file creations can occur outside this base directory, such as in /tmp, /etc, /var, just to give some examples. I've constructed a partial proof of concept FTP server that demonstrates directory and file creation outside the base directory (the directory the client script was launched from). I understand that most of the files in Tools/scripts/ are legacy applications that have long been deprecated. However, if the maintainers think these applications should be safe nonetheless, I'll be happy to construct and submit a patch that will remediate this issue. Guido Vranken Intelworks ---------- components: Demos and Tools messages: 233189 nosy: Guido priority: normal severity: normal status: open title: Tools/scripts/ftpmirror.py allows overwriting arbitrary files on filesystem type: security 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 Tue Dec 30 04:07:23 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 30 Dec 2014 03:07:23 +0000 Subject: [issue23119] Remove unicode specialization from set objects In-Reply-To: <1419677411.19.0.303130627071.issue23119@psf.upfronthosting.co.za> Message-ID: <1419908843.71.0.50641057887.issue23119@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file37557/measure_build_set.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 04:08:13 2014 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 30 Dec 2014 03:08:13 +0000 Subject: [issue23119] Remove unicode specialization from set objects In-Reply-To: <1419677411.19.0.303130627071.issue23119@psf.upfronthosting.co.za> Message-ID: <1419908893.58.0.0265783649138.issue23119@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file37558/build_set_timings.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 05:21:10 2014 From: report at bugs.python.org (Rosa Maria) Date: Tue, 30 Dec 2014 04:21:10 +0000 Subject: [issue23131] saving to file add inexistance characters Message-ID: <1419913270.54.0.105314148927.issue23131@psf.upfronthosting.co.za> New submission from Rosa Maria: I make an xml extractor for mexican internet invoices; the extraction is correct, but when save to csv, some numbers has additional numbers that does not exist, for example 5010.000000 is saved as 5010.0000002. As you can see in the print function at line 155. The problem is in Python 3.4.2 in machines with windows xp, windows 7 and windows 8 It is an small error, but this data is used for Accounting. Thanks in advance and best regards. Rosa Maria ---------- components: IO files: Python_Send.7z messages: 233190 nosy: Gravitania priority: normal severity: normal status: open title: saving to file add inexistance characters type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file37559/Python_Send.7z _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 06:43:19 2014 From: report at bugs.python.org (Anders Rundgren) Date: Tue, 30 Dec 2014 05:43:19 +0000 Subject: [issue23123] Only READ support for Decimal in json In-Reply-To: <1419700251.42.0.619867786079.issue23123@psf.upfronthosting.co.za> Message-ID: <1419918199.54.0.527142130319.issue23123@psf.upfronthosting.co.za> Anders Rundgren added the comment: Ethan Furman added the comment: > I am not a regular json user, but my impression is the format is > pretty basic, and we would be overloading it to try and keep numbers > with three decimal places as Decimal, and anything else as float. > Isn't json's main purpose to support data exchange between different > programs of different languages? Not between different Python > programs? Right, unfortunately the need to support non-native data types like big decimals, dates and blobs have lead to a certain amount of confusion and innovation among JSON tool designers. I (FWIW) do actually NOT want to extend a single bit from the RFC, I just want serializing to be "non-invasive". If the parse_float option stays "as is" it seems that both the people who want big (non-standard) numbers and I who want somewhat non-standard serialization would be happy. I.e. a documentation snippet would be sufficient as far as I can tell. Serialization order of objects is apparently a hot topic https://code.google.com/p/v8/issues/detail?id=164 but Python has no problem with that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 06:59:06 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 30 Dec 2014 05:59:06 +0000 Subject: [issue23131] saving to file add inexistance characters In-Reply-To: <1419913270.54.0.105314148927.issue23131@psf.upfronthosting.co.za> Message-ID: <1419919146.81.0.833536093696.issue23131@psf.upfronthosting.co.za> Benjamin Peterson added the comment: That's because line 153 prints extra numbers at the end of the total. ---------- nosy: +benjamin.peterson resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 09:28:01 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 30 Dec 2014 08:28:01 +0000 Subject: [issue23123] Only READ support for Decimal in json In-Reply-To: <1419700251.42.0.619867786079.issue23123@psf.upfronthosting.co.za> Message-ID: <1419928081.8.0.85605079683.issue23123@psf.upfronthosting.co.za> Antoine Pitrou added the comment: """To cope with this potential problem, compliant parsers must preserve the original textual representation of properties internally in order to support JCS normalization requirements""" That sounds ridiculous. Did someone try to reason the "IETF guys"? :) ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 09:32:34 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 30 Dec 2014 08:32:34 +0000 Subject: [issue22166] test_codecs leaks references In-Reply-To: <1407444567.64.0.0425446064781.issue22166@psf.upfronthosting.co.za> Message-ID: <1419928354.05.0.795201803285.issue22166@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: resolved -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 09:45:17 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 30 Dec 2014 08:45:17 +0000 Subject: [issue23103] Reduce memory usage for ipaddress object instances In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> Message-ID: <1419929117.92.0.965420137006.issue23103@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > I believe you need to add a bunch of __slots__ = () to various base classes in the module, even though they lack member variables. Done. Here is updated patch. I don't think that IP addresses need weak references more than base types as integers or strings. Caching can be implemented without weak references (some caching already is used for networks), and I afraid that supporting weak references list will spent more memory than saved with caching. ---------- Added file: http://bugs.python.org/file37560/ipaddress_lightweight_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 10:16:22 2014 From: report at bugs.python.org (Anders Rundgren) Date: Tue, 30 Dec 2014 09:16:22 +0000 Subject: [issue23123] Only READ support for Decimal in json In-Reply-To: <1419700251.42.0.619867786079.issue23123@psf.upfronthosting.co.za> Message-ID: <1419930982.88.0.898521634566.issue23123@psf.upfronthosting.co.za> Anders Rundgren added the comment: > Antoine Pitrou added the comment: > > "To cope with this potential problem, compliant parsers must preserve the original textual representation of properties internally in order to support JCS normalization requirements" > > That sounds ridiculous. Did someone try to reason the "IETF guys"?:) The alternative is either doing what Bob suggested which is almost the same as writing a new parser or take the IETF route and shroud the message payload in base64. So all solutions are "by definition" baaaaaaaaaaaaaaaad :-) FWIW my super-bad solution has the following compatibility issues: - Whitespace: None, all parsers can "stringify", right? - Escaping: None, all parsers MUST do it to follow the JSON spec. - Property order: A problem in some parsers. If you take a look on stackoverflow lots of folks request that insertion/reader order should be honored since computers <> humans. Fixed in Python. Works in browsers as well. - Floating point: an almost useless JSON feature anyway, it doesn't work for crypto-numbers or money. It is "only" a validation problem though. Now fixed in Python. http://www.ietf.org/mail-archive/web/acme/current/msg00200.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 10:22:09 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 30 Dec 2014 09:22:09 +0000 Subject: [issue23132] Faster total_ordering Message-ID: <1419931329.13.0.970719266671.issue23132@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch makes comparation method generated by the total_ordering decorator faster up to 20%. Benchmark results: Unpatched Patched a < b 2.46 2.45 b < a 2.48 2.49 a >= b 4.86 4.16 b >= a 5.1 4.16 a <= b 4.93 4.15 b <= a 7.31 5.98 a > b 5.25 4.38 b > a 8.11 7.04 It also adds few additional attributes to generated methods. ---------- components: Library (Lib) files: total_ordering_faster.patch keywords: patch messages: 233196 nosy: ncoghlan, rhettinger, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Faster total_ordering type: performance versions: Python 3.5 Added file: http://bugs.python.org/file37561/total_ordering_faster.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 10:22:58 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 30 Dec 2014 09:22:58 +0000 Subject: [issue23132] Faster total_ordering In-Reply-To: <1419931329.13.0.970719266671.issue23132@psf.upfronthosting.co.za> Message-ID: <1419931378.57.0.292983433216.issue23132@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file37562/total_ordering_bench.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 10:34:24 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 30 Dec 2014 09:34:24 +0000 Subject: [issue23094] Unpickler failing with PicklingError at frame end on readline due to a broken comparison In-Reply-To: <1419117872.02.0.125928182025.issue23094@psf.upfronthosting.co.za> Message-ID: <1419932064.14.0.10597325522.issue23094@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +needs review stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 10:35:40 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 30 Dec 2014 09:35:40 +0000 Subject: [issue23103] Reduce memory usage for ipaddress object instances In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> Message-ID: <1419932140.21.0.284882734062.issue23103@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I don't think that IP addresses need weak references more than base types as integers or strings. People may already be taking weak references, so it's a matter of compatibility. (and weakrefs can actually help implement an interning scheme as proposed here) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 10:39:25 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 30 Dec 2014 09:39:25 +0000 Subject: [issue23123] Only READ support for Decimal in json In-Reply-To: <1419700251.42.0.619867786079.issue23123@psf.upfronthosting.co.za> Message-ID: <1419932365.65.0.430069892649.issue23123@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I won't claim to know/understand the specifics, but "message payload in base64" actually sounds reasonable to me, if far from optimal (both from readibility and space overhead POV) :-). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 10:47:17 2014 From: report at bugs.python.org (Anders Rundgren) Date: Tue, 30 Dec 2014 09:47:17 +0000 Subject: [issue23123] Only READ support for Decimal in json In-Reply-To: <1419700251.42.0.619867786079.issue23123@psf.upfronthosting.co.za> Message-ID: <1419932837.39.0.770076988094.issue23123@psf.upfronthosting.co.za> Anders Rundgren added the comment: > Antoine Pitrou added the comment: > > I won't claim to know/understand the specifics, but "message payload in base64" actually sounds reasonable to me, if far from optimal (both from readibility and space overhead POV) :-). It is indeed a working solution. I do though think that communities that previously used XML would accept base64-encoded messages. It becomes really messy when applied to counter-signed messages like the following: { "@context": "http://xmlns.webpki.org/wcpp-payment-demo", "@qualifier": "AuthData", "paymentRequest": { "commonName": "Demo Merchant", "amount": 8600550, "currency": "USD", "referenceId": "#1000000", "dateTime": "2014-12-18T13:39:35Z", "signature": { "algorithm": "RS256", "signerCertificate": { "issuer": "CN=Merchant Network Sub CA5,C=DE", "serialNumber": "1413983542582", "subject": "CN=Demo Merchant,2.5.4.5=#1306383936333235,C=DE" }, "certificatePath": [ "MIIDQzCCAiugAwIBAgIGAUk3_J02M...eMGlY734U3NasQfAhTUhxrdDbphEvsWTc", "MIIEPzCCAiegAwIBAgIBBTANBgkqh...gU1IyRGA7IbdHOeDB2RUpsXloU2QKfLrk" ], "value": "Ny4Qe6FQhd5_qcSc3xiH8Kt7tIZ9Z...9LEjC6_Rulg_G20fGxJ-wzezFpsAGbmuFQg" } }, "domainName": "merchant.com", "cardType": "SuperCard", "pan": "1618342124919252", "dateTime": "2014-12-18T13:40:59Z", "signature": { "algorithm": "RS256", "signerCertificate": { "issuer": "CN=Mybank Client Root CA1,C=US", "serialNumber": "1413983550045", "subject": "CN=The Cardholder,2.5.4.5=#13083935363733353232" }, "certificatePath": ["MIIENzCCAh-gAwIBAgIGAUk3_LpdM...IGcN1md5feo5DndNnV8D0UM-oBRkUDDFiWlhCU"], "value": "wyUcFcHmvM5ZozZKOEwOQkYic0D7M...S_HbaPGau5KfZjCaksvb5U1lYZaXxP8kAbuGPQ" } } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 10:51:29 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 30 Dec 2014 09:51:29 +0000 Subject: [issue11245] Implementation of IMAP IDLE in imaplib? In-Reply-To: <1298061371.03.0.0638918089315.issue11245@psf.upfronthosting.co.za> Message-ID: <1419933089.06.0.76166870106.issue11245@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 10:52:03 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 30 Dec 2014 09:52:03 +0000 Subject: [issue18921] In imaplib, cached capabilities may be out of date after login In-Reply-To: <1378304850.85.0.68028293284.issue18921@psf.upfronthosting.co.za> Message-ID: <1419933123.68.0.295752131142.issue18921@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 11:00:11 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 30 Dec 2014 10:00:11 +0000 Subject: [issue23103] Reduce memory usage for ipaddress object instances In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> Message-ID: <1419933611.38.0.645806172532.issue23103@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated patch preserves weak references support. ---------- Added file: http://bugs.python.org/file37563/ipaddress_lightweight_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 11:52:49 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 30 Dec 2014 10:52:49 +0000 Subject: [issue23133] Pickling of ipaddress classes Message-ID: <1419936769.64.0.614386046628.issue23133@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Currently ipaddress classes support pickling, but the pickling is not efficient and is implementation depened. Proposed patch makes pickling more compact and implementation agnostic. ---------- components: Library (Lib) files: ipaddress_pickle.patch keywords: patch messages: 233201 nosy: ncoghlan, pmoody, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Pickling of ipaddress classes type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file37564/ipaddress_pickle.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 11:56:39 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 30 Dec 2014 10:56:39 +0000 Subject: [issue23103] Reduce memory usage for ipaddress object instances In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za> Message-ID: <1419936999.81.0.623897470706.issue23103@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: As far as adding __slots__ breaks pickling with protocols < 2, issue23133 can be considered as a dependency. ---------- dependencies: +Pickling of ipaddress classes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 12:50:39 2014 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 30 Dec 2014 11:50:39 +0000 Subject: [issue22939] integer overflow in iterator object In-Reply-To: <1416912993.1.0.671503723984.issue22939@psf.upfronthosting.co.za> Message-ID: <1419940239.91.0.171489673109.issue22939@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Is it necessary to raise when it_index is PY_SSIZE_T_MAX? An alternative is to set it_index to -1 when there would be overflow and raise an exception on the next call to next(). That way a virtual sequence with PY_SSIZE_T_MAX-1 items would still work (instead of failing unexpectedly). ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 13:19:43 2014 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 30 Dec 2014 12:19:43 +0000 Subject: [issue11245] Implementation of IMAP IDLE in imaplib? In-Reply-To: <1298061371.03.0.0638918089315.issue11245@psf.upfronthosting.co.za> Message-ID: <1419941983.79.0.563483404994.issue11245@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: -terry.reedy versions: +Python 3.4 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 14:03:13 2014 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 30 Dec 2014 13:03:13 +0000 Subject: [issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch In-Reply-To: <1265062373.01.0.461114831555.issue7833@psf.upfronthosting.co.za> Message-ID: <1419944593.18.0.750595202509.issue7833@psf.upfronthosting.co.za> Mark Lawrence added the comment: This is referenced from #4431 which has been closed for over six years but keeps getting comments. ---------- nosy: +BreamoreBoy, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 14:05:45 2014 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 30 Dec 2014 13:05:45 +0000 Subject: [issue4431] Distutils MSVC doesn't create manifest file In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za> Message-ID: <1419944745.86.0.243638340212.issue4431@psf.upfronthosting.co.za> Mark Lawrence added the comment: Should this issue be reopened or not? ---------- components: +Windows nosy: +dstufft, steve.dower, tim.golden, zach.ware versions: +Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 15:24:32 2014 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 30 Dec 2014 14:24:32 +0000 Subject: [issue19980] Improve help('non-topic') response In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za> Message-ID: <1419949472.42.0.0665702086341.issue19980@psf.upfronthosting.co.za> Mark Lawrence added the comment: I screwed up, sorry folks. If the latest patch isn't correct I give up as it's three strikes and I'm out :( ---------- Added file: http://bugs.python.org/file37565/issue19880v3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 16:40:28 2014 From: report at bugs.python.org (Philipp Emanuel Weidmann) Date: Tue, 30 Dec 2014 15:40:28 +0000 Subject: [issue23128] Key presses are doubled in Tkinter dialog invoked from window close handler (OS X only) In-Reply-To: <1419870862.78.0.0503102610416.issue23128@psf.upfronthosting.co.za> Message-ID: <1419954028.35.0.274510461522.issue23128@psf.upfronthosting.co.za> Philipp Emanuel Weidmann added the comment: I upgraded to Python 2.7.9 and ActiveTcl 8.5.17.0 as suggested. I confirmed that this is the Tk version actually used by looking at Python's About dialog. The problem persists. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 16:46:22 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 30 Dec 2014 15:46:22 +0000 Subject: [issue23129] sqlite3 COMMIT nested in SELECT returns unexpected results In-Reply-To: <1419873078.33.0.518262497665.issue23129@psf.upfronthosting.co.za> Message-ID: <1419954382.75.0.420420461002.issue23129@psf.upfronthosting.co.za> R. David Murray added the comment: (Please trim the original message when replying to a tracker issue.) When I said, "that probably means it's a doc issue", I meant that, even if it is a bug, for backward compatibility reasons we'd have to just document the behavior. Fixing the bug would then be a new feature (new keyword to change the behavior or some such). (ie: the fix to a design bug is a feature :) Now, if it turns out that the bug lies elsewhere, or that changing the current statement-reset behavior wouldn't actually change the meaning of anyone's program if we changed it, then we could fix it as a bug. But we'll need to understand the bug in detail before we can make that determination. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 16:51:10 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 30 Dec 2014 15:51:10 +0000 Subject: [issue23130] Tools/scripts/ftpmirror.py allows overwriting arbitrary files on filesystem In-Reply-To: <1419904594.24.0.782191401639.issue23130@psf.upfronthosting.co.za> Message-ID: <1419954670.06.0.484659271989.issue23130@psf.upfronthosting.co.za> R. David Murray added the comment: I would guess that the most future-proof response to this would be to delete the script. If we do keep it, it should definitely be fixed. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 17:02:02 2014 From: report at bugs.python.org (Jim Carroll) Date: Tue, 30 Dec 2014 16:02:02 +0000 Subject: [issue23129] sqlite3 COMMIT nested in SELECT returns unexpected results In-Reply-To: <1419873078.33.0.518262497665.issue23129@psf.upfronthosting.co.za> Message-ID: <002401d02449$f140c230$d3c24690$@carroll.com> Jim Carroll added the comment: Completely understood. I recently found a workaround. Setting isolation_level to None seems to mitigate the issue, ie: db = sq.connect(':memory:', isolation_level=None) I'm hoping to put some time in scrutinizing the c-api code later this week (as SQLite bugs directly affect projects we work on) to see if we can get to the bottom of the issue. ---------- title: sqlite3 COMMIT nested in SELECT returns unexpected results -> sqlite3 COMMIT nested in SELECT returns unexpected results _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 17:10:03 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 30 Dec 2014 16:10:03 +0000 Subject: [issue23129] sqlite3 COMMIT nested in SELECT returns unexpected results In-Reply-To: <1419873078.33.0.518262497665.issue23129@psf.upfronthosting.co.za> Message-ID: <1419955803.48.0.220583371246.issue23129@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, then I suspect you are getting hit by the 'automatic transaction' feature of the DB2 API. So it is probably not the commit, but the subsequent implicit 'begin transaction' that is causing the problem. The trick then is to figure out why that affects the existing select cursor. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 17:10:15 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Dec 2014 16:10:15 +0000 Subject: [issue23130] Tools/scripts/ftpmirror.py allows overwriting arbitrary files on filesystem In-Reply-To: <1419904594.24.0.782191401639.issue23130@psf.upfronthosting.co.za> Message-ID: <20141230160953.125161.63791@psf.io> Roundup Robot added the comment: New changeset 8f92ab37dd3a by Benjamin Peterson in branch '2.7': delete old ftpmirror script, which now has security bugs (closes #23130) https://hg.python.org/cpython/rev/8f92ab37dd3a New changeset 223d0927e27d by Benjamin Peterson in branch '3.2': delete old ftpmirror script, which now has security bugs (closes #23130) https://hg.python.org/cpython/rev/223d0927e27d New changeset e15d93926e47 by Benjamin Peterson in branch '3.3': merge 3.2 (#23130) https://hg.python.org/cpython/rev/e15d93926e47 New changeset 483746c32296 by Benjamin Peterson in branch '3.4': merge 3.3 (#23130) https://hg.python.org/cpython/rev/483746c32296 New changeset 4b64d300a67a by Benjamin Peterson in branch 'default': merge 3.4 (#23130) https://hg.python.org/cpython/rev/4b64d300a67a ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 19:12:18 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 30 Dec 2014 18:12:18 +0000 Subject: [issue23111] ftplib.FTP_TLS's default constructor does not work with TLSv1.1 or TLSv1.2 In-Reply-To: <1419457507.62.0.0499182915126.issue23111@psf.upfronthosting.co.za> Message-ID: <1419963138.08.0.147577678613.issue23111@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: ssl_version is a class attribute so you can simply set that before instantiating FTP_TLS class: >>> import ftplib >>> ftplib.FTP_TLS.ssl_version = ... >>> client = ftplib.FTP_TLS(...) >>> ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 19:04:02 2014 From: report at bugs.python.org (Tomasz Ryczkowski) Date: Tue, 30 Dec 2014 18:04:02 +0000 Subject: [issue23134] datetime.strptime at the turn of the year Message-ID: <1419962642.25.0.70032949175.issue23134@psf.upfronthosting.co.za> New submission from Tomasz Ryczkowski: I've found wrong behaviour datetime.strptim function at the turn of the year. I've created datetime object base on the week number (%W), year (%Y) and day of week (%w). The date for Tuesday in the first week in 2015 is wrong: >>> from datetime import datetime >>> datetime.strptime('%s %s %s' % (0, 2015, 1), '%W %Y %w').date() datetime.date(2014, 12, 29) # OK >>> datetime.strptime('%s %s %s' % (0, 2015, 2), '%W %Y %w').date() datetime.date(2015, 1, 1) # WRONG !!! >>> datetime.strptime('%s %s %s' % (0, 2015, 3), '%W %Y %w').date() datetime.date(2014, 12, 31) # OK >>> datetime.strptime('%s %s %s' % (0, 2015, 4), '%W %Y %w').date() datetime.date(2015, 1, 1) # OK >>> datetime.strptime('%s %s %s' % (0, 2015, 5), '%W %Y %w').date() datetime.date(2015, 1, 2) # OK >>> datetime.strptime('%s %s %s' % (0, 2015, 6), '%W %Y %w').date() datetime.date(2015, 1, 3) # OK >>> datetime.strptime('%s %s %s' % (0, 2015, 0), '%W %Y %w').date() datetime.date(2015, 1, 4) # OK The same error exists in another years. Link to my post about this on stackoverflow: http://stackoverflow.com/questions/27708833/why-does-datetime-strptime-get-an-incorrect-date-for-tuesday-in-the-week-0-of ---------- messages: 233213 nosy: torm priority: normal severity: normal status: open title: datetime.strptime at the turn of the year type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 19:45:17 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 30 Dec 2014 18:45:17 +0000 Subject: [issue23134] datetime.strptime at the turn of the year In-Reply-To: <1419962642.25.0.70032949175.issue23134@psf.upfronthosting.co.za> Message-ID: <1419965117.01.0.704804987935.issue23134@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In C the strptime function doesn't return valid data if an input is invalid. $ ./strptimetest "0 2015 1" "%W %Y %w" 2015-00--2 00:00:00 $ ./strptimetest "0 2015 2" "%W %Y %w" 2015-00--1 00:00:00 $ ./strptimetest "0 2015 3" "%W %Y %w" 2015-00-00 00:00:00 $ ./strptimetest "0 2015 4" "%W %Y %w" 2015-01-01 00:00:00 $ ./strptimetest "0 2015 5" "%W %Y %w" 2015-01-02 00:00:00 $ ./strptimetest "0 2015 6" "%W %Y %w" 2015-01-03 00:00:00 $ ./strptimetest "0 2015 7" "%W %Y %w" 2015-01-00 00:00:00 So this behavior likely is not a bug and doesn't need to be fixed in maintained releases. But it would be good to make strptime() more consistant and either extend it to support week and weekday numbers out of current valid range, or raise an exception. ---------- nosy: +belopolsky, serhiy.storchaka versions: +Python 3.5 Added file: http://bugs.python.org/file37566/strptimetest.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 20:10:31 2014 From: report at bugs.python.org (c2621566) Date: Tue, 30 Dec 2014 19:10:31 +0000 Subject: [issue23135] import searchpaths as arguments Message-ID: <1419966631.84.0.639997296504.issue23135@psf.upfronthosting.co.za> New submission from c2621566: This patch allows specifying import searchpaths as `-p path` arguments to the interpreter, without touching environment variables. Avoiding environment variables simplifies a script of mine and is a portable way of swapping module implementation without touching the importing script. e.g. # python -p ~/.bin/customlib -p ~/.bin/other script.py is equivalent to # PYTHONPATH=~/.bin/customlib:~/.bin/other:$PYTHONPATH python script.py similarly to # ghci -i.bin/customlib:.bin/other foo.hs It is implemented by prepending the arguments to sys.path in Py_Main just after Py_Initialize is called. ---------- components: Interpreter Core files: main.c.searchpatharg1.diff keywords: patch messages: 233216 nosy: c2621566 priority: normal severity: normal status: open title: import searchpaths as arguments type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file37567/main.c.searchpatharg1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 20:34:53 2014 From: report at bugs.python.org (varde) Date: Tue, 30 Dec 2014 19:34:53 +0000 Subject: [issue23111] ftplib.FTP_TLS's default constructor does not work with TLSv1.1 or TLSv1.2 In-Reply-To: <1419457507.62.0.0499182915126.issue23111@psf.upfronthosting.co.za> Message-ID: <1419968093.26.0.952479837765.issue23111@psf.upfronthosting.co.za> varde added the comment: I know that, but it seems pretty unusual. And I would never had guessed from the documentation, I had to read the source. My point is that it should be easier to just connect to a TLSv1.2 server: the documentation should mention the fact that ssl_version is a class attribute or it should be set to something more compatible like ssl.PROTOCOL_SSLv23. I'm not sure about the implications of the latter. I'm not saying that this is a serious bug, but I'm used to Python providing us with something that works (more or less) out of the box. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 21:20:44 2014 From: report at bugs.python.org (R. David Murray) Date: Tue, 30 Dec 2014 20:20:44 +0000 Subject: [issue23135] import searchpaths as arguments In-Reply-To: <1419966631.84.0.639997296504.issue23135@psf.upfronthosting.co.za> Message-ID: <1419970844.14.0.211014526593.issue23135@psf.upfronthosting.co.za> R. David Murray added the comment: Thank you for the suggestion and patch, but we have a general policy of not adding unnecessary command line options, so I don't know that it will be accepted. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 22:04:37 2014 From: report at bugs.python.org (Jim Carroll) Date: Tue, 30 Dec 2014 21:04:37 +0000 Subject: [issue23136] BUG in how _strptime() handles week 0 Message-ID: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za> New submission from Jim Carroll: The following bit of code demonstrates a bug in how _strptime handles week 0. The bug is an edge condition that specifically affects how it handles two days before the first day of the new year >>> for i in range(7): ... datetime.strptime('%s %s %s' % (0, 2015, i), '%W %Y %w').date() ... datetime.date(2015, 1, 4) datetime.date(2014, 12, 29) datetime.date(2015, 1, 1) # <-- ERROR: should be '2014, 12, 30' datetime.date(2014, 12, 31) datetime.date(2015, 1, 1) datetime.date(2015, 1, 2) datetime.date(2015, 1, 3) The issue stems from the fact that calls to _calc_julian_from_U_or_W() can return a -1, which under normal circumstances is invalid. The strptime() function tests and corrects when julian values are -1...but it should not do this when the week_of_year is zero. The fact that it tests for ONLY -1 is why we see the problem in 2015. The error condition only exists when the first day of the year is exactly two days ahead of the date being tested for. Patch is attached ---------- components: Library (Lib) files: patch.txt messages: 233219 nosy: jamercee priority: normal severity: normal status: open title: BUG in how _strptime() handles week 0 versions: Python 2.7 Added file: http://bugs.python.org/file37568/patch.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 22:09:58 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Dec 2014 21:09:58 +0000 Subject: [issue19776] Provide expanduser() on Path objects In-Reply-To: <1385409778.55.0.842571848249.issue19776@psf.upfronthosting.co.za> Message-ID: <20141230210948.71911.74108@psf.io> Roundup Robot added the comment: New changeset bee697b0fd18 by Antoine Pitrou in branch 'default': Issue #19776: Add a expanduser() method on Path objects. https://hg.python.org/cpython/rev/bee697b0fd18 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 22:10:15 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 30 Dec 2014 21:10:15 +0000 Subject: [issue19776] Provide expanduser() on Path objects In-Reply-To: <1385409778.55.0.842571848249.issue19776@psf.upfronthosting.co.za> Message-ID: <1419973815.57.0.879582257834.issue19776@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 22:16:33 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Dec 2014 21:16:33 +0000 Subject: [issue23111] ftplib.FTP_TLS's default constructor does not work with TLSv1.1 or TLSv1.2 In-Reply-To: <1419457507.62.0.0499182915126.issue23111@psf.upfronthosting.co.za> Message-ID: <20141230211622.102383.54512@psf.io> Roundup Robot added the comment: New changeset 414c450e8406 by Benjamin Peterson in branch '3.4': make PROTOCOL_SSLv23 the default protocol version for ftplib (closes #23111) https://hg.python.org/cpython/rev/414c450e8406 New changeset 33603f7949c5 by Benjamin Peterson in branch 'default': merge 3.4 (#23111) https://hg.python.org/cpython/rev/33603f7949c5 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Dec 30 22:17:23 2014 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Dec 2014 21:17:23 +0000 Subject: [issue23111] ftplib.FTP_TLS's default constructor does not work with TLSv1.1 or TLSv1.2 In-Reply-To: <1419457507.62.0.0499182915126.issue23111@psf.upfronthosting.co.za> Message-ID: <20141230211716.120063.35745@psf.io> Roundup Robot added the comment: New changeset 29689050ec78 by Benjamin Peterson in branch '3.4': update docs for #23111 https://hg.python.org/cpython/rev/29689050ec78 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 00:23:04 2014 From: report at bugs.python.org (Bertrand Janin) Date: Tue, 30 Dec 2014 23:23:04 +0000 Subject: [issue23127] socket.setsockopt() is still broken for multicast TTL and Loop options In-Reply-To: <1419859867.69.0.91970081595.issue23127@psf.upfronthosting.co.za> Message-ID: <1419981784.19.0.0183353479898.issue23127@psf.upfronthosting.co.za> Bertrand Janin added the comment: I don't really need it in my own software, I was trying to use https://github.com/SoCo/SoCo/ and couldn't get it working on OpenBSD. I'm sure this is a portability problem on a number of library using Multicast. Do you see something wrong with the patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 01:25:06 2014 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 31 Dec 2014 00:25:06 +0000 Subject: [issue23127] socket.setsockopt() is still broken for multicast TTL and Loop options In-Reply-To: <1419859867.69.0.91970081595.issue23127@psf.upfronthosting.co.za> Message-ID: <1419985506.09.0.937032832435.issue23127@psf.upfronthosting.co.za> Benjamin Peterson added the comment: We don't really have a precedent for adjusting the size automatically when integers are passed to setsockopt. Anyway, your patch will be wrong for big-endian systems. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 02:54:10 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 31 Dec 2014 01:54:10 +0000 Subject: [issue23077] PEP 1: Allow Provisional status for PEPs In-Reply-To: <1418861338.72.0.949069550217.issue23077@psf.upfronthosting.co.za> Message-ID: <1419990850.0.0.0427292711832.issue23077@psf.upfronthosting.co.za> Nick Coghlan added the comment: As we've started working through the post-release PEP 440 changes, I think this is definitely worthy of a separate PEP. I'll take the opportunity to pitch some other changes as well, like separating out the interoperability standards from the informational PEPs like the CPython release process guide, and add new metadata headers to indicate when the reference implementation of a standard is provided by a project other than CPython. We may decide the extra complexity isn't worth it, but after wrangling PEP 440 through to completion under the delegation of authority to distutils-sig, I'd at least like to have the discussion about what we think represents a "necessary, but sufficient" level of process change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 06:06:29 2014 From: report at bugs.python.org (Christopher Foo) Date: Wed, 31 Dec 2014 05:06:29 +0000 Subject: [issue23138] cookiejar parses cookie value as int with empty name-value pair and Expires Message-ID: <1420002389.34.0.647467472383.issue23138@psf.upfronthosting.co.za> New submission from Christopher Foo: Something like "Set-Cookie: ; Expires=Thu, 01 Jan 1970 00:00:10 GMT" causes the resulting cookie.value to be parsed as an int. I expected either str or None as described in the documentation. Example evil server: try: import http.server as http_server except ImportError: import BaseHTTPServer as http_server class MyHandler(http_server.BaseHTTPRequestHandler): def do_GET(self): self.send_response(200) self.send_header('Set-Cookie', '; Expires=Thu, 01 Jan 1970 00:00:10 GMT') self.send_header('Set-Cookie', 'good=123.45600') self.end_headers() def main(): server = http_server.HTTPServer(('127.0.0.1', 8000), MyHandler) server.serve_forever() if __name__ == '__main__': main() Example innocent client: try: import http.cookiejar as http_cookiejar except ImportError: import cookielib as http_cookiejar try: import urllib.request as urllib_request except ImportError: import urllib2 as urllib_request def main(): cj = http_cookiejar.CookieJar() opener = urllib_request.build_opener(urllib_request.HTTPCookieProcessor(cj)) r = opener.open("http://127.0.0.1:8000/") print(cj._cookies) if __name__ == '__main__': main() The resulting output is: {'127.0.0.1': {'/': {'expires': Cookie(version=0, name='expires', value=10.0, port=None, port_specified=False, domain='127.0.0.1', domain_specified=False, domain_initial_dot=False, path='/', path_specified=False, secure=False, expires=None, discard=True, comment=None, comment_url=None, rest={}, rfc2109=False), 'good': Cookie(version=0, name='good', value='123.45600', port=None, port_specified=False, domain='127.0.0.1', domain_specified=False, domain_initial_dot=False, path='/', path_specified=False, secure=False, expires=None, discard=True, comment=None, comment_url=None, rest={}, rfc2109=False)}}} It gives two cookies where the first one contains name='expires', value=10.0 which is unexpected. I expected that either the bad cookie is discarded or it is accepted but the value is always a str (even if it is garbage) or None. This bug was found in my custom cookie policy where I do len(cookie.value or ''). There is also a reference on StackOverflow but I believe no Python library bug report was filed: http://stackoverflow.com/q/20325571/1524507 . This was tested on Python 2.7.8, 3.2.6, 3.3.6, and 3.4.2. ---------- components: Library (Lib) messages: 233227 nosy: chfoo priority: normal severity: normal status: open title: cookiejar parses cookie value as int with empty name-value pair and Expires type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 06:55:55 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 31 Dec 2014 05:55:55 +0000 Subject: [issue23132] Faster total_ordering In-Reply-To: <1419931329.13.0.970719266671.issue23132@psf.upfronthosting.co.za> Message-ID: <1420005355.79.0.110375911416.issue23132@psf.upfronthosting.co.za> Nick Coghlan added the comment: This looks like a nice, relatively simple improvement in both speed and introspection support, so +1 from me. Something I've wondered since we changed total_ordering to handle NotImplemented correctly is whether it would be worth exposing more of the *components* of rich boolean comparison operations through the operator module. Currently it isn't possible to access the individual steps, which is why handling NotImplemented incurred such a large performance hit relative to the previous implementation that didn't worry about it (but also potentially hit RecursionError if the underlying comparison operation returned NotImplemented). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 07:39:45 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 31 Dec 2014 06:39:45 +0000 Subject: [issue23132] Faster total_ordering In-Reply-To: <1419931329.13.0.970719266671.issue23132@psf.upfronthosting.co.za> Message-ID: <1420007985.41.0.325704201077.issue23132@psf.upfronthosting.co.za> Nick Coghlan added the comment: I tweaked Serhiy's benchmark script to also include the timing relative to spelling out all four ordered comparison methods. For an unpatched debug build of trunk, I get the following: $ ../py3k/python total_ordering_relative_bench.py a < b 1.643 1.605 x0.98 b < a 1.611 1.611 x1.00 a >= b 1.599 3.539 x2.21 b >= a 1.607 3.579 x2.23 a <= b 1.600 3.677 x2.30 b <= a 1.601 5.599 x3.50 a > b 1.600 3.624 x2.26 b > a 1.612 6.465 x4.01 With Serhiy's change applied I get: $ ../py3k/python total_ordering_relative_bench.py a < b 1.599 1.602 x1.00 b < a 1.607 1.609 x1.00 a >= b 1.602 2.802 x1.75 b >= a 1.605 2.804 x1.75 a <= b 1.737 2.842 x1.64 b <= a 1.607 4.835 x3.01 a > b 1.667 2.821 x1.69 b > a 1.597 5.557 x3.48 ---------- Added file: http://bugs.python.org/file37569/total_ordering_relative_bench.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 10:00:31 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 31 Dec 2014 09:00:31 +0000 Subject: [issue23136] BUG in how _strptime() handles week 0 In-Reply-To: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za> Message-ID: <1420016431.8.0.755699973594.issue23136@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +belopolsky, lemburg stage: -> patch review versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 10:14:22 2014 From: report at bugs.python.org (Demian Brecht) Date: Wed, 31 Dec 2014 09:14:22 +0000 Subject: [issue20898] Missing 507 response description In-Reply-To: <1394637244.26.0.361164120424.issue20898@psf.upfronthosting.co.za> Message-ID: <1420017262.26.0.434720890434.issue20898@psf.upfronthosting.co.za> Demian Brecht added the comment: The patch in #21793 has been merged, resolving this issue as well. This should now be closed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 10:23:41 2014 From: report at bugs.python.org (Demian Brecht) Date: Wed, 31 Dec 2014 09:23:41 +0000 Subject: [issue23004] mock_open() should allow reading binary data In-Reply-To: <1417965857.24.0.521739131396.issue23004@psf.upfronthosting.co.za> Message-ID: <1420017821.81.0.206592731109.issue23004@psf.upfronthosting.co.za> Demian Brecht added the comment: A few more comments were left in Rietveld for you, likely hidden by spam filters. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 10:25:18 2014 From: report at bugs.python.org (Demian Brecht) Date: Wed, 31 Dec 2014 09:25:18 +0000 Subject: [issue22992] Adding a git developer's guide to Mercurial to devguide In-Reply-To: <1417651753.19.0.905189748743.issue22992@psf.upfronthosting.co.za> Message-ID: <1420017918.09.0.193088529852.issue22992@psf.upfronthosting.co.za> Demian Brecht added the comment: Ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 10:26:37 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 31 Dec 2014 09:26:37 +0000 Subject: [issue23132] Faster total_ordering In-Reply-To: <1419931329.13.0.970719266671.issue23132@psf.upfronthosting.co.za> Message-ID: <1420017997.56.0.0516851506414.issue23132@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Side effect of improving introspection is that generated unbounded methods are pickleable now. Updated patch contains a test for this. ---------- Added file: http://bugs.python.org/file37570/total_ordering_faster_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 10:29:10 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 31 Dec 2014 09:29:10 +0000 Subject: [issue20898] Missing 507 response description In-Reply-To: <1394637244.26.0.361164120424.issue20898@psf.upfronthosting.co.za> Message-ID: <1420018150.36.0.702407102343.issue20898@psf.upfronthosting.co.za> Berker Peksag added the comment: I think the documentation part of the patch is still useful. ---------- components: +Documentation -Extension Modules nosy: +berker.peksag stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 10:34:10 2014 From: report at bugs.python.org (Berker Peksag) Date: Wed, 31 Dec 2014 09:34:10 +0000 Subject: [issue15025] httplib and http.client are missing response messages for defined WEBDAV responses, e.g., UNPROCESSABLE_ENTITY (422) In-Reply-To: <1339067742.9.0.619240246861.issue15025@psf.upfronthosting.co.za> Message-ID: <1420018450.53.0.653967330846.issue15025@psf.upfronthosting.co.za> Berker Peksag added the comment: This was fixed by issue 21793. ---------- nosy: +berker.peksag resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 10:47:51 2014 From: report at bugs.python.org (Friedrich Spee von Langenfeld) Date: Wed, 31 Dec 2014 09:47:51 +0000 Subject: [issue23139] syntax diagram after EBNF description? Message-ID: <1420019271.73.0.760663743856.issue23139@psf.upfronthosting.co.za> New submission from Friedrich Spee von Langenfeld: In our full grammar specification (10th chapter of the language reference, https://docs.python.org/3/reference/grammar.html), the grammar of Python is comprehensively notated. What would you think of adding a picture with an equivalent syntax diagram (e. g. produced with the help of http://www.bottlecaps.de/rr/ui) to open a new way of understanding for readers? ---------- assignee: docs at python components: Documentation messages: 233236 nosy: Friedrich.Spee.von.Langenfeld, docs at python priority: normal severity: normal status: open title: syntax diagram after EBNF description? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 10:56:13 2014 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 31 Dec 2014 09:56:13 +0000 Subject: [issue23140] InvalidStateError on asyncio subprocess task cancelled Message-ID: <1420019773.34.0.176587493323.issue23140@psf.upfronthosting.co.za> New submission from Xavier de Gaye: The attached test_cancel.py script prints the following error: Exception in callback SubprocessStreamProtocol.process_exited() handle: source_traceback: Object created at (most recent call last): File "test_cancel.py", line 37, in loop.run_until_complete(main_task) File "Lib/asyncio/base_events.py", line 286, in run_until_complete self.run_forever() File "Lib/asyncio/base_events.py", line 258, in run_forever self._run_once() File "Lib/asyncio/base_events.py", line 1102, in _run_once handle._run() File "Lib/asyncio/events.py", line 120, in _run self._callback(*self._args) File "Lib/asyncio/base_subprocess.py", line 146, in _process_exited self._call(self._protocol.process_exited) File "Lib/asyncio/base_subprocess.py", line 130, in _call self._loop.call_soon(cb, *data) Traceback (most recent call last): File "Lib/asyncio/events.py", line 120, in _run self._callback(*self._args) File "Lib/asyncio/subprocess.py", line 99, in process_exited waiter.set_result(returncode) File "Lib/asyncio/futures.py", line 338, in set_result raise InvalidStateError('{}: {!r}'.format(self._state, self)) asyncio.futures.InvalidStateError: CANCELLED: ---------- components: asyncio files: test_cancel.py messages: 233237 nosy: giampaolo.rodola, gvanrossum, haypo, pitrou, xdegaye, yselivanov priority: normal severity: normal status: open title: InvalidStateError on asyncio subprocess task cancelled type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file37571/test_cancel.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 11:00:25 2014 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 31 Dec 2014 10:00:25 +0000 Subject: [issue23123] Only READ support for Decimal in json In-Reply-To: <1419700251.42.0.619867786079.issue23123@psf.upfronthosting.co.za> Message-ID: <1420020025.51.0.193901263587.issue23123@psf.upfronthosting.co.za> Mark Dickinson added the comment: See also #16535. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 11:04:22 2014 From: report at bugs.python.org (Martin Panter) Date: Wed, 31 Dec 2014 10:04:22 +0000 Subject: [issue23135] import searchpaths as arguments In-Reply-To: <1419966631.84.0.639997296504.issue23135@psf.upfronthosting.co.za> Message-ID: <1420020262.09.0.650966210502.issue23135@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 11:11:06 2014 From: report at bugs.python.org (Martin Panter) Date: Wed, 31 Dec 2014 10:11:06 +0000 Subject: [issue23134] datetime.strptime at the turn of the year In-Reply-To: <1419962642.25.0.70032949175.issue23134@psf.upfronthosting.co.za> Message-ID: <1420020666.1.0.772323353739.issue23134@psf.upfronthosting.co.za> Martin Panter added the comment: Issue 23136 looks like a duplicate, but has a potential patch ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 13:56:48 2014 From: report at bugs.python.org (Adam Mead) Date: Wed, 31 Dec 2014 12:56:48 +0000 Subject: [issue23141] Command line long filename not passed correctly Message-ID: <1420030608.19.0.589524689474.issue23141@psf.upfronthosting.co.za> New submission from Adam Mead: Under windows the following code does not pass the LFN to the script. Nor does any other method I've tried (getopts & argparse) test.py import sys print ('Number of arguments:', len(sys.argv), 'arguments.') print ('Argument List:', str(sys.argv)) for x in range(0, len(sys.argv)): print("->" + sys.argv[x]) ---------------------------------------- Output with quotes: H:\bin>test "test lfn.txt" Number of arguments: 3 arguments. Argument List: ['H:\\bin\\test.py', ' test', 'lfn.txt'] ->H:\bin\test.py -> test ->lfn.txt Output when doubling the quotes: H:\bin>test ""test lfn.txt"" Number of arguments: 2 arguments. Argument List: ['H:\\bin\\test.py', ' "test lfn.txt"'] ->H:\bin\test.py -> "test lfn.txt" ---------- components: Windows messages: 233240 nosy: Adam.Mead, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Command line long filename not passed correctly type: behavior versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 13:58:26 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 31 Dec 2014 12:58:26 +0000 Subject: [issue23136] BUG in how _strptime() handles week 0 In-Reply-To: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za> Message-ID: <1420030706.72.0.181327169592.issue23136@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 14:28:56 2014 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 31 Dec 2014 13:28:56 +0000 Subject: [issue23135] import searchpaths as arguments In-Reply-To: <1419966631.84.0.639997296504.issue23135@psf.upfronthosting.co.za> Message-ID: <1420032536.38.0.718310144696.issue23135@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 15:39:20 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 31 Dec 2014 14:39:20 +0000 Subject: [issue23141] Command line long filename not passed correctly In-Reply-To: <1420030608.19.0.589524689474.issue23141@psf.upfronthosting.co.za> Message-ID: <1420036760.77.0.689894528565.issue23141@psf.upfronthosting.co.za> R. David Murray added the comment: What do you mean by "does not pass the LFN to the script? Everything works fine for me with python3: C:\>test "test lfn.txt" ['C:\\test.py', 'test lfn.txt'] argparse and getopt both depend on sys.argv, by the way, so it's no surprise they didn't have different behavior. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 15:41:10 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 31 Dec 2014 14:41:10 +0000 Subject: [issue23141] Command line long filename not passed correctly In-Reply-To: <1420030608.19.0.589524689474.issue23141@psf.upfronthosting.co.za> Message-ID: <1420036870.21.0.0369874371434.issue23141@psf.upfronthosting.co.za> R. David Murray added the comment: Oh, I see, you are talking about a filename with a space in it. Sorry, my unix-centric eyes didn't see that at first. But like I said, it works fine for me, using python 3.4.1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 15:51:22 2014 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 31 Dec 2014 14:51:22 +0000 Subject: [issue23077] PEP 1: Allow Provisional status for PEPs In-Reply-To: <1419990850.0.0.0427292711832.issue23077@psf.upfronthosting.co.za> Message-ID: <20141231095109.015f2618@anarchist.wooz.org> Barry A. Warsaw added the comment: On Dec 31, 2014, at 01:54 AM, Nick Coghlan wrote: >As we've started working through the post-release PEP 440 changes, I think >this is definitely worthy of a separate PEP. I'm open to discussion and ideas, but I want to caution against spreading information about the PEP (and more largely, enhancing Python) process over too many documents. PEP 1 and the process has worked well I think because it's relatively easy to find information on the process in a concise format. I also don't think we necessarily need to cross-and-dot every I-and-T. Flexibility can be a good thing too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 16:33:48 2014 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 31 Dec 2014 15:33:48 +0000 Subject: [issue23141] Command line long filename not passed correctly In-Reply-To: <1420030608.19.0.589524689474.issue23141@psf.upfronthosting.co.za> Message-ID: <1420040028.96.0.837977051311.issue23141@psf.upfronthosting.co.za> Eric V. Smith added the comment: This works fine for me, too, using the Windows version of 3.4.2 downloaded from python.org. 2 questions: - where did you download Python? - which shell are you using? ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 16:37:22 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Wed, 31 Dec 2014 15:37:22 +0000 Subject: [issue23136] BUG in how _strptime() handles week 0 In-Reply-To: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za> Message-ID: <1420040242.6.0.549142868894.issue23136@psf.upfronthosting.co.za> Changes by Saimadhav Heblikar : ---------- nosy: +sahutd _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 16:40:01 2014 From: report at bugs.python.org (Adam Mead) Date: Wed, 31 Dec 2014 15:40:01 +0000 Subject: [issue23141] Command line long filename not passed correctly In-Reply-To: <1420030608.19.0.589524689474.issue23141@psf.upfronthosting.co.za> Message-ID: <1420040401.19.0.00140015666217.issue23141@psf.upfronthosting.co.za> Adam Mead added the comment: Hi, I think I've found the problem. After reading you message and seeing your output I went to my laptop which didn't have python installed (using portable on it) and clean installed. Using a clean install with 3.4.2 on a Win8 machine it worked fine. I suspect the issue is not so much python but the way my Win7N machine is configured and passing the command line to python. By default the Win7N machine was set to auto open in PSPad, I changed it by modifying a registry key, likely I did this incorrectly. Apologies! Adam ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 16:42:52 2014 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 31 Dec 2014 15:42:52 +0000 Subject: [issue23141] Command line long filename not passed correctly In-Reply-To: <1420030608.19.0.589524689474.issue23141@psf.upfronthosting.co.za> Message-ID: <1420040572.62.0.00243935615542.issue23141@psf.upfronthosting.co.za> Eric V. Smith added the comment: I'm glad you found it! ---------- resolution: fixed -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:13:49 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:13:49 +0000 Subject: [issue18648] FP Howto and the PEP 8 lambda guildline In-Reply-To: <1375563496.73.0.458556999556.issue18648@psf.upfronthosting.co.za> Message-ID: <1420042429.87.0.303064481631.issue18648@psf.upfronthosting.co.za> A.M. Kuchling added the comment: This section is trying to illustrate the reasoning that leads to PEP 8's conclusion, so I don't want to just replace it with a reference to PEP8. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:15:07 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:15:07 +0000 Subject: [issue18779] Misleading documentations and comments in regular expression HOWTO In-Reply-To: <1376898316.85.0.0813282739116.issue18779@psf.upfronthosting.co.za> Message-ID: <1420042507.09.0.386330616892.issue18779@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:16:14 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:16:14 +0000 Subject: [issue1671676] test_mailbox is hanging while doing gmake test on HP-UX v3 Message-ID: <1420042574.45.0.516136699235.issue1671676@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- resolution: -> wont fix status: languishing -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:18:11 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:18:11 +0000 Subject: [issue3786] _curses, _curses_panel & _multiprocessing can't be build in 2.6b3 w/ SunStudio 12 In-Reply-To: <1220608521.1.0.66106932182.issue3786@psf.upfronthosting.co.za> Message-ID: <1420042691.55.0.800945068971.issue3786@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:18:38 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:18:38 +0000 Subject: [issue433030] SRE: Atomic Grouping (?>...) is not supported Message-ID: <1420042718.71.0.636640268929.issue433030@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:18:50 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:18:50 +0000 Subject: [issue9584] fnmatch, glob: Allow curly brace expansion In-Reply-To: <1281688613.27.0.00233773234268.issue9584@psf.upfronthosting.co.za> Message-ID: <1420042730.52.0.883690486273.issue9584@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:19:00 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:19:00 +0000 Subject: [issue10590] Parameter type error for xml.sax.parseString(string, ...) In-Reply-To: <1291145861.74.0.873169501029.issue10590@psf.upfronthosting.co.za> Message-ID: <1420042740.17.0.444694248537.issue10590@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:19:09 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:19:09 +0000 Subject: [issue3367] Uninitialized value read in parsetok.c In-Reply-To: <1216153264.95.0.467111480464.issue3367@psf.upfronthosting.co.za> Message-ID: <1420042749.3.0.353209680386.issue3367@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:19:19 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:19:19 +0000 Subject: [issue1467929] %-formatting and dicts Message-ID: <1420042759.26.0.160813823852.issue1467929@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:19:30 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:19:30 +0000 Subject: [issue2202] urllib2 fails against IIS 6.0 (No support for MD5-sess auth) In-Reply-To: <1204223194.19.0.670418970441.issue2202@psf.upfronthosting.co.za> Message-ID: <1420042770.01.0.983906816713.issue2202@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:19:50 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:19:50 +0000 Subject: [issue2212] Cookie.BaseCookie has ambiguous unicode handling In-Reply-To: <1204315669.5.0.476777122389.issue2212@psf.upfronthosting.co.za> Message-ID: <1420042790.41.0.292012570337.issue2212@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:19:57 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:19:57 +0000 Subject: [issue5368] curses patch add color_set and wcolor_set , and addchstr family of functions In-Reply-To: <1235583031.0.0.493464972804.issue5368@psf.upfronthosting.co.za> Message-ID: <1420042797.93.0.965587781563.issue5368@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:20:19 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:20:19 +0000 Subject: [issue14713] PEP 414 installation hook fails with an AssertionError In-Reply-To: <1336059741.48.0.751323304263.issue14713@psf.upfronthosting.co.za> Message-ID: <1420042819.46.0.529350938763.issue14713@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:20:36 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:20:36 +0000 Subject: [issue7695] missing termios constants In-Reply-To: <1263412950.84.0.252347161386.issue7695@psf.upfronthosting.co.za> Message-ID: <1420042836.87.0.100380792097.issue7695@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:20:52 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:20:52 +0000 Subject: [issue1751519] curses - new window methods: addchstr and addchnstr Message-ID: <1420042852.54.0.188540848771.issue1751519@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:20:57 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:20:57 +0000 Subject: [issue2675] Curses terminal resize problems when Python is in interactive mode In-Reply-To: <1208965300.42.0.575050740888.issue2675@psf.upfronthosting.co.za> Message-ID: <1420042857.71.0.505828585037.issue2675@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:21:04 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:21:04 +0000 Subject: [issue1483] xml.sax.saxutils.prepare_input_source ignores character stream in InputSource In-Reply-To: <1195653795.8.0.542576278207.issue1483@psf.upfronthosting.co.za> Message-ID: <1420042864.56.0.0591261337456.issue1483@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:21:09 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:21:09 +0000 Subject: [issue1512163] mailbox (2.5b1): locking doesn't work (esp. on FreeBSD) Message-ID: <1420042869.09.0.535684762503.issue1512163@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:21:29 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:21:29 +0000 Subject: [issue14944] Setup & Usage documentation for pydoc, idle & 2to3 In-Reply-To: <1338256058.02.0.10025521772.issue14944@psf.upfronthosting.co.za> Message-ID: <1420042889.94.0.24563942768.issue14944@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:21:35 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:21:35 +0000 Subject: [issue15858] tarfile missing entries due to omitted uid/gid fields In-Reply-To: <1346701660.86.0.976031645545.issue15858@psf.upfronthosting.co.za> Message-ID: <1420042895.1.0.462510069294.issue15858@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:21:42 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:21:42 +0000 Subject: [issue9770] curses.ascii.isblank() function is broken. It confuses backspace (BS 0x08) with tab (0x09) In-Reply-To: <1283558509.74.0.494754089018.issue9770@psf.upfronthosting.co.za> Message-ID: <1420042902.32.0.198051121474.issue9770@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:21:49 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:21:49 +0000 Subject: [issue1745108] 2.5.1 curses panel segfault in new_panel on aix 5.3 Message-ID: <1420042909.25.0.556084250555.issue1745108@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:21:55 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:21:55 +0000 Subject: [issue14945] Setup & Usage documentation for selected stdlib modules In-Reply-To: <1338256259.22.0.129056676976.issue14945@psf.upfronthosting.co.za> Message-ID: <1420042915.33.0.235797425881.issue14945@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:22:09 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:22:09 +0000 Subject: [issue8502] support plurals in pygettext In-Reply-To: <1271985007.3.0.675755685137.issue8502@psf.upfronthosting.co.za> Message-ID: <1420042929.67.0.866703233167.issue8502@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:22:16 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:22:16 +0000 Subject: [issue11352] Update cgi module doc In-Reply-To: <1298895261.86.0.965235067518.issue11352@psf.upfronthosting.co.za> Message-ID: <1420042936.17.0.86301886773.issue11352@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:22:24 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:22:24 +0000 Subject: [issue1570255] redirected cookies Message-ID: <1420042944.79.0.0580129230419.issue1570255@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:22:31 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:22:31 +0000 Subject: [issue17006] Add advice on best practices for hashing secrets In-Reply-To: <1358758082.76.0.415880124971.issue17006@psf.upfronthosting.co.za> Message-ID: <1420042951.93.0.758092519117.issue17006@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:22:37 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:22:37 +0000 Subject: [issue10552] Tools/unicode/gencodec.py error In-Reply-To: <1290889753.14.0.0688566147025.issue10552@psf.upfronthosting.co.za> Message-ID: <1420042957.23.0.0174790273271.issue10552@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:23:00 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:23:00 +0000 Subject: [issue5901] missing meta-info in documentation pdf In-Reply-To: <1241246578.79.0.771794251259.issue5901@psf.upfronthosting.co.za> Message-ID: <1420042980.79.0.0240048022841.issue5901@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:23:08 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:23:08 +0000 Subject: [issue18280] Documentation is too personalized In-Reply-To: <1371889714.5.0.753258621658.issue18280@psf.upfronthosting.co.za> Message-ID: <1420042988.56.0.575141389387.issue18280@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:23:13 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:23:13 +0000 Subject: [issue20487] Odd words in unittest.mock document. In-Reply-To: <1391355507.86.0.158179018907.issue20487@psf.upfronthosting.co.za> Message-ID: <1420042993.95.0.77703676481.issue20487@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:23:19 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:23:19 +0000 Subject: [issue1723038] Curses Menu Message-ID: <1420042999.46.0.0240853675221.issue1723038@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:23:24 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:23:24 +0000 Subject: [issue1098749] Single-line option to pygettext.py Message-ID: <1420043004.47.0.612380684803.issue1098749@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:23:43 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:23:43 +0000 Subject: [issue10388] spwd returning different value depending on privileges In-Reply-To: <1289484192.53.0.424683719192.issue10388@psf.upfronthosting.co.za> Message-ID: <1420043023.79.0.584302350027.issue10388@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:23:50 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:23:50 +0000 Subject: [issue18787] Misleading error from getspnam function of spwd module In-Reply-To: <1376971981.98.0.467831293927.issue18787@psf.upfronthosting.co.za> Message-ID: <1420043030.6.0.394417032396.issue18787@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:23:57 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:23:57 +0000 Subject: [issue1500504] Alternate RFC 3986 compliant URI parsing module Message-ID: <1420043037.04.0.354950194814.issue1500504@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:24:03 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:24:03 +0000 Subject: [issue1687125] cannot catch KeyboardInterrupt when using curses getkey() Message-ID: <1420043043.5.0.152225118226.issue1687125@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:24:09 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:24:09 +0000 Subject: [issue2209] mailbox module doesn't support compressed mbox In-Reply-To: <1204283686.29.0.398991298124.issue2209@psf.upfronthosting.co.za> Message-ID: <1420043049.37.0.877606900413.issue2209@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:24:38 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:24:38 +0000 Subject: [issue4254] _cursesmodule.c callable update_lines_cols() In-Reply-To: <1225724529.97.0.843166149521.issue4254@psf.upfronthosting.co.za> Message-ID: <1420043078.48.0.895011407174.issue4254@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:24:42 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:24:42 +0000 Subject: [issue1103213] Adding the missing socket.recvall() method Message-ID: <1420043082.88.0.79579349384.issue1103213@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:24:58 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:24:58 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1420043098.28.0.54580430334.issue2292@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:25:04 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:25:04 +0000 Subject: [issue12384] difflib.SequenceMatcher and Match: code and doc bugs In-Reply-To: <1308686441.84.0.396418173173.issue12384@psf.upfronthosting.co.za> Message-ID: <1420043104.29.0.845080429878.issue12384@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:25:13 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 31 Dec 2014 16:25:13 +0000 Subject: [issue23136] BUG in how _strptime() handles week 0 In-Reply-To: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za> Message-ID: <1420043113.05.0.840640752984.issue23136@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: What's a New Year without fixing a calendar bug! :-) Jim's logic looks right to me. The patch needs a test before it can be applied. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:25:14 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:25:14 +0000 Subject: [issue18644] Got ResourceWarning: unclosed file when using test function from formatter module In-Reply-To: <1375537519.43.0.405840418589.issue18644@psf.upfronthosting.co.za> Message-ID: <1420043114.18.0.382457761574.issue18644@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:25:20 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:25:20 +0000 Subject: [issue18518] return-ing within code timed with timeit.timeit causes wrong return value of timeit.timeit In-Reply-To: <1374400020.0.0.45788018989.issue18518@psf.upfronthosting.co.za> Message-ID: <1420043120.51.0.776257127671.issue18518@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:25:26 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:25:26 +0000 Subject: [issue1599254] mailbox: other programs' messages can vanish without trace Message-ID: <1420043126.66.0.923250604118.issue1599254@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:25:32 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:25:32 +0000 Subject: [issue21360] mailbox.Maildir should ignore files named with a leading dot In-Reply-To: <1398550003.67.0.360972625113.issue21360@psf.upfronthosting.co.za> Message-ID: <1420043132.58.0.511757421359.issue21360@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:25:39 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:25:39 +0000 Subject: [issue1005895] curses for win32 Message-ID: <1420043139.91.0.0741965040483.issue1005895@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:25:52 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:25:52 +0000 Subject: [issue2889] curses for windows (alternative patch) In-Reply-To: <1210919907.42.0.842256015219.issue2889@psf.upfronthosting.co.za> Message-ID: <1420043152.33.0.0308716004638.issue2889@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:25:57 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:25:57 +0000 Subject: [issue1708316] doctest work with Windows PyReadline Message-ID: <1420043157.53.0.0286760194269.issue1708316@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:30:33 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 31 Dec 2014 16:30:33 +0000 Subject: [issue23134] datetime.strptime at the turn of the year In-Reply-To: <1419962642.25.0.70032949175.issue23134@psf.upfronthosting.co.za> Message-ID: <1420043433.39.0.135014435769.issue23134@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Closing as a duplicate of #23136. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> BUG in how _strptime() handles week 0 versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:31:25 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:31:25 +0000 Subject: [issue16024] Doc cleanup regarding path=fd, dir_fd, follow_symlinks, etc In-Reply-To: <1348500599.22.0.118178834994.issue16024@psf.upfronthosting.co.za> Message-ID: <1420043485.47.0.743539546334.issue16024@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:32:31 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Wed, 31 Dec 2014 16:32:31 +0000 Subject: [issue23136] BUG in how _strptime() handles week 0 In-Reply-To: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za> Message-ID: <1420043551.08.0.0508511943979.issue23136@psf.upfronthosting.co.za> Saimadhav Heblikar added the comment: Hi, Here is my understanding of it. I have used the following C example of strptime and strftime to show that the string '0 2015 2' along with the format specifier '%W %Y %w' is invalid. For any valid string, strptime followed by strftime should return the same string. This is easily verified. However, when you try the same thing(as in the attached example) with '0 2015 2', we get a different string after strptime followed by strftime, indicating the string is invalid. Do let me know if I have made any mistake in understanding this. ---------- Added file: http://bugs.python.org/file37572/example.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:34:48 2014 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 31 Dec 2014 16:34:48 +0000 Subject: [issue16776] Document PyCFunction_New and PyCFunction_NewEx functions In-Reply-To: <1356434154.16.0.0981038830976.issue16776@psf.upfronthosting.co.za> Message-ID: <1420043688.21.0.173058555712.issue16776@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- nosy: -akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:41:49 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 31 Dec 2014 16:41:49 +0000 Subject: [issue23136] BUG in how _strptime() handles week 0 In-Reply-To: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za> Message-ID: <1420044109.06.0.71819351892.issue23136@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: In a comment for #23134, Serhiy suggested that this may not be a bug (msg233215) because C strptime behavior for this case is undefined. I disagree. On Mac OSX, strptime man page states: """ The %U and %W format specifiers accept any value within the range 00 to 53 without validat- ing against other values supplied (like month or day of the year, for example). """ And for the data="0 2015 2", format="%W %Y %w" case, it produces 2015-12-30 00:00:00 as expected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:48:25 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 31 Dec 2014 16:48:25 +0000 Subject: [issue23136] BUG in how _strptime() handles week 0 In-Reply-To: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za> Message-ID: <1420044505.12.0.325670740818.issue23136@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: See also #12006. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 17:51:29 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 31 Dec 2014 16:51:29 +0000 Subject: [issue23136] BUG in how _strptime() handles week 0 In-Reply-To: <1420030706.75.0.708059932507.issue23136@psf.upfronthosting.co.za> Message-ID: <15780348.jP0JPME51R@raxxla> Serhiy Storchaka added the comment: Thank you Jim for your patch. That all right and the patch fixes the issue. But the code looks a little tricky, and it would be more robust to use other signal value for julian (e.g. None). However I'm not sure that strptime should accept weekdays before the start of year. In C the strptime function doesn't return valid date for such input. $ ./strptimetest "0 2015 1" "%W %Y %w" 2015-00--2 00:00:00 $ ./strptimetest "0 2015 2" "%W %Y %w" 2015-00--1 00:00:00 $ ./strptimetest "0 2015 3" "%W %Y %w" 2015-00-00 00:00:00 $ ./strptimetest "0 2015 4" "%W %Y %w" 2015-01-01 00:00:00 $ ./strptimetest "0 2015 5" "%W %Y %w" 2015-01-02 00:00:00 $ ./strptimetest "0 2015 6" "%W %Y %w" 2015-01-03 00:00:00 $ ./strptimetest "0 2015 7" "%W %Y %w" 2015-01-00 00:00:00 May be Python strptime should raise an exception for weekdays before the start of year as well as it raise an exception for weekdays out of range 0-6. I'm not sure that any patch should be applied to maintained releases. ---------- keywords: +patch Added file: http://bugs.python.org/file37573/strptimetest.c Added file: http://bugs.python.org/file37574/strptime_julian_none.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: strptimetest.c Type: text/x-csrc Size: 444 bytes Desc: not available URL: -------------- next part -------------- diff -r ac176a69d188 Lib/_strptime.py --- a/Lib/_strptime.py Sun Dec 28 22:14:23 2014 -0600 +++ b/Lib/_strptime.py Wed Dec 31 18:30:51 2014 +0200 @@ -348,9 +348,9 @@ def _strptime(data_string, format="%a %b # though week_of_year = -1 week_of_year_start = -1 - # weekday and julian defaulted to -1 so as to signal need to calculate + # weekday and julian defaulted to None so as to signal need to calculate # values - weekday = julian = -1 + weekday = julian = None found_dict = found.groupdict() for group_key in found_dict.keys(): # Directives not explicitly handled below: @@ -452,14 +452,14 @@ def _strptime(data_string, format="%a %b year = 1900 # If we know the week of the year and what day of that week, we can figure # out the Julian day of the year. - if julian == -1 and week_of_year != -1 and weekday != -1: + if julian is None and week_of_year != -1 and weekday is not None: week_starts_Mon = True if week_of_year_start == 0 else False julian = _calc_julian_from_U_or_W(year, week_of_year, weekday, week_starts_Mon) # Cannot pre-calculate datetime_date() since can change in Julian # calculation and thus could have different value for the day of the week # calculation. - if julian == -1: + if julian is None: # Need to add 1 to result since first day of the year is 1, not 0. julian = datetime_date(year, month, day).toordinal() - \ datetime_date(year, 1, 1).toordinal() + 1 @@ -469,7 +469,7 @@ def _strptime(data_string, format="%a %b year = datetime_result.year month = datetime_result.month day = datetime_result.day - if weekday == -1: + if weekday is None: weekday = datetime_date(year, month, day).weekday() # Add timezone info tzname = found_dict.get("Z") From report at bugs.python.org Wed Dec 31 17:51:57 2014 From: report at bugs.python.org (Tomasz Ryczkowski) Date: Wed, 31 Dec 2014 16:51:57 +0000 Subject: [issue23136] BUG in how _strptime() handles week 0 In-Reply-To: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za> Message-ID: <1420044717.27.0.194424116196.issue23136@psf.upfronthosting.co.za> Changes by Tomasz Ryczkowski : ---------- nosy: +torm _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 18:12:46 2014 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 31 Dec 2014 17:12:46 +0000 Subject: [issue10388] spwd returning different value depending on privileges In-Reply-To: <1289484192.53.0.424683719192.issue10388@psf.upfronthosting.co.za> Message-ID: <1420045966.45.0.377921300562.issue10388@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: I still think this should be fixed (raise an exception) in the next major release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 18:30:15 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 31 Dec 2014 17:30:15 +0000 Subject: [issue23136] BUG in how _strptime() handles week 0 In-Reply-To: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za> Message-ID: <1420047015.6.0.190396672298.issue23136@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is alternative patch which rejects week-weekday combinations out of specified year. ---------- Added file: http://bugs.python.org/file37575/strptime_check_valid_week.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 18:35:28 2014 From: report at bugs.python.org (Jim Carroll) Date: Wed, 31 Dec 2014 17:35:28 +0000 Subject: [issue23136] BUG in how _strptime() handles week 0 In-Reply-To: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za> Message-ID: <1420047328.22.0.82545598009.issue23136@psf.upfronthosting.co.za> Jim Carroll added the comment: I understand. Actually, raising an exception would be perfectly acceptable as well (possibly even more desirable). I too experimented with the c-lib strptime() and discovered the negative values of tm_mday. These results are good too -- as they clearly show the number of days before the new year. I don't think it's important for the python version to return the same values, but it would be better for it to at least be predictable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 18:40:25 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 31 Dec 2014 17:40:25 +0000 Subject: [issue23136] BUG in how _strptime() handles week 0 In-Reply-To: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za> Message-ID: <1420047625.05.0.108847973391.issue23136@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > For any valid string, strptime followed by strftime should return > the same string. Not necessarily. String to datetime mapping implemented by strptime can be many to one. For example, >>> datetime.strptime("2014 366", "%Y %j") == datetime.strptime("2015 1", "%Y %j") True in this case, strptime-strftime may not round-trip. >>> datetime.strptime("2014 366", "%Y %j").strftime("%Y %j") '2015 001' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 19:00:19 2014 From: report at bugs.python.org (Saimadhav Heblikar) Date: Wed, 31 Dec 2014 18:00:19 +0000 Subject: [issue23136] BUG in how _strptime() handles week 0 In-Reply-To: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za> Message-ID: <1420048819.04.0.239936328416.issue23136@psf.upfronthosting.co.za> Saimadhav Heblikar added the comment: >>Not necessarily. String to datetime mapping implemented by strptime can be many to one. For example, I was referring to C strptime and strftime. But thanks for posting the round trip example. I was unaware of it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 19:05:48 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 31 Dec 2014 18:05:48 +0000 Subject: [issue23136] BUG in how _strptime() handles week 0 In-Reply-To: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za> Message-ID: <1420049148.22.0.159331209677.issue23136@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I would prefer to accept "denormalized" "%Y %W %w" combinations. Note that while Mac OSX and glibc versions of strptime produce different results, neither implementation signals an error by returning NULL. > In C the strptime function doesn't return valid date for such input. This is not true. In C, struct tm is not required to contain normalized data. I am attaching a modified version of Serhiy's strptimetest.c: $ diff -u strptimetest.c strptimetest2.c --- strptimetest.c 2014-12-30 13:45:17.000000000 -0500 +++ strptimetest2.c 2014-12-31 12:56:17.000000000 -0500 @@ -16,6 +16,7 @@ exit(1); } strptime(argv[1], argv[2], &tm); + mktime(&tm); strftime(buf, sizeof(buf), "%Y-%m-%d %H:%M:%S", &tm); puts(buf); return 0; With this modification, I get on Linux $ ./a.out "0 2015 2" "%W %Y %w" 2014-11-29 00:00:00 which is still wrong, but I think this is a glibc issue: mktime accepted strptime result as valid even though it failed to normalize it correctly. ---------- Added file: http://bugs.python.org/file37576/strptimetest2.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 19:09:35 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 31 Dec 2014 18:09:35 +0000 Subject: [issue10388] spwd returning different value depending on privileges In-Reply-To: <1289484192.53.0.424683719192.issue10388@psf.upfronthosting.co.za> Message-ID: <1420049375.14.0.199549530897.issue10388@psf.upfronthosting.co.za> R. David Murray added the comment: Unless Serhiy (or someone else) still objects, I say go ahead and commit it to default. ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 19:11:11 2014 From: report at bugs.python.org (R. David Murray) Date: Wed, 31 Dec 2014 18:11:11 +0000 Subject: [issue10388] spwd returning different value depending on privileges In-Reply-To: <1289484192.53.0.424683719192.issue10388@psf.upfronthosting.co.za> Message-ID: <1420049471.81.0.823266982779.issue10388@psf.upfronthosting.co.za> R. David Murray added the comment: Adding a test would be a good idea, though... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 19:11:14 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 31 Dec 2014 18:11:14 +0000 Subject: [issue23135] import searchpaths as arguments In-Reply-To: <1419966631.84.0.639997296504.issue23135@psf.upfronthosting.co.za> Message-ID: <1420049474.94.0.299634953336.issue23135@psf.upfronthosting.co.za> Nick Coghlan added the comment: Issue 13475 provides some additional context for discussion of changes to the sys.path initialisation process. The status quo is that I'm currently wary of adding more complexity to an already fragile initialisation sequence for things that can be implemented by way of running a custom launch script that uses the runpy module to replicate the CPython script invocation options. In the specific case of this patch, while the idea is one we've considered before (and may end up implementing some day), this specific implementation adds new path initilisation logic directly in Py_Main, well away from getpath.c (which, in collaboration with site.py, is intended to fully handle the path initialisation logic), and without being separated out into a distinct API that embedding applications can easily take advantage of. A lot of Python code will also run *before* the command line arguments are processed, so you'll end up with a case where code run early may pick up a version of a module from later in sys.path, giving the appearance that the sys.path additions are being ignored, even though they appear in sys.path after the program is fully initialised. While the technical concerns mean it isn't likely this particular approach would be pursued further, as a practical matter, additional things that would be needed for a patch to the interpreter argument handling to be accepted include: - a signed contributor licensing agreement - documentation upates in the "using" guide - a new test (or tests) in Lib/test/test_cmdline.py and Lib/test/test_cmdline_script.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 19:13:41 2014 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 31 Dec 2014 18:13:41 +0000 Subject: [issue23077] PEP 1: Allow Provisional status for PEPs In-Reply-To: <1418861338.72.0.949069550217.issue23077@psf.upfronthosting.co.za> Message-ID: <1420049621.48.0.336243979847.issue23077@psf.upfronthosting.co.za> Nick Coghlan added the comment: The new PEP wouldn't be a permanent one - it would be describing the proposed changes to PEP 1, and the rationale for them. It would be for my own benefit as much as anyone's - if I can't explain the proposed change and its intended benefits clearly in PEP form, its probably a bad idea :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 19:16:57 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 31 Dec 2014 18:16:57 +0000 Subject: [issue18518] return-ing within code timed with timeit.timeit causes wrong return value of timeit.timeit In-Reply-To: <1374400020.0.0.45788018989.issue18518@psf.upfronthosting.co.za> Message-ID: <1420049817.97.0.767900423885.issue18518@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: May be add a guard against statements which can confuse timeit? These are not only "return", but "yield", and "break" and "continue" outside of a loop. Proposed patch checks that testing code can be compiled outside of a function. ---------- assignee: docs at python -> components: +Library (Lib) -Documentation nosy: +serhiy.storchaka stage: -> patch review versions: +Python 3.5 -Python 3.3 Added file: http://bugs.python.org/file37577/timeit_reject_invalid_statements.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 19:19:55 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 31 Dec 2014 18:19:55 +0000 Subject: [issue23136] BUG in how _strptime() handles week 0 In-Reply-To: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za> Message-ID: <1420049995.88.0.765243943227.issue23136@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Also, given that "2015 0 0", "2015 0 1", and "2015 0 3", all currently work with '%Y %W %w' format specification and produce dates in the year 2014, I think raising an error in all those cases is more likely to break user code than correcting the value in the edge case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 19:30:28 2014 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 31 Dec 2014 18:30:28 +0000 Subject: [issue10388] spwd returning different value depending on privileges In-Reply-To: <1289484192.53.0.424683719192.issue10388@psf.upfronthosting.co.za> Message-ID: <1420050628.28.0.682287432707.issue10388@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This issue should be considered in conjunction with issue18787. And if we decise to break backward compatibility, this should be well documented in What's New. May be discuss these issues on Python-Dev? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 19:57:14 2014 From: report at bugs.python.org (Steve Dower) Date: Wed, 31 Dec 2014 18:57:14 +0000 Subject: [issue23018] Add version info to python[w].exe In-Reply-To: <1418102862.79.0.624047396863.issue23018@psf.upfronthosting.co.za> Message-ID: <1420052234.31.0.173470662726.issue23018@psf.upfronthosting.co.za> Steve Dower added the comment: Add for Windows 10 (source: http://blogs.msdn.com/b/chuckw/archive/2013/09/10/manifest-madness.aspx) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 19:59:06 2014 From: report at bugs.python.org (Steve Dower) Date: Wed, 31 Dec 2014 18:59:06 +0000 Subject: [issue19143] Finding the Windows version getting messier (detect windows 8.1?) In-Reply-To: <1380675004.25.0.239416620624.issue19143@psf.upfronthosting.co.za> Message-ID: <1420052346.12.0.0144530204378.issue19143@psf.upfronthosting.co.za> Steve Dower added the comment: I've attached a replacement for the win32_ver function in platform.py that will get the actual version number from kernel32.dll's resources. Originally I was just writing a helper function, but it seemed easy enough to replace the entire function. The attached function only really supports Python 3.5 as it assumes that the earliest Windows version will be Vista (6.0). The comments in platform.py suggest backwards compatibility is important for this file, so my win32_ver() may be a better reference for someone who wants to add this functionality in a backwards-compatible way. Though if it's okay for the stdlib platform.py to not support pre-3.5 this should be fine (and I'll do the extra work to make sure). It's probably also easy to support 3.4 and Windows XP/WS2K3 as well, but I don't have any machines handy to test it. As part of my patch for #23018, I'll add the manifest required so that GetVersionEx() will recognise 8.1 and 10. ---------- versions: +Python 3.5 -Python 3.3 Added file: http://bugs.python.org/file37578/win32_ver.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 20:03:46 2014 From: report at bugs.python.org (c2621566) Date: Wed, 31 Dec 2014 19:03:46 +0000 Subject: [issue23135] import searchpaths as arguments In-Reply-To: <1419966631.84.0.639997296504.issue23135@psf.upfronthosting.co.za> Message-ID: <1420052626.72.0.15145031517.issue23135@psf.upfronthosting.co.za> c2621566 added the comment: Thanks for the feedback. The technical arguments convinced me not to spend more time on this. I admit this patch is kind of an ugly hack. The effort needed for a technically satisfactory solution seems too much for this unimportant feature. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 20:20:11 2014 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 31 Dec 2014 19:20:11 +0000 Subject: [issue23136] BUG in how _strptime() handles week 0 In-Reply-To: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za> Message-ID: <1420053611.7.0.227060063782.issue23136@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +Erik.Cederstrand, aganders3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 20:31:35 2014 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 31 Dec 2014 19:31:35 +0000 Subject: [issue17056] Support Visual Studio 2012 In-Reply-To: <1359330739.37.0.839652698697.issue17056@psf.upfronthosting.co.za> Message-ID: <1420054295.36.0.407546163875.issue17056@psf.upfronthosting.co.za> Mark Lawrence added the comment: Can this be closed as essentially a duplicate of #22919 which targets Visual Studio 2015? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 20:36:24 2014 From: report at bugs.python.org (Bertrand Janin) Date: Wed, 31 Dec 2014 19:36:24 +0000 Subject: [issue23127] socket.setsockopt() is still broken for multicast TTL and Loop options In-Reply-To: <1419859867.69.0.91970081595.issue23127@psf.upfronthosting.co.za> Message-ID: <1420054584.9.0.299527200418.issue23127@psf.upfronthosting.co.za> Bertrand Janin added the comment: Good point, I updated the diff with a better cast to avoid endianness issues (tested on MIPS64) and added an OpenBSD #ifdef, is that more acceptable? diff -r 88de50c1696b Modules/socketmodule.c --- a/Modules/socketmodule.c Sun Dec 28 18:51:25 2014 +0200 +++ b/Modules/socketmodule.c Wed Dec 31 14:25:55 2014 -0500 @@ -1881,24 +1881,31 @@ { int level; int optname; int res; char *buf; int buflen; int flag; if (PyArg_ParseTuple(args, "iii:setsockopt", &level, &optname, &flag)) { buf = (char *) &flag; buflen = sizeof flag; +#if defined(__OpenBSD__) + /* Multicast options take shorter arguments */ + if (optname == IP_MULTICAST_TTL || optname == IP_MULTICAST_LOOP) { + buflen = sizeof(u_char); + *buf = (u_char)flag; + } +#endif } else { PyErr_Clear(); if (!PyArg_ParseTuple(args, "iis#:setsockopt", &level, &optname, &buf, &buflen)) return NULL; } res = setsockopt(s->sock_fd, level, optname, (void *)buf, buflen); if (res < 0) return s->errorhandler(); Py_INCREF(Py_None); return Py_None; ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 21:52:10 2014 From: report at bugs.python.org (Steve Dower) Date: Wed, 31 Dec 2014 20:52:10 +0000 Subject: [issue17056] Support Visual Studio 2012 In-Reply-To: <1359330739.37.0.839652698697.issue17056@psf.upfronthosting.co.za> Message-ID: <1420059130.05.0.215912283964.issue17056@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> duplicate status: open -> closed superseder: -> Update PCBuild for VS 2015 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 23:14:24 2014 From: report at bugs.python.org (eryksun) Date: Wed, 31 Dec 2014 22:14:24 +0000 Subject: [issue19143] Finding the Windows version getting messier (detect windows 8.1?) In-Reply-To: <1380675004.25.0.239416620624.issue19143@psf.upfronthosting.co.za> Message-ID: <1420064064.32.0.397033665013.issue19143@psf.upfronthosting.co.za> eryksun added the comment: > actual_len = kernel32.GetModuleFileNameW(kernel32._handle, name, len(name)) A module handle is the module's base address. kernel32 is loaded at a 32-bit base address in a 64-bit process, but I don't know whether that will always be true in current and future versions. It's safer to use HANDLE(kernel32._handle) instead of the default C int conversion. > ver_block = byref(c_buffer(size)) byref is unnecessary. An array gets passed as a pointer. > maj = int(pvi.contents.dwProductVersionMS >> 16) > min = int(pvi.contents.dwProductVersionMS & 0xFFFF) > build = int(pvi.contents.dwProductVersionLS >> 16) pvi.contents.dwProductVersionMS is already an int, else the bitshift would fail. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Dec 31 00:49:11 2014 From: report at bugs.python.org (Vinson Lee) Date: Tue, 30 Dec 2014 23:49:11 +0000 Subject: [issue23137] Python 2.7.9 test_gdb fails on CentOS 7 Message-ID: <1419983350.87.0.850193733351.issue23137@psf.upfronthosting.co.za> New submission from Vinson Lee: Python 2.7.9 test_gdb fails on CentOS 7. $./python Lib/test/regrtest.py -v test_gdb == CPython 2.7.9 (default, Dec 22 2014, 10:54:52) [GCC 4.8.2 20140120 (Red Hat 4.8.2-16)] == Linux-3.10.0-123.13.2.el7.x86_64-x86_64-with-centos-7.0.1406-Core little-endian == Python-2.7.9/build/test_python_16739 Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0) [1/1] test_gdb test_NULL_instance_dict (test.test_gdb.PrettyPrintTests) Ensure that a PyInstanceObject with with a NULL in_dict is handled ... FAIL test_NULL_ob_type (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with NULL ob_type is handled gracefully ... FAIL test_NULL_ptr (test.test_gdb.PrettyPrintTests) Ensure that a NULL PyObject* is handled gracefully ... FAIL test_builtin_function (test.test_gdb.PrettyPrintTests) ... FAIL test_builtin_method (test.test_gdb.PrettyPrintTests) ... FAIL test_builtins_help (test.test_gdb.PrettyPrintTests) Ensure that the new-style class _Helper in site.py can be handled ... FAIL test_classic_class (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of classic class instances ... FAIL test_corrupt_ob_type (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with a corrupt ob_type is handled gracefully ... FAIL test_corrupt_tp_flags (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with a type with corrupt tp_flags is handled ... FAIL test_corrupt_tp_name (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with a type with corrupt tp_name is handled ... FAIL test_dicts (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of dictionaries ... FAIL test_exceptions (test.test_gdb.PrettyPrintTests) ... FAIL test_frames (test.test_gdb.PrettyPrintTests) ... ok test_frozensets (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of frozensets ... FAIL test_getting_backtrace (test.test_gdb.PrettyPrintTests) ... ok test_int (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of various "int" values ... FAIL test_lists (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of lists ... FAIL test_long (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of various "long" values ... FAIL test_modern_class (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of new-style class instances ... FAIL test_selfreferential_dict (test.test_gdb.PrettyPrintTests) Ensure that a reference loop involving a dict doesn't lead proxyval ... FAIL test_selfreferential_list (test.test_gdb.PrettyPrintTests) Ensure that a reference loop involving a list doesn't lead proxyval ... FAIL test_selfreferential_new_style_instance (test.test_gdb.PrettyPrintTests) ... FAIL test_selfreferential_old_style_instance (test.test_gdb.PrettyPrintTests) ... FAIL test_sets (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of sets ... FAIL test_singletons (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of True, False and None ... FAIL test_strings (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of strings ... FAIL test_subclassing_list (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of an instance of a list subclass ... FAIL test_subclassing_tuple (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of an instance of a tuple subclass ... FAIL test_truncation (test.test_gdb.PrettyPrintTests) Verify that very long output is truncated ... FAIL test_tuples (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of tuples ... FAIL test_unicode (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of unicode values ... FAIL test_basic_command (test.test_gdb.PyListTests) Verify that the "py-list" command works ... skipped 'Python was compiled with optimizations' test_one_abs_arg (test.test_gdb.PyListTests) Verify the "py-list" command with one absolute argument ... skipped 'Python was compiled with optimizations' test_two_abs_args (test.test_gdb.PyListTests) Verify the "py-list" command with two absolute arguments ... skipped 'Python was compiled with optimizations' test_down_at_bottom (test.test_gdb.StackNavigationTests) Verify handling of "py-down" at the bottom of the stack ... ok test_pyup_command (test.test_gdb.StackNavigationTests) Verify that the "py-up" command works ... skipped 'Python was compiled with optimizations' test_up_at_top (test.test_gdb.StackNavigationTests) Verify handling of "py-up" at the top of the stack ... ok test_up_then_down (test.test_gdb.StackNavigationTests) Verify "py-up" followed by "py-down" ... skipped 'Python was compiled with optimizations' test_basic_command (test.test_gdb.PyBtTests) Verify that the "py-bt" command works ... skipped 'Python was compiled with optimizations' test_basic_command (test.test_gdb.PyPrintTests) Verify that the "py-print" command works ... skipped 'Python was compiled with optimizations' test_print_after_up (test.test_gdb.PyPrintTests) ... skipped 'Python was compiled with optimizations' test_printing_builtin (test.test_gdb.PyPrintTests) ... skipped 'Python was compiled with optimizations' test_printing_global (test.test_gdb.PyPrintTests) ... skipped 'Python was compiled with optimizations' test_basic_command (test.test_gdb.PyLocalsTests) ... skipped 'Python was compiled with optimizations' test_locals_after_up (test.test_gdb.PyLocalsTests) ... skipped 'Python was compiled with optimizations' ====================================================================== FAIL: test_NULL_instance_dict (test.test_gdb.PrettyPrintTests) Ensure that a PyInstanceObject with with a NULL in_dict is handled ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 476, in test_NULL_instance_dict exptype='Foo') File "Python-2.7.9/Lib/test/test_gdb.py", line 432, in assertSane (gdb_repr, gdb_output)) AssertionError: Unexpected gdb representation: 'op at entry=' Breakpoint 1 at 0x45d9c0: PyObject_Print. (2 locations) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, PyObject_Print (op=op at entry=, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 329 { #0 PyObject_Print (op=op at entry=, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 #1 0x000000000043a38c in file_PyObject_Print (f=0x7ffff7fc3150, f=0x7ffff7fc3150, flags=1, op=) at Objects/fileobject.c:110 #2 PyFile_WriteObject (v=v at entry=, f=f at entry=, flags=flags at entry=1) at Objects/fileobject.c:2579 #3 0x00000000004b3bbf in PyEval_EvalFrameEx (f=f at entry=Frame 0x7ffff7f23050, for file , line 6, in (), throwflag=throwflag at entry=0) at Python/ceval.c:1771 #4 0x00000000004b69f8 in PyEval_EvalCodeEx (co=co at entry=0x7ffff7fb4bb0, globals=globals at entry={'foo': , '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, locals=locals at entry={'foo': , '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3265 #5 0x00000000004b6b22 in PyEval_EvalCode (co=co at entry=0x7ffff7fb4bb0, globals=globals at entry={'foo': , '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, locals=locals at entry={'foo': , '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}) at Python/ceval.c:667 #6 0x00000000004e6d62 in run_mod (arena=0x7f6710, flags=0x7fffffffe310, locals={'foo': , '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, globals={'foo': , '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, filename=0x549f56 "", mod=0x835030) at Python/pythonrun.c:1371 #7 PyRun_StringFlags (flags=0x7fffffffe310, locals={'foo': , '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, globals={'foo': , '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, start=257, str=0x7ef010 "\nclass Foo:\n pass\nfoo = Foo()\nfoo.an_int = 42\nprint foo\n") at Python/pythonrun.c:1334 #8 PyRun_SimpleStringFlags (command=command at entry=0x7ef010 "\nclass Foo:\n pass\nfoo = Foo()\nfoo.an_int = 42\nprint foo\n", flags=flags at entry=0x7fffffffe310) at Python/pythonrun.c:975 #9 0x0000000000415548 in Py_Main (argc=, argv=) at Modules/main.c:584 #10 0x00007ffff7117af5 in __libc_start_main () from /lib64/libc.so.6 #11 0x0000000000414b91 in _start () ====================================================================== FAIL: test_NULL_ob_type (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with NULL ob_type is handled gracefully ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 447, in test_NULL_ob_type 'set op->ob_type=0') File "Python-2.7.9/Lib/test/test_gdb.py", line 432, in assertSane (gdb_repr, gdb_output)) AssertionError: Unexpected gdb representation: 'op at entry=' Breakpoint 1 at 0x45d9c0: PyObject_Print. (2 locations) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, PyObject_Print (op=op at entry=42, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 329 { #0 PyObject_Print (op=op at entry=, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 #1 0x000000000043a38c in file_PyObject_Print (f=0x7ffff7fc3150, f=0x7ffff7fc3150, flags=1, op=) at Objects/fileobject.c:110 #2 PyFile_WriteObject (v=v at entry=, f=f at entry=, flags=flags at entry=1) at Objects/fileobject.c:2579 #3 0x00000000004b3bbf in PyEval_EvalFrameEx (f=f at entry=Frame 0x7ffff7f921f8, for file , line 1, in (), throwflag=throwflag at entry=0) at Python/ceval.c:1771 #4 0x00000000004b69f8 in PyEval_EvalCodeEx (co=co at entry=0x7ffff7fb4830, globals=globals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3265 #5 0x00000000004b6b22 in PyEval_EvalCode (co=co at entry=0x7ffff7fb4830, globals=globals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667 #6 0x00000000004e6d62 in run_mod (arena=0x7f66e0, flags=0x7fffffffe340, locals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x549f56 "", mod=0x834da8) at Python/pythonrun.c:1371 #7 PyRun_StringFlags (flags=0x7fffffffe340, locals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, start=257, str=0x7ef010 "print 42\n") at Python/pythonrun.c:1334 #8 PyRun_SimpleStringFlags (command=command at entry=0x7ef010 "print 42\n", flags=flags at entry=0x7fffffffe340) at Python/pythonrun.c:975 #9 0x0000000000415548 in Py_Main (argc=, argv=) at Modules/main.c:584 #10 0x00007ffff7117af5 in __libc_start_main () from /lib64/libc.so.6 #11 0x0000000000414b91 in _start () ====================================================================== FAIL: test_NULL_ptr (test.test_gdb.PrettyPrintTests) Ensure that a NULL PyObject* is handled gracefully ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 442, in test_NULL_ptr self.assertEqual(gdb_repr, '0x0') AssertionError: '0x0, op at entry=42' != '0x0' ====================================================================== FAIL: test_builtin_function (test.test_gdb.PrettyPrintTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 579, in test_builtin_function self.assertEqual(gdb_repr, '') AssertionError: 'op at entry=' != '' ====================================================================== FAIL: test_builtin_method (test.test_gdb.PrettyPrintTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 586, in test_builtin_method (gdb_repr, gdb_output)) AssertionError: Unexpected gdb representation: 'op at entry=' Breakpoint 1 at 0x45d9c0: PyObject_Print. (2 locations) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, PyObject_Print (op=op at entry=, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 329 { #0 PyObject_Print (op=op at entry=, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 #1 0x000000000043a38c in file_PyObject_Print (f=0x7ffff7fc3150, f=0x7ffff7fc3150, flags=1, op=) at Objects/fileobject.c:110 #2 PyFile_WriteObject (v=v at entry=, f=f at entry=, flags=flags at entry=1) at Objects/fileobject.c:2579 #3 0x00000000004b3bbf in PyEval_EvalFrameEx (f=f at entry=Frame 0x7ffff7fca200, for file , line 1, in (), throwflag=throwflag at entry=0) at Python/ceval.c:1771 #4 0x00000000004b69f8 in PyEval_EvalCodeEx (co=co at entry=0x7ffff7fb4830, globals=globals at entry={'__builtins__': , '__name__': '__main__', 'sys': , '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': , '__name__': '__main__', 'sys': , '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3265 #5 0x00000000004b6b22 in PyEval_EvalCode (co=co at entry=0x7ffff7fb4830, globals=globals at entry={'__builtins__': , '__name__': '__main__', 'sys': , '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': , '__name__': '__main__', 'sys': , '__doc__': None, '__package__': None}) at Python/ceval.c:667 #6 0x00000000004e6d62 in run_mod (arena=0x7f66f0, flags=0x7fffffffe320, locals={'__builtins__': , '__name__': '__main__', 'sys': , '__doc__': None, '__package__': None}, globals={'__builtins__': , '__name__': '__main__', 'sys': , '__doc__': None, '__package__': None}, filename=0x549f56 "", mod=0x834e80) at Python/pythonrun.c:1371 #7 PyRun_StringFlags (flags=0x7fffffffe320, locals={'__builtins__': , '__name__': '__main__', 'sys': , '__doc__': None, '__package__': None}, globals={'__builtins__': , '__name__': '__main__', 'sys': , '__doc__': None, '__package__': None}, start=257, str=0x7ef010 "import sys; print sys.stdout.readlines\n") at Python/pythonrun.c:1334 #8 PyRun_SimpleStringFlags (command=command at entry=0x7ef010 "import sys; print sys.stdout.readlines\n", flags=flags at entry=0x7fffffffe320) at Python/pythonrun.c:975 #9 0x0000000000415548 in Py_Main (argc=, argv=) at Modules/main.c:584 #10 0x00007ffff7117af5 in __libc_start_main () from /lib64/libc.so.6 #11 0x0000000000414b91 in _start () ====================================================================== FAIL: test_builtins_help (test.test_gdb.PrettyPrintTests) Ensure that the new-style class _Helper in site.py can be handled ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 486, in test_builtins_help msg='Unexpected rendering %r' % gdb_repr) AssertionError: Unexpected rendering 'op at entry=<_Helper at remote 0x7ffff7eefd90>' ====================================================================== FAIL: test_classic_class (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of classic class instances ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 360, in test_classic_class msg='Unexpected classic-class rendering %r' % gdb_repr) AssertionError: Unexpected classic-class rendering 'op at entry=' ====================================================================== FAIL: test_corrupt_ob_type (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with a corrupt ob_type is handled gracefully ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 453, in test_corrupt_ob_type expvalue=42) File "Python-2.7.9/Lib/test/test_gdb.py", line 432, in assertSane (gdb_repr, gdb_output)) AssertionError: Unexpected gdb representation: 'op at entry=' Breakpoint 1 at 0x45d9c0: PyObject_Print. (2 locations) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, PyObject_Print (op=op at entry=42, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 329 { #0 PyObject_Print (op=op at entry=, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 #1 0x000000000043a38c in file_PyObject_Print (f=0x7ffff7fc3150, f=0x7ffff7fc3150, flags=1, op=) at Objects/fileobject.c:110 #2 PyFile_WriteObject (v=v at entry=, f=f at entry=, flags=flags at entry=1) at Objects/fileobject.c:2579 #3 0x00000000004b3bbf in PyEval_EvalFrameEx (f=f at entry=Frame 0x7ffff7f921f8, for file , line 1, in (), throwflag=throwflag at entry=0) at Python/ceval.c:1771 #4 0x00000000004b69f8 in PyEval_EvalCodeEx (co=co at entry=0x7ffff7fb4830, globals=globals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3265 #5 0x00000000004b6b22 in PyEval_EvalCode (co=co at entry=0x7ffff7fb4830, globals=globals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667 #6 0x00000000004e6d62 in run_mod (arena=0x7f66e0, flags=0x7fffffffe340, locals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x549f56 "", mod=0x834da8) at Python/pythonrun.c:1371 #7 PyRun_StringFlags (flags=0x7fffffffe340, locals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, start=257, str=0x7ef010 "print 42\n") at Python/pythonrun.c:1334 #8 PyRun_SimpleStringFlags (command=command at entry=0x7ef010 "print 42\n", flags=flags at entry=0x7fffffffe340) at Python/pythonrun.c:975 #9 0x0000000000415548 in Py_Main (argc=, argv=) at Modules/main.c:584 #10 0x00007ffff7117af5 in __libc_start_main () from /lib64/libc.so.6 #11 0x0000000000414b91 in _start () ====================================================================== FAIL: test_corrupt_tp_flags (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with a type with corrupt tp_flags is handled ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 459, in test_corrupt_tp_flags expvalue=42) File "Python-2.7.9/Lib/test/test_gdb.py", line 432, in assertSane (gdb_repr, gdb_output)) AssertionError: Unexpected gdb representation: 'op at entry=' Breakpoint 1 at 0x45d9c0: PyObject_Print. (2 locations) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, PyObject_Print (op=op at entry=42, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 329 { #0 PyObject_Print (op=op at entry=, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 #1 0x000000000043a38c in file_PyObject_Print (f=0x7ffff7fc3150, f=0x7ffff7fc3150, flags=1, op=) at Objects/fileobject.c:110 #2 PyFile_WriteObject (v=v at entry=, f=f at entry=, flags=flags at entry=1) at Objects/fileobject.c:2579 #3 0x00000000004b3bbf in PyEval_EvalFrameEx (f=f at entry=Frame 0x7ffff7f921f8, for file , line 1, in (), throwflag=throwflag at entry=0) at Python/ceval.c:1771 #4 0x00000000004b69f8 in PyEval_EvalCodeEx (co=co at entry=0x7ffff7fb4830, globals=globals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3265 #5 0x00000000004b6b22 in PyEval_EvalCode (co=co at entry=0x7ffff7fb4830, globals=globals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667 #6 0x00000000004e6d62 in run_mod (arena=0x7f66e0, flags=0x7fffffffe340, locals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x549f56 "", mod=0x834da8) at Python/pythonrun.c:1371 #7 PyRun_StringFlags (flags=0x7fffffffe340, locals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, start=257, str=0x7ef010 "print 42\n") at Python/pythonrun.c:1334 #8 PyRun_SimpleStringFlags (command=command at entry=0x7ef010 "print 42\n", flags=flags at entry=0x7fffffffe340) at Python/pythonrun.c:975 #9 0x0000000000415548 in Py_Main (argc=, argv=) at Modules/main.c:584 #10 0x00007ffff7117af5 in __libc_start_main () from /lib64/libc.so.6 #11 0x0000000000414b91 in _start () ====================================================================== FAIL: test_corrupt_tp_name (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with a type with corrupt tp_name is handled ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 465, in test_corrupt_tp_name expvalue=42) File "Python-2.7.9/Lib/test/test_gdb.py", line 432, in assertSane (gdb_repr, gdb_output)) AssertionError: Unexpected gdb representation: 'op at entry=' Breakpoint 1 at 0x45d9c0: PyObject_Print. (2 locations) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, PyObject_Print (op=op at entry=42, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 329 { #0 PyObject_Print (op=op at entry=, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 #1 0x000000000043a38c in file_PyObject_Print (f=0x7ffff7fc3150, f=0x7ffff7fc3150, flags=1, op=) at Objects/fileobject.c:110 #2 PyFile_WriteObject (v=v at entry=, f=f at entry=, flags=flags at entry=1) at Objects/fileobject.c:2579 #3 0x00000000004b3bbf in PyEval_EvalFrameEx (f=f at entry=Frame 0x7ffff7f921f8, for file , line 1, in (), throwflag=throwflag at entry=0) at Python/ceval.c:1771 #4 0x00000000004b69f8 in PyEval_EvalCodeEx (co=co at entry=0x7ffff7fb4830, globals=globals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3265 #5 0x00000000004b6b22 in PyEval_EvalCode (co=co at entry=0x7ffff7fb4830, globals=globals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667 #6 0x00000000004e6d62 in run_mod (arena=0x7f66e0, flags=0x7fffffffe340, locals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x549f56 "", mod=0x834da8) at Python/pythonrun.c:1371 #7 PyRun_StringFlags (flags=0x7fffffffe340, locals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': , '__name__': '__main__', '__doc__': None, '__package__': None}, start=257, str=0x7ef010 "print 42\n") at Python/pythonrun.c:1334 #8 PyRun_SimpleStringFlags (command=command at entry=0x7ef010 "print 42\n", flags=flags at entry=0x7fffffffe340) at Python/pythonrun.c:975 #9 0x0000000000415548 in Py_Main (argc=, argv=) at Modules/main.c:584 #10 0x00007ffff7117af5 in __libc_start_main () from /lib64/libc.so.6 #11 0x0000000000414b91 in _start () ====================================================================== FAIL: test_dicts (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of dictionaries ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 251, in test_dicts self.assertGdbRepr({}) File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr self.assertEqual(gdb_repr, repr(val)) AssertionError: 'op at entry={}' != '{}' ====================================================================== FAIL: test_exceptions (test.test_gdb.PrettyPrintTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 337, in test_exceptions "exceptions.RuntimeError('I am an error',)") AssertionError: "op at entry=exceptions.RuntimeError('I am an error',)" != "exceptions.RuntimeError('I am an error',)" ====================================================================== FAIL: test_frozensets (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of frozensets ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 318, in test_frozensets self.assertGdbRepr(frozenset()) File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr self.assertEqual(gdb_repr, repr(val)) AssertionError: 'op at entry=frozenset([])' != 'frozenset([])' ====================================================================== FAIL: test_int (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of various "int" values ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 230, in test_int self.assertGdbRepr(42) File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr self.assertEqual(gdb_repr, repr(val)) AssertionError: 'op at entry=42' != '42' ====================================================================== FAIL: test_lists (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of lists ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 257, in test_lists self.assertGdbRepr([]) File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr self.assertEqual(gdb_repr, repr(val)) AssertionError: 'op at entry=[]' != '[]' ====================================================================== FAIL: test_long (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of various "long" values ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 238, in test_long self.assertGdbRepr(0L) File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr self.assertEqual(gdb_repr, repr(val)) AssertionError: 'op at entry=0L' != '0L' ====================================================================== FAIL: test_modern_class (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of new-style class instances ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 372, in test_modern_class msg='Unexpected new-style class rendering %r' % gdb_repr) AssertionError: Unexpected new-style class rendering 'op at entry=' ====================================================================== FAIL: test_selfreferential_dict (test.test_gdb.PrettyPrintTests) Ensure that a reference loop involving a dict doesn't lead proxyval ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 507, in test_selfreferential_dict self.assertEqual(gdb_repr, "{'foo': {'bar': {...}}}") AssertionError: "op at entry={'foo': {'bar': {...}}}" != "{'foo': {'bar': {...}}}" ====================================================================== FAIL: test_selfreferential_list (test.test_gdb.PrettyPrintTests) Ensure that a reference loop involving a list doesn't lead proxyval ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 494, in test_selfreferential_list self.assertEqual(gdb_repr, '[3, 4, 5, [...]]') AssertionError: 'op at entry=[3, 4, 5, [...]]' != '[3, 4, 5, [...]]' ====================================================================== FAIL: test_selfreferential_new_style_instance (test.test_gdb.PrettyPrintTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 533, in test_selfreferential_new_style_instance (gdb_repr, gdb_output)) AssertionError: Unexpected gdb representation: 'op at entry=) at remote 0x7ffff7f70310>' Breakpoint 1 at 0x45d9c0: PyObject_Print. (2 locations) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, PyObject_Print (op=op at entry=) at remote 0x7ffff7f70310>, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 329 { #0 PyObject_Print (op=op at entry=) at remote 0x7ffff7f70310>, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 #1 0x000000000043a38c in file_PyObject_Print (f=0x7ffff7fc3150, f=0x7ffff7fc3150, flags=1, op=) at remote 0x7ffff7f70310>) at Objects/fileobject.c:110 #2 PyFile_WriteObject (v=v at entry=) at remote 0x7ffff7f70310>, f=f at entry=, flags=flags at entry=1) at Objects/fileobject.c:2579 #3 0x00000000004b3bbf in PyEval_EvalFrameEx (f=f at entry=Frame 0x7ffff7f23050, for file , line 6, in (), throwflag=throwflag at entry=0) at Python/ceval.c:1771 #4 0x00000000004b69f8 in PyEval_EvalCodeEx (co=co at entry=0x7ffff7fb4bb0, globals=globals at entry={'foo': ) at remote 0x7ffff7f70310>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, locals=locals at entry={'foo': ) at remote 0x7ffff7f70310>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3265 #5 0x00000000004b6b22 in PyEval_EvalCode (co=co at entry=0x7ffff7fb4bb0, globals=globals at entry={'foo': ) at remote 0x7ffff7f70310>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, locals=locals at entry={'foo': ) at remote 0x7ffff7f70310>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}) at Python/ceval.c:667 #6 0x00000000004e6d62 in run_mod (arena=0x7f6710, flags=0x7fffffffe300, locals={'foo': ) at remote 0x7ffff7f70310>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, globals={'foo': ) at remote 0x7ffff7f70310>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, filename=0x549f56 "", mod=0x835078) at Python/pythonrun.c:1371 #7 PyRun_StringFlags (flags=0x7fffffffe300, locals={'foo': ) at remote 0x7ffff7f70310>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, globals={'foo': ) at remote 0x7ffff7f70310>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, start=257, str=0x7ef010 "\nclass Foo(object):\n pass\nfoo = Foo()\nfoo.an_attr = foo\nprint foo\n") at Python/pythonrun.c:1334 #8 PyRun_SimpleStringFlags (command=command at entry=0x7ef010 "\nclass Foo(object):\n pass\nfoo = Foo()\nfoo.an_attr = foo\nprint foo\n", flags=flags at entry=0x7fffffffe300) at Python/pythonrun.c:975 #9 0x0000000000415548 in Py_Main (argc=, argv=) at Modules/main.c:584 #10 0x00007ffff7117af5 in __libc_start_main () from /lib64/libc.so.6 #11 0x0000000000414b91 in _start () ====================================================================== FAIL: test_selfreferential_old_style_instance (test.test_gdb.PrettyPrintTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 520, in test_selfreferential_old_style_instance (gdb_repr, gdb_output)) AssertionError: Unexpected gdb representation: 'op at entry=) at remote 0x7ffff7f966c8>' Breakpoint 1 at 0x45d9c0: PyObject_Print. (2 locations) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, PyObject_Print (op=op at entry=) at remote 0x7ffff7f966c8>, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 329 { #0 PyObject_Print (op=op at entry=) at remote 0x7ffff7f966c8>, fp=0x7ffff74b1400 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:329 #1 0x000000000043a38c in file_PyObject_Print (f=0x7ffff7fc3150, f=0x7ffff7fc3150, flags=1, op=) at remote 0x7ffff7f966c8>) at Objects/fileobject.c:110 #2 PyFile_WriteObject (v=v at entry=) at remote 0x7ffff7f966c8>, f=f at entry=, flags=flags at entry=1) at Objects/fileobject.c:2579 #3 0x00000000004b3bbf in PyEval_EvalFrameEx (f=f at entry=Frame 0x7ffff7f23050, for file , line 6, in (), throwflag=throwflag at entry=0) at Python/ceval.c:1771 #4 0x00000000004b69f8 in PyEval_EvalCodeEx (co=co at entry=0x7ffff7fb4bb0, globals=globals at entry={'foo': ) at remote 0x7ffff7f966c8>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, locals=locals at entry={'foo': ) at remote 0x7ffff7f966c8>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3265 #5 0x00000000004b6b22 in PyEval_EvalCode (co=co at entry=0x7ffff7fb4bb0, globals=globals at entry={'foo': ) at remote 0x7ffff7f966c8>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, locals=locals at entry={'foo': ) at remote 0x7ffff7f966c8>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}) at Python/ceval.c:667 #6 0x00000000004e6d62 in run_mod (arena=0x7f6710, flags=0x7fffffffe300, locals={'foo': ) at remote 0x7ffff7f966c8>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, globals={'foo': ) at remote 0x7ffff7f966c8>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, filename=0x549f56 "", mod=0x835030) at Python/pythonrun.c:1371 #7 PyRun_StringFlags (flags=0x7fffffffe300, locals={'foo': ) at remote 0x7ffff7f966c8>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, globals={'foo': ) at remote 0x7ffff7f966c8>, '__builtins__': , '__package__': None, '__name__': '__main__', 'Foo': , '__doc__': None}, start=257, str=0x7ef010 "\nclass Foo:\n pass\nfoo = Foo()\nfoo.an_attr = foo\nprint foo\n") at Python/pythonrun.c:1334 #8 PyRun_SimpleStringFlags (command=command at entry=0x7ef010 "\nclass Foo:\n pass\nfoo = Foo()\nfoo.an_attr = foo\nprint foo\n", flags=flags at entry=0x7fffffffe300) at Python/pythonrun.c:975 #9 0x0000000000415548 in Py_Main (argc=, argv=) at Modules/main.c:584 #10 0x00007ffff7117af5 in __libc_start_main () from /lib64/libc.so.6 #11 0x0000000000414b91 in _start () ====================================================================== FAIL: test_sets (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of sets ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 299, in test_sets self.assertGdbRepr(set()) File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr self.assertEqual(gdb_repr, repr(val)) AssertionError: 'op at entry=set([])' != 'set([])' ====================================================================== FAIL: test_singletons (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of True, False and None ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 245, in test_singletons self.assertGdbRepr(True) File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr self.assertEqual(gdb_repr, repr(val)) AssertionError: 'op at entry=True' != 'True' ====================================================================== FAIL: test_strings (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of strings ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 262, in test_strings self.assertGdbRepr('') File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr self.assertEqual(gdb_repr, repr(val)) AssertionError: "op at entry=''" != "''" ====================================================================== FAIL: test_subclassing_list (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of an instance of a list subclass ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 385, in test_subclassing_list msg='Unexpected new-style class rendering %r' % gdb_repr) AssertionError: Unexpected new-style class rendering 'op at entry=' ====================================================================== FAIL: test_subclassing_tuple (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of an instance of a tuple subclass ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 399, in test_subclassing_tuple msg='Unexpected new-style class rendering %r' % gdb_repr) AssertionError: Unexpected new-style class rendering 'op at entry=' ====================================================================== FAIL: test_truncation (test.test_gdb.PrettyPrintTests) Verify that very long output is truncated ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 553, in test_truncation "[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, " AssertionError: 'op at entry=[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226...(truncated)' != '[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226...(truncated)' ====================================================================== FAIL: test_tuples (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of tuples ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 269, in test_tuples self.assertGdbRepr(tuple()) File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr self.assertEqual(gdb_repr, repr(val)) AssertionError: 'op at entry=()' != '()' ====================================================================== FAIL: test_unicode (test.test_gdb.PrettyPrintTests) Verify the pretty-printing of unicode values ---------------------------------------------------------------------- Traceback (most recent call last): File "Python-2.7.9/Lib/test/test_gdb.py", line 276, in test_unicode self.assertGdbRepr(u'') File "Python-2.7.9/Lib/test/test_gdb.py", line 226, in assertGdbRepr self.assertEqual(gdb_repr, repr(val)) AssertionError: "op at entry=u''" != "u''" ---------------------------------------------------------------------- Ran 45 tests in 8.235s FAILED (failures=29, skipped=12) 1 test failed: test_gdb ---------- components: Tests messages: 233224 nosy: vlee priority: normal severity: normal status: open title: Python 2.7.9 test_gdb fails on CentOS 7 versions: Python 2.7 _______________________________________ Python tracker _______________________________________