Live data from Hacker News

Python's pre-declared constants are kinda weird

sebsite.pw

161–170 of 234 posts

Re: Python's pre-declared constants are kinda weird

#161
post #138

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…

Yes, that's a Path object from pathlib. It has been around for while but likely still qualifies, site says from 3.4.

Re: Python's pre-declared constants are kinda weird

#162
post #158

Earlier 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.

> 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/

Re: Python's pre-declared constants are kinda weird

#163
post #71

Earlier 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.

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.

Re: Python's pre-declared constants are kinda weird

#164
post #71

Earlier 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.

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.

Re: Python's pre-declared constants are kinda weird

#165

Earlier 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.

I would argue more easily.

Re: Python's pre-declared constants are kinda weird

#166

Earlier 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…

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.

Re: Python's pre-declared constants are kinda weird

#167
post #31
post #8

Earlier 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.

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.

Re: Python's pre-declared constants are kinda weird

#168
post #38
post #8

Earlier 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.

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.

Re: Python's pre-declared constants are kinda weird

#169

Earlier 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.

They should have made `std::bitset` what todays `std::vector` is (actually maybe not, `std::bitset` is fixed sized, just compile time fixed size). While at it also make `std::array` a runtime fixed size array.

Re: Python's pre-declared constants are kinda weird

#170
post #71

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.

Post reply on HN