A.T.Hofkamp wrote:
> Hmm, maybe numbers in sets are broken then?
a = 12345
b = 12345
a == b
>
> True
>
a is b
>
> False
>
set([a,b])
>
> set([12345])
>
> Numbers and my Car2 objects behave the same w.r.t. '==' and 'is', yet I get a
> set with 1 number, and a set with 2 car
On 2007-06-29, Gabriel Genellina <[EMAIL PROTECTED]> wrote:
> En Thu, 28 Jun 2007 11:38:56 -0300, A.T.Hofkamp <[EMAIL PROTECTED]>
> escribió:
>
>> The point I intended to make was that having a default __hash__ method on
>> objects give weird results that not everybody may be aware of.
>> In addi
A.T.Hofkamp wrote:
> On 2007-06-29, Steve Holden <[EMAIL PROTECTED]> wrote:
>> Just the same there are sound reasons for it, so I'd prefer to see you
>> using "counterintuitive" or "difficult to fathom" rather than "broken"
>> and "wrong".
>
> You are quite correct, in the heat of typing an answ
On 2007-06-28, Roy Smith <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> "A.T.Hofkamp" <[EMAIL PROTECTED]> wrote:
>
>> In object oriented programming, objects are representations of values, and
>> the
>> system shouldn't care about how many instances there are of some value, just
>
On 2007-06-29, Steve Holden <[EMAIL PROTECTED]> wrote:
> Just the same there are sound reasons for it, so I'd prefer to see you
> using "counterintuitive" or "difficult to fathom" rather than "broken"
> and "wrong".
You are quite correct, in the heat of typing an answer, my wording was too
stron
On Fri, 29 Jun 2007 00:47:16 -0300
"Gabriel Genellina" <[EMAIL PROTECTED]> wrote:
> __hash__ and equality tests are used by the dictionary
> implementation, and the default implementation is OK for immutable
> objects.
That is probably why inf == inf yields True.
In this unique case, I do not lik
En Thu, 28 Jun 2007 11:38:56 -0300, A.T.Hofkamp <[EMAIL PROTECTED]>
escribió:
> The point I intended to make was that having a default __hash__ method on
> objects give weird results that not everybody may be aware of.
> In addition, to get useful behavior of objects in sets one should
> overr
A.T.Hofkamp wrote:
> On 2007-06-28, Alan Isaac <[EMAIL PROTECTED]> wrote:
>> A.T.Hofkamp wrote:
>>
>> a = Car2(123)
>> b = Car2(123)
>> a == b
>>> True
>>>
>> set([a,b])
>>> set([Car2(123), Car2(123)])
>>>
>>> I get a set with two equal cars, something that never happens with a set
In article <[EMAIL PROTECTED]>,
"A.T.Hofkamp" <[EMAIL PROTECTED]> wrote:
> In object oriented programming, objects are representations of values, and the
> system shouldn't care about how many instances there are of some value, just
> like numbers in math. Every instance with a certain value is t
On 2007-06-28, Alan Isaac <[EMAIL PROTECTED]> wrote:
> A.T.Hofkamp wrote:
>
>a = Car2(123)
>b = Car2(123)
>a == b
>>
>> True
>>
>set([a,b])
>>
>> set([Car2(123), Car2(123)])
>>
>> I get a set with two equal cars, something that never happens with a set
>> my math teacher once to
A.T.Hofkamp wrote:
a = Car2(123)
b = Car2(123)
a == b
>
> True
>
set([a,b])
>
> set([Car2(123), Car2(123)])
>
> I get a set with two equal cars, something that never happens with a set
> my math teacher once told me.
Then your math teacher misspoke.
You have two different car
On 2007-06-27, Alex Martelli <[EMAIL PROTECTED]> wrote:
> A.T.Hofkamp <[EMAIL PROTECTED]> wrote:
>
>> I think that again now with the default implementation of the
>> object.__eq__ and object.__hash__ methods. I believe these methods should
>> not exist until the programmer explicitly defines th
Aahz wrote:
> In article <[EMAIL PROTECTED]>,
> Alex Martelli <[EMAIL PROTECTED]> wrote:
>> In Python 3000, ordering comparisons will not exist by default (sigh, a
>> modest loss of practicality on the altar of purity -- ah well, saw it
>> coming, ever since complex numbers lost ordering compariso
In article <[EMAIL PROTECTED]>,
Alex Martelli <[EMAIL PROTECTED]> wrote:
>
>In Python 3000, ordering comparisons will not exist by default (sigh, a
>modest loss of practicality on the altar of purity -- ah well, saw it
>coming, ever since complex numbers lost ordering comparisons), but
>equality an
14 matches
Mail list logo
