Re: [Python-Dev] setUpClass and setUpModule in unittest
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. > > > > Well, by "breaking compatibility with custom TestSuite > > implementations that override run" I mean that is one possible place > > to put the functionality. Code that does override it will *not* stop > > working, it just won't support the new features. > > > > > Ah, I see. This doesn't sound *too* bad, but I'd personally prefer it > if the distinction were a bit more clearly drawn. I'd like frameworks > to be able to implement extension functionality without having to > first stub out functionality. In other words, if I want a test suite > without setUpClass, I'd prefer to avoid having an abstraction > inversion. +1 > > If we chose this implementation strategy there would be no > > compatibility issues for existing tests / frameworks that don't use > > the new features. > > That's very good to hear. It does however get tougher to be 'stdlib compatible' for frameworks that extend the stdlib - at least with how extensions work today. > > If tests do want to use the new features then the framework authors > > will need to ensure they are compatible with them. This seems like a > > reasonable trade-off to me. We can ensure that it is easy to write > > custom TestSuite objects that work with earlier versions of unittest > > but are also compatible with setUpClass in 2.7 (and document the > > recipe - although I expect it will just mean that TestSuite.run > > should call a single method if it exists). > > > > > This is something that I hope Jonathan Lange or Robert Collins will > chime in to comment on: expanding the protocol between suite and test > is an area which is fraught with peril, but it seems like it's > something that test framework authors always want to do. (Personally, > *I* really want to do it because I want to be able to run things > asynchronously, so the semantics of 'run()' need to change pretty > dramatically to support that...) It might be good to eventually > develop a general mechanism for this, rather than building up an > ad-hoc list of test-feature compatibility recipes which involve a list > of if hasattr(...): foo(); checks in every suite implementation. Please have a look at the testtools.TestCase.run - its incomplete, but its working towards making it possible for trial to not need to replace run, but instead provide a couple of hooks (registered during setUp) to handle what you need. What it currently offers is catching additional exceptions for you, which is a common form of extension. bzrlib is using this quite successfully, and we deleted a lot of code that overlapped the stdlib unittest run(). > > Perhaps a better idea might be to also add startTest and stopTest > > methods to TestSuite so that frameworks can build in features like > > timing tests (etc) without having to override run itself. This is > > already possible in the TestResult of course, which is a more common > > extensibility point in *my* experience. > > > > I think timing and monitoring tests can mostly be done in the > TestResult class; those were bad examples. There's stuff like > synthesizing arguments for test methods, or deciding to repeat a > potentially flaky test method before reporting a failure, which are > not possible to do from the result. I'm not sure that startTest and > stopTest hooks help with those features, the ones which really need > suites; it would seem it mostly gives you a hook to do stuff that > could already be done in TestResult anyway. Also its not really possible to 'run one thing' around a test at the moment - theres no good place (without changing tests or doing somewhat convoluted stuff) to have custom code sit in the stack above the test code - this makes it harder to handle: - profiling - drop-into-a-debugger - $other use case This is also in my hit-list of things to solve-and-propose-for-stdlib-unittest that I blogged about a while back. -Rob signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
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 to get the right solution for a valid RFC 3339 timestamp. One of the reasons I see is that date/time functions are implemented in C, they expose C API, and there are not many people who can help and patch them. I am sure many current Python users will appreciate UTC functions and improved date/time API more than any new language features. That's why I would like to propose this enhancements for a coding spring on forthcoming PyCon. I am located in Europe and can't attend PyCon, but I summarized date/time issues related to UTC below. More open UTC-related Python issues: http://bugs.python.org/issue1647654 No obvious and correct way to get the time zone offset http://bugs.python.org/issue1667546 Time zone-capable variant of time.localtime http://bugs.python.org/issue7662 time.utcoffset() http://bugs.python.org/issue7229 [PATCH] Manual entry for time.daylight can be misleading http://bugs.python.org/issue5094 datetime lacks concrete tzinfo impl. for UTC http://bugs.python.org/issue7584 datetime.rfcformat() for Date and Time on the Internet (support RFC 3339, ISO 8601 datetime format) http://bugs.python.org/issue665194 datetime-RFC2822 roundtripping http://bugs.python.org/issue6280 calendar.timegm() belongs in time module, next to time.gmtime() All solutions require C expertise. If it will be impossible to find experts able to modify current implementation, then perhaps it could be real to create Python stub for coding solution in Python later? FWIW, this proposal is from my other issue about problems with Python date/time in separate tracker on Google Code [2]. [1] http://bugs.python.org/issue7582[patch] diff.py to use iso timestamp [2] http://code.google.com/p/rainforce/issues/detail?id=10python: date/time is a mess -- anatoly t. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
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 functions are > implemented in C, they expose C API, and there are not many people who > can help and patch them. Is it no possible to extend Python datetime module in Python? There are already 3rd party libraries: http://pypi.python.org/pypi/pytz http://pypi.python.org/pypi/django-timezones http://www.egenix.com/products/python/mxBase/mxDateTime/ ... Can't why integrating an existing module (well tested, with a documentation, an user base, etc.)? > I am sure many current Python users will appreciate UTC functions and > improved date/time API more than any new language features. Sure, the current API is complex and has few documentation. > That's why I would like to propose this enhancements for a coding spring on > forthcoming PyCon. Excellent idea :) -- There are also some interesting open issues about the datetime module: http://bugs.python.org/issue1289118 - timedelta multiply and divide by floating point http://bugs.python.org/issue1673409 - datetime module missing some important methods http://bugs.python.org/issue2706 - datetime: define division timedelta/timedelta http://bugs.python.org/issue2736 - datetime needs and "epoch" method Bugs about old timestamps: http://bugs.python.org/issue1726687 - Bug found in datetime for Epoch time = -1 http://bugs.python.org/issue1777412 - Python's strftime dislikes years before 1900 http://bugs.python.org/issue2494 - Can't round-trip datetimes<->timestamps prior to 1970 on Windows Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
Maybe an alternate sprint idea would be to incorporate dateutil into the Python core: http://labix.org/python-dateutil Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
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 of pytz: http://pytz.sourceforge.net/ Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Release timer for Core Development page
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 | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
[email protected] 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 though...) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
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 reasons I see is that date/time functions are >> implemented in C, they expose C API, and there are not many people who >> can help and patch them. > > Is it no possible to extend Python datetime module in Python? Splitting datetime into a datetime.py with an underlying _datetime.c is an idea definitely worth exploring - that module structure makes it much easier to accelerate things that need it, while allowing less critical or more complex aspects to be written in the higher level language. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
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 (in my opinion at > least), I was really thinking of pytz: http://pytz.sourceforge.net/ I think dateutil is fairly heavy for the stdlib, but I think pytz would be a very good candidate for inclusion. Without it, the timezone support in datetime is hardly usable. I'd be happy to participate in a PyCon sprint to get datetime issues sorted out and/or work on pytz inclusion. Cheers, Dirkjan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [email protected] 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 (in my opinion at > least), I was really thinking of pytz: http://pytz.sourceforge.net/ 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. Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkt6uQwACgkQ+gerLs4ltQ4BiwCcDKbfmFmapdQZ188AbiiJ8iCD JvcAoMozT+bcXDCX1tQ5FuLqpCTTbxZe =OP1W -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
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 using what the OS provides. At least on Linux, the basic timezone data is usually updated by other means (at least on the distro I'm familiar with, it's updated quite often, too; through the package manager). I'm assuming Windows and OS X would also be able to provide something like this. I think pytz already looks at this data if it's available (precisely because it might well be newer). Cheers, Dirkjan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
On 03:43 pm, [email protected] 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 the package were part of stdlib. By using what the OS provides. At least on Linux, the basic timezone data is usually updated by other means (at least on the distro I'm familiar with, it's updated quite often, too; through the package manager). I'm assuming Windows and OS X would also be able to provide something like this. I think pytz already looks at this data if it's available (precisely because it might well be newer). pytz includes its own timezone database. It doesn't use the system timezone data, even on Linux. Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
-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 way to preserve that flexibility if the >> package were part of stdlib. > > By using what the OS provides. At least on Linux, the basic timezone > data is usually updated by other means (at least on the distro I'm > familiar with, it's updated quite often, too; through the package > manager). I'm assuming Windows and OS X would also be able to provide > something like this. I think pytz already looks at this data if it's > available (precisely because it might well be newer). If that were so, I don't think Stuart would be going to the trouble to re-release the library 6 - 12 times per year. Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkt6xVwACgkQ+gerLs4ltQ4q4ACdGRozE9rfoYkYGmNOiGTQIZyj CeMAoJlmEamyWUbHSQYA0Yq28t+YlbZT =UC3U -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
On 2/16/2010 11:15 AM, [email protected] wrote: > On 03:43 pm, [email protected] 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-4e4386d98006f1e3cb9290a04bff7e01e584505b or on windows see tzwin. http://labix.org/python-dateutil#head-566bbb3e75e621ac00d2cb1b54abc09036b994f1 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
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 (RFC 3339). In my case [1] it took about one month > and five people to get the right solution for a valid RFC 3339 > timestamp. One of the reasons I see is that date/time functions are > implemented in C, they expose C API, and there are not many people who > can help and patch them. > > I am sure many current Python users will appreciate UTC functions and > improved date/time API more than any new language features. That's why > I would like to propose this enhancements for a coding spring on > forthcoming PyCon. I am located in Europe and can't attend PyCon, but > I summarized date/time issues related to UTC below. > > More open UTC-related Python issues: > http://bugs.python.org/issue1647654 No obvious and correct way to get > the time zone offset > http://bugs.python.org/issue1667546 Time zone-capable variant of > time.localtime > http://bugs.python.org/issue7662 time.utcoffset() > http://bugs.python.org/issue7229 [PATCH] Manual entry for > time.daylight can be misleading > http://bugs.python.org/issue5094 datetime lacks concrete tzinfo > impl. for UTC 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). I did a code review on it in Rietveld and it only has minor things to correct. > http://bugs.python.org/issue7584 datetime.rfcformat() for Date and > Time on the Internet (support RFC 3339, ISO 8601 datetime format) > http://bugs.python.org/issue665194 datetime-RFC2822 roundtripping > http://bugs.python.org/issue6280 calendar.timegm() belongs in time > module, next to time.gmtime() > > All solutions require C expertise. If it will be impossible to find > experts able to modify current implementation, then perhaps it could > be real to create Python stub for coding solution in Python later? Probably worth doing as I am sure everyone would prefer to maintain a pure Python version when possible and only drop into C as needed. See heapq, warnings, and a couple of others if you don't know how to properly do a Python/C module split. -Brett > > FWIW, this proposal is from my other issue about problems with Python > date/time in separate tracker on Google Code [2]. > > [1] http://bugs.python.org/issue7582 [patch] diff.py to use iso timestamp > [2] http://code.google.com/p/rainforce/issues/detail?id=10 python: > date/time is a mess > -- > anatoly t. > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] math.hypot, complex.__abs__, and documentation
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))
... 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 states, "All functions return a quiet NaN if
at least one of the args is NaN."
math.pow(1.0, nan) is another such exception to the rule. Perhaps the
documentation should be updated to reflect this.
Thanks,
- David
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] math.hypot, complex.__abs__, and documentation
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 states, > “All functions return a quiet NaN if at least one of the args is NaN.” > > math.pow(1.0, nan) is another such exception to the rule. Perhaps the > documentation should be updated to reflect this. This sounds like a legitimate documentation bug for the tracker at bugs.python.org (bug reports tend to get lost/forgotten if they only exist on the mailing list). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] math.hypot, complex.__abs__, and documentation
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 module’s documentation for both 2.6 and 3.1 states, “All functions > return a quiet NaN if at least one of the args is NaN.” Yes; this is a doc bug. Please could you open an issue on http://bugs.python.org ? > math.pow(1.0, nan) is another such exception to the rule. Perhaps the > documentation should be updated to reflect this. Yes, it should. Thanks! Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] math.hypot, complex.__abs__, and documentation
Ok, thanks! It's submitted as issue 7947. - David -Original Message- From: Mark Dickinson [mailto:[email protected]] Sent: Tuesday, February 16, 2010 2:15 PM To: David DiCato Cc: [email protected] Subject: Re: [Python-Dev] math.hypot, complex.__abs__, and documentation 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 module’s documentation for both 2.6 and 3.1 states, “All functions > return a quiet NaN if at least one of the args is NaN.” Yes; this is a doc bug. Please could you open an issue on http://bugs.python.org ? > math.pow(1.0, nan) is another such exception to the rule. Perhaps the > documentation should be updated to reflect this. Yes, it should. Thanks! Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] math.hypot, complex.__abs__, and documentation
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')
> print math.hypot(inf, nan)
> print abs(complex(nan, inf))
>
> ... 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.
What's the justification for that convention? It seems wrong to me.
If you expand out hypot and substitute a=inf and b=nan, you get:
>>> math.sqrt(inf*inf + nan*nan)
nan
which agrees with my pencil-and-paper calculation:
sqrt(inf*inf + nan*nan)
= sqrt(inf + nan)
= sqrt(nan)
= nan
--
Steven D'Aprano
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] math.hypot, complex.__abs__, and documentation
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 second
argument simply doesn't matter when the first is 1.0.
FWIW, these conventions also exist in the C99 standard.
Hope this helps,
- David
-Original Message-
From: [email protected]
[mailto:[email protected]] On Behalf Of
Steven D'Aprano
Sent: Tuesday, February 16, 2010 2:47 PM
To: [email protected]
Subject: Re: [Python-Dev] math.hypot, complex.__abs__, and documentation
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')
> print math.hypot(inf, nan)
> print abs(complex(nan, inf))
>
> ... 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.
What's the justification for that convention? It seems wrong to me.
If you expand out hypot and substitute a=inf and b=nan, you get:
>>> math.sqrt(inf*inf + nan*nan)
nan
which agrees with my pencil-and-paper calculation:
sqrt(inf*inf + nan*nan)
= sqrt(inf + nan)
= sqrt(nan)
= nan
--
Steven D'Aprano
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ddicato%40microsoft.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] math.hypot, complex.__abs__, and documentation
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 that starts "Were there no way to get rid of NaNs ...". I don't think it covers hypot, but the same justification given for having nan**0 == 1 applies here. Interestingly, he says that at the time of writing, 1**nan == nan is the preferred alternative. But since then, the standards (well, at least C99 and IEEE 754-2008) have come out in favour of 1**nan == 1. Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] math.hypot, complex.__abs__, and documentation
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 7. Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
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 objects are naive unless you explicitly specify a timezone. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
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 can't see any way to preserve that flexibility if the >>> package were part of stdlib. >> >> By using what the OS provides. At least on Linux, the basic timezone >> data is usually updated by other means (at least on the distro I'm >> familiar with, it's updated quite often, too; through the package >> manager). I'm assuming Windows and OS X would also be able to provide >> something like this. I think pytz already looks at this data if it's >> available (precisely because it might well be newer). > > If that were so, I don't think Stuart would be going to the trouble to > re-release the library 6 - 12 times per year. 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. This way the package can be included in the supported release but still receive timezone information updates via the OS (but no code updates, but these are rare and usually irrelevant unless you where the person who filed the bug ;) ). I'd be happy to rework pytz for the standard Library using the system installed zoneinfo database if it is available. I think for the standard library though, it needs to follow the documented API better rather than the .normalize() & .localize rubbish I needed to get localized datetime arithmetic working correctly. Having seen the confusion and bug reports over the last few years, I think people who need this are in the minority and pytz can still exist as a separate package to support them. tzwin could be used on Windows platforms - I'd need to look into that further to see if the API can remain consistent between *nix and Windows. I suspect that pytz without the .normalize() & .localize() rubbish may look remarkably similar to dateutil so that might be a better option to start from. We could consider extending the existing datetime library to support localized datetime arithmetic. This would either involve adding an extra bit to datetime instances to support the is_dst flag (originally deemed unacceptable as it increased the pickle size by a whole byte), or better support for tzinfo implementations to store the is_dst flag in the tzinfo instance (the approach pytz used). This requires a C programmer though and I'm so very, very rusty. I am not at pycon alas. Some of my coworkers from Canonical will be though and they might be interested as we use pytz for Launchpad and other Canonical projects. -- Stuart Bishop http://www.stuartbishop.net/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add UTC to 2.7 (PyCon sprint idea)
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 :-) -Toshio pgpbt9HFJA542.pgp Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] embedding Python interpreter in non-console windows application
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 do output/input with.
I properly initialize the CRT and AllocConsole() to do this. I then
GetSTDHandle() for stdin and stdout accordingly
and open those handles with the requisite flags "read" for STDIN and "write"
for stdout. This all works great
and is then verified and tested to work by printf() and fgets(). This issue
however happens when attempting
to PyRun_InteractiveLoop() and PyRun_SimpleString(). A
PyRun_SimpleString("print 'test'") displays nothing in my
freshly allocated console window. Similarly a PyRun_InteractiveLoop(stdin,
NULL); yields nothing either even though
the line printf("testing"); directly ahead of it works just fine. Does
anyone have insight on how I can make this work
with the freshly allocated console's stdin/stdout/stderr?
SPECULATION:
That is the question, so now on to the speculation. I suspect that something
in the python runtime doesn't "get handles"
correctly for STDIN and STDOUT upon initialization. I have perused the
source code to find out exactly how this is done
and I suspect that it starts in PyInitializeEx with calls to
PySys_GetObject("stdin") and "stdout" accordingly. However I
don't actually see where this translates into the Python runtime checking
with the C-runtime for the "real" handles to STDIN and STDOUT. I dont ever
see the Python runtime "ask the system" where his handles to STDIN and
STDOUT are.
SUBSEQUENT QUESTION:
Is there anything I can do to initialize the Python interpreter (running as
a dll) pointing him at his appropriate STDIN and STDOUT
handles?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
