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
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
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
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
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
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
[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.
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
[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; -
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
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
11 matches
Mail list logo
