[Christopher Barker] > 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.
Holly hell! I'm sorry I insulted your mother or whatever serious crime I committed. Yes, I agree that two levels of indentation is an improvement and is in-fact how I write function definitions. [Christopher Baker] > this is more readable to me :-) I wish you would have watched the video I linked <https://www.youtube.com/watch?v=B3b4tremI5o&t=7m45s> so I wouldn't have to make all the same arguments, but in the context of code running off the edge of a window, having the argument list hidden out there with arbitrary indentation is definitely a readability issue. [Christopher Baker] > This puts the parameter definitions over on the right, after the function > name, where they belong According to whom? [Christopher Baker] > 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'd seen my other replies in this very thread, you'd see that's exactly the style I use. [Christopher Baker] > well, that is an issue that I do face, but I blame it on my crappy tools > :-) I consider it a good thing that your tools don't facilitate bad coding style ;) This is just more Stockholm syndrome. Nowhere else will you see people consider cramming valuable information off into the right margin with arbitrary indentation "good design". You won't see it in prose. You won't see it in mathematical notation. You won't see it anywhere else. On Wed, Feb 20, 2019 at 8:42 PM Christopher Barker <python...@gmail.com> wrote: > 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/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
