I can't agree with this. I have always had a very good experience with python documentation. One can use the built-in "help" function which works seamlessly with the docstring feature of the language. The complaint in the blog post seems to refer to the UI of the website missing a table of contents for functions. Yeah sure they could add that but I don't see it as a big point.
> Python’s package management sucks
Hmm, it has some weaknesses but I wouldn't really say it sucks. Going deeper ->
> Every project seems to use a different tool and it’s a massive headache. Off the top of my head there’s ...
Don't all of these use pip under the hood? I personally use the lower-level pip and virtualenv tools, but some others enjoy the convenience of poetry. That's a bit of personal preference. It's a bit more akin to an IDE choice than a feature of the language. None of conda, poetry, etc. are core Python features.
> Python’s standard library sucks
I have to disagree again, I think it is pretty well designed and minimal on purpose. The community additions of numpy, etc. are by design not part of the core language to reduce bloat.
> Python is slow
OK sure, it is slower than compiled languages like C++, that is a concession we make when opting for the ease of readability, writability, usability, etc.
> Python is huge, the python:3.9-slim Docker image is 118MB
Hmmm. 118MB isn't really that big anymore. The docker image would presumably be cached and reused in a deployment pipeline.
> Python syntax sucks.
This one I can't even understand the reasoning for. The python syntax is what people love about it. I personally dislike the walrus operator, f-strings, and some of the other newer features (did they add the switch statement yet?) but those are my only gripes. And they are more pet-peeves / personal preferences than complaints.
I have to agree. I have a lot of gripes with Python, but the documentation and the standard library are generally great.
The author favors Javascript while deriding Python for its syntax, type-hints, and standard library, and favors Go while deriding a Python Docker image's size and documentation. I feel like the author must use Python in a very different way than I do for Javascript and Go to be the winners in these categories.
I do agree without reservation that package management and dependencies are horrible with Python.
I have a lot of gripes with Python, but the documentation and the standard library are generally great.
It depends what you're comparing them against. Python's style of documentation - for the language itself and for many of the popular libraries that follow the same style - is mostly reference material and often incomplete. It's very lacking in examples of usage. It almost completely ignores types. It often doesn't appear in search engine results for relevant keywords leading to spending several minutes brute force searching the official docs site to find something that should have been a 10 second search. Perhaps the most obvious comparison is with the JavaScript/TypeScript world, which has embraced both types and different kinds of documentation and as a result gives a much better developer experience in those areas today.
The standard library in Python is strange because it has a lot of content but much of that content just isn't very good. Entire packages in the standard library are largely ignored in favour of some de facto standard package from PyPI that does the same job much better. Some of the packages for working with different protocols and file formats are useful in the right circumstances but they're so slow that they're not suitable for many applications and again you end up pulling in a better alternative. Meanwhile common data structures and algorithms that you might look for in any modern language's toolbox are scarce to non-existent and the ones that do exist don't always compose easily.
It definitely varies from library to library. The urllib.request example provided is pretty horrible, and it's simply just been in a blind spot in my eye.
I also agree with you on typing, searchability, and the problem of standards vs defacto standards. (The page for `urllib.request` points you to `requests`, which is good! But the page for `array` has a link to `numpy` only at the very bottom.) I also don't have the JS/TS experience to compare against, but I believe you there. (The MDN alone is excellent.)
I think my experience is biased from spending a lot of time in deep learning. (Keras and Pytorch have a bit of a competition for having good docs). The adjacent libraries, like Numpy or Pandas or stdlib like `socket`, have also been good in my experience. (Perhaps these benefit from having relatively 'obvious' types for most functions. One might infer the types and dimensions of `numpy.matmul(x1, x2)` easily, whereas I have no idea what the types of the args in `Request.set_proxy(host, type)` are.)
It's a shame this post was flagged, because I've had a lot of blind spots uncovered in this thread!
I, a python dev with a decade of experience sometimes still need half a day to figure out some weird dependency venv import-path issue. This happens often.
It takes me half a day to figure out a reliable way to cross compile rust binaries for Raspberry Pis, withput ever having done this before.
There are a lot of good things about python but the dev environment sucks a lot and it is so engrained in the very substance of the language/tooling that I don't really see a path out of that other than going all Python 4.0 on it and repeating the python2/python3 schism all over again.
Python is still my goto language but it is my goto language despite the tooling, not because of it.
Python's documentation is good, but it's a departure from expectations if you're used to Javadoc-style documentation of APIs. You can get just that by providing good docstrings in your library's code or using documentation generators like Sphinx and whatnot.
Agree with the rest of your points, though, except not liking newer syntax. Newer syntax, in my experience, makes writing code less of a chore and mirrors the developer conveniences in other modern languages.
> OK sure, it is slower than compiled languages like C++, that is a concession we make when opting for the ease of readability, writability, usability, etc.
Does not being compiled really help with readability? How? After all, one can compile python to machine code, and there are C++ interpreters [1] (I have not heard any claims that using it makes C++ more readable). Then there are very readable/usable languages such as Haskell that come out of the box with both a compiler and interpreter.
To be more specific: which features does the absence of the possibility of compilation [2] enable?
You are quite right it is not just compilation that sets Python apart from C++, that was a bit of a simplification on my part.
There is also tools such as Cython and numba (JIT) which use various techniques to compile Python code btw. But I am generally in favour of switching to a high performance language or writing in C++ and then importing in Python at that point, personal preference again...
Interesting to read about cling, will have to play around with that.
> You are quite right it is not just compilation that sets Python apart from C++, that was a bit of a simplification on my part.
That's how I understood your post. Sorry if my post came off as a correction - it was not meant as such, but as a question (not specifically about Python or C++):
How does a language benefit from not having the option to compile it? What restrictions does the requirement to be able to produce a machine-code executable place on it?
Because naively, I would say it should have no effect - one could package the interpreter and source-code into a single file, and think of that as a (very unoptimized) "compiled executable".
data = slow_computation()
metrics = produce_metrics(data)
Now later I want to play with some metrics and experiment a bit I can do that in the interactive shell (running with python -i file.py will run the script as normal but leave a python interpreter open at the end with all the variables kept alive)
When I am happy with my experimentation results, say, I have found something interesting about the data and written a new function cool_metric(metrics) I can commit it to the script at the end
data = slow_computation()
metrics = produce_metrics(data)
cool_metric = cool_metric(metrics)
There's also the ability to drop in breakpoints where you can then have the full python shell available, can break out of the debugger into an interactive shell if you want, or can modify a variable and then continue the script as normal. I think you can do that with GDB for instance but it's not quite as flexible if I am not mistaken?
so if I have
def some_buggy_function(args):
data = analyse(args)
breakpoint()
new_data = further_analyse(data)
that can be quite powerful in making debugging easy
> How does a language benefit from not having the option to compile it? What restrictions does the requirement to be able to produce a machine-code executable place on it?
“Compiled” is being used as a short-hand for “compiled with optimisations”, so yes, an unoptimised build wouldn’t count here.
The design decision is around when (between the code being written and being run) is the final decision made about what exact code will run. If that is known really early (static types, no dynamic dispatch) then optimisations can be made early too. If it is really late (polymorphic methods, support for redefining types etc) then optimisation needs to run very quickly (“just in time”) or not at all.
If you want to go deeper on this, look at performance optimisation in Julia. It has the same LLVM backend as C/Rust, so can use all the same optimisations, but it is arguably a more dynamic and easier to use language than Python, so when and how optimisations apply really depends on how the code itself is written. As a bonus, it has some great tooling to see how changes to the code impact performance.
> I have to disagree again, I think it is pretty well designed and minimal on purpose
Oh come on. That’s like saying “this buffet has no food selection but that’s good cause I’m on a diet”. Meaning that you like that it sucks (that’s fine).
Numpy is not the kind of thing you would include in the std lib anyway.
> OK sure, it is slower than compiled languages like C++, that is a concession we make when opting for the ease of readability, writability, usability, etc.
Fair, but I’ve spent enough time python environment/dependency hell that a lot of those gains (which are mostly cognitive) weren’t worth it for me.
Numpy is not the kind of thing you would include in the std lib anyway.
If I could add one thing to the python standard library it would be unify the python std lib array and the numpy array and make many of the most common and useful numpy array methods available in the std lib.
yeah python is alright, it's not a masterpiece, but it's well rounded
I ported a golang (non concurrent) program that was 3 files and lots of intermediate procedures over custom types (synchronized maps)
it thing fit beautifully in a one page python script, very readable. bonus: concurrency (threadpool over queues). the only libs were click and rich but not relevant to the design
and the fact that it's repl-able you can quickly navigate in the stdlib.
ps: python docs are not amazing but they have a low signal/noise/confusion ratio. if one wants to suffer go "read" the javadoc, with it's empty package descriptions, extreme redudancy of autogenerated get/set * polymorphic methods. Or to stay in the python world, django docs. They're abysmally non technical.. it's full on guess fest to infer the relationships between classes and dataflow. Superb.
The point is that every extra tool you need to work on a project is another thing you need to get installed and working. It's another thing that will rot over time. In 5 years it might be totally unusable and broken.
When I clone a project, I want to be productive with it as quickly as possible.
I am the author. npm/yarn are pretty much the defacto package managers for JS, so that's one less nightmare to deal with. But I never really said that the tooling is better in the JS ecosystem. The better performance is just enough to tip the scales in favor of it.
And pip is the defacto package manager for Python, and it's built in, and it just works, and venv is the defacto virtual environment manager, and it's built in, and it just works. And yes, there are other abstractions built on top of pip and venv, and some of them, like Poetry, work incredibly well.
But JavaScript is in no way different in this regard: Bit, Yarn, PNPM, Turbo, NX, Rush. If anything, JS has more tooling chaos than Python. And don't get me started on webpack and all its alternatives. And then there is the repository chaos, umpteen abandoned packages, repeated instances of malware injection (which has also happened in the cheeseshop, I know, but not nearly as often).
In the end, you choose a tool, and use it until you decide there is a better tool, and you get to work. I used to use only pip and venv. For a while I used virtualenvwrapper. Now I use Poetry with asdf, and it is a very pleasant experience.
The better JavaScript performance doesn't matter in 90% of use cases. In nearly every real-world bottleneck, the answer is not to switch ecosystems, but to optimize. How much traction has JS gotten in workloads where numpy and tensorflow rule the roost?
And you don't like Python's syntax. That's your prerogative. I love it, and so do millions of other python devs.
>> Python is huge, the python:3.9-slim Docker image is 118MB
> Hmmm. 118MB isn't really that big anymore. The docker image would presumably be cached and reused in a deployment pipeline.
Caching aside, it seems that the Python slim image is built on Debian, which will usually have slightly bigger container sizes than something like Alpine, which is comparatively more lightweight/barebones:
> docker pull python:3.9-slim && docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
python 3.9-slim e2f464551004 8 days ago 125MB
> docker run --rm python:3.9-slim sh -c "cat /etc/*-release"
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
> docker pull python:3.9-alpine3.17 && docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
python 3.9-slim e2f464551004 8 days ago 125MB
python 3.9-alpine3.17 d6d1ed462b20 3 weeks ago 48.8MB
> docker run --rm python:3.9-alpine3.17 sh -c "cat /etc/*-release"
3.17.0
NAME="Alpine Linux"
Now, I'm not saying that Alpine is the perfect base distro for your container images, despite it generally being a reasonable pick (I've heard some stories about Python performance in particular, and sometimes there are package related oddities), but the distro that you choose will most definitely have an effect on what you'll ship.
Of course, caching and any additional tools that you may or may not want to include also plays a part. Personally, I just went for maximum predictability and usability, and now build most of my personal container images basing them on Ubuntu LTS, with some common CLI tools included for debugging: https://blog.kronis.dev/articles/using-ubuntu-as-the-base-fo...
Just use whatever works for you, but rest assured that JDK and other stacks will typically also have some overhead to them. Python might not be the worst offender here. Something like Go with compiled binaries is still very nice, granted.
I have always had a very good experience with python documentation.
While I generally do like the python documentation, I often find that it likes to explain exactly how and why a library works in detail. This is great if you want to really learn the library and often I miss this level of detail in for example JavaScript, but if you just quickly want to find the most obvious way to do the most common thing, it can be quite annoying.
Python class syntax sucks. Other syntax is mostly nice. List comprehensions etc are great, I really wish I had those in c++. Plus, I wish I had a similarly useful standard library, repl, and package manager in c++.
Yeah. And I don’t want confusing initialisers or constructors or whatchamacallit, and weird calls to super, and underscore methods. Maybe the language should just be minimally aware of classes and how they work, and build that into the semantics of the language using keywords, rather than giving me building blocks that make it feel like I’m rebuilding class semantics from scratch.
It’s like when it comes to classes, Java is cleaner and simpler than python. Which is weird, cuz python is simpler and more fun to work with on all other fronts (well, almost, concurrency and threading is also kind of easier in Java).
…I really like python, but man it’s warts are annoying.
When I first started using python (somewhere before the 2to3 migration) I was extremely pissed at the object layer.
I hate redundancy and the dunder and explicit self parameters completely stupid. With time I just got used to them .. (thanks partly to editor templates). The private field shenaningans weren't sexy either..
Other than that I agree.. it would be worth a python4
class Foo(Bar):
new(*a, **kw):
"keyword: new"
super(*a, **kw)
print('v4')
bar(a,b,adjust=1):
"no self, shorthand super.parent_method()"
return super.bar(a, b) + adjust
The thing is, every language has serious issues, whether usability issues, documentation issues, performance issues, community issues, standard library issues, dependency issues, whatever. And for every issue, there are some people who just don't feel affected by it (or disagree that it is even an issue), and others who feel it deeply, to the point of outrage. So even if you ever get a consensus on what the issues are, there's even less of a consensus on how much they matter and what to do with them. Some people can live with certain problems and others are really distracted or bothered by them. It depends hugely on the context and environmental constraints too (can your org switch languages? when? on what terms? etc).
I think there's something deeply path dependent about how software people go through languages and fall in and out of love with them. Python was the first language I ever used professionally. It was amazing at the time compared to Java. But I haven't touched it in years now and don't especially want to. It's not that I "broke up" with it -- I just went elsewhere and it wasn't used there. You usually have to speak the local language wherever you go...
At a certain point, I think a lot of us give up on the idea of "loving" or "not loving" the language we use. They are all just tools. Some professional software people still have love affairs with their tools. That's cool I guess, but I have to say, I've written useful software in horrible languages (PHP) and I feel good about that too, and about not caring about the lovability factor (so to speak) of my professional toolkit.
I'm at a point where I think I would turn down any job offer that required me to do anything with python (even just the occasional change). I don't have the time or energy to fight with my tooling and environment that much
It's really a shame that data science, ML, and notebooks are so wrapped up in it. Otherwise we could jettison the whole thing into space
Same. I was at an AI startup that used python for everything and it was so bad. Even worse since it was AI engineers writing a lot of the main app code too.
> It's really a shame that data science, ML, and notebooks are so wrapped up in it. Otherwise we could jettison the whole thing into space
Although I personally feel Python has its place, I contribute to a project that hopes to diversify the ML/scientific computing space with a TypeScript tensor lib called Shumai: https://github.com/facebookresearch/shumai
It does, which surprised me when the author said they preferred JS over Python given the reasons they stated.
There are a lot of reasons to like or not like Python that will become evident after using it in a significant fashion. I was hoping for some of that insight, both to commiserate and celebrate the horrors and joys that I've experienced using the language and its ecosystem for some time. This article was not that.
People joke that Python programming is 'pip install solution', but it's honestly not too far from the truth. Until Go, Rust, or whatever fancy new language can match the wealth of well maintained libraries that Python has, I don't see it ever getting replaced for the quick scripting that the author talks about.
Easy examples I use every day: ML and Quantum Computing libraries.
There is a depth to the Python ecosystem that can't be matched anywhere else.
Honestly, I'm sure I will get a ton of flack for this, but I really dislike Python. I use it every day and have for years and not only has it failed to grow on me (like most languages do), I've learned to dislike it more with each year. That said, I'm locked in. Outside of Python the libraries available are abandoned research projects or hobby tools, at least when it comes to my areas of focus.
Those are really exceptions because researchers love Python. Outside of those areas, there's really nothing special that Python's ecosystem brings to the table.
I'd really like to see machine learning stuff in languages other than Python so that there's less friction in experimenting. I know that would require prying it from researchers' cold dead hands though.
Those aren't exceptions, those are the norm. Yeah Go has really slick libraries to support your favorite protocol, but that's the easy part of programming. If I want to hack together something using computer vision, do some amature data science, or use cutting edge scripts written by security researchers, that's gonna be Python. Pretty much all code that I would wanna steal for my project is written in Python, or has Python bindings as its main way of using it.
I agree, though, the urllib module that he links to it's not the best thing ever when it comes to Python, and I say that as a guy who has written Python code for a living for 17 years now. But other than that I find the standard library more than ok.
The only thing that I can agree on is the slowness, but even that is relative, as we're not all writing speed-critical code. The type annotations never took off because they were, and are, basically un-pythonic, trying to force types on Python's throat, so to speak, is definitely un-pythonic. Unfortunately the "types are a silver bullet"-hype is all too real, so there's also that.
He should have also learned to love dir()-ing stuff.
> the urllib module that he links to it's not the best thing ever
I think the reason it (and the http modules in general) has never been improved is that even when Python was young, there were better third party packages out there, but no single one of them ever got to the point where the Python devs would consider making it part of the standard library. Particularly when it comes to servers, there have always been multiple third party frameworks with significant market share. For clients, we might be getting to the point where the requests library is common enough to be a candidate for the standard library.
Disagree on typing. Modern types, as evidenced by typescript, are very helpful and don’t incur significant verbosity cost. They are expensive in large projects during linting.
My personal recommendation is to use typing and mypy in all new code, coming from somebody who was celebrating new-style classes in 2.2.
IMO Python typing really became good with the advent of Microsoft's type checker in VSCode, and probably PyCharm too, although I've never used it.
Typing with mypy during development never quite cut it because it's optional (unlike e.g. Typescript), and the editor support just didn't quite make it effortless the way VSCode/Pylance did. (I'm talking about development, not CI.)
Have they? Genuinely asking. The recent code samples I did see on SO don’t yet include them and the one big Python project (Django) that I use hasn’t started making use of then just yet, or at least not to my knowledge.
IME they are increasingly used by application developers but a lot of libraries and even Python's own documentation have not really embraced them yet. That makes using them a lot harder - and sometimes less useful - than in comparable languages like TypeScript. Every client we've worked with recently who uses Python was at least trying to use type annotations but not necessarily with the same level of commitment or expected ROI.
Was very surprised to see that in the article! My complaint is the Python std lib is bloated. If I could design a Python 4, it would be a subset of Python. Ie get rid of the various struct-like data structures (eg both types of named tuple) other than dataclass that have accumulated over time.
I don't fully agree with these arguments, but they all have some validity. I really felt his point on the documentation - it's great that it's reference-complete if that's what you're looking for, but it's maddening if you are coming to something to find out what it does.
Lately i've been using ChatGPT for that instead and it's phenomenal. Previously, I'd just open up my site-packages folder in a dedicated Sublime window and just search the source code for what I wanted to know.
If you haven't already or aren't aware, install IPython, use ipython3 as a replacement REPL and use the '?' or '??' operators to open the docs/definitions of the object you want to inspect.
ipython3
import some_module
some_module?
# or
some_module??
You can also type the object's name and hit tab to get a drop-down menu that will list its methods and attributes, like dir() with a better UX. Modules are objects, too.
> If you haven’t already or aren’t aware, install IPython, use ipython3 as a replacement REPL and use the ‘?’ or ‘??’ operators to open the docs/definitions of the object you want to inspect.
you can read the docs in the standard REPL with help(object).
And, of course, IDEs (or editors with decent Python support plugins) will do it on hover.
I have gripes with some things in the current state of Python, package management particularly, but choosing JavaScript because Python's standard library is "barebones" doesn't really make any sense to me.
I've always found the Python standard library to have tons of useful stuff, and when I'm doing something in JS I often feel like I'm missing my toolbelt or something. Then I install a single npm package to do something simple and it winds up having 350 dependencies.
It made me wonder if I was hallucinating, so I went and checked... my `node` execurtable is 78MB. Thanks to its robust standard library, my node_modules folder is only 884 MB.
I never said "you should use JavaScript." The post is my own justifications for avoiding Python and I'm not even saying JS beats it on all of these points. The better performance and adequacy of npm/yarn just barely tips the scales in favor of it for me.
What is such low effort post doing here? I use Python way less than I used to, but this is just unfounded whining. And imagining js is better on those points... omfg.
I came here to say the same. The author clearly has only a very superficial knowledge of python (and a large distaste for it).
Throughout my studies and career I've written c, c++, java, javascript, perl, bash, python and a little bit of go.
Python for me is by far my favorite and most productive language. Expressive syntax, an unmatched wealth of useful libraries and most importantly: when I come back to code I wrote months ago I can easily read and understand it! Which can't be said of my old perl code.
I also love how python has been picking up steam lately, 3.6 - 3.11 have been splendid releases with plenty of goodies in each one.
>The author clearly has only a very superficial knowledge of python (and a large distaste for it)
I wouldn't make assumptions like that. I've worked with production Python codebases. In fact, until recently I was working as a DevOps Engineer in a hedge fund building much bigger, more complex systems than a typical CRUD backend. I worked hands on with some of the Python repositories and it was extremely painful simply because of the nature of Python.
Had to play with compiler flags to reduce trivy to a proper size (it was 300MB with default flags), and that was only the binary, without any containers.
And the dependency story is hardly any better than Python.
I'm all for people finding better programming languages and explaining why they're better for them… But without that context, without any context, this feels like they're scraping the barrel to make a point to somebody with no discernable reason why.
Python has plenty of issues, but it's still great for a huge pile of use-cases.
I've built a career on Python and Django. Even as my frontend work migrates into thick assemblies of javascript, I can't imagine using anything else for the backend for complex systems, but who knows what the next 20 years holds.
Sure. If you've done nothing significant with the language then a breakup is easy. Easy come, easy go.
If you've spent years, or even decades, building a portfolio with Python then the breakup is going to be much harder, just like in human relationships. Some things will make sense to leave in Python until end-of-life. Other things will be worthwhile to migrate to Go. Of course your new greenfield projects can start off using Go.
Just know this - you're going to go through this again in another 10-15 years, if not sooner. I've been writing software now for 40 years, that's just the way it goes.
And I'm not entirely sure it would be good idea for general purpose language. Knowing the history servers. Which likely will anyway have some critical design or security issue at one and probably many points in their life.
There's the adage that the standard library is where modules go to die, which seems to ring true in Python's case.
Having a big standard library can be great, especially for things and designs that have been settled years ago, but inclusion into the standard library means iterating upon those modules will receive pushback from maintainers looking out for consumers of the standard library who need it to remain stable for potentially decades.
It's rich that the author unfavorably compares python's docs to go's. Go's documentation is barely more than API auto-doc level documentation: and many if not most of the open source projects using it have followed suit. It's some of the worst documentation out there, in my opinion.
> Python doc peaked for me with the 1.x “library index to keep under your pillow”
I can see why that’s nice, but I find it odd to be described as a peak. While the details of the standard library it documents have evolved, I don’t see how the current version (linked from the main docs site with the same “keep this under your pillow” line) of the same portion of the docs is any worse:
Because it’s so much more readable without being littered with numerous examples and footnotes all over the place.
It just gave you exactly what you needed to know and otherwise stayed out of the way. Remember l, this was from an age when online doc didn’t really exist… I certainly never used the html version.
When you’re on dialup a local, quickly searchable version was very valuable.
I've been recommending Python to the occasional aspirational young programmer. Is it already passé? What would you recommend instead for a starter language? Looking for beginner-friendliness, widespread use, and longevity.
edit: to be clear, I hope this won't devolve into a language flamewar. I'm sincerely interested in other devs' opinions, and hoping that either Python is still a good recommendation (which seems to be the consensus so far) or that there's a better alternative.
No, it isn't passe, this developer just has some personal gripes with it that can range from understandable to "you'd complain if we did it any other way" with regard to their question about why type annotations were implemented the way they were.
I hate a lot of things about python because I've been using it for almost 20 years, and I know its innards, its history and its trajectory. I want to love Nim or Julia or Typescript, but they just aren't doing it for me. But you can't hate a language as deeply as I do without loving it as long as I have. I don't think this article, or my own opinions, are representative of the community.
I have, for the life of me, never understood the 'beginner friendly' argument for python.
Java, PHP or JavaScript for 'widespread use and longevity'. None of these are going anywhere, and I think you'd find more resources for beginners to advanced users for those 3. Yes, of course there's others - everyone has their faves. And Python will continue to kick around as well, but I've just never understood the 'beginner friendly' bit.
Java the language used to be so simple that it needed significant library usage to accomplish anything at all. It aimed for ‘safe C with classes’ and succeeded… in the enterprise where management was making technical decisions. After feeling the heat from C# it managed to catch up, mostly, to modern realities. Not a good beginner language, despite the simplicity.
PHP was not designed at all. It took a decade to make it more than a template processor. The biggest, by far, selling point was ease of deployment: ftp and done. Good if you want to display something in a browser. Learning programming, not so much.
Javascript is starting to become a sane language with ES6. It’s an accident of history that became an industry standard due to sheer power of will of browser companies. Tooling complexity in its ecosystem rivals, if not exceeds, that of C++. Recommending js s as a language to learn programming on has been until last couple of years irresponsible.
Python was designed to be beginner friendly, it was the next iteration of other beginner-friendly languages that had some academic research done about, you guessed it, beginner friendliness. It is not an accident it’s recommended for newbies! Due to that and a decade of 1) numpy for biological computing 2) django/flask for web services it’s ubiquitous in two very loosely connected domains, giving birth to jupyter and tensor libraries, and here we are. Turns out a batteries-included standard library makes packaging not a priority for too long.
I would guess the main reason it gets recommended to beginners is because it's the most prominent language with the most minimalist syntax, so you can read it more closely to a written language.
Also, being interpreted, you don't need much (or really any other than the interpreter itself) tooling to start playing around with it. This is true, of course, for lots of other languages.
I think also the fact that people do use it for real solutions makes it more appealing to recommend than a "toy" language like Logo or BASIC. (Mentally, I see BASIC as separate than VB. And yes, I am sure some people will comment that real solutions are built in BASIC, but I am sure these days Python dwarfs those in count by a factor of 100, at least.)
In my experience PowerShell fits well as a toe-dipping language.
It allows to solve the menial tasks someone with no programmng experience usually needs to solve, can interact with HTTP/REST-like APIs, sometimes has the modules for a popular solutions, is object oriented, lax on the indentation *smirk*.
> In my experience PowerShell fits well as a toe-dipping language.
Ugh. Sorry, I've not really got anything constructive (destructive?) to say in support of that other than (a) in practical terms it isn't a transferrable skill beyond Windows, (b) the Naming-Conventions-OfThings is both awful and verbose, and (c) I've never had a use case where more than a handful (at most) of my fellow devs would be happy to work with it in the future.
YMMV and I appreciate this is very much a personal opinion.
a) thats only for modules designed to interact with Windows features. Sure, Get-ADComputer doesn't work on Linux, but... by default Python doesn't work with a ton of things which are available through the wast library of Python modules. Same deal with PS, you can't interact with Snipe-it or Netbox by deaful... but there are modules for that.[0]
Basics works everywhere. In my personal experience I often found myself in a situation where I'm spending a lot of time wrestling with *nix shell (especially finding workarounds for the differences between Debian/Ubuntu and RH/CentOS/Rocky) instead of spending 5 minutes on PS script which would would everywhere, just supply the distro specific paths.
b) not a problem in the real life. Come on, you don't sprn you time writing the paths, you just TAB them - same thing with PS, except it works on cmdlet names AND their parameters, out of the box, on any platform. Ubuntu has it now by default (for some supported things), RH-like - not.
c) well they probably had a more familiar to them tool on their hands already
YMMV, of course, but the thing is what you are being constructive here, with explicitly stating things you don't kno2 or understand.
[0] and there are Py modules for that too, but they are not the part of the default install too
I appreciate the response; as I say, YMMV. I did feel a little misunderstood at the end of that response, though, so I'll clarify.
> explicitly stating things you don't kno2 or understand
I've done Windows development since 3.1 (and .Net since 2001) so in that time I've written a lot of PowerShell. I'm not offering uninformed second-hand opinions.
For (a) I'd argue that the lack of adoption outside Windows makes it de-facto not really a transferrable skill, even though it does run elsewhere. For (b) so what if it is easy to autocomplete? It doesn't make it any less ugly/verbose. For (c) yes, that was exactly my point. Stuff needs to be maintainable, and if fellow devs have other more familiar tooling then using that tooling is usually more appropriate.
If PowerShell is for you, great. I don't feel the need to convince you otherwise; in your situation maybe it is. But sometimes a difference of opinion is just that - a difference of opinion, and not ignorance of the subject matter.
> lack of adoption outside Windows makes it de-facto not really a transferrable skill
If you want to only write/use PS - then probably, but... if this is yours environment - you chose the tools, if it's not - the overall concepts and workflow doesn't differs too much, especially for Python.
I had an unpleasant experience of rewriting a Python 2 script to Python 3. At some point I just said "fuck it" and rewrote it, from scratch, on Linux, with .NET SNMP library - and I got a working script in an hour, compared to 3 days of headache with a known good Py2 script which I only needed to adapt to Py3.
The difference was in the quirks of Python (especially on strong typing and indentation), not in the program flow.
Later I finished rewriting it in Py3 but the overall experience of writing in Python left a sour taste.
A person who would start with PS could easily adapt to Python (or honestly any other language) if he would understand how the things work - and PS allows, IMNSHO, that in a quick and easy way.
But if someone just copy-paste the code from SE - does it matters if that happens in Python or PS?
> so what if it is easy to autocomplete? It doesn't make it any less ugly/verbose
LOL, "I need a PL what is easy for a beginner, so I would NOT recommend an explicitly verbose language for that!"?
a) easiness of autocomplete allows the discoverability of the options. Just a simple Ctrl+Space offers all the options of a cmdlet (conveniently listing them with the precedence used by the author, leaving all the automatic shit added by cmdletbinding() at the end) and this alone helps tremendously with writing. I don't keep all the things, options and parameters in my head (and I don't want to) and a beginner doesn't know them in the first place.
Most of the time I just write something and see if the are means to do what I want through the autocompletion of parameters and cmdlets. If I don't see the appropriate things or they don't work as I expect them to work - only then I consult with manual. If in your opinion nobody should write a single LOC without a couple of hours in the docs...
b) I often hear about how the verboseness of PS as bad thing, but... honestly, IMO, it doesn't matter, it's not THAT verbose as Java, it's not full of obscure and senseless abbreviations and names (especially compared to Linux CLI) and if you compare the actual similar code.. it's not that big difference in LOC and line length. Oh, and you don't reinvent the wheel each time you need to have a working help and argument parsing *smirk*.
c) are we still on the "PL for a beginner" topic? For a carpenter microscope is just a very bad hammer.
> difference of opinion
Let's get back to "PL for a beginner". Between Python and PS the latter would win just because it has a better IDE/autocomplete and has automagik on a lot of things what would drive a beginner mad in Python (oh god, just calling an external binary and capturing it's output...)
PS, as an anecdata: I have a friend who can write some Java, for util level things. I've seen his PS code - he treats PS as a full fledged PL (which again - isn't a bad thing, just not the best way to spend your time writing PS scripts). I doubt he wrote anything in Python, but of what I saw in his PS code means he would have no problems (well, except strong typing and indentation, LOL) writing something in Python.
Some good points (though I remain unconvinced about PS personally).
The only thing I'd note is that unfortunately by not mentioning it in my earlier reply I left you thinking I was suggesting Python over PowerShell, which makes sense given the way others were discussing the topic.
On this, however, I agree with you in that I too would not automatically suggest Python as the best learning language. I'd actually plump for Go scripting or C# (single file), but on the understanding that it's for learning business domain or web programming. For the true beginner I don't really have a strong opinion so maybe PS could work.
Python is syntactically simple but that doesn't necessarily make it a good choice for beginners. I've seen students spend hours wrestling the interpreter over whitespace issues.
I tend towards recommending python just because of that. I used to be a TA in an intro to programming course, and it's unbelievable the mess complete beginners can make when indentation isn't enforced, like in {} delimited languages.
The docs you linked say that IDLE can help with indentation, not reindent code for you. This might surprise you, but students don't necessarily know how to preserve indentation or reindent code as they cut/paste around.
Python is a good choice for many large projects, as well. Typing has helped a lot when it comes to managing large codebases in Python that would have been a pain to manage using something like Python 2.
I agree with some of the sentiment here, but at the end of the day i’m not sure i’d be able to make a clean cut like OP suggests.
Python is used in so many places that’s it’s part of the lingua franca of programming. I’ve worked at multiple ruby shops over the last few years and pythons still been there in force for data applications.
I much prefer other languages (Ruby, Kotlin), but at the end of the day i need to be comfortable with the language that will be spoken for years to come.
I'm getting stuck into Go at the moment and thoroughly enjoying it, but can it really fill the same niche as Python as the article suggests? (Sincere question.) Doesn't the absence of an out-of-the-box REPL hinder quick scripting? As I say, I'm new to Go so would love to hear about people's experience using it in this context.
I use go and python pretty heavily, and I probably write twice the amount of functionality and three times the number of bugs in python in a day as go in a day. I take that to mean that they're good at different things, and therefore probably aren't quite as interchangable as the author makes them out to be.
I don't disagree with any of his points, actually, and agree with almost all of them. The standard library has some holes - though I think that's true everywhere. I don't know that eg Ruby or java don't have holes either.
I do think the packaging Story in python is nuts. Why does gem just work for Ruby but python's story is such a disaster? Though imo my modern advice is "just use poetry and ignore everything else".
Pythons main draw for me is some combination of:
Type hinting is good enough. It has a big escape hatch to be able to do C stuff if you need to. Numpy. The language is still straightforward enough that beginners can approach it and the experienced can wax reasonably eloquent with it. And it's pervasive.
So when I sit here and I'm like "ugh I need a thing to sit here and hit an api and dump it to a file every day in a cron job, and I don't want to spend a whole day writing this". I go for python. And while go and java and rust etc would be just fine, I still end up taking longer than I'd like.
Somehow python is just the shortest, sanest route to just getting a small to medium sized doodad out the door and running reliably in a small footprint of time without needing to remember boilerplate (java) or think way lower level than I'd like to (go/rust). Python just lets me do it with low cognitive overhead. Sometimes while I'm half-listening to a meeting I'm in!
Honestly my biggest gripe with python is it's really hard to tell early enough when your program is on a trajectory to be too big for python. And I don't mean from a perf perspective or anything, I just mean when it goes from being "easy python" to "oops it's spaghetti now." There's a tipping point and I think even seasoned people end up well past it by the time they pause and rub their eyes and think "ugh I wish this were in java."
> I do think the packaging Story in python is nuts.
That is one of my three big gripes with Python. The other two are the horrible way the 2 to 3 transition was managed and the GIL.
But none of those has driven me to switch to another language, nor do I expect it to. Go seems to be this author's alternative of choice; perhaps if my one goal in life was to write a production network backend without using any dependencies, I might agree, but it isn't, and having done some work with Go I find it gets in my way much more than Python does. I have the same problem with other languages.
For me the greatest pain point with Python is that you are never sure about what any line of code does, because basically everything can be redefined.
It might not be a big issue in a small script, but as soon as you get a biggish codebase, with mixins or magical utilities written a couple of years ago by a developer who in the meantime left, it takes hours just to track the control flow in the mess of patched methods, dunder stuff calling nested supers, etc.
To say nothing of big frameworks like DRF. There isn't even an agreed-on way to mark methods that are overridden from a base class.
Plus, simply changing the order of imports can violently change the semantics of the exact same code.
A fetish for hidden magic, state everywhere, and basically global coupling of code vastly override the supposedly simple syntax: it might be easy to read, but it is impossible to understand, locally.
I do not understand the incentive structure that would lead anyone to believe such a low effort blog post brings anything to anyone. The points raised are very standard, have reasons and counterpoints, and finally just invoking Go and JS without any details is so meh...
Don't forget how much of a pain packaging apps for end users is. There are helpful tools out there for it, but nothing that comes close to the ease of Go's default static builds that I have found.
> the ease of Go's default static builds that I have found
Seconded.
These are examples [1] of the scripts that I use on Linux, MacOS, and Windows for producing cross-platform builds. Run the one for the platform you're on, and it will produce stand-alone builds for all the targets (Linux, Windows, MacOS Intel, and MacOS ARM). And the builds are small enough that in many cases for simple tools I commit them straight into the repo for easier usage.
Python's lambda sums up everything that sucks in Python. It's a crippled, half-assed implementation of something which is considered a basic requirement for any programming language aiming for mainstream adoption. Even Java 8 did a better job after realising it wasn't too late in the day. Python's virtualenv requirement is also another admission of failure, IMHO.
I want to break up with Python, too. The one-size-fits-all philosophy that runs through the language from end to end leaves me feeling like I'm typing with three fingers. Sometimes its Right Way really is okay or even right, but sometimes I'd really, really, rather use something else. I worry about a generation of programmers for whom this is the first, main, and possibly only thing they've learned. I worry about them being brain damaged.
But where would I go? I clicked through hoping to find a good suggestion, and found none.
Python has become the lingua franca of programming, in many contexts, in many fields. You don't have a choice. You have to be able to read it, if you want to read what people are doing. You have to be able to write it, if you want people to read your stuff. It's where the libraries are. It's where stuff is happening. For better or for worse, Python won.
Even if I don't care about any of that, I really don't know where to go.
I really loved perl. I loved the powerful expression and conciseness. I miss it. But perl 5 is old, and it shows -- a lot of good ideas have come along in the last couple decades, and a lot of things that seemed like good ideas at the time really haven't worked out. A decade or so ago, I was excited about perl 6, but it doesn't seem to have worked out.
I don't like python. But I don't know what to replace it with. Javascript and Ruby seem like the serious options to me, and it's hard to take the one seriously, and the other is so niche that that itself feels like a serious drawback. I want a general purpose scripting language that can do small scripts well (Messes allowed! Shortcuts encouraged! Power in a small space!) and grow to large projects well (Thoughtful object system! Good package management! Good support for alternative paradigms!)
That question can't be answered without knowing what kind of programs you're writing. You got a lot of options if you're thinking about websites/apis, almost none if it's machine learning and basically everything is better if you're thinking about GUI applications.
You know, I hadn't thought about it that way before. Perhaps the dream of a general purpose language was always incoherent. Perhaps the mess you get when perl tries to offer options to do everything well, and the suffocation you get when python tries to do everything the same way, are inevitable. Maybe using one language for small and large projects was never going to end well -- maybe either the language or the programmers were always going to do it wrong.
I suppose I have been assuming that the best policy is to do as the Romans for a long time now. Windows apps are C++ (or is it C# now?) because that's how things are over there. Android is Java, or Scala if you must -- at any rate, you hardly get to pick. Iphone requires learning Objective C. Jquery for frontend, or whatever the cool kids are doing; PHP on the back is good enough for most of the web, and it's good enough for you. And as you say, in ML, Python is not optional.
And as I think about it, I've been using specialized languages in specialized contexts for a long time. It seems the knowing the underlying language is only ever part of the problem -- you have to learn the specialized language for what you're doing, whether it's GL for graphics or your web framework's way of doing things, or MFC or .NET, or . . .
Yeah. Small tools for specific purposes, and follow the local ecosystem. Things have been going that way, and it's probably a good answer.
If you try to please everyone you end up without personality. Python has plenty of flaws but it feels also as a very distinct way of solving a vast range of problems. But its longevity will depend on how well its community can address legitimate complaints (which do not require it become all things to all people)
If you chose JavaScript over Python for backend scripting, sounds like you want to hurt yourself.
If JavaScript is your goto language, then ok. But, otherwise, Python is the most used language for writing backend scripts, so it's pretty good at this, but also there's a lot of material online.
I have just started getting into python as I'm experimenting with pytorch and after a lot of googling I'm still trying to figure out how to use conda properly. Could anyone point me to the best way to manage python environments and packages?
I don't think there is a "best" way, in my biased opinion package management for Python is terrible. It works for trivial cases but if you do anything serious it will get unmanageable fast.
Everyone will tell you of the "best" (i.e. their favorite) way to handle packages and dependencies. Usually mixed with some sandbox framework. Everything will be broken in some way: nonstandard, convoluted, too slow, cannot handle corner cases, or just way too difficult to understand. Even those labeled "for humans". Everyone will agree the situation is a mess "except for this one way that works": never trust that way, it doesn't really work past trivial cases.
Of course this is just my experience. But I feel after years of battling with Python and trying different things, I've earned the right to say this.
It encourages to set up project specific definitions which are saved in the local pyproject.toml file. Keeping everything local and project specific, including the env definition, turns out to be a fantastic boon to reproducibility and sanity of mind.
Use mamba instead of conda to install your packages, and always use the conda-forge channel. mamba is essentially a drop-in replacement. I have always found conda to be horribly slow for installing packages. For environments:
- `conda env create|list|remove` commands to manage them
- `conda activate <env name>` to enter your environment
- `conda deactivate` to return to your base environment
If you want to use a conda environment in jupyter, you must install ipykernel and create a kernel definition for your environment:
(Lots of the other advice here—mamba excepted, and that might be a good choice—is good for python in general but potentially will cause problems if you are otherwise using anaconda.)
Pyenv for Python versions and/or environments, Poetry for package management and/or environments, and pip if you end up needing it for package management.
The article mentions using JavaScript in place of Python. I use JavaScript a lot for browser stuff but can JavaScript be used for the random command-line scripts that I implement in Python? (Genuine question, not rhetorical.)
Node is an interpreter just like Python, gives access to OS features like sockets, file systems and processes, so yes, you can.
However I’d rather not if you value your sanity and want to use typescript, because then you introduce packages and compilers and the whole npm ecosystem which makes building C++ look easy and sane.
To build what I’m currently working on it is required to use docker, pnpm, npm, nx, tsc, corepack and nvm. I think. Not sure at all. I haven’t built some parts of the project. There’s more involved to run most tests.
I use Node.js/TypeScript for all my scripting needs. Together with pm2 which can auto-generate a systemd service if it needs to run as a service on boot. Coming back to a strongly typed project / script is actually really beneficial to refactor or extend.
Last time I argued, like the TFA does, that Python's typing system is both too complex for casual users and useless for power users ("it doesn't do anything" is about right), and that this makes it hard to evangelize its use to other devs who aren't sold on type systems ("but this doesn't do anything!"), I got into a 30-level nesting flame war with some HN regular who just wouldn't let go.
So that's still my line of thought, but I'm already regretting typing this on HN.
Yeah, I think I agree with you. I still find it curious that the python language server is quite capable of inferring types from unannotated code yet most of the type checking tools for python seem to explode as soon as they encounter an very popular yet untyped library. I guess typing is more of an afterthought than a priority for most dynamic language developers so it doesn't get much love.
> I still find it curious that the python language server is quite capable of inferring types from unannotated code yet most of the type checking tools for python seem to explode as soon as they encounter an very popular yet untyped library.
There are multiple python language servers, but if you mean the Microsoft one, well, that just incorporates one of the best of the Python static typecheckers (Microsoft’s pyright)
Personally, I’ve been pretty happy with python, I think it works wonderfully as a glue language (like bash); I.E: you shouldn’t write a lot of it, you should use it for plumbing. Its fantastic for that.
> my friend made a write up before about the inadequecies of python
To be honest, this seems like even less of a balanced criticism than the article this overall discussion is based on. A more balanced summary of the valid points might be: "Python has issues that you will probably trip over in certain kinds of applications". Which is true of every language.
> I think it works wonderfully as a glue language
It also works very well as an application language, just not for all types of applications. Which, again, is true of every language.
Every language that's been around long enough has issues. Python has its own of course, and the ones the OP listed are real. But none of them are show-stoppers or as big a deal as to stop coding in Python.
Here is my take on what the OP is actually trying to say: "I don't want to code in Python any more (because there are newer cooler languages like Go?) and here is my list of reasons for rationalizing my rather irrational decision"
Agree with syntax and slow, the others not so much.
But my bigger reason for avoiding Python when I can is I just think the days of dynamic languages are behind us. Which is to say, we are past the tipping point where the ergonomics of adding typing are less costly than the benefits, and that applies even for short scripting use cases (in part because so many short scripts grow their way into real production code that needs to be maintained).
I went down the rabbit hole of adding type hints but at the end of the rabbit hole it was a lot of work and the value realised was still only 50% of that from having a real type system. Vast numbers of type errors still not getting caught in my editor, autocompletion stymied at shallow points where the type system gets lost, and as the weight of the project grows the tools like MyPy getting slower and slower as they have to process massive amounts of the dependency tree just to infer the type of the single line you are typing.
These days even for short scripts I am preferring to write them in languages like Groovy which get me all the benefits of Python from the dynamic language point of view but built on a foundation of a real type system which means I have a pathway to grow the code into full static typing using any of the JVM languages if I want / need to. And it also largely solves the problem with performance.
This was awfully generic. Not necessarily wrong, but certainly not a meaningful blow against python that's going to show anyone the light and give them tangible thoughts about using another tool. (Especially given the breath of what python is used for. Does it suck at everything?) What are we supposed to get out of this?
I'm not sure go should be compared to python as they are designed for very different things. Go is more fairly compared against modern c++ or rust in my mind. Python is not designed to be lightweight or fast (although it has been consistently improving with each release) but favors expressability and run time flexibility instead.
This is garbage. It typifies a kind a drive-by rant disguised as a rational opinion that is basically insulting to the intelligence of everyone, regardless of language preference. The level of narcissism and pettiness is high, and the level of rational discourse is low. Entitled spewing of garbage.
> Python’s documentation sucks
Dead giveaway. Well, it doesn't suck. It's pretty great, pretty comprehensive. OH... Wait, ot isn't formatted with a index pane. that's why it sucks. The author probably has problems with the font-kerning too.
> Every project seems to use a different tool and it’s a massive headache
Um, no. Everything really uses pip. I don't even really like pip, but everyone uses it so I use it. You know why? Because it's never, ever a pain in anything at all. It just works.
> Python’s standard library sucks
What? is this satire?
> Python is huge
This has got to be satire. Author prefers "go". Nothing wrong with go, but nothing wrong with Python either.
> Python syntax sucks.
Nuts! this guys is legit insane. The only really controversial thing is the whitespace-indent vs. delimited thing. Guess what? I really dislike the indentation scheme. You could have a reasonable debate over that relatively unique syntax scheme. But the entire syntax as a whole is cleverly regular, predictable and tidy.
> Python is slow
Well, as the author said, "Python has been my go-to language for a quick bit of scripting". Slow is a perfectly acceptable trade-off there. And you could certainly come up with a different set of trades that also make sense. To say "SUCKS" implies it's just stupid and sub-optimal everywhere; a lose-lose-lose-lose. Which it isn't.
> It’s like everything under the kitchen sink has been jammed in.
I though you said that the standard library "sucked"; is there too much sink or too little? "let that sink in"
The author seems to be infatuated with javascript and go (at the moment), but neither is really in the same niche as python. That doesn't make any of those other choices "suck".
Larry Ellison and his company and products suck. Software patent trolls suck. Python does not "suck" because you like other things at the moment.
There is no reason to start a new project in python IMO. Existing ones should be deprecated.
the packaging ecosystem alone is enough to make anyone mad. I maintained a production system in python for a few years a while back and code refactoring was extremely painful.
Oh yeah, "every language has issues", or "if you just invest a little effort you'll get it", sure. But those languages that I use don't prevent me from installing a CLI tool and have me fighting with its half-witted package manager to do so. And they don't (or they very rarely do) mandate me to learn idiosyncrasies so I can do basic activities.
The only thing that keeps Python alive and well is the fact that many people don't know anything else -- and never will know anything else -- and that's one of the reasons it's widely taught in universities. The AI/ML stuff can be replaced with its underlying C/C++/Rust libraries in a week so that's not an argument in Python's favor at all.
I wish people stopped pretending Python is OK. It very much is not. It's a collective delusion kept alive by network effects.
I can't agree with this. I have always had a very good experience with python documentation. One can use the built-in "help" function which works seamlessly with the docstring feature of the language. The complaint in the blog post seems to refer to the UI of the website missing a table of contents for functions. Yeah sure they could add that but I don't see it as a big point.
> Python’s package management sucks
Hmm, it has some weaknesses but I wouldn't really say it sucks. Going deeper ->
> Every project seems to use a different tool and it’s a massive headache. Off the top of my head there’s ...
Don't all of these use pip under the hood? I personally use the lower-level pip and virtualenv tools, but some others enjoy the convenience of poetry. That's a bit of personal preference. It's a bit more akin to an IDE choice than a feature of the language. None of conda, poetry, etc. are core Python features.
> Python’s standard library sucks
I have to disagree again, I think it is pretty well designed and minimal on purpose. The community additions of numpy, etc. are by design not part of the core language to reduce bloat.
> Python is slow
OK sure, it is slower than compiled languages like C++, that is a concession we make when opting for the ease of readability, writability, usability, etc.
> Python is huge, the python:3.9-slim Docker image is 118MB
Hmmm. 118MB isn't really that big anymore. The docker image would presumably be cached and reused in a deployment pipeline.
> Python syntax sucks.
This one I can't even understand the reasoning for. The python syntax is what people love about it. I personally dislike the walrus operator, f-strings, and some of the other newer features (did they add the switch statement yet?) but those are my only gripes. And they are more pet-peeves / personal preferences than complaints.