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

161–170 of 369 posts

Re: Writing Python like it's Rust

#161

Post by roflyear »

clawlor wrote: post #151
miiiiiike wrote: post #125

I can’t get over how clunky Python 3 is getting. Does anyone like working with type hinting in Python? All of my code is typed but compared to basically every other type system the process was far more painful than it should have been. Even years later I still keep printouts of the typing documentation next to me so I can save time when I invariably need to look up the multiple ways you can define ‘T’ when it would j…

> [...] when it would just be ‘class Foo ’ in almost any other language. Good news on that front at least. PEP-895 [1] removes the need for `T = TypeVar(...)` boilerplate in Python 3.12. [1] - https://peps.python.org/pep-0695/

Yes. Incremental change is good imo. They may actually be moving too fast.

Re: Writing Python like it's Rust

#162

Post by zelphirkalt »

orthoxerox wrote: post #104
zelphirkalt wrote: post #102

At some point you gotta ask yourself: Why am I still writing Python then, if I want to write Rust? If I want Rust's safety, why not write Rust then, with battle proven tools and better type system from the start? Often the answer to this question unfortunately is not a technological merit, but knowledge of a team and willingness to learn. You might want to write actual Rust code and there can be any number of benefit…

> At some point you gotta ask yourself: Why am I still writing Python then, if I want to write Rust? If I want Rust's safety, why not write Rust then, with battle proven tools and better type system from the start? Garbage collection

To what end? I think avoiding manual memory management is great, but I never had issues in Rust either, since I don't manage memory manually there either. I think that is kind of a point of Rust, as it avoids that whole class of bugs common in C programs.

But to what end do you want garbage collection (GC)? Just for having GC? Or a more specific purpose, that is difficult to attain with Rust's model?

For example: I usually want tail call optimization in languages I use. But not for it in itself, but for being able to write functions nicely, not having to worry about recursion depth, expressing things more declaratively, avoiding mutation (at least of an explicitly managed stack or any loop variable) and probably other things that don't come to mind right now.

Re: Writing Python like it's Rust

#163

Post by nrakx »

dragonsh wrote: post #158
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…

> But that's missing the point that Python is still not meant to be the best at anything, but good at most things. The most important thing about Python is readability and its part of its syntax and is one of the best languages out there for readability. Zen of python: >>> import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Compl…

That applies to Python 2.7 and the code that Tim Peters writes. It does not apply to current Python and the coding styles that most people employ.

Current coding styles are either:

- Java-like ravioli, with class hierarchies that no one understands.

- Academic functional and iterator spaghetti, written by academics who think Python offers the same guarantees as Haskell.

Both styles result in severely broken code bases.

Re: Writing Python like it's Rust

#164

Post by okasaki »

> I have no idea what is going on from the signature itself. Is records a list, a dict or a database connection? Is check a boolean, or a function? What does this function return? What happens if it fails, does it raise an exception, or return None? [...]

This type of objection is only raised by people who have never seriously used Python before. It sounds convincing that this is a serious flaw in Python, but in practice it never comes up because when you know what domain you're working in it's always immediately obvious what types the arguments are.

Re: Writing Python like it's Rust

#165

Post by NeutralForest »

mejutoco wrote: post #140
NeutralForest wrote: post #73

Earlier quoted context omitted.

A typical pain point where type hinting fails in Python is with list of some types, it can't be enforced by the language without more checks. For example, you can't do: if isinstance(x, list[int]) though it would be super useful

You need to use mypy or similar to not check it at runtime: els: List[int] To test it at runtime you can use typeguard s @typechecked annotation. For convenience you can also use Pydantic.

Yes I know, I'm just pointing out that you need additional tool to check that.

Re: Writing Python like it's Rust

#166

Post by eyegor »

extr wrote: post #35

What is the smart money doing for type checking in Python? I've used mypy which seems to work well but is incredibly slow (3-4s to update linting after I change code). I've tried pylance type checking in VS Code, which seems to work well + fast but is less clear and comprehensive than mypy. I've also seen projects like pytype [1] and pyre [2] used by Google/Meta, but people say those tools don't really make sense to…

Ruff [0] is the best linter around for performance but I'm not sure how well it fills the static analysis role. It has a vscode extension which updates the linting with no noticeable lag but it isn't a full fledged type checker. Their suggestion is to run ruff through the vscode extension and then manually run mypy or whatever type checker on occasion (maybe as a pre commit hook?).

[0] https://github.com/charliermarsh/ruff

Re: Writing Python like it's Rust

#167

Post by zokier »

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…

> the whole ecosystem is always getting better and better.

That is debatable. In many ways the ecosystem is getting more enterprisy, more ceremonious, overall "heavier". I feel Python ecosystem is rapidly losing its winning characteristic lightness that was so defining for it 10ish years ago.

I don't think "modern" Python code like in the article would inspire comics like this https://xkcd.com/353/

Re: Writing Python like it's Rust

#168

Post by Shish2k »

okasaki wrote: post #164

> I have no idea what is going on from the signature itself. Is records a list, a dict or a database connection? Is check a boolean, or a function? What does this function return? What happens if it fails, does it raise an exception, or return None? [...] This type of objection is only raised by people who have never seriously used Python before. It sounds convincing that this is a serious flaw in Python, but in prac…

> This type of objection is only raised by people who have never seriously used Python before

How serious is “serious”? Because I’ve worked on millions-of-lines python projects powering billion-dollar companies, and I 100% agree that maintaining untyped python code that somebody else wrote (or that I wrote myself, 6 months ago) is a nightmare for exactly these reasons...

Re: Writing Python like it's Rust

#169

Post by d0mine »

extr wrote: post #35

What is the smart money doing for type checking in Python? I've used mypy which seems to work well but is incredibly slow (3-4s to update linting after I change code). I've tried pylance type checking in VS Code, which seems to work well + fast but is less clear and comprehensive than mypy. I've also seen projects like pytype [1] and pyre [2] used by Google/Meta, but people say those tools don't really make sense to…

Have tried ruff? It is a Python linter with a speed in mind.

Re: Writing Python like it's Rust

#170

Post by dgan »

okasaki wrote: post #164

> I have no idea what is going on from the signature itself. Is records a list, a dict or a database connection? Is check a boolean, or a function? What does this function return? What happens if it fails, does it raise an exception, or return None? [...] This type of objection is only raised by people who have never seriously used Python before. It sounds convincing that this is a serious flaw in Python, but in prac…

> it never comes up because when you know what domain you're working in it's always immediately obvious what types the arguments are.

Oh this one is hilariously wrong. Is it InvoiceLine that we are getting here? Or Maybe LineInvoice? Nope those aren't the same. But the only argument is called «line». How shameful. Much sadness. Better add a print statement, push a new build and comeback in twenty minutes

Post reply on HN