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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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/archive%40mail-archive.com
