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 7 Jul 2014 10:47, "Guido van Rossum" wrote:
>
> It would still be nice to know who "the appropriate persons" are. Too
much of our infrastructure seems to be maintained by house elves or the ITA.
I volunteered to be the board's liaison to the infrastructure team, and
getting more visibility aro
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 Mon, Jul 7, 2014 at 10:01 PM, francis wrote:
> On 06/23/2014 10:12 PM, R. David Murray wrote:
>
>> The stats graphs are based on the data generated for the
>> weekly issue report. I have a patched version of that
>> report that adds the bug/enhancement info. I'll try to dig
>> it up this week
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 07/07/2014 12:01 PM, francis wrote:
On 06/23/2014 10:12 PM, R. David Murray wrote:
The stats graphs are based on the data generated for the
weekly issue report. I have a patched version of that
report that adds the bug/enhancement info. I'll try to dig
it up this week; someone ping me if I
On 06/23/2014 10:12 PM, R. David Murray wrote:
The stats graphs are based on the data generated for the
weekly issue report. I have a patched version of that
report that adds the bug/enhancement info. I'll try to dig
it up this week; someone ping me if I forget :) It think
the patch will need
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
Le 07/07/2014 13:22, Guido van Rossum a écrit :
It's a reference to Neil Stephenson's Anathem.
According to Google, it doesn't look like he played the trombone, though.
Regards
Antoine.
On Jul 7, 2014 8:55 AM, "Benjamin Peterson" mailto:benja...@python.org>> wrote:
On Mon, Jul 7, 201
It's a reference to Neil Stephenson's Anathem.
On Jul 7, 2014 8:55 AM, "Benjamin Peterson" wrote:
> On Mon, Jul 7, 2014, at 08:44, Guido van Rossum wrote:
> > It would still be nice to know who "the appropriate persons" are. Too
> > much
> > of our infrastructure seems to be maintained by house e
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,
On Mon, Jul 7, 2014, at 08:44, Guido van Rossum wrote:
> It would still be nice to know who "the appropriate persons" are. Too
> much
> of our infrastructure seems to be maintained by house elves or the ITA.
:) Is ITA "International Trombone Association"?
__
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
It would still be nice to know who "the appropriate persons" are. Too much
of our infrastructure seems to be maintained by house elves or the ITA.
On Sun, Jul 6, 2014 at 11:33 PM, Terry Reedy wrote:
> On 7/6/2014 7:54 PM, Ned Deily wrote:
>
>> As of the moment, buildbot.python.org seems to be d
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
47 matches
Mail list logo
