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

2017-10-14 Thread Nathaniel Smith
On Sat, Oct 14, 2017 at 9:53 PM, M.-A. Lemburg wrote: > I have a hard time seeing the advantage of having a default > where the context at the time of execution is dependent on > where it happens rather than where it's defined. > > IMO, the default should be to use the context where the line > was

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

2017-10-14 Thread Nick Coghlan
On 15 October 2017 at 15:05, Guido van Rossum wrote: > I would like to reboot this discussion (again). It feels to me we're > getting farther and farther from solving any of the problems we might solve. > > I think we need to give up on doing anything about generators; the use > cases point in to

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

2017-10-14 Thread M.-A. Lemburg
On 15.10.2017 06:39, Nick Coghlan wrote: > On 15 October 2017 at 05:47, Paul Moore > wrote: > > On 14 October 2017 at 17:50, Nick Coghlan > wrote: > > If you capture the context eagerly, then there are fewer opportunities > to >

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

2017-10-14 Thread Nick Coghlan
On 15 October 2017 at 14:53, M.-A. Lemburg wrote: > On 15.10.2017 06:39, Nick Coghlan wrote: > > On 15 October 2017 at 05:47, Paul Moore > > wrote: > > > > On 14 October 2017 at 17:50, Nick Coghlan > > wrote: > > > If you captur

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

2017-10-14 Thread Guido van Rossum
I would like to reboot this discussion (again). It feels to me we're getting farther and farther from solving any of the problems we might solve. I think we need to give up on doing anything about generators; the use cases point in too many conflicting directions. So we should keep the semantics t

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

2017-10-14 Thread Nick Coghlan
On 15 October 2017 at 05:47, Paul Moore wrote: > On 14 October 2017 at 17:50, Nick Coghlan wrote: > > If you capture the context eagerly, then there are fewer opportunities to > > get materially different values from "data = list(iterable)" and "data = > > iter(context_capturing_iterable)". > >

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

2017-10-14 Thread Paul Moore
On 14 October 2017 at 17:50, Nick Coghlan wrote: > On 14 October 2017 at 21:56, Paul Moore wrote: > > TL;DR of below: PEP 550 currently gives you what you're after, so your > perspective counts as a preference for "please don't eagerly capture the > creation time context in generators or coroutin

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

2017-10-14 Thread Nick Coghlan
On 14 October 2017 at 21:56, Paul Moore wrote: TL;DR of below: PEP 550 currently gives you what you're after, so your perspective counts as a preference for "please don't eagerly capture the creation time context in generators or coroutines". To give an example: > > async def get_webpage(id)

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

2017-10-14 Thread Antoine Pitrou
On Sun, 15 Oct 2017 01:46:50 +1000 Nick Coghlan wrote: > > Might it make more sense to have a parallel *module* that works with a > different base data type rather than parallel functions within the existing > API? > > That is, if folks wanted to switch to 64-bit nanosecond time, they would > us

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

2017-10-14 Thread Nick Coghlan
On 14 October 2017 at 18:21, Antoine Pitrou wrote: > On Sat, 14 Oct 2017 10:49:11 +0300 > Serhiy Storchaka > wrote: > > I don't like the idea of adding a parallel set of functions. > > > > In the list of alternatives in PEP 410 there is no an idea about fixed > > precision float type with nanose

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

2017-10-14 Thread Paul Moore
On 14 October 2017 at 08:09, Nick Coghlan wrote: > To try and bring this back to synchronous examples that folks may find more > intuitive, I figure it's worth framing the question this way: do we want > people to reason about context variables like the active context is > implicitly linked to the

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

2017-10-14 Thread Antoine Pitrou
On Sat, 14 Oct 2017 10:49:11 +0300 Serhiy Storchaka wrote: > 13.10.17 17:12, Victor Stinner пише: > > 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 experienc

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

2017-10-14 Thread Serhiy Storchaka
13.10.17 17:12, Victor Stinner пише: 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

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

2017-10-14 Thread Nick Coghlan
On 14 October 2017 at 16:06, Antoine Rozo wrote: > I am not searching for an external library (as I pointed, there are some > on PyPI like iterutils or more-itertools). > My point was that recipes are documented in itertools module, but not > implemented in standard library, and it would be usefu

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

2017-10-14 Thread Nick Coghlan
On 14 October 2017 at 08:44, Steve Dower wrote: > > It's not possible to special case __aenter__ and __aexit__ reliably >> (supporting wrappers, decorators, and possible side effects). >> > > Why not? Can you not add a decorator that sets a flag on the code object > that means "do not create a ne