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

291–300 of 369 posts

Re: Writing Python like it's Rust

#291

Post by __MatrixMan__ »

eyegor wrote: post #166
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/charliermars…

Has anyone managed to get ruff to work when run as a pre-commit hook in a project whose deps (such as python and pre-commit) are declared in a flake.nix?

I love being able to pop between devices and have a uniform dev experience everywhere, but ruff is a thorn in my side. pre-commit can't be told to just use the ruff binary /nix/store and fails to install it correctly, so things get hacky.

Re: Writing Python like it's Rust

#292

Post by roflyear »

mumblemumble wrote: post #249
roflyear wrote: post #161

Earlier quoted context omitted.

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

I think you're right, but maybe times that those mantras change.

Re: Writing Python like it's Rust

#293

Post by DangitBobby »

kgeist wrote: post #226
DangitBobby wrote: post #203

Earlier quoted context omitted.

More Pros: * Compiling to a single binary is awesome * Rich library ecosystem at this point * Backwards compatibility is a priority so you can be pretty sure code you wrote yesterday will work tomorrow More Cons: * Unused variables and imports are a compilation error which is INCREDIBLY annoying during development (number one frustration with the language) * If you work with a team or a legacy project, you will almos…

>Unused variables and imports are a compilation error which is INCREDIBLY annoying during development It's easily solved with: _ = unused_variable _ "unused_import" Sure, it's annoying, but not in an incredible way :) Before I knew about this trick, I used to temporarily delete or comment out all related code, which is indeed incredibly annoying.

I know about it. Still incredibly annoying. I shouldn't need to do anything, it should just be completely ignored unless I run a linter or compiler in pedantic mode.

Re: Writing Python like it's Rust

#294

Post by DangitBobby »

sidlls wrote: post #270
DangitBobby wrote: post #203

Earlier quoted context omitted.

More Pros: * Compiling to a single binary is awesome * Rich library ecosystem at this point * Backwards compatibility is a priority so you can be pretty sure code you wrote yesterday will work tomorrow More Cons: * Unused variables and imports are a compilation error which is INCREDIBLY annoying during development (number one frustration with the language) * If you work with a team or a legacy project, you will almos…

Unused variables are an indication that the author hasn't completed their thought, so to speak, in the best case. In the worst case, it's a mistake and indicates the code is likely implemented in a way that it does something other than what it intended. I think making it a compiler error is the right way to do it. Other languages should adopt it.

The thing about software in development is that it isn't complete, practically by definition. I don't litter my code with unused imports and variables, I just have some stuff hanging out below while fixing it above. This is what linters are for, and unused variables and imports weren't the thing making software unmaintainable. Could even have a compiler flag that errors on unused for prod builds. There are a bunch of ways to skin a cat.

Re: Writing Python like it's Rust

#295

Post by throwaway290 »

jstx1 wrote: post #251
throwaway290 wrote: post #221

Earlier quoted context omitted.

> You already have CI Don't worry about me. I mean all projects that do not have people and resources for this stuff. People just want to write Python and be done with it. Without type hints they wrote Python and if they run it and tests pass then it works. Now they write Python code that can be wrong but they don't find out unless they also run an extra tool. The fact that it requires CI now is a good illustration o…

I don't understand who the "just want to write Python and be done with it" demographic is. If you're a developer, it makes sense to do things well, if you aren't and you're writing small one-off scripts, you can do fine without type hints. Anyone who can write and run a test can also call "mypy ." on their project.

Of course, but they forget.

So when you see type declarations in Python, you cannot trust them the way you can trust them in Rust or TypeScript. Outright wrong types that make zero sense cause no errors, no test failures, etc. Type validation is reduced to the level of linter, and no one really cares about the linter the same way as they care about working code.

This gets people new to static typing into bad habits and loses the main benefit of type system.

Re: Writing Python like it's Rust

#296

Post by giantrobot »

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…

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 testing that inside a method or with a decorator or something (and verifying with tests).

Even a big project can hum along happily without type hints. They're also something you can add with relative ease at any point.

Re: Writing Python like it's Rust

#297

Post by dragonwriter »

giantrobot wrote: post #296
Yoric wrote: post #218

Earlier quoted context omitted.

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

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 your QoL vs. code quality argument.

With typing, the type-checker can statically find potential errors in your description, or in my attempt to follow it—that’s a code quality feature. (Of course, that it does provide a description, and a better chance that the description is correct, is also a QoL issue.)

Re: Writing Python like it's Rust

#298

Post by digdugdirk »

__MatrixMan__ wrote: post #290
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…

You're absolutely right that: > Often the answer to this question unfortunately is not a technological merit, but knowledge of a team and willingness to learn. And for the software engineer, this is also true: > [it is] important ... to learn multiple programming languages But I don't think the majority of python users are software engineers. They're data analysts, they're scientists, they're students. They'll never…

100% this. As one of those people graduating from "Maker of Excel-abominations", I absolutely love that python can shape itself to my learning curve, while being useful the whole way through.

Articles like this expose people like me to concepts of typing that I never would get otherwise, and by practicing the concepts in python I might eventually be able to make the leap.

Re: Writing Python like it's Rust

#299

Post by havercosine »

BiteCode_dev wrote: post #107
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…

To be fair, a division between hell and heaven will happen with any language. The question is: is this particular hell worth the result? There is no generic answer to that of course, it just happens is has been the case for me during those 20 years. First, you have to get to the industrialization phase. And of course, you have to get there, with the constraint of time, budgets, and talent. Second, Python does have le…

Wholeheartedly agree. I'm a self taught programmer who programs to get things done rather than just doing programming for fun (I started in ML/data science field). That way, my code often resembles the caricature of these hacky codebases alluded above. And I'm well aware of it.

I often have arguments about utility of Python with my more technically solid engineer friends who keep telling me "Python doesn't scale" etc. And I often come back to the same point you highlighted: is the particular hell worth the result? For 85-90% of the cases the answer is resounding yes.

For nimble teams, startup projects, internal tools : most of the code is often thrown away eventually. Python's beauty is that the language quickly gets out of the way. Everyone then is forced to focus on complexity of the business domain, "does the code solve the business problem". The architecture/scale/speed problems will eventually arrive with Python. But most purist engineers overestimate how soon it will come. At most of the failed startup attempts I was part of, the PMF problem was more pressing to solve than software constraints.

Early days of YouTube, Dropbox, Instagram (and maybe OpenAI too) are big testament to this. I've made my peace these days by not fighting to prove Python is the best language etc. If someone tells me "Rust beats Python" kind of argument: I say I agree, wish them luck and focus on shipping things.

tl:dr; Python is still the best choice to "quickly deliver value and test your business hypothesis".

Re: Writing Python like it's Rust

#300

Post by ReflectedImage »

havercosine wrote: post #299
BiteCode_dev wrote: post #107

Earlier quoted context omitted.

To be fair, a division between hell and heaven will happen with any language. The question is: is this particular hell worth the result? There is no generic answer to that of course, it just happens is has been the case for me during those 20 years. First, you have to get to the industrialization phase. And of course, you have to get there, with the constraint of time, budgets, and talent. Second, Python does have le…

Wholeheartedly agree. I'm a self taught programmer who programs to get things done rather than just doing programming for fun (I started in ML/data science field). That way, my code often resembles the caricature of these hacky codebases alluded above. And I'm well aware of it. I often have arguments about utility of Python with my more technically solid engineer friends who keep telling me "Python doesn't scale" etc…

Python scales fine as long as you know microservices.

The issue is people assuming that they don't need to learn anything new to use Python.

You got people stating that using static typing in a dynamically typed language like Python is a good or reasonable idea. It's not.

But people don't want to put in the effort to learn things like dynamic typing and microservices.

Post reply on HN