Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE forreview)
Walter Dörwald wrote: We should have one uniform way of representing time in Python. IMHO datetime objects are the natural choice. Alas datetime objects do not unambiguously identify a point in time. datetime objects are not timestamps: They represent the related but different concept of _local time_, which can be good for presentation, but shouldn't be allowed anywhere near a persistent store. - Anders ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE forreview)
On 6/28/05, Anders J. Munch [EMAIL PROTECTED] wrote: Alas datetime objects do not unambiguously identify a point in time. datetime objects are not timestamps: They represent the related but different concept of _local time_, which can be good for presentation, but shouldn't be allowed anywhere near a persistent store. You misunderstand the datetime module! You can have a datetime object whose timezone is UTC; or you can have a convention in your API that datetime objects without timezone represent UTC. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE forreview)
I wrote: Alas datetime objects do not unambiguously identify a point in time. datetime objects are not timestamps: They represent the related but different concept of _local time_, which can be good for presentation, but shouldn't be allowed anywhere near a persistent store. GvR replied: You misunderstand the datetime module! You can have a datetime object whose timezone is UTC; or you can have a convention in your API that datetime objects without timezone represent UTC. I can do a lot of things in my own code, and I'm sure the datetime module provides tools that I can build on to do so, but that doesn't help in interfacing with other people's code -- such as the standard library. Try saving a pickle of datetime.now() and reading it on a computer set to a different time zone. The repr will then show the local time on the _originating_ computer, and figuring out the absolute time this corresponds to requires knowledge of time zone and DST settings on the originating computer. How about datetime.utcnow(), then? Just use UTC for datetime timestamps? But that goes against the grain of the datetime module: Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import datetime, time datetime.datetime.fromtimestamp(time.time()) - datetime.datetime.now() datetime.timedelta(0) datetime.datetime.fromtimestamp(time.time()) - datetime.datetime.utcnow() datetime.timedelta(0, 7200) It seems when I subtract the present time from the present time, there's a two hour difference. - Anders ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE forreview)
[Anders J. Munch] Alas datetime objects do not unambiguously identify a point in time. datetime objects are not timestamps: They represent the related but different concept of _local time_, which can be good for presentation, but shouldn't be allowed anywhere near a persistent store. [GvR] You misunderstand the datetime module! You can have a datetime object whose timezone is UTC; or you can have a convention in your API that datetime objects without timezone represent UTC. [Anders] I can do a lot of things in my own code, and I'm sure the datetime module provides tools that I can build on to do so, but that doesn't help in interfacing with other people's code -- such as the standard library. Try saving a pickle of datetime.now() and reading it on a computer set to a different time zone. The repr will then show the local time on the _originating_ computer, and figuring out the absolute time this corresponds to requires knowledge of time zone and DST settings on the originating computer. How about datetime.utcnow(), then? Just use UTC for datetime timestamps? But that goes against the grain of the datetime module: Against the grain? There's just a bug in your example; stop assigning intentions to datetime that it doesn't have. Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import datetime, time datetime.datetime.fromtimestamp(time.time()) - datetime.datetime.now() datetime.timedelta(0) datetime.datetime.fromtimestamp(time.time()) - datetime.datetime.utcnow() datetime.timedelta(0, 7200) It seems when I subtract the present time from the present time, there's a two hour difference. No, you're mixing intentions. I can't tell if you're doing this intentionally to make the design look bad or if you don't understand the design; I'm going to assume the latter (if the former there's no point to this discussion at all) and explain what you should have done: datetime.datetime.utcfromtimestamp(time.time()) - datetime.datetime.utcnow() datetime.timedelta(0) Your bug is similar to comparing centimeters to inches, or speed to acceleration, or any number of similar mistakes. What I give you, however, is that a timezone object representing UTC should be part of the standard library, so that you wouldn't have an excuse for using tz-less datetime objects to represent UTC. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE forreview)
From: Guido van Rossum [mailto:[EMAIL PROTECTED] datetime.datetime.utcfromtimestamp(time.time()) - datetime.datetime.utcnow() datetime.timedelta(0) I overlooked the utcfromtimestamp method, sorry. Your bug is similar to comparing centimeters to inches, or speed to acceleration, or any number of similar mistakes. Quite so, and that is exactly the point. time.time() unambiguously identifies a point in time. A datetime object does not. At least not unless a tzinfo object is included, and even then there is a corner case at the end of DST that cannot possibly be handled. If ctime/mtime/atime were to return datetime objects, that would pretty much have to be UTC to not lose information in the DST transition. I doubt that's what Walter wanted though, as that would leave users with the job of converting from UTC datetime to local datetime; - unless perhaps I've overlooked a convenient UTC-local conversion method? - Anders ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE forreview)
[Anders J. Munch] If ctime/mtime/atime were to return datetime objects, that would pretty much have to be UTC to not lose information in the DST transition. I doubt that's what Walter wanted though, as that would leave users with the job of converting from UTC datetime to local datetime; - unless perhaps I've overlooked a convenient UTC-local conversion method? To be honest, I'm not sure what the point would be of returning datetime objects for this use case. A time.time()-like value seems just fine to me. The quest for a single representation of time (as expressed by Walter's We should have one uniform way of representing time in Python) is IMO a mistake; there are too many different use cases. Note that datetime intentionally doesn't handle things like leap seconds and alternate calendars. Those things are very specialized applications and deserve to be handled by application-specific code. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE forreview)
[Reinhold Birkenfeld] One more issue is open: the one of naming. As path is already the name of a module, what would the new object be called to avoid confusion? pathobj? objpath? Path? [Michael Hoffman] I would argue for Path. Granted path is actually os.path, but I don't think it's wise to have stdlib modules whose names are differentiated only by case, especially on Windows (and other case-insensitive filesystems). =Tony.Meyer ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE forreview)
At 12:08 PM 6/27/2005 +1200, Tony Meyer wrote: [Reinhold Birkenfeld] One more issue is open: the one of naming. As path is already the name of a module, what would the new object be called to avoid confusion? pathobj? objpath? Path? [Michael Hoffman] I would argue for Path. Granted path is actually os.path, but I don't think it's wise to have stdlib modules whose names are differentiated only by case, especially on Windows (and other case-insensitive filesystems). This is the name of a *class*, not a module. I.e., we are discussing adding a Path class to the 'os' module, that implements the interface of the path module. We can't call it path (as a top-level module) because the interface will not be backward-compatible with current uses and installations of the path module. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE forreview)
[Reinhold Birkenfeld] One more issue is open: the one of naming. As path is already the name of a module, what would the new object be called to avoid confusion? pathobj? objpath? Path? [Michael Hoffman] I would argue for Path. [Tony Meyer Granted path is actually os.path, but I don't think it's wise to have stdlib modules whose names are differentiated only by case, especially on Windows (and other case-insensitive filesystems). [Phillip J. Eby] This is the name of a *class*, not a module. Sorry - it sounded like the idea was to put this class in a module by itself (i.e. the class would be os.Path.Path). I.e., we are discussing adding a Path class to the 'os' module, that implements the interface of the path module. In that case, I would argue against Path as the name of the class because it's confusing to have os.path be the path module, and os.Path be an class that provides an interface to that module. I think differentiating things solely on the case of the name is a bad idea. =Tony.Meyer ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
