Guido van Rossum wrote:
if there is an *actual*
causal link between file A and B, the difference in timestamps should
always be much larger than 100 ns.
And if there isn't a causal link, simultaneity is relative
anyway. To Fred sitting at his computer, file A might have
been created before
Greg Ewing greg.ew...@canterbury.ac.nz writes:
Guido van Rossum wrote:
if there is an *actual* causal link between file A and B, the
difference in timestamps should always be much larger than 100 ns.
And if there isn't a causal link, simultaneity is relative anyway. To
Fred sitting at
Georg Brandl wrote:
Am 16.02.2012 11:14, schrieb Martin v. Löwis:
Am 16.02.2012 10:51, schrieb Victor Stinner:
2012/2/16 Martin v. Löwis mar...@v.loewis.de:
Maybe an alternative PEP could be written that supports the filesystem
copying use case only, using some specialized ns APIs? I really
Maybe it's okay to wait a few years on this, until either 128-bit
floats are more common or cDecimal becomes the default floating point
type? In the mean time for clock freaks we can have a few specialized
APIs that return times in nanoseconds as a (long) integer.
I don't think that the
On Fri, Feb 17, 2012 at 9:33 PM, Victor Stinner
victor.stin...@gmail.com wrote:
Maybe it's okay to wait a few years on this, until either 128-bit
floats are more common or cDecimal becomes the default floating point
type? In the mean time for clock freaks we can have a few specialized
APIs
Victor Stinner victor.stin...@gmail.com wrote:
Can't we improve the compatibility between Decimal and float, e.g. by
allowing Decimal+float? Decimal (base 10) + float (base 2) may loss
precision and this issue matters in some use cases. So we still need a
way to warn the user on loss of
On 02/16/2012 02:14 AM, Martin v. Löwis wrote:
Am 16.02.2012 10:51, schrieb Victor Stinner:
2012/2/16 Martin v. Löwismar...@v.loewis.de:
Maybe an alternative PEP could be written that supports the filesystem
copying use case only, using some specialized ns APIs? I really think
that all you
Am 17.02.2012 10:28, schrieb Steven D'Aprano:
Georg Brandl wrote:
Am 16.02.2012 11:14, schrieb Martin v. Löwis:
Am 16.02.2012 10:51, schrieb Victor Stinner:
2012/2/16 Martin v. Löwis mar...@v.loewis.de:
Maybe an alternative PEP could be written that supports the filesystem
copying use case
Am 15.02.2012 21:06, schrieb Antoine Pitrou:
On Wed, 15 Feb 2012 20:56:26 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
With the quartz in Victor's machine, a single clock takes 0.3ns, so
three of them make a nanosecond. As the quartz may not be entirely
accurate (and also as the CPU
Maybe an alternative PEP could be written that supports the filesystem
copying use case only, using some specialized ns APIs? I really think
that all you need is st_{a,c,m}time_ns fields and os.utime_ns().
I'm -1 on that, because it will make people write complicated code.
Regards,
Martin
2012/2/16 Martin v. Löwis mar...@v.loewis.de:
Maybe an alternative PEP could be written that supports the filesystem
copying use case only, using some specialized ns APIs? I really think
that all you need is st_{a,c,m}time_ns fields and os.utime_ns().
I'm -1 on that, because it will make
Am 16.02.2012 10:51, schrieb Victor Stinner:
2012/2/16 Martin v. Löwis mar...@v.loewis.de:
Maybe an alternative PEP could be written that supports the filesystem
copying use case only, using some specialized ns APIs? I really think
that all you need is st_{a,c,m}time_ns fields and
2012/2/15 Guido van Rossum gu...@python.org:
So using floats we can match 100ns precision, right?
Nope, not to store an Epoch timestamp newer than january 1987:
x=2**29; (x+1e-7) != x # no loss of precision
True
x=2**30; (x+1e-7) != x # lose precision
False
A data point on this specific use case. The following code throws its
assert ~90% of the time in Python 3.2.2 on a modern Linux machine (assuming
foo exists and bar does not):
import shutil
import os
shutil.copy2(foo, bar)
assert os.stat(foo).st_mtime == os.stat(bar).st_mtime
It
PEP author Victor asked
(in http://mail.python.org/pipermail/python-dev/2012-February/116499.html):
Maybe I missed the answer, but how do you handle timestamp with an
unspecified starting point like os.times() or time.clock()? Should we
leave these function unchanged?
If *all* you know is
On Thu, 16 Feb 2012 13:46:18 +0100
Victor Stinner victor.stin...@gmail.com wrote:
Let's try in a ext4 filesystem:
$ ~/prog/python/timestamp/python
Python 3.3.0a0 (default:35d6cc531800+, Feb 16 2012, 13:32:56)
import decimal, os, shutil, time
open(test, x).close()
shutil.copy2(test,
The way Linux does that is to use the time-stamping counter of the
processor (the rdtsc instructions), which (originally) counts one unit
per CPU clock. I believe current processors use slightly different
countings (e.g. through the APIC), but still: you get a resolution
within the clock
If I run your snippet and inspect modification times using `stat`, the
difference is much smaller (around 10 ns, not 1 ms):
$ stat test | \grep Modify
Modify: 2012-02-16 13:51:25.643597139 +0100
$ stat test2 | \grep Modify
Modify: 2012-02-16 13:51:25.643597126 +0100
The loss of precision
Le jeudi 16 février 2012 à 14:20 +0100, Victor Stinner a écrit :
If I run your snippet and inspect modification times using `stat`, the
difference is much smaller (around 10 ns, not 1 ms):
$ stat test | \grep Modify
Modify: 2012-02-16 13:51:25.643597139 +0100
$ stat test2 | \grep
On 02/15/2012 08:12 PM, Guido van Rossum wrote:
On Wed, Feb 15, 2012 at 7:28 PM, Larry Hastingsla...@hastings.org wrote:
I fixed this in trunk last September
(issue 12904); os.utime now preserves all the precision that Python
currently conveys.
So, essentially you fixed this particular issue
$ stat test | \grep Modify
Modify: 2012-02-16 13:51:25.643597139 +0100
$ stat test2 | \grep Modify
Modify: 2012-02-16 13:51:25.643597126 +0100
The loss of precision is not constant: it depends on the timestamp value.
Well, I've tried several times and I can't reproduce a 1 ms
On Thu, Feb 16, 2012 at 2:04 PM, Victor Stinner
victor.stin...@gmail.com wrote:
It doesn't change anything to the Makefile issue, if timestamps are
different in a single nanosecond, they are seen as different by make
(by another program comparing the timestamp of two files using
nanosecond
2012/2/16 Guido van Rossum gu...@python.org:
On Thu, Feb 16, 2012 at 2:04 PM, Victor Stinner
victor.stin...@gmail.com wrote:
It doesn't change anything to the Makefile issue, if timestamps are
different in a single nanosecond, they are seen as different by make
(by another program comparing
On Thu, Feb 16, 2012 at 2:48 PM, Victor Stinner
victor.stin...@gmail.com wrote:
2012/2/16 Guido van Rossum gu...@python.org:
On Thu, Feb 16, 2012 at 2:04 PM, Victor Stinner
victor.stin...@gmail.com wrote:
It doesn't change anything to the Makefile issue, if timestamps are
different in a
The problem is that shutil.copy2() produces sometimes *older*
timestamp :-/ (...)
Have you been able to reproduce this with an actual Makefile? What's
the scenario?
Hum. I asked the Internet who use shutil.copy2() and I found an old
issue (Decimal('43462967.173053') seconds ago):
Python
So, make is unaffected. In my first post on this subject I already
noted that the only real use case is making a directory or filesystem
copy and then verifying that the copy is identical using native tools
that compare times with nsec precision. At least one of the bugs you
quote is about the
On Wed, Feb 15, 2012 at 11:39 AM, Guido van Rossum gu...@python.org wrote:
Maybe it's okay to wait a few years on this, until either 128-bit
floats are more common or cDecimal becomes the default floating point
type?
+1
___
Python-Dev mailing list
Am 16.02.2012 11:14, schrieb Martin v. Löwis:
Am 16.02.2012 10:51, schrieb Victor Stinner:
2012/2/16 Martin v. Löwis mar...@v.loewis.de:
Maybe an alternative PEP could be written that supports the filesystem
copying use case only, using some specialized ns APIs? I really think
that all you
Am 14.02.2012 23:29, schrieb Barry Warsaw:
I think I will just state my reasoning one last time and then leave it to the
BDFL or BDFOP to make the final decision.
I'd like to remind people what the original point of the PEP process
was: to avoid going in cycles in discussions. To achieve this,
On Wed, Feb 15, 2012 at 10:11, Martin v. Löwis mar...@v.loewis.de wrote:
My primary concern with the PEP is adding to users confusion when they have
to
handle (at least) 5 different types[*] that represent time in Python.
I agree with Barry here (despite having voiced support for using
On Wed, Feb 15, 2012 at 7:11 PM, Martin v. Löwis mar...@v.loewis.de wrote:
I agree with Barry here (despite having voiced support for using Decimal
before): datetime.datetime *is* the right data type to represent time
stamps. If it means that it needs to be improved before it can be used
in
I agree with Barry here (despite having voiced support for using Decimal
before): datetime.datetime *is* the right data type to represent time
stamps. If it means that it needs to be improved before it can be used
in practice, then so be it - improve it.
Maybe I missed the answer, but how do
2012/2/15 Martin v. Löwis mar...@v.loewis.de:
I agree with Barry here (despite having voiced support for using Decimal
before): datetime.datetime *is* the right data type to represent time
stamps. If it means that it needs to be improved before it can be used
in practice, then so be it -
I'd like to remind people what the original point of the PEP process
was: to avoid going in cycles in discussions. To achieve this, the PEP
author is supposed to record all objections in the PEP, even if he
disagrees (and may state rebuttals for each objection that people
brought up).
So,
On Feb 15, 2012, at 10:23 AM, Nick Coghlan wrote:
What should timedelta.total_seconds() return to avoid losing nanosecond
precision? How should this be requested when calling the API?
See, I have no problem having this method return a Decimal for high precision
values. This preserves the
On Feb 15, 2012, at 10:11 AM, Martin v. Löwis wrote:
I think improving datetime needs to go in two directions:
a) arbitrary-precision second fractions. My motivation for
proposing/supporting Decimal was that it can support arbitrary
precision, unlike any of the alternatives (except for
PEP author Victor asked
(in http://mail.python.org/pipermail/python-dev/2012-February/116499.html):
Maybe I missed the answer, but how do you handle timestamp with an
unspecified starting point like os.times() or time.clock()? Should we
leave these function unchanged?
If *all* you know is
I just came to this thread. Having read the good arguments on both
sides, I keep wondering why anybody would care about nanosecond
precision in timestamps. Unless you're in charge of managing one of
the few atomic reference clocks in the world, your clock is not going
to tell time that accurate.
On Wed, 15 Feb 2012 08:39:45 -0800
Guido van Rossum gu...@python.org wrote:
What purpose is there to recording timestamps in nanoseconds? For
clocks that start when the process starts running, float *is*
(basically) good enough. For measuring e.g. file access times, there
is no way that the
On Wed, Feb 15, 2012 at 8:47 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 15 Feb 2012 08:39:45 -0800
Guido van Rossum gu...@python.org wrote:
What purpose is there to recording timestamps in nanoseconds? For
clocks that start when the process starts running, float *is*
(basically)
2012/2/15 Guido van Rossum gu...@python.org:
I just came to this thread. Having read the good arguments on both
sides, I keep wondering why anybody would care about nanosecond
precision in timestamps.
Python 3.3 exposes C functions that return timespec structure. This
structure contains a
On Wed, 15 Feb 2012 18:23:55 +0100
Victor Stinner victor.stin...@gmail.com wrote:
Linux supports nanosecond timestamps since Linux 2.6, Windows supports
100 ns resolution since Windows 2000 or maybe before. It doesn't mean
that Windows system clock is accurate: in practical, it's hard to get
On Wed, Feb 15, 2012 at 9:23 AM, Victor Stinner
victor.stin...@gmail.com wrote:
2012/2/15 Guido van Rossum gu...@python.org:
I just came to this thread. Having read the good arguments on both
sides, I keep wondering why anybody would care about nanosecond
precision in timestamps.
Python 3.3
Linux supports nanosecond timestamps since Linux 2.6, Windows supports
100 ns resolution since Windows 2000 or maybe before. It doesn't mean
that Windows system clock is accurate: in practical, it's hard to get
something better than 1 ms :-)
Well, do you think the Linux system clock is
So using floats we can match 100ns precision, right?
On Wed, Feb 15, 2012 at 9:58 AM, Victor Stinner
victor.stin...@gmail.com wrote:
Linux supports nanosecond timestamps since Linux 2.6, Windows supports
100 ns resolution since Windows 2000 or maybe before. It doesn't mean
that Windows system
Le mercredi 15 février 2012 à 18:58 +0100, Victor Stinner a écrit :
It gives me differences smaller than 1000 ns on Ubuntu 11.10 and a
Intel Core i5 @ 3.33GHz:
$ ./a.out
0 s, 781 ns
$ ./a.out
0 s, 785 ns
$ ./a.out
0 s, 798 ns
$ ./a.out
0 s, 818 ns
$ ./a.out
0 s, 270 ns
What is it
*Apart* from the specific use case of making an exact copy of a
directory tree that can be verified by other tools that simply compare
the nanosecond times for equality, I don't see any reason for
complicating so many APIs to preserve the fake precision. As far as
simply comparing whether one
Am 15.02.2012 19:10, schrieb Antoine Pitrou:
Le mercredi 15 février 2012 à 18:58 +0100, Victor Stinner a écrit :
It gives me differences smaller than 1000 ns on Ubuntu 11.10 and a
Intel Core i5 @ 3.33GHz:
$ ./a.out
0 s, 781 ns
$ ./a.out
0 s, 785 ns
$ ./a.out
0 s, 798 ns
$ ./a.out
0
On Wed, 15 Feb 2012 20:56:26 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
With the quartz in Victor's machine, a single clock takes 0.3ns, so
three of them make a nanosecond. As the quartz may not be entirely
accurate (and also as the CPU frequency may change) you have to measure
the
Antoine Pitrou wrote:
On Wed, 15 Feb 2012 20:56:26 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
With the quartz in Victor's machine, a single clock takes 0.3ns, so
three of them make a nanosecond. As the quartz may not be entirely
accurate (and also as the CPU frequency may change) you have
2012/2/15 Mark Shannon m...@hotpy.org:
I reckon PyPy might be able to call clock_gettime() in a tight loop
almost as frequently as the C program (although not with the overhead
of converting to a decimal).
The nanosecond resolution is just as meaningless in C.
--
Regards,
Benjamin
On Wed, Feb 15, 2012 at 11:38 AM, Martin v. Löwis mar...@v.loewis.de wrote:
*Apart* from the specific use case of making an exact copy of a
directory tree that can be verified by other tools that simply compare
the nanosecond times for equality, I don't see any reason for
complicating so many
On 16/02/12 06:43, Guido van Rossum wrote:
This does not explain why microseconds aren't good enough. It seems
none of the clocks involved can actually measure even relative time
intervals more accurate than 100ns, and I expect that kernels don't
actually keep their clock more accurate than
On Wed, Feb 15, 2012 at 6:06 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
On 16/02/12 06:43, Guido van Rossum wrote:
This does not explain why microseconds aren't good enough. It seems
none of the clocks involved can actually measure even relative time
intervals more accurate than 100ns,
Guido van Rossum gu...@python.org writes:
On Wed, Feb 15, 2012 at 6:06 PM, Greg Ewing greg.ew...@canterbury.ac.nz
wrote:
It probably isn't worth the bother for things like file timestamps,
where the time taken to execute the system call that modifies the
file is likely to be several
On 02/15/2012 09:43 AM, Guido van Rossum wrote:
*Apart* from the specific use case of making an exact copy of a
directory tree that can be verified by other tools that simply compare
the nanosecond times for equality,
A data point on this specific use case. The following code throws its
On Wed, Feb 15, 2012 at 7:28 PM, Larry Hastings la...@hastings.org wrote:
On 02/15/2012 09:43 AM, Guido van Rossum wrote:
*Apart* from the specific use case of making an exact copy of a
directory tree that can be verified by other tools that simply compare
the nanosecond times for equality,
A datetime module based approach would need to either use a mix of
datetime.datetime() (when returning an absolute time) and
datetime.timedelta() (when returning a time relative to an unknown
starting point),
Returning a different type depending on the function would be
surprising and
FWIW, I'm with Barry on this; doing more with the datetime types seems
preferable to introducing yet more different stuff to date/time
handling.
On Mon, Feb 13, 2012 at 19:33, Victor Stinner victor.stin...@gmail.com wrote:
Oh, I forgot to mention my main concern about datetime: many functions
IMO supporting nanosecond in datetime and timedelta is an orthogonal issue.
Not if you use it to cast them aside for this issue. ;)
Hum yes, I wanted to say that even if we don't keep datetime as a
supported type for time.time(), we can still patch the type to make it
support nanosecond
On Feb 13, 2012, at 07:33 PM, Victor Stinner wrote:
Oh, I forgot to mention my main concern about datetime: many functions
returning timestamp have an undefined starting point (an no timezone
information ), and so cannot be converted to datetime:
- time.clock(), time.wallclock(),
2012/2/14 Barry Warsaw ba...@python.org:
On Feb 13, 2012, at 07:33 PM, Victor Stinner wrote:
Oh, I forgot to mention my main concern about datetime: many functions
returning timestamp have an undefined starting point (an no timezone
information ), and so cannot be converted to datetime:
-
(Oops, I sent my email by mistake, here is the end of my email)
(...) Ah, timedelta case is different. But I already replied to Nick in this
thread about timedelta. You can also
see arguments against timedelta in the PEP 410.
Victor
___
Python-Dev
I think I will just state my reasoning one last time and then leave it to the
BDFL or BDFOP to make the final decision.
Victor on IRC says that there is not much difference between Decimal and
timedelta, and this may be true from an implementation point of view. From a
cognitive point of view, I
On Wed, Feb 15, 2012 at 8:29 AM, Barry Warsaw ba...@python.org wrote:
My primary concern with the PEP is adding to users confusion when they have to
handle (at least) 5 different types[*] that represent time in Python.
My key question to those advocating the use of timedelta instead of Decimal:
On Tue, Feb 14, 2012 at 2:29 PM, Barry Warsaw ba...@python.org wrote:
I think I will just state my reasoning one last time and then leave it to the
BDFL or BDFOP to make the final decision.
Victor on IRC says that there is not much difference between Decimal and
timedelta, and this may be
On Tue, Feb 14, 2012 at 4:23 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Wed, Feb 15, 2012 at 8:29 AM, Barry Warsaw ba...@python.org wrote:
My primary concern with the PEP is adding to users confusion when they have
to
handle (at least) 5 different types[*] that represent time in Python.
On Tue, Feb 14, 2012 at 5:13 PM, Gregory P. Smith g...@krypto.org wrote:
On Tue, Feb 14, 2012 at 4:23 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Wed, Feb 15, 2012 at 8:29 AM, Barry Warsaw ba...@python.org wrote:
My primary concern with the PEP is adding to users confusion when they have
to
On Feb 13, 2012, at 01:28 AM, Victor Stinner wrote:
I'm still waiting for Nick Coghlan and Guido van Rossum for their
decision on the PEP.
Thanks for continuing to work on this Victor. I agree with the general
motivation behind the PEP, and appreciate your enthusiasm for improving Python
here.
However, I am still -1 on the solution proposed by the PEP. I still think
that migrating to datetime use is a better way to go, rather than a
proliferation of the data types used to represent timestamps, along with an
API to specify the type of data returned.
Let's look at each item in the
Antoine Pitrou conviced me to drop simply the int type: float and
Decimal are just enough. Use an explicit cast using int() to get int.
os.stat_float_times() is still deprecated by the PEP.
Victor
___
Python-Dev mailing list
Python-Dev@python.org
On Tue, Feb 14, 2012 at 4:33 AM, Victor Stinner
victor.stin...@gmail.com wrote:
However, I am still -1 on the solution proposed by the PEP. I still think
that migrating to datetime use is a better way to go, rather than a
proliferation of the data types used to represent timestamps, along with
Hi,
I finished the implementation of the PEP 410 (Use decimal.Decimal
type for timestamps). The PEP:
http://www.python.org/dev/peps/pep-0410/
The implementation:
http://bugs.python.org/issue13882
Rietveld code review tool for this issue:
http://bugs.python.org/review/13882/show
The patch is
On Mon, Feb 13, 2012 at 10:28 AM, Victor Stinner
victor.stin...@gmail.com wrote:
Hi,
I finished the implementation of the PEP 410 (Use decimal.Decimal
type for timestamps). The PEP:
http://www.python.org/dev/peps/pep-0410/
The implementation:
http://bugs.python.org/issue13882
Rietveld
74 matches
Mail list logo
