classification
Title: Update utime API to not require explicit None argument
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: brian.curtin Nosy List: brian.curtin, jcea, petri.lehtinen, pitrou, python-dev
Priority: normal Keywords: needs review, patch

Created on 2011-11-02 23:46 by brian.curtin, last changed 2011-11-08 16:28 by python-dev. This issue is now closed.

Files
File name Uploaded Description Edit
utime.diff brian.curtin, 2011-11-02 23:46 review
Messages (13)
msg146884 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2011-11-02 23:46
os.utime currently requires an explicit `None` as the second argument in order to update to the current time. Other APIs would just have the second argument as optional in this case, operating with one argument.

Attached is a patch which changes the second argument to accept the time tuple, `None`, or literally nothing. Tested on Windows and Mac.

If this is acceptable, I'll make the same change for futimes, lutimes, and futimens.
msg146889 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-11-03 02:12
You have a possible failure here: 

+        # Set to the current time in the old explicit way.
+        os.utime(support.TESTFN, None)
+        st1 = os.stat(support.TESTFN)
+        # Set to the current time in the new way
+        os.utime(support.TESTFN)
+        st2 = os.stat(support.TESTFN)
+        self.assertEqual(st1.st_mtime, st2.st_mtime)

I managed to trigger it after a run of tests:

======================================================================
FAIL: test_utime_noargs (test.test_os.StatAttributeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/test/test_os.py", line 286, in test_utime_noargs
    self.assertEqual(st1.st_mtime, st2.st_mtime)
AssertionError: 1320285959.712339 != 1320285959.7133389


Otherwise, +1.
msg146891 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2011-11-03 02:27
Ah, yes. Would the following work better for the last line?

self.assertAlmostEqual(st1.st_mtime, st2.st_mtime, places=2)
msg146892 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-11-03 02:32
I would specify an even smaller "places". We have very slow buildbots.
You could first call utime() with a date far away in the past if you want.
msg146894 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2011-11-03 03:28
The `delta` keyword would actually be better than `places`, especially on the slower buildbots. delta=10 would allow up to 10 seconds between those utime calls. Is that being too permissive?
msg146900 - (view) Author: Petri Lehtinen (petri.lehtinen) * (Python committer) Date: 2011-11-03 08:06
+1 on making the second arg optional.
msg146914 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-11-03 11:25
> The `delta` keyword would actually be better than `places`, especially
> on the slower buildbots. delta=10 would allow up to 10 seconds between
> those utime calls. Is that being too permissive?

I think it's ok. We don't have to test the system's utime
implementation, just that the second parameter does what it should.
msg146920 - (view) Author: Jesús Cea Avión (jcea) * (Python committer) Date: 2011-11-03 12:14
+1 to the optional parameter.
msg147173 - (view) Author: Roundup Robot (python-dev) Date: 2011-11-06 19:41
New changeset 99e118951a80 by Brian Curtin in branch 'default':
Fix #13327. Remove the need for an explicit None as the second argument to
http://hg.python.org/cpython/rev/99e118951a80
msg147259 - (view) Author: Roundup Robot (python-dev) Date: 2011-11-07 22:10
New changeset 59dca1e2363d by Brian Curtin in branch 'default':
Fix #13327. utimensat now has the atime and mtime arguments set as optional,
http://hg.python.org/cpython/rev/59dca1e2363d
msg147261 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2011-11-07 22:26
Changeset 045e8757f10d was also entered for this, which should conclude the changes. Everything seems to have survived the buildbots for now, so closing as fixed. Feel free to reopen if there are any other issues.
msg147262 - (view) Author: Roundup Robot (python-dev) Date: 2011-11-07 22:30
New changeset 5e18ff5476e8 by Brian Curtin in branch 'default':
News updates for #13327.
http://hg.python.org/cpython/rev/5e18ff5476e8
msg147308 - (view) Author: Roundup Robot (python-dev) Date: 2011-11-08 16:28
New changeset 8907d646e0df by Jesus Cea in branch 'default':
Commit 59dca1e2363d for issue #13327 introduced a compilation warning
http://hg.python.org/cpython/rev/8907d646e0df
History
Date User Action Args
2011-11-08 16:28:21python-devsetmessages: + msg147308
2011-11-07 22:30:22python-devsetmessages: + msg147262
2011-11-07 22:26:36brian.curtinsetstatus: open -> closed
resolution: fixed
messages: + msg147261

stage: patch review -> resolved
2011-11-07 22:10:23python-devsetmessages: + msg147259
2011-11-06 19:41:44python-devsetnosy: + python-dev
messages: + msg147173
2011-11-03 12:14:55jceasetnosy: + jcea
messages: + msg146920
2011-11-03 11:25:15pitrousetmessages: + msg146914
2011-11-03 08:06:01petri.lehtinensetnosy: + petri.lehtinen
messages: + msg146900
2011-11-03 03:28:37brian.curtinsetmessages: + msg146894
2011-11-03 02:32:48pitrousetmessages: + msg146892
2011-11-03 02:27:22brian.curtinsetmessages: + msg146891
2011-11-03 02:12:42pitrousetnosy: + pitrou
messages: + msg146889
2011-11-02 23:46:31brian.curtincreate