Re: [Python-Dev] Decimal floats as default (was: discussion aboutPEP239 and 240)
On 6/27/05, Fredrik Johansson [EMAIL PROTECTED] wrote: The context (as I envision it) would not be just a binary float context, but a universal float context that lets you choose between binary and decimal precision at run time. You mean something like this? from __future__ import new_float_behaviour 1.1 1.1 import sys sys.float_context.binary = True 1.1 1.1001 I don't see why this couldn't be done. The default will be use decimal fp, and you can switch to binary fp if you need silicon-speed (unless, of course, you have decimal-on-silicon). In decimal mode, the context will be a full one, in binary mode, it's not mandatory to allow access to fpu flags, it could be just like now. .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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 for review)
On 6/27/05, Phillip J. Eby [EMAIL PROTECTED] wrote: I think the only questions remaining open are where to put it and what to call the class. Whoa! Do we really need a completely different mechanism for doing the same stuff we can already do? The path module seems mostly useful for folks coming from Java who are used to the Java Path class. With the massive duplication of functionality we should also consider what to recommend for the future: will the old os.path module be deprecated, or are we going to maintain both alternatives forever? (And what about all the duplication with the os module itself, like the cwd() constructor?) Remember TOOWTDI. I think we should put it in os.path, such that 'from os.path import path' gives you the path class for your platform, and using one of the path modules directly (e.g. 'from posixpath import path') gives you the specific platform's version. Aargh! Call it anything except path. Having two things nested inside each other with the same name is begging for confusion forever. We have a few of these in the stdlib now (StringIO, UserDict etc.) and they were MISTAKES. This is useful because sometimes you need to manipulate paths that are foreign to your current OS. For example, the distutils and other packages sometimes use POSIX paths for input and then convert them to local OS paths. Also, POSIX path objects would be useful for creating or parsing the path portion of many kinds of URLs, and I have often used functions from posixpath for that myself. Right. That's why posixpath etc. always exists, not only when os.name == posix. As for a PEP, I doubt a PEP is really required for something this simple; I have never seen anyone say, no, we shouldn't have this in the stdlib. I think it would be more important to write reference documentation and a complete test suite. No, we shouldn't have this in the stdlib. At least, not without more motivation than it gets high praise. By the way, it also occurs to me that for the sake of subclassability, the methods should not return 'path(somestr)' when creating new objects, but instead use self.__class__(somestr). Clearly it needs a PEP. -- --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)
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 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 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 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 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
[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 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
