[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

2016-11-07 Thread Yury Selivanov
Yury Selivanov added the comment: See https://github.com/python/asyncio/pull/452. I believe that the issue is not resolved (almost). What's left is documenting how to use get_event_loop and when to use explicit/implicit loop passing. Closing this issue. Will open a new one for the documentat

[issue28637] Python startup performance regression

2016-11-07 Thread STINNER Victor
STINNER Victor added the comment: Hum strange, the changeset d903a243c281 (the revert) optimized regex_compile: 480 ms (rev 573bc1f9900e) => 403 ms (rev cf7711887b4a). But it didn't restore python_startup performance: 26.ms (rev 573bc1f9900e) => 24.6 ms (rev cf7711887b4a). Another change made

[issue28637] Python startup performance regression

2016-11-07 Thread Guido van Rossum
Guido van Rossum added the comment: Agreed. --Guido (mobile) -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue28637] Python startup performance regression

2016-11-07 Thread STINNER Victor
STINNER Victor added the comment: python_startup: * 2.7: 7.74 ms +- 0.28 ms * 3.4: 18.7 ms +- 0.4 ms * 3.5: 20.3 ms +- 0.7 ms * 3.6: 26.9 ms +- 0.6 ms (rev c4319c0d0131, before the revert) * 3.7: 26.6 ms +- 0.5 ms (rev 36af3566b67a, before the revert) * 3.7: 24.6 ms +- 0.0 ms (rev cf7711887b4a,

[issue28637] Python startup performance regression

2016-11-07 Thread Guido van Rossum
Guido van Rossum added the comment: So what does that benchmark measure? For me, python 3.6 startup is 44 ms and python 2.7 startup is 78 ms (real time; user time is proportionally less). On Mon, Nov 7, 2016 at 5:40 PM, STINNER Victor wrote: > > STINNER Victor added the comment: > > python_sta

[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

2016-11-07 Thread Ilya Kulakov
Ilya Kulakov added the comment: I'm very happy that the issue is finally resolved. But a bit offended that it took Andrew only 4 days to push it :) > On 07 Nov 2016, at 17:04, Yury Selivanov wrote: > > > Yury Selivanov added the comment: > > See https://github.com/python/asyncio/pull/452. I

[issue28023] python-gdb.py must be updated for the new Python 3.6 compact dict

2016-11-07 Thread INADA Naoki
Changes by INADA Naoki : -- nosy: +ned.deily priority: high -> release blocker stage: patch review -> commit review ___ Python tracker ___ ___

[issue28563] Arbitrary code execution in gettext.c2py

2016-11-07 Thread Xiang Zhang
Xiang Zhang added the comment: > Sorry Xiang, but your patch looks overcomplicated to me. Too much methods, > decorators, classes, too much strange names. It's fine. That's a Pratt parser. Yes, the names are strange. Your patch looks more simpler. I left several comments. --

[issue28638] Creating namedtuple is too slow

2016-11-07 Thread INADA Naoki
New submission from INADA Naoki: I surprised how functools make import time slower. And I find namedtuple makes it slower. When I replaced _CacheInfo = namedtuple("CacheInfo", ["hits", "misses", "maxsize", "currsize"]) this line with `_CachedInfo._source`: (before) $ ~/local/py37/bin/python3

[issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools)

2016-11-07 Thread INADA Naoki
Changes by INADA Naoki : -- components: +Library (Lib) title: Creating namedtuple is too slow -> Creating namedtuple is too slow to be used in common stdlib (e.g. functools) versions: +Python 3.6, Python 3.7 ___ Python tracker

[issue28572] IDLE: add tests for config dialog.

2016-11-07 Thread Roundup Robot
Roundup Robot added the comment: New changeset f604b6ebd802 by Terry Jan Reedy in branch '3.6': Issue #28572: Use system-specific values for configdialog font test https://hg.python.org/cpython/rev/f604b6ebd802 -- ___ Python tracker

[issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools)

2016-11-07 Thread INADA Naoki
INADA Naoki added the comment: I feel this patch is safe enough to be landed in 3.6. -- keywords: +patch Added file: http://bugs.python.org/file45386/28638-functools-no-namedtuple.patch ___ Python tracker _

[issue28639] inspect.isawaitable(native_coro) returns int

2016-11-07 Thread Justin Mayfield
New submission from Justin Mayfield: Patch available on my github fork.. https://github.com/mayfield/cpython/commit/8d50cc61f42fa280d380e9c10c420c949a619bef -- components: asyncio messages: 280280 nosy: Justin Mayfield, gvanrossum, yselivanov priority: normal severity: normal status: op

[issue28639] inspect.isawaitable(native_coro) returns int

2016-11-07 Thread Yury Selivanov
Yury Selivanov added the comment: Thank you! Will merge it tomorrow. -- assignee: -> yselivanov components: +Library (Lib) -asyncio nosy: -gvanrossum versions: -Python 3.5 ___ Python tracker ___

[issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools)

2016-11-07 Thread Xiang Zhang
Xiang Zhang added the comment: I doubt this deserves a change. The slow import is the case only the first time functools is imported. Later imports will just use the cache (sys.modules). And if this is gonna change, maybe we don't have to copy the entire namedtuple structure? -- nosy:

[issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools)

2016-11-07 Thread Xiang Zhang
Changes by Xiang Zhang : -- nosy: +ncoghlan, rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:/

[issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools)

2016-11-07 Thread INADA Naoki
INADA Naoki added the comment: > The slow import is the case only the first time functools is imported. Later > imports will just use the cache (sys.modules). Yes. But first import time is also important for CLI applications. That's why mercurial and Bazaar has lazy import system. Since many s

[issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools)

2016-11-07 Thread Xiang Zhang
Xiang Zhang added the comment: > Yes. But first import time is also important for CLI applications. That's why mercurial and Bazaar has lazy import system. The lazy import system could benefit many libs so the result could be impressive. But here only functools is enhanced, half a millisecond i

[issue21590] Systemtap and DTrace support

2016-11-07 Thread Berker Peksag
Changes by Berker Peksag : -- stage: patch review -> resolved ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools)

2016-11-07 Thread INADA Naoki
INADA Naoki added the comment: > The lazy import system could benefit many libs so the result could be > impressive. But here only functools is enhanced, half a millisecond is > reduced. On the other hand, implementing lazy import makes application complex. This patch only enhance functools,

[issue28555] provid also sha-1 and sha-256 also on download links

2016-11-07 Thread Benjamin Peterson
Benjamin Peterson added the comment: md5 is provided to verify the integrity of the download only. Use the GPG signatures to verify authenticity if the fact that all the downloads are served over HTTPS is insufficient. -- nosy: +benjamin.peterson resolution: -> wont fix status: open -

<    1   2