Author vstinner
Recipients Alexander.Belopolsky, Arfrever, belopolsky, eric.smith, loewis, mark.dickinson, pitrou, vstinner
Date 2012-01-29.23:42:14
SpamBayes Score 2.22045e-16
Marked as misclassified No
Message-id <1327880535.51.0.390396847127.issue13882@psf.upfronthosting.co.za>
In-reply-to
Content
> Constant arguments

What do you call a constant argument? "float" and "decimal"? You would prefer a constant like time.FLOAT_FORMAT? Or maybe a boolean (decimal=True)?

I chose a string because my first idea was to add a registry to support other format, maybe user defined formats, like the one used by Unicode codecs.

If we choose to not support other formats, but only float and decimal, a simpler API can be designed.

Another possible format would be "tuple": (intpart: int, floatpart: int, divisor: int), a low level type used to "implement" other user-defined types. Using such tuple, you have all information (clock value and clock resolution) without losing information.

> varying return type

I agree that it is something uncommon in Python. I know os.listdir(bytes)->bytes and os.listdir(str)->str. I suppose that there are other functions with a different result type depending on the input.

I am not attached to my API, it was just a proposition.

> hidden import

Ah? I wouldn't call it hidden because I don't see how a function can return a decimal.Decimal object without importing it. If you consider that it is surprising (unexepected), it can be documented.

> and the list can go on.

What else?

> What is wrong with simply creating a new module, say "hirestime"
> with functions called decimal_time(), float_time(), datetime_time()
> and whatever else you would like.

Hum, adding a new module would need to duplicate code. The idea of adding an argument is also to simplify the implementation: most code is shared. We can still share a lot of code if we choose to add a new function in th time module instead of adding a new argument to existing functions.

> Let's keep the good old 'time' module simple.

What is complex in my patch? It doesn't break backward compatibility and should have a low (or null) overhead in runtime speed if the format is not set.

--

I notified something surprising in my patch: "t1=time.time("decimal"); t2=time.time("decimal"); t2-t1" returns something bigger than 20 ms... That's because the "import decimal" is done after reading the first clock value, and not before.
History
Date User Action Args
2012-01-29 23:42:15vstinnersetrecipients: + vstinner, loewis, mark.dickinson, belopolsky, pitrou, eric.smith, Arfrever, Alexander.Belopolsky
2012-01-29 23:42:15vstinnersetmessageid: <1327880535.51.0.390396847127.issue13882@psf.upfronthosting.co.za>
2012-01-29 23:42:14vstinnerlinkissue13882 messages
2012-01-29 23:42:14vstinnercreate