Python programming is drowning in red tape
51–60 of 183 posts
Re: Python programming is drowning in red tape
#52> a CODE_OF_CONDUCT, because we assume preemptively that you are a racist homophobic asshole, and we have to cover our bases. This one is a new personal pet peeve. I'm not a racist homophobe--I'm a good person. And though it doesn't give me any authority to speak on the matter, I'm bi and I've dated all sorts of people. I don't like to be presumed to be an asshole (or presume that others may be), and I'm offended tha…
I once attended a tech meetup held at the headquarters of a FAANG. As we were waiting for the presentation to start, they projected their a link to their code on conduct for the meeting.
I tried to visit the link. It gave a 404. Apparently it hasn’t been working for some time. Nobody noticed.
Ironically, the meetup was about site reliability engineering.
Edit: in all fairness I’ve seen a good tech group destroyed over a dumb battle about their code of conduct.
Re: Python programming is drowning in red tape
#53Earlier quoted context omitted.
> 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.
> we are starting to look like a heavily templatized cpp code Which was my main concern when type-hints were added Give a hand to the strong-typed people and they will take the whole arm. They will take Python as "now it's like Java" and will push it all the way through.
Re: Python programming is drowning in red tape
#54As 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.
Re: Python programming is drowning in red tape
#55The "frowny face" is ): which in Python is all over the place, but hopefully you don't notice it, and if you do, you don't care.
I find it to be sufficient separation between the arguments and the code. It's too bad the author doesn't, but that doesn't change it for me or other devs that are comfortable with it.
This:
def very_important_function(
template: str,
*variables,
file: os.PathLike,
engine: str,
header: bool = True,
debug: bool = False,
):
"""Applies `variables` to the `template` and writes to `file`."""
with open(file, "w") as f:
is similar to this, which has caught on in React with Prettier: setFruit(value)}
>
Apple
Orange
Banana
The fact that people like it in multiple languages means it's definitely an uphill battle to go back to indenting it further.Re: Python programming is drowning in red tape
#56As 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…
> Tools like black and poetry are nice, but are not part of the standard library. If black does non-PEP 8 formatting, as the article says, then I would not expect it to be in the standard library, since PEP 8 formatting is the Python standard. > the language itself is increasingly baroque and complicated I don't find current Python 3 any more baroque or complicated than Python 2.7. In fact I have plenty of Python cod…
I'm personally not a fan of it (I'm still a gevent proponent; Go seems to be doing fine with a green thread model), but a lot of libraries I use are written with it, so it's pretty annoying for me. That and the dependency/package story are the two things that've made me seriously consider switching to a different language. (The article's complaints about things like pre-commit and isort are pretty silly and irrelevant, IMO, though it would be nice if there was something official like "go fmt".)
So far the benefits still outweigh the costs for me, compared to other languages, but I predict a better, cleaner, and more performant successor to Python may come this decade. If it does, I think I might become an early adopter.
Re: Python programming is drowning in red tape
#57I would appreciate it very much if Python would have a standard language formatter ala `go fmt` to end the bikeshedding. I personally use black but I wouldn't mind other standards as long as I don't have to pick and choose anymore.
Re: Python programming is drowning in red tape
#58Re: Python programming is drowning in red tape
#59> As I adventured in this petty task, it’s worth nothing the amount of red tape required to setup a python project today. You need: I have never used most of those tools and I've been knee deep in Python for ~4 years. Go look at some of your favorite pypi libraries, chances are they are using a small fraction of those tools as well. The author is making things overly complicated, but it's all self-inflicted. Just cod…
Re: Python programming is drowning in red tape
#60Earlier quoted context omitted.
> 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.
Type annotations help catch common errors, and they help humans. Maybe it's not as pretty but as someone who often have to read Python, it really helps me understand what the contract is of a function I'm looking at.