Movatterモバイル変換
[0]ホーム
[Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
Barry Warsawbarry at python.org
Mon Feb 13 16:26:47 CET 2012
On Feb 13, 2012, at 01:28 AM, Victor Stinner wrote:>I'm still waiting for Nick Coghlan and Guido van Rossum for their>decision on the PEP.Thanks for continuing to work on this Victor. I agree with the generalmotivation behind the PEP, and appreciate your enthusiasm for improving Pythonhere.However, I am still -1 on the solution proposed by the PEP. I still thinkthat migrating to datetime use is a better way to go, rather than aproliferation of the data types used to represent timestamps, along with anAPI to specify the type of data returned.Let's look at each item in the PEPs rationale for discarding the use ofdatetimes: * datetime.datetime only supports microsecond resolution, but can be enhanced to support nanosecond.Great! JFDI! * datetime.datetime has issues with timezone. For example, a datetime object without timezone and a datetime with a timezone cannot be compared.This may be so, but I don't think it causes fatal problems with thisapproach. The APIs returning high resolution datetimes should return naive(i.e. timezone-less) datetimes. If this is done consistently, then most mathon such datetimes (along with high resolution timedeltas) should Just Work.I'm looking at a use case from my flufl.lock library: return datetime.datetime.fromtimestamp( os.stat(self._lockfile).st_mtime)and later, this value is compared: datetime.datetime.now() > release_timeSo with higher resolution naive datetimes, this would still work. I thinkit's fine if the user wants to mix naive and timezone-ful datetimes, they willhave to resolve the compatibility issues, but I think that will be theminority of cases.So this issue should not be a blocker for high resolution datetimes (andtimedeltas). * datetime.datetime has ordering issues with daylight saving time (DST) in the duplicate hour of switching from DST to normal time.Sure, but only for timezone-ful datetimes, right? I can live with that, sinceI have to live with that for all non-naive datetimes anyway, and as Imentioned, I don't think in general it will be a practical problem when usinghigh resolution datetime.s * datetime.datetime is not as well integrated than Epoch timestamps, some functions don't accept this type as input. For example, os.utime() expects a tuple of Epoch timestamps.So, by implication, Decimal is better integrated by virtue of its ability tobe coerced to floats and other numeric stack types? Will users ever have toexplicitly convert Decimal types to use other APIs?I don't think this one is insurmountable either. We could certainly improvethe compatibility of datetimes with other APIs, and in fact, I think we shouldregardless of which direction this PEP takes. You could even argue for EIBTIin converting from datetimes to types acceptable to those other APIs, many ofwhich derive their argument types by virtue of the C APIs underneath.It bothers me that the PEP is proposing that users will now have to beprepared to handle yet another (and potentially *many* more) data types comingfrom what are essentially datetime-like APIs.If it really is impossible or suboptimal to build high resolution datetimesand timedeltas, and to use them in these APIs, then at the very least, the PEPneeds a stronger rationale for why this is. But I think ultimately, it wouldbe better for Python to improve the resolution, and API support for datetimesand timestamps.In any case, thanks for your work in this (and so many other!) areas.Cheers,-Barry-------------- next part --------------A non-text attachment was scrubbed...Name: signature.ascType: application/pgp-signatureSize: 836 bytesDesc: not availableURL: <http://mail.python.org/pipermail/python-dev/attachments/20120213/4a8482c4/attachment.pgp>
More information about the Python-Devmailing list
[8]ページ先頭