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 d
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
On Tue, Feb 16, 2010 at 11:18 PM, Tres Seaver wrote:
> Dirkjan Ochtman wrote:
>> On Tue, Feb 16, 2010 at 16:26, Tres Seaver wrote:
>>> Because timezones are defined politically, they change frequently. pytz
>>> is released frequently (multiple times per year) to accomodate those
>>> changes: I
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
obje
On Tue, Feb 16, 2010 at 11:06 PM, Mark Dickinson 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* mentioned, on page
On Tue, Feb 16, 2010 at 10:46 PM, Steven D'Aprano
> 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 discussion on page 8 t
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 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')
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 Tue, Feb 16, 2010 at 9:19 PM, 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.
> as well, and FWIW, I personally agree with this convention. However, the
> math modu
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
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))
... t
On Tue, Feb 16, 2010 at 02:38, anatoly techtonik 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
> internet timestamps
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.
http://labix.org/python-dateutil#head-4e438
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dirkjan Ochtman wrote:
> On Tue, Feb 16, 2010 at 16:26, Tres Seaver 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
On 03:43 pm, dirk...@ochtman.nl wrote:
On Tue, Feb 16, 2010 at 16:26, Tres Seaver
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 th
On Tue, Feb 16, 2010 at 16:26, Tres Seaver 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 part of stdlib.
By
-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 dat
On Tue, Feb 16, 2010 at 13:05, 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 would be nice
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
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 th
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, Aus
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 thinking
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:
http://mail.py
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/ti
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
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 m
27 matches
Mail list logo
