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

#25291

On 13 Jul 2012 15:04:21 GMT, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> declaimed the following in
gmane.comp.python.general:

> 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.
>
	And for the real fun... VMS F77 (if not the VAX/Alpha architecture
itself) basically used lsb making 1, 3, 5... True; and 0, 2, 4... False
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#25405

Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> On Fri, 13 Jul 2012 12:30:47 +0000, Albert van der Horst wrote:
>> 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
> 
Technically of course Python doesn't have assignment, it just binds names.

Albert raised the subject of Algol 68 which if I remember correctly used := 
for assignment and = to bind names (although unlike Python you couldn't 
then re-bind the name to another object in the same scope).


-- 
Duncan Booth http://kupuguy.blogspot.com

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

#25408

Duncan Booth <duncan.booth@invalid.invalid> writes:

> Technically of course Python doesn't have assignment, it just binds
> names.

Names, or other references.

I'd argue that Python has assignment, and assignment in Python is
identical with binding references to objects.

But then, the Python documentation refers to “variables” as though they
exist in Python, which I'd argue they don't. It's all very confusing :-)

-- 
 \         “Religious faith is the one species of human ignorance that |
  `\     will not admit of even the *possibility* of correction.” —Sam |
_o__)                                 Harris, _The End of Faith_, 2004 |
Ben Finney

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

#25482

In article <XnsA0927750022F4duncanbooth@127.0.0.1>,
Duncan Booth  <duncan.booth@suttoncourtenay.org.uk> wrote:
>Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
>
>> On Fri, 13 Jul 2012 12:30:47 +0000, Albert van der Horst wrote:
>>> 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
>>
>Technically of course Python doesn't have assignment, it just binds names.
>
>Albert raised the subject of Algol 68 which if I remember correctly used :=
>for assignment and = to bind names (although unlike Python you couldn't
>then re-bind the name to another object in the same scope).

Algol 68 is very particular about this indeed.
For instance they have a whole theory behind
real x;
x := 17.;

This is considered an abbreviation of
ref real x = loc real;
x:= 17;

So x is a reference bound to a freshly generated local real.
You see = and that means you can't ever break that relationship.
On the left side of a := it is required to have a ref something.
Because that generates a pretty clear context, you have considerable
leeway on the right side, that is cast into the something.

real x= 18.;
x := 15.;
is right out.

If you want to rebind something you need a ref which is really
a ref ref. Then you can only switch bindings between different
types. So it is totally different from Python.

I never thought about = in python to mean binding to set it
apart from the Pascal := , instead of being a c-ism.

Still my mathematical mind is bothered about the sequence
( legal in FORTRAN , C Python )
   X = 1   <separator>
   X = 2

Groetjes Albert

>--
>Duncan Booth http://kupuguy.blogspot.com

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]

#25296

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

I believe the following rule is true: if a op b is True or False raises, 
then op is a potentially chained comparison operation. They are (not) 
equal (and (not) is), the 4 order comparisons, and (not) in. 'in' should 
be the only surprise and most confusing.
 >>> 1 < 3 in {3,4}
True
 >>> 3 in {3,4} < {4}
False

'and' and 'or' are not included because they do not always return a 
bool, and indeed, they are not binary operators in the usual sense 
because of short-circuiting.

-- 
Terry Jan Reedy

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

#25308

On Fri, Jul 13, 2012 at 5:09 PM, Terry Reedy <tjreedy@udel.edu> wrote:
>
>> From now on, for each operator I would have to remember wether it
>> is a supposedly comparison operator or not.
>
>
> I believe the following rule is true: if a op b is True or False raises,

I don't follow.  Raises what?

> then op is a potentially chained comparison operation. They are (not) equal
> (and (not) is), the 4 order comparisons, and (not) in. 'in' should be the
> only surprise and most confusing.
>>>> 1 < 3 in {3,4}
> True
>>>> 3 in {3,4} < {4}
> False
>
> 'and' and 'or' are not included because they do not always return a bool,
> and indeed, they are not binary operators in the usual sense because of
> short-circuiting.

The only one of those operators that can be said to always return a
bool is "is (not)".  The others (apart from "and" and "or") all can be
overloaded to return anything you want (for example, sqlalchemy
overloads them to return expression objects that are later compiled
into SQL), and chaining still occurs regardless of the types they are
applied to.

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

#25320

On 7/14/2012 5:26 AM, Ian Kelly wrote:
> On Fri, Jul 13, 2012 at 5:09 PM, Terry Reedy <tjreedy@udel.edu> wrote:

>> I believe the following rule is true: if a op b is True or False raises,

Sorry, left out 'or' in 'or raises'
>
> I don't follow.  Raises what?

an Exception.

>> then op is a potentially chained comparison operation. They are (not) equal
>> (and (not) is), the 4 order comparisons, and (not) in. 'in' should be the
>> only surprise and most confusing.
>>>>> 1 < 3 in {3,4}
>> True
>>>>> 3 in {3,4} < {4}
>> False
>>
>> 'and' and 'or' are not included because they do not always return a bool,
>> and indeed, they are not binary operators in the usual sense because of
>> short-circuiting.
>
> The only one of those operators that can be said to always return a
> bool is "is (not)".  The others (apart from "and" and "or") all can be
> overloaded to return anything you want

OK, add 'by default, without over-rides ;-).
or 'for builtin classes'.

Python's flexibility makes it really hard to make any general statement. 
In my book-in-progress, I am currently resorting to saying "In Python*, 
..." whenever I know and remember that it is possibly to over-ride the 
customary behavior described in '...'.

-- 
Terry Jan Reedy

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

#24719

On Jul 1, 8:23 am, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Sun, 01 Jul 2012 10:37:05 +1000, Chris Angelico wrote:
> > On Sun, Jul 1, 2012 at 10:08 AM, Ben Finney <ben+pyt...@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?

Kernighan and Ritchie admit they made a design mistake with their
operator precedences:

http://en.wikipedia.org/wiki/C_%28programming_language%29#Criticism

That those mistakes are repeated and replicated is more unfortunate.
The second bullet above to be read along with
http://en.wikipedia.org/wiki/Assignment_%28computer_science%29#Assignment_versus_equality

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

#24721

On Sun, Jul 1, 2012 at 2:07 PM, rusi <rustompmody@gmail.com> wrote:
> Kernighan and Ritchie admit they made a design mistake with their
> operator precedences:
>
> http://en.wikipedia.org/wiki/C_%28programming_language%29#Criticism
>

The examples given there have nothing to do with the chaining of
comparisons and how it's to be interpreted. Yes, "x & 1 == 0" is
evaluated oddly. Doesn't affect "x == 1 == y".

Python's interpretation is more algebraic than C's. That doesn't mean
that C is wrong and Python is right, nor does it mean the converse.

ChrisA

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

#24732

Chris Angelico <rosuav@gmail.com> writes:

> 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.

So, languages without strong typing then. In that case, I revise my
statement: I know of no programming language with strong typing that
would give a newcomer to Python the above expectation.

Since Python does have strong typing, norms about operations from
weakly-typed languages should not be expected to apply.

(Incidentally, PostgreSQL was the SQL implementation I went to, and::

    postgres=# SELECT (1 < 2) < 3;
    ERROR:  operator does not exist: boolean < integer
    LINE 1: SELECT (1 < 2) < 3;
                           ^
    HINT:  No operator matches the given name and argument type(s). You might need to add explicit type casts.

So not all SQL implementations make the mistake of weak typing.)

-- 
 \     “Try adding “as long as you don't breach the terms of service – |
  `\          according to our sole judgement” to the end of any cloud |
_o__)                      computing pitch.” —Simon Phipps, 2010-12-11 |
Ben Finney

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

#24734

On 07/01/2012 09:28 AM, Ben Finney wrote:
> Chris Angelico <rosuav@gmail.com> writes:
> 
>> 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.
> 
> So, languages without strong typing then. In that case, I revise my
> statement: I know of no programming language with strong typing that
> would give a newcomer to Python the above expectation.
> 
> Since Python does have strong typing, norms about operations from
> weakly-typed languages should not be expected to apply.
> 
> (Incidentally, PostgreSQL was the SQL implementation I went to, and::
> 
>     postgres=# SELECT (1 < 2) < 3;
>     ERROR:  operator does not exist: boolean < integer
>     LINE 1: SELECT (1 < 2) < 3;
>                            ^
>     HINT:  No operator matches the given name and argument type(s). You might need to add explicit type casts.
> 
> So not all SQL implementations make the mistake of weak typing.)

I don't have PostgeSQL handy just now - what is the result of
(1 < 2 < 3) ? I bet it's the same error, which means the two are still
equivalent.

Look through the part of this thread about languages, and you will see
how unique Python is in this regard. You argument about strong typing
doesn't really hold: in Python, as in some other languages, bool is an
integer type, so it can actually be compared to numbers, so even if
Python used the same rules as Java, chaining comparison operators would
still be valid syntax (if a little silly in most cases)

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

#24752

On Sun, 01 Jul 2012 09:46:56 +0200, Thomas Jollans wrote:

> I don't have PostgeSQL handy just now - what is the result of (1 < 2 <
> 3) ? I bet it's the same error, which means the two are still
> equivalent.

$ psql misc

psql (9.1.4)

Type "help" for help.

misc=# select (1 < 2);

 ?column? 

----------

 t

(1 row)

misc=# select (1 < 2 < 3);

ERROR:  syntax error at or near "<"

LINE 1: select (1 < 2 < 3);
                      ^
misc=#

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

#24736

On Sun, Jul 1, 2012 at 3:28 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
> Chris Angelico <rosuav@gmail.com> writes:
>> C, SQL, REXX, and many other languages.
>
> So, languages without strong typing then. In that case, I revise my
> statement: I know of no programming language with strong typing that
> would give a newcomer to Python the above expectation.

OCaml is a language with absurdly strong typing, where a < b < c is
equivalent to (a < b) < c.

Obviously, this only works if c is a boolean, and if a and b are the
same type. Otherwise it is a type error.

Also, you claimed earlier that the notion of associative "<" is not
founded in mathematical notation. It really depends on whose
mathematical notation you use -- there's more than one, you know. For
example, it's reasonable to expect < to be left- or right-associative
in a system like Rick Hehner's Unified Algebra:
http://www.cs.toronto.edu/~hehner/UA.pdf (although, he himself doesn't
specify it as being one or the other, so by default one would assume
'a < b < c' to be nonsensical.)

-- Devin

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

#24753

On Sun, 01 Jul 2012 05:18:09 -0400, Devin Jeanpierre wrote:

> Also, you claimed earlier that the notion of associative "<" is not
> founded in mathematical notation. It really depends on whose
> mathematical notation you use -- there's more than one, you know. For
> example, it's reasonable to expect < to be left- or right-associative in
> a system like Rick Hehner's Unified Algebra:
> http://www.cs.toronto.edu/~hehner/UA.pdf (although, he himself doesn't
> specify it as being one or the other, so by default one would assume 'a
> < b < c' to be nonsensical.)

Sheesh guys. Don't go hunting through the most obscure corners of 
mathematics for examples of computer scientists who have invented their 
own maths notation. (Which, by your own admission, is under-specified and 
therefore incomplete.) Who uses Hehner's "Unified Algebra" notation? 
Apart from Hehner, if he even uses it himself.

Pick up any standard maths book and you will see chained comparisons used 
with exactly the meaning that Python gives them.

For example, Wolfram MathWorld uses it:

http://mathworld.wolfram.com/Inequality.html


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.



-- 
Steven

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

#24758

On Sun, Jul 1, 2012 at 8:41 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Sun, 01 Jul 2012 05:18:09 -0400, Devin Jeanpierre wrote:
> Sheesh guys. Don't go hunting through the most obscure corners of
> mathematics for examples of computer scientists who have invented their
> own maths notation. (Which, by your own admission, is under-specified and
> therefore incomplete.) Who uses Hehner's "Unified Algebra" notation?
> Apart from Hehner, if he even uses it himself.

I didn't hunt, I was taught it in university.

-- Devin

(Of course, it shouldn't be hard to guess who the professor was :)

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

#24745

On Sun, 01 Jul 2012 17:28:20 +1000, Ben Finney
<ben+python@benfinney.id.au> declaimed the following in
gmane.comp.python.general:


> So, languages without strong typing then. In that case, I revise my
> statement: I know of no programming language with strong typing that
> would give a newcomer to Python the above expectation.
>
	I'd think a true newcomer (to programming) would have NO
expectations... And if they'd had any complex math classes may actually
consider 
		if 1 < x < 10:
to be the norm (though it should be less-than-or-equal to map to the
normally inclusive endpoints in "pick a number between 1 and 10")

-=-=-=-
Assignment: Conditionals and Looping

	The program shall play "Guess the Number" with the user.
	The program shall generate an random integer between 1 and 10
(including 1 and 10 in the range).
	The program shall loop asking the user for a guess.
	The program shall reject non-integer input.
	The program shall reject integers outside the range of 1 to 10.
	The program shall maintain a score (count) of incorrect guesses.
	The program shall display the score and exit when the user's guess
matches the randomly generated integer.
-=-=-=-


	In contrast to this total neophyte, someone transferring from
another language should have enough experience to at least browse the
language reference and tutorial -- especially after encountering the
simple fact that Python requires indentation to denote blocks! Something
not seen in any other language and which should trigger the thought
"what else is different?"

	At least the Python reference is only around 100 pages (last time I
printed it) in contrast to the 800 page Ada 2005 (okay, the appendices
should be counted as equivalent to the Python standard library
reference; that still leaves over three times as many pages for Ada
reference, and the print is much finer)


 
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#24763

On Sun, 01 Jul 2012 13:41:20 -0400
Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:


> 	I'd think a true newcomer (to programming) would have NO
> expectations... And if they'd had any complex math classes may actually
> consider 
> 		if 1 < x < 10:
> to be the norm 
[...]

+1

I've only ever known Python (well, I've almost forgotten Bash), and when I
first needed a range test, I guessed at the above form and was pleasantly
surprised that it worked: it seemed too good to be true that Python was smart
enough to know I wanted the same "x" to be an operand in two comparisons at
once.

John

P.S. I know I'm not helping, but I'm starting to feel sorry for the guy who
wanted his code reviewed!

John

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

#24723

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

On 6/30/2012 19:37, Chris Angelico wrote:
> On Sun, Jul 1, 2012 at 10:08 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
>> 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.

Some others: Lua, Javascript, Ruby, O'Caml.

In fact, the only language I can find that uses infix notation (i.e. no
Lisp) where it's *not* true that "a < b < c" is equivalent to "(a < b) <
c" is Haskell -- and that's because < is not associative and "a < b < c"
is a syntax error. (FWIW this is my favorite approach.) 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've been programming in Python for a few years and this is the first
time I've seen this. If I had seen that in a program, I'd have assumed
it was a bug.

Evan

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

#24729

Evan Driscoll wrote:

> On 6/30/2012 19:37, Chris Angelico wrote:
>> On Sun, Jul 1, 2012 at 10:08 AM, Ben Finney <ben+python@benfinney.id.au>
>> wrote:
>>> 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.
> 
> Some others: Lua, Javascript, Ruby, O'Caml.

JFTR: Contrary to popular belief there is no programming language named 
"Javascript".  In your second point, you are talking about ECMAScript 
implementations; one of which is _JavaScript_, Netscape's and later 
Mozilla.org's ECMAScript implementation.  Other implementations include that 
of Microsoft, JScript.

<http://PointedEars.de/es-matrix>

-- 
PointedEars

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

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

#24738

On Sat, 30 Jun 2012 23:45:25 -0500, Evan Driscoll wrote:

> On 6/30/2012 19:37, Chris Angelico wrote:
>> On Sun, Jul 1, 2012 at 10:08 AM, Ben Finney
>> <ben+python@benfinney.id.au> wrote:
>>> 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.
> 
> Some others: Lua, Javascript, Ruby, O'Caml.
> 
> In fact, the only language I can find that uses infix notation (i.e. no
> Lisp) where it's *not* true that "a < b < c" is equivalent to "(a < b) <
> c" is Haskell -- and that's because < is not associative and "a < b < c"
> is a syntax error. (FWIW this is my favorite approach.) 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've been programming in Python for a few years and this is the first
> time I've seen this. If I had seen that in a program, I'd have assumed
> it was a bug.
> 
> Evan

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.

I suppose I have the advantage that it is only the taint of BASIC (in the 
home computer era) that I have had to overcome and my programming style 
has not been unduly influenced by c & others.

it is easy to write C, or Pascal or even BASIC in python but why bother, 
why not just use C, Pascal or BASIC in that case?

-- 
I respect faith, but doubt is what gives you an education.
		-- Wilson Mizner

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

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

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

csiph-web