Re: [Python-ideas] PEP draft: context variables

2017-10-13 Thread Amit Green
really like what Paul Moore wrote here as it matches a *LOT* of what I have been feeling as I have been reading this whole discussion; specifically: - I find the example, and discussion, really hard to follow. - I also, don't understand async, but I do understand generators very

Re: [Python-ideas] PEP draft: context variables

2017-10-13 Thread Ethan Furman
On 10/13/2017 03:30 PM, Yury Selivanov wrote: At this time, we have so many conflicted examples and tangled discussions on these topics, that I myself just lost what everybody is implying by "this semantics isn't obvious to *me*". Which semantics? It's hard to tell. For me, it's not apparent

Re: [Python-ideas] Add a module itertools.recipes

2017-10-13 Thread Lucas Wiman
On Fri, Oct 13, 2017 at 11:35 AM, Chris Angelico wrote: > On Sat, Oct 14, 2017 at 5:16 AM, Antoine Rozo > wrote: > [...] > Can we consider making itertools a package and adding a module > > itertools.recipes that implements all these utilility

Re: [Python-ideas] PEP draft: context variables

2017-10-13 Thread Steve Dower
On 13Oct2017 1132, Yury Selivanov wrote: On Fri, Oct 13, 2017 at 1:45 PM, Ethan Furman wrote: On 10/13/2017 09:48 AM, Steve Dower wrote: On 13Oct2017 0941, Yury Selivanov wrote: Actually, capturing context at the moment of coroutine creation (in PEP 550 v1 semantics)

Re: [Python-ideas] PEP draft: context variables

2017-10-13 Thread Paul Moore
On 13 October 2017 at 19:32, Yury Selivanov wrote: >>> It seems simpler to have one specially named and specially called function >>> be special, rather than make the semantics >>> more complicated for all functions. >> > > It's not possible to special case __aenter__ and

Re: [Python-ideas] Add a module itertools.recipes

2017-10-13 Thread Chris Angelico
On Sat, Oct 14, 2017 at 5:16 AM, Antoine Rozo wrote: > Hello, > > A very useful part of the itertools module's documentation is the section > "Recipes", giving utility functions that use itertools iterators. > But when you want to use one of theese functions, you have to

Re: [Python-ideas] PEP draft: context variables

2017-10-13 Thread Yury Selivanov
On Fri, Oct 13, 2017 at 1:45 PM, Ethan Furman wrote: > On 10/13/2017 09:48 AM, Steve Dower wrote: >> >> On 13Oct2017 0941, Yury Selivanov wrote: > > >>> Actually, capturing context at the moment of coroutine creation (in >>> PEP 550 v1 semantics) will not work at all. Async

[Python-ideas] Add a module itertools.recipes

2017-10-13 Thread Antoine Rozo
Hello, A very useful part of the itertools module's documentation is the section "Recipes", giving utility functions that use itertools iterators. But when you want to use one of theese functions, you have to copy it in your source code (or use external PyPI modules like iterutils). Can we

Re: [Python-ideas] PEP draft: context variables

2017-10-13 Thread Koos Zevenhoven
On Fri, Oct 13, 2017 at 8:45 PM, Ethan Furman wrote: > On 10/13/2017 09:48 AM, Steve Dower wrote: > >> On 13Oct2017 0941, Yury Selivanov wrote: >> > > Actually, capturing context at the moment of coroutine creation (in >>> PEP 550 v1 semantics) will not work at all. Async

Re: [Python-ideas] (PEP 555 subtopic) Propagation of context in async code

2017-10-13 Thread Koos Zevenhoven
On Fri, Oct 13, 2017 at 7:38 PM, Yury Selivanov wrote: > On Fri, Oct 13, 2017 at 11:49 AM, Koos Zevenhoven > wrote: > [..] > > This was my starting point 2.5 years ago, when Yury was drafting this > status > > quo (PEP 492). It looked a lot of PEP 492

Re: [Python-ideas] PEP draft: context variables

2017-10-13 Thread Ethan Furman
On 10/13/2017 09:48 AM, Steve Dower wrote: On 13Oct2017 0941, Yury Selivanov wrote: Actually, capturing context at the moment of coroutine creation (in PEP 550 v1 semantics) will not work at all. Async context managers will break. class AC: async def __aenter__(self):

Re: [Python-ideas] PEP draft: context variables

2017-10-13 Thread Koos Zevenhoven
On Fri, Oct 13, 2017 at 2:07 AM, Stefan Krah wrote: [..] > So the decimal examples can be helpful for understanding, but (except > for the performance issues) shouldn't be the centerpiece of the > discussion. > > > Speaking of performance, I have seen that adressed in Koos'

Re: [Python-ideas] PEP draft: context variables

2017-10-13 Thread Steve Dower
On 13Oct2017 0941, Yury Selivanov wrote: On Fri, Oct 13, 2017 at 3:25 AM, Nick Coghlan wrote: [..] However, considering that coroutines are almost always instantiated at the point where they're awaited, I do concede that creation time context capture would likely also work

Re: [Python-ideas] PEP draft: context variables

2017-10-13 Thread Yury Selivanov
On Fri, Oct 13, 2017 at 3:25 AM, Nick Coghlan wrote: [..] > However, considering that coroutines are almost always instantiated at the > point where they're awaited, I do concede that creation time context capture > would likely also work out OK for the coroutine case, which

Re: [Python-ideas] (PEP 555 subtopic) Propagation of context in async code

2017-10-13 Thread Yury Selivanov
On Fri, Oct 13, 2017 at 11:49 AM, Koos Zevenhoven wrote: [..] > This was my starting point 2.5 years ago, when Yury was drafting this status > quo (PEP 492). It looked a lot of PEP 492 was inevitable, but that there > will be a problem, where each API that uses "blocking IO"

[Python-ideas] (PEP 555 subtopic) Propagation of context in async code

2017-10-13 Thread Koos Zevenhoven
This is a continuation of the PEP 555 discussion in https://mail.python.org/pipermail/python-ideas/2017-September/046916.html And this month in https://mail.python.org/pipermail/python-ideas/2017-October/047279.html If you are new to the discussion, the best point to start reading this might

Re: [Python-ideas] PEP draft: context variables

2017-10-13 Thread Yury Selivanov
On Fri, Oct 13, 2017 at 3:25 AM, Nick Coghlan wrote: [..] > The rationale for this behaviour *does* arise from a refactoring argument: > >async def original_async_function(): > with some_context(): > do_some_setup() > raw_data = await

Re: [Python-ideas] Add time.time_ns(): system clock with nanosecond resolution

2017-10-13 Thread Antoine Pitrou
On Fri, 13 Oct 2017 16:57:28 +0200 Stefan Behnel wrote: > Victor Stinner schrieb am 13.10.2017 um 16:12: > > I would like to add new functions to return time as a number of > > nanosecond (Python int), especially time.time_ns(). > > I might have missed it while skipping

Re: [Python-ideas] Add time.time_ns(): system clock with nanosecond resolution

2017-10-13 Thread Victor Stinner
2017-10-13 16:57 GMT+02:00 Stefan Behnel : > I might have missed it while skipping through your post, but could you > quickly explain why improving the precision of time.time() itself wouldn't > help already? Would double FP precision not be accurate enough here? 80-bit

Re: [Python-ideas] Add time.time_ns(): system clock with nanosecond resolution

2017-10-13 Thread Stefan Behnel
Victor Stinner schrieb am 13.10.2017 um 16:12: > I would like to add new functions to return time as a number of > nanosecond (Python int), especially time.time_ns(). I might have missed it while skipping through your post, but could you quickly explain why improving the precision of time.time()

[Python-ideas] Add time.time_ns(): system clock with nanosecond resolution

2017-10-13 Thread Victor Stinner
Hi, I would like to add new functions to return time as a number of nanosecond (Python int), especially time.time_ns(). It would enhance the time.time() clock resolution. In my experience, it decreases the minimum non-zero delta between two clock by 3 times, new "ns" clock versus current clock:

Re: [Python-ideas] PEP draft: context variables

2017-10-13 Thread Nick Coghlan
On 13 October 2017 at 10:56, Guido van Rossum wrote: > I'm out of energy to debate every point (Steve said it well -- that > decimal/generator example is too contrived), but I found one nit in Nick's > email that I wish to correct. > > On Wed, Oct 11, 2017 at 1:28 AM, Nick