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 [email protected] 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 [email protected] 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 for review)
Phillip J. Eby wrote: > At 03:45 PM 6/27/2005 -0500, Skip Montanaro wrote: > >We're getting enough discussion about various aspects of Jason's > >path module that perhaps a PEP is warranted. All this discussion on > >python-dev is just going to get lost. > > AFAICT, the only unresolved issue outstanding is a compromise or > Pronouncement regarding the atime/ctime/mtime members' datatype. > This is assuming, of course, that making the "empty path" be > os.curdir doesn't receive any objections, and that nobody strongly > prefers 'path.fromcwd()' over 'path.cwd()' as the alternate > constructor name. > > Apart from these fairly minor issues, there is a very short to-do > list, small enough to do an implementation patch in an evening or > two. Documentation might take a similar amount of time after that; > mostly it'll be copy-paste from the existing os.path docs, though. > > 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. My issues with the 'path' module (basically recapping what I've said on the subject in the past): - It inherits from str/unicode, so path object have many str methods that make no sense for paths. - On OSX, it inherits from str instead of unicode, due to http://python.org/sf/767645 - I don't like __div__ overloading for join(). Just ___ Python-Dev mailing list [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 RFEforreview)
Maybe this has already been answered somewhere (although I don't recall seeing it, and it's not in the sourceforge tracker) but has anyone asked Jason Orendorff what his opinion about this (including the module in the stdlib) is? If someone has, or if he posted it somewhere other than here, could someone provide a link to it? =Tony.Meyer ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PySWT -- Python binding of SWT using GCJ + SIP
Hi, all, I just made an initial Python binding for SWT library from IBM's Eclipse project using GCJ + SIP. you can find some information here: http://www.cs.nyu.edu/zilin/pyswt/pmwiki.php The basic idea is as follows: 1. use GCJ compile SWT source codes 2. use gcjh to generate C++ header files for SWT 3. I modified SIP's code generator to generate C++ wrapper codes. It is still in very early stage, but most widgets are usable now. Hope I can get more time work on this. Weclome any feedbacks, and feel free to forward this annocement to any place you want@ thanks! Zilin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
