> 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. >> We may need more information when adding a new timestamp formats >> later. If we expose the "internal structure" used to compute any >> timestamp format, we cannot change the internal structure later >> without breaking (one more time) the API. > > You're assuming we're ever going to want timestamps that are something > more than just a number. That's a *huge* leap (much bigger than > increasing the precision, which is the problem we're dealing with > now). 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. It doesn't mean that we should add datetime.datetime or datetime.timedelta right now. It can be done later, or never :-) > No, you wouldn't add a timestamp specific method to the Decimal class > - you'd add one that let you easily construct a decimal from a fixed > point representation (i.e. integer + fraction*10**exponent) Only if you use (intpart, floatpart, exponent). Would this function be useful for something else than timestamps? > 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. > 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. Internally, it would help to support Windows timestamps (number of 100 ns since 1601.1.1), even if we may have to convert the Windows timestamp to a Epoch timestamp if the user requests a number instead of a datetime object (for backward compatibility ?). Victor _______________________________________________ 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
