Comment by mdaniel a day ago
> but it's a lot easier for me to hack on Rust projects
That static typing is nice, I wonder if it's going to catch on one day.
The amount of energy spent trying to bend dynamically types languages into being real ones is just comical. Even the standard library is barely typed, so they give no fucks https://github.com/python/cpython/blob/v3.13.3/Lib/re/__init...
What does it accept? Who knows. What does it return? Don't worry about it
Also, the Zen of Python is supposed to be one obvious way to do something but ddg "python dependency manager" and have a good laugh. That actually becomes triple lol for when uv steps in and says "uh, your pip requirements.txt is unsatisifyable, what are you even?!"
And let me just say what an absolutely stellar job the rustc authors have done with the error messages. Just out of this world thoughtful. I have not yet gotten on board with their compile time vs safety and insight tradeoff, but I can see why they chose those two axes
Yeah, and static typing is not limited to Rust, and there are many other programming languages that do not have any of that venvs / pip nonsense.
What languages? I'm asking this earnestly, because there are dozens of languages I can name but I have not used. Every language I've used (except maybe Julia) asks you also to install and use something extra, like "meson" or "ninja" or "maven" or "cmake", for its build phase.
You want languages that can be compiled similarly to "cargo build"? Well, Go is one of them. Many C projects are just one "make" command away. OCaml has "dune build". Odin has "odin build", too. There are a lot of other languages I am missing here though.
Type inference is handy, but as an observation source code is 90% written for humans - I believe that CPython knows what types they are, that's how TypeError even exists, but seeing "def doit(erthang):" doesn't help me in the slightest. Often PyCharm can figure it out, because bless their hearts, but then developers whine about "wwwaaa, pycharm too slo grug use ed" and then one gets AttributeError in production because who could have foreseen
regex.match takes strings and returns a match object. There are most likely stubs, if you are new to it and need support.
It is exactly two strings that are required. The docs are there for flags etc, use them. Types were not entered directly into stdlib source for historical reasons.
If you would enjoy further support, install stubs from typeshed.
> It is exactly two strings that are required
It is exactly as I said, it's not just strings
$ python3.12 -c '
import re
pat = re.compile("who knew")
ma = re.match(pat, "who knew types matter")
print(ma)
'
<re.Match object; span=(0, 8), match='who knew'>
I guess it's good we're all using LLMs nowadays, since in general computers no read so good, that's why we write in specialized languages for their benefit. That would include this fancy new thing I've heard about where one writes down what the input and output domains are for functions
> Types were not entered directly into stdlib source for historical reasons.
Historical reasons defeats the purpose of having git tags, to say nothing of them having several concurrent branches named after the various release trains. I mean, historically print was a keyword, but you sure don't see them from __future__ import print_statement all over the 3.12 tree now do you? It's because they DGAF preferring there to be seemingly unlimited aftermarket tooling to try and drag python3000 into the 21st century
> If you would enjoy further support, install stubs from typeshed.
While trying to dig up whatever a sane person would use to "install stubs" -- because it for damn sure isn't $(pip install typeshed) -- I learned that you were even more incorrect - it accepts bytes, too https://github.com/python/typeshed/blob/9430260770b627c04313...
Anyway, they also go out of their way to say "don't install typeshed" and I guess that's why they don't have any git tags because releases are for children
Right, the first arg can also be a compiled pattern|bytes. Not an issue in the real world however. The problem is when it can't handle what you give it, not when it can handle what you give it and additional things.
Normally you'd use `pattern.match(string)` in that case.
They said specifically more than once that they're not going to change (almost) every line in the repo for any reason, and not only to types but other syntax improvements. Probably to keep git blame intact and avoid introducing new bugs.
Honestly, this reads as an obsession with theoretical concerns.
Static typing is a big one, but I've been so steeped in Python that I don't appreciate it as much as maybe I should.
The big thing for me is that most Rust projects are statically(ish) compiled (like go) and only need a `cargo build`. No venvs or pip commands or node/npm/nvm or make, etc.