[Python-ideas] RFC: PEP: Add dict.__version__

Chris Angelico rosuav at gmail.com
Sun Jan 10 20:55:24 EST 2016


On Mon, Jan 11, 2016 at 12:39 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Mon, Jan 11, 2016 at 01:15:47AM +0100, Victor Stinner wrote:
>
>> * the behaviour on integer overflow is an implementation detail, it's
>> sad to have to describe it in the specification of a *Python*
>> property. Users expect Python to abtract the hardware
>
>
> Is that a real possibility? A 32-bit counter will overflow, sure, but a
> 64-bit counter starting from zero should never overflow in a human
> lifetime.
>
> Even if we assume a billion increments per second (one per nanosecond),
> it would take over 584 years of continuous operation for the counter to
> overflow. What am I missing?

You're missing that a 32-bit build of Python would then be allowed to
use a 32-bit counter. But if the spec says "64-bit counter", then
yeah, we can pretty much assume that it won't overflow.

Reasonable usage wouldn't include nanosecondly updates; I doubt you
could even achieve 1000 updates a second, sustained over a long period
of time, and that would only overflow every 50ish days. Unless there's
some bizarre lockstep system that forces you to run into the rollover,
it's going to be basically one chance in four billion that you hit the
exact equal counter. So even a 32-bit counter is unlikely to cause
problems in real-world situations; and anyone who's paranoid can just
insist on using a 64-bit build of Python. (Most of us probably are
anyway.)

ChrisA


More information about the Python-ideas mailing list