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
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
[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;
> 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
> accelera
[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 pers
> 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.
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 out
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 an
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
