[Python-Dev] Store timestamps as decimal.Decimal objects (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Tue Jan 31 12:11:37 CET 2012
- Previous message: [Python-Dev] Store timestamps as decimal.Decimal objects
- Next message: [Python-Dev] Store timestamps as decimal.Decimal objects
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Jan 31, 2012 at 7:42 PM, Victor Stinner <victor.stinner at haypocalc.com> wrote:
I think this is definitely worth elaborating in a PEP (to recap the long discussion in #11457 if nothing else). The discussion in issues #13882 and #11457 already lists many alternatives with their costs and benefits, but I can produce a PEP if you need a summary.
PEPs are about more than just providing a summary - they're about presenting the alternatives in a clear form instead of having them scattered across a long meandering tracker discussion. Laying out the alternatives and clearly articulating their pros and cons (as Larry attempted to do on the tracker) helps to make better decisions.
I counted several options presented as possibilities and I probably missed some:
- expose the raw POSIX (seconds, nanoseconds) 2-tuples (lots of good reasons not to go that way)
- use decimal.Decimal (with or without cdecimal)
- use float128 (nixed due to cross-platform supportability problems)
- use datetime (bad idea for the reasons Martin mentioned)
- use timedelta (not mentioned on the tracker, but a much better fit for a timestamp than datetime, since timestamps are relative to the epoch while datetime objects try to be absolute)
A PEP would also allow the following items to be specifically addressed:
- a survey of what other languages are doing to cope with nanosecond time resolutions (as suggested by Raymond but not actually done as far I could see on the tracker)
- how to avoid a negative performance impact on os.stat() (new API? flag argument? new lazily populated attributes accessed by name only?)
Guido's admonition against analysis paralysis doesn't mean we should go to the other extreme and skip clearly documenting our analysis of complex problems altogether (particularly for something like this which may end up having ramifications for a lot of other time related code).
Having a low-level module like os needing to know about higher-level types like decimal.Decimal and datetime.datetime (or even timedelta) should be setting off all kinds of warning bells. Of all the possibilties that offer decent arithmetic support, timedelta is probably the one currently most suited to being pushed down to the os level, although decimal.Decimal is also a contender if backed up by Stefan's C implementation.
You're right that supporting this does mean being able to at least select between 'int', 'float' and output, but that's the kind of case that can be made most clearly in a PEP.
Cheers, Nick.
-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message: [Python-Dev] Store timestamps as decimal.Decimal objects
- Next message: [Python-Dev] Store timestamps as decimal.Decimal objects
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]