On Tue, 2010-02-16 at 02:09 -0500, Glyph Lefkowitz wrote:
In a recent message he was talking about either breaking
compatibility with TestSuite implementations that override run(),
or test-reordering - both of which I consider important, core
features of the unittest module.
Hello,
So far, Python timezone handling is far from pythonic. There is no
function to get current UTC offset, intuitive API to get DST of
current time zone and whenever it is active, no functions to work with
internet timestamps (RFC 3339). In my case [1] it took about one month
and five people
Hi,
Le Tuesday 16 February 2010 11:38:05 anatoly techtonik, vous avez écrit :
So far, Python timezone handling is far from pythonic. There is no
function to get current UTC offset, (...)
There is the time.timezone attribute: UTC offset in seconds.
One of the reasons I see is that date/time
Maybe an alternate sprint idea would be to incorporate dateutil into the
Python core: http://labix.org/python-dateutil
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Maybe an alternate sprint idea would be to incorporate dateutil into the
Python core: http://labix.org/python-dateutil
Whoops... (just waking up - still need that first cup of coffee)
While incorporating dateutil into the core would be nice (in my opinion at
least), I was really
anatoly techtonik wrote:
Does anybody else find this feature useful for Python development?
Not particularly. The target release dates are in the release PEPs and
if I wanted a timer I'd add it to my personal calendar.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane,
s...@pobox.com wrote:
While incorporating dateutil into the core would be nice (in my opinion at
least)
I believe that idea has come up before - as I recall, the major concern
was with the heuristic nature of some of the 'natural language' date
parsing. (I could be completely misremembering
Victor Stinner wrote:
Hi,
Le Tuesday 16 February 2010 11:38:05 anatoly techtonik, vous avez écrit :
So far, Python timezone handling is far from pythonic. There is no
function to get current UTC offset, (...)
There is the time.timezone attribute: UTC offset in seconds.
One of the
On Tue, Feb 16, 2010 at 13:05, s...@pobox.com wrote:
Maybe an alternate sprint idea would be to incorporate dateutil into the
Python core: http://labix.org/python-dateutil
Whoops... (just waking up - still need that first cup of coffee)
While incorporating dateutil into the core
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
s...@pobox.com wrote:
Maybe an alternate sprint idea would be to incorporate dateutil into the
Python core: http://labix.org/python-dateutil
Whoops... (just waking up - still need that first cup of coffee)
While incorporating dateutil
On Tue, Feb 16, 2010 at 16:26, Tres Seaver tsea...@palladion.com wrote:
Because timezones are defined politically, they change frequently. pytz
is released frequently (multiple times per year) to accomodate those
changes: I can't see any way to preserve that flexibility if the
package were
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dirkjan Ochtman wrote:
On Tue, Feb 16, 2010 at 16:26, Tres Seaver tsea...@palladion.com wrote:
Because timezones are defined politically, they change frequently. pytz
is released frequently (multiple times per year) to accomodate those
changes:
On 2/16/2010 11:15 AM, exar...@twistedmatrix.com wrote:
On 03:43 pm, dirk...@ochtman.nl wrote:
pytz includes its own timezone database. It doesn't use the system
timezone data, even on Linux.
dateutil can use the system timezone data. See tzfile.
On Tue, Feb 16, 2010 at 02:38, anatoly techtonik techto...@gmail.com wrote:
Hello,
So far, Python timezone handling is far from pythonic. There is no
function to get current UTC offset, intuitive API to get DST of
current time zone and whenever it is active, no functions to work with
I have a minor concern about certain corner cases with math.hypot and
complex.__abs__, namely when one component is infinite and one is not a number.
If we execute the following code:
import math
inf = float('inf')
nan = float('nan')
print math.hypot(inf, nan)
print abs(complex(nan, inf))
...
David DiCato wrote:
… then we see that ‘inf’ is printed in both cases. The standard library
tests (for example, test_cmath.py:test_abs()) seem to test for this
behavior as well, and FWIW, I personally agree with this convention.
However, the math module’s documentation for both 2.6 and 3.1
On Tue, Feb 16, 2010 at 9:19 PM, David DiCato ddic...@microsoft.com wrote:
I have a minor concern about certain corner cases with math.hypot and
complex.__abs__, namely when one component is infinite and one is not a
number.
examples snipped
as well, and FWIW, I personally agree with this
Ok, thanks! It's submitted as issue 7947.
- David
-Original Message-
From: Mark Dickinson [mailto:dicki...@gmail.com]
Sent: Tuesday, February 16, 2010 2:15 PM
To: David DiCato
Cc: python-dev@python.org
Subject: Re: [Python-Dev] math.hypot, complex.__abs__, and documentation
On Tue, Feb
On Wed, 17 Feb 2010 08:19:00 am David DiCato wrote:
I have a minor concern about certain corner cases with math.hypot and
complex.__abs__, namely when one component is infinite and one is not
a number. If we execute the following code:
import math
inf = float('inf')
nan = float('nan')
Mathematically, think of nan as 'indeterminate'. When you're trying to get the
magnitude of a vector, you know that it's infinite if even one of the
components is infinite. So, the fact that the other component is indeterminate
can be ignored. It's the same with math.pow(1.0, float('nan')); the
On Tue, Feb 16, 2010 at 10:46 PM, Steven D'Aprano st...@pearwood.info
What's the justification for that convention? It seems wrong to me.
It's difficult to do better than to point to Kahan's writings. See
http://www.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF
and particularly the
On Tue, Feb 16, 2010 at 11:06 PM, Mark Dickinson dicki...@gmail.com wrote:
and particularly the discussion on page 8 that starts Were there no
way to get rid of NaNs I don't think it covers hypot, but the
Whoops. I should have reread that article myself. The behaviour of
hypot *is*
Brett Cannon wrote:
Issue 5094 already has a patch that is nearly complete to provide a
default UTC object (and requisite changes to functions to no longer be
naive but to use UTC).
Are you sure it's really a good idea to default to UTC?
I thought it was considered a feature that datetime
On Tue, Feb 16, 2010 at 11:18 PM, Tres Seaver tsea...@palladion.com wrote:
Dirkjan Ochtman wrote:
On Tue, Feb 16, 2010 at 16:26, Tres Seaver tsea...@palladion.com wrote:
Because timezones are defined politically, they change frequently. pytz
is released frequently (multiple times per year)
On Wed, Feb 17, 2010 at 09:15:25AM +0700, Stuart Bishop wrote:
The Debian, Ubuntu and I think Redhat packages all use the system
zoneinfo database - there are hooks in there to support package
maintainers that want to do this.
Where RedHat == Fedora EPEL packages for RHEL/Centos 5, yes :-)
Hello,
THE PROBLEM:
I am having a problem that I have seen asked quite a bit on the web, with
little to no follow up.
The problem is essentially this. When embedding (LoadLibraryA()) the python
interpreter dll
in a non-windows application the developer must first create a console for
python to
26 matches
Mail list logo
