Dear All,
For the first time I have come across a Python feature that seems
completely wrong. After the introduction of rich comparisons, equality
comparison does not have to return a truth value, and may indeed return
nothing at all and throw an error instead. As a result, code like
if foo == b
Robert Kern Wrote:
>Terry Reedy wrote:
>> Rasmus Fogh wrote:
>>> Personally I would like to get these [EMAIL PROTECTED]&* misfeatures
>>> removed,
>>
>> What you are calling a misfeature is an absence, not a presence that
>> can be removed.
>
Jamed Stroud Wrote:
> Rasmus Fogh wrote:
>> Dear All,
>> For the first time I have come across a Python feature that seems
>> completely wrong. After the introduction of rich comparisons, equality
>> comparison does not have to return a truth value, and may indeed r
> On Sun, 07 Dec 2008 13:03:43 +0000, Rasmus Fogh wrote:
>> Jamed Stroud Wrote:
> ...
>>> Second, consider that any value in python also evaluates to a truth
>>> value in boolean context.
> But bool(x) can fail too. So not every object in Python can be
> inte
Rober Kern wrote:
>James Stroud wrote:
>> Steven D'Aprano wrote:
>>> On Sun, 07 Dec 2008 13:57:54 -0800, James Stroud wrote:
>>>> Rasmus Fogh wrote:
>>>>>>>> ll1 = [y,1]
>>>>>>>> y in ll1
>>>>>
Steven DAprano wrote:
> On Mon, 08 Dec 2008 14:24:59 +0000, Rasmus Fogh wrote:
>> For my personal problem I could indeed wrap all objects in a wrapper
>> with whatever 'correct' behaviour I want (thanks, TJR). It does seem a
>> bit much, though, just to get cod
Steven DAprano wrote:
> On Mon, 08 Dec 2008 14:24:59 +0000, Rasmus Fogh wrote:
snip
>> What might be a sensible behaviour (unlike your proposed wrapper)
Sorry
1) I was rude,
2) I thanked TJR for your wrapper class proposal in a later mail. It is
yours.
> What do you dislike abou
Mark Dickinson wrote:
> On Dec 8, 2:24 pm, Rasmus Fogh <[EMAIL PROTECTED]> wrote:
>> So, I would much prefer a language change. I am not competent to even
>> propose one properly, but I'll try.
> I don't see any technical problems in what you propose: a
Rhamphoryncus wrote:
> You grossly overvalue using the "in" operator on lists.
Maybe. But there is more to it than just 'in'. If you do:
>>> c = numpy.zeros((2,))
>>> ll = [1, c, 3.]
then the following all throw errors:
3 in ll, 3 not in ll, ll.index(3), ll.count(3), ll.remove(3)
c in ll, c not i
Rhodri James wrote:
> On Mon, 08 Dec 2008 14:24:59 -0000, Rasmus Fogh wrote:
>> On the minus side there would be the difference between
>> '__equal__' and '__eq__' to confuse people.
> This is a very big minus. It would be far better to spell __equal__ i
10 matches
Mail list logo
