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

241–250 of 369 posts

Re: Writing Python like it's Rust

#241

Post by ptx »

more-coffee wrote: post #118
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…

For your mypy performance question, make sure it's using incremental mode [1] so that it can skip checks on code that didn't change. Yes, it is probably among the slowest of type checkers, but it is also quite thorough. [1] https://mypy.readthedocs.io/en/stable/command_line.html#incr...

It sounds like incremental mode is the default now? I've noticed that it runs much faster after the initial run, with no special configuration

But that link also mentions daemon mode [1], which supposedly "can be 10 or more times faster", so that could be something to try. Running as a persistent server with an in-memory cache is probably part of why LSP-based type checkers like Pyright can perform better than mypy.

[1] https://mypy.readthedocs.io/en/stable/mypy_daemon.html#mypy-...

Re: Writing Python like it's Rust

#242

Post by martopix »

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 think this is a form of selection bias. Certain other languages wouldn't even allow a project like your point 2. to get started. In Python, the bar for something to start kind of working is quite low, even if you're a beginner, a scientist of another discipline who needs a little script to manage some data, a teen who's learning to code, etc. So of course you see a lot of half-baked stuff. It's important we distinguish between 1. and 2., but 2s might sometimes be better than nothing.

Re: Writing Python like it's Rust

#243

Post by mumblemumble »

Yoric wrote: post #218
giantrobot wrote: post #199

Earlier quoted context omitted.

> Something I really like about Python for this sort of thing is that I have a lot more ability to delay this industrialization stuff to the last responsible moment This is one of my favorite aspects of Python. I can start with every module in prototype form and industrialize each module as its design firms up. I can spend my early development getting an idea fleshed out with minimal overhead.

> I can start with every module in prototype form and industrialize each module as its design firms up. That is definitely the theory. And this flexibility is indeed very precious for some types of work. However... does it actually happen as you describe? I can count on half of the fingers of one hand the number of Python codebases that I've seen that actually feel like they've properly been reworked into something o…

Wandering offtopic, perhaps, but I've noticed that this kind of behavior seems to strongly correlate with Scrum.

The work starts getting rushed toward the end of the sprint. Every two weeks, people start furiously cutting corners to meet a completely artificial due date. And then there's basically zero chance that you'll be able to get the PO to agree to cleaning it up in the next sprint, because they can't see the problem.

Scrum of course prescribes all sorts of adornments you can add to try and counteract this effect. But I'm a firm believer that an ounce of prevention is worth a pound of cure.

Re: Writing Python like it's Rust

#244

Post by smnrchrds »

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.

I didn't know about typeguard. Thank you for the recommendation!

How do you do this in Pydantic though?

Re: Writing Python like it's Rust

#245

Post by lyu07282 »

hakanderyal wrote: post #43

I went through a similar journey, without the Rust part. Started using type hints, data classes, pydantic to get the benefit of static typing after dealing with the pain of refactoring dynamically typed projects. It was better, but it _feels_ like lipstick on a pig. I love Python, but types are not what it's best at. It's missing features that makes typing easier. I've realized if was going to write typed Python, I m…

I'm also 100% convinced most people who use mypy don't realize the myriad ways it just silently stopps typing things or just silently crashes with a 0 exit code. Even if you configure it to warn untyped functions etc. It will still just not work properly in some of circumstances and you will literally never know until you debug a bug that just happened to trigger it. There are over 1.4k open bug tickets it's such a broken piece of software: https://github.com/python/mypy/issues?q=is%3Aissue+is%3Aopen...

The involvement of Guido in mypy is such a tragedy.

Re: Writing Python like it's Rust

#246

Post by jeroenhd »

Sosh101 wrote: post #130
ptx wrote: post #95

Earlier quoted context omitted.

Another difference you might be surprised by is that the .NET tooling by default collects various data from your system and sends it to Microsoft [1]. If you want to avoid this (and still want to use .NET) you'll have to make sure that the environment variable DOTNET_CLI_TELEMETRY_OPTOUT is set to 1 in all contexts before touching anything. [1] https://github.com/dotnet/sdk/issues/6145

> DOTNET_CLI_TELEMETRY_OPTOUT I didn't know about this. I wonder how that sits legally with local data protection rules (EU).

I doubt they way they approach it is legal, but I don't think any of the DPAs have time to look into it.

For what it's worth, the tool prints a clear warning the first time you invoke it. You shouldn't need to opt out regardless, but they do at least communicate their stalking.

Re: Writing Python like it's Rust

#247

Post by esafak »

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…

I had personal experience with statically-typed languages before I ventured into industry with Python. Years of working in large python code bases revealed the wisdom of once again returning to statically-typed languages.

Re: Writing Python like it's Rust

#248

Post by Yoric »

martopix wrote: post #242
Yoric wrote: post #100

Earlier quoted context omitted.

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 think this is a form of selection bias. Certain other languages wouldn't even allow a project like your point 2. to get started. In Python, the bar for something to start kind of working is quite low, even if you're a beginner, a scientist of another discipline who needs a little script to manage some data, a teen who's learning to code, etc. So of course you see a lot of half-baked stuff. It's important we disting…

Absolutely. In some domains, the choice is between 2. and nothing – and 2. is better. That's true for Python or JavaScript, for instance (in each their domain).

I believe that we agree that there are actually many domains in which you really want 1., and if you can't have it, then "nothing" is generally preferable to 2.

Re: Writing Python like it's Rust

#249

Post by mumblemumble »

roflyear wrote: post #161
clawlor wrote: post #151

Earlier quoted context omitted.

> [...] 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.

Incremental change is good as long as the increments can themselves be changed. When you're promising indefinite backward compatibility, it's important to be VERY confident of each change before committing to it.

It seems like the price of all these small incremental changes in Python is that the language as a whole keeps falling further and further away from the 13th item in PEP20: "There should be one - and preferably only one - obvious way to do it." Also, for that matter, "Never is often better than *right* now."

Re: Writing Python like it's Rust

#250

Post by esafak »

okasaki wrote: post #181
Shish2k wrote: post #168

Earlier quoted context omitted.

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

I mean I can't even imagine what would lead anyone to write millions of lines of Python for a single project, so maybe there's a level of serious above what I do. Maybe you're doing it wrong?

How many engineers does your company have? When you have thousands it is easy to write millions of lines of code.
Post reply on HN