Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I used to like Python in the 2010s when it felt like a breath of fresh air relative to PHP and Perl.
Now it feels like a weird PHP itself that is slow, brittle, and dangerous to write code at scale in.
The loose typing, potluck standard library, and horrible package manager (insofar as the community does not know how to package code) all feel so dated.
by echelon - Who cares tho. The agents deal with all of that, if you’re still looking at the code or caring about anything other than the loops and orbs you’re at the wrong level of abstraction. The important thing is the models have tons of python in their training data.by slopinthebag
- I feel the same way. It was, back then “the second best language for everything, the first best at nothing”
Can’t take credit for the quote, read it somewhere.
The whole language changed when they kicked what’s-his-name out, and it’s a tool I almost never reach for anymore, whereas 15 years ago it was my Swiss Army knife.
by irishcoffee - I don't understand how people talk about how Python is "easy to learn for beginners" or "easy to understand." To me it's so hard to remember and follow all the weirdness. Racket / Scheme / I dare say even Haskell would just be so much simpler for learners.
I'm with Conal Elliot when he said on Type Theory for All that it is sooo much harder to understand a program in Python.
by adamddev1 - Python certainly has some baggage, especially the typing system (which is still not finished, if you're looking at static typing and so is implemented differently by type checkers) and pip's safety, or lack thereof. But comparing it to PHP or Perl is rhetoric leading you one step too far.by KK7NIL
- I felt the same way about moving to Python versus PHP and Perl.
I still really enjoy using python though. It's not really a fair comparison because I hadn't used PHP and Perl for as long but I just don't hit some mystifying issue every single session like I did with those languages when I'm using python. I honestly have never even read about that __debug__ constant. It's fun to hear about it but it's just not something that's comes up much.
by plant-ian - It is 30+ years old with all the baggage you would expect. It’s very much a product of its time.by datakan
- Python is just such a weird language in general despite its popularity that I honestly cannot recommend anyone who starts programming to choose Python as their first language, contrary to popular sentiments. I mean, I was one of the first person to start using Python when I was in grad school almost a decade ago when everybody else in my field was still using Matlab for their lab code, for the simply reason that Numpy was less awful than Matlab and I needed something that can easily print graphs to PDFs.
The only thing good I can say about Python nowadays is that it's easy to get started for the first five minutes, and then you'll have to deal with all of its weirdness: significant whitespace, truthiness, duck typing, GIL, distribution/packaging, etc, etc.
I was a big fan of Julia as the potential replacement for Python for science for such a long time and I had evangelized it a lot previously, but recently I've been more and more convinced that JIT/multiple dispatch was only good if you already know how to program well to begin with, which for a lot of academics who are not working in computer science, they write quite horrific code. I think it may be better off to skip Python altogether and write your code in a statically typed language to begin with.
by YuechenLi - > and then you'll have to deal with all of its weirdness: significant whitespace
By "weirdness" here you apparently mean not having to worry about matching up curly braces, and getting what you want automatically just for indenting your code the way you're supposed to indent it anyway... ?
> truthiness
Which is different from how it works in other similar languages, how exactly?
> duck typing
Which is weird, how exactly?
> GIL
You can go a lot further than five minutes in Python without having to worry about threads at all, and if you do attempt threading, unless you're writing C extensions, the worst thing the GIL does is deny you the multi-core processing you thought you were going to get.
> distribution/packaging
Tons better now, but it was honestly never difficult, people just didn't care.
by zahlman - I hate Python and I'm onboard with putting it down in many ways, but significant whitespace isn't weird in a first programming language. It's only weird if you've absorbed from some other language the convention that whitespace shouldn't be significant.by Chinjut
- > I honestly cannot recommend anyone who starts programming to choose Python as their first language, contrary to popular sentiments
> I think it may be better off to skip Python altogether and write your code in a statically typed language to begin with
Having a good REPL is a huge advantage for beginners (and expert users too), but I'm not aware of any (popular) statically-typed languages with a good REPL.
Despite Python's many faults, it's easy to install (especially on Windows), it has a large standard library, there are third-party packages available for essentially everything, it comes with a user-friendly REPL out-of-the-box, and it gives comprehensible error messages. I'm not really aware of any other (popular) languages with all these attributes.
- Are academics who are not working in computer science interested in learning statically typed programming languages?
In the past, the usual answer to people who need a programming language but did not want to learn programming was to give them a domain specific language that focused on solving the specific problem they wanted to solve.
by belorn - I think Python remains a very good intro language for getting kids in the door because it doesn’t demand too much tedious stuff, is flexible, and lets people actually solve problems rather than doing computer science.
In my experience the difficulty is understanding what exactly is important when teaching someone something new. And it largely depends on the goals. What you’d teach some biology undergrad is going to be very different from what you teach a bunch of robotics team high schoolers (and no you’re not teaching them the best language for controls and embedded).
by Waterluvian - Love the investigation and write up.
Took me down some rabbit holes, but interesting to see the chatter about the fix here:
https://github.com/python/cpython/issues/80233
Initially you could reassign True,False but that was verboten with the switch to python 3! The walrus operator was the one simply an oversight.
https://python-history.blogspot.com/2013/11/story-of-none-tr...
Explanation from Guido himself
by persedes - Python is awful. There are so many one offs in libraries, none agree on a style, it’s slow, and it’s way too easy to do the wrong thing. I often work with data scientists and have to productionize their jupyter notebooks which is pure suboptimal hell. I guess it must be a good easy learning curve for research/scratchpadby hmokiguess
- I used to build quant investment notebooks that had to be deployed in production. Lots of problems with that. Mine were: Notebook cells run out of order, so you often have something that works in a session, but not in a fresh run. Developing against limited datasets, so you fail against things you didn’t know to test for. Small adaptions that have to be made every time the notebook is translated into a code file. We streamlined it by making a graph-structured Computation a first class object that tracked staleness as code or data was updated. Then that class could be directly published, and when failures happened in production, the graph could be serialized with the inputs and intermediate calculation data that caused failure, for investigation in a notebook.
We open sourced the implementation https://github.com/janushendersonassetallocation/loman
by edparcell - How is that a language problem? Data scientists are not engineers. No matter what language you give them, they will hand you something you are going to have to polish for production.
The fact that Python has become the language of choice for machine learning and data science is not a language issue.
- When one writes jupyter notebooks for DS you are not writing python. If you ask 10 DSs explain to me what python's attribute lookup model is and why is it different from other OO languages like say Java or C++, they would not care about it. The only thing DSs care about is the rich DS Library support and fast speed of protoyping. To a DS using jupyter this is almost the same feedback loop as a type system at compile time.
Have you tried using `uv`'s newer tools? They help a lot e.g. with linting speed, lock management, package dependency separation, correct python version mgmt and no need to fudge with venv.
by itissid - > it’s slow
For little utilities, it’s faster than a lot of alternatives - just start the interpreter, no compilation needed.
It’s all relative, but if you view it as replacing bash scripts for renaming files or running other tools, it’s 100x better.
by ks2048 - Python is a language for "consenting adults". It doesn't try to prevent you from doing awful things so you can do great things. People who can't program well are given plenty of rope to hang themselves. It shares that with Perl and Ruby.
That said, I find it the nicest, cleanest option of the three. I still wouldn't use it for large and complex projects. I really like it for stuff where one might otherwise use shellscript. It's way way better than shellscript... except if it's all about files and running external commands.
by ahartmetz - The performance hell thing is also also kind of a virtue, though. The language is awful, so everything that does any amount of compute is FFI'd into third party libraries (numpy, torch, sympy, etc). Those libraries are for the most part pretty well designed... or, at least, keep you in a few pretty well-constrained patterns that are easy enough to translate.
If you've ever read through FORTRAN code from a mathematics department or MATLAB/C/C++ from (non-software) engineering disciplines, then you probably understand why productionizing a jupyter notebook is definitely not the worst of all possible worlds.
by fultonn - You don’t like working with data scientists. The data science Python ecosystem is really a separate beast that’ll have “normal” coders scratching their heads at the best of times, some of the most popular packages do all sorts of metaprogramming, and the standards for code quality are very different. Don’t blame the language. Well, blame it only in that it allows such things in the first place, which does have some very nice precipitations now and again, as well as some very bad ones.
In an age where people are still standing by C over memory-safe systems programming languages, I feel quite comfortable depending Python for the great many things that Python is good at.
- I’ll never not be bitter than Python “won” the scripting language war over Ruby, more or less just because someone did a bit of AI work in it first and it took over that space by default.
Ruby has such a nice holistic consistency to it. With a few exceptions, it feels like it was conceived of by one person with a core idea in mind. Python feels like a mess.
by stouset - I made a constant library for python which I liked some years ago. I wonder if any of my ideas made it in:
https://github.com/nucypher/constantSorrow/blob/master/tests...
by jMyles - That’s a fun library :)by JoBrad
- Isn't "..." then also behaving like True, False and None, i.e. being a lexical token that rewolves to a hardwired value during parsing?by xg15
- You wouldn't expect ... = 42 to work syntactically.by b3orn
- rewolves? EDIT: ah, "resolves" typo. was v curious about python's mysterious "wolfing" aspectsby chrisweekly
- It is, but Ellipsis is just an ordinary pre-defined constant (with the same value).by zahlman
- If you count pre-release versions, there are actually 7 pre-declared constants, since Python 3.15 (planned for release in November [0]) adds a new constant "TYPE_CHECKING" that should behave like "Ellipsis" and "NotImplemented" do right now [1].
[0]: https://peps.python.org/pep-0790/#schedule
[1]: https://peps.python.org/pep-0781/#backwards-compatibility