30.09.17 10:10, INADA Naoki пише:
https://github.com/python/cpython/commit/b24cd055ecb3eea9a15405a6ca72dafc739e6531
commit: b24cd055ecb3eea9a15405a6ca72dafc739e6531
branch: master
author: James Sexton
committer: INADA Naoki
date: 2017-09-30T16:10:31+09:00
summary:
bpo-30806 netrc.__repr__() is
On Sep 29, 2017 18:21, "Guido van Rossum" wrote:
PS. PEP 550 is still unaccepted, awaiting a new revision from Yury and
Elvis.
This is getting really off-topic, but I do have updates to add to PEP 555
if there is interest in that. IMO, 555 is better and most likely faster
than 550, but on the
Your PEP is currently incomplete. If you don't finish it, it is not even a
contender. But TBH it's not my favorite anyway, so you could also just
withdraw it.
On Oct 1, 2017 9:13 AM, "Koos Zevenhoven" wrote:
> On Sep 29, 2017 18:21, "Guido van Rossum" wrote:
>
>
> PS. PEP 550 is still unaccepte
On Oct 1, 2017 19:26, "Guido van Rossum" wrote:
Your PEP is currently incomplete. If you don't finish it, it is not even a
contender. But TBH it's not my favorite anyway, so you could also just
withdraw it.
I can withdraw it if you ask me to, but I don't want to withdraw it without
any reason.
See also https://github.com/requests/requests/issues/4315
I tried new `-X importtime` option to `import requests`.
Full output is here:
https://gist.github.com/methane/96d58a29e57e5be97769897462ee1c7e
Currently, it took about 110ms. And major parts are from Python stdlib.
Followings are root of
On Sun, Oct 1, 2017 at 7:04 PM, INADA Naoki wrote:
> 4. http.client
>
> import time: 1376 | 2448 | email.header
> ...
> import time: 1469 | 7791 | email.utils
> import time: 408 | 10646 | email._policybase
> impor
On 10/1/2017 7:34 PM, Nathaniel Smith wrote:
Another major slowness comes from compiling regular expression.
I think we can increase cache size of `re.compile` and use ondemand cached
compiling (e.g. `re.match()`),
instead of "compile at import time" in many modules.
In principle re.compile() it
On Sun, Oct 1, 2017 at 1:52 PM, Koos Zevenhoven wrote:
> On Oct 1, 2017 19:26, "Guido van Rossum" wrote:
>
> Your PEP is currently incomplete. If you don't finish it, it is not even a
> contender. But TBH it's not my favorite anyway, so you could also just
> withdraw it.
>
>
> I can withdraw it
One more thing. I would really appreciate it if you properly wrapped lines
in your PEP around column 72 instead of using a single line per paragraph.
This is the standard convention, see the template in PEP 12.
On Sun, Oct 1, 2017 at 8:42 PM, Guido van Rossum wrote:
> On Sun, Oct 1, 2017 at 1:52
Hope you don't mind me CC'ing python-dev.
On Sun, Oct 1, 2017 at 9:38 AM, Barry Warsaw wrote:
> You seem to be in PEP review mode :)
>
> What do you think about 553? Still want to wait, or do you think it’s
> missing anything? So far, all the feedback has been positive, and I think
> we can ba
> On Oct 1, 2017, at 7:34 PM, Nathaniel Smith wrote:
>
> In principle re.compile() itself could be made lazy -- return a
> regular exception object that just holds the string, and then compiles
> and caches it the first time it's used. Might be tricky to do in a
> backwards compatibility way if
On 10/2/2017 12:44 AM, Guido van Rossum wrote:
- There's no rationale for the *args, **kwds part of the breakpoint()
signature. (I vaguely recall someone on the mailing list asking for it
but it seemed far-fetched at best.)
If IDLE's event-driven GUI debugger were rewritten to run in the user
12 matches
Mail list logo
