111–120 of 262 posts
Earlier quoted context omitted.
80 columns is very standard.
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?
.editorconfig is a start but the amount of time saved through automation and removing customization is significant.
I really want to use Black, but we have a particular style point that we’d miss so much that we haven’t adopted it yet... Double quotes for strings that need to be human readable, single quotes otherwise. This makes it so obvious when something is going to be sent to the user, we find it really useful. That said, I think Black’s appeal is it’s uncompromising nature, so I wouldn’t ask it to change. Adding the option t…
Earlier quoted context omitted.
> It's not configurable. Except for the line length: > if you're paid by the line of code you write, you can pass --line-length with a lower number.
Yeah, I wasn't willing to die on that hill, especially that I'm introducing a new default value that wasn't popular before.
Earlier quoted context omitted.
Colons in slices are implemented to the letter of PEP 8. Your disagreement here probably stems from pycodestyle mistakenly enforcing a different rule (no spaces before colons on if-statements, defs, and so on) in the slice context. The language itself doesn't have an established standard in terms of string quote usage. If it did, Black would follow it. What repr() does is a weak indicator and how the documentation is…
Double quotes also have drawbacks, visual noise and the doubling of keypresses required on the most common keyboard layouts.
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?
Earlier quoted context omitted.
Originally PEP 8 had 79 characters. Now that was a weird choice so most companies went with 80 instead, including Facebook. You want a low-ish limit because it makes it possible to fit two files side by side on a typical screen resolution. Even if you don't edit like that, you look at diffs like that. More importantly, a low column limit is helpful to disabled engineers who don't have to navigate horizontally so much…
> More importantly, a low column limit is helpful to disabled engineers who don't have to navigate horizontally so much. I saw that you mentioned that - where have you seen a study that claims 100 is the cutoff? Would be interested in seeing that.
88 column wrap? Yeah - no thanks.
just specify a different --line-length argument? Easily solved. I have mine set to 120. I code my python code in Pycharm, on a high resolution screen. Having a column limit of 88 only makes sense if you are inside of VIM or something.
Earlier 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?
This is great except for the enforcement of double-quotes around all strings and spaces around slice operators. These two choices contradict the standard Python documentation, most of the standard library, and the behaviour of the interpreter itself. When the language itself has an established convention, Black should follow that convention, not fight it. These two weird choices just generate needless churn, which is…
Colons in slices are implemented to the letter of PEP 8. Your disagreement here probably stems from pycodestyle mistakenly enforcing a different rule (no spaces before colons on if-statements, defs, and so on) in the slice context. The language itself doesn't have an established standard in terms of string quote usage. If it did, Black would follow it. What repr() does is a weak indicator and how the documentation is…
This leads to the following difference between the PEP 8 recommendation and Black:
PEP 8 accepts both of these:
ham[lower+offset : upper+offset]
ham[lower + offset : upper + offset]
ham[lower + offset : upper + offset]
slice[a.b : c.d]
After typing this all out, I think that it might be the case that the bigger difference is actually in how binary operators are treated. It looks like Black always puts whitespace around binary operators, which contradicts PEP 8's recommendation that you are allowed to vary spacing around binary operators to make precedence clear.
Since Black does allow for leaving in extraneous parentheses to make precedence clear, I wonder why it doesn't allow varying the space around binary operators as well? Of course, it should enforce that the spacing actually does match the precedence, and that the spacing is consistent within an expression. That would allow the following examples which PEP 8 lists as "Yes":
x = x*2 - 1
hypot2 = x*x + y*y
c = (a+b) * (a-b)
x = x * 2 - 1
hypot2 = x * x + y * y
c = (a + b) * (a - b)I really want to use Black, but we have a particular style point that we’d miss so much that we haven’t adopted it yet... Double quotes for strings that need to be human readable, single quotes otherwise. This makes it so obvious when something is going to be sent to the user, we find it really useful. That said, I think Black’s appeal is it’s uncompromising nature, so I wouldn’t ask it to change. Adding the option t…
One idea you might want to consider is to create a global function, let’s call it h() and pass all your human readable strings through it, like so h(“hello world”). This function, simply returns the same string. This is more explicit than relying on quote types. It also allows you to do interesting things such as logging everything to a text file and running a spell checker on it, or checking for wrongly encoded stri…