find . -name '*.py' | xargs grep -n '^.\{80\}'
and post it here. find . -name '*.py' | xargs grep -n '^.\{80\}'
and post it here.But it's stupid to break a line like this in two
stuff.do_something_funny(abc, def, ghi)
when the limit is reached at the 3rd parameter (or worse, at the parenthesis)
Don't get me wrong, I personally think 80 is a fine number and it's what I use myself. But making things like this hard rules for what basically are arbitrary reasons (e.g. depending on screen resolution) doesn't seem right in my book. I'm seriously not even considering doing something about a line if it's 81 characters.
I think that's just as reasonable as the rest of Python's whitespace usage, since it (hopefully!) causes the programmer to consider whether that ceremony (classes, methods, etc.) is neccessary or just overcomplication.
It's directly comparable to, say, nesting lambdas in lambdas in lambdas; probably not great for readability, etc. It just-so-happens that in Python's OO, that first lambda is called a class and the second is called a method (objects are a poor man's closures, and closures are a poor man's object!)
As for python, some fancy list comprehensions get rather long rather quickly. Especially if itertools are involved as you izip, etc. Or using useful variable names (i.e. not 'fcnt', 'tcnt') while destructuring as in this example from pyspark/mllib:
(failure_count, test_count) = doctest.testmod(globs=globs, optionflags=doctest.ELLIPSIS)
I adapted your grep to:
find . -name '*.py' | xargs grep -n '^ *.\{80\}'
So leading indentation doesn't mess with the results.Sure, and we all know that indentation in Python is not allowed for list comprehensions.
class Foo:
# ...
def bar():
# ...
if baz:
# ...
result = [
y.strip()[1:14].replace("this", "that")
for x in nabla.generate(q, w, y, z)
for y in x.something_other()
if y.has_property(...)
]hn is such a cool place. :)