Am 03.02.2012 um 01:59 schrieb Nick Coghlan ncogh...@gmail.com:
On Fri, Feb 3, 2012 at 10:21 AM, Victor Stinner
victor.stin...@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
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
On Fri, Feb 3, 2012 at 3:57 AM, Victor Stinner
victor.stin...@haypocalc.com 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.
On Thu, Feb 2, 2012 at 4:59 PM, Nick Coghlan ncogh...@gmail.com 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
On Fri, 3 Feb 2012 11:04:14 -0800
Jeffrey Yasskin jyass...@gmail.com wrote:
On Thu, Feb 2, 2012 at 4:59 PM, Nick Coghlan ncogh...@gmail.com 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
On Fri, Feb 3, 2012 at 11:17 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 3 Feb 2012 11:04:14 -0800
Jeffrey Yasskin jyass...@gmail.com wrote:
On Thu, Feb 2, 2012 at 4:59 PM, Nick Coghlan ncogh...@gmail.com wrote:
datetime.datetime
- real problem with the idea is that not all
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
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
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 accepted
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 it
On 2 February 2012 03:47, Nick Coghlan ncogh...@gmail.com 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
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 structure,
On 2 February 2012 12:16, Victor Stinner victor.stin...@haypocalc.com 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
On Thu, Feb 2, 2012 at 10:16 PM, Victor Stinner
victor.stin...@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 to
me. Returning Decimal when
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 int,
On Thu, Feb 2, 2012 at 10:45 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 2 February 2012 12:16, Victor Stinner victor.stin...@haypocalc.com wrote:
Let's take an NTP timestamp in format (c): (sec=0,
floatpart=1, divisor=2**32):
Decimal(1) * Decimal(10)**-10
On Thu, Feb 2, 2012 at 11:10 PM, Victor Stinner
victor.stin...@haypocalc.com 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,
On Thu, 2 Feb 2012 23:07:28 +1000
Nick Coghlan ncogh...@gmail.com 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
On Thu, 2 Feb 2012 14:10:14 +0100
Victor Stinner victor.stin...@haypocalc.com 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
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 something like:
On Thu, Feb 2, 2012 at 11:31 PM, M.-A. Lemburg m...@egenix.com 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
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
On Thu, 2 Feb 2012 15:09:41 +0100
Victor Stinner victor.stin...@haypocalc.com 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
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?
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
On Feb 3, 2012 2:59 AM, Barry Warsaw ba...@python.org 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
On Wed, Feb 1, 2012 at 5:03 PM, Victor Stinner
victor.stin...@haypocalc.com 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
On 2/2/2012 6:28 AM, Antoine Pitrou wrote:
On Thu, 2 Feb 2012 15:09:41 +0100
Victor Stinnervictor.stin...@haypocalc.com 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 ?
On Fri, Feb 3, 2012 at 8:37 AM, Glenn Linderman v+pyt...@g.nevcal.com 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
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
___
On Fri, Feb 3, 2012 at 10:21 AM, Victor Stinner
victor.stin...@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
On 2/2/2012 3:38 PM, Nick Coghlan wrote:
On Fri, Feb 3, 2012 at 8:37 AM, Glenn Lindermanv+pyt...@g.nevcal.com 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
On Thu, 2 Feb 2012 16:25:25 +0100
Victor Stinner victor.stin...@haypocalc.com 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
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:
On Thu, Feb 2, 2012 at 11:03 AM, Victor Stinner
victor.stin...@haypocalc.com 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
35 matches
Mail list logo
