[issue11457] Expose nanosecond precision from system calls

2011-09-29 Thread Ezio Melotti
Changes by Ezio Melotti : -- stage: -> test needed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue11457] Expose nanosecond precision from system calls

2011-09-26 Thread Larry Hastings
Larry Hastings added the comment: Mark Dickinson wrote: > I think this could work. "could"? Oh ye of little faith! Attached is a patch against a nice fresh trunk (2b47f0146639) that adds Decimal attributes "ctime", "mtime", and "atime" to the object returned by os.stat(). The functions tha

[issue11457] Expose nanosecond precision from system calls

2011-09-12 Thread Mark Dickinson
Mark Dickinson added the comment: > I propose adding the Decimal fields "ctime", "atime", and "mtime" to the > > named tuple returned by os.stat(). That would be an interesting precedent: I don't think there are many (any?) other places outside the 'decimal' module that deal with Decimal obj

[issue11457] Expose nanosecond precision from system calls

2011-09-11 Thread Martin v . Löwis
Martin v. Löwis added the comment: > As I wrote before, I would prefer to keep the same number of fields > in the Python structure and in the C structure, but I don't have a > strong opinion on this choice. I'm with Larry - exposing time fields as structured records is hostile to the programmer

[issue11457] Expose nanosecond precision from system calls

2011-09-11 Thread STINNER Victor
STINNER Victor added the comment: > If a two-ints representation > is considered necessary, I'd favor a rational number (numerator, > denominator) over a pair (second, subsecond); this would also support > 2**-32 fractions (as used in NTP !!!). Which OS uses NTP timestamps in stat()? Or are you

[issue11457] Expose nanosecond precision from system calls

2011-09-11 Thread Martin v . Löwis
Martin v. Löwis added the comment: > The quad-precision float would be highly portable Larry, please stop this discussion in this issue. I believe a PEP would be needed, and would likely be rejected because of the very very very long list of issues that can't be resolved. I think you seriously

[issue11457] Expose nanosecond precision from system calls

2011-09-11 Thread Larry Hastings
Larry Hastings added the comment: Victor STINNER: > Python is compiled using Visual Studio 2008 on Windows. Portability > does matter on Python. If a type is not available on *all* platforms > (including some old platforms, e.g. FreeBSD 6 or Windows XP), we > cannot use it by default. The quad-

[issue11457] Expose nanosecond precision from system calls

2011-09-11 Thread STINNER Victor
STINNER Victor added the comment: "As I mentioned earlier in this thread, GCC has supported __float128 since 4.3, Clang added support within the last year, and Intel has a _Quad type. All are purported to be IEEE 754-2008 quad-precision floats. Glibc added "quadmath.h" recently (maybe in 4.

[issue11457] Expose nanosecond precision from system calls

2011-09-11 Thread Larry Hastings
Larry Hastings added the comment: Mark Dickinson: > > I realize a new float type would be a major undertaking > That's an understatement and a half. The only way this could ever > be viable is if float128 support becomes widespread enough that we > don't have to write our own algorithms for ba

[issue11457] Expose nanosecond precision from system calls

2011-09-10 Thread Mark Dickinson
Mark Dickinson added the comment: [about adding float128] > I realize a new float type would be a major undertaking That's an understatement and a half. The only way this could ever be viable is if float128 support becomes widespread enough that we don't have to write our own algorithms for

[issue11457] Expose nanosecond precision from system calls

2011-09-09 Thread Alexander Belopolsky
Alexander Belopolsky added the comment: On Fri, Sep 9, 2011 at 6:18 PM, Larry Hastings wrote: .. > I've drawn an ASCII table summarizing the proposals so far. You did not mention "closely matches C API" as an upside. -- ___ Python tracker

[issue11457] Expose nanosecond precision from system calls

2011-09-09 Thread Alexander Belopolsky
Alexander Belopolsky added the comment: On Fri, Sep 9, 2011 at 5:42 PM, Larry Hastings wrote: .. > How is this superior to using either Decimal or float128? It is explicit about the units of time used. If we use named tuples and retain C API field names, stat_result.tv_atimespec.tv_sec will c

[issue11457] Expose nanosecond precision from system calls

2011-09-09 Thread Larry Hastings
Larry Hastings added the comment: s/pair-of-floats/pair-of-ints/ Also, to be clear: yocto is the smallest defined SI prefix. And what I meant when I referred to 10**-3 was, float128 could handle 10**-24 but not 10**-27. According to my back-of-the-envelope calculations, float128 could accur

[issue11457] Expose nanosecond precision from system calls

2011-09-09 Thread Larry Hastings
Larry Hastings added the comment: I've drawn an ASCII table summarizing the proposals so far. If I've made any factual errors I trust you'll let me know. = means os.stat().st_mtime is changed to that type. + means os.stat() grows a new field using that type, and the current behavior of st_

[issue11457] Expose nanosecond precision from system calls

2011-09-09 Thread Martin v . Löwis
Martin v. Löwis added the comment: > This predates both the inclusion of Decimal in Python (2.4) and > nanosecond resolution in the utime API (2008). I could find no > discussion of the change, so I don't know what other representations > were considered. It's hard to say what the author of th

[issue11457] Expose nanosecond precision from system calls

2011-09-09 Thread Larry Hastings
Larry Hastings added the comment: > To support higher resolution > will need to supply 3 fields in st_xtimesuperspec: tv_sec and tv_nsec > packed in st_xtimespec (say tv_timespec) and new tv_psec field. > st_xtime will now be st_xtimesuperspec.tv_timespec.tv_sec and > st_xtimespec will be a ne

[issue11457] Expose nanosecond precision from system calls

2011-09-09 Thread Alexander Belopolsky
Alexander Belopolsky added the comment: On Fri, Sep 9, 2011 at 5:22 PM, Alexander Belopolsky wrote: .. > If history repeats, struct stat will grow new st_xtimesuperspec > fields, st_xtimespec will become a macro expanding to > st_xtimesuperspec.tv_picosec On the second thought, this won't work

[issue11457] Expose nanosecond precision from system calls

2011-09-09 Thread Alexander Belopolsky
Alexander Belopolsky added the comment: On Fri, Sep 9, 2011 at 4:50 PM, Larry Hastings wrote: .. > I think a pair of integers is a poor API.  It ties the value of the > fractional part to nanoseconds.  What happens > when a future filesystem implements picosecond resolution? If history repeat

[issue11457] Expose nanosecond precision from system calls

2011-09-09 Thread Larry Hastings
Larry Hastings added the comment: I think a pair of integers is a poor API. It ties the value of the fractional part to nanoseconds. What happens when a future filesystem implements picosecond resolution? And then later goes to femtoseconds? Or some platform chooses another divisor (2**32

[issue11457] Expose nanosecond precision from system calls

2011-09-08 Thread Arfrever Frehtes Taifersar Arahesis
Arfrever Frehtes Taifersar Arahesis added the comment: I suggest to have low-level, POSIX-compatible, (int, int)-based interface in os module and add high-level, decimal.Decimal-based interface in shutil module. -- ___ Python tracker

[issue11457] Expose nanosecond precision from system calls

2011-09-08 Thread STINNER Victor
STINNER Victor added the comment: timespec is just a structure of two integers, so we should expose it as a simple and efficient Python tuple: (int, int). We can simply expose this type in os.stat, or we can do better by providing an optional callback to convert this tuple to a high level obj

[issue11457] Expose nanosecond precision from system calls

2011-09-06 Thread Larry Hastings
Larry Hastings added the comment: Here's a better idea: we add a new IEEE 754-2008 quad-precision float type. The IEEE 754-2008 quad precision float has 1 sign bit, 15 bits of exponent, and 112 bits of mantissa, so it should have enough precision to last utime until humanity transforms itsel

[issue11457] Expose nanosecond precision from system calls

2011-09-05 Thread Larry Hastings
Larry Hastings added the comment: This is probably a terrible idea, but: what about using a subclass of float that internally preserves the original sec / usec values? Call it a utime_float for now. os.stat would produce them, and os.utime would look for them--and if it found one it'd pull

[issue11457] Expose nanosecond precision from system calls

2011-09-05 Thread Stefan Krah
Changes by Stefan Krah : -- nosy: +skrah ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org

[issue11457] Expose nanosecond precision from system calls

2011-06-27 Thread Alexander Belopolsky
Alexander Belopolsky added the comment: On Sun, Jun 26, 2011 at 8:23 AM, Martin v. Löwis wrote: .. >> I understand that it is an issue of the datetime module. Can it be >> solved, or is there a design issue in the module? > > It's an inherent flaw of broken-down time. Don't use that > represent

[issue11457] Expose nanosecond precision from system calls

2011-06-26 Thread Martin v . Löwis
Martin v. Löwis added the comment: >> any broken-down time has issues of time stamp ordering in the >> duplicate hour of switching from DST to normal time > > I understand that it is an issue of the datetime module. Can it be > solved, or is there a design issue in the module? It's an inherent

[issue11457] Expose nanosecond precision from system calls

2011-06-24 Thread STINNER Victor
STINNER Victor added the comment: > there is no easy way to convert it into "seconds since the epoch" Ah yes, it remembers me that Alexander rejected my .totimestamp() patch (#2736) because he considers that "Converting datetime values to float is easy": (dt - datetime(1970, 1, 1)) / timedelt

[issue11457] Expose nanosecond precision from system calls

2011-06-24 Thread Martin v . Löwis
Martin v. Löwis added the comment: > I didn't know that datetime is "extremely bad at representing time > stamps", could you explain please? - there is no easy way to convert it into "seconds since the epoch" - any broken-down time has issues of time stamp ordering in the duplicate hour of sw

[issue11457] Expose nanosecond precision from system calls

2011-06-24 Thread STINNER Victor
STINNER Victor added the comment: > datetime.datetime is extremely bad at representing time stamps. > Don't use broken-down time if you can avoid it. I didn't know that datetime is "extremely bad at representing time stamps", could you explain please? -- _

[issue11457] Expose nanosecond precision from system calls

2011-06-24 Thread Martin v . Löwis
Martin v. Löwis added the comment: > Hey, why nobody proposed datetime.datetime objects? datetime.datetime is extremely bad at representing time stamps. Don't use broken-down time if you can avoid it. > By the way, Windows does also use timestamps with a nanosecond > resolution, it's not speci

[issue11457] Expose nanosecond precision from system calls

2011-06-24 Thread STINNER Victor
STINNER Victor added the comment: > I suggest that rather than using composite time stamps, > decimal.Decimal is used to represent high-precision time in Python. Hey, why nobody proposed datetime.datetime objects? Can't we improve the datetime precision to support nanoseconds? I would prefer t

[issue11457] Expose nanosecond precision from system calls

2011-06-07 Thread Martin v . Löwis
Martin v. Löwis added the comment: > Can you elaborate on this? Not on the tracker; this is appropriate on python-dev. -- ___ Python tracker ___ ___

[issue11457] Expose nanosecond precision from system calls

2011-06-07 Thread Alexander Belopolsky
Alexander Belopolsky added the comment: On Fri, Jun 3, 2011 at 6:52 PM, Martin v. Löwis wrote: .. >> One reason is the desire to avoid loading Python module from a >> C-module. > > This desire is indeed no guidance for Python development; the opposite > is the case. Can you elaborate on this?

[issue11457] Expose nanosecond precision from system calls

2011-06-03 Thread Martin v . Löwis
Martin v. Löwis added the comment: > One reason is the desire to avoid loading Python module from a > C-module. This desire is indeed no guidance for Python development; the opposite is the case. The only exception may be bootstrapping issues, which I claim are irrelevant in this case. ---

[issue11457] Expose nanosecond precision from system calls

2011-06-03 Thread Alexander Belopolsky
Alexander Belopolsky added the comment: On Fri, Jun 3, 2011 at 6:13 PM, Martin v. Löwis wrote: .. >> I support this idea in theory, but as long as decimal is implemented >> in Python, os module should probably expose a low level (tuple-based?) >> interface and a higher level module would provid

[issue11457] Expose nanosecond precision from system calls

2011-06-03 Thread Martin v . Löwis
Martin v. Löwis added the comment: > I support this idea in theory, but as long as decimal is implemented > in Python, os module should probably expose a low level (tuple-based?) > interface and a higher level module would provide Decimal-based > high-precision time. Can you explain why you thi

[issue11457] Expose nanosecond precision from system calls

2011-06-03 Thread Martin v . Löwis
Martin v. Löwis added the comment: Am 03.06.2011 22:11, schrieb Arfrever Frehtes Taifersar Arahesis: > > Arfrever Frehtes Taifersar Arahesis added the > comment: > > os.utimensat() and os.futimens() already exist since Python 3.3 and require > 2-tuples (or None) as second and third argument

[issue11457] Expose nanosecond precision from system calls

2011-06-03 Thread Alexander Belopolsky
Alexander Belopolsky added the comment: On Fri, Jun 3, 2011 at 3:57 PM, Martin v. Löwis wrote: .. > I suggest that rather than using composite time stamps, decimal.Decimal is > used to represent high-precision time in Python. I support this idea in theory, but as long as decimal is implemente

[issue11457] Expose nanosecond precision from system calls

2011-06-03 Thread Arfrever Frehtes Taifersar Arahesis
Arfrever Frehtes Taifersar Arahesis added the comment: os.utimensat() and os.futimens() already exist since Python 3.3 and require 2-tuples (or None) as second and third argument. (utime() is deprecated since POSIX 2008: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/utime.h.html)

[issue11457] Expose nanosecond precision from system calls

2011-06-03 Thread Martin v . Löwis
Martin v. Löwis added the comment: I suggest that rather than using composite time stamps, decimal.Decimal is used to represent high-precision time in Python. On input to os.utime, the function could just polymorphically accept Decimal, and try its best. I see three approaches that preserve

[issue11457] Expose nanosecond precision from system calls

2011-06-03 Thread R. David Murray
R. David Murray added the comment: The mailbox module would benefit from having this precision available. -- nosy: +r.david.murray ___ Python tracker ___ ___

[issue11457] Expose nanosecond precision from system calls

2011-04-28 Thread Ross Lagerwall
Changes by Ross Lagerwall : -- dependencies: +Support st_atim, st_mtim and st_ctim attributes in os.stat_result ___ Python tracker ___ ___

[issue11457] Expose nanosecond precision from system calls

2011-04-28 Thread Jesús Cea Avión
Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue11457] Expose nanosecond precision from system calls

2011-04-27 Thread Ross Lagerwall
Ross Lagerwall added the comment: Closed #11941 as a duplicate of this. -- nosy: +rosslagerwall ___ Python tracker ___ ___ Python-bug

[issue11457] Expose nanosecond precision from system calls

2011-03-11 Thread Arfrever Frehtes Taifersar Arahesis
Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue11457] Expose nanosecond precision from system calls

2011-03-11 Thread Alexander Belopolsky
Alexander Belopolsky added the comment: See also issue10812 which implements os.futimens(). -- ___ Python tracker ___ ___ Python-bugs

[issue11457] Expose nanosecond precision from system calls

2011-03-11 Thread Alexander Belopolsky
Changes by Alexander Belopolsky : -- nosy: +belopolsky ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue11457] Expose nanosecond precision from system calls

2011-03-10 Thread Nadeem Vawda
Changes by Nadeem Vawda : -- nosy: +nvawda ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue11457] Expose nanosecond precision from system calls

2011-03-09 Thread Lars Gustäbel
Changes by Lars Gustäbel : -- nosy: +lars.gustaebel ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue11457] Expose nanosecond precision from system calls

2011-03-09 Thread Antoine Pitrou
Changes by Antoine Pitrou : -- nosy: +mark.dickinson versions: +Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue11457] Expose nanosecond precision from system calls

2011-03-09 Thread Kris Henriksson
Kris Henriksson added the comment: Also, a new function similar to os.utime would be needed as well, perhaps something named like os.utimens. This would be needed to allow setting times with nanosecond precision. -- ___ Python tracker

[issue11457] Expose nanosecond precision from system calls

2011-03-09 Thread Kris Henriksson
New submission from Kris Henriksson : The most recent (issue 7) release of the POSIX standard mandates support for nanosecond precision in certain system calls. For example, the stat structure include a timespec struct for each of mtime, atime, and ctime that provides such nanosecond precision