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

#104064

On Friday, March 4, 2016 at 3:41:29 PM UTC-8, Ben Finney wrote:
> alister <alister.ware@ntlworld.com> writes:
> 
> > On Fri, 04 Mar 2016 10:23:37 +0900, INADA Naoki wrote:
> >
> > > 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
> >
> > and that is to make it obvious that there is more to come.
> 
> That's a good way to express it.
> 
> I think there are competing models here:
> 
> * When breaking an expression between two lines, put the binary operator
>   at the end of the earlier line.
> 
>   This makes it obvious what's going on when reading the earlier line.
> 
> * When breaking an expression between two lines, put the binary operator
>   at the beginning of the later line.
> 
>   This makes it obvious what's going on when reading the continuation
>   line.
> 
> Both have merit. Both models make an almost-identical appeal to
> readability.
> 
> We can't put the binary operator in multiple places,

<snip>

Who are you, the binary operator police?  Watch me!

if x == y and \
        x == z and \
        a > b \
        or b > c \
        and (d is not \
        None \
        ):
    pass

You're not the boss of me!

And that code hurt to write...

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

#104065

sohcahtoa82@gmail.com writes:

> On Friday, March 4, 2016 at 3:41:29 PM UTC-8, Ben Finney wrote:
> > We can't put the binary operator in multiple places,
>
> <snip>
>
> Who are you, the binary operator police?  Watch me!
>
> if x == y and \
>         x == z and \
>         a > b \
>         or b > c \
>         and (d is not \
>         None \
>         ):
>     pass

Each one of those binary operators is in exactly one place.

> You're not the boss of me!

Nor am I your father.

-- 
 \               “… correct code is great, code that crashes could use |
  `\           improvement, but incorrect code that doesn’t crash is a |
_o__)                    horrible nightmare.” —Chris Smith, 2008-08-22 |
Ben Finney

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

#104068

On 03/04/2016 04:30 PM, Ben Finney wrote:> sohcahtoa82@gmail.com writes:
 >> On Friday, March 4, 2016 at 3:41:29 PM UTC-8, Ben Finney wrote:

 >>> We can't put the binary operator in multiple places,
 >>
 >> <snip>
 >>
 >> Who are you, the binary operator police?  Watch me!
 >>
 >> if x == y and \
 >>          x == z and \
 >>          a > b \
 >>          or b > c \
 >>          and (d is not \
 >>          None \
 >>          ):
 >>      pass
 >
 > Each one of those binary operators is in exactly one place.
 >
 >> You're not the boss of me!
 >
 > Nor am I your father.

What was that disturbance?  The Force whimpering away...

--
~Ethan~

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

#104011

On 04/03/16 01:23, 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.

I mean in the general scheme of things, which is why I gave a C example
too ;)

Perhaps I am challenging the wisdom of of PEP8 ;)

E.

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

#104015

Steven D'Aprano <steve@pearwood.info>:

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

The class is aptly named "C"; the parentheses give a C-esque feel to the
statement.

Continuation lines abound in the standard lib sources. For example:

========================================================================
   difflib.py:
========================================================================
        # Extend the best by non-junk elements on each end.  In particular,
        # "popular" non-junk elements aren't in b2j, which greatly speeds
        # the inner loop above, but also means "the best" match so far
        # doesn't contain any junk *or* popular non-junk elements.
        while besti > alo and bestj > blo and \
              not isbjunk(b[bestj-1]) and \
              a[besti-1] == b[bestj-1]:
            besti, bestj, bestsize = besti-1, bestj-1, bestsize+1
        while besti+bestsize < ahi and bestj+bestsize < bhi and \
              not isbjunk(b[bestj+bestsize]) and \
              a[besti+bestsize] == b[bestj+bestsize]:
            bestsize += 1

        # Now that we have a wholly interesting match (albeit possibly
        # empty!), we may as well suck up the matching junk on each
        # side of it too.  Can't think of a good reason not to, and it
        # saves post-processing the (possibly considerable) expense of
        # figuring out what to do with it.  In the case of an empty
        # interesting match, this is clearly the right thing to do,
        # because no other kind of match is possible in the regions.
        while besti > alo and bestj > blo and \
              isbjunk(b[bestj-1]) and \
              a[besti-1] == b[bestj-1]:
            besti, bestj, bestsize = besti-1, bestj-1, bestsize+1
        while besti+bestsize < ahi and bestj+bestsize < bhi and \
              isbjunk(b[bestj+bestsize]) and \
              a[besti+bestsize] == b[bestj+bestsize]:
            bestsize = bestsize + 1
========================================================================

========================================================================
   ast.py:
========================================================================
def literal_eval(node_or_string):
    """
    Safely evaluate an expression node or a string containing a Python
    expression.  The string or node provided may only consist of the following
    Python literal structures: strings, bytes, numbers, tuples, lists, dicts,
    sets, booleans, and None.
    """
    if isinstance(node_or_string, str):
        node_or_string = parse(node_or_string, mode='eval')
    if isinstance(node_or_string, Expression):
        node_or_string = node_or_string.body
    def _convert(node):
        if isinstance(node, (Str, Bytes)):
            return node.s
        elif isinstance(node, Num):
            return node.n
        elif isinstance(node, Tuple):
            return tuple(map(_convert, node.elts))
        elif isinstance(node, List):
            return list(map(_convert, node.elts))
        elif isinstance(node, Set):
            return set(map(_convert, node.elts))
        elif isinstance(node, Dict):
            return dict((_convert(k), _convert(v)) for k, v
                        in zip(node.keys, node.values))
        elif isinstance(node, NameConstant):
            return node.value
        elif isinstance(node, UnaryOp) and \
             isinstance(node.op, (UAdd, USub)) and \
             isinstance(node.operand, (Num, UnaryOp, BinOp)):
            operand = _convert(node.operand)
            if isinstance(node.op, UAdd):
                return + operand
            else:
                return - operand
        elif isinstance(node, BinOp) and \
             isinstance(node.op, (Add, Sub)) and \
             isinstance(node.right, (Num, UnaryOp, BinOp)) and \
             isinstance(node.left, (Num, UnaryOp, BinOp)):
            left = _convert(node.left)
            right = _convert(node.right)
            if isinstance(node.op, Add):
                return left + right
            else:
                return left - right
        raise ValueError('malformed node or string: ' + repr(node))
    return _convert(node_or_string)
========================================================================


Marko

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

#103915

On Wednesday, March 2, 2016 at 3:44:07 PM UTC-5, Skip Montanaro wrote:
> 
>     if (some_condition and
>         some_other_condition and
>         some_final_condition):
>         play_bingo()

How about:

  continue_playing = (
      some_condition and
      some_other_condition and
      some_final_condition
  )

  if continue_playing:
      play_bingo()

or:

  play_conditions = [
      some_condition,
      some_other_condition,
      some_final_condition,
  ]

  if all(play_conditions):
      play_bingo()

Regards,
Igor.

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

#103917

On Thu, Mar 3, 2016 at 10:46 AM,  <codewizard@gmail.com> wrote:
> On Wednesday, March 2, 2016 at 3:44:07 PM UTC-5, Skip Montanaro wrote:
>>
>>     if (some_condition and
>>         some_other_condition and
>>         some_final_condition):
>>         play_bingo()
>
> How about:
>
>   continue_playing = (
>       some_condition and
>       some_other_condition and
>       some_final_condition
>   )
>
>   if continue_playing:
>       play_bingo()
>
> or:
>
>   play_conditions = [
>       some_condition,
>       some_other_condition,
>       some_final_condition,
>   ]
>
>   if all(play_conditions):
>       play_bingo()

Those feel like warping your code around the letter of the law,
without really improving anything.

ChrisA

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

#103919

Chris Angelico <rosuav@gmail.com> writes:

> On Thu, Mar 3, 2016 at 10:46 AM,  <codewizard@gmail.com> wrote:
>> On Wednesday, March 2, 2016 at 3:44:07 PM UTC-5, Skip Montanaro wrote:
>>>
>>>     if (some_condition and
>>>         some_other_condition and
>>>         some_final_condition):
>>>         play_bingo()
>>
>> How about:
>>
>>   continue_playing = (
>>       some_condition and
>>       some_other_condition and
>>       some_final_condition
>>   )
>>
>>   if continue_playing:
>>       play_bingo()
>>
>> or:
>>
>>   play_conditions = [
>>       some_condition,
>>       some_other_condition,
>>       some_final_condition,
>>   ]
>>
>>   if all(play_conditions):
>>       play_bingo()
>
> Those feel like warping your code around the letter of the law,
> without really improving anything.

I beg to differ. If an expression is long or complex then splitting it
up and, importantly, giving good names to the intermediates makes the
code clearer. That advice is not restricted to if statements.

-- 
Pete Forman

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

#103918

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

On 03/02/2016 04:54 PM, Chris Angelico wrote:
> On Thu, Mar 3, 2016 at 10:46 AM,  <codewizard@gmail.com> wrote:
>> On Wednesday, March 2, 2016 at 3:44:07 PM UTC-5, Skip Montanaro wrote:
>>>
>>>     if (some_condition and
>>>         some_other_condition and
>>>         some_final_condition):
>>>         play_bingo()
>>
>> How about:
>>
>>   continue_playing = (
>>       some_condition and
>>       some_other_condition and
>>       some_final_condition
>>   )
>>
>>   if continue_playing:
>>       play_bingo()
>>
>> or:
>>
>>   play_conditions = [
>>       some_condition,
>>       some_other_condition,
>>       some_final_condition,
>>   ]
>>
>>   if all(play_conditions):
>>       play_bingo()
> 
> Those feel like warping your code around the letter of the law,
> without really improving anything.

Not at all! Taking a series of boolean-joined conditions and giving the
combined condition a single name is often a major improvement in
readability. Not primarily for code-layout reasons, but because it
forces you to name the concept (e.g. "continue_playing" here.)

I often find that the best answer to "how do I wrap this long line?" is
"don't, instead extract a piece of it and give that its own name on its
own line(s)." The extracted piece might be a new variable or even a new
function. The pressure to do this type of refactor more frequently is
one reason I continue to prefer relatively short (80 char) line length
limits.

This is closely related to the XP guideline "when you're tempted to add
a comment, instead extract that bit of code into a function or variable
and give it a name that clarifies the same thing the comment would have."

Names are important!

Carl

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

#103925

On Thu, 3 Mar 2016 11:02 am, Carl Meyer wrote:

> On 03/02/2016 04:54 PM, Chris Angelico wrote:
>> On Thu, Mar 3, 2016 at 10:46 AM,  <codewizard@gmail.com> wrote:
>>> On Wednesday, March 2, 2016 at 3:44:07 PM UTC-5, Skip Montanaro wrote:
>>>>
>>>>     if (some_condition and
>>>>         some_other_condition and
>>>>         some_final_condition):
>>>>         play_bingo()
>>>
>>> How about:
>>>
>>>   continue_playing = (
>>>       some_condition and
>>>       some_other_condition and
>>>       some_final_condition
>>>   )
>>>
>>>   if continue_playing:
>>>       play_bingo()
>>>
>>> or:
>>>
>>>   play_conditions = [
>>>       some_condition,
>>>       some_other_condition,
>>>       some_final_condition,
>>>   ]
>>>
>>>   if all(play_conditions):
>>>       play_bingo()
>> 
>> Those feel like warping your code around the letter of the law,
>> without really improving anything.
> 
> Not at all! Taking a series of boolean-joined conditions and giving the
> combined condition a single name is often a major improvement in
> readability. Not primarily for code-layout reasons, but because it
> forces you to name the concept (e.g. "continue_playing" here.)

If you only use "continue_playing" in exactly one place, then it doesn't
deserve a name. You wouldn't write:

the_index = x + 1
value = sequence[the_index]

would you? 

> Names are important!

Too important to waste on every single-use expression.




-- 
Steven

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

#103927

Steven D'Aprano <steve@pearwood.info> writes:

> If you only use "continue_playing" in exactly one place, then it
> doesn't deserve a name.

I disagree. If it's complex, then it may still deserve a name.

> > Names are important!
>
> Too important to waste on every single-use expression.

To waste on *every* single-use expression? Of course. No one was
advocating that.

The point is to bind a descriptive name to a *complex* expression, if
doing so will clarify the semantic intent of that expression.

If your functions are so long that you fear using a specific name will
deter you from using it again *in the same scope*, then the name isn't
descriptive and a better one should be chosen, or the function is too
large and should be broken into smaller pieces.

-- 
 \      “The history of Western science confirms the aphorism that the |
  `\     great menace to progress is not ignorance but the illusion of |
_o__)            knowledge.” —Daniel J. Boorstin, historian, 1914–2004 |
Ben Finney

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

#103928

On Thu, Mar 3, 2016 at 1:30 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
> If your functions are so long that you fear using a specific name will
> deter you from using it again *in the same scope*, then the name isn't
> descriptive and a better one should be chosen, or the function is too
> large and should be broken into smaller pieces.

It's not just name collisions. You should be able to keep in your head
every local name in a section of code. Giving a name to a single-use
expression wastes one of those precious slots in your mind, even if
it's easily and safely unique.

ChrisA

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

#103932

On 03/02/2016 06:33 PM, Chris Angelico wrote:

> It's not just name collisions. You should be able to keep in your head
> every local name in a section of code. Giving a name to a single-use
> expression wastes one of those precious slots in your mind, even if
> it's easily and safely unique.

If it's a single-use name I stop remembering after its single use.

--
~Ethan~

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

#103920

(Igor, your “From” field doesn't contain a name for you. Can you put
your name, e.g. “Igor Whateverisyoursurname”, in the “From” field?)

codewizard@gmail.com writes:

> How about:
>
>   continue_playing = (
>       some_condition and
>       some_other_condition and
>       some_final_condition
>   )
>
>   if continue_playing:
>       play_bingo()
>
> or:
>
>   play_conditions = [
>       some_condition,
>       some_other_condition,
>       some_final_condition,
>   ]
>
>   if all(play_conditions):
>       play_bingo()

Yes, these are good. When a condition is too complex, it makes sense to
assign a name to it. It can even help to pull out a coherent part of the
complex condition and assign a name to that::

    play_conditions = [
            some_other_condition,
            some_extra_condition,
            (some and compound and condition)]

    if some_condition and all(play_conditions):
        play_bingo()

-- 
 \        “Perchance you who pronounce my sentence are in greater fear |
  `\   than I who receive it.” —Giordano Bruno, burned at the stake by |
_o__)  the Catholic church for the heresy of heliocentrism, 1600-02-16 |
Ben Finney

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

#103954

codewizard@gmail.com wrote:
> On Wednesday, March 2, 2016 at 3:44:07 PM UTC-5, Skip Montanaro wrote:
> > 
> >     if (some_condition and
> >         some_other_condition and
> >         some_final_condition):
> >         play_bingo()
> 
> How about:
> 
>   continue_playing = (
>       some_condition and
>       some_other_condition and
>       some_final_condition
>   )
> 
>   if continue_playing:
>       play_bingo()
> 
> or:
> 
>   play_conditions = [
>       some_condition,
>       some_other_condition,
>       some_final_condition,
>   ]
> 
>   if all(play_conditions):
>       play_bingo()
> 
I'd much prefer the [] and () to be aligned so I can check that
beginnings have ends.  Similarly in C I prefer:-

    if ( x == y )
    {
        z = 99;
    }

rather than:-

    if ( x == y ) {
        z = 99;
    }

Apparently the second is/was only popular because it uses fewer lines
and thus more code would appear on a single screen.

-- 
Chris Green
·

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web