[Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review (original) (raw)

Barry Warsaw barry 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 general motivation behind the PEP, and appreciate your enthusiasm for improving Python here.

However, I am still -1 on the solution proposed by the PEP. I still think that migrating to datetime use is a better way to go, rather than a proliferation of the data types used to represent timestamps, along with an API to specify the type of data returned.

Let's look at each item in the PEPs rationale for discarding the use of datetimes:

Great! JFDI!

This may be so, but I don't think it causes fatal problems with this approach. The APIs returning high resolution datetimes should return naive (i.e. timezone-less) datetimes. If this is done consistently, then most math on 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_time

So with higher resolution naive datetimes, this would still work. I think it's fine if the user wants to mix naive and timezone-ful datetimes, they will have to resolve the compatibility issues, but I think that will be the minority of cases.

So this issue should not be a blocker for high resolution datetimes (and timedeltas).

Sure, but only for timezone-ful datetimes, right? I can live with that, since I have to live with that for all non-naive datetimes anyway, and as I mentioned, I don't think in general it will be a practical problem when using high resolution datetime.s

So, by implication, Decimal is better integrated by virtue of its ability to be coerced to floats and other numeric stack types? Will users ever have to explicitly convert Decimal types to use other APIs?

I don't think this one is insurmountable either. We could certainly improve the compatibility of datetimes with other APIs, and in fact, I think we should regardless of which direction this PEP takes. You could even argue for EIBTI in converting from datetimes to types acceptable to those other APIs, many of which 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 be prepared to handle yet another (and potentially many more) data types coming from what are essentially datetime-like APIs.

If it really is impossible or suboptimal to build high resolution datetimes and timedeltas, and to use them in these APIs, then at the very least, the PEP needs a stronger rationale for why this is. But I think ultimately, it would be better for Python to improve the resolution, and API support for datetimes and 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.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://mail.python.org/pipermail/python-dev/attachments/20120213/4a8482c4/attachment.pgp>

More information about the Python-Dev mailing list