Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #56535 > unrolled thread

I am never going to complain about Python again

Back to article view | Back to comp.lang.python

Contents

  I am never going to complain about Python again Steven D'Aprano <steve@pearwood.info> - 2013-10-10 04:36 +0000
    Re: I am never going to complain about Python again Chris Angelico <rosuav@gmail.com> - 2013-10-10 15:50 +1100
    Re: I am never going to complain about Python again Chris Rebert <clp2@rebertia.com> - 2013-10-09 22:26 -0700
    Re: I am never going to complain about Python again Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-10-10 06:39 +0100
    Re: I am never going to complain about Python again Christian Gollwitzer <auriocus@gmx.de> - 2013-10-10 08:41 +0200
    Re: I am never going to complain about Python again "Frank Millman" <frank@chagford.com> - 2013-10-10 10:23 +0200
    Re: I am never going to complain about Python again MRAB <python@mrabarnett.plus.com> - 2013-10-10 12:10 +0100
    Re: I am never going to complain about Python again Tim Chase <python.list@tim.thechases.com> - 2013-10-10 06:43 -0500
    Re: I am never going to complain about Python again "Frank Millman" <frank@chagford.com> - 2013-10-10 13:44 +0200
    Re: I am never going to complain about Python again Roy Smith <roy@panix.com> - 2013-10-10 09:09 -0400
      Re: I am never going to complain about Python again Neil Cerutti <neilc@norwich.edu> - 2013-10-10 15:51 +0000
        Re: I am never going to complain about Python again Rotwang <sg552@hotmail.co.uk> - 2013-10-10 16:57 +0100
          Re: I am never going to complain about Python again MRAB <python@mrabarnett.plus.com> - 2013-10-10 17:10 +0100
            Re: I am never going to complain about Python again Neil Cerutti <neilc@norwich.edu> - 2013-10-10 17:48 +0000
              Re: I am never going to complain about Python again Ian Kelly <ian.g.kelly@gmail.com> - 2013-10-10 12:35 -0600
                Re: I am never going to complain about Python again Neil Cerutti <neilc@norwich.edu> - 2013-10-10 18:49 +0000
              Re: I am never going to complain about Python again Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-10-10 20:47 +0100
                Re: I am never going to complain about Python again Neil Cerutti <neilc@norwich.edu> - 2013-10-10 19:54 +0000
              Re: I am never going to complain about Python again Cameron Simpson <cs@zip.com.au> - 2013-10-11 08:52 +1100
              Re: I am never going to complain about Python again Roy Smith <roy@panix.com> - 2013-10-10 20:07 -0400
                Is this the room for an argument? John Ladasky <john_ladasky@sbcglobal.net> - 2013-10-10 21:26 -0700
                  Re: Is this the room for an argument? Roy Smith <roy@panix.com> - 2013-10-11 09:49 -0400
              Re: I am never going to complain about Python again Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-11 02:23 +0000
                Re: I am never going to complain about Python again Neil Cerutti <neilc@norwich.edu> - 2013-10-11 12:31 +0000
      Re: I am never going to complain about Python again Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-10-10 20:09 -0400
      Re: I am never going to complain about Python again Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-11 02:08 +0000
        Re: I am never going to complain about Python again Joshua Landau <joshua@landau.ws> - 2013-10-11 09:17 +0100
          Re: I am never going to complain about Python again Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-10-11 09:11 +0000
            Re: I am never going to complain about Python again Chris Angelico <rosuav@gmail.com> - 2013-10-11 20:52 +1100
            Re: I am never going to complain about Python again Joshua Landau <joshua@landau.ws> - 2013-10-11 17:56 +0100

Page 1 of 2  [1] 2  Next page →

#56535 — I am never going to complain about Python again

Just came across this little Javascript gem:

",,," == Array((null,'cool',false,NaN,4));

=> evaluates as true

http://wtfjs.com/2011/02/11/all-your-commas-are-belong-to-Array

I swear, I am never going to complain about Python again.




-- 
Steven

[toc] | [next] | [standalone]

#56536

On Thu, Oct 10, 2013 at 3:36 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> Just came across this little Javascript gem:
>
> ",,," == Array((null,'cool',false,NaN,4));
>
> => evaluates as true
>
> http://wtfjs.com/2011/02/11/all-your-commas-are-belong-to-Array
>
> I swear, I am never going to complain about Python again.

*blank look*

Wow.

Now, is there a situation in which this problem can actually crop up
in production code? And is it as serious as PHP's treatment of
hexadecimal hashes (eg that "100"== "1E2")?

ChrisA

[toc] | [prev] | [next] | [standalone]

#56539

On Wed, Oct 9, 2013 at 9:36 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> Just came across this little Javascript gem:
>
> ",,," == Array((null,'cool',false,NaN,4));
>
> => evaluates as true
>
> http://wtfjs.com/2011/02/11/all-your-commas-are-belong-to-Array
>
> I swear, I am never going to complain about Python again.

Oh, indeed, you have no idea.
Since we're talking about JavaScript suckage, I'm obliged to link to
this wonderful video on the subject:
https://www.destroyallsoftware.com/talks/wat

Cheers,
Chris R.

[toc] | [prev] | [next] | [standalone]

#56541

On 10/10/2013 05:36, Steven D'Aprano wrote:
> Just came across this little Javascript gem:
>
> ",,," == Array((null,'cool',false,NaN,4));
>
> => evaluates as true
>
> http://wtfjs.com/2011/02/11/all-your-commas-are-belong-to-Array
>
> I swear, I am never going to complain about Python again.
>

Isn't that what the CS gurus call a type safe array?  What's the 
problem, *I* don't see anything wrong with it :)

-- 
Roses are red,
Violets are blue,
Most poems rhyme,
But this one doesn't.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#56546

Am 10.10.13 06:36, schrieb Steven D'Aprano:
> Just came across this little Javascript gem:
>
> ",,," == Array((null,'cool',false,NaN,4));
>
> => evaluates as true
>
> http://wtfjs.com/2011/02/11/all-your-commas-are-belong-to-Array
>
> I swear, I am never going to complain about Python again.

More of this fun for polyglott programmers:
	https://www.destroyallsoftware.com/talks/wat

Christian

[toc] | [prev] | [next] | [standalone]

#56556

"Steven D'Aprano" <steve@pearwood.info> wrote in message 
news:52562ee3$0$2931$c3e8da3$76491128@news.astraweb.com...
> Just came across this little Javascript gem:
>
> ",,," == Array((null,'cool',false,NaN,4));
>
> => evaluates as true
>
> http://wtfjs.com/2011/02/11/all-your-commas-are-belong-to-Array
>
> I swear, I am never going to complain about Python again.
>

I am sure you know this, but for the record, Javascript has two equality 
operators, '==' and '==='.

The double form attempts to coerce the left and right sides to the same 
type, the triple form does not.

'1' == 1 returns true

'1' === 1 returns false

The moment I discovered this, I changed all my operators from the double 
form to the triple form. Now I no longer have surprises of this nature.

Frank Millman

[toc] | [prev] | [next] | [standalone]

#56559

On 10/10/2013 09:23, Frank Millman wrote:
>
> "Steven D'Aprano" <steve@pearwood.info> wrote in message
> news:52562ee3$0$2931$c3e8da3$76491128@news.astraweb.com...
>> Just came across this little Javascript gem:
>>
>> ",,," == Array((null,'cool',false,NaN,4));
>>
>> => evaluates as true
>>
>> http://wtfjs.com/2011/02/11/all-your-commas-are-belong-to-Array
>>
>> I swear, I am never going to complain about Python again.
>>
>
> I am sure you know this, but for the record, Javascript has two equality
> operators, '==' and '==='.
>
> The double form attempts to coerce the left and right sides to the same
> type, the triple form does not.
>
Re "==", this page:

     http://php.net/manual/en/language.operators.comparison.php

states:

"""If you compare a number with a string or the *comparison involves
numerical strings*, then each string is converted to a number and the
comparison performed numerically.""" (emphasis added)

So they get coerced to numbers if they _look_ like numbers!

> '1' == 1 returns true
>
> '1' === 1 returns false
>
> The moment I discovered this, I changed all my operators from the double
> form to the triple form. Now I no longer have surprises of this nature.
>

[toc] | [prev] | [next] | [standalone]

#56560

On 2013-10-10 12:10, MRAB wrote:
> Re "==", this page:
> 
>      http://php.net/manual/en/language.operators.comparison.php
> 
> states:
> 
> """If you compare a number with a string or the *comparison involves
> numerical strings*, then each string is converted to a number and
> the comparison performed numerically.""" (emphasis added)
> 
> So they get coerced to numbers if they _look_ like numbers!

BEDEVERE: How do you know she is a number?

VILLAGER1: She looks like one!

CROWD: Right! Yeah! Yeah!

BEDEVERE: Bring her forward.

STRING: I'm not a number. I'm not a number.

BEDEVERE: Uh, but you are dressed as one.

STRING: They dressed me up like this. 

Tenuously-trying-to-keep-python-related'ly yours,

-tkc

[toc] | [prev] | [next] | [standalone]

#56561

"MRAB" <python@mrabarnett.plus.com> wrote in message 
news:52568B30.8040905@mrabarnett.plus.com...
> On 10/10/2013 09:23, Frank Millman wrote:
>>
>> "Steven D'Aprano" <steve@pearwood.info> wrote in message
>> news:52562ee3$0$2931$c3e8da3$76491128@news.astraweb.com...
>>> Just came across this little Javascript gem:
>>>
>>> ",,," == Array((null,'cool',false,NaN,4));
>>>
>>> => evaluates as true
>>>
>>> http://wtfjs.com/2011/02/11/all-your-commas-are-belong-to-Array
>>>
>>> I swear, I am never going to complain about Python again.
>>>
>>
>> I am sure you know this, but for the record, Javascript has two equality
>> operators, '==' and '==='.
>>
>> The double form attempts to coerce the left and right sides to the same
>> type, the triple form does not.
>>
> Re "==", this page:
>
>     http://php.net/manual/en/language.operators.comparison.php
>
> states:
>
> """If you compare a number with a string or the *comparison involves
> numerical strings*, then each string is converted to a number and the
> comparison performed numerically.""" (emphasis added)
>
> So they get coerced to numbers if they _look_ like numbers!
>

I just tested Steven's example.

",,," == Array((null,'cool',false,NaN,4)) evaluates to true

",,," === Array((null,'cool',false,NaN,4)) evaluates to false

I did look at the article that Steven linked to, but it made my eyes glaze, 
so don't ask me to explain it. I am prepared to use up a few brain cells 
trying to improve my own programming, but not trying to understand someone 
else's 'wtf' moments! [1]

Frank

[1]  Unless I have to maintain it, of course. I have been there before, and 
I have some dark memories!

[toc] | [prev] | [next] | [standalone]

#56564

In article <52562ee3$0$2931$c3e8da3$76491128@news.astraweb.com>,
 Steven D'Aprano <steve@pearwood.info> wrote:

> Just came across this little Javascript gem:
> 
> ",,," == Array((null,'cool',false,NaN,4));
> 
> => evaluates as true
> 
> http://wtfjs.com/2011/02/11/all-your-commas-are-belong-to-Array
> 
> I swear, I am never going to complain about Python again.

I've just finished reading JavaScript: The Good Parts, by Douglas 
Crockford (now I'm working on the harder part of re-reading it slowly, 
to make sure I really understand it).  Anybody who is forced to work 
with javascript should read this book.  It's the K&R of JS.

Anyway, one of the pieces of advice he gives is to pretend that == 
doesn't exist, and always use ===.  PHP suffers from much the same 
problem.

BTW, here's a Python equality oddity:

>>> r = 0.0
>>> c = 0 + 0j
>>> r == c
True
>>> int(r) == int(c)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't convert complex to int

If x == y, then f(x) should also equal f(y).  More specifically, if x == 
y, and x is in the domain of f(), then y should also be in the domain of 
f().

BTW, one of the earliest things that turned me on to Python was when I 
discovered that it uses j as the imaginary unit, not i.  All 
right-thinking people will agree with me on this.

[toc] | [prev] | [next] | [standalone]

#56585

On 2013-10-10, Roy Smith <roy@panix.com> wrote:
> In article <52562ee3$0$2931$c3e8da3$76491128@news.astraweb.com>,
>  Steven D'Aprano <steve@pearwood.info> wrote:
>
>> Just came across this little Javascript gem:
>> 
>> ",,," == Array((null,'cool',false,NaN,4));
>> 
>> => evaluates as true
>> 
>> http://wtfjs.com/2011/02/11/all-your-commas-are-belong-to-Array
>> 
>> I swear, I am never going to complain about Python again.
>
> I've just finished reading JavaScript: The Good Parts, by Douglas 
> Crockford (now I'm working on the harder part of re-reading it slowly, 
> to make sure I really understand it).  Anybody who is forced to work 
> with javascript should read this book.  It's the K&R of JS.
>
> Anyway, one of the pieces of advice he gives is to pretend that == 
> doesn't exist, and always use ===.  PHP suffers from much the same 
> problem.
>
> BTW, here's a Python equality oddity:
>
>>>> r = 0.0
>>>> c = 0 + 0j
>>>> r == c
> True
>>>> int(r) == int(c)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: can't convert complex to int
>
> If x == y, then f(x) should also equal f(y).  More
> specifically, if x == y, and x is in the domain of f(), then y
> should also be in the domain of f().

Mixed arithmetic always promotes to the wider type (except in
the case of complex numbers (Ha!)).

r == c is equivalent to r == abs(c), which returns the magintude
of the complex number.

I wonder why it was deemed reasonable to do that but not for the
float constructor to do the same, or even int.

> BTW, one of the earliest things that turned me on to Python was
> when I discovered that it uses j as the imaginary unit, not i.
> All right-thinking people will agree with me on this.

On top of the engineering origin, j is more noticeable.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#56586

On 10/10/2013 16:51, Neil Cerutti wrote:
> [...]
>
> Mixed arithmetic always promotes to the wider type (except in
> the case of complex numbers (Ha!)).
>
> r == c is equivalent to r == abs(c), which returns the magintude
> of the complex number.

What?

 >>> -1 == -1 + 0j
True
 >>> -1 == abs(-1 + 0j)
False
 >>> 1 == 0 + 1j
False
 >>> 1 == abs(0 + 1j)
True

[toc] | [prev] | [next] | [standalone]

#56587

On 10/10/2013 16:57, Rotwang wrote:
> On 10/10/2013 16:51, Neil Cerutti wrote:
>> [...]
>>
>> Mixed arithmetic always promotes to the wider type (except in
>> the case of complex numbers (Ha!)).
>>
>> r == c is equivalent to r == abs(c), which returns the magintude
>> of the complex number.
>
> What?
>
>   >>> -1 == -1 + 0j
> True
>   >>> -1 == abs(-1 + 0j)
> False
>   >>> 1 == 0 + 1j
> False
>   >>> 1 == abs(0 + 1j)
> True
>
Indeed.

If r is real (float) and c is complex:

     r == c means r == c.real and c.imag == 0.0

[toc] | [prev] | [next] | [standalone]

#56593

On 2013-10-10, MRAB <python@mrabarnett.plus.com> wrote:
> On 10/10/2013 16:57, Rotwang wrote:
>> On 10/10/2013 16:51, Neil Cerutti wrote:
>>> [...]
>>>
>>> Mixed arithmetic always promotes to the wider type (except in
>>> the case of complex numbers (Ha!)).
>>>
>>> r == c is equivalent to r == abs(c), which returns the magintude
>>> of the complex number.
>>
>> What?
>>
>>   >>> -1 == -1 + 0j
>> True
>>   >>> -1 == abs(-1 + 0j)
>> False
>>   >>> 1 == 0 + 1j
>> False
>>   >>> 1 == abs(0 + 1j)
>> True
>>
> Indeed.
>
> If r is real (float) and c is complex:
>
>      r == c means r == c.real and c.imag == 0.0

Woah. I thought I was going by what the docs say:

  Python fully supports mixed arithmetic: when a binary
  arithmetic operator has operands of different numeric types,
  the operand with the “narrower” type is widened to that of the
  other, where integer is narrower than floating point, which is
  narrower than complex. Comparisons between numbers of mixed
  type use the same rule. [2] The constructors int(), float(),
  and complex() can be used to produce numbers of a specific
  type.

[...]

  [2] Not for complex numbers. Instead convert to floats using
     abs() if appropriate.

I guess the "if appropriate" part eluded my eye. When *is* it
appropriate? Apparently not during an equal test.

>>> 5.0 == abs(3 + 4j)
False

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#56597

On Thu, Oct 10, 2013 at 11:48 AM, Neil Cerutti <neilc@norwich.edu> wrote:
> On 2013-10-10, MRAB <python@mrabarnett.plus.com> wrote:
>> On 10/10/2013 16:57, Rotwang wrote:
>>> On 10/10/2013 16:51, Neil Cerutti wrote:
>>>> [...]
>>>>
>>>> Mixed arithmetic always promotes to the wider type (except in
>>>> the case of complex numbers (Ha!)).
>>>>
>>>> r == c is equivalent to r == abs(c), which returns the magintude
>>>> of the complex number.
>>>
>>> What?
>>>
>>>   >>> -1 == -1 + 0j
>>> True
>>>   >>> -1 == abs(-1 + 0j)
>>> False
>>>   >>> 1 == 0 + 1j
>>> False
>>>   >>> 1 == abs(0 + 1j)
>>> True
>>>
>> Indeed.
>>
>> If r is real (float) and c is complex:
>>
>>      r == c means r == c.real and c.imag == 0.0
>
> Woah. I thought I was going by what the docs say:
>
>   Python fully supports mixed arithmetic: when a binary
>   arithmetic operator has operands of different numeric types,
>   the operand with the “narrower” type is widened to that of the
>   other, where integer is narrower than floating point, which is
>   narrower than complex. Comparisons between numbers of mixed
>   type use the same rule. [2] The constructors int(), float(),
>   and complex() can be used to produce numbers of a specific
>   type.
>
> [...]
>
>   [2] Not for complex numbers. Instead convert to floats using
>      abs() if appropriate.
>
> I guess the "if appropriate" part eluded my eye. When *is* it
> appropriate? Apparently not during an equal test.

If you click on the footnote, it takes you to:

[2]As a consequence, the list [1, 2] is considered equal to [1.0,
2.0], and similarly for tuples.

The text that you have mistakenly identified as the footnote is
actually part of the key to the "Notes" column of the numeric
operations table, where it is referred to by the "x % y" and
"divmod(x, y)" operations.  Specifically, it warns of this error:

>>> 3j % 2j
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't mod complex numbers.

[toc] | [prev] | [next] | [standalone]

#56599

On 2013-10-10, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Thu, Oct 10, 2013 at 11:48 AM, Neil Cerutti <neilc@norwich.edu> wrote:
>> Woah. I thought I was going by what the docs say:
>>
>>   Python fully supports mixed arithmetic: when a binary
>>   arithmetic operator has operands of different numeric types,
>>   the operand with the ?narrower? type is widened to that of the
>>   other, where integer is narrower than floating point, which is
>>   narrower than complex. Comparisons between numbers of mixed
>>   type use the same rule. [2] The constructors int(), float(),
>>   and complex() can be used to produce numbers of a specific
>>   type.
>>
>> [...]
>>
>>   [2] Not for complex numbers. Instead convert to floats using
>>      abs() if appropriate.
>>
>> I guess the "if appropriate" part eluded my eye. When *is* it
>> appropriate? Apparently not during an equal test.
>
> If you click on the footnote, it takes you to:
>
> [2]As a consequence, the list [1, 2] is considered equal to [1.0,
> 2.0], and similarly for tuples.
>
> The text that you have mistakenly identified as the footnote is
> actually part of the key to the "Notes" column of the numeric
> operations table, where it is referred to by the "x % y" and
> "divmod(x, y)" operations.  Specifically, it warns of this error:
>
>>>> 3j % 2j
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: can't mod complex numbers.

Doh!

Thanks, for that, and for the corrections. I could have avoided
all this by testing it correctly in the REPL, too.

I'll click on those footnotes instead of scanning to them from
now on.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#56605

On 10 October 2013 18:48, Neil Cerutti <neilc@norwich.edu> wrote:
> I guess the "if appropriate" part eluded my eye. When *is* it
> appropriate? Apparently not during an equal test.
>
>>>> 5.0 == abs(3 + 4j)
> False

If the above is genuine output then it's most likely floating point
error. I wouldn't expect any errors in that though. What version of
Python are you using and on what OS/hardware?

I get the following in Python 2.7 and 3.2 on Ubuntu 12.04 with a
32-bit AMD processor:
>>> 5.0 == abs(3+4j)
True


Oscar

[toc] | [prev] | [next] | [standalone]

#56606

On 2013-10-10, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
> On 10 October 2013 18:48, Neil Cerutti <neilc@norwich.edu> wrote:
>> I guess the "if appropriate" part eluded my eye. When *is* it
>> appropriate? Apparently not during an equal test.
>>
>>>>> 5.0 == abs(3 + 4j)
>> False
>
> If the above is genuine output then it's most likely floating point
> error. I wouldn't expect any errors in that though. What version of
> Python are you using and on what OS/hardware?
>
> I get the following in Python 2.7 and 3.2 on Ubuntu 12.04 with a
> 32-bit AMD processor:
>>>> 5.0 == abs(3+4j)
> True

I get the same thing. I was apparently quite confused.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#56611

On 10Oct2013 17:48, Neil Cerutti <neilc@norwich.edu> wrote:
> On 2013-10-10, MRAB <python@mrabarnett.plus.com> wrote:
> > If r is real (float) and c is complex:
> >      r == c means r == c.real and c.imag == 0.0
> 
> Woah. I thought I was going by what the docs say:
> 
>   Python fully supports mixed arithmetic: when a binary
>   arithmetic operator has operands of different numeric types,
>   the operand with the “narrower” type is widened to that of the
>   other, where integer is narrower than floating point, which is
>   narrower than complex. Comparisons between numbers of mixed
>   type use the same rule. [2] The constructors int(), float(),
>   and complex() can be used to produce numbers of a specific
>   type.
> 
> [...]
> 
>   [2] Not for complex numbers. Instead convert to floats using
>      abs() if appropriate.
> 
> I guess the "if appropriate" part eluded my eye. When *is* it
> appropriate? Apparently not during an equal test.

I must say that I read the footnote [2] as a directive to the
programmer. "If you need to do this, a good way is to compare
magnitudes is appropriate."

Cheers,
-- 
Cameron Simpson <cs@zip.com.au>

My life is a never ending battle for the forces of good.
Unfortunately, unlike many other crusaders for righteousness, in my
system of morality, the right thing to do is very often to sit around
reading the paper or watching TV.       - Tim_Mefford <tim@physics.orst.edu>

[toc] | [prev] | [next] | [standalone]

#56622

In article <bbo7j0Fbp3qU1@mid.individual.net>,
 Neil Cerutti <neilc@norwich.edu> wrote:

> >>> 5.0 == abs(3 + 4j)
> False

I'd like an argument, please.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web