Am 16.07.2014 13:40, schrieb Andreas Maier:
Am 13.07.2014 22:05, schrieb Akira Li:
Nick Coghlan writes:
...
There was related issue "Tuple comparisons with NaNs are broken"
http://bugs.python.org/issue21873
but it was closed as "not a bug" despite the corresponding behavior is
*not documented*
Am 13.07.2014 18:23, schrieb Steven D'Aprano:
On Sun, Jul 13, 2014 at 05:13:20PM +0200, Andreas Maier wrote:
Second, if not by delegation to equality of its elements, how would the
equality of sequences defined otherwise?
Wow. I'm impressed by the amount of detailed effort you've put into
inv
Am 13.07.2014 22:05, schrieb Akira Li:
Nick Coghlan writes:
...
definition of floats and the definition of container invariants like
"assert x in [x]")
The current approach means that the lack of reflexivity of NaN's stays
confined to floats and similar types - it doesn't leak out and infect
t
Am 14.07.2014 04:55, schrieb Ethan Furman:
On 07/13/2014 08:13 AM, Andreas Maier wrote:
Test #8: Same object of class C
(C.__eq__() implemented with equality of x,
C.__ne__() returning NotImplemented):
obj1: type=, str=C(256), id=39406504
obj2: type=, str=C(256), id=39406504
On 07/13/2014 10:33 PM, Andreas Maier wrote:
Am 14.07.2014 04:55, schrieb Ethan Furman:
On 07/13/2014 08:13 AM, Andreas Maier wrote:
Test #8: Same object of class C
(C.__eq__() implemented with equality of x,
C.__ne__() returning NotImplemented):
obj1: type=, str=C(256), id=3940650
On 07/13/2014 08:13 AM, Andreas Maier wrote:
Am 11.07.2014 22:54, schrieb Ethan Furman:
Here is the externally visible behavior:
Python 3.5.0a0 (default:34881ee3eec5, Jun 16 2014, 11:31:20)
[GCC 4.7.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
--> NaN = fl
Nick Coghlan writes:
...
> definition of floats and the definition of container invariants like
> "assert x in [x]")
>
> The current approach means that the lack of reflexivity of NaN's stays
> confined to floats and similar types - it doesn't leak out and infect
> the behaviour of the container t
Nick Coghlan :
> Right, it's not a mere optimisation - it's the only way to get
> containers to behave sensibly. Otherwise we'd end up with nonsense
> like:
>
x = float("nan")
x in [x]
> False
Why is that nonsense? I mean, why is it any more nonsense than
>>> x == x
False
Anyway
On 13 July 2014 13:16, Chris Angelico wrote:
> On Mon, Jul 14, 2014 at 4:11 AM, Nick Coghlan wrote:
>> What we've never figured out is a good place to *document* it. I
>> thought there was an open bug for that, but I can't find it right now.
>
> Yeah. The Py3 docs explain why "x in [x]" is True,
On Mon, Jul 14, 2014 at 4:11 AM, Nick Coghlan wrote:
> What we've never figured out is a good place to *document* it. I
> thought there was an open bug for that, but I can't find it right now.
Yeah. The Py3 docs explain why "x in [x]" is True, but I haven't found
a parallel explanation of sequenc
On 13 July 2014 11:34, Chris Angelico wrote:
> On Mon, Jul 14, 2014 at 2:23 AM, Steven D'Aprano wrote:
>>> We will see
>>> later that that happens. Further, when comparing float NaNs of the same
>>> identity, the list implementation forgot to special-case NaNs. Which
>>> would be a bug, IMHO.
>>
On Mon, Jul 14, 2014 at 2:23 AM, Steven D'Aprano wrote:
>> We will see
>> later that that happens. Further, when comparing float NaNs of the same
>> identity, the list implementation forgot to special-case NaNs. Which
>> would be a bug, IMHO.
>
> "Forgot"? I don't think the behaviour of list compa
On Sun, Jul 13, 2014 at 05:13:20PM +0200, Andreas Maier wrote:
> Second, if not by delegation to equality of its elements, how would the
> equality of sequences defined otherwise?
Wow. I'm impressed by the amount of detailed effort you've put into
investigating this. (Too much detail to absorb,
Am 11.07.2014 22:54, schrieb Ethan Furman:
On 07/11/2014 07:04 AM, Andreas Maier wrote:
Am 09.07.2014 03:48, schrieb Raymond Hettinger:
Personally, I see no need to make the same mistake by removing
the identity-implies-equality rule from the built-in containers.
There's no need to upset the a
On 07/11/2014 07:04 AM, Andreas Maier wrote:
Am 09.07.2014 03:48, schrieb Raymond Hettinger:
Personally, I see no need to make the same mistake by removing
the identity-implies-equality rule from the built-in containers.
There's no need to upset the apple cart for nearly zero benefit.
Contain
Am 08.07.2014 05:47, schrieb Ethan Furman:
On 07/07/2014 08:34 PM, Stephen J. Turnbull wrote:
Ethan Furman writes:
And what would be this 'sensible definition' [of value equality]?
I think that's the wrong question. I suppose Andreas's point is that
when the programmer doesn't provide a def
Am 11.07.2014 10:54, schrieb Ethan Furman:
On 07/11/2014 01:51 AM, Andreas Maier wrote:
I like the motivation provided by Benjamin and will work it into the
doc patch for issue #12067. The NaN special case
will also stay in.
Cool -- you should nosy myself, D'Aprano, and Benjamin (at least) on
Am 09.07.2014 03:48, schrieb Raymond Hettinger:
On Jul 7, 2014, at 4:37 PM, Andreas Maier wrote:
I do not really buy into the arguments that try to show how identity and value
are somehow the same. They are not, not even in Python.
The argument I can absolutely buy into is that the implemen
Le 09/07/2014 00:21, Stephen J. Turnbull a écrit :
Steven D'Aprano writes:
> I don't think so. Floating point == represents *numeric* equality,
There is no such thing as floating point == in Python. You can apply
== to two floating point numbers, but == (at the language level)
handles any tw
Steven D'Aprano writes:
> I don't think so. Floating point == represents *numeric* equality,
There is no such thing as floating point == in Python. You can apply
== to two floating point numbers, but == (at the language level)
handles any two numbers, as well as pairs of things that aren't
numb
On Jul 7, 2014, at 4:37 PM, Andreas Maier wrote:
> I do not really buy into the arguments that try to show how identity and
> value are somehow the same. They are not, not even in Python.
>
> The argument I can absolutely buy into is that the implementation cannot be
> changed within a major
On Tue, Jul 08, 2014 at 06:33:31PM +0100, MRAB wrote:
> The log of a negative number is a complex number.
Only in complex arithmetic. In real arithmetic, the log of a negative
number isn't a number at all.
--
Steven
___
Python-Dev mailing list
Python
On 2014-07-08 17:57, Steven D'Aprano wrote:
[snip]
In particular, reflexivity for NANs was dropped for a number of reasons,
some stronger than others:
- One of the weaker reasons for NAN non-reflexivity is that it preserved
the identity x == y <=> x - y == 0. Although that is the cornerstone
On Wed, Jul 9, 2014 at 3:00 AM, Steven D'Aprano wrote:
> On Tue, Jul 08, 2014 at 04:58:33PM +0200, Anders J. Munch wrote:
>
>> For two NaNs computed differently to compare equal is no worse than 2+2
>> comparing equal to 1+3. You're comparing values, not their history.
>
> a = -23
> b = -42
> if
On Tue, Jul 08, 2014 at 04:58:33PM +0200, Anders J. Munch wrote:
> For two NaNs computed differently to compare equal is no worse than 2+2
> comparing equal to 1+3. You're comparing values, not their history.
a = -23
b = -42
if log(a) == log(b):
print "a == b"
--
Steven
_
On Tue, Jul 08, 2014 at 04:53:50PM +0900, Stephen J. Turnbull wrote:
> Chris Angelico writes:
>
> > The reason NaN isn't equal to itself is because there are X bit
> > patterns representing NaN, but an infinite number of possible
> > non-numbers that could result from a calculation.
>
> I unde
Chris Angelico wrote:
This is off-topic for this thread, but still...
The trouble is that your "arguably just as wrong" is an
indistinguishable case. If you don't want two different calculations'
NaNs to *ever* compare equal, the only solution is to have all NaNs
compare unequal
For two NaNs co
On Tue, Jul 8, 2014 at 5:53 PM, Stephen J. Turnbull wrote:
> But you're missing at least two alternatives that
> involve raising on some calculations involving NaN, as well as the
> fact that forcing inequality of two NaNs produced by equivalent
> calculations is arguably just as wrong as allowing
Chris Angelico writes:
> The reason NaN isn't equal to itself is because there are X bit
> patterns representing NaN, but an infinite number of possible
> non-numbers that could result from a calculation.
I understand that. But you're missing at least two alternatives that
involve raising on
On Tue, Jul 8, 2014 at 5:01 PM, Stephen J. Turnbull wrote:
> I agree with Steven d'A that this rule is not part of the language
> definition and shouldn't be, but it's the rule of thumb I find hardest
> to imagine *ever* wanting to break in my own code (although I sort of
> understand why the IEEE
Rob Cliffe writes:
> > Why? What value (pun intended) is there in adding an explicit statement
> > of value to every single class?
> It troubles me a bit that "value" seems to be a fuzzy concept - it has
> an obvious meaning for some types (int, float, list etc.) but for
> callable objects
On 7 Jul 2014 19:22, "Andreas Maier" wrote:
>
> Thanks to all who responded.
>
> In absence of class-specific equality test methods, the default
implementations revert to use the identity (=address) of the object as a
basis for the test, in both Python 2 and Python 3.
>
> In absence of specific or
On 07/07/2014 08:34 PM, Stephen J. Turnbull wrote:
Ethan Furman writes:
And what would be this 'sensible definition' [of value equality]?
I think that's the wrong question. I suppose Andreas's point is that
when the programmer doesn't provide a definition, there is no such
thing as a "sensib
On 08/07/2014 04:12, Steven D'Aprano wrote:
On Tue, Jul 08, 2014 at 02:59:30AM +0100, Rob Cliffe wrote:
- "*Every object has an identity, a type and a value.*"
Hm, is that *really* true?
Yes. It's pretty much true by definition: objects are *defined* to have
an identity, type and value, even
Ethan Furman writes:
> And what would be this 'sensible definition' [of value equality]?
I think that's the wrong question. I suppose Andreas's point is that
when the programmer doesn't provide a definition, there is no such
thing as a "sensible definition" to default to. I disagree, but given
On Tue, Jul 8, 2014 at 1:12 PM, Steven D'Aprano wrote:
> Why? What value (pun intended) is there in adding an explicit statement
> of value to every single class?
>
> "The value of a str is the str's sequence of characters."
> "The value of a list is the list's sequence of items."
> "The value of
On Tue, Jul 08, 2014 at 02:59:30AM +0100, Rob Cliffe wrote:
> >- "*Every object has an identity, a type and a value.*"
>
> Hm, is that *really* true?
Yes. It's pretty much true by definition: objects are *defined* to have
an identity, type and value, even if that value is abstract rather than
c
On 07/07/2014 06:18 PM, Andreas Maier wrote:
Am 2014-07-08 01:50, schrieb Ethan Furman:
I never add __eq__ to my classes until I come upon a place where I need to
check if two instances of those classes are
'equal', for whatever I need equal to mean in that case.
With that strategy, you woul
On 07/07/2014 06:58 PM, Steven D'Aprano wrote:
On Mon, Jul 07, 2014 at 04:52:17PM -0700, Ethan Furman wrote:
On 07/07/2014 04:49 PM, Benjamin Peterson wrote:
Probably the best argument for the behavior is that "x is y" should
imply "x == y", which preludes raising an exception. No such invaria
On Tue, Jul 08, 2014 at 01:53:06AM +0200, Andreas Maier wrote:
> Thanks to all who responded.
>
> In absence of class-specific equality test methods, the default
> implementations revert to use the identity (=address) of the object as a
> basis for the test, in both Python 2 and Python 3.
Scrub
On Tue, Jul 8, 2014 at 11:59 AM, Rob Cliffe wrote:
> If I came across an int object and had no concept of what an integer number
> was, how would I know what its "value" is supposed to be?
The value of an integer is the number it represents. In CPython, it's
entirely possible to have multiple int
On 08/07/2014 00:37, Andreas Maier wrote:
[...]
Am 2014-07-07 23:11, schrieb Jan Kaliszewski:
IMHO, in Python context, "value" is a very vague term. Quite often
we can read it as the very basic (but not the only one) notion of
"what makes objects being equal or not" -- and then saying that
On Mon, Jul 07, 2014 at 04:52:17PM -0700, Ethan Furman wrote:
> On 07/07/2014 04:49 PM, Benjamin Peterson wrote:
> >
> >Probably the best argument for the behavior is that "x is y" should
> >imply "x == y", which preludes raising an exception. No such invariant
> >is desired for ordering, so defaul
Andreas Maier writes:
> A class designer can directly implement what equality means to the
> class, but he or she cannot implement an accessor method for the
> value.
Of course she can! What you mean to say, I think, is that Python does
not insist on an accessor method for the value. Ie, the
Am 2014-07-08 02:22, schrieb Ethan Furman:
On 07/07/2014 05:12 PM, Andreas Maier wrote:
Am 2014-07-07 18:09, schrieb Ethan Furman:
Just because two instances from the same object have the same value
does not mean they are equal. For a real-life
example, look at twins: biologically identica
Am 2014-07-08 01:50, schrieb Ethan Furman:
On 07/07/2014 04:36 PM, Andreas Maier wrote:
Am 2014-07-07 19:43, schrieb Ethan Furman:
Python cannot know which values are important in an equality test,
and which are not. So it refuses to guess.
Well, one could argue that using the address of a
Andreas Maier writes:
> The problem of the default implementation is that "x is not y"
> implies "x != y" and that may or may not be true under a sensible
> definition of equality.
I noticed this a long time ago and just decided it was covered by
"consenting adults". That is, if the "sensible
On 07/07/2014 05:12 PM, Andreas Maier wrote:
Am 2014-07-07 18:09, schrieb Ethan Furman:
Just because two instances from the same object have the same value does not
mean they are equal. For a real-life
example, look at twins: biologically identical, yet not equal.
I think they *are* equal
On 07/07/2014 04:49 PM, Benjamin Peterson wrote:
Probably the best argument for the behavior is that "x is y" should
imply "x == y", which preludes raising an exception. No such invariant
is desired for ordering, so default implementations of < and > are not
provided in Python 3.
Nice. This b
On 07/07/2014 04:36 PM, Andreas Maier wrote:
Am 2014-07-07 19:43, schrieb Ethan Furman:
Python cannot know which values are important in an equality test, and which
are not. So it refuses to guess.
Well, one could argue that using the address of an object for its value
equality test is pre
Am 2014-07-07 18:09, schrieb Ethan Furman:
Just because two instances from the same object have the same value
does not mean they are equal. For a real-life example, look at
twins: biologically identical, yet not equal.
I think they *are* equal in Python if they have the same value, by
def
Am 2014-07-08 01:49, schrieb Benjamin Peterson:
On Mon, Jul 7, 2014, at 16:36, Andreas Maier wrote:
Am 2014-07-07 19:43, schrieb Ethan Furman:
On 07/07/2014 09:56 AM, Andreas Maier wrote:
Am 07.07.2014 17:55, schrieb Ethan Furman:
On 07/07/2014 04:22 AM, Andreas Maier wrote:
Where is the dis
Thanks to all who responded.
In absence of class-specific equality test methods, the default
implementations revert to use the identity (=address) of the object as a
basis for the test, in both Python 2 and Python 3.
In absence of specific ordering test methods, the default
implementations r
On Mon, Jul 7, 2014, at 16:36, Andreas Maier wrote:
> Am 2014-07-07 19:43, schrieb Ethan Furman:
> > On 07/07/2014 09:56 AM, Andreas Maier wrote:
> >> Am 07.07.2014 17:55, schrieb Ethan Furman:
> >>> On 07/07/2014 04:22 AM, Andreas Maier wrote:
>
> Where is the discrepancy between the doc
Am 2014-07-07 23:31, schrieb Rob Cliffe:
On 07/07/2014 22:11, Jan Kaliszewski wrote:
[snip]
IMHO, in Python context, "value" is a very vague term. Quite often
we can read it as the very basic (but not the only one) notion of
"what makes objects being equal or not" -- and then saying that
"o
Am 2014-07-07 23:11, schrieb Jan Kaliszewski:
07.07.2014 18:11, Andreas Maier wrote:
Am 07.07.2014 17:58, schrieb Xavier Morel:
On 2014-07-07, at 13:22 , Andreas Maier wrote:
While discussing Python issue #12067
(http://bugs.python.org/issue12067#msg222442), I learned that
Python 3.4 imple
Am 2014-07-07 19:43, schrieb Ethan Furman:
On 07/07/2014 09:56 AM, Andreas Maier wrote:
Am 07.07.2014 17:55, schrieb Ethan Furman:
On 07/07/2014 04:22 AM, Andreas Maier wrote:
Where is the discrepancy between the documentation of == and its
default implementation on object documented?
There
On 07/07/2014 22:11, Jan Kaliszewski wrote:
[snip]
IMHO, in Python context, "value" is a very vague term. Quite often we
can read it as the very basic (but not the only one) notion of "what
makes objects being equal or not" -- and then saying that "objects are
compared by value" is a tautol
07.07.2014 18:11, Andreas Maier wrote:
Am 07.07.2014 17:58, schrieb Xavier Morel:
On 2014-07-07, at 13:22 , Andreas Maier
wrote:
While discussing Python issue #12067
(http://bugs.python.org/issue12067#msg222442), I learned that Python
3.4 implements '==' and '!=' on the object type such
On 07/07/2014 08:29 AM, Andreas Maier wrote:
So the Python 2.7 implementation shows the same discrepancy as Python 3.x
regarding the == and != default implementation.
Why do you see this as a discrepancy?
Just because two instances from the same object have the same value does not mean they
On 7/7/2014 7:22 AM, Andreas Maier wrote:
While discussing Python issue #12067
(http://bugs.python.org/issue12067#msg222442), I learned that Python 3.4
implements '==' and '!=' on the object type such that if no special
equality test operations are implemented in derived classes, there is a
defau
On 07/07/2014 09:56 AM, Andreas Maier wrote:
Am 07.07.2014 17:55, schrieb Ethan Furman:
On 07/07/2014 04:22 AM, Andreas Maier wrote:
Where is the discrepancy between the documentation of == and its
default implementation on object documented?
There's seems to be no discrepancy (at least, you
Am 07.07.2014 17:55, schrieb Ethan Furman:
On 07/07/2014 04:22 AM, Andreas Maier wrote:
Where is the discrepancy between the documentation of == and its
default implementation on object documented?
There's seems to be no discrepancy (at least, you have not shown it),
The documentation state
On 07/07/2014 04:22 AM, Andreas Maier wrote:
Where is the discrepancy between the documentation of == and its default
implementation on object documented?
There's seems to be no discrepancy (at least, you have not shown it), but to answer the question about why the default
equals operation i
Am 07.07.2014 17:58, schrieb Xavier Morel:
On 2014-07-07, at 13:22 , Andreas Maier wrote:
While discussing Python issue #12067
(http://bugs.python.org/issue12067#msg222442), I learned that Python 3.4
implements '==' and '!=' on the object type such that if no special equality
test operatio
On 2014-07-07, at 13:22 , Andreas Maier wrote:
> While discussing Python issue #12067
> (http://bugs.python.org/issue12067#msg222442), I learned that Python 3.4
> implements '==' and '!=' on the object type such that if no special equality
> test operations are implemented in derived classes,
Am 07.07.2014 17:15, schrieb Benjamin Peterson:
On Mon, Jul 7, 2014, at 04:22, Andreas Maier wrote:
Python 2.x does not seem to have such a default implementation; == and
!= raise an exception if attempted on objects that don't implement
equality in derived classes.
Why do you think that?
B
On Tue, Jul 8, 2014 at 1:15 AM, Benjamin Peterson wrote:
> Why do you think that?
>
> % python
> Python 2.7.6 (default, May 29 2014, 22:22:15)
> [GCC 4.7.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
class x(object): pass
> ...
class y(object): pas
On Mon, Jul 7, 2014, at 04:22, Andreas Maier wrote:
> While discussing Python issue #12067
> (http://bugs.python.org/issue12067#msg222442), I learned that Python 3.4
> implements '==' and '!=' on the object type such that if no special
> equality test operations are implemented in derived classe
While discussing Python issue #12067
(http://bugs.python.org/issue12067#msg222442), I learned that Python 3.4
implements '==' and '!=' on the object type such that if no special
equality test operations are implemented in derived classes, there is a
default implementation that tests for identit
70 matches
Mail list logo
