On Wed, Feb 1, 2012 at 9:40 PM, Victor Stinner <victor.stin...@haypocalc.com> wrote: >> If a callback protocol is used at all, there's no reason those details >> need to be exposed to the callbacks. Just choose an appropriate >> exponent based on the precision of the underlying API call. > > If the clock divisor cannot be written as a power of 10, you loose > precision, just because your format requires a power of 10. Using > (seconds, floatpart, divisor) you don't loose any bit. The conversion > function using this tuple can choose how to use these numbers and do > its best to optimize the precision (e.g. choose how to round the > division). > > By the way, my patch uses a dummy integer division (floatpart / > divisor). I hesitate to round to the closest integer. For example, > 19//10=1, whereas 2 whould be a better answer. A possibility is to use > (floatpart + (divisor/2)) / divisor.
If you would lose precision, make the decimal exponent (and hence fractional part) larger. You have exactly the same problem when converting to decimal, and the solution is the same (i.e. use as many significant digits as you need to preserve the underlying precision). > I tried to design an API supporting future timestamp formats. For time > methods, it is maybe not useful to produce directly a datetime object. > But for os.stat(), it is just *practical* to get directly a high-level > object. > > We may add a new float128 type later, and it would nice to be able to > get a timestamp directly as a float128, without having to break the > API one more time. Getting a timestamp as a Decimal to convert it to > float128 is not optimal. That's why I don't like adding a boolean > flag. Introducing API complexity now for entirely theoretical future needs is a classic case of YAGNI (You Ain't Gonna Need It). Besides, float128 is a bad example - such a type could just be returned directly where we return float64 now. (The only reason we can't do that with Decimal is because we deliberately don't allow implicit conversion of float values to Decimal values in binary operations). >> But this gets us to my final question. Given that Decimal supports >> arbitrary precision, *why* increase the complexity of the underlying >> API by supporting *other* output types? > > We need to support at least 3 formats: int, float and <high resolution > format> (e.g. Decimal), to keep backward compatibilty. int and float are already supported today, and a process global switch works for that (since they're numerically interoperable). A per-call setting is only needed for Decimal due to its deliberate lack of implicit interoperability with binary floats. >> datetime, timedelta and so forth would be able to get everything >> they needed from the Decimal value. > > Yes. Getting timestamps directly as datetime or timedelta is maybe overkill. > > datetime gives more information than a raw number (int, float or > Decimal): you don't have to care the start date of the timestamp. That's a higher level concern though - not something the timestamp APIs themselves should be worrying about. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
