[Python-Dev] PEP: New timestamp formats (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Fri Feb 3 01:59:14 CET 2012
- Previous message: [Python-Dev] PEP: New timestamp formats
- Next message: [Python-Dev] PEP: New timestamp formats
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, Feb 3, 2012 at 10:21 AM, Victor Stinner <victor.stinner at haypocalc.com> wrote:
I updated and completed my PEP and published the last draft. It will be available at: http://www.python.org/dev/peps/pep-0410/ ( or read the source: http://hg.python.org/peps/file/tip/pep-0410.txt )
I tried to list all alternatives.
Looks pretty good to me, just a few comments in regards to the descriptions of the alternatives (I'm not advocating for any the rejected options any more, since I'm happy with the current proposal, but the PEP should be clear on our reasons for rejecting them):
decimal.Decimal
- using this by default was considered, but rejected due to the bootstrapping problem (decimals are not builtin) and the compatibility problem (decimals do not play nicely with binary floats)
- the chosen API also relates to the bootstrapping problem - since decimal.Decimal is passed in to the API directly, the builtin modules don't need to perform their own implicit import to get access to the type
datetime.datetime
- as noted earlier in the thread, total_seconds() actually gives you a decent timestamp value and always returning UTC avoids timezone issues
- real problem with the idea is that not all timestamps can be easily made absolute (e.g. some APIs may return "time since system started" or "time since process started")
- the complexity argument used against timedelta also applies
tuple of integers
- option B doesn't force loss of precision, it's just awkward because you have to do a complicated calculation to express the full precision fraction in base 10
- option C only requires that the denominator be expressible as a power of some base. That's the case for all interfaces we're aware of (either a power of 2 or a power of 10).
protocol
- should explicitly note that the "tuple of integers" format discussion is relevant to any such protocol design
- explicitly note that this was rejected as being excessive given the requirements, but that the specific syntax proposed allows this to be introduced later if compelling use cases are discovered
boolean argument
- should note explicitly that this was rejected because we don't generally like having argument values change return types (in cases like 3.3's IOError, where values can determine the specific subclass created, there's still a common parent type).
-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message: [Python-Dev] PEP: New timestamp formats
- Next message: [Python-Dev] PEP: New timestamp formats
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]