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

#11225 — Re: [Python-ideas] allow line break at operators

Hi Matt,

On Thu, Aug 11, 2011 at 5:28 PM, Matt Joiner <anacrolix@gmail.com> wrote:
> +0.5
>
> The "trailing \" workaround is nonobvious. Wrapping in () is noisy and
> already heavily used by other syntactical structures. Since a final
> ':' is needed anyway, i think this would be great.
>
> if a
>  and b
>  or c:
>  do stuff()
>
If you really think so, try writing some coffeescript (remember to
obey 79 chars limit). Coffeescript is amasing, but it lacks
strictness of python. So you really don't know how to break line,
and it really takes time to figure out right way each time you need
it.

-- 
Paul

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

#11227 — Re: [Python-ideas] allow line break at operators

> Right now you do not need to indent continuation lines. So in order to disambiguate you would need to enforce indentation for continuations, but for backward compatibility that would only be required when not using parentheses or backslashes. Ick. Can blank lines or comment lines appear between a line and its continuation? That's allowed now as well.

Eek no. If I was suggesting anything, it would have been a third form
of continuation: collapsing subsequent extra-indented lines. This is
never ambiguous. (This could be done in such a way as to permit
comments, namely, by doing it to the tokenstream rather than to the
actual text)

Devin

On Thu, Aug 11, 2011 at 4:45 PM, Bruce Leban <bruce@leapyear.org> wrote:
>
> On Thu, Aug 11, 2011 at 12:24 PM, Devin Jeanpierre <jeanpierreda@gmail.com> wrote:
>>
>> Javascript also lets you break lines. For example, this does what you want:
>>
>>     return 1
>>         + 5
>>
>> Whereas this does not
>>
>>     return
>>         1 + 5
>>
>> Of course, Python would have no such problem, because you could make both cases unambiguous due to the indent.
>>
>> Devin
>>
> Note that this is already valid and is not a continuation line:
>
> return 1
> +5
>
> Right now you do not need to indent continuation lines. So in order to disambiguate you would need to enforce indentation for continuations, but for backward compatibility that would only be required when not using parentheses or backslashes. Ick. Can blank lines or comment lines appear between a line and its continuation? That's allowed now as well.
> Now allowing line breaks *after* operators would be unambiguous and would not require new indentation rules. When a line ends with an operator, it's clearly incomplete (so no fear the reader will think the statement has ended unlike the above case) and it's a syntax error today:
>
> return 1 +
>     5
> x = y > 0 and
>    y < 10
>
> This code is not valid today without parens or \ regardless of indentation. I'm +0 on this. I'd use it but does it really add enough convenience?
> --- Bruce
> Follow me: http://www.twitter.com/Vroo http://www.vroospeak.com

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

#11228 — Re: [Python-ideas] allow line break at operators

    a = b,
    c = d

is a pair of such statements.

Howeverm indentation errors have been extremely rare in my experience,
so I'm not really compelled to think it's harmful. Especially since
3.x outlaws mixing tabs and spaces.

I don't love it, but I guess I prefer it to throwing parentheses and
especially \ everywhere. Parentheses can be awkward and don't quite
work everywhere the way one might want, and \ has that trailing space
ugliness.

Devin

On Thu, Aug 11, 2011 at 5:21 PM, Bruce Leban <bruce@leapyear.org> wrote:
>
> On Thu, Aug 11, 2011 at 2:06 PM, Devin Jeanpierre <jeanpierreda@gmail.com>
> wrote:
>>
>> Eek no. If I was suggesting anything, it would have been a third form
>> of continuation: collapsing subsequent extra-indented lines. This is
>> never ambiguous. (This could be done in such a way as to permit
>> comments, namely, by doing it to the tokenstream rather than to the
>> actual text)
>
> So if I miss-indent this
> a = b
>   (x, y) = z
>
> instead of getting "unexpected indent" I get "SyntaxError: can't assign to
> function call". I'm sure someone can come up with two valid statements that
> have a different meaning when spliced together.
> --- Bruce
> Follow me: http://www.twitter.com/Vroo http://www.vroospeak.com
>
>
>

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

#11229 — Re: [Python-ideas] allow line break at operators

On Thu, Aug 11, 2011 at 5:29 PM, Devin Jeanpierre
<jeanpierreda@gmail.com> wrote:
> Howeverm indentation errors have been extremely rare in my experience,
> so I'm not really compelled to think it's harmful. Especially since
> 3.x outlaws mixing tabs and spaces.

I normally get them when starting with code from somewhere else (which
might well mixed tabs and spaces, or worse, if emailed or posted to
the web) or when cutting and pasting at an interactive prompt.

-jJ

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

#11235 — Re: [Python-ideas] allow line break at operators

Well the tabs&spaces issue is no longer an issue as far as I
understand it (such a change to indent semantics could only go into
3.x), and cutting and pasting to the interpreter is obvious anyway
just visually, regardless of the specific error message.

The other issue sounds reasonable. Code that has indentation stripped
or mangled due to the transition medium would be even harder to
recompose.

Devin

On Thu, Aug 11, 2011 at 5:39 PM, Jim Jewett <jimjjewett@gmail.com> wrote:
> On Thu, Aug 11, 2011 at 5:29 PM, Devin Jeanpierre
> <jeanpierreda@gmail.com> wrote:
>> Howeverm indentation errors have been extremely rare in my experience,
>> so I'm not really compelled to think it's harmful. Especially since
>> 3.x outlaws mixing tabs and spaces.
>
> I normally get them when starting with code from somewhere else (which
> might well mixed tabs and spaces, or worse, if emailed or posted to
> the web) or when cutting and pasting at an interactive prompt.
>
> -jJ
>

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

#12618 — Re: [Python-ideas] allow line break at operators

I guess the issue here is that you can't tell if an expression is
complete without checking the indent of the following line. This is
likely not desirable.

On Thu, Sep 1, 2011 at 11:43 PM, Yingjie Lan <lanyjie@yahoo.com> wrote:
> Hi Matt,
> =======================================================
> From: Matt Joiner <anacrolix@gmail.com>
>
> The "trailing \" workaround is nonobvious. Wrapping in () is noisy and
> already heavily used by other syntactical structures.
> =======================================================
> How about only require indentation
> to freely break lines? Here is an example:
> x = firstpart * secondpart #line breaks here
> + anotherpart #continue by indentation
> + stillanother #continue on.
> #until here, another line starts by dedentation
> y = some_expression - another_one
> All this would be completely compatible with former code, while
> having almost free line breaking! Plus, indentation makes it pretty.
> Really hope Python can have freedom in breaking lines.
> Yingjie

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

#12709 — Re: [Python-ideas] allow line break at operators

In article <mailman.688.1314941609.27778.python-list@python.org>,
 Matt Joiner <anacrolix@gmail.com> wrote:

> I guess the issue here is that you can't tell if an expression is
> complete without checking the indent of the following line. This is
> likely not desirable.

I wrote a weird bug the other day.  I had a function that returned a 
4-tuple and wanted to unpack it, so I wrote:

    var1,
    var2,
    var3,
    var4 = my_function()

which isn't a syntax error, but also isn't what I meant.  Depending on 
whether var[123] have pre-existing values, this doesn't even produce a 
run-time error.  Emacs encouraged me in this crime by merrily 
auto-indenting the code the way I expected :-)

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

#12625 — Re: [Python-ideas] allow line break at operators

Gabriel AHTUNE writes:
 > So can be done with this syntax:
 > 
 > > x = firstpart * secondpart  +  #line breaks here
 > > anotherpart + #continue
 > > stillanother #continue on.
 > 
 > after a "+" operator the line is clearly not finished yet.

Sure, but IIRC one design principle of Python is that the keyword that
denotes the syntax should be the first thing on the line, making it
easy to scan down the left side of the code to see the syntactic
structure.  The required indentation of the controlled suite also
helps emphasize that keyword.

Analogously, if operators are going to denote continuation, they
should come first on the line.

I just don't think this idea is going anywhere.  Explicit continuation
with backslash or implicit continuation of parenthesized expressions
is just not that heavy a price to pay.  Perhaps historically some of
these ideas could have been implemented, but now they're just going to
confuse a host of editors and code analysis tools.

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

#12667 — Re: [Python-ideas] allow line break at operators

On Fri, Sep 2, 2011 at 12:28 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> Gabriel AHTUNE writes:
>  > So can be done with this syntax:
>  >
>  > > x = firstpart * secondpart  +  #line breaks here
>  > > anotherpart + #continue
>  > > stillanother #continue on.
>  >
>  > after a "+" operator the line is clearly not finished yet.
>
> Sure, but IIRC one design principle of Python is that the keyword that
> denotes the syntax should be the first thing on the line, making it
> easy to scan down the left side of the code to see the syntactic
> structure.  The required indentation of the controlled suite also
> helps emphasize that keyword.

That's true for *statements* (except assignments and calls).

> Analogously, if operators are going to denote continuation, they
> should come first on the line.

That doesn't follow. My preferred style is actually to put the binary
operator at the end of the line. This also matches the prevailing
style for breaking lines after commas (a comma can be seen as a kind
of binary operator).

> I just don't think this idea is going anywhere.  Explicit continuation
> with backslash or implicit continuation of parenthesized expressions
> is just not that heavy a price to pay.  Perhaps historically some of
> these ideas could have been implemented, but now they're just going to
> confuse a host of editors and code analysis tools.

Totally agreed that this isn't going to happen.

-- 
--Guido van Rossum (python.org/~guido)

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

#12689 — Re: [Python-ideas] allow line break at operators

Guido van Rossum writes:
 > On Fri, Sep 2, 2011 at 12:28 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:

 > > Sure, but IIRC one design principle of Python is that the keyword that
 > > denotes the syntax should be the first thing on the line,
[...]
 > That's true for *statements* (except assignments and calls).
 > 
 > > Analogously, if operators are going to denote continuation, they
 > > should come first on the line.

 > That doesn't follow.

Agreed, it's not a logical implication.  The analogy is only an
analogy, but my eyes do work that way.

My conclusion is that we shouldn't try to encourage either style,
because people "see" continuation differently.  Legislating a style
isn't going to change that, I think.

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

#12693 — Re: [Python-ideas] allow line break at operators

Yingjie Lan writes:

 > Have you considered line continuation by indentation? It seems to
 > meet the design principle. I think it is the most natural way to
 > allow free line breaking in Python.

Briefly, yes, and I think it would need a lot of tuning and probably
complex rules.  Unlike statements, where everybody (except the judges
of the Obfuscated C Contest) agrees on a simple rule: "In a control
structure, the controlled suite should be uniformly indented one
level", line breaking and indentation of long expressions is an art,
and people have different opinions on "readability" and "beauty."
Achieving a compromise that is workable even for a few major styles is
likely to be annoying and bug-prone.

Pretty much every program I write seems to have a continued list of
data or a multi-line dictionary display as data.  It's not unusual for
me to comment the formal arguments in a function definition, or the
parent classes of a class definition.  The exception for parenthesized
objects is something I depend on for what I consider good style.  Of
course I could use explicit continuation, but in a long table that's
ugly and error-prone.

Long expressions that need to be broken across lines, on the other
hand, often indication that I haven't thought carefully enough about
that component of the program, and an extra pair of parentheses or a
terminal backslash just isn't that "heavy" or ugly in the context of
such long expressions.  For me, they're also pretty rare; many
programs I write have no explicit continuations in them at all.

YMMV, of course, but I find the compromise that Python arrived at to
be very useful, and I must suppose that it was substantially easier to
implement than "fully free" line breaking (whatever that means to you).

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

#12716 — Re: [Python-ideas] allow line break at operators

On 9/3/2011 3:51 AM, Yingjie Lan wrote:
> I agree that long lines of code are not very common in many projects,
> though it might be the case with some heavily involved in math. For some
> reason, when the feature of free line breaking came about in computer
> languages, it is welcomed and generally well accepted.

Every language with blocks needs some mechanism to indicate the 
beginning and ending of blocks and of statements within blocks. If 
visible fences ('begin/end' or '{}') and statement terminators (';') are 
used, then '\n' can be treated as merely a space, as it is in C, for 
instance.

> Python uses indentation for blocks,

and it uses unescaped '\n' (with two escapement options) to terminate 
statements. This is fundamental to Python's design and goes along with 
significant indents.

 > and by the same mechanism, line breaking can be
> accommodated without requiring parenthesis or ending backslashes.

You need proof for your claim that indentation can be used for both jobs 
in the form of a grammar that works with Python's parser. I am dubious 
that you can do that with an indents *after* the newline.

Even if you could, it would be confusing for human readers. There would 
then be three ways to escape newline, with one doing double duty. And 
for what? Merely to avoid using either of the two methods already available.

-- 
Terry Jan Reedy

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

#12743 — Re: [Python-ideas] allow line break at operators

On Sat, 2011-09-03 at 13:38 +0900, Stephen J. Turnbull wrote:
> Guido van Rossum writes:
>  > On Fri, Sep 2, 2011 at 12:28 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> 
>  > > Sure, but IIRC one design principle of Python is that the keyword that
>  > > denotes the syntax should be the first thing on the line,
> [...]
>  > That's true for *statements* (except assignments and calls).
>  > 
>  > > Analogously, if operators are going to denote continuation, they
>  > > should come first on the line.
> 
>  > That doesn't follow.
> 
> Agreed, it's not a logical implication.  The analogy is only an
> analogy, but my eyes do work that way.
> 
> My conclusion is that we shouldn't try to encourage either style,
> because people "see" continuation differently.  Legislating a style
> isn't going to change that, I think.

I like to start continued lines with an operator as well.   I also think
it helps me keep it in my head a bit easier when I do that. 

I think this is one of those areas where computers and people differ,
but it may also depend on the persons native language as to what works
better for them.

Ron

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

#12746

On Sep 4, 10:22 am, ron3200 <ron3...@gmail.com> wrote:

> I think this is one of those areas where computers and people differ,
> but it may also depend on the persons native language as to what works
> better for them.

Yes but what works better for "them" is not always a better way of
doing things! People do foolish things all the time just from pure
habit. A foolish consistency is a foolish consistency my friend. I
mean, look at the folks who popped their cherry writing Basic code;
talk about dysfunctional!

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

#11126

Chris Angelico 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.
> Putting the + at the end of the previous line at least prevents that,
> since most unary operators bind to the operand on the right;

Not so:

>>> x = (42 + -
...     100)
>>>
>>> x
-58



-- 
Steven

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

#11133

On Wed, Aug 10, 2011 at 3:37 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
>> 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;
>
> Not so:
>
>>>> x = (42 + -
> ...     100)
>>>>
>>>> x
> -58

Your unary - is binding to the operand to its right, in this case the
100. (I think I have left and right correct; being in theatre has a
tendency to make you forget which is which.) Your + is binary,
operating on 42 and the result of applying unary - to 100, which is
-100.

My point about binding can be illustrated by inventing an operator @.
Let's say that a@b is the atan2 of a and b, and x@ is x factorial (I
can't imagine what deranged mind would do something like this, apart
from my own).

y = 5 @     # 120, as per factorial
x = 5 @ 2   # 1.19 or so, as per atan2
foo(123)     # Calls foo() and discards its return value
z = 5 @
foo(123)

Is that last example one statement or two?

But this situation shouldn't ever occur in Python, because all its
unary operators (not, -, +, ~) bind to the operand to their right (I
don't think there's any I've missed, are there?). It does mean,
however, that a leading operator is not unambiguous. Without the
surrounding parentheses and/or otherwise-unexpected indentation, an
expression beginning with a + could conceivably be applying the unary
plus operator to the rest of the expression, rather than implying that
it's continuing the previous line.

Chris Angelico

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

#11134

On Wed, Aug 10, 2011 at 8:37 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
>> 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;
>
> Not so:
>
>>>> x = (42 + -
> ...     100)
>>>>
>>>> x
> -58

That is still binding to the operand on the "right" (i.e., the
sequentially later).  And it still does not cause the problem that
Chris was talking about, since without the parentheses that would be a
syntax error.  So I guess I'm not certain what exactly it is that
you're trying to demonstrate here.

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

#11154

Ian Kelly wrote:

> On Wed, Aug 10, 2011 at 8:37 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>>> 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;
>>
>> Not so:
>>
>>>>> x = (42 + -
>> ...     100)
>>>>>
>>>>> x
>> -58
> 
> That is still binding to the operand on the "right" (i.e., the
> sequentially later).  And it still does not cause the problem that
> Chris was talking about, since without the parentheses that would be a
> syntax error.  So I guess I'm not certain what exactly it is that
> you're trying to demonstrate here.

Chris stated that putting the unary + at the end of the line
prevents "that", that being applying the unary + operator to the value on
the right. But that is not the case -- unary prefix operators in Python can
be separated from their operands by whitespace, including newlines.

(Python doesn't have any unary postfix operators.)

 

-- 
Steven

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

#11157

On Thu, Aug 11, 2011 at 12:32 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Chris stated that putting the unary + at the end of the line
> prevents "that", that being applying the unary + operator to the value on
> the right. But that is not the case -- unary prefix operators in Python can
> be separated from their operands by whitespace, including newlines.
>

Right, I forgot that. It certainly would not be normal to do it that
way, though.

ChrisA

[toc] | [prev] | [standalone]

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

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

csiph-web