Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On 18 October 2017 at 05:55, Yury Selivanov wrote: > On Tue, Oct 17, 2017 at 2:25 PM, Guido van Rossum > wrote: > > On Tue, Oct 17, 2017 at 8:54 AM, Yury Selivanov > > [..] > >> My way of thinking about this:

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

I updated my PEP 564 to add time.process_time_ns(): https://github.com/python/peps/blob/master/pep-0564.rst The HTML version should be updated shortly: https://www.python.org/dev/peps/pep-0564/ I better explained why some functions got a new nanosecond variant, whereas others don't. The

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

Antoine Pitrou: > Why not ``time.process_time_ns()``? I measured the minimum delta between two clock reads, ignoring zeros. I tested time.process_time(), os.times(), resource.getrusage(), and their nanosecond variants (with my WIP implementation of the PEP 564). Linux: * process_time_ns(): 1 ns

Re: [Python-Dev] Python startup optimization: script vs. service

Let's kick this part of the discussion back to python-ideas. On Tue, Oct 17, 2017 at 1:36 PM, Michel Desmoulin wrote: > Maybe it's time to bring back the debate on the "lazy" keyword then ? > Rendering any statement arbitrarily lazy could help with perfs. It would >

Re: [Python-Dev] Python startup optimization: script vs. service

Maybe it's time to bring back the debate on the "lazy" keyword then ? Rendering any statement arbitrarily lazy could help with perfs. It would also make hacks like ugettext_lazy in Django useless. And would render moot the extensions of f-strings for lazily rendered ones. And bring lazy imports in

Re: [Python-Dev] PEP 510 (function specialization) rejected

It takes courage to admit failures like this! I think this is a good call. It echoes the experiences with Unladen Swallow and Pyston. Despite what people may think, CPython really isn't slow, given the large set of constraints on the implementation. On Tue, Oct 17, 2017 at 1:10 PM, Victor Stinner

Re: [Python-Dev] PEP 510 (function specialization) rejected

2017-10-17 22:25 GMT+02:00 Guido van Rossum : > It takes courage to admit failures like this! I think this is a good call. > It echoes the experiences with Unladen Swallow and Pyston. Despite what > people may think, CPython really isn't slow, given the large set of > constraints

[Python-Dev] PEP 511 (code transformers) rejected

Hi, I rejected my own PEP 511 "API for code transformers" that I wrote in January 2016: https://github.com/python/peps/commit/9d8fd950014a80324791d7dae3c130b1b64fdace Rejection Notice: """ This PEP was rejected by its author. This PEP was seen as blessing new Python-like programming languages

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Tue, Oct 17, 2017 at 12:51 PM, Nathaniel Smith wrote: > On Oct 17, 2017 11:25 AM, "Guido van Rossum" wrote: > > > In short, I really don't think there's a need for context variables to be > faster than instance variables. > > > There really is: currently the

[Python-Dev] PEP 510 (function specialization) rejected

Hi, I rejected my own PEP 510 "Specialize functions with guards" that I wrote in January 2016: https://github.com/python/peps/commit/c99fb8bf5b5c16c170e1603a1c66a74e93a4ae84 "This PEP was rejected by its author since the design didn't show any significant speedup, but also because of the lack

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Tue, Oct 17, 2017 at 2:25 PM, Guido van Rossum wrote: > On Tue, Oct 17, 2017 at 8:54 AM, Yury Selivanov [..] >> My way of thinking about this: "get_execution_context()" returns you a >> shallow copy of the current EC (at least conceptually). So

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Oct 17, 2017 11:25 AM, "Guido van Rossum" wrote: In short, I really don't think there's a need for context variables to be faster than instance variables. There really is: currently the cost of looking up a thread local through the C API is a dict lookup, which is faster

[Python-Dev] [RELEASE] Python 3.7.0a2 is now available for testing

Python 3.7.0a2 is the second of four planned alpha previews of Python 3.7, the next feature release of Python. During the alpha phase, Python 3.7 remains under heavy development: additional features will be added and existing features may be modified or deleted. Please keep in mind that this is

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

Also, IMO this is all the interface we should need to explain to users (even framework authors): https://github.com/gvanrossum/pep550/blob/master/simpler.py On Tue, Oct 17, 2017 at 11:25 AM, Guido van Rossum wrote: > On Tue, Oct 17, 2017 at 8:54 AM, Yury Selivanov

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Tue, Oct 17, 2017 at 8:54 AM, Yury Selivanov wrote: > On Tue, Oct 17, 2017 at 1:02 AM, Nick Coghlan wrote: > > The reason I say that is because one of the biggest future-proofing > concerns > > when it comes to exposing a mapping as the lowest API

Re: [Python-Dev] Reorganize Python categories (Core, Library, ...)?

Antoine Pitrou wrote: > There is no definite "correct category" when you're mixing different > classification schemes (what kind of bug it is -- > bug/security/enhancement/etc. --, what functional domain it pertains > to -- networking/concurrency/etc. --, which stdlib API it

Re: [Python-Dev] Python startup optimization: script vs. service

Christian Heimes wrote: > That approach could work, but I think that it is the wrong > approach. I'd rather keep Python optimized for long-running > processes and introduce a new mode / option to optimize for > short-running scripts. Another idea is to run a fake

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Tue, Oct 17, 2017 at 1:02 AM, Nick Coghlan wrote: > On 17 October 2017 at 14:31, Guido van Rossum wrote: >> >> No, that version just defers to magic in ContextVar.get/set, whereas what >> I'd like to see is that the latter are just implemented in terms of

Re: [Python-Dev] Timeout for PEP 550 / Execution Context discussion

On Mon, Oct 16, 2017 at 10:02 PM, Nick Coghlan wrote: > On 17 October 2017 at 14:31, Guido van Rossum wrote: > >> No, that version just defers to magic in ContextVar.get/set, whereas what >> I'd like to see is that the latter are just implemented in terms

Re: [Python-Dev] PEP 564: Add new time functions with nanosecond resolution

> Since the ``time.clock()`` function was deprecated in Python 3.3, no > ``time.clock_ns()`` is added. FYI I just proposed a change to *remove* time.clock() from Python 3.7: https://bugs.python.org/issue31803 This change is not required by, nor directly related to, the PEP 564. Victor

[Python-Dev] Two new environment variables to debug Python 2.7

Hi, FYI I just merged two pull requests into Python 2.7, each add a new environment variable changing the behaviour in debug mode: bpo-31733: don't dump "[xxx refs]" into stderr by default anymore Set PYTHONSHOWREFCOUNT=1 commit 3c082a7fdb472f02bcac7a7f8fe1e3a34a11b70b bpo-31692, bpo-19527: