Earlier quoted context omitted.
Yeah, I wasn't willing to die on that hill, especially that I'm introducing a new default value that wasn't popular before.
When I read that line in the documentation, it hurt a little. I'm going to be honest here. I did not feel good with someone saying that an 80-column limit is just there to pad my paycheck, rather than an informed decision I made. I realize that it was tongue in cheek, but it still felt bad.
Black: An uncompromising Python code formatter
141–150 of 262 posts
Re: Black: An uncompromising Python code formatter
#142Earlier quoted context omitted.
It was a standard from a time when we had green-screen terminals only capable of displaying an 80x24 grid of characters. ( https://en.wikipedia.org/wiki/VT100 ) It's worth asking - does the standard make sense still, given how we edit today?
Definitely not. We turn all line-wrapping off. Everybody has wide-screens.
Re: Black: An uncompromising Python code formatter
#143Maybe I missed it, but I don't see a comparison with PyCharm's built-in code formatter. Why would I integrate this code-formatter, "black", into PyCharm when PyCharm already does this for me and the whole team?
Re: Black: An uncompromising Python code formatter
#144Earlier quoted context omitted.
Double quotes also have drawbacks, visual noise and the doubling of keypresses required on the most common keyboard layouts.
You can still type single quotes. You have a tool to convert that for you. The visual noise complaint is interesting. Do you also consider the letter W to be more noisy than the letter V? Should we discourage the use of noisy letters in the alphabet?
I thought the same. I guess you could just modify your programming font to make the double quotes really tiny :)
Re: Black: An uncompromising Python code formatter
#145Re: Black: An uncompromising Python code formatter
#146Earlier quoted context omitted.
Definitely not. We turn all line-wrapping off. Everybody has wide-screens.
And nobody uses split windows? No screen can comfortably fit more then about 200 columns, so I believe 100 is the absolute maximum width.
Re: Black: An uncompromising Python code formatter
#147Earlier quoted context omitted.
When I read that line in the documentation, it hurt a little. I'm going to be honest here. I did not feel good with someone saying that an 80-column limit is just there to pad my paycheck, rather than an informed decision I made. I realize that it was tongue in cheek, but it still felt bad.
If that hurt you, you need bigger problems in life.
Re: Black: An uncompromising Python code formatter
#148In case of credit where credit’s due, is gofmt where the concept of auto-formatting syntax became mainstream? At first I hated it because I thought I had a style, but later on I enjoyed the consistency far more than I enjoyed my signature approach. A programming language has an opinion on how you build software with it, so it’s appreciated that it also has an opinion on how you should write it so that it remains cons…
When i heard about gofmt, i hated it. I wanted choice. Then i realised i loved python because it forced people to indent. I gave black a try. I still hate some style decisions, but who cares ? The benefits are far too great to pass up.
That is a fantastic achievement.
Re: Black: An uncompromising Python code formatter
#149Earlier quoted context omitted.
Not really. I worked at one place where they enforced PEP8 (using flake8 etc) using a git commit hook. In other words, when you try to commit some code, it would run flake8 which would most likely balk at some of the changes you made (and not let you commit until those were fixed). A lot of the rules/warnings are extremely nitpicky, and they had all of them turned on (except for the line length); I don't know how man…
> I don't know how many times I could not commit my code because I left a space at the end of a line, or an empty line contained whitespace Trailing whitespace causes issues with git, editors, diff tools, and numerous other things, as well; keeping it out of a repository is a good thing. > I had only one blank line between two class definitions I certainly agree that that's the kind of thing a tool should help with r…
It's also the type of thing you should be getting your IDE to worry about. And not leave it till it's time to commit/push.
Re: Black: An uncompromising Python code formatter
#150Earlier quoted context omitted.
When I read that line in the documentation, it hurt a little. I'm going to be honest here. I did not feel good with someone saying that an 80-column limit is just there to pad my paycheck, rather than an informed decision I made. I realize that it was tongue in cheek, but it still felt bad.
If that hurt you, you need bigger problems in life.
I am just being honest, and I think I am being helpful because other people will also react negatively to the way the documentation is written. I support the project and want it to be successful, providing feedback like this achieves progress towards that goal, in my estimation.