A lot of Python design decisions have felt weird and off to me but they’ve long justified it by saying that it’s those little ugly design choices that make the language so usable and effective in practice compared to more well-designed languages that hardly anybody uses. I’m not enough of an expert to clearly say if that’s really true, but imo, there’s a repeated pattern of slightly weirdly designed languages becoming super popular: Python, Javascript, perhaps C as well. Or, maybe we only notice the weirdness because these languages are used so much and get nitpicked to no end.
It's not the ugly design choices that make it popular. It's just that it was the first that did a decent job of being easy to read/write. Even if you write an objectively better language, you can't replace the ecosystem of libraries, education material and human support that comes with popularity. Popularity begets popularity, and since ease of use is the selling point, it's probably never going to practical to replace it as a general purpose go-to for beginners. And where people begin, they tend to stay. So instead we slowpy march on, bearing the burdens of original sin.
JS is a lot less weird than Python. And Python is what I started with and continue to use half the time. The article missed the most common one, __name__ == "__main__" like wtf
I’m not a regular JS user and haven’t touched the language in a long time, but I remember a (popular?) website for teaching modern JavaScript mentioned that some aspect of the function/macro that returns the type of an object was just plain wrong in a specific and important case. This was years ago however, so maybe the problem isn’t there anymore. Anyhow, I added JS to the list mainly because it is known as a badly designed language and Brendan Eich seems to agree.
There are certainly weird things about it, but they're all things you can ignore especially in modern times, whereas in Python you're constantly dealing with it head-on.
Totally agreed there, Python is my main language nowadays because of work but the inconsistencies and lack of some very easy to add syntactic sugar to cover up some of the ugliness (like your example above) in a backward compatible way is constantly irksome and keeps me from really loving my most used tool.
I'm not sure what world you live in but I remember quite well when prototypical inheritance was The Way in JS to do object-oriented programming. Then they copied the C#/Java syntax for classes. Then they aded a bunch of reactivity with Observable with a ton of quirks.
Every single new, large feature in JS has been full of quirks. The same cannot be said for Python; the exceptions are few and far between and more often than not they're not actually exceptions but rather something bound to core language fundamentals which once understood don't present a challenge because there is an actual underlying consistency.
11 years ago sure. Then the classes they added were syntactical sugar. Observable was never part of JS, it's from the rxjs lib that I avoided cause yeah it's spaghetti.
In about the same timeline, Py went from threading to async-await, which created classic blocking vs nonblocking mismatches. The whole 2 to 3 breaking migration was also still a big deal in 2015.
If you read it you'll realize that, very much like I said, the Python WTFs have to do with mechanisms that not obvious but are consistent. This is far better than Javascript, where the underlying mechanisms may be superficially obvious in some subset of cases, but are not consistent and generate many special cases.
Helped me get a more pragmatic approach to use that chaotic mess of a language and environment. Just use what works, ignore the rest (but I also ignored some specific advice from the book and used what worked for me).
A lot of those are stuff I'd never do like `Test.prototype = null;`. Some are legit footguns, but they rarely get in your way.
Python has weird file imports (no relative ones either), broken package management, historical differences between asyncio and blocking that still cause issues, threading/GIL caveats that trip up even experienced users, indentation for scope (esp weird given it was designed for REPL), weirdly no anonymous functions, 2 vs 3 (mostly gone by now), the __init__ and __init__.py stuff, namedtuple vs dict vs object, `global`, and a whole mess with type-linting if you're going there. You have to deal with all those things every time.
Here's one little Python footgun that everyone hits and is also annoying after:
def func(array=[]): # default value is empty array, right?
array.append("asdf")
print(array)
>>> func()
['asdf']
>>> func()
['asdf', 'asdf']
I don't know why you think it should be so common, because mutating a parameter with a default value doesn't make a lot of sense in the first place. But also it's one of the single most well-documented things about the language, and it's also historically been found useful when invoked intentionally (https://stackoverflow.com/questions/9158294).
Also, we call that a list, not an array.
> no relative ones either
It certainly does have relative imports, and I have no idea what you think is "weird" about the import system.
If you're talking about dynamically importing from a string path, that, too, works just fine with a relative path. It's just that relative paths are relative to CWD rather than the source file, just like any other time you open a file.
If you're annoyed that you don't just specify a file path, keep in mind that a Python module doesn't have to correspond to a file at all. What you ask for in this case is impossible and nonsensical.
> weirdly no anonymous functions
Incorrect. `lambda`.
> differences between asyncio and blocking
This is like saying "differences between cars and traffic jams". It makes no sense whatsoever.
I could go on, but the short version is that you do not know what you are talking about.
List default args are well-documented because everyone runs into it and no other language does it that way. "You can use it to cache values between function calls:" and I really hope nobody does that.
Python has "relative imports" in that you can import relative packages, not files. So the weirdness is, even within my little app, I have to define packages for everything rather than just doing like require("./common.js") like you'd expect in a scripting language. https://stackoverflow.com/questions/714063/importing-modules... . The __init__.py thing is weird in of itself because different Py versions have different rules, and without __init__.py you accidentally make it a namespace package: https://stackoverflow.com/questions/448271/what-is-init-py-f...
> Incorrect. `lambda`.
I meant for general functions, not single-line only. Python code tends to have lots of one-off defs. It's common in other langs to pass around anon functions like outer((var){ ... }). Instead Python covered a subset of those use cases with a whole separate context manager feature (`with`). Why are lambdas single-line only, probably because indents-as-scope would make multiline too weird.
> This is like saying "differences between cars and traffic jams". It makes no sense whatsoever.
I'm sure you've done async coding and run into the classic issue of accidentally doing blocking I/O in code that shouldn't be waiting. For a long time, Python had no such thing, so something like a web backend would use a thread pool which adds a lot of overhead the more IO-bound your handlers are. Then they added asyncio to Python. So now the libraries are mixed on whether or not they do things async. Even psycopg2 needed a whole rework to psycopg3 for this, and it still has caveats https://www.psycopg.org/psycopg3/docs/advanced/async.html#as... . Django has some complexity around async vs non-async too. I don't fault Python for not thinking of this back then, but the end result is confusing.
JS had an event loop from day 1, so it's much safer to assume there that IO is non-blocking. This was part of the motivation for Node.js. There's still code predating async-await, but it's easy to wrap that.
What you put as an example isn't a footgun if you know how the language evaluation rules work. Once you understand that the "footgun" explains a dozen behaviors, which may be a weird behavior but it is consistent.
No, the JS WTFs have to do with language quirks that result in conditionally different behaviors. The Python WTFs have to do with underlying mechanisms that are not conditionally different, but the condition may not be "obvious".
This is so much so that it is described in the Zen of Python: There's preferably One Way to do things, but that one way may not be obvious.
All of these are cause JS builtins like to auto-cast things. + only accepts strings or numbers, - only accepts numbers. Really these should be errors instead, but it's also not very surprising or annoying once you know this. Basically, don't perform arithmetic on things that aren't numbers.
The name parseInt suggests it takes a string. Especially "" - 5, why?
Never knew about this one! Quite funny actually and I'm curious why that happens. I suppose because `0.0000001` is represented as an exponent rather than a decimal? Although I haven't seen `parseInt` used since 2015, you should use `Number`.
> "" + 5 == "5"
> "" - 5 = -5
iirc
`+` operator:
- If LHS is a string, concatenate
- Otherwise, cast to Number and perform arithmetic.
`-` operator:
- Perform arithmetic.
All of these are explainable, and never catch anybody competent out in practice. And, since TypeScript is the norm in a lot of places now, it's never an issue.
parseInt wants a string. If the input isn't a string, it calls toString. 0.0000001.toString() gives "1e-7". parseInt takes the first number it seems in a string, so 1 in this case, or like parseInt("123asdfasdf") gives 123.
What about the fact that there isn't a single 'parseInt' function in JS that can reliably only convert number strings to numbers?
They each have different quirks (some will parse 'a123' as 123, others will handle scientific notation etc). The only reliable way of doing this is doing a regex followed by parseInt... which is definitely a footgun IMO.
Unary "+" returns NaN for strings that don't contain exactly a number (except for empty string which standard type conversion turns into 0). It even works for scientific notation like +'1e3' === 1000.
A lot of them are also about nulls and == vs ===, which are weird, but they're weird in many langs. Like Python has the whole == vs `is`. You just learn the convention and use it. Same with typecasts.
> The article missed the most common one, __name__ == "__main__" like wtf
It makes perfect sense, but also is not an example of what TFA is about. In fact the entire point of having that `if` check is that `__name__` is not a constant.
It’s only weird syntactically. Python tends to lean towards intuitive, natural language by default. I would have assumed they’d have created a syntactically straightforward alternative, like:
__this_file__ == “__launch_file__”
or similar. I understand python values “only one way” of doing things, but it would be helpful for readability.
Again, this is a CS/Math major kind of thinking. The term __main__ means nothing syntactically. If we care about language acquisition -- thus language adoption -- it is always better to make "very common terms" in the language understandable to someone who is completely illiterate to your formal language.
I honestly think one of the main reasons why python is so successful is as simple as:
print "Hello world!"
...and later:
print("Hello world!")
It might not seem like much, but when you're asking someone to pick up a language outside of a classroom setting, it's just much more intuitive than:
echo "Hello world!";
or:
console.log("Hello world!");
or god forbid:
public class GFG{
public static void main(String[] args) {
System.out.println("Hello world!");
}
}
These little things matter in the long run, even if they don't seem like they matter when you're already fluent.
Idk what's better, console.log or print, cause way back as a beginner I was confused what it means to print something. Like with ink? They're both ok, unlike the C++ or Java ways.
But Python breaking hello world in version 3 was crazy.
It would be nice if, just once, we could have a thread about interesting esoteric Python behaviours without people taking it as an invitation to dump their laundry list of things they personally don't (or do, for that matter) like about Python, or to make inane comparisons to other languages (especially JavaScript, for very unclear reasons) while being simply uninformed.
The __debug__ constant is really weird - any block of code guarded with `if __debug__:` will be entirely omitted from the bytecode under PYTHONOPTIMIZE=1. This and `assert` are the only two examples of real “conditional compilation” in Python. This is also the reason why you cannot assign to __debug__: doing so would make it possible to invalidate the compiler’s assumption about `if __debug__:` statements.
I honestly have never even heard of this constant and I feel like I've been using python for a pretty long time. Although maybe my memory for some things just gets garbage collected if I don't use it enough. Does it actually get used that often in real world code? Seems like it might be kind of risky.
Because Python lets you get as far as it does without formally learning everything, but is also expected to suit a huge variety of use cases, it ends up with lots of hidden details that are irrelevant to most users.
The most direct way to find out about `__debug__` is to read `python -h` (or the usage message, which is not all that easy to trigger) in full, and then head over to the documentation.
> Does it actually get used that often in real world code?
I feel like it's the kind of thing you might wind up caring about if you're micro-optimizing your python, but in my experience that's a losing game and you're better served rewriting it in another language than bothering with trying to speed up the execution of the raw python code (it's not that you can't optimize python code, but only in broader strokes. If you are looking at the bytecode you're in too deep and every time I've seen it tried the code has been ported shortly afterwards).
Ditto. I’ve certainly never used it and can’t recall seeing it in any codebases I’ve worked on or looked at. Sounds interesting though!
I’ve of course certainly heard of, seen, and used `assert`, but more often than not, outside of pytest, I see its use way more in potential footgun scenarios—I doubt that many people know that assertions can be silenced, and that they’d probably be better off raising exceptions in many cases where they’re using `assert`.
I made a CTF problem where `assert` was used as a critical safety check - and where "accidentally" running the program under -O (for speed!) resulted in a security vulnerability. A large fraction of the people who attempted the problem seemingly missed this bug.
I would not be surprised in the least if that pattern existed in the wild. In fact, it's quite common to see this in C/C++ codebases too: people will use assert() to check a security-relevant property, and then disable those checks in their release builds "because it can't happen".
I see asserts used in production code as part of flow control way too frequently, so I assume the majority of python users aren't aware of the -O flag, much less this behavior- which I too haven't ever heard of.
Of recently, I've noticed claude is a big fan of asserts too.
If 0. Etc. are also compiled out, at compile time __debug__ is simply False or True and the existing optimization paths take care of it.
Assigning to __debug__ wouldn't do anything to the compiler as it never actually reads the variable, so assignment would just cause weirdness from other use
Misery is trying to retrofit "bool", True/False, and nil/null to a language. C had to do that. Python had to do that. Getting those wrong is one of the classic language design mistakes. It seems like treating "True" as a value that equates to 1 will work, but then the special cases get you. Like being able to perform arithmetic on True.
Common language design boners:
- Not building in strings. That's now in the past. Everybody has strings. (Well, C...)
- Not building in multidimensional arrays of the numeric types. Everything that number-crunches needs them, and having multiple definitions is Not Fun and may lead to expensive re-copying between different libraries.
This is an enormous blind spot in language design. It's one of the reasons FORTRAN, which has good multidimensional numeric arrays, is still often used for number-crunching.
- Not standardizing the small vectors (vec2, vec3, vec4) and their matrix friends. Graphics code depends on these, and it's really annoying if there are multiple slightly incompatible implementations. Especially since GPUs have hardware for those types, and you want CPU and GPU to use the same representations.
- Not having arrays of bits. Pascal had PACKED ARRAY[0..N] of BOOLEAN but that was lost in later languages. It's useful to have that as a language construct, because most modern CPUs have good hardware for dealing with bit strings, and you'd like the compiler to use it.
Most useful languages acquire these features, but, when they come in late, there are multiple similar implementations, and libraries made incompatible by depending on different implementations.
(Amusingly, when Second Life switched from Linden Scripting Language to Luau, they initially had True, TRUE, and true all in use, as different types with different semantics. I was able to persuade the devs to unify the boolean types.)
You list a few absences but absences aren't the end of the world, I say it's worse when designers make a booboo where the language semantics are wrong. In C++ there are so many of these it's not sporting but a recurring example from the garbage collected languages would be the for-each loop mistake.
Several times now†, people make a language where the way a for-each loop (for each Goose in Geese ...) works is that there's a single variable Goose and each time around the loop we change which value is referred to by the Goose variable. This seems intuitively like a reasonable way to do this. But it's wrong and eventually your programmers will get nasty surprises. What you actually should deliver is an implementation where each time around the loop there's a new variable named Goose, that variable goes away at the end of that iteration and will be replaced by the next one, with the same exact name.
> What you actually should deliver is an implementation where each time around the loop there's a new variable named Goose, that variable goes away at the end of that iteration and will be replaced by the next one, with the same exact name.
Is this because a closure inside a loop will capture a reference to `Goose`?
I think that this is a capture problem not a variable problem. The closure should always do the right thing and capture the value of all variables (not just ones inside the loop), instead of capturing the reference to the variables.
Then the general problem is fixed to match what developers expect, instead of a specific instance of that class of problems being fixed and working differently to how other captured variables work.
The interior of a for-loop is only a scope, not a closure. In most non-dynamic languages you can't package up the state and hold onto it beyond the life of the loop, which is what closures are for.
Most trouble in this area came from the iteration variable outliving the loop. That's not good when the iteration variable is a pointer. In C, it often is, and at the end of the loop, it points to an invalid address. It was a change to C (when?) to make the iteration variable go out of scope before code after the loop could get at it.
> I think that this is a capture problem not a variable problem. The closure should always do the right thing and capture the value of all variables (not just ones inside the loop), instead of capturing the reference to the variables.
Now your "lalanthran closures" can't mutate the world because they work exclusively with copies not references, if they try to mutate something then whatever they're touching was just a copy not the real thing.
> Now your "lalanthran closures" can't mutate the world because they work exclusively with copies not references, if they try to mutate something then whatever they're touching was just a copy not the real thing.
That is true. I still don't like the idea of "Here is a general rule. It applies everywhere but $HERE." Whether that general rule is "All captures are by value" or "All captures are by reference", the rule should not have exceptions based on context in the code.
A better tradeoff would be to have the general rule (whatever it is) apply everywhere, along with syntax for capturing (or not, depending what the default is). I'd rather have it grab everything by value, and for those things that are susceptible to race conditions (because more than one closure is modifying it), explicitly annotate it with a sigil (`&`, or a keyword, or similar).
I mean, in pseudocode, when I see:
... variables x, y and z are declared and used in this scope ...
return (x, y, x) => { ... }
I don't want to have to examine the surrounding scope to know whether or not `y` is susceptible to a race. I'd rather just see:
... variables x, y and z are declared and used in this scope ...
return (x, &y, x) => { ... }
An alternative viewpoint is that many languages have immutable variables and they seem to be getting along just fine without needing mutation on variables, shared or otherwise.
> the rule should not have exceptions based on context in the code.
But the rules didn't and still don't have any such exceptions.
> A better tradeoff would be to have the general rule (whatever it is) apply everywhere, along with syntax for capturing (or not, depending what the default is)
This "solution" is how it works in C++. We can thus castigate the programmer for writing the wrong runes in their captures list and never for a moment doubt that we got it right when we introduced so very many footguns...
Tony Hoare's observation applies "One way is to make the program so simple, there are obviously no errors. The other is to make it so complicated, there are no obvious errors."
> An alternative viewpoint is that many languages have immutable variables and they seem to be getting along just fine without needing mutation on variables, shared or otherwise.
Sure, and one of the astonishing things in C# or Go before they fixed this is that you can indeed have immutable variables which change, even though that's silly - the language can decide that you mustn't change Goose, but it doesn't need to obey its own rules because it will change it for each loop iteration.
> Not having arrays of bits. Pascal had PACKED ARRAY[0..N] of BOOLEAN but that was lost in later languages. It's useful to have that as a language construct, because most modern CPUs have good hardware for dealing with bit strings, and you'd like the compiler to use it.
I'm not sure exactly which features are responsible (I'm inclined to blame templates), but C++'s std::vector<bool> is a rough edge. For those unfamiliar, the standard specifies this vector template in a way that's not compatible with other vectors.
They should have made `std::bitset<std::dynamic_extent>` what todays `std::vector<bool>` is (actually maybe not, `std::bitset` is fixed sized, just compile time fixed size). While at it also make `std::array<std::dynamic_extent>` a runtime fixed size array.
Vectors & multidimesional arrays are something I'm 100% adding to my language's core.
It kind of started with vectors as the very first feature (I was sick & tired of libraries reinventing their own `Point`/`VectorN` in incompatible ways).
Oh wow, I had no idea that SL did another language change after migrating LSL to Mono. Surprising considering that happened late '00s/early '10s?
I'd consider LSL to have been foundational in my ultimate interest/career in software engineering. The strict typing, very usable compile/runtime errors, and good documentation/examples made it so easy to pick up as a teen. Not to mention as long as you didn't edit/save a script again it would always run the same regardless of updates.
Strings are a really weird data type. I'm not sure you can do much better than C strings without implicitly requiring dynamic memory allocation, which C deliberately does not do.
Definitely agree on multidimensional arrays. I feel like efficient arrays in general are underrated in high-level language design.
> Strings are a really weird data type. I'm not sure you can do much better than C strings without implicitly requiring dynamic memory allocation, which C deliberately does not do.
The thing you want is what Rust delivers in the box, &str a string slice reference type, in Rust's case the "string" is UTF-8 encoded text. On the bare metal the way to represent this type is as a "fat pointer" typically a pair of registers, one with the address of the first byte of the string and the other with a length.
C should have fat pointers, they were proposed, for IIRC C89 but the proposal was rejected. That's pretty sad, the fat pointer is expensive to the point of maybe feeling extravagant on a PDP-11, but by 1989 that's long gone.
More ridiculously C++ didn't get this type (which it eventually called std::string_view and provides in its standard library not as a built-in) until 2017, years after Rust 1.0 shipped. In the meanwhile C++ just did not have a sensible way to do this, strings are hard apparently.
The string buffer feature, allowing you to actually make strings is less important, as you say it will need an allocator and so on very bare metal you might not have this - but the string slice reference doesn't need an allocator.
I think it's worth delivering the basic "it's a growable array type, duh" implemenation of the string buffer type, which is what Rust's String type is, but C++ chooses to ship an oddly specific small-string optimized version as std::string right from the offset.
Yes I remember a friend doing university marking for a beginners programming course years ago and some student had managed to swap True and False making their assignment very wonky.
Hmm. Having read your post, surely the bug is having a function where
set(foo, false)
removes foo entirely. What if you want foo to have the value False? Even besides the unintended behaviour where 0 is coerced to a boolean value, this function seems poorly designed.
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].
Python has some absolutely kick-ass libraries, even without C. It has Django, for those of us who like developing web apps but never could fall in love with Ruby on Rails. And Django is amazing. I've also yet to see a better language for writing quick ETL scripts and pipelines. Also, an 'I need a script for $SYSADMIN_TASK but I want to be able to read it later.' Anything dominated by external latencies (web, databases, etc) will be fast enough for many uses in Python.
Sure, it's not a language to write a web browser or game engine in. And it is slow. But it has some very strong niches outside of ML/Data science. Personally, I love it. To each their own.
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/scratchpad
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.
Ruby is beautiful in its design, but it made imports and namespaces (a.k.a. modules) separate concepts. This is so flexible it became hard to ever find anything easily in practice.
Likewise, it made classes incredibly easy to extend, which led to a monkey patching bonanza and far too much magic everywhere (Rails being by far the worst offender but not the only one). It meant having to keep too much stuff in your head and needing deep framework/library familiarity just to be able to understand basic code.
In the end, I feel like the incredible flexibility was Ruby's undoing, not just lack of library availability for a specific popular application. I was a Ruby zealot at one point but it began to lose its lustre not because it wasn't beautiful in theory, but because it was inconvenient in practice. In some ways, Python's restrictiveness became its greatest attribute. Then Python 3 helped to fix a lot of the inconsistency.
Both Python and Ruby have a consistent logic to them, just not consistent with each other. Just as all attributes are methods in Ruby, so all methods area attributes in Python, etc. Things get much easier in either language if you stop fighting their internal logic.
Long before AI work, numerical data crunching is what Python became popular for among non-computer scientists and this led directly to the AI use cases. The reason was obviously the lower barrier to entry without having a software engineering background. I also share with you that feeling about Ruby in particular.
> 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.
This is just my personal opinion with no data to back it up, but I suspect that Python "won" because it has excellent Windows support, while Ruby doesn't. Even a decade ago, Python's website offered an official native Windows installer [0], while Ruby's website [1] still points you to a third-party installer, which doesn't even have native support since it uses MSYS2 [2].
Most non-developers use Windows, so if you're choosing the first language to teach a large group of people, good Windows support is fairly important. Python being the "default" introductory language gave it a huge number of users, then I suspect that everything flowed down from there.
This could be it. The classic student with a Windows laptop and git-bash installed, where they think git and bash are the same thing, also PuTTY.
I also wonder how many people gave up on Python just because the installer doesn't put it in your PATH. You'd install Python then no python, wtf. Ok so https://discuss.python.org/t/python-command-not-found/22255 ... Then you fix it and it runs the wrong version of Python.
> but I suspect that Python "won" because it has excellent Windows support, while Ruby doesn't. Even a decade ago, Python's website offered an official native Windows installer
I think you might be able to go an additional decade backwards. Back in college most of my friends were on windows and one of them was using python for class projects.
Python's strength is that it's easy to make C libs work in it. That's also why CPython is de facto the only Python implementation and stuff like PyPy never took off.
Yeah and I would say that another important factor is Cython, which compiles Python with minimal modifications to C extensions that can in turn be imported in Python. It really makes it easy to get started in Python and worry about performance of the computation later. (Doesn’t help with concurrency I know but that’s a different story.)
The point of SWIG is it works across many langs, but this comes at a cost. The SWIG .i and autogen'd C wrapper are extra layers that can get annoying, particularly during debug. Always hated dealing with SWIG'd libs at work. And Python C modules give easier control over Python specifics.
I like Python but this was always actually one of my pain points. The CPython C API is full of foot guns, the API surface is expansive, and writing against it requires a lot of careful care. Anyone who's ever written C modules for both languages would be able to attest how much more pleasant the experience was for Ruby than Python.
Did you mean to say that Ruby doesn't link name spaces to file system paths? Ruby has namespaces and they're far more flexible than Python's... too flexible in my opinion, making it harder to find things.
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.
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.
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.
>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.
This is exactly what I remember being said about C (which I agree with) and often given as a reason why higher level languages like Python or Java have so many protections against things C/C++ allowed (memory management being the biggest one of course). Very funny, and I assume not coincidental, to read this about Python in the modern programming landscape.
Well, there are plenty of safety mechanisms that Python doesn't have and dangerous (usually powerful, occasionally badly designed) mechanisms that it does have.
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.
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.
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.
Relatively new, scripts can define dependency metadata now adays to achieve that to some degree. Any pip style versioning including an exact match works there.
The imports/packages situation is terrible in general. This was basically broken until uv, and uv is still not the default.
And it's weird how you import files. They're dot-separated packages that resemble file structure but not exactly. NodeJS has a self-explanatory require("./foo.js") or "../foo.js". The newer JS `import` syntax is annoyingly different from `require` but not terrible.
I've never become a fan of the language syntax, but otherwise I've become quite smitten with the total Python ecosystem. The Agents/LLMs + uv combo have made Python so useful and productive for me.
My CLI tools publish from Github to PyPI so that I can run tools with just `uvx sql-agent-cli` or `uvx dlna-here. Nothing for me to handle downloading (directly myself), no environment to manually setup, portable (Linux, Windows, Mac, ARM, x86). Easy for agents to run from a skill.md file without any other prereq than uv.
Really useful library ecosystem to leverage. No more shell scripts, or TS/JS/PHP backend services. I've even used Python on devices I've built around Raspberry Pi Zero 2 boards.
> I often work with data scientists and have to productionize their jupyter notebooks
I'm not a huge Python fan, despite working with it fulltime, but this feels like mixing correlation and causation. Data scientists would not be writing good, optimized code in any language.
Why wouldn't we? It's still a very relevant distinction, even if the terminology is a bit weird (since scripting is by definition programming). A programmer has very different needs when he writes a script to automate some server tasks versus a complex piece of software. It makes perfect sense that different tools will be more or less effective at meeting those different needs.
There is no reason why automating a server task cannot be a complex piece of software. I think you’re not aware of just what server automation is used for nowadays in countless cases. Also, Python is more popularly used in ML and web-development areas compared to server automation, so that would mean it’s not a scripting language by your logic.
Spoken like someone who hasn't tried to get data scientists to use other languages productively, where they'll be missing half the libraries, will have to triple their dependency count because you can't count on large common libraries and will have to dig to the ends of GitHub to find random functionality etc.
Python is amazing compared to writing bat/sh scripts. Different languages are for different purposes, using eg. Rust to write system scripts would just be mental. Whether people abuse those languages for purposes they were not intended for is another story, but that doesn't mean the language is inherently bad. And I mean,
> and it’s way too easy to do the wrong thing
is there another programming language where you believe a data scientist is going to have an easier time writing correct code than Python? Do you think C or Rust or JavaScript or C# make it harder to do the wrong thing?
C'mon man, I don't know any mid and above python developer who seriously has ever considered programming in Jupiter Notebooks. Python is not slow, it's you being the issue. If you are an amateur then it's easy to do the wrong thing, that's true.
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.
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).
What is the best language for controls and embedded, in your opinion? I assume from your comment that it's not a great choice as a first language to teach newbies, but I've never done anything in the field of robotics or embedded stuff, so I'm quite ignorant in that area.
If I'm not allowed to toot my own horn, I think for controls, you probably should not start with choosing a programming language, the first step is learning control theory and automata theory, you kinda have to understand feedback control/PID/steady state/jitter/hysteresis and the like. Python has never had great control libraries to begin with as far as I can remember (my info could be a bit outdated though), so the paid option is still Matlab/Simulink as it is their last niche really.
Embedded firmware, probably C/C++/Rust. Not the answer you want to hear, but these are the languages for bare metal applications. Of course, if you are just using an Arduino/Pi, just use their SDK for their hardware on whichever language they support.
Those two fields are just not very friendly towards beginners in general.
Sure, short list:
- Easier to write than Python other than the simplest script, almost no way to write bad code and have it compile, reads like pseudocode most of the time
- Compiles into Go binary, runs at Go speed, compiles at Go speed
- Trivial to wrap any Go library via LLMs, so any Go library is also an Oct library.
- Can metaprogram existing Go codebases, so it doesn't really replace Go, just supplements it
- Easy concurrency/parallelism
- SI units as types
- Can be used as build script for C/C++ in place of CMake
- Einstein tensor notation
- Builtin GPU acceleration via Vulkan
It was designed as a teaching language for academics to stop writing bad code, but now I just get LLMs to do research/science for me with it for fun.
Yeah! Like when helping teens set up PID controllers for their CAN-bussed robot, it was very much a "we've got a lot of example working Java code with a PID Controller library already. So we're using that." The language itself is so inconsequential at the early stage, that you really just pick whatever gets in your way the least.
None of them. Walks away. Stops. Turns. All of them.
It depends. If you're a teen I'm mentoring, you're probably starting with some Scratch to drive Lego robots around. Then on to Python to drive the same robots around but now with more fun!. Probably because you absolutely couldn't stand the standard line follower solution of jittering back and forth and you sniffed out the existence of better control loops you cannot realize in Scratch. If you're on the FIRST Robotics team you're probably doing Java or Python, mainly because that's just what we've geared up for (and this is really the core theme for me at least: at introductory levels, what really matters most is whatever is most readily accessible to you and whatever kit you already have).
If you're doing your own stuff and you're a newbie with absolutely no opinions on where you started or what you were trying to do, you'd probably start poking around with an Arduino or similar, so you could write MicroPython (it's Python but you squint your eyes a bit!) or C. There's so many great kits for beginners.
In the context of my comment: what I meant is that you wouldn't decide, "the professionals do it in C++, C, or Rust, so we'll start with one of those." I'm going to give you a recorder (Python) before I hand you bagpipes (C++).
If I'm teaching you programming and you've learned Scratch, I'm going to hand you Snap! (https://snap.berkeley.edu/) next. Because it's Scratch, but with the artificial limiters removed. Snap! (the exclamation mark is part of the name) allows you to store lists in variables and pass them as inputs to functions, and it has the standard list-handling functions you'd expect, like filter and map. Moreover, it also allows you to store blocks (functions, basically) in data structures and pass them as inputs to other blocks, so you can actually learn to write code in functional-programming style.
Once you learn that Brian Harvey, one of the two main designers of Snap!, was one of the principle people behind Berkeley Logo (which itself was a variant of Lisp, though that wasn't clear to me when I was learning Logo at age eight), it all starts to become clear. Snap! is itself nearly a Lisp, just lacking macros (and Brian Harvey is trying to figure out how to add a macro system to Snap!, with the primary challenge being making it comprehensible in graphical-blocks form).
We’re spoiled with great options. My kid jumped right from Scratch to JavaScript for game dev because he loves how he can put his games on the Web easily. Huge props to Microsoft Make Code Arcade for allowing you to port your Scratch to JS. It gave him a powerful way to see what he knows and how it looks like in JS.
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.
Well, many times in my field of mechanical engineering, they have to, because CFD and FEA are very performance sensitive. The professors I had were still writing FORTRAN and C++ before, but maybe they've switched to Rust now.
> 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.
> 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.
scala's repl is decent. It has its annoyances, but so does python's (white space sensitivity + repl + terminal emulators stuck in the late mid century don't mix).
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.
Haskell, Lean, and Agda too. But even if Python were the only one, it wouldn't be weird to someone for whom this was their first programming language. It would just seem the way programming languages are. There's nothing intrinsically weird about indentation being significant. It's quite visibly part of the code you write and read.
> There's nothing intrinsically weird about indentation being significant. It's quite visibly part of the code you write and read.
The idea is fine, I guess, although I certainly don't care for it. Where it gets most nasty is that whitespace that looks the same (in your editor) might not be equal and will cause you pain.
> Where it gets most nasty is that whitespace that looks the same (in your editor) might not be equal and will cause you pain.
First off, what editor could I end up using in 2026 that makes this a realistic problem? Even the most basic editors I know of have options to convert tabs to spaces automatically (and any responsible teacher will tell the student to indent with spaces), and to continue the previous line's indentation automatically.
Second, modern Python is stricter about this, and also gives clear error messages.
> 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.
It also helps prevent people from ever redefining them. I mean, if you try to redefine False (in a version of Python that allows it) then you deserve everything that's about to happen to your code... but at the same time, it could possibly lead to a security attack. Redefine False then import some module and get unexpected behavior that you can manipulate to your advantage, somehow. I don't know how that would work, it probably wouldn't... but there's also no reason not to lock those names in and prevent them from ever being redefined.
I don't. I have no interest in trying to assign a value to something that's built-in and not meant to be written to. Like who fucking cares that the boolean constants are actually weird little structure that sometimes let you mess with them and other times your edits are ignored? Maybe this is helpful for writing an entry for an obfuscated code challenge but I'm not doing weird shit like that with the code I expect to work between various Python versions and implementations, especially when I'm getting paid to do it.
Please. Such a charged response wasn’t justified at all. Different people are curious about different things. You ask “who fucking cares?”. The answer? You don’t, and the person you’re replying to does.
Yeah it was a blast to make. If memory serves, a significant piece was over a very lovely and piney joint with Kieran Prasch at an airbnb in... Seattle?
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.
I keep on hearing people be excited about PHP. Having first attempted to use PHP in early 00s, I simply cannot bring myself to attempt it again. I once had to rewrite large chunks of a site because it simply couldn't deal with the fact that a string had an apostrophe in it.
I can only recommend to check out a popular project, maybe Laravel, and read it’s documentation. Alternatively, look at the PHP website itself. The new syntax improvements alone are pretty convincing IMHO, but the engine also got a JIT compiler, a runtime type system that’s fully opt-in, fibers for concurrency, and much more.
PHP has evolved a lot, but it also still has a lot of cruft from its earlier days. And it has made breaking changes on a scale python probably couldn't get away with.
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.
Perl is a lot like that also, you can read about some really weird old features like $[ but you never see that in practice, you just write code with variables and functions and so on.
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.
Comparing it with PHP is unfair… to PHP. The amount of hard work that the PHP community has done to advance and keep their language relevant is impressive and admirable, and Python is perhaps the most extreme counterexample there is.
The Python community has spent the last 15 years refusing to improve in any meaningful way, or to learn anything from their peers. As someone who used to choose only jobs that would let me work with Python, I’ve gone through every phase of grief, and now just try to forget that it exists.
Lol, Python has had incredible improvements over the last decade plus, while uv fixed packaging. It's the best/comprehensive glue language ever made, even with a few remaining warts.
Most of the time downvoters don't explain their downvote, but I'll explain mine. I voted this comment down because it's just plain incorrect.I worked with PHP for nearly ten years (and I never want to go back). Maybe PHP has improved since I worked with it (PHP 7.4 was the most recent version when I last worked with it, I have never used PHP 8), but I doubt it.
But to describe the Python community as "spen[ding] the last 15 years refusing to improve in any meaningful way" is just laughably wrong. I can't give details as I haven't been doing much Python work, but even so I know of multiple changes, such as the typing system, or packaging improvements, which have significantly improved the language AFAICT. If there's a reason why you would not consider those to be "improv[ing] in any meaningful way", please enlighten me.
You mentioned two biggies, but also the GIL removal, async, performance improvements, f-string, walrus, fast dicts w. merge ops, data classes, pattern matching, friendlier repl, and hundreds of smaller yearly improvements.
Pattern matching? Nice, I'd managed to miss that one completely, as well as the fact that Python had introduced dictionary-merging (according to a quick search, Python 3.9 introduced the | (pipe) operator for dict unions). I did know about the others you mentioned, but couldn't call them to mind when writing my comment.
But reading through a Python script that I had Claude Code write for me taught me another one: apparently there's now a / operator on strings, because Claude wrote `path = "some" / "dir" / "filename.txt"` without importing anything outside of the stdlib. I presume it is shorthand for calling os.path.join and will therefore apply the correct path separator on Linux vs Windows.
You are both focusing on Python improving in any way but the person you're responding to said "improve in any meaningful way, or to learn anything from their peers"
Which I will say is overstated but I can see where they are coming from even when you bring into scope things like types, async, etc.
First types. This is what the type hints in Python allow you to do:
def foo(x: int) -> int:
return x
foo("hello")
We can say that this is great Python has type hints, but at the same time the lesson they learned is wrong because the feature to have isn't type hints but actually enforcing them so the above code cannot be written. In my eye, this is an anti-feature.
Second async, this is also the wrong lesson to have learned from other languages. Adding async/await is a bandaid over the problem that the synchronous imperative model clashes with asynchronous distributed semantics. The async/await keyword are a way to try to bridge between the two, but it creates a "function coloring" problem that all these languages which added async/await have.
The lesson Python should have learned is to not add these keywords and go back to its glue language root, allowing actually natively asynchronous languages to coordinate asynchronous processes, while Python code handles the synchronous core. Python doesn't have to be everything, the wrong lesson was to try to be the one language to rule them all.
You also brought up the packaging improvements, which I feel were the wrong lesson learned. The problem with the Python packaging ecosystem is well known since it's been expressed in the XKCD comic. The lesson from other languages is: one blessed compiler toolchain integrated into the packaging story makes for a better user experience. This is the npm, cargo lesson. For Python to really learn it, uv or equivalent would be the blessed way of managing Python projects. Instead it's still a very fragmented landscape with many competing solutions, which goes against Python's own zen.
Moving on to pattern matching, again I feel the wrong lesson was learned. Pattern matching is a feature from the functional paradigm that in my opinion became more popular with developers when they became exposed to it in Rust, and so Python joined in and added the feature as well. But the reason it's such a nice feature in Rust is because it will refuse to compile any code that does not do exhaustive matching on all variants. This is great because it catches problems early and forces you to consider the non happy path where things can error. So pattern matching alone isn't the feature it's pattern matching PLUS structured Enums and exhaustive patterns.
So in Python you can do this:
x = 3
match x:
case 1:
print("one")
case 2:
print("two")
print("done")
Output will be "done" rather than an error on the match, which is what should happen if they had learned the right lesson, because without exhaustive matching this is no better than an if or switch. Again I consider this an anti-feature -- better to not have at all if it doesn't work as expected.
Anyway, I'm not trying to say Python is bad, I'm just saying I get where the other poster is coming from when they say Python has refused to learn the right lessons. Although I would not agree they haven't improved a lot over 15 years.
Not every improvement is perfect, that’s true. I in particular fought against walrus syntax and don’t use pattern matching for other reasons. Python is also boxed in by its history. Some of the things you want done are incongruent with its design.
Many people like them however. And you’re being way too charitable to that dumbass comment.
I guess what I’m trying to do is draw a distinction between “improvement” and “change”. We can agree to disagree but my view is the things I called anti-features are not improvements at all, but rather loaded footguns. Python would be more coherent language without async/unenforced type hints/non exhaustive pattern matching. Like you say, it’s constrained by its history and I feel a lot of the recent changes are to make Python more palatable to the devs who are using it for AI and ML rather than keeping it true to to its nature.
Type hints are very helpful on big projects. And are enforced by other tools. Honestly, this kind of criticism shows a lack of experience, and denial of reality for an almost 40 year old language.
It sounds like scoffing at a Silver medalist to me.
In fact, Python is better at what it does than almost anything from the era. That’s why we use it. Nothing is ever going to be perfect because better solutions are emergent, and reverse time travel does not exist.
> Honestly, this kind of criticism shows a lack of experience, and denial of reality for an almost 40 year old language.
Okay that's where you lost me. You can talk about the language from your perspective, and like I said we can agree to disagree, but it crosses a line when you want to comment on others' experience and put them down just because they disagree with you. No on is scoffing here, what I wrote was a considered criticism. Have a nice day.
It’s about as near a well-documented fact as there is in this industry, and not intended to be an insult. Sometimes we need a wake-up call, and yes they’re not usually enjoyable. I know as well as anyone else, having received my share over the years.
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.
I can understand that "advanced" python programs may be difficult to understand for beginners (lots of implicit/hidden behaviors, possibility to change basically everything one should expect, etc).
But to _learn_ programming, I really, really don't see how using Haskell would be simpler than Python. Perhaps if you have a specific background (e.g., math), but else python is almost pseudo code already. You'll really have to convince me that a more abstract language is better...
Haskell’s hard to interpret error messages alone disqualify it from being a beginner language.
Python: errors based on incorrect indentation (many beginners don’t use nice IDEs), or don’t understand the meaning of the hints) and scope (don’t forget your “global” if you’re hacking in PyGame) are challenges.
Starting with 3.13, even the REPL is a sufficiently nice IDE to avoid any careless indentation errors from poor formatting (as opposed to ones caused by actually not understanding how many levels of indentation the current line of code should have).
> Racket / Scheme / I dare say even Haskell would just be so much simpler for learners.
I have used all three languages; and you clearly have no idea of the notion of usability of a language. So many things contradict this, let me list them off the top of my head
- Getting a running toolchain working: Prexisting (most OSes bundle a Python interpreter) or a package install away for Python. Scheme / Racket is some odd mix of custom IDEs with Dr. in the name, or someone's 20 page essay on how SLIME is the best thing ever. Haskell gets into odd stuff with ghci, cabal, and stack, and all of them are extremely slow.
- Tutorials: Python has a ton of them, they all get you printing to stdout and calculating things in about 10 minutes. Scheme / Racket typically spends multiple chapters navel-gazing about lists, cons, and such. Haskell is actually better in terms of the Hello World stuff, but ghci v/s ghc bites you again; and no one has a clear idea of which one to use.
- Advanced concepts: Python has mainstream but halfhearted OOP; and things like decorators and metaprogramming. Quickly intelligible if you learned something else like Java or C++. Or if you learned shell scripts you can get quite a bit done with just imperative. Racket/Scheme: 3 chapters in and you're still trying to figure out tail recursion. Haskell: Instead of just doing fun things with take and foldl you're being hit with trivia about typeclasses.
> Haskell: that was funny but an absurd criticism ghc vs ghci?? Nobody has that problem.
Back when I was a beginner actually interested in getting out of the beginner step of Haskell, this was an issue for me times. So there's at least one person :)
Also anecdotally I have seen people ask this in Freenode #haskell as well (the “Freenode” probably tells you how long ago this was) ; and there a few issues [1] and [2] where I see beginners having the same/similar issue. The second one is particularly funny, 4 people give 5 solutions and no one seems to know what the actual fix is. Instead you have people arguing whether a repeated do works or not. This would never happen with Python, just saying :)
> Racket: criticizing for having a beginner-friendly IDE doesn’t make a lot of sense.
Sorry, perhaps too harsh but I don't think it's as beginner-friendly as you think. I think it would probably help if they made the design more modern and welcoming. All these details about you can rewrite entire languages in Lisp and we can't even at least get a GUI that looks like it was written after 2007?
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.
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.
Don't mind the web designers calling themselves engineers.
There's a lot of annoying issues with Python, but compared to the billions of dollars and thousands of man hours that has been spent trying to fix Javascript and how horrible it still is, it's a perfectly cromulent language.
you could shadow True for twenty years and Python just shrugged, then one day it's a SyntaxError and every tutorial you ever wrote breaks. peak Python, honestly.
A lot of Python design decisions have felt weird and off to me but they’ve long justified it by saying that it’s those little ugly design choices that make the language so usable and effective in practice compared to more well-designed languages that hardly anybody uses. I’m not enough of an expert to clearly say if that’s really true, but imo, there’s a repeated pattern of slightly weirdly designed languages becoming super popular: Python, Javascript, perhaps C as well. Or, maybe we only notice the weirdness because these languages are used so much and get nitpicked to no end.
It's not the ugly design choices that make it popular. It's just that it was the first that did a decent job of being easy to read/write. Even if you write an objectively better language, you can't replace the ecosystem of libraries, education material and human support that comes with popularity. Popularity begets popularity, and since ease of use is the selling point, it's probably never going to practical to replace it as a general purpose go-to for beginners. And where people begin, they tend to stay. So instead we slowpy march on, bearing the burdens of original sin.
Yes. These are funny little quirks, but nobody will ever get tripped up by them.
JS is a lot less weird than Python. And Python is what I started with and continue to use half the time. The article missed the most common one, __name__ == "__main__" like wtf
I’m not a regular JS user and haven’t touched the language in a long time, but I remember a (popular?) website for teaching modern JavaScript mentioned that some aspect of the function/macro that returns the type of an object was just plain wrong in a specific and important case. This was years ago however, so maybe the problem isn’t there anymore. Anyhow, I added JS to the list mainly because it is known as a badly designed language and Brendan Eich seems to agree.
There are certainly weird things about it, but they're all things you can ignore especially in modern times, whereas in Python you're constantly dealing with it head-on.
JavaScript still has many quirks you can’t just ignore, such as sort() using string comparison by default.
That one does suck. I'd get it if < > did the same thing, but it doesn't.
Totally agreed there, Python is my main language nowadays because of work but the inconsistencies and lack of some very easy to add syntactic sugar to cover up some of the ugliness (like your example above) in a backward compatible way is constantly irksome and keeps me from really loving my most used tool.
I'm not sure what world you live in but I remember quite well when prototypical inheritance was The Way in JS to do object-oriented programming. Then they copied the C#/Java syntax for classes. Then they aded a bunch of reactivity with Observable with a ton of quirks.
Every single new, large feature in JS has been full of quirks. The same cannot be said for Python; the exceptions are few and far between and more often than not they're not actually exceptions but rather something bound to core language fundamentals which once understood don't present a challenge because there is an actual underlying consistency.
11 years ago sure. Then the classes they added were syntactical sugar. Observable was never part of JS, it's from the rxjs lib that I avoided cause yeah it's spaghetti.
In about the same timeline, Py went from threading to async-await, which created classic blocking vs nonblocking mismatches. The whole 2 to 3 breaking migration was also still a big deal in 2015.
You've probably just gotten used to it so you don't notice it anymore: https://github.com/satwikkansal/wtfpython
(Note some of these are outdated, but some of those only mention that towards the end of the section rather than the beginning)
If you read it you'll realize that, very much like I said, the Python WTFs have to do with mechanisms that not obvious but are consistent. This is far better than Javascript, where the underlying mechanisms may be superficially obvious in some subset of cases, but are not consistent and generate many special cases.
The Python wtfs are definitely more consistent than the JS wtfs.
Ah yes, nowdays it is even easier, but "Javascript, the good parts" came out 18 years ago already.
https://www.oreilly.com/library/view/javascript-the-good/978...
Helped me get a more pragmatic approach to use that chaotic mess of a language and environment. Just use what works, ignore the rest (but I also ignored some specific advice from the book and used what worked for me).
> JS is a lot less weird than Python.
I challenge you to find Python behaviors as weird and off-putting as anything here: https://wtfjs.com/
A lot of those are stuff I'd never do like `Test.prototype = null;`. Some are legit footguns, but they rarely get in your way.
Python has weird file imports (no relative ones either), broken package management, historical differences between asyncio and blocking that still cause issues, threading/GIL caveats that trip up even experienced users, indentation for scope (esp weird given it was designed for REPL), weirdly no anonymous functions, 2 vs 3 (mostly gone by now), the __init__ and __init__.py stuff, namedtuple vs dict vs object, `global`, and a whole mess with type-linting if you're going there. You have to deal with all those things every time.
Here's one little Python footgun that everyone hits and is also annoying after:
> that everyone hits and is also annoying after
I don't know why you think it should be so common, because mutating a parameter with a default value doesn't make a lot of sense in the first place. But also it's one of the single most well-documented things about the language, and it's also historically been found useful when invoked intentionally (https://stackoverflow.com/questions/9158294).
Also, we call that a list, not an array.
> no relative ones either
It certainly does have relative imports, and I have no idea what you think is "weird" about the import system.
If you're talking about dynamically importing from a string path, that, too, works just fine with a relative path. It's just that relative paths are relative to CWD rather than the source file, just like any other time you open a file.
If you're annoyed that you don't just specify a file path, keep in mind that a Python module doesn't have to correspond to a file at all. What you ask for in this case is impossible and nonsensical.
> weirdly no anonymous functions
Incorrect. `lambda`.
> differences between asyncio and blocking
This is like saying "differences between cars and traffic jams". It makes no sense whatsoever.
I could go on, but the short version is that you do not know what you are talking about.
List default args are well-documented because everyone runs into it and no other language does it that way. "You can use it to cache values between function calls:" and I really hope nobody does that.
Python has "relative imports" in that you can import relative packages, not files. So the weirdness is, even within my little app, I have to define packages for everything rather than just doing like require("./common.js") like you'd expect in a scripting language. https://stackoverflow.com/questions/714063/importing-modules... . The __init__.py thing is weird in of itself because different Py versions have different rules, and without __init__.py you accidentally make it a namespace package: https://stackoverflow.com/questions/448271/what-is-init-py-f...
> Incorrect. `lambda`.
I meant for general functions, not single-line only. Python code tends to have lots of one-off defs. It's common in other langs to pass around anon functions like outer((var){ ... }). Instead Python covered a subset of those use cases with a whole separate context manager feature (`with`). Why are lambdas single-line only, probably because indents-as-scope would make multiline too weird.
> This is like saying "differences between cars and traffic jams". It makes no sense whatsoever.
I'm sure you've done async coding and run into the classic issue of accidentally doing blocking I/O in code that shouldn't be waiting. For a long time, Python had no such thing, so something like a web backend would use a thread pool which adds a lot of overhead the more IO-bound your handlers are. Then they added asyncio to Python. So now the libraries are mixed on whether or not they do things async. Even psycopg2 needed a whole rework to psycopg3 for this, and it still has caveats https://www.psycopg.org/psycopg3/docs/advanced/async.html#as... . Django has some complexity around async vs non-async too. I don't fault Python for not thinking of this back then, but the end result is confusing.
JS had an event loop from day 1, so it's much safer to assume there that IO is non-blocking. This was part of the motivation for Node.js. There's still code predating async-await, but it's easy to wrap that.
What you put as an example isn't a footgun if you know how the language evaluation rules work. Once you understand that the "footgun" explains a dozen behaviors, which may be a weird behavior but it is consistent.
Which isn't really much of a refutation because you can say the exact same thing about what's on wtfjs.
There's really no comparison. I use both languages extensively and JavaScript is by far the quirkier language.
No, the JS WTFs have to do with language quirks that result in conditionally different behaviors. The Python WTFs have to do with underlying mechanisms that are not conditionally different, but the condition may not be "obvious".
This is so much so that it is described in the Zen of Python: There's preferably One Way to do things, but that one way may not be obvious.
A property of footguns is they make sense and are coherent to people who do understand them. To them they are just useful tools (i.e. guns).
A gun becomes a footgun when you put it in the hands of someone who doesn’t understand how it works and they promptly blow off their foot.
I clicked on half a dozen of these at random and none of them are weird.
For example, why would you expect `Boolean("false")` to equal `false`? It's a string, and bears no relation to the Boolean type. [0]
[0] https://wtfjs.com/wtfs/2014-10-07-true-equals-false
I agree that the examples on that site are not very good. What about
or orAll of these are cause JS builtins like to auto-cast things. + only accepts strings or numbers, - only accepts numbers. Really these should be errors instead, but it's also not very surprising or annoying once you know this. Basically, don't perform arithmetic on things that aren't numbers.
The name parseInt suggests it takes a string. Especially "" - 5, why?
> [1, 2, 3] + [4, 5, 6] == "1, 2, 34, 5, 6"
Well, `+` is a string operator. There's no infix array concatenation operator, so makes sense.
> parseInt(0.000001) == 0 > parseInt(0.0000001) == 1
Never knew about this one! Quite funny actually and I'm curious why that happens. I suppose because `0.0000001` is represented as an exponent rather than a decimal? Although I haven't seen `parseInt` used since 2015, you should use `Number`.
> "" + 5 == "5" > "" - 5 = -5
iirc
`+` operator: - If LHS is a string, concatenate - Otherwise, cast to Number and perform arithmetic.
`-` operator: - Perform arithmetic.
All of these are explainable, and never catch anybody competent out in practice. And, since TypeScript is the norm in a lot of places now, it's never an issue.
parseInt wants a string. If the input isn't a string, it calls toString. 0.0000001.toString() gives "1e-7". parseInt takes the first number it seems in a string, so 1 in this case, or like parseInt("123asdfasdf") gives 123.
What about the fact that there isn't a single 'parseInt' function in JS that can reliably only convert number strings to numbers?
They each have different quirks (some will parse 'a123' as 123, others will handle scientific notation etc). The only reliable way of doing this is doing a regex followed by parseInt... which is definitely a footgun IMO.
Unary "+" returns NaN for strings that don't contain exactly a number (except for empty string which standard type conversion turns into 0). It even works for scientific notation like +'1e3' === 1000.
A lot of them are also about nulls and == vs ===, which are weird, but they're weird in many langs. Like Python has the whole == vs `is`. You just learn the convention and use it. Same with typecasts.
Distinguishing object equality from object identity is not even remotely comparable to having implicit, unintuitive casts everywhere.
Fair, but I'd expect consistency. Number("1") equals `1` IIRC.
> The article missed the most common one, __name__ == "__main__" like wtf
It makes perfect sense, but also is not an example of what TFA is about. In fact the entire point of having that `if` check is that `__name__` is not a constant.
> __name__ == "__main__"
What makes this weirder than other languages detecting if they’re an import or an invoked file?
It’s only weird syntactically. Python tends to lean towards intuitive, natural language by default. I would have assumed they’d have created a syntactically straightforward alternative, like:
__this_file__ == “__launch_file__”
or similar. I understand python values “only one way” of doing things, but it would be helpful for readability.
No, the “readable” shortcut would have been
There are no magic strings to remember and the IDE can help you look up variables.Again, this is a CS/Math major kind of thinking. The term __main__ means nothing syntactically. If we care about language acquisition -- thus language adoption -- it is always better to make "very common terms" in the language understandable to someone who is completely illiterate to your formal language.
I honestly think one of the main reasons why python is so successful is as simple as:
...and later: It might not seem like much, but when you're asking someone to pick up a language outside of a classroom setting, it's just much more intuitive than: or: or god forbid: These little things matter in the long run, even if they don't seem like they matter when you're already fluent.Idk what's better, console.log or print, cause way back as a beginner I was confused what it means to print something. Like with ink? They're both ok, unlike the C++ or Java ways.
But Python breaking hello world in version 3 was crazy.
this isn't uniquely pythonic and JS isn't a great counterexample.
https://nodejs.org/api/esm.html#importmetamain
node also has __dirname and __filename from the good old days.
Past: https://news.ycombinator.com/item?id=49284392 (with my comment), https://news.ycombinator.com/item?id=49250370 .
Nice to see it get attention this time.
… I take it back.
It would be nice if, just once, we could have a thread about interesting esoteric Python behaviours without people taking it as an invitation to dump their laundry list of things they personally don't (or do, for that matter) like about Python, or to make inane comparisons to other languages (especially JavaScript, for very unclear reasons) while being simply uninformed.
The __debug__ constant is really weird - any block of code guarded with `if __debug__:` will be entirely omitted from the bytecode under PYTHONOPTIMIZE=1. This and `assert` are the only two examples of real “conditional compilation” in Python. This is also the reason why you cannot assign to __debug__: doing so would make it possible to invalidate the compiler’s assumption about `if __debug__:` statements.
I honestly have never even heard of this constant and I feel like I've been using python for a pretty long time. Although maybe my memory for some things just gets garbage collected if I don't use it enough. Does it actually get used that often in real world code? Seems like it might be kind of risky.
Because Python lets you get as far as it does without formally learning everything, but is also expected to suit a huge variety of use cases, it ends up with lots of hidden details that are irrelevant to most users.
The most direct way to find out about `__debug__` is to read `python -h` (or the usage message, which is not all that easy to trigger) in full, and then head over to the documentation.
> Does it actually get used that often in real world code?
https://github.com/search?q=language%3APython+%2F%28%3F-i%29...
I feel like it's the kind of thing you might wind up caring about if you're micro-optimizing your python, but in my experience that's a losing game and you're better served rewriting it in another language than bothering with trying to speed up the execution of the raw python code (it's not that you can't optimize python code, but only in broader strokes. If you are looking at the bytecode you're in too deep and every time I've seen it tried the code has been ported shortly afterwards).
Ditto. I’ve certainly never used it and can’t recall seeing it in any codebases I’ve worked on or looked at. Sounds interesting though!
I’ve of course certainly heard of, seen, and used `assert`, but more often than not, outside of pytest, I see its use way more in potential footgun scenarios—I doubt that many people know that assertions can be silenced, and that they’d probably be better off raising exceptions in many cases where they’re using `assert`.
I made a CTF problem where `assert` was used as a critical safety check - and where "accidentally" running the program under -O (for speed!) resulted in a security vulnerability. A large fraction of the people who attempted the problem seemingly missed this bug.
I would not be surprised in the least if that pattern existed in the wild. In fact, it's quite common to see this in C/C++ codebases too: people will use assert() to check a security-relevant property, and then disable those checks in their release builds "because it can't happen".
I see asserts used in production code as part of flow control way too frequently, so I assume the majority of python users aren't aware of the -O flag, much less this behavior- which I too haven't ever heard of. Of recently, I've noticed claude is a big fan of asserts too.
Yep. I’ve had to tell Claude to basically not use assert. Thankfully it’s very complaint in this one area.
If 0. Etc. are also compiled out, at compile time __debug__ is simply False or True and the existing optimization paths take care of it.
Assigning to __debug__ wouldn't do anything to the compiler as it never actually reads the variable, so assignment would just cause weirdness from other use
I remember reading that in early versions of Python there was no built in True and False. Each user would implement this themselves as
True = 1
False = 0
then later these got added to the language. In Python 2 you could still reassign and swap them so that 'if False' was actually true!
True, False = False, True
Python 3 you could no longer reassign them.
Misery is trying to retrofit "bool", True/False, and nil/null to a language. C had to do that. Python had to do that. Getting those wrong is one of the classic language design mistakes. It seems like treating "True" as a value that equates to 1 will work, but then the special cases get you. Like being able to perform arithmetic on True.
Common language design boners:
- Not building in strings. That's now in the past. Everybody has strings. (Well, C...)
- Not building in multidimensional arrays of the numeric types. Everything that number-crunches needs them, and having multiple definitions is Not Fun and may lead to expensive re-copying between different libraries. This is an enormous blind spot in language design. It's one of the reasons FORTRAN, which has good multidimensional numeric arrays, is still often used for number-crunching.
- Not standardizing the small vectors (vec2, vec3, vec4) and their matrix friends. Graphics code depends on these, and it's really annoying if there are multiple slightly incompatible implementations. Especially since GPUs have hardware for those types, and you want CPU and GPU to use the same representations.
- Not having arrays of bits. Pascal had PACKED ARRAY[0..N] of BOOLEAN but that was lost in later languages. It's useful to have that as a language construct, because most modern CPUs have good hardware for dealing with bit strings, and you'd like the compiler to use it.
Most useful languages acquire these features, but, when they come in late, there are multiple similar implementations, and libraries made incompatible by depending on different implementations.
(Amusingly, when Second Life switched from Linden Scripting Language to Luau, they initially had True, TRUE, and true all in use, as different types with different semantics. I was able to persuade the devs to unify the boolean types.)
You list a few absences but absences aren't the end of the world, I say it's worse when designers make a booboo where the language semantics are wrong. In C++ there are so many of these it's not sporting but a recurring example from the garbage collected languages would be the for-each loop mistake.
Several times now†, people make a language where the way a for-each loop (for each Goose in Geese ...) works is that there's a single variable Goose and each time around the loop we change which value is referred to by the Goose variable. This seems intuitively like a reasonable way to do this. But it's wrong and eventually your programmers will get nasty surprises. What you actually should deliver is an implementation where each time around the loop there's a new variable named Goose, that variable goes away at the end of that iteration and will be replaced by the next one, with the same exact name.
† At least Go and C#, I think there are others
> What you actually should deliver is an implementation where each time around the loop there's a new variable named Goose, that variable goes away at the end of that iteration and will be replaced by the next one, with the same exact name.
Is this because a closure inside a loop will capture a reference to `Goose`?
I think that this is a capture problem not a variable problem. The closure should always do the right thing and capture the value of all variables (not just ones inside the loop), instead of capturing the reference to the variables.
Then the general problem is fixed to match what developers expect, instead of a specific instance of that class of problems being fixed and working differently to how other captured variables work.
The interior of a for-loop is only a scope, not a closure. In most non-dynamic languages you can't package up the state and hold onto it beyond the life of the loop, which is what closures are for.
Most trouble in this area came from the iteration variable outliving the loop. That's not good when the iteration variable is a pointer. In C, it often is, and at the end of the loop, it points to an invalid address. It was a change to C (when?) to make the iteration variable go out of scope before code after the loop could get at it.
> I think that this is a capture problem not a variable problem. The closure should always do the right thing and capture the value of all variables (not just ones inside the loop), instead of capturing the reference to the variables.
Now your "lalanthran closures" can't mutate the world because they work exclusively with copies not references, if they try to mutate something then whatever they're touching was just a copy not the real thing.
> Now your "lalanthran closures" can't mutate the world because they work exclusively with copies not references, if they try to mutate something then whatever they're touching was just a copy not the real thing.
That is true. I still don't like the idea of "Here is a general rule. It applies everywhere but $HERE." Whether that general rule is "All captures are by value" or "All captures are by reference", the rule should not have exceptions based on context in the code.
A better tradeoff would be to have the general rule (whatever it is) apply everywhere, along with syntax for capturing (or not, depending what the default is). I'd rather have it grab everything by value, and for those things that are susceptible to race conditions (because more than one closure is modifying it), explicitly annotate it with a sigil (`&`, or a keyword, or similar).
I mean, in pseudocode, when I see:
I don't want to have to examine the surrounding scope to know whether or not `y` is susceptible to a race. I'd rather just see: An alternative viewpoint is that many languages have immutable variables and they seem to be getting along just fine without needing mutation on variables, shared or otherwise.> the rule should not have exceptions based on context in the code.
But the rules didn't and still don't have any such exceptions.
> A better tradeoff would be to have the general rule (whatever it is) apply everywhere, along with syntax for capturing (or not, depending what the default is)
This "solution" is how it works in C++. We can thus castigate the programmer for writing the wrong runes in their captures list and never for a moment doubt that we got it right when we introduced so very many footguns...
Tony Hoare's observation applies "One way is to make the program so simple, there are obviously no errors. The other is to make it so complicated, there are no obvious errors."
> An alternative viewpoint is that many languages have immutable variables and they seem to be getting along just fine without needing mutation on variables, shared or otherwise.
Sure, and one of the astonishing things in C# or Go before they fixed this is that you can indeed have immutable variables which change, even though that's silly - the language can decide that you mustn't change Goose, but it doesn't need to obey its own rules because it will change it for each loop iteration.
> Not having arrays of bits. Pascal had PACKED ARRAY[0..N] of BOOLEAN but that was lost in later languages. It's useful to have that as a language construct, because most modern CPUs have good hardware for dealing with bit strings, and you'd like the compiler to use it.
I'm not sure exactly which features are responsible (I'm inclined to blame templates), but C++'s std::vector<bool> is a rough edge. For those unfamiliar, the standard specifies this vector template in a way that's not compatible with other vectors.
Agreed. Instead of special casing Boolean arrays to be packed, it's better to have standard Boolean arrays and bitarrays as separate types.
They should have made `std::bitset<std::dynamic_extent>` what todays `std::vector<bool>` is (actually maybe not, `std::bitset` is fixed sized, just compile time fixed size). While at it also make `std::array<std::dynamic_extent>` a runtime fixed size array.
Vectors & multidimesional arrays are something I'm 100% adding to my language's core.
It kind of started with vectors as the very first feature (I was sick & tired of libraries reinventing their own `Point`/`VectorN` in incompatible ways).
Oh wow, I had no idea that SL did another language change after migrating LSL to Mono. Surprising considering that happened late '00s/early '10s?
I'd consider LSL to have been foundational in my ultimate interest/career in software engineering. The strict typing, very usable compile/runtime errors, and good documentation/examples made it so easy to pick up as a teen. Not to mention as long as you didn't edit/save a script again it would always run the same regardless of updates.
Strings are a really weird data type. I'm not sure you can do much better than C strings without implicitly requiring dynamic memory allocation, which C deliberately does not do.
Definitely agree on multidimensional arrays. I feel like efficient arrays in general are underrated in high-level language design.
> Strings are a really weird data type. I'm not sure you can do much better than C strings without implicitly requiring dynamic memory allocation, which C deliberately does not do.
The thing you want is what Rust delivers in the box, &str a string slice reference type, in Rust's case the "string" is UTF-8 encoded text. On the bare metal the way to represent this type is as a "fat pointer" typically a pair of registers, one with the address of the first byte of the string and the other with a length.
C should have fat pointers, they were proposed, for IIRC C89 but the proposal was rejected. That's pretty sad, the fat pointer is expensive to the point of maybe feeling extravagant on a PDP-11, but by 1989 that's long gone.
More ridiculously C++ didn't get this type (which it eventually called std::string_view and provides in its standard library not as a built-in) until 2017, years after Rust 1.0 shipped. In the meanwhile C++ just did not have a sensible way to do this, strings are hard apparently.
The string buffer feature, allowing you to actually make strings is less important, as you say it will need an allocator and so on very bare metal you might not have this - but the string slice reference doesn't need an allocator.
I think it's worth delivering the basic "it's a growable array type, duh" implemenation of the string buffer type, which is what Rust's String type is, but C++ chooses to ship an oddly specific small-string optimized version as std::string right from the offset.
Yes I remember a friend doing university marking for a beginners programming course years ago and some student had managed to swap True and False making their assignment very wonky.
I was surprised TFA didn't mention this, or seemingly know about it.
It is certainly the case that isinstance(True, int) returns True, even today.
I got a bug for not remembering it, a couple of years ago: https://jpscaletti.com/p/8/true-false-one-and-zero
Hmm. Having read your post, surely the bug is having a function where
removes foo entirely. What if you want foo to have the value False? Even besides the unintended behaviour where 0 is coerced to a boolean value, this function seems poorly designed.I don't remember the specifics, it might have been a simplification for the example
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
Python has some absolutely kick-ass libraries, even without C. It has Django, for those of us who like developing web apps but never could fall in love with Ruby on Rails. And Django is amazing. I've also yet to see a better language for writing quick ETL scripts and pipelines. Also, an 'I need a script for $SYSADMIN_TASK but I want to be able to read it later.' Anything dominated by external latencies (web, databases, etc) will be fast enough for many uses in Python.
Sure, it's not a language to write a web browser or game engine in. And it is slow. But it has some very strong niches outside of ML/Data science. Personally, I love it. To each their own.
> Also, an 'I need a script for $SYSADMIN_TASK but I want to be able to read it later
uv + PEP723 make this even better.
Isn't "..." then also behaving like True, False and None, i.e. being a lexical token that rewolves to a hardwired value during parsing?
rewolves? EDIT: ah, "resolves" typo. was v curious about python's mysterious "wolfing" aspects
Yes, sorry, I had typed that on my phone. But yeah, now I want to know more too about python's new type wolfing paradigm.
It is, but Ellipsis is just an ordinary pre-defined constant (with the same value).
Yeah, that makes sense.
You wouldn't expect ... = 42 to work syntactically.
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/scratchpad
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.
Ruby is beautiful in its design, but it made imports and namespaces (a.k.a. modules) separate concepts. This is so flexible it became hard to ever find anything easily in practice.
Likewise, it made classes incredibly easy to extend, which led to a monkey patching bonanza and far too much magic everywhere (Rails being by far the worst offender but not the only one). It meant having to keep too much stuff in your head and needing deep framework/library familiarity just to be able to understand basic code.
In the end, I feel like the incredible flexibility was Ruby's undoing, not just lack of library availability for a specific popular application. I was a Ruby zealot at one point but it began to lose its lustre not because it wasn't beautiful in theory, but because it was inconvenient in practice. In some ways, Python's restrictiveness became its greatest attribute. Then Python 3 helped to fix a lot of the inconsistency.
Both Python and Ruby have a consistent logic to them, just not consistent with each other. Just as all attributes are methods in Ruby, so all methods area attributes in Python, etc. Things get much easier in either language if you stop fighting their internal logic.
Long before AI work, numerical data crunching is what Python became popular for among non-computer scientists and this led directly to the AI use cases. The reason was obviously the lower barrier to entry without having a software engineering background. I also share with you that feeling about Ruby in particular.
> 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.
This is just my personal opinion with no data to back it up, but I suspect that Python "won" because it has excellent Windows support, while Ruby doesn't. Even a decade ago, Python's website offered an official native Windows installer [0], while Ruby's website [1] still points you to a third-party installer, which doesn't even have native support since it uses MSYS2 [2].
Most non-developers use Windows, so if you're choosing the first language to teach a large group of people, good Windows support is fairly important. Python being the "default" introductory language gave it a huge number of users, then I suspect that everything flowed down from there.
[0]: https://web.archive.org/web/20160824235759/https://www.pytho...
[1]: https://www.ruby-lang.org/en/downloads/
[2]: https://rubyinstaller.org/
This could be it. The classic student with a Windows laptop and git-bash installed, where they think git and bash are the same thing, also PuTTY.
I also wonder how many people gave up on Python just because the installer doesn't put it in your PATH. You'd install Python then no python, wtf. Ok so https://discuss.python.org/t/python-command-not-found/22255 ... Then you fix it and it runs the wrong version of Python.
> but I suspect that Python "won" because it has excellent Windows support, while Ruby doesn't. Even a decade ago, Python's website offered an official native Windows installer
I think you might be able to go an additional decade backwards. Back in college most of my friends were on windows and one of them was using python for class projects.
> I think you might be able to go an additional decade backwards
Yeah, Python has had good Windows support at least 15 [0] or 25 years [1], depending on how you count it.
> Back in college most of my friends were on windows and one of them was using python for class projects.
Well it's always been possible to install Ruby on Windows too, it's just that Python supports it so much better.
[0]: https://peps.python.org/pep-0397/
[1]: https://peps.python.org/pep-0277/
Python's strength is that it's easy to make C libs work in it. That's also why CPython is de facto the only Python implementation and stuff like PyPy never took off.
Yeah and I would say that another important factor is Cython, which compiles Python with minimal modifications to C extensions that can in turn be imported in Python. It really makes it easy to get started in Python and worry about performance of the computation later. (Doesn’t help with concurrency I know but that’s a different story.)
> Python's strength is that it's easy to make C libs work in it.
SWIG[0] makes working with C libraries trivial for over a dozen programming languages; Perl, Python, and Ruby included.
0 - https://www.swig.org/
There are reasons all those Py libraries with C code didn't just do it in SWIG.
> There are reasons all those Py libraries with C code didn't just do it in SWIG.
And those reasons are?
The point of SWIG is it works across many langs, but this comes at a cost. The SWIG .i and autogen'd C wrapper are extra layers that can get annoying, particularly during debug. Always hated dealing with SWIG'd libs at work. And Python C modules give easier control over Python specifics.
I like Python but this was always actually one of my pain points. The CPython C API is full of foot guns, the API surface is expansive, and writing against it requires a lot of careful care. Anyone who's ever written C modules for both languages would be able to attest how much more pleasant the experience was for Ruby than Python.
Ruby can interface with C (or Odin, or anything that can export C style functions) just as easily.
I would argue more easily.
How is a language that has different semantics for referring to lambdas vs other functions consistent?
Ruby's most important error is that it does not support namespaces. This by itself makes it a far less scalable language than Python.
Did you mean to say that Ruby doesn't link name spaces to file system paths? Ruby has namespaces and they're far more flexible than Python's... too flexible in my opinion, making it harder to find things.
Ruby namespaces force requiring everything and don't allow for relative imports among other features that are very important for larger software.
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.
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.
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.
>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.
This is exactly what I remember being said about C (which I agree with) and often given as a reason why higher level languages like Python or Java have so many protections against things C/C++ allowed (memory management being the biggest one of course). Very funny, and I assume not coincidental, to read this about Python in the modern programming landscape.
Well, there are plenty of safety mechanisms that Python doesn't have and dangerous (usually powerful, occasionally badly designed) mechanisms that it does have.
If that's the case maybe we should stop teaching it to kids?
Until someone adds a dependency…
I generally just "apt install" them. pyenv and pip (just pyenv really) are a little clunky, but work too.
> 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.
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.
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.
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
I'm fine with the language. I just hate that you can't do
and the code gets exactly the version it wants.Relatively new, scripts can define dependency metadata now adays to achieve that to some degree. Any pip style versioning including an exact match works there.
https://packaging.python.org/en/latest/specifications/inline...
The imports/packages situation is terrible in general. This was basically broken until uv, and uv is still not the default.
And it's weird how you import files. They're dot-separated packages that resemble file structure but not exactly. NodeJS has a self-explanatory require("./foo.js") or "../foo.js". The newer JS `import` syntax is annoyingly different from `require` but not terrible.
I've never become a fan of the language syntax, but otherwise I've become quite smitten with the total Python ecosystem. The Agents/LLMs + uv combo have made Python so useful and productive for me.
My CLI tools publish from Github to PyPI so that I can run tools with just `uvx sql-agent-cli` or `uvx dlna-here. Nothing for me to handle downloading (directly myself), no environment to manually setup, portable (Linux, Windows, Mac, ARM, x86). Easy for agents to run from a skill.md file without any other prereq than uv.
Really useful library ecosystem to leverage. No more shell scripts, or TS/JS/PHP backend services. I've even used Python on devices I've built around Raspberry Pi Zero 2 boards.
> No more shell scripts, or TS/JS/PHP backend services
You didn't use Perl before? https://xkcd.com/353/
> I often work with data scientists and have to productionize their jupyter notebooks
At least it’s Python/Jupyter and not R, SAS, or MATLAB.
> Python is awful.
> I often work with data scientists and have to productionize their jupyter notebooks
I'm not a huge Python fan, despite working with it fulltime, but this feels like mixing correlation and causation. Data scientists would not be writing good, optimized code in any language.
Well, yeah. You might need to bring an R notebook into production.
Scripting languages are awful. Python is one of the nicest scripting languages.
Holy 2000s! Are we really still doing “programming” vs “scripting”?
Why wouldn't we? It's still a very relevant distinction, even if the terminology is a bit weird (since scripting is by definition programming). A programmer has very different needs when he writes a script to automate some server tasks versus a complex piece of software. It makes perfect sense that different tools will be more or less effective at meeting those different needs.
There is no reason why automating a server task cannot be a complex piece of software. I think you’re not aware of just what server automation is used for nowadays in countless cases. Also, Python is more popularly used in ML and web-development areas compared to server automation, so that would mean it’s not a scripting language by your logic.
There’s still a great difference in requirements between small and large scale development.
Spoken like someone who hasn't tried to get data scientists to use other languages productively, where they'll be missing half the libraries, will have to triple their dependency count because you can't count on large common libraries and will have to dig to the ends of GitHub to find random functionality etc.
Python is amazing compared to writing bat/sh scripts. Different languages are for different purposes, using eg. Rust to write system scripts would just be mental. Whether people abuse those languages for purposes they were not intended for is another story, but that doesn't mean the language is inherently bad. And I mean,
> and it’s way too easy to do the wrong thing
is there another programming language where you believe a data scientist is going to have an easier time writing correct code than Python? Do you think C or Rust or JavaScript or C# make it harder to do the wrong thing?
C'mon man, I don't know any mid and above python developer who seriously has ever considered programming in Jupiter Notebooks. Python is not slow, it's you being the issue. If you are an amateur then it's easy to do the wrong thing, that's true.
Seems like an excellent user for LLMs
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
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.
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).
What is the best language for controls and embedded, in your opinion? I assume from your comment that it's not a great choice as a first language to teach newbies, but I've never done anything in the field of robotics or embedded stuff, so I'm quite ignorant in that area.
If I'm not allowed to toot my own horn, I think for controls, you probably should not start with choosing a programming language, the first step is learning control theory and automata theory, you kinda have to understand feedback control/PID/steady state/jitter/hysteresis and the like. Python has never had great control libraries to begin with as far as I can remember (my info could be a bit outdated though), so the paid option is still Matlab/Simulink as it is their last niche really.
Embedded firmware, probably C/C++/Rust. Not the answer you want to hear, but these are the languages for bare metal applications. Of course, if you are just using an Arduino/Pi, just use their SDK for their hardware on whichever language they support.
Those two fields are just not very friendly towards beginners in general.
Please do toot your own horn. I assume you're referring to https://github.com/yuechen-li-dev/oct — tell us why it's good.
Sure, short list: - Easier to write than Python other than the simplest script, almost no way to write bad code and have it compile, reads like pseudocode most of the time - Compiles into Go binary, runs at Go speed, compiles at Go speed - Trivial to wrap any Go library via LLMs, so any Go library is also an Oct library. - Can metaprogram existing Go codebases, so it doesn't really replace Go, just supplements it - Easy concurrency/parallelism - SI units as types - Can be used as build script for C/C++ in place of CMake - Einstein tensor notation - Builtin GPU acceleration via Vulkan
It was designed as a teaching language for academics to stop writing bad code, but now I just get LLMs to do research/science for me with it for fun.
Yeah! Like when helping teens set up PID controllers for their CAN-bussed robot, it was very much a "we've got a lot of example working Java code with a PID Controller library already. So we're using that." The language itself is so inconsequential at the early stage, that you really just pick whatever gets in your way the least.
None of them. Walks away. Stops. Turns. All of them.
It depends. If you're a teen I'm mentoring, you're probably starting with some Scratch to drive Lego robots around. Then on to Python to drive the same robots around but now with more fun!. Probably because you absolutely couldn't stand the standard line follower solution of jittering back and forth and you sniffed out the existence of better control loops you cannot realize in Scratch. If you're on the FIRST Robotics team you're probably doing Java or Python, mainly because that's just what we've geared up for (and this is really the core theme for me at least: at introductory levels, what really matters most is whatever is most readily accessible to you and whatever kit you already have).
If you're doing your own stuff and you're a newbie with absolutely no opinions on where you started or what you were trying to do, you'd probably start poking around with an Arduino or similar, so you could write MicroPython (it's Python but you squint your eyes a bit!) or C. There's so many great kits for beginners.
In the context of my comment: what I meant is that you wouldn't decide, "the professionals do it in C++, C, or Rust, so we'll start with one of those." I'm going to give you a recorder (Python) before I hand you bagpipes (C++).
If I'm teaching you programming and you've learned Scratch, I'm going to hand you Snap! (https://snap.berkeley.edu/) next. Because it's Scratch, but with the artificial limiters removed. Snap! (the exclamation mark is part of the name) allows you to store lists in variables and pass them as inputs to functions, and it has the standard list-handling functions you'd expect, like filter and map. Moreover, it also allows you to store blocks (functions, basically) in data structures and pass them as inputs to other blocks, so you can actually learn to write code in functional-programming style.
Once you learn that Brian Harvey, one of the two main designers of Snap!, was one of the principle people behind Berkeley Logo (which itself was a variant of Lisp, though that wasn't clear to me when I was learning Logo at age eight), it all starts to become clear. Snap! is itself nearly a Lisp, just lacking macros (and Brian Harvey is trying to figure out how to add a macro system to Snap!, with the primary challenge being making it comprehensible in graphical-blocks form).
We’re spoiled with great options. My kid jumped right from Scratch to JavaScript for game dev because he loves how he can put his games on the Web easily. Huge props to Microsoft Make Code Arcade for allowing you to port your Scratch to JS. It gave him a powerful way to see what he knows and how it looks like in JS.
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.
Well, many times in my field of mechanical engineering, they have to, because CFD and FEA are very performance sensitive. The professors I had were still writing FORTRAN and C++ before, but maybe they've switched to Rust now.
> 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.
> 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.
scala's repl is decent. It has its annoyances, but so does python's (white space sensitivity + repl + terminal emulators stuck in the late mid century don't mix).
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.
Oh, by "significant whitespace" I meant whitespace sensitive indentation, which I think Python and YAML are the only languages that has that feature.
Haskell, Lean, and Agda too. But even if Python were the only one, it wouldn't be weird to someone for whom this was their first programming language. It would just seem the way programming languages are. There's nothing intrinsically weird about indentation being significant. It's quite visibly part of the code you write and read.
> There's nothing intrinsically weird about indentation being significant. It's quite visibly part of the code you write and read.
The idea is fine, I guess, although I certainly don't care for it. Where it gets most nasty is that whitespace that looks the same (in your editor) might not be equal and will cause you pain.
> Where it gets most nasty is that whitespace that looks the same (in your editor) might not be equal and will cause you pain.
First off, what editor could I end up using in 2026 that makes this a realistic problem? Even the most basic editors I know of have options to convert tabs to spaces automatically (and any responsible teacher will tell the student to indent with spaces), and to continue the previous line's indentation automatically.
Second, modern Python is stricter about this, and also gives clear error messages.
> Where it gets most nasty is that whitespace that looks the same (in your editor) might not be equal and will cause you pain.
This is why idiomatic Python only uses spaces for indentation.
Hmm. Learned something new today. Thanks.
F# as well.
> 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.
> Which is different from how it works in other similar languages, how exactly?
They are contrasting with languages where true is true and 1 is 1; but true is not 1, and 1 is not true.
> Which is weird, how exactly?
Sometimes if it looks like a duck and quacks like a duck it can still not be a duck.
> You can go a lot further than five minutes in Python without having to worry about threads at all
Unless you specifically want to do multithreading.
> the worst thing the GIL does is deny you the multi-core processing you thought you were going to get.
That is the worst thing because I wanted that multi-core processing, that's the whole reason I wanted to do multithreading.
> True, False, and None are keywords. they aren't identifiers, they're just straight up their own lexical tokens.
Could this be so that the interpreter don't inadvertently manipulate them or pass them to a function? param=None and param="" can be very different.
It also helps prevent people from ever redefining them. I mean, if you try to redefine False (in a version of Python that allows it) then you deserve everything that's about to happen to your code... but at the same time, it could possibly lead to a security attack. Redefine False then import some module and get unexpected behavior that you can manipulate to your advantage, somehow. I don't know how that would work, it probably wouldn't... but there's also no reason not to lock those names in and prevent them from ever being redefined.
Wow, I wish to understand the internal details of Python implementation that makes it behave in such a way :)
I don't. I have no interest in trying to assign a value to something that's built-in and not meant to be written to. Like who fucking cares that the boolean constants are actually weird little structure that sometimes let you mess with them and other times your edits are ignored? Maybe this is helpful for writing an entry for an obfuscated code challenge but I'm not doing weird shit like that with the code I expect to work between various Python versions and implementations, especially when I'm getting paid to do it.
Please. Such a charged response wasn’t justified at all. Different people are curious about different things. You ask “who fucking cares?”. The answer? You don’t, and the person you’re replying to does.
You're right, I was feeling a little salty
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...
That’s a fun library :)
Yeah it was a blast to make. If memory serves, a significant piece was over a very lovely and piney joint with Kieran Prasch at an airbnb in... Seattle?
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.
It is 30+ years old with all the baggage you would expect. It’s very much a product of its time.
It’s not like that cannot be changed. Look at PHP, which managed to evolve brilliantly over the last decade and gets tons of things right now.
I keep on hearing people be excited about PHP. Having first attempted to use PHP in early 00s, I simply cannot bring myself to attempt it again. I once had to rewrite large chunks of a site because it simply couldn't deal with the fact that a string had an apostrophe in it.
I can only recommend to check out a popular project, maybe Laravel, and read it’s documentation. Alternatively, look at the PHP website itself. The new syntax improvements alone are pretty convincing IMHO, but the engine also got a JIT compiler, a runtime type system that’s fully opt-in, fibers for concurrency, and much more.
It’s really worth a second look.
PHP has evolved a lot, but it also still has a lot of cruft from its earlier days. And it has made breaking changes on a scale python probably couldn't get away with.
Show me a language that old without lots of cruft. The worst thing you can find is the standard library, which is just an unsolvable problem.
That's my point. PHP is still an old language with lots of "baggage", just like python is an old language with lots of "baggage".
Just like C# has baggage. Or R has. Or Go, to some extent. This is a non-sequitur.
I don't disagree with any of that. The context for my comment was (paraphrased):
GP: python has baggage because it is old
P: that can be changed. Look at PHP
Me: PHP still has baggage, despite its evolution. You can't really get rid of it without making major breaking changes.
Python 3(000) was an opportunity to fix all the things, so in a sense, the modern Python is less than 20 years old.
They didn't fix nearly enough, and then everyone complained about too much being fixed, and acted like twelve years wasn't enough time to adapt.
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.
Perl is a lot like that also, you can read about some really weird old features like $[ but you never see that in practice, you just write code with variables and functions and so on.
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.
Comparing it with PHP is unfair… to PHP. The amount of hard work that the PHP community has done to advance and keep their language relevant is impressive and admirable, and Python is perhaps the most extreme counterexample there is.
The Python community has spent the last 15 years refusing to improve in any meaningful way, or to learn anything from their peers. As someone who used to choose only jobs that would let me work with Python, I’ve gone through every phase of grief, and now just try to forget that it exists.
Lol, Python has had incredible improvements over the last decade plus, while uv fixed packaging. It's the best/comprehensive glue language ever made, even with a few remaining warts.
Most of the time downvoters don't explain their downvote, but I'll explain mine. I voted this comment down because it's just plain incorrect.I worked with PHP for nearly ten years (and I never want to go back). Maybe PHP has improved since I worked with it (PHP 7.4 was the most recent version when I last worked with it, I have never used PHP 8), but I doubt it.
But to describe the Python community as "spen[ding] the last 15 years refusing to improve in any meaningful way" is just laughably wrong. I can't give details as I haven't been doing much Python work, but even so I know of multiple changes, such as the typing system, or packaging improvements, which have significantly improved the language AFAICT. If there's a reason why you would not consider those to be "improv[ing] in any meaningful way", please enlighten me.
You mentioned two biggies, but also the GIL removal, async, performance improvements, f-string, walrus, fast dicts w. merge ops, data classes, pattern matching, friendlier repl, and hundreds of smaller yearly improvements.
Pattern matching? Nice, I'd managed to miss that one completely, as well as the fact that Python had introduced dictionary-merging (according to a quick search, Python 3.9 introduced the | (pipe) operator for dict unions). I did know about the others you mentioned, but couldn't call them to mind when writing my comment.
But reading through a Python script that I had Claude Code write for me taught me another one: apparently there's now a / operator on strings, because Claude wrote `path = "some" / "dir" / "filename.txt"` without importing anything outside of the stdlib. I presume it is shorthand for calling os.path.join and will therefore apply the correct path separator on Linux vs Windows.
Yes, that's a Path object from pathlib. It has been around for while but likely still qualifies, site says from 3.4.
You are both focusing on Python improving in any way but the person you're responding to said "improve in any meaningful way, or to learn anything from their peers"
Which I will say is overstated but I can see where they are coming from even when you bring into scope things like types, async, etc.
First types. This is what the type hints in Python allow you to do:
We can say that this is great Python has type hints, but at the same time the lesson they learned is wrong because the feature to have isn't type hints but actually enforcing them so the above code cannot be written. In my eye, this is an anti-feature.Second async, this is also the wrong lesson to have learned from other languages. Adding async/await is a bandaid over the problem that the synchronous imperative model clashes with asynchronous distributed semantics. The async/await keyword are a way to try to bridge between the two, but it creates a "function coloring" problem that all these languages which added async/await have.
The lesson Python should have learned is to not add these keywords and go back to its glue language root, allowing actually natively asynchronous languages to coordinate asynchronous processes, while Python code handles the synchronous core. Python doesn't have to be everything, the wrong lesson was to try to be the one language to rule them all.
You also brought up the packaging improvements, which I feel were the wrong lesson learned. The problem with the Python packaging ecosystem is well known since it's been expressed in the XKCD comic. The lesson from other languages is: one blessed compiler toolchain integrated into the packaging story makes for a better user experience. This is the npm, cargo lesson. For Python to really learn it, uv or equivalent would be the blessed way of managing Python projects. Instead it's still a very fragmented landscape with many competing solutions, which goes against Python's own zen.
Moving on to pattern matching, again I feel the wrong lesson was learned. Pattern matching is a feature from the functional paradigm that in my opinion became more popular with developers when they became exposed to it in Rust, and so Python joined in and added the feature as well. But the reason it's such a nice feature in Rust is because it will refuse to compile any code that does not do exhaustive matching on all variants. This is great because it catches problems early and forces you to consider the non happy path where things can error. So pattern matching alone isn't the feature it's pattern matching PLUS structured Enums and exhaustive patterns.
So in Python you can do this:
Output will be "done" rather than an error on the match, which is what should happen if they had learned the right lesson, because without exhaustive matching this is no better than an if or switch. Again I consider this an anti-feature -- better to not have at all if it doesn't work as expected.Anyway, I'm not trying to say Python is bad, I'm just saying I get where the other poster is coming from when they say Python has refused to learn the right lessons. Although I would not agree they haven't improved a lot over 15 years.
Not every improvement is perfect, that’s true. I in particular fought against walrus syntax and don’t use pattern matching for other reasons. Python is also boxed in by its history. Some of the things you want done are incongruent with its design.
Many people like them however. And you’re being way too charitable to that dumbass comment.
I guess what I’m trying to do is draw a distinction between “improvement” and “change”. We can agree to disagree but my view is the things I called anti-features are not improvements at all, but rather loaded footguns. Python would be more coherent language without async/unenforced type hints/non exhaustive pattern matching. Like you say, it’s constrained by its history and I feel a lot of the recent changes are to make Python more palatable to the devs who are using it for AI and ML rather than keeping it true to to its nature.
Type hints are very helpful on big projects. And are enforced by other tools. Honestly, this kind of criticism shows a lack of experience, and denial of reality for an almost 40 year old language.
It sounds like scoffing at a Silver medalist to me.
In fact, Python is better at what it does than almost anything from the era. That’s why we use it. Nothing is ever going to be perfect because better solutions are emergent, and reverse time travel does not exist.
> Honestly, this kind of criticism shows a lack of experience, and denial of reality for an almost 40 year old language.
Okay that's where you lost me. You can talk about the language from your perspective, and like I said we can agree to disagree, but it crosses a line when you want to comment on others' experience and put them down just because they disagree with you. No on is scoffing here, what I wrote was a considered criticism. Have a nice day.
It’s about as near a well-documented fact as there is in this industry, and not intended to be an insult. Sometimes we need a wake-up call, and yes they’re not usually enjoyable. I know as well as anyone else, having received my share over the years.
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.
I can understand that "advanced" python programs may be difficult to understand for beginners (lots of implicit/hidden behaviors, possibility to change basically everything one should expect, etc).
But to _learn_ programming, I really, really don't see how using Haskell would be simpler than Python. Perhaps if you have a specific background (e.g., math), but else python is almost pseudo code already. You'll really have to convince me that a more abstract language is better...
Haskell’s hard to interpret error messages alone disqualify it from being a beginner language.
Python: errors based on incorrect indentation (many beginners don’t use nice IDEs), or don’t understand the meaning of the hints) and scope (don’t forget your “global” if you’re hacking in PyGame) are challenges.
> many beginners don’t use nice IDEs
Starting with 3.13, even the REPL is a sufficiently nice IDE to avoid any careless indentation errors from poor formatting (as opposed to ones caused by actually not understanding how many levels of indentation the current line of code should have).
It would help a lot if every single racket/scheme example wasn't entirely made of single character variables.
> Racket / Scheme / I dare say even Haskell would just be so much simpler for learners.
I have used all three languages; and you clearly have no idea of the notion of usability of a language. So many things contradict this, let me list them off the top of my head
- Getting a running toolchain working: Prexisting (most OSes bundle a Python interpreter) or a package install away for Python. Scheme / Racket is some odd mix of custom IDEs with Dr. in the name, or someone's 20 page essay on how SLIME is the best thing ever. Haskell gets into odd stuff with ghci, cabal, and stack, and all of them are extremely slow.
- Tutorials: Python has a ton of them, they all get you printing to stdout and calculating things in about 10 minutes. Scheme / Racket typically spends multiple chapters navel-gazing about lists, cons, and such. Haskell is actually better in terms of the Hello World stuff, but ghci v/s ghc bites you again; and no one has a clear idea of which one to use.
- Advanced concepts: Python has mainstream but halfhearted OOP; and things like decorators and metaprogramming. Quickly intelligible if you learned something else like Java or C++. Or if you learned shell scripts you can get quite a bit done with just imperative. Racket/Scheme: 3 chapters in and you're still trying to figure out tail recursion. Haskell: Instead of just doing fun things with take and foldl you're being hit with trivia about typeclasses.
> Quickly intelligible if you learned something else like Java or C++
You’re replying to a post making assertions about beginners.
That doesn’t usually mean people with 4 years programming experience picking up a new language.
Racket: criticizing for having a beginner-friendly IDE doesn’t make a lot of sense. There’s always Magic Racket for VSCode for the others.
I guess you’re not starting people with “How to Design Programs” because that’s pictures and animations for ages.
Haskell: that was funny but an absurd criticism ghc vs ghci?? Nobody has that problem. The other stuff - valid but lead with it instead of trolling.
> Haskell: that was funny but an absurd criticism ghc vs ghci?? Nobody has that problem.
Back when I was a beginner actually interested in getting out of the beginner step of Haskell, this was an issue for me times. So there's at least one person :)
Also anecdotally I have seen people ask this in Freenode #haskell as well (the “Freenode” probably tells you how long ago this was) ; and there a few issues [1] and [2] where I see beginners having the same/similar issue. The second one is particularly funny, 4 people give 5 solutions and no one seems to know what the actual fix is. Instead you have people arguing whether a repeated do works or not. This would never happen with Python, just saying :)
> Racket: criticizing for having a beginner-friendly IDE doesn’t make a lot of sense.
Sorry, perhaps too harsh but I don't think it's as beginner-friendly as you think. I think it would probably help if they made the design more modern and welcoming. All these details about you can rewrite entire languages in Lisp and we can't even at least get a GUI that looks like it was written after 2007?
---------
[1] https://www.reddit.com/r/haskell/comments/1kfym5s/difference...
[2] https://www.reddit.com/r/haskell/comments/18yj7i5/i_have_jus...
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.
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.
I've heard of orbs but what is it actually?
It’s basically self-contained cloud agents. I’m not sure why they’re called that but I think it’s just the next grift, kinda like “loops”…
Queue the hoards of Python haters apparently.
*cue
*hordes
just my 2c but py is honestly one of the worst languages and ecosystems i’ve used in my life.
for all the hate js used to get, py is at least a few magnitudes worse.
my opinion ofc. don’t get mad xD
I'm not mad, but curious - I use Python for years and only dabbled with JS. Could you elaborate what makes Python magnitide worse than JavaScript?
Don't mind the web designers calling themselves engineers.
There's a lot of annoying issues with Python, but compared to the billions of dollars and thousands of man hours that has been spent trying to fix Javascript and how horrible it still is, it's a perfectly cromulent language.
There are two kinds of languages, ones that people complain about and ones nobody uses.
Webmasters would like a word
cool insult, yet i chose those 2 languages exactly because they're popular and horrible as examples.
let me guess you work somewhere that hired you to bikeshed all day
Not OP, but dependency management, for one.
Really? https://www.destroyallsoftware.com/talks/wat
JavaScript has its share of wtfs, so I wonder how much of it is which one someone experienced during some formative window in their learning.
Did you encounter JS first?
Glass house? Was Python written in a bar?
you could shadow True for twenty years and Python just shrugged, then one day it's a SyntaxError and every tutorial you ever wrote breaks. peak Python, honestly.
Python is three scripting languages in a trench-coat.