[Python-ideas] Minor tweak to PEP 8?
Mike Meyer
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 <m...@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
_______________________________________________
Python-ideas mailing list
Python...@python.org
http://mail.python.org/mailman/listinfo/python-ideas
Mike Graham
> 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
Ben Finney
> 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
Steven Klass
Carl M. Johnson
Ben Finney
<cmjohnson....@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__) |
Mike Meyer
Ben Finney <ben+p...@benfinney.id.au> wrote:
> "Carl M. Johnson"
> <cmjohnson....@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 <m...@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
Ben Finney
> On Wed, 11 May 2011 13:50:42 +1000
> Ben Finney <ben+p...@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
Paul Moore
> 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.
Guido van Rossum
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)
Steven D'Aprano
> 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
Mike Meyer
Steven D'Aprano <st...@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 <m...@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
Steven D'Aprano
>> 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
Steven D'Aprano
> 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
M.-A. Lemburg
> 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/
Guido van Rossum
> 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)
Ben Finney
> 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
Gregory P. Smith
> 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)
>
>
Guido van Rossum
Guido van Rossum
patch by Steven Klass.
--Guido
On Wed, May 11, 2011 at 7:23 AM, Guido van Rossum <gu...@python.org> wrote:
Barry Warsaw
>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
Guido van Rossum
Yeah, please prepare a patch. Maybe you can send it to Barry so he can
check it in. I would use 4-space indent for the "Opt:" exanple at the
end though.
On Sat, Jun 4, 2011 at 9:03 AM, Steven Klass <skl...@pointcircle.com> wrote:
> Hey Barry,
> You are correct - it was an artifact from the email tool..
> Guido - it appears we are reaching some consensus. Thoughts? Did you want me
> to update the repo?
> Continuation lines should align wrapped elements either vertically
> using
> Python's implicit line joining inside parentheses, brackets and braces,
> or
> or using a hanging indent. When using a hanging indent the following
> considerations should be applied; there should be no arguments on the
> first line and further indentation should be used to clearly distinguish
> the itself as a continuation line.
>
> Yes: # Aligned with opening delimiter
> foo = long_function_name(var_one, var_two,
> var_three, var_four)
> # More indentation included to distiguish this from the rest.
> def long_function_name(
> var_one, var_two, var_three,
> var_four):
> print(var_one)
> No: # Stuff on first line forbidden when not using vertical alignment
> foo = long_function_name(var_one, var_two,
> var_three, var_four)
> # Further indentation required as indentation is not
> distiguishable
> def long_function_name(
> var_one, var_two, var_three,
> var_four):
> print(var_one)
>
> Opt: # Extra indentation not necessary.
> foo = long_function_name(
> var_one, var_two,
> var_three, var_four)
>
>
>
> On Fri, Jun 3, 2011 at 11:09 AM, Barry Warsaw <ba...@python.org> wrote:
>>
>> Hi Steven,
>>
>> On Jun 03, 2011, at 08:57 AM, Steven Klass wrote:
>>
>> > Continuation lines should align wrapped elements either vertically
>> > using
>> > Python's implicit line joining inside parentheses, brackets and
>> > braces,
>> > or or using a hanging indent. When using a hanging indent the
>> > following
>> > considerations should be applied; there should be no arguments on the
>> > first line and further indentation should be used to clearly
>> > distinguish
>> > the itself as a continuation line.
>> >
>> > Yes: # Aligned with opening delimiter
>> > foo = long_function_name(var_one, var_two,
>> > var_three, var_four)
>> -------------------------------------^
>> I'm sure that's just an email alignment bug, right?
>>
>> >
>> > # More indentation included to distiguish this from the rest.
>> > def long_function_name(
>> > var_one, var_two, var_three,
>> > var_four):
>> > print(var_one)
>> >
>> >
>> > No: # Stuff on first line forbidden when not using vertical
>> > alignment
>> > foo = long_function_name(var_one, var_two,
>> > var_three, var_four)
>> >
>> > # Further indentation required as indentation is not
>> > distiguishable
>> > def long_function_name(
>> > var_one, var_two, var_three,
>> > var_four):
>> > print(var_one)
>> >
>> >
>> >Thoughts?
>>
>> That looks great to me, thanks. I would add one more example to the 'Yes'
>> section to cover the case we've been talking about:
>>
>> # Extra indentation not necessary.
>> foo = long_function_name(
>> var_one, var_two,
>> var_three, var_four)
>>
>> This doesn't say that extra indentation isn't allowed, just that it's not
>> necessary, so I think it strikes the right balance.
>>
>> Cheers,
>> -Barry
>
>
>
> --
> ---
>
> Steven M. Klass
>
> ☎ 1 (480) 225-1112
> ✉ skl...@pointcircle.com
>
--
--Guido van Rossum (python.org/~guido)