71–80 of 183 posts
Earlier quoted context omitted.
I completely agree. Who cares if black is ugly? It's a standard which is easy to automate. Want a better standard? Make it. Until then black works.
> Beautiful is better than ugly.
Earlier quoted context omitted.
Don't mix things, guy! - asyncio it's one thing: From my point of view it's amazing... makes python be able to compete with nodejs or go.. (not so hard, if you work also on the browser) - mypy: that's another story, but it's also optional, use it if you want... (my opinion, like in typescript, if I want types I will do it with go or rust)
Good luck finding a pandas or scipy implementation for go or rust :-/
Long term goal is to create a lightweight Pandas equivalent by and for the Rust community, but with slight differences in focus..."
https://docs.rs/black-jack/0.1.0/blackjack/
EDIT: That one looks like it's not being worked on actively. Here's a reddit thread with more ideas. Weld looks interesting.
https://www.reddit.com/r/rust/comments/apo66e/dataframes_wha...
And Arrow looks like a new project Wes McKinney is contributing to.
> It was bikeshedding at its worst It's ironic that discussions about formatting are taking up so much mindshare in the python community. For years all you'd hear was that whitespace significance was a sign of the lowliness of python. Meanwhile, tons of people were ignoring the bikeshedding and getting things done. Now it's one of the most widely used languages in existence. The kinds of people that are focused on is…
Frankly, after having been out of the Python ecosystem for a long time, I'm surprised that something like black ever gained traction, if it really has strayed in any significant sense from pep8.
The entire reason you have been able to ignore stupid formatting debates like this for so long is because of things like pep8 and strict definitions of what entails "Pythonic" code.
What happened?
As a long time Python fan, I find the current state of the language frustrating. Tools like black and poetry are nice, but are not part of the standard library. Yet they seem to be required by every popular project out there. (Also, black’s formatting is quite ugly, as noted in this blog post) Meanwhile, the language itself is increasingly baroque and complicated. Type-annotated, asyncio-enabled Python hardly resembl…
As a long time Python fan, I find the current state of the language frustrating. Tools like black and poetry are nice, but are not part of the standard library. Yet they seem to be required by every popular project out there. (Also, black’s formatting is quite ugly, as noted in this blog post) Meanwhile, the language itself is increasingly baroque and complicated. Type-annotated, asyncio-enabled Python hardly resembl…
> Type-annotated, asyncio-enabled Python hardly resembles the easy-to-understand language I fell in love with back in 2006. true. i am all for types in general and for types annotations in python. but i have seen some heavily type-annotated python code lately and i don't think that's where we want to be. we are starting to look like a heavily templatized cpp code.
Since I started using them, the number of runtime errors coming out from my own code has been drastically reduced.
Of course one can always go overboard with those `Generic[T]` hints. Though this is a problem of the tool user, not the tool.
Long-time python programmer: we could do a better job with bootstrapping projects. `create-react-app` and `create-probot-app` set up complete projects for ya. How great would it be to have a project skeleton with black + poetry + mypy with everything hooked together?
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’…
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 is 40 commits behind and 0 ahead. Meaning the OP didn't do any public work yet.
Earlier quoted context omitted.
Come on, I hate this as much as you do, but we don’t need yet another flamewar over this with canned responses.
> Come on, I hate this as much as you do, but we don’t need yet another flamewar over this with canned responses. I must live under a bush.
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’…
> 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
[2]: https://github.com/psf/black/issues/1178
[3]: https://github.com/psf/black/issues/1336
[4]: https://github.com/PyCQA/pylint/issues/289
[5]: https://discuss.python.org/t/pep-8-clarify-if-multiline-argu...