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

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

Continuing indentation

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

Contents

  Continuing indentation Skip Montanaro <skip.montanaro@gmail.com> - 2016-03-02 14:43 -0600
    Re: Continuing indentation Marko Rauhamaa <marko@pacujo.net> - 2016-03-02 22:50 +0200
      Re: Continuing indentation Ethan Furman <ethan@stoneleaf.us> - 2016-03-02 14:01 -0800
        Re: Continuing indentation Marko Rauhamaa <marko@pacujo.net> - 2016-03-03 00:10 +0200
          Re: Continuing indentation Skip Montanaro <skip.montanaro@gmail.com> - 2016-03-02 16:44 -0600
          Re: Continuing indentation Ethan Furman <ethan@stoneleaf.us> - 2016-03-02 14:51 -0800
          Re: Continuing indentation Ethan Furman <ethan@stoneleaf.us> - 2016-03-02 14:56 -0800
          Re: Continuing indentation Chris Angelico <rosuav@gmail.com> - 2016-03-03 10:46 +1100
          Re: Continuing indentation Steven D'Aprano <steve@pearwood.info> - 2016-03-03 13:15 +1100
          Re: Continuing indentation John Gordon <gordon@panix.com> - 2016-03-03 16:16 +0000
            Re: Continuing indentation Marko Rauhamaa <marko@pacujo.net> - 2016-03-03 18:47 +0200
              Re: Continuing indentation Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-03-03 18:06 +0000
                Re: Continuing indentation Marko Rauhamaa <marko@pacujo.net> - 2016-03-03 21:36 +0200
              Re: Continuing indentation Steven D'Aprano <steve@pearwood.info> - 2016-03-04 11:13 +1100
                Re: Continuing indentation INADA Naoki <songofacandy@gmail.com> - 2016-03-04 09:45 +0900
                Re: Continuing indentation Erik <python@lucidity.plus.com> - 2016-03-04 01:06 +0000
                Re: Continuing indentation INADA Naoki <songofacandy@gmail.com> - 2016-03-04 10:23 +0900
                  Re: Continuing indentation Steven D'Aprano <steve@pearwood.info> - 2016-03-04 14:48 +1100
                    Re: Continuing indentation cl@isbd.net - 2016-03-04 10:12 +0000
                      Re: Continuing indentation alister <alister.ware@ntlworld.com> - 2016-03-04 14:03 +0000
                        Re: Continuing indentation Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-04 08:25 -0700
                        Re: Continuing indentation Ethan Furman <ethan@stoneleaf.us> - 2016-03-04 09:36 -0800
                        Re: Continuing indentation sohcahtoa82@gmail.com - 2016-03-04 13:14 -0800
                          Re: Continuing indentation Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-04 21:20 +0000
                          Re: Continuing indentation Erik <python@lucidity.plus.com> - 2016-03-04 23:31 +0000
                          Re: Continuing indentation Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-04 23:45 +0000
                          Re: Continuing indentation Ethan Furman <ethan@stoneleaf.us> - 2016-03-04 15:53 -0800
                          Re: Continuing indentation Simon Ward <simon+python@bleah.co.uk> - 2016-03-05 00:23 +0000
                            Re: Continuing indentation sohcahtoa82@gmail.com - 2016-03-04 17:17 -0800
                              Re: Continuing indentation Ethan Furman <ethan@stoneleaf.us> - 2016-03-04 18:14 -0800
                              Re: Continuing indentation Ben Finney <ben+python@benfinney.id.au> - 2016-03-05 13:22 +1100
                              Re: Continuing indentation Tim Chase <python.list@tim.thechases.com> - 2016-03-04 20:49 -0600
                              Re: Continuing indentation srinivas devaki <mr.eightnoteight@gmail.com> - 2016-03-05 10:25 +0530
                              Re: Continuing indentation Ben Finney <ben+python@benfinney.id.au> - 2016-03-05 16:10 +1100
                          Re: Continuing indentation Erik <python@lucidity.plus.com> - 2016-03-05 00:52 +0000
                          Re: Continuing indentation Ben Finney <ben+python@benfinney.id.au> - 2016-03-05 12:05 +1100
                          Re: Continuing indentation Erik <python@lucidity.plus.com> - 2016-03-05 01:45 +0000
                          Re: Continuing indentation Steven D'Aprano <steve@pearwood.info> - 2016-03-05 18:17 +1100
                  Re: Continuing indentation alister <alister.ware@ntlworld.com> - 2016-03-04 13:59 +0000
                    Re: Continuing indentation Ben Finney <ben+python@benfinney.id.au> - 2016-03-05 10:41 +1100
                      Re: Continuing indentation sohcahtoa82@gmail.com - 2016-03-04 16:06 -0800
                        Re: Continuing indentation Ben Finney <ben+python@benfinney.id.au> - 2016-03-05 11:30 +1100
                        Re: Continuing indentation Ethan Furman <ethan@stoneleaf.us> - 2016-03-04 17:01 -0800
                Re: Continuing indentation Erik <python@lucidity.plus.com> - 2016-03-04 02:24 +0000
                Re: Continuing indentation Marko Rauhamaa <marko@pacujo.net> - 2016-03-04 08:28 +0200
    Re: Continuing indentation codewizard@gmail.com - 2016-03-02 15:46 -0800
      Re: Continuing indentation Chris Angelico <rosuav@gmail.com> - 2016-03-03 10:54 +1100
        Re: Continuing indentation Pete Forman <petef4+usenet@gmail.com> - 2016-03-03 00:23 +0000
      Re: Continuing indentation Carl Meyer <carl@oddbird.net> - 2016-03-02 17:02 -0700
        Re: Continuing indentation Steven D'Aprano <steve@pearwood.info> - 2016-03-03 13:22 +1100
          Re: Continuing indentation Ben Finney <ben+python@benfinney.id.au> - 2016-03-03 13:30 +1100
          Re: Continuing indentation Chris Angelico <rosuav@gmail.com> - 2016-03-03 13:33 +1100
          Re: Continuing indentation Ethan Furman <ethan@stoneleaf.us> - 2016-03-02 18:57 -0800
      Re: Continuing indentation Ben Finney <ben+python@benfinney.id.au> - 2016-03-03 11:30 +1100
      Re: Continuing indentation cl@isbd.net - 2016-03-03 10:22 +0000

Page 1 of 3  [1] 2 3  Next page →

#103894 — Continuing indentation

Running flake8 over some code which has if statements with multiple
conditions like this:

    if (some_condition and
        some_other_condition and
        some_final_condition):
        play_bingo()

the tool complains that the indentation of the conditions is the same
as the next block.  In this particular case, the overall conditions
are too long to string together on a single line. I tried placing a
second space after the if keyword:

    if  (some_condition and
         some_other_condition and
         some_final_condition):
        play_bingo()

which solves the matching indentation problem, but creates a multiple
spaces after keyword problem.  My guess is that adding a space after
the open paren would provoke a message as well.

I use GNU Emacs as my text editor, and its python mode.  I'm pretty
happy with everything (been using it in its current state for several
years).  Aside from manually or configure-ologically suppressing E129,
is there a better way to break lines I'm missing which will make
flake8 happy?

Thx,

Skip

[toc] | [next] | [standalone]

#103895

Skip Montanaro <skip.montanaro@gmail.com>:

> Running flake8 over some code which has if statements with multiple
> conditions like this:
>
>     if (some_condition and
>         some_other_condition and
>         some_final_condition):
>         play_bingo()
> [...]
>
> is there a better way to break lines I'm missing which will make
> flake8 happy?

This is the idiomatic way:

    if some_condition and \
       some_other_condition and \
       some_final_condition:
        play_bingo()


Marko

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

#103902

On 03/02/2016 12:50 PM, Marko Rauhamaa wrote:
> Skip Montanaro queried:
>
>> Running flake8 over some code which has if statements with multiple
>> conditions like this:
>>
>>      if (some_condition and
>>          some_other_condition and
>>          some_final_condition):
>>          play_bingo()
>> [...]
>>
>> is there a better way to break lines I'm missing which will make
>> flake8 happy?
>
> This is the idiomatic way:
>
>      if some_condition and \
>         some_other_condition and \
>         some_final_condition:
>          play_bingo()

No, it isn't.  Using '\' for line continuation is strongly discouraged.

--
~Ethan~

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

#103906

Ethan Furman <ethan@stoneleaf.us>:

> No, it isn't.  Using '\' for line continuation is strongly discouraged.

Why would you discourage valid syntax?


Marko

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

#103909

Thanks for the replies, folks. I'll provide a single response:

1. Using backslash to continue... When I first started using Python in
the mid-90s I don't recall that parenthesized expressions could be
continued across lines (at least, not in all contexts), so the
backslash was required. I believe the parser change necessary to
support ( ... \n ... ) in all contexts was added precisely to minimize
the need for backslashes as continuation.

2. Changing the indentation of the continued lines... My brain thinks
the right thing to do is to what it currently does (line up continued
lines inside the indentation in the column following the left paren,
so I'm really not interested in using (\n or other variations which
allow me to fool the Python mode auto-indent feature. I'm pretty sure
the XEmacs python-mode.el did things the same way. A quick peek at
python.el didn't indicate an obvious way to change that offset to
something other than the default indentation. This is Emacs though. No
doubt there is a way. Since I like the current behavior, I'm not
inclined to go out of my way to figure it out.

3. Adding a comment... I do that where a comment is necessary, but it
doesn't suppress the error message.

I don't know. Maybe I need to ask the flake8 author about his
rationale for this message. It seems to me from my experience with the
language that this particular message is going against pretty common
practice. Does vim's Python mode exhibit similar behavior by default?
What about other editors/IDEs?

Thx,

Skip

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

#103910

On 03/02/2016 02:10 PM, Marko Rauhamaa wrote:
> Ethan Furman <ethan@stoneleaf.us>:
>
>> No, it isn't.  Using '\' for line continuation is strongly discouraged.
>
> Why would you discourage valid syntax?

1) It's ugly
2) Any non-newline whitespace after the '\' and you don't have line
    continuation any more, and no visible way to notice.

--
~Ethan~

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

#103912

On 03/02/2016 02:44 PM, Skip Montanaro wrote:

> I don't know. Maybe I need to ask the flake8 author about his
> rationale for this message. It seems to me from my experience with the
> language that this particular message is going against pretty common
> practice. Does vim's Python mode exhibit similar behavior by default?
> What about other editors/IDEs?

My vim mode indents an extra four spaces when continuing lines (so eight 
total), and dedents back four after the ): (which does line up with the 
extra-indented conditions, but with the original condition).

I find the different indentation levels for conditions version body to 
be very helpful.

--
~Ethan~

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

#103916

On Thu, Mar 3, 2016 at 9:10 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Ethan Furman <ethan@stoneleaf.us>:
>
>> No, it isn't.  Using '\' for line continuation is strongly discouraged.
>
> Why would you discourage valid syntax?
>

Isn't that exactly the point of style guides? They stipulate/encourage
a particular subset of valid syntax, and decry/discourage another
subset. If ugly code were not syntactically valid, the style guide
wouldn't need to say anything.

ChrisA

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

#103924

On Thu, 3 Mar 2016 09:10 am, Marko Rauhamaa wrote:

> Ethan Furman <ethan@stoneleaf.us>:
> 
>> No, it isn't.  Using '\' for line continuation is strongly discouraged.
> 
> Why would you discourage valid syntax?

Because it is error-prone and ugly.


This is valid syntax too. Do you write your code like this?


x                                                      = ++ ++ -- ++ -- --1
y = (((((2)))))                                        , 3
s = "Hello world!"                                     .             upper()





-- 
Steven

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

#103972

In <871t7sbkex.fsf@elektro.pacujo.net> Marko Rauhamaa <marko@pacujo.net> writes:

> Ethan Furman <ethan@stoneleaf.us>:

> > No, it isn't.  Using '\' for line continuation is strongly discouraged.

> Why would you discourage valid syntax?

Some things that are permissible may not be desirable.

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

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

#103978

John Gordon <gordon@panix.com>:

> In <871t7sbkex.fsf@elektro.pacujo.net> Marko Rauhamaa
> <marko@pacujo.net> writes:
>
>> Ethan Furman <ethan@stoneleaf.us>:
>
>> > No, it isn't.  Using '\' for line continuation is strongly discouraged.
>
>> Why would you discourage valid syntax?
>
> Some things that are permissible may not be desirable.

Line continuations are such a central part of the syntax that it would
seem silly to deprecate them.

While it is true that

   if a and \
      b:
       pass

is ugly,

   if (a and
       b):
       pass

is even uglier.


Marko

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

#103983

Marko Rauhamaa wrote:

> John Gordon <gordon@panix.com>:
>
>> In <871t7sbkex.fsf@elektro.pacujo.net> Marko Rauhamaa
>> <marko@pacujo.net> writes:
>>
>>> Ethan Furman <ethan@stoneleaf.us>:
>>
>>> > No, it isn't.  Using '\' for line continuation is strongly discouraged.
>>
>>> Why would you discourage valid syntax?
>>
>> Some things that are permissible may not be desirable.
>
> Line continuations are such a central part of the syntax that it would
> seem silly to deprecate them.
>
> While it is true that
>
>    if a and \
>       b:
>        pass
>
> is ugly,
>
>    if (a and
>        b):
>        pass
>
> is even uglier.
>
>
> Marko

Not ugly, error-prone.  The first is purely aestehetic, the second
actually matters.  Let something as simple as a trailing space sneak in
after your backslash and your meaning changes.  Blank line between; same
thing.

Granted in Python that will tend to lead to a SyntaxError, rather than
silently shoot you in the foot the way this used to in C:

if (condition)
   first_action();
   section_action();
else {
   alternate action();
}

But the principle remains.  Syntactic whitespace has its ups and downs
on the leading edge of the line, but at least it's visible there.  On
the trailing end of the line it's actively inviting trouble in for
coffee and eggs.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com

Email address domain is currently out of order.  See above to fix.

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

#103985

Rob Gaddi <rgaddi@highlandtechnology.invalid>:

> Not ugly, error-prone. The first is purely aestehetic, the second
> actually matters. Let something as simple as a trailing space sneak in
> after your backslash and your meaning changes. Blank line between;
> same thing.

Never been bitten by that.

Now, trying how emacs' indentation would react to such a syntax error, I
notice:

    if some_condition \ 
    and some_other_condition \
        and some_final_condition:
    play_bingo()

The misalignment is a surefire way to notice something is fishy (in all
programming languages).

> But the principle remains. Syntactic whitespace has its ups and downs
> on the leading edge of the line, but at least it's visible there. On
> the trailing end of the line it's actively inviting trouble in for
> coffee and eggs.

Continuation lines with backslashes are all over the place: make, bash,
C, Python. I can't remember such accidents taking place.

Now, *leading* whitespace causes all kinds of mischief including jagged
diffs and syntax errors.


Marko

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

#104007

On Fri, 4 Mar 2016 03:47 am, Marko Rauhamaa wrote:

> John Gordon <gordon@panix.com>:
> 
>> In <871t7sbkex.fsf@elektro.pacujo.net> Marko Rauhamaa
>> <marko@pacujo.net> writes:
>>
>>> Ethan Furman <ethan@stoneleaf.us>:
>>
>>> > No, it isn't.  Using '\' for line continuation is strongly
>>> > discouraged.
>>
>>> Why would you discourage valid syntax?
>>
>> Some things that are permissible may not be desirable.
> 
> Line continuations are such a central part of the syntax that it would
> seem silly to deprecate them.

What a wonderfully wrong sentence! Line continuations are not a central part
of the syntax, they've very much a minor and rarely used part.

Indentation is a central part of the syntax. Students need to learn about
indentation right from the beginning, and it is barely possible to go ten
minutes of writing Python code without using indentation. But line
continuations? It is quite possible to go years between seeing \ line
continuations in code, and it is never *necessary* to use them.

Nevertheless, they are not deprecated. They are just *discouraged*. Are you
familiar with the difference?


Deprecate: a formal or semi-formal process whereby features are removed from
a programming language.


Discourage: a social process whereby use of a feature is deterred but not
prohibited.



> While it is true that
> 
>    if a and \
>       b:
>        pass
> 
> is ugly,
> 
>    if (a and
>        b):
>        pass
> 
> is even uglier.


It's silly to break such short expressions over multiple lines, and you
cannot judge the aesthetics of long expressions by looking at short ones.


class C:
    def method(self):
        if (result is None 
                or self.some_condition()
                or len(some_sequence) > 100
                or some_other_condition
                or page_count < 5
            ):
            do_processing()


Looks fine to me.



-- 
Steven

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

#104008

>
>
> class C:
>     def method(self):
>         if (result is None
>                 or self.some_condition()
>                 or len(some_sequence) > 100
>                 or some_other_condition
>                 or page_count < 5
>             ):
>             do_processing()
>
>
> Looks fine to me.
>
>
Looks nice to me too.  But...

```
$ cat > t.py
class C:
    def method(self):
        if (result is None
                or self.some_condition()
                or len(some_sequence) > 100
                or some_other_condition
                or page_count < 5
            ):
            do_processing()

$ pep8 t.py
t.py:4:17: W503 line break before binary operator
t.py:5:17: W503 line break before binary operator
t.py:6:17: W503 line break before binary operator
t.py:7:17: W503 line break before binary operator
t.py:8:5: E125 continuation line with same indent as next logical line
```

pep8.py is toooo strict.

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

#104009

On 04/03/16 00:13, Steven D'Aprano wrote:
> class C:
>      def method(self):
>          if (result is None
>                  or self.some_condition()
>                  or len(some_sequence) > 100
>                  or some_other_condition
>                  or page_count < 5
>              ):
>              do_processing()
>
> Looks fine to me.

Indeed. I don't understand why, when splitting a condition such as this, 
people tend to put the operator at the end of each line.

In C, I also prefer (a style copied from an old colleague of mine who 
had lots of strange ideas, but I liked this one ;)) -

if (  long_condition
   &&  other_long_condition
   &&  (another_long_condition
     || yet_another_long_condition)
   || some_other_condition) {
     process();
}

I just find that so much easier to grok than:

if (long_condition &&
     other_long_condition &&
     (another_long_condition ||
      yet_another_long_condition) ||
     some_other_condition) {
     process();
}

Also, it sort of lays out just what the short-circuit evaluation is 
going to do, so when those long conditions are /actually/ long and 
require a bit of mental parsing, you can scan the left hand side of the 
code and not have to read most of it as you work out which conditions 
may be true. With the second form, you have to parse every line to work 
out if the operator at the end is a top-level operator or part of a 
sub-condition.

E.

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

#104010

>
>
> Indeed. I don't understand why, when splitting a condition such as this,
> people tend to put the operator at the end of each line.
>
>
Because PEP8 says:

> The preferred place to break around a binary operator is after the
operator, not before it.
http://pep8.org/#maximum-line-length

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

#104013

On Fri, 4 Mar 2016 12:23 pm, INADA Naoki wrote:

>>
>>
>> Indeed. I don't understand why, when splitting a condition such as this,
>> people tend to put the operator at the end of each line.
>>
>>
> Because PEP8 says:
> 
>> The preferred place to break around a binary operator is after the
> operator, not before it.
> http://pep8.org/#maximum-line-length

PEP 8 is wrong :-)



-- 
Steven

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

#104020

Steven D'Aprano <steve@pearwood.info> wrote:
> On Fri, 4 Mar 2016 12:23 pm, INADA Naoki wrote:
> 
> >>
> >>
> >> Indeed. I don't understand why, when splitting a condition such as this,
> >> people tend to put the operator at the end of each line.
> >>
> >>
> > Because PEP8 says:
> > 
> >> The preferred place to break around a binary operator is after the
> > operator, not before it.
> > http://pep8.org/#maximum-line-length
> 
> PEP 8 is wrong :-)
> 
Yes, I agree.  In my mind the logic is:-

    IF xxx
        AND yyy
        AND zzz
        OR aaa
    THEN do something

The PEP8 correct(er):-

    IF xxx AND
         yyy AND
         zzz OR
         aaa
    THEN do something

... just seems all wrong and difficult to understand.

-- 
Chris Green
·

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

#104038

On Fri, 04 Mar 2016 10:12:58 +0000, cl wrote:

> Steven D'Aprano <steve@pearwood.info> wrote:
>> On Fri, 4 Mar 2016 12:23 pm, INADA Naoki wrote:
>> 
>> 
>> >>
>> >> Indeed. I don't understand why, when splitting a condition such as
>> >> this,
>> >> people tend to put the operator at the end of each line.
>> >>
>> >>
>> > Because PEP8 says:
>> > 
>> >> The preferred place to break around a binary operator is after the
>> > operator, not before it. http://pep8.org/#maximum-line-length
>> 
>> PEP 8 is wrong :-)
>> 
> Yes, I agree.  In my mind the logic is:-
> 
>     IF xxx
>         AND yyy AND zzz OR aaa
>     THEN do something
> 
> The PEP8 correct(er):-
> 
>     IF xxx AND
>          yyy AND zzz OR aaa
>     THEN do something
> 
> ... just seems all wrong and difficult to understand.

not at all
the split after the operator shows that their is more to that line
splitting before & the reader could believe that the condition ends there

PEP 8 is mos definitely correct on this one



-- 
According to all the latest reports, there was no truth in any of the
earlier reports.

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web