The problem is that Python programmers tend to think the job of readability is done just by indentation. This is wrong, and it shows in all sorts of readability issues. Many of which are in official docs.
Same could be said about people that don’t think that indentation is not important for readability. Both are important, but if you really care about it defining an auto formatter and customising it for whatever consensus the team has is the only way to operate anyway.
Same could be said about people that don’t think that indentation is not important for readability.
You should really avoid double negatives. What you actually said was "Same could be said about people that think that indentation is important for readability“, which makes no sense in the context of the rest of your post.
And I’m not saying this just to be a dick about grammar. I mean, obviously I am, but not just that. If your English isn’t readable, then I don’t trust your Python, either.
My bad, I deleted part of the comment to rewrite it and forgot part of the original. And as you probably guessed I meant for it to be a single negative.
Good thing this is a casual forum and not a work environment where I would reread my code with care haha. There’s a reason linters exist in code editors, it’s for people like me.
Yeah pythonistas just group bad code into “non-pythonic”
It’s basically a credo if you aren’t familiar but Python is preeeetty explicit about formatting recommendations and whatnot so there’s really no excuse for poor Python practices/non-pythonic code
This is a mess. None of this ascii vomit is useful or enlightening.
I got it from the argparse docs, which is a core module. But really, this is just the way Python docs are generated. Every class doc has an ascii vomit like this at the top, and my eyes hurt every time I see it.
Markdown seems to put it on one line, which has its own problems, but this is what it looks like in actual docs:
This is hardly even the worst offender; it gets worse as the number of internal class members goes up, since they all get listed out. This whole section should just be dropped in favor of simply listing the class name. Further down, there’s a bulleted list of the params, which is what you actually want.
In fact, there’s plenty more in that doc that could be fixed. For example:
parser.add_argument('integers', metavar='N', type=int, nargs='+',
help='an integer for the accumulator')
Too many parameters on each line. Do this instead:
parser.add_argument(
'integers',
metavar = 'N',
type = int,
nargs = '+',
help = 'an integer for the accumulator'
)
This also puts more whitespace around the key/value pairs, which gives your eyes more resting point. In general, erring on the side of additional whitespace around non-alphanum characters tends to improve readability.
This style can come into conflict with coding rules about max function length. The solution to that is to be flexible about max function length. I would rather see 40 simple lines than 10 with everything jammed up together.
Edit: interestingly, my Lemmy instance seems to handle syntax highlighting on the second add_argument example better than the first. That might just be the implementation, though; my vim setup seems to handle highlighting both equivalently.
I have to be honest: I dont see the problem of including the entire signature at the top of the doc, and the listing the params below. If I know the class/function, a quick look at the signature is often all I need, so I find it convenient that it’s at the top of the doc. If it’s a class/function I’m not familiar with, I just scroll to the bullet points.
I agree on the bit about whitespace in signatures though. Luckily Python allows me to use as many lines as I want within a parentheses.
The problem is that Python programmers tend to think the job of readability is done just by indentation. This is wrong, and it shows in all sorts of readability issues. Many of which are in official docs.
Same could be said about people that
don’tthink that indentation is not important for readability. Both are important, but if you really care about it defining an auto formatter and customising it for whatever consensus the team has is the only way to operate anyway.You should really avoid double negatives. What you actually said was "Same could be said about people that think that indentation is important for readability“, which makes no sense in the context of the rest of your post.
And I’m not saying this just to be a dick about grammar. I mean, obviously I am, but not just that. If your English isn’t readable, then I don’t trust your Python, either.
My bad, I deleted part of the comment to rewrite it and forgot part of the original. And as you probably guessed I meant for it to be a single negative.
Good thing this is a casual forum and not a work environment where I would reread my code with care haha. There’s a reason linters exist in code editors, it’s for people like me.
Yeah pythonistas just group bad code into “non-pythonic”
It’s basically a credo if you aren’t familiar but Python is preeeetty explicit about formatting recommendations and whatnot so there’s really no excuse for poor Python practices/non-pythonic code
Then what the hell is this shit?
class argparse.ArgumentParser(prog=None, usage=None, description=None, epilog=None, parents=[], formatter_class=argparse.HelpFormatter, prefix_chars='-', fromfile_prefix_chars=None, argument_default=None, conflict_handler='error', add_help=True, allow_abbrev=True, exit_on_error=True)This is a mess. None of this ascii vomit is useful or enlightening.
I got it from the argparse docs, which is a core module. But really, this is just the way Python docs are generated. Every class doc has an ascii vomit like this at the top, and my eyes hurt every time I see it.
I can’t see what you’re referring to
Markdown seems to put it on one line, which has its own problems, but this is what it looks like in actual docs:
This is hardly even the worst offender; it gets worse as the number of internal class members goes up, since they all get listed out. This whole section should just be dropped in favor of simply listing the class name. Further down, there’s a bulleted list of the params, which is what you actually want.
In fact, there’s plenty more in that doc that could be fixed. For example:
parser.add_argument('integers', metavar='N', type=int, nargs='+', help='an integer for the accumulator')Too many parameters on each line. Do this instead:
parser.add_argument( 'integers', metavar = 'N', type = int, nargs = '+', help = 'an integer for the accumulator' )This also puts more whitespace around the key/value pairs, which gives your eyes more resting point. In general, erring on the side of additional whitespace around non-alphanum characters tends to improve readability.
This style can come into conflict with coding rules about max function length. The solution to that is to be flexible about max function length. I would rather see 40 simple lines than 10 with everything jammed up together.
Edit: interestingly, my Lemmy instance seems to handle syntax highlighting on the second
add_argumentexample better than the first. That might just be the implementation, though; my vim setup seems to handle highlighting both equivalently.I can only see the picture you included, my instance * likely blocks ascii in favor of input cleaning sorry to be stuck a pain!
I have to be honest: I dont see the problem of including the entire signature at the top of the doc, and the listing the params below. If I know the class/function, a quick look at the signature is often all I need, so I find it convenient that it’s at the top of the doc. If it’s a class/function I’m not familiar with, I just scroll to the bullet points.
I agree on the bit about whitespace in signatures though. Luckily Python allows me to use as many lines as I want within a parentheses.