Earlier quoted context omitted.
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: app…
Python's pre-declared constants are kinda weird
161–170 of 234 posts
Re: Python's pre-declared constants are kinda weird
#162Earlier quoted context omitted.
> 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 inst…
> 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.
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.
Re: Python's pre-declared constants are kinda weird
#163Earlier quoted context omitted.
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.
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.
Re: Python's pre-declared constants are kinda weird
#164Earlier quoted context omitted.
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.
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.
Re: Python's pre-declared constants are kinda weird
#165Earlier quoted context omitted.
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.
Ruby can interface with C (or Odin, or anything that can export C style functions) just as easily.
Re: Python's pre-declared constants are kinda weird
#166Earlier quoted context omitted.
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.
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 ofte…
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.
Re: Python's pre-declared constants are kinda weird
#167Earlier quoted context omitted.
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.
It’s really worth a second look.
Re: Python's pre-declared constants are kinda weird
#168Earlier quoted context omitted.
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.
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.
Re: Python's pre-declared constants are kinda weird
#169Earlier quoted context omitted.
> 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 is a rough edge. For those unfamiliar, t…
Agreed. Instead of special casing Boolean arrays to be packed, it's better to have standard Boolean arrays and bitarrays as separate types.
Re: Python's pre-declared constants are kinda weird
#170Python 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.
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.