> Keep in mind timedelta has a microsecond resolution. The use cases
> meant for the PEP imply nanosecond resolution (POSIX' clock_gettime(),
> for example).
datetime.datetime and datetime.timedelta can be patched to support nanosecond.
>> A plain number of seconds is superficially simpler, but i
> I don't see any real issue of adding datetime as another accepted
> type, if Decimal is also accepted. Each type has limitations, and the
> user can choose the best type for his/her use case.
>
> I dropped datetime because I prefer incremental changes (and a simpler
> PEP is also more easily acce
> consider changing the default on any of these that return a time
> value. these for example:
> * time.clock_gettime()
> * time.wallclock() (reuse time.clock_gettime(time.CLOCK_MONOTONIC))
Ah. Nanosecond resolution is overkill is common cases, float is enough
and is faster. I prefer to use the
Why is the PEP promoting the float type being used as the default on the
new-in-3.3 APIs that were added explicitly to provide nanosecond level
resolution that cannot be represented by a float?
The *new* APIs should default to the high precision return value (be that
datetime/timedelta or decimal)
On Fri, Feb 3, 2012 at 11:17 AM, Antoine Pitrou wrote:
> On Fri, 3 Feb 2012 11:04:14 -0800
> Jeffrey Yasskin wrote:
>> On Thu, Feb 2, 2012 at 4:59 PM, Nick Coghlan wrote:
>> > datetime.datetime
>> >
>> > - real problem with the idea is that not all timestamps can be easily
>> > made absolute (e.
On Fri, 3 Feb 2012 11:04:14 -0800
Jeffrey Yasskin wrote:
> On Thu, Feb 2, 2012 at 4:59 PM, Nick Coghlan wrote:
> > datetime.datetime
> >
> > - 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
On Thu, Feb 2, 2012 at 4:59 PM, Nick Coghlan wrote:
> datetime.datetime
>
> - 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")
I think this is an argument for returning the
On Fri, Feb 3, 2012 at 3:57 AM, Victor Stinner
wrote:
>> datetime.datetime
>>
>> - as noted earlier in the thread, total_seconds() actually gives you a
>> decent timestamp value and always returning UTC avoids timezone issues
>
> os.stat() and time.time() use the local time.
The documentation dis
> datetime.datetime
>
> - as noted earlier in the thread, total_seconds() actually gives you a
> decent timestamp value and always returning UTC avoids timezone issues
os.stat() and time.time() use the local time. Using UTC would be
completly wrong. It is possible to get the current timezone for
t
Am 03.02.2012 um 01:59 schrieb Nick Coghlan :
> On Fri, Feb 3, 2012 at 10:21 AM, Victor Stinner
> 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/
On Thu, 2 Feb 2012 16:25:25 +0100
Victor Stinner wrote:
> > That said, I don't understand why we couldn't simply deprecate
> > stat_float_times() right now. Having an option for integer timestamps
> > is pointless, you can just call int() on the result if you want.
>
> So which API do you propose
On 2/2/2012 3:38 PM, Nick Coghlan wrote:
On Fri, Feb 3, 2012 at 8:37 AM, Glenn Linderman wrote:
> Sorry to bring this up, but the PEP should probably consider another option:
> Introducing a precedent following os.stat_decimal_times(). Like
> os.stat_float_times, it would decide the return
On Fri, Feb 3, 2012 at 10:21 AM, Victor Stinner
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
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.
Victor
___
Python-De
On Fri, Feb 3, 2012 at 8:37 AM, Glenn Linderman wrote:
> Sorry to bring this up, but the PEP should probably consider another option:
> Introducing a precedent following os.stat_decimal_times(). Like
> os.stat_float_times, it would decide the return types of timestamps from
> os.stat. Or somethi
On 2/2/2012 6:28 AM, Antoine Pitrou wrote:
On Thu, 2 Feb 2012 15:09:41 +0100
Victor Stinner wrote:
Why int? That doesn't seem to bring anything.
It helps to deprecate/replace os.stat_float_times(), which may be used
for backward compatibility (with Python 2.2 ? :-)).
I must admit I don't und
On Wed, Feb 1, 2012 at 5:03 PM, Victor Stinner
wrote:
> datetime.datetime
> -
>
> datetime.datetime only supports microsecond resolution, but can be enhanced
> to support nanosecond.
>
> datetime.datetime has issues:
>
> - there is no easy way to convert it into "seconds since the
On Feb 3, 2012 2:59 AM, "Barry Warsaw" wrote:
>
> On Feb 02, 2012, at 11:07 PM, Nick Coghlan wrote:
>
> >Yup, that's why your middle-ground approach didn't make any sense to
> >me. Returning Decimal when a flag is set to request high precision
> >values actually handles everything (since any epoch
On Feb 02, 2012, at 11:07 PM, Nick Coghlan wrote:
>Yup, that's why your middle-ground approach didn't make any sense to
>me. Returning Decimal when a flag is set to request high precision
>values actually handles everything (since any epoch related questions
>only arise later when converting the d
> That said, I don't understand why we couldn't simply deprecate
> stat_float_times() right now. Having an option for integer timestamps
> is pointless, you can just call int() on the result if you want.
So which API do you propose for time.time() to get a Decimal object?
time.time(timestamp=deci
On Thu, 2 Feb 2012 15:09:41 +0100
Victor Stinner wrote:
> > Why int? That doesn't seem to bring anything.
>
> It helps to deprecate/replace os.stat_float_times(), which may be used
> for backward compatibility (with Python 2.2 ? :-)).
I must admit I don't understand the stat_float_times documen
> Why int? That doesn't seem to bring anything.
It helps to deprecate/replace os.stat_float_times(), which may be used
for backward compatibility (with Python 2.2 ? :-)).
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
On Thu, Feb 2, 2012 at 11:31 PM, M.-A. Lemburg wrote:
> Isn't the above (having the return type depend on an argument
> setting) something we generally try to avoid ?
In Victor's actual patch, the returned object is an instance of the
type you pass in, so it actually avoids that issue.
> I think
Nick Coghlan wrote:
> On Thu, Feb 2, 2012 at 10:16 PM, Victor Stinner
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 so
On Thu, 2 Feb 2012 14:10:14 +0100
Victor Stinner wrote:
> > Even if I like the idea, I don't think that we need all this machinery
> > to support nanosecond resolution. I should maybe forget my idea of
> > using datetime.datetime or datetime.timedelta, or only only support
> > int, float and decim
On Thu, 2 Feb 2012 23:07:28 +1000
Nick Coghlan wrote:
>
> We can't add new fields to the stat tuple anyway - it breaks tuple
> unpacking.
I don't think that's true. The stat tuple already has a varying number
of fields: http://docs.python.org/dev/library/os.html#os.stat
“For backward compatibil
On Thu, Feb 2, 2012 at 11:10 PM, Victor Stinner
wrote:
>> Even if I like the idea, I don't think that we need all this machinery
>> to support nanosecond resolution. I should maybe forget my idea of
>> using datetime.datetime or datetime.timedelta, or only only support
>> int, float and decimal.De
On Thu, Feb 2, 2012 at 10:45 PM, Paul Moore wrote:
> On 2 February 2012 12:16, Victor Stinner wrote:
>> Let's take an NTP timestamp in format (c): (sec=0,
>> floatpart=1, divisor=2**32):
>>
> Decimal(1) * Decimal(10)**-10
>> Decimal('0.01')
> Decimal(1) / D
> Even if I like the idea, I don't think that we need all this machinery
> to support nanosecond resolution. I should maybe forget my idea of
> using datetime.datetime or datetime.timedelta, or only only support
> int, float and decimal.Decimal.
I updated my patch (issue #13882) to only support in
On Thu, Feb 2, 2012 at 10:16 PM, Victor Stinner
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 to
me. Returning Decimal when a flag is set to request hi
On 2 February 2012 12:16, Victor Stinner wrote:
> Let's take an NTP timestamp in format (c): (sec=0,
> floatpart=1, divisor=2**32):
>
Decimal(1) * Decimal(10)**-10
> Decimal('0.01')
Decimal(1) / Decimal(2)**32
> Decimal('0.023283064365386962890625')
>
> Yo
> I'd add datetime.timedelta to this list. It's exactly what timestamps
> are, after all - the difference between the current time and the
> relevant epoch value.
Ah yes, I forgot to mention it, whereas it is listed in the "final
timestamp formats list" :-)
>> * a) (sec, nsec): C timespec struct
On 2 February 2012 03:47, Nick Coghlan wrote:
> Rather than being timestamp specific, such a protocol would be a
> general numeric protocol. If (integer, numerator, denominator) is used
> (i.e. a "mixed number" in mathematical terms), then "__from_mixed__"
> would be an appropriate name. If (integ
On Thu, Feb 2, 2012 at 11:03 AM, Victor Stinner
wrote:
> Even if I am not really conviced that a PEP helps to design an API,
> here is a draft of a PEP to add new timestamp formats to Python 3.3.
> Don't see the draft as a final proposition, it is just a document
> supposed to help the discussion
Even if I am not really conviced that a PEP helps to design an API,
here is a draft of a PEP to add new timestamp formats to Python 3.3.
Don't see the draft as a final proposition, it is just a document
supposed to help the discussion :-)
---
PEP: xxx
Title: New timestamp formats
Version: $Revisi
35 matches
Mail list logo
