bpo-36558: Change time.mktime() return type from float to int?
Hi, time.mktime() looks "inconsistent" to me and I would like to change it, but I'm not sure how it impacts backward compatibility. https://bugs.python.org/issue36558 time.mktime() returns a floating point number:
type(time.mktime(time.localtime())) <class 'float'>
The documentation says: "It returns a floating point number, for compatibility with :func:`.time`." time.time() returns a float because it has sub-second resolution, but the C function mktime() returns an integer number of seconds. Would it make sense to change mktime() return type from float to int? I would like to change mktime() return type to make the function more consistent: all inputs are integers, it sounds wrong to me to return float. The result should be integer as well. How much code would it break? I guess that the main impact are unit tests relying on repr(time.mktime(t)) exact value. But it's easy to fix the tests: use int(time.mktime(t)) or "%.0f" % time.mktime(t) to never get ".0", or use float(time.mktime(t))) to explicitly cast for a float (that which be a bad but quick fix). Note: I wrote and implemented the PEP 564 to avoid any precision loss. mktime() will not start loosing precision before year 285,422,891 (which is quite far in the future ;-)). Victor -- Night gathers, and now my watch begins. It shall not end until my death.
I already chimed in on the issue, but for the list, I'll boil my comments down to two questions: 1. For anyone who knows: when the documentation refers to "compatibility with `.time`", is that just saying it was designed that way because .time returns a float (i.e. for /consistency/ with `.time()`), or is there some practical reason that you would want `.time()` and `.mktime()` to return the same type? 2. Mainly for Victor, but anyone can answer: I agree that the natural output of `mktime()` would be `int` if I were designing it today, but would there be any /practical/ benefits for making this change? Are there problems cropping up because it's returning a float? Is it faster to return an integer? Best, Paul On 4/16/19 10:24 AM, Victor Stinner wrote:
Hi,
time.mktime() looks "inconsistent" to me and I would like to change it, but I'm not sure how it impacts backward compatibility. https://bugs.python.org/issue36558
time.mktime() returns a floating point number:
type(time.mktime(time.localtime())) <class 'float'>
The documentation says:
"It returns a floating point number, for compatibility with :func:`.time`."
time.time() returns a float because it has sub-second resolution, but the C function mktime() returns an integer number of seconds.
Would it make sense to change mktime() return type from float to int?
I would like to change mktime() return type to make the function more consistent: all inputs are integers, it sounds wrong to me to return float. The result should be integer as well.
How much code would it break? I guess that the main impact are unit tests relying on repr(time.mktime(t)) exact value. But it's easy to fix the tests: use int(time.mktime(t)) or "%.0f" % time.mktime(t) to never get ".0", or use float(time.mktime(t))) to explicitly cast for a float (that which be a bad but quick fix).
Note: I wrote and implemented the PEP 564 to avoid any precision loss. mktime() will not start loosing precision before year 285,422,891 (which is quite far in the future ;-)).
Victor
Le mar. 16 avr. 2019 à 16:44, Paul Ganssle <paul@ganssle.io> a écrit :
2. Mainly for Victor, but anyone can answer: I agree that the natural output of `mktime()` would be `int` if I were designing it today, but would there be any practical benefits for making this change?
It's just for the consistency of the function regarding to C function mktime() return type and its input types :-)
Are there problems cropping up because it's returning a float?
None. Victor -- Night gathers, and now my watch begins. It shall not end until my death.
On Tue, Apr 16, 2019 at 8:19 AM Victor Stinner <vstinner@redhat.com> wrote:
2. Mainly for Victor, but anyone can answer: I agree that the natural output of `mktime()` would be `int` if I were designing it today, but would
Le mar. 16 avr. 2019 à 16:44, Paul Ganssle <paul@ganssle.io> a écrit : there be any practical benefits for making this change?
It's just for the consistency of the function regarding to C function mktime() return type and its input types :-)
But all Python times are reported or accept floats -- this allows sub-second precision without using complicated data structures. None of the C functions use floats. Consistency with C should not be the issue -- consistency between the time functions is important.
Are there problems cropping up because it's returning a float?
None.
So let's drop the idea.
Victor -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
I would like to change mktime() return type to make the function more consistent: all inputs are integers, it sounds wrong to me to return float. The result should be integer as well. In C, the signature of mktime is time_t mktime(struct tm *time); from Wikipedia, the Unix time_t data type, on many platforms, is a signed integer, tradionally (32bits). In the newer operating systems, time_t has been widened to 64 bits.
-- Stéphane Wirtel - https://wirtel.be - @matrixise
On 16.04.2019 17:24, Victor Stinner wrote:
Hi,
time.mktime() looks "inconsistent" to me and I would like to change it, but I'm not sure how it impacts backward compatibility. https://bugs.python.org/issue36558
time.mktime() returns a floating point number:
type(time.mktime(time.localtime())) <class 'float'>
The documentation says:
"It returns a floating point number, for compatibility with :func:`.time`."
time.time() returns a float because it has sub-second resolution, but the C function mktime() returns an integer number of seconds.
Would it make sense to change mktime() return type from float to int?
I would like to change mktime() return type to make the function more consistent: all inputs are integers, it sounds wrong to me to return float. The result should be integer as well.
How much code would it break? I guess that the main impact are unit tests relying on repr(time.mktime(t)) exact value. But it's easy to fix the tests: use int(time.mktime(t)) or "%.0f" % time.mktime(t) to never get ".0", or use float(time.mktime(t))) to explicitly cast for a float (that which be a bad but quick fix). I envision it breaking code that relies on implicitly inferring the type of the result from the types of both operands (e.g. arithmetic operations). But for mktime() specifically, I presume the amount of such code very small. Note: I wrote and implemented the PEP 564 to avoid any precision loss. mktime() will not start loosing precision before year 285,422,891 (which is quite far in the future ;-)).
Victor
-- Regards, Ivan
participants (5)
-
Guido van Rossum -
Ivan Pozdeev -
Paul Ganssle -
Stéphane Wirtel -
Victor Stinner