4 ms·

I don’t love black’s formatting, but this article is just wrong. 1. Black’s formatting of function arguments does not break PEP8, because the closing parenthes

by oefrha 7y ago

I don’t love black’s formatting, but this article is just wrong. 1. Black’s formatting of function arguments does not break PEP8, because the closing parenthesis is one level of indentation back, breaking the continuation. (I don’t even need to check linked threads. Dude is wrong and must have been told so. He doesn’t want to listen, fine. Fork as he wishes, but it’s not like I’m gonna use his fork over Łukasz Langa’s just because he’s tired arguing.) 2. “Piles and piles of red tape”: half are generic project or generic GitHub project stuff, optional of course (oh and black is there so that you don’t need editorconfig). The Python specific stuff? - mypy? If you drank the koolaid and now dogmatically type check all your code whether warranted or not. Me? Still enjoying dynamic typing. (Don’t get me wrong, I use mypy judiciously.) - nose, pytest, unittest, etc.? Sorry you have a choice! - Finally, I haven’t even heard of bumpversion and setuptools_scm and I’ve been scraping by pushing out releases after releases. I guess you’ll always find a way to pile on the red tapes if you’re enamored with stupid tooling to begin with. 3. Don’t see any “My experience with forking black”, only saw a few talking points, including useless ones like “Remove the ‘for humans’ garbage”. Guess it’s not written yet. Btw, if a “massive” 3000 line module (lol) chokes up your editor, maybe it’s time to get a better one.

jordic 7y ago
100% agree with you. So happy with black and pytest. - The formatting he is proposing for multiple args on a function with double tabs it's wired... O_O - Same argument on mypy, if I want to type all variables, I perhaps will be happy doing it in go or rust.. python is dynamic :) - pytest - balck works so fine with vscode (pycharm will work if he disables linting code on every keystroke... )haha
- anyfoo 7y ago
  mypy kept python viable for me. I was working on a pretty complicated hw interface, which also used a lot of async/await. Even without what was basically my own coroutine implementation, there were just complicated (but not unusually so!) types in general. You know, just dicts of tuples of lists of tuples and the like. At what felt like the 1000th runtime problem because of some type confusion somewhere (or just forgetting "await", which is essentially a no-op, since you got a promise that you threw away), and a lot of these problems happening much later than where the actual bug in the code was, I was ready to throw in the towel and bid python--and all other dynamic languages--good bye. So I decided to try out mypy as some kind of last hurrah, and it paid out immediately. Adding the types went pretty quickly, and after that numerous problems were caught by the type checker, instead of manifesting as some obscure runtime problem down the way.
  - jordic 7y ago
    Most of the problems you mention could also be solved with a good test suit... I'm not against mypy.. but after working near two years with typescript.. if I have to type I prefer to do it with compiled things...
stinos 7y ago
it’s not like I’m gonna use his fork Probably shouldn't no, no use: the article is from february 3, meanwhile the fork https://github.com/stefanoborini/black https://github.com/stefanoborini/black is 40 commits behind and 0 ahead. Meaning the OP didn't do any public work yet.
- jakear 7y ago
  Alternatively: OP was able to upstream all of their contributions!
- carlosperate 7y ago
  Wrong repo: https://github.com/stefanoborini/blacker https://github.com/stefanoborini/blacker
  - stinos 7y ago
    Good find, I stand corrected.
soulmerge 7y ago
Interestingly, the question whether this particular choice of code formatting in black adheres to pep8 is still an ongoing discussion[1][2][3][4]. Guido, for example, thinks that black's choice is not compatible with pep8 and I think he described the situation quite well on Python's Discourse[5]: > So the root of this argument is that Black produces code that isn’t always in compliance with PEP 8. I say this is fine – if you use Black you don’t need PEP 8 to tell you how to format your code. (PEP 8 is still useful for other things like naming things.) > Black optimizes for a different goal than PEP 8; PEP 8 optimizes for readability while Black sometimes compromises readability in order to satisfy other goals such as minimizing lines changed as code evolves. > I don’t want to compromise PEP 8 though. [1]: https://github.com/psf/black/issues/48 https://github.com/psf/black/issues/48 [2]: https://github.com/psf/black/issues/1178 https://github.com/psf/black/issues/1178 [3]: https://github.com/psf/black/issues/1336 https://github.com/psf/black/issues/1336 [4]: https://github.com/PyCQA/pylint/issues/289 https://github.com/PyCQA/pylint/issues/289 [5]: https://discuss.python.org/t/pep-8-clarify-if-multiline-argument-list-with-a-closing-on-a-separate-line-is-acceptable/2948/7 https://discuss.python.org/t/pep-8-clarify-if-multiline-argu...
- oefrha 7y ago
  Thanks for the pointers, I stand corrected. OP could continue this debate if that’s his passion. I bow out. Meanwhile, I’ll happily enforce black where I can so that I don’t need to have these pointless arguments, although I personally strongly disagree with many of its decisions. I also have no problem contributing to whatever non-blackened projects, including CPython itself (contributed quite a few patches over the years), which is probably the final word on PEP8.
  - donquichotte 7y ago
    > so that I don’t need to have these pointless arguments This. I can't believe how much time is lost in such discussions. To paraphrase cjbprime from 11 months ago [1], "nobody likes what the code-formatter does to their code, but everybody likes what it does to their coworker's." [1] https://news.ycombinator.com/item?id=19941119 https://news.ycombinator.com/item?id=19941119
zo1 7y ago
To be fair, it's a giant 4100 line file. That's ridiculous and should be broken up in some way. Let's not try to defend ridiculous behavior just because we don't like the tone of this article, as he's spot on in this regard regarding the organization of this library. I've encountered similar "libraries" that are next to impossible to alter in behavior without forking precisely because they're giant single-file messes.
- RhysU 7y ago
  That's silly long. But it is tested and works. And it didn't cost me any money.
kelnos 7y ago
Personally I like black's style in function argument formatting better than PEP8, assuming the example given is representative of both styles; I find black's to be much more readable. But that's of course a bikeshed. At any rate, if black's formatting does break PEP8 (as a downthread commenter rebuts), I would think it's weird that black doesn't have a --pep8-correct flag or something for people who do want PEP-compliant stuff. Certainly black can go its own way, but if people are going to consider it "the blessed python code formatter", it should have a mode that actually conforms to the python standard for formatting. But hey, ultimately it's the black maintainer's choice.

by oefrha 7y ago

jordic 7y ago

100% agree with you. So happy with black and pytest. - The formatting he is proposing for multiple args on a function with double tabs it's wired... O_O - Same argument on mypy, if I want to type all variables, I perhaps will be happy doing it in go or rust.. python is dynamic :) - pytest - balck works so fine with vscode (pycharm will work if he disables linting code on every keystroke... )haha

anyfoo 7y ago
mypy kept python viable for me. I was working on a pretty complicated hw interface, which also used a lot of async/await. Even without what was basically my own coroutine implementation, there were just complicated (but not unusually so!) types in general. You know, just dicts of tuples of lists of tuples and the like. At what felt like the 1000th runtime problem because of some type confusion somewhere (or just forgetting "await", which is essentially a no-op, since you got a promise that you threw away), and a lot of these problems happening much later than where the actual bug in the code was, I was ready to throw in the towel and bid python--and all other dynamic languages--good bye. So I decided to try out mypy as some kind of last hurrah, and it paid out immediately. Adding the types went pretty quickly, and after that numerous problems were caught by the type checker, instead of manifesting as some obscure runtime problem down the way.
- jordic 7y ago
  Most of the problems you mention could also be solved with a good test suit... I'm not against mypy.. but after working near two years with typescript.. if I have to type I prefer to do it with compiled things...

stinos 7y ago

it’s not like I’m gonna use his fork Probably shouldn't no, no use: the article is from february 3, meanwhile the fork https://github.com/stefanoborini/black https://github.com/stefanoborini/black is 40 commits behind and 0 ahead. Meaning the OP didn't do any public work yet.

jakear 7y ago
Alternatively: OP was able to upstream all of their contributions!
carlosperate 7y ago
Wrong repo: https://github.com/stefanoborini/blacker https://github.com/stefanoborini/blacker
- stinos 7y ago
  Good find, I stand corrected.

soulmerge 7y ago

Interestingly, the question whether this particular choice of code formatting in black adheres to pep8 is still an ongoing discussion[1][2][3][4]. Guido, for example, thinks that black's choice is not compatible with pep8 and I think he described the situation quite well on Python's Discourse[5]: > So the root of this argument is that Black produces code that isn’t always in compliance with PEP 8. I say this is fine – if you use Black you don’t need PEP 8 to tell you how to format your code. (PEP 8 is still useful for other things like naming things.) > Black optimizes for a different goal than PEP 8; PEP 8 optimizes for readability while Black sometimes compromises readability in order to satisfy other goals such as minimizing lines changed as code evolves. > I don’t want to compromise PEP 8 though. [1]: https://github.com/psf/black/issues/48 https://github.com/psf/black/issues/48 [2]: https://github.com/psf/black/issues/1178 https://github.com/psf/black/issues/1178 [3]: https://github.com/psf/black/issues/1336 https://github.com/psf/black/issues/1336 [4]: https://github.com/PyCQA/pylint/issues/289 https://github.com/PyCQA/pylint/issues/289 [5]: https://discuss.python.org/t/pep-8-clarify-if-multiline-argument-list-with-a-closing-on-a-separate-line-is-acceptable/2948/7 https://discuss.python.org/t/pep-8-clarify-if-multiline-argu...

oefrha 7y ago
Thanks for the pointers, I stand corrected. OP could continue this debate if that’s his passion. I bow out. Meanwhile, I’ll happily enforce black where I can so that I don’t need to have these pointless arguments, although I personally strongly disagree with many of its decisions. I also have no problem contributing to whatever non-blackened projects, including CPython itself (contributed quite a few patches over the years), which is probably the final word on PEP8.
- donquichotte 7y ago
  > so that I don’t need to have these pointless arguments This. I can't believe how much time is lost in such discussions. To paraphrase cjbprime from 11 months ago [1], "nobody likes what the code-formatter does to their code, but everybody likes what it does to their coworker's." [1] https://news.ycombinator.com/item?id=19941119 https://news.ycombinator.com/item?id=19941119

zo1 7y ago

To be fair, it's a giant 4100 line file. That's ridiculous and should be broken up in some way. Let's not try to defend ridiculous behavior just because we don't like the tone of this article, as he's spot on in this regard regarding the organization of this library. I've encountered similar "libraries" that are next to impossible to alter in behavior without forking precisely because they're giant single-file messes.

RhysU 7y ago
That's silly long. But it is tested and works. And it didn't cost me any money.

kelnos 7y ago

Personally I like black's style in function argument formatting better than PEP8, assuming the example given is representative of both styles; I find black's to be much more readable. But that's of course a bikeshed. At any rate, if black's formatting does break PEP8 (as a downthread commenter rebuts), I would think it's weird that black doesn't have a --pep8-correct flag or something for people who do want PEP-compliant stuff. Certainly black can go its own way, but if people are going to consider it "the blessed python code formatter", it should have a mode that actually conforms to the python standard for formatting. But hey, ultimately it's the black maintainer's choice.