Nick Maclaren wrote:
>>> I really do mean that quite a lot of floating-point bells and whistles
>>> are non-transitive.
Martin v. Löwis wrote:
>> If so, they just shouldn't use the equal operator (==). == ought to
>> be transitive. It should be consistent with has().
Nick Maclaren wrote:
> Fine.
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <[EMAIL PROTECTED]> wrote:
>
> >> If so, they just shouldn't use the equal operator (==). == ought to
> >> be transitive. It should be consistent with has().
> >
> > Fine. A very valid viewpoint. Would you like to explain that to
> > the IEEE 754 peopl
George Sakkis wrote:
> far too often I use the idiom dict(zip(keys,values)), or
> the same with izip. How does letting dict take two positional
> arguments sound ?
I think the dict constructor is already a bit too complicated, and
would prefer that it be a separate classmethod, such as
dict.
Nick Maclaren schrieb:
>> If so, they just shouldn't use the equal operator (==). == ought to
>> be transitive. It should be consistent with has().
>
> Fine. A very valid viewpoint. Would you like to explain that to
> the IEEE 754 people?
Why should I? I don't talk about IEEE 754, I talk about
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <[EMAIL PROTECTED]> wrote:
>
> > I really do mean that quite a lot of floating-point bells and whistles
> > are non-transitive.
>
> If so, they just shouldn't use the equal operator (==). == ought to
> be transitive. It should be consistent with has().
Fi
Nick Maclaren schrieb:
For 0: hash(+0.0)==hash(-0.0)==hash(0)=hash(0L)=0
>>> Unfortunately, that assumes that equality is transitive.
>> No, but the (transitively closed set of equivalent objects) must have
>> the same hash. ...
>
> Er, how do you have a transitive closure for a non-transiti
Andrew Koenig wrote:
>> Unfortunately
>>
>>dict(keys=keys, values=values) == {keys: values}
>
> Ummm, no:
>
> dict(keys=keys, values=values) == {'keys': keys, 'values': values}
>
Of course I should really have written
dict(keys=keys, values=values) != dict(zip(keys, values))
reg
> Unfortunately
>
>dict(keys=keys, values=values) == {keys: values}
Ummm, no:
dict(keys=keys, values=values) == {'keys': keys, 'values': values}
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
George Sakkis wrote:
> Um, you do realize that dict(keys=keys, values=values) is already
> valid and quite different from dict(zip(keys, values)), don't you ? :)
Sorry, minor misreading on my part. Like that time in Sunday school when
I missed the "not" in "Though shall not kill". That was a ro
Brian Quinlan wrote:
> George Sakkis wrote:
>> Perhaps this has been brought up in the past but I couldn't find it in
>> the archives: far too often I use the idiom dict(zip(keys,values)), or
>> the same with izip. How does letting dict take two positional
>> arguments sound ?
>>
>> Pros:
>> - Pret
On 2/1/07, Brian Quinlan <[EMAIL PROTECTED]> wrote:
> George Sakkis wrote:
> > Perhaps this has been brought up in the past but I couldn't find it in
> > the archives: far too often I use the idiom dict(zip(keys,values)), or
> > the same with izip. How does letting dict take two positional
> > argu
"Jim Jewett" <[EMAIL PROTECTED]> wrote:
>
> >> For 0: hash(+0.0)==hash(-0.0)==hash(0)=hash(0L)=0
>
> > Unfortunately, that assumes that equality is transitive.
>
> No, but the (transitively closed set of equivalent objects) must have
> the same hash. ...
Er, how do you have a transitive closur
George Sakkis wrote:
> Perhaps this has been brought up in the past but I couldn't find it in
> the archives: far too often I use the idiom dict(zip(keys,values)), or
> the same with izip. How does letting dict take two positional
> arguments sound ?
>
> Pros:
> - Pretty obvious semantics, no ment
13 matches
Mail list logo
