On Mon, 2005-06-27 at 14:25, Phillip J. Eby wrote: [...] > As for the open issues, if we can't reach some sane compromise about > atime/ctime/mtime, I'd suggest just providing the stat() method and let > people use stat().st_mtime et al. Alternately, I'd be okay with creating > last_modified(), last_accessed(), and created_on() methods that return > datetime objects, as long as there's also atime()/mtime()/ctime() methods > that return timestamps. +1 for atime/mtime/ctime being timestamps -1 for redundant duplicates that return DateTimes +1 for a stat() method (there is lots of other goodies in a stat). -- Donovan Baarda <abo at minkirri.apana.org.au>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4