Live data from Hacker News

Writing Python like it's Rust

kobzol.github.io

31–40 of 369 posts

Re: Writing Python like it's Rust

#31
post #9

I've seen a bunch of code like this, usually written by juniors once they get a bit of experience and discover the concept of types. A surefire way to make your Python code terrible. The whole point of Python is the duck typing. If you're not going to use that then you might as well use a real programming language.

Typically, the selection of a programming language is predetermined in brownfield projects, leaving little room for choosing the "ideal" programming language for migration unless it is absolutely necessary (go can be a suitable option for migrations).

Code, like the one provided by the OP, should be valued and encouraged to prevent future bugs. Incorporating tools like Mypy during pre-commit and pyright during code editing can make a significant difference. This approach helps eliminate the need for writing unnecessary unit tests that check for None type.

In my opinion, as a mid-senior developer, I always appreciate the use of types in Python. If you are confident about having predictable inputs, you can rely on duck typing and use it primarily for scripting purposes.

Re: Writing Python like it's Rust

#32
post #12

Earlier quoted context omitted.

Can you enumerate the languages that you deem "real" and those you don't? I have a very hard time understanding what meaning you give to that word.

Languages that you would build serious production software in, rather than some script. C, C++ are the main ones.

So you deny that the industry used Python to build serious production softwares?

Understood, no need to argue then, I don't think any amount of proof would change your mind...

Re: Writing Python like it's Rust

#33
post #12

Earlier quoted context omitted.

Can you enumerate the languages that you deem "real" and those you don't? I have a very hard time understanding what meaning you give to that word.

Languages that you would build serious production software in, rather than some script. C, C++ are the main ones.

Lots of production software is written in Python, for better or for worse. In fact, production software gets written in every language eventually, no matter the intent of its designers. Maybe you only write your production software in C and C++, in which case good for you.

Re: Writing Python like it's Rust

#34
Cool post, I've also been using more and more type hints and it really makes writing python more enjoyable. Although unfortunately it's still quite common for libraries to not have type stubs.

On the section of construction functions, I've always used/seen `@classmethod` instead of `@staticmethod`. I just had a quick look at some big python libraries (pandas, transformers), and they do use class methods. Is there any particular reason you'd want to use static methods instead?

Re: Writing Python like it's Rust

#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 use unless you're an engineer for those companies.

Am just curious if mypy is really the best option right now?

[1] https://github.com/google/pytype [2] https://pyre-check.org/

Re: Writing Python like it's Rust

#36
post #12

Earlier quoted context omitted.

Can you enumerate the languages that you deem "real" and those you don't? I have a very hard time understanding what meaning you give to that word.

Languages that you would build serious production software in, rather than some script. C, C++ are the main ones.

Out of genuine curiousity, what do you consider as serious production software? C C++ would probably help in embedded but I highly doubt they are used in every other domains.

Re: Writing Python like it's Rust

#37

So cool. I love rust and my day job is in Python. But I have a question. I'm a junior dev(gimme some leeway here). I don't really understand how important these design patterns are because in the programs I write, I usually write the classes and call them in runtime myself. I think usually we write the servers and client ourselves. Let's take the different client types example. You are making an assumption that users…

I have limited development experience but I would say this is taking shared libraries into consideration, where you want your public API as comprehensible and failproof as possible. Now put yourself in the shoes of the library user in both scenarios, you will clearly see which code is more prone to errors. The code presented in the article looks like something I'd feel comfortable working with.

It is also more convenient for your own private libraries, but makes not so much of a difference for one-off scripts you maintain alone (unless you are also the type that forgets what you were even doing in that script a few months from now, in which case you could benefit like me). It's about lowering cognitive overhead and chance of development errors in the long run if everything is nicely abstracted.

Re: Writing Python like it's Rust

#38
I started my programming journey with C# which is a statically typed language, and when I later was introduced to Python when I was in college, I really liked how convenient it is but the lack of typing made me really uncomfortable.

Re: Writing Python like it's Rust

#39

The thing with type hints in Python is that it's not enforced unless you make and maintain checking it as part of your workflow. And it comes with a bunch of things, at least: make sure to configure mypy, make sure you run mypy after push (experienced pythonists will forget to run it before), make sure everyone's IDE has it integrated, make sure to be super clear on which version of mypy you run (so errors people see…

Having mypy in the pre-commit hook helps a lot! (But I agree that difference between mypy versions is a pain.)

Re: Writing Python like it's Rust

#40

The thing with type hints in Python is that it's not enforced unless you make and maintain checking it as part of your workflow. And it comes with a bunch of things, at least: make sure to configure mypy, make sure you run mypy after push (experienced pythonists will forget to run it before), make sure everyone's IDE has it integrated, make sure to be super clear on which version of mypy you run (so errors people see…

It's not that many steps. You already have CI - adding mypy is one extra line, you should already have a way to keep track of versions in your project - keeping track of the mypy version isn't any additional overhead.

If your team uses VSCode, you can have a devcontainer for the project (https://code.visualstudio.com/docs/devcontainers/containers) to make sure that it's in everyone's IDE along with your other linters, formatters etc and you can also have pre-commit hooks.

Post reply on HN