PEP eight has an interesting omission in the "Code Layout" section. It doesn't say how to indent continuation lines when code is wrapped to comply with the line length limits. It has examples, but no textual guides. Which means you can do a rock-stupid word warp (with no indentation on the continuation lines), point at the resulting mess, and say "See? If we follow this part of the PEP, we get really ugly code!". Mail doing just that is what prompted this suggestion. I therefore propose adding a sentence or two to this section, something along the lines of: The continuation line(s) should be indented to reflect the structure of the statement being continued. This should be at least one space beyond the first open parenthesis that is not closed on the continued line, if present. Nothing hard and fast, just a requirement to use good sense and the minimal indent resulting from doing so. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On Tue, May 10, 2011 at 10:47 AM, Mike Meyer <mwm@mired.org> wrote:
PEP eight has an interesting omission in the "Code Layout" section. It doesn't say how to indent continuation lines when code is wrapped to comply with the line length limits. It has examples, but no textual guides. Which means you can do a rock-stupid word warp (with no indentation on the continuation lines), point at the resulting mess, and say "See? If we follow this part of the PEP, we get really ugly code!". Mail doing just that is what prompted this suggestion.
I therefore propose adding a sentence or two to this section, something along the lines of:
The continuation line(s) should be indented to reflect the structure of the statement being continued. This should be at least one space beyond the first open parenthesis that is not closed on the continued line, if present.
Nothing hard and fast, just a requirement to use good sense and the minimal indent resulting from doing so.
<mike
It is not shocking that you can be in technical compliance with PEP8 and have hideous code. PEP8 doesn't attempt to specify every existing case nor should it, which would be long and pedantic. I'm not sure anyone has bad enough taste for this omission to be problematic, so I'm -0 on the the proposal in general. For this actual rule, I am -1, as I think this is too limiting. Sometimes the indentation is too far and the best style is self.other_thing.some_long_method_name( foo, barMightBeSortOfLongNaturally, baz........ This approach also has the advantage of working well with variable-width typefaces. There are too many cases here that it would be silly to enumerate what style might be best and when. Mike
Mike Graham <mikegraham@gmail.com> writes:
For this actual rule, I am -1, as I think this is too limiting.
And often results in hideous code :-) I'm −1 also. Please don't make the indentation of continuation lines dependent on the content of the opening line.
Sometimes the indentation is too far and the best style is
self.other_thing.some_long_method_name( foo, barMightBeSortOfLongNaturally, baz........
I assume you meant a four-column (not three-column) additional indent. +1 if so, this matches the indentation style I advocate for continuation lines. -- \ “I believe in making the world safe for our children, but not | `\ our children's children, because I don't think children should | _o__) be having sex.” —Jack Handey | Ben Finney
+1 for this method self.some_insane_long_method_which_should_have_originator_shot( True, None, keyword = foobar) :-) On Tue, May 10, 2011 at 2:35 PM, Ben Finney <ben+python@benfinney.id.au>wrote:
Mike Graham <mikegraham@gmail.com> writes:
For this actual rule, I am -1, as I think this is too limiting.
And often results in hideous code :-)
I'm −1 also. Please don't make the indentation of continuation lines dependent on the content of the opening line.
Sometimes the indentation is too far and the best style is
self.other_thing.some_long_method_name( foo, barMightBeSortOfLongNaturally, baz........
I assume you meant a four-column (not three-column) additional indent.
+1 if so, this matches the indentation style I advocate for continuation lines.
-- \ “I believe in making the world safe for our children, but not | `\ our children's children, because I don't think children should | _o__) be having sex.” —Jack Handey | Ben Finney
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- Steven M. Klass ☎ 1 (480) 225-1112 ✉ sklass@pointcircle.com
Can we all at least agree that continuation lines should always be at least one space more indented than the parent line? So, for example, this would be right out: for item in items: modified_item = self.frobincation_with_spengulizer( item, True, False, spam=None) The arguments should at least line up with the o in modified, if not the f.
"Carl M. Johnson" <cmjohnson.mailinglist@gmail.com> writes:
Can we all at least agree that continuation lines should always be at least one space more indented than the parent line?
At least one standard (four-column) indentation level further than the opening line. If you think you need to break that so your multi-line string will have the right content, think again: use the ‘textwrap.dedent’ function <URL:http://stackoverflow.com/questions/2504411/proper-indentation-for-python-multiline-strings/2504454#2504454>. -- \ “Drop your trousers here for best results.” —dry cleaner, | `\ Bangkok | _o__) | Ben Finney
On Wed, 11 May 2011 13:50:42 +1000 Ben Finney <ben+python@benfinney.id.au> wrote:
"Carl M. Johnson" <cmjohnson.mailinglist@gmail.com> writes:
Can we all at least agree that continuation lines should always be at least one space more indented than the parent line?
At least one standard (four-column) indentation level further than the opening line.
Still overly strict. Consider: f(long_named_argument_one, calculated_value_two(with_arguments), another_argument) The two-space indent is perfectly reasonable here, as it aligns the first element (a function argument) with the same function's argument above it. In some cases, a similar one-space indent is also reasonable. I stand by my second proposal (reworded): Continuation lines should be indented to reflect the structure of the code. The indentation should either align with similar elements or match the surrounding source. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Mike Meyer <mwm@mired.org> writes:
On Wed, 11 May 2011 13:50:42 +1000 Ben Finney <ben+python@benfinney.id.au> wrote:
At least one standard (four-column) indentation level further than the opening line.
Still overly strict. Consider:
f(long_named_argument_one, calculated_value_two(with_arguments), another_argument)
The two-space indent is perfectly reasonable here
Maybe so; I'm not saying it's unreasonable. I'm saying it's *more* reasonable to not have the indentation level depend on the opening line. This generally involves breaking the opening line at a bracketing token, such as ‘"""’, ‘(’, ‘[’, etc., as Carl's suggestion showed, so there's no parameter on that line for lining up. Also, that function needs to be renamed to something more descriptive :-) -- \ “Kissing a smoker is like licking an ashtray.” —anonymous | `\ | _o__) | Ben Finney
On 11 May 2011 04:19, Carl M. Johnson <cmjohnson.mailinglist@gmail.com> wrote:
Can we all at least agree that continuation lines should always be at least one space more indented than the parent line?
Like it or not, some_string = """\ Text to be used for something incredibly exciting!""" is not uncommon. I know about textwrap.dedent, but having to use a Python function call to code a literal has always made me uncomfortable. I'm not saying it's right or wrong, just that there are reasonable arguments why it might be reasonable. What's wrong with just saying that continuation lines should be formatted as appropriate to ensure readability, and leave it at that? I know people have various standards of readability, but I'm willing to assume that PEP 8 is targeted at people with some level of common sense (anyone who is arguing "letter of the law" over something daft like the example that started the thread is clearly trolling and could find loopholes in anything, so why bother trying to convince them?) Paul.
At Google we use the following rule (from http://google-styleguide.googlecode.com/svn/trunk/pyguide.html#Indentation): Yes: # Aligned with opening delimiter foo = long_function_name(var_one, var_two, var_three, var_four) # 4-space hanging indent; nothing on first line foo = long_function_name( var_one, var_two, var_three, var_four) No: # Stuff on first line forbidden foo = long_function_name(var_one, var_two, var_three, var_four) # 2-space hanging indent forbidden foo = long_function_name( var_one, var_two, var_three, var_four) I propose we somehow incorporate these two allowed alternatives into PEP 8. They both serve a purpose. -- --Guido van Rossum (python.org/~guido)
Guido van Rossum wrote:
At Google we use the following rule (from http://google-styleguide.googlecode.com/svn/trunk/pyguide.html#Indentation):
Yes: # Aligned with opening delimiter foo = long_function_name(var_one, var_two, var_three, var_four)
I cringe whenever I see that. If people are going to bother lining things up other than at 4-space indents, they should at least line them up in a visually attractive place. The delimiter should surround the arguments, not line up with them: foo = long_function_name(var_one, var_two, var_three, var_four) although the effect may be spoiled if you're reading this in a non-monospaced font. This is analogous to the way that professional typesetters use handing punctuation: http://desktoppub.about.com/od/typelayout/ss/hangingquotes.htm "Li Europan lingues es membres del sam familie. Lor separat existentie es un myth. Por scientie, musica, sport etc, litot Europa usa li sam vocabular. Li lingues differe solmen in li grammatica, li pronunciation e li plu commun vocabules." compared to: "Li Europan lingues es membres del sam familie. Lor separat existentie es un myth. Por scientie, musica, sport etc, litot Europa usa li sam vocabular. Li lingues differe solmen in li grammatica, li pronunciation e li plu commun vocabules." On the other hand, there's a good argument for not spending the time to neatly line up blocks of code (other than at the usual multiples of four spaces), whether it is to the delimiter or not. It's the same argument against doing this: fee_fi_fo_fum = "something" # Align the equals foo = "something else" # and/or the hashes. When actively changing code lined up like that, you can easily spend more time aligning things than programming. I have a hard time reconciling the advice in PEP 8 against such alignments with the current suggestion. -- Steven
Steven D'Aprano wrote:
Guido van Rossum wrote:
At Google we use the following rule (from http://google-styleguide.googlecode.com/svn/trunk/pyguide.html#Indentation):
Yes: # Aligned with opening delimiter foo = long_function_name(var_one, var_two, var_three, var_four)
I cringe whenever I see that. If people are going to bother lining things up other than at 4-space indents, they should at least line them up in a visually attractive place. The delimiter should surround the arguments, not line up with them:
foo = long_function_name(var_one, var_two, var_three, var_four)
See the link Guido posted: that's what they use. Looks like the MUA dropped a blank or there was a tab/space issue involved. Whitespace tends to be mysterious sometimes ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 11 2011)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
2011-06-20: EuroPython 2011, Florence, Italy 40 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Wed, May 11, 2011 at 2:44 PM, Steven D'Aprano <steve@pearwood.info> wrote:
Guido van Rossum wrote:
At Google we use the following rule (from
http://google-styleguide.googlecode.com/svn/trunk/pyguide.html#Indentation):
Yes: # Aligned with opening delimiter foo = long_function_name(var_one, var_two, var_three, var_four)
I cringe whenever I see that. If people are going to bother lining things up other than at 4-space indents, they should at least line them up in a visually attractive place. The delimiter should surround the arguments, not line up with them:
foo = long_function_name(var_one, var_two, var_three, var_four)
although the effect may be spoiled if you're reading this in a non-monospaced font.
I used rich text in gmail and it looks aligned to me. Sorry if it doesn't for you; as MAL said, follow the link to see how it's supposed to look.
This is analogous to the way that professional typesetters use handing punctuation:
http://desktoppub.about.com/od/typelayout/ss/hangingquotes.htm
"Li Europan lingues es membres del sam familie. Lor separat existentie es un myth. Por scientie, musica, sport etc, litot Europa usa li sam vocabular. Li lingues differe solmen in li grammatica, li pronunciation e li plu commun vocabules."
compared to:
"Li Europan lingues es membres del sam familie. Lor separat existentie es un myth. Por scientie, musica, sport etc, litot Europa usa li sam vocabular. Li lingues differe solmen in li grammatica, li pronunciation e li plu commun vocabules."
On the other hand, there's a good argument for not spending the time to neatly line up blocks of code (other than at the usual multiples of four spaces), whether it is to the delimiter or not.
Emacs automatically does this for me. I spend zero time aligning code.
It's the same argument against doing this:
fee_fi_fo_fum = "something" # Align the equals foo = "something else" # and/or the hashes.
When actively changing code lined up like that, you can easily spend more time aligning things than programming.
I have a hard time reconciling the advice in PEP 8 against such alignments with the current suggestion.
Hardly; that is about spaces *between* tokens. This is about indentation. The amount of degradation in non-monospace fonts is quite different. Indentation still looks indented, just not aligned with [the first character inside] the open parenthesis, whereas internal spaces look completely jumbled. IF PEP 8 was still mine I would add this specific rule from the Google style guide. If people want to bikeshed it to death, go ahead, I will probably mute the thread. -- --Guido van Rossum (python.org/~guido)
Guido van Rossum <guido@python.org> writes:
Yes: # Aligned with opening delimiter foo = long_function_name(var_one, var_two, var_three, var_four)
This is needlessly dependent on the content of the opening line; if that changes, the rest need to change. It begs for the indentation to get mis-aligned when other lines are edited.
# 4-space hanging indent; nothing on first line foo = long_function_name( var_one, var_two, var_three, var_four)
This one doesn't have the previous problem, which is why it's what I recommend. I would be happy to see the latter explicitly recommended in PEP 8. If the price of that is to have the former also recommended, I'd grumble but it would be an improvement.
No: # Stuff on first line forbidden foo = long_function_name(var_one, var_two, var_three, var_four)
# 2-space hanging indent forbidden foo = long_function_name( var_one, var_two, var_three, var_four)
I agree with pointing to both of these as bad examples. -- \ “People demand freedom of speech to make up for the freedom of | `\ thought which they avoid.” —Soren Aabye Kierkegaard (1813–1855) | _o__) | Ben Finney
On Wed, May 11, 2011 at 7:23 AM, Guido van Rossum <guido@python.org> wrote:
At Google we use the following rule (from http://google-styleguide.googlecode.com/svn/trunk/pyguide.html#Indentation):
Yes: # Aligned with opening delimiter foo = long_function_name(var_one, var_two, var_three, var_four)
# 4-space hanging indent; nothing on first line foo = long_function_name( var_one, var_two, var_three, var_four)
and note that this should be "8-space hanging indent" if it goes into pep8. The rule is really "double your code indentation hanging indent" so that you can never confuse the two visually. it works well.
No: # Stuff on first line forbidden foo = long_function_name(var_one, var_two, var_three, var_four)
# 2-space hanging indent forbidden foo = long_function_name( var_one, var_two, var_three, var_four)
I propose we somehow incorporate these two allowed alternatives into PEP 8. They both serve a purpose.
-- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
Indeed. Somebody update PEP 8 please! On Sat, May 14, 2011 at 11:51 AM, Gregory P. Smith <greg@krypto.org> wrote:
On Wed, May 11, 2011 at 7:23 AM, Guido van Rossum <guido@python.org> wrote:
At Google we use the following rule (from http://google-styleguide.googlecode.com/svn/trunk/pyguide.html#Indentation):
Yes: # Aligned with opening delimiter foo = long_function_name(var_one, var_two, var_three, var_four)
# 4-space hanging indent; nothing on first line foo = long_function_name( var_one, var_two, var_three, var_four)
and note that this should be "8-space hanging indent" if it goes into pep8. The rule is really "double your code indentation hanging indent" so that you can never confuse the two visually. it works well.
No: # Stuff on first line forbidden foo = long_function_name(var_one, var_two, var_three, var_four)
# 2-space hanging indent forbidden foo = long_function_name( var_one, var_two, var_three, var_four)
I propose we somehow incorporate these two allowed alternatives into PEP 8. They both serve a purpose.
-- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- --Guido van Rossum (python.org/~guido)
FYI, I've submitted this change to PEP 8, with the help of a draft patch by Steven Klass. --Guido On Wed, May 11, 2011 at 7:23 AM, Guido van Rossum <guido@python.org> wrote:
At Google we use the following rule (from http://google-styleguide.googlecode.com/svn/trunk/pyguide.html#Indentation):
Yes: # Aligned with opening delimiter foo = long_function_name(var_one, var_two, var_three, var_four)
# 4-space hanging indent; nothing on first line foo = long_function_name( var_one, var_two, var_three, var_four)
No: # Stuff on first line forbidden foo = long_function_name(var_one, var_two, var_three, var_four)
# 2-space hanging indent forbidden foo = long_function_name( var_one, var_two, var_three, var_four)
I propose we somehow incorporate these two allowed alternatives into PEP 8. They both serve a purpose.
-- --Guido van Rossum (python.org/~guido)
-- --Guido van Rossum (python.org/~guido)
On Jun 02, 2011, at 11:11 AM, Guido van Rossum wrote:
FYI, I've submitted this change to PEP 8, with the help of a draft patch by Steven Klass.
Thanks Guido. This is probably the right mailing list to follow up to (ignore my python-dev followup to the -checkins message). I agree with the change, except for the recommendation to double-indent. Yes, double-indent does look better with Google's 2-space indentation level rule, but it looks excessive (to my eyes anyway) with a 4-space rule. One indentation level looks fine. I posted some examples to python-dev. Is it worth softening the PEP 8 recommendation on double-indents? Cheers, -Barry
On Wed, May 11, 2011 at 7:23 AM, Guido van Rossum <guido-+ZN9ApsXKcEdnm+yROfE0A@public.gmane.org> wrote:
At Google we use the following rule (from http://google-styleguide.googlecode.com/svn/trunk/pyguide.html#Indentation):
Yes: # Aligned with opening delimiter foo = long_function_name(var_one, var_two, var_three, var_four)
# 4-space hanging indent; nothing on first line foo = long_function_name( var_one, var_two, var_three, var_four)
No: # Stuff on first line forbidden foo = long_function_name(var_one, var_two, var_three, var_four)
# 2-space hanging indent forbidden foo = long_function_name( var_one, var_two, var_three, var_four)
I propose we somehow incorporate these two allowed alternatives into PEP 8. They both serve a purpose.
-- --Guido van Rossum (python.org/~guido)
Paul Moore wrote:
What's wrong with just saying that continuation lines should be formatted as appropriate to ensure readability, and leave it at that?
+1 I think that specifying exactly how to indent continuation lines, or even whether or not to indent them, is way too controlling for my tastes. I don't believe it makes that much difference. Like the brace wars, if there actually was any objective, meaningful, consistent benefit of one style over the others, there would be no argument about it. Instead, it's all subjective, vague, and far from consistent. -- Steven
On Thu, 12 May 2011 00:54:32 +1000 Steven D'Aprano <steve@pearwood.info> wrote:
Paul Moore wrote:
What's wrong with just saying that continuation lines should be formatted as appropriate to ensure readability, and leave it at that? +1
-1. This sentiment is adequately expressed by the "A Foolish Consistency ..." section. It shouldn't need repeating.
I think that specifying exactly how to indent continuation lines, or even whether or not to indent them, is way too controlling for my tastes. I don't believe it makes that much difference. Like the brace wars, if there actually was any objective, meaningful, consistent benefit of one style over the others, there would be no argument about it. Instead, it's all subjective, vague, and far from consistent.
If you don't believe it makes much different "whether or not to indent them", I suggest you align all continuation lines on the left hand side of the page in code you have to maintain and then report back to us. As for there being no benefit for one choice over another - that's true about almost everything in the PEP (four space indent instead of tabs? 80 character or 79 characters lines? spaces around = with exceptions? No spaces before/after "." and after open parens or before close parens? etc.). The goal is consistency. The important thing isn't so much what we choose as that we choose something so it'll be consistent when it doesn't make any difference. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Mike Meyer wrote:
I think that specifying exactly how to indent continuation lines, or even whether or not to indent them, is way too controlling for my tastes. I don't believe it makes that much difference. Like the brace wars, if there actually was any objective, meaningful, consistent benefit of one style over the others, there would be no argument about it. Instead, it's all subjective, vague, and far from consistent.
If you don't believe it makes much different "whether or not to indent them", I suggest you align all continuation lines on the left hand side of the page in code you have to maintain and then report back to us.
In general, that would be an *outdent*, rather than not indenting. As a matter of fact, there is at least one situation where I don't indent continuation lines: if condition: do_something("some long piece of text, most likely" " but not always an error message, which uses implicit" " concatenation over multiple lines blah blah blah blah" % spam) # and it's perfectly maintainable, thanks for asking. The fact that I have bare strings (with a leading space) and/or a binary operator is more than enough clue that the lines form a block. Indenting would be superfluous, and counter-productive, as it would reduce the space available on each line. -- Steven
participants (11)
-
Barry Warsaw -
Ben Finney -
Carl M. Johnson -
Gregory P. Smith -
Guido van Rossum -
M.-A. Lemburg -
Mike Graham -
Mike Meyer -
Paul Moore -
Steven D'Aprano -
Steven Klass