On Wed, Feb 20, 2019 at 10:57 PM Abe Dillon <abedil...@gmail.com> wrote:
> I wish you would have watched the video I linked > <https://www.youtube.com/watch?v=B3b4tremI5o&t=7m45s> > that is an hour and 7 minute video! And I did watch some of it, and do agree with much of it. By the way, everyone should watch one of Jack Diederich's "naming things once videos as well: https://www.youtube.com/watch?v=hZ7hgYKKnF0 > but in the context of code running off the edge of a window, > I never said anything about running off the edge of the window -- if you put all your parameters on their own line, and don't use insanely long names, that will not be an issue. Keeping it to 72 chars is virtually never a problem. > having the argument list hidden out there > nothing hidden about it --it's exactly where a single argument would be -- does anyone advocate putting a single parameter or argument on the next line? But my core point really was these are all matter of opiniion, and it's a godo thing that PEP 8 allows some variation. > This puts the parameter definitions over on the right, after the function >> name, where they belong > > > According to whom? > According to me, of course. But it is wehre a single parameter would be, yes? > [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. > I've lost track of who advocates what style, but I was responding to someone that specifically advocated one level of indentation -- which is really the worst option. [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 ;) > mostly they don't facilitate any of these styles in this context (I've been meaning to write a plugin for sublime that does, but haven't gotten around to it ). But the point is that handling indenting is really something the tools should do for you -- choosing a style for "ease of refactoring" should be pointless. > This is just more Stockholm syndrome. > honestly, I haven't chooses this style due to having been forced (or even encouraged) to use it -- I spend more time re-aligning code to make it the way I want it -- so no, I"ve come on this 'cuse it fits my brain better. > Nowhere else will you see people consider cramming valuable information > off into the right margin with arbitrary indentation "good design". > It's not the margin, and it's not arbitrary. > You won't see it in prose. You won't see it in mathematical notation. You > won't see it anywhere else. > Actually, I"ve seen in it math, where you have an "array" of equations, and > tabular information with columns on the right being important is not the > least bit rare. > > 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. > I feel the complete opposite. "One indentation" is the only unit > in > multiples of which anything should ever be indented. Using arbitrary > "indentation" to visually line things up is horrible. Everything gets > indented by an integer number of indentation levels. OK, then use two indentation levels for the parameter stack -- just don't use one -- that really is the worst option -- one indentation has real meaning in code. -CHB -- 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/
