Antoine Pitrou schrieb am 16.10.2017 um 10:20:
> 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 w
Antoine Pitrou:
> Given the implementation costs, hardware decimal128 will only become
> mainstream if there's a strong incentive for it, which I'm not sure
> exists or will ever exist ;-)
Stefan Behnel:
> Then we shouldn't implement the new nanosecond API at all, in order to keep
> pressure on th
Hi all,
Please excuse me for getting a bit off-topic, but I would like
to point out that except for bean-counters who need to be
bug-compatible with accounting standards, decimal
floating point is generally a bad idea.
That is because the worst-case bound on the rounding error
grows linear with t
Hi Victor,
On 10/13/2017 04:12 PM, Victor Stinner wrote:
> I would like to add:
>
> * time.time_ns()
> * time.monotonic_ns()
> * time.perf_counter_ns()
> * time.clock_gettime_ns()
> * time.clock_settime_ns()
due nano vs. pico vs. ...
why not something like (please change '_in' for what you like)
On Thu, Oct 19, 2017 at 9:05 AM, Stephan Houben wrote:
>
> I (quickly) tried to get something to work using the win32 package,
> in particular the win32job functions.
> However, it seems setting
> "ProcessMemoryLimit" using win32job.SetInformationJobObject
> had no effect
> (i.e. a subsequent win
Hi francis,
Le 20 oct. 2017 18:42, "francismb" a écrit :
Hi Victor,
On 10/13/2017 04:12 PM, Victor Stinner wrote:
> I would like to add:
>
> * time.time_ns()
> * time.monotonic_ns()
> * time.perf_counter_ns()
> * time.clock_gettime_ns()
> * time.clock_settime_ns()
due nano vs. pico vs. ...
why
