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

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

Re: allow line break at operators

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: allow line break at operators Yingjie Lan <lanyjie@yahoo.com> - 2011-08-09 23:05 -0700
    Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-10 18:32 +1000
      Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-10 09:39 +0100
      Re: allow line break at operators Dan Sommers <dan@tombstonezero.net> - 2011-08-10 09:56 +0000
        Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-11 00:44 +1000
      Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-10 11:26 +0100
        Re: allow line break at operators Duncan Booth <duncan.booth@invalid.invalid> - 2011-08-10 12:25 +0000
          Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-10 13:42 +0100
          Re: allow line break at operators Yingjie Lan <lanyjie@yahoo.com> - 2011-08-10 05:58 -0700
          Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-10 15:45 +0100
          Re: allow line break at operators Yingjie Lan <lanyjie@yahoo.com> - 2011-08-10 06:19 -0700
          Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-10 16:56 +0100
            Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-10 17:55 +0000
              Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-11 07:51 +1000
                Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-10 23:42 +0100
                  Re: allow line break at operators Neil Cerutti <neilc@norwich.edu> - 2011-08-11 14:40 +0000
                Re: Python & Sullivan Tim Chase <python.list@tim.thechases.com> - 2011-08-10 18:26 -0500
                  Re: Python & Sullivan Ben Finney <ben+python@benfinney.id.au> - 2011-08-11 10:57 +1000
                Re: Python & Sullivan Chris Angelico <rosuav@gmail.com> - 2011-08-11 00:54 +0100
                Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-11 04:59 +0000
                  Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-11 15:56 +1000
                    Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-11 21:19 +0000
                      Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-12 00:58 +0100
                        Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-12 11:40 +1000
                          Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-12 08:09 +0100
                          Re: allow line break at operators Neil Cerutti <neilc@norwich.edu> - 2011-08-12 12:57 +0000
                          Re: allow line break at operators Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-08-12 14:54 +0200
                          Re: allow line break at operators Tim Roberts <timr@probo.com> - 2011-08-14 22:22 -0700
                      Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-12 18:59 +1000
                        Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-12 20:40 +1000
                          Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-12 21:16 +1000
                        Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 16:33 +0000
                  Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-11 22:29 +1000
                    Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-11 22:40 +1000
                      Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-11 21:19 +0000
                    Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-11 21:19 +0000
                      Re: allow line break at operators Ethan Furman <ethan@stoneleaf.us> - 2011-08-11 15:43 -0700
                        Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 06:34 +0000
                          Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-12 08:20 +0100
                            Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-12 08:33 -0700
                              Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-12 20:52 +0100
                            Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 16:33 +0000
                          Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-12 20:39 +1000
                            Re: allow line break at operators Chris Rebert <clp2@rebertia.com> - 2011-08-12 10:03 -0700
                              Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 18:37 +0000
                            Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 16:33 +0000
                              Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-12 21:01 +0100
                                Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 21:06 +0000
                          Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-12 08:26 -0700
                            Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 16:33 +0000
                              Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-12 10:57 -0700
                                Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-12 21:09 +0100
                                  Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 21:06 +0000
                                    Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-13 08:39 +1000
                                      Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-12 23:50 +0100
                                        Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-13 09:19 +1000
                                      Re: allow line break at operators Tim Chase <python.list@tim.thechases.com> - 2011-08-12 18:53 -0500
                                      Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-13 00:39 +0000
                                        Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-13 10:57 +1000
                                          Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-13 02:34 +0000
                                        Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-13 18:50 -0700
                                        Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-13 19:07 -0700
                                        Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-13 18:59 -0700
                                        Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-14 17:10 +1000
                                          Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-14 08:07 +0000
                                            Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-14 19:25 +1000
                                            Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-15 00:26 +1000
                                              Re: allow line break at operators Roy Smith <roy@panix.com> - 2011-08-14 11:35 -0400
                                                Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-15 03:24 +1000
                                                Re: Re: allow line break at operators Dave Angel <davea@ieee.org> - 2011-08-14 17:46 -0400
                                                  Re: allow line break at operators Roy Smith <roy@panix.com> - 2011-08-14 18:46 -0400
                                                    Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-15 00:02 +0100
                                              Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-14 16:39 +0100
                                                Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-15 03:26 +1000
                                              Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-14 19:01 +0000
                                                Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-15 11:54 +1000
                                                  Re: allow line break at operators Chris Rebert <clp2@rebertia.com> - 2011-08-14 19:10 -0700
                                                    Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-15 04:28 +0000
                                                      Re: allow line break at operators Tim Chase <python.list@tim.thechases.com> - 2011-08-15 06:40 -0500
                                                      Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-15 23:30 +1000
                                                        Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-15 16:32 +0000
                                                        Re: allow line break at operators alex23 <wuwei23@gmail.com> - 2011-08-15 21:13 -0700
                                                          Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-15 21:37 -0700
                                                            Re: allow line break at operators alex23 <wuwei23@gmail.com> - 2011-08-15 23:49 -0700
                                                              Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-16 11:56 -0700
                                                  Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-15 04:28 +0000
                                                    Re: allow line break at operators Terry Reedy <tjreedy@udel.edu> - 2011-08-15 03:31 -0400
                                                      Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-15 14:21 -0700
                                                    Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-15 09:27 +0100
                                          Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-14 09:34 +0100
                                            Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-14 19:27 +1000
                                              Re: allow line break at operators Ethan Furman <ethan@stoneleaf.us> - 2011-08-14 03:51 -0700
                                              Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-14 12:59 +0100
                                            Re: allow line break at operators Teemu Likonen <tlikonen@iki.fi> - 2011-08-14 12:46 +0300
                                              Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-14 19:01 +0000
                                            Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-14 19:01 +0000
                                          Re: allow line break at operators Chris Rebert <clp2@rebertia.com> - 2011-08-14 01:44 -0700
                                            Re: allow line break at operators Teemu Likonen <tlikonen@iki.fi> - 2011-08-16 07:04 +0300
                                    Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-13 19:18 -0700
                                  Re: allow line break at operators Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-08-13 13:19 +1200
                                  Re: allow line break at operators Johann Hibschman <jhibschman+usenet@gmail.com> - 2011-08-15 08:27 -0500
                                  Re: allow line break at operators Roy Smith <roy@panix.com> - 2011-08-15 09:41 -0400
                                    Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-15 15:16 +0100
                                      Re: allow line break at operators Roy Smith <roy@panix.com> - 2011-08-15 20:34 -0400
                                        Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-16 01:37 +0100
                                    Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-16 00:28 +1000
                                      Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-15 15:42 +0100
                                      Re: allow line break at operators Roy Smith <roy@panix.com> - 2011-08-15 20:30 -0400
                                        Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-16 00:39 +0000
                                      Re: allow line break at operators Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-08-16 12:43 +1200
                                    Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-15 16:32 +0000
                                Re: allow line break at operators Ethan Furman <ethan@stoneleaf.us> - 2011-08-12 13:35 -0700
                                Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 21:06 +0000
                              Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-13 08:03 +1000
                                Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-12 22:14 +0000
                                  Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-13 08:36 +1000
                                  Re: allow line break at operators Terry Reedy <tjreedy@udel.edu> - 2011-08-12 20:15 -0400
                                    Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-13 00:44 +0000
                                Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-08-13 18:25 -0700
                              Re: allow line break at operators Ben Finney <ben+python@benfinney.id.au> - 2011-08-13 08:12 +1000
                              RE: allow line break at operators "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2011-08-16 15:51 -0400
                  RE: allow line break at operators "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2011-08-16 15:26 -0400
                    Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-16 20:19 +0000
                  Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-16 21:05 +0100
              Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-11 10:32 +1000
                Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-11 01:47 +0100
                Re: allow line break at operators Seebs <usenet-nospam@seebs.net> - 2011-08-11 04:59 +0000
          Re: allow line break at operators Yingjie Lan <lanyjie@yahoo.com> - 2011-08-10 19:52 -0700
            Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-11 14:18 +1000
              Re: allow line break at operators Chris Rebert <clp2@rebertia.com> - 2011-08-11 00:50 -0700
              Re: allow line break at operators Vito 'ZeD' De Tullio <zak.mc.kraken@libero.it> - 2011-08-11 12:21 +0200
          Re: allow line break at operators Yingjie Lan <lanyjie@yahoo.com> - 2011-08-10 19:58 -0700
          Re: allow line break at operators Chris Rebert <clp2@rebertia.com> - 2011-08-10 21:16 -0700
          Re: allow line break at operators Chris Rebert <clp2@rebertia.com> - 2011-08-10 22:07 -0700
          Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-11 09:24 +0100
          Re: allow line break at operators MRAB <python@mrabarnett.plus.com> - 2011-08-11 14:03 +0100
          Re: [Python-ideas] allow line break at operators Matt Joiner <anacrolix@gmail.com> - 2011-08-12 00:28 +1000
            Re: [Python-ideas] allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-12 12:32 +1000
          Re: [Python-ideas] allow line break at operators Jakob Bowyer <jkbbwr@gmail.com> - 2011-08-11 16:42 +0100
          Re: [Python-ideas] allow line break at operators Daniel Greenfeld <pydanny@gmail.com> - 2011-08-11 10:04 -0700
          Re: [Python-ideas] allow line break at operators Paul Colomiets <paul@colomiets.name> - 2011-08-11 22:17 +0300
          Re: [Python-ideas] allow line break at operators Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-08-11 17:06 -0400
          Re: [Python-ideas] allow line break at operators Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-08-11 17:29 -0400
          Re: [Python-ideas] allow line break at operators Jim Jewett <jimjjewett@gmail.com> - 2011-08-11 17:39 -0400
          Re: [Python-ideas] allow line break at operators Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-08-11 18:29 -0400
          Re: [Python-ideas] allow line break at operators Matt Joiner <anacrolix@gmail.com> - 2011-09-02 15:33 +1000
            Re: [Python-ideas] allow line break at operators Roy Smith <roy@panix.com> - 2011-09-03 12:59 -0400
          Re: [Python-ideas] allow line break at operators "Stephen J. Turnbull" <stephen@xemacs.org> - 2011-09-02 16:28 +0900
          Re: [Python-ideas] allow line break at operators Guido van Rossum <guido@python.org> - 2011-09-02 12:30 -0700
          Re: [Python-ideas] allow line break at operators "Stephen J. Turnbull" <stephen@xemacs.org> - 2011-09-03 13:38 +0900
          Re: [Python-ideas] allow line break at operators "Stephen J. Turnbull" <stephen@xemacs.org> - 2011-09-03 15:10 +0900
          Re: [Python-ideas] allow line break at operators Terry Reedy <tjreedy@udel.edu> - 2011-09-03 15:01 -0400
          Re: [Python-ideas] allow line break at operators ron3200 <ron3200@gmail.com> - 2011-09-04 10:22 -0500
            Re: allow line break at operators rantingrick <rantingrick@gmail.com> - 2011-09-04 11:08 -0700
        Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-11 00:37 +1000
          Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-10 16:13 +0100
          Re: allow line break at operators Ian Kelly <ian.g.kelly@gmail.com> - 2011-08-10 09:16 -0600
            Re: allow line break at operators Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-11 09:32 +1000
              Re: allow line break at operators Chris Angelico <rosuav@gmail.com> - 2011-08-11 00:55 +0100

Page 1 of 8  [1] 2 3 4 5 6 7 8  Next page →

#11094 — Re: allow line break at operators

On Tue, Aug 9, 2011 at 9:42 PM, Yingjie Lan <lanyjie@yahoo.com> wrote:

> Hi all,
>
> When writing a long expresion, one usually would like to break it into multiple lines. Currently, you may use a '\' to do so, but it looks a little awkward (more like machine-oriented thing). Therefore I start wondering why not allow line breaking at an operator, which is the standard way of breaking a long expression in publication? Here is an example:
>
> #the old way
>
> x = 1+2+3+4+\
>       1+2+3+4
>
> #the new way
> x = 1+2+3+4+ #line continues as it is clearly unfinished
>
>       1+2+3+4

:# the currently allowed way
:x = (1+2+3+4+
:    1+2+3+4)
:# note the parentheses
:
:I think this is sufficient.

That works, but not in the most natural way--the way people are customed to...why require a pair of parenthis when we can do without them? Also, the new way does not affect the old ways of doing things at all, it is fully backward compatible. So this just offers a new choice.

> Of course, the dot operator is also included, which may facilitate method chaining:
>
> x = svg.append( 'circle' ).
>       r(2).cx(1).xy(1).
>       foreground('black').bkground('white')

:Also, I dislike this for the dot operator especially, as it can
:obscure whether a method call or a function call is taking place.

Again, this only offers a new choice, and does not force anybody to do it this way.

cheers,

Yingjie

[toc] | [next] | [standalone]

#11102

On Wed, 10 Aug 2011 04:05 pm Yingjie Lan wrote:

> :# the currently allowed way
> :x = (1+2+3+4+
> :1+2+3+4)
> :# note the parentheses
> :
> :I think this is sufficient.
> 
> That works, but not in the most natural way--the way people are customed
> to...why require a pair of parenthis when we can do without them? 

Because it is better to be explicit that the line is still open. An opening
parenthesis or bracket that hasn't been closed is an explicit sign that the
line is still open. An operator is not.


> Also, 
> the new way does not affect the old ways of doing things at all, it is
> fully backward compatible. So this just offers a new choice.

You say that as if having more choices is always good. It isn't. More
choices means more for people to learn, more complicated parser, more
options to consider, and more likelihood that errors will fail to raise
SyntaxError and instead go on to silently do the wrong thing. A new choice
should only be accepted when there is a clear and obvious benefit, not
merely because it will provide more choice.

Python is a programming language, not an ice cream shop.


>> Of course, the dot operator is also included, which may facilitate method
>> chaining:
>>
>> x = svg.append( 'circle' ).
>> r(2).cx(1).xy(1).
>> foreground('black').bkground('white')

If you are chaining six dots like that, you are in gross violation of the
Law Of Demeter. That is poor code, and should be discouraged, not
encouraged.


> 
> :Also, I dislike this for the dot operator especially, as it can
> :obscure whether a method call or a function call is taking place.
> 
> Again, this only offers a new choice, and does not force anybody to do it
> this way.

But it does force people to read it, because some people will use it, and so
others will have to suffer for their poor judgement.



-- 
Steven

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

#11103

On Wed, Aug 10, 2011 at 9:32 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
>>> Of course, the dot operator is also included, which may facilitate method
>>> chaining:
>>>
>>> x = svg.append( 'circle' ).
>>> r(2).cx(1).xy(1).
>>> foreground('black').bkground('white')
>
> If you are chaining six dots like that, you are in gross violation of the
> Law Of Demeter. That is poor code, and should be discouraged, not
> encouraged.

I would only accept that this is poor code IF there is a viable
alternative, such as:

x = svg.append(circle(r=2,cx=1,xy=1,foreground='black',bkground='white'))

This would, imho, be a more Pythonic way to do it. But if this isn't
available, and if the methods already return self, then I see nothing
wrong with chaining. It's a handy way of getting additional mileage
out of lambdas and list comps when writing one-liners. :)

(Cue long thread about whether or not one-liners are Pythonic.)

Chris Angelico

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

#11106

On Wed, 10 Aug 2011 18:32:05 +1000, Steven D'Aprano wrote:

> Python is a programming language, not an ice cream shop.

+1 QOTW

How about a cheese shop?

In terms of easier to read, I find code easier to read when the operators 
are at the beginnings of the lines (PEP 8 notwithstanding):

    x = (someobject.somemethod(object3, thing)
         + longfunctionname(object2)
         + otherfunction(value1, value2, value3))

I can see the "+" signs a lot easier there than at the end of some line, 
where it might be buried between two longer lines:

    x = (someobject.somemethod(object3, thing) +
         longfunctionname(object2) +         
         otherfunction(value1, value2, value3))
-- 
Dan

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

#11130

Dan Sommers wrote:

> In terms of easier to read, I find code easier to read when the operators
> are at the beginnings of the lines (PEP 8 notwithstanding):
> 
>     x = (someobject.somemethod(object3, thing)
>          + longfunctionname(object2)
>          + otherfunction(value1, value2, value3))

Agreed.


-- 
Steven

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

#11108

On Wed, Aug 10, 2011 at 10:56 AM, Dan Sommers <dan@tombstonezero.net> wrote:
> In terms of easier to read, I find code easier to read when the operators
> are at the beginnings of the lines (PEP 8 notwithstanding):
>
>    x = (someobject.somemethod(object3, thing)
>         + longfunctionname(object2)
>         + otherfunction(value1, value2, value3))
>

Without the parentheses, this is legal but (probably) useless; it
applies the unary + operator to the return value of those functions.
Putting the + at the end of the previous line at least prevents that,
since most unary operators bind to the operand on the right; but
there's still the potential for ambiguity.

When line breaks are significant, they cannot be randomly inserted
inside expressions.

ChrisA

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

#11113

Chris Angelico <rosuav@gmail.com> wrote:

> On Wed, Aug 10, 2011 at 10:56 AM, Dan Sommers <dan@tombstonezero.net>
> wrote: 
>> In terms of easier to read, I find code easier to read when the
>> operators are at the beginnings of the lines (PEP 8 notwithstanding):
>>
>>    x = (someobject.somemethod(object3, thing)
>>         + longfunctionname(object2)
>>         + otherfunction(value1, value2, value3))
>>
> 
> Without the parentheses, this is legal but (probably) useless; it
> applies the unary + operator to the return value of those functions.

No, in some other languages it might be legal, but this is Python.
without the parentheses it is a syntax error.


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

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

#11116

On Wed, Aug 10, 2011 at 1:25 PM, Duncan Booth
<duncan.booth@invalid.invalid> wrote:
> Chris Angelico <rosuav@gmail.com> wrote:
>
>> On Wed, Aug 10, 2011 at 10:56 AM, Dan Sommers <dan@tombstonezero.net>
>> wrote:
>>> In terms of easier to read, I find code easier to read when the
>>> operators are at the beginnings of the lines (PEP 8 notwithstanding):
>>>
>>>    x = (someobject.somemethod(object3, thing)
>>>         + longfunctionname(object2)
>>>         + otherfunction(value1, value2, value3))
>>>
>>
>> Without the parentheses, this is legal but (probably) useless; it
>> applies the unary + operator to the return value of those functions.
>
> No, in some other languages it might be legal, but this is Python.
> without the parentheses it is a syntax error.

It would be parsed as three separate statements. The only reason it
would be a syntax error would be because of the indentation, which is
not what I'd call reliable; it happens to catch this case, because
assignment doesn't allow subsequent lines to be indented, but nothing
forces continuation lines to be indented.

x = (5
+4)

x = 5
+4

What we have is a strangeness that can arise when a programmer ignores
something that is often insignificant; spare parentheses usually don't
matter.

Another potential danger is the similarity with tuple creation:

x = (someobject.somemethod(object3, thing)
     + longfunctionname(object2)
     + otherfunction(value1, value2, value3),)

This is a tuple with one element. Not too bad with the + operator, but
imagine if everything's done with method chaining on . which results
in the , being nearly indistinguishable. Not an insurmountable
problem, but a potential risk.

ChrisA

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

#11117

> On Wed, Aug 10, 2011 at 10:56 AM, Dan Sommers <dan@tombstonezero.net>

> wrote: 
>> In terms of easier to read, I find code easier to read when the
>> operators are at the beginnings of the lines (PEP 8 notwithstanding):
>>
>>    x = (someobject.somemethod(object3, thing)
>>         + longfunctionname(object2)
>>         + otherfunction(value1, value2, value3))
>>
> 
> Without the parentheses, this is legal but (probably) useless; it
> applies the unary + operator to the return value of those functions.

:No, in some other languages it might be legal, but this is Python.
:without the parentheses it is a syntax error.

This discussion leads me to this question:

Is it possible for python to allow free splitting of single-line statements
without the backslashes, if we impose that expressions can only be split
when it is not yet a finished expression? Note: splitting before closing 
parenthis, brace, or bracket can be viewed as special case of this 
more general rule.


Yingjie

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

#11131

On Wed, Aug 10, 2011 at 1:58 PM, Yingjie Lan <lanyjie@yahoo.com> wrote:
> Is it possible for python to allow free splitting of single-line statements
> without the backslashes, if we impose that expressions can only be split
> when it is not yet a finished expression?

The trouble is that in a lot of cases, the next statement after an
unfinished expression could conceivably be a continuation of it. If
this were permitted, it would have to also require that the
continuation lines be indented, to avoid the problem described above.
It'd still have the potential to mis-diagnose errors, though.

ChrisA

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

#11137

>> In terms of easier to read, I find code easier to read when the

>> operators are at the beginnings of the lines (PEP 8 notwithstanding):
>>
>>    x = (someobject.somemethod(object3, thing)
>>         + longfunctionname(object2)
>>         + otherfunction(value1, value2, value3))
>>
> 
> Without the parentheses, this is legal but (probably) useless; it
> applies the unary + operator to the return value of those functions.

If ';' are employed (required), truely free line-splitting should be OK, 
the operators may appear at the beginnings of the lines as you wish.

Yingjie

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

#11138

On Wed, Aug 10, 2011 at 2:19 PM, Yingjie Lan <lanyjie@yahoo.com> wrote:
> If ';' are employed (required), truely free line-splitting should be OK,
> the operators may appear at the beginnings of the lines as you wish.
>

And if we require {} then truly free indentation should be OK too! But
it wouldn't be Python any more.

ChrisA

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

#11145

On 2011-08-10, Chris Angelico <rosuav@gmail.com> wrote:
> And if we require {} then truly free indentation should be OK too! But
> it wouldn't be Python any more.

Would it really not be Python at all?

I've seen bits of code in preprocessing-based "Python with {}" type things,
and they still look like Python to me, only they favor explicit over
implicit a little more strongly.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#11150

Seebs <usenet-nospam@seebs.net> writes:

> On 2011-08-10, Chris Angelico <rosuav@gmail.com> wrote:
> > And if we require {} then truly free indentation should be OK too!
> > But it wouldn't be Python any more.
>
> Would it really not be Python at all?

See the Python interpreter's response to ‘from __future__ import braces’.

> I've seen bits of code in preprocessing-based "Python with {}" type
> things, and they still look like Python to me, only they favor
> explicit over implicit a little more strongly.

They introduce unnecessary ambiguity: the indentation-as-structure and
braces-as-structure can then disagree.

In which case either the Python interpreter must guess the programmer's
intent (very un-Pythonic), or it throws an error and the programmer must
do busy-work to keep braces and indentation in agreement (also
un-Pythonic).

The ambiguity is resolved by having exactly one of indentation or braces
determining structure: Python uses indentation. In which case, braces
are pointless for indicating block structure.

-- 
 \            “Without cultural sanction, most or all of our religious |
  `\          beliefs and rituals would fall into the domain of mental |
_o__)                                 disturbance.” —John F. Schumaker |
Ben Finney

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

#11151

On Wed, Aug 10, 2011 at 10:51 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
> Seebs <usenet-nospam@seebs.net> writes:
>> I've seen bits of code in preprocessing-based "Python with {}" type
>> things, and they still look like Python to me, only they favor
>> explicit over implicit a little more strongly.
>
> They introduce unnecessary ambiguity: the indentation-as-structure and
> braces-as-structure can then disagree.
>
> The ambiguity is resolved by having exactly one of indentation or braces
> determining structure: Python uses indentation. In which case, braces
> are pointless for indicating block structure.

That's why it wouldn't be Python. It would have to use the braces and
not the indentation.

ChrisA
PS. I mistakenly sent this to a Gilbert & Sullivan group first. Oddly
enough, opera-goers are not used to discussing the relative merits of
braces vs indentation in code.

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

#11219

On 2011-08-10, Chris Angelico <rosuav@gmail.com> wrote:
> On Wed, Aug 10, 2011 at 10:51 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
>> Seebs <usenet-nospam@seebs.net> writes:
>>> I've seen bits of code in preprocessing-based "Python with {}" type
>>> things, and they still look like Python to me, only they favor
>>> explicit over implicit a little more strongly.
>>
>> They introduce unnecessary ambiguity: the indentation-as-structure and
>> braces-as-structure can then disagree.
>>
>> The ambiguity is resolved by having exactly one of indentation or braces
>> determining structure: Python uses indentation. In which case, braces
>> are pointless for indicating block structure.
>
> That's why it wouldn't be Python. It would have to use the braces and
> not the indentation.
>
> ChrisA
> PS. I mistakenly sent this to a Gilbert & Sullivan group first. Oddly
> enough, opera-goers are not used to discussing the relative merits of
> braces vs indentation in code.

Had I not become a lover of semantic indentation,
Wisely wielding willing whitespace in a wondrous preparation,
I could buttress blocks with braces, a la Kernighan and Ritchie,
(Other styles, just as valid, make me terri-bul-ly twitchy),
What I noticed was the whitespace hasn't shifted one iota,
With the braces superfluous in my wc -m quota,
When delineating code-blocks, with my keys a-clitter-clatter,
I prefer semantic whitespace 'cause the braces shouldn't matter.
No, the braces shouldn't matter,
(Matter, matter, matter, matter)
No, the braces shouldn't matter,
(Matter, matter, matter, matter)
When delineating code-clocks, with my keys a-clitter-clatter,
I prefer semantic whitespace 'cause the braces shouldn't matter.

-- 
Neil Cerutti

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

#11153 — Re: Python & Sullivan

On 08/10/2011 05:42 PM, Chris Angelico wrote:
> PS. I mistakenly sent this to a Gilbert&  Sullivan group
> first. Oddly enough, opera-goers are not used to discussing
> the relative merits of braces vs indentation in code.

It's only fair turnabout:

http://coding.derkeiler.com/Archive/Python/comp.lang.python/2006-09/msg01783.html

-tkc

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

#11162 — Re: Python & Sullivan

Tim Chase <python.list@tim.thechases.com> writes:

> On 08/10/2011 05:42 PM, Chris Angelico wrote:
> > PS. I mistakenly sent this to a Gilbert&  Sullivan group
> > first. Oddly enough, opera-goers are not used to discussing
> > the relative merits of braces vs indentation in code.
>
> It's only fair turnabout:
>
> http://coding.derkeiler.com/Archive/Python/comp.lang.python/2006-09/msg01783.html

Also of interest: Do a web search for “debian dueling banjos”.

Or read about the phenomenon at <URL:http://gumbaby.com/?p=64>.

-- 
 \        “The restriction of knowledge to an elite group destroys the |
  `\                   spirit of society and leads to its intellectual |
_o__)                                impoverishment.” —Albert Einstein |
Ben Finney

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

#11156 — Re: Python & Sullivan

On Thu, Aug 11, 2011 at 12:26 AM, Tim Chase
<python.list@tim.thechases.com> wrote:
> On 08/10/2011 05:42 PM, Chris Angelico wrote:
>>
>> PS. I mistakenly sent this to a Gilbert&  Sullivan group
>> first. Oddly enough, opera-goers are not used to discussing
>> the relative merits of braces vs indentation in code.
>
> It's only fair turnabout:
>
> http://coding.derkeiler.com/Archive/Python/comp.lang.python/2006-09/msg01783.html

Yes, I know about that one. My problem is that I snap off quick
responses to both lists, and sometimes type "sav" instead of "py" or
vice versa. Usually I catch it before hitting Send, though!!

On MUDs, we call that a mischannel. I've now mischanneled both directions. :|

ChrisA

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

#11184

On 2011-08-10, Ben Finney <ben+python@benfinney.id.au> wrote:
> Seebs <usenet-nospam@seebs.net> writes:
>> On 2011-08-10, Chris Angelico <rosuav@gmail.com> wrote:
>> > And if we require {} then truly free indentation should be OK too!
>> > But it wouldn't be Python any more.

>> Would it really not be Python at all?

> See the Python interpreter's response to ???from __future__ import braces???.

I'm aware of that.  I have seen all the counterarguments, and what I've
mostly become convinced of is this:

1.  Indentation as flow control was a bad idea.
2.  People are subconsciously aware of this.
3.  There is a HUGE degree of emotional investment in defending it.

The responses I have seen on this issue are highly emotional, full of insults,
full of blame-throwing, and utterly contrary to the basic engineering spirit
I usually see in programming communities.  In other languages, and even in
Python on any issue but this one, I regularly see people acknowledge
shortcomings and explain either why they think the tradeoffs are good, or why
they are willing to put up with it anyway.

The characteristic vehemence and hostility this issue produces are the surest
sign of people who have a desperate need not to acknowledge the elephant in
the room.

>> I've seen bits of code in preprocessing-based "Python with {}" type
>> things, and they still look like Python to me, only they favor
>> explicit over implicit a little more strongly.

> They introduce unnecessary ambiguity: the indentation-as-structure and
> braces-as-structure can then disagree.

Yes, they can.

> In which case either the Python interpreter must guess the programmer's
> intent (very un-Pythonic), or it throws an error and the programmer must
> do busy-work to keep braces and indentation in agreement (also
> un-Pythonic).

The obvious answer would be:

* Braces win because they are explicit rather than implicit.
* Everyone would use things configured to throw a warning or error.

The thing is...  This whole argument rests on the assumption that if there
are no braces, there is only one set of things, but if you have braces,
there are two.

This is untrue.

If there are no braces, there are two things describing flow control;
indentation and programmer intent.  With braces, there's three.

The most common misalignment is between the code as interpreted by the
computer and the programmer's intent.  Neither system prevents this, but
that's where all the real hassle comes from.

My expectation would be that the only times braces and indentation
would be "ambiguous" would be cases where the indentation got screwed up.

In these cases, I would MUCH prefer to get a fatal error than to have
things run in a way entirely unrelated to the intent I had when I wrote
the code.

> The ambiguity is resolved by having exactly one of indentation or braces
> determining structure: Python uses indentation. In which case, braces
> are pointless for indicating block structure.

I don't think so, any more than I think parentheses which happen to align
with the existing precendence rules are pointless.

In the real world, we are confronted constantly with tools which work
perfectly with every programming language but Python or very old FORTRAN,
but which mangle Python code sporadically and inexplicably.  Mail servers
chew up whitespace like there's no tomorrow.  Web pages find innovative new
explanations for why those leading spaces don't need to be displayed.

I like Python a lot in some ways, but I am really sick of the insistance that
this godawful wart is the sublime epitome of all perfection, never to be
improved on.  It was a really interesting experiment.  As sometimes happens,
the experiment discovered things that no one could have reasonably anticipated
without running the experiment.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

Page 1 of 8  [1] 2 3 4 5 6 7 8  Next page →

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

csiph-web