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 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7  Next page →

#24699

On 06/30/2012 08:39 PM, Thomas 'PointedEars' Lahn wrote:
> Peter Otten wrote:
> 
>> If you spell it
>>
>> def is_valid_password(password):
>>     return mud.minpass <= len(password) <= mud.maxpass
>>
>> it is even easier to see that you are performing an interval check.
> 
> This is probably a tautology around here, but *what* *a* *great* 
> *programming* *language*.
> 

Personally, I don't like this feature of the language. I find a ternary
operator that uses symbols that can also be binary operators confusing
and inconsistent with the way operators usually work/the way terms are
usually associated.

It has the charm of being something you'd "naturally" write in the
context of non-programming mathematics, at the cost of being very odd
indeed in the context of programming in general and Python in particular.

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

#24701

On Sat, 30 Jun 2012 21:38:58 +0200, Thomas Jollans wrote:

> On 06/30/2012 08:39 PM, Thomas 'PointedEars' Lahn wrote:
>> Peter Otten wrote:
>> 
>>> If you spell it
>>>
>>> def is_valid_password(password):
>>>     return mud.minpass <= len(password) <= mud.maxpass
>>>
>>> it is even easier to see that you are performing an interval check.
>> 
>> This is probably a tautology around here, but *what* *a* *great*
>> *programming* *language*.
>> 
>> 
> Personally, I don't like this feature of the language. I find a ternary
> operator that uses symbols that can also be binary operators confusing
> and inconsistent with the way operators usually work/the way terms are
> usually associated.
> 
> It has the charm of being something you'd "naturally" write in the
> context of non-programming mathematics, at the cost of being very odd
> indeed in the context of programming in general and Python in
> particular.

Surely this fits perfectly with the lines 1 & 7 in the zen of python 
(import this)
"Beautifull is better than ugly" and "Readability counts"

I find that construct both beautiful and readable, if it cannot be used 
in the languages then that is their loss.



-- 
Removing the straw that broke the camel's back does not necessarily
allow the camel to walk again.

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

#24702

On 06/30/2012 10:30 PM, Alister wrote:
> On Sat, 30 Jun 2012 21:38:58 +0200, Thomas Jollans wrote:
> 
>> On 06/30/2012 08:39 PM, Thomas 'PointedEars' Lahn wrote:
>>> Peter Otten wrote:
>>>
>>>> If you spell it
>>>>
>>>> def is_valid_password(password):
>>>>     return mud.minpass <= len(password) <= mud.maxpass
>>>>
>>>> it is even easier to see that you are performing an interval check.
>>>
>>> This is probably a tautology around here, but *what* *a* *great*
>>> *programming* *language*.
>>>
>>>
>> Personally, I don't like this feature of the language. I find a ternary
>> operator that uses symbols that can also be binary operators confusing
>> and inconsistent with the way operators usually work/the way terms are
>> usually associated.
>>
>> It has the charm of being something you'd "naturally" write in the
>> context of non-programming mathematics, at the cost of being very odd
>> indeed in the context of programming in general and Python in
>> particular.
> 
> Surely this fits perfectly with the lines 1 & 7 in the zen of python 
> (import this)
> "Beautifull is better than ugly" and "Readability counts"
> 
> I find that construct both beautiful and readable, if it cannot be used 
> in the languages then that is their loss.

Are we quoting the Zen now?

Contra:

In re usual operator rules:
"Special cases aren't special enough to break the rules."

Which of the two comparisons is done first anyway?
"In the face of ambiguity, refuse the temptation to guess."

Speaking of two comparisons, no "and"!
"Explicit is better than implicit."

Then again, pro:

"Beautiful is better than ugly."
"Readability counts."
"[Although] practicality beats purity."


I can see the appeal. It's quite elegant in and of itself. However, I
find that in the context of the whole Python language, it's a bit of a
glitch and reduces elegance. (I'm probably in the minority on this one)

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

#24703

Thomas Jollans <t@jollybox.de> writes:

>>>>> def is_valid_password(password):
>>>>>     return mud.minpass <= len(password) <= mud.maxpass

> Which of the two comparisons is done first anyway?
> "In the face of ambiguity, refuse the temptation to guess."

There is no ambiguity. See the language reference:

"Formally, if a, b, c, ..., y, z are expressions and op1, op2, ..., opN
are comparison operators, then a op1 b op2 c ... y opN z is equivalent
to a op1 b and b op2 c and ... y opN z, except that each expression is
evaluated at most once."

The last restriction (single evaluation of involved expressions) makes
this a bit more than raw syntactic sugar.

-- Alain.

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

#24704

On 06/30/2012 11:07 PM, Alain Ketterlin wrote:
> Thomas Jollans <t@jollybox.de> writes:
> 
>>>>>> def is_valid_password(password):
>>>>>>     return mud.minpass <= len(password) <= mud.maxpass
> 
>> Which of the two comparisons is done first anyway?
>> "In the face of ambiguity, refuse the temptation to guess."
> 
> There is no ambiguity. See the language reference:

Of course it's technically clearly defined, but the syntax isn't
explicit. To know what the order is (or whether there is an order!) one
has to consult the language reference (which shouldn't be necessary), or
make an educated guess, which would almost certainly be correct, but
we're supposed to refuse the temptation to guess, right?

> "Formally, if a, b, c, ..., y, z are expressions and op1, op2, ..., opN
> are comparison operators, then a op1 b op2 c ... y opN z is equivalent
> to a op1 b and b op2 c and ... y opN z, except that each expression is
> evaluated at most once."
> 
> The last restriction (single evaluation of involved expressions) makes
> this a bit more than raw syntactic sugar.

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

#24707

On 6/30/2012 5:35 PM, Thomas Jollans wrote:
> On 06/30/2012 11:07 PM, Alain Ketterlin wrote:
>> Thomas Jollans <t@jollybox.de> writes:
>>
>>>>>>> def is_valid_password(password):
>>>>>>>      return mud.minpass <= len(password) <= mud.maxpass
>>
>>> Which of the two comparisons is done first anyway?
>>> "In the face of ambiguity, refuse the temptation to guess."
>>
>> There is no ambiguity. See the language reference:
>
> Of course it's technically clearly defined, but the syntax isn't
> explicit. To know what the order is (or whether there is an order!) one
> has to consult the language reference (which shouldn't be necessary), or
> make an educated guess, which would almost certainly be correct, but
> we're supposed to refuse the temptation to guess, right?

Python pretty consistently evaluates expressions and equal precedence 
operators left to right. One really should learn that. No 
'implementation defined' ambiguity.


-- 
Terry Jan Reedy

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

#24708

On 06/30/2012 11:47 PM, Terry Reedy wrote:
> On 6/30/2012 5:35 PM, Thomas Jollans wrote:
>> On 06/30/2012 11:07 PM, Alain Ketterlin wrote:
>>> Thomas Jollans <t@jollybox.de> writes:
>>>
>>>>>>>> def is_valid_password(password):
>>>>>>>>      return mud.minpass <= len(password) <= mud.maxpass
>>>
>>>> Which of the two comparisons is done first anyway?
>>>> "In the face of ambiguity, refuse the temptation to guess."
>>>
>>> There is no ambiguity. See the language reference:
>>
>> Of course it's technically clearly defined, but the syntax isn't
>> explicit. To know what the order is (or whether there is an order!) one
>> has to consult the language reference (which shouldn't be necessary), or
>> make an educated guess, which would almost certainly be correct, but
>> we're supposed to refuse the temptation to guess, right?
> 
> Python pretty consistently evaluates expressions and equal precedence
> operators left to right. 

Yes. My sole point, really, is that "normally", one would expect these
two expressions to be equivalent:

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

This is clearly not true. That's the inconsistency here with the rest of
the language. As soon as you read it as a ternary operator, the two
comparisons are logically simultaneous. Doing the left hand comparison
first is clearly the intuitive thing to do, but it's still, strictly
speaking, arbitrary. Intuitive, clearly defined, but arbitrary.

The ternary conditional operator is a different beast because its
sub-operators "if" and "else" aren't also binary operators, so it's
obvious that it's parsed differently.

> One really should learn that. No
> 'implementation defined' ambiguity.

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

#24709

Thomas Jollans <t@jollybox.de> writes:

> On 06/30/2012 11:47 PM, Terry Reedy wrote:

>>>>>>>>> def is_valid_password(password):
>>>>>>>>>      return mud.minpass <= len(password) <= mud.maxpass
>>>>
>>>>> Which of the two comparisons is done first anyway?
>>>>> "In the face of ambiguity, refuse the temptation to guess."
>>>>
>>>> There is no ambiguity. See the language reference:

>>> Of course it's technically clearly defined, but the syntax isn't
>>> explicit.

>> Python pretty consistently evaluates expressions and equal precedence
>> operators left to right. 
>
> Yes. My sole point, really, is that "normally", one would expect these
> two expressions to be equivalent:
>
> a < b < c
> (a < b) < c
>
> This is clearly not true. That's the inconsistency here with the rest of
> the language.

No, comparison operators are different from arithmetic operators in that
they always evaluate to a boolean. There are only rare cases where it
makes sense to compare comparisons.

> As soon as you read it as a ternary operator, the two comparisons are
> logically simultaneous.

There is no ternary operator, you can chain as many as you want, using
whatever operators:

  if a <= b < c > d >= e:
      ...

Once you view this as a conjonction of conditions, you find back the
semantics of "and": short-circuit, left to right evaluation. I find this
consistent.

-- Alain.

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

#24712

Thomas Jollans <t@jollybox.de> writes:

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

What norm gives you that expectation? That's not how those operators
work in mathematical notation. I know of no programming language that
would give a newcomer to Python that expectation. So where is the norm
you're referring to?

The operator symbols are not chosen arbitrarily for Python; they are, in
the case of ‘<’ and ‘>’, chosen because of semantic meaning those
symbols already have. That's the norm informing this meaning, and I
think it negates the point you're making.

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

There is inconsistency already in the symbols people see and the
semantics already associated with those symbols. Expecting that any
symbol, before Python defines it, will be devoid of any normal meaning
is a delusion.

-- 
 \     “The Vatican is not a state.… a state must have territory. This |
  `\         is a palace with gardens, about as big as an average golf |
_o__)                         course.” —Geoffrey Robertson, 2010-09-18 |
Ben Finney

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

#24713

On Sun, Jul 1, 2012 at 10:08 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
> Thomas Jollans <t@jollybox.de> writes:
>
>> My sole point, really, is that "normally", one would expect these two
>> expressions to be equivalent:
>>
>> a < b < c
>> (a < b) < c
>
> What norm gives you that expectation? That's not how those operators
> work in mathematical notation. I know of no programming language that
> would give a newcomer to Python that expectation. So where is the norm
> you're referring to?

C, SQL, REXX, and many other languages.

ChrisA

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

#24717

On Sun, 01 Jul 2012 10:37:05 +1000, Chris Angelico wrote:

> On Sun, Jul 1, 2012 at 10:08 AM, Ben Finney <ben+python@benfinney.id.au>
> wrote:
>> Thomas Jollans <t@jollybox.de> writes:
>>
>>> My sole point, really, is that "normally", one would expect these two
>>> expressions to be equivalent:
>>>
>>> a < b < c
>>> (a < b) < c
>>
>> What norm gives you that expectation? That's not how those operators
>> work in mathematical notation. I know of no programming language that
>> would give a newcomer to Python that expectation. So where is the norm
>> you're referring to?
> 
> C, SQL, REXX, and many other languages.

All the worse for those languages, since they violate the semantics of 
mathematical notation.

The more I learn about C, the less I want to know about C. What sort of 
crazy language designer thought that having

2 == 2 == 2

return 0 (false) was a good idea? At least Pascal gives an error, since 
you can't compare bools with longints, and forces you to write:

(2 = 2) and (2 = 2)

Sheer craziness for C to abuse mathematical notation like that. But what 
is one to expect from a language where

(unsigned)-1 == -1

apparently is true.

http://nitoprograms.blogspot.com.au/2011/05/signed-and-unsigned-
comparisons-in-c-c.html


-- 
Steven

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

#24718

On Sun, Jul 1, 2012 at 1:23 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> All the worse for those languages, since they violate the semantics of
> mathematical notation.

Not so. It simply means that booleans are nothing special. In REXX,
there are no data types at all, and "1" and "0" are your booleans. In
C, boolean and comparison operations return integers, either 1 or 0.
Same was true of Python early on, if I understand correctly. It's not
shameful.

> The more I learn about C, the less I want to know about C. What sort of
> crazy language designer thought that having
>
> 2 == 2 == 2
>
> return 0 (false) was a good idea?

It makes perfect sense though; your comparisons simply return
integers, so you can legally index using them. A simple binary tree
can work thus:

node child[2];

next_node = child[search_value>current_value];

> Sheer craziness for C to abuse mathematical notation like that. But what
> is one to expect from a language where
>
> (unsigned)-1 == -1
>
> apparently is true.

Of course it's true. When you compare an unsigned value to a signed
one, the signed value is automatically up-cast to unsigned, in the
same way that comparing 32-bit and 64-bit integers will do. So
whatever rule the compiler uses to cast your first -1 to unsigned will
be used to cast the second to unsigned, and they'll be equal.

As to "2 == 2 == 2": I don't see it as a problem that:

x = (2 == 2)
y = (x == 2)
z = (2 == 2 == 2)

leave y and z as the same. There are different ways of interpreting
the z statement, but having it identical to y is certainly a plausible
one.

ChrisA

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

#24728

On Sun, 01 Jul 2012 13:48:04 +1000, Chris Angelico wrote:

> On Sun, Jul 1, 2012 at 1:23 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> All the worse for those languages, since they violate the semantics of
>> mathematical notation.
> 
> Not so. It simply means that booleans are nothing special. In REXX,
> there are no data types at all, and "1" and "0" are your booleans. In C,
> boolean and comparison operations return integers, either 1 or 0. 

This has nothing to do with the presence of a Boolean type or not. It is 
about syntax, not types.

Python didn't have bools until relatively recently but it still had 
chained comparisons. In Python2.1 and older, boolean and comparison 
operations return integers, either 1 or 0, precisely the same as C.

You can even use chained comparisons for types that don't interpret the 
operators as comparisons:

py> class Funny:
...     def __init__(self, x):
...             self.x = x
...     def __lt__(self, other):
...             return Funny(self.x + 3*other.x)
...     def __str__(self):
...             return str(self.x)
...
py> a = Funny(2)
py> b = Funny(3)
py> c = Funny(4)
py>
py> print a < b < c
15
py> print (a < b) and (b < c)
15

Although the interpretation of such may not be useful.



> Same
> was true of Python early on, if I understand correctly. It's not
> shameful.

The first public release of Python, 0.9, included chained comparisons. 
This was even before the language had == for equality tests!

steve@runes:~$ ./python0.9.1
>>> print 2 < 3 < 4
1
>>> print 2 = 2 = 2
1
>>> print (2 = 2) = 2
0


So no, Python has always included chained comparisons, and yes, it is 
shameful that a language would force you to unlearn standard notation in 
favour of a foolish consistency with other operators. Comparisons aren't 
special because they return bools. They are special because of the way 
they are used.

C treats comparison operators as if they were arithmetic operators, and 
so the behaviour of a chained comparison is the same as the behaviour as 
a sequence of arithmetic operators: a foolish consistency. Python treats 
comparison operators as comparison operators, and gives them behaviour 
appropriate to comparisons.

The fact that so many languages do the wrong thing here, and so few 
emulate standard mathematical notation, is symptomatic of the lousy state 
of language design.

Pascal might be verbose, but at least it makes it harder to write code 
that silently does the wrong thing -- it prevents you from writing 
chained comparisons which do the wrong thing, and forces you to be 
explicit. C has the worst of both worlds:

- it allows the standard concise mathematical notation a < x < b
- but it quietly changes the semantics to something that the user 
  hardly ever wants

thus giving the maximum number of bugs with the minimum amount of 
convenience.


>> The more I learn about C, the less I want to know about C. What sort of
>> crazy language designer thought that having
>>
>> 2 == 2 == 2
>>
>> return 0 (false) was a good idea?
> 
> It makes perfect sense though; 

Not in English-speaking countries with a culture of writing chained 
comparisons in mathematics and allowing them in natural language:

"Rock is beaten by Paper, is beaten by Scissors".



-- 
Steven

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

#24730

On Sun, Jul 1, 2012 at 4:54 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Not in English-speaking countries with a culture of writing chained
> comparisons in mathematics and allowing them in natural language:
>
> "Rock is beaten by Paper, is beaten by Scissors".

I would write that as:

Rock is beaten by Paper, and beats Scissors.

That's natural language. Unless you put a "which" in the middle, the
grammar of English demands that the subject be common, not a promoted
object.

ChrisA

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

#24739

On 7/1/2012 2:54 AM, Steven D'Aprano wrote:

> So no, Python has always included chained comparisons, and yes, it is
> shameful that a language would force you to unlearn standard notation in
> favour of a foolish consistency with other operators. Comparisons aren't
> special because they return bools. They are special because of the way
> they are used.
>
> C treats comparison operators as if they were arithmetic operators, and
> so the behaviour of a chained comparison is the same as the behaviour as
> a sequence of arithmetic operators: a foolish consistency. Python treats
> comparison operators as comparison operators, and gives them behaviour
> appropriate to comparisons.

I considered this a great feature of Python when I first learned it. 
Reading about how rare it is among programming languages to treat 
comparisons in the standard way in mathematics reinforces that.

-- 
Terry Jan Reedy

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

#24755

On Sun, 01 Jul 2012 05:55:24 -0400, Terry Reedy wrote:

> On 7/1/2012 2:54 AM, Steven D'Aprano wrote:
> 
>> So no, Python has always included chained comparisons, and yes, it is
>> shameful that a language would force you to unlearn standard notation
>> in favour of a foolish consistency with other operators. Comparisons
>> aren't special because they return bools. They are special because of
>> the way they are used.
>>
>> C treats comparison operators as if they were arithmetic operators, and
>> so the behaviour of a chained comparison is the same as the behaviour
>> as a sequence of arithmetic operators: a foolish consistency. Python
>> treats comparison operators as comparison operators, and gives them
>> behaviour appropriate to comparisons.
> 
> I considered this a great feature of Python when I first learned it.
> Reading about how rare it is among programming languages to treat
> comparisons in the standard way in mathematics reinforces that.

Apart from Python, Mathematica, Perl 6, CoffeeScript, Cobra and Clay give 
chained comparisons the standard meaning. It is, or was, a feature 
request for Boo, but I can't tell whether it has been implemented or not.


C-like semantics are next to useless, except perhaps for obfuscation:

http://stackoverflow.com/questions/4089284/why-does-0-5-3-return-true/

And surprising:

http://answers.yahoo.com/question/index?qid=20090923172909AA4O9Hx

C-like semantics are a clear case of purity of implementation overruling 
functional usefulness.

-- 
Steven

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

#25260

In article <4ff0f8e0$0$29988$c3e8da3$5496439d@news.astraweb.com>,
Steven D'Aprano  <steve+comp.lang.python@pearwood.info> wrote:
>On Sun, 01 Jul 2012 05:55:24 -0400, Terry Reedy wrote:
>
>> On 7/1/2012 2:54 AM, Steven D'Aprano wrote:
>>
>>> So no, Python has always included chained comparisons, and yes, it is
>>> shameful that a language would force you to unlearn standard notation
>>> in favour of a foolish consistency with other operators. Comparisons
>>> aren't special because they return bools. They are special because of
>>> the way they are used.
>>>
>>> C treats comparison operators as if they were arithmetic operators, and
>>> so the behaviour of a chained comparison is the same as the behaviour
>>> as a sequence of arithmetic operators: a foolish consistency. Python
>>> treats comparison operators as comparison operators, and gives them
>>> behaviour appropriate to comparisons.
>>
>> I considered this a great feature of Python when I first learned it.
>> Reading about how rare it is among programming languages to treat
>> comparisons in the standard way in mathematics reinforces that.
>
>Apart from Python, Mathematica, Perl 6, CoffeeScript, Cobra and Clay give
>chained comparisons the standard meaning. It is, or was, a feature
>request for Boo, but I can't tell whether it has been implemented or not.

Algol 68 does not. It has promoted operator symbols to first
class citizens. In that context chained comparison operators
cannot be made to work.
Both Mathematica and Perl are ad-hoc-ish languages. I would
hate Python go that way.

From now on, for each operator I would have to remember wether it
is a supposedly comparison operator or not.

Comparison operations on booleans make sense.
I remember a FORTRAN compiler complaining about me
comparing LOGICALS. The lack of abstraction!

>
>
>C-like semantics are next to useless, except perhaps for obfuscation:
>
>http://stackoverflow.com/questions/4089284/why-does-0-5-3-return-true/
>
>And surprising:
>
>http://answers.yahoo.com/question/index?qid=20090923172909AA4O9Hx
>
>C-like semantics are a clear case of purity of implementation overruling
>functional usefulness.

The worst of is, of course, = for assignment instead of := .
This is a convention that Python follows, to my dismay.

>
>--
>Steven

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#25265

On Fri, 13 Jul 2012 12:30:47 +0000, Albert van der Horst wrote:

>>Apart from Python, Mathematica, Perl 6, CoffeeScript, Cobra and Clay
>>give chained comparisons the standard meaning. It is, or was, a feature
>>request for Boo, but I can't tell whether it has been implemented or
>>not.
> 
> Algol 68 does not. It has promoted operator symbols to first class
> citizens. In that context chained comparison operators cannot be made to
> work.
> Both Mathematica and Perl are ad-hoc-ish languages. I would hate Python
> go that way.

Perl 5 does not have chained comparisons. Perl 6, which is more designed 
and less ad-hoc, does.

> From now on, for each operator I would have to remember wether it is a
> supposedly comparison operator or not.

Are you often in the habit of using operators *without* remembering what 
they do? <wink>

I can't speak for you, but it isn't often that I've found myself not 
remembering whether the less-than operator <  means "compare two values" 
or "multiply two values".


> Comparison operations on booleans make sense.

Actually, no. Is True less than False, or is it greater? In boolean 
algebra, the question has no answer. It is only an implementation detail 
of Python that chooses False < True.

Of course, equality and inequality make sense for all values. But the 
other comparison operators, < <= >= > only make sense for values which 
are ordered, like real numbers (but not complex numbers), strings, and 
similar, or for set comparisons (subset and superset). Arbitrary types 
may not define comparison operators.


> I remember a FORTRAN
> compiler complaining about me comparing LOGICALS. The lack of
> abstraction!

The opposite: LOGICALS are abstract values which do not define greater 
than or less than.

> The worst of is, of course, = for assignment instead of := . This is a
> convention that Python follows, to my dismay.

*shrug*

The worst is to use = for both equality and assignment, like some BASICs. 
At least Python does not allow assignment as an expression, so you can't 
make the typical C error of:

if x = y: do_something()  # oops meant x == y



-- 
Steven

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

#25266

On Sat, Jul 14, 2012 at 1:04 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Actually, no. Is True less than False, or is it greater? In boolean
> algebra, the question has no answer. It is only an implementation detail
> of Python that chooses False < True.

Maybe in boolean algebra, but in code, it's handy to have sortable
bools. In SQL, for instance, I can use a boolean in an ORDER BY,
perhaps followed by another criterion, and it's effectively sorting by
"1 if some_boolean else 0" or in C notation "some_boolean ? 0 : 1"

ChrisA

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

#25270

On Jul 13, 8:36 pm, Chris Angelico <ros...@gmail.com> wrote:
> On Sat, Jul 14, 2012 at 1:04 AM, Steven D'Aprano
>
> <steve+comp.lang.pyt...@pearwood.info> wrote:
> > Actually, no. Is True less than False, or is it greater? In boolean
> > algebra, the question has no answer. It is only an implementation detail
> > of Python that chooses False < True.
>
> Maybe in boolean algebra, but in code, it's handy to have sortable
> bools. In SQL, for instance, I can use a boolean in an ORDER BY,
> perhaps followed by another criterion, and it's effectively sorting by
> "1 if some_boolean else 0" or in C notation "some_boolean ? 0 : 1"
>
> ChrisA

Actually a boolean algebra is a lattice with some additional
properties
A lattice is a poset (partially ordered set) with suprema and infimas
And so there is one natural order relation on any boolean algebra
which may be defined as
a ≤ b iff a ⋀ b = a

tl;dr version: In a boolean algebra, False is bottom and True is top

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

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

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

csiph-web