Nick Coghlan gmail.com> writes:
> If you poke around in the test directory a bit, you may find there is
> already some code along these lines in other tests (e.g. I'm pretty
> sure the urllib tests already fire up a local server). Starting down
> the path of standardisation of that test functiona
On 4/27/2011 11:54 PM, Nick Coghlan wrote:
On Thu, Apr 28, 2011 at 4:20 PM, Glenn Linderman wrote:
In that bug, Nick, you mention that reflexive equality is something that
container classes rely on in their implementation. Such reliance seems to
me to be a bug, or an inappropriate optimization
On Thu, Apr 28, 2011 at 2:54 AM, Nick Coghlan wrote:
..
> No, as Raymond has articulated a number of times over the years, it's
> a property of the equivalence relation that is needed in order to
> present sane invariants to users of the container. I included in the
> bug report the critical invar
On Thu, Apr 28, 2011 at 5:27 PM, Glenn Linderman wrote:
> Without having read the original articulations by Raymond or any discussions
> of the pros and cons,
In my first post to this thread, I pointed out the bug tracker item
(http://bugs.python.org/issue4296) that included the discussion of
re
Hello
I removed some assert calls in distutils some time ago because the
package was not behaving correctly when people were using Python with
the --optimize flag. In other words, assert became a full part of the
code logic and removing them via -O was changing the behavior.
In my opinion assert
On Thu, Apr 28, 2011 at 5:30 PM, Alexander Belopolsky
wrote:
> On Thu, Apr 28, 2011 at 2:54 AM, Nick Coghlan wrote:
> ..
>> No, as Raymond has articulated a number of times over the years, it's
>> a property of the equivalence relation that is needed in order to
>> present sane invariants to user
On 04/28/2011 04:31 AM, Stephen J. Turnbull wrote:
Are you saying you would expect that
nan = float('nan')
a = [1, ..., 499, nan, 501, ..., 999]# meta-ellipsis, not Ellipsis
a == a
False
??
I would expect l1 == l2, where l1 and l2 are both lists, to be
semantically equivalent to len
On Thu, Apr 28, 2011 at 3:57 AM, Nick Coghlan wrote:
..
>> It is an interesting question of what "sane invariants" are. Why you
>> consider the invariants that you listed essential while say
>>
>> if c1 == c2:
>> assert all(x == y for x,y in zip(c1, c2))
>>
>> optional?
>
> Because this asserti
On 4/28/2011 3:54 AM, Tarek Ziadé wrote:
Hello
I removed some assert calls in distutils some time ago because the
package was not behaving correctly when people were using Python with
the --optimize flag. In other words, assert became a full part of the
code logic and removing them via -O was ch
On 4/28/2011 12:32 AM, Nick Coghlan wrote:
On Thu, Apr 28, 2011 at 5:27 PM, Glenn Linderman wrote:
Without having read the original articulations by Raymond or any discussions
of the pros and cons,
In my first post to this thread, I pointed out the bug tracker item
(http://bugs.python.org/iss
Related to the discussion on "Not a Number" can I point out a few things
that have not be explicitly addressed so far.
The IEEE standard is about hardware and bit patterns, rather than types
and values so may not be entirely appropriate for high-level language
like Python.
NaN is *not* a numb
Nick Coghlan wrote:
Because this assertion is an assertion about the behaviour of
comparisons that violates IEEE754, while the assertions I list are all
assertions about the behaviour of containers that can be made true
*regardless* of IEEE754 by checking identity explicitly.
Aren't you making
Mark Shannon wrote:
NaN does not have to be a float or a Decimal.
Perhaps it should have its own class.
Perhaps, but that wouldn't solve anything on its own. If
this new class compares reflexively, then it still violates
IEE754. Conversely, existing NaNs could be made to compare
reflexively wi
On Thu, Apr 28, 2011 at 6:30 PM, Alexander Belopolsky
wrote:
> On Thu, Apr 28, 2011 at 3:57 AM, Nick Coghlan wrote:
> ..
>>> It is an interesting question of what "sane invariants" are. Why you
>>> consider the invariants that you listed essential while say
>>>
>>> if c1 == c2:
>>> assert all(
On Thu, Apr 28, 2011 at 7:10 PM, Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> Because this assertion is an assertion about the behaviour of
>> comparisons that violates IEEE754, while the assertions I list are all
>> assertions about the behaviour of containers that can be made true
>> *regardless
On 28/04/2011 09:34, Terry Reedy wrote:
On 4/28/2011 3:54 AM, Tarek Ziadé wrote:
Hello
I removed some assert calls in distutils some time ago because the
package was not behaving correctly when people were using Python with
the --optimize flag. In other words, assert became a full part of the
c
On Thu, Apr 28, 2011 at 7:17 PM, Greg Ewing wrote:
> Mark Shannon wrote:
>
>> NaN does not have to be a float or a Decimal.
>> Perhaps it should have its own class.
>
> Perhaps, but that wouldn't solve anything on its own. If
> this new class compares reflexively, then it still violates
> IEE754.
On Thu, 28 Apr 2011 07:23:43 + (UTC)
Vinay Sajip wrote:
> Nick Coghlan gmail.com> writes:
>
> > If you poke around in the test directory a bit, you may find there is
> > already some code along these lines in other tests (e.g. I'm pretty
> > sure the urllib tests already fire up a local ser
On Thu, 28 Apr 2011 07:23:43 + (UTC)
Vinay Sajip wrote:
> Nick Coghlan gmail.com> writes:
>
> > If you poke around in the test directory a bit, you may find there is
> > already some code along these lines in other tests (e.g. I'm pretty
> > sure the urllib tests already fire up a local ser
On Thu, Apr 28, 2011 at 12:27 PM, Michael Foord
wrote:
> On 28/04/2011 09:34, Terry Reedy wrote:
>>
>> On 4/28/2011 3:54 AM, Tarek Ziadé wrote:
>>>
>>> Hello
>>>
>>> I removed some assert calls in distutils some time ago because the
>>> package was not behaving correctly when people were using Pyt
2011/4/27 Vinay Sajip :
> 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 parentheses include branc
On Thu, 28 Apr 2011 09:54:23 +0200
Tarek Ziadé wrote:
>
> I have seen some other places where thing would simply break with -O.
>
> Am I right thinking we should do a pass on those and remove them or
> turn them into exception that are triggered with -O as well ?
Agreed. Argument checking shoul
I am not a specialist in this area (although I call myself a
mathematician). But they say that sometimes the outsider sees most of
the game, or more likely that sometimes the idiot's point of view is useful.
To me the idea of non-reflexive equality (an object not being equal to
itself) is abh
Hi,
> But what I would like to know, is if is there any reason why XML-RPC can't
> optionally work over TLS/SSL using Python's ssl module. I'll create a
> ticket, and send a patch, but I was wondering if it was a reason why this
> was not implemented.
I think there’s no deeper reason than nobody
Hi,
>> I'm at the point where to appreciably increase coverage, I'd need to write
>> some
>> test servers to exercise client code in SocketHandler, DatagramHandler and
>> HTTPHandler.
>>
>> I notice there are no utility classes in test.support to help with this kind
>> of
>> thing - would there
Hi,
I’m still educating myself about concurrency and race conditions, so I
hope my naïve question won’t be just a waste of time. Here it is:
> http://hg.python.org/cpython/rev/0c8bc3a0130a
> user:Senthil Kumaran
> summary:
> Fix closes issue10761: tarfile.extractall failure when sym
Hi,
> http://hg.python.org/cpython/rev/57c076ab4bbd
> user:Łukasz Langa
> --- a/Lib/test/test_cfgparser.py
> +++ b/Lib/test/test_cfgparser.py
> @@ -20,10 +20,16 @@
> def values(self):
> return [i[1] for i in self.items()]
>
> -def iteritems(self): return iter(self.ite
Hi,
> http://hg.python.org/cpython/rev/5185e1d91f3d
> user:Vinay Sajip
> summary:
> Refined time test in test_logging.
> +ZERO = datetime.timedelta(0)
> +
> +class UTC(datetime.tzinfo):
> +def utcoffset(self, dt):
> +return ZERO
> +
> +dst = utcoffset
> +
> +def tzn
On Apr 28, 2011, at 04:34 AM, Terry Reedy wrote:
>On 4/28/2011 3:54 AM, Tarek Ziadé wrote:
>> Hello
>>
>> I removed some assert calls in distutils some time ago because the
>> package was not behaving correctly when people were using Python with
>> the --optimize flag. In other words, assert becam
On Thu, Apr 28, 2011 at 04:20:06PM +0200, Éric Araujo wrote:
> > if hasattr(os, "symlink") and hasattr(os, "link"):
> > # For systems that support symbolic and hard links.
> > if tarinfo.issym():
> > +if os.path.exists(targetpath):
> > +
Mark Shannon wrote:
Related to the discussion on "Not a Number" can I point out a few things
that have not be explicitly addressed so far.
The IEEE standard is about hardware and bit patterns, rather than types
and values so may not be entirely appropriate for high-level language
like Python.
On Thu, Apr 28, 2011 at 10:37 AM, Barry Warsaw wrote:
> I would agree. Use asserts for "this can't possibly happen "
> conditions.
Maybe we should rename "assert" to "wink", just to be clear on the usage. :-)
-Fred
--
Fred L. Drake, Jr.
"Give me the luxuries of life and I will willing
Barry> I would agree. Use asserts for "this can't possibly happen
Barry> " conditions.
Without looking, I suspect that's probably what the author thought he was
doing.
Skip
___
Python-Dev mailing list
[email protected]
http://mail.python.o
On Apr 28, 2011, at 10:22 AM, [email protected] wrote:
>Barry> I would agree. Use asserts for "this can't possibly happen
>Barry> " conditions.
>
>Without looking, I suspect that's probably what the author thought he was
>doing.
BTW, I think it always helps to have a really good assert mess
On Apr 28, 2011, at 11:04 AM, Fred Drake wrote:
>On Thu, Apr 28, 2011 at 10:37 AM, Barry Warsaw wrote:
>> I would agree. Use asserts for "this can't possibly happen "
>> conditions.
>
>Maybe we should rename "assert" to "wink", just to be clear on the usage. :-)
Off to python-ideas for you!
On Thu, 28 Apr 2011 22:44:50 +0800
Senthil Kumaran wrote:
> On Thu, Apr 28, 2011 at 04:20:06PM +0200, Éric Araujo wrote:
> > > if hasattr(os, "symlink") and hasattr(os, "link"):
> > > # For systems that support symbolic and hard links.
> > > if tarinfo.issym():
>
On Thu, Apr 28, 2011 at 4:44 PM, Senthil Kumaran wrote:
> On Thu, Apr 28, 2011 at 04:20:06PM +0200, Éric Araujo wrote:
>> > if hasattr(os, "symlink") and hasattr(os, "link"):
>> > # For systems that support symbolic and hard links.
>> > if tarinfo.issym():
>> > +
On Thu, Apr 28, 2011 at 5:26 PM, Barry Warsaw wrote:
> On Apr 28, 2011, at 10:22 AM, [email protected] wrote:
>
>> Barry> I would agree. Use asserts for "this can't possibly happen
>> Barry> " conditions.
>>
>>Without looking, I suspect that's probably what the author thought he was
>>doing.
>
On 4/27/11 11:54 PM, Guido van Rossum wrote:
On Wed, Apr 27, 2011 at 9:25 PM, Robert Kern wrote:
On 2011-04-27 23:01 , Guido van Rossum wrote:
And I wouldn't want to change that. It sounds like NumPy wouldn't be
much affected if we were to change this (which I'm not saying we
would).
Well, I
On 4/28/11 12:37 AM, Alexander Belopolsky wrote:
On Thu, Apr 28, 2011 at 12:33 AM, Robert Kern wrote:
On 2011-04-27 23:24 , Guido van Rossum wrote:
..
So do new masks get created when the outcome of an elementwise
operation is a NaN?
No.
Yes.
from MA import array
print array([0])/array(
Steven D'Aprano wrote:
Mark Shannon wrote:
Related to the discussion on "Not a Number" can I point out a few things
that have not be explicitly addressed so far.
The IEEE standard is about hardware and bit patterns, rather than types
and values so may not be entirely appropriate for high-leve
On 28/04/2011 15:58, Steven D'Aprano wrote:
Fundamentally, the problem is that some containers bypass equality
tests for identity tests. There may be good reasons for that shortcut,
but it leads to problems with *any* object that does not define
equality to be reflexive, not just NANs.
I say y
Mark Shannon wrote:
Steven D'Aprano wrote:
Mark Shannon wrote:
Related to the discussion on "Not a Number" can I point out a few
things that have not be explicitly addressed so far.
The IEEE standard is about hardware and bit patterns, rather than
types and values so may not be entirely appr
[This is a mega-reply, combining responses to several messages in this
thread. I may be repeating myself a bit, but I think I am being
consistent. :-)]
On Wed, Apr 27, 2011 at 10:12 PM, Nick Coghlan wrote:
> On Thu, Apr 28, 2011 at 2:54 PM, Guido van Rossum wrote:
>>> Well, I didn't say that. I
On Thu, Apr 28, 2011 at 12:54 AM, Tarek Ziadé wrote:
> In my opinion assert should be avoided completely anywhere else than
> in the tests. If this is a wrong statement, please let me know why :)
I would turn that around. The assert statement should not be used in
unit tests; unit tests should us
Alexander Belopolsky wrote:
With the status quo in Python, it may only make sense to store NaNs in
array.array, but not in a list.
That's a bit extreme. It only gets you into trouble if you reason like this:
>>> a = b = [1, 2, 3, float('nan')]
>>> if a == b:
... for x,y in zip(a,b):
...
Rob Cliffe wrote:
To me the idea of non-reflexive equality (an object not being equal to
itself) is abhorrent. Nothing is more likely to put off new Python
users if they happen to run into it.
I believe that's a gross exaggeration. In any case, that's just your
opinion, and Python is hardly
Guido van Rossum wrote:
*If* my proposal gets accepted, there will be a blanket rule that no
matter how exotic an type's __eq__ is defined, self.__eq__(self)
(i.e., __eq__ called with the same *object* argument) must return True
if the type's __eq__ is to be considered well-behaved; and Python
c
Steven D'Aprano wrote:
I know thousands of words have been spilled on this, including many by
myself, but I really believe this discussion is mostly bike-shedding.
Hmmm... on reflection, I think I may have been a bit unfair. In
particular, I don't mean any slight on any of the people who hav
On Apr 28, 2011, at 12:59 PM, Guido van Rossum wrote:
> On Thu, Apr 28, 2011 at 12:54 AM, Tarek Ziadé wrote:
>> In my opinion assert should be avoided completely anywhere else than
>> in the tests. If this is a wrong statement, please let me know why :)
>
> I would turn that around. The assert
On Thu, Apr 28, 2011 at 1:25 PM, Steven D'Aprano wrote:
..
> But it's perfectly fine to do this:
>
sum(a)
> nan
>
This use case reminded me Kahan's
"""
Were there no way to get rid of NaNs, they would be as useless as
Indefinites on CRAYs; as soon as one were encountered, computation
would
On 28/04/2011 18:26, Steven D'Aprano wrote:
Rob Cliffe wrote:
To me the idea of non-reflexive equality (an object not being equal
to itself) is abhorrent. Nothing is more likely to put off new
Python users if they happen to run into it.
I believe that's a gross exaggeration. In any case, th
Hello,
As announced in my GSoC proposal I'd like to announce which benchmarks
I'll use for the benchmark suite I will work on this summer.
As of now there are two benchmark suites (that I know of) which
receive some sort of attention, those are the ones developed as part
of the PyPy project[1] whi
Éric Araujo wrote:
> Hi,
>
> > But what I would like to know, is if is there any reason why XML-RPC can't
> > optionally work over TLS/SSL using Python's ssl module. I'll create a
> > ticket, and send a patch, but I was wondering if it was a reason why this
> > was not implemented.
>
> I think
On 4/28/2011 6:11 AM, Nick Coghlan wrote:
On Thu, Apr 28, 2011 at 6:30 PM, Alexander Belopolsky
wrote:
On Thu, Apr 28, 2011 at 3:57 AM, Nick Coghlan wrote:
..
It is an interesting question of what "sane invariants" are. Why you
consider the invariants that you listed essential while say
if
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. There is some value in it, but some
of its microbenchmarks are also tied to CPython's interpreter behaviour.
For example, the benchmarks for
ISTM there is no right or wrong answer.
There is just a question of what is most useful.
AFAICT, the code for dictionaries (and therefore the code for sets)
has always had identity-implies-equality logic. It makes dicts
blindingly fast for common cases. It also confers some nice
properties like
On 4/28/2011 4:40 AM, Mark Shannon wrote:
NaN is *not* a number (the clue is in the name).
The problem is that the committee itself did not believe or stay
consistent with that. In the text of the draft, they apparently refer to
Nan as an indefinite, unspecified *number*. Sort of like a rand
On Thu, Apr 28, 2011 at 9:51 PM, Raymond Hettinger <
[email protected]> wrote:
> Personally, I think the status quo is fine
> and that practicality is beating purity.
>
+1
>
> Raymond
>
cheers
lvh
___
Python-Dev mailing list
Python-Dev@pyth
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. There is some value in it, but
> some of its microbenchmarks are also tied to CPython's interpreter
> behavio
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:
>> In my opinion assert should be avoided completely anywhere else than
>> in the tests. If this is a wrong statement, please let me know why :)
>
> I would turn that around. The assert
On 4/28/2011 12:55 PM, Guido van Rossum wrote:
*If* my proposal gets accepted, there will be a blanket rule that no
matter how exotic an type's __eq__ is defined, self.__eq__(self)
(i.e., __eq__ called with the same *object* argument) must return True
if the type's __eq__ is to be considered wel
On 4/28/2011 11:22 AM, [email protected] wrote:
Barry> I would agree. Use asserts for "this can't possibly happen
Barry> " conditions.
Without looking, I suspect that's probably what the author thought he was
doing.
You wish: to repeat the example from threading:
def __init__(se
On 4/28/11 3: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:
In my opinion assert should be avoided completely anywhere else than
in the tests. If this is a wrong statement, please let me know why :)
I
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. There is some value in it, but
some of its microbenchmarks are also tied to CPython's
On Thu, Apr 28, 2011 at 1:48 PM, Terry Reedy wrote:
> On 4/28/2011 12:55 PM, Guido van Rossum wrote:
>
>> *If* my proposal gets accepted, there will be a blanket rule that no
>> matter how exotic an type's __eq__ is defined, self.__eq__(self)
>> (i.e., __eq__ called with the same *object* argument
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:
>>> In my opinion assert should be avoided completely anywhere else than
>>> in the tests. If this is a wrong statement, please le
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:
In my opinion assert should be avoided completely anywhere e
On 4/28/11 11:55 AM, Guido van Rossum wrote:
On Thu, Apr 28, 2011 at 8:52 AM, Robert Kern wrote:
Smaller, certainly. But now it's a trilemma. :-)
1. Have just np.float64 and np.complex128 scalars follow the Python float
semantics since they subclass Python float and complex, respectively.
2.
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 Rossum wrote:
On Thu, Apr 28, 2011 at 12:54 AM, Tarek Ziadé
On Fri, Apr 29, 2011 at 5:51 AM, Raymond Hettinger
wrote:
> * x = obj implies x == obj # assignment really works
While I agree with your point of view regarding the status quo as a
useful, practical compromise, I need to call out that particular
example:
>>> nan = float('nan')
>>> x = nan
>>>
On Thu, Apr 28, 2011 at 3:22 PM, Robert Kern wrote:
> On 4/28/11 11:55 AM, Guido van Rossum wrote:
>
>> On Thu, Apr 28, 2011 at 8:52 AM, Robert Kern
>> wrote:
>>>
>>> Smaller, certainly. But now it's a trilemma. :-)
>>>
>>> 1. Have just np.float64 and np.complex128 scalars follow the Python float
On Fri, Apr 29, 2011 at 8:55 AM, Guido van Rossum wrote:
> Sorry, we'll have to make an exception for those of course. This will
> somewhat complicate the interpretation of well-behaved, because those
> are *not* well-behaved as far as containers go (both dict key lookup
> and list membership are
2011/4/28 Raymond Hettinger :
> It might be nice if there were a pragma or module variable to selectively
> enable asserts for a given test module so that -O would turn-off asserts in
> the production code but leave them on in a test_suite.
from __future__ import perfect_code_so_no_asserts
:)
On Fri, Apr 29, 2011 at 2:55 AM, Guido van Rossum wrote:
> Raymond strongly believes that containers must be allowed to use the
> modified definition, I believe purely for performance reasons.
> (Without this rule, a list or tuple could not even cut short being
> compared to *itself*.) It seems yo
On Thu, Apr 28, 2011 at 4:04 PM, Nick Coghlan wrote:
> On Fri, Apr 29, 2011 at 8:55 AM, Guido van Rossum wrote:
>> Sorry, we'll have to make an exception for those of course. This will
>> somewhat complicate the interpretation of well-behaved, because those
>> are *not* well-behaved as far as con
On Fri, Apr 29, 2011 at 9:13 AM, Guido van Rossum wrote:
>> I hadn't really thought about it that way before this discussion - it
>> is the identity checking behaviour of the builtin containers that lets
>> us sensibly handle cases like sets of NumPy arrays.
>
> But do they? For non-empty arrays,
On Thu, Apr 28, 2011 at 4:40 PM, Nick Coghlan wrote:
> Pondering the NaN problem further, I think we can relatively easily
> argue that reflexive behaviour at the object level fits within the
> scope of IEEE754.
Now we're talking. :-)
> 1. IEEE754 is a value-based system, with a finite number of
On Thu, Apr 28, 2011 at 7:47 PM, Guido van Rossum wrote:
> On Thu, Apr 28, 2011 at 4:40 PM, Nick Coghlan wrote:
>> Pondering the NaN problem further, I think we can relatively easily
>> argue that reflexive behaviour at the object level fits within the
>> scope of IEEE754.
>
> Now we're talking.
On 4/28/2011 4:40 PM, Nick Coghlan wrote:
Hmm, true. And things like count() and index() would still be
thoroughly broken for sequences. OK, so scratch that idea - there's
simply no sane way to handle such objects without using an
identity-based container that ignores equality definitions altoget
On Thu, Apr 28, 2011 at 5:24 PM, Glenn Linderman wrote:
> Would it be reasonable to implement 3 types of containers:
That's something for python-ideas. Occasionally containers that use
custom comparisons come in handy (e.g. case-insensitive dicts).
--
--Guido van Rossum (python.org/~guido)
Terry Reedy wrote:
I think the committee goofed -- badly. Statisticians used missing value
indicators long before the committee existed. They has no problem
thinking that the indicator, as an object, equaled itself. So one could
write (and I often did through the 1980s) the equivalent of
for
On 4/28/11 6:13 PM, Guido van Rossum wrote:
On Thu, Apr 28, 2011 at 4:04 PM, Nick Coghlan wrote:
On Fri, Apr 29, 2011 at 8:55 AM, Guido van Rossum wrote:
Sorry, we'll have to make an exception for those of course. This will
somewhat complicate the interpretation of well-behaved, because those
Nick Coghlan wrote:
I hadn't really thought about it that way before this discussion - it
is the identity checking behaviour of the builtin containers that lets
us sensibly handle cases like sets of NumPy arrays.
Except that it doesn't:
>>> from numpy import array
>>> a1 = array([1,2])
>>> a2
Terry Reedy writes:
> On 4/28/2011 4:40 AM, Mark Shannon wrote:
> > NaN does not have to be a float or a Decimal.
> > Perhaps it should have its own class.
>
> Like None
Would it make sense for ‘NaN’ to be another instance of ‘NoneType’?
--
\ “I am too firm in my consciousness of the mar
Taking a step back from all this, why does Python allow
NaNs to arise from computations *at all*?
+Inf and -Inf are arguably useful elements of the algebra,
yet Python insists on raising an exception for 1.0./0.0
instead of returning an infinity.
Why do this but not raise an exception for any op
On Fri, Apr 29, 2011 at 11:11 AM, Ben Finney wrote:
> Would it make sense for ‘NaN’ to be another instance of ‘NoneType’?
This is fine IHMO as I (personally) find myself doing things like:
if x is None:
...
cheers
James
--
-- James Mills
--
-- "Problems are solved by method"
_
Nick Coghlan wrote:
1. IEEE754 is a value-based system, with a finite number of distinct
NaN payloads
2. Python is an object-based system. In addition to their payload, NaN
objects are further distinguished by their identity (infinite in
theory, in practice limited by available memory).
I argu
Greg Ewing wrote:
Taking a step back from all this, why does Python allow
NaNs to arise from computations *at all*?
The real question should be, why does Python treat all NANs as
signalling NANs instead of quiet NANs? I don't believe this helps anyone.
+Inf and -Inf are arguably useful elem
On 4/28/11 8:44 PM, Steven D'Aprano wrote:
Greg Ewing wrote:
Taking a step back from all this, why does Python allow
NaNs to arise from computations *at all*?
The real question should be, why does Python treat all NANs as signalling NANs
instead of quiet NANs? I don't believe this helps anyone
Tarek Ziadé writes:
> On Thu, Apr 28, 2011 at 5:26 PM, Barry Warsaw wrote:
> > BTW, I think it always helps to have a really good assert message, and/or a
> > leading comment to explain *why* that condition can't possibly happen.
>
> why bother, it can't happen ;)
Except before breakfast,
Steven D'Aprano writes:
> (I grant that Alexander is an exception -- I understand that he does do
> a lot of numeric work, and does come across NANs, and still doesn't like
> them one bit.)
I don't think I'd want anybody who *likes* NaNs to have a commit bit
at python.org.
__
Robert Kern wrote:
On 4/28/11 8:44 PM, Steven D'Aprano wrote:
Greg Ewing wrote:
Taking a step back from all this, why does Python allow
NaNs to arise from computations *at all*?
The real question should be, why does Python treat all NANs as
signalling NANs
instead of quiet NANs? I don't bel
>> On Thu, Apr 28, 2011 at 04:20:06PM +0200, Éric Araujo wrote:
>> > > if hasattr(os, "symlink") and hasattr(os, "link"):
>> > > # For systems that support symbolic and hard links.
>> > > if tarinfo.issym():
>> > > + if os.path.exists(targetpath):
>
Steven D'Aprano writes:
> Robert Kern wrote:
> > On 4/28/11 8:44 PM, Steven D'Aprano wrote:
> >> The real question should be, why does Python treat all NANs as
> >> signalling NANs instead of quiet NANs? I don't believe this helps
> >> anyone.
> >
> > Actually, Python treats all NaNs as quiet NaN
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, an exception)?
>
> If I do x = 0.0
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 p
Ben Finney wrote:
Steven D'Aprano writes:
Robert Kern wrote:
On 4/28/11 8:44 PM, Steven D'Aprano wrote:
The real question should be, why does Python treat all NANs as
signalling NANs instead of quiet NANs? I don't believe this helps
anyone.
Actually, Python treats all NaNs as quiet NaNs and
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 os.unlink. Whether it
>> is an exploitable flaw would need
99 matches
Mail list logo
