Re: Continuing indentation

[Steven D'Aprano]

On Sat, 5 Mar 2016 08:14 am, sohcahto...@gmail.com wrote:

> I wouldn't call PEP 8 "correct".  I would say that you just simply agree
> with PEP 8's suggestion.
> 
> You guys are spending way too much time fighting over something that is
> clearly subjective.  Nobody is "correct" here.  There's no right and
> wrong, just simple preference.

Your point is taken, but I think there is an objectively better style. Or at
least there may be an objectively better style. 

Of course, coming up with an objective definition of what is meant
by "better", and performing UI testing to determine which style is better,
is a lot of hard work for marginal gain. It's much more fun to just flame
each other :-)



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Ben Finney]

srinivas devaki  writes:

> thought i should add this here so that people will get to this after
> someone decides a standard way to do this :P

No, you've wasted that effort. If you want a request to be acted on by
those who maintain the official Python source, submit it to the official
Python bug tracker. Here, it will simply be ignored.

-- 
 \ “We live in capitalism. Its power seems inescapable. So did the |
  `\   divine right of kings.” —Ursula K. LeGuin, National Book Awards |
_o__)acceptance speech, 2014-11-19 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[srinivas devaki]

thought i should add this here so that people will get to this after
someone decides a standard way to do this :P

look for second if condition in the source code of
subprocess.Popen(*args, **kwargs).communicate

def communicate(self, input=None, timeout=None):
"""Interact with process: Send data to stdin.  Read data from
stdout and stderr, until end-of-file is reached.  Wait for
process to terminate.

The optional "input" argument should be data to be sent to the
child process (if self.universal_newlines is True, this should
be a string; if it is False, "input" should be bytes), or
None, if no data should be sent to the child.

communicate() returns a tuple (stdout, stderr).  These will be
bytes or, if self.universal_newlines was True, a string.
"""

if self._communication_started and input:
raise ValueError("Cannot send input after starting communication")

# Optimization: If we are not worried about timeouts, we haven't
# started communicating, and we have one or zero pipes, using select()
# or threads is unnecessary.
if (timeout is None and not self._communication_started and
[self.stdin, self.stdout, self.stderr].count(None) >= 2):
stdout = None
stderr = None
if self.stdin:
self._stdin_write(input)
elif self.stdout:
stdout = self.stdout.read()
self.stdout.close()
elif self.stderr:
stderr = self.stderr.read()
[. extra code snapped]

ps: Python3.5.1


On Sat, Mar 5, 2016 at 8:19 AM, Tim Chase  wrote:
> On 2016-03-04 17:17, sohcahto...@gmail.com wrote:
>> x \
>> = \
>> 5
>> if \
>> y \
>> == \
>> z:
>> print \
>> 'this is terrible'
>> print \
>> 'but still not incorrect
>>
>> It would be terrible, still but not incorrect.
>
> And has the sociopathic benefit that the diffs make it quite clear
> what changed.  None of this
> looking-deep-into-lines-to-see-what-changed.
>
>   x \
>   = \
>   5
>   if \
>   y \
> - != \
> + == \
>   z:
>   print \
>   'this is terrible'
>   print \
>   'but still not incorrect
>
> Still terrible.  But not quite as useless as a knee-jerk reaction
> might suggest.
>
> I actually hacked together a binary-diff something like this,
> emitting every hex-formatted byte of each file on its own line, then
> diffing the two results.  I could see doing something similar to diff
> Python ASTs.
>
> -tkc
>
>
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list



-- 
Regards
Srinivas Devaki
Junior (3rd yr) student at Indian School of Mines,(IIT Dhanbad)
Computer Science and Engineering Department
ph: +91 9491 383 249
telegram_id: @eightnoteight
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Tim Chase]

On 2016-03-04 17:17, sohcahto...@gmail.com wrote:
> x \
> = \
> 5
> if \
> y \
> == \
> z:
> print \
> 'this is terrible'
> print \
> 'but still not incorrect
> 
> It would be terrible, still but not incorrect.

And has the sociopathic benefit that the diffs make it quite clear
what changed.  None of this
looking-deep-into-lines-to-see-what-changed.

  x \
  = \
  5
  if \
  y \
- != \
+ == \
  z:
  print \
  'this is terrible'
  print \
  'but still not incorrect

Still terrible.  But not quite as useless as a knee-jerk reaction
might suggest.

I actually hacked together a binary-diff something like this,
emitting every hex-formatted byte of each file on its own line, then
diffing the two results.  I could see doing something similar to diff
Python ASTs.

-tkc




-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Ben Finney]

sohcahto...@gmail.com writes:

> Arguing whether or not a style guide is "incorrect" is as silly as
> arguing over whether lima beans are delicious. I think they're
> disgusting, but you can't make a statement of fact about the topic.

Yet there *are* many relevant facts that bear on the choice of one style
over another.

Objective facts about human capacity to comprehend program text.
Objective facts about the intended semantics of a syntactic structure.
Objective facts about how commonly one style is used in deployed code.

Many objective facts exist that are relevant to the choices in a style
guide. Those facts may be infeasible to *measure* with our limited
access to code bases, and limited resources available for such research.
That doesn't take away from the objective nature of what is actually
factual for a criterion.

So it isn't a pure matter of taste and preference, as some assert.

Yet, when facts are too difficult to ascertain, or when in fact several
styles are equally “good” by whatever objective criteria we might choose
— then deciding that specific matter based on some person's preference
can be quite reasonable, in pursuit of *some* single style which will
allow consistency across a code base.

> Style guides are just guides. They're a suggestion. You can agree with
> them or disagree with them.

Right. The power of such a guide comes from whether, and how, it is
enforced within a particular community.

Don't make the mistake of thinking there are *no* relevant objective
facts to discuss, though.

> I just can't understand why so many people get their panties all up in
> a bunch over how other people choose to format their code.

One factor is that we know (objectively!) that there are many relevant
objective facts to be known; paired with a paucity of actual verifiable
research into those facts available for us to apply to these discussions.

People's personal prejudices start to weigh heavily in those
circumstances.

Yet we can neither say “just do whatever you like” (because too much
inconsistency is a huge cost that is what leads us to write style guides
in the first place), nor can we say “it's all subjective, pick one and
stop arguing” (because that's just not true, there are plenty of
relevant facts that bear on the matter of choosing a style).


What we do need is the wisdom to recognise – when several styles have
good arguments supporting them and no objective facts can help decide
between them – *at what point* should we stop arguing that specific
issue, and just pick a style and stick with it.

Choosing too soon risks dismissing relevant facts that can demonstrate
one style is substantially better than the chosen style.

Choosing too late can allow a community to become weary of ever
discussing style issues again, or of arguing past the point of reason,
or of subverting cohesion by violating the style guide, or resenting it.

All of which loses the unified approach which was the whole point of
working on a style guide in the first place. Wisdom is needed to avoid
that.

I don't have a good general answer.

-- 
 \  “Faith is generally nothing more than the permission religious |
  `\ people give to one another to believe things strongly without |
_o__)  evidence.” —Sam Harris, _Letter to a Christian Nation_ 2006 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Ethan Furman]

On 03/04/2016 05:17 PM, sohcahto...@gmail.com wrote:


I just can't understand why so many people get their panties all up in a bunch 
over how other people choose to format their code.


s/panties/undies/g

;)

--
~Ethan~

--
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Erik]

Hi Ben,

On 05/03/16 01:05, Ben Finney wrote:

Certainly you are allowed. You should not expect that suggestion to be
compelling unless it is accompanied by *factual*, rather than emotive,
argument.


I thought I had done that. I pointed out that LHS (whitespace) is 
significant when it comes to code structure but RHS seems significant 
when it comes to a condition structure (according to this PEP's 
recommendation). That inconsistency was my argument in the message you 
responded to.



That may be enough to rule
out the option you are suggesting, because we're not starting from a
blank slate of no existing code.


And that's fair enough. I certainly have no desire to argue this until 
everyone agrees with me (which is what some people are accusing me of) - 
I'm just replying to those who keep saying "because PEP8".


I'm done with this thread.

BR,
E.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[sohcahtoa82]

On Friday, March 4, 2016 at 4:43:57 PM UTC-8, Simon Ward wrote:
> On 4 March 2016 23:31:43 GMT+00:00, Erik  wrote:
> >On 04/03/16 21:14, sohcahto...@gmail.com wrote:
> >> You guys are spending way too much time fighting over something that
> >is clearly subjective.  Nobody is "correct" here.  There's no right and
> >wrong, just simple preference.
> >
> >I will take that as a vote +1 that PEP8 is wrong (*). ;)
> >
> >E.
> >
> >(*) PEP8 defines a specific format and you are stating that no specific
> >
> >format can be considered correct.
> 
> Style guides are always going to be considered incorrect by some people, but 
> they should aim more for consistency (the hobgoblin that may be), which is 
> what makes code easier to grok. Stop arguing, start thinking about others who 
> will have to read your code. What is better in your subjective opinion means 
> very little. Having commonly understandable style is what matters, and what 
> style guides help (including PEP8).
> 
> Simon
> -- 
> Sent from Kaiten Mail. Please excuse my brevity.

Arguing whether or not a style guide is "incorrect" is as silly as arguing over 
whether lima beans are delicious.  I think they're disgusting, but you can't 
make a statement of fact about the topic.

Style guides are just guides.  They're a suggestion.  You can agree with them 
or disagree with them.  If I write a guide that dictates that every line of 
code should only include necessary indentation, a single token, and then a line 
continuation backslash if necessary, so code looks like this:

x \
= \
5
if \
y \
== \
z:
print \
'this is terrible'
print \
'but still not incorrect

It would be terrible, still but not incorrect.

This argument about whether binary operators should go on the end of one line 
or the beginning of the next is the C/C++/C#/Java/etc. fight about braces all 
over again.  It is entirely subjective, and I find it absolutely ridiculous 
that so many people are willing to argue until they're blue in the face about 
it.

If you're doing your own project, do it however you like it and ignore anyone 
that tells you that you're doing it "wrong".  Not formatting your code to match 
PEP 8 doesn't make your code formatted wrong, it just means you're choosing not 
to follow PEP 8 to a T.  Personally, I hate underscores in variable names that 
aren't constants.  I much prefer myVariableName over my_variable_name.  I think 
using underscores creates a sort of white space that makes it harder to read.  
Do I think that people that use underscores are wrong?  No.  They just have a 
different opinion.

I just can't understand why so many people get their panties all up in a bunch 
over how other people choose to format their code.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Ben Finney]

Erik  writes:

> On 05/03/16 00:23, Simon Ward wrote:
> > Style guides are always going to be considered incorrect by some
> > people, but they should aim more for consistency (the hobgoblin that
> > may be), which is what makes code easier to grok.
>
> So you're saying that it doesn't matter if something is good or bad,
> as long as it's consistently so?

That's not my reading of the above. “X more than Y” does not dismiss the
importance of Y.

> Am I not allowed to suggest that the style guide is wrong in what it
> suggests?

Certainly you are allowed. You should not expect that suggestion to be
compelling unless it is accompanied by *factual*, rather than emotive,
argument.

If the advantage is small, you need to accept that the small advantage
will be weighed against the high cost of a long period of inconsistency
with existing, currently-conformant, code. That may be enough to rule
out the option you are suggesting, because we're not starting from a
blank slate of no existing code.

You also need to accept that many choices in a good style guide *will*
be on the basis of choosing among many good options, and thereby exclude
a number of good options from that guide.

It doesn't make those options un-good, it just means that conforming to
the style guide excludes those options.

-- 
 \ “For a sentimentalist is simply one who desires to have the |
  `\luxury of an emotion without paying for it.” —Oscar Wilde, _De |
_o__) Profundis_, 1897 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Ethan Furman]

On 03/04/2016 04:30 PM, Ben Finney wrote:> sohcahto...@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,
>>
>> 
>>
>> 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~


--
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Erik]

On 05/03/16 00:23, Simon Ward wrote:

Style guides are always going to be considered incorrect by some
people, but they should aim more for consistency (the hobgoblin that
may be), which is what makes code easier to grok.


So you're saying that it doesn't matter if something is good or bad, as 
long as it's consistently so? I don't agree. Am I not allowed to suggest 
that the style guide is wrong in what it suggests?


FWIW, my issue here is that the language defines that the structure of 
the code is strictly defined by the indentation on the LHS (which is a 
feature I like). This PEP recommends that the structure of the condition 
should be determined by the keywords appearing on the RHS. That, to me, 
is inconsistency. I would prefer it if the PEP suggested that the LHS is 
significant in this case also.


E.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Simon Ward]

On 4 March 2016 23:31:43 GMT+00:00, Erik  wrote:
>On 04/03/16 21:14, sohcahto...@gmail.com wrote:
>> You guys are spending way too much time fighting over something that
>is clearly subjective.  Nobody is "correct" here.  There's no right and
>wrong, just simple preference.
>
>I will take that as a vote +1 that PEP8 is wrong (*). ;)
>
>E.
>
>(*) PEP8 defines a specific format and you are stating that no specific
>
>format can be considered correct.

Style guides are always going to be considered incorrect by some people, but 
they should aim more for consistency (the hobgoblin that may be), which is what 
makes code easier to grok. Stop arguing, start thinking about others who will 
have to read your code. What is better in your subjective opinion means very 
little. Having commonly understandable style is what matters, and what style 
guides help (including PEP8).

Simon
-- 
Sent from Kaiten Mail. Please excuse my brevity.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Ben Finney]

sohcahto...@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,
>
> 
>
> 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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[sohcahtoa82]

On Friday, March 4, 2016 at 3:41:29 PM UTC-8, Ben Finney wrote:
> alister  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,



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...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Ethan Furman]

On 03/04/2016 03:45 PM, Mark Lawrence wrote:

> PEP8 is not a standard that must be adhered to under all
> cicumstances, it is only a style guide [...]

Not only that, it's a style guide for code /in the stdlib/.

Make your own style guide for your own projects.  ;)

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Mark Lawrence]

On 04/03/2016 23:31, Erik wrote:

On 04/03/16 21:14, sohcahto...@gmail.com wrote:

You guys are spending way too much time fighting over something that
is clearly subjective.  Nobody is "correct" here.  There's no right
and wrong, just simple preference.


I will take that as a vote +1 that PEP8 is wrong (*). ;)

E.

(*) PEP8 defines a specific format and you are stating that no specific
format can be considered correct.



PEP8 is not a standard that must be adhered to under all cicumstances, 
it is only a style guide, hence:-



A style guide is about consistency. Consistency with this style guide is 
important. Consistency within a project is more important. Consistency 
within one module or function is the most important.


However, know when to be inconsistent -- sometimes style guide 
recommendations just aren't applicable. When in doubt, use your best 
judgment. Look at other examples and decide what looks best. And don't 
hesitate to ask!



--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Ben Finney]

alister  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, so have to make a
choice. And, for consistency, we are motivated to set one style and
disallow the other.

Our mistake, I think, is to draw the inference that, because one style
has been chosen, it means the excluded styles do not have merit.

That inference is IMO unfounded. It may be that there are multiple
styles which could be justifiably chosen, and no option clearly superior
to all others.

I think this case – where to put the binary operator when breaking
an expression over a line break – is one where the style guide should
not be taken as advocating on the basis of superiority, but only having
chosen one for consistency.

-- 
 \   “Working out the social politics of who you can trust and why |
  `\  is, quite literally, what a very large part of our brain has |
_o__)   evolved to do.” —Douglas Adams |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Erik]

On 04/03/16 21:14, sohcahto...@gmail.com wrote:

You guys are spending way too much time fighting over something that is clearly 
subjective.  Nobody is "correct" here.  There's no right and wrong, just simple 
preference.


I will take that as a vote +1 that PEP8 is wrong (*). ;)

E.

(*) PEP8 defines a specific format and you are stating that no specific 
format can be considered correct.


--
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Mark Lawrence]

On 04/03/2016 21:14, sohcahto...@gmail.com wrote:

On Friday, March 4, 2016 at 6:03:48 AM UTC-8, alister wrote:

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


Steven D'Aprano  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.


I wouldn't call PEP 8 "correct".  I would say that you just simply agree with 
PEP 8's suggestion.

You guys are spending way too much time fighting over something that is clearly 
subjective.  Nobody is "correct" here.  There's no right and wrong, just simple 
preference.



+1

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[sohcahtoa82]

On Friday, March 4, 2016 at 6:03:48 AM UTC-8, alister wrote:
> On Fri, 04 Mar 2016 10:12:58 +, cl wrote:
> 
> > Steven D'Aprano  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.

I wouldn't call PEP 8 "correct".  I would say that you just simply agree with 
PEP 8's suggestion.

You guys are spending way too much time fighting over something that is clearly 
subjective.  Nobody is "correct" here.  There's no right and wrong, just simple 
preference.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Ethan Furman]

On 03/04/2016 07:25 AM, Ian Kelly wrote:

On Fri, Mar 4, 2016 at 7:03 AM, alister  wrote:

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


Steven D'Aprano  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


I disagree. When I'm skimming over code, I find it unlikely that I'll
read the last token of the line. That's where trivialities like
arguments to function calls are found. It's much more likely that I'll
read the first token of the next line.


And, as any pythonista knows: The conditions aren't over until the 
indentation changes.  ;)


--
~Ethan~

--
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Ian Kelly]

On Fri, Mar 4, 2016 at 7:03 AM, alister  wrote:
> On Fri, 04 Mar 2016 10:12:58 +, cl wrote:
>
>> Steven D'Aprano  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

I disagree. When I'm skimming over code, I find it unlikely that I'll
read the last token of the line. That's where trivialities like
arguments to function calls are found. It's much more likely that I'll
read the first token of the next line.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[alister]

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

> Steven D'Aprano  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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[alister]

On Fri, 04 Mar 2016 10:23:37 +0900, 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

and that is to make it obvious that there is more to come.




-- 
Nonsense.  Space is blue and birds fly through it.
-- Heisenberg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[cl]

Steven D'Aprano  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
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Marko Rauhamaa]

Steven D'Aprano :

> 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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Steven D'Aprano]

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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Erik]

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.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[INADA Naoki]

>
>
> 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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Erik]

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.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[INADA Naoki]

>
>
> 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 t strict.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Steven D'Aprano]

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

> John Gordon :
> 
>> In <871t7sbkex@elektro.pacujo.net> Marko Rauhamaa
>>  writes:
>>
>>> Ethan Furman :
>>
>>> > 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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Marko Rauhamaa]

Rob Gaddi :

> 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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Rob Gaddi]

Marko Rauhamaa wrote:

> John Gordon :
>
>> In <871t7sbkex@elektro.pacujo.net> Marko Rauhamaa
>>  writes:
>>
>>> Ethan Furman :
>>
>>> > 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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Marko Rauhamaa]

John Gordon :

> In <871t7sbkex@elektro.pacujo.net> Marko Rauhamaa
>  writes:
>
>> Ethan Furman :
>
>> > 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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[John Gordon]

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

> Ethan Furman :

> > 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
gor...@panix.com  B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[cl]

codewiz...@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
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Tim Chase]

On 2016-03-03 08:29, Ben Finney wrote:
> Skip Montanaro  writes:
>> 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()
> 
> For this reason I prefer to indent all continuation lines 8 spaces::
> 
> if (
> some_condition and
> some_other_condition and
> some_final_condition):
> play_bingo()

This is generally what I do with two modifications, (1) putting
the conjunction at the beginning makes it easier for me to
read, and (2) putting the close-paren and colon on their own line to
make diffs cleaner when adding/removing conditions:

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

making my diffs look like

 if (
 some_condition
 and some_other_condition
 and some_additional_condition
+and some_new_condition
 ):
 play_bingo()

instead of

 if (
 some_condition
 and some_other_condition
-and some_additional_condition):
+and some_additional_condition
+and some_new_condition):
 play_bingo()

which is harder to follow, IMHO.

Though, as a side note, if I have lots of "and" or "or" conjunctions,
I tend to use any() or all() on a list of them:

 if all([
 some_condition,
 some_other_condition,
 some_additional_condition,
+some_new_condition,
 ]):
 play_bingo()

which I happen to find even tidier (though it might come at a minor
performance penalty, having not tested it since it's never mattered
in my code)

-tkc




-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Ethan Furman]

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~

--
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Chris Angelico]

On Thu, Mar 3, 2016 at 1:30 PM, Ben Finney  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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Ben Finney]

Steven D'Aprano  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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Steven D'Aprano]

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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Steven D'Aprano]

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

> Ethan Furman :
> 
>> 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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Ben Finney]

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

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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Pete Forman]

Chris Angelico  writes:

> On Thu, Mar 3, 2016 at 10:46 AM,   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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Carl Meyer]

On 03/02/2016 04:54 PM, Chris Angelico wrote:
> On Thu, Mar 3, 2016 at 10:46 AM,   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



signature.asc
Description: OpenPGP digital signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Chris Angelico]

On Thu, Mar 3, 2016 at 10:46 AM,   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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[codewizard]

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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Chris Angelico]

On Thu, Mar 3, 2016 at 9:10 AM, Marko Rauhamaa  wrote:
> Ethan Furman :
>
>> 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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Ethan Furman]

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~

--
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Ethan Furman]

On 03/02/2016 02:10 PM, Marko Rauhamaa wrote:

Ethan Furman :


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~
--
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Skip Montanaro]

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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Marko Rauhamaa]

Ethan Furman :

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

Why would you discourage valid syntax?


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Ethan Furman]

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~
--
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Ben Finney]

Skip Montanaro  writes:

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

For this reason I prefer to indent all continuation lines 8 spaces::

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

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

The style I recommend above is PEP 8 compliant, easy to read, remember,
and apply.

-- 
 \ “This [Bush] Administration is not sinking. This Administration |
  `\   is soaring. If anything they are rearranging the deck chairs on |
_o__) the Hindenburg.” —Steven Colbert, 2006-04-29 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Peter Otten]

Skip Montanaro wrote:

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

Manually inspecting the output of

$ cd /usr/lib/python3.4
$ find . -name \*.py -print0 | xargs -0 egrep 'if \([^:]+$' --color -A3

[...]

gives the impression that those who do care are a minority and that the most 
common workaround is an extra indent of four spaces.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Wolfgang Maier]

On 3/2/2016 21:43, Skip Montanaro wrote:

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?



I don't know about flake8, but pep8 says all these are acceptable though 
the first version (like yours) has the readability problem flake8 
complains about:


# No extra indentation.
if (this_is_one_thing and
that_is_another_thing):
do_something()

# Add a comment, which will provide some distinction in editors
# supporting syntax highlighting.
if (this_is_one_thing and
that_is_another_thing):
# Since both conditions are true, we can frobnicate.
do_something()

# Add some extra indentation on the conditional continuation line.
if (this_is_one_thing
and that_is_another_thing):
do_something()

Maybe version 2 would make the tool happy?


--
https://mail.python.org/mailman/listinfo/python-list

Re: Continuing indentation

[Marko Rauhamaa]

Skip Montanaro :

> 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
-- 
https://mail.python.org/mailman/listinfo/python-list