Python programming is drowning in red tape
stefanoborini.com
Python programming is drowning in red tape
1–10 of 183 posts
Re: Python programming is drowning in red tape
#2I run into this in Django a lot with my chained ORM queries. The usually tend to be like 10-15 chars to long. And in this case you have to line break on the parameters or on a ‘.’ which is ugly as well.
While not related to Python, I feel like whenever I write JS code, especially Vue I have a terrible time with line length.
Re: Python programming is drowning in red tape
#3Line length is such a hard problem to solve. I wish there was a way to be like don’t allow more than 95% percent of my lines to be longer than X. I run into this in Django a lot with my chained ORM queries. The usually tend to be like 10-15 chars to long. And in this case you have to line break on the parameters or on a ‘.’ which is ugly as well. While not related to Python, I feel like whenever I write JS code, espe…
Re: Python programming is drowning in red tape
#4Meanwhile, the language itself is increasingly baroque and complicated. Type-annotated, asyncio-enabled Python hardly resembles the easy-to-understand language I fell in love with back in 2006.
Perhaps this is just an “old man yells at cloud” moment...
Re: Python programming is drowning in red tape
#5Line length is such a hard problem to solve. I wish there was a way to be like don’t allow more than 95% percent of my lines to be longer than X. I run into this in Django a lot with my chained ORM queries. The usually tend to be like 10-15 chars to long. And in this case you have to line break on the parameters or on a ‘.’ which is ugly as well. While not related to Python, I feel like whenever I write JS code, espe…
Re: Python programming is drowning in red tape
#6Re: Python programming is drowning in red tape
#7I 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 code and be happy.
Re: Python programming is drowning in red tape
#8As 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…
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 code that runs just fine, unmodified, under both interpreters. And I have plenty of other Python code that only needs from __future__ import print_function to run unmodified under both interpreters.
That's not to say I think there are no issues with current Python 3; just that I wouldn't describe those issues as "the language is increasingly baroque and complicated". See further comments below.
> Type-annotated, asyncio-enabled Python hardly resembles the language I fell in love with back in 2006.
You don't have to use these features if you don't want or need them. Nobody uses 100% of any language's features, and the subset that is used can be very different from person to person. I don't see that as a problem.
I did see the way the Python 3 transition was handled as a big problem, but that's water under the bridge now and the issues that gave many people headaches during the transition were pretty much resolved by Python 3.3.
The two big problems I see with current Python 3 are memory usage and the GIL. Python 3 objects take more memory than Python 2 objects did; for programs that create a lot of objects that can be an issue. (To be fair, many such programs are numerical simulations that can take advantage of the many optimizations in the NumPy and SciPy libraries.) There seems to be work in progress on supporting multiple interpreters running in the same Python process, which would fix the GIL issue, but it's too soon to see if that will really address the issues surrounding the GIL.
Re: Python programming is drowning in red tape
#9> 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…
My reaction exactly.
Re: Python programming is drowning in red tape
#10As 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…
There are massive differences between languages, though. I think I might use close to 70% of Objective-C's or Java's features regularly, while I can't even hope to use 50% of C++'s.