[Python-Dev] Adding the 'path' module (was Re: Some RFE for review)

[Phillip J. Eby]

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.