[issue14127] os.stat and os.utime: allow preserving exact metadata

STINNER Victor added the comment: I'm lost in all issues related to os.stat/utime and nanosecond, here is a list: - #10148: duplicate - #11457: closed (was related the the rejected PEP 410) - #12904: closed, it was the first step to fix os.stat/os.utime - #13882: closed (implementation of th

[issue14127] os.stat and os.utime: allow preserving exact metadata

Nick Coghlan added the comment: FWIW, +1 on using the *name* of the keyword arg to define the format/resolution of the argument. It's simple and clear right now, and is easily updated to handle higher resolutions in the future. -- nosy: +ncoghlan _

[issue14127] os.stat and os.utime: allow preserving exact metadata

Guido van Rossum added the comment: I don't see how that's better than os.utime(path, ns=(atime, mtime)) If you think that in the future you could add resolution="fs", well, you could just as easily add fs=(atime, mtime). -- ___ Python tracker

[issue14127] os.stat and os.utime: allow preserving exact metadata

Arfrever Frehtes Taifersar Arahesis added the comment: The following solution might be compatible with Guido's suggestion: os.stat(path).st_atime_ns -> nanoseconds_since_epoch_as_int os.stat(path).st_ctime_ns -> nanoseconds_since_epoch_as_int os.stat(path).st_mtime_ns -> nanoseconds_since_epoch

[issue14127] os.stat and os.utime: allow preserving exact metadata

Antoine Pitrou added the comment: > I grant you that (int, float) is probably, theoretically better than > (int, int). But it's academic as Guido has ruled against anything but > a straight int representing nanoseconds, and I doubt he's gonna change > his mind. Why not let Guido speak out? --

[issue14127] os.stat and os.utime: allow preserving exact metadata

Guido van Rossum added the comment: Any solution involving tuple is too ugly. Please stick with the plan. -- ___ Python tracker ___ _

[issue14127] os.stat and os.utime: allow preserving exact metadata

Larry Hastings added the comment: I grant you that (int, float) is probably, theoretically better than (int, int). But it's academic as Guido has ruled against anything but a straight int representing nanoseconds, and I doubt he's gonna change his mind. -- __

[issue14127] os.stat and os.utime: allow preserving exact metadata

Antoine Pitrou added the comment: > Well, Guido has already nixed future-proof formats, see his comments > above: I don't think Guido is *against* future-proof formats per se, he's against them when they have a cost compared to non future-proof ones. The proposal I made (a (integral part, floa

[issue14127] os.stat and os.utime: allow preserving exact metadata

Larry Hastings added the comment: Well, Guido has already nixed future-proof formats, see his comments above: "I take full responsibility for fixing the precision at ns." So hope is all I have left. -- ___ Python tracker

[issue14127] os.stat and os.utime: allow preserving exact metadata

Antoine Pitrou added the comment: > Actually, I'm hoping that by the time we get better than nanosecond > resolution, we can also switch to 128-bit floats, and then the > existing st_[acm]time field will become the preferred representation > once more. What if your hope isn't fulfilled? That do

[issue14127] os.stat and os.utime: allow preserving exact metadata

Larry Hastings added the comment: Actually, I'm hoping that by the time we get better than nanosecond resolution, we can also switch to 128-bit floats, and then the existing st_[acm]time field will become the preferred representation once more. What goes around comes around! -- ___

[issue14127] os.stat and os.utime: allow preserving exact metadata

Antoine Pitrou added the comment: > os.utime() would accept int, float or (sec: int, nsec: int) for atime and > mtime. That's not future-proof for when we have better-than-nanosecond timestamps. See my suggestion above. -- ___ Python tracker

[issue14127] os.stat and os.utime: allow preserving exact metadata

STINNER Victor added the comment: Because the use case is to copy the access and modification time from a file to another, I would prefer to use the timespec structure: (sec: int, nsec: int). st_atime_ns and st_mtime_ns fields would be added to os.stat() structure: int in range [0; 9]

[issue14127] os.stat and os.utime: allow preserving exact metadata

Changes by Ross Lagerwall : -- nosy: +rosslagerwall ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue14127] os.stat and os.utime: allow preserving exact metadata

Martin v. Löwis added the comment: Let's go with ns= them. It's also what POSIX uses (although I initially had problems parsing "futimens", reading it as foo-timen-z, when it really is eff-youtime-en-es) -- ___ Python tracker

[issue14127] os.stat and os.utime: allow preserving exact metadata

Larry Hastings added the comment: My mistake! That ought to teach me to bound out of bed Sunday morning with my "brilliant realization". (But it probably won't.) I volunteer to implement this, with the new custom class for the os.stat object. I'll have it done no later than the PyCon sprin

[issue14127] os.stat and os.utime: allow preserving exact metadata

Guido van Rossum added the comment: Thanks Martin. I'd be happy with nsec instead of ns. -- ___ Python tracker ___ ___ Python-bugs-li

[issue14127] os.stat and os.utime: allow preserving exact metadata

Martin v. Löwis added the comment: > I suggest that publishing nanoseconds as a plain int would be a > nasty API. Consider what it would do to os.utime: No, it wouldn't. Please re-read Guido's proposal. If you want to specify nanoseconds, you have to pass the ns= parameter. My only quibble w

[issue14127] os.stat and os.utime: allow preserving exact metadata

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

[issue14127] os.stat and os.utime: allow preserving exact metadata

Antoine Pitrou added the comment: >>> st = os.stat('LICENSE') >>> st.st_mtime 1330108216.7984242 >>> st.st_mtime_frac 0.798424152 >>> tup = st.st_mtime, st.st_mtime_frac >>> os.utime('LICENSE', (tup, tup)) Of course, the fact that utime takes a (atime, mtime) tuple makes this a bit cumbersome.

[issue14127] os.stat and os.utime: allow preserving exact metadata

Larry Hastings added the comment: @pitrou: What would that look like when passed in to os.utime? -- ___ Python tracker ___ ___ Python

[issue14127] os.stat and os.utime: allow preserving exact metadata

Antoine Pitrou added the comment: How about a separate float attribute for the fractional part (in seconds)? This gives a femtosecond precision (assuming a 50 bits mantissa). The utime() could accept a (integral part, fractional part) tuple to set a timestamp without losing bits. (PHP does s

[issue14127] os.stat and os.utime: allow preserving exact metadata

Larry Hastings added the comment: (D'oh. My pseudo-code should have said value = int(mtime * 10) for that second assignment. Hopefully my point was still clear.) -- ___ Python tracker _

[issue14127] os.stat and os.utime: allow preserving exact metadata

Larry Hastings added the comment: I suggest that publishing nanoseconds as a plain int would be a nasty API. Consider what it would do to os.utime: if isinstance(mtime, int): # must be st_mtime_ns, it's in nanoseconds, use as-is value = mtime else: assert isins

[issue14127] os.stat and os.utime: allow preserving exact metadata

Guido van Rossum added the comment: @RDM: yes, that's insane for this purpose. The size of the solution doesn't match the size of the problem (the problem is non-existent for most people). @Larry: That seems unnecessarily general. I take full responsibility for fixing the precision at ns. An

[issue14127] os.stat and os.utime: allow preserving exact metadata

R. David Murray added the comment: Is it totally insane to think about using a float subclass with an additional attribute instead of a tuple? -- nosy: +r.david.murray ___ Python tracker _

[issue14127] os.stat and os.utime: allow preserving exact metadata

Martin v. Löwis added the comment: OTOH, it seems that Guido is very much in favor of hard-coding ns resolution in the API, claiming that expectations of even finer resolution are academic. While I still disagree (the *very* same argument was brought up for ms resolution ten years ago), I thi

[issue14127] os.stat and os.utime: allow preserving exact metadata

Larry Hastings added the comment: Guido proposed st_atime_ns et al. I'll make an alternate proposal. I'd like to avoid tying ourselves to ns resolution. As MvL said: "I don't want to deal with this issue *again* in my lifetime". If all we want is to facilitate copying the exact metadata fro

[issue14127] os.stat and os.utime: allow preserving exact metadata

New submission from Larry Hastings : Following on from Guido's rejection of PEP 410: http://mail.python.org/pipermail/python-dev/2012-February/116837.html This bug is the proposed hammering-out space for how to preserve exact metadata for st_atime / st_mtime between os.stat and os.utime. (Yes,