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

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

code review

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

Contents

  code review "Littlefield, Tyler" <tyler@tysdomain.com> - 2012-06-28 20:57 -0600
    Re: code review alex23 <wuwei23@gmail.com> - 2012-06-28 20:58 -0700
      Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-06-29 07:31 +0000
        Re: code review Chris Angelico <rosuav@gmail.com> - 2012-06-29 17:42 +1000
        Re: code review "Littlefield, Tyler" <tyler@tysdomain.com> - 2012-06-29 09:03 -0600
          Re: code review Alister <alister.ware@ntlworld.com> - 2012-06-29 19:41 +0000
            Re: code review MRAB <python@mrabarnett.plus.com> - 2012-06-29 21:09 +0100
            Re: code review "Martin P. Hellwig" <martin.hellwig@gmail.com> - 2012-06-29 13:27 -0700
              Re: code review Alister <alister.ware@ntlworld.com> - 2012-06-29 20:43 +0000
                Re: code review Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-06-29 19:02 -0400
                Re: code review Terry Reedy <tjreedy@udel.edu> - 2012-06-29 23:02 -0400
            Re: code review "Littlefield, Tyler" <tyler@tysdomain.com> - 2012-06-29 14:49 -0600
              Re: code review Alister <alister.ware@ntlworld.com> - 2012-06-30 09:31 +0000
                Re: code review Alister <alister.ware@ntlworld.com> - 2012-06-30 09:36 +0000
            Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-06-30 02:28 +0000
              Re: code review Alister <alister.ware@ntlworld.com> - 2012-06-30 09:22 +0000
            Re: code review Terry Reedy <tjreedy@udel.edu> - 2012-06-29 23:00 -0400
          Re: code review Alister <alister.ware@ntlworld.com> - 2012-06-30 10:04 +0000
            Re: code review Peter Otten <__peter__@web.de> - 2012-06-30 12:29 +0200
              Re: code review Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-06-30 20:39 +0200
                Re: code review Thomas Jollans <t@jollybox.de> - 2012-06-30 21:38 +0200
                  Re: code review Alister <alister.ware@ntlworld.com> - 2012-06-30 20:30 +0000
                    Re: code review Thomas Jollans <t@jollybox.de> - 2012-06-30 22:50 +0200
                      Re: code review Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2012-06-30 23:07 +0200
                        Re: code review Thomas Jollans <t@jollybox.de> - 2012-06-30 23:35 +0200
                        Re: code review Terry Reedy <tjreedy@udel.edu> - 2012-06-30 17:47 -0400
                        Re: code review Thomas Jollans <t@jollybox.de> - 2012-07-01 00:05 +0200
                          Re: code review Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2012-07-01 01:03 +0200
                          Re: code review Ben Finney <ben+python@benfinney.id.au> - 2012-07-01 10:08 +1000
                            Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-01 10:37 +1000
                              Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-01 03:23 +0000
                                Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-01 13:48 +1000
                                  Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-01 06:54 +0000
                                    Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-01 16:59 +1000
                                    Re: code review Terry Reedy <tjreedy@udel.edu> - 2012-07-01 05:55 -0400
                                      Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-02 01:26 +0000
                                        Re: code review Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-07-13 12:30 +0000
                                          Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-13 15:04 +0000
                                            Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-14 01:36 +1000
                                              Re: code review rusi <rustompmody@gmail.com> - 2012-07-13 09:24 -0700
                                            Re: code review Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-07-13 16:39 -0400
                                            Re: code review Duncan Booth <duncan.booth@invalid.invalid> - 2012-07-16 10:43 +0000
                                              Re: code review Ben Finney <ben+python@benfinney.id.au> - 2012-07-16 21:34 +1000
                                              Re: code review Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-07-17 10:54 +0000
                                          Re: code review Terry Reedy <tjreedy@udel.edu> - 2012-07-13 19:09 -0400
                                          Re: code review Ian Kelly <ian.g.kelly@gmail.com> - 2012-07-14 03:26 -0600
                                          Re: code review Terry Reedy <tjreedy@udel.edu> - 2012-07-14 16:42 -0400
                                Re: code review rusi <rustompmody@gmail.com> - 2012-06-30 21:07 -0700
                                  Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-01 14:20 +1000
                              Re: code review Ben Finney <ben+python@benfinney.id.au> - 2012-07-01 17:28 +1000
                                Re: code review Thomas Jollans <t@jollybox.de> - 2012-07-01 09:46 +0200
                                  Re: code review HoneyMonster <nobody@someplace.invalid> - 2012-07-01 20:53 +0000
                                Re: code review Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-01 05:18 -0400
                                  Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-02 00:41 +0000
                                    Re: code review Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-01 21:40 -0400
                                Re: code review Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-07-01 13:41 -0400
                                Re: code review John O'Hagan <research@johnohagan.com> - 2012-07-02 14:43 +1000
                            Re: Re: code review Evan Driscoll <driscoll@cs.wisc.edu> - 2012-06-30 23:45 -0500
                              Re: Re: code review Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-07-01 08:57 +0200
                              Re: code review Alister <alister.ware@ntlworld.com> - 2012-07-01 09:54 +0000
                                Re: Re: code review Evan Driscoll <driscoll@cs.wisc.edu> - 2012-07-01 10:48 -0500
                                  Re: Re: code review lars van gemerden <lars@rational-it.com> - 2012-07-06 04:22 -0700
                                  Re: Re: code review lars van gemerden <lars@rational-it.com> - 2012-07-06 04:22 -0700
                                    Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-06 13:58 +0000
                                      Re: code review Roy Smith <roy@panix.com> - 2012-07-13 08:32 -0700
                            Re: code review Evan Driscoll <driscoll@cs.wisc.edu> - 2012-06-30 23:57 -0500
                              Re: code review Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-07-01 09:04 +0200
                          Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-01 02:06 +0000
                            Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-01 12:20 +1000
                              Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-01 04:17 +0000
                                Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-01 14:23 +1000
                                  Re: code review Steven D'Aprano <steve+usenet@pearwood.info> - 2012-07-01 06:27 +0000
                                    Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-01 16:33 +1000
                                      Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-02 01:28 +0000
                                        Re: code review Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-07-01 21:50 -0400
                                          Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-02 07:29 +0000
                                        Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-02 12:04 +1000
                                          Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-02 08:11 +0000
                                            Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-02 18:20 +1000
                                              Re: code review Rick Johnson <rantingrickjohnson@gmail.com> - 2012-07-02 08:57 -0700
                                                Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-03 02:42 +1000
                                                  Re: code review Rick Johnson <rantingrickjohnson@gmail.com> - 2012-07-02 11:22 -0700
                                                    Re: code review Thomas Jollans <t@jollybox.de> - 2012-07-02 21:06 +0200
                                                      Re: code review Rick Johnson <rantingrickjohnson@gmail.com> - 2012-07-02 12:35 -0700
                                                    Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-03 07:57 +1000
                                                  Re: code review Neil Cerutti <neilc@norwich.edu> - 2012-07-03 12:19 +0000
                                        Re: code review Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-07-02 01:20 -0400
                                        Re: code review Thomas Jollans <t@jollybox.de> - 2012-07-02 16:41 +0200
                                        Re: code review Terry Reedy <tjreedy@udel.edu> - 2012-07-02 11:33 -0400
                            Re: code review Thomas Jollans <t@jollybox.de> - 2012-07-01 09:35 +0200
                              Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-02 00:43 +0000
                                Re: code review Thomas Jollans <t@jollybox.de> - 2012-07-02 16:26 +0200
                            Re: code review Rick Johnson <rantingrickjohnson@gmail.com> - 2012-07-02 08:16 -0700
                              Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-03 02:55 +1000
                                Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-03 00:57 +0000
                                  Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-03 11:22 +1000
                                  Re: code review John O'Hagan <research@johnohagan.com> - 2012-07-03 12:25 +1000
                                    Re: code review Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-03 04:11 +0000
                                      Re: code review Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-07-03 02:09 -0400
                                        Re: code review Roy Smith <roy@panix.com> - 2012-07-03 08:33 -0400
                                      Re: code review Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-03 16:53 +0100
                                      Re: code review Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-07-03 17:32 -0400
                                    Re: code review rusi <rustompmody@gmail.com> - 2012-07-02 22:10 -0700
                                      Re: code review Ben Finney <ben+python@benfinney.id.au> - 2012-07-03 15:46 +1000
                                      Re: code review John O'Hagan <research@johnohagan.com> - 2012-07-04 00:59 +1000
                                  Re: code review Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-03 16:50 +0100
                                    Re: code review Paul Rudin <paul.nospam@rudin.co.uk> - 2012-07-04 10:29 +0100
                                      Re: code review Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-04 17:25 +0100
                                  Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-04 01:53 +1000
                                  Re: code review Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-03 17:05 +0100
                                  Re: code review Dave Angel <d@davea.name> - 2012-07-03 16:13 -0400
                                  Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-04 07:54 +1000
                                  Re: code review Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-04 09:28 +0100
                          Re: code review rusi <rustompmody@gmail.com> - 2012-06-30 19:37 -0700
                        Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-01 09:25 +1000
                        Re: code review Thomas Jollans <t@jollybox.de> - 2012-07-01 01:50 +0200
                    Re: code review "Martin P. Hellwig" <martin.hellwig@gmail.com> - 2012-06-30 14:48 -0700
                    Re: code review Ian Kelly <ian.g.kelly@gmail.com> - 2012-07-02 13:16 -0600
              Re: code review Alister <alister.ware@ntlworld.com> - 2012-06-30 20:25 +0000
            Re: code review Kushal Kumaran <kushal.kumaran+python@gmail.com> - 2012-07-03 23:23 +0530
              Re: code review John Gordon <gordon@panix.com> - 2012-07-03 18:18 +0000
                Re: code review Ian Kelly <ian.g.kelly@gmail.com> - 2012-07-03 12:27 -0600
                Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-04 07:51 +1000
            Re: code review Ian Kelly <ian.g.kelly@gmail.com> - 2012-07-03 12:19 -0600
            Re: code review kushal.kumaran+python@gmail.com - 2012-07-04 08:27 +0530
            Re: code review Chris Angelico <rosuav@gmail.com> - 2012-07-04 13:53 +1000
            Re: code review Simon Cropper <simoncropper@fossworkflowguides.com> - 2012-07-04 14:55 +1000
            Re: code review "Littlefield, Tyler" <tyler@tysdomain.com> - 2012-07-03 23:39 -0600
              Re: code review alex23 <wuwei23@gmail.com> - 2012-07-03 23:17 -0700
                Re: code review rusi <rustompmody@gmail.com> - 2012-07-04 00:05 -0700
            Apology for OT posts (was: code review) John O'Hagan <research@johnohagan.com> - 2012-07-06 12:06 +1000
            Re: Apology for OT posts Simon Cropper <simoncropper@fossworkflowguides.com> - 2012-07-06 15:30 +1000
            Re: Apology for OT posts Chris Angelico <rosuav@gmail.com> - 2012-07-06 17:45 +1000
            Re: Apology for OT posts Mark Lawrence <breamoreboy@yahoo.co.uk> - 2012-07-06 10:37 +0100

Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →

#24743

On 7/1/2012 4:54, Alister wrote:
> On Sat, 30 Jun 2012 23:45:25 -0500, Evan Driscoll wrote:
>> If I had seen that in a program, I'd have assumed it was a bug.
> 
> You would?
> I have only been using python for 6 - 12 months but in my past I 
> programmed microcontrollers in assembly.
> 
> as soon as i saw it i understood it & thought great, like a light bulb 
> going on.

It's not a matter of "I wouldn't have understood what the author was
trying to do" (with a small caveat), it's a matter of "I'd have assumed
that the author didn't understand the language semantics."

I'm pretty sure it goes contrary to *every other programming language
I've ever used* (and a couple that I haven't).

I understand why Python does it, and it certainly is nice in that it
matches typical mathematical notation, but the surprise quotient is
*very* high in the PL world IMO.

Evan

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

#24964

On Sunday, July 1, 2012 5:48:40 PM UTC+2, Evan Driscoll wrote:
> On 7/1/2012 4:54, Alister wrote:
> > On Sat, 30 Jun 2012 23:45:25 -0500, Evan Driscoll wrote:
> >> If I had seen that in a program, I'd have assumed it was a bug.
> > 
> > You would?
> > I have only been using python for 6 - 12 months but in my past I 
> > programmed microcontrollers in assembly.
> > 
> > as soon as i saw it i understood it & thought great, like a light bulb 
> > going on.
> 
> It's not a matter of "I wouldn't have understood what the author was
> trying to do" (with a small caveat), it's a matter of "I'd have assumed
> that the author didn't understand the language semantics."
> 
> I'm pretty sure it goes contrary to *every other programming language
> I've ever used* (and a couple that I haven't).
> 
> I understand why Python does it, and it certainly is nice in that it
> matches typical mathematical notation, but the surprise quotient is
> *very* high in the PL world IMO.
> 
> Evan

Avoiding suprises would mean we cannot improve languages, just reshuffle features?

Cheers, Lars

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

#24965

On Sunday, July 1, 2012 5:48:40 PM UTC+2, Evan Driscoll wrote:
> On 7/1/2012 4:54, Alister wrote:
> > On Sat, 30 Jun 2012 23:45:25 -0500, Evan Driscoll wrote:
> >> If I had seen that in a program, I'd have assumed it was a bug.
> > 
> > You would?
> > I have only been using python for 6 - 12 months but in my past I 
> > programmed microcontrollers in assembly.
> > 
> > as soon as i saw it i understood it & thought great, like a light bulb 
> > going on.
> 
> It's not a matter of "I wouldn't have understood what the author was
> trying to do" (with a small caveat), it's a matter of "I'd have assumed
> that the author didn't understand the language semantics."
> 
> I'm pretty sure it goes contrary to *every other programming language
> I've ever used* (and a couple that I haven't).
> 
> I understand why Python does it, and it certainly is nice in that it
> matches typical mathematical notation, but the surprise quotient is
> *very* high in the PL world IMO.
> 
> Evan

Avoiding suprises would mean we cannot improve languages, just reshuffle features?

Cheers, Lars

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

#24969

On Fri, 06 Jul 2012 04:22:18 -0700, lars van gemerden wrote:

> Avoiding suprises would mean we cannot improve languages, just reshuffle
> features?

No, of course not.

But there have been hundreds of programming languages, including many 
different programming paradigms (procedural, imperative, object oriented, 
stack-based, functional, logic, aspect, event-driven, natural language, 
and many others), and tens of millions of person-days worth of experience 
in programming. It's not 1960 any more, in general terms we mostly have a 
good idea of what works and what doesn't. (Sadly, when I say "we" I mean 
collectively. Many language designers, and programmers, don't have the 
foggiest clue as to what makes a good clean design. Hence C++ and PHP.)

The days when you could expect a brilliant new programming paradigm to 
lead to a massive improvement in programmer productivity, like going from 
assembly code to Fortran, are long gone. Now we look for incremental 
improvements. (Although of course there is always a chance that some yet 
unthought of new paradigm will revolutionise computer programming -- but 
I wouldn't bet on it.)

When you're dealing with a well-designed, mature language like Python, 
you are even more limited. There's only so many changes you can make 
without turning it into a completely different language. And if you care 
about backward compatibility and wish to avoid breaking existing 
programs, there are even fewer changes that can be considered.

Many good programming features must be avoided, not because they are bad, 
but because they don't match the rest of the language. Even though Python 
copies features from many different paradigms and languages, there is a 
mostly unified style of good Python code and any feature that doesn't 
match that style should be left out. There's few things worse than a 
language with random features just bolted on.


-- 
Steven

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

#25267

On Friday, July 6, 2012 9:58:10 AM UTC-4, Steven D'Aprano wrote:
> (Sadly, when I say "we" I mean 
> collectively. Many language designers, and programmers, don't have the 
> foggiest clue as to what makes a good clean design. Hence C++ and PHP.)

I'm not going to defend C++, but to be fair, a major driver of the design is that it had to be plug-compatible with C.  From that you're stuck with the preprocessor and pointers.  Much goes downhill when you start from there.

PHP, yeah, that's just charlie-foxtrot from start to finish.

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

#24724

[Multipart message — attachments visible in raw view] — view raw

On 6/30/2012 23:45, Evan Driscoll wrote:
> You may also
> want to put Java in there as well, as < is effectively not commutative
> in that language. (I didn't try C#.)

I guess you could actually put Lua and Ruby into the roughly same
category as Java too.

But things get a little nastier in ==, as 'false == false == false'
evaluates as '(false == false) == false' to 'false' in Java and Lua.
(Ruby produces a syntax error for this, roughly the Haskell approach.)

But we have Javascript:
  1 < 1 < 2
  => true
  false == false == false
  => false

O'Caml:
  # false == false == false;;
  - : bool = false
  # 1 < 2 < true;;
  - : bool = false

Java:
  System.out.println(false == false == false);
  (outputs) false

Lua:
  > print(false == false == false)
  false

C and C++:
  std::cout << (1 < 1 < 3) << "\n";
  (outputs) 1
  std::cout << (false == false == false) << "\n";
  (outputs) 0

Evan

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

#24731

Evan Driscoll wrote:

> On 6/30/2012 23:45, Evan Driscoll wrote:
>> You may also
>> want to put Java in there as well, as < is effectively not commutative
>> in that language. (I didn't try C#.)
> 
> I guess you could actually put Lua and Ruby into the roughly same
> category as Java too.
> 
> But things get a little nastier in ==, as 'false == false == false'
> evaluates as '(false == false) == false' to 'false' in Java and Lua.
> (Ruby produces a syntax error for this, roughly the Haskell approach.)
> 
> But we have Javascript:

s/Javascript/ECMAScript (implementations)/g

>   1 < 1 < 2
>   => true
>   false == false == false
>   => false

Correct, because

  0. 1 < 1 < 2
  1. (1 < 1) < 2
  2. false < 2
  3. 0 < 2
  4. true

and

  0. false == false == false
  1. (false == false) == false
  2. true == false
  3. false

See also the ECMAScript Language Specification, 5.1 Edition, section 11.9:

<http://ecma-international.org/ecma-262/5.1/#sec-11.9>

-- 
PointedEars

Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#24714

On Sun, 01 Jul 2012 00:05:26 +0200, Thomas Jollans wrote:

> Yes. My sole point, really, is that "normally", one would expect these
> two expressions to be equivalent:
> 
> a < b < c
> (a < b) < c

Good grief. Why would you expect that?

You can't just arbitrarily stick parentheses around parts of expressions 
and expect the result to remain unchanged. Order of evaluation matters:

2**3**4 != (2**3)**4

Comparisons are no different. You can't just toss in some arbitrary 
brackets and expect the result to be the same. In the second case, the 
parentheses explicitly turn the comparison into the equivalent of this:

temporary_flag = a < b
temporary_flag < c

which is not the same as a < b < c.

This has nothing to do with chained comparisons. You can write the same 
thing without chaining:

a < b and b < c
(a < b) < c

Is it not obvious that the second case is completely different from the 
first? Chaining is irrelevant here.


> This is clearly not true. That's the inconsistency here with the rest of
> the language.

Nonsense. Your expectation that parentheses should not affect the order 
of evaluation is at odds with the entire Python language, to say nothing 
of almost every programming language in existence.


> As soon as you read it as a ternary operator, 

Well that's your problem. Why are you reading it as a ternary operator? 
It isn't one. It is a pair of chained binary operator.

How can you tell that it is a pair of binary operators, rather than a 
single ternary operator?

1) There are TWO operators, hence a pair, not a single ternary operator;

2) each operator takes TWO arguments, not three.



Chained comparisons is a standard mathematical notation with an obvious 
meaning that is familiar to anyone with even a passing familiarity to 
mathematics. They have straight-forward and simple semantics. If other 
languages don't allow them, so much the worse for other languages.

You seem to be inventing arguments to support an irrational dislike to 
the feature, but the arguments don't stand up. By all means say that you 
don't like chained comparisons, that is your right, but your attempts to 
rationalise that dislike simply do not work.


-- 
Steven

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

#24715

On Sun, Jul 1, 2012 at 12:06 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> You can't just arbitrarily stick parentheses around parts of expressions
> and expect the result to remain unchanged. Order of evaluation matters:
>
> 2**3**4 != (2**3)**4

But that's because ** binds right to left. It _is_ valid to say:

2**3**4 = 2**(3**4)

That's the usual way of depicting order of evaluation: putting in the
implicit parentheses.

1+2*3 = 1+(2*3)

Everyone who knows algebra knows that the parens are optional, but
nobody would expect them to change the evaluation of the expression.
It's like adding whitespace:

1+2*3 = 1 + 2 * 3 = 1 + 2*3

where the latter is another way of showing order of evaluation (the
asterisk "binds more tightly" than the plus). With comparisons, it's
not the same.

(a<b)<=(c<d)

is, incidentally, a valid expression, as long as you accept that False
is less than True. So if (c<d) is replaced by a boolean variable, you
can conceivably have an expression like:

(len(x)<minimum)<require_minimum

where 'minimum' is an integer and 'require_minimum' is a boolean that,
if set to False, overrides the check. Sure, there's other ways to do
this, but this is at least plausible. And it's completely different
from:

len(x)<minimum<require_minimum

as Python interprets it.

ChrisA

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

#24720

On Sun, 01 Jul 2012 12:20:52 +1000, Chris Angelico wrote:

> On Sun, Jul 1, 2012 at 12:06 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> You can't just arbitrarily stick parentheses around parts of
>> expressions and expect the result to remain unchanged. Order of
>> evaluation matters:
>>
>> 2**3**4 != (2**3)**4
> 
> But that's because ** binds right to left. It _is_ valid to say:
> 
> 2**3**4 = 2**(3**4)

Yes, but my point is that you can't just add parentheses arbitrarily 
without understanding what you're doing.

If you're used to some feeble $2 calculator that doesn't implement 
operator precedence, you might expect that you could do this too:

1+2*3
(1+2)*3

But you can't. It's your expectations that are skewed, not Python.

If you (generic you) are used to some feeble $2 language that doesn't 
implement chained comparisons, it is your expectations that are skewed, 
not Python.

Comparisons were invented long before C, or even computers, and they have 
had chained semantics long before Python. Languages like C force you to 
unlearn the standard semantics of comparisons, and substitute something 
that is less expressive, less powerful, less efficient, and more likely 
to contain a bug.

This is almost always wrong in languages without chained comparisons:

a < func(x) < b


This is inefficient, and still wrong, if x has side-effects or isn't 
reentrant:

a < func(x) and func(x) < b


This is too verbose for such a simple comparison:

tmp = func(x)
(a < tmp) and (tmp < b)


[...]
> Everyone who knows algebra knows that the parens are optional, but
> nobody would expect them to change the evaluation of the expression.

Nonsense. Of course parens change the evaluation of the expression. 
That's what parens are for!

There may be some specific cases where they don't, because you have 
happened to put them in a specially crafted position where they don't 
actually change the order of evaluation. E.g. putting parens around the 
entire expression, or putting them around a single atom, or around 
another pair of parentheses:

2*(3+4)
=> (2*(3+4))  # unchanged
=> (2)*(3+4)
=> 2*((3+4))


but just because there are *some* places you can add redundant parens 
doesn't mean that you can add them *anywhere*. You have to understand the 
semantics of expression, including the precedence rules. If you don't 
understand them, you might as well be just adding parens in random 
positions, in which case you should expect the semantics to change.


[...]
> (a<b)<=(c<d)
> 
> is, incidentally, a valid expression, as long as you accept that False
> is less than True. 

Right. I'm not saying that there's never any need to evaluate a 
comparison, and then compare it to the result of another comparison. 
That's a perfectly valid thing to do.

And you know what? You can do it, using parens, exactly as shown.

Chained comparisons is the common case, it should have the simple syntax. 
That's why mathematicians write {x : a < x < b} instead of 
{x: a < x} ∩ {x: x < b}. The uncommon case, treating a bool as a value to 
be compared to another value, should be possible, which it is.



-- 
Steven

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

#24722

On Sun, Jul 1, 2012 at 2:17 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Nonsense. Of course parens change the evaluation of the expression.
> That's what parens are for!

The whole point of my example was that it wouldn't.

ChrisA

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

#24726

On Sun, 01 Jul 2012 14:23:36 +1000, Chris Angelico wrote:

> On Sun, Jul 1, 2012 at 2:17 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> Nonsense. Of course parens change the evaluation of the expression.
>> That's what parens are for!
> 
> The whole point of my example was that it wouldn't.

Yes, you can find specially crafted examples where adding parentheses in 
certain places, but not others, doesn't change the overall evaluation of 
the expression. So what? IN GENERAL, adding parentheses changes the 
evaluation of the expression -- that is what they are for.

Therefore, IN GENERAL you should expect that adding parentheses will 
change the result, unless you carefully place them where you know that 
they will have no effect.

Even in C, I can't just do this:

2+3*4
=> (2+3)*4

with the expectation that you can stick parentheses around the left-most 
term without changing the value. The fact that you can do for some 
expressions is irrelevant.

In general, if you don't know the semantics of an expression (including 
the operator precedence), you cannot just assume that adding parens is 
harmless.


-- 
Steven

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

#24727

On Sun, Jul 1, 2012 at 4:27 PM, Steven D'Aprano
<steve+usenet@pearwood.info> wrote:
> Yes, you can find specially crafted examples where adding parentheses in
> certain places, but not others, doesn't change the overall evaluation of
> the expression.

My point was that adding parentheses around the tightest-binding
operator is a common, clear, and usually insignificant, way of
demonstrating operator precedence. So FOR THAT USE they must not
change evaluation of the expression. Obviously if you put them
anywhere else, they change evaluation. Nice job knocking down a straw
man.

ChrisA

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

#24757

On Sun, 01 Jul 2012 16:33:15 +1000, Chris Angelico wrote:

> On Sun, Jul 1, 2012 at 4:27 PM, Steven D'Aprano
> <steve+usenet@pearwood.info> wrote:
>> Yes, you can find specially crafted examples where adding parentheses
>> in certain places, but not others, doesn't change the overall
>> evaluation of the expression.
> 
> My point was that adding parentheses around the tightest-binding
> operator is a common, clear, and usually insignificant, way of
> demonstrating operator precedence. So FOR THAT USE they must not change
> evaluation of the expression. Obviously if you put them anywhere else,
> they change evaluation. Nice job knocking down a straw man.

We *really did have* somebody arguing that chained comparisons are Bad 
because you can't stick parentheses around bits of it without changing 
the semantics. That was an actual argument, not a straw-man.

It's a stupid argument, but don't blame me for pointing out it's 
stupidity. The author *assumed* that a chain of < must be left-
associative in the same way that a chain of + operators is left-
associative, but it isn't. That's an invalid and unsafe assumption -- 
even in C-like languages, there are operators which aren't left-
associative, e.g. exponentiation ** which is usually right-associative. 
(For the record, C itself doesn't have an exponentiation operator.)

When you make unsafe assumptions about an operator, and get bitten by it, 
the *correct* conclusion should be that the assumption was wrong, not 
that the language is wrong.

Technically, < in Python is left-associative: a < b < c first evaluates 
a, not b or c. But it is left-associative under the rules of comparison 
operator chaining, not arithmetic operator chaining.


-- 
Steven

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

#24759

On Sun, Jul 1, 2012 at 9:28 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Technically, < in Python is left-associative: a < b < c first evaluates
> a, not b or c. But it is left-associative under the rules of comparison
> operator chaining, not arithmetic operator chaining.

Left-associativity is when a < b < c is equivalent to (a < b) < c.

You're talking about evaluation order, which can be different. For
example, hypothetically, (a < b) < c could evaluate c first, then b,
then a. However, Python always evaluates operands left-to-right.

A particular case where this comes into play is the ** operator, which
is right-associative but still has a left-to-right evaluation order.

-- Devin

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

#24765

On Sun, 01 Jul 2012 21:50:29 -0400, Devin Jeanpierre wrote:

> On Sun, Jul 1, 2012 at 9:28 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> Technically, < in Python is left-associative: a < b < c first evaluates
>> a, not b or c. But it is left-associative under the rules of comparison
>> operator chaining, not arithmetic operator chaining.
> 
> Left-associativity is when a < b < c is equivalent to (a < b) < c.
> 
> You're talking about evaluation order, which can be different. For
> example, hypothetically, (a < b) < c could evaluate c first, then b,
> then a. However, Python always evaluates operands left-to-right.
> 
> A particular case where this comes into play is the ** operator, which
> is right-associative but still has a left-to-right evaluation order.

Yes, you are right, my mistake.




-- 
Steven

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

#24760

On Mon, Jul 2, 2012 at 11:28 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Sun, 01 Jul 2012 16:33:15 +1000, Chris Angelico wrote:
>
>> On Sun, Jul 1, 2012 at 4:27 PM, Steven D'Aprano
>> <steve+usenet@pearwood.info> wrote:
>>> Yes, you can find specially crafted examples where adding parentheses
>>> in certain places, but not others, doesn't change the overall
>>> evaluation of the expression.
>>
>> My point was that adding parentheses around the tightest-binding
>> operator is a common, clear, and usually insignificant, way of
>> demonstrating operator precedence. So FOR THAT USE they must not change
>> evaluation of the expression. Obviously if you put them anywhere else,
>> they change evaluation. Nice job knocking down a straw man.
>
> We *really did have* somebody arguing that chained comparisons are Bad
> because you can't stick parentheses around bits of it without changing
> the semantics. That was an actual argument, not a straw-man.

Okay, I take back the "straw man" accusation, and apologize for it.
But you were quoting my text at the time, so I thought you were aiming
at my argument - which, not being that, was what led me to think you
were answering what you weren't answering.

> Chained comparisons in the Python sense may be rare in computer
> languages, but it is the standard in mathematics and hardly needs to be
> explained to anyone over the age of twelve. That is a terrible indictment
> on the state of programming language design.

I'd say that proves that Python is a good language for expressing
mathematics in, then. That's all. Doesn't necessarily mean it's good
for any other task (doesn't mean it's bad either of course). Python
does not, meanwhile, have inbuilt operators for calculus, nor does it
have an equation solver. Do we absolutely need them? Empirically no.
Python can be an excellent language without making every bit of
mathematical notation executable. There are, I am sure, plenty of
cases where it would be nice to go:

x = y+2
x*3 = y*4+7
print("x = %d, y = %d",x,y)

You can argue that Python ought to have more-different operators for
comparison and assignment, but the fact of algebra is that it has
neither - the equals sign is more of a declaration of truth. Algebra
simply isn't imperative. It's fine (and fits the Eliza principle) to
evaluate expressions algebraically, but equations aren't assignment.

ChrisA

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

#24768

On Mon, 02 Jul 2012 12:04:29 +1000, Chris Angelico wrote:

>> Chained comparisons in the Python sense may be rare in computer
>> languages, but it is the standard in mathematics and hardly needs to be
>> explained to anyone over the age of twelve. That is a terrible
>> indictment on the state of programming language design.
> 
> I'd say that proves that Python is a good language for expressing
> mathematics in, then. That's all. 

No. Python is a terrible language for expressing mathematics in. As you 
point out, I can't do things like:

x = y+2
x*3 = y*4+7
print("x = %d, y = %d",x,y)

and sensibly get x = 1, y = -1.


But Python is an excellent language for expressing a series of 
comparisons in, which has applications beyond pure maths or algebra. For 
example:

"c" < first_word < second_word == third_word < "x"

I'm sure I don't have to explain what that means -- that standard chained 
notation for comparisons is obvious and simple. 

In Python, you write it the normal way, as above. But some other 
languages force you into verbosity:

("c" < first_word) and (first_word < second_word) and (second_word == 
third_word) and (third_word < "x")

Worst of all are those languages which allow you to write the expression 
as normal, but evaluate it in a way that you almost never want: the 
maximum number of bugs with the minimum convenience.

This has nothing to do with algebra. It is about picking semantics for 
chained comparisons which is sensible and useful and matches what people 
expect from regular language. 

If you write 2+2 = 2*2 = 4, nearly everyone will agree that, yes, that is 
true. Interpreting it as 1 == 4 is neither sensible nor useful and it is 
certainly not what people expect.


-- 
Steven

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

#24769

On Mon, Jul 2, 2012 at 6:11 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> "c" < first_word < second_word == third_word < "x"
>
> I'm sure I don't have to explain what that means -- that standard chained
> notation for comparisons is obvious and simple.
>
> In Python, you write it the normal way, as above. But some other
> languages force you into verbosity:
>
> ("c" < first_word) and (first_word < second_word) and (second_word ==
> third_word) and (third_word < "x")

Uhh, actually you DO have to explain that, because I interpreted it
quite differently:

(("c" < first_word) and (first_word < second_word)) == (third_word < "x")

And even if you can prove that my interpretation is wrong, it's still
plausible enough that I, as a programmer, would have to dive to the
manual (or test in interactive interpreter) to find out which way the
language evaluates this.

ChrisA

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

#24778

On Jul 2, 3:20 am, Chris Angelico <ros...@gmail.com> wrote:
> On Mon, Jul 2, 2012 at 6:11 PM, Steven D'Aprano
>
> <steve+comp.lang.pyt...@pearwood.info> wrote:
> > "c" < first_word < second_word == third_word < "x"
>
> > I'm sure I don't have to explain what that means -- that standard chained
> > notation for comparisons is obvious and simple.
>
> > In Python, you write it the normal way, as above. But some other
> > languages force you into verbosity:
>
> > ("c" < first_word) and (first_word < second_word) and (second_word ==
> > third_word) and (third_word < "x")
>
> Uhh, actually you DO have to explain that, because I interpreted it
> quite differently:
>
> (("c" < first_word) and (first_word < second_word)) == (third_word < "x")

Poor Chris. That's because you've been brainwashed into believing you
must spoon feed your interpreter to get your code working correctly.
Stop applying these naive assumptions to Python code. Python knows
when you reach the end of a statement, no need for redundant
semicolons! Python knows when its reached the end of block and needs
to drop back one level, no need for redundant road signs.  Python
knows Chris; Python KNOWS!

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

Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →

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

csiph-web