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

On 15 October 2017 at 15:49, Nathaniel Smith wrote: > It's not like this is a new and weird concept in Python either -- e.g. > when you raise an exception, the relevant 'except' block is determined > based on where the 'raise' happens (the runtime stack), not where the > 'raise' was written: > >

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

Nick Coghlan schrieb am 14.10.2017 um 17:46: > 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 abou

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

> (That being said, I'm a big fan of fractions, so I wonder if a Fraction with a constant nano denominator wouldn't fit in here...) It was discussed in depth in PEP 410, and the PEP was rejected. Guido voted for nanoseconds as int, when os.stat_result.st_mtime_ns was added. Victor ___

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

> 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? I asked about adding new functions to 4 different modules: os, resource, signal, time. For example, I dislike the idea of having os and os_ns m

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

On 15 October 2017 at 05: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 >> > get materially different values from "data = list(iter

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

On 15 October 2017 at 06:43, Nick Coghlan wrote: > 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 do

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

On Sun, Oct 15, 2017 at 06:53:58AM +0200, 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 l

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

On 13 October 2017 at 23:30, Yury Selivanov wrote: > At this point of time, there's just one place which describes one well > defined semantics: PEP 550 latest version. Paul, if you have > time/interest, please take a look at it, and say what's confusing > there. Hi Yury, The following is my imp

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

Once again, I think Paul Moore gets to the heart of the issue. Generators are simply confusing & async even more so. Per my earlier email, the fact that generators look like functions, but are not functions, is at the root of the confusion. This next part really gets to the heart of the matter:

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

On 15 October 2017 at 13:51, Amit Green wrote: > Once again, I think Paul Moore gets to the heart of the issue. > > Generators are simply confusing & async even more so. > > Per my earlier email, the fact that generators look like functions, but are > not functions, is at the root of the confusion

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

Let me respond to my own email. I'm sorry I wrote a long email, but I figured I'll have to take the time to write this down carefully (and even in a new thread with a clear title) so that people would know what the discussion was about. Probably I could have done better structuring that email, but

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

Generators are a wonderful feature of the python language, and one of its best idea. They are initially very intuitive to understand & easy to use. However, once you get beyond that; they are actually quite confusing because their behavior is not natural. Thus they have a initial easy learning &

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

On Sun, Oct 15, 2017 at 9:44 AM, Koos Zevenhoven wrote: > So, see below for some more discussion between (it would be useful if some > people could reply to this email and say if and why they agree or disagree > with something below -- also non-experts that roughly understand what I'm > talking a

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

On Sun, Oct 15, 2017 at 5:34 PM, Amit Green wrote: > On Sun, Oct 15, 2017 at 9:44 AM, Koos Zevenhoven > wrote: > >> So, see below for some more discussion between (it would be useful if >> some people could reply to this email and say if and why they agree or >> disagree with something below --

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

I'd like to have time.time_ns() -- this is most parallel to st_mtime_ns. On Sun, Oct 15, 2017 at 2:59 AM, Victor Stinner 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? > > I as

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

On Sun, Oct 15, 2017 at 6:58 PM, Guido van Rossum wrote: > I'd like to have time.time_ns() -- this is most parallel to st_mtime_ns. > > ​ Welcome to the list Guido! You sound like a C programmer. For many people, that was the best language they knew of when they learned to program. But have you e

[Python-ideas] Why not picoseconds?

Since new APIs are expensive and we'd like to be future-proof, why not move to picoseconds? That would be safe until clocks reach the THz barrier, which is quite far away from us. Regards Antoine. On Fri, 13 Oct 2017 16:12:39 +0200 Victor Stinner wrote: > Hi, > > I would like to add new fun

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

On 15.10.2017 07:13, Nick Coghlan wrote: > On 15 October 2017 at 14:53, M.-A. Lemburg wrote: >> The behavior of also deferring the context to time of >> execution should be the non-standard form to not break >> this intuition, otherwise debugging will be a pain and >> writing fully working code wo

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

All joking aside, I actually like it that Python also allows one to interact with lower-level concepts when needed. Maybe there could be even more of this? -- Koos On Sun, Oct 15, 2017 at 8:04 PM, Koos Zevenhoven wrote: > On Sun, Oct 15, 2017 at 6:58 PM, Guido van Rossum > wrote: > >> I'd like

Re: [Python-ideas] Why not picoseconds?

On Sun, Oct 15, 2017 at 8:17 PM, Antoine Pitrou wrote: > > Since new APIs are expensive and we'd like to be future-proof, why not > move to picoseconds? That would be safe until clocks reach the THz > barrier, which is quite far away from us. > > ​I somewhat like the thought, but would everyone

Re: [Python-ideas] Why not picoseconds?

On 2017-10-15 19:02, Koos Zevenhoven wrote: On Sun, Oct 15, 2017 at 8:17 PM, Antoine Pitrou >wrote: Since new APIs are expensive and we'd like to be future-proof, why not move to picoseconds?  That would be safe until clocks reach the THz barrier, which i

Re: [Python-ideas] Why not picoseconds?

I proposed to use nanoseconds because UNIX has 1 ns resolution in timespec, the most recent API, and Windows has 100 ns. Using picoseconds would confuse users who may expect sub-nanosecond resolution, whereas no OS support them currently. Moreover, nanoseconds as int already landed in os.stat and

Re: [Python-ideas] Why not picoseconds?

Hi all, I propose multiples of the Planck time, 5.39 × 10 −44 s. Unlikely computers can be more accurate than that anytime soon. On a more serious note, I am not sure what problem was solved by moving from double to a fixed-precision format. I do know that it now introduced the issue of finding

Re: [Python-ideas] Why not picoseconds?

On 10/15/2017 3:13 PM, Stephan Houben wrote: Hi all, I propose multiples of the Planck time, 5.39 × 10 ^−44 s. Unlikely computers can be more accurate than that anytime soon. On a more serious note, I am not sure what problem was solved by moving from double to a fixed-precision format. I do

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

On Sat, Oct 14, 2017 at 11:46 AM, Nick Coghlan wrote: > > 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 t

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

All this arguing based on "equivalence" between different code fragments is nuts. The equivalences were never meant to be exact, and people don't typically understand code using generators using these equivalencies. The key problem we're trying to address is creating a "context" abstraction that c

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

On Sun, Oct 15, 2017 at 08:04:25PM +0300, Koos Zevenhoven wrote: > On Sun, Oct 15, 2017 at 6:58 PM, Guido van Rossum wrote: > > > I'd like to have time.time_ns() -- this is most parallel to st_mtime_ns. > > > > ​ > Welcome to the list Guido! You sound like a C programmer. For many people, > that

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

Sorry, that's an in-joke. Koos is expressing his disappointment in the rejection of PEP 555 in a way that's only obvious if you're Dutch. On Sun, Oct 15, 2017 at 3:16 PM, Steven D'Aprano wrote: > On Sun, Oct 15, 2017 at 08:04:25PM +0300, Koos Zevenhoven wrote: > > On Sun, Oct 15, 2017 at 6:58 PM

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

It could be: time.time(ns=True) On Sun, Oct 15, 2017 at 7:44 PM, Guido van Rossum wrote: > Sorry, that's an in-joke. Koos is expressing his disappointment in the > rejection of PEP 555 in a way that's only obvious if you're Dutch. > > On Sun, Oct 15, 2017 at 3:16 PM, Steven D'Aprano > wrote: >

Re: [Python-ideas] Why not picoseconds?

On 16 October 2017 at 04:28, Victor Stinner wrote: > I proposed to use nanoseconds because UNIX has 1 ns resolution in > timespec, the most recent API, and Windows has 100 ns. > > Using picoseconds would confuse users who may expect sub-nanosecond > resolution, whereas no OS support them currentl

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

On 15 October 2017 at 20:45, Paul Moore wrote: > On 15 October 2017 at 06:43, Nick Coghlan wrote: > > > # Generator form > > def _results_gen(data): > > for item in data: > > with adjusted_context(): > > yield calculate_result(item) > > > > resul

Re: [Python-ideas] Why not picoseconds?

On Sun, Oct 15, 2017 at 8:40 PM, Nick Coghlan wrote: > Hopefully by the time we decide it's worth worrying about picoseconds in > "regular" code, compiler support for decimal128 will be sufficiently > ubiquitous that we'll be able to rely on that as our 3rd generation time > representation (where

Re: [Python-ideas] Why not picoseconds?

2017-10-15 22:08 GMT+02:00 Eric V. Smith : >From Victor's original message, describing the current functions using 64-bit binary floating point numbers (aka double). They lose precision: "The problem is that Python returns time as a floatting point number > which is usually a 64-bit binary floatti