Movatterモバイル変換
[0]ホーム
[Python-Dev] Store timestamps as decimal.Decimal objects
Nick Coghlanncoghlan at gmail.com
Wed Feb 1 05:08:34 CET 2012
On Wed, Feb 1, 2012 at 12:35 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:> It strikes me as inelegant to have to do so much typing for something> as simple as getting the current time. We should approach the> simplicity of ``time.time(format='decimal')`` or> ``time.decimal_time()``.Getting the current time is simple (you can already do it), gettingaccess to high precision time without performance regressions orbackwards incompatiblities or excessive code duplication is hard.There's a very simple rule in large scale software development:coupling is bad and you should do everything you can to minimise it.Victor's approach throws that out the window by requiring that timeand os know about every possible output format for time values.That's why protocols are so valuable: instead of having MxN points ofinterconnection, you just define a standard protocol as the basis forinteraction, and the consumer of the protocol doesn't need to careabout the details of the provider, they just care about the protocolitself.So, the question becomes how to solve the problem of exposing highresolution timestamps to Python code in a way that:- is applicable not just to time.time(), but also to os.stat(),time.clock(), time.wall_clock() and any other timestamp sources I'veforgotten.- is backwards compatible for all those use cases- doesn't cause a significant performance regression for any of those use cases- doesn't cause excessive coupling between the time and os modules andother parts of Python- doesn't excessively duplicate code- doesn't add too much machinery for a relatively minor problemThe one key aspect that I think Victor's suggestion gets right is thatwe want a way to request high precision time from the *existing* APIs,and that this needs to be selected on a per call basis rather thanglobally for the whole application.The big advantage of going with a callback based approach is that itgives you flexibility and low coupling without any additionalsupporting infrastructure, and you have the full suite of Python toolsavailable to deal with any resulting verbosity issues.For example, it would become *trivial* to write Alexander's suggested"hirestime" module that always returned decimal.Decimal objects: _hires = decimal.Decimal.from_components def time(): return time.time(convert=_hires) def clock(): return time.clock(convert=_hires) def stat(path): return os.stat(path, timestamps=_hires) # etc...PJE is quite right that using a new named protocol rather than acallback with a particular signature could also work, but I don't seea lot of advantages in doing so.On the other hand, if you go with the "named output format","hires=True" or new API approaches, you end up having to decide whatadditional coupling you're going to introduce to time and os. Now, inthis case, I actually think there *is* a reasonable option availableif we decide to go down that path:- incorporate Stefan Krah's cdecimal work into the standard library- add a "hires=False" flag to affected APIs- return a Decimal instance with full available precision if"hires=True" is passed in.- make time and os explicitly depend on the ability to createdecimal.Decimal instancesA hirestime module is even easier to implement in that case: def time(): return time.time(hires=True) def clock(): return time.clock(hires=True) def stat(path): return os.stat(path, hires=True) # etc...All of the other APIs (datetime, timedelta, etc) can then just beupdated to also accept a Decimal object as input, rather than handlingthe (integer, fraction, exponent) callback signature I suggested.Either extreme (full flexibility via a callback API or protocol, orelse settling specifically on decimal.Decimal and explicitly makingtime and os dependent on that type) makes sense to me. A wishy-washymiddle ground that introduces a dependency from time and os ontomultiple other modules *without* making the API user extensibledoesn't seem reasonable at all.Cheers,Nick.-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Devmailing list
[8]ページ先頭