Steven D'Aprano wrote:
If I do x = 0.0/0 I get an exception instead of a NAN.
But the exception you get is ZeroDivisionError, so I think
Python is catching this before you get to the stage of
producing a NaN.
--
Greg
___
Python-Dev mailing list
Pyth
On Fri, Apr 29, 2011 at 11:35, Alexander Belopolsky
wrote:
> On Fri, Apr 29, 2011 at 11:31 AM, Robert Kern wrote:
> ..
>> And in fact, 0.0/0.0 is covered by the more general rule that x/0.0 raises
>> ZeroDivisionError, not a rule that converts IEEE-754 INVALID exceptions into
>> Python exceptions
Ricardo Kirkner wrote:
I'll give you the example I came upon:
I have a TestCase class, which inherits from both Django's TestCase
and from some custom TestCases that act as mixin classes. So I have
something like
class MyTestCase(TestCase, Mixin1, Mixin2):
...
now django's TestCase class in
Terry Reedy udel.edu> writes:
> > http://coverage.livinglogic.de/
>
> which, however, currently has nothing for *.py.
> Perhaps a glitch/bug, as there used to be such.
> Anyone who knows the page owner might ask about this.
>
Thanks for the pointer, nevertheless, Terry.
Regards,
Vinay Sajip
I know that the svn repo is now for legacy purposes only, but I doubt it
is intended that the online source browser should raise exceptions.
(See report below.)
All the best,
Michael
Original Message
Subject:viewVC shows traceback on non utf-8 module markup
Date: T
On 4/29/2011 3:11 PM, Terry Reedy wrote:
On 4/29/2011 12:09 PM, Vinay Sajip wrote:
BTW, is there a public place somewhere showing stdlib coverage
statistics? I
looked on the buildbot pages as the likeliest home for them, but
perhaps I
missed them.
http://docs.python.org/devguide/coverage.html
On 4/29/2011 12:09 PM, Vinay Sajip wrote:
BTW, is there a public place somewhere showing stdlib coverage statistics? I
looked on the buildbot pages as the likeliest home for them, but perhaps I
missed them.
http://docs.python.org/devguide/coverage.html
has a link to
http://coverage.livinglogic
On Fri, Apr 29, 2011 at 1:11 PM, Guido van Rossum wrote:
> … Would it make sense to add
> a float context that also lets one specify what should happen? That
> could include returning Inf for 1.0/0.0 (for experts), or raising
> exceptions when NaNs are produced (for the numerically naive like
> my
On Fri, Apr 29, 2011 at 12:10 AM, Stephen J. Turnbull
wrote:
> Other aspects of NaN behavior may be a mistake. But it's not clear to
> me, even after all the discussion in this thread.
ISTM that the current behavior of NaN (never mind the identity issue)
helps numeric experts write better code.
On Fri, Apr 29, 2011 at 11:31 AM, Robert Kern wrote:
..
> And in fact, 0.0/0.0 is covered by the more general rule that x/0.0 raises
> ZeroDivisionError, not a rule that converts IEEE-754 INVALID exceptions into
> Python exceptions.
It is unfortunate that official text of IEEE-754 is not freely
a
[Georg]
> > BTW, didn't we agree not to put "pragma" comments into the stdlib code?
I'd be grateful for a link to the prior discussion - it must have passed me by
originally, and I searched python-dev on gmane but couldn't find any threads
about this.
[Nick]
> I think some folks objected, but si
ACTIVITY SUMMARY (2011-04-22 - 2011-04-29)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open2760 ( +8)
closed 20976 (+39)
total 23736 (+47)
Open issues wit
On 4/29/11 1:35 AM, Nick Coghlan wrote:
On Fri, Apr 29, 2011 at 3:28 PM, Steven D'Aprano wrote:
Robert Kern wrote:
Actually, Python treats all NaNs as quiet NaNs and never signalling NaNs.
Sorry, did I get that backwards? I thought it was signalling NANs that cause
a signal (in Python terms,
> You can implement this in your own subclass of dict, no?
Yes, I just thought it would be convenient to have in the language
itself, but the responses to my post seem to indicate that [not
returning the updated object] is an intended language feature for
mutable types like dict or list.
class
2011/4/29 R. David Murray :
> 2011/4/29 Roy Hyunjin Han :
>> It would be convenient if replacing items in a dictionary returns the
>> new dictionary, in a manner analogous to str.replace()
>
> This belongs on python-ideas, but the short answer is no. The
> general language design principle (as I u
Hi! Seems like a question for python-ideas mailing list, not for python-dev.
On Fri, Apr 29, 2011 at 10:27:46AM -0400, Roy Hyunjin Han wrote:
> It would be convenient if replacing items in a dictionary returns the
> new dictionary, in a manner analogous to str.replace(). What do you
> think?
> ::
On Fri, 29 Apr 2011 10:27:46 -0400, Roy Hyunjin Han
wrote:
> It would be convenient if replacing items in a dictionary returns the
> new dictionary, in a manner analogous to str.replace(). What do you
> think?
This belongs on python-ideas, but the short answer is no. The
general language desig
Roy Hyunjin Han wrote:
It would be convenient if replacing items in a dictionary returns the
new dictionary, in a manner analogous to str.replace(). What do you
think?
::
# Current behavior
x = {'key1': 1}
x.update(key1=3) == None
x == {'key1': 3} # Original variable has change
It would be convenient if replacing items in a dictionary returns the
new dictionary, in a manner analogous to str.replace(). What do you
think?
::
# Current behavior
x = {'key1': 1}
x.update(key1=3) == None
x == {'key1': 3} # Original variable has changed
# Possible behavior
Steven D'Aprano writes:
> I'm sorry for my lack of clarity. I'm referring to functions which
> potentially produce NANs, not the exceptions themselves. A calculation
> which might have produced a (quiet) NAN as the result instead raises
> an exception (which I'm treating as equivalent to a signal
On Fri, 29 Apr 2011 14:29:46 +0200
DasIch wrote:
> Given those facts I think including pybench is a mistake. It does not
> allow for a fair or meaningful comparison between implementations
> which is one of the things the suite is supposed to be used for in the
> future.
"Including" is quite vagu
DasIch wrote:
> Given those facts I think including pybench is a mistake. It does not
> allow for a fair or meaningful comparison between implementations
> which is one of the things the suite is supposed to be used for in the
> future.
>
> This easily leads to misinterpretation of the results fro
Given those facts I think including pybench is a mistake. It does not
allow for a fair or meaningful comparison between implementations
which is one of the things the suite is supposed to be used for in the
future.
This easily leads to misinterpretation of the results from this
particular benchmar
On Fri, Apr 29, 2011 at 9:44 PM, Georg Brandl wrote:
> On 27.04.2011 23:23, Vinay Sajip wrote:
>> I've been recently trying to improve the test coverage for the logging
>> package,
>> and have got to a not unreasonable point:
>>
>> logging/__init__.py 99% (96%)
>> logging/config.py 89% (85%)
>> l
On 27.04.2011 23:23, Vinay Sajip wrote:
> I've been recently trying to improve the test coverage for the logging
> package,
> and have got to a not unreasonable point:
>
> logging/__init__.py 99% (96%)
> logging/config.py 89% (85%)
> logging/handlers.py 60% (54%)
>
> where the figures in parenth
On 28 April 2011 23:07, Guido van Rossum wrote:
> On Thu, Apr 28, 2011 at 2:53 PM, Raymond Hettinger
> wrote:
>>
>> On Apr 28, 2011, at 1:27 PM, Holger Krekel wrote:
>>
>>> On Thu, Apr 28, 2011 at 6:59 PM, Guido van Rossum wrote:
On Thu, Apr 28, 2011 at 12:54 AM, Tarek Ziadé
wrote:
>
On 29/04/2011 11:04, M.-A. Lemburg wrote:
Mark Shannon wrote:
Maciej Fijalkowski wrote:
On Thu, Apr 28, 2011 at 11:10 PM, Stefan Behnel
wrote:
M.-A. Lemburg, 28.04.2011 22:23:
Stefan Behnel wrote:
DasIch, 28.04.2011 20:55:
the CPython
benchmarks have an extensive set of microbenchmarks in t
Mark Shannon wrote:
> Maciej Fijalkowski wrote:
>> On Thu, Apr 28, 2011 at 11:10 PM, Stefan Behnel
>> wrote:
>>> M.-A. Lemburg, 28.04.2011 22:23:
Stefan Behnel wrote:
> DasIch, 28.04.2011 20:55:
>> the CPython
>> benchmarks have an extensive set of microbenchmarks in the pybench
>
On Fri, Apr 29, 2011 at 10:02 AM, Eli Bendersky wrote:
> I completely understand this "other code/thread deletes the path
> between exists() and unlink()" case - it indeed is a race condition
> waiting to happen. What I didn't understand was Antoine's example of
> "attacker creates targetpath betw
Maciej Fijalkowski wrote:
On Thu, Apr 28, 2011 at 11:10 PM, Stefan Behnel wrote:
M.-A. Lemburg, 28.04.2011 22:23:
Stefan Behnel wrote:
DasIch, 28.04.2011 20:55:
the CPython
benchmarks have an extensive set of microbenchmarks in the pybench
package
Try not to care too much about pybench. The
On Fri, Apr 29, 2011 at 9:55 AM, Holger Krekel wrote:
> On Fri, Apr 29, 2011 at 12:31 AM, Raymond Hettinger
> wrote:
>>
>> On Apr 28, 2011, at 3:07 PM, Guido van Rossum wrote:
>>
>>> On Thu, Apr 28, 2011 at 2:53 PM, Raymond Hettinger
>>> wrote:
On Apr 28, 2011, at 1:27 PM, Holger Kreke
On Fri, Apr 29, 2011 at 09:52, Nick Coghlan wrote:
> On Fri, Apr 29, 2011 at 4:26 PM, Eli Bendersky wrote:
On Thu, Apr 28, 2011 at 04:20:06PM +0200, Éric Araujo wrote:
>>> The kind of race condition which can happen here is if an attacker
>>> creates "targetpath" between os.path.exists and o
On Fri, Apr 29, 2011 at 12:31 AM, Raymond Hettinger
wrote:
>
> On Apr 28, 2011, at 3:07 PM, Guido van Rossum wrote:
>
>> On Thu, Apr 28, 2011 at 2:53 PM, Raymond Hettinger
>> wrote:
>>>
>>> On Apr 28, 2011, at 1:27 PM, Holger Krekel wrote:
>>>
On Thu, Apr 28, 2011 at 6:59 PM, Guido van Rossu
Terry Reedy writes:
> > Python treats it as if it were a number:
>
> As I said, so did the committee, and that was its mistake that we are
> more or less stuck with.
The committee didn't really have a choice. You could ask that they
call NaNs something else, but some bit pattern is going t
34 matches
Mail list logo
