Most of this thread is all just so much opinion, so I have avoided chiming
in -- but as for opinion:
<histrionic>
A better way to list arguments is only one indentation level above the
> current:
>
> variable = some_class.method(
> argument=value,
> argument2=value)
>
God no! I HATE that style -- for me, it makes it MUCH harder to read --
even more so if the variable names are a bit longer.
But if you are going to do it, for the love of god, use more than four
spaces! four spaces is one indentation, one indentation is how a code block
is delineated in Python -- this is NOT a code block. It should not look
like one.
</histrionic>
By the way, this is much worse for, say, function definitions:
def a_function_with_lots_of_params(
param1,
param2,
kwarg1=something,
kwarg2=something_else):
now_a_line_of_code = this_thing()
How can anyone think that's more readable than (view with fixed-width font
if this email doesn't already do that for you):
def a_function_with_lots_of_params(param1,
param2,
kwarg1=something,
kwarg2=something_else):
now_a_line_of_code = this_thing()
This puts the parameter definitions over on the right, after the function
name, where they belong, and makes it very clear where the definition ends
and the function code begins. But if you HAVE to put it off to the left for
I don't know why, at least put some extra space in there:
def a_function_with_lots_of_params(
param1,
param2,
kwarg1=something,
kwarg2=something_else):
now_a_line_of_code = this_thing()
The parameters are still in an odd place, but at least it's clear where the
body of the function begins.
If you need more convincing, consider functions with fewer params, and how
they look compared to ones with many:
def a_function_with_few_params(param1, param2):
now_a_line_of_code = this_thing()
then:
def a_function_with_lots_of_params(
param1,
param2,
kwarg1=something,
kwarg2=something_else)
now_a_line_of_code = this_thing()
why am I looking in a different place for the parameters when there are
more of them??
Trying to match the indentation of the opening line is less readable
>
> variable = some_class.method(argument=value,
> argument2=value)
>
this is more readable to me :-)
> and less robust to refactoring:
> var = cls.method(argument=value,
> argument2=value)
>
well, that is an issue that I do face, but I blame it on my crappy tools :-)
But YAPF does it the way I like :-)
Except in the case of the "facebook" style -- yeach!)
https://yapf.now.sh/
Facebook style:
def a_function_with_lots_of_params(
param1, param2, kwarg1=something, kwarg2=something_else
):
now_a_line_of_code = this_thing()
Anyway, PEP8 is officially for the standard library, but it HAS become a
python-wide standard. As such, it simply needs to be flexible on some of
these opinionated issues -- so both of the above styles are OK, as is
adjusting your max line length up some.
So at most, I'd say rewording this:
"""
Some teams strongly prefer a longer line length. For code maintained
exclusively or primarily by a team that can reach agreement on this issue,
it is okay to increase the nominal line length from 80 to 100 characters
(effectively increasing the maximum length to 99 characters), provided that
comments and docstrings are still wrapped at 72 characters.
"""
To be a bit less harsh would be a fine idea -- that is, change the clause:
"For code maintained exclusively or primarily by a team that can reach
agreement on this issue, it is okay ..."
To maybe just
"For code maintained by a team that can reach agreement on this issue, it
is okay ..."
Then we can all go back to bike-shedding something else.
-CHB
PS -- I personally use 95 char per line :-)
--
Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
