At 08:52 PM 6/27/2005 +0200, Walter Dörwald wrote:
Phillip J. Eby wrote:
At 09:26 PM 6/26/2005 -0400, Bob Ippolito wrote:
On Jun 26, 2005, at 8:54 PM, Phillip J. Eby wrote:
At 12:22 AM 6/27/2005 +0200, Dörwald Walter wrote:
Phillip J. Eby wrote:
I'm also not keen on the fact that it makes certain things properties whose value can change over time; i.e. ctime/mtime/ atime and size really shouldn't be properties, but rather methods.
I think ctime, mtime and atime should be (or return) datetime.datetime objects instead of integer timestamps.
With what timezone? I don't think that can be done portably and unambiguously, so I'm -1 on that.
That makes no sense, timestamps aren't any better,
Sure they are, if what you want is a timestamp. In any case, the most common use case I've seen for mtime and friends is just comparing against a previous value, or the value on another file, so it doesn't actually matter most of the time what the type of the value is.
I find timestamp values to be somewhat opaque. So all things being equal, I'd prefer datetime objects.
Their opaqueness is actually one of the reasons I prefer them. :)
and datetime objects have no time zone set by default anyway. datetime.fromtimestamp(time.time()) gives you the same thing as datetime.now().
In which case, it's also easy enough to get a datetime if you really want one. I personally would rather do that than complicate the use cases where a datetime isn't really needed. (i.e. most of the time, at least in my experience)
We should have one uniform way of representing time in Python.
Um, counting the various datetime variants (date, time, datetime), timestamps (float and long), and time tuples, Python has 6 ways now. The type chosen for a given API is largely dependent on the *source* of the time value. And the value supplied by most existing OS-level Python APIs is either a long or a float. However, there's also a practicality-beats-purity issue here; using a datetime produces an otherwise-unnecessary dependency on the datetime module for users of this functionality, despite use cases for an actual datetime value being very infrequent. Date arithmetic on file timestamps that can't be trivially done in terms of seconds is rare, as is display of file timestamps. None of these use cases will be significantly harmed by having to use datetime.fromtimestamp(); they will probably be importing datetime already. What I don't want is for simple scripts to need to import datetime (even indirectly by way of the path class) just to get easy access to stat() values.