Movatterモバイル変換
[0]ホーム
[Python-Dev] PEP: New timestamp formats
Nick Coghlanncoghlan at gmail.com
Thu Feb 2 14:07:28 CET 2012
On Thu, Feb 2, 2012 at 10:16 PM, Victor Stinner<victor.stinner at haypocalc.com> wrote:> If we only support int, float and Decimal, we don't need to add a new> protocol, hardcoded functions are enough :-)Yup, that's why your middle-ground approach didn't make any sense tome. Returning Decimal when a flag is set to request high precisionvalues actually handles everything (since any epoch related questionsonly arise later when converting the decimal timestamp to an absolutetime value).I think a protocol based approach would be *feasible*, but alsooverkill for the specific problem we're trying to handle (i.e.arbitrary precision timestamps). If a dependency from time and os onthe decimal module means we decide to finally incorporate Stefan'scdecimal branch, I consider that a win in its own right (there aresome speed hacks in decimal that didn't fair well in the Py3ktransition because they went from being 8-bit str based to Unicode strbased. They didn't *break* from a correctness point of view, but mymoney would be on they're being pessimisations now instead ofoptimisations).>>> os.stat: add new fields>>> -----------------------> New fields can be optional (add a flag to get them), but I don't like> the idea of a structure with a variable number of fields, especially> because os.stat() structure can be used as a tuple (get a field by its> index).>> Patching os.stat() doesn't solve the problem for the time module anyway.We can't add new fields to the stat tuple anyway - it breaks tupleunpacking. Any new fields would have been accessible by name only(which poses its own problems, but is a solution we've used before -in the codecs module, for example).As you say though, this was never going to be adequate since itdoesn't help with the time APIs.>>> Add an argument to change the result type>>> ----------------------------------------->>>> There should also be a description of the "set a boolean flag to>> request high precision output" approach.>> You mean something like: time.time(hires=True)? Or time.time(decimal=True)?Yeah, I was thinking "hires" as the short form of "high resolution",but it's a little confusing since it also parses as the word "hires"(i.e. "hire"+"s"). "hi_res", "hi_prec" (for "high precision") or"full_prec" (for "full precision") might be better.I don't really like "decimal" as the flag name, since it confuses animplementation detail (using decimal.Decimal) with the design intent(preserving the full precision of the underlying timestamp).Cheers,Nick.-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Devmailing list
[8]ページ先頭