On Sat, Jul 12, 2014 at 3:07 PM, Alan Bawden
a...@scooby-doo.csail.mit.edu wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:
But perhaps we only care about changes in value, not type. NAN or no NAN,
list equality works fine:
py data = [1.0, 2.0, float('nan'), 4.0]
py old =
Hallöchen!
Alan Bawden writes:
[...]
You lost me right here. If list equality is determined by
comparing lists element-by-element, and the second element of old
is _not_ equal to the second element of data, then why should old
and data be equal?
I think Python first tests for identity,
Hallöchen!
Torsten Bronger writes:
Alan Bawden writes:
[...]
You lost me right here. If list equality is determined by
comparing lists element-by-element, and the second element of old
is _not_ equal to the second element of data, then why should old
and data be equal?
I think Python
On 07/11/2014 10:07 PM, Alan Bawden wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:
But perhaps we only care about changes in value, not type. NAN or no NAN,
list equality works fine:
py data = [1.0, 2.0, float('nan'), 4.0]
py old = data[:]
py old == data # No changes
On Sat, Jul 12, 2014 at 4:11 PM, Ethan Furman et...@stoneleaf.us wrote:
class list:
def __eq__(self, other):
if len(self) != len(other):
return False
for this, that in zip(self, other):
if this is that or this == that:
continue
Chris Angelico ros...@gmail.com:
On Sat, Jul 12, 2014 at 4:11 PM, Ethan Furman et...@stoneleaf.us wrote:
class list:
def __eq__(self, other):
if len(self) != len(other):
return False
for this, that in zip(self, other):
if this is that or this ==
On 07/11/2014 11:39 PM, Chris Angelico wrote:
On Sat, Jul 12, 2014 at 4:11 PM, Ethan Furman et...@stoneleaf.us wrote:
class list:
def __eq__(self, other):
if len(self) != len(other):
return False
for this, that in zip(self, other):
if this is
On Sat, Jul 12, 2014 at 4:53 PM, Ethan Furman et...@stoneleaf.us wrote:
Because I'm tired, and it seemed like a good excuse to show else with for,
and because I'm tired. :)
Excellent justification. I withdraw the criticism. :)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
On Sat, 12 Jul 2014 01:07:28 -0400, Alan Bawden wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:
But perhaps we only care about changes in value, not type. NAN or no
NAN, list equality works fine:
py data = [1.0, 2.0, float('nan'), 4.0]
py old = data[:]
py old == data
On 09.07.2014 11:17, Steven D'Aprano wrote:
People are already having problems, just listen to Anders. He's
(apparently) not doing NAN-aware computations on his data, he just wants
to be able to do something like
this_list_of_floats == that_list_of_floats
This is a horrible example.
On Sat, 12 Jul 2014 13:54:07 +0200, Johannes Bauer wrote:
On 09.07.2014 11:17, Steven D'Aprano wrote:
People are already having problems, just listen to Anders. He's
(apparently) not doing NAN-aware computations on his data, he just
wants to be able to do something like
On Sun, Jul 13, 2014 at 2:35 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
You're not going to hear me arguing that the non-reflexivity of NANs and
SQL NULL is a bad idea, although some very smart people have:
On 12.07.2014 18:35, Steven D'Aprano wrote:
If you said, for many purposes, one should not compare floats for
equality, but should use some sort of fuzzy comparison instead then I
would agree with you. But your insistence that equality always is wrong
takes it out of good advice into the
In article mailman.11777.1405184093.18130.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
And there are plenty of other laws of real numbers that floats violate
(or, let's be generous, approximate to rather than following
perfectly). For instance, adding two positive
On Sun, Jul 13, 2014 at 4:14 AM, Johannes Bauer dfnsonfsdu...@gmx.de wrote:
Bullshit. Comparing floats by their representation is *generally* a bad
idea because of portability issues. You don't know if IEEE754 is used to
represent floats on the systems that your code is used on.
No, you don't,
In article mailman.11779.1405206078.18130.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
On Sun, Jul 13, 2014 at 4:14 AM, Johannes Bauer dfnsonfsdu...@gmx.de wrote:
Bullshit. Comparing floats by their representation is *generally* a bad
idea because of portability issues.
On Sun, Jul 13, 2014 at 9:06 AM, Roy Smith r...@panix.com wrote:
But, you can still have:
print x
1.0
print y
1.0
print x == y
False
which, I know, isn't really what you were talking about, but it is part
of the general confusion of using floats.
This is partly because of the
On Sat, 12 Jul 2014 20:14:32 +0200, Johannes Bauer wrote:
On 12.07.2014 18:35, Steven D'Aprano wrote:
If you said, for many purposes, one should not compare floats for
equality, but should use some sort of fuzzy comparison instead then I
would agree with you. But your insistence that
Thanks to everyone who has commented. Some responses:
* I was completely mistaken about == enforcing the rule
that __eq__ returns True or False. I have no idea where
I got that idea from, sorry for the noise.
* I disagree that having two equals operators, == and ===,
would be confusing.
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:
But perhaps we only care about changes in value, not type. NAN or no NAN,
list equality works fine:
py data = [1.0, 2.0, float('nan'), 4.0]
py old = data[:]
py old == data # No changes made yet, should return True
True
You
On 9 July 2014 09:00, Steven D'Aprano st...@pearwood.info wrote:
At the moment, Python has two (in)equality operators, == and != which
call __eq__ and __ne__ methods. Some problems with those:
* Many people expect == to always be reflexive (that is, x == x for
every x) but classes which
At the moment, Python has two (in)equality operators, == and != which
call __eq__ and __ne__ methods. Some problems with those:
* Many people expect == to always be reflexive (that is, x == x for
every x) but classes which customise __eq__ may not be.
* The == operator requires __eq__ to
On Wed, Jul 9, 2014 at 5:00 PM, Steven D'Aprano st...@pearwood.info wrote:
Thoughts? Comments?
First thought: It will just add confusion. Currently, there are small
pockets of confusion surrounding the few cases where something's
non-reflexive, and there are occasional threads on the subject,
On 09Jul2014 07:00, Steven D'Aprano st...@pearwood.info wrote:
At the moment, Python has two (in)equality operators, == and != which
call __eq__ and __ne__ methods. Some problems with those:
* Many people expect == to always be reflexive (that is, x == x for
every x) but classes which
On Wed, 09 Jul 2014 18:17:23 +1000, Cameron Simpson wrote:
On 09Jul2014 07:00, Steven D'Aprano st...@pearwood.info wrote:
At the moment, Python has two (in)equality operators, == and != which
call __eq__ and __ne__ methods. Some problems with those:
* Many people expect == to always be
On Wed, 09 Jul 2014 17:21:20 +1000, Chris Angelico wrote:
On Wed, Jul 9, 2014 at 5:00 PM, Steven D'Aprano st...@pearwood.info
wrote:
Thoughts? Comments?
First thought: It will just add confusion. Currently, there are small
pockets of confusion surrounding the few cases where something's
On Wed, Jul 9, 2014 at 7:02 PM, Steven D'Aprano st...@pearwood.info wrote:
If you can tell the difference between x=y and x==y you should be able to
also distinguish x===y. But I accept that it's a little sub-optimal.
I'm not bothered so much by the which one is this confusion as the
which
On Wed, Jul 9, 2014 at 12:00 AM, Steven D'Aprano st...@pearwood.info wrote:
At the moment, Python has two (in)equality operators, == and != which
call __eq__ and __ne__ methods. Some problems with those:
* Many people expect == to always be reflexive (that is, x == x for
every x) but
In article 53bce8a3$0$2746$c3e8da3$76491...@news.astraweb.com,
Steven D'Aprano st...@pearwood.info wrote:
At the moment, Python has two (in)equality operators, == and != which
call __eq__ and __ne__ methods. Some problems with those:
* Many people expect == to always be reflexive (that
On Wed, 09 Jul 2014 08:27:28 -0400, Roy Smith wrote:
We would have *three* ways to compare for equality (==, ===, and is).
`is` does not, never has, and never will, be a test for equality.
py x = []
py y = []
py x is y
False
--
Steven
--
On 07/09/2014 12:00 AM, Steven D'Aprano wrote:
I propose:
[adding new operators]
-1
Too much added confusion, too little gain.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On 2014-07-09 08:00, Steven D'Aprano wrote:
At the moment, Python has two (in)equality operators, == and != which
call __eq__ and __ne__ methods. Some problems with those:
* Many people expect == to always be reflexive (that is, x == x for
every x) but classes which customise __eq__ may not
On Wednesday, July 9, 2014 2:47:40 PM UTC+5:30, Steven D'Aprano wrote:
On Wed, 09 Jul 2014 17:21:20 +1000, Chris Angelico wrote:
wrote:
Thoughts? Comments?
First thought: It will just add confusion. Currently, there are small
pockets of confusion surrounding the few cases where
On Wed, Jul 9, 2014 at 3:17 AM, Steven D'Aprano st...@pearwood.info wrote:
People are already having problems, just listen to Anders. He's
(apparently) not doing NAN-aware computations on his data, he just wants
to be able to do something like
this_list_of_floats == that_list_of_floats
On 2014-07-09 12:48, Steven D'Aprano wrote:
On Wed, 09 Jul 2014 08:27:28 -0400, Roy Smith wrote:
We would have *three* ways to compare for equality (==, ===, and
is).
`is` does not, never has, and never will, be a test for equality.
py x = []
py y = []
py x is y
False
I too am in
On Wed, Jul 9, 2014 at 12:05 PM, Tim Chase
python.l...@tim.thechases.com wrote:
def equalish(x, y):
return x == y or (math.isnan(x) and math.isnan(y))
With more generality:
def nan_type(x):
if isinstance(x, numbers.Complex):
if cmath.isnan(x): return 'qnan'
elif
In article 53bd3a1d$0$29995$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
On Wed, 09 Jul 2014 08:27:28 -0400, Roy Smith wrote:
We would have *three* ways to compare for equality (==, ===, and is).
`is` does not, never has, and never will,
TL;DR: I've got an alternative proposal at the bottom of this message.
On 09Jul2014 09:17, Steven D'Aprano st...@pearwood.info wrote:
On Wed, 09 Jul 2014 17:21:20 +1000, Chris Angelico wrote:
First thought: It will just add confusion. Currently, there are small
pockets of confusion surrounding
On Wed, 09 Jul 2014 13:05:22 -0500, Tim Chase wrote:
If you want to compare things in a NaN-aware way, you can either spell
it out explicitly:
if x == y or (math.isnan(x) and math.isnan(y)):
do_stuff()
But do we really want any arbitrary NAN to compare equal-ish with every
other
39 matches
Mail list logo
