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

61–70 of 369 posts

Re: Writing Python like it's Rust

#61

Post by Kwpolska »

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…

Seconded, C# is a great language these days. LINQ is just magic (in a good sense of the word), doubly so when it’s seamlessly translated into SQL by Entity Framework.

Re: Writing Python like it's Rust

#62

Post by asib »

mgaunard wrote: post #46
hmry wrote: post #33

Earlier quoted context omitted.

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.

I do write Python code used in production, but does that doesn't make it serious production software. It takes a lot of effort to make a Python program not break on some inputs, so it's not really fire and forget like it is with C++. It's possible but it requires many more iterations.

> ...so it's not really fire and forget like it is with C++.

Seriously questionable assertion to my eyes. Maybe I just haven't used C++ in way too long to appreciate that it's true. I have heard lots of people say that modern C++ is really great.

Re: Writing Python like it's Rust

#63

Post by oefrha »

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

Factory methods should be class methods if the class is meant to be inherited from. Since most classes people write day to day aren’t going to be inherited from, ever, the distinction is irrelevant for the most part. I doubt they have a particular reason for choosing the less extensible option.

Re: Writing Python like it's Rust

#64

Post by Kwpolska »

JodieBenitez wrote: post #59
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…

> One thing that kept me using [language X] was [insert awesome library here] And that's why I keep [language X], because sometimes the equivalent in [language Z] is not as good.

If [awesome library] is the primary thing your code does, then sure, you might be stuck with [language X]. But if it isn’t, then perhaps the [language Z] replacement might be good enough (or better but not yet well understood, as in the case of the OP), or you might keep [language X] just for that small component.

Re: Writing Python like it's Rust

#65

Post by asib »

throwaway290 wrote: post #22

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…

Don't all the exact same problems exist with e.g. what version of Python or what formatter/linter your team uses? I don't see how this is unique to mypy.

There is undoubtedly setup with all these tools, but the benefit massively outweighs the cost to my mind.

Re: Writing Python like it's Rust

#66

Post by [deleted] »

mgaunard wrote: 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.

[deleted]

Re: Writing Python like it's Rust

#68

Post by hakuseki »

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

Re: Writing Python like it's Rust

#69

Post by Kwpolska »

csunbird wrote: post #58
Kwpolska wrote: post #53

Earlier quoted context omitted.

Named tuples, typed or not, are a bad idea for most data structures. They might make some sense when dealing with coordinates (x, y, z), but why would you want to use it for an Employee class, as shown in the example? This is a tuple, so you can iterate over it, employee[0] == "Guido", and employee[1] == 3. This isn’t useful in any way, it’s confusing, and it’s making it harder to change the order of fields in this c…

Isn’t the whole point of named tuples to not iterate over indexes, but to iterate over field names instead, e.g employee.name, employee.salary? You can also use typing.namedtuple as a baseclass for your classes to have the same functionality .

Named tuples have both field names and numeric indexes. If you iterate over a namedtuple, you just get the values. The field names are hidden in a _fields attribute, there is no way to iterate over (name, value) pairs.

Re: Writing Python like it's Rust

#70

Post by arcanemachiner »

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…

I just did some highly unscientific spelunking on the topic a couple hours ago, and my takeaway was more or less that a bunch of people on reddit said pyright was better.
Post reply on HN