Alexander Belopolsky added the comment: "nanosecond support [in Python]" is a PEP-size topic. As Victor suggested, "If you are motivated enough, you may update the PEP and write a new one." The tracker does not provide a sufficiently large forum to discuss "nanosecond support" in full generality.
>assuming it worked, this would somewhat be more agreeable ? >class timestamp(int): pass > """measure of time expressed as a number of nanoseconds""" By "working", I assume you mean "if arithmetic operations worked as expected." In this case you are reinventing mxDateTime [1], which is similar to stdlib datetime, but supports a much higher resolution. > Ref. to PEP410 rejection and de facto standard seems a bit expeditive. I don't think so. Possibly, I should have referred to PEP 20, as well, but that is usually implicit. We now have two APIs in stdlib that pass nanosecond-resolution timestamps as plain integers: os.stat() and os.utime(). This is not going to change, so for compatibility reasons, any new type would have to be interchangeable with int. In theory, your timestamp subclass would qualify, but what advantage would it give you over plain int? If you start adding functionality to timestamp, you will quickly end up with something that is half-way between int and either datetime or timedelta. [1] http://www.egenix.com/products/python/mxBase/mxDateTime ---------- status: pending -> open _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23084> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
