Re: [Python-ideas] Membership of infinite iterators

Given that: - it doesn't break anything; - the behavior makes sense; - it can avoid the machine freezing when one is not careful; It can be a good idea. Those generators could have iterators that are not themselves and have a __contains__ method behaving accordingly. I only did the mistake of

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

Paul Moore writes: > But I do agree with MAL, it seems wrong to need a helper for this, > even though it's a logical consequence of the other semantics I > described as intuitive :-( It seems to me this is an argument for using Haskell if you want life to be simple. :-) Or, in the spirit of

Re: [Python-ideas] Membership of infinite iterators

בתאריך יום ג׳, 17 באוק׳ 2017, 00:13, מאת Terry Reedy ‏: > On 10/15/2017 9:12 PM, Jason Campbell wrote: > ... > > itertools.cycle could use membership from the underlying iterable > > If the underlying iterable is an iterator, this does not work. You > could define a Cycle class

Re: [Python-ideas] Membership of infinite iterators

On 10/15/2017 9:12 PM, Jason Campbell wrote: I recently came across a bug where checking negative membership (__contains__ returns False) of an infinite iterator will freeze the program. It may seem a bit obvious, but you can check membership in range for example without iterating over the

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

On Mon, Oct 16, 2017 at 6:12 PM, Guido van Rossum wrote: > Sorry about your frustration. I should not have given you hope about PEP > 555 -- it was never going to make it, so I should just have spared you the > effort. Do you want to withdraw it or do I have to actually reject

[Python-ideas] Membership of infinite iterators

I recently came across a bug where checking negative membership (__contains__ returns False) of an infinite iterator will freeze the program. It may seem a bit obvious, but you can check membership in range for example without iterating over the entire range. `int(1e100) in

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

I agree, we shouldn't pursue Todd's proposal. It's too complicated, for too little benefit. On Mon, Oct 16, 2017 at 9:49 AM, Victor Stinner wrote: > 2017-10-16 18:13 GMT+02:00 Todd : > > I am not suggesting implementing a new numeric data type.

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

2017-10-16 18:13 GMT+02:00 Todd : > I am not suggesting implementing a new numeric data type. People wouldn't > use the class directly like they would an int or float, they would simply > use it to define the the precision and numeric type (float, int, decimal). > Then they

Re: [Python-ideas] Why not picoseconds?

On 2017-10-16 16:42, MRAB wrote: > On 2017-10-16 13:30, Greg Ewing wrote: >> Stephan Houben wrote: >> >>> Interestingly, that 2.2e-16 pretty much aligns with the accuracy of the >>> cesium atomic clocks which are currently used to *define* the second. >>> So we move to this new API, we should

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

On Mon, Oct 16, 2017 at 3:58 AM, Victor Stinner wrote: > Hi, > > > What if we had a class, say time.time_base. The user could specify the > base > > units (such as "s", "ns", 1e-7, etc) and the data type ('float', 'int', > > 'decimal', etc.) when the class is

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

Sorry about your frustration. I should not have given you hope about PEP 555 -- it was never going to make it, so I should just have spared you the effort. Do you want to withdraw it or do I have to actually reject it? On Mon, Oct 16, 2017 at 1:56 AM, Koos Zevenhoven wrote: >

Re: [Python-ideas] Why not picoseconds?

On Mon, Oct 16, 2017 at 4:10 PM, Victor Stinner wrote: > 2017-10-16 9:46 GMT+02:00 Stephan Houben : > > Hi all, > > > > I realize this is a bit of a pet peeve of me, since > > in my day job I sometimes get people complaining that > > numerical data

Re: [Python-ideas] Why not picoseconds?

On 2017-10-16 13:30, Greg Ewing wrote: Stephan Houben wrote: Interestingly, that 2.2e-16 pretty much aligns with the accuracy of the cesium atomic clocks which are currently used to *define* the second. So we move to this new API, we should provide our own definition of the second, since those

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

Hi, FYI I proposed the PEP 564 on python-dev. "PEP 564 -- Add new time functions with nanosecond resolution" https://www.python.org/dev/peps/pep-0564/ Victor ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] Why not picoseconds?

2017-10-16 9:46 GMT+02:00 Stephan Houben : > Hi all, > > I realize this is a bit of a pet peeve of me, since > in my day job I sometimes get people complaining that > numerical data is "off" in the sixteenth significant digit > (i.e. it was stored as a double). > (...) Oh.

Re: [Python-ideas] Why not picoseconds?

Stephan Houben wrote: Interestingly, that 2.2e-16 pretty much aligns with the accuracy of the cesium atomic clocks which are currently used to *define* the second. So we move to this new API, we should provide our own definition of the second, since those rough SI seconds are just too imprecise

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

On 16 October 2017 at 21:08, Juancarlo Añez wrote: > > Interestingly, thinking about the problem in terms of exception handling >> flow reminded me of the fact that having a generator-iterator yield while >> inside a with statement or try/except block is already considered an

Re: [Python-ideas] Why not picoseconds?

Hi, FYI I proposed the PEP 564 directly on python-dev. The paragraph about "picosecond": https://www.python.org/dev/peps/pep-0564/#sub-nanosecond-resolution Let's move the discussion on python-dev ;-) Victor ___ Python-ideas mailing list

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

> Interestingly, thinking about the problem in terms of exception handling > flow reminded me of the fact that having a generator-iterator yield while > inside a with statement or try/except block is already considered an > anti-pattern in many situations, precisely because it means that any >

Re: [Python-ideas] Why not picoseconds?

w/r relativistic effects and continental drift - not really. The speed is about 1cm/yr or v = 1e-18 c. Relativistic effect would go like 0.5 * (v/c)**2, so more like 5E-37 in relative rate of proper time. You can just barely capture a few minutes of that even with int128 resolution. As for

Re: [Python-ideas] Why not picoseconds?

Stephan Houben wrote: Do we realize that at this level of accuracy, relativistic time dilatation due to continental drift starts to matter? Probably also want an accurate GPS position for your computer so that variations in the local gravitational field can be taken into account. -- Greg

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

On Mon, Oct 16, 2017 at 2:44 AM, 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. > > Hmm, or more accurately, it has to do with me going crazy because of the

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

I'm completely +1 to Victor. nanosecond integer timestamp is used these days. And no complex newtype or newmodule is not needed for supporting it. INADA Naoki On Fri, Oct 13, 2017 at 11:12 PM, Victor Stinner wrote: > Hi, > > I would like to

Re: [Python-ideas] Why not picoseconds?

On Sun, 15 Oct 2017 22:00:10 -0700 Guido van Rossum wrote: > 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

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

Hi, > What if we had a class, say time.time_base. The user could specify the base > units (such as "s", "ns", 1e-7, etc) and the data type ('float', 'int', > 'decimal', etc.) when the class is initialized. (...) It's easy to invent various funny new types for arbitrary precision. But I prefer

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

2017-10-16 3:19 GMT+02:00 Juancarlo Añez : > It could be: time.time(ns=True) Please read my initial message: """ [PEP 410] was rejected for different reasons: (...) * Guido van Rossum rejected the idea of adding a new optional parameter to change the result type: it's an

Re: [Python-ideas] Why not picoseconds?

On Mon, Oct 16, 2017 at 08:40:33AM +0200, Stephan Houben wrote: > "The problem is that Python returns time as a floatting point number > > which is usually a 64-bit binary floatting number (in the IEEE 754 > > format). This type starts to loose nanoseconds after 104 days." > > > > > Do we realize

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