Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing Python like it's Rust

kobzol.github.io

Post reply on HN
Print view View original

311–320 of 369 posts

Re: Writing Python like it's Rust

#311

Post by kobzol »

throwaway894345 wrote: post #261
BiteCode_dev wrote: post #76

Lots of comments here are stating that typing is half baked in Python, and that if you gotta use types, you should use another language. But that's missing the point that Python is still not meant to be the best at anything, but good at most things. And in this case, it's exactly what you get: optional typing, with decent safety if you need it. You can quick script or design seriously, you can explore in a shell or c…

I’ve been a Python developer for about 15 years and it isn’t good at most things. Performance is bad, package management is bad, typing is bad, async is bad, etc. Mostly it shines these days because of early mindshare in an exploding niche (AI/ML/numeric computing).

Hey now. Async in Python ain't that bad :)

Re: Writing Python like it's Rust

#312

Post by giantrobot »

dragonwriter wrote: post #297
giantrobot wrote: post #296

Earlier quoted context omitted.

The thing is type hints in Python are less a code quality feature and more a quality of life feature for developers. As long as I've got descriptive argument names and docstrings I can just tell you how to use a method. Your IDE can at least tell you argument names. Type hints help reduce cognitive load when someone else (or you in the future) is trying to use some code. If you have strict type requirements you're te…

> The thing is type hints in Python are less a code quality feature and more a quality of life feature for developers. They are absolutely a code quality feature. > As long as I've got descriptive argument names and docstrings I can just tell you how to use a method. Yes, you can, but that doesn’t seem to be germane to the argument, since “it is possible to communicate intended use without typing” doesn’t support you…

> Yes, you can, but that doesn’t seem to be germane to the argument, since “it is possible to communicate intended use without typing” doesn’t support your QoL vs. code quality argument.

Jillions of lines of quality Python were written before type hints. They're not strictly necessary for writing quality code. If you find modern code that's high quality it probably uses type hints but type hints don't automatically make high quality code.

Re: Writing Python like it's Rust

#313

Post by kobzol »

__MatrixMan__ wrote: post #239

I like these ideas, and practice many of them regularly. Unfortunately one gets the feeling that they're swimming upstream a bit of the time. For instance: data classes instead of tuples or dicts. Great, love it. Now add immutability (frozen=true isn't enough so you're probably going to need pyrsistent) and serialization (dataclasses_json works reasonably well for this), and precommit hooks with pyright or mypy... An…

I agree that it's not easy to explain this to other people, and Python tooling in general is pretty terrible. OTOH, having types in the code and giving newcomers to the codebase the ability to actually see what types "flow" through functions, and having the ability to "Go to definition" is a big benefit for introducing old Python code to newcomers.

Re: Writing Python like it's Rust

#314

Post by kobzol »

k1next wrote: post #303

I really like type hints in Python. It allowed me to catch several errors before running code. But it isn't always the most straight forward process. However, my most frequently occurring thought is: I'm doing all the typing, I wish I could get some performance benefits out of it.

Good point! Guido mentioned that maybe in the future, the new "mini-JIT" in CPython might be able to leverage the type hints. I also want to have this as a thesis topic for my students, to try it out.

Re: Writing Python like it's Rust

#315

Post by berkes »

Yoric wrote: post #100
BiteCode_dev wrote: post #76

Lots of comments here are stating that typing is half baked in Python, and that if you gotta use types, you should use another language. But that's missing the point that Python is still not meant to be the best at anything, but good at most things. And in this case, it's exactly what you get: optional typing, with decent safety if you need it. You can quick script or design seriously, you can explore in a shell or c…

On the one side, yes Python is incredibly versatile. On the other side, I have worked on many Python projects, some of them fairly high profile, and I have seen exactly two kinds of Python codebases: 1. a few were written by extreme professionals, plugging at every single hole, with ~100% coverage, plus considerable maintenance because every dependency upgrade tends to break something; 2. many that feel cobbled toget…

I see exactly this with Ruby. In that regard, Ruby and Python too, are very alike.

Re: Writing Python like it's Rust

#316

Post by berkes »

fastasucan wrote: post #276
BiteCode_dev wrote: post #76

Lots of comments here are stating that typing is half baked in Python, and that if you gotta use types, you should use another language. But that's missing the point that Python is still not meant to be the best at anything, but good at most things. And in this case, it's exactly what you get: optional typing, with decent safety if you need it. You can quick script or design seriously, you can explore in a shell or c…

>Lots of comments here are stating that typing is half baked in Python, and that if you gotta use types, you should use another language. Its weird that so many conflate "this would be nice to have" with "this is the most important factor when deciding on a programming language". I think, obviously, very few Python users have type safety as their most important factor when deciding on a programming language.

> very few Python users have type safety as their most important factor

This is a text-book example of selection-bias though.

Re: Writing Python like it's Rust

#317

Post by kobzol »

quietbritishjim wrote: post #15

> Dataclasses instead of tuples or dictionaries The point is good in general, but it's still perfectly possible to use tuples and get all the field name and typing benefits: just use typed named tuples [1]. Unfortunately this is buried in the typing module. I couldn't even find it in the table if contents, and I knew what I was specifically looking for. https://docs.python.org/3/library/typing.html#typing.NamedTu...

I didn't know about that, thanks. I kind of agree with a sibling comment that in most cases you don't want to expose an indexer if the fields are named, but it might be useful sometimes.

Re: Writing Python like it's Rust

#318

Post by kobzol »

hakuseki wrote: post #68

The `find_item` example uses List for an argument. To my thinking, this indicates that the function is intended to mutate the argument. I don't think that was the author's intention, though, so I would prefer to use Sequence in this situation (or possibly Iterable, if we only need to traverse the sequence once in order).

Someone else also mentioned this on Reddit, good point.

Re: Writing Python like it's Rust

#319

Post by kobzol »

CoastalCoder wrote: post #184

I'm curious how much our early programming experiences fix (as in, make permanent) our mindset about types. As a little kid, I dabbled a bit in BASIC. But my more formative years, in high school and college, really centered on statically typed languages: Pascal, then C++. In the 20+ years since then, statically typed languages have always seemed far saner to me than, e.g. Python. I can think of various explanations f…

This probably plays a role. But for me, I started with C#, but still after I later used Python, I wasn't using types at all. Only after I got more experience in programming, and especially was exposed to Rust, then I started to write Python in a.. different way :)
Post reply on HN